From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Mon, 06 May 2024 03:57:30 -0700 Received: from mail-yb1-f190.google.com ([209.85.219.190]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1s3w2B-0005AV-N5 for bitcoindev@gnusha.org; Mon, 06 May 2024 03:57:29 -0700 Received: by mail-yb1-f190.google.com with SMTP id 3f1490d57ef6-de60cd96bf3sf4369210276.0 for ; Mon, 06 May 2024 03:57:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1714993041; x=1715597841; 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=WDArlbBRoewV3S0e9BnPsfuN9aL23zN8mqlkS15ouZs=; b=ips1TwfrsvzBa77+Vkjo4D+Z5loITd+iszyExPffnrQ3H3VZb5URG/Tg8v+q4FfXvZ VULmlOu0G8vZlIUWjLCRXp9QGYiGGQfTWNyeagg272/mpPk9yvbeQ17aJxfKn8U4WwP1 I95UWoIP+dSO7cvBVTlt/TBjM7Kv2t6o7i0gUSM6dglhsMwI1KvrZkE0th4g7ib1vSBu D7oEYUdU6t2BvCdOo1QoEqolUYLci61YHuYEgcWGYPDqu1e9mO3sF57uF3a45xRu8hcW Gu8ujT2byOKOundPqnNPkgfq3i8YLZXDF5y9HQnyqsFeN0zbCy8Hhy1CIIMe+XF/2KG/ RHyw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714993041; x=1715597841; 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=WDArlbBRoewV3S0e9BnPsfuN9aL23zN8mqlkS15ouZs=; b=b7qrmJNcia+ixUQlBnDfjsxcJB0PrKLES8EaXq0j1obWvUS8LuoYW7mO41f50yieQm GRNmzGlXf/ulkW8yVbZZC8ntS6sVZP3xlIGeTLqiA1vfC23i7OlOupsytXiLG7WgYxyB hYRDwMwZ3vZxM7V+9oNO8Sf56mKqC9TBk2ABfklJJtwbXeTn/V/x5t7JasmkLocrjvqe lX7l2974tO1krJI1QVKhWoLdiTyp4FVy0cX1Z2mjxxHixQj/Yk/AkMdMOg0uG+1FXkG/ 4MVkdE6ZYdQLlpKtN92VIVjVE87OCuCdmaEz2GaNj3AU9TjYKSBZwk/rVPwDDeFTdp8F pZEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714993041; x=1715597841; 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=WDArlbBRoewV3S0e9BnPsfuN9aL23zN8mqlkS15ouZs=; b=fPeVx75lwJnDlceGkD0hZ9IIVGThed4Ia1aCsLhWSKWT1WnKNP+q0EY3dxRzY3A9eQ WZxiLg8AMIuCiGwABa9t/jwqortAH25DKm20n0ZbwdvbFwzwRsQ9gPZNE4JVUEnwuAHx VtoeIlAU5w7GrDThmOZ/J6vbSqh74pazZWB6Oz0Qyo8d5o0MJ1J2oPEa2zJwiQsbwvpm bwBtt+Q+pSg6ZXhXc03b5YDjKQKUqiMRgtw/KywXSToF6o5K52xwqHeOQSiEauRFgSeD RoiRybP4ZSU1I3HS+ypa6BHjpWvDtnLxW3isWDLebcLFOsM2XeQ4K8uk/TCqIublSWW1 OWCw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCUaMBGqLYntNwJPO38DrV4FyQuKYjHXDmpP/hUb7RpOsZKdeQLJiskxH88P/qWxAFga/yjJRIDFwY37zXg86yr99X+HxTs= X-Gm-Message-State: AOJu0YxLC6Padx3O38MiL8uG8Z3R+zJe6BFQAsVrHFiOa6bCN/L+OmXo MmWl3dHSWJRUDpyTgtan2hLLflW5t9IyKa5S5N1QLuGkC7Jc86ay X-Google-Smtp-Source: AGHT+IHclvgh/Y2boKv4Sp5f6WLlmFZicHlVCqZG8ExYdI5QIEI6ZfVFtlRTMAwR2Kw1vDnStcpAHw== X-Received: by 2002:a25:aacb:0:b0:de8:a500:ffdb with SMTP id t69-20020a25aacb000000b00de8a500ffdbmr7493576ybi.26.1714993041005; Mon, 06 May 2024 03:57:21 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a25:6891:0:b0:de6:10bb:1374 with SMTP id 3f1490d57ef6-de8b54f8c1bls107267276.2.-pod-prod-09-us; Mon, 06 May 2024 03:57:19 -0700 (PDT) X-Received: by 2002:a05:6902:2b0a:b0:de6:166f:3250 with SMTP id fi10-20020a0569022b0a00b00de6166f3250mr3437431ybb.2.1714993039173; Mon, 06 May 2024 03:57:19 -0700 (PDT) Received: by 2002:a05:690c:f88:b0:620:4018:7c57 with SMTP id 00721157ae682-62040188054ms7b3; Sun, 5 May 2024 18:10:13 -0700 (PDT) X-Received: by 2002:a81:8394:0:b0:61a:b2d4:a3fb with SMTP id t142-20020a818394000000b0061ab2d4a3fbmr2056426ywf.8.1714957812240; Sun, 05 May 2024 18:10:12 -0700 (PDT) Date: Sun, 5 May 2024 18:10:11 -0700 (PDT) From: Antoine Riard To: Bitcoin Development Mailing List Message-Id: <5c2b1a47-5a7a-48f3-9904-c17fa5ece5a6n@googlegroups.com> In-Reply-To: <67ec72f6-b89f-4f8d-8629-0ebc8bdb7acfn@googlegroups.com> References: <1KbVdD952_XRfsKzMKaX-y4lrPOxYiknn8xXOMDQGt2Qz2fHFM-KoSplL-A_GRE1yuUkgNMeoEBHZiEDlMYwiqOiITFQTKEm5u1p1oVlL9I=@protonmail.com> <62640263-077c-4ac7-98a6-d9c17913fca0n@googlegroups.com> <8fFFuAU-SN2NrQ2SKhS2eOeLkHIdCQtnivE4LzWe32vk5gejNEwNvr9IIa3JJ-sII2UUIpOx8oRMslzmA1ZL6y1kBuQEB1fpTaXku2QGAC0=@protonmail.com> <3e93b83e-f0ea-43b9-8f77-f7b044fb3187n@googlegroups.com> <67ec72f6-b89f-4f8d-8629-0ebc8bdb7acfn@googlegroups.com> Subject: Re: [bitcoindev] Re: Great Consensus Cleanup Revival MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_336097_75779780.1714957811861" 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_336097_75779780.1714957811861 Content-Type: multipart/alternative; boundary="----=_Part_336098_933014348.1714957811861" ------=_Part_336098_933014348.1714957811861 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Maaku, >From reading back the "forward block" paper, while it effectively=20 guarantees an on-chain settlment throughput increases without the necessity to upgrade old clients, one could argue the proof-of-work change= =20 on the forward chain (unless it's a no-op double-sha256) coupled with the subsidy schedule smoothing, constitutes a substantial=20 change of the already-mined UTXO security model. You can use a lot of hash functions as proof-of-work primitive, though it doesn't= =20 mean they are relying on as strong assumptions or level of cryptanalysis. In fine, you could have poorly picked up hash function for the forward=20 chain resulting in a lowering of everyone coins security (the > 100 TH/s of today is securing years old coins from block mined under= =20 < 1 TH/s). I hold the opinion that fundamental changes affecting the security of everyone coins should be better to be opted-in by= =20 the super-economic majority of nodes, including non-mining nodes. At the contrary, the "forward block" proposal sounds to make the=20 point it's okay to update proof-of-work algorithm by a combined set of mining nodes and upgraded non-mining nodes, which could=20 hypothetically lead to a "security downgrade" due to weaker proof-of-work algorithm used on the forward chain. While your papers introduce formalization of both full-node cost of=20 validation and censorship resistance concepts, one could also add "hardness to change" as a property of the Bitcoin network we all=20 cherishes. If tomorrow, 10% of the hahrate was able to enforce proof-of-work upgrade to the broken SHA-1, I think we would all consider as= =20 a security downgrade. Beyond, this is corect we have a diversity of old nodes used in the=20 ecosystem, probably for block explorer and mempool websites. Yet in practice, they're more certainly vectors of weakness for their=20 end-users, as Bitcoin Core has sadly a limited security fixes backport policy, which doesn't go as far as v0.8 for sure. That we can all= =20 deplore the lack of half-decade old LTS release policy for Bitcoin Core, like done by the Linux kernel is a legitimate conversation to= =20 have (and it would be indeed make it easier with libbitcoinkernel progress). I think we shall rather invite operators of=20 oldest still-running nodes to upgrade to more recent versions, before to ask them to go through the analytical process of=20 weighting all the security / scalability trade-offs of a proposal like "forward block". Finally, on letting options open to bump block inter-val as a soft-fork on= =20 the compatibility chain, I think one could still have a multi-stage "forward block" deployment, where a) a new difficutly=20 adjustment algoritm with parameters is introduced bumping block inter-val for upgraded mining nodes e.g a block every 400 s in average and= =20 the b) re-use this block inter-val capacity increase for the forward chain flexible block size. Now why a miner would opt-in in such= =20 block-interval constraining soft-fork is a good question, in a paradigm where they still get the same block subsidy distribution. This is just a thought experiment aiming to invalidate the "as far as=20 anyone can tell" statement on forclosing forever on-chain settlement throughput increase, if we fix the timewarp bug. Best, Antoine Le mercredi 1 mai 2024 =C3=A0 09:58:48 UTC+1, Mark F a =C3=A9crit : > Hi Antoine, > > That's a reasonable suggestion, and one which has been discussed in the= =20 > past under various names. Concrete ideas for a pegged extension-block sid= e=20 > chain go back to 2014 at the very least. However there is one concrete wa= y=20 > in which these proposals differ from forward blocks: the replay of=20 > transactions to the compatibility block chain. With forward blocks, even= =20 > ancient versions of bitcoind that have been running since 2013 (picked as= a=20 > cutoff because of the probabilistic fork caused by v0.8) will see all=20 > blocks, and have a complete listing of all UTXOs, and the content of=20 > transactions as they appear. > > Does this matter? In principle you can just upgrade all nodes to=20 > understand the extension block, but in practice for a system as diverse a= s=20 > bitcoin support of older node versions is often required in critical=20 > infrastructure. Think of all the block explorer and mempool websites out= =20 > there, for example, and various network monitoring and charting tools. Ma= ny=20 > of which are poorly maintained and probably running on two or three year= =20 > old versions of Bitcoin Core. > > The forward blocks proposal uses the timewarp bug to enable (1) a=20 > proof-of-work change, (2) sharding, (3) subsidy schedule smoothing, and (= 4)=20 > a flexible block size, all without forcing any non-mining nodes to *have*= =20 > to upgrade in order to regain visibility into the network. Yes it's an=20 > everything-and-the-kitchen-sink straw man proposal, but that was on purpo= se=20 > to show that all these so-called =E2=80=9Chard-fork=E2=80=9D changes can = in fact be done as=20 > a soft-fork on vanilla bitcoin, while supporting even the oldest=20 > still-running nodes. > > That changes if we "fix" the timewarp bug though. At the very least, the= =20 > flexible block size and subsidy schedule smoothing can't be accomplished= =20 > without exploiting the timewarp bug, as far as anyone can tell. Therefore= =20 > fixing the timewarp bug will _permanently_ cutoff the bitcoin community= =20 > from ever having the ability to scale on-chain in a backwards-compatible= =20 > way, now or decades or centuries into the future. > > Once thrown, this fuse switch can't be undone. We should be damn sure we= =20 > will never, ever need that capability before giving it up. > > Mark > > On Thursday, April 25, 2024 at 3:46:40=E2=80=AFAM UTC-7 Antoine Riard wro= te: > >> 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= =20 >> the content of blocks is deterministic anyway. There is no centralizatio= n=20 >> pressure from the frequency > of blocks on the compatibility chain, as t= he=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 possib= ly=20 >> acquire from larger blocks, and the block size would re-> adjust downwar= d=20 >> shortly after the cessation of that artificial fee pressure. >> >> > * Increased block frequency of compatibility blocks has no effect on= =20 >> the 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 debate= d=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 activ= ate=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 se= e=20 >> all transactions). >> >> > I think we should keep our options open. >> >> Somehow, I'm sharing your concerns on preserving the long-term=20 >> evolvability w.r.t scalability options >> of bitcoin under the security model as very roughly describer in the=20 >> paper. 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=20 >> number of block headers be >> compressed in a merkle tree committed in the BIP141 extensible commitmen= t=20 >> structure. Compression >> structure can only be defined by the forward chain consensus algorithm t= o=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= =20 >> the 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"-lik= e=20 >> conversations. >> >> Best, >> Antoine >> >> Le vendredi 19 avril 2024 =C3=A0 01:19:23 UTC+1, Antoine Poinsot a =C3= =A9crit : >> >>> 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=20 >>> with a fun hack exploiting bugs in Bitcoin and you are biased against= =20 >>> fixing them. Yet, the cost of not fixing timewarp objectively far=20 >>> exceeds the 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= keep=20 >>> more hashrate than the rest of the network combined for as long as h= e wants=20 >>> to prevent some people from using Bitcoin. By exploiting timewarp th= e=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 lev= eraged=20 >>> by your proposal. I believe this variant of the attack is more likel= y to=20 >>> happen, simply for the reason that all participants of the system ha= ve 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 = the=20 >>> block subsidy exponentially decreases miners are likely to start pla= ying=20 >>> more games and that's a particularly attractive one. Given the level= of=20 >>> mining centralization we are witnessing [0] i believe this is partic= ularly=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, = all=20 >>> Bitcoin users coordinate and arbitrarily decide of the validity of a= block?=20 >>> A few weeks is very little time if this is at all achievable. If you= add 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 Poinso= t 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=20 >>> centralization pressure of an increased block frequency, leveraging the= =20 >>> timewarp to achieve it would put the network constantly on the Brink of= =20 >>> being seriously (fatally?) harmed. And this sets pernicious incentives = too.=20 >>> Every individual user has a short-term incentive to get lower fees by t= he=20 >>> increased block space, at the expense of all users longer term. And eve= ry=20 >>> individual miner has an incentive to get more block reward at the expen= se=20 >>> of future miners. (And of course bigger miners benefit from an increase= d=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= =20 >>> the content of blocks is deterministic anyway. There is no centralizati= on=20 >>> pressure from the frequency of blocks on the compatibility chain, as th= e=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 = here=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 th= e=20 >>> block size beyond what is currently provided for will have to pay=20 >>> significantly (multiple orders of magnitude) more than they could possi= bly=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 th= e=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 acti= vate=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 s= ee=20 >>> all transactions). >>> >>> I think we should keep our options open. >>> >>> -Mark >>> >>> --=20 >>> >>> You received this message because you are subscribed to the Google=20 >>> Groups "Bitcoin Development Mailing List" group. >>> To unsubscribe from this group and stop receiving emails from it, send= =20 >>> an 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-d9= c17913fca0n%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/5c2b1a47-5a7a-48f3-9904-c17fa5ece5a6n%40googlegroups.com. ------=_Part_336098_933014348.1714957811861 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Maaku,

From reading back the "forward block" paper, while it = effectively guarantees an on-chain settlment throughput increases without t= he
necessity to upgrade old clients, one could argue the proof-of-work= change on the forward chain (unless it's a no-op double-sha256)
coupl= ed with the subsidy schedule smoothing, constitutes a substantial change of= the already-mined UTXO security model. You can
use a lot of hash func= tions as proof-of-work primitive, though it doesn't mean they are relying o= n as strong assumptions or level
of cryptanalysis.

In fine,= you could have poorly picked up hash function for the forward chain result= ing in a lowering of everyone coins security
(the > 100 TH/s of tod= ay is securing years old coins from block mined under < 1 TH/s). I hold = the opinion that fundamental changes
affecting the security of everyon= e coins should be better to be opted-in by the super-economic majority of n= odes, including non-mining
nodes. At the contrary, the "forward block"= proposal sounds to make the point it's okay to update proof-of-work algori= thm by a
combined set of mining nodes and upgraded non-mining nodes, w= hich could hypothetically lead to a "security downgrade" due to weaker
proof-of-work algorithm used on the forward chain.

While your p= apers introduce formalization of both full-node cost of validation and cens= orship resistance concepts, one could also
add "hardness to change" as= a property of the Bitcoin network we all cherishes. If tomorrow, 10% of th= e hahrate was able to enforce
proof-of-work upgrade to the broken SHA-= 1, I think we would all consider as a security downgrade.

Beyond= , this is corect we have a diversity of old nodes used in the ecosystem, pr= obably for block explorer and mempool websites.
Yet in practice, they'= re more certainly vectors of weakness for their end-users, as Bitcoin Core = has sadly a limited security fixes
backport policy, which doesn't go a= s far as v0.8 for sure. That we can all deplore the lack of half-decade old= LTS release policy for
Bitcoin Core, like done by the Linux kernel is= a legitimate conversation to have (and it would be indeed make it easier w= ith
libbitcoinkernel progress). I think we shall rather invite operato= rs of oldest still-running nodes to upgrade to more recent
versions, b= efore to ask them to go through the analytical process of weighting all the= security / scalability trade-offs of a
proposal like "forward block".=

Finally, on letting options open to bump block inter-val as a s= oft-fork on the compatibility chain, I think one could still have
a mu= lti-stage "forward block" deployment, where a) a new difficutly adjustment = algoritm with parameters is introduced bumping block
inter-val for upg= raded mining nodes e.g a block every 400 s in average and the b) re-use thi= s block inter-val capacity increase for
the forward chain flexible blo= ck size. Now why a miner would opt-in in such block-interval constraining s= oft-fork is a good question,
in a paradigm where they still get the sa= me block subsidy distribution.

