WIP: Dual Funding (v2 Channel Establishment protocol) #524

niftynei · 2018-12-05T00:58:27Z

This is a first draft proposal for adding a second open channel version. This will empower either side of the channel to contribute to the funding transaction.

Broadly speaking, the largest change between this and version one of open_channel is that both sides now construct and broadcast the funding transaction. This adds a few more communication rounds, as the commitment transaction signatures can't be exchanged until both sides have the info necessary to construct the funding transaction.

Errata

~~Employs strawman idea of using a sha of the revocation points for the channel_id as put forth here https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-December/001709.html~~
TODO: Needs size limits on witness data submissions
Includes handling for RBF

rustyrussell

This is generally good, and I like the rbf flow. @Roasbeef suggested we keep it more minimal (ie. no change of inputs), but that doesn't gain very much compared to this approach, AFAICT.

I've bikeshedded a few things, because that's what we do :)

rustyrussell · 2018-12-10T03:17:32Z

02-peer-protocol.md

+    - MUST fail the channel if:
+      - `change_satoshis` would be negative.
+  - if has not yet sent a `funding_compose`:
+    - MUST send their `funding_compose` message.


s/their/its/

rustyrussell · 2018-12-10T03:23:26Z

02-peer-protocol.md

+    - MUST send their `funding_compose` message.
+  - otherwise:
+    - MUST use the sent and received `input_info` and `output_info`
+      to create the funding transaction, using `max_extra_witness_len`


It's now called 'max_witness_len'.

rustyrussell · 2018-12-10T03:25:49Z

02-peer-protocol.md

+        the `put_limit`.
+  - otherwise:
+    - MUST fail the channel if:
+      - `change_satoshis` would be negative.


It may not be able to figure this out yet (fees). So, perhaps this should be 'sum of input amounts < sum of output amounts'? And add the change_satoshis test only once it has calculated the tx?

Hmm, actually, I think this being negative should be allowed: in that case, funding_satoshis should be reduced. In effect, this allows you to say "I don't want change, take the fee out of my initial balance". Or perhaps we should make the change output optional for this case?

This seems like a valid use case. Will remove the 'change_satoshis must be positive' requirement.

Allowing negative change amounts means the resulting channel balance will be less than the indicated funding_satoshis, which ostensibly came from the user. Implementations would probably want to add a way for users to indicate where to take the fees out -- either the provided channel fund amount or in addition to that. (You could do this with the existing flow too, since it's just UX.)

My hesitation with making the change_address optional is that 1) it's an edge case (depends on available UTXO set) 2) it has a small chance of introducing bugs (i.e. broken implementation forgets to include a change address so you end up with a huge channel balance by accident). Leaving out the change address doesn't save you much in calculation overhead when picking out the input UTXO set either. The only thing it does save on is wire bytes, in the case where your funding amt works out exactly right.

rustyrussell · 2018-12-10T03:26:33Z

02-peer-protocol.md

+      to create the funding transaction, using `max_extra_witness_len`
+      for each `input_info` and `feerate_per_kw_funding` as specified in
+      `open_channel2`.
+    - MUST send `commitment_signed2`.


Can we just use commitment_signed. It's identical, and performs the identical function, so I really think it deserves the same name...

Right. The rationale was that it might be nice to decouple the two flows as that would allow future modification without needing to worry much about backwards compatibility.

rustyrussell · 2018-12-10T03:28:51Z

02-peer-protocol.md

+
+`satoshis` is the value of the input or output. The opener must provide
+one change address for the transaction, which is flagged with a
+`satoshis` value of zero.


You said this below as well; delete one? We try to avoid spec-sounding language (i.e. "must") in Rationales to avoid confusion; I would say "The opener provides one output with satoshis equal zero, as a change address once the amount of change can be calculated".

rustyrussell · 2018-12-10T03:38:03Z

02-peer-protocol.md

+#### Requirements
+The sending node:
+  - MUST set `witness` to the marshalled witness data for each of its
+    inputs, in funding transaction order. FIXME: add reference


