Subject: Re: [bitcoindev] BIP 8.5: Flag day activation based on nlocktime signaling

From: Murch <[email-masked]>
Date: Tue, 20 Aug 2024 14:05:22 -0400

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 8 
and BIP 9, it introduces new problems.

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

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

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

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

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

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

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

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

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

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

Cheers,

Murch

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

-- 
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 [email-masked].
To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/4de6a775-f9ed-44f0-bc93-7e74d64e36ad%40murch.one.