This is just a thought experiment= aiming to invalidate the "as far as anyone can tell" statement on forclosi= ng forever on-chain
settlement throughput increase, if we fix the time= warp bug.

Best,
Antoine
Le mercredi 1 mai 2024 =C3=A0 09:58:48 = UTC+1, Mark F a =C3=A9crit=C2=A0:
Hi Antoine,

That's a reasonable suggestion,= and one which has been discussed in the past under various names. Concrete= ideas for a pegged extension-block side chain go back to 2014 at the very = least. However there is one concrete way in which these proposals differ fr= om forward blocks: the replay of transactions to the compatibility block ch= ain. With forward blocks, even ancient versions of bitcoind that have been = running since 2013 (picked as a cutoff because of the probabilistic fork ca= used by v0.8) will see all blocks, and have a complete listing of all UTXOs= , and the content of transactions as they appear.

Does this matter? = In principle you can just upgrade all nodes to understand the extension blo= ck, but in practice for a system as diverse as bitcoin support of older nod= e versions is often required in critical infrastructure. Think of all the b= lock explorer and mempool websites out there, for example, and various netw= ork monitoring and charting tools. Many of which are poorly maintained and = probably running on two or three year old versions of Bitcoin Core.

= The forward blocks proposal uses the timewarp bug to enable (1) a proof-of-= work change, (2) sharding, (3) subsidy schedule smoothing, and (4) a flexib= le block size, all without forcing any non-mining nodes to *have* to upgrad= e in order to regain visibility into the network. Yes it's an everythin= g-and-the-kitchen-sink straw man proposal, but that was on purpose to show = that all these so-called =E2=80=9Chard-fork=E2=80=9D changes can in fact be= done as a soft-fork on vanilla bitcoin, while supporting even the oldest s= till-running nodes.

That changes if we "fix" the timewarp = bug though. At the very least, the flexible block size and subsidy schedule= smoothing can't be accomplished without exploiting the timewarp bug, a= s far as anyone can tell. Therefore fixing the timewarp bug will _permanent= ly_ cutoff the bitcoin community from ever having the ability to scale on-c= hain in a backwards-compatible way, now or decades or centuries into the fu= ture.

Once thrown, this fuse switch can't be undone. We should b= e damn sure we will never, ever need that capability before giving it up.
Mark

On Thursday, April 25, 2024 at 3:46:40=E2=80=AFAM UTC-7 Antoine Ri= ard wrote:
Hi Maaku,
> Every single concern mentioned here = is addressed prominently in the paper/presentation for Forward Blocks:
>
> * Increased block frequency is only on the compat= ibility chain, where the content of blocks is deterministic anyway. There i= s no centralization pressure from the frequency > of blocks on the compa= tibility chain, as the content of the blocks is not miner-editable in econo= mically meaningful ways. Only the block frequency of the forward block >= chain matters, and here the block frequency is actually *reduced*, thereby= decreasing centralization pressure.
>
&g= t; * The elastic block size adjustment mechanism proposed in the paper is p= urposefully constructed so that users or miners wanting to increase the blo= ck size beyond what > is currently provided for will have to pay signifi= cantly (multiple orders of magnitude) more than they could possibly acquire= from larger blocks, and the block size would re-> adjust downward short= ly after the cessation of that artificial fee pressure.

> * Increased block frequency of compatibility blocks h= as no effect on the total issuance, so miners are not rewarded by faster bl= ocks.

> You are free to criticize Forward Block= s, but please do so by actually addressing the content of the proposal. Let= 's please hold a standard of intellectual excellence on this > maili= ng list in which ideas are debated based on content-level arguments rather = than repeating inaccurate takes from Reddit/Twitter.

> To the topic of the thread, disabling time-warp will close off an u= nlikely and difficult to pull off subsidy draining attack that to activate = would necessarily require weeks of > forewarning and could be easily cou= ntered in other ways, with the tradeoff of removing the only known mechanis= m for upgrading the bitcoin protocol to larger effective > block sizes w= hile staying 100% compatible with un-upgraded nodes (all nodes see all tran= sactions).

> I think we should keep our options= open.

Somehow, I'm sharing y= our concerns on preserving the long-term evolvability w.r.t scalability opt= ions
of bitcoin under the security model as very roughly describe= r in the paper. Yet, from my understanding
of the forwarding bloc= k proposal as described in your paper, I wonder if the forward block chain = could
be re-pegged to the main bitcoin chain using the BIP141 ext= ensible commitment structure (assuming
a future hypothetical soft= -fork).

From my understanding, it's like doubl= y linked-list in C, you just need a pointer in the BIP141 extensible
<= div>commitment structure referencing back the forward chain headers. If one= wishes no logically authoritative
cross-chain commitment, one co= uld leverage some dynamic-membership 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 th= e number of block headers be
compressed in a merkle tree committe= d in the BIP141 extensible commitment structure. Compression
stru= cture can only be defined by the forward chain consensus algorithm to allow= more efficient accumulator
than merkle tree to be used".

