Hi Antoine and all,
About nLockTime fun thing is Lisa, Cdecker and I had this conversation to integrate it to C-lightning just yesterday. Unfortunately you need to add a "My tip is xxxx" to the openchannel msg, otherwise if you set nLockTime to tip. (cdecker) Moreover in case of reorg the funding tx (now non-final) would be dropped from mempool ? But you could set nLockTime to, say, tip - 6. (niftynei) Antoine \-------- Original Message -------- On Jan 30, 2020, 01:21, Antoine Riard < antoine.ri...@gmail.com> wrote: > > > > Hey thanks for this proposal! > > > > 2 high-level questions: > > > > > > What about multi-party tx construction ? By multi-party, let's define > > Alice initiate a tx construction to Bob and then Bob announce a > > > construction to Caroll and "bridge" all inputs/outputs additions/substractions > > > in both directions. I think the current proposal hold, if you are a bit more > > > tolerant and bridge peer don't send a tx\_complete before receiving ones > > > from all its peers. > > > > > > What about transactions format ? I think we should coordinate with Coinjoin > > > people to converge to a common one to avoid leaking protocol usage when > we can hinder under Taproot. Like setting the nLocktime or sorting inputs > > > in some protocol-specific fashion. Ideally we should have a BIP for format > > > but every layer 2 protocols its own set of messages concerning the > construction. > > > nLocktime is always set to 0x000000 > Maybe we can implement anti-fee sniping and mask among wallet core > txn set: > [https://github.com/bitcoin/bitcoin/blob/aabec94541e23a67a9f30dc2c80dab3383a01737/src/wallet/wallet.cpp\#L2519][https_github.com_bitcoin_bitcoin_blob_aabec94541e23a67a9f30dc2c80dab3383a01737_src_wallet_wallet.cpp_L2519] > ? > > > In the case of a close, a failed collaborative close would result in an > > error and a uninlateral close" > Or can we do first a mutual closing tx, hold tx broadcast for a bit if > "opt\_dual\_fund" > is signaled to see if a tx\_construction + add\_funding\_input for the > channel is received > soon ? At least that would be a dual opt-in to know than one party can submit > a funding-outpoint > as part of a composed tx ? > > > > > Antoine > > > > > > Le lun. 27 janv. 2020 à 20:51, lisa neigut > <[nifty...@gmail.com][niftynei_gmail.com]> a écrit : > > > > Some of the feedback I received from the check-in for the dual-funding > > proposal this past Monday was along the lines that we look at simplifying > > for breaking it into smaller, more manageable chunks. > > > > > > > > > > The biggest piece of the dual-funding protocol update is definitely the > > move from a single peer constructing a transaction to two participants. > > We're also going to likely want to reuse this portion of the protocol for > > batched closings and splicing. To that extent, it seemed useful to > > highlight it in a separate email. > > > > > > > > > > This is a change from the existing proposal in the dual-funding [PR > > \#524][PR _524] \-- it allows for the removal of inputs and outputs. > > > > > > > > > > The set of messages are as follows. > > > > > > > > > > Note that the 'initiation' of this protocol will be different depending on > > the case of the transaction (open, close or splice): > > > > > > > > > > 1. type: 440 \`tx\_add\_input\` > > > > 2. data: > > > > \* \[\`32\*byte\`:\`channel\_identifier\`\] > > > > \* \[\`u64\`:\`sats\`\] > > > > \* \[\`sha256\`:\`prevtx\_txid\`\] > > > > \* \[\`u32\`:\`prevtx\_vout\`\] > > > > \* \[\`u16\`:\`prevtx\_scriptpubkey\_len\`\] > > > > \* \[\`prevtx\_scriptpubkey\_len\*byte\`:\`prevtx\_scriptpubkey\`\] > > > > \* \[\`u16\`:\`max\_witness\_len\`\] > > > > \* \[\`u16\`:\`scriptlen\`\] > > > > \* \[\`scriptlen\*byte\`:\`script\`\] > > > > \* \[\`byte\`:\`signal\_rbf\`\] > > > > > > > > > > 1. type: 442 \`tx\_add\_output\` > > > > 2. data: > > > > \* \[\`32\*byte\`:\`channel\_identifier\`\] > > > > \* \[\`u64\`:\`sats\`\] > > > > \* \[\`u16\`:\`scriptlen\`\] > > > > \* \[\`scriptlen\*byte\`:\`script\`\] > > > > > > > > > > 1. type: 444 \`tx\_remove\_input\` > > > > 2. data: > > > > \* \[\`32\*byte\`:\`channel\_identifier\`\] > > > > \* \[\`sha256\`:\`prevtx\_txid\`\] > > > > \* \[\`u32\`:\`prevtx\_vout\`\] > > > > > > > > > > 1. type: 446 \`tx\_remove\_output\` > > > > 2. data: > > > > \* \[\`32\*byte\`:\`channel\_identifier\`\] > > > > \* \[\`u64\`:\`sats\`\] > > > > \* \[\`u16\`:\`scriptlen\`\] > > > > \* \[\`scriptlen\*byte\`:\`script\`\] > > > > > > > > > > 1. type: 448 \`tx\_complete\` > > > > 2. data: > > > > \* \[\`32\*byte\`:\`channel\_identifier\`\] > > > > \* \[\`u16\`:\`num\_inputs\`\] > > > > \* \[\`u16\`:\`num\_outputs\`\] > > > > > > > > > > 1. type: 448 \`tx\_sigs\` > > > > 2. data: > > > > \* \[\`channel\_id\`:\`channel\_identifier\`\] > > > > \* \[\`u16\`:\`num\_witnesses\`\] > > > > \* \[\`num\_witnesses\*witness\_stack\`:\`witness\_stack\`\] > > > > > > > > > > 1. subtype: \`witness\_stack\` > > > > 2. data: > > > > \* \[\`sha256\`:\`prevtx\_txid\`\] > > > > \* \[\`u32\`:\`prevtx\_vout\`\] > > > > \* \[\`u16\`:\`num\_input\_witness\`\] > > > > \* \[\`num\_input\_witness\*witness\_element\`:\`witness\_element\`\] > > > > > > > > > > 1. subtype: \`witness\_element\` > > > > 2. data: > > > > \* \[\`u16\`:\`len\`\] > > > > \* \[\`len\*byte\`:\`witness\`\] > > > > > > > > > > > > > > > > \#\# General Notes > > > > \- Validity of inputs/outputs is not checked until both peers have sent > > consecutive \`tx\_complete\` messages. > > > > \- Duplicate inputs or outputs is a protocol error. > > > > \- Feerate is set by the initiator, or in the case of a closing > > transaction, negotiated before the transaction construction is initiated. > > > > \- Every peer pays fees for the inputs + outputs they contribute, plus > > enough to cover the maximum estimate of their witnesses. Overpayment of > > fees is permissible. > > > > \- Initiator is responsible for contributing the output/input in question, > > i.e. the > > > > funding output in the case of an opening, or the funding input in the > > case of a close. > > > > (This means that the opener will pay for the opening output). In the case > > of a splice, > > > > the initiator of the splice pays for the funding tx's inclusion as an > > input and the > > > > new 'funding tx' output. > > > > \- Any contributor may signal that their input is RBF'able. The nSequence > > for this input should be set to 0xFEFF FFFF, 0xFFFFFFFF otherwise. > > > > \- The initiating peer is understood to be paying the fee for the shared > > transaction fields (nVersion \[4\], segwit marker + flag \[2\], input + > > output counts \[2-18\], witness count \[1-9\], nLocktime \[4\]; total > > \[13-40bytes\]) > > > > \- Inputs MUST be segwit compatible (PW\* or P2SH-PW\*) > > > > \- All output scripts must be standard > > > > \- nLocktime is always set to 0x00000000. > > > > \- The \`num\_inputs\` and \`num\_outputs\` in \`tx\_complete\` is a count > > of that peer’s final input and output contributions, net any removals. > > > > > > > > > > \- Either peer may add or remove inputs and outputs until both peers have > > successfully > > > > exchanged a \`tx\_complete\` message in succession. > > > > \- Either peer may only add or remove their own input or output. > > > > \- In the case that a \`tx\_complete\` agreement cannot be reached, either > > peer may > > > > fail the channel or open protocol (whatever is reasonable for the > > particular case) > > > > - In the case of a splice, this would be a soft error (channel returns to > > normal operation until > > > > otherwise failed or closed.) > > > > - In the case of an open, this would be a failure to open the channel. > > > > - In the case of a close, a failed collaborative close would result in an > > error and a unilateral close. > > > > > > > > > > \#\#\# Considering the Simple Open case (2 parties) > > > > \- Both peers signal \`opt\_dual\_fund\` > > > > \- Opener initiates a channel open with \`open\_channel2\` message, > > indicating the feerate for the opening transaction > > > > \- Accepter signals acceptance of channel open as proposed, including > > proposed feerate, via \`accept\_channel2\` > > > > \- Opener sends \`tx\_add\_output\`, with the funding output for the sum of > > both peer’s funding\_amount > > > > \- Opener sends \`tx\_add\_input\` for each input the wish to add to the > > funding transaction > > > > \- Opener sends \`tx\_add\_output\` for their change > > > > \- Opener sends \`tx\_complete\` > > > > \- Accepter sends \`tx\_add\_input\` for each input they wish to add to the > > funding transaction > > > > \- Accepter sends \`tx\_add\_output\` for their change. > > > > \- Accepter sends \`tx\_complete\` > > > > \- Opener sends \`tx\_complete\` > > > > \- Opener and accepter exchange commitment signatures; etc. > > > > > > > > > > \#\#\# Considering the Splice case: > > > > \- Both peers signal \`opt\_splice\_ok\` > > > > \- One peer initiates a splice, also signaling the feerate for the > > transaction. Exact protocol unspecified herein. > > > > \- Initiator sends \`tx\_add\_input\` with the original funding output > > > > \- Initiator sends \`tx\_add\_output\` with the new, post-splice funding > > output > > > > \- Initiator sends \`tx\_add\_input/output\` as needed to add all desired > > inputs + outputs > > > > \- Initiator sends \`tx\_complete\` > > > > \- Peer sends \`tx\_add\_input/output\` as needed to add all desired inputs > > + outputs > > > > \- Initiator sends \`tx\_complete\` > > > > \- Peer sends \`tx\_complete\` > > > > \- Initiator + peer exchange commitment signatures, etc. > > > > > > > > > > \#\#\# Considering the Close case: > > > > \- Both peers signal \`opt\_collaborative\_close\` in their > > \`node\_announcement\`. > > > > \- A peer initiates a close sending a \`shutdown\`, as per usual. > > > > \- A feerate is negotiated. Out of band for this particular portion of the > > protocol. > > > > \-The closing initiator (peer which first sent \`shutdown\`), sends > > \`tx\_add\_input\` to spend the funding output and \`tx\_add\_output\` to > > add their output for the channel closure. > > > > \- 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. > > > > > > > > > > > > \#\# Updating a collaborative transaction with RBF: > > > > \- 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. > > > > \- Note that this section has been cribbed and re-purposed from the > > original RBF proposal for splicing, see > > https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001621.html > > > > > > > > > > 1. type: 45 (\`init\_rbf\`) (\`option\_collaborative\_rbf\`) > > > > 2. data: > > > > \* \[\`32\`:\`channel\_id\`\] > > > > \* \[\`4\`:\`fee\_step\`\] > > > > > > > > > > Each \`fee\_step\` adds 1/4 (rounded down) to the initial > > > > transaction feerate. eg. if the initial feerate was 512 satoshis per > > kiloweight, \`fee\_step\` 1 > > > > is 512 + 512 / 4 = 640, \`fee\_step\` 2 is 640 + 640 / 4 = 800. > > > > > > > > > > The sender: > > > > - MUST set \`fee\_step\` greater than zero and greater than any prior > > \`fee\_step\`. > > > > > > > > > > The recipient: > > > > - if the new fee exceeds the sender's current balance minus reserve > > > > after it is applied to the splice transaction: > > > > - MUST error. > > > > > > > > NOTES: > > > > 1. 1/4 is a reasonable minimal RBF, but as each one requires more > > > > tracking by the recipient, serves to limit the number you can create. > > > > 2. Rule 4 of BIP125 requires a feerate increase to at least surpass the > > minimum transaction relay setting. Ratcheting by 25% should satisfy this > > requirement > > > > 3. 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. > > > > > > > > > > \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ > > Lightning-dev mailing list > > [Lightning-dev@lists.linuxfoundation.org][Lightning-dev_lists.linuxfoundation.org] > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > [https_github.com_bitcoin_bitcoin_blob_aabec94541e23a67a9f30dc2c80dab3383a01737_src_wallet_wallet.cpp_L2519]: https://github.com/bitcoin/bitcoin/blob/aabec94541e23a67a9f30dc2c80dab3383a01737/src/wallet/wallet.cpp#L2519 [niftynei_gmail.com]: mailto:nifty...@gmail.com [PR _524]: https://github.com/lightningnetwork/lightning-rfc/pull/524 [Lightning-dev_lists.linuxfoundation.org]: mailto:Lightning-dev@lists.linuxfoundation.org
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
