Delivery-date: Wed, 01 May 2024 01:58:56 -0700
Sender: bitcoindev@googlegroups.com
Date: Tue, 30 Apr 2024 15:20:16 -0700 (PDT)
From: Mark F <mark@friedenbach.org>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <67ec72f6-b89f-4f8d-8629-0ebc8bdb7acfn@googlegroups.com>
In-Reply-To: <3e93b83e-f0ea-43b9-8f77-f7b044fb3187n@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>
 <8fFFuAU-SN2NrQ2SKhS2eOeLkHIdCQtnivE4LzWe32vk5gejNEwNvr9IIa3JJ-sII2UUIpOx8oRMslzmA1ZL6y1kBuQEB1fpTaXku2QGAC0=@protonmail.com>
 <3e93b83e-f0ea-43b9-8f77-f7b044fb3187n@googlegroups.com>
Subject: Re: [bitcoindev] Re: Great Consensus Cleanup Revival
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_13658_363086555.1714515616900"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_Part_13658_363086555.1714515616900
Content-Type: multipart/alternative; 
	boundary="----=_Part_13659_1295575210.1714515616900"

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

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 side=
=20
chain go back to 2014 at the very least. However there is one concrete way=
=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 understand=
=20
the extension block, but in practice for a system as diverse as bitcoin=20
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. Many=
=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 purpose=
=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 wrote=
:

> 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 centralization=
=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=
=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 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 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 activa=
te=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=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 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 th=
e=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=A9=
crit :
>
>> 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 wit=
h=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 =
keep=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 leve=
raged=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 hav=
e 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 t=
he=20
>>    block subsidy exponentially decreases miners are likely to start play=
ing=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 particu=
larly=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, a=
ll=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 <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 centralizatio=
n=20
>> pressure of an increased block frequency, leveraging the timewarp to=20
>> achieve it would put the network constantly on the Brink of being seriou=
sly=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 ever=
y=20
>> individual miner has an incentive to get more block reward at the expens=
e=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 th=
e=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 h=
ere=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 possib=
ly=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 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.
>>
>> -Mark
>>
>> --=20
>>
>> You received this message because you are subscribed to the Google Group=
s=20
>> "Bitcoin Development Mailing List" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n=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-d9c=
17913fca0n%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/67ec72f6-b89f-4f8d-8629-0ebc8bdb7acfn%40googlegroups.com.

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

Hi Antoine,<br /><br />That's a reasonable suggestion, and one which has be=
en discussed in the past under various names. Concrete ideas for a pegged e=
xtension-block side chain go back to 2014 at the very least. However there =
is one concrete way in which these proposals differ from forward blocks: th=
e replay of transactions to the compatibility block chain. With forward blo=
cks, even ancient versions of bitcoind that have been running since 2013 (p=
icked as a cutoff because of the probabilistic fork caused by v0.8) will se=
e all blocks, and have a complete listing of all UTXOs, and the content of =
transactions as they appear.<br /><br />Does this matter? In principle you =
can just upgrade all nodes to understand the extension block, but in practi=
ce for a system as diverse as bitcoin support of older node versions is oft=
en required in critical infrastructure. Think of all the block explorer and=
 mempool websites out there, for example, and various network monitoring an=
d charting tools. Many of which are poorly maintained and probably running =
on two or three year old versions of Bitcoin Core.<br /><br />The forward b=
locks proposal uses the timewarp bug to enable (1) a proof-of-work change, =
(2) sharding, (3) subsidy schedule smoothing, and (4) a flexible block size=
, all without forcing any non-mining nodes to *have* to upgrade in order to=
 regain visibility into the network. Yes it's an everything-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-f=
ork on vanilla bitcoin, while supporting even the oldest still-running node=
s.<br /><br />That changes if we "fix" the timewarp bug though. At the very=
 least, the flexible block size and subsidy schedule smoothing can't be acc=
omplished without exploiting the timewarp bug, as far as anyone can tell. T=
herefore fixing the timewarp bug will _permanently_ cutoff the bitcoin comm=
unity from ever having the ability to scale on-chain in a backwards-compati=
ble way, now or decades or centuries into the future.<br /><br />Once throw=
n, this fuse switch can't be undone. We should be damn sure we will never, =
ever need that capability before giving it up.<br /><br />Mark<br /><br /><=
div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">On Thursda=
y, April 25, 2024 at 3:46:40=E2=80=AFAM UTC-7 Antoine Riard wrote:<br/></di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; border-le=
ft: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Hi Maaku,<div><br></d=
iv><div></div><div><div>&gt; Every single concern mentioned here is address=
ed prominently in the paper/presentation for Forward Blocks:</div><div>&gt;=
</div><div>&gt; * Increased block frequency is only on the compatibility ch=
ain, where the content of blocks is deterministic anyway. There is no centr=
alization pressure from the frequency &gt; of blocks on the compatibility c=
hain, as the content of the blocks is not miner-editable in economically me=
aningful ways. Only the block frequency of the forward block &gt; chain mat=
ters, and here the block frequency is actually *reduced*, thereby decreasin=
g centralization pressure.</div><div>&gt;</div></div><div><div>&gt; * The e=
lastic block size adjustment mechanism proposed in the paper is purposefull=
y constructed so that users or miners wanting to increase the block size be=
yond what &gt; is currently provided for will have to pay significantly (mu=
ltiple orders of magnitude) more than they could possibly acquire from larg=
er blocks, and the block size would re-&gt; adjust downward shortly after t=
he cessation of that artificial fee pressure.</div></div><div><div><br></di=
v><div>&gt; * Increased block frequency of compatibility blocks has no effe=
ct on the total issuance, so miners are not rewarded by faster blocks.</div=
><div><br></div><div>&gt; You are free to criticize Forward Blocks, but ple=
ase do so by actually addressing the content of the proposal. Let&#39;s ple=
ase hold a standard of intellectual excellence on this &gt; mailing list in=
 which ideas are debated based on content-level arguments rather than repea=
