path: root/f5/fbd2b134c6668badc48ce266d2d0652d7a717f

Delivery-date: Wed, 27 Mar 2024 12:18:41 -0700
Received: from mail-oo1-f61.google.com ([209.85.161.61])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBC3PT7FYWAMRBCPCSGYAMGQEZZSLKBY@googlegroups.com>)
	id 1rpYnI-0008Br-1h
	for bitcoindev@gnusha.org; Wed, 27 Mar 2024 12:18:41 -0700
Received: by mail-oo1-f61.google.com with SMTP id 006d021491bc7-5a553729aa5sf169661eaf.2
        for <bitcoindev@gnusha.org>; Wed, 27 Mar 2024 12:18:39 -0700 (PDT)
ARC-Seal: i=2; a=rsa-sha256; t=1711567114; cv=pass;
        d=google.com; s=arc-20160816;
        b=0cs5fIjI/asEWitIQEV+sePwTwaIX5wntsKpBNJcenw8dxAue47e1InPJXd+5I7uK0
         WPPeAYvQ+EmWp5xvsE24BzeVkqHjrhvQASx2sxlbS1KhxA8QNxEq/Hs7x9qCXsnfkAnp
         rYEIkStah9shj1tjZoGQA7FycoXuOnSQgH3WTxmyAEKOfT3mRld5IhnaKSVcQe+t0t3G
         2yujH1mPOq9KGiMzuWcwCYBJls4GNkoaD6Wg5XmFdEhK5xD5um0dPxFEJ9qktBWGCOhh
         U38q8Q5c8xHkb9Fri6RFM4JXBh1JFzyctmwsrg/jHBlVKP22m1TUOgjEgmnzWfCu0mYG
         5TMQ==
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:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:sender:dkim-signature
         :dkim-signature;
        bh=1Bq+zQriu1EFjuPVPJ7+MPIlLQTUexGBhzMwCnlkPwc=;
        fh=SpmzuplPY5WCzQCjxlQGoW0gh8/Fw0UdHTgnxgAwCY0=;
        b=TCJaZlSBwwziGcFTAqJJlyyN4C9FryXN1NO8xrRVtjynQr60YpAnShJemcOJMxg+ad
         5pZ3FuXyC34HAZfni3VBEmuS+hgaRqpWQTbjLag4hB5DQKFqgpl3SXkJfrkzvYk0HHM+
         Ed6EqH+9Mcqh5g1xhXXvhPkKGkZoE38nU+U5XMF2fae7HyHktUH5rRqeUxGDZ049UHmH
         7GBBOHRyyEWKLxz+RpSFuCcjT8BFOo3BIIf0hJkvWuzQRZObNDi6OZcxul2op2CyrUKL
         LJQ9QHHBLVIrUB074HKOt3b/2OghAOA8JAvfcV88Q+Py68D21f2gwblwexunPzd/Rhod
         U5Ug==;
        darn=gnusha.org
