path: root/b2/7f7b2779609b504b164dc0be416f1e32a03435

Delivery-date: Sun, 21 Jul 2024 02:53:09 -0700
Received: from mail-yb1-f184.google.com ([209.85.219.184])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDFI7PF4QIERB6VU6O2AMGQEPGJFYAI@googlegroups.com>)
	id 1sVTFa-0007Yo-TG
	for bitcoindev@gnusha.org; Sun, 21 Jul 2024 02:53:08 -0700
Received: by mail-yb1-f184.google.com with SMTP id 3f1490d57ef6-e02b5792baasf7316628276.2
        for <bitcoindev@gnusha.org>; Sun, 21 Jul 2024 02:53:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1721555580; x=1722160380; 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=my7YYzMdZKBfp8dbgpGPLC3DnWzp0aQBvaUEvN5UxdE=;
        b=NVgYwxk+yW96UeFvH4JHxLsLaBaY2nTyuhdbsxbSg38Uy/iBMMwelkoXzps/5m+b9q
         DjrTNDuPryYO8a2DzYkv4TGz3vbbJeRzWImBAi3rZS3nwGDg/MBYh0eFSIEoa9rtupaI
         quIsMdgG/lsxFHHHZR5B/t6N+unr1ZPHpGf5TsydIirM0mZd1fCW01VdfM+ErSO8vSd1
         ztI6bjVkjhdkkWLVlUJyP1ptg+EecHWBvYE7vEUFpUirsqwgQNMIJuUdM0osLxTFAy+g
         C1wg4gAxbH110QJpLw+4/TEgqz7TsLCWpoA7HKIo3WCW4Co9FpVuPMcmARqkwzYBeQ6D
         XD+A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1721555580; x=1722160380; 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=my7YYzMdZKBfp8dbgpGPLC3DnWzp0aQBvaUEvN5UxdE=;
        b=Jgz1DjAVfL1/KZOY1EqtGxpyRAFiILnF0ghyucYsPgrsCK+/3iHlg3XCD9BBVhX8QT
         /WZoTzkdzmZpRMT0pi6F6mxIe+f60EmEaquMQWnZiTiDu2thdXAJRfrUw9kUn/hyrZHG
         DJ9/TcT4pQCGLpFJ+iH0NNn7osTnnQ+GHFSK1uWMXQxzvFLyUo54JjF50zTPec3Ewld4
         DRgICFOoXU5+d9gN8YGQYKFV4HJ1v4zLaC9bavQMLImN/i7tm0mV26/2K03sO39pYFDP
         XGFYobpsj83bi8cENRIdBNPwoP6QEpqdx0juPHTk9dbyRQKStWg12OayXn0hpEmF/ljR
         GD8A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1721555580; x=1722160380;
        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=my7YYzMdZKBfp8dbgpGPLC3DnWzp0aQBvaUEvN5UxdE=;
        b=JsFJuKXJmXHC8/qMPCKAwQFPqaV0snU+96NTCsh0L5O7umUQP8DSqKPIavQbaPcvc7
         y14MlD0I9tA0frxUv997c0GbKQGlCDUscW5yc6UDaixn+Zs2+43IOuLNxo756pikBW6+
         MYF52r1OdD0nr15sf0xsSMpBvG82U2Ny7R50d7kr+vV+mfEmrxdnR8xNuowZYzT30zOt
         GpLUPqjrbuPPWOva6LQLuhNA0+Jt1KH40rJUp4ySfsyQ2wg18EDApogIHl58odX5WTOZ
         VdKAE583Bdlm0trM9aeaW+hj7nAzpLV77wJO8K/56IlHl8Bgp3NaWusG21saqsKvnFD8
         I7rQ==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCU4LZHTeucu8yQL17Ci6Y5aYdttvM5pNuKCw+OGiRmpiyByohg6wfIs1OpthodybOUwaUk0QtVr/eqv0K8B4a+OSd39S74=
X-Gm-Message-State: AOJu0YxIZRg5Gcm4janULyGMiUtCeRKhxVKTjW9B6nZY8TNFS6kcgH8I
	aADhr9frvkUSHfkeWzVeVS6ybTbQRdXYIyUf3PcugNeqkkryXmJ4