The forward block chain can have elastic block size = consensus-bounded by miners fees on long period
of time. Transact= ion elements can be just committed in the block headers themselves, so no c= entralization
pressure on the main chain. Increased block frequen= cy or block size on the forward block chain have not
effect on th= e total issuance (modulo the game-theory limits of the known empirical effe= cts of colored coins
on miners incentives).

<= div>I think the time-warp issues opens the door to economically non-null ex= ploitation under some scenarios
over some considered time periods= . If one can think to other ways to mitigate the issue in minimal and
=
non-invasive way w.r.t current Bitcoin consensus rules and respecting = un-upgraded node ressources
consumption, I would say you're f= ree to share them.

I can only share your take on m= aintaining a standard of intellectual excellence on the mailing list,
=
and avoid faltering in Reddit / Twitter-style "madness of the cro= wd"-like conversations.

Best,
Antoi= ne

Le vendredi 19 avril 2024 =C3=A0 01:19:23 UTC+1, A= ntoine Poinsot a =C3=A9crit=C2=A0:
You are free to= criticize Forward Blocks, but 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 bitcoindev+...@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/5c2b1a47-5a7a-48f3-9904-c17fa5ece5a6n%40googlegroups.com.=
------=_Part_336098_933014348.1714957811861-- ------=_Part_336097_75779780.1714957811861--