Delivery-date: Wed, 17 Apr 2024 17:55:12 -0700
Sender: bitcoindev@googlegroups.com
Date: Wed, 17 Apr 2024 17:46:23 -0700 (PDT)
From: Mark F <mark@friedenbach.org>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <62640263-077c-4ac7-98a6-d9c17913fca0n@googlegroups.com>
In-Reply-To: <1KbVdD952_XRfsKzMKaX-y4lrPOxYiknn8xXOMDQGt2Qz2fHFM-KoSplL-A_GRE1yuUkgNMeoEBHZiEDlMYwiqOiITFQTKEm5u1p1oVlL9I=@protonmail.com>
References: <gnM89sIQ7MhDgI62JciQEGy63DassEv7YZAMhj0IEuIo0EdnafykF6RH4OqjTTHIHsIoZvC2MnTUzJI7EfET4o-UQoD-XAQRDcct994VarE=@protonmail.com>
 <dc2cc46f-e697-4b14-91b3-34cf11de29a3n@googlegroups.com>
 <1KbVdD952_XRfsKzMKaX-y4lrPOxYiknn8xXOMDQGt2Qz2fHFM-KoSplL-A_GRE1yuUkgNMeoEBHZiEDlMYwiqOiITFQTKEm5u1p1oVlL9I=@protonmail.com>
Subject: Re: [bitcoindev] Re: Great Consensus Cleanup Revival
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_54456_163615468.1713401183387"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_Part_54456_163615468.1713401183387
Content-Type: multipart/alternative; 
	boundary="----=_Part_54457_551036384.1713401183387"

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

On Wednesday, March 27, 2024 at 4:00:34=E2=80=AFAM UTC-7 Antoine Poinsot wr=
ote:

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 seriously=
=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.)

=20
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 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 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 unlikely=
=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 "=
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/62640263-077c-4ac7-98a6-d9c17913fca0n%40googlegroups.com.

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

On Wednesday, March 27, 2024 at 4:00:34=E2=80=AFAM UTC-7 Antoine Poinsot wr=
ote:<br /><div><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-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 benefici=
al case I can remember about the timewarp issue is "forwarding blocks" by m=
aaku for on-chain scaling:</div><div><a href=3D"http://freico.in/forward-bl=
ocks-scalingbitcoin-paper.pdf" target=3D"_blank" rel=3D"nofollow">http://fr=
eico.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><di=
v style=3D"font-family: Arial, sans-serif; font-size: 14px; color: rgb(0, 0=
, 0); background-color: rgb(255, 255, 255);">I would not qualify this hack =
of "beneficial". Besides the centralization pressure of an increased block =
frequency, leveraging the timewarp to achieve it would put the network cons=
tantly on the Brink of being seriously (fatally?) harmed. And this sets per=
nicious 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 l=
onger term. And every individual miner has an incentive to get more block r=
eward at the expense of future miners. (And of course bigger miners benefit=
 from an increased block frequency.)</div></div></blockquote><div>=C2=A0</d=
iv><div>Every single concern mentioned here is addressed prominently in the=
 paper/presentation for Forward Blocks:</div><div><br /></div><div>* Increa=
sed block frequency is only on the compatibility chain, where the content o=
f blocks is deterministic anyway. There is no centralization pressure from =
the frequency of blocks on the compatibility chain, as the content of the b=
locks 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 pressure.</div><d=
iv><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 block size beyond what is currently provided for will have to=
 pay significantly (multiple orders of magnitude) more than they could poss=
ibly acquire from larger blocks, and the block size would re-adjust downwar=
d shortly after the cessation of that artificial fee pressure.</div><div><b=
r /></div><div>* Increased block frequency of compatibility blocks has no e=
ffect 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 ple=
ase 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 id=
eas are debated based on content-level arguments rather than repeating inac=
curate takes from Reddit/Twitter.</div><div><br /></div><div>To the topic o=
f the thread, disabling time-warp will close off an unlikely and difficult =
to pull off subsidy draining attack that to activate would necessarily requ=
ire 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% compatible wit=
h 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 &=
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/62640263-077c-4ac7-98a6-d9c17913fca0n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/62640263-077c-4ac7-98a6-d9c17913fca0n%40googlegroups.com</a>.=
<br />

------=_Part_54457_551036384.1713401183387--

------=_Part_54456_163615468.1713401183387--