Published on: 2016-03-10T20:30:34+00:00
In an email conversation between Joseph Poon and Nicolas Dorier, they discuss the use of SIGHASH_NOINPUT to address storage requirements in Bitcoin transactions. Additionally, they explore an unusual use of OP_CODESEPARATOR that allows a single pubkey to enforce the execution of a specific code path. This can be useful in multi-party multi-signature situations where parties only want to sign off on certain conditions. The conversation focuses on finding efficient ways to handle Bitcoin transactions and revocations. Another email conversation between Fabrice Drouin and Nicolas Dorier revolves around the payment channel script. Dorier mentions that he has adapted the script to use less space, resulting in savings of 32 bytes in the scriptpubkey for the R value and 70 bytes in the signature when Alice closes the channel. Links are provided to check the scripts for Alice closing the channel and Bob using revocation. However, there is confusion about how nodes would react when old commit transactions are published. Dorier explains that storing one R value per commitment and using OP_CODESEPARATOR can save space on the blockchain.The conversation further delves into exploring the use of signatures as a method of revocation for commitments. It is proposed that disclosing temporary private keys instead of signatures can achieve compactness. An example of a compact revocable broadcast script for Bob and Alice is provided, showcasing successful redemption and penalty transactions. Space can be saved in the timeout/non-penalty case, but transactions are larger for penalty cases. The conversation concludes with a mention of the potential usefulness of OP_CODESEPARATOR if SIGHASH_NOINPUT is implemented in segregated witness in the future.Nicolas Dorier and Rusty discuss a useful case for OP_CODESEPARATOR, acknowledging the need to ensure that no commit transaction is identical to a previous one and that all previous signatures must be stored. Despite the caveat, it is considered a premature optimization since these scripts will rarely hit the chain.In response to a query about node reactions to old commit transactions published without R + shachain/elkrem, Nicolas Dorier states that he has adapted the payment channel script to use less space. Links are provided to check the scripts for Alice closing the channel and Bob using revocation, showcasing the 100 bytes saved between the anchor transaction and commitment broadcasted.A member of the Lightning-dev mailing list raises a question about node reactions to old commit transactions published with a new scheme instead of R + shachain/elkrem. The author of the script responds by stating that they have managed to adapt the payment channel script to save space. Links are provided to demonstrate the script's functionality in the context of Alice closing the channel and Bob using revocation. In total, 100 bytes are saved between the anchor transaction and commitment broadcasted.The payment channel script has been modified to consume less space, resulting in savings of 32 bytes in the scriptpubkey and 70 bytes in the signature when Alice closes the channel. Links are provided to view the updated script for Alice closing the channel and Bob using revocation, showcasing the 100 bytes saved between the anchor transaction and commitment broadcasted.The context also highlights a proposed modification to the escape redeem function using OP_CODESEPARATOR to remove duplicate bytes. This change involves replacing OP_HASH160 OP_EQUAL OP_IF with OP_CHECKSIG OP_IF. The modified function's output would be {} for SIGA-Revocation and 0 {} for the second escape. The commitment revocation process involves revealing a specific key signature computed with ScriptCode. A tool called http://n.bitcoin.ninja/checkscript can be used to test the script.
Updated on: 2023-07-31T18:53:28.821990+00:00