X-Google-Smtp-Source: AGHT+IEJq2t4zsKOy+Ttv6nYx11mvjJLbNJJfiZaSgjwup+mxnieic6Xbps6dvgmrTnXpFQG1CZwsA==
X-Received: by 2002:a05:6902:2207:b0:e05:f270:aa6 with SMTP id 3f1490d57ef6-e087067adb2mr4722358276.46.1721555580341;
        Sun, 21 Jul 2024 02:53:00 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a25:ab13:0:b0:e05:a978:7726 with SMTP id 3f1490d57ef6-e05fdbde3b6ls3509849276.2.-pod-prod-00-us;
 Sun, 21 Jul 2024 02:52:58 -0700 (PDT)
X-Received: by 2002:a05:690c:8:b0:64b:2608:a6b9 with SMTP id 00721157ae682-66a66060563mr5357267b3.3.1721555578476;
        Sun, 21 Jul 2024 02:52:58 -0700 (PDT)
Received: by 2002:a05:690c:2e0a:b0:64a:6fb4:b878 with SMTP id 00721157ae682-669195b3414ms7b3;
        Sat, 20 Jul 2024 14:39:59 -0700 (PDT)
X-Received: by 2002:a05:690c:6606:b0:618:5009:cb71 with SMTP id 00721157ae682-66a66a2ba20mr3801357b3.5.1721511598233;
        Sat, 20 Jul 2024 14:39:58 -0700 (PDT)
Date: Sat, 20 Jul 2024 14:39:58 -0700 (PDT)
From: Murad Ali <murad55533320@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <34a43375-a08e-4a8d-b409-0fd67730d753n@googlegroups.com>
In-Reply-To: <1KbVdD952_XRfsKzMKaX-y4lrPOxYiknn8xXOMDQGt2Qz2fHFM-KoSplL-A_GRE1yuUkgNMeoEBHZiEDlMYwiqOiITFQTKEm5u1p1oVlL9I=@protonmail.com>
References: <gnM89sIQ7MhDgI62JciQEGy63DassEv7YZAMhj0IEuIo0EdnafykF6RH4OqjTTHIHsIoZvC2MnTUzJI7EfET4o-UQoD-XAQRDcct994VarE=@protonmail.com>
 <dc2cc46f-e697-4b14-91b3-34cf11de29a3n@googlegroups.com>
 <1KbVdD952_XRfsKzMKaX-y4lrPOxYiknn8xXOMDQGt2Qz2fHFM-KoSplL-A_GRE1yuUkgNMeoEBHZiEDlMYwiqOiITFQTKEm5u1p1oVlL9I=@protonmail.com>
Subject: Re: [bitcoindev] Re: Great Consensus Cleanup Revival
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_517306_569961685.1721511598026"
X-Original-Sender: murad55533320@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_517306_569961685.1721511598026
Content-Type: multipart/alternative; 
	boundary="----=_Part_517307_462434843.1721511598026"

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


ok
On Wednesday 27 March 2024 at 04:00:34 UTC-7 Antoine Poinsot wrote:

>
> Hi Poinsot,
>
>
> Hi Riard,
>
>
> The only beneficial case I can remember about the timewarp issue is=20
> "forwarding blocks" by maaku for on-chain scaling:
> http://freico.in/forward-blocks-scalingbitcoin-paper.pdf
>
>
> I would not qualify this hack of "beneficial". Besides the centralization=
=20
> pressure of an increased block frequency, leveraging the timewarp to=20
> achieve it would put the network constantly on the Brink of being serious=
ly=20
> (fatally?) harmed. And this sets pernicious incentives too. Every=20
> individual user has a short-term incentive to get lower fees by the=20
> increased block space, at the expense of all users longer term. And every=
=20
> individual miner has an incentive to get more block reward at the expense=
=20
> of future miners. (And of course bigger miners benefit from an increased=
=20
> block frequency.)
>
>
> I think any consensus boundaries on the minimal transaction size would=20
> need to be done carefully and have all lightweight
> clients update their own transaction acceptance logic to enforce the chec=
k=20
> to avoid years-long transitory massive double-spend
> due to software incoordination.
>
>
> Note in my writeup i suggest we do not introduce a minimum transaction,=
=20
> but we instead only make 64 bytes transactions invalid. See=20
> https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710#can-we-c=
ome-up-with-a-better-fix-10
> :
>
> However the BIP proposes to also make less-than-64-bytes transactions=20
> invalid. Although they are of no (or little) use, such transactions are n=
ot=20
> harmful. I believe considering a type of transaction useless is not=20
> sufficient motivation for making them invalid through a soft fork.
>
> Making (exactly) 64 bytes long transactions invalid is also what AJ=20
> implemented in his pull request to Bitcoin-inquisition=20
> <https://github.com/bitcoin-inquisition/bitcoin/pull/24>.
>
>
>
> I doubt `MIN_STANDARD_TX_NON_WITNESS_SIZE` is implemented correctly by al=
l=20
> transaction-relay backends and it's a mess in this area.
>
>
> What type of backend are you referring to here? Bitcoin full nodes=20
> reimplementations? These transactions have been non-standard in Bitcoin=
=20
> Core for the past 6 years (commit 7485488e907e236133a016ba7064c89bf9ab6da=
3
> ).
>
>
> Quid if we have < 64 bytes transaction where the only witness is enforced=
=20
> to be a minimal 1-byte
> as witness elements are only used for higher layers protocols semantics ?
>
>
> This restriction is on the size of the transaction serialized without=20
> witness. So this particular instance would not be affected and whatever t=
he=20
> witness is isn't relevant.
>
>
> Making coinbase unique by requesting the block height to be enforced in=
=20
> nLocktime, sounds more robust to take a monotonic counter
> in the past in case of accidental or provoked shallow reorgs. I can see o=
f=20
> you would have to re-compute a block template, loss a round-trip
> compare to your mining competitors. Better if it doesn't introduce a new=
=20
> DoS vector at mining job distribution and control.
>
>
> Could you clarify? Are you suggesting something else than to set the=20
> nLockTime in the coinbase transaction to the height of the block? If so,=
=20
> what exactly are you referring to by "monotonic counter in the past"?
>
> At any rate in my writeup i suggested making the coinbase commitment=20
> mandatory (even when empty) instead for compatibility reasons.
>
> That said, since we could make this rule kick in in 25 years from now, we=
=20
> might want to just do the Obvious Thing and just require the height in=20
> nLockTime.
>
>
>  and b) it's already a lot of careful consensus
> code to get right :)
>
>
> Definitely. I just want to make sure we are not missing anything importan=
t=20
> if a soft fork gets proposed along these lines in the future.
>
>
> Best,
> Antoine
>
> Le dimanche 24 mars 2024 =C3=A0 19:06:57 UTC, Antoine Poinsot a =C3=A9cri=
t :
>
>> Hey all,=20
>>
>> I've recently posted about the Great Consensus Cleanup there:=20
>> https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710.=20
>>
>> I'm starting a thread on the mailing list as well to get comments and=20
>> opinions from people who are not on Delving.=20
>>
>> TL;DR:=20
>> - i think the worst block validation time is concerning. The mitigations=
=20
>> proposed by Matt are effective, but i think we should also limit the=20
>> maximum size of legacy transactions for an additional safety margin;=20
>> - i believe it's more important to fix the timewarp bug than people=20
>> usually think;=20
>> - it would be nice to include a fix to make coinbase transactions unique=
=20
>> once and for all, to avoid having to resort back to doing BIP30 validati=
on=20
>> after block 1,983,702;=20
>> - 64 bytes transactions should definitely be made invalid, but i don't=
=20
>> think there is a strong case for making less than 64 bytes transactions=
=20
>> invalid.=20
>>
>> Anything in there that people disagree with conceptually?=20
>> Anything in there that people think shouldn't (or don't need to) be=20
>> fixed?=20
>> Anything in there which can be improved (a simpler, or better fix)?=20
>> Anything NOT in there that people think should be fixed?=20
>>
>>
>> Antoine Poinsot=20
>>
> --=20
> You received this message because you are subscribed to the Google Groups=
=20
> "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
=20
> email to bitcoindev+...@googlegroups.com.
> To view this discussion on the web visit=20
> https://groups.google.com/d/msgid/bitcoindev/dc2cc46f-e697-4b14-91b3-34cf=
11de29a3n%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/34a43375-a08e-4a8d-b409-0fd67730d753n%40googlegroups.com.

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

