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

From: /dev /fd0 <[email-masked]>
Date: Thu, 22 Aug 2024 04:43:59 -0700 (PDT)

Hi Murch,

Thanks for reviewing the BIP draft and suggesting improvements.

>  I would suggest the following areas of
improvement

I have answered other responses and will reply to your feedback below. I 
will improve motivation section and add rationale, backwards compatibility, 
syntax etc. by first week of September.

>  I appreciate that the signaling mechanism you propose would introduce
a cost to signaling. 

This isn't the primary goal of the BIP but exists because bitcoin 
transactions require fees. Otherwise paid voting is possible on nostr using 
polls.

> 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.

The real signal we need to analyze after 3 months comes from users who 
participate in this signaling with transactions that were going to happen 
anyway. These are the users with some economic activity whose opinion 
matters the most for changes in consensus rules. 

> Someone that may have sent a batched payments transaction might consider 
splitting it into multiple separate transactions instead to increase their 
signaling

This depends on the analysis and I would give more weight to the batch 
payment using nLockTime for signaling.

> Either way, it would be better to use the field for anti-fee sniping, 
which also is not compatible with your signaling mechanism.

Lot of transactions use zero as nLockTime so signaling could work fine for 
at least next 12 years: 
https://blockchair.com/bitcoin/transactions?s=time(desc)&q=lock_time(0),time(2024-01-01..)#f=time,lock_time

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

This signaling is mainly targeting economic nodes and I think most of them 
would be able to do it. I will also create a website which can be used to 
enter unsigned PSBT and change its nLockTime.

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

I am not sure if this can be used to track anything meaningful which 
affects privacy.

> 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.

I like the idea of using bit array and I will update the draft accordingly.

> 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.

This depends on analysis and could be interpreted differently. Let me share 
an example:

Alice and Bob analyze these transactions after 3 months. Some blocks had 
only 1 transaction that signaled support for a soft fork proposal. Alice 
marked them red and don't consider helpful or at the bottom in analysis 
report. Bob looked at each transaction and considered some different from 
others. In a transaction, Bitfinex moved some bitcoin from hot wallet to 
cold storage so it was given some weight over others and marked with a 
different color.

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

I agree that proposal is focused on looking at support and not opposition. 
Still it could be visible if some nodes and miners try to reject these 
transactions. If someone really has a genuine problem with any of these 
soft forks, best way to share it would be a technical review, test etc. 
posted on mailing list.

> 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.

Miners never endorse any soft forks. Neither in this BIP nor BIP 8/9. 
Miners should always be ready for soft forks, but a coordination exercise 
before activation is always a safe approach in a decentralized network.

/dev/fd0
floppy disk guy

On Wednesday, August 21, 2024 at 2:14:48 PM UTC Murch wrote:

> 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/00e0601c-ed59-4245-a79d-0c36f1c8795bn%40googlegroups.com.