lisa neigut [ARCHIVE] on Nostr: 📅 Original date posted:2018-12-03 📝 Original message: > > > > +----+ +----+ > > ...

📅 Original date posted:2018-12-03
📝 Original message:
>
>
> > +----+ +----+
> > 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>;