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