From: Murch <murch@murch•one>
To: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] BIP 8.5: Flag day activation based on nlocktime signaling
Date: Tue, 20 Aug 2024 14:05:22 -0400 [thread overview]
Message-ID: <4de6a775-f9ed-44f0-bc93-7e74d64e36ad@murch.one> (raw)
In-Reply-To: <29d850d1-912a-4b15-ba41-cc36d05e7074n@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 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 <alicexbt@protonmail•com>
> 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 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.
next prev parent reply other threads:[~2024-08-21 14:14 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-19 5:08 /dev /fd0
2024-08-19 13:16 ` 'Fabian' via Bitcoin Development Mailing List
2024-08-19 17:50 ` /dev /fd0
2024-08-19 13:22 ` David A. Harding
2024-08-19 17:50 ` /dev /fd0
2024-08-20 18:05 ` Murch [this message]
2024-08-22 11:43 ` /dev /fd0
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4de6a775-f9ed-44f0-bc93-7e74d64e36ad@murch.one \
--to=murch@murch$(echo .)one \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox