path: root/75/34a1c9f95d689da270a5abae22bf540d583fe8

Delivery-date: Mon, 06 May 2024 03:57:30 -0700
Received: from mail-yb1-f190.google.com ([209.85.219.190])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBC3PT7FYWAMRBD7P4KYQMGQEK24FL7Q@googlegroups.com>)
	id 1s3w2B-0005AV-N5
	for bitcoindev@gnusha.org; Mon, 06 May 2024 03:57:29 -0700
Received: by mail-yb1-f190.google.com with SMTP id 3f1490d57ef6-de60cd96bf3sf4369210276.0
        for <bitcoindev@gnusha.org>; Mon, 06 May 2024 03:57:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1714993041; x=1715597841; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=WDArlbBRoewV3S0e9BnPsfuN9aL23zN8mqlkS15ouZs=;
        b=ips1TwfrsvzBa77+Vkjo4D+Z5loITd+iszyExPffnrQ3H3VZb5URG/Tg8v+q4FfXvZ
         VULmlOu0G8vZlIUWjLCRXp9QGYiGGQfTWNyeagg272/mpPk9yvbeQ17aJxfKn8U4WwP1
         I95UWoIP+dSO7cvBVTlt/TBjM7Kv2t6o7i0gUSM6dglhsMwI1KvrZkE0th4g7ib1vSBu
         D7oEYUdU6t2BvCdOo1QoEqolUYLci61YHuYEgcWGYPDqu1e9mO3sF57uF3a45xRu8hcW
         Gu8ujT2byOKOundPqnNPkgfq3i8YLZXDF5y9HQnyqsFeN0zbCy8Hhy1CIIMe+XF/2KG/
         RHyw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1714993041; x=1715597841; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:from:to:cc
         :subject:date:message-id:reply-to;
        bh=WDArlbBRoewV3S0e9BnPsfuN9aL23zN8mqlkS15ouZs=;
        b=b7qrmJNcia+ixUQlBnDfjsxcJB0PrKLES8EaXq0j1obWvUS8LuoYW7mO41f50yieQm
         GRNmzGlXf/ulkW8yVbZZC8ntS6sVZP3xlIGeTLqiA1vfC23i7OlOupsytXiLG7WgYxyB
         hYRDwMwZ3vZxM7V+9oNO8Sf56mKqC9TBk2ABfklJJtwbXeTn/V/x5t7JasmkLocrjvqe
         lX7l2974tO1krJI1QVKhWoLdiTyp4FVy0cX1Z2mjxxHixQj/Yk/AkMdMOg0uG+1FXkG/
         4MVkdE6ZYdQLlpKtN92VIVjVE87OCuCdmaEz2GaNj3AU9TjYKSBZwk/rVPwDDeFTdp8F
         pZEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1714993041; x=1715597841;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:references:in-reply-to:message-id:to:from:date:x-beenthere
         :x-gm-message-state:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=WDArlbBRoewV3S0e9BnPsfuN9aL23zN8mqlkS15ouZs=;
        b=fPeVx75lwJnDlceGkD0hZ9IIVGThed4Ia1aCsLhWSKWT1WnKNP+q0EY3dxRzY3A9eQ
         WZxiLg8AMIuCiGwABa9t/jwqortAH25DKm20n0ZbwdvbFwzwRsQ9gPZNE4JVUEnwuAHx
         VtoeIlAU5w7GrDThmOZ/J6vbSqh74pazZWB6Oz0Qyo8d5o0MJ1J2oPEa2zJwiQsbwvpm
         bwBtt+Q+pSg6ZXhXc03b5YDjKQKUqiMRgtw/KywXSToF6o5K52xwqHeOQSiEauRFgSeD
         RoiRybP4ZSU1I3HS+ypa6BHjpWvDtnLxW3isWDLebcLFOsM2XeQ4K8uk/TCqIublSWW1
         OWCw==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCUaMBGqLYntNwJPO38DrV4FyQuKYjHXDmpP/hUb7RpOsZKdeQLJiskxH88P/qWxAFga/yjJRIDFwY37zXg86yr99X+HxTs=
X-Gm-Message-State: AOJu0YxLC6Padx3O38MiL8uG8Z3R+zJe6BFQAsVrHFiOa6bCN/L+OmXo
	MmWl3dHSWJRUDpyTgtan2hLLflW5t9IyKa5S5N1QLuGkC7Jc86ay
X-Google-Smtp-Source: AGHT+IHclvgh/Y2boKv4Sp5f6WLlmFZicHlVCqZG8ExYdI5QIEI6ZfVFtlRTMAwR2Kw1vDnStcpAHw==
X-Received: by 2002:a25:aacb:0:b0:de8:a500:ffdb with SMTP id t69-20020a25aacb000000b00de8a500ffdbmr7493576ybi.26.1714993041005;
        Mon, 06 May 2024 03:57:21 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a25:6891:0:b0:de6:10bb:1374 with SMTP id 3f1490d57ef6-de8b54f8c1bls107267276.2.-pod-prod-09-us;
 Mon, 06 May 2024 03:57:19 -0700 (PDT)
X-Received: by 2002:a05:6902:2b0a:b0:de6:166f:3250 with SMTP id fi10-20020a0569022b0a00b00de6166f3250mr3437431ybb.2.1714993039173;
        Mon, 06 May 2024 03:57:19 -0700 (PDT)
Received: by 2002:a05:690c:f88:b0:620:4018:7c57 with SMTP id 00721157ae682-62040188054ms7b3;
        Sun, 5 May 2024 18:10:13 -0700 (PDT)
X-Received: by 2002:a81:8394:0:b0:61a:b2d4:a3fb with SMTP id t142-20020a818394000000b0061ab2d4a3fbmr2056426ywf.8.1714957812240;
        Sun, 05 May 2024 18:10:12 -0700 (PDT)
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"
X-Original-Sender: antoine.riard@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

------=_Part_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--