ting inaccurate takes from Reddit/Twitter.</div><div><br></div><div>&gt; To=
 the topic of the thread, disabling time-warp will close off an unlikely an=
d difficult to pull off subsidy draining attack that to activate would nece=
ssarily require weeks of &gt; forewarning and could be easily countered in =
other ways, with the tradeoff of removing the only known mechanism for upgr=
ading the bitcoin protocol to larger effective &gt; block sizes while stayi=
ng 100% compatible with un-upgraded nodes (all nodes see all transactions).=
</div><div><br></div><div>&gt; I think we should keep our options open.</di=
v></div><div></div><div><br></div><div>Somehow, I&#39;m sharing your concer=
ns on preserving the long-term evolvability w.r.t scalability options</div>=
<div>of bitcoin under the security model as very roughly describer in the p=
aper. Yet, from my understanding</div><div>of the forwarding block proposal=
 as described in your paper, I wonder if the forward block chain could</div=
><div>be re-pegged to the main bitcoin chain using the BIP141 extensible co=
mmitment structure (assuming</div><div>a future hypothetical soft-fork).</d=
iv><div><br></div><div>From my understanding, it&#39;s like doubly linked-l=
ist in C, you just need a pointer in the BIP141 extensible</div><div>commit=
ment structure referencing back the forward chain headers. If one wishes no=
 logically authoritative</div><div>cross-chain commitment, one could levera=
ge some dynamic-membership multi-party signature. This</div><div>DMMS could=
 even be backup by proof-of-work based schemes.</div><div><br></div><div>Th=
e forward block chain can have higher block-rate frequency and the number o=
f block headers be</div><div>compressed in a merkle tree committed in the B=
IP141 extensible commitment structure. Compression</div><div>structure can =
only be defined by the forward chain consensus algorithm to allow more effi=
cient accumulator</div><div>than merkle tree to be used&quot;.</div><div><b=
r></div><div>The forward block chain can have elastic block size consensus-=
bounded by miners fees on long period</div><div>of time. Transaction elemen=
ts can be just committed in the block headers themselves, so no centralizat=
ion</div><div>pressure on the main chain. Increased block frequency or bloc=
k size on the forward block chain have not</div><div>effect on the total is=
suance (modulo the game-theory limits of the known empirical effects of col=
ored coins</div><div>on miners incentives).</div><div><br></div><div>I thin=
k the time-warp issues opens the door to economically non-null exploitation=
 under some scenarios</div><div>over some considered time periods. If one c=
an think to other ways to mitigate the issue in minimal and</div><div>non-i=
nvasive way w.r.t current Bitcoin consensus rules and respecting un-upgrade=
d node ressources</div><div>consumption, I would say you&#39;re free to sha=
re them.</div><div><br></div><div>I can only share your take on maintaining=
 a standard of intellectual excellence on the mailing list,</div><div>and a=
void faltering in Reddit / Twitter-style &quot;madness of the crowd&quot;-l=
ike conversations.</div><div><br></div><div>Best,</div><div>Antoine</div><d=
iv><div><br></div></div><div class=3D"gmail_quote"><div dir=3D"auto" class=
=3D"gmail_attr">Le vendredi 19 avril 2024 =C3=A0 01:19:23 UTC+1, Antoine Po=
insot a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex"><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 free to critici=
ze Forward Blocks, but 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=
=3Den&amp;q=3Dhttps://x.com/0xB10C/status/1780611768081121700&amp;source=3D=
gmail&amp;ust=3D1714601908606000&amp;usg=3DAOvVaw0YjcziU6KSDRw0Zp8jVVjR">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 rel=3D"nofo=
llow">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=
en&amp;q=3Dhttp://freico.in/forward-blocks-scalingbitcoin-paper.pdf&amp;sou=
rce=3Dgmail&amp;ust=3D1714601908606000&amp;usg=3DAOvVaw0kB6FYABuW0FBXZja9Ef=
8i">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 rel=3D"noreferrer nofollow noopener">bitcoindev+...@googlegroups=
.com</a>.<br></blockquote></div><div><blockquote type=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=3Den&amp;q=3Dhttps://groups.google.c=
om/d/msgid/bitcoindev/62640263-077c-4ac7-98a6-d9c17913fca0n%2540googlegroup=
s.com&amp;source=3Dgmail&amp;ust=3D1714601908606000&amp;usg=3DAOvVaw1jgs17I=
d-bCVHQiC4ykkeM">https://groups.google.com/d/msgid/bitcoindev/62640263-077c=
-4ac7-98a6-d9c17913fca0n%40googlegroups.com</a>.<br>

        </blockquote><br>
    </div></blockquote></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/67ec72f6-b89f-4f8d-8629-0ebc8bdb7acfn%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/67ec72f6-b89f-4f8d-8629-0ebc8bdb7acfn%40googlegroups.com</a>.=
<br />

------=_Part_13659_1295575210.1714515616900--

------=_Part_13658_363086555.1714515616900--