Delivery-date: Mon, 06 May 2024 03:57:30 -0700
Sender: bitcoindev@googlegroups.com
Date: Sun, 5 May 2024 18:10:11 -0700 (PDT)
From: Antoine Riard <antoine.riard@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <5c2b1a47-5a7a-48f3-9904-c17fa5ece5a6n@googlegroups.com>
In-Reply-To: <67ec72f6-b89f-4f8d-8629-0ebc8bdb7acfn@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>
 <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"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_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 <ma...@friedenbach.org=
>=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,<br /><br />From reading back the "forward block" paper, while it =
effectively guarantees an on-chain settlment throughput increases without t=
he<br />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)<br />coupl=
ed with the subsidy schedule smoothing, constitutes a substantial change of=
 the already-mined UTXO security model. You can<br />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<br />of cryptanalysis.<br /><br />In fine,=
 you could have poorly picked up hash function for the forward chain result=
ing in a lowering of everyone coins security<br />(the &gt; 100 TH/s of tod=
ay is securing years old coins from block mined under &lt; 1 TH/s). I hold =
the opinion that fundamental changes<br />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<br />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<br />combined set of mining nodes and upgraded non-mining nodes, w=
hich could hypothetically lead to a "security downgrade" due to weaker<br /=
>proof-of-work algorithm used on the forward chain.<br /><br />While your p=
apers introduce formalization of both full-node cost of validation and cens=
orship resistance concepts, one could also<br />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<br />proof-of-work upgrade to the broken SHA-=
1, I think we would all consider as a security downgrade.<br /><br />Beyond=
, this is corect we have a diversity of old nodes used in the ecosystem, pr=
obably for block explorer and mempool websites.<br />Yet in practice, they'=
re more certainly vectors of weakness for their end-users, as Bitcoin Core =
has sadly a limited security fixes<br />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<br />Bitcoin Core, like done by the Linux kernel is=
 a legitimate conversation to have (and it would be indeed make it easier w=
ith<br />libbitcoinkernel progress). I think we shall rather invite operato=
rs of oldest still-running nodes to upgrade to more recent<br />versions, b=
efore to ask them to go through the analytical process of weighting all the=
 security / scalability trade-offs of a<br />proposal like "forward block".=
<br /><br />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<br />a mu=
lti-stage "forward block" deployment, where a) a new difficutly adjustment =
algoritm with parameters is introduced bumping block<br />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<br />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,<br />in a paradigm where they still get the sa=
me block subsidy distribution.<br /><br />This is just a thought experiment=
 aiming to invalidate the "as far as anyone can tell" statement on forclosi=
ng forever on-chain<br />settlement throughput increase, if we fix the time=
warp bug.<br /><br />Best,<br />Antoine<br /><div class=3D"gmail_quote"><di=
v dir=3D"auto" class=3D"gmail_attr">Le mercredi 1 mai 2024 =C3=A0 09:58:48 =
UTC+1, Mark F a =C3=A9crit=C2=A0:<br/></div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 204, 204);=
 padding-left: 1ex;">Hi Antoine,<br><br>That&#39;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.<br><br>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.<br><br>=
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&#39;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.<br><br>That changes if we &quot;fix&quot; the timewarp =
bug though. At the very least, the flexible block size and subsidy schedule=
 smoothing can&#39;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.<br><br>Once thrown, this fuse switch can&#39;t be undone. We should b=
e damn sure we will never, ever need that capability before giving it up.<b=
r><br>Mark<br><br><div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gma=
il_attr">On Thursday, April 25, 2024 at 3:46:40=E2=80=AFAM UTC-7 Antoine Ri=
ard wrote:<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">Hi Maaku,<d=
iv><br></div><div></div><div><div>&gt; Every single concern mentioned here =
is addressed prominently in the paper/presentation for Forward Blocks:</div=
><div>&gt;</div><div>&gt; * 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 &gt; 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 &gt;=
 chain matters, and here the block frequency is actually *reduced*, thereby=
 decreasing centralization pressure.</div><div>&gt;</div></div><div><div>&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 &gt; 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-&gt; adjust downward short=