ARC-Authentication-Results: i=2; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=gUkX4kuL;
       spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::129 as permitted sender) smtp.mailfrom=antoine.riard@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1711567114; x=1712171914; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:sender:from:to:cc:subject:date:message-id
         :reply-to;
        bh=1Bq+zQriu1EFjuPVPJ7+MPIlLQTUexGBhzMwCnlkPwc=;
        b=aPi57fXDTwLK6Tizy1S2dhNfIiI9M3QEITYDbGPERXZUfWo7ifwAjcPZWrGBsNdSbZ
         jg/lUztD008NjxCO2F7wvKFI/LWa0nYbWV1yN+iQubXrrghVouH6x3i0etJYrXhCXBf6
         qf5zgQUzAZBF7EfttoZH01pSskYTItQEcGh+8DEeFgaFaAuc7JeChKnzNOcPKhwFxOff
         SHw/EoyYyavdcIorHLM3xYn80RCwk3PTDs1vASuADiKTG0PQLfdriCqnnIfCQKSg4Fov
         eUOP+Wrtq534OiOZXEK83cP1rmP9XwhPF+tyNPNHUK06bJbTngcXMHhOxzPzzfAcDKn1
         kNcA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1711567114; x=1712171914; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:from:to:cc:subject:date:message-id:reply-to;
        bh=1Bq+zQriu1EFjuPVPJ7+MPIlLQTUexGBhzMwCnlkPwc=;
        b=Qdm/UuIaAc6GsVLRfUvO04AVQPqp1rKB0rKmRd54MuU2CjO8S3r2aPKyiTwB0Wq7zG
         fRuGne4dAemsk/RpqgJUNZPiMHnY1frzwEZ+JZBdeXMDQfqYzWUNQxxMOLS6F1Tlj/e1
         7QVXqHsf5n4ARoIREYtxtlv53rV2396BwmlqwLJZib+ntQlyWViHtvPbyYnHC8scHWcf
         FVQb5gLDQp6sJWVi+SxU0RHMOp7yEzlGZhtWDRjcU6PWw1bdMeBzrrRHF0a6SsMADt1r
         2yfxDBCqSclKxwBGdERQR7zyGHTN3yTJOZ+maun9GiV1Ui2ZyDO6Oi5RI2x8t+o2MDL1
         mcNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1711567114; x=1712171914;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-authentication-results
         :x-original-sender:cc:to:subject:message-id:date:from:in-reply-to
         :references:mime-version:x-beenthere:x-gm-message-state:sender:from
         :to:cc:subject:date:message-id:reply-to;
        bh=1Bq+zQriu1EFjuPVPJ7+MPIlLQTUexGBhzMwCnlkPwc=;
        b=dNnRFavWa0q8Vha3e5eAiRkbQdmOfoaoG1AH+x3H0L+fg+1YlRb8fWZxfsQNNtQR3/
         wX7loJMvbfpr7fLk84sO9vqlUKyVWi4je7Ay0R/EyduIJqJIvMILrszY7wGyYw+prsm4
         hHxPOe6lDNyJLIZ+bB+m1ldYTDmjn0ENAz3WgfiGkreP/yIN+iIkNHzJY6rEjFE7bgZA
         pjFTbDTn4fHMVGVn0YqPL6qvWe1iBz9RclDTEYDrclAscM32O4+DuacqzbM3VAXbJOdk
         xlLQ0YJZrHYj3ilmt4aPOAHfxx1KaONuec/GMsHX4Nlu/bo1LSR0cCdjLjl0UannvFIy
         R3sg==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=2; AJvYcCVTfagLsqf0IhydLCFz6xht3viCTRIPxvoOcMYl6uWqOJ41C3xyMpepLA0S6PFmWRXJ1Hu9dw6lqU/MZcirY8qx/Tj7AI0=
X-Gm-Message-State: AOJu0YylOeMwcKugm9b7+KT8ghS1MYlcJAXhPGgPR5PR4tVZbMPzPXXT
	egv977A+gJs4PqfYBJhvfv3W+wSiSKZuk78XIELCI+EOspRwuv+R
X-Google-Smtp-Source: AGHT+IEFRfrGMUnI79YZMUi1cx58wX3LXYY17znjYbvqmLIv46QHUbw4d9tJkmu3vrtfLAjjU2iA9Q==
X-Received: by 2002:a05:6820:1522:b0:5a5:1fdc:8542 with SMTP id ay34-20020a056820152200b005a51fdc8542mr1285079oob.2.1711567113775;
        Wed, 27 Mar 2024 12:18:33 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com
Received: by 2002:a4a:4305:0:b0:5a4:8287:2eb7 with SMTP id k5-20020a4a4305000000b005a482872eb7ls60940ooj.1.-pod-prod-00-us;
 Wed, 27 Mar 2024 12:18:33 -0700 (PDT)
X-Received: by 2002:a05:6830:4876:b0:6e6:ec4a:7111 with SMTP id dx22-20020a056830487600b006e6ec4a7111mr2405otb.1.1711567112951;
        Wed, 27 Mar 2024 12:18:32 -0700 (PDT)
Received: by 2002:a05:6808:3098:b0:3c3:cc09:ef6d with SMTP id 5614622812f47-3c3de96a8ccmsb6e;
        Wed, 27 Mar 2024 11:58:05 -0700 (PDT)
