Re: [Lightning-dev] Splicing Proposal: Feedback please!

2018-11-06 Thread ZmnSCPxj via Lightning-dev
Good morning Laolu,

>> I worry about doing away with initiator distinction
>
> Can you re-phrase this sentence? I'm having trouble parsing it, thanks.

The initiator of an action is the node which performs the first step in an 
action.

For instance, when opening a channel, the node which initiates the channel open 
is the initiator.  Even in a dual-funding channel open, we should distinguish 
the initiator.

What I want to preserve (as for current channel opening) is that the initiator 
of an action should be the one to pay any costs or fees to that action.

For instance, when opening a channel, the channel opener is the one who pays 
for all onchain fees related to opening and closing the channel, as the opening 
node is the initiator of the action.

Similarly, for channel splicing, I think it would be wiser to have the 
initiator of the splice be the one, to pay for any onchain fees related to 
splicing (and any backoff/failure path if some backoff is needed), even if the 
other side then also decides to splice in/out some funds together with the 
splice.

To my mind, this is wiser as it reduces the surface of potential attacks in 
case of a bad design or implementation of dual-fund-opening and splicing; to 
engage in the attack, one must be willing to shoulder all the onchain fees, 
which hopefully should somewhat deter all but the most egregious or lopsided of 
attacks.

Regards,
ZmnSCPxj___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


Re: [Lightning-dev] Splicing Proposal: Feedback please!

2018-11-06 Thread Christian Decker
Olaoluwa Osuntokun  writes:

>> However personally I do not really see the need to create multiple
> channels
>> to a single peer, or increase the capacity with a specific peer (via
> splice
>> or dual-funding).  As Christian says in the other mail, this
> consideration,
>> is that it becomes less a network and more of some channels to specific
> big
>> businesses you transact with regularly.
>
> I made no reference to any "big businesses", only the utility that arises
> when one has multiple channels to a given peer. Consider an easier example:
> given the max channel size, I can only ever send 0.16 or so BTC to that
> peer. If I have two channels, then I can send 0.32 and so on. Consider the
> case post AMP where we maintain the current limit of the number of in flight
> HTLCs. If AMP causes most HTLCs to generally be in flight within the
> network, then all of a sudden, this "queue" size (outstanding HTLCS in a
> commitment) becomes more scarce (assume a global MTU of say 100k sat for
> simplicity). This may then promote nodes to open additional channels to
> other nodes (1+) in order to accommodate the increased HTLC bandwidth load
> due to the sharded multi-path payments.

I think I see the issue now, thanks for explaining. However I get the
feeling that this is a rather roundabout way of increasing the
limitations that you negotiated with your peer (max HTLC in flight, max
channel capacity, ...), so wouldn't those same limits also apply across
all channels that you have with that peer? Isn't the real solution here
to lift those limitations?

> Independent on bolstering the bandwidth capabilities of your links to other
> nodes, you would still want to maintain a diverse set of channels for fault
> tolerance, path diversity, and redundancy reasons.

Absolutely agree, and it was probably my mistake for assuming that you
would go for the one peer only approach as a direct result of increasing
bandwidth to one peer.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


Re: [Lightning-dev] Splicing Proposal: Feedback please!

2018-11-06 Thread Rusty Russell
Olaoluwa Osuntokun  writes:
>> Mainly limitations of our descriptor language, TBH.
>
> I don't follow...so it's a size issue? Or wanting to avoid "repeated"
> fields?

Not that smart: tools/extract-formats.py extracts descriptions from the
spec for each message.  It currently requires constants in the field
lengths, and these would be variable.

We'd have to teach it about messages within messages, eg:

1. subtype: 1 (`splice_add_input`)
2. data:
   * [`8`: `satoshis`]
   * [`32`: `prevtxid`]
   * [`4`: `prevtxoutnum`]
   * [`2`: `wscriptlen`]
   * [`wscriptlen`: `wscript`]
   * [`2`: `scriptlen`]
   * [`scriptlen`: `scriptpubkey`]

1. subtype: 2 (`splice_add_output`)
2. data:
   * [`32`:`channel_id`]
   * [`8`: `satoshis`]
   * [`2`: `scriptlen`]
   * [`scriptlen`: `outscript`]

1. type:  40 (`splice_add`) (`option_splice`)
   * [`32`:`channel_id`]
   * [`2`: `num_splice_in`]
   * [`num_splice_in*splice_add_input`: `inputs`]
   * [`2`: `num_splice_out`]
   * [`num_splice_out*splice_add_output`: `outputs`]

>> We're basically co-generating a tx here, just like shutdown, except it's
>> funding a new replacement channel.  Do we want to CPFP this one too?
>
> It'd be nice to be able to also anchor down this splicing transaction given
> that we may only allow a single outstanding splicing operation to begin
> with. Being able to CPFP it (and later on provide arbitrary fee inputs)
> allows be to speed up the process if I want to queue another operation up
> right afterwards.

That has some elegance (we would whatever fee scheme we will use for
commitment txs), but means we will almost always *have* to CPFP, which
is unfortunate for chain bloat.

Cheers,
Rusty.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


Re: [Lightning-dev] Splicing Proposal: Feedback please!

2018-11-05 Thread Olaoluwa Osuntokun
> Mainly limitations of our descriptor language, TBH.

I don't follow...so it's a size issue? Or wanting to avoid "repeated"
fields?

> I thought about restarting the revocation sequence, but it seems like that
> only saves a tiny amount since we only store log(N) entries

Yeah that makes sense, forgetting the HTLC state is a big enough win in and
of itself.

>>> Splice Signing
>>
>> It seems that we're missing some fields here if we're to allow the
splicing
>> of inputs to be done in a non-blocking manner. We'll need to send two
>> revocation points for the new commitment: one to allow it to be created,
and
>> another to allow updates to proceed right after the signing is
completed. In
>> this case we'll also need to update both commitments in tandem until the
>> splicing transaction has been sufficiently confirmed.
>
>I think we can use the existing revocation points for both.

Yep, if we retain the existing shachain trees, then we just continue to
extend the leaves!

> We're basically co-generating a tx here, just like shutdown, except it's
> funding a new replacement channel.  Do we want to CPFP this one too?

It'd be nice to be able to also anchor down this splicing transaction given
that we may only allow a single outstanding splicing operation to begin
with. Being able to CPFP it (and later on provide arbitrary fee inputs)
allows be to speed up the process if I want to queue another operation up
right afterwards.

-- Laolu


On Wed, Oct 17, 2018 at 9:31 AM Rusty Russell  wrote:

