Author: Olaoluwa Osuntokun 2017-04-05 14:05:37
Published on: 2017-04-05T14:05:37+00:00
The xblock proposal includes a sub-proposal for Lightning Network (LN) which is essentially a block-size decrease for each open channel within the network. The decrease reserves space in blocks to allow honest parties guaranteed space in the blocks to punish dishonest channel counter parties. As a result, the block size is permanently decreased for each channel open.The proposal also introduces a new safety measure called Pre-Allocated Smart-contract Dispute arena (PASDA), which is insufficiently described and under specified in the proposal. PASDA aims to mitigate a systematic risk related to blockchain availability in case of a channel dispute. The attack vector mentioned in the original paper is a DoS attack where if a channel counterparty can prevent a transaction from being committed to the chain, they are able to steal money from the honest participant in the channel. A minor mitigation to this attack that's purely commitment transaction policy is to mandate that the counterparty's balance in the channel never dips below some reserve value R. Another mitigation involves using the channel reserve to implement a ceiling on the maximum size of any in-flight HTLC. The proposal suggests two potential enhancements to the Lightning Network and Bitcoin. The first is the concept of time stomp, which introduces a sequence-locks block height to prevent DoS attacks from delaying punishment of dishonest parties within smart contracts. However, many details of this proposal remain underspecified, such as how miners signal to full nodes that the sequence-lock clock has stopped. The second proposal is called Pre-Allocated Smart-Contract Dispute Area (PASDA), which allows transactions that commence smart contracts to pre-allocate a section of the block that will always be reserved for dispute transactions. This guarantees space in blocks to handle disputes in case the contract breaks down.The proposed Payment Channel Arbitration Service Deployed in Advance (PASDA) aims to eliminate the denial-of-service (DoS) attack against Lightning Network (LN), although its high costs could be prohibitive. It requires a tribute to be paid by participants of the contract for each subsequent block, accounting for miners' loss in revenue due to the reduction in block size. PASDA could fill up an entirely distinct proposal by itself spanning several pages.A proposal for an extension block has been discussed by Christopher Jeffrey, Joseph Poon, Fedor Indutny, and Steven Pair. The Witness script hash v0 shall be worth the number of accurately counted sigops in the redeem script, multiplied by a factor of 8. However, there is a flaw here: witness script with no sigop will be counted as 0 and have a lot free space. This specification defines a method of increasing bitcoin transaction throughput without altering any existing consensus rules, using extension blocks that leverage several features of BIP141, BIP143, and BIP144 for transaction opt-in, serialization, verification, and network services. However, the rules in BIP 141 are fundamentally incompatible with this one, so saying BIP 141 is activated is confusingly incorrect. Extension blocks are not compatible with BIP141 in its current form, and will require a few minor additional rules. To reduce the chance of having redeem scripts which simply allow for garbage data in the witness vector, every 73 bytes in the serialized witness vector is worth 1 additional point. The genesis resolution transaction may also include a 1-100 byte pushdata in the first input script, allowing the miner of the genesis resolution to add a special message. Transactions within the extended transaction vector may include a witness vector using BIP141 transaction serialization. BIPs should not specify policy at all. Transactions fees may be calculated by transaction cost as well as additional size/legacy-sigops added to the canonical block due to entering or exiting outputs. Note that BIP141's nested P2SH feature is no longer available, and no longer a consensus rule. This leaves room for 7 future soft-fork upgrades to relax DoS limits. The "deactivation" deployment's start time is defined but timeout is not mentioned. BIPs must be in MediaWiki format, not Markdown. They should be submitted for discussion to the bitcoin-dev mailing list, not social media and news. Extension blocks are more of a hard-fork IMO. BIPs may not be "public domain" due to non-recognition in some jurisdictions.
Updated on: 2023-05-20T01:36:23.489498+00:00