Add subchannel spec #1

Tibo-lg · 2021-10-21T07:59:57Z

No description provided.

Ichiro0219 · 2021-10-22T00:37:39Z

XX-sub-channel.md

+
+    OP_IF
+        # Penalty transaction
+        <split_pubkey>


Explanation of <split_pubkey> may be necessary.

Added some explanation here hope it helps.

Ichiro0219 · 2021-10-22T01:13:35Z

XX-sub-channel.md

+        `to_self_delay`
+        OP_CHECKSEQUENCEVERIFY
+        OP_DROP
+        <local_delayedpubkey>


Isn't it something like this?
2 <local_pubkey> <remote_pubkey> 2 OP_CHECKMULTISIG

Yes it is thanks for spotting that!

Ichiro0219 · 2021-10-22T02:11:31Z

XX-sub-channel.md

+    - MUST set `next_per_commitment_points` to the values for the next commitment transactions of each sub-channel.
+    - MUST set `split_signature` to the Bitcoin signature of the split transaction of the sending party.
+    - MUST set each commitment transaction `signature` to the Bitcoin signature of the commitment transaction of the receiving party for the corresponding sub-channel.
+  - if `nb_subchannels` is equal to 0:


s/nb_subchannels/num_subchannels

Ichiro0219 · 2021-10-22T02:23:57Z

XX-sub-channel.md

+
+  - MUST set `per_split_secret` to the secret used to generate keys for the previous split/commitment transaction.
+  - MUST set `next_per_split_point` to the values for its next split/commitment transaction.
+  - MUST set `nb_subchannels` to the same value as in the received `subchannel_request`.


s/nb_subchannels/num_subchannels

Ichiro0219 · 2021-10-22T02:24:11Z

XX-sub-channel.md

+  - MUST set `per_split_secret` to the secret used to generate keys for the previous split/commitment transaction.
+  - MUST set `next_per_split_point` to the values for its next split/commitment transaction.
+  - MUST set `nb_subchannels` to the same value as in the received `subchannel_request`.
+  - if `nb_subchannels` is greater than 1:


s/nb_subchannels/num_subchannels

Ichiro0219 · 2021-10-22T04:58:09Z

XX-sub-channel.md

+   * [`point`: `next_per_split_point`]
+   * [`u8`: `num_subchannels`]
+   *   [`signature`: `signature`]        ‾|
+   *   [`point`: `next_per_commitment_point`] _| x num_subchannels


s/point/num_subchannels * point/ ?

In The subchannel_finalize message, next_per_commitment_point is defined as below:

[num_subchannels * point:next_per_commitment_point]

Yeah this is just a notation detail, in subchannel_finalize there is only a single field that is * num_subchannels while for request and accept there are multiple.

ariard · 2021-11-03T00:31:04Z

XX-sub-channel.md

+
+Each output of a split transaction is delayed to allow an opportunity for the counter party to submit a penalty transaction.
+It can be claimed without delay by the counter-party with the revocation secret and a signature using its `split_key`.
+Note that due to the addition of the split transaction, recovery of fund in the case of a unilateral close takes twice as much time than for a regular channel.


I think one additional point is that go-to-chain deadline for received/accepted HTLC, as laid out in the BOLT2's cltv_expiry_delta selection, should be scaled in consequence to include the split_tx's CSV.

Good point. I added something to mention it but I'm not 100% confident about what's a safe buffer here so let me know what you think.

ariard · 2021-11-03T00:40:00Z

XX-sub-channel.md

+
+## Split transaction
+
+The split transaction is used to fan out the fund output to multiple ones that can be used as inputs to sub-channels.


I think a counterparty can block your fee-bumping ability by broadcasting chain of junk transactions attached on the anchor output of one of the commitment transaction. And as such interfere with a time-sensitive confirmation of your split_tx.

To remedy I would say you need to add a pair of anchor at the split_tx-level and encumber the sub-channels outputs with a 1-block CSV.

Yes I think indeed anchor outputs might be necessary, added a small paragraph. Though since the outputs are already not spendable by a single party without knowledge of revocation secret I don't think they need any change?

ariard · 2021-11-03T00:43:49Z

XX-sub-channel.md

+
+The split transaction is used to fan out the fund output to multiple ones that can be used as inputs to sub-channels.
+
+In order to enable updates to the set of sub-channels, a split transaction can be revoked, meaning that each party holds a different version, and all of the outputs are timelocked or spendable directly with knowledge of the correct secrets, which consist of a revocable secret updated every time the split transaction is updated, and a `split_key` whose public point should be exchanged prior to the sub-channel establishment.


I think one simplification could be to unify the revocation paths across the transaction stage of the protocol under the argument that if a counterparty "cheats" on one level it contamines the whole tree of transaction. One revocation point could be used for the split_tx, the commitment_tx and the HTLC ones, that way avoiding to inflate commitment_tx/HTLC_txn scripts with one more path for the split_tx specific revocation.

