Delivery-date: Wed, 21 Aug 2024 07:14:55 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of murch@murch.one designates 185.26.156.235 as permitted sender) client-ip=185.26.156.235;
Message-ID: <4de6a775-f9ed-44f0-bc93-7e74d64e36ad@murch.one>
Date: Tue, 20 Aug 2024 14:05:22 -0400
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [bitcoindev] BIP 8.5: Flag day activation based on nlocktime signaling
To: bitcoindev@googlegroups.com
References: <29d850d1-912a-4b15-ba41-cc36d05e7074n@googlegroups.com>
Content-Language: en-US
From: Murch <murch@murch.one>
In-Reply-To: <29d850d1-912a-4b15-ba41-cc36d05e7074n@googlegroups.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

Hello floppy and list,

On 8/19/24 01:08, /dev /fd0 wrote:
 > Hi Bitcoin Developers,
 >
 > I am proposing an alternative way to activate soft forks. Please let
 > me know if you see any issues with this method.

While your proposal may address some of the criticisms leveled at BIP=E2=80=
=AF8=20
and BIP=E2=80=AF9, it introduces new problems.

1. I appreciate that the signaling mechanism you propose would introduce=20
a cost to signaling. Unfortunately, this cost is unevenly distributed:=20
if you were going to make a transaction anyway, it=E2=80=99s free, but othe=
rwise=20
you would have to pay to get your signal out there. It may also lead to=20
a distortion of usage. Someone that may have sent a batched payments=20
transaction might consider splitting it into multiple separate=20
transactions instead to increase their signaling for a reduced cost=20
compared to making transactions just for signaling, but increased=20
blockspace demand compared to their batched payments transaction.

2. The `nLockTime` field is not unused. Transactions that have to set it=20
to make use of other protocol functions are inherently prevented from=20
signaling. Either way, it would be better to use the field for anti-fee=20
sniping, which also is not compatible with your signaling mechanism.

3. Most wallet software does not support setting the locktime manually,=20
so some users that might want to signal support cannot without switching=20
software.

4. This introduces a new fingerprint for transactions pertaining to=20
software that supports setting locktime manually.

5. A transaction can only set a single nLockTime value, so if there are=20
multiple proposals that are up for debate, a transaction can only signal=20
support for one. This could side-stepped by using nLockTime as a bit=20
array where each position signals support for one proposal, much like BIP=
=E2=80=AF9.

6. As already surfaced in your conversation with Fabian, it is up for=20
debate how the signaling data later would be interpreted. You mention=20
that spam could later be excluded, and blocks that include at least one=20
transaction that signals would be some sort of signal, but it=E2=80=99s unc=
lear=20
why one out of thousands of transactions should be relevant whatsoever.=20
Unless a very large portion of transactions signals support, I=E2=80=99m no=
t=20
sure what we would learn from this signal at all.

7. Your proposal does not allow distinguishing between apathy and=20
opposition: not signaling could mean either.

8. You suggest that miners could choose to exclude signaling=20
transactions if they are not ready, but it is much simpler for miners to=20
do nothing, so the inclusion of signaling transactions cannot be=20
interpreted as an endorsement.

Overall, this approach does not seem expedient to me, but should you=20
choose to maturate this proposal, I would suggest the following areas of=20
improvement:

- The proposal should address the questions brought up above and by=20
other responses
- The motivation should describe in more detail the existing issues that=20
are being addressed, and how this proposal mitigates them
- A rationale section should explain design choices, and put the=20
proposal into the context of alternate designs and related work
- A backwards compatibility section should address how implementers=20
should think about this proposal in the context of other uses of=20
nLockTime such as anti-fee sniping
- The specification should describe the syntax and semantics in=20
sufficient detail for other developers to implement the proposal

Cheers,

Murch

>=20
>      BIP: XXX
>      Layer: Consensus (soft fork)
>      Title: nLockTime signaling and flag day activation
>      Author: /dev/fd0 <alicexbt@protonmail.com>
>      Status: Draft
>      Type: Standards Track
>      Created: 2024-08-19
>      License: Public Domain
>=20
> ## Abstract
>=20
> This document describes a process to activate soft forks using flag day
> after `nLockTime` signaling and discussion.
>=20
> ## Motivation
>=20
> BIP 8 and BIP 9 are controversial. This BIP is an alternative which
> addresses the problems with other activation methods.
>=20
> ## Specification
>=20
> - Assign numbers to different soft fork proposals or use their BIP number=
s
> - Users can broadcast their transactions with one of these numbers used a=
s
> `nLockTime` to show support
> - Miners inlcuding a transaction in block would signal readiness for a so=
ft
> fork
> - Community can analyze these transactions after 3 months and prepare for=
 a
> flag day activation of soft fork
>=20
> Example:
> Use 119 to signal support for OP_CHECKTEMPLATEVERIFY in `nLockTime`
>=20
> ## Reference implementation
>=20
> Activation:
> https://github.com/bitcoin/bitcoin/commit/ab91bf39b7c11e9c86bb2043c24f0f3=
77f1cf514.diff
>=20
> Exclusion in relay or mining:
> https://github.com/bitcoinknots/bitcoin/commit/18cd7b0ef6eaeacd06678c6d19=
2b6cacc9d7eee5.diff
>=20
> ---
>=20
> If a transaction does not get included in block for a long time, users ca=
n
> replace it with another transaction spending same inputs and use a
> different `nLockTime`.
>=20
> /dev/fd0
> floppy disk guy
>=20

--=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/4de6a775-f9ed-44f0-bc93-7e74d64e36ad%40murch.one.