Delivery-date: Thu, 18 Apr 2024 17:19:30 -0700
Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 185.70.40.27 as permitted sender) client-ip=185.70.40.27;
Date: Thu, 18 Apr 2024 10:04:18 +0000
To: Mark F <mark@friedenbach.org>
From: "'Antoine Poinsot' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: Great Consensus Cleanup Revival
Message-ID: <8fFFuAU-SN2NrQ2SKhS2eOeLkHIdCQtnivE4LzWe32vk5gejNEwNvr9IIa3JJ-sII2UUIpOx8oRMslzmA1ZL6y1kBuQEB1fpTaXku2QGAC0=@protonmail.com>
In-Reply-To: <62640263-077c-4ac7-98a6-d9c17913fca0n@googlegroups.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>
Feedback-ID: 7060259:user:proton
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="b1_xOlv1nSSowLT3Iuos96tFwR4hkEAOCrBc0qt7oJJao"
Reply-To: Antoine Poinsot <darosior@protonmail.com>
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

This is a multi-part message in MIME format.

--b1_xOlv1nSSowLT3Iuos96tFwR4hkEAOCrBc0qt7oJJao
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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

You are the 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 =
making "forward blocks" impossible.

As already addressed in the DelvingBitcoin post:

- The timewarp bug significantly changes the 51% attacker threat model. Wit=
hout exploiting it a censoring miner needs to continuously keep more hashra=
te than the rest of the network combined for as long as he wants to prevent=
 some people from using Bitcoin. By exploiting timewarp the attacker can pr=
event everybody from using Bitcoin within 40 days.
- The timewarp bug allows an attacking miner to force on full nodes more bl=
ock data than they agreed to. This is actually the attack leveraged by your=
 proposal. I believe this variant of the attack is more likely to happen, s=
imply for the reason that all participants of the system have a short term =
incentive to exploit this (yay lower fees! yay more block subsidy!), at the=
 expense of the long term health of the system. As the block subsidy expone=
ntially decreases miners are likely to start playing more games and that's =
a particularly attractive one. Given the level of mining centralization we =
are witnessing [0] i believe this is particularly worrisome.
- I'm very skeptical of arguments about how "we" can stop an attack which r=
equires "weeks of forewarning". Who's we? How do we proceed, all Bitcoin us=
ers coordinate and arbitrarily decide of the validity of a block? A few wee=
ks is very little time if this is at all achievable. If you add on top of t=
hat the political implications of the previous point it gets particularly m=
essy.

I'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 w=
ill 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 <mark@friedenbach.org> wro=
te:

> 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 "fo=
rwarding 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 centralizatio=
n pressure of an increased block frequency, leveraging the timewarp to achi=
eve it would put the network constantly on the Brink of being seriously (fa=
tally?) harmed. And this sets pernicious incentives too. Every individual u=
ser has a short-term incentive to get lower fees by the increased block spa=
ce, at the expense of all users longer term. And every individual miner has=
 an incentive to get more block reward at the expense of future miners. (An=
d of course bigger miners benefit from an increased block frequency.)
>
> Every single concern mentioned here is addressed prominently in the paper=
/presentation for Forward Blocks:
>
> * Increased block frequency is only on the compatibility chain, where the=
 content of blocks is deterministic anyway. There is no centralization pres=
sure from the frequency of blocks on the compatibility chain, as the conten=
t of the blocks is not miner-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 pressur=
e.
>
> * The elastic block size adjustment mechanism proposed in the paper is pu=
rposefully constructed so that users or miners wanting to increase the bloc=
k size beyond what is currently provided for will have to pay significantly=
 (multiple orders of magnitude) more than they could possibly acquire from =
larger blocks, and the block size would re-adjust downward shortly after th=
e cessation of that artificial fee pressure.
>
> * Increased 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 actually ad=
dressing the content of the proposal. Let's please hold a standard of intel=
lectual excellence on this mailing 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 unlikel=
y and difficult to pull off subsidy draining attack that to activate would =
necessarily require weeks of forewarning and could be easily countered in o=
ther ways, with the tradeoff of removing the only known mechanism for upgra=
ding the 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.
>
> -Mark
>
> --
> 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=
 email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgi=
d/bitcoindev/62640263-077c-4ac7-98a6-d9c17913fca0n%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/8fFFuAU-SN2NrQ2SKhS2eOeLkHIdCQtnivE4LzWe32vk5gejNEwNvr9IIa3JJ-sI=
I2UUIpOx8oRMslzmA1ZL6y1kBuQEB1fpTaXku2QGAC0%3D%40protonmail.com.

--b1_xOlv1nSSowLT3Iuos96tFwR4hkEAOCrBc0qt7oJJao
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<blockquote style=3D"border-color: rgb(200, 200, 200); border-left: 3px sol=
id rgb(200, 200, 200); padding-left: 10px; color: rgb(102, 102, 102);"><div=
 style=3D"font-family: Arial, sans-serif; font-size: 14px;"><span>You are f=
ree 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.</span></div></blockquote><div style=
=3D""><br></div><div style=3D""><span><span style=3D"font-family: Arial, sa=
ns-serif; font-size: 14px; font-weight: 400; color: rgb(0, 0, 0); backgroun=
d-color: rgb(255, 255, 255);">You are the 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 making "forward blocks" impossible.</s=
pan></div><div style=3D""><span><br></span></div><div style=3D""><span>As a=
lready addressed in the DelvingBitcoin post:</span></div><div style=3D""><o=
l data-editing-info=3D"{&quot;orderedStyleType&quot;:1,&quot;unorderedStyle=
Type&quot;:1}"><li style=3D"list-style-type: &quot;1. &quot;;"><span>The ti=
mewarp bug significantly changes the 51% attacker threat model. Without exp=
loiting it a censoring miner needs to continuously keep more hashrate than =
the rest of the network combined for as long as he wants to prevent some pe=
ople from using Bitcoin. By exploiting timewarp the attacker can prevent ev=
erybody from using Bitcoin within 40 days.</span></li><li style=3D"list-sty=
le-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 actual=
ly the attack leveraged by your proposal. I believe this variant of the att=
ack is more likely to happen, simply for the reason that all participants o=
f the system have a short term incentive to exploit this (yay lower fees! y=
ay more block subsidy!), at the expense of the long term health of the syst=
em. As the block subsidy exponentially decreases miners are likely to start=
 playing 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.</span></li><li style=3D"list-style-type: &quot;3. &quot;;"=
><span>I'm very skeptical of arguments about how "we" can stop an attack wh=
ich requires "weeks of forewarning". Who's we? How do we proceed, all Bitco=
in users coordinate and arbitrarily decide of the validity of a block? A fe=
w weeks is very little time if this is at all achievable. If you add on top=
 of that the political implications of the previous point it gets particula=
rly messy.</span></li></ol><div><br></div><div>I've got better things to do=
 than to play "you are being dishonest! -no it's you -no you" games. So unl=
ess 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 target=3D"_blank" rel=3D"noreferrer nofollow noopener" href=
=3D"https://x.com/0xB10C/status/1780611768081121700">https://x.com/0xB10C/s=
tatus/1780611768081121700</a></span><br></div></div><div class=3D"protonmai=
l_quote">
        On Thursday, April 18th, 2024 at 2:46 AM, Mark F &lt;mark@friedenba=
ch.org&gt; wrote:<br>
        <blockquote class=3D"protonmail_quote" 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; bo=
rder-left-width: 1px; border-left-style: solid; border-left-color: rgb(204,=
 204, 204); padding-left: 1ex;"><div><blockquote type=3D"cite"><div>The onl=
y beneficial case I can remember about the timewarp issue is "forwarding bl=
ocks" by maaku for on-chain scaling:</div><div><a rel=3D"noreferrer nofollo=
w noopener" target=3D"_blank" href=3D"http://freico.in/forward-blocks-scali=
ngbitcoin-paper.pdf">http://freico.in/forward-blocks-scalingbitcoin-paper.p=
df</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 style=3D"font-family: Arial, sans-serif; font-s=
ize: 14px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">I wo=
uld not qualify this hack of "beneficial". Besides the centralization press=
ure of an increased block frequency, 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 lower fees by the increased block space, at =
the expense of all users longer term. And every individual miner has an inc=
entive to get more block reward at the expense of future miners. (And of co=
urse bigger miners benefit from an increased block frequency.)</div></div><=
/blockquote><div> </div><div>Every single concern mentioned here is address=
ed prominently in the paper/presentation for Forward Blocks:</div><div><br>=
</div><div>* Increased block frequency is only on the compatibility chain, =
where the content of blocks is deterministic anyway. There is no centraliza=
tion pressure from the frequency of blocks on the compatibility chain, as t=
he content of the blocks is not miner-editable in economically meaningful w=
ays. Only the block frequency of the forward block chain matters, and here =
the block frequency is actually *reduced*, thereby decreasing centralizatio=
n pressure.</div><div><br></div><div>* The elastic block size adjustment me=
chanism proposed in the paper is purposefully constructed so that users or =
miners wanting to increase the block size beyond what is currently provided=
 for will have to pay significantly (multiple orders of magnitude) more tha=
n they could possibly acquire from larger blocks, and the block size would =
re-adjust downward shortly after the cessation of that artificial fee press=
ure.</div><div><br></div><div>* Increased block frequency of compatibility =
blocks has no effect on the total issuance, so miners are not rewarded by f=
aster blocks.</div><div><br></div><div>You are free to criticize Forward Bl=
ocks, but please do so by actually addressing the content of the proposal. =
Let's please hold a standard of intellectual excellence on this mailing lis=
t in which ideas are debated based on content-level arguments rather than r=
epeating inaccurate takes from Reddit/Twitter.</div><div><br></div><div>To =
the topic of the thread, disabling time-warp will close off an unlikely and=
 difficult to pull off subsidy draining attack that to activate would neces=
sarily require weeks of forewarning and could be easily countered in other =
ways, with the tradeoff of removing the only known mechanism for upgrading =
the bitcoin protocol to larger effective block sizes while staying 100% com=
patible with un-upgraded nodes (all nodes see all transactions).</div><div>=
<br></div><div>I think we should keep our options open.</div><div><br></div=
><div>-Mark</div></div>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" 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" rel=3D"n=
oreferrer nofollow noopener" target=3D"_blank">bitcoindev+unsubscribe@googl=
egroups.com</a>.<br>
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">https://groups.=
google.com/d/msgid/bitcoindev/62640263-077c-4ac7-98a6-d9c17913fca0n%40googl=
egroups.com</a>.<br>

        </blockquote><br>
    </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/8fFFuAU-SN2NrQ2SKhS2eOeLkHIdCQtnivE4LzWe32vk5gejNEwNv=
r9IIa3JJ-sII2UUIpOx8oRMslzmA1ZL6y1kBuQEB1fpTaXku2QGAC0%3D%40protonmail.com?=
utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/b=
itcoindev/8fFFuAU-SN2NrQ2SKhS2eOeLkHIdCQtnivE4LzWe32vk5gejNEwNvr9IIa3JJ-sII=
2UUIpOx8oRMslzmA1ZL6y1kBuQEB1fpTaXku2QGAC0%3D%40protonmail.com</a>.<br />

--b1_xOlv1nSSowLT3Iuos96tFwR4hkEAOCrBc0qt7oJJao--