<br />ok<div class=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">O=
n Wednesday 27 March 2024 at 04:00:34 UTC-7 Antoine Poinsot 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;"><div style=3D"font-fa=
mily:Arial,sans-serif;font-size:14px"><br></div>
        <div><blockquote type=3D"cite">
            Hi Poinsot,</blockquote><div style=3D"font-family:Arial,sans-se=
rif;font-size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)"><br>=
</div><div style=3D"font-family:Arial,sans-serif;font-size:14px;color:rgb(0=
,0,0);background-color:rgb(255,255,255)">Hi Riard,<br></div></div><div><div=
 style=3D"font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);back=
ground-color:rgb(255,255,255)"><br></div><br><blockquote type=3D"cite"><div=
>The only beneficial case I can remember about the timewarp issue is &quot;=
forwarding blocks&quot; by maaku for on-chain scaling:</div><div><a href=3D=
"http://freico.in/forward-blocks-scalingbitcoin-paper.pdf" target=3D"_blank=
" rel=3D"nofollow" data-saferedirecturl=3D"https://www.google.com/url?hl=3D=
en-GB&amp;q=3Dhttp://freico.in/forward-blocks-scalingbitcoin-paper.pdf&amp;=
source=3Dgmail&amp;ust=3D1721597961213000&amp;usg=3DAOvVaw3s46FXgx6UISBNt2B=
gVt-o">http://freico.in/forward-blocks-scalingbitcoin-paper.pdf</a><br></di=
v></blockquote><div style=3D"font-family:Arial,sans-serif;font-size:14px;co=
lor:rgb(0,0,0);background-color:rgb(255,255,255)"><br></div></div><div><div=
 style=3D"font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);back=
ground-color:rgb(255,255,255)">I would not qualify this hack of &quot;benef=
icial&quot;. Besides the centralization pressure of an increased block freq=
uency, leveraging the timewarp to achieve it would put the network constant=
ly on the Brink of being seriously (fatally?) harmed. And this sets pernici=
ous incentives too. Every individual user has a short-term incentive to get=
 lower fees by the increased block space, at the expense of all users longe=
r term. And every individual miner has an incentive to get more block rewar=
d at the expense of future miners. (And of course bigger miners benefit fro=
m an increased block frequency.)<br></div></div><div><div style=3D"font-fam=
ily:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);background-color:rgb(2=
55,255,255)"><br></div><br><blockquote type=3D"cite"><div>I think any conse=
nsus boundaries on the minimal transaction size would need to be done caref=
ully and have all lightweight</div><div>clients update their own transactio=
n acceptance logic to enforce the check to avoid years-long transitory mass=
ive double-spend</div><div>due to software incoordination.</div></blockquot=
e><div style=3D"font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0=
);background-color:rgb(255,255,255)"><br></div></div><div><div style=3D"fon=
t-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);background-color:=
rgb(255,255,255)">Note in my writeup i suggest we do not introduce a minimu=
m transaction, but we instead only make 64 bytes transactions invalid. See =
<span><a rel=3D"noreferrer nofollow noopener" href=3D"https://delvingbitcoi=
n.org/t/great-consensus-cleanup-revival/710#can-we-come-up-with-a-better-fi=
x-10" target=3D"_blank" data-saferedirecturl=3D"https://www.google.com/url?=
hl=3Den-GB&amp;q=3Dhttps://delvingbitcoin.org/t/great-consensus-cleanup-rev=
ival/710%23can-we-come-up-with-a-better-fix-10&amp;source=3Dgmail&amp;ust=
=3D1721597961213000&amp;usg=3DAOvVaw3kZbtE2QIAw9zFwR9y-zIy">https://delving=
bitcoin.org/t/great-consensus-cleanup-revival/710#can-we-come-up-with-a-bet=
ter-fix-10</a></span>:</div><blockquote style=3D"border-color:rgb(200,200,2=
00);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;color:r=
gb(0,0,0);background-color:rgb(255,255,255)"><p>However the BIP proposes to=
 also make less-than-64-bytes transactions
 invalid. Although they are of no (or little) use, such transactions are
 not harmful. I believe considering a type of transaction useless is not
 sufficient motivation for making them invalid through a soft fork.</p><p>M=
aking (exactly) 64 bytes long transactions invalid is also what AJ implemen=
ted in <a href=3D"https://github.com/bitcoin-inquisition/bitcoin/pull/24" t=
arget=3D"_blank" rel=3D"nofollow" data-saferedirecturl=3D"https://www.googl=
e.com/url?hl=3Den-GB&amp;q=3Dhttps://github.com/bitcoin-inquisition/bitcoin=
/pull/24&amp;source=3Dgmail&amp;ust=3D1721597961213000&amp;usg=3DAOvVaw2Bxx=
dKdmfvz6FoCj06wOTt">his pull request to Bitcoin-inquisition</a>.</p></div><=
/blockquote></div><div><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><b=
r></div><blockquote type=3D"cite"><div>I doubt `MIN_STANDARD_TX_NON_WITNESS=
_SIZE` is implemented correctly by all transaction-relay backends and it&#3=
9;s a mess in this area.</div></blockquote><div style=3D"font-family:Arial,=
sans-serif;font-size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255=
)"><br></div></div><div><div style=3D"font-family:Arial,sans-serif;font-siz=
e:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)">What type of bac=
kend are you referring to here? Bitcoin full nodes reimplementations? These=
 transactions have been non-standard in Bitcoin Core for the past 6 years (=
commit <span>7485488e907e236133a016ba7064c89bf9ab6da3</span>).<br></div></d=
iv><div><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><br></div><blockq=
uote type=3D"cite"><div>Quid if we have  &lt; 64 bytes transaction where th=
e only witness is enforced to be a minimal 1-byte</div><div>as witness elem=
ents are only used for higher layers protocols semantics  ?</div></blockquo=
te><div style=3D"font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,=
0);background-color:rgb(255,255,255)"><br></div></div><div><div style=3D"fo=
nt-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);background-color=
:rgb(255,255,255)">This restriction is on the size of the transaction seria=
lized without witness. So this particular instance would not be affected an=
d whatever the witness is isn&#39;t relevant.<br></div></div><div><div styl=
e=3D"font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);backgroun=
d-color:rgb(255,255,255)"><br></div><div style=3D"font-family:Arial,sans-se=
rif;font-size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)"><br>=
</div><blockquote type=3D"cite"><div>Making coinbase unique by requesting t=
he block height to be enforced in nLocktime, sounds more robust to take a m=
onotonic counter</div><div>in the past in case of accidental or provoked sh=
allow reorgs. I can see of you would have to re-compute a block template, l=
oss a round-trip</div><div>compare to your mining competitors. Better if it=
 doesn&#39;t introduce a new DoS vector at mining job distribution and cont=
rol.</div></blockquote><div style=3D"font-family:Arial,sans-serif;font-size=
:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)"><br></div></div><=
div><div style=3D"font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0=
,0);background-color:rgb(255,255,255)">Could you clarify? Are you suggestin=
g something else than to set the nLockTime in the coinbase transaction to t=
he height of the block? If so, what exactly are you referring to by &quot;m=
onotonic counter in the past&quot;?</div><div style=3D"font-family:Arial,sa=
ns-serif;font-size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)"=
><br></div><div style=3D"font-family:Arial,sans-serif;font-size:14px;color:=
rgb(0,0,0);background-color:rgb(255,255,255)">At any rate in my writeup i s=
uggested making the coinbase commitment mandatory (even when empty) instead=
 for compatibility reasons.</div><div style=3D"font-family:Arial,sans-serif=