I think one simplification could be to unify the revocation paths across the transaction stage of the protocol under the argument that if a counterparty "cheats" on one level it contamines the whole tree of transaction. One revocation point could be used for the split_tx, the commitment_tx and the HTLC ones

Mmmm I don't really follow you here. The split tx and commitment tx can be revoked separately so it doesn't really make sense to me for them to share the same revocation point. Am I misunderstanding what you're saying?

One revocation point could be used for the split_tx, the commitment_tx and the HTLC ones, that way avoiding to inflate commitment_tx/HTLC_txn scripts with one more path for the split_tx specific revocation.

Also I'm not sure what you mean here, in my mind the commitment tx and htlc txs don't need to have anything about the split tx, can you clarify for me?

ariard · 2021-11-03T00:58:08Z

XX-sub-channel.md

+  - if the sum of all `sender_satoshis`is not equal to the previous balance of the sending party (plus or minus the fee difference with the previous channel state if the sender funded the channel):
+    - SHOULD fail the channel.
+  - if the sum of all `reveiver_satoshis`is not equal to the previous balance of the sending party (plus or minus the fee difference with the previous channel state if the receiver funded the channel):
+    - SHOULD fail the channel.


What if the funder doesn't have balance liquidity to cover the split_tx and the sub-channels txn at the negotiated feerate ? Should the request be rejected ?

Added a bullet point for this thanks

ariard · 2021-11-03T01:01:38Z

XX-sub-channel.md

+A sending node:
+  - MUST not set `num_subchannels` to 1.
+  - MUST set `num_subchannels` to a value greater than 1 if the channel is a single channel at the time of sending.
+  - MUST set the values `sender_satoshis` and `receiver_satoshis` of the first sub-channel to large enough values to provide for all HTLC outputs and satisfy each peer's channel reserve.


I think it could be defined more precisely as sender_satoshis the sum of requester balance and outbound HTLCs and receiver_satoshis the sum of accepter balance and inbound HTLCs. And maybe the funder sub-channel balance should be large enough to cover at least one commitment + one CET ?

Updated, though I prefer not to mention CET in this doc. I think it's better to leave it up to the application layer to decide whether sub-channel size is adequate or not. If not then the reject message can be used, and is not a violation of the protocol but just not adequate with the application.

ariard · 2021-11-03T01:10:35Z

XX-sub-channel.md

+
+There is a possibility that the two nodes of a channel send a `subchannel_request` message at around the same time.
+To solve this, the node with the highest `node_id` MUST reply with a `subchannel_reject` message if it receives a `subchannel_request` message after having sent a `subchannel_request` message of its own and before receiving a `subchannel_accept` or `subchannel_reject` message.
+If the node with the highest `node_id` the receives a `subchannel_reject` message, it SHOULD wait for a small amount of time before sending another `subchannel_request` message to leave time to the other peer to send its own request.


I think you might need to introduce a update ordering rule across the split_tx state machine and the sub-channel ones, otherwise you have a risk the update split_tx-level to always halt. I.e the split_tx is updated, an update_add_htlc is exchanged, the split_tx must wait for inclusion otherwise signature is broken, though once done, simultaneously a CET has been proposed in another sub-channel, etc.

I need some more time to think about this. I think indeed there might be some issues if receiving an update_add_htlc right after having sent a subchannel_request that make your request invalid, is that what you mean?

otherwise signature is broken

I'm not sure I understand this part, which signature would be broken?

Tibo-lg force-pushed the add-subchannel-spec branch 3 times, most recently from af866e4 to f2317cc Compare October 22, 2021 01:18

Ichiro0219 reviewed Oct 22, 2021

View reviewed changes

Tibo-lg force-pushed the add-subchannel-spec branch 2 times, most recently from 16064e9 to 0a07288 Compare October 22, 2021 08:00

ariard reviewed Nov 3, 2021

View reviewed changes

Tibo-lg force-pushed the add-subchannel-spec branch from 0a07288 to 62049ab Compare November 5, 2021 06:22

Add subchannel spec

3801a27

Tibo-lg force-pushed the add-subchannel-spec branch from 62049ab to 3801a27 Compare November 5, 2021 12:03


		## Split transaction

		The split transaction is used to fan out the fund output to multiple ones that can be used as inputs to sub-channels.


		The split transaction is used to fan out the fund output to multiple ones that can be used as inputs to sub-channels.

		In order to enable updates to the set of sub-channels, a split transaction can be revoked, meaning that each party holds a different version, and all of the outputs are timelocked or spendable directly with knowledge of the correct secrets, which consist of a revocable secret updated every time the split transaction is updated, and a `split_key` whose public point should be exchanged prior to the sub-channel establishment.

Add subchannel spec #1

Are you sure you want to change the base?

Add subchannel spec #1

Uh oh!

Conversation

Tibo-lg commented Oct 21, 2021

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants