> Yes that's the reason I wrote the initiator can just announce its own and > receiver use it to sign the funding tx, even if receiver tip is backward. > Funding tx won't propagate from receiver mempool but that's fine if it does > from the initiator one.
Ah, then we are back to my first response where niftynei proposed to accord on setting it to tip-6 so that reorg is not a problem (or if it is, there are bigger). \-------- Original Message -------- On Jan 30, 2020, 19:45, Antoine Riard < antoine.ri...@gmail.com> wrote: > > > > > The funding transaction sig would actually fail verification if tip differs > > between funder and fundee > > > > Yes that's the reason I wrote the initiator can just > > > announce its own and receiver use it to sign the funding tx, > > > even if receiver tip is backward. Funding tx won't propagate > > > from receiver mempool but that's fine if it does from the initiator > > one. > > > > Or are you talking about the commitment tx (different issue and there is > > > broader privacy leaks there) ? > > > Darosior ( i'll stick with my pseudo, first names definitely don't have > > enough entropy :-) ) > > > > Ahaha yeah this pseudo-random-name-generator is definitely not trustworthy :p > > > > > > > > > Le jeu. 30 janv. 2020 à 13:19, darosior > <[daros...@protonmail.com][darosior_protonmail.com]> a écrit : > > > > 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][antoine.riard_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