I realize this is quoting me, but the term I should have used is 'serialized' which IIRC is what the BIPs use.

rustyrussell · 2018-12-10T03:38:38Z

02-peer-protocol.md

+Exchanging witness data allows both sides to broadcast the funding
+transaction and maintains information symmetry.
+
+### The `funding_locked2` Message


Again, prefer direct 'funding_locked' reuse.

inclusion of the funding_tx_id means we need a v2 for this

rustyrussell · 2018-12-10T03:44:52Z

02-peer-protocol.md

+  * [`4`:`feerate_per_kw`]
+  * [`4`:`feerate_per_kw_funding`]
+  * [`2`:`num_inputs`]
+  * [`num_inputs`\*`input_info`]


num_additional_inputs might be clearer?

rustyrussell · 2018-12-10T03:46:37Z

02-peer-protocol.md

+      e.g. an `output_info` entry  with `satoshis` set to zero.
+    - the `feerate_per_kw_funding` is not greater than the previously
+      negotiated rate.
+    - `change_satoshis` is negative.


I think we should allow "extract from channel" in this case, as well.

02-peer-protocol.md

rustyrussell · 2019-03-04T09:51:58Z

02-peer-protocol.md

+#### Requirements
+
+The sending node:
+  - MUST ensure each `input_info` refers to an existing UTXO


Moreover, it must ensure that it's non-malleable.

rustyrussell · 2019-03-04T09:57:14Z

02-peer-protocol.md

+    - MAY send zero inputs and/or outputs.
+
+The receiving node:
+  - if the total `input_info`.`satoshis` is less than the total `output_info`.`satoshis`


(Summary of discussion with @niftynei elsewhere)

Unfortunately, the receiving node needs to know this input is not malleable. That requires that it know the output being spent. We could either have the sender include the entire TX, or insist the recipient know the UTXO. Both are unappealing: the 64k packet size means some txs can't be used, and the UTXO requirement means no CPFP.

I think we have to go for "send the input tx"; creating a "fetch tx" for this would lead to another untested code path. Which makes this different from splice, which doesn't have this problem.

Thinking about this more, I think we can simplify this requirement by checking the scriptSig data in addition to the txid/vout for inputs, and merely verifying that it is either 00 or one of the two acceptable v0 redeemScript formats for P2SH-P2W*. (i.e. 0014xxx or 0020xxx)

Ok, updated to include the scriptPubKey of the desired output as well.

rustyrussell · 2019-03-04T09:59:51Z

02-peer-protocol.md

+Exchanging witness data allows both sides to broadcast the funding
+transaction and maintains information symmetry.
+
+### The `funding_locked2` Message


niftynei · 2019-04-30T02:03:08Z

Working on the implementation of this for c-lightning, and I've hit a bit of a conundrum around what's the best way forward wrt the channel_reserve_satoshi.

In v1 of the channel establishment protocol, the entire funding balance is known as of the first open_channel message. In v2, the entire funding balance won't be known until after accept_channel2 has been exchanged.

Here's a few options that I've come up with for how to deal with this. Leaning towards the 3rd option.

leave it as is, and have both the opener and the accepter's values be based on the opener's funding_satoshis value (same as v1)
leave the opener's reserve requirement to be the same, and have the accepter's value include their contribution as well. e.g. the opener sends funding_satoshi: 10 000 and channel_reserve_satoshi: 1 000; accepter sends funding_satoshis:10 000 and channel_reserve_satoshi:2 000.
move the channel_reserve_satoshi field to the funding_compose message, so that the entire funding balance can be taken into account. e.g. both would send channel_reserve_satoshi:2 000 (which is 1% of the entire funding balance).
remove the channel_reserve_satoshi field altogether, and set it permanently at 1% of the entire funding balance

darosior · 2019-10-30T15:38:25Z

02-peer-protocol.md

+
+If nodes have negotiated `option_dual_fund`:
+  - the opening node:
+    - MUST not send `open_channel`


nit

Suggested change

- MUST not send `open_channel`

