Hi Fabian,<div><br /></div><div>Thanks for your feedback.<br /><br />&gt; 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.</div><div><br /></div><div>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.</div><div><br /></div><div>&gt; 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.</div><div><br /></div><div>Spam could be analyzed and filtered by different developers, users etc. in the discussion before flag day activation.</div><div><br /></div><div>&gt; Depending on whether the users pay high or low fees in these signaling transactions, they can choose their own adventure of misaligned incentives.</div><div><br /></div><div>I don't see a problem with users competing to pay more fees on-chain.</div><div><br /></div><div>&gt; 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.</div><div><br /></div><div>- Miners are not signaling support in this process</div><div>- Its easy for a mining pool to exclude these transactions in their blocks if they aren't ready for a soft fork</div><div>- Its a feature and not bug that miners leave some money on the table for signaling reluctance</div><div><br /></div><div>Signaling in this BIP or BIP 8/9 is just a coordination mechanism and miners can always false-signal. <br /></div><div><br /></div><div>&gt; 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.</div><div><br /></div><div>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.</div><div><br /></div><div>&gt; 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?</div><div><br /></div><div>Nobody is using BIP numbers in nLockTime for ordinals. There is a protocol which uses 21 and it won't affect this process. </div><div><br /></div><div>&gt; "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.<br /></div><div><br /></div><div>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.</div><div><br /></div><div>nLockTime signaling is to record the overall sentiment without social media debates.</div><div><br /></div><div>&gt; 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.</div><div><br /></div><div>Its not a misdirection because such things would be easy to identify in the analysis after 3 months.</div><div><br /></div><div>&gt; 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.</div><div><br /></div><div>- BIP 9 is controversial because it gives a small amount of hashpower veto power over any soft fork activation</div><div>- BIP 8 is controversial because there are lot disagreements whether LOT should be TRUE or FALSE</div><div><br /></div><div>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.</div><div><br /></div><div>&gt; Miners may "signal" by including high fee transactions even though they don't know about the process at all</div><div><br /></div><div>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.</div><div><br /></div><div>&gt; 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</div><div><br /></div><div>Users that are not involved in any economic activity on-chain can continue to discuss these proposals on social media.</div><div><br /></div><div>&gt; Spammers have many avenues today to exploit this mechanism at minimal cost, all of these loop holes would need to be closed/defended</div><div><br /></div><div>It is possible to differentiate spam from regular transactions and analysis by different developers after 3 months would make this easier.</div><div><br /></div><div>&gt; 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.</div><div><br /></div><div>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.<br /><br />Its neither a question nor the first time I am trying to improve BIP 8: <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020452.html">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-May/020452.html</a></div><div><br /></div><div>&gt; And please don't self-assign BIP numbers, it's irritating.</div><div><br /></div><div>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.</div><div><br /></div><div>/dev/fd0<br />floppy disk guy</div><div><br /></div><div class="gmail_quote"><div dir="auto" class="gmail_attr">On Monday, August 19, 2024 at 2:13:25 PM UTC Fabian wrote:<br/></div><blockquote class="gmail_quote" style="margin: 0 0 0 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div style="font-family:Arial,sans-serif;font-size:14px">Hi,</div><div style="font-family:Arial,sans-serif;font-size:14px"><br></div><div style="font-family:Arial,sans-serif;font-size:14px">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:</div><div style="font-family:Arial,sans-serif;font-size:14px"><br></div><div style="font-family:Arial,sans-serif;font-size:14px"><ul><li style="list-style-type:&quot;- &quot;"><span>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.</span></li><li style="list-style-type:&quot;- &quot;">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.</li><li style="list-style-type:&quot;- &quot;">Depending on whether the users pay high or low fees in these signaling transactions, they can choose their own adventure of misaligned incentives...</li><li style="list-style-type:&quot;- &quot;">If the users pay high fees in these transactions some miners that don&#39;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.</li><li style="list-style-type:&quot;- &quot;">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.</li><li style="list-style-type:&quot;- &quot;">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.</li><li style="list-style-type:&quot;- &quot;">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?</li><li style="list-style-type:&quot;- &quot;;font-family:system-ui,sans-serif">&quot;<span style="font-family:system-ui,sans-serif;text-align:start;display:inline!important">Community can analyze these transactions&quot; That won&#39;t work. </span>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&#39;s really not a lot of transactions that would need to get into blocks via one of the manipulation methods I mentioned above.</li><li style="list-style-type:&quot;- &quot;">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&#39;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&#39;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.</li><li style="list-style-type:&quot;- &quot;">I also don&#39;t think that the readiness signaling mechanism is actually the reason why bip8/9 are controversial so I don&#39;t think your proposal really would make things better even if the signaling part would work well.</li></ul><div><br></div><div>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&#39;t work:</div><div><ul><li style="list-style-type:&quot;- &quot;">Miners may &quot;signal&quot; by including high fee transactions even though they don&#39;t know about the process at all</li><li style="list-style-type:&quot;- &quot;">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</li><li style="list-style-type:&quot;- &quot;">Spammers have many avenues today to exploit this mechanism at minimal cost, all of these loop holes would need to be closed/defended</li></ul><div><br></div><div>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.</div><div><br></div><div>And please don&#39;t self-assign BIP numbers, it&#39;s irritating.</div><div><br></div></div><div>Best,</div><div>Fabian</div></div><div></div><div>
        On Monday, August 19th, 2024 at 7:08 AM, /dev /fd0 &lt;<a href data-email-masked rel="nofollow">alice...@gmail.com</a>&gt; wrote:<br>
        </div><div><blockquote type="cite">
            Hi Bitcoin Developers,<div><br></div><div>I am proposing an alternative way to activate soft forks. Please let me know if you see any issues with this method.<br><br>    BIP: XXX  <br>    Layer: Consensus (soft fork)  <br>    Title: nLockTime signaling and flag day activation<br>    Author: /dev/fd0 &lt;<a href data-email-masked rel="nofollow">alic...@protonmail.com</a>&gt;  <br>    Status: Draft  <br>    Type: Standards Track  <br>    Created: 2024-08-19  <br>    License: Public Domain<br><br>## Abstract<br><br>This document describes a process to activate soft forks using flag day after `nLockTime` signaling and discussion.<br><br>## Motivation<br><br>BIP 8 and BIP 9 are controversial. This BIP is an alternative which addresses the problems with other activation methods.<br><br>## Specification<br><br>- Assign numbers to different soft fork proposals or use their BIP numbers<br>- Users can broadcast their transactions with one of these numbers used as `nLockTime` to show support<br>- Miners inlcuding a transaction in block would signal readiness for a soft fork<br>- Community can analyze these transactions after 3 months and prepare for a flag day activation of soft fork<br><br>Example:<br>Use 119 to signal support for OP_CHECKTEMPLATEVERIFY in `nLockTime`<br><br>## Reference implementation<br><br>Activation: <a href="https://github.com/bitcoin/bitcoin/commit/ab91bf39b7c11e9c86bb2043c24f0f377f1cf514.diff" rel="noreferrer nofollow noopener" target="_blank" data-saferedirecturl="https://www.google.com/url?hl=en&amp;q=https://github.com/bitcoin/bitcoin/commit/ab91bf39b7c11e9c86bb2043c24f0f377f1cf514.diff&amp;source=gmail&amp;ust=1724171117177000&amp;usg=AOvVaw3vcJsH44fLkipoHnpKA5oB">https://github.com/bitcoin/bitcoin/commit/ab91bf39b7c11e9c86bb2043c24f0f377f1cf514.diff</a><br><br>Exclusion in relay or mining: <a href="https://github.com/bitcoinknots/bitcoin/commit/18cd7b0ef6eaeacd06678c6d192b6cacc9d7eee5.diff" rel="noreferrer nofollow noopener" target="_blank" data-saferedirecturl="https://www.google.com/url?hl=en&amp;q=https://github.com/bitcoinknots/bitcoin/commit/18cd7b0ef6eaeacd06678c6d192b6cacc9d7eee5.diff&amp;source=gmail&amp;ust=1724171117177000&amp;usg=AOvVaw2cJEsrLoWEG1E5kMhtCCmi">https://github.com/bitcoinknots/bitcoin/commit/18cd7b0ef6eaeacd06678c6d192b6cacc9d7eee5.diff</a><br><br>---<br><br>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`.<br><br>/dev/fd0<br>floppy disk guy</div>

<p></p></blockquote></div><div><blockquote type="cite">

-- <br>
You received this message because you are subscribed to the Google Groups &quot;Bitcoin Development Mailing List&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an email to <a href rel="noreferrer nofollow noopener" data-email-masked>bitcoindev+...@googlegroups.com</a>.<br>
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/bitcoindev/29d850d1-912a-4b15-ba41-cc36d05e7074n%40googlegroups.com" rel="noreferrer nofollow noopener" target="_blank" data-saferedirecturl="https://www.google.com/url?hl=en&amp;q=https://groups.google.com/d/msgid/bitcoindev/29d850d1-912a-4b15-ba41-cc36d05e7074n%2540googlegroups.com&amp;source=gmail&amp;ust=1724171117177000&amp;usg=AOvVaw1_a8ZAxF5KAE-np57m0b-z">https://groups.google.com/d/msgid/bitcoindev/29d850d1-912a-4b15-ba41-cc36d05e7074n%40googlegroups.com</a>.<br>

        </blockquote><br>
    </div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoindev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/bitcoindev/eeedc7ff-de37-4180-a657-116a5efcec98n%40googlegroups.com?utm_medium=email&utm_source=footer">https://groups.google.com/d/msgid/bitcoindev/eeedc7ff-de37-4180-a657-116a5efcec98n%40googlegroups.com</a>.<br />