<div dir="ltr"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
> +----+ +----+<br>
> where node A is the ‘initiator’ and node B is the ‘dual-funder’<br>
<br>
We currently use the terms funder and fundee, which are now<br>
inaccurate ofc. Perhaps 'opener' and 'accepter' are not great english,<br>
but they map to the messages well?<br></blockquote><div><br></div><div>'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.</div><div><br></div><div>"Another subtle point is the feerate_per_kw field; in the old scheme it<br>applied to the first commitment tx, but here it applies to both the<br>first commitment tx and the funding tx itself"<br></div><div><br></div><div>You're right. Initially I didn't think the `accepter` would care since they're not paying them, </div><div>but you need it to be able to construct the funding transaction. I'll add a second field, it seems</div><div>important to keep them separated esp since the timing consideration for the fees is different (now vs the future).</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> The sending node:<br>
> -<br>
> MAY begin channel establishment using `open_channel2`<br>
<br>
- MUST NOT send `open_channel`.<br>
<br>
> Otherwise the receiving node:<br>
> -<br>
> MUST return an error.<br>
<br>
This is a requirement for receiving `open_channel` IIUC?<br>
<br>
ie.<br>
<br>
The receiving node MUST fail the channel if:<br>
...<br>
- `option_dual_fund` has been negotiated.<br></blockquote><div><br></div><div>Does v2 of channel open necessarily deprecate the original between two upgraded nodes? </div><div><br></div><div>This seems more sane than having both as an option...will update.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> ____`funding_puts2`<br>
<br>
We can probably drop the 2 here and call it, um.. `funding_compose`?<br>
(Thanks <a href="http://thesaurus.com" rel="noreferrer" target="_blank">thesaurus.com</a>). I get where you're going with 'puts, but it<br>
took me a while :)</blockquote><div><br></div><div>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.</div><div> </div><div>+1 for `funding_compose`, it's definitely more easily understood. :-D</div><div><br></div><div>...</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> MUST NOT send a number of `input_data` and/or `output_data` which<br>
> exceeds the `put_limit`<br>
<br>
Side note: I wonder if we should relax this limit when we talk about<br>
`option_will_fund_for_food`?<br></blockquote><div><br></div><div>Yes! Thanks for pointing this out.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> -<br>
> MAY send an empty message<br>
<br>
Be explicit? MAY offer zero `num_inputs` and `num_outputs`. That's not<br>
quite an empty message...<br></blockquote><div><br></div><div>I defined it a few lines above, but that's not super easy to see from this. Will fix.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> The receiving node:<br>
><br>
> If is the initiator (A):<br>
><br>
> -<br>
> MUST fail the channel if the `num_inputs` plus `num_outputs` is greater<br>
> than the `put_limit`<br>
<br>
How about MAY? It's a protection thing, but less to change when we<br>
option_will_fund_for_food. Unless we set the `put_limit` to min (4) or<br>
something in that case?<br></blockquote><div><br></div><div>+1 for MAY, considering that the opener will be paying the fees. </div><div>The limit for what's reasonable to pay is fairly subjective, i.e. perhaps the opener doesn't</div><div> care how many inputs/outputs the acceptor adds.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Oh, it needs to check max_extra_witness_len is reasonable too, since<br>
that will affect the fees. Each signature adds 74, and pubkey adds 34,<br>
so I think MUST BE less than 500 is perfectly reasonable (for both<br>
reader and writer).<br></blockquote><div><br></div><div>Ack</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> ___`funding_locked2`<br>
><br>
> // same as v1<br>
><br>
> Requirements:<br>
><br>
> A dual-funding node (B):<br>
><br>
> -<br>
><br>
> SHOULD broadcast their funding transaction if it does not see the<br>
> transaction broadcast after a reasonable timeout.<br>
<br>
Let's just reuse `funding_locked` maybe?<br>
<br>
Not sure why this should wait for broadcast?<br></blockquote><div><br></div><div>I was overthinking this*. Can't think of a reason for both sides not to broadcast; will amend.</div><div> </div><div>* confused it with conflicting transaction broadcast behavior</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> == RBF for Channel Establishment v2<br>
><br>
> _____`init_rbf`<br>
><br>
> This message is sent by the initiator, after the funding transaction has<br>
> been broadcast but before the `funding_locked2` has been exchanged.<br>
><br>
> [32: `channel_id`]<br>
> [8: funding_satoshis]<br>
> [8:dust_limit_satoshis]<br>
> [8:channel_reserve_satoshis]<br>
> [4: feerate_per_kw]<br>
> [`2`:`num_inputs`]<br>
> [`num_inputs*input_info`]<br>
> [`2`:`num_outputs`]<br>
> [`num_outputs`*ouput_info`]<br>
<br>
Typo again :)<br>
<br>
> Requirements<br>
><br>
> The sending node:<br>
> - MUST be the initiator (A)<br>
> - MAY update the amount, fee rate, dust limit, or channel reserve for the<br>
> channel<br>
<br>
- MAY send init_rbf if it considers the most recent funding tx unlikely<br>
to be confirmed in reasonable time.<br>
- MUST set `feerate_per_kw` larger than the most recent funding tx.<br></blockquote><div><br></div><div>Another good reason to break out `funding_txn_feerate_per_kw` from</div><div>`commitment_txn_feerate_per_kw` in `open_channel2`</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Do we really want to negotiate everything again? It seems like the<br>
funder should be able to maybe add *new* inputs and outputs (though TBH<br>
I think that's going to be unusual enough that we could omit it), but<br>
doing a wholesale replacement means we have to be careful that the all<br>
RBFs end up having at least one input in common. Yech.<br></blockquote><div><br></div><div>Only allowing the opener to add new inputs/outputs drives down the scope of a RBF a good deal. I like it.</div><div>Adding new inputs seems like a common sense bare minimum, especially if we </div><div>assume wildly unpredictable fee rates.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
><br>
> Rationale:<br>
><br>
> Once an `init_rbf` has been accepted by the dual-funding node, the message<br>
> flow returns to `commitment_signed2` and proceeds as above, with the<br>
> exception that the `temporary_channel_id` remains as the `channel_id` for<br>
> the currently published but unmined transaction.<br>
<br>
By this stage, we are no longer using temporary_channel_id though.<br>
<br>
But it's an excellent point I had missed. The channel_id changes on<br>
each renegotiation. We could either switch channel_id *after*<br>
each accept_rbf, or keep the original channel_id until funding_locked2 (in<br>
which case it should have a "final_channel_id" field, to make sure we're<br>
talking about the same funding tx).<br>
<br>
Since we have to handle the "oops, old one got in!" it might be weird to<br>
see `funding_locked2` with an old txid. Perhaps we stick with the<br>
original channel_id until then, and flip *after* funding_locked2 is sent<br>
and received.<br>
<br></blockquote><div><br></div><div>Would it be more sane to continue to include the temporary channel id, </div><div>in addition to the 'current' (i.e. most recently negotiated funding txn) channel id,</div><div>until the funding_locked2 is sent (adds a `temporary_channel_id` field for </div><div>`commitment_signed2`, ` funding_signed2` and `funding_locked2`, in addition to `channel_id`)? </div><div>That way, all opening messages would have a stable id across an RBF re-negotiation, `temp_channel_id`.</div><div>Sticking with the first broadcast funding transaction hash feels</div><div>a bit misleading in the case of a second round of `commitment_signed2` and `funding_signed2`.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
And yeah, no `update_fee`, `announcement_signatures` until that<br>
funding_locked2 exchange is complete, so we don't get those with an<br>
unsettled channel_id.<br>
<br>
> The channel id that becomes fixed for this node will be determined by the<br>
> `funding_locked2` message.<br>
><br>
> ___`accept_rbf`<br>
><br>
> This message accepts an RBF request, and renegotiates a dual-funder’s<br>
> funds, dust limit, and channel reserve, and sends the dual-funder’s updated<br>
> puts.<br>
<br>
I would make this an empty message, simply an ack. And note that<br>
the channel_id after this is that of the RBFed tx.<br>
<br>
The question then becomes what do we do about reconnection. I suggest:<br>
<br>
opener: if we haven't sent funding_signed, consider it cancelled. If<br>
we've received funding_signed, it's obviously locked in. If we sent<br>
and didn't received, re-xmit.<br>
<br>
accepter: must remember rbf if we sent commitment_signed2. If we<br>
received funding_signed it's locked in. If we receive an init_rbf,<br>
drop the one we remembered. If we receive funding_signed, continue.<br>
<br>
We still need to address the funding_tx construction; BIP69-style seems<br>
like an unnecessary information leak here. A 128-bit seed in<br>
open_channel2 could be added, with sorting by SHA(seed | <marshal of<br>
input> | <marshal of witness>) and SHA(seed | <marshal of output>)?<br>
<br>
Phew!<br>
Rusty.<br>
</blockquote></div></div></div>