X-Received: by 2002:a17:90b:1e0b:b0:2a0:3dc1:2926 with SMTP id pg11-20020a17090b1e0b00b002a03dc12926mr495077pjb.17.1711565883875;
        Wed, 27 Mar 2024 11:58:03 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; t=1711565883; cv=none;
        d=google.com; s=arc-20160816;
        b=HpQfHQSptp0Dp34lXjdrePWc6ILFT+3efHfJ0gSkb5dGBRZte7tHbgvI4G5PRdlBjk
         7129v4pinlamx/SKD4oiDpD+IxDAPW1eBMK1FHhAZzoLUnRsj3offVAO6QSA2xyi5iZp
         Oho7LL+ALYwHiYLMPHc6nxBmsW9oVv5KBcf7Ca1BUgd6eG+cMxXALOTfIlL76VMBk/Ds
         mqXoKAlZbjR1WQB7XcvH5EoJQs4yqdWY6SyuVyq2JaQZSQJiPV7hk14P7fNj05b4Q8Qz
         O8ZjBHDbj/59Tc/nf/RSCtesQ6uQURdc9/txJt23ga3Pfcz1deQYuThssx8O8QJV8VWr
         utIQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
        h=cc:to:subject:message-id:date:from:in-reply-to:references
         :mime-version:dkim-signature;
        bh=/GkjPQglahZrvIUyFqwIF0v59IHzsX0gJXfGOtrgfmg=;
        fh=m2IwlnuMmP6ceRgqI8U7RCh8Dkd3VeWlWEfxse0Wcvc=;
        b=BGzm+twInfYKQNMfCxjRkYlW0TFZGSyrFXd1zb8p+4sMUv5pZRe9gknK0X+F3xRvg0
         r3Jq2sd1D8XClGc+z94sxxPD4xNca7Rwc+KfRb1JrgsvjTpFx5DiHKt8WUpg4mT/77xu
         EREw/s/shDFvCHByb10sS6h090H3TKNRWHXfkuo4y+dUkM8tTLx+U4WKnUZArL2KAsz3
         cqudYzemH28AdfIFc3W6261df3CT6Lo+tCCJcXanGm27EC+K8XW0jIk6zUZ6840xCZ/1
         8jDPm/Ey2WNMllAzUKwBbtQFc5HV/YVsLcBOBFCf33uX8vOYnQo4+Azyqd3eo7SUeQI/
         8uQQ==;
        dara=google.com
ARC-Authentication-Results: i=1; gmr-mx.google.com;
       dkim=pass header.i=@gmail.com header.s=20230601 header.b=gUkX4kuL;
       spf=pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::129 as permitted sender) smtp.mailfrom=antoine.riard@gmail.com;
       dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com
Received: from mail-il1-x129.google.com (mail-il1-x129.google.com. [2607:f8b0:4864:20::129])
        by gmr-mx.google.com with ESMTPS id z22-20020a17090ad79600b002a1fa6b8725si95102pju.3.2024.03.27.11.58.03
        for <bitcoindev@googlegroups.com>
        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
        Wed, 27 Mar 2024 11:58:03 -0700 (PDT)
Received-SPF: pass (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::129 as permitted sender) client-ip=2607:f8b0:4864:20::129;
Received: by mail-il1-x129.google.com with SMTP id e9e14a558f8ab-368a97b31d1so364485ab.0
        for <bitcoindev@googlegroups.com>; Wed, 27 Mar 2024 11:58:03 -0700 (PDT)
X-Received: by 2002:a92:d486:0:b0:368:a474:4410 with SMTP id
 p6-20020a92d486000000b00368a4744410mr1037255ilg.2.1711565882969; Wed, 27 Mar
 2024 11:58:02 -0700 (PDT)
MIME-Version: 1.0
References: <gnM89sIQ7MhDgI62JciQEGy63DassEv7YZAMhj0IEuIo0EdnafykF6RH4OqjTTHIHsIoZvC2MnTUzJI7EfET4o-UQoD-XAQRDcct994VarE=@protonmail.com>
 <dc2cc46f-e697-4b14-91b3-34cf11de29a3n@googlegroups.com> <1KbVdD952_XRfsKzMKaX-y4lrPOxYiknn8xXOMDQGt2Qz2fHFM-KoSplL-A_GRE1yuUkgNMeoEBHZiEDlMYwiqOiITFQTKEm5u1p1oVlL9I=@protonmail.com>
