[Lightning-dev] Dual Funding Proposal

lisa neigut niftynei at gmail.com
Mon Dec 3 18:33:16 UTC 2018

> >    +----+                              +----+
> >   where node A is the ‘initiator’ and node B is the ‘dual-funder’
> We currently use the terms funder and fundee, which are now
> inaccurate ofc.  Perhaps 'opener' and 'accepter' are not great english,
> but they map to the messages well?

'opener' and 'accepter' do map to the messages. I've adopted it for the
rest of this response, to see how it fits in context.

"Another subtle point is the feerate_per_kw field; in the old scheme it
applied to the first commitment tx, but here it applies to both the
first commitment tx and the funding tx itself"

You're right. Initially I didn't think the `accepter` would care since
they're not paying them,
but you need it to be able to construct the funding transaction. I'll add a
second field, it seems
important to keep them separated esp since the timing consideration for the
fees is different (now vs the future).

> The sending node:
> >    -
> >    MAY begin channel establishment using `open_channel2`
>  - MUST NOT send `open_channel`.
> > Otherwise the receiving node:
> >    -
> >    MUST return an error.
> This is a requirement for receiving `open_channel`  IIUC?
> ie.
> The receiving node MUST fail the channel if:
>    ...
>    - `option_dual_fund` has been negotiated.

Does v2 of channel open necessarily deprecate the original between two
upgraded nodes?

This seems more sane than having both as an option...will update.

> > ____`funding_puts2`
> We can probably drop the 2 here and call it, um.. `funding_compose`?
> (Thanks thesaurus.com).  I get where you're going with 'puts, but it
> took me a while :)

Initially only the duplicated messages had the 2-suffix, but ended up
adding it to all of them to denote that they belonged to the v2 of channel
open... I can see how that's confusing though.

+1 for `funding_compose`, it's definitely more easily understood. :-D


> >    MUST NOT send a number of `input_data` and/or `output_data` which
> >    exceeds the `put_limit`
> Side note: I wonder if we should relax this limit when we talk about
> `option_will_fund_for_food`?

Yes! Thanks for pointing this out.

> >    -
> >    MAY send an empty message
> Be explicit? MAY offer zero `num_inputs` and `num_outputs`.  That's not
> quite an empty message...

I defined it a few lines above, but that's not super easy to see from this.
Will fix.

> > The receiving node:
> >
> >   If is the initiator (A):
> >
> >    -
> >    MUST fail the channel if the `num_inputs` plus `num_outputs` is
> greater
> >    than the `put_limit`
> How about MAY?  It's a protection thing, but less to change when we
> option_will_fund_for_food.  Unless we set the `put_limit` to min (4) or
> something in that case?

+1 for MAY, considering that the opener will be paying the fees.
The limit for what's reasonable to pay is fairly subjective, i.e. perhaps
the opener doesn't
 care how many inputs/outputs the acceptor adds.

> Oh, it needs to check max_extra_witness_len is reasonable too, since
> that will affect the fees.  Each signature adds 74, and pubkey adds 34,
> so I think MUST BE less than 500 is perfectly reasonable (for both
> reader and writer).


> > ___`funding_locked2`
> >
> > // same as v1
> >
> > Requirements:
> >
> > A dual-funding node (B):
> >
> >    -
> >
> >    SHOULD broadcast their funding transaction if it does not see the
> >    transaction broadcast after a reasonable timeout.
> Let's just reuse `funding_locked` maybe?
> Not sure why this should wait for broadcast?

I was overthinking this*. Can't think of a reason for both sides not to
broadcast; will amend.

* confused it with conflicting transaction broadcast behavior

> > == RBF for Channel Establishment v2
> >
> > _____`init_rbf`
> >
> > This message is sent by the initiator, after the funding transaction has
> > been broadcast but before the `funding_locked2` has been exchanged.
> >
> > [32: `channel_id`]
> > [8: funding_satoshis]
> > [8:dust_limit_satoshis]
> > [8:channel_reserve_satoshis]
> > [4: feerate_per_kw]
> > [`2`:`num_inputs`]
> > [`num_inputs*input_info`]
> > [`2`:`num_outputs`]
> > [`num_outputs`*ouput_info`]
> Typo again :)
> > Requirements
> >
> > The sending node:
> >    - MUST be the initiator (A)
> >    - MAY update the amount, fee rate, dust limit, or channel reserve for
> the
> >    channel
>  - MAY send init_rbf if it considers the most recent funding tx unlikely
>    to be confirmed in reasonable time.
>  - MUST set `feerate_per_kw` larger than the most recent funding tx.

Another good reason to break out `funding_txn_feerate_per_kw` from
`commitment_txn_feerate_per_kw` in `open_channel2`

> Do we really want to negotiate everything again?  It seems like the
> funder should be able to maybe add *new* inputs and outputs (though TBH
> I think that's going to be unusual enough that we could omit it), but
> doing a wholesale replacement means we have to be careful that the all
> RBFs end up having at least one input in common.  Yech.

Only allowing the opener to add new inputs/outputs drives down the scope of
a RBF a good deal. I like it.
Adding new inputs seems like a common sense bare minimum, especially if we
assume wildly unpredictable fee rates.

> >
> > Rationale:
> >
> > Once an `init_rbf` has been accepted by the dual-funding node, the
> message
> > flow returns to `commitment_signed2` and proceeds as above, with the
> > exception that the `temporary_channel_id` remains as the `channel_id` for
> > the currently published but unmined transaction.
> By this stage, we are no longer using temporary_channel_id though.
> But it's an excellent point I had missed.  The channel_id changes on
> each renegotiation.  We could either switch channel_id *after*
> each accept_rbf, or keep the original channel_id until funding_locked2 (in
> which case it should have a "final_channel_id" field, to make sure we're
> talking about the same funding tx).
> Since we have to handle the "oops, old one got in!" it might be weird to
> see `funding_locked2` with an old txid.  Perhaps we stick with the
> original channel_id until then, and flip *after* funding_locked2 is sent
> and received.
Would it be more sane to continue to include the temporary channel id,
in addition to the 'current' (i.e. most recently negotiated funding txn)
channel id,
until the funding_locked2 is sent  (adds a `temporary_channel_id` field for
`commitment_signed2`, ` funding_signed2` and `funding_locked2`, in addition
to `channel_id`)?
That way, all opening messages would have a stable id across an RBF
re-negotiation, `temp_channel_id`.
Sticking with the first broadcast funding transaction hash feels
a bit misleading in the case of a second round of `commitment_signed2` and

> And yeah, no `update_fee`, `announcement_signatures` until that
> funding_locked2 exchange is complete, so we don't get those with an
> unsettled channel_id.
> > The channel id that becomes fixed for this node will be determined by the
> > `funding_locked2` message.
> >
> > ___`accept_rbf`
> >
> > This message accepts an RBF request, and renegotiates a dual-funder’s
> > funds, dust limit, and channel reserve, and sends the dual-funder’s
> updated
> > puts.
> I would make this an empty message, simply an ack.  And note that
> the channel_id after this is that of the RBFed tx.
> The question then becomes what do we do about reconnection.  I suggest:
> opener: if we haven't sent funding_signed, consider it cancelled.  If
>    we've received funding_signed, it's obviously locked in.  If we sent
>    and didn't received, re-xmit.
> accepter: must remember rbf if we sent commitment_signed2.  If we
>    received funding_signed it's locked in.  If we receive an init_rbf,
>    drop the one we remembered.  If we receive funding_signed, continue.
> We still need to address the funding_tx construction; BIP69-style seems
> like an unnecessary information leak here.  A 128-bit seed in
> open_channel2 could be added, with sorting by SHA(seed | <marshal of
> input> | <marshal of witness>) and SHA(seed | <marshal of output>)?
> Phew!
> Rusty.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181203/4ac6a8cb/attachment.html>

More information about the Lightning-dev mailing list