[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).
>

Ack


> > ___`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
`funding_signed2`.


> 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