> Olaoluwa Osuntokun  writes:
> > Hi Rusty,
> >
> > Happy to get the splicing train rolling!
> >
> >> We've had increasing numbers of c-lightning users get upset they can't
> >> open multiple channels, so I guess we're most motivated to allow
> splicing
> > of
> >> existing channels
> >
> > Splicing isn't a substitute for allowing multiple channels. Multiple
> > channels allow nodes to:
> >
> >   * create distinct channels with distinct acceptance policies.
> >   * create a mix of public and non-advertised channels with a node.
> >   * be able to send more than the (current) max HTLC amount
> > using various flavors of AMP.
> >   * get past the (current) max channel size value
> >   * allow a link to carry more HTLCs (due to the current super low max
> HTLC
> > values) given the additional HTLC pressure that
> > AMP may produce (alternative is a commitment fan out)
>
> These all seem marginal to me.  I think if we start hitting max values,
> we should discuss increasing them.
>
> > Is there a fundamental reason that CL will never allow nodes to create
> > multiple channels? It seems unnecessarily limiting.
>
> Yeah, we have a daemon per peer.  It's really simple with 1 daemon, 1
> channel.  My own fault: I was the one who insisted we mux multiple
> connections over the same transport; if we'd gone for independent
> connections our implementation would have been trivial.
>
> >> Splice Negotiation:
> >
> > Any reason to now make the splicing_add_* messages allow one to add
> several
> > inputs in a single message? Given "acceptable" constraints for how large
> the
> > witness and pkScripts can be, we can easily enforce an upper limit on the
> > number of inputs/outputs to add.
>
> Mainly limitations of our descriptor language, TBH.
>
> > I like that the intro messages have already been designed with the
> > concurrent case in mind beyond a simpler propose/accept flow. However is
> > there any reason why it doesn't also allow either side to fully
> re-negotiate
> > _all_ the funding details? Splicing is a good opportunity to garbage
> collect
> > the prior revocation state, and also free up obsolete space in watch
> towers.
>
> I thought about restarting the revocation sequence, but it seems like
> that only saves a tiny amount since we only store log(N) entries.  We
> can drop old HTLC info post-splice though, and (after some delay for
> obscurity) tell watchtowers to drop old entries I think.
>
> > Additionally, as the size of the channel is either expanding or
> contracting,
> > both sides should be allowed to modify things like the CSV param,
> reserve,
> > max accepted htlc's, max htlc size, etc. Many of these parameters like
> the
> > CSV value should scale with the size of the channel, not allowing these
> > parameters to be re-negotiated could result in odd scenarios like still
> > maintain a 1 week CSV when the channel size has dipped from 1 BTC to 100k
> > satoshis.
>
> Yep, good idea!  I missed that.
>
> Brings up a side point about these values, which deserves its own
> post...
>
> >> 1. type: 40 (`splice_add_input`) (`option_splice`)
> >
> > In order to add nested p2sh inputs, we'll need to also expose the redeem
> > script here, or add additional fields to allow sides to set a sig script
> as
> > well as witness during the signing phase.
> >
> >> - scriptpubkey is empty, or of form 'HASH160 <20-byte-script-hash>
> EQUAL'
> >
> > So no P2SH? :(
>
> Another omission, yeah, we'd want that too I think.
>

Re: [Lightning-dev] Splicing Proposal: Feedback please!

2018-11-05 Thread Olaoluwa Osuntokun
> However personally I do not really see the need to create multiple
channels
> to a single peer, or increase the capacity with a specific peer (via
splice
> or dual-funding).  As Christian says in the other mail, this
consideration,
> is that it becomes less a network and more of some channels to specific
big
> businesses you transact with regularly.

I made no reference to any "big businesses", only the utility that arises
when one has multiple channels to a given peer. Consider an easier example:
given the max channel size, I can only ever send 0.16 or so BTC to that
peer. If I have two channels, then I can send 0.32 and so on. Consider the
case post AMP where we maintain the current limit of the number of in flight
HTLCs. If AMP causes most HTLCs to generally be in flight within the
network, then all of a sudden, this "queue" size (outstanding HTLCS in a
commitment) becomes more scarce (assume a global MTU of say 100k sat for
simplicity). This may then promote nodes to open additional channels to
other nodes (1+) in order to accommodate the increased HTLC bandwidth load
due to the sharded multi-path payments.

Independent on bolstering the bandwidth capabilities of your links to other
nodes, you would still want to maintain a diverse set of channels for fault
tolerance, path diversity, and redundancy reasons.

In the splicing case, if only a single in flight splice is permitted, and me
as users wants to keep all their funds in channels, the more channels I
have, the more concurrent on-chain withdraws/deposits I'll be able to
service.

> I worry about doing away with initiator distinction

Can you re-phrase this sentence? I'm having trouble parsing it, thanks.

> which puzzles me, and I wonder if I am incorrect in my prioritization.

Consider that not all work items are created equal, and they have varying
levels of implementation and network wide synchronization. For example, I
think we all consider multi-hop decor to be a high priority.  However, it
has the longest and hardest road to deployment as it effectively forces us
to perform a "slow motion hard-fork" within the network. On the other hand,
if lnd wanted to deploy a flavor of non-interactive (no invoice) payments
*today*, we could do that without *any* synchronization at the
implementation of network level, as it's purely an end-to-end change.

> I am uncertain what this means in particular, but let me try to restate
> what you are talking about in other terms:

Thought about it a bit more (like way ago) and this is really no different
than having a donation page where people use public derivation to derive
addresses to deposit directly to your channel. All the Lightning node needs
to do, is recognize that any coins send to these derived addresses should be
immediately spliced into an available channel (doesn't have any other
outstanding splices).

> It seems to me naively that the above can be done by the client software
> without any modifications to the Lightning Network BOLT protocol

Sticking with that prior version yes, this would be able to be seamlessly
included in the async splce proposal. The one requirement is a link-level
protocol that allows both sides to collaboratively create and recognize
these outputs.

> Or is my above restatement different from what you are talking about?

You're missing the CLTV timeout clause. It isn't a plain p2wkh, it's a p2wsh
script. Either they splice this in before the timeout, or it times out and
it goes back to one party. In this case, it's no different than the async
concurrent commitment splice in double spend case.

-- Laolu


On Tue, Oct 16, 2018 at 10:16 PM ZmnSCPxj  wrote:

> Good morning Laolu,
>
> Is there a fundamental reason that CL will never allow nodes to create
> multiple channels? It seems unnecessarily limiting.
>
>
> The architecture of c-lightning assigns a separate process to each peer.
> For simplicity this peer process handles only a single channel.  Some of
> the channel initiation and shutdown protocols are written "directly", i.e.
> if the BOLT spec says this must happen before that, we literally write in
> the C code this_function(); that_function();.  It would be possible  to
> change this architecture with significant difficulty.
>
> However personally I do not really see the need to create multiple
> channels to a single peer, or increase the capacity with a specific peer
> (via splice or dual-funding).  As Christian says in the other mail, this
> consideration, is that it becomes less a network and more of some channels
> to specific big businesses you transact with regularly.  But I suppose,
> that we will have to see how the network evolves eventually; perhaps the
> goal of decentralization is simply doomed regardless, and Lightning will
> indeed evolve into a set of channels you maintain to specific big
> businesses you regularly work with.
>
>
> >* [`4`:`feerate_per_kw`]
>
> What fee rate is this? IMO we should do commitmentv2 before splicing as
> then
> we can 

Re: [Lightning-dev] Splicing Proposal: Feedback please!

2018-10-24 Thread Rusty Russell
Conner Fromknecht  writes:
> In light of this, and if I'm following along, it seems our hand is forced in
> splicing via a single on-chain transaction. In my book, this is preferable
> anyway. I'd much rather push complexity off-chain than having to do a
> mutli-stage splicing pipeline.

Agreed.  As Christian pointed out, at least our design space is reduced now?

> I would propose sending a distinct message, which references the
> `active_channel_id` and a `splice_channel_id` for the pending splice:
>
> 1. type: XXX (`commitment_splice_signed`) (`option_splice`)
> 2. data:
>* [`32`:`active_channel_id`]
>* [`32`:`splice_channel_id`]
>* [`64`:`signature`]
>* [`2`:`num_htlcs`]
>* [`num_htlcs*64`:`htlc_signature`]
>
> This more directly addresses handling multiple pending splices, as well as
> preventing us from running into any size constraints. The purpose of
> including the `active_channel_id` would be to remote node locate the
> spliced channel, since it may not be populated indexes containing
> active channels. If we don't want to include this, the existing message
> can be used without modification.

Yes, I like this!  I don't think the `splice_channel_id` helps us much,
since we need to wait we receive all pending commitement_splice_signed
before sending revoke_and_ack, and I think we should simply insist they
be in splice order which makes implementation easier (simple counter).

>> We shouldn't allow more than one pending splice operation anyway, as
>> stated in your proposal initially. We are already critically reliant on
> our
>> transaction being confirmed on-chain, so I don't see this as much of an
>> added issue.
>
> IMO there's no reason to limit ourselves to one pending splice at the
> message
> level. I think it'd be an oversight to not to plan ahead with RBF in mind,
> given that funding transactions have gone unconfirmed precisely because of
> improperly chosen fee rates. Arguably, funding flow should be extended to
> support this as well.

Good reminder re: RBF and funding.  I've put this on the brainstorming
list with your name next to it ;)

> Adding a splice-reject message/error code should be sufficient to allow
> implementations to signal that their local tolerance for number of pending
> splices has been reached. It's likely we'd all start with getting one splice
> working, but then the messages won't need to modified if we want to
> implement
> additional pending splices via RBF.
>
> A node that wants to RBF but receives a reject can then proceed with CPFP
> as a
> last resort.
>
> Are there any downsides I'm overlooking with this approach?

No, I think you've covered it.

>> | Bit Position  | Name  | Field
>   |
>> | - | - |
>  |
>> | 0 | `option_channel_htlc_max` | `htlc_maximum_msat`
>   |
>> | 1 | `option_channel_moving`   | `moving_txid
>  |
>>
>> The `channel_update` gains the following field:
>> * [`32`: moving_txid`] (option_channel_moving)
>
> Do we actually need to send the `moving_txid` via a channel update? I think
> it's
> enough for both parties to send `channel_update`s with the
> `option_channel_moving` bit set, and continue to keep the channel in our
> routing
> table.

It helps because they can't broadcast the new channel for 6 confirms.
OTOH, that's probably not too long to wait.

> If we receive later receive two `channel_update`s whose `short_channel_id`s
> reference the spending transaction (and the node pubkeys are the same), we
> assume the splice was successful and that this channel has been
> subsumed.

So rule would be: if we've seen both channel_updates with
option_channel_moving set, we remember the txid which closed it, and
start a 100-block countdown the "real close".  If we
a (valid) channel_announce for that closing tx with same node pubkeys,
we simply delete the 100-block countdown.

> I
> think this works so long as the spending transaction doesn't contain
> multiple
> funding outputs, though I think the current proposal is fallible to this as
> well.

I think variant above works even in that case?

> To me, this proposal has the benefit of not bloating gossip bandwidth with
> an
> extra field that would need to parsed indefinitely, and gracefully
> supporting
> RBF down the road. Otherwise we'd need to gossip and store each potential
> txid.
>
> With regards to forwarding, both `short_channel_id`s would be accepted by
> the
> splicers for up to 100 blocks (after splice confirm?), at which point they
> can
> both forget the prior `short_channel_id`.

Technically, the need to remember for some grace period after they
announce the block.  We have a similar recommendation for old fee
values, though it's soft.  100 seems overkill.

I think we can assume gossip will propagate widely within 6 blocks and
say they should accept it at least up to 6 blocks after announcing?  Or
1 hour, though I prefer using the 

Re: [Lightning-dev] Splicing Proposal: Feedback please!

2018-10-22 Thread Conner Fromknecht
Good evening lightning-dev,

> If we receive later receive two `channel_update`s whose
`short_channel_id`s
> reference the spending transaction (and the node pubkeys are the same), we
> assume the splice was successful and that this channel has been subsumed.
I
> think this works so long as the spending transaction doesn't contain
multiple
> funding outputs, though I think the current proposal is fallible to this
as
> well.

Thought about this some more. The main difference seems to be whether the
gossiped data is forward or backward looking. By forward looking, I mean
that we
gossip where the splice will move to, and backward looking gossips where the
splice moved from.

If we want to make the original proposal work w/ multiple funding outputs on
one splice, I think it can be accomplished by sending the funding outpoint
as
opposed to just the txid. For the backward looking proposal, the
`channel_update`
could be modified to include the `short_channel_id` of the prior funding
output.
IMO we probably want to include the extra specificity even if we don't plan
to
have multiple funding outputs on a commitment implemented tomorrow, since
outputs are what we truly care about.