;font-size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)"><br></d=
iv><div style=3D"font-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,=
0);background-color:rgb(255,255,255)">That said, since we could make this r=
ule kick in in 25 years from now, we might want to just do the Obvious Thin=
g and just require the height in nLockTime.<br></div></div><div><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 style=3D"font-family:Arial,sans-ser=
if;font-size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)"><br><=
/div><blockquote type=3D"cite">=C2=A0and b) it&#39;s already a lot of caref=
ul consensus<div>code to get right :)</div></blockquote><div style=3D"font-=
family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);background-color:rg=
b(255,255,255)"><br></div></div><div><div style=3D"font-family:Arial,sans-s=
erif;font-size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)">Def=
initely. I just want to make sure we are not missing anything important if =
a soft fork gets proposed along these lines in the future.<br></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)"><br></div><div style=3D"font-family:Arial,sans-=
serif;font-size:14px;color:rgb(0,0,0);background-color:rgb(255,255,255)"><b=
r></div><blockquote type=3D"cite"></blockquote></div><div><blockquote type=
=3D"cite"><div>Best,</div><div>Antoine</div><div><br></div><div class=3D"gm=
ail_quote"><div class=3D"gmail_attr" dir=3D"auto">Le dimanche 24 mars 2024 =
=C3=A0 19:06:57 UTC, Antoine Poinsot a =C3=A9crit :<br></div><blockquote st=
yle=3D"margin:0 0 0 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex" class=3D"gmail_quote">Hey all,
<br>
<br>I&#39;ve recently posted about the Great Consensus Cleanup there: <a re=
l=3D"noreferrer nofollow noopener" href=3D"https://delvingbitcoin.org/t/gre=
at-consensus-cleanup-revival/710" target=3D"_blank" data-saferedirecturl=3D=
"https://www.google.com/url?hl=3Den-GB&amp;q=3Dhttps://delvingbitcoin.org/t=
/great-consensus-cleanup-revival/710&amp;source=3Dgmail&amp;ust=3D172159796=
1213000&amp;usg=3DAOvVaw2vxBKL4Qxqn984ANoDNFO-">https://delvingbitcoin.org/=
t/great-consensus-cleanup-revival/710</a>.
<br>
<br>I&#39;m starting a thread on the mailing list as well to get comments a=
nd opinions from people who are not on Delving.
<br>
<br>TL;DR:
<br>- i think the worst block validation time is concerning. The mitigation=
s proposed by Matt are effective, but i think we should also limit the maxi=
mum size of legacy transactions for an additional safety margin;
<br>- i believe it&#39;s more important to fix the timewarp bug than people=
 usually think;
<br>- it would be nice to include a fix to make coinbase transactions uniqu=
e once and for all, to avoid having to resort back to doing BIP30 validatio=
n after block 1,983,702;
<br>- 64 bytes transactions should definitely be made invalid, but i don&#3=
9;t think there is a strong case for making less than 64 bytes transactions=
 invalid.
<br>
<br>Anything in there that people disagree with conceptually?
<br>Anything in there that people think shouldn&#39;t (or don&#39;t need to=
) be fixed?
<br>Anything in there which can be improved (a simpler, or better fix)?
<br>Anything NOT in there that people think should be fixed?
<br>
<br>
<br>Antoine Poinsot
<br></blockquote></div>

<p></p></blockquote></div><div><blockquote type=3D"cite">

-- <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 rel=3D"noreferrer nofollow noopener" data-email-masked>bitc=
oindev+...@googlegroups.com</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/dc2cc46f-e697-4b14-91b3-34cf11de29a3n%40googlegroups.=
com" rel=3D"noreferrer nofollow noopener" target=3D"_blank" data-saferedire=
cturl=3D"https://www.google.com/url?hl=3Den-GB&amp;q=3Dhttps://groups.googl=
e.com/d/msgid/bitcoindev/dc2cc46f-e697-4b14-91b3-34cf11de29a3n%2540googlegr=
oups.com&amp;source=3Dgmail&amp;ust=3D1721597961213000&amp;usg=3DAOvVaw3Y0a=
E3Ac_DjuPgNkg5i6mk">https://groups.google.com/d/msgid/bitcoindev/dc2cc46f-e=
697-4b14-91b3-34cf11de29a3n%40googlegroups.com</a>.<br>

        </blockquote><br>
    </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/34a43375-a08e-4a8d-b409-0fd67730d753n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/34a43375-a08e-4a8d-b409-0fd67730d753n%40googlegroups.com</a>.=
<br />

------=_Part_517307_462434843.1721511598026--

------=_Part_517306_569961685.1721511598026--