- MUST NOT send `open_channel`

darosior · 2019-10-30T15:47:24Z

02-peer-protocol.md

+  - MUST add all received inputs to the funding transaction
+  - MUST fail the channel if:
+    - it receives a duplicate input to one it sent previously
+    - if it receives this message after `funding_add_complete` is received.


nit: trailing if

darosior · 2019-10-30T15:52:55Z

02-peer-protocol.md

+Native SegWit inputs (P2WPKH and P2WSH) inputs, will have an empty `script` field
+See [BIP141](https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#examples).
+
+The `accepter` node may omit this message.


Duplicated with https://github.com/lightningnetwork/lightning-rfc/pull/524/files#diff-3369c5aa1774fef2ff1e246979f223eaR621 ?

ack, removed.

darosior · 2019-10-30T15:55:13Z

02-peer-protocol.md

+    - MUST NOT send a total count of more than 8 outputs, across all `funding_add_output` messages.
+
+The receiving node:
+  - MUST add all received outputs to the funding transaction
+  - MUST fail the channel if
+    - it receives this message after receiving `funding_add_complete`
+  - if is the `opener`:
+    - MUST fail the channel if:
+      - receives a total count of more than 3 outputs, across all `funding_add_output`s


max of 8 then 3 ?

darosior · 2019-10-30T15:55:14Z

02-peer-protocol.md

+    - MUST NOT send a total count of more than 8 outputs, across all `funding_add_output` messages.
+
+The receiving node:
+  - MUST add all received outputs to the funding transaction
+  - MUST fail the channel if
+    - it receives this message after receiving `funding_add_complete`
+  - if is the `opener`:
+    - MUST fail the channel if:
+      - receives a total count of more than 3 outputs, across all `funding_add_output`s


max of 8 then 3 ?

darosior · 2019-10-30T16:03:43Z

02-peer-protocol.md

+    - the `num_outputs` does not correspond to the total sum of all `num_outputs`
+      received in all `funding_add_output` messages
+    - the total satoshis of the senders inputs is less than their outputs plus
+      the funding_sats, specified earlier


Suggested change

the funding_sats, specified earlier

the `funding_satoshis`, specified earlier

darosior · 2019-10-30T16:21:28Z

02-peer-protocol.md

+
+### The `funding_signed2` Message
+
+This message contains witness data for for the inputs that were


Suggested change

This message contains witness data for for the inputs that were

This message contains witness data for the inputs that were

darosior · 2019-10-30T16:30:04Z

02-peer-protocol.md

+  - MUST return an error if:
+    - the `feerate_per_kw_funding` is not greater than the previously
+      negotiated rate.
+  - MUST return an error, but not fail the channel if:


How does the remote node know that it should not fail the channel upon receiving the error ?

This is, at best, a case for the 'soft error' idea that @rustyrussell has been talking about. Clearly the node that sent you the init_rbf is confused, the polite thing to do in the case is to inform them that they've made a mistake. The other option, without a 'soft error' is probably to ignore the init_rbf request entirely.

You make a good point though, what we really want here is that a node MUST NOT send an init_rbf if it has already sent a funding_locked message.

darosior · 2019-10-30T16:33:45Z

02-peer-protocol.md

+    * [`u16`:`num_outputs`]
+    * [`num_outputs*output_info`:`output_info`]
+
+#### Requirements


As it has been stated for other messages, maybe :

Either node: - MAY omit this message

?

darosior · 2019-10-30T16:36:01Z

02-peer-protocol.md

+  - MAY include additional inputs.
+  - MAY set the `num_inputs` to zero.
+  - MUST transmit all outputs, excluduing the channel funding output.
+  - MAY include at least one output with the `sats` set to zero,


Should we also specify which output to reduce ?

Hmm reading further it seems that the opener should pay for the fees. Maybe we then should explicit the receiver of init_rbf to check that the reduced (or removed) output is receiver's change ?

Well, retransmitting all of the outputs would give you the opportunity to update the outputs as necessary.

The change output is calculated dynamically by each of the peers, and is identifiable in the output set as "the output of value zero", so you wouldn't need to update it. In fact, the change calculation should 1) drop the change output if it's below dust and 2) add or subtract any resultant amount to the opener's satoshis in the funding output. So, you wouldn't need to update the outputs on an rbf, unless you wanted to preserve your funding output's value.

