path: root/a4/466dabd7375eaaa32d6aef32e956f1ee14280a

Delivery-date: Wed, 27 Mar 2024 04:00:41 -0700
Received: from mail-qt1-f189.google.com ([209.85.160.189])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDL4XL646QOBBUPYR6YAMGQE2BDM5VI@googlegroups.com>)
	id 1rpR1N-0007GS-4L
	for bitcoindev@gnusha.org; Wed, 27 Mar 2024 04:00:41 -0700
Received: by mail-qt1-f189.google.com with SMTP id d75a77b69052e-4311e71a898sf84129621cf.1
        for <bitcoindev@gnusha.org>; Wed, 27 Mar 2024 04:00:40 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1711537235; cv=pass;
        d=google.com; s=arc-20160816;
        b=dBy5iyZWFRSnwUnQ6MWDXKk4v2cTuYn7Pj1tOdo6KOZZYO5ASycY139OgN7BQVgKyj
         k+5PBsjV5nnjwkypsIbG9tN2/6Z2NuWuZhOFaKne51nNpZewulKWDolqsWIzh/1IynQV
         VtTctMT/2191OY9E8MM9pn32kEyXhUxN4HcUonEzQco5jbbucXTENzw0Wms5KWs9mLkV
         TO5vf4YIYe6piQE4q7Hlbm1QdsnxDG+D+BY2ZrXjZzl7HNwHG63B5N2KDR2lQUj7uvyK
         aMu0v+17AaE/mLLua6jLLoVT0ZFvTxz1z5hwp+4QbM+OcW4kZQocnqJXTxFfrmnfl5F2
         Jraw==
ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to:mime-version:feedback-id
         :references:in-reply-to:message-id:subject:cc:from:to:date
         :dkim-signature;
        bh=a4+gvGI9QeBGunBLyJciAKSQdxAlzUJNBAr+dcL4c04=;
        fh=Ra9H7dDuQhPuv3+utZzDf5JfXTMsnOrnaq++ltpkADs=;
        b=K1XFzHcnQO49zXEOxMWmv3eNFGzzD9XcSnCafzkFB2gSz5NxLFn0ADWRpELkSYsCU4
         IeYMlIAyITPXipIo0dM4evNOa+XqTcvsIN/ht3DTnsrnJlzDm9tUsqBBp4gArqFtAajT
         Mf0+ag84CK3Th3a1CzPir35DK3m7d3QrBlUgk66+S2yvaPzw9QRRoqpNOYFbnSe0sMK+
         b1hhR11M2D2wukkF6ShQmCljKMM0+itw4IknGQjRbaX2BPDvQCanffEGebBONbbcLora
         EUwbqIBKRtoMGCdZG7zwOb52Ng+UIaeXBg5sP7L5yu30jsOjpvecMJ3EvOqnfXa1Hy3C
         9PjQ==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=BaHvvz9K;
       spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.18 as permitted sender) smtp.mailfrom=darosior@protonmail.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1711537235; x=1712142035; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to
         :x-original-authentication-results:x-original-sender:mime-version
         :feedback-id:references:in-reply-to:message-id:subject:cc:from:to
         :date:from:to:cc:subject:date:message-id:reply-to;
        bh=a4+gvGI9QeBGunBLyJciAKSQdxAlzUJNBAr+dcL4c04=;
        b=pV0CSok8ma6mCKiSgx3lEktTpnpqP/joEfKp6eMwIW/eROR87FcSzheLmVybk19k4u
         C1xnhrn7T2X958AXmcDwpq1KxX7T05dLAHaBMcVBRR7enUpvf5eu7yZEHQ6fg43ILqvU
         fUaSeSg6t+xZEpTKh2HTo3ZecGGWnc1AcKh6a6smS+6djjg7o1gn5FM4aHecNTxZv81X
         c8+X6pKo68aZ1/AVR0fOfJmQEnTfTTgU95gU9WaIuYS7tYga2lLp0qGSdjIUfElRyJAm
         viwsHHKgtS9luIz7JeYudRyWWmvcxQtIpZZIJ00X3p14pnbbdDSDOACssz5Z6v+sVi7d
         C0dA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711537235; x=1712142035;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:reply-to
         :x-original-authentication-results:x-original-sender:mime-version
         :feedback-id:references:in-reply-to:message-id:subject:cc:from:to
         :date:x-beenthere:x-gm-message-state:from:to:cc:subject:date
         :message-id:reply-to;
        bh=a4+gvGI9QeBGunBLyJciAKSQdxAlzUJNBAr+dcL4c04=;
        b=Y/nTMS5qzr2a20jhJ6Oj6eq86k73KiUo/+jvpon0CG3Bh7ptyeM7Ls6LXVrmaN6XHn
         HEbfPDfWXfo8VliuJLmpjMmPTkrLWZ+1Sw0ylGTe1yUnYDa74BjgmxBp2EPbAlww2ZmK
         iga+/+szbYM5foGbRghBwDaofCj0U0Ql2S2mKVeFez/gVy0kjGUDBVjOvyeC1PiX9Twa
         LVspnT86UlvcBjT6x4rvPkbYKvIWjXyKLEA+6k4KkZ8eEkw845b5JcWA44Gp6bMT7URH
         6iGrsZcnsqa1BFHj2YxiMEVZxhzSV/GvpsKgPbvN3L83t8oXS6Jbi9MFoh1lakIvhhyu
         kkhw==
X-Forwarded-Encrypted: i=2; AJvYcCXIuoxjZTXZrlLXysEIEqlN8S3Az3uUVXjQGZ+yHTVRXSb9ye4ZdXcfukJyduh17R/Vtv1zUGefR9LCQaNuvEByR7Io9vE=
X-Gm-Message-State: AOJu0YyR7v/Z1oXloVUKdl3h2W5Gy2j9D7UMQLLHvufu8pcmhMOPK393
	Tk5+qK8OQU2oIUV8qJeRmsGrckOK0UQX0nEgnrZNsg+1JrKUnPtD
X-Google-Smtp-Source: AGHT+IEcRx25NSw7T4LMj3UDfpVlGdQxbT4TRmZhQgDpkBLkoiPdf7o0GRaFuOk/Njxwg+pHQKmxrg==
X-Received: by 2002:a05:622a:1b87:b0:431:529b:e0ed with SMTP id bp7-20020a05622a1b8700b00431529be0edmr748174qtb.14.1711537234532;
        Wed, 27 Mar 2024 04:00:34 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a05:622a:1314:b0:431:5f32:de48 with SMTP id
 v20-20020a05622a131400b004315f32de48ls125317qtk.1.-pod-prod-09-us; Wed, 27
 Mar 2024 04:00:33 -0700 (PDT)
X-Received: by 2002:a05:622a:2a09:b0:431:5b14:3056 with SMTP id hc9-20020a05622a2a0900b004315b143056mr699631qtb.4.1711537233457;
        Wed, 27 Mar 2024 04:00:33 -0700 (PDT)
Received: by 2002:a05:620a:1a1f:b0:78a:4f40:42f5 with SMTP id af79cd13be357-78a6c1329c8ms85a;
        Wed, 27 Mar 2024 03:36:03 -0700 (PDT)
X-Received: by 2002:a19:3848:0:b0:513:8a39:e0d9 with SMTP id d8-20020a193848000000b005138a39e0d9mr606670lfj.64.1711535760953;
        Wed, 27 Mar 2024 03:36:00 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1711535760; cv=none;
        d=google.com; s=arc-20160816;
        b=UuV194uIpQTkbjijAR4BeEPEbqJSUmqVgzcaw2AA4P8BUPIYfE5DaBLviLlNrKNZTV
         l9z+xVZT80PCHjVSSViFpIZgTDtav7d0769MAvem8NarRjFY4C3cBuKjQQPJJPg4jzFM
         JNqcXWGEv3tmR/wPeVPi+cLsQAEg/nvcAJBI/Kz48WQX+F9ccofdWLsyMb/VGh4UiWgc
         rI44wTxbLY5wb94hZ2hYe4t8CfL6W61ChfbCLAOA1jXyFbNO5JpeTaEoEb9OGhVXeD3d
         MvZbGmA6zfsHdLFfM+BQEN7/74ZkNLv1fHgKsbbKVKwjJwl6fs0Evog0rW5a7l2Lu+Dp
         8Zcg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=mime-version:feedback-id:references:in-reply-to:message-id:subject
         :cc:from:to:date:dkim-signature;
        bh=wI43J7HP0+3Nq4ei82Me60rMmm1ZOItSPT7HVzJY5Js=;
        fh=sapDHqhE46zLmMBeB1lkoe0zq8J9+V3Afx71/j8kvug=;
        b=J7K7EK5wB3uyKawlKtP/ImOqBcmocLEGS/KMySUrd6raaepAiXoZyA6Y7hh8PbLfQp
         1/fH6qrxIOXo61xIreblU+FeVok/DwjZ9QvIK+QHUx1xlGybp5fKnAWM0PQZ7CWCN4oZ
         0VLaOvSAxxIQ4sD48Ztpwx2jTd1VvpuwePD8oLV1L5UVj2L+JrIGky5rll9/hurnKhCK
         ihgSTz/eCCeGWwvMLZXCziJgrrukqEZh0Ic5PF7kcL2IvqemDZCRrE6ohoESunNk1Kbu
         I4nA/RLSRIR+L8rrJiCselXcHw6+YLFjIWmh5onOLqokYWL+ILlZl2pBNOMhD+lwzWkh
         fqRQ==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@protonmail.com header.s=protonmail3 header.b=BaHvvz9K;
       spf=pass (google.com: domain of darosior@protonmail.com designates 185.70.43.18 as permitted sender) smtp.mailfrom=darosior@protonmail.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com
Received: from mail-4318.protonmail.ch (mail-4318.protonmail.ch. [185.70.43.18])
        by gmr-mx.google.com with ESMTPS id p13-20020a05651211ed00b0051584d7f6a3si260646lfs.8.2024.03.27.03.36.00
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Wed, 27 Mar 2024 03:36:00 -0700 (PDT)
Received-SPF: pass (google.com: domain of darosior@protonmail.com designates 185.70.43.18 as permitted sender) client-ip=185.70.43.18;
Date: Wed, 27 Mar 2024 10:35:51 +0000
To: Antoine Riard <antoine.riard@gmail.com>
From: "'Antoine Poinsot' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Re: Great Consensus Cleanup Revival
Message-ID: <1KbVdD952_XRfsKzMKaX-y4lrPOxYiknn8xXOMDQGt2Qz2fHFM-KoSplL-A_GRE1yuUkgNMeoEBHZiEDlMYwiqOiITFQTKEm5u1p1oVlL9I=@protonmail.com>
In-Reply-To: <dc2cc46f-e697-4b14-91b3-34cf11de29a3n@googlegroups.com>
References: <gnM89sIQ7MhDgI62JciQEGy63DassEv7YZAMhj0IEuIo0EdnafykF6RH4OqjTTHIHsIoZvC2MnTUzJI7EfET4o-UQoD-XAQRDcct994VarE=@protonmail.com> <dc2cc46f-e697-4b14-91b3-34cf11de29a3n@googlegroups.com>
Feedback-ID: 7060259:user:proton
MIME-Version: 1.0
Content-Type: multipart/alternative;
 boundary="b1_u70ErIln1yHwbVljTNO079SNuKdPPACFp4808fxkfA"
X-Original-Sender: darosior@protonmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@protonmail.com header.s=protonmail3 header.b=BaHvvz9K;
       spf=pass (google.com: domain of darosior@protonmail.com designates
 185.70.43.18 as permitted sender) smtp.mailfrom=darosior@protonmail.com;
       dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=protonmail.com
X-Original-From: Antoine Poinsot <darosior@protonmail.com>
Reply-To: Antoine Poinsot <darosior@protonmail.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: -1.0 (-)

This is a multi-part message in MIME format.

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

> Hi Poinsot,

Hi Riard,