In-Reply-To: <1KbVdD952_XRfsKzMKaX-y4lrPOxYiknn8xXOMDQGt2Qz2fHFM-KoSplL-A_GRE1yuUkgNMeoEBHZiEDlMYwiqOiITFQTKEm5u1p1oVlL9I=@protonmail.com>
From: Antoine Riard <antoine.riard@gmail.com>
Date: Wed, 27 Mar 2024 18:57:51 +0000
Message-ID: <CALZpt+GeEonE08V6tBoY0gsc1hj6r3y1yTUri_nCJ-=Lyq6jLA@mail.gmail.com>
Subject: Re: [bitcoindev] Re: Great Consensus Cleanup Revival
To: Antoine Poinsot <darosior@protonmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="00000000000076df030614a8fced"
X-Original-Sender: antoine.riard@gmail.com
X-Original-Authentication-Results: gmr-mx.google.com;       dkim=pass
 header.i=@gmail.com header.s=20230601 header.b=gUkX4kuL;       spf=pass
 (google.com: domain of antoine.riard@gmail.com designates 2607:f8b0:4864:20::129
 as permitted sender) smtp.mailfrom=antoine.riard@gmail.com;       dmarc=pass
 (p=NONE sp=QUARANTINE dis=NONE) header.from=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 (/)

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

Hi Darosior,

> I would not qualify this hack of "beneficial". Besides the centralization
pressure of an increased block frequency, 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 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 of course bigger miners benefit from an increased
block frequency.)

I'm not saying the hack is beneficial either. The "forward block" paper is
just good to provide more context around timewarp.

> Note in my writeup i suggest we do not introduce a minimum transaction,
but we instead only make 64 bytes transactions invalid

I think it's easier for the sake of analysis.
See this mailing list issue for 60-byte example transaction use-case:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-May/017883.htm=
l
Only I'm aware of to the best of my knowledge.

> What type of backend are you referring to here?

I can't find where `MIN_STANDARD_TX_NON_WITNESS_SIZE` is checked in btcd's
`maybeAcceptTransaction()`.

> This restriction is on the size of the transaction serialized without
witness.

Oky.

> Could you clarify? Are you suggesting something else than to set the
nLockTime in the coinbase transaction to the height of the block? If so,
what exactly are you referring to by "monotonic counter in the past"?

Thinking more, I believe it's okay to use the nLocktime in the coinbase
transaction, as the wtxid of the coinbase is assumed to be 0x00.
To be checked if it doesn't break anything w.rt Stratum V2 / mining job
distribution.

Best,
Antoine












Le mer. 27 mars 2024 =C3=A0 10:36, Antoine Poinsot <darosior@protonmail.com=
> a
=C3=A9crit :

>
> Hi Poinsot,
>
>
> Hi Riard,
>
>
> The only beneficial case I can remember about the timewarp issue is
> "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
> pressure of an increased block frequency, leveraging the timewarp to
> achieve it would put the network constantly on the Brink of being serious=
ly
> (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 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 of course bigger miners benefit from an increased
> block frequency.)
>
>
> I think any consensus boundaries on the minimal transaction size would
> need 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://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
> invalid. Although they are of no (or little) use, such transactions are n=
ot
> harmful. I believe considering a type of transaction useless is not
> sufficient motivation for making them invalid through a soft fork.
>
> Making (exactly) 64 bytes long transactions invalid is also what AJ
> implemented in his pull request to Bitcoin-inquisition
> <https://github.com/bitcoin-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
> reimplementations? These transactions have been non-standard in Bitcoin
> Core for the past 6 years (commit 7485488e907e236133a016ba7064c89bf9ab6da=
3
> ).
>
>
> 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
> witness. So this particular instance would not be affected and whatever t=
he
> witness is isn't relevant.
>
>
> Making coinbase unique by requesting the block height to be enforced in
> 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
> 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
> nLockTime in the coinbase transaction to the height of the block? If so,
> what exactly are you referring to by "monotonic counter in the past"?
>
> At any rate in my writeup i suggested making the coinbase commitment
> mandatory (even when empty) instead for compatibility reasons.
>
> That said, since we could make this rule kick in in 25 years from now, we
> might want to just do the Obvious Thing and just require the height in
> 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
> 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://delvingbitcoin.org/t/great-consensus-cleanup-revival/710.
>>
>> I'm starting a thread on the mailing list as well to get comments and
>> opinions 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
>> maximum 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 unique
>> once and for all, to avoid having to resort back to doing BIP30 validati=
on
>> after block 1,983,702;
>> - 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
>> 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
> "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/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/CALZpt%2BGeEonE08V6tBoY0gsc1hj6r3y1yTUri_nCJ-%3DLyq6jLA%40mail.g=
mail.com.

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