ly after the cessation of that artificial fee pressure.</div></div><div><di=
v><br></div><div>&gt; * Increased block frequency of compatibility blocks h=
as no effect on the total issuance, so miners are not rewarded by faster bl=
ocks.</div><div><br></div><div>&gt; You are free to criticize Forward Block=
s, but please do so by actually addressing the content of the proposal. Let=
&#39;s please hold a standard of intellectual excellence on this &gt; maili=
ng list in which ideas are debated based on content-level arguments rather =
than repeating inaccurate takes from Reddit/Twitter.</div><div><br></div><d=
iv>&gt; 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 &gt; 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 &gt; block sizes w=
hile staying 100% compatible with un-upgraded nodes (all nodes see all tran=
sactions).</div><div><br></div><div>&gt; I think we should keep our options=
 open.</div></div><div></div><div><br></div><div>Somehow, I&#39;m sharing y=
our concerns on preserving the long-term evolvability w.r.t scalability opt=
ions</div><div>of bitcoin under the security model as very roughly describe=
r in the paper. Yet, from my understanding</div><div>of the forwarding bloc=
k 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 ext=
ensible commitment structure (assuming</div><div>a future hypothetical soft=
-fork).</div><div><br></div><div>From my understanding, it&#39;s like doubl=
y linked-list in C, you just need a pointer in the BIP141 extensible</div><=
div>commitment structure referencing back the forward chain headers. If one=
 wishes no logically authoritative</div><div>cross-chain commitment, one co=
uld leverage some dynamic-membership multi-party signature. This</div><div>=
DMMS could even be backup by proof-of-work based schemes.</div><div><br></d=
iv><div>The forward block chain can have higher block-rate frequency and th=
e number of block headers be</div><div>compressed in a merkle tree committe=
d in the BIP141 extensible commitment structure. Compression</div><div>stru=
cture can only be defined by the forward chain consensus algorithm to allow=
 more efficient accumulator</div><div>than merkle tree to be used&quot;.</d=
iv><div><br></div><div>The forward block chain can have elastic block size =
consensus-bounded by miners fees on long period</div><div>of time. Transact=
ion elements can be just committed in the block headers themselves, so no c=
entralization</div><div>pressure on the main chain. Increased block frequen=
cy or block size on the forward block chain have not</div><div>effect on th=
e total issuance (modulo the game-theory limits of the known empirical effe=
cts of colored coins</div><div>on miners incentives).</div><div><br></div><=
div>I think the time-warp issues opens the door to economically non-null ex=
ploitation under some scenarios</div><div>over some considered time periods=
. If one can think to other ways to mitigate the issue in minimal and</div>=
<div>non-invasive way w.r.t current Bitcoin consensus rules and respecting =
un-upgraded node ressources</div><div>consumption, I would say you&#39;re f=
ree to share them.</div><div><br></div><div>I can only share your take on m=
aintaining a standard of intellectual excellence on the mailing list,</div>=
<div>and avoid faltering in Reddit / Twitter-style &quot;madness of the cro=
wd&quot;-like conversations.</div><div><br></div><div>Best,</div><div>Antoi=
ne</div><div><div><br></div></div><div class=3D"gmail_quote"><div dir=3D"au=
to" class=3D"gmail_attr">Le vendredi 19 avril 2024 =C3=A0 01:19:23 UTC+1, A=
ntoine Poinsot a =C3=A9crit=C2=A0:<br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex"><blockquote style=3D"border-color:rgb(200,200,200);border-left=
:3px solid 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=
 criticize 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=
=3Dfr&amp;q=3Dhttps://x.com/0xB10C/status/1780611768081121700&amp;source=3D=
gmail&amp;ust=3D1715043935791000&amp;usg=3DAOvVaw2Vv4r8NfDki5tHipoqfDHs">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=
fr&amp;q=3Dhttp://freico.in/forward-blocks-scalingbitcoin-paper.pdf&amp;sou=
rce=3Dgmail&amp;ust=3D1715043935791000&amp;usg=3DAOvVaw2dVS9ZR81TY3-2iujn3g=
KU">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=3Dfr&amp;q=3Dhttps://groups.google.c=
om/d/msgid/bitcoindev/62640263-077c-4ac7-98a6-d9c17913fca0n%2540googlegroup=
s.com&amp;source=3Dgmail&amp;ust=3D1715043935791000&amp;usg=3DAOvVaw1x7NluV=
z-XFKWoqMEFoAA4">https://groups.google.com/d/msgid/bitcoindev/62640263-077c=
-4ac7-98a6-d9c17913fca0n%40googlegroups.com</a>.<br>

        </blockquote><br>
    </div></blockquote></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/5c2b1a47-5a7a-48f3-9904-c17fa5ece5a6n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/5c2b1a47-5a7a-48f3-9904-c17fa5ece5a6n%40googlegroups.com</a>.=
<br />

------=_Part_336098_933014348.1714957811861--

------=_Part_336097_75779780.1714957811861--