Of the two, it still seems like the backward looking approach results in
less
gossiped data since are able to reference a single confirmed output by
location
(8 bytes), instead of N unconfirmed outputs by outpoint (N*34 bytes).

Another advantage I see with the backward looking splice announcments is
that
they can be properly verified before forwarding to the network by examining
the
channel lineage. In contrast, one can't be sure if the outpoint in a
forward looking
announcement will ever confirm, or even if it spends from the original
channel point
unless one also has the transaction. Until a splice does confirm, a node has
to store multiple potential splice outpoints. Seeing this, it seems to me
that
backward looking announcements are less susceptible to abuse and DOS in
this regard.

Thoughts?

Cheers,
Conner

On Thu, Oct 18, 2018 at 8:04 PM Conner Fromknecht
 wrote:

> Good evening all,
>
> Thank you Rusty for starting us down this path :) and to ZmnSCPxj and Lisa
> for
> your thoughts. I think this narrows down the design space considerably!
>
> In light of this, and if I'm following along, it seems our hand is forced
> in
> splicing via a single on-chain transaction. In my book, this is preferable
> anyway. I'd much rather push complexity off-chain than having to do a
> mutli-stage splicing pipeline.
>
> > To add some context to this, if you start accepting HTLC's for the new
> balance
> > after the parallel commitment is made, but before the re-anchor is
> buried,
> > there's the potential for a race condition between a unilateral close
> (or any
> > revoked commitment transaction) and the re-anchoring commitment
> transaction,
> > that spends the 'pre-committed' UTXO of splicing in funds and the
> original
> > funding transaction
>
> Indeed, I'm not aware of any splicing mechanism that enables off-chain use
> of
> spliced-in funds before the new funding output confirms. Even in the async,
> single-txn case, the new funds cannot be spent until the new funding output
> confirms sufficiently.
>
> From my POV, the desired properties of a splice are:
>  1. non-blocking (asynchronous) usage of the channel
>  2. single on-chain txn
>  3. ability to RBF (have multiple pending splices)
>
> Of these, it seems we've solidified 1 and 2. I understand the desire to not
> tackle RBF on the first attempt given the additional complexity.  However,
> I
> do believe there are ways we can proceed in which our first attempt largely
> coincides with supporting it in the future.
>
> With that in mind, here are some thoughts on the proposals above.
>
> ## RBF and Multiple Splices
>
> > 1. type: 132 (`commitment_signed`)
> > 2. data:
> >* [`32`:`channel_id`]
> >* [`64`:`signature`]
> >* [`2`:`num_htlcs`]
> >* [`num_htlcs*64`:`htlc_signature`]
> >* [`num_htlcs*64`:`htlc_splice_signature`] (`option_splice`)
>
> This will overflow the maximum message size of 65535 bytes for num_htlcs >
> 511.
>
> I would propose sending a distinct message, which references the
> `active_channel_id` and a `splice_channel_id` for the pending splice:
>
> 1. type: XXX (`commitment_splice_signed`) (`option_splice`)
> 2. data:
>* [`32`:`active_channel_id`]
>* [`32`:`splice_channel_id`]
>* [`64`:`signature`]
>* [`2`:`num_htlcs`]
>* [`num_htlcs*64`:`htlc_signature`]
>
> This more directly addresses handling multiple pending splices, as well as
> preventing us from running into any size constraints. The purpose of
> including the `active_channel_id` would be to remote node locate the
> spliced channel, since it may not be populated indexes containing
> active channels. If we don't want to include this, the existing message
> can be used without modification.
>
> > We shouldn't allow more than one pending splice operation anyway, as
> > stated 

Re: [Lightning-dev] Splicing Proposal: Feedback please!

2018-10-18 Thread ZmnSCPxj via Lightning-dev
Hi Rusty et al,

Would this work?

Glossary


Old funding output - the TXO that the channel uses pre-splice.  This must be a 
SegWit 2-of-2.

New funding output - the TXO that the channel will use post-splice.  This must 
be a SegWit 2-of-2.

Old commitment transaction - a Poon-Dryja-revocable commitment transaction that 
consumes the old funding output.

New commitment transaction - a Poon-Dryja-revocable commitment transaction that 
consumes the new funding output.

Spliced input - a TXO wholly controlled solely by one channel party, which is 
intended for splicing into the channel.  This must be SegWit.

Splicing transaction - a transaction that consumes the old funding output and 
one or more spliced inputs, and outputs the new funding output.

oldfunding --> [splicing]--> newfunding
 /\
 ||
splicedin  ==++

Splice Preparation Protocol
---

1.  Both sides provide a list of spliced inputs.  They confirm that the 
transactions are either confirmed or on their mempool.
2.  Both sides maintain a separate pair of division of their money.  One pair 
is the amount of money that can be currently used during the splice, and is 
initialized to the current state of the channel (money-during-splice).  The 
other pair is the amount of money each has that will be added after the splice 
is confirmed (money-added-to-splice).
3.  Both sides generate (but do not provide signatures or broadcast) the 
splicing transaction.
4.  Both sides sign the new commitment transaction of the opposing side (which 
spends the new funding transaction of the splicing transaction).
5.  Both sides now sign the splicing transaction, providing signatures for 
their nominated spliced inputs, and broadcast the fully signed splicing 
transaction.

Operation During Splice
---

While the splicing transaction is not sufficiently confirmed but is validly in 
their mempool or confirmed lightly, the channel is in "currently splicing" mode 
and changes to commitment transactions can be changed only according to these 
rules:

1.  Both old commitment transactions and new commitment transactions are 
updated in parallel.
2.  Each side can only use money that is theirs during the splice 
(money-during-splice) to offer HTLCs.  They cannot use spliced-in money yet to 
offer HTLCs.

Failure Modes
-

If the splicing transaction becomes invalidated from the mempool, and was not 
confirmed/included in the block, then the splice has failed.  Both sides should 
inform this splice failure to the other.

1.  If any old commitment transaction was spent to invalidate the splice 
transaction, then the channel has closed and both sides drop to tracking the 
channel closure as unilateral close.
2.  Otherwise, the splicing transaction became invalidated either due to a 
spend of any spliced input, or by invalidation of spliced input via transaction 
replacement (RBF).  In this case, the protocol moves to splice failure.

Splice Failure
--

1.  One side notices the splice failure and claims that the splice has failed.
2.  The other side monitors its own mempool for invalidation of the splicing 
transaction, with a timeout.
3.  If the other side also notices the splice failure, then both sides can drop 
the (money-added-to-splice) and revert back to the pre-splice channel.  Spliced 
inputs should be considered by their owner to be spendable again for other 
onchain purposes.
3.  Otherwise if the other side times out without seeing the splicing 
transaction getting invalidated, it will publish the latest old commitment 
transaction and the latest new commitment transaction and consider the channel 
as closing and tracking it as a unilateral close, checking for either the old 
funding output or the new funding output to be spent.

Regards,
ZmnSCPxj


Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Wednesday, October 17, 2018 6:30 AM, Rusty Russell  
wrote:

