<div dir="ltr"><div>> Mainly limitations of our descriptor language, TBH. </div><div> </div><div>I don't follow...so it's a size issue? Or wanting to avoid "repeated"</div><div>fields?</div><div><br></div><div>> I thought about restarting the revocation sequence, but it seems like that</div><div>> only saves a tiny amount since we only store log(N) entries</div><div><br></div><div>Yeah that makes sense, forgetting the HTLC state is a big enough win in and</div><div>of itself.</div><div><br></div><div>>>> Splice Signing</div><div>>></div><div>>> It seems that we're missing some fields here if we're to allow the splicing</div><div>>> of inputs to be done in a non-blocking manner. We'll need to send two</div><div>>> revocation points for the new commitment: one to allow it to be created, and</div><div>>> another to allow updates to proceed right after the signing is completed. In</div><div>>> this case we'll also need to update both commitments in tandem until the</div><div>>> splicing transaction has been sufficiently confirmed.</div><div>></div><div>>I think we can use the existing revocation points for both.</div><div><br></div><div>Yep, if we retain the existing shachain trees, then we just continue to</div><div>extend the leaves!</div><div><br></div><div>> We're basically co-generating a tx here, just like shutdown, except it's</div><div>> funding a new replacement channel. Do we want to CPFP this one too?</div><div><br></div><div>It'd be nice to be able to also anchor down this splicing transaction given</div><div>that we may only allow a single outstanding splicing operation to begin</div><div>with. Being able to CPFP it (and later on provide arbitrary fee inputs)</div><div>allows be to speed up the process if I want to queue another operation up</div><div>right afterwards.</div><div><br></div><div>-- Laolu</div><div><br></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 17, 2018 at 9:31 AM Rusty Russell <<a href="mailto:rusty@rustcorp.com.au">rusty@rustcorp.com.au</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Olaoluwa Osuntokun <<a href="mailto:laolu32@gmail.com" target="_blank">laolu32@gmail.com</a>> writes:<br>
> Hi Rusty,<br>
><br>
> Happy to get the splicing train rolling!<br>
><br>
>> We've had increasing numbers of c-lightning users get upset they can't<br>
>> open multiple channels, so I guess we're most motivated to allow splicing<br>
> of<br>
>> existing channels<br>
><br>
> Splicing isn't a substitute for allowing multiple channels. Multiple<br>
> channels allow nodes to:<br>
><br>
> * create distinct channels with distinct acceptance policies.<br>
> * create a mix of public and non-advertised channels with a node.<br>
> * be able to send more than the (current) max HTLC amount<br>
> using various flavors of AMP.<br>
> * get past the (current) max channel size value<br>
> * allow a link to carry more HTLCs (due to the current super low max HTLC<br>
> values) given the additional HTLC pressure that<br>
> AMP may produce (alternative is a commitment fan out)<br>
<br>
These all seem marginal to me. I think if we start hitting max values,<br>
we should discuss increasing them.<br>
<br>
> Is there a fundamental reason that CL will never allow nodes to create<br>
> multiple channels? It seems unnecessarily limiting.<br>
<br>
Yeah, we have a daemon per peer. It's really simple with 1 daemon, 1<br>
channel. My own fault: I was the one who insisted we mux multiple<br>
connections over the same transport; if we'd gone for independent<br>
connections our implementation would have been trivial.<br>
<br>
>> Splice Negotiation:<br>
><br>
> Any reason to now make the splicing_add_* messages allow one to add several<br>
> inputs in a single message? Given "acceptable" constraints for how large the<br>
> witness and pkScripts can be, we can easily enforce an upper limit on the<br>
> number of inputs/outputs to add.<br>
<br>
Mainly limitations of our descriptor language, TBH. <br>
<br>
> I like that the intro messages have already been designed with the<br>
> concurrent case in mind beyond a simpler propose/accept flow. However is<br>
> there any reason why it doesn't also allow either side to fully re-negotiate<br>
> _all_ the funding details? Splicing is a good opportunity to garbage collect<br>
> the prior revocation state, and also free up obsolete space in watch towers.<br>
<br>
I thought about restarting the revocation sequence, but it seems like<br>
that only saves a tiny amount since we only store log(N) entries. We<br>
can drop old HTLC info post-splice though, and (after some delay for<br>
obscurity) tell watchtowers to drop old entries I think.<br>
<br>
> Additionally, as the size of the channel is either expanding or contracting,<br>
> both sides should be allowed to modify things like the CSV param, reserve,<br>
> max accepted htlc's, max htlc size, etc. Many of these parameters like the<br>
> CSV value should scale with the size of the channel, not allowing these<br>
> parameters to be re-negotiated could result in odd scenarios like still<br>
> maintain a 1 week CSV when the channel size has dipped from 1 BTC to 100k<br>
> satoshis.<br>
<br>
Yep, good idea! I missed that.<br>
<br>
Brings up a side point about these values, which deserves its own<br>
post...<br>
<br>
>> 1. type: 40 (`splice_add_input`) (`option_splice`)<br>
><br>
> In order to add nested p2sh inputs, we'll need to also expose the redeem<br>
> script here, or add additional fields to allow sides to set a sig script as<br>
> well as witness during the signing phase.<br>
><br>
>> - scriptpubkey is empty, or of form 'HASH160 <20-byte-script-hash> EQUAL'<br>
><br>
> So no P2SH? :(<br>
<br>
Another omission, yeah, we'd want that too I think.<br>
<br>
>> * [`4`:`feerate_per_kw`]<br>
><br>
> What fee rate is this? IMO we should do commitmentv2 before splicing as then<br>
> we can more or less do away with the initiator distinction and have most<br>
> fees be ad hoc.<br>
<br>
We're basically co-generating a tx here, just like shutdown, except it's<br>
funding a new replacement channel. Do we want to CPFP this one too?<br>
<br>
>> Splice Signing<br>
><br>
> It seems that we're missing some fields here if we're to allow the splicing<br>
> of inputs to be done in a non-blocking manner. We'll need to send two<br>
> revocation points for the new commitment: one to allow it to be created, and<br>
> another to allow updates to proceed right after the signing is completed. In<br>
> this case we'll also need to update both commitments in tandem until the<br>
> splicing transaction has been sufficiently confirmed.<br>
<br>
I think we can use the existing revocation points for both.<br>
<br>
> Also, what about change addresses? Are they to be explicitly specified as<br>
> splice outs?<br>
<br>
They'd be splice-outs, yeah.<br>
<br>
>> 1. type: 43 (`splice_commitment_signature`) (`option_splice`)<br>
><br>
> It may be worth pointing out there that we're able to transfer all existing<br>
> HTLCs over to the new commitment as additional context.<br>
<br>
Yeah, I think people missed that it was non-blocking like that.<br>
<br>
>> 1. type: 45 (`splice_witness`) (`option_splice`)<br>
><br>
> Should also allow either side to specify the sig script here if we're to<br>
> allow nested p2sh (which we should IMO!).<br>
<br>
Yep.<br>
<br>
>> * [`2`:`len`]<br>
>> * [`len`:`witnesses`]<br>
><br>
> Is the extra length needed if all the witness elements themselves are length<br>
> delimited?<br>
<br>
Yes, we always length-delimit fields so we can add options later.<br>
<br>
><br>
> It isn't clear in the current draft, but I take it that the splice_signature<br>
> is for the old multi-sig?<br>
<br>
Yes, that's the signature required to spend the old funding txout.<br>
<br>
>> so we append to the existing `channel_update` for the original channel,<br>
>> using a new `message_flags` field:<br>
><br>
> IMO, we need to hold off on optional fields for now, until we revisit the<br>
> formatting in order to actually get it right. As is now, all the optional<br>
> fields are basically serial mandatory soft forks. So clients must understand<br>
> the prior in order to understand the following fields. Instead, we<br>
> essentially need more of a map design.<br>
<br>
You need to add prior options to your wire parser, but that's usually<br>
the most trivial part of handling them. And they may waste space on the<br>
wire since we treat them as append-only, but OTOH it avoids<br>
combinatorial testing explosion.<br>
<br>
>> The post-splice reserve is 1% of post-splice capcacity (rounded down).<br>
><br>
> This should be re-negotiated at time of splice creation, rather than a new<br>
> hard coded value in the protocol.<br>
><br>
>> In addition, you can forget everything about the old channel (including<br>
>> old HTLCs and revocation requirements).<br>
><br>
> We still have the same shachain state however (if we don't allow new state<br>
> to be exchanged during the start of the splicing scenario), correct?<br>
<br>
Yep.<br>
<br>
Thanks,<br>
Rusty.<br>
<br>
> -- Laolu<br>
><br>
> -- Laolu<br>
<br>
PS, Damn, I always suspected there were multiple Roasbeefs, and we're simply<br>
dealing with the output of an advanced multiplexing protocol. I present<br>
the above as conclusive evidence of this thesis...<br>
</blockquote></div></div>