<div dir=3D"ltr">Hi Darosior,<div><br></div><div>&gt;=C2=A0<span style=3D"c=
olor:rgb(0,0,0);font-family:Arial,sans-serif;font-size:14px">I would not qu=
alify this hack of &quot;beneficial&quot;. Besides the centralization press=
ure of an increased block frequency, 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 lower fees by the increased block space, at =
the expense of all users longer term. And every individual miner has an inc=
entive to get more block reward at the expense of future miners. (And of co=
urse bigger miners benefit from an increased block frequency.)</span></div>=
<div><span style=3D"color:rgb(0,0,0);font-family:Arial,sans-serif;font-size=
:14px"><br></span></div><div><span style=3D"color:rgb(0,0,0);font-family:Ar=
ial,sans-serif">I&#39;m not saying the hack is beneficial either. The &quot=
;forward block&quot; paper is just good to provide more context around time=
warp.</span></div><div><span style=3D"color:rgb(0,0,0);font-family:Arial,sa=
ns-serif"><br></span></div><div><span style=3D"color:rgb(0,0,0);font-family=
:Arial,sans-serif">&gt;=C2=A0</span><span style=3D"color:rgb(0,0,0);font-fa=
mily:Arial,sans-serif;font-size:14px">Note in my writeup i suggest we do no=
t introduce a minimum transaction, but we instead only make 64 bytes transa=
ctions invalid</span></div><div><span style=3D"color:rgb(0,0,0);font-family=
:Arial,sans-serif;font-size:14px"><br></span></div><div><span style=3D"colo=
r:rgb(0,0,0);font-family:Arial,sans-serif">I think it&#39;s easier for the =
sake of analysis.</span></div><div><span style=3D"color:rgb(0,0,0);font-fam=
ily:Arial,sans-serif">See this mailing list issue for 60-byte example trans=
action use-case:=C2=A0</span><a href=3D"https://lists.linuxfoundation.org/p=
ipermail/bitcoin-dev/2020-May/017883.html">https://lists.linuxfoundation.or=
g/pipermail/bitcoin-dev/2020-May/017883.html</a></div><div>Only I&#39;m awa=
re of to the best of my knowledge.</div><div><br></div><div>&gt;=C2=A0<span=
 style=3D"color:rgb(0,0,0);font-family:Arial,sans-serif;font-size:14px">Wha=
