From fcd456dbee9b936ed24d819ee997124094cc5f5c Mon Sep 17 00:00:00 2001 From: Tyler van der Hoeven Date: Mon, 13 Jun 2022 09:41:06 -0400 Subject: [PATCH 1/6] Rough in a Rationale section outlining why CAP 21 + 40 usage makes sense --- .../starlight-payment-channel-mechanics.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/specifications/starlight-payment-channel-mechanics.md b/specifications/starlight-payment-channel-mechanics.md index 43edf0d1..ed48d27d 100644 --- a/specifications/starlight-payment-channel-mechanics.md +++ b/specifications/starlight-payment-channel-mechanics.md @@ -735,6 +735,18 @@ methods through which more than two participants can coordinate and exchange dependent agreements. These issues are likely to be discussed in separate proposals. +## Rationale +### Why use `extraSigners` and atomic signature disclosure instead of pre-authorized transactions? +Using a preauth tx works too to some degree, however it creates a ledger entry, and any operation that creates a ledger entry has extra failure cases. The most relevant here is that lumens required for the entry. If those lumens are missing the tx will fail, but the tx will still have been included in the ledger and the sequence number will have been consumed on the source account. If the failed tx was the most recent close tx then the channel will be stuck unless the participants agree to sign a new set of txs, which could mean one party can hold the other part ransom. + +One of the proprieties of Starlight's protocol is that no ledger entries must be created for its operation once open. + +### Why use atomic signature disclosure instead of hashX `extraSigners` +In order to generate a valid hashX signer for the `extraSigners` field in the Declaration transaction and thus reveal the Close signature you need the counter party to sign the Close transaction hash thus introducing an additional trip. Atomic signature disclosure reduces this two step process down to a one step process by effectively introducing a blank signature request of a payload vs requiring the payload be signed before the transaction can even be constructed. + +### Why use accounts vs claimable balances for storing channel balances +// TODO + ## Implementations Prototype implementation of these mechanics are in the `sdk/state` package of: From 2034ea36b8e1ed8f29d6b60a41039a3606268920 Mon Sep 17 00:00:00 2001 From: Leigh McCulloch <351529+leighmcculloch@users.noreply.github.com> Date: Wed, 15 Jun 2022 09:32:53 -0700 Subject: [PATCH 2/6] shift --- .../starlight-payment-channel-mechanics.md | 39 ++++++++++++------- 1 file changed, 26 insertions(+), 13 deletions(-) diff --git a/specifications/starlight-payment-channel-mechanics.md b/specifications/starlight-payment-channel-mechanics.md index ed48d27d..a965d035 100644 --- a/specifications/starlight-payment-channel-mechanics.md +++ b/specifications/starlight-payment-channel-mechanics.md @@ -589,6 +589,20 @@ Changes in the networks base reserve do not impact the channel. ## Security Concerns +### Sponsoring Ledger Entries + +The protocol does not, and must not, create new sponsorship of ledger entries +while the channel is open. Any Stellar operation that creates a ledger entry +depends on sponsorship and the transaction containing the operation may fail +when being applied if the sponsorship cannot be satisfied. When the operation +fails, the transaction containing it fails, consuming the sequence number of the +transaction even though it was not successful. If the sequence number of the +declaration or close transactions are consumed without being successful the +channel may be in a state where participants would need to collaborate honestly +to close the channel. + +This constraint is why the protocol does not use claimable balances or preauthorized transactions, as both features create ledger entries. + ### Transaction Signing Order In many of the processes outlined in the protocol an order is provided to when @@ -689,7 +703,7 @@ liabilities are the sum of all selling offers for the asset and therefore represent the maximum amount the balance could be reduced if all offers were consumed. -### Transaction Signature Disclosure +### Atomic Transaction Signature Disclosure Processes that require the signing of multiple transactions make use of an ed25519 signed payload signer proposed in [CAP-40] and the `extraSigners` @@ -704,6 +718,17 @@ could submit a subset of the transactions required by the process and the participant will not have any other capability to authorize and submit the remaining transactions. +It may be observed that it could be possible to create a link between multiple +transactions by using other mechanisms on the Stellar network by using hash +locks, such as the `HASH_X` signer. For example, it has been previously proposed +that a `HASH_X` signer of the close transaction's signature could be included in +the declaration transaction's `extraSigners` requiring the reveal of the close +transaction's signature. However, there is no efficient method to prove that a +`HASH_X` signer is the hash of a valid signature of the close transaction which +introduces some uncertainty for the payer participant. Also, exchanging the hash +would need to occur prior to the agreement signatures being exchanged, +introducing additional messages reducing on-the-wire efficiency. + ### Queueing Multiple Payments This protocol implicitly supports participants sending multiple payments to the @@ -735,18 +760,6 @@ methods through which more than two participants can coordinate and exchange dependent agreements. These issues are likely to be discussed in separate proposals. -## Rationale -### Why use `extraSigners` and atomic signature disclosure instead of pre-authorized transactions? -Using a preauth tx works too to some degree, however it creates a ledger entry, and any operation that creates a ledger entry has extra failure cases. The most relevant here is that lumens required for the entry. If those lumens are missing the tx will fail, but the tx will still have been included in the ledger and the sequence number will have been consumed on the source account. If the failed tx was the most recent close tx then the channel will be stuck unless the participants agree to sign a new set of txs, which could mean one party can hold the other part ransom. - -One of the proprieties of Starlight's protocol is that no ledger entries must be created for its operation once open. - -### Why use atomic signature disclosure instead of hashX `extraSigners` -In order to generate a valid hashX signer for the `extraSigners` field in the Declaration transaction and thus reveal the Close signature you need the counter party to sign the Close transaction hash thus introducing an additional trip. Atomic signature disclosure reduces this two step process down to a one step process by effectively introducing a blank signature request of a payload vs requiring the payload be signed before the transaction can even be constructed. - -### Why use accounts vs claimable balances for storing channel balances -// TODO - ## Implementations Prototype implementation of these mechanics are in the `sdk/state` package of: From 1b4c971cc643057347b7fbbe3818fd1271ec8a96 Mon Sep 17 00:00:00 2001 From: Leigh McCulloch <351529+leighmcculloch@users.noreply.github.com> Date: Wed, 15 Jun 2022 09:41:05 -0700 Subject: [PATCH 3/6] fmt --- specifications/starlight-payment-channel-mechanics.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/specifications/starlight-payment-channel-mechanics.md b/specifications/starlight-payment-channel-mechanics.md index a965d035..5c98e0db 100644 --- a/specifications/starlight-payment-channel-mechanics.md +++ b/specifications/starlight-payment-channel-mechanics.md @@ -601,7 +601,8 @@ declaration or close transactions are consumed without being successful the channel may be in a state where participants would need to collaborate honestly to close the channel. -This constraint is why the protocol does not use claimable balances or preauthorized transactions, as both features create ledger entries. +This constraint is why the protocol does not use claimable balances or +preauthorized transactions, as both features create ledger entries. ### Transaction Signing Order From 16cd1005b20b45c66e10e6e2f0a2ec625586636d Mon Sep 17 00:00:00 2001 From: Leigh McCulloch <351529+leighmcculloch@users.noreply.github.com> Date: Wed, 15 Jun 2022 09:42:22 -0700 Subject: [PATCH 4/6] typo --- .../starlight-payment-channel-mechanics.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/specifications/starlight-payment-channel-mechanics.md b/specifications/starlight-payment-channel-mechanics.md index 5c98e0db..ca407a8d 100644 --- a/specifications/starlight-payment-channel-mechanics.md +++ b/specifications/starlight-payment-channel-mechanics.md @@ -593,13 +593,13 @@ Changes in the networks base reserve do not impact the channel. The protocol does not, and must not, create new sponsorship of ledger entries while the channel is open. Any Stellar operation that creates a ledger entry -depends on sponsorship and the transaction containing the operation may fail -when being applied if the sponsorship cannot be satisfied. When the operation -fails, the transaction containing it fails, consuming the sequence number of the -transaction even though it was not successful. If the sequence number of the -declaration or close transactions are consumed without being successful the -channel may be in a state where participants would need to collaborate honestly -to close the channel. +depends on sponsorship may cause the transaction containing the operation to +fail when being applied if the sponsorship cannot be satisfied. When the +operation fails, the transaction containing it fails, consuming the sequence +number of the transaction even though it was not successful. If the sequence +number of the declaration or close transactions are consumed without being +successful the channel may be in a state where participants would need to +collaborate honestly to close the channel. This constraint is why the protocol does not use claimable balances or preauthorized transactions, as both features create ledger entries. From 97b10074c441f8f884f59d98e5b5d10a3cdc08f4 Mon Sep 17 00:00:00 2001 From: Leigh McCulloch <351529+leighmcculloch@users.noreply.github.com> Date: Wed, 15 Jun 2022 09:42:59 -0700 Subject: [PATCH 5/6] words --- .../starlight-payment-channel-mechanics.md | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-) diff --git a/specifications/starlight-payment-channel-mechanics.md b/specifications/starlight-payment-channel-mechanics.md index ca407a8d..2d51cd42 100644 --- a/specifications/starlight-payment-channel-mechanics.md +++ b/specifications/starlight-payment-channel-mechanics.md @@ -593,13 +593,12 @@ Changes in the networks base reserve do not impact the channel. The protocol does not, and must not, create new sponsorship of ledger entries while the channel is open. Any Stellar operation that creates a ledger entry -depends on sponsorship may cause the transaction containing the operation to -fail when being applied if the sponsorship cannot be satisfied. When the -operation fails, the transaction containing it fails, consuming the sequence -number of the transaction even though it was not successful. If the sequence -number of the declaration or close transactions are consumed without being -successful the channel may be in a state where participants would need to -collaborate honestly to close the channel. +depends on sponsorship may fail when being applied if the sponsorship cannot be +satisfied. When the operation fails, the transaction containing it fails, +consuming the sequence number of the transaction even though it was not +successful. If the sequence number of the declaration or close transactions are +consumed without being successful the channel may be in a state where +participants would need to collaborate honestly to close the channel. This constraint is why the protocol does not use claimable balances or preauthorized transactions, as both features create ledger entries. From 7ca9e2effb42f0d1073ca00c484ac9491c5d4c08 Mon Sep 17 00:00:00 2001 From: Leigh McCulloch <351529+leighmcculloch@users.noreply.github.com> Date: Wed, 15 Jun 2022 09:44:30 -0700 Subject: [PATCH 6/6] words --- specifications/starlight-payment-channel-mechanics.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/specifications/starlight-payment-channel-mechanics.md b/specifications/starlight-payment-channel-mechanics.md index 2d51cd42..cbbcb685 100644 --- a/specifications/starlight-payment-channel-mechanics.md +++ b/specifications/starlight-payment-channel-mechanics.md @@ -727,7 +727,7 @@ transaction's signature. However, there is no efficient method to prove that a `HASH_X` signer is the hash of a valid signature of the close transaction which introduces some uncertainty for the payer participant. Also, exchanging the hash would need to occur prior to the agreement signatures being exchanged, -introducing additional messages reducing on-the-wire efficiency. +introducing additional messages and reducing on-the-wire efficiency. ### Queueing Multiple Payments