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 ) 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 ; 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 To: Bitcoin Development Mailing List Message-Id: <34a43375-a08e-4a8d-b409-0fd67730d753n@googlegroups.com> In-Reply-To: <1KbVdD952_XRfsKzMKaX-y4lrPOxYiknn8xXOMDQGt2Qz2fHFM-KoSplL-A_GRE1yuUkgNMeoEBHZiEDlMYwiqOiITFQTKEm5u1p1oVlL9I=@protonmail.com> References: <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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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 > . > > > > 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
ok
O= n 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 "= forwarding blocks" by maaku for on-chain scaling:
I would not qualify this hack of "benef= icial". 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.)


I think any conse= nsus boundaries on the minimal transaction size would need to be done caref= ully and have all lightweight
clients update their own transactio= n acceptance logic to enforce the check to avoid years-long transitory mass= ive double-spend
due to software incoordination.

Note in my writeup i suggest we do not introduce a minimu= m transaction, but we instead only make 64 bytes transactions invalid. See = https://delving= bitcoin.org/t/great-consensus-cleanup-revival/710#can-we-come-up-with-a-bet= ter-fix-10:

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.

M= aking (exactly) 64 bytes long transactions invalid is also what AJ implemen= ted in his pull request to Bitcoin-inquisition.

<= /blockquote>

I doubt `MIN_STANDARD_TX_NON_WITNESS= _SIZE` is implemented correctly by all transaction-relay backends and it= 9;s a mess in this area.

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 7485488e907e236133a016ba7064c89bf9ab6da3).


Quid if we have < 64 bytes transaction where th= e only witness is enforced to be a minimal 1-byte
as witness elem= ents are only used for higher layers protocols semantics ?

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't relevant.


=
Making coinbase unique by requesting t= he block height to be enforced in nLocktime, sounds more robust to take a m= onotonic counter
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
compare to your mining competitors. Better if it= doesn't introduce a new DoS vector at mining job distribution and cont= rol.

<= div>
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 "m= onotonic counter in the past"?

At any rate in my writeup i s= uggested making the coinbase commitment mandatory (even when empty) instead= for compatibility reasons.

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.


<= /div>
=C2=A0and b) it's already a lot of caref= ul consensus
code to get right :)

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.

Best,
Antoine

Le dimanche 24 mars 2024 = =C3=A0 19:06:57 UTC, Antoine Poinsot a =C3=A9crit :
Hey all,

I've recently posted about the Great Consensus Cleanup there: https://delvingbitcoin.org/= t/great-consensus-cleanup-revival/710.

I'm starting a thread on the mailing list as well to get comments a= nd opinions from people who are not on Delving.

TL;DR:
- 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;
- i believe it's more important to fix the timewarp bug than people= usually think;
- 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;
- 64 bytes transactions should definitely be made invalid, but i don= 9;t think there is a strong case for making less than 64 bytes transactions= invalid.

Anything in there that people disagree with conceptually?
Anything in there that people think shouldn't (or don't need to= ) be fixed?
Anything in there which can be improved (a simpler, or better fix)?
Anything NOT in there that people think should be fixed?


Antoine Poinsot

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitc= oindev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/dc2cc46f-e= 697-4b14-91b3-34cf11de29a3n%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg= id/bitcoindev/34a43375-a08e-4a8d-b409-0fd67730d753n%40googlegroups.com.=
------=_Part_517307_462434843.1721511598026-- ------=_Part_517306_569961685.1721511598026--