Sorry I wasn't clear enough in the \`(cdecker)\` paragraph.
The funding transaction sig would actually fail verification if tip differs between funder and fundee. Darosior ( i'll stick with my pseudo, first names definitely don't have enough entropy :-) ) \-------- Original Message -------- On Jan 30, 2020, 19:09, Antoine Riard < antoine.ri...@gmail.com> wrote: > > > > Hey Darosior, > > > > You don't need a strict synchronization between both peers, > > > just let nLocktime picked up by initiator and announce it at > > > same time than feerate or at \`tx\_complete\`. Worst-case, > > > a slow-block-processing receiver may not be able to get > > > the transaction accepted by its local mempool, but IMO that's > fine if at least the initiator is able to do so. We are requiring peers > > > to be weakly in sync before operating channel anyway (\`funding\_locked\` > > > exchange). > > > > > > Funding\_tx can already be drop from mempool for others > > > reasons like mempool shrinks or expiry so broadcaster > > > should always be ready to re-send it or bump feerate. > > > > Or are you describing another issue ? > > > > > > Le jeu. 30 janv. 2020 à 04:06, darosior > <[daros...@protonmail.com][darosior_protonmail.com]> a écrit : > > > > 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][antoine.riard_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 > > > > [darosior_protonmail.com]: mailto:daros...@protonmail.com [antoine.riard_gmail.com]: mailto:antoine.ri...@gmail.com [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
