From: /dev /fd0 <alicexbtong@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] BIP 8.5: Flag day activation based on nlocktime signaling
Date: Thu, 22 Aug 2024 04:43:59 -0700 (PDT) [thread overview]
Message-ID: <00e0601c-ed59-4245-a79d-0c36f1c8795bn@googlegroups.com> (raw)
In-Reply-To: <4de6a775-f9ed-44f0-bc93-7e74d64e36ad@murch.one>
[-- Attachment #1.1: Type: text/plain, Size: 10124 bytes --]
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 <alic...@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/00e0601c-ed59-4245-a79d-0c36f1c8795bn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 12530 bytes --]
prev parent reply other threads:[~2024-08-22 12:57 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
2024-08-22 11:43 ` /dev /fd0 [this message]
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=00e0601c-ed59-4245-a79d-0c36f1c8795bn@googlegroups.com \
--to=alicexbtong@gmail$(echo .)com \
--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