So, you wouldn't need to update the outputs on an rbf, unless you wanted to preserve your funding output's value.

That's what I assumed: doesn't it make it more simple for both participants if the funding amount stayed the same but the fee bump was taken on the change output of the funder instead ?
Since both add inputs to the tx, they will most likely also include change outputs, at least that what I assumed when writing that.
My question was then whether to introduce an explicit MUST on the receiver side to check that the tx the funder sends does not greeds on the fundee's change output (which implems would of course do, but ..)

But maybe I'm missing something here ?

That's what I assumed: doesn't it make it more simple for both participants if the funding amount stayed the same but the fee bump was taken on the change output of the funder instead ?

It's up to the funder to know what it's estimated change burden will be and add sufficient funds such that the total amount of funding is untouched by a fee-bump, if that's what they desire.

does not greeds on the fundee's change output (which implems would of course do, but ..)

Fees never come out of the accepter's change; though it might (hypothetically) start eating out of their funding balance if the opener's balance is consumed by change. Reconsidering this and the point you made earlier, a nack_rbf message (or a 'soft-error') might be appropriate here. This would allow the second node to disallow a fee update that would eat into the entirety of the fundchannel amount.

ariard

Really cool work! Thanks to pushing this forward

What's your thoughts about splitting the transaction composition part to enable batching from the dual-funding channel part ? There is at least 3 cases where it may be reused :

channel closing
channel novation (or splicing)
channel opening

I think you need one party among all being the coordinator to act as tie-breaker and avoid endless input/output add, fees changes dependencies (though there is other design issue like fees management, belongs more to the ml)

niftynei · 2020-01-28T19:38:22Z

