Published on: 2017-05-10T01:19:30+00:00
A proposal has been made for an extension block that would allow atomic swaps between Bitcoin and Xbitcoin. However, there are concerns about the maturity rule and its impact on legacy wallets. Christopher Jeffrey suggests revising the extension block code to coexist with mainchain segwit and require exiting outputs to only be witness programs. This would mitigate the issue assuming most segwit-supporting wallets implement this rule before the activation of segwit.There is also discussion about allowing direct exit payments to legacy addresses and the lock-up period for exiting outputs. One solution is to add a maturity requirement for exiting outputs, but this would make non-upgraded wallets unusable. Another solution is to move all exiting outputs to the coinbase, but this would deteriorate user experience and essentially become a hardfork. It is suggested that switching to witness programs only and requiring exiting outputs to be witness programs may be a good balance between fungibility and backward-compatibility.The proposal also addresses the issue of making return outputs transparent to unupgraded wallets. The proposed solution is to send them to something non-standard today. The mainchain segwit is important in enabling atomic swaps between Bitcoin and Xbitcoin. The extension block specification/code is being revised to coexist with mainchain segwit and require exiting outputs to only be witness programs.In another discussion, Olaoluwa Osuntokun analyzes the xblock proposal and focuses on the sub-proposal for Lightning Network (LN) safety enhancement. The proposal involves a block-size decrease for each open channel within the network, which reserves space for honest parties to punish dishonest channel counter parties. There is also a proposal for a Pre-Allocated Smart-contract Dispute Arena (PASDA) to address systematic risks in the LN. However, the system has not been fully specified and evaluated yet.Overall, the discussions revolve around the proposed extension block, its compatibility with segwit, the issue of direct exit payments to legacy addresses, and the need for a balance between fungibility and backward-compatibility. The proposal also introduces additional safety measures for Lightning Network (LN) and blockchain availability in case of channel disputes.The writer of the context raises concerns about a new Bitcoin Improvement Proposal (BIP) and expresses disappointment that their proposal was not given more consideration. They criticize the lack of specificity in the proposed approach to resolving transaction malleability and suggest changes to how the merkle root is calculated. Additionally, they question whether direct exit payment to legacy addresses should be allowed and propose limiting the number of soft-fork upgrades, increasing the points for witness v0 outputs, and setting a higher dust threshold.A work-in-progress extension block proposal has been introduced by Christopher Jeffrey, Joseph Poon, Fedor Indutny, and Steven Pair. The proposal is available on Github and aims to increase bitcoin transaction throughput without altering existing consensus rules. However, the writer argues that extension blocks create additional complexity compared to other proposals and can potentially create two classes of "full nodes," leaving some insecure. They also mention potential issues with the maximum extension size and the validity of output script code in extension blocks.The Witness Vector specification details that every 73 bytes in the serialized witness vector is worth one additional point, but it doesn't explain why this number was chosen. The writer emphasizes the importance of submitting BIPs in MediaWiki format and for discussion on the bitcoin-dev mailing list rather than social media and news outlets. They assert that extension blocks are more like a hard-fork rather than a soft-fork and highlight the potential legal implications of BIPs not being recognized in certain jurisdictions.The UTXO set behaves fundamentally differently with the extension block proposal, but mostly in a compatible manner. Canonical blocks containing entering outputs must have an extension block commitment, even if it contains all zeroes. The writer suggests adding a special message to the genesis resolution transaction and mentions the possibility of including a witness vector using BIP141 transaction serialization within the extended transaction vector. They also note the enforcement of a consensus dust threshold within the extension block.The deployment name for this specification is "extblk" and appears as "!extblk" in GBT. The writer points out that while the start time for the deactivation deployment is mentioned, there is no information about the timeout or how to continue the extension block. They critique the lack of clarity and specificity in the new BIP and propose alternative solutions. Finally, they caution against specifying policy in BIPs and comment on the potential negative effects of deactivating unused chains.
Updated on: 2023-08-01T20:14:37.007434+00:00