Olaoluwa Osuntokun [ARCHIVE] on Nostr: 📅 Original date posted:2018-10-15 📝 Original message: Hi Rusty, Happy to get ...
📅 Original date posted:2018-10-15
📝 Original message:
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)
Is there a fundamental reason that CL will never allow nodes to create
multiple channels? It seems unnecessarily limiting.
> 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.
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.
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.
> 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? :(
> * [`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.
> 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.
Also, what about change addresses? Are they to be explicitly specified as
splice outs?
> 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.
> 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!).
> * [`2`:`len`]
> * [`len`:`witnesses`]
Is the extra length needed if all the witness elements themselves are length
delimited?
It isn't clear in the current draft, but I take it that the splice_signature
is for the old multi-sig?
> so we append to the existing `channel_update` for the original channel,
> using a new `message_flags` field:
IMO, we need to hold off on optional fields for now, until we revisit the
formatting in order to actually get it right. As is now, all the optional
fields are basically serial mandatory soft forks. So clients must understand
the prior in order to understand the following fields. Instead, we
essentially need more of a map design.
> The post-splice reserve is 1% of post-splice capcacity (rounded down).
This should be re-negotiated at time of splice creation, rather than a new
hard coded value in the protocol.
> In addition, you can forget everything about the old channel (including
> old HTLCs and revocation requirements).
We still have the same shachain state however (if we don't allow new state
to be exchanged during the start of the splicing scenario), correct?
-- Laolu
-- Laolu
On Tue, Oct 9, 2018 at 8:46 PM Rusty Russell <rusty at rustcorp.com.au> 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`]
>
> 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 contains
> `option_channel_moving` a node SHOULD ignore the channel close for at
> least 100 blocks iff spent by `moving_txid`.
>
> A node SHOULD immediately forward a `channel_update` it sees containing
> `option_channel_moving` if neither previous `channel_update` for the
> channel contains `option_channel_moving`.
>
> Each side of the splice can send these unilaterally, and SHOULD allow a
> few minutes for propagation (remember, average propagation from old
> nodes is still 30 seconds) prior to broadcast of the splice transaction.
>
>
> Message Changes During Splicing
> -------------------------------
> Once you've sent `splice_commitment_signature` each commitment
> transaction is duplicated: one spends the old funding transaction, one
> spends the splice transaction:
>
> 1. type: 39 (`closing_signed`)
> 2. data:
> * [`32`:`channel_id`]
> * [`8`:`fee_satoshis`]
> * [`64`:`signature`]
> * [`64`:`splice_signature`] (`option_splice`)
>
> 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`)
>
> If a reconnection occurs between between sending and receiving
> `splice_commitment_signature`) the peer's status is uncertain (similarly
> for closing). This we have a new field in `channel_reestablish` to flag
> that we consider ourselves to be splicing:
>
> 1. type: 136 (`channel_reestablish`)
> 2. data:
> * [`32`:`channel_id`]
> * [`8`:`next_local_commitment_number`]
> * [`8`:`next_remote_revocation_number`]
> * [`32`:`your_last_per_commitment_secret`] (`option_data_loss_protect`)
> * [`33`:`my_current_per_commitment_point`] (`option_data_loss_protect`)
> * [`32`:`splice_txid`] (`option_splice`)
>
> The splice_txid field indicates that this side considers itself to be
> splicing.
>
> The sender:
> - if it has sent `splice_commitment_signature` and not sent the
> corresponding
> `splice_closed`, MUST set `splice_txid` to the txid of the splice tx.
> - Otherwise MUST NOT.
>
> The recipient:
> - if it has sent `splice_commitment_signature` and not sent the
> corresponding
> `splice_closed`:
> - if `splice_txid` does not exist or does not match the current splice:
> - SHOULD fail the channel
> - otherwise:
> - MUST retransmit `splice_signature`
> - otherwise:
> - if `splice_txid` field exists and is not all zeroes:
> - MUST send `splice_closed`
>
>
> Validation Changes During Splicing
> ----------------------------------
> We track "post-splice" values as well as current values during
> splicing.
>
> The post-splice reserve is 1% of post-splice capcacity (rounded down).
>
> The fees for the splicing transaction itself are divided into parts by
> the number of `splice_add_input` plus `splice_add_output`, rounded up.
> Each side pays as many parts as it proposed `splice_add_input` plus
> `splice_add_output`.
>
> (So if Alice proposes two and Bob proposes one, and the total fee is 1000
> satoshi, each part is 334 satoshi: Alice pays 668 and Bob pays 334.)
>
> Each side's post-splice funds are debited their `splice_add_output`
> amounts, and credited their `splice_add_input` amounts, a debited the
> splice tx fees. If any debiting occurs, the funds must be above the
> post-splice reserve (ie. you can have below reserve, but you can't spend
> if you're below reserve).
>
> All update_add_htlc must be valid for the *both* the current and
> post-splice balances.
>
> Completing Splicing
> -------------------
> Once you've seen both side's `minimum_depth` confirmations of the splice
> transaction (ie. the maximum of the two `minimum_depth` values), you can
> complete the splice by sending:
>
> 1. type: 46 (`splice_closed`) (`option_splice`)
> 2. data:
> * [`32`:`channel_id`]
>
> Once you've sent and received `splice_closed` you can send
> `announcement_signatures` for the new channel as per normal rules (ie. 6
> confirmations, `announce_channel` bit set).
>
> In addition, you can forget everything about the old channel (including
> old HTLCs and revocation requirements).
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181015/493ab074/attachment-0001.html>;
📝 Original message:
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)
Is there a fundamental reason that CL will never allow nodes to create
multiple channels? It seems unnecessarily limiting.
> 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.
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.
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.
> 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? :(
> * [`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.
> 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.
Also, what about change addresses? Are they to be explicitly specified as
splice outs?
> 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.
> 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!).
> * [`2`:`len`]
> * [`len`:`witnesses`]
Is the extra length needed if all the witness elements themselves are length
delimited?
It isn't clear in the current draft, but I take it that the splice_signature
is for the old multi-sig?
> so we append to the existing `channel_update` for the original channel,
> using a new `message_flags` field:
IMO, we need to hold off on optional fields for now, until we revisit the
formatting in order to actually get it right. As is now, all the optional
fields are basically serial mandatory soft forks. So clients must understand
the prior in order to understand the following fields. Instead, we
essentially need more of a map design.
> The post-splice reserve is 1% of post-splice capcacity (rounded down).
This should be re-negotiated at time of splice creation, rather than a new
hard coded value in the protocol.
> In addition, you can forget everything about the old channel (including
> old HTLCs and revocation requirements).
We still have the same shachain state however (if we don't allow new state
to be exchanged during the start of the splicing scenario), correct?
-- Laolu
-- Laolu
On Tue, Oct 9, 2018 at 8:46 PM Rusty Russell <rusty at rustcorp.com.au> 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`]
>
> 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 contains
> `option_channel_moving` a node SHOULD ignore the channel close for at
> least 100 blocks iff spent by `moving_txid`.
>
> A node SHOULD immediately forward a `channel_update` it sees containing
> `option_channel_moving` if neither previous `channel_update` for the
> channel contains `option_channel_moving`.
>
> Each side of the splice can send these unilaterally, and SHOULD allow a
> few minutes for propagation (remember, average propagation from old
> nodes is still 30 seconds) prior to broadcast of the splice transaction.
>
>
> Message Changes During Splicing
> -------------------------------
> Once you've sent `splice_commitment_signature` each commitment
> transaction is duplicated: one spends the old funding transaction, one
> spends the splice transaction:
>
> 1. type: 39 (`closing_signed`)
> 2. data:
> * [`32`:`channel_id`]
> * [`8`:`fee_satoshis`]
> * [`64`:`signature`]
> * [`64`:`splice_signature`] (`option_splice`)
>
> 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`)
>
> If a reconnection occurs between between sending and receiving
> `splice_commitment_signature`) the peer's status is uncertain (similarly
> for closing). This we have a new field in `channel_reestablish` to flag
> that we consider ourselves to be splicing:
>
> 1. type: 136 (`channel_reestablish`)
> 2. data:
> * [`32`:`channel_id`]
> * [`8`:`next_local_commitment_number`]
> * [`8`:`next_remote_revocation_number`]
> * [`32`:`your_last_per_commitment_secret`] (`option_data_loss_protect`)
> * [`33`:`my_current_per_commitment_point`] (`option_data_loss_protect`)
> * [`32`:`splice_txid`] (`option_splice`)
>
> The splice_txid field indicates that this side considers itself to be
> splicing.
>
> The sender:
> - if it has sent `splice_commitment_signature` and not sent the
> corresponding
> `splice_closed`, MUST set `splice_txid` to the txid of the splice tx.
> - Otherwise MUST NOT.
>
> The recipient:
> - if it has sent `splice_commitment_signature` and not sent the
> corresponding
> `splice_closed`:
> - if `splice_txid` does not exist or does not match the current splice:
> - SHOULD fail the channel
> - otherwise:
> - MUST retransmit `splice_signature`
> - otherwise:
> - if `splice_txid` field exists and is not all zeroes:
> - MUST send `splice_closed`
>
>
> Validation Changes During Splicing
> ----------------------------------
> We track "post-splice" values as well as current values during
> splicing.
>
> The post-splice reserve is 1% of post-splice capcacity (rounded down).
>
> The fees for the splicing transaction itself are divided into parts by
> the number of `splice_add_input` plus `splice_add_output`, rounded up.
> Each side pays as many parts as it proposed `splice_add_input` plus
> `splice_add_output`.
>
> (So if Alice proposes two and Bob proposes one, and the total fee is 1000
> satoshi, each part is 334 satoshi: Alice pays 668 and Bob pays 334.)
>
> Each side's post-splice funds are debited their `splice_add_output`
> amounts, and credited their `splice_add_input` amounts, a debited the
> splice tx fees. If any debiting occurs, the funds must be above the
> post-splice reserve (ie. you can have below reserve, but you can't spend
> if you're below reserve).
>
> All update_add_htlc must be valid for the *both* the current and
> post-splice balances.
>
> Completing Splicing
> -------------------
> Once you've seen both side's `minimum_depth` confirmations of the splice
> transaction (ie. the maximum of the two `minimum_depth` values), you can
> complete the splice by sending:
>
> 1. type: 46 (`splice_closed`) (`option_splice`)
> 2. data:
> * [`32`:`channel_id`]
>
> Once you've sent and received `splice_closed` you can send
> `announcement_signatures` for the new channel as per normal rules (ie. 6
> confirmations, `announce_channel` bit set).
>
> In addition, you can forget everything about the old channel (including
> old HTLCs and revocation requirements).
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181015/493ab074/attachment-0001.html>;