Author: darosior 2020-01-30 10:03:17
Published on: 2020-01-30T10:03:17+00:00
Antoine proposed a transaction chain construction as a solution to utxos snooping. The proposal involves the first input being signed by A with SIGHASH_SINGLE|SIGHASH_ANYONECANPAY and creating a first transaction txA1. A then creates and signs the funding transaction out of the first output of txA1 called txA2, which is signed with SINGLE|ANYONECANPAY allowing B to add inputs and outputs for its own change. This method requires more setup fees opener-side but avoids gratuitous probing by the accepter.Lisa Neigut shared feedback from the check-in for the dual-funding proposal suggesting simplifying it into smaller, more manageable chunks. The email highlights the biggest piece of the dual-funding protocol update as the move from a single peer constructing a transaction to two participants. The proposal aims to reuse this portion of the protocol for batched closings and splicing.The set of messages involved in the dual-funding proposal includes `tx_add_input`, `tx_add_output`, `tx_remove_input`, `tx_remove_output`, `tx_complete`, and `tx_sigs` with subtypes `witness_stack` and `witness_element`. Validity of inputs/outputs is not checked until both peers have sent consecutive `tx_complete` messages. Inputs must be segwit compatible (PW* or P2SH-PW*) and all output scripts must be standard. Either peer may add or remove inputs and outputs until both peers have successfully exchanged a `tx_complete` message in succession. In case of a failure to agree on `tx_complete`, either peer may fail the channel or open protocol.The Lightning Network protocol outlines the process for initiating a channel open with an `open_channel2` message, which includes proposing a feerate for the opening transaction. The accepter then signals acceptance of the proposal via `accept_channel2`. In the case of a Splice, both peers signal `opt_splice_ok` and one peer initiates the splice, signaling the feerate for the transaction. The initiator sends `tx_add_input` with the original funding output, `tx_add_output` with the new post-splice funding output, and any additional `tx_add_input/output` as needed. The peer does the same and both parties send `tx_complete`. They then exchange commitment signatures and continue with the protocol. In the close case, both peers signal `opt_collaborative_close` in their `node_announcement`. A peer initiates a close by sending a `shutdown`, negotiates a feerate out of band, and then adds their output for the channel closure via `tx_add_input` and `tx_add_output`. The peer responds with `tx_add_output`, adding their output to the close transaction. If `option_upfront_shutdown_script` is flagged but no such output with a value at or within a reasonable feerate gap of the peer's funding output is present, then the peer must fail the channel.If any input is flagged as RBF’able, then the transaction is considered eligible for RBF. RBF can be initiated by either party, and serves as an initiation for another round of transaction composition, as outlined above. Each `fee_step` adds 1/4 (rounded down) to the initial transaction feerate. The sender MUST set `fee_step` greater than zero and greater than any prior `fee_step`. If the new fee exceeds the sender's current balance minus reserve after it is applied to the splice transaction, the recipient MUST error. An additional rule will be added to the checks of an RBF transaction that it must include at least one identical, replaceable input as the original transaction.
Updated on: 2023-06-02T23:12:55.903811+00:00