09-features.md

 | 10/11 | `gossip_queries_ex`              | Gossip queries can include additional information                         | [BOLT #7][bolt07-query]      |
-| 12/13| `option_static_remotekey`     | Static key for remote output                                              | [BOLT #3](03-transactions.md)    |
+| 12/13 | `option_static_remotekey`        | Static key for remote output                                              | [BOLT #3](03-transactions.md)|
+| 28/29 | `option_dual_fund`               | Use v2 of channel open, enables dual funding                              | [BOLT #2](02-peer-protocol)  |


are we waiting on a spec change for 'N+/-', it's not currently listed in the features doc (but C+/- is)

Yes, we need to discuss this during the next meeting, but we still need some clarifying on feature bits (potentially the N+/N- modifiers).

niftynei · 2020-01-27T22:13:22Z

02-peer-protocol.md

+
+Accepter sends their `funding_satoshi` value here instead of allowing the opener to derive
+it from their `funding_compose` response so that the opener can notionally decide whether
+to complete the opening without exposing their output set.


Vectors for revelation of your utxo set heavily depends on how much/how many inputs an accepter chooses to contribute to a channel, and will vary depending on the policy individual nodes set for their threshold and amount they've decided to contribute to a channel.

Currently, the c-lightning implementation mitigates this (slightly) by promoting any exposed utxos to be first eligible for spending. A repeated inquiry should expose the exact same utxos, until they're spent.

02-peer-protocol.md

+    - MUST send at least one `funding_add_input` message
+    - MUST NOT send a total count of more than 64 inputs, across all `funding_add_input` messages.
+  - if is the `accepter`:
+    - MAY omit this message


niftynei · 2020-01-28T19:39:51Z

02-peer-protocol.md

+  - MAY omit this message
+
+The sending node:
+  - MUST NOT send `funding_add_input` if it has already transmitted `funding_add_complete`


i'm not sure this is common sense -- it needs to be specified somewhere

niftynei · 2020-01-27T22:14:22Z

02-peer-protocol.md

+  - MUST send this after `accept_channel2` has been exchanged, but before `funding_add_complete`
+  - MUST add all sent inputs to the funding transaction
+  - MUST NOT re-transmit inputs it has already received from the peer
+  - MUST ensure each `input_info` refers to a non-malleable (segwit) UTXO.


Oh good point. This isn't currently checked on funding transactions.

niftynei · 2020-01-28T01:24:12Z

02-peer-protocol.md

+of zero. This will be used for change, or discarded if its value is
+be below `dust_limit_satoshis`.
+
+Change is calculated as the sum of the opener's `input_info`.`sats`


Yess, I've got a draft for how to re-distribute fees (and a tweak to this protocol) I'm about to send to the mailing list. :)

02-peer-protocol.md

+the `funding_txid`, instead of the `temporary_node_id`.
+
+
+### The `funding_signed2` Message


niftynei · 2020-01-28T01:20:26Z

02-peer-protocol.md

+  - MUST send a `feerate_per_kw_funding` greater than the most recently
+    negotiated rate.
+  - MAY update the `feerate_per_kw`, the commitment transaction feerate.
+  - MAY include additional inputs.


This is a misinterpretation of rule 2; an "unconfirmed input" is a utxo that has not yet been confirmed in a block (mined).

The replacement transaction may only include an unconfirmed input if that input was included in one of the original transactions. (An unconfirmed input spends an output from a currently-unconfirmed transaction.)

I think this is an oversight of the spec though; it should strictly exclude unconfirmed inputs (and thus disallow chaining), as they're difficult for the peer to verify.

niftynei · 2020-01-28T01:15:54Z

02-peer-protocol.md

+RBF workflow, the RBF attempt MUST be abandoned.
+
+
+### Acknowledging Replace-By-Fee `ack_rbf`


good point, i think it is infact superfluous.

update: in order to avoid reversing the order of commitment_signed exchange, you need to get at least one message back from the peer before you send them the commitment_signed message.

niftynei · 2020-01-27T22:17:12Z

02-peer-protocol.md

+transaction has been broadcast but before a `funding_locked` message
+is exchanged.
+
+Once an `init_rbf` message has been successfully ack'd by the accepter


I believe you mean 'output available to cpfp'. :)

Including an output for CPFP might be one strategy here, but there's no reason to make it standard in the spec, as its not required and if not a 'useful' output (i.e. a withdrawal or another closing output etc) contributes to utxo bloat.

Given that RBF is an option for opening transactions, it seems reasonable to not make CPFP mandatory here.

t-bast

This is really nicely spec-ed, thanks @niftynei !

It's honestly a bit hard for me to find meaningful design comments without trying to implement this, at first glance it looks good and there are already many interesting discussions/comments.

I was wondering how the batching would work in terms of fees. If we have A <-> B <-> C, it seems to me that the naive version would have A pay all the fees, which is quite unfair (A shouldn't pay for a B <-> C channel). How do you think distributing the fee between all openers would work?

t-bast · 2020-01-21T13:45:41Z

02-peer-protocol.md

+
+The receiving node:
+  - if the `witness_stack` length exceeds `max_witness_len`:
+    - MUST error.


What does that mean exactly? Sending an error message to the other party and forgetting everything about this channel creation attempt?

I haven't thought about it deeply enough yet, but I feel that aborting during the funding flow may have some subtle edge cases. Are there some gotchas you ran into while implementing?

Hmm. You've highlighted what I believe is the most subjective error case.

How the opener chooses to handle this is hard to enforce. At this point, they have all the information necessary to successfully broadcast the transaction (the accepter is the only peer that transmits their signatures). If they choose to accept the lower effective feerate anyway and broadcast the tx, there's nothing stopping them. What we're looking to accomplish is incentivize the peer (accepter) to provide an accurate witness length, so that the agreed upon feerate is accurate. The way I've chosen to incentivize this is by threatening that the opener will cancel the open on them.

So yes, the opener would send the peer and error message and, ideally, spend an input to the tx such that the opening transaction was definitively invalidated.

niftynei

Thanks for the most recent feedback @t-bast and @ariard. I just sent a message to the mailing list with a draft proposal for how to break out a more "universal collaborative transaction" protocol. It's a bit different than the protocol proposed here (namely in that it includes two removal messages), but should be largely compatible with the work already specified herein.

First draft of flow for v2 of channel establishment.

since we now require the opener to 'pre-send' the total number of inputs and outputs that they're going to be including in the funding tx, if the number of actual inputs and outputs that they send is less than this, we can fail the channel. we do this because we base our input selection on the number of inputs and outputs that they send. having a lower number means that we might be in violation of the rule so we fail this requirement also

fixes incorrect calculation of funding output's weight.

for v2 channel establishment we switch from the temporary channel_id to the channel_id derived from the funding_txid after both funding_compose messages have been exchanged, as at this point both opener/accepter have the ability to derive the funding_txid which is required for the channel_id.

On further consideration, the channel_id encapsulates all of the necessary info to determine which funding transaction attempt that the funding_locked message pertains to

We fix the total permitted contribution from the acceptor node to 4, and remove it from the protocol.

Fix the reserve to always be 1% of the channel balance, or the dust_limit, whichever is greater. This reduces the complexity around calculating the reserve balance.

Shorten the round trips required by only having the accepter send their sigs to the opener. This means only the opener is able to compose the funding transaction completely, and that only they are in control of publishing it, which is the same as current implementations.

Break funding_compose into 3 messages, to allow for asynchronous input and output construction. This is done to enable multi-party funding transaction construction

Further limit the total inputs/outputs allowed from a peer

@darosior

Reported-By: @darosior

Makes a non-malleable input more concise, and adds missing restriction that input must be confirmed, i.e. mined.

ecdsa · 2020-12-27T18:59:48Z

@rustyrussell suggested to add Lloyd Fournier's deterministic generation of funding output to this PR, see https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-December/002910.html

niftynei · 2021-04-01T19:22:44Z

Superceded by #851

rustyrussell reviewed Dec 10, 2018

View reviewed changes

rustyrussell added this to the v1.1 milestone Dec 10, 2018

niftynei mentioned this pull request Dec 11, 2018

Is it possible to make payment channel by both participants' funding? ElementsProject/lightning#2107

Closed

niftynei force-pushed the dual-funding branch from 00c6e6f to 8bacfe4 Compare February 6, 2019 02:20

niftynei changed the title ~~WIP: dual funding first draft~~ WIP: Dual Funding (v2 Channel Establishment protocol) Feb 6, 2019

rustyrussell requested changes Mar 4, 2019

View reviewed changes

niftynei force-pushed the dual-funding branch 2 times, most recently from 3cb65ff to 4c0a516 Compare March 7, 2019 23:33

niftynei force-pushed the dual-funding branch 3 times, most recently from bc409b8 to cb8990b Compare April 3, 2019 00:33

niftynei force-pushed the dual-funding branch from 7d50c70 to 2b1cf09 Compare July 24, 2019 02:12

niftynei force-pushed the dual-funding branch from 2b1cf09 to 1a9a018 Compare October 1, 2019 02:30

niftynei mentioned this pull request Oct 1, 2019

experimental: dual-funding (II of IV) ElementsProject/lightning#3122

Closed

niftynei force-pushed the dual-funding branch from 1a9a018 to 867a6d8 Compare October 11, 2019 19:51

darosior reviewed Oct 30, 2019

View reviewed changes

carlaKC mentioned this pull request Nov 4, 2019

[Feature Request] mutually funded channels implementation lightningnetwork/lnd#3673

Closed

niftynei mentioned this pull request Jan 17, 2020

dual-funding, the monster ElementsProject/lightning#3418

Closed

6 tasks

ariard reviewed Jan 21, 2020

View reviewed changes

t-bast mentioned this pull request Jan 21, 2020

BOLT 02: opt-in dual-funding #184

Closed

t-bast reviewed Jan 21, 2020

View reviewed changes

niftynei force-pushed the dual-funding branch from f150a15 to 45fbb33 Compare January 24, 2020 18:10

niftynei commented Jan 28, 2020

View reviewed changes

niftynei force-pushed the dual-funding branch from 45fbb33 to eb9bec1 Compare January 28, 2020 19:19

features: add option for dual funding

944bcce

niftynei force-pushed the dual-funding branch 2 times, most recently from ebfdc9e to 36561fc Compare January 28, 2020 19:50

niftynei added 2 commits January 28, 2020 12:12

peer: add v2 for open_channel

5a748ae

First draft of flow for v2 of channel establishment.

peer-protocol: remove commitment_signed2 message

a119f07

niftynei added 25 commits January 28, 2020 12:12

dual-funding: fixup egregious weight calculation in Appendix

e067a61

fixes incorrect calculation of funding output's weight.

fixup: spacing error with contrib-count

d8f3a11

dual-funding: remove the funding_locked2 message

14b55f9

On further consideration, the channel_id encapsulates all of the necessary info to determine which funding transaction attempt that the funding_locked message pertains to

fixup: update types to new represenations

363ca15

fixup: rename 'satoshis' so our checks work

04c9fd2

revert later: make opener->funder so BOLT checks pass

65ee3db

fixup length count and update transaction with new data

eb7d517

df: remove contribution count, fix at 4.

3a3e4ff

We fix the total permitted contribution from the acceptor node to 4, and remove it from the protocol.

df: remove channel_reserve_satoshis from openchannel2

c06d7b7

Fix the reserve to always be 1% of the channel balance, or the dust_limit, whichever is greater. This reduces the complexity around calculating the reserve balance.

df: add separate tlv type for accept_channel2

140ab5b

update feature number briefly

d1df2a1

dual funding: break up funding composition messages

afbf8d2

Break funding_compose into 3 messages, to allow for asynchronous input and output construction. This is done to enable multi-party funding transaction construction

dual-funding: fixup some wording on the RBF section

a233f57

dual-funding: reduce total input/outputs from the accepter

5dd384a

Further limit the total inputs/outputs allowed from a peer

fixup: wording, spelling and logic/duplication errors

40c0b80

Reported-By: @darosior

df: clarify handling of dust-limit for funding tx

761bc13

df: normalize type numbers

c2de44f

cleanup duplicative omit message

8c92423

add note about ignoring bad funding_signed2 msg

8aca867

fixup! remove invalid requirement

a960a1b

fixup: remove redundant/verbose wording

5800879

df: clarify that an input cannot be malleable and add new restriction

2e40838

Makes a non-malleable input more concise, and adds missing restriction that input must be confirmed, i.e. mined.

niftynei force-pushed the dual-funding branch from 36561fc to 2e40838 Compare January 28, 2020 20:13

SomberNight mentioned this pull request Feb 26, 2021

Consider setting RBF flag for Lightning funding transactions spesmilo/electrum#7072

Open

niftynei closed this Apr 1, 2021

	- MUST not send `open_channel`
	- MUST NOT send `open_channel`

	the funding_sats, specified earlier
	the `funding_satoshis`, specified earlier


		### The `funding_signed2` Message

		This message contains witness data for for the inputs that were

	This message contains witness data for for the inputs that were
	This message contains witness data for the inputs that were

		the `funding_txid`, instead of the `temporary_node_id`.


		### The `funding_signed2` Message

		RBF workflow, the RBF attempt MUST be abandoned.


		### Acknowledging Replace-By-Fee `ack_rbf`

WIP: Dual Funding (v2 Channel Establishment protocol) #524

WIP: Dual Funding (v2 Channel Establishment protocol) #524

Uh oh!

Conversation

niftynei commented Dec 5, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustyrussell left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

niftynei Mar 6, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

niftynei commented Apr 30, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

niftynei commented Dec 5, 2018 •

edited

Loading

niftynei Mar 6, 2019 •

edited

Loading

niftynei commented Apr 30, 2019 •

edited

Loading

niftynei Nov 13, 2019 •

edited

Loading