* [bitcoindev] BIP 8.5: Flag day activation based on nlocktime signaling
@ 2024-08-19 5:08 /dev /fd0
2024-08-19 13:16 ` 'Fabian' via Bitcoin Development Mailing List
` (2 more replies)
0 siblings, 3 replies; 7+ messages in thread
From: /dev /fd0 @ 2024-08-19 5:08 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 1980 bytes --]
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.
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/29d850d1-912a-4b15-ba41-cc36d05e7074n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 2696 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoindev] BIP 8.5: Flag day activation based on nlocktime signaling
2024-08-19 5:08 [bitcoindev] BIP 8.5: Flag day activation based on nlocktime signaling /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-20 18:05 ` Murch
2 siblings, 1 reply; 7+ messages in thread
From: 'Fabian' via Bitcoin Development Mailing List @ 2024-08-19 13:16 UTC (permalink / raw)
To: /dev /fd0; +Cc: Bitcoin Development Mailing List
[-- Attachment #1: Type: text/plain, Size: 6791 bytes --]
Hi,
that would be a NACK from me. I think this idea has many issues, I am just listing the ones that came to my head first:
- Requiring users to make transactions in order to participate in order to signal is problematic because it comes with economic costs to them that depends a lot on their personal setup. What if they have their funds in a vault? Then they have to go through a lengthy and costly process to get them out. Or if they simply timelocked them for a number of years? Then they can not participate at all.
- Motivated spammers can, however, simulate support for low costs if they have the right setup. I would guess spammers have a few UTXOs laying around in hot wallets and would be willing to invest some money if it serves their interests.
- Depending on whether the users pay high or low fees in these signaling transactions, they can choose their own adventure of misaligned incentives...
- If the users pay high fees in these transactions some miners that don't care about this will just mine the transaction not because they want to signal but instead because it serves their economic interest. This means you would need buy-in from all miners (template builders) in the world for this to work on not get seemingly great signaling for these high fee transactions even though the miners just want to earn the fees and may not even know about a softfork proposal.
- If the miners pay low fees still all miners that offer out of band acceleration of transactions would need to buy-in and not allow these transactions to be boosted to prevent manipulation.
- The low fee transactions would still need to be kept in a mempool somewhere to prevent manipulation via eviction from mempools or the signaling transactions simply disappearing. Keeping a transaction in the mempool has many problems which is apparent from all the L2 research that is going into this topic.
- As far as I can tell there are some ordinal protocols that use the lock time field for something, how do you keep these two concepts apart?
- "Community can analyze these transactions" That won't work. What do you define as the lock-in mechanism? I suppose you would count the number of blocks that had at least one signaling transaction in them. Ok, that could work but that would mean that it's really not a lot of transactions that would need to get into blocks via one of the manipulation methods I mentioned above.
- Thinking more about the previous point: Users broadcasting their own transactions with signaling is really just an unnecessary misdirection. If a miner signals by including these transactions in a block it doesn't matter if they include one or 100 of these in a block. A block can just signal or not signal. So it would probably play out in a way that users wouldn't send any signaling transactions and miners would just include a single signaling self payment in their block template. Which then is just a worse way of doing the signaling with the version field.
- I also don't think that the readiness signaling mechanism is actually the reason why bip8/9 are controversial so I don't think your proposal really would make things better even if the signaling part would work well.
That was bit ramblin, so, to summarize the top 3 issues I could come up with off the top of my head why this wouldn't work:
- Miners may "signal" by including high fee transactions even though they don't know about the process at all
- Users (if they would even need/want to participate) would bare economic cost or may even have excluded themselves from the process already without knowing it
- Spammers have many avenues today to exploit this mechanism at minimal cost, all of these loop holes would need to be closed/defended
If you want to follow up please first take a look at the level of detail that BIP8 and BIP9 provide and try to get your proposal at least somewhere close to that level of detail if you want to have it taken serious as a BIP proposal. Otherwise, if this is just an idea or a question then maybe make it a Stack Exchange question or maybe a delving bitcoin post.
And please don't self-assign BIP numbers, it's irritating.
Best,
Fabian
On Monday, August 19th, 2024 at 7:08 AM, /dev /fd0 <alicexbtong@gmail•com> 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.
>
> 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/29d850d1-912a-4b15-ba41-cc36d05e7074n%40googlegroups.com.
--
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/KvOQPbOdGzE0_dViIN57KDCx8X-HdOLNKc8xM9y83vbyxVgujA1YI8MTzFsWV7wBIrQ8nBEzHxVhGt54H20t--FiRh3_iTvJeqqgaAOgZs0%3D%40protonmail.com.
[-- Attachment #2: Type: text/html, Size: 9339 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoindev] BIP 8.5: Flag day activation based on nlocktime signaling
2024-08-19 5:08 [bitcoindev] BIP 8.5: Flag day activation based on nlocktime signaling /dev /fd0
2024-08-19 13:16 ` 'Fabian' via Bitcoin Development Mailing List
@ 2024-08-19 13:22 ` David A. Harding
2024-08-19 17:50 ` /dev /fd0
2024-08-20 18:05 ` Murch
2 siblings, 1 reply; 7+ messages in thread
From: David A. Harding @ 2024-08-19 13:22 UTC (permalink / raw)
To: /dev /fd0; +Cc: Bitcoin Development Mailing List
On 2024-08-18 19:08, /dev /fd0 wrote:
> - Users can broadcast their transactions with one of these numbers
> used as `nLockTime` to show support
Variations on this idea have been proposed many times before; here's a
few I quickly found:
-
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014193.html
-
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014321.html
-
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020344.html
-
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-June/002729.html
I think it'd be useful if you could explain how your proposal
meaningfully differs from previous proposals.
-Dave
--
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/f3142cbfa94acd21e5fe9577b4e2fa9e%40dtrt.org.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoindev] BIP 8.5: Flag day activation based on nlocktime signaling
2024-08-19 13:16 ` 'Fabian' via Bitcoin Development Mailing List
@ 2024-08-19 17:50 ` /dev /fd0
0 siblings, 0 replies; 7+ messages in thread
From: /dev /fd0 @ 2024-08-19 17:50 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 14959 bytes --]
Hi Fabian,
Thanks for your feedback.
> Requiring users to make transactions in order to participate in order to
signal is problematic because it comes with economic costs to them that
depends a lot on their personal setup. What if they have their funds in a
vault? Then they have to go through a lengthy and costly process to get
them out. Or if they simply timelocked them for a number of years? Then
they can not participate at all.
I consider it a feature because users with 'economic activity' would be
participating in the process. This is better than social media wars. I am
sure users who hold bitcoin for long term would have some amount in hot
wallets for regular transactions. If not, they can always do transactions
to create another vault or add to existing vault.
> Motivated spammers can, however, simulate support for low costs if they
have the right setup. I would guess spammers have a few UTXOs laying around
in hot wallets and would be willing to invest some money if it serves their
interests.
Spam could be analyzed and filtered by different developers, users etc. in
the discussion before flag day activation.
> Depending on whether the users pay high or low fees in these signaling
transactions, they can choose their own adventure of misaligned incentives.
I don't see a problem with users competing to pay more fees on-chain.
> If the users pay high fees in these transactions some miners that don't
care about this will just mine the transaction not because they want to
signal but instead because it serves their economic interest. This means
you would need buy-in from all miners (template builders) in the world for
this to work on not get seemingly great signaling for these high fee
transactions even though the miners just want to earn the fees and may not
even know about a softfork proposal.
- Miners are not signaling support in this process
- Its easy for a mining pool to exclude these transactions in their blocks
if they aren't ready for a soft fork
- Its a feature and not bug that miners leave some money on the table for
signaling reluctance
Signaling in this BIP or BIP 8/9 is just a coordination mechanism and
miners can always false-signal.
> The low fee transactions would still need to be kept in a mempool
somewhere to prevent manipulation via eviction from mempools or the
signaling transactions simply disappearing. Keeping a transaction in the
mempool has many problems which is apparent from all the L2 research that
is going into this topic.
Bitcoin would work as expected and no change in mempool policies is
required for this process. Also, these can be everyday transactions and not
necessarily transactions done with the only purpose of signaling.
> As far as I can tell there are some ordinal protocols that use the lock
time field for something, how do you keep these two concepts apart?
Nobody is using BIP numbers in nLockTime for ordinals. There is a protocol
which uses 21 and it won't affect this process.
> "Community can analyze these transactions" That won't work. What do you
define as the lock-in mechanism? I suppose you would count the number of
blocks that had at least one signaling transaction in them. Ok, that could
work but that would mean that it's really not a lot of transactions that
would need to get into blocks via one of the manipulation methods I
mentioned above.
I am not sure which part won't work because blocks and transactions are
often analyzed by different developers, users etc. There is no lock-in
mechanism. Everyone would share their analysis after 3 months and it could
differ from each other. Number of blocks with at least one signaling
transaction is a good example. As with any other soft fork activation
discussion, these analysis would be evaluated together with technical
trade-offs to prepare for a flag day activation.
nLockTime signaling is to record the overall sentiment without social media
debates.
> Users broadcasting their own transactions with signaling is really just
an unnecessary misdirection. If a miner signals by including these
transactions in a block it doesn't matter if they include one or 100 of
these in a block. A block can just signal or not signal. So it would
probably play out in a way that users wouldn't send any signaling
transactions and miners would just include a single signaling self payment
in their block template. Which then is just a worse way of doing the
signaling with the version field.
Its not a misdirection because such things would be easy to identify in the
analysis after 3 months.
> I also don't think that the readiness signaling mechanism is actually the
reason why bip8/9 are controversial so I don't think your proposal really
would make things better even if the signaling part would work well.
- BIP 9 is controversial because it gives a small amount of hashpower veto
power over any soft fork activation
- BIP 8 is controversial because there are lot disagreements whether LOT
should be TRUE or FALSE
My proposal is flag day activation or UASF which requires economic nodes to
run the software to activate new consensus rules. nLockTime signaling is
only added to gather overall sentiment before moving forward, analyze and
discuss it which could help in coordination.
> Miners may "signal" by including high fee transactions even though they
don't know about the process at all
As I said earlier, miners are only required to be active and involved in
the process. They aren't voting for or against any soft fork in this
process. Steve Lee was able to contact most mining pools recently to make
them aware of the risks associated with non-standard transactions so I
think everyone would know the process if its used at some point.
> Users (if they would even need/want to participate) would bare economic
cost or may even have excluded themselves from the process already without
knowing it
Users that are not involved in any economic activity on-chain can continue
to discuss these proposals on social media.
> Spammers have many avenues today to exploit this mechanism at minimal
cost, all of these loop holes would need to be closed/defended
It is possible to differentiate spam from regular transactions and analysis
by different developers after 3 months would make this easier.
> If you want to follow up please first take a look at the level of detail
that BIP8 and BIP9 provide and try to get your proposal at least somewhere
close to that level of detail if you want to have it taken serious as a BIP
proposal. Otherwise, if this is just an idea or a question then maybe make
it a Stack Exchange question or maybe a delving bitcoin post.
The level of detail in this BIP draft is kept minimum to avoid unnecessary
complexity. I like simple things that can do the job. I have reviewed BIP
8, 9, 148 and others before writing this draft. Maybe I will add a FAQ
section and more details on the website that will be used for this BIP.
Its neither a question nor the first time I am trying to improve BIP 8:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020452.html
> And please don't self-assign BIP numbers, it's irritating.
BIP has "XXX" mentioned in the draft and 8.5 was the subject to convey the
idea is to get something between BIP 8 and BIP 9. Its irritating for me as
well that improvement proposals for a decentralized protocol need numbers
from a central authority to appease some developers, users etc.
/dev/fd0
floppy disk guy
On Monday, August 19, 2024 at 2:13:25 PM UTC Fabian wrote:
> Hi,
>
> that would be a NACK from me. I think this idea has many issues, I am just
> listing the ones that came to my head first:
>
>
> - Requiring users to make transactions in order to participate in
> order to signal is problematic because it comes with economic costs to them
> that depends a lot on their personal setup. What if they have their funds
> in a vault? Then they have to go through a lengthy and costly process to
> get them out. Or if they simply timelocked them for a number of years? Then
> they can not participate at all.
> - Motivated spammers can, however, simulate support for low costs if
> they have the right setup. I would guess spammers have a few UTXOs laying
> around in hot wallets and would be willing to invest some money if it
> serves their interests.
> - Depending on whether the users pay high or low fees in these
> signaling transactions, they can choose their own adventure of misaligned
> incentives...
> - If the users pay high fees in these transactions some miners that
> don't care about this will just mine the transaction not because they want
> to signal but instead because it serves their economic interest. This means
> you would need buy-in from all miners (template builders) in the world for
> this to work on not get seemingly great signaling for these high fee
> transactions even though the miners just want to earn the fees and may not
> even know about a softfork proposal.
> - If the miners pay low fees still all miners that offer out of band
> acceleration of transactions would need to buy-in and not allow these
> transactions to be boosted to prevent manipulation.
> - The low fee transactions would still need to be kept in a mempool
> somewhere to prevent manipulation via eviction from mempools or the
> signaling transactions simply disappearing. Keeping a transaction in the
> mempool has many problems which is apparent from all the L2 research that
> is going into this topic.
> - As far as I can tell there are some ordinal protocols that use the
> lock time field for something, how do you keep these two concepts apart?
> - "Community can analyze these transactions" That won't work. What do
> you define as the lock-in mechanism? I suppose you would count the number
> of blocks that had at least one signaling transaction in them. Ok, that
> could work but that would mean that it's really not a lot of transactions
> that would need to get into blocks via one of the manipulation methods I
> mentioned above.
> - Thinking more about the previous point: Users broadcasting their own
> transactions with signaling is really just an unnecessary misdirection. If
> a miner signals by including these transactions in a block it doesn't
> matter if they include one or 100 of these in a block. A block can just
> signal or not signal. So it would probably play out in a way that users
> wouldn't send any signaling transactions and miners would just include a
> single signaling self payment in their block template. Which then is just a
> worse way of doing the signaling with the version field.
> - I also don't think that the readiness signaling mechanism is
> actually the reason why bip8/9 are controversial so I don't think your
> proposal really would make things better even if the signaling part would
> work well.
>
>
> That was bit ramblin, so, to summarize the top 3 issues I could come up
> with off the top of my head why this wouldn't work:
>
> - Miners may "signal" by including high fee transactions even though
> they don't know about the process at all
> - Users (if they would even need/want to participate) would bare
> economic cost or may even have excluded themselves from the process already
> without knowing it
> - Spammers have many avenues today to exploit this mechanism at
> minimal cost, all of these loop holes would need to be closed/defended
>
>
> If you want to follow up please first take a look at the level of detail
> that BIP8 and BIP9 provide and try to get your proposal at least somewhere
> close to that level of detail if you want to have it taken serious as a BIP
> proposal. Otherwise, if this is just an idea or a question then maybe make
> it a Stack Exchange question or maybe a delving bitcoin post.
>
> And please don't self-assign BIP numbers, it's irritating.
>
> Best,
> Fabian
> On Monday, August 19th, 2024 at 7:08 AM, /dev /fd0 <alice...@gmail•com>
> 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.
>
> 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+...@googlegroups•com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/bitcoindev/29d850d1-912a-4b15-ba41-cc36d05e7074n%40googlegroups.com
> .
>
>
>
--
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/eeedc7ff-de37-4180-a657-116a5efcec98n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 18614 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoindev] BIP 8.5: Flag day activation based on nlocktime signaling
2024-08-19 13:22 ` David A. Harding
@ 2024-08-19 17:50 ` /dev /fd0
0 siblings, 0 replies; 7+ messages in thread
From: /dev /fd0 @ 2024-08-19 17:50 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- Attachment #1.1: Type: text/plain, Size: 1938 bytes --]
Hi Dave,
Below are the differences between proposed BIP and earlier proposals:
>
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014193.html
- It uses OP_RETURN
- It requires some percentage of tagged input addresses to reach a certain
level
>
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014321.html
- It requires soft fork and a new opcode OP_CHECKBLOCKVERSION
>
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020344.html
- It requires soft fork
>
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-June/002729.html
- It involves Proof-of-Stake voting based on UTXOs
/dev/fd0
floppy disk guy
On Monday, August 19, 2024 at 2:13:33 PM UTC David A. Harding wrote:
> On 2024-08-18 19:08, /dev /fd0 wrote:
> > - Users can broadcast their transactions with one of these numbers
> > used as `nLockTime` to show support
>
> Variations on this idea have been proposed many times before; here's a
> few I quickly found:
>
> -
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014193.html
>
> -
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014321.html
>
> -
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-April/020344.html
>
> -
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-June/002729.html
>
> I think it'd be useful if you could explain how your proposal
> meaningfully differs from previous proposals.
>
> -Dave
>
--
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/003b5d22-a3c6-403c-b56d-0b2f3aca1e2an%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 4417 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoindev] BIP 8.5: Flag day activation based on nlocktime signaling
2024-08-19 5:08 [bitcoindev] BIP 8.5: Flag day activation based on nlocktime signaling /dev /fd0
2024-08-19 13:16 ` 'Fabian' via Bitcoin Development Mailing List
2024-08-19 13:22 ` David A. Harding
@ 2024-08-20 18:05 ` Murch
2024-08-22 11:43 ` /dev /fd0
2 siblings, 1 reply; 7+ messages in thread
From: Murch @ 2024-08-20 18:05 UTC (permalink / raw)
To: bitcoindev
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [bitcoindev] BIP 8.5: Flag day activation based on nlocktime signaling
2024-08-20 18:05 ` Murch
@ 2024-08-22 11:43 ` /dev /fd0
0 siblings, 0 replies; 7+ messages in thread
From: /dev /fd0 @ 2024-08-22 11:43 UTC (permalink / raw)
To: Bitcoin Development Mailing List
[-- 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 --]
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2024-08-22 12:57 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-08-19 5:08 [bitcoindev] BIP 8.5: Flag day activation based on nlocktime signaling /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 is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox