Published on: 2015-09-18T01:21:19+00:00
In a discussion on the bitcoin-dev mailing list, Mark Friedenbach proposed changing the rules regarding sequence numbers in Bitcoin transactions. He created two new repositories, one of which inverts the sequence number and interprets it as a fixed-point number, allowing for up to five-year relative lock times using blocks or up to approximately two-year relative lock times using seconds. The other repository inverts the sequence number with nSequence=1 meaning one block relative lock-height and nSequence=LOCKTIME_THRESHOLD meaning one second relative lock-height. Friedenbach also discussed the maximum time required for relative lock-times, suggesting a maximum of one year. He questioned whether there are any use cases that would require more than a year of lock time.Rusty Russell agreed with Friedenbach's suggestion and emphasized simplicity. He mentioned that reserving the remaining half of the number space for future purposes and leaving the top two bits for those who are paranoid would be a good approach.Eric Lombrozo commented that he would prefer replacing the entire nSequence field with an explicit relative lock-time with clear semantics.Gregory Maxwell suggested representing one block with more than one increment to leave additional space for future signaling or allow higher resolution numbers for a share chain commitment.In another discussion, Rusty Russell proposed an IsStandard() rule that would ensure nSequence is either 0xFFFFFFFF or 0 to avoid issues with soft forks. However, it was pointed out that this rule is not necessary since BIP68 is not active for version 1 transactions and no existing wallets would be affected.There was also a discussion on transaction finality and the proposal code named BIP112. It was suggested to use the "sequence" field instead of the "version" field, as it is associated with transaction finality. It was also mentioned that chaining transactions and extending the relative locktime could be a way to delay confirmation in cases where the clock start is uncertain.Overall, the discussions revolved around improving sequence numbers and relative lock-times in Bitcoin transactions, considering different use cases and future implications.In a discussion on the bitcoin-dev mailing list, Gregory Maxwell proposed the idea of representing one block with more than one increment, which would provide additional space for future signaling or higher resolution numbers for a sharechain commitment. However, there had been no prior discussion of this idea. Another participant in the thread suggested using 600 increments to make it more similar to timestamps. The discussion also touched on the inversion of nSequence and preserving existing semantics in Bitcoin transactions.Tom Harding posted a message regarding an idea for preserving existing semantics in a Bitcoin transaction, but another member requested clarification as they couldn't follow the logic. Mark Friedenbach expressed his indifference towards the issue of bit inversion and explained that he implemented it to preserve existing semantics, even if they were not commonly used. Jorge Timón raised an issue with this implementation on GitHub, and a pull request for the opcode CHECKSEQUENCEVERIFY in Bitcoin Core was announced.Joseph Poon and Mark Friedenbach discussed the inversion of nSequence in mempool transaction selection via email. Poon mentioned his indifference to the issue but expressed concern about technical debt and noted that transactions with shorter relative locks have higher priority. The group ultimately agreed to remove the inversion for ease of use and mental calculation.The bitcoin-dev community engaged in a discussion regarding a proposed change to the Bitcoin Improvement Proposals. The proposal involved changing how transactions are selected in the mempool to prioritize those with shorter relative locks. Some developers were indifferent to the issue, while others expressed concern over technical debt. Joseph Poon suggested noting the information for those who wish to write code for mempool transaction selection, regardless of their opinion.Btc Drak provided an update on the bitcoin-dev mailing list regarding a new pull request for the opcode CHECKSEQUENCEVERIFY in Bitcoin Core. The pull request can be found on Github, labeled as pull request number 179. Another pull request for a BIP was also submitted and can be found on Github, labeled as pull request number 6564.The writer expressed their displeasure towards the inversion of nSequence to preserve existing semantics. They argued that these semantics were not enforceable by consensus and suggested using nMaturity instead. The writer emphasized the importance of moving forward without technical debt and believed that clearer documentation could be achieved through this decision.The context discussed the assumed malleability-fix CHECKSIG2 version of lightning, which allows for outsourcing monitoring and response to bad behavior. It was noted that this requires users' wallets to be online. The proposal also mentioned the need for mitigations against a systemic supervillain attack but did not include provisions for it. The scenario of a hub turning evil and cheating its users out of their bonds was discussed, along with potential ways to protect against such behavior.
Updated on: 2023-08-01T15:11:20.666401+00:00