t type of backend are you referring to here?</span></div><div><br></div><di=
v><font color=3D"#000000" face=3D"Arial, sans-serif"><span style=3D"caret-c=
olor: rgb(0, 0, 0);">I can&#39;t find where `MIN_STANDARD_TX_NON_WITNESS_SI=
ZE` is checked in btcd&#39;s `maybeAcceptTransaction()`.</span></font></div=
><div><font color=3D"#000000" face=3D"Arial, sans-serif"><span style=3D"car=
et-color: rgb(0, 0, 0);"><br></span></font></div><div><font color=3D"#00000=
0" face=3D"Arial, sans-serif"><span style=3D"caret-color: rgb(0, 0, 0);">&g=
t;=C2=A0</span></font><span style=3D"color:rgb(0,0,0);font-family:Arial,san=
s-serif;font-size:14px">This restriction is on the size of the transaction =
serialized without witness.</span><span class=3D"gmail-Apple-converted-spac=
e" style=3D"color:rgb(0,0,0);font-family:Arial,sans-serif;font-size:14px">=
=C2=A0</span></div><div><span class=3D"gmail-Apple-converted-space" style=
=3D"color:rgb(0,0,0);font-family:Arial,sans-serif;font-size:14px"><br></spa=
n></div><div><span class=3D"gmail-Apple-converted-space" style=3D"color:rgb=
(0,0,0);font-family:Arial,sans-serif">Oky.</span></div><div><span class=3D"=
gmail-Apple-converted-space" style=3D"color:rgb(0,0,0);font-family:Arial,sa=
ns-serif"><br></span></div><div><span class=3D"gmail-Apple-converted-space"=
 style=3D"color:rgb(0,0,0);font-family:Arial,sans-serif"><span style=3D"fon=
t-size:14px">&gt; Could you clarify? Are you suggesting something else than=
 to set the nLockTime in the coinbase transaction to the height of the bloc=
k? If so, what exactly are you referring to by &quot;monotonic counter in t=
he past&quot;?</span><br></span></div><div><span class=3D"gmail-Apple-conve=
rted-space" style=3D"color:rgb(0,0,0);font-family:Arial,sans-serif;font-siz=
e:14px"><br></span></div><div><span class=3D"gmail-Apple-converted-space" s=
tyle=3D"color:rgb(0,0,0);font-family:Arial,sans-serif">Thinking more, I bel=
ieve it&#39;s okay to use the nLocktime=C2=A0in the coinbase transaction, a=
s the wtxid of the coinbase is assumed to be 0x00.</span></div><div>To be c=
hecked if it doesn&#39;t break anything w.rt Stratum V2 / mining job distri=
bution.</div><div><br></div><div>Best,</div><div>Antoine</div><div><font co=
lor=3D"#000000" face=3D"Arial, sans-serif"><span style=3D"font-size:14px"><=
br></span></font></div><div><font color=3D"#000000" face=3D"Arial, sans-ser=
if"><span style=3D"caret-color: rgb(0, 0, 0);"><br></span></font></div><div=
><font color=3D"#000000" face=3D"Arial, sans-serif"><span style=3D"caret-co=
lor: rgb(0, 0, 0);"><br></span></font></div><div><font color=3D"#000000" fa=
ce=3D"Arial, sans-serif"><span style=3D"caret-color: rgb(0, 0, 0);"><br></s=
pan></font></div><div><font color=3D"#000000" face=3D"Arial, sans-serif"><s=
pan style=3D"caret-color: rgb(0, 0, 0);"><br></span></font></div><div><span=
 style=3D"color:rgb(0,0,0);font-family:Arial,sans-serif"><br></span></div><=
div><span style=3D"color:rgb(0,0,0);font-family:Arial,sans-serif"><br></spa=
n></div><div><span style=3D"color:rgb(0,0,0);font-family:Arial,sans-serif">=
<br></span></div><div><span style=3D"color:rgb(0,0,0);font-family:Arial,san=
s-serif"><br></span></div><div><span style=3D"color:rgb(0,0,0);font-family:=
Arial,sans-serif">=C2=A0=C2=A0</span></div><div><br></div></div><br><div cl=
ass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Le=C2=A0mer. 27 m=
ars 2024 =C3=A0=C2=A010:36, Antoine Poinsot &lt;<a href=3D"mailto:darosior@=
protonmail.com">darosior@protonmail.com</a>&gt; a =C3=A9crit=C2=A0:<br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204)=
;padding-left:1ex"><div style=3D"font-family:Arial,sans-serif;font-size:14p=
x"><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 style=3D"f=
ont-family:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);background-colo=
r:rgb(255,255,255)"><br></div><br><blockquote type=3D"cite"><div>The only b=
eneficial 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://fre=
ico.in/forward-blocks-scalingbitcoin-paper.pdf" target=3D"_blank">http://fr=
eico.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);b=
ackground-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,25=
5)">I would not qualify this hack of &quot;beneficial&quot;. Besides the ce=
ntralization pressure of an increased block frequency, leveraging the timew=
arp to achieve it would put the network constantly on the Brink of being se=
riously (fatally?) harmed. And this sets pernicious incentives too. Every i=
ndividual user has a short-term incentive to get lower fees by the increase=
d block space, at the expense of all users longer term. And every individua=
l miner has an incentive to get more block reward at the expense of future =
miners. (And of course bigger miners benefit from an increased block freque=
ncy.)<br></div><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><br><blockquote=
 type=3D"cite"><div>I think any consensus boundaries on the minimal transac=
tion size would need to be done carefully and have all lightweight</div><di=
v>clients update their own transaction acceptance logic to enforce the chec=
k to avoid years-long transitory massive double-spend</div><div>due to soft=
ware incoordination.</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 style=3D"font-family:Arial,sans-serif;font-size:14px;color:rg=
b(0,0,0);background-color:rgb(255,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 <span><a rel=3D"noreferrer nofollow noopener" hre=
f=3D"https://delvingbitcoin.org/t/great-consensus-cleanup-revival/710#can-w=
e-come-up-with-a-better-fix-10" target=3D"_blank">https://delvingbitcoin.or=
g/t/great-consensus-cleanup-revival/710#can-we-come-up-with-a-better-fix-10=
</a></span>:</div><blockquote style=3D"border-color:rgb(200,200,200);border=
-left-width:3px;border-left-style:solid;padding-left:10px;color:rgb(102,102=
,102)"><div style=3D"font-family:Arial,sans-serif;font-size:14px;color:rgb(=
0,0,0);background-color:rgb(255,255,255)"><p>However the BIP proposes to al=
so 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">his pull request to Bitcoin-inquisition</a>.</p></div></bl=
ockquote><div style=3D"font-family:Arial,sans-serif;font-size:14px;color:rg=
b(0,0,0);background-color:rgb(255,255,255)"><br></div><div><br></div><block=
quote type=3D"cite"><div>I doubt `MIN_STANDARD_TX_NON_WITNESS_SIZE` is impl=
emented correctly by all transaction-relay backends and it&#39;s a mess in =
this area.</div></blockquote><div style=3D"font-family:Arial,sans-serif;fon=
t-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);b=
ackground-color:rgb(255,255,255)">What type of backend are you referring to=
 here? Bitcoin full nodes reimplementations? These transactions have been n=
on-standard in Bitcoin Core for the past 6 years (commit <span>7485488e907e=
236133a016ba7064c89bf9ab6da3</span>).<br></div><div style=3D"font-family:Ar=
ial,sans-serif;font-size:14px;color:rgb(0,0,0);background-color:rgb(255,255=
,255)"><br></div><div><br></div><blockquote type=3D"cite"><div>Quid if we h=
ave  &lt; 64 bytes transaction where the only witness is enforced to be a m=
inimal 1-byte</div><div>as witness elements are only used for higher layers=
 protocols semantics  ?</div></blockquote><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><div style=3D"font-family:Arial,sans-serif;font-size:14px;color=
:rgb(0,0,0);background-color:rgb(255,255,255)">This restriction is on the s=
ize of the transaction serialized without witness. So this particular insta=
nce would not be affected and whatever the witness is isn&#39;t relevant.<b=
r></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-fam=
ily:Arial,sans-serif;font-size:14px;color:rgb(0,0,0);background-color:rgb(2=
55,255,255)"><br></div><blockquote type=3D"cite"><div>Making coinbase uniqu=
e by requesting the block height to be enforced in nLocktime, sounds more r=
obust to take a monotonic counter</div><div>in the past in case of accident=
al or provoked shallow reorgs. I can see of you would have to re-compute a =
block template, loss a round-trip</div><div>compare to your mining competit=
ors. Better if it doesn&#39;t introduce a new DoS vector at mining job dist=
ribution and control.</div></blockquote><div style=3D"font-family:Arial,san=
s-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:r=
gb(0,0,0);background-color:rgb(255,255,255)">Could you clarify? Are you sug=
gesting something else than to set the nLockTime in the coinbase transactio=
n to the height of the block? If so, what exactly are you referring to by &=
quot;monotonic counter in the past&quot;?</div><div style=3D"font-family:Ar=
ial,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)">At any rate in my write=
up i suggested making the coinbase commitment mandatory (even when empty) i=
nstead 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></div><div style=3D"font-family:Arial,sans-serif;font-size:14px;color:rg=
b(0,0,0);background-color:rgb(255,255,255)">That said, since we could make =
this rule kick in in 25 years from now, we might want to just do the Obviou=
s Thing and just require the height in nLockTime.<br></div><div style=3D"fo=
nt-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;fon=
t-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 careful con=
sensus<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:rgb(255,=
255,255)"><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)">Definitely. I just w=
ant to make sure we are not missing anything important if a soft fork gets =
proposed along these lines in the future.<br></div><div style=3D"font-famil=
y: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:1=
4px;color:rgb(0,0,0);background-color:rgb(255,255,255)"><br></div><blockquo=
te type=3D"cite"><div>Best,</div><div>Antoine</div><div><br></div><div clas=
s=3D"gmail_quote"><div class=3D"gmail_attr" dir=3D"auto">Le dimanche 24 mar=
s 2024 =C3=A0 19:06:57 UTC, Antoine Poinsot a =C3=A9crit :<br></div><blockq=
uote style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-st=
yle:solid;border-left-color:rgb(204,204,204);padding-left:1ex" class=3D"gma=
il_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">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>

-- <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" 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></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/CALZpt%2BGeEonE08V6tBoY0gsc1hj6r3y1yTUri_nCJ-%3DLyq6j=
LA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.=
google.com/d/msgid/bitcoindev/CALZpt%2BGeEonE08V6tBoY0gsc1hj6r3y1yTUri_nCJ-=
%3DLyq6jLA%40mail.gmail.com</a>.<br />

--00000000000076df030614a8fced--