path: root/f2/f7c24c6a8f15fbcca35c0f5ccf97824b8799f5

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 <bitcoindev+bncBC3PT7FYWAMRBDXJVCYQMGQE4EXMWGQ@googlegroups.com>)
	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 <bitcoindev@gnusha.org>; 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 <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <3e93b83e-f0ea-43b9-8f77-f7b044fb3187n@googlegroups.com>
In-Reply-To: <8fFFuAU-SN2NrQ2SKhS2eOeLkHIdCQtnivE4LzWe32vk5gejNEwNvr9IIa3JJ-sII2UUIpOx8oRMslzmA1ZL6y1kBuQEB1fpTaXku2QGAC0=@protonmail.com>
References: <gnM89sIQ7MhDgI62JciQEGy63DassEv7YZAMhj0IEuIo0EdnafykF6RH4OqjTTHIHsIoZvC2MnTUzJI7EfET4o-UQoD-XAQRDcct994VarE=@protonmail.com>
 <dc2cc46f-e697-4b14-91b3-34cf11de29a3n@googlegroups.com>
 <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: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
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 <ma...@friedenbach.org>=
=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,<div><br /></div><div><div>&gt; Every single concern mentioned her=
e is addressed prominently in the paper/presentation for Forward Blocks:</d=
iv><div>&gt;</div><div>&gt; * 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 &gt; 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.</div><div>&gt;</div><div>&gt; * 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 &gt; 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-&gt; adjust downward shortly after =
the cessation of that artificial fee pressure.</div><div><br /></div><div>&=
gt; * Increased block frequency of compatibility blocks has no effect on th=
e total issuance, so miners are not rewarded by faster blocks.</div><div><b=
r /></div><div>&gt; 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 &gt; mailing list in which ide=
as are debated based on content-level arguments rather than repeating inacc=
urate takes from Reddit/Twitter.</div><div><br /></div><div>&gt; 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 &gt; 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 &gt; block sizes while staying 100% =
compatible with un-upgraded nodes (all nodes see all transactions).</div><d=
iv><br /></div><div>&gt; I think we should keep our options open.</div></di=
v><div><br /></div><div>Somehow, I'm sharing your concerns on preserving th=
e long-term evolvability w.r.t scalability options</div><div>of bitcoin und=
er the security model as very roughly describer in the paper. Yet, from my =
understanding</div><div>of the forwarding block proposal as described in yo=
ur paper, I wonder if the forward block chain could</div><div>be re-pegged =
to the main bitcoin chain using the BIP141 extensible commitment structure =
(assuming</div><div>a future hypothetical soft-fork).</div><div><br /></div=
><div>From my understanding, it's like doubly linked-list in C, you just ne=
ed a pointer in the BIP141 extensible</div><div>commitment structure refere=
ncing back the forward chain headers. If one wishes no logically authoritat=
ive</div><div>cross-chain commitment, one could leverage some dynamic-membe=
rship multi-party signature. This</div><div>DMMS could even be backup by pr=
oof-of-work based schemes.</div><div><br /></div><div>The forward block cha=
in can have higher block-rate frequency and the number of block headers be<=
/div><div>compressed in a merkle tree committed in the BIP141 extensible co=
mmitment structure. Compression</div><div>structure can only be defined by =
the forward chain consensus algorithm to allow more efficient accumulator</=
div><div>than merkle tree to be used".</div><div><br /></div><div>The forwa=
rd block chain can have elastic block size consensus-bounded by miners fees=
 on long period</div><div>of time. Transaction elements can be just committ=
ed in the block headers themselves, so no centralization</div><div>pressure=
 on the main chain. Increased block frequency or block size on the forward =
block chain have not</div><div>effect on the total issuance (modulo the gam=
e-theory limits of the known empirical effects of colored coins</div><div>o=
n miners incentives).</div><div><br /></div><div>I think the time-warp issu=
es opens the door to economically non-null exploitation under some scenario=
s</div><div>over some considered time periods. If one can think to other wa=
ys to mitigate the issue in minimal and</div><div>non-invasive way w.r.t cu=
rrent Bitcoin consensus rules and respecting un-upgraded node ressources</d=
iv><div>consumption, I would say you're free to share them.</div><div><br /=
></div><div>I can only share your take on maintaining a standard of intelle=
ctual excellence on the mailing list,</div><div>and avoid faltering in Redd=
it / Twitter-style "madness of the crowd"-like conversations.</div><div><br=
 /></div><div>Best,</div><div>Antoine</div><div><div><br /></div></div><div=
 class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">Le vendredi 1=
9 avril 2024 =C3=A0 01:19:23 UTC+1, Antoine Poinsot a =C3=A9crit=C2=A0:<br/=
></div><blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; bord=
er-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote styl=
e=3D"border-color:rgb(200,200,200);border-left:3px solid rgb(200,200,200);p=
adding-left:10px;color:rgb(102,102,102)"><div style=3D"font-family:Arial,sa=
ns-serif;font-size:14px"><span>You are free to criticize Forward Blocks, bu=
t please do so by=20
actually addressing the content of the proposal. Let&#39;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.</span></div></blockquote><div><br></d=
iv><div><span><span style=3D"font-family:Arial,sans-serif;font-size:14px;fo=
nt-weight:400;color:rgb(0,0,0);background-color:rgb(255,255,255)">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.</span> =
Yet, the cost of not fixing timewarp objectively far exceeds the cost of ma=
king &quot;forward blocks&quot; impossible.</span></div><div><span><br></sp=
an></div><div><span>As already addressed in the DelvingBitcoin post:</span>=
</div><div><ol><li style=3D"list-style-type:&quot;1. &quot;"><span>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.</span></li><li style=3D"list-style=
-type:&quot;2. &quot;"><span>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&#39;s a particularly attractive one. Given the lev=
el of mining centralization we are witnessing [0] i believe this is particu=
larly worrisome.</span></li><li style=3D"list-style-type:&quot;3. &quot;"><=
span>I&#39;m very skeptical of arguments about how &quot;we&quot; can stop =
an attack which requires &quot;weeks of forewarning&quot;. Who&#39;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.</span></li></ol><div><br></div><div>I&=
#39;ve got better things to do than to play &quot;you are being dishonest! =
-no it&#39;s you -no you&quot; games. So unless you bring something new to =
the table this will be my last reply to your accusations.<br></div><div><br=
></div><div>Antoine</div><div><br></div><div>[0] <span><a rel=3D"noreferrer=
 nofollow noopener" href=3D"https://x.com/0xB10C/status/1780611768081121700=
" target=3D"_blank" data-saferedirecturl=3D"https://www.google.com/url?hl=
=3Dfr&amp;q=3Dhttps://x.com/0xB10C/status/1780611768081121700&amp;source=3D=
gmail&amp;ust=3D1714110945579000&amp;usg=3DAOvVaw1MsW6kBs4DxDL0b5Oj5xnE">ht=
tps://x.com/0xB10C/status/1780611768081121700</a></span><br></div></div><di=
v></div><div>
        On Thursday, April 18th, 2024 at 2:46 AM, Mark F &lt;<a href data-e=
mail-masked rel=3D"nofollow">ma...@friedenbach.org</a>&gt; wrote:<br>
        </div><div><blockquote type=3D"cite">
            On Wednesday, March 27, 2024 at 4:00:34=E2=80=AFAM UTC-7 Antoin=
e Poinsot wrote:<br><div><blockquote style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204=
);padding-left:1ex"><div><blockquote type=3D"cite"><div>The only beneficial=
 case I can remember about the timewarp issue is &quot;forwarding blocks&qu=
ot; by maaku for on-chain scaling:</div><div><a rel=3D"noreferrer nofollow =
noopener" href=3D"http://freico.in/forward-blocks-scalingbitcoin-paper.pdf"=
 target=3D"_blank" data-saferedirecturl=3D"https://www.google.com/url?hl=3D=
fr&amp;q=3Dhttp://freico.in/forward-blocks-scalingbitcoin-paper.pdf&amp;sou=
rce=3Dgmail&amp;ust=3D1714110945579000&amp;usg=3DAOvVaw1eQRUs0VtEc1eHOecFxQ=
bS">http://freico.in/forward-blocks-scalingbitcoin-paper.pdf</a><br></div><=
/blockquote><div style=3D"font-family:Arial,sans-serif;font-size:14px;color=
:rgb(0,0,0);background-color:rgb(255,255,255)"><br></div></div><div><div st=
yle=3D"font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);backgro=
und-color:rgb(255,255,255)">I would not qualify this hack of &quot;benefici=
al&quot;. 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.)</div></div></blockquote><div> </div><div>Ever=
y single concern mentioned here is addressed prominently in the paper/prese=
ntation for Forward Blocks:</div><div><br></div><div>* 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><div><br></div><=
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.</div><div><br></div><div>* I=
ncreased block frequency of compatibility blocks has no effect on the total=
 issuance, so miners are not rewarded by faster blocks.</div><div><br></div=
><div>You are free to criticize Forward Blocks, but please do so by actuall=
y addressing the content of the proposal. Let&#39;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.</div><div><br></div><div>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).</div><div><br></div><div>I think we sho=
uld keep our options open.</div><div><br></div><div>-Mark</div></div>

<p></p></blockquote></div><div><blockquote type=3D"cite">

-- <br></blockquote></div><div><blockquote type=3D"cite">
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href rel=3D"noreferrer nofollow noopener" data-email-masked>bitc=
oindev+...@googlegroups.com</a>.<br></blockquote></div><div><blockquote typ=
e=3D"cite">
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/62640263-077c-4ac7-98a6-d9c17913fca0n%40googlegroups.=
com" rel=3D"noreferrer nofollow noopener" target=3D"_blank" data-saferedire=
cturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://groups.google.c=
om/d/msgid/bitcoindev/62640263-077c-4ac7-98a6-d9c17913fca0n%2540googlegroup=
s.com&amp;source=3Dgmail&amp;ust=3D1714110945579000&amp;usg=3DAOvVaw1sv8vQ4=
At8VM1yzKcjcWTw">https://groups.google.com/d/msgid/bitcoindev/62640263-077c=
-4ac7-98a6-d9c17913fca0n%40googlegroups.com</a>.<br>

        </blockquote><br>
    </div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/3e93b83e-f0ea-43b9-8f77-f7b044fb3187n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/3e93b83e-f0ea-43b9-8f77-f7b044fb3187n%40googlegroups.com</a>.=
<br />

------=_Part_48333_907036947.1714025311801--

------=_Part_48332_80447901.1714025311801--