> Rusty Russell ru...@rustcorp.com.au writes:
>
> > If we're going to do side splice-in like this, I would use a very
> > different protocol: the reason for this protocol was to treat splice-in
> > and splice-out the same, and inline splice-in requires wait time. Since
> > splice-out doesn't, we don't need this at all.
> > It would look much more like:
> >
> > 1.  Prepare any output with script of specific form. eg:
> > OP_DEPTH 3 OP_EQUAL OP_IF
> >   OP_CHECKMULTISIG
> > OP_ELSE
> >  OP_CHECKLOCKTIMEVERIFY OP_DROP
> >  OP_CHECKSIG
> > OP_ENDIF
> >
> > 2.  type: 40 (`splice_in`) (`option_splice`)
> >
> > 3.  data:
> > -   [`32`:`channel_id`]
> > -   [`8`: `satoshis`]
> > -   [`32`: `txid`]
> > -   [`4`: `txoutnum`]
> > -   [`4`: `blockheight`]
> > -   [`33`: `myrescue_pubkey`]
> > 4.  type: 137 (`update_splice_in_accept`) (`option_splice`)
> > data:
> > -   [`32`:`channel_id`]
> > -   [`32`: `txid`]
> > -   [`4`: 

Re: [Lightning-dev] Splicing Proposal: Feedback please!

2018-10-16 Thread ZmnSCPxj via Lightning-dev
Good morning lisa,

This is a good observation.

Before, I'd already considered the rationale, for why channels have a single 
2-of-2 UTXO as funding output.  And it seems I should have considered this, 
prior to accepting the "parallel" construction as feasible.

For sake of posterity, I leave the below writeup as a tangential to the design 
of splice (and to the design of Lightning having a single 2-of-2 UTXOs):

# 0-conf is Unsafe, Yet Lightning is Safe; Why?

To accept a 0-conf transaction output, is known to be unsafe.  Replace-by-fee 
is always a possibility, regardless of whether the transaction opts in to RBF 
or not: a rational miner will always accept the higher feerate, disregarding 
any "opt-in" flag that is set or not set on the transaction.  Thus we reject 
any advice that claims that 0-conf is tenable, even for tiny amounts.

Yet when viewed solely in terms of transactions, Lightning protocol uses 
transactions that are not on any block (are kept offchain).  Since they are not 
in a block, they are indistinguishable from 0-conf transactions, which are 
accepted by the receiver, yet are also not on any block.  One might argue the 
distinction, that a "real" 0-conf transaction exists on some mempool somewhere, 
and thus has a chance to be on a block in the future, but mempools have no 
consensus, and the existence of a transaction on some mempool is not a safe 
assurance of it existing in the mempool of the next winning miner.

So why is Lightning safe, when 0-conf transactions are in general not safe?

Again, we should focus on why 0-conf transactions in general are not safe: 
transaction replacement.  Thus, 0-conf transactions can be made safe, if you 
are somehow able to ensure that replacement transactions cannot be made.

For example, if you are part of an n-of-n federation that signs the 
transaction, you can always safely accept a 0-conf transaction from that 
federation paying only to you, because you can always veto any replacement (by 
simply refusing to sign) that is not in your interests.

This is in fact how Lightning works: a 2-of-2 federation (the channel 
counterparties) are the signatories of the 0-conf transactions that are the 
commitment transactions of the Lightning protocol.  Replacement of the 
commitment transactions is strictly guided by the protocol; both sides have 
veto rights, since the source transaction output is 2-of-2.

Thus, Lightning, though it uses 0-conf transactions, is safe, because it 
prevents the replacement of a 0-conf transaction without the receiver allowing 
it, by the simple expedient of including the receiver in the 2-of-2 multisig 
guarding its single funding TXO.

##  The Implications for Splice Proposals

Some splice proposals involve creating the equivalent of multiple funding TXOs 
for a single channel.  Such constructions are unsafe-by-default on Poon-Dryja.

In reality, every commitment transaction (or update transaction in 
Decker-Osuntokun-Russell) is replaceable by any other commitment (or update) 
transaction for that channel.  Under Poon-Dryja older transactions are revoked 
(and hence one side risks loss of their collateral) while under 
Decker-Osuntokun-Russell older transactions may be "gainsaid" (i.e. newer 
update transactions may be reanchored to consume the TXO of the older update 
transaction, thus preventing that update from truly being committed to).

This is relevant since before a splice, the channel has a single funding TXO, 
while after the splice, the channel has multiple.

In particular, a commitment (or update) transaction, that has multiple inputs 
(to consume the multiple funding TXOs), can be replaced with a commitment (or 
update) transaction that was created before the splice.  Under Poon-Dryja, such 
a commitment transaction may be revoked, but this leaves the other funding TXOs 
unuseable.  Under Decker-Osuntokun-Russell, as long as the sequence number is 
preserved across the splice, it is possible for a later update transaction with 
multiple inputs to simply gainsay the old single-input update with the new 
multiple-input update transaction. (I suppose, that this is another advantage 
that Decker-Osuntokun-Russell has).

Regards,
ZmnSCPxj

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐ Original Message ‐‐‐
On Wednesday, October 17, 2018 9:09 AM, lisa neigut  wrote:

> To add some context to this, if you start accepting HTLC's for the new 
> balance after the parallel commitment is made, but before the re-anchor is 
> buried, there's the potential for a race condition between a unilateral close 
> (or any revoked commitment transaction) and the re-anchoring commitment 
> transaction, that spends the 'pre-committed' UTXO of splicing in funds and 
> the original funding transaction.
>
> You can get around this by waiting until both the pre-commitment UTXO and the 
> re-anchor have cleared a minimum depth before accepting HTLC's for the new 
> balance totals, but that's twice as long 

Re: [Lightning-dev] Splicing Proposal: Feedback please!

2018-10-16 Thread lisa neigut
To add some context to this, if you start accepting HTLC's for the new
balance after the parallel commitment is made, but before the re-anchor is
buried, there's the potential for a race condition between a unilateral
close (or any revoked commitment transaction) and the re-anchoring
commitment transaction, that spends the 'pre-committed' UTXO of splicing in
funds and the original funding transaction.

You can get around this by waiting until both the pre-commitment UTXO and
the re-anchor have cleared a minimum depth before accepting HTLC's for the
new balance totals, but that's twice as long of a wait as the first,
synchronized re-commitment scheme that Rusty originally proposed.

It also makes leaving the original funding transaction 'exposed' (ie Rene's
version of parallel splice) untenable, as there's always the risk of an old
state being published to consume that input. This foobars your current HTLC
commitments.

On Tue, Oct 16, 2018 at 3:31 PM Rusty Russell  wrote:

> Rusty Russell  writes:
> > If we're going to do side splice-in like this, I would use a very
> > different protocol: the reason for this protocol was to treat splice-in
> > and splice-out the same, and inline splice-in requires wait time.  Since
> > splice-out doesn't, we don't need this at all.
> >
> > It would look much more like:
> >
> > 1. Prepare any output with script of specific form. eg:
> > OP_DEPTH 3 OP_EQUAL OP_IF
> >   OP_CHECKMULTISIG
> > OP_ELSE
> >  OP_CHECKLOCKTIMEVERIFY OP_DROP
> >  OP_CHECKSIG
> > OP_ENDIF
> >
> > 1. type: 40 (`splice_in`) (`option_splice`)
> > 2. data:
> >* [`32`:`channel_id`]
> >* [`8`: `satoshis`]
> >* [`32`: `txid`]
> >* [`4`: `txoutnum`]
> >* [`4`: `blockheight`]
> >* [`33`: `myrescue_pubkey`]
> >
> > 1. type: 137 (`update_splice_in_accept`) (`option_splice`)
> >data:
> >* [`32`:`channel_id`]
> >* [`32`: `txid`]
> >* [`4`: `txoutnum`]
> >
> > 1. type: 138 (`update_splice_in_reject`) (`option_splice`)
> >data:
> >* [`32`:`channel_id`]
> >* [`32`: `txid`]
> >* [`2`:`len`]
> >* [`len`:`errorstr`]
> >
> > The recipient of `splice_in` checks that it's happy with the
> > `blockheight` (far enough in future).  Once it sees the tx referred to
> > buried to its own `minimum_depth`, it checks output is what they
> > claimed, then sends `update_splice_in_accept`; it's followed up
> > `commitment_signed` like normal, but from this point onwards, all
> > commitment txs signatures have one extra sig.
>
> Lisa started asking pointed questions, and so I noticed that parallel
> splice doesn't work with Poon-Dryja channels.
>
> The counterparty can spend the old funding txout with a revoked spend.
> Sure, I can take all the money from that, but what about the spliced
> input?
>
> I came up with increasingly elaborate workarounds, but nothing stuck.
>
> Back to Plan A...
> Rusty.
> ___
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


Re: [Lightning-dev] Splicing Proposal: Feedback please!

2018-10-16 Thread Rusty Russell
Olaoluwa Osuntokun  writes:
> Hi Rusty,
>
> Happy to get the splicing train rolling!
>
>> We've had increasing numbers of c-lightning users get upset they can't
>> open multiple channels, so I guess we're most motivated to allow splicing
> of
>> existing channels
>
> Splicing isn't a substitute for allowing multiple channels. Multiple
> channels allow nodes to:
>
>   * create distinct channels with distinct acceptance policies.
>   * create a mix of public and non-advertised channels with a node.
>   * be able to send more than the (current) max HTLC amount
> using various flavors of AMP.
>   * get past the (current) max channel size value
>   * allow a link to carry more HTLCs (due to the current super low max HTLC
> values) given the additional HTLC pressure that
> AMP may produce (alternative is a commitment fan out)

These all seem marginal to me.  I think if we start hitting max values,
we should discuss increasing them.

> Is there a fundamental reason that CL will never allow nodes to create
> multiple channels? It seems unnecessarily limiting.

Yeah, we have a daemon per peer.  It's really simple with 1 daemon, 1
channel.  My own fault: I was the one who insisted we mux multiple
connections over the same transport; if we'd gone for independent
connections our implementation would have been trivial.

>> Splice Negotiation:
>
> Any reason to now make the splicing_add_* messages allow one to add several
> inputs in a single message? Given "acceptable" constraints for how large the
> witness and pkScripts can be, we can easily enforce an upper limit on the
> number of inputs/outputs to add.

Mainly limitations of our descriptor language, TBH.  

> I like that the intro messages have already been designed with the
> concurrent case in mind beyond a simpler propose/accept flow. However is
> there any reason why it doesn't also allow either side to fully re-negotiate
> _all_ the funding details? Splicing is a good opportunity to garbage collect
> the prior revocation state, and also free up obsolete space in watch towers.

I thought about restarting the revocation sequence, but it seems like
that only saves a tiny amount since we only store log(N) entries.  We
can drop old HTLC info post-splice though, and (after some delay for
obscurity) tell watchtowers to drop old entries I think.

> Additionally, as the size of the channel is either expanding or contracting,
> both sides should be allowed to modify things like the CSV param, reserve,
> max accepted htlc's, max htlc size, etc. Many of these parameters like the
> CSV value should scale with the size of the channel, not allowing these
> parameters to be re-negotiated could result in odd scenarios like still
> maintain a 1 week CSV when the channel size has dipped from 1 BTC to 100k
> satoshis.

Yep, good idea!  I missed that.

Brings up a side point about these values, which deserves its own
post...

>> 1. type: 40 (`splice_add_input`) (`option_splice`)
>
> In order to add nested p2sh inputs, we'll need to also expose the redeem
> script here, or add additional fields to allow sides to set a sig script as
> well as witness during the signing phase.
>
>> - scriptpubkey is empty, or of form 'HASH160 <20-byte-script-hash> EQUAL'
>
> So no P2SH? :(

Another omission, yeah, we'd want that too I think.

>>* [`4`:`feerate_per_kw`]
>
> What fee rate is this? IMO we should do commitmentv2 before splicing as then
> we can more or less do away with the initiator distinction and have most
> fees be ad hoc.

We're basically co-generating a tx here, just like shutdown, except it's
funding a new replacement channel.  Do we want to CPFP this one too?

>> Splice Signing
>
> It seems that we're missing some fields here if we're to allow the splicing
> of inputs to be done in a non-blocking manner. We'll need to send two
> revocation points for the new commitment: one to allow it to be created, and
> another to allow updates to proceed right after the signing is completed. In
> this case we'll also need to update both commitments in tandem until the
> splicing transaction has been sufficiently confirmed.

I think we can use the existing revocation points for both.

> Also, what about change addresses? Are they to be explicitly specified as
> splice outs?

They'd be splice-outs, yeah.

>> 1. type: 43 (`splice_commitment_signature`) (`option_splice`)
>
> It may be worth pointing out there that we're able to transfer all existing
> HTLCs over to the new commitment as additional context.

Yeah, I think people missed that it was non-blocking like that.

>> 1. type: 45 (`splice_witness`) (`option_splice`)
>
> Should also allow either side to specify the sig script here if we're to
> allow nested p2sh (which we should IMO!).

Yep.

>>   * [`2`:`len`]
>>   * [`len`:`witnesses`]
>
> Is the extra length needed if all the witness elements themselves are length
> delimited?

Yes, we always length-delimit fields so we can add options later.

>
> It isn't clear in the 

Re: [Lightning-dev] Splicing Proposal: Feedback please!

2018-10-16 Thread Rusty Russell
Rusty Russell  writes:
> If we're going to do side splice-in like this, I would use a very
> different protocol: the reason for this protocol was to treat splice-in
> and splice-out the same, and inline splice-in requires wait time.  Since
> splice-out doesn't, we don't need this at all.
>
> It would look much more like:
>
> 1. Prepare any output with script of specific form. eg:
> OP_DEPTH 3 OP_EQUAL OP_IF
>   OP_CHECKMULTISIG
> OP_ELSE
>  OP_CHECKLOCKTIMEVERIFY OP_DROP
>  OP_CHECKSIG
> OP_ENDIF
>
> 1. type: 40 (`splice_in`) (`option_splice`)
> 2. data:
>* [`32`:`channel_id`]
>* [`8`: `satoshis`]
>* [`32`: `txid`]
>* [`4`: `txoutnum`]
>* [`4`: `blockheight`]
>* [`33`: `myrescue_pubkey`]
>
> 1. type: 137 (`update_splice_in_accept`) (`option_splice`)
>data:
>* [`32`:`channel_id`]
>* [`32`: `txid`]
>* [`4`: `txoutnum`]
>
> 1. type: 138 (`update_splice_in_reject`) (`option_splice`)
>data:
>* [`32`:`channel_id`]
>* [`32`: `txid`]
>* [`2`:`len`]
>* [`len`:`errorstr`]
>
> The recipient of `splice_in` checks that it's happy with the
> `blockheight` (far enough in future).  Once it sees the tx referred to
> buried to its own `minimum_depth`, it checks output is what they
> claimed, then sends `update_splice_in_accept`; it's followed up
> `commitment_signed` like normal, but from this point onwards, all
> commitment txs signatures have one extra sig.

Lisa started asking pointed questions, and so I noticed that parallel
splice doesn't work with Poon-Dryja channels.

The counterparty can spend the old funding txout with a revoked spend.
Sure, I can take all the money from that, but what about the spliced
input?

I came up with increasingly elaborate workarounds, but nothing stuck.

Back to Plan A...
Rusty.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


Re: [Lightning-dev] Splicing Proposal: Feedback please!

2018-10-16 Thread Johan Torås Halseth
>
> This is one of the cases where a simpler solution (relatively
> speaking ^^) is to be preferred imho, allowing for future
> iterations.
>

I think we should strive to splice in 1 on-chain tx, as if not the biggest
benefit really is lost compared to just closing and reopening the channel.

Complexity wise I don't think it will be that much to gain from the 2-tx
proposal as (if I understand the proposal correctly) there will be even
more transaction types with new scripts to code up and maintain.

On Tue, Oct 16, 2018 at 5:38 AM Christian Decker 
wrote:

> ZmnSCPxj via Lightning-dev 
> writes:
>
> >> One thing that I think we should lift from the multiple funding output
> >> approach is the "pre seating of inputs". This is cool as it would allow
> >> clients to generate addresses, that others could deposit to, and then
> have
> >> be spliced directly into the channel. Public derivation can be used,
> along
> >> with a script template to do it non-interactively, with the clients
> picking
> >> up these deposits, and initiating a splice in as needed.
> >
> > I am uncertain what this means in particular, but let me try to
> > restate what you are talking about in other terms:
> >
> > 1.  Each channel has two public-key-derivation paths (BIP32) to create
> onchain addresses.  One for each side of the channel.
> > 2.  When somebody sends to one of the onchain addresses in the path,
> their client detects this.
> > 3.  The client initiates a splice-in automatically from this UTXO paying
> to that address into the channel.
> >
> > It seems to me naively that the above can be done by the client
> > software without any modifications to the Lightning Network BOLT
> > protocol, as long as the BOLT protocol is capable of supporting *some*
> > splice-in operation, i.e. it seems to be something that a client
> > software can implement as a feature without requiring a BOLT change.
> > Or is my above restatement different from what you are talking about?
> >
> > How about this restatement?
> >
> > 1.  Each channel has two public-key-derivation paths (BIP32) to create
> onchain addresses.  One for each side of the channel.
> > 2.  The base of the above is actually a combined private-public keypair
> of both sides (e.g. created via MuSig or some other protocol).  Thus the
> addresses require cooperation of both parties to spend.
> > 3.  When somebody sends to one of the onchain addresses in the path,
> their client detects this.
> > 4.  The client updates the current transaction state, such that the new
> commit transaction has two inputs ( the original channel transaction and
> the new UTXO).
> >
> > The above seems unsafe without trust in the other peer, as, the other
> > peer can simply refuse to create the new commit transaction.  Since
> > the address requires both parties to spend, the money cannot be spent
> > and there is no backoff transaction that can be used.  But maybe you
> > can describe some mechanism to ensure this, if this is what is meant
> > instead?
>
> This could easily be solved by making the destination address a Taproot
> address, which by default is just a 2-of-2, but in the uncooperative
> case it can reveal the script it commits to, which is just a timelocked
> refund that requires a single-sig. The only problem with this is that
> the refund would be non-interactive, and so the entirety of the funds,
> that may be from a third-party, need to be claimed by one endpoint,
> i.e., there is no splitting the funds in case of an uncollaborative
> refund. Not sure how important that is though, since I don't think
> third-party funds will come from unrelated parties, e.g., most of these
> funds will come from an on-chain wallet that is under the control of
> either parties so the refund should go back to that party anyway.
>
> Cheers,
> Christian
> ___
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


Re: [Lightning-dev] Splicing Proposal: Feedback please!

2018-10-16 Thread Christian Decker
ZmnSCPxj via Lightning-dev 
writes:

>> One thing that I think we should lift from the multiple funding output
>> approach is the "pre seating of inputs". This is cool as it would allow
>> clients to generate addresses, that others could deposit to, and then have
>> be spliced directly into the channel. Public derivation can be used, along
>> with a script template to do it non-interactively, with the clients picking
>> up these deposits, and initiating a splice in as needed.
>
> I am uncertain what this means in particular, but let me try to
> restate what you are talking about in other terms:
>
> 1.  Each channel has two public-key-derivation paths (BIP32) to create 
> onchain addresses.  One for each side of the channel.
> 2.  When somebody sends to one of the onchain addresses in the path, their 
> client detects this.
> 3.  The client initiates a splice-in automatically from this UTXO paying to 
> that address into the channel.
>
> It seems to me naively that the above can be done by the client
> software without any modifications to the Lightning Network BOLT
> protocol, as long as the BOLT protocol is capable of supporting *some*
> splice-in operation, i.e. it seems to be something that a client
> software can implement as a feature without requiring a BOLT change.
> Or is my above restatement different from what you are talking about?
>
> How about this restatement?
>
> 1.  Each channel has two public-key-derivation paths (BIP32) to create 
> onchain addresses.  One for each side of the channel.
> 2.  The base of the above is actually a combined private-public keypair of 
> both sides (e.g. created via MuSig or some other protocol).  Thus the 
> addresses require cooperation of both parties to spend.
> 3.  When somebody sends to one of the onchain addresses in the path, their 
> client detects this.
> 4.  The client updates the current transaction state, such that the new 
> commit transaction has two inputs ( the original channel transaction and the 
> new UTXO).
>
> The above seems unsafe without trust in the other peer, as, the other
> peer can simply refuse to create the new commit transaction.  Since
> the address requires both parties to spend, the money cannot be spent
> and there is no backoff transaction that can be used.  But maybe you
> can describe some mechanism to ensure this, if this is what is meant
> instead?

This could easily be solved by making the destination address a Taproot
address, which by default is just a 2-of-2, but in the uncooperative
case it can reveal the script it commits to, which is just a timelocked
refund that requires a single-sig. The only problem with this is that
the refund would be non-interactive, and so the entirety of the funds,
that may be from a third-party, need to be claimed by one endpoint,
i.e., there is no splitting the funds in case of an uncollaborative
refund. Not sure how important that is though, since I don't think
third-party funds will come from unrelated parties, e.g., most of these
funds will come from an on-chain wallet that is under the control of
either parties so the refund should go back to that party anyway.

Cheers,
Christian
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


Re: [Lightning-dev] Splicing Proposal: Feedback please!

2018-10-16 Thread ZmnSCPxj via Lightning-dev
Good morning Laolu,

> Is there a fundamental reason that CL will never allow nodes to create
> multiple channels? It seems unnecessarily limiting.

The architecture of c-lightning assigns a separate process to each peer.  For 
simplicity this peer process handles only a single channel.  Some of the 
channel initiation and shutdown protocols are written "directly", i.e. if the 
BOLT spec says this must happen before that, we literally write in the C code 
this_function(); that_function();.  It would be possible  to change this 
architecture with significant difficulty.

However personally I do not really see the need to create multiple channels to 
a single peer, or increase the capacity with a specific peer (via splice or 
dual-funding).  As Christian says in the other mail, this consideration, is 
that it becomes less a network and more of some channels to specific big 
businesses you transact with regularly.  But I suppose, that we will have to 
see how the network evolves eventually; perhaps the goal of decentralization is 
simply doomed regardless, and Lightning will indeed evolve into a set of 
channels you maintain to specific big businesses you regularly work with.

>>* [`4`:`feerate_per_kw`]
>
> What fee rate is this? IMO we should do commitmentv2 before splicing as then
> we can more or less do away with the initiator distinction and have most
> fees be ad hoc.

I worry about doing away with initiator distinction, as I worry that an 
initiatee may be forced to pay fees they did not really voluntarily consider 
paying, when they are given funds on a channel initiated by someone else in 
exchange for funds on a separate channel; but this is probably a separate topic.

>If you think any of these items is a higher priority than splicing then you
>can simply start working on them! There's no agency that prescribes what
>should and shouldn't be pursued or developed, just your willingness to
>write some code.

While true, for me personally I can only devote a limited amount of time to 
coding for Lightning, and thus I must always worry whether my priorities are 
even correct.  I find it very common that people want to prioritize splicing 
over AMP or watchtowers, which puzzles me, and I wonder if I am incorrect in my 
prioritization.

> One thing that I think we should lift from the multiple funding output
> approach is the "pre seating of inputs". This is cool as it would allow
> clients to generate addresses, that others could deposit to, and then have
> be spliced directly into the channel. Public derivation can be used, along
> with a script template to do it non-interactively, with the clients picking
> up these deposits, and initiating a splice in as needed.

I am uncertain what this means in particular, but let me try to restate what 
you are talking about in other terms:

1.  Each channel has two public-key-derivation paths (BIP32) to create onchain 
addresses.  One for each side of the channel.
2.  When somebody sends to one of the onchain addresses in the path, their 
client detects this.
3.  The client initiates a splice-in automatically from this UTXO paying to 
that address into the channel.

It seems to me naively that the above can be done by the client software 
without any modifications to the Lightning Network BOLT protocol, as long as 
the BOLT protocol is capable of supporting *some* splice-in operation, i.e. it 
seems to be something that a client software can implement as a feature without 
requiring a BOLT change.  Or is my above restatement different from what you 
are talking about?

How about this restatement?

1.  Each channel has two public-key-derivation paths (BIP32) to create onchain 
addresses.  One for each side of the channel.
2.  The base of the above is actually a combined private-public keypair of both 
sides (e.g. created via MuSig or some other protocol).  Thus the addresses 
require cooperation of both parties to spend.
3.  When somebody sends to one of the onchain addresses in the path, their 
client detects this.
4.  The client updates the current transaction state, such that the new commit 
transaction has two inputs ( the original channel transaction and the new UTXO).

The above seems unsafe without trust in the other peer, as, the other peer can 
simply refuse to create the new commit transaction.  Since the address requires 
both parties to spend, the money cannot be spent and there is no backoff 
transaction that can be used.  But maybe you can describe some mechanism to 
ensure this, if this is what is meant instead?

Regards,
ZmnSCPxj___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


Re: [Lightning-dev] Splicing Proposal: Feedback please!

2018-10-15 Thread Christian Decker
Olaoluwa Osuntokun  writes:
> Splicing isn't a substitute for allowing multiple channels. Multiple
> channels allow nodes to:
>
>   * create distinct channels with distinct acceptance policies.
>   * create a mix of public and non-advertised channels with a node.
>   * be able to send more than the (current) max HTLC amount
> using various flavors of AMP.
>   * get past the (current) max channel size value
>   * allow a link to carry more HTLCs (due to the current super low max HTLC
> values) given the additional HTLC pressure that
> AMP may produce (alternative is a commitment fan out)

While these are all good points, I think they are equally well served if
by creating channels to other peers. This has the added benefit of
reducing the node's reliance on a single peer. In fact it seems we are
currently encouraging users to have a small number of fat channels that
are manually maintained (dual-funding, splicing, multiple channels per
peer), rather than making the default to create a diverse set of
channels that allow indirectly routed payments.

Instead of obsessing about that one peer and hoping that that peer is
online when we need it, we should make routed payments a first-class
citizen. If we can route correctly and with confidence we can stop
worrying about that one peer and our connectivity to it. On the other
hand, if routing doesn't work, and people have to worry about that one
channel that connects them directly to the destination, then we're not
much of a network, but rather a set of disjoint channels.

Ultimately users should stop caring about individual channels or peer
relationships, and multipath routing gets us a long way there. I'd
really like to have a wallet that'll just manage channels in the
background and not expose those details to the users which just want to
send and receive payments, and we can start that now by de-emphasizing
the importance of the peer selection.

Regards,
Christian
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


Re: [Lightning-dev] Splicing Proposal: Feedback please!

2018-10-15 Thread Olaoluwa Osuntokun
> I would suggest more to consider the simpler method, despite its larger
> onchain footprint (which is galling),

The on-chain footprint is a shame, and also it gets worse if we start to
allow multiple pending splices. Also the lack of a non-blocking splice in is
a big draw back IMO.

> but mostly because I do not see splicing as being as important as AMP or
> watchtowers (and payment decorrelation seems to affect how AMP can be
> implemented, so its priority also goes up).

Most of what you mention here have _very_ different deployment timelines and
synchronization requirements across clients. For example, splicing is a link
level change and can start to be rolled out immediately. Decorrelation on
the other hand, is a _network_ level change, and would take a considerable
amount of time to reach widespread deployment as it essentially splits the
rouble paths in the network until all/most are upgraded.

If you think any of these items is a higher priority than splicing then you
can simply start working on them! There's no agency that prescribes what
should and shouldn't be pursued or developed, just your willingness to
write some code.

One thing that I think we should lift from the multiple funding output
approach is the "pre seating of inputs". This is cool as it would allow
clients to generate addresses, that others could deposit to, and then have
be spliced directly into the channel. Public derivation can be used, along
with a script template to do it non-interactively, with the clients picking
up these deposits, and initiating a splice in as needed.

-- Laolu



On Thu, Oct 11, 2018 at 11:14 PM ZmnSCPxj via Lightning-dev <
lightning-dev@lists.linuxfoundation.org> wrote:

> Good morning Rusty,
>
> >
> > > It may be good to start brainstorming possible failure modes during
> splice, and how to recover, and also to indicate the expected behavior in
> the proposal, as I believe these will be the points where splicing must be
> designed most precisely. What happens when a splice is ongoing and the
> communication gets disconnected? What happens when some channel failure
> occurs during splicing and we are forced to drop onchain? And so on.
> >
> > Agreed, but we're now debating two fairly different methods for
> > splicing. Once we've decided on that, we can try to design the
> > proposals themselves.
>
> I would suggest more to consider the simpler method, despite its larger
> onchain footprint (which is galling), but mostly because I do not see
> splicing as being as important as AMP or watchtowers (and payment
> decorrelation seems to affect how AMP can be implemented, so its priority
> also goes up).  So I think getting *some* splicing design out would be
> better even if imperfect.  Others may disagree on priority.
>
> Regards,
> ZmnSCPxj
> ___
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


Re: [Lightning-dev] Splicing Proposal: Feedback please!

2018-10-11 Thread Rusty Russell
ZmnSCPxj  writes:
> Good morning Rusty,
>
> In BOLT #2 we currently impose a 2^24 satoshi limit on total channel 
> capacity.  Is splicing intended to allow violation of this limit? I do not 
> see it mentioned in the proposal. Can I splice 21 million bitcoins on a 
> 1-satoshi channel?

Good question!  I think that's the kind of thing we should consider
carefully at the Summit.

> It may be good to start brainstorming possible failure modes during splice, 
> and how to recover, and also to indicate the expected behavior in the 
> proposal, as I believe these will be the points where splicing must be 
> designed most precisely. What happens when a splice is ongoing and the 
> communication gets disconnected?  What happens when some channel failure 
> occurs during splicing and we are forced to drop onchain?  And so on.

Agreed, but we're now debating two fairly different methods for
splicing.  Once we've decided on that, we can try to design the
proposals themselves.

Thanks,
Rusty.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


Re: [Lightning-dev] Splicing Proposal: Feedback please!

2018-10-11 Thread Rusty Russell
Christian Decker  writes:
> On Thu, Oct 11, 2018 at 3:40 AM Rusty Russell  wrote:
>
>> > * Once we have enough confirmations we merge the channels (either
>> > automatically or with the next channel update). A new commitment tx is
>> > being created which now spends each output of each of the two funding tx
>> > and assigns the channel balance to the channel partners accordingly to
>> the
>> > two independent channels. The old commitment txs are being invalidated.
>> > * The disadvantage is that while splicing is not completed and if the
>> > funder of the splicing tx is trying to publish an old commitment tx the
>> > node will only be punished by sending all the funds of the first funding
>> tx
>> > to the partner as the special commitment tx of the 2nd output has no
>> newer
>> > state yet.
>>
>> Yes, this is the alternative method; produce a parallel funding tx
>> (which only needs to support a single revocation, or could even be done
>> by a long timeout) and then join them when it reaches the agreed depth.
>>
>> It has some elegance; particularly because one side doesn't have to do
>> any validation or store anything until it's about to splice in.  You get
>> asked for a key and signature, you produce a new one, and sign whatever
>> tx they want.  They hand you back the tx and the key you used once it's
>> buried far enough, and you check the tx is indeed buried and the output
>> is the script you're expecting, then you flip the commitment tx.
>>
>> But I chose chose not to do this because every transaction commitment
>> forever will require 2 signatures, and doesn't allow us to forget old
>> revocation information.
>>
>> And it has some strange side-effects: onchain this looks like two
>> channels; do we gossip about both?  We have to figure the limit on
>> splice-in to make sure the commitment tx stays under 400kSipa.
>>
>
> This is a lot closer to my original proposal for splicing, and I
> still like it a lot more since the transition from old to new
> channel is bascially atomic (not having to update state on both
> pre-splice and post-splice version). The new funds will remain
> unavailable for the same time, and since we allow only one
> concurrent splice in your proposal we don't even lose any
> additional time regarding the splice-outs.
>
> So pulling the splice_add_input and splice_add_output up to
> signal the intent of adding funds to a splice. Splice_all_added
> is then used to start moving the funds to a pre-allocated 2-of-2
> output where the funds can mature. Once the funds are
> matured (e.g., 6 confirmations) we can start the transition: both
> parties claim the funding output, and the pre-allocated funds, to
> create a new funding tx which is immediately broadcast, and we
> flip over to the new channel state. No need to keep parallel
> state and then disambiguating which one it was.

If we're going to do side splice-in like this, I would use a very
different protocol: the reason for this protocol was to treat splice-in
and splice-out the same, and inline splice-in requires wait time.  Since
splice-out doesn't, we don't need this at all.

It would look much more like:

1. Prepare any output with script of specific form. eg:
OP_DEPTH 3 OP_EQUAL OP_IF
  OP_CHECKMULTISIG
OP_ELSE
 OP_CHECKLOCKTIMEVERIFY OP_DROP
 OP_CHECKSIG
OP_ENDIF

1. type: 40 (`splice_in`) (`option_splice`)
2. data:
   * [`32`:`channel_id`]
   * [`8`: `satoshis`]
   * [`32`: `txid`]
   * [`4`: `txoutnum`]
   * [`4`: `blockheight`]
   * [`33`: `myrescue_pubkey`]

1. type: 137 (`update_splice_in_accept`) (`option_splice`)
   data:
   * [`32`:`channel_id`]
   * [`32`: `txid`]
   * [`4`: `txoutnum`]

1. type: 138 (`update_splice_in_reject`) (`option_splice`)
   data:
   * [`32`:`channel_id`]
   * [`32`: `txid`]
   * [`2`:`len`]
   * [`len`:`errorstr`]

The recipient of `splice_in` checks that it's happy with the
`blockheight` (far enough in future).  Once it sees the tx referred to
buried to its own `minimum_depth`, it checks output is what they
claimed, then sends `update_splice_in_accept`; it's followed up
`commitment_signed` like normal, but from this point onwards, all
commitment txs signatures have one extra sig.

Similarly, splice-out:

1. type: 139 (`update_splice_out`) (`option_splice`)
   * [`32`:`channel_id`]
   * [`8`: `satoshis`]
   * [`2`: `scriptlen`]
   * [`scriptlen`: `outscript`]

The recipient checks that the output script is standard, and the amount
can be afforded by the other side.  From then on, each commitment tx has
a new output.

Note this doesn't put the splice out on the blockchain!

1. type: 140 (`propose_reopen`) (`option_splice`)
   * [`32`:`channel_id`]
   * [`4`:`feerate_per_kw`]
   * [`33`:`funding_pubkey`]

This is initiates a mutually-agreed broadcast of the current state: all
inputs (original and spliced), all spliced outputs, and a funding-style
2x2 which has all the remaining funds.  Call this a 'reopen tx'.

This 

Re: [Lightning-dev] Splicing Proposal: Feedback please!

2018-10-11 Thread ZmnSCPxj via Lightning-dev
Good morning Rusty and Christian and list,

> This is one of the cases where a simpler solution (relatively
> speaking ^^) is to be preferred imho, allowing for future
> iterations.

I would basically agree here, with the further proviso that I think splice is 
not quite as priority as AMP, decorrelation, or watchtowers.

The simpler solution has the drawback of more transactions onchain, but 
massively reduces the complexity of maintaining parallel state updates.  
Parallel updates would increase greatly our need to test the feature in various 
conditions (and specify also in the formal spec what possible failure modes are 
and how they should be recovered, as a basic safety for users of Lightning).

Of course, the same course of thought is what lead to onchain transaction bloat 
in the first place.

Splicing features might be versioned, with the possibility of better splicing 
mechanisms being defined in later BOLT specs.  This can allow us to iterate 
somewhat and start with the simpler-but-more-onchain-txes splicev1 feature, 
possibly getting replaced with a more thought-out-and-planned splicev2 feature 
with parallel updates (and careful analysis of possible failures in parallel 
updates and how we should recover from them).  The drawback is that this is 
further complexity later on by having to possibly support multiple splicing 
mechanisms (but if we assign completely separate feature bits, it may be 
possible for pragmatic implementations to eventually stop signalling the 
ability to splice using older splicing feature versions in favor of newer 
splicing feature versions).

Regards,
ZmnSCPxj___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


Re: [Lightning-dev] Splicing Proposal: Feedback please!

2018-10-11 Thread Christian Decker
On Thu, Oct 11, 2018 at 3:40 AM Rusty Russell  wrote:

> > * Once we have enough confirmations we merge the channels (either
> > automatically or with the next channel update). A new commitment tx is
> > being created which now spends each output of each of the two funding tx
> > and assigns the channel balance to the channel partners accordingly to
> the
> > two independent channels. The old commitment txs are being invalidated.
> > * The disadvantage is that while splicing is not completed and if the
> > funder of the splicing tx is trying to publish an old commitment tx the
> > node will only be punished by sending all the funds of the first funding
> tx
> > to the partner as the special commitment tx of the 2nd output has no
> newer
> > state yet.
>
> Yes, this is the alternative method; produce a parallel funding tx
> (which only needs to support a single revocation, or could even be done
> by a long timeout) and then join them when it reaches the agreed depth.
>
> It has some elegance; particularly because one side doesn't have to do
> any validation or store anything until it's about to splice in.  You get
> asked for a key and signature, you produce a new one, and sign whatever
> tx they want.  They hand you back the tx and the key you used once it's
> buried far enough, and you check the tx is indeed buried and the output
> is the script you're expecting, then you flip the commitment tx.
>
> But I chose chose not to do this because every transaction commitment
> forever will require 2 signatures, and doesn't allow us to forget old
> revocation information.
>
> And it has some strange side-effects: onchain this looks like two
> channels; do we gossip about both?  We have to figure the limit on
> splice-in to make sure the commitment tx stays under 400kSipa.
>

This is a lot closer to my original proposal for splicing, and I
still like it a lot more since the transition from old to new
channel is bascially atomic (not having to update state on both
pre-splice and post-splice version). The new funds will remain
unavailable for the same time, and since we allow only one
concurrent splice in your proposal we don't even lose any
additional time regarding the splice-outs.

So pulling the splice_add_input and splice_add_output up to
signal the intent of adding funds to a splice. Splice_all_added
is then used to start moving the funds to a pre-allocated 2-of-2
output where the funds can mature. Once the funds are
matured (e.g., 6 confirmations) we can start the transition: both
parties claim the funding output, and the pre-allocated funds, to
create a new funding tx which is immediately broadcast, and we
flip over to the new channel state. No need to keep parallel
state and then disambiguating which one it was.

The downsides of this is that we now have 2 on-chain
transactions (pre-allocation and re-open), and splice-outs are no
longer immediate if we have a splice-in in the changeset as well.
The latter can be remediatet with one more reanchor that just
considers splice-ins that were proposed.



>
> > I believe splicing out is even safer:
> > * One just creates a spent of the funding tx which has two outputs. One
> > output goes to the recipient of the splice out operation and the second
> > output acts as a new funding transaction for the newly spliced channel.
> > Once signatures for the new commitment transaction are exchanged
> (basically
> > following the protocol to open a channel) the splicing operation can be
> > broadcasted.
> >
> > * The old channel MUST NOT be used anymore but the new channel can be
> > operational right away without blockchain confirmation. In case someone
> > tries to publish an old state of the old channel it will be a double
> spent
> > of the splicing operation and in the worst case will be punished and the
> > splicing was not successful.
> >
> >  if one publishes an old state of the new
> > channel everything will just work as normal even if the funding tx is not
> > yet mined. It could only be replaced with an old state of the previous
> > channel (which as we saw is not a larger risk than the usual operation
> of a
> > lightning node)
>
> Right, you're relying on CPFP pushing through the splice-out tx if it
> gets stuck.  This requires that we check carefully for standardness and
> other constraints which might prevent this; for example, we can't allow
> more than 20 (?) of these in a row without being sufficiently buried
> since I think that's where CPFP calculations top out.
>

We shouldn't allow more than one pending splice operation anyway, as
stated in your proposal initially. We are already critically reliant on our
transaction being confirmed on-chain, so I don't see this as much of an
added issue.


> > As mentioned maybe you had this workflow already in your mind but I don't
> > see why we need to send around all the messages twice with my workflow.
> We
> > only need to maintain double state but only until it is fair / safe to do
> > so. I would also 

Re: [Lightning-dev] Splicing Proposal: Feedback please!

2018-10-10 Thread ZmnSCPxj via Lightning-dev
Good morning Rusty,

In BOLT #2 we currently impose a 2^24 satoshi limit on total channel capacity.  
Is splicing intended to allow violation of this limit? I do not see it 
mentioned in the proposal. Can I splice 21 million bitcoins on a 1-satoshi 
channel?

It may be good to start brainstorming possible failure modes during splice, and 
how to recover, and also to indicate the expected behavior in the proposal, as 
I believe these will be the points where splicing must be designed most 
precisely. What happens when a splice is ongoing and the communication gets 
disconnected?  What happens when some channel failure occurs during splicing 
and we are forced to drop onchain?  And so on.


Regards,
ZmnSCPxj


Sent with ProtonMail Secure Email.

‐‐‐ Original Message ‐‐‐
On Wednesday, October 10, 2018 11:45 AM, Rusty Russell  
wrote:

> Hi all!
>
> We've had increasing numbers of c-lightning users get upset they
> can't open multiple channels, so I guess we're most motivated to allow
> splicing of existing channels. Hence this rough proposal.
>
> For simplicity, I've chosen to only allow a single splice at a time.
> It's still complex :(
>
> Feedback welcome!
>
> --
>
> Splice Negotiation:
>
> 1.  type: 40 (`splice_add_input`) (`option_splice`)
> 2.  data:
> -   [`32`:`channel_id`]
> -   [`8`: `satoshis`]
> -   [`32`: `prevtxid`]
> -   [`4`: `prevtxoutnum`]
> -   [`2`: `scriptlen`]
> -   [`scriptlen`: `scriptpubkey`]
> 3.  type: 41 (`splice_add_output`) (`option_splice`)
> 4.  data:
> -   [`32`:`channel_id`]
> -   [`8`: `satoshis`]
> -   [`2`: `scriptlen`]
> -   [`scriptlen`: `outscript`]
> 5.  type: 42 (`splice_all_added`) (`option_splice`)
> 6.  data:
> -   [`32`:`channel_id`]
> -   [`4`:`feerate_per_kw`]
> -   [`4`:`minimum_depth`]
>
> Each side sends 0 or more `splice_add_input` and 0 or more
> `splice_add_output` followed by `spice_all_added` to complete the 
> splice
> proposal. This is done either to initiate a splice, or to respond to a
> `splice_*` from the other party.
>
> `splice_add_input` is checked for the following:
>
>
> -   must not be during a current splice
>
> -   scriptpubkey is empty, or of form 'HASH160 <20-byte-script-hash> EQUAL'
>
> -   `satoshis` doesn't wrap on addition.
>
> -   MAY check that it matches outpoint specified (sig will simply be
> invalid if so), and that outpoint is segwit.
>
> `splice_add_output` is checked for the following:
>
> -   must not be during a current splice
>
> -   `satoshis` is less than or equal to amount owing to proposer, minus
> current reserve, and greater than or equal to `dust_limit_satoshis` we
> sent in our open_channel/accept_channel ,sg.
>
> -   script is one of the approved forms as it is for `shutdown`.
>
> FIXME: Do we disallow splice-out if they specified
> option_upfront_shutdown_script?
>
> `splice_all_added` is checked for the following:
>
> -   average of `feerate_per_kw` by both sides (round down) is sufficient.
>
> -   average of `feerate_per_kw` by both sides not grossly excessive, if we're
> paying some of the fees (see below!)
>
> -   both sides can afford the fees from their post-splice funds (see
> Verification Changes below)
>
> -   maximum of the two `minimum_depth` is not grossly excessive.
>
> -   There is at least one splice_add_input or splice_add_output.
>
> Splice negotiation, like closing negotiation, does not have persistent
> state. Reconnecting forgets previous negotiation.
>
> Splice Signing
>
>
> Once`splice_all_added` is both sent and received, we need to create and
> sign both the splice tx itself, and the first commitment transaction
> which spends it (but not in that order!).
>
> 1.  One input spends the current funding tx output.
> 2.  There is one additional input for each splice_add_input.
> 3.  One output creates the new funding tx.
> 4.  There is one additional output for each splice_add_output.
> 5.  The entire transaction is sorted into BIP69 order.
> 6.  The feerate is the sum of the two `feerate_per_kw` divided by 2,
> rounded down.
>
> 7.  type: 43 (`splice_commitment_signature`) (`option_splice`)
> 8.  data:
> -   [`32`:`channel_id`]
> -   [`64`:`commitment_signature`]
> -   [`2`:`num_htlcs`]
> -   [`num_htlcs*64`:`htlc_signature`]
> 9.  type: 44 (`splice_signature`) (`option_splice`)
> 10.  data:
> -   [`32`:`channel_id`]
> -   [`64`:`splice_signature`]
> 11.  type: 45 (`splice_witness`) (`option_splice`)
> 12.  data:
> -   [`32`:`channel_id`]
> -   [`2`: `num_witness_elements`
> -   [`2`:`len`]
> -   

[Lightning-dev] Splicing Proposal: Feedback please!

2018-10-09 Thread Rusty Russell
Hi all!

We've had increasing numbers of c-lightning users get upset they
can't open multiple channels, so I guess we're most motivated to allow
splicing of existing channels.  Hence this rough proposal.

For simplicity, I've chosen to only allow a single splice at a time.
It's still complex :(

Feedback welcome!
--
Splice Negotiation:

1. type: 40 (`splice_add_input`) (`option_splice`)
2. data:
   * [`32`:`channel_id`]
   * [`8`: `satoshis`]
   * [`32`: `prevtxid`]
   * [`4`: `prevtxoutnum`]
   * [`2`: `scriptlen`]
   * [`scriptlen`: `scriptpubkey`]

1. type: 41 (`splice_add_output`) (`option_splice`)
2. data:
   * [`32`:`channel_id`]
   * [`8`: `satoshis`]
   * [`2`: `scriptlen`]
   * [`scriptlen`: `outscript`]

1. type: 42 (`splice_all_added`) (`option_splice`)
2. data:
   * [`32`:`channel_id`]
   * [`4`:`feerate_per_kw`]
   * [`4`:`minimum_depth`]

Each side sends 0 or more `splice_add_input` and 0 or more
`splice_add_output` followed by `spice_all_added` to complete the splice
proposal.  This is done either to initiate a splice, or to respond to a
`splice_*` from the other party.

`splice_add_input` is checked for the following:
- must not be during a current splice
- scriptpubkey is empty, or of form 'HASH160 <20-byte-script-hash> EQUAL'
- `satoshis` doesn't wrap on addition.
- MAY check that it matches outpoint specified (sig will simply be
  invalid if so), and that outpoint is segwit.

`splice_add_output` is checked for the following:
- must not be during a current splice
- `satoshis` is less than or equal to amount owing to proposer, minus
  current reserve, and greater than or equal to `dust_limit_satoshis` we
  sent in our open_channel/accept_channel ,sg.
- script is one of the approved forms as it is for `shutdown`.

FIXME: Do we disallow splice-out if they specified
   option_upfront_shutdown_script?

`splice_all_added` is checked for the following:
- average of `feerate_per_kw` by both sides (round down) is sufficient.
- average of `feerate_per_kw` by both sides not grossly excessive, if we're
  paying some of the fees (see below!)
- both sides can afford the fees from their post-splice funds (see
  Verification Changes below)
- maximum of the two `minimum_depth` is not grossly excessive.
- There is at least one splice_add_input or splice_add_output.

Splice negotiation, like closing negotiation, does not have persistent
state.  Reconnecting forgets previous negotiation.


Splice Signing
--

Once `splice_all_added` is both sent and received, we need to create and
sign both the splice tx itself, and the first commitment transaction
which spends it (but not in that order!).

1. One input spends the current funding tx output.
2. There is one additional input for each splice_add_input.
3. One output creates the new funding tx.
4. There is one additional output for each splice_add_output.
5. The entire transaction is sorted into BIP69 order.
6. The feerate is the sum of the two `feerate_per_kw` divided by 2,
   rounded down.

1. type: 43 (`splice_commitment_signature`) (`option_splice`)
2. data:
   * [`32`:`channel_id`]
   * [`64`:`commitment_signature`]
   * [`2`:`num_htlcs`]
   * [`num_htlcs*64`:`htlc_signature`]

1. type: 44 (`splice_signature`) (`option_splice`)
2. data:
   * [`32`:`channel_id`]
   * [`64`:`splice_signature`]

1. type: 45 (`splice_witness`) (`option_splice`)
2. data:
   * [`32`:`channel_id`]
   * [`2`: `num_witness_elements`
   * [`2`:`len`]
   * [`len`:`witnesses`]

`witnesses` itself is serialized as `num_witness_elements` of:
* `2`:`len`
* `len`: `witness_element`

Each side sends `splice_commitment_signature` and waits to receive and
verify the other side's `splice_commitment_signature` before sending
`splice_signature` and `splice_witness` for each `splice_add_input` it
proposed, in BIP69 input order.

Once a node has sent `splice_commitment_signature` it should remember
the splice proposal across reconnects.  Once it has both sent
`splice_signature`, the splice is locked in.


Splice Announcement
---

We have to tell the network about the new channel, otherwise there will
be a distruption when it sees the old funding transaction spent.  This
is inevitable for older nodes who won't understand splicing anyway.

We can't send out a `channel_announcement` or `channel_update` for the
new channel until after the new funding transaction has 6 confirmations,
so we append to the existing `channel_update` for the original channel,
using a new `message_flags` field:

| Bit Position  | Name  | Field|
| - | - |  |
| 0 | `option_channel_htlc_max` | `htlc_maximum_msat`  |
| 1 | `option_channel_moving`   | `moving_txid |

The `channel_update` gains the following field:
* [`32`: moving_txid`] (option_channel_moving)

If a current `channel_update` for a closing channel