{"type":"rich","version":"1.0","title":"Antoine Riard [ARCHIVE] wrote","author_name":"Antoine Riard [ARCHIVE] (npub1vj…4x8dd)","author_url":"https://yabu.me/npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8dd","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2020-01-29\n📝 Original message:\nHey thanks for this proposal!\n\n2 high-level questions:\n\nWhat about multi-party tx construction ? By multi-party, let's define\nAlice initiate a tx construction to Bob and then Bob announce a\nconstruction to Caroll and \"bridge\" all inputs/outputs\nadditions/substractions\nin both directions. I think the current proposal hold, if you are a bit more\ntolerant and bridge peer don't send a tx_complete before receiving ones\nfrom all its peers.\n\nWhat about transactions format ? I think we should coordinate with Coinjoin\npeople to converge to a common one to avoid leaking protocol usage when\nwe can hinder under Taproot. Like setting the nLocktime or sorting inputs\nin some protocol-specific fashion. Ideally we should have a BIP for format\nbut every layer 2 protocols its own set of messages concerning the\nconstruction.\n\n\u003e nLocktime is always set to 0x000000\nMaybe we can implement anti-fee sniping and mask among wallet core\ntxn set:\nhttps://github.com/bitcoin/bitcoin/blob/aabec94541e23a67a9f30dc2c80dab3383a01737/src/wallet/wallet.cpp#L2519\n?\n\n\u003e In the case of a close, a failed collaborative close would result in an\nerror and a uninlateral close\"\nOr can we do first a mutual closing tx, hold tx broadcast for a bit if\n\"opt_dual_fund\"\nis signaled to see if a tx_construction + add_funding_input for the channel\nis received\nsoon ? At least that would be a dual opt-in to know than one party can\nsubmit a funding-outpoint\nas part of a composed tx ?\n\nAntoine\n\nLe lun. 27 janv. 2020 à 20:51, lisa neigut \u003cniftynei at gmail.com\u003e a écrit :\n\n\u003e Some of the feedback I received from the check-in for the dual-funding\n\u003e proposal this past Monday was along the lines that we look at simplifying\n\u003e for breaking it into smaller, more manageable chunks.\n\u003e\n\u003e The biggest piece of the dual-funding protocol update is definitely the\n\u003e move from a single peer constructing a transaction to two participants.\n\u003e We're also going to likely want to reuse this portion of the protocol for\n\u003e batched closings and splicing. To that extent, it seemed useful to\n\u003e highlight it in a separate email.\n\u003e\n\u003e This is a change from the existing proposal in the dual-funding PR #524\n\u003e \u003chttps://github.com/lightningnetwork/lightning-rfc/pull/524\u003e -- it allows\n\u003e for the removal of inputs and outputs.\n\u003e\n\u003e The set of messages are as follows.\n\u003e\n\u003e\n\u003e Note that the 'initiation' of this protocol will be different depending\n\u003e on the case of the transaction (open, close or splice):\n\u003e\n\u003e 1. type:   440 `tx_add_input`\n\u003e\n\u003e 2. data:\n\u003e\n\u003e     * [`32*byte`:`channel_identifier`]\n\u003e\n\u003e     * [`u64`:`sats`]\n\u003e\n\u003e     * [`sha256`:`prevtx_txid`]\n\u003e\n\u003e     * [`u32`:`prevtx_vout`]\n\u003e\n\u003e     * [`u16`:`prevtx_scriptpubkey_len`]\n\u003e\n\u003e     * [`prevtx_scriptpubkey_len*byte`:`prevtx_scriptpubkey`]\n\u003e\n\u003e     * [`u16`:`max_witness_len`]\n\u003e\n\u003e     * [`u16`:`scriptlen`]\n\u003e\n\u003e     * [`scriptlen*byte`:`script`]\n\u003e\n\u003e     * [`byte`:`signal_rbf`]\n\u003e\n\u003e 1. type: 442 `tx_add_output`\n\u003e\n\u003e 2. data:\n\u003e\n\u003e     * [`32*byte`:`channel_identifier`]\n\u003e\n\u003e     * [`u64`:`sats`]\n\u003e\n\u003e     * [`u16`:`scriptlen`]\n\u003e\n\u003e     * [`scriptlen*byte`:`script`]\n\u003e\n\u003e 1. type: 444 `tx_remove_input`\n\u003e\n\u003e 2. data:\n\u003e\n\u003e     * [`32*byte`:`channel_identifier`]\n\u003e\n\u003e     * [`sha256`:`prevtx_txid`]\n\u003e\n\u003e     * [`u32`:`prevtx_vout`]\n\u003e\n\u003e 1. type: 446 `tx_remove_output`\n\u003e\n\u003e 2. data:\n\u003e\n\u003e     * [`32*byte`:`channel_identifier`]\n\u003e\n\u003e     * [`u64`:`sats`]\n\u003e\n\u003e     * [`u16`:`scriptlen`]\n\u003e\n\u003e     * [`scriptlen*byte`:`script`]\n\u003e\n\u003e 1. type: 448 `tx_complete`\n\u003e\n\u003e 2. data:\n\u003e\n\u003e     * [`32*byte`:`channel_identifier`]\n\u003e\n\u003e     * [`u16`:`num_inputs`]\n\u003e\n\u003e     * [`u16`:`num_outputs`]\n\u003e\n\u003e 1. type:  448 `tx_sigs`\n\u003e\n\u003e 2. data:\n\u003e\n\u003e     * [`channel_id`:`channel_identifier`]\n\u003e\n\u003e     * [`u16`:`num_witnesses`]\n\u003e\n\u003e     * [`num_witnesses*witness_stack`:`witness_stack`]\n\u003e\n\u003e 1. subtype: `witness_stack`\n\u003e\n\u003e 2. data:\n\u003e\n\u003e     * [`sha256`:`prevtx_txid`]\n\u003e\n\u003e     * [`u32`:`prevtx_vout`]\n\u003e\n\u003e     * [`u16`:`num_input_witness`]\n\u003e\n\u003e     * [`num_input_witness*witness_element`:`witness_element`]\n\u003e\n\u003e 1. subtype: `witness_element`\n\u003e\n\u003e 2. data:\n\u003e\n\u003e     * [`u16`:`len`]\n\u003e\n\u003e     * [`len*byte`:`witness`]\n\u003e\n\u003e\n\u003e\n\u003e ## General Notes\n\u003e\n\u003e - Validity of inputs/outputs is not checked until both peers have sent\n\u003e consecutive `tx_complete`  messages.\n\u003e\n\u003e - Duplicate inputs or outputs is a protocol error.\n\u003e\n\u003e - Feerate is set by the initiator, or in the case of a closing\n\u003e transaction, negotiated before the transaction construction is initiated.\n\u003e\n\u003e - Every peer pays fees for the inputs + outputs they contribute, plus\n\u003e enough to cover the maximum estimate of their witnesses. Overpayment of\n\u003e fees is permissible.\n\u003e\n\u003e - Initiator is responsible for contributing the output/input in question,\n\u003e i.e. the\n\u003e\n\u003e   funding output in the case of an opening, or the funding input in the\n\u003e case of a close.\n\u003e\n\u003e   (This means that the opener will pay for the opening output). In the\n\u003e case of a splice,\n\u003e\n\u003e   the initiator of the splice pays for the funding tx's inclusion as an\n\u003e input and the\n\u003e\n\u003e   new 'funding tx' output.\n\u003e\n\u003e - Any contributor may signal that their input is RBF'able. The nSequence\n\u003e for this input should be set to 0xFEFF FFFF, 0xFFFFFFFF otherwise.\n\u003e\n\u003e - The initiating peer is understood to be paying the fee for the shared\n\u003e transaction fields (nVersion [4], segwit marker + flag [2], input + output\n\u003e counts [2-18], witness count [1-9], nLocktime [4]; total [13-40bytes])\n\u003e\n\u003e - Inputs MUST be segwit compatible (PW* or P2SH-PW*)\n\u003e\n\u003e - All output scripts must be standard\n\u003e\n\u003e - nLocktime is always set to 0x00000000.\n\u003e\n\u003e - The `num_inputs` and `num_outputs` in `tx_complete` is a count of that\n\u003e peer’s final input and output contributions, net any removals.\n\u003e\n\u003e - Either peer may add or remove inputs and outputs until both peers have\n\u003e successfully\n\u003e\n\u003e   exchanged a `tx_complete` message in succession.\n\u003e\n\u003e - Either peer may only add or remove their own input or output.\n\u003e\n\u003e - In the case that a `tx_complete` agreement cannot be reached, either\n\u003e peer may\n\u003e\n\u003e   fail the channel or open protocol (whatever is reasonable for the\n\u003e particular case)\n\u003e\n\u003e   - In the case of a splice, this would be a soft error (channel returns\n\u003e to normal operation until\n\u003e\n\u003e     otherwise failed or closed.)\n\u003e\n\u003e   - In the case of an open, this would be a failure to open the channel.\n\u003e\n\u003e   - In the case of a close, a failed collaborative close would result in\n\u003e an error and a unilateral close.\n\u003e\n\u003e ### Considering the Simple Open case (2 parties)\n\u003e\n\u003e - Both peers signal `opt_dual_fund`\n\u003e\n\u003e - Opener initiates a channel open with `open_channel2` message, indicating\n\u003e the feerate for the opening transaction\n\u003e\n\u003e - Accepter signals acceptance of channel open as proposed, including\n\u003e proposed feerate, via `accept_channel2`\n\u003e\n\u003e - Opener sends `tx_add_output`, with the funding output for the sum of\n\u003e both peer’s funding_amount\n\u003e\n\u003e - Opener sends `tx_add_input` for each input the wish to add to the\n\u003e funding transaction\n\u003e\n\u003e - Opener sends `tx_add_output` for their change\n\u003e\n\u003e - Opener sends `tx_complete`\n\u003e\n\u003e - Accepter sends `tx_add_input` for each input they wish to add to the\n\u003e funding transaction\n\u003e\n\u003e - Accepter sends `tx_add_output` for their change.\n\u003e\n\u003e - Accepter sends `tx_complete`\n\u003e\n\u003e - Opener sends `tx_complete`\n\u003e\n\u003e - Opener and accepter exchange commitment signatures; etc.\n\u003e\n\u003e ### Considering the Splice case:\n\u003e\n\u003e - Both peers signal `opt_splice_ok`\n\u003e\n\u003e - One peer initiates a splice, also signaling the feerate for the\n\u003e transaction. Exact protocol unspecified herein.\n\u003e\n\u003e - Initiator sends `tx_add_input` with the original funding output\n\u003e\n\u003e - Initiator sends `tx_add_output` with the new, post-splice funding output\n\u003e\n\u003e - Initiator sends `tx_add_input/output` as needed to add all desired\n\u003e inputs + outputs\n\u003e\n\u003e - Initiator sends `tx_complete`\n\u003e\n\u003e - Peer sends `tx_add_input/output` as needed to add all desired inputs +\n\u003e outputs\n\u003e\n\u003e - Initiator sends `tx_complete`\n\u003e\n\u003e - Peer sends `tx_complete`\n\u003e\n\u003e - Initiator + peer exchange commitment signatures, etc.\n\u003e\n\u003e ### Considering the Close case:\n\u003e\n\u003e - Both peers signal `opt_collaborative_close` in their `node_announcement`.\n\u003e\n\u003e - A peer initiates a close sending a `shutdown`, as per usual.\n\u003e\n\u003e - A feerate is negotiated. Out of band for this particular portion of the\n\u003e protocol.\n\u003e\n\u003e -The closing initiator (peer which first sent `shutdown`), sends\n\u003e `tx_add_input` to spend the funding output and `tx_add_output` to add their\n\u003e output for the channel closure.\n\u003e\n\u003e - The peer responds with `tx_add_output`, adding their output to the close\n\u003e transaction.\n\u003e\n\u003e - If `option_upfront_shutdown_script` is flagged but no such output with a\n\u003e value at or within a reasonable feerate gap of the peer's funding output is\n\u003e present, then the peer must fail the channel.\n\u003e\n\u003e\n\u003e ## Updating a collaborative transaction with RBF:\n\u003e\n\u003e - If any input is flagged as RBF’able, then the transaction is considered\n\u003e eligible for RBF\n\u003e\n\u003e - RBF can be initiated by either party, and serves as an initiation for\n\u003e another round of transaction composition, as outlined above.\n\u003e\n\u003e - Note that this section has been cribbed and re-purposed from the\n\u003e original RBF proposal for splicing, see\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001621.html\n\u003e\n\u003e 1. type: 45 (`init_rbf`) (`option_collaborative_rbf`)\n\u003e\n\u003e 2. data:\n\u003e\n\u003e    * [`32`:`channel_id`]\n\u003e\n\u003e    * [`4`:`fee_step`]\n\u003e\n\u003e Each `fee_step` adds 1/4 (rounded down) to the initial\n\u003e\n\u003e transaction feerate. eg. if the initial feerate was 512 satoshis per\n\u003e kiloweight, `fee_step` 1\n\u003e\n\u003e is  512 + 512 / 4 = 640, `fee_step` 2 is 640 + 640 / 4 = 800.\n\u003e\n\u003e The sender:\n\u003e\n\u003e   - MUST set `fee_step` greater than zero and greater than any prior\n\u003e `fee_step`.\n\u003e\n\u003e The recipient:\n\u003e\n\u003e   - if the new fee exceeds the sender's current balance minus reserve\n\u003e\n\u003e     after it is applied to the splice transaction:\n\u003e\n\u003e     - MUST error.\n\u003e\n\u003e\n\u003e\n\u003e NOTES:\n\u003e\n\u003e 1. 1/4 is a reasonable minimal RBF, but as each one requires more\n\u003e\n\u003e    tracking by the recipient, serves to limit the number you can create.\n\u003e\n\u003e 2. Rule 4 of BIP125 requires a feerate increase to at least surpass the\n\u003e minimum transaction relay setting. Ratcheting by 25% should satisfy this\n\u003e requirement\n\u003e\n\u003e 3. An additional rule will be added to the checks of an RBF transaction\n\u003e that it must include at least one identical, replaceable input as the\n\u003e original transaction.\n\u003e\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200129/d155c0a0/attachment-0001.html\u003e"}