From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 25 Apr 2024 03:46:47 -0700 Received: from mail-yw1-f188.google.com ([209.85.128.188]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rzwco-00027W-72 for bitcoindev@gnusha.org; Thu, 25 Apr 2024 03:46:47 -0700 Received: by mail-yw1-f188.google.com with SMTP id 00721157ae682-61b2abd30f9sf14548387b3.0 for ; Thu, 25 Apr 2024 03:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1714042000; x=1714646800; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=jprVSjYwlpaIWfkCTXl8AfiZKE3San/wkXjq2vFm5nk=; b=FMFpyvHgthu7m0FfX90KhevrPrc6r8mq8XVj5gPjF48CnJkjpt0/2USwdfVxIJi15a QOh3mCRwlcLhjRjNMcc5HU6xC9bYW7AjP/HCF5SdKVN08nbGyQbsJfQxagHn2udOpZAx eA/qD6nvSqXLgQS0xk+PLo01ygx6UCSMxbu1oJ08EUzJaofH7gX7IZHQHe5VnyttTKlt cb/JqPIggLr5PlBt9Cdu45apaRR0ROfX9llRl29dow6BZx2R71Aa8lxAobSPM2Uh2nwb 8YVsMcbIt2I/uAW1vhjMS9PHoOkEXlRk8XJPQu2nzqPrlDT2iz/bV9JT+bM5yv9KTSce UDFg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714042000; x=1714646800; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=jprVSjYwlpaIWfkCTXl8AfiZKE3San/wkXjq2vFm5nk=; b=hOiUUIEhEQAUpxrVsPDdhDZRFh/woPNSF6NR2WHDh3mkhZOAXfVaSR3RSVXmvVdOfL KbMDTkgbjdzS8UUwcSWl5It0AEdmFxzEkaHw1DBSo7hGZJIhpHQ4heGWlJpNj3kZK9ed Pc/BX4Wbt5TJISRDAflQ1xVQ6ZSPrupI7FERJIKmLRBByJ8tlq1rXin9CkJI8XRBRXfd KwdC1/iPpuxtwmyOhP+aKLvT6yRTTY+jHSGflZQ1Y37OpYWB9ZxaLfIw50ZAbyaMezvL axA1HHM2v44YngV9kO8FXSUHilGJSnK/M9BvoW9GueDklKnfM2ILJ1gHrTK9KUnYxbEX LF+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714042000; x=1714646800; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=jprVSjYwlpaIWfkCTXl8AfiZKE3San/wkXjq2vFm5nk=; b=uGCxHqy6da3r63XamDDO5e7eaCOxJZWxnlpaNsORLi9SenM7Gk5LPxcsWdJvIZR14V facVAepwjVn7dxF8n69BHJ4moIagVFnSiFNRC6NY4O5RDgu8GjSGWzxK0hODXksS19i4 dSu1If5k4Uk27pPWICNBn7MzhLA2hKuKSaV7KhXdMmsbNW8zs/MC6LJsmGabx94ilyEy GZdsfkKGISEW81kdeoxfPcnGOhUTsvgvFflaKgzE6aMLs3FgYYKYGZSWOjKV2xxLLG1/ DQGfzDSFCDQ1w2kHt4LlCCb3Jk1MBnQBYiYl15lSeYxDmMXPYgdyqiu7oa7ImCiToSkD WYUw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCWL4drxQyAME8WWvOHroabqPxLdaHfOh+f01Dve8pUMleIVUgx1X8zJFBkZrzbVpFBy2h/eh5kOduKYd1wxMh4oSPXFqoI= X-Gm-Message-State: AOJu0Yz1ruVYuK0fZcSBNyfzGjnAOOQlQj2QgLI3PSnsKfwR+zFryn5M Z3Uc13edKXMgK9C3Nrs5GPmVJOq3RhAQW9L8lNk6MA0lySoeTY4n X-Google-Smtp-Source: AGHT+IGYP6rHXrNdZL7dcSjJWWwsvXcrgvIAbwaSplxGGMSHwlDuls6h37/lt1sK6wY8NxI6CVnzBQ== X-Received: by 2002:a25:8483:0:b0:dc7:3165:2db1 with SMTP id v3-20020a258483000000b00dc731652db1mr5449545ybk.49.1714041999909; Thu, 25 Apr 2024 03:46:39 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a25:c78b:0:b0:de5:4a92:4349 with SMTP id 3f1490d57ef6-de585ec30b1ls1155887276.0.-pod-prod-09-us; Thu, 25 Apr 2024 03:46:38 -0700 (PDT) X-Received: by 2002:a81:4847:0:b0:617:d650:11e2 with SMTP id v68-20020a814847000000b00617d65011e2mr1279125ywa.3.1714041998388; Thu, 25 Apr 2024 03:46:38 -0700 (PDT) Received: by 2002:a05:690c:10d:b0:61b:61d:c6fe with SMTP id 00721157ae682-61b84b1930ams7b3; Wed, 24 Apr 2024 23:08:33 -0700 (PDT) X-Received: by 2002:a81:5b42:0:b0:61b:32dc:881d with SMTP id p63-20020a815b42000000b0061b32dc881dmr451308ywb.3.1714025312175; Wed, 24 Apr 2024 23:08:32 -0700 (PDT) Date: Wed, 24 Apr 2024 23:08:31 -0700 (PDT) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: <3e93b83e-f0ea-43b9-8f77-f7b044fb3187n@googlegroups.com> In-Reply-To: <8fFFuAU-SN2NrQ2SKhS2eOeLkHIdCQtnivE4LzWe32vk5gejNEwNvr9IIa3JJ-sII2UUIpOx8oRMslzmA1ZL6y1kBuQEB1fpTaXku2QGAC0=@protonmail.com> References: <1KbVdD952_XRfsKzMKaX-y4lrPOxYiknn8xXOMDQGt2Qz2fHFM-KoSplL-A_GRE1yuUkgNMeoEBHZiEDlMYwiqOiITFQTKEm5u1p1oVlL9I=@protonmail.com> <62640263-077c-4ac7-98a6-d9c17913fca0n@googlegroups.com> <8fFFuAU-SN2NrQ2SKhS2eOeLkHIdCQtnivE4LzWe32vk5gejNEwNvr9IIa3JJ-sII2UUIpOx8oRMslzmA1ZL6y1kBuQEB1fpTaXku2QGAC0=@protonmail.com> Subject: Re: [bitcoindev] Re: Great Consensus Cleanup Revival MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_48332_80447901.1714025311801" X-Original-Sender: antoine.riard@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_48332_80447901.1714025311801 Content-Type: multipart/alternative; boundary="----=_Part_48333_907036947.1714025311801" ------=_Part_48333_907036947.1714025311801 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Maaku, > Every single concern mentioned here is addressed prominently in the=20 paper/presentation for Forward Blocks: > > * Increased block frequency is only on the compatibility chain, where the= =20 content of blocks is deterministic anyway. There is no centralization=20 pressure from the frequency > of blocks on the compatibility chain, as the= =20 content of the blocks is not miner-editable in economically meaningful=20 ways. Only the block frequency of the forward block > chain matters, and=20 here the block frequency is actually *reduced*, thereby decreasing=20 centralization pressure. > > * The elastic block size adjustment mechanism proposed in the paper is=20 purposefully constructed so that users or miners wanting to increase the=20 block size beyond what > is currently provided for will have to pay=20 significantly (multiple orders of magnitude) more than they could possibly= =20 acquire from larger blocks, and the block size would re-> adjust downward= =20 shortly after the cessation of that artificial fee pressure. > * Increased block frequency of compatibility blocks has no effect on the= =20 total issuance, so miners are not rewarded by faster blocks. > You are free to criticize Forward Blocks, but please do so by actually=20 addressing the content of the proposal. Let's please hold a standard of=20 intellectual excellence on this > mailing list in which ideas are debated= =20 based on content-level arguments rather than repeating inaccurate takes=20 from Reddit/Twitter. > To the topic of the thread, disabling time-warp will close off an=20 unlikely and difficult to pull off subsidy draining attack that to activate= =20 would necessarily require weeks of > forewarning and could be easily=20 countered in other ways, with the tradeoff of removing the only known=20 mechanism for upgrading the bitcoin protocol to larger effective > block=20 sizes while staying 100% compatible with un-upgraded nodes (all nodes see= =20 all transactions). > I think we should keep our options open. Somehow, I'm sharing your concerns on preserving the long-term evolvability= =20 w.r.t scalability options of bitcoin under the security model as very roughly describer in the paper.= =20 Yet, from my understanding of the forwarding block proposal as described in your paper, I wonder if=20 the forward block chain could be re-pegged to the main bitcoin chain using the BIP141 extensible=20 commitment structure (assuming a future hypothetical soft-fork). >From my understanding, it's like doubly linked-list in C, you just need a= =20 pointer in the BIP141 extensible commitment structure referencing back the forward chain headers. If one=20 wishes no logically authoritative cross-chain commitment, one could leverage some dynamic-membership=20 multi-party signature. This DMMS could even be backup by proof-of-work based schemes. The forward block chain can have higher block-rate frequency and the number= =20 of block headers be compressed in a merkle tree committed in the BIP141 extensible commitment= =20 structure. Compression structure can only be defined by the forward chain consensus algorithm to= =20 allow more efficient accumulator than merkle tree to be used". The forward block chain can have elastic block size consensus-bounded by=20 miners fees on long period of time. Transaction elements can be just committed in the block headers=20 themselves, so no centralization pressure on the main chain. Increased block frequency or block size on the= =20 forward block chain have not effect on the total issuance (modulo the game-theory limits of the known=20 empirical effects of colored coins on miners incentives). I think the time-warp issues opens the door to economically non-null=20 exploitation under some scenarios over some considered time periods. If one can think to other ways to=20 mitigate the issue in minimal and non-invasive way w.r.t current Bitcoin consensus rules and respecting=20 un-upgraded node ressources consumption, I would say you're free to share them. I can only share your take on maintaining a standard of intellectual=20 excellence on the mailing list, and avoid faltering in Reddit / Twitter-style "madness of the crowd"-like= =20 conversations. Best, Antoine Le vendredi 19 avril 2024 =C3=A0 01:19:23 UTC+1, Antoine Poinsot a =C3=A9cr= it : > You are free to criticize Forward Blocks, but please do so by actually=20 > addressing the content of the proposal. Let's please hold a standard of= =20 > intellectual excellence on this mailing list in which ideas are debated= =20 > based on content-level arguments rather than repeating inaccurate takes= =20 > from Reddit/Twitter. > > > You are the one being dishonest here. Look, i understand you came up with= =20 > a fun hack exploiting bugs in Bitcoin and you are biased against fixing= =20 > them. Yet, the cost of not fixing timewarp objectively far exceeds the=20 > cost of making "forward blocks" impossible. > > As already addressed in the DelvingBitcoin post: > > 1. The timewarp bug significantly changes the 51% attacker threat=20 > model. Without exploiting it a censoring miner needs to continuously k= eep=20 > more hashrate than the rest of the network combined for as long as he = wants=20 > to prevent some people from using Bitcoin. By exploiting timewarp the= =20 > attacker can prevent everybody from using Bitcoin within 40 days. > 2. The timewarp bug allows an attacking miner to force on full nodes= =20 > more block data than they agreed to. This is actually the attack lever= aged=20 > by your proposal. I believe this variant of the attack is more likely = to=20 > happen, simply for the reason that all participants of the system have= a=20 > short term incentive to exploit this (yay lower fees! yay more block= =20 > subsidy!), at the expense of the long term health of the system. As th= e=20 > block subsidy exponentially decreases miners are likely to start playi= ng=20 > more games and that's a particularly attractive one. Given the level o= f=20 > mining centralization we are witnessing [0] i believe this is particul= arly=20 > worrisome. > 3. I'm very skeptical of arguments about how "we" can stop an attack= =20 > which requires "weeks of forewarning". Who's we? How do we proceed, al= l=20 > Bitcoin users coordinate and arbitrarily decide of the validity of a b= lock?=20 > A few weeks is very little time if this is at all achievable. If you a= dd on=20 > top of that the political implications of the previous point it gets= =20 > particularly messy. > > > I've got better things to do than to play "you are being dishonest! -no= =20 > it's you -no you" games. So unless you bring something new to the table= =20 > this will be my last reply to your accusations. > > Antoine > > [0] https://x.com/0xB10C/status/1780611768081121700 > On Thursday, April 18th, 2024 at 2:46 AM, Mark F = =20 > wrote: > > On Wednesday, March 27, 2024 at 4:00:34=E2=80=AFAM UTC-7 Antoine Poinsot = wrote: > > The only beneficial case I can remember about the timewarp issue is=20 > "forwarding blocks" by maaku for on-chain scaling: > http://freico.in/forward-blocks-scalingbitcoin-paper.pdf > > > I would not qualify this hack of "beneficial". Besides the centralization= =20 > pressure of an increased block frequency, leveraging the timewarp to=20 > achieve it would put the network constantly on the Brink of being serious= ly=20 > (fatally?) harmed. And this sets pernicious incentives too. Every=20 > individual user has a short-term incentive to get lower fees by the=20 > increased block space, at the expense of all users longer term. And every= =20 > individual miner has an incentive to get more block reward at the expense= =20 > of future miners. (And of course bigger miners benefit from an increased= =20 > block frequency.) > > Every single concern mentioned here is addressed prominently in the=20 > paper/presentation for Forward Blocks: > > * Increased block frequency is only on the compatibility chain, where the= =20 > content of blocks is deterministic anyway. There is no centralization=20 > pressure from the frequency of blocks on the compatibility chain, as the= =20 > content of the blocks is not miner-editable in economically meaningful=20 > ways. Only the block frequency of the forward block chain matters, and he= re=20 > the block frequency is actually *reduced*, thereby decreasing=20 > centralization pressure. > > * The elastic block size adjustment mechanism proposed in the paper is=20 > purposefully constructed so that users or miners wanting to increase the= =20 > block size beyond what is currently provided for will have to pay=20 > significantly (multiple orders of magnitude) more than they could possibl= y=20 > acquire from larger blocks, and the block size would re-adjust downward= =20 > shortly after the cessation of that artificial fee pressure. > > * Increased block frequency of compatibility blocks has no effect on the= =20 > total issuance, so miners are not rewarded by faster blocks. > > You are free to criticize Forward Blocks, but please do so by actually=20 > addressing the content of the proposal. Let's please hold a standard of= =20 > intellectual excellence on this mailing list in which ideas are debated= =20 > based on content-level arguments rather than repeating inaccurate takes= =20 > from Reddit/Twitter. > > To the topic of the thread, disabling time-warp will close off an unlikel= y=20 > and difficult to pull off subsidy draining attack that to activate would= =20 > necessarily require weeks of forewarning and could be easily countered in= =20 > other ways, with the tradeoff of removing the only known mechanism for=20 > upgrading the bitcoin protocol to larger effective block sizes while=20 > staying 100% compatible with un-upgraded nodes (all nodes see all=20 > transactions). > > I think we should keep our options open. > > -Mark > > --=20 > > You received this message because you are subscribed to the Google Groups= =20 > "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an= =20 > email to bitcoindev+...@googlegroups.com. > > To view this discussion on the web visit=20 > https://groups.google.com/d/msgid/bitcoindev/62640263-077c-4ac7-98a6-d9c1= 7913fca0n%40googlegroups.com > . > > > --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/= bitcoindev/3e93b83e-f0ea-43b9-8f77-f7b044fb3187n%40googlegroups.com. ------=_Part_48333_907036947.1714025311801 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Maaku,

> Every single concern mentioned her= e is addressed prominently in the paper/presentation for Forward Blocks:
>
> * Increased block frequency is only on the comp= atibility chain, where the content of blocks is deterministic anyway. There= is no centralization pressure from the frequency > of blocks on the com= patibility chain, as the content of the blocks is not miner-editable in eco= nomically meaningful ways. Only the block frequency of the forward block &g= t; chain matters, and here the block frequency is actually *reduced*, there= by decreasing centralization pressure.
>
> * The = elastic block size adjustment mechanism proposed in the paper is purposeful= ly constructed so that users or miners wanting to increase the block size b= eyond what > is currently provided for will have to pay significantly (m= ultiple orders of magnitude) more than they could possibly acquire from lar= ger blocks, and the block size would re-> adjust downward shortly after = the cessation of that artificial fee pressure.

&= gt; * Increased block frequency of compatibility blocks has no effect on th= e total issuance, so miners are not rewarded by faster blocks.
> You are free to criticize Forward Blocks, but please do= so by actually addressing the content of the proposal. Let's please hold a= standard of intellectual excellence on this > mailing list in which ide= as are debated based on content-level arguments rather than repeating inacc= urate takes from Reddit/Twitter.

> To the top= ic of the thread, disabling time-warp will close off an unlikely and diffic= ult to pull off subsidy draining attack that to activate would necessarily = require weeks of > forewarning and could be easily countered in other wa= ys, with the tradeoff of removing the only known mechanism for upgrading th= e bitcoin protocol to larger effective > block sizes while staying 100% = compatible with un-upgraded nodes (all nodes see all transactions).

> I think we should keep our options open.

Somehow, I'm sharing your concerns on preserving th= e long-term evolvability w.r.t scalability options
of bitcoin und= er the security model as very roughly describer in the paper. Yet, from my = understanding
of the forwarding block proposal as described in yo= ur paper, I wonder if the forward block chain could
be re-pegged = to the main bitcoin chain using the BIP141 extensible commitment structure = (assuming
a future hypothetical soft-fork).

From my understanding, it's like doubly linked-list in C, you just ne= ed a pointer in the BIP141 extensible
commitment structure refere= ncing back the forward chain headers. If one wishes no logically authoritat= ive
cross-chain commitment, one could leverage some dynamic-membe= rship multi-party signature. This
DMMS could even be backup by pr= oof-of-work based schemes.

The forward block cha= in can have higher block-rate frequency and the number of block headers be<= /div>
compressed in a merkle tree committed in the BIP141 extensible co= mmitment structure. Compression
structure can only be defined by = the forward chain consensus algorithm to allow more efficient accumulator
than merkle tree to be used".

The forwa= rd block chain can have elastic block size consensus-bounded by miners fees= on long period
of time. Transaction elements can be just committ= ed in the block headers themselves, so no centralization
pressure= on the main chain. Increased block frequency or block size on the forward = block chain have not
effect on the total issuance (modulo the gam= e-theory limits of the known empirical effects of colored coins
o= n miners incentives).

I think the time-warp issu= es opens the door to economically non-null exploitation under some scenario= s
over some considered time periods. If one can think to other wa= ys to mitigate the issue in minimal and
non-invasive way w.r.t cu= rrent Bitcoin consensus rules and respecting un-upgraded node ressources
consumption, I would say you're free to share them.

I can only share your take on maintaining a standard of intelle= ctual excellence on the mailing list,
and avoid faltering in Redd= it / Twitter-style "madness of the crowd"-like conversations.
Best,
Antoine

Le vendredi 1= 9 avril 2024 =C3=A0 01:19:23 UTC+1, Antoine Poinsot a =C3=A9crit=C2=A0:
You are free to criticize Forward Blocks, bu= t please do so by=20 actually addressing the content of the proposal. Let's please hold a=20 standard of intellectual excellence on this mailing list in which ideas=20 are debated based on content-level arguments rather than repeating=20 inaccurate takes from Reddit/Twitter.

You are t= he one being dishonest here. Look, i understand you came up with a fun hack= exploiting bugs in Bitcoin and you are biased against fixing them. = Yet, the cost of not fixing timewarp objectively far exceeds the cost of ma= king "forward blocks" impossible.

As already addressed in the DelvingBitcoin post:=
  1. The time= warp bug significantly changes the 51% attacker threat model. Without explo= iting it a censoring miner needs to continuously keep more hashrate than th= e rest of the network combined for as long as he wants to prevent some peop= le from using Bitcoin. By exploiting timewarp the attacker can prevent ever= ybody from using Bitcoin within 40 days.
  2. The timewarp bug allows an attacking miner to = force on full nodes more block data than they agreed to. This is actually t= he attack leveraged by your proposal. I believe this variant of the attack = is more likely to happen, simply for the reason that all participants of th= e system have a short term incentive to exploit this (yay lower fees! yay m= ore block subsidy!), at the expense of the long term health of the system. = As the block subsidy exponentially decreases miners are likely to start pla= ying more games and that's a particularly attractive one. Given the lev= el of mining centralization we are witnessing [0] i believe this is particu= larly worrisome.
  3. <= span>I'm very skeptical of arguments about how "we" can stop = an attack which requires "weeks of forewarning". Who's we? Ho= w do we proceed, all Bitcoin users coordinate and arbitrarily decide of the= validity of a block? A few weeks is very little time if this is at all ach= ievable. If you add on top of that the political implications of the previo= us point it gets particularly messy.

I&= #39;ve got better things to do than to play "you are being dishonest! = -no it's you -no you" games. So unless you bring something new to = the table this will be my last reply to your accusations.
Antoine

On Thursday, April 18th, 2024 at 2:46 AM, Mark F <ma...@friedenbach.org> wrote:
On Wednesday, March 27, 2024 at 4:00:34=E2=80=AFAM UTC-7 Antoin= e Poinsot wrote:
The only beneficial= case I can remember about the timewarp issue is "forwarding blocks&qu= ot; by maaku for on-chain scaling:
<= /blockquote>

I would not qualify this hack of "benefici= al". Besides the centralization pressure of an increased block frequen= cy, leveraging the timewarp to achieve it would put the network constantly = on the Brink of being seriously (fatally?) harmed. And this sets pernicious= incentives too. Every individual user has a short-term incentive to get lo= wer fees by the increased block space, at the expense of all users longer t= erm. And every individual miner has an incentive to get more block reward a= t the expense of future miners. (And of course bigger miners benefit from a= n increased block frequency.)
Ever= y single concern mentioned here is addressed prominently in the paper/prese= ntation for Forward Blocks:

* Increased block freq= uency is only on the compatibility chain, where the content of blocks is de= terministic anyway. There is no centralization pressure from the frequency = of blocks on the compatibility chain, as the content of the blocks is not m= iner-editable in economically meaningful ways. Only the block frequency of = the forward block chain matters, and here the block frequency is actually *= reduced*, thereby decreasing centralization pressure.

<= div>* The elastic block size adjustment mechanism proposed in the paper is = purposefully constructed so that users or miners wanting to increase the bl= ock size beyond what is currently provided for will have to pay significant= ly (multiple orders of magnitude) more than they could possibly acquire fro= m larger blocks, and the block size would re-adjust downward shortly after = the cessation of that artificial fee pressure.

* I= ncreased block frequency of compatibility blocks has no effect on the total= issuance, so miners are not rewarded by faster blocks.

You are free to criticize Forward Blocks, but please do so by actuall= y addressing the content of the proposal. Let's please hold a standard = of intellectual excellence on this mailing list in which ideas are debated = based on content-level arguments rather than repeating inaccurate takes fro= m Reddit/Twitter.

To the topic of the thread, disa= bling time-warp will close off an unlikely and difficult to pull off subsid= y draining attack that to activate would necessarily require weeks of forew= arning and could be easily countered in other ways, with the tradeoff of re= moving the only known mechanism for upgrading the bitcoin protocol to large= r effective block sizes while staying 100% compatible with un-upgraded node= s (all nodes see all transactions).

I think we sho= uld keep our options open.

-Mark

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitc= oindev+...@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg= id/bitcoindev/3e93b83e-f0ea-43b9-8f77-f7b044fb3187n%40googlegroups.com.=
------=_Part_48333_907036947.1714025311801-- ------=_Part_48332_80447901.1714025311801--