> The only beneficial case I can remember about the timewarp issue is "forw=
arding 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 p=
ressure of an increased block frequency, leveraging the timewarp to achieve=
 it would put the network constantly on the Brink of being seriously (fatal=
ly?) harmed. And this sets pernicious 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 longer term. And every individual miner has an=
 incentive to get more block reward at the expense of future miners. (And o=
f course bigger miners benefit from an increased block frequency.)

> I think any consensus boundaries on the minimal transaction size would ne=
ed to be done carefully and have all lightweight
> clients update their own transaction acceptance logic to enforce the chec=
k 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, but=
 we instead only make 64 bytes transactions invalid. See https://delvingbit=
coin.org/t/great-consensus-cleanup-revival/710#can-we-come-up-with-a-better=
-fix-10:

> However the BIP proposes to also make less-than-64-bytes transactions inv=
alid. Although they are of no (or little) use, such transactions are not ha=
rmful. I believe considering a type of transaction useless is not sufficien=
t motivation for making them invalid through a soft fork.
>
> Making (exactly) 64 bytes long transactions invalid is also what AJ imple=
mented in [his pull request to Bitcoin-inquisition](https://github.com/bitc=
oin-inquisition/bitcoin/pull/24).

> I doubt `MIN_STANDARD_TX_NON_WITNESS_SIZE` is implemented correctly by al=
l transaction-relay backends and it's a mess in this area.

What type of backend are you referring to here? Bitcoin full nodes reimplem=
entations? These transactions have been non-standard in Bitcoin Core for th=
e past 6 years (commit 7485488e907e236133a016ba7064c89bf9ab6da3).

> Quid if we have < 64 bytes transaction where the only witness is enforced=
 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 witne=
ss. So this particular instance would not be affected and whatever the witn=
ess is isn't relevant.

> Making coinbase unique by requesting the block height to be enforced in n=
Locktime, sounds more robust to take a monotonic counter
> in the past in case of accidental or provoked shallow reorgs. I can see o=
f 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 =
DoS vector at mining job distribution and control.

Could you clarify? Are you suggesting something else than to set the nLockT=
ime in the coinbase transaction to the height of the block? If so, what exa=
ctly are you referring to by "monotonic counter in the past"?

At any rate in my writeup i suggested making the coinbase commitment mandat=
ory (even when empty) instead for compatibility reasons.

That said, since we could make this rule kick in in 25 years from now, we m=
ight want to just do the Obvious Thing and just require the height in nLock=
Time.

> 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 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=A9cri=
t :
>
>> Hey all,
>>
>> I've recently posted about the Great Consensus Cleanup there: https://de=
lvingbitcoin.org/t/great-consensus-cleanup-revival/710.
>>
>> I'm starting a thread on the mailing list as well to get comments and op=
inions from people who are not on Delving.
>>
>> TL;DR:
>> - i think the worst block validation time is concerning. The mitigations=
 proposed by Matt are effective, but i think we should also limit the maxim=
um size of legacy transactions for an additional safety margin;
>> - i believe it's more important to fix the timewarp bug than people usua=
lly think;
>> - it would be nice to include a fix to make coinbase transactions unique=
 once and for all, to avoid having to resort back to doing BIP30 validation=
 after block 1,983,702;
>> - 64 bytes transactions should definitely be made invalid, but i don't t=
hink there is a strong case for making less than 64 bytes transactions inva=
lid.
>>
>> Anything in there that people disagree with conceptually?
>> Anything in there that people think shouldn't (or don't need to) be fixe=
d?
>> 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=
 "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an=
 email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgi=
d/bitcoindev/dc2cc46f-e697-4b14-91b3-34cf11de29a3n%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/1KbVdD952_XRfsKzMKaX-y4lrPOxYiknn8xXOMDQGt2Qz2fHFM-KoSplL-A_GRE1=
yuUkgNMeoEBHZiEDlMYwiqOiITFQTKEm5u1p1oVlL9I%3D%40protonmail.com.

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

<div style=3D"font-family: Arial, sans-serif; font-size: 14px;"><br></div>
        <div class=3D"protonmail_quote"><blockquote class=3D"protonmail_quo=
te" type=3D"cite">
            Hi Poinsot,</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 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 style=3D"font-family: Arial, sans-serif; font-size: 14px; c=
olor: rgb(0, 0, 0); background-color: rgb(255, 255, 255);"><br></div><br><b=
lockquote class=3D"protonmail_quote" type=3D"cite"><div>The only beneficial=
 case I can remember about the timewarp issue is "forwarding blocks" by maa=
ku for on-chain scaling:</div><div>http://freico.in/forward-blocks-scalingb=
itcoin-paper.pdf<br></div></blockquote><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-si=
ze: 14px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);">I wou=
ld not qualify this hack of "beneficial". Besides the centralization pressu=
re of an increased block frequency, leveraging the timewarp to achieve it w=
ould 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 lower fees by the increased block space, at t=
he expense of all users longer term. And every individual miner has an ince=
ntive to get more block reward at the expense of future miners. (And of cou=
rse bigger miners benefit from an increased block frequency.)<br></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><br><blockquote class=
=3D"protonmail_quote" type=3D"cite"><div>I think any consensus boundaries o=
n the minimal transaction size would need to be done carefully and have all=
 lightweight</div><div>clients update their own transaction acceptance logi=
c to enforce the check to avoid years-long transitory massive double-spend<=
/div><div>due to software incoordination.</div></blockquote><div style=3D"f=
ont-family: Arial, sans-serif; font-size: 14px; color: rgb(0, 0, 0); backgr=
ound-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(2=
55, 255, 255);">Note in my writeup i suggest we do not introduce a minimum =
transaction, but we instead only make 64 bytes transactions invalid. See <s=
pan><a target=3D"_blank" rel=3D"noreferrer nofollow noopener" href=3D"https=
://delvingbitcoin.org/t/great-consensus-cleanup-revival/710#can-we-come-up-=
with-a-better-fix-10">https://delvingbitcoin.org/t/great-consensus-cleanup-=
revival/710#can-we-come-up-with-a-better-fix-10</a></span>:</div><blockquot=
e 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; color: rgb(0, 0, 0); backg=
round-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">h=
is pull request to Bitcoin-inquisition</a>.</p></div></blockquote><div styl=
e=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><blockquote=
 class=3D"protonmail_quote" type=3D"cite"><div>I doubt `MIN_STANDARD_TX_NON=
_WITNESS_SIZE` is implemented correctly by all transaction-relay backends a=
nd it's a mess in this area.</div></blockquote><div style=3D"font-family: A=
rial, sans-serif; font-size: 14px; color: rgb(0, 0, 0); background-color: r=
gb(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)=
;">What type of backend are you referring to here? Bitcoin full nodes reimp=
lementations? These transactions have been non-standard in Bitcoin Core for=
 the past 6 years (commit <span>7485488e907e236133a016ba7064c89bf9ab6da3</s=
pan>).<br></div><div style=3D"font-family: Arial, sans-serif; font-size: 14=
px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);"><br></div><=
div><br></div><blockquote class=3D"protonmail_quote" type=3D"cite"><div>Qui=
d if we have  &lt; 64 bytes transaction where the only witness is enforced =
to be a minimal 1-byte</div><div>as witness elements are only used for high=
er layers protocols semantics  ?</div></blockquote><div style=3D"font-famil=
y: Arial, sans-serif; font-size: 14px; color: rgb(0, 0, 0); background-colo=
r: 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);">This restriction is on the size of the transaction serialized withou=
t witness. So this particular instance would not be affected and whatever t=
he witness is isn't relevant.<br></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-si=
ze: 14px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);"><br><=
/div><blockquote class=3D"protonmail_quote" type=3D"cite"><div>Making coinb=
ase unique by requesting the block height to be enforced in nLocktime, soun=
ds more robust to take a monotonic counter</div><div>in the past in case of=
 accidental or provoked shallow reorgs. I can see of you would have to re-c=
ompute a block template, loss a round-trip</div><div>compare to your mining=
 competitors. Better if it doesn't introduce a new DoS vector at mining job=
 distribution and control.</div></blockquote><div style=3D"font-family: Ari=
al, 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-serif; f=
ont-size: 14px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 255);"=
>Could you clarify? Are you suggesting something else than to set the nLock=
Time in the coinbase transaction to the height of the block? If so, what ex=
actly are you referring to by "monotonic counter in the past"?</div><div st=
yle=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-famil=
y: Arial, sans-serif; font-size: 14px; color: rgb(0, 0, 0); background-colo=
r: rgb(255, 255, 255);">At any rate in my writeup i suggested making the co=
inbase commitment mandatory (even when empty) instead for compatibility rea=
sons.</div><div style=3D"font-family: Arial, sans-serif; font-size: 14px; c=
olor: rgb(0, 0, 0); background-color: rgb(255, 255, 255);"><br></div><div s=
tyle=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 th=
is rule kick in in 25 years from now, we might want to just do the Obvious =
Thing and just require the height in nLockTime.<br></div><div style=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, s=
ans-serif; font-size: 14px; color: rgb(0, 0, 0); background-color: rgb(255,=
 255, 255);"><br></div><blockquote class=3D"protonmail_quote" type=3D"cite"=
>&nbsp;and b) it's already a lot of careful consensus<div>code to get right=
 :)</div></blockquote><div style=3D"font-family: Arial, sans-serif; font-si=
ze: 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);">Definitely. I just wan=
t to make sure we are not missing anything important if a soft fork gets pr=
oposed along these lines in the future.<br></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-seri=
f; font-size: 14px; color: rgb(0, 0, 0); background-color: rgb(255, 255, 25=
5);"><br></div><blockquote class=3D"protonmail_quote" type=3D"cite"><div>Be=
st,</div><div>Antoine</div><div><br></div><div class=3D"gmail_quote"><div c=
lass=3D"gmail_attr" dir=3D"auto">Le dimanche 24 mars 2024 =C3=A0 19:06:57 U=
TC, Antoine Poinsot a =C3=A9crit :<br></div><blockquote style=3D"margin: 0 =
0 0 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" c=
lass=3D"gmail_quote">Hey all,
<br>
<br>I've recently posted about the Great Consensus Cleanup there: <a data-s=
aferedirecturl=3D"https://www.google.com/url?hl=3Dfr&amp;q=3Dhttps://delvin=
gbitcoin.org/t/great-consensus-cleanup-revival/710&amp;source=3Dgmail&amp;u=
st=3D1711565663390000&amp;usg=3DAOvVaw0H-vWJQFB5_UBHVBwhQ1qE" rel=3D"norefe=
rrer nofollow noopener" target=3D"_blank" href=3D"https://delvingbitcoin.or=
g/t/great-consensus-cleanup-revival/710">https://delvingbitcoin.org/t/great=
-consensus-cleanup-revival/710</a>.
<br>
<br>I'm starting a thread on the mailing list as well to get comments and o=
pinions 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's more important to fix the timewarp bug than people usu=
ally 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't =
think there is a strong case for making less than 64 bytes transactions inv=
alid.
<br>
<br>Anything in there that people disagree with conceptually?
<br>Anything in there that people think shouldn't (or don't need to) be fix=
ed?
<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>

-- <br>
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" 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" rel=3D"n=
oreferrer nofollow noopener" target=3D"_blank">bitcoindev+unsubscribe@googl=
egroups.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">https://groups.=
google.com/d/msgid/bitcoindev/dc2cc46f-e697-4b14-91b3-34cf11de29a3n%40googl=
egroups.com</a>.<br>

        </blockquote><br>
    </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/1KbVdD952_XRfsKzMKaX-y4lrPOxYiknn8xXOMDQGt2Qz2fHFM-Ko=
SplL-A_GRE1yuUkgNMeoEBHZiEDlMYwiqOiITFQTKEm5u1p1oVlL9I%3D%40protonmail.com?=
utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/b=
itcoindev/1KbVdD952_XRfsKzMKaX-y4lrPOxYiknn8xXOMDQGt2Qz2fHFM-KoSplL-A_GRE1y=
uUkgNMeoEBHZiEDlMYwiqOiITFQTKEm5u1p1oVlL9I%3D%40protonmail.com</a>.<br />

--b1_u70ErIln1yHwbVljTNO079SNuKdPPACFp4808fxkfA--