Topics: Add Swap-in Potentiam (SIP) #1538
Conversation
arshbot
force-pushed
the
swap-in-potentiam
branch
from
a4b9f0a to
6f0a54c
Compare
Co-authored-by: Mike Schmidt <[email protected]>
|
Got |
_topics/en/swap-in-potentiam.md
Outdated
| link: https://gist.github.com/t-bast/5fd89979a8088b99d0b95c124902aa56 | ||
|
|
||
| --- | ||
| SIP is a [submarine swap][topic submarine swaps] |
There was a problem hiding this comment.
Is it? As I think about it, a submarine swap starts with Alice and Bob both already having channels; Alice creates a UTXO that Bob can only spend if by revealing a preimage that will allow Alice to claim sats in her channel.
A SIP can start with neither party having a channel and only one party contributing any funding. The second party doesn't give the first party anything (except a signature, if the first party wants to fully open the channel). That doesn't seem like a "swap" to me at all. I think it's just an alternative channel opening protocol.
There was a problem hiding this comment.
That doesn't seem like a "swap" to me at all. I think it's just an alternative channel opening protocol.
This is an incomplete understanding of SiP. At it's core, the "potentiam" addition to "swap-in" is earned by adding optionality to funds a mobile wallet receives onchain.
Once a mobile wallet receives funds onchain (to the script address generated by LSP & mobile wallet), the wallet has the following options with the LSPs cooperation:
- Swap in onchain funds to wallet's lightning channel
- Create a new channel to wallet
- Send to another onchain address
With an additional trapdoor after some long period of time:
- Unilateral send onchain by wallet.
Aside from the advantages above, an LSP can support SiP without supporting creating new channels because SiP offers the following advantages
- static receiving address
- onchain offline receiving for lightning only wallets
There was a problem hiding this comment.
Might be worth illustrating these paths in the article. Is mermaidjs or similar supported?
There was a problem hiding this comment.
Something else worth pointing out, Lightning Labs is supporting this scheme in their static loop in upgrade, but not supporting any channel creation functionality
There was a problem hiding this comment.
Mermaidjs is not supported. You can draw graphs in any tool, export or screenshot them, and include a PNG. Several articles do this, you can cd _topics/en/ ; git grep '\.png' for examples.
I still don't think SIPs are a type of submarine swap, but if that's a claim supported by its authors, I'm fine with us saying that.
There was a problem hiding this comment.
I am also surprised by the categorization of a swap-in potentiam as a Submarine Swap. Maybe the definition of Submarine Swaps has evolved, but my understanding of Submarine Swaps was that they allowed the first or the last hop of a multi-hop payment to be executed on-chain, and it involved the on-chain funds to be locked in an HTLC construction. It does not seem to me that a splice-in and submarine swap are all that similar. I’m not sure bringing submarine swaps into the explanation makes it easier to understand since Submarine Swaps seem more complicated than SIP itself.
There was a problem hiding this comment.
Revisiting this, I hold that SIP has the same broadly used utility of submarine swaps (moving funds from onchain to an existing lightning channel and vice versa) with a different mechanism that doesn't allow final hop, and thus not comparable to an HTLC. To me, HTLC is mechanism and subswap is function (or else all HTLC behavior would be considered a subswap).
If this is still a sticking point, I'd propose a change with wording that waters down the comparison, but still keeps it in. Keeping the comparison to submarine swaps helps the reader understand that this is a tool to achieve the same utility with a different mechanism. I can also elaborate on the differences as well.
There was a problem hiding this comment.
I still don’t see how it would be beneficial to group these together.
FWIU, SIP refers to receiving an on-chain payment in a way that stages funds for a later splice-in or channel opening operation because they are already temporarily co-owned by the channel co-owners (or to-be channel co-owners). I would be open to an argument that splicing is similar to submarine swaps, but SIP seems to be a separate, removed step from it.
There was a problem hiding this comment.
Sure, happy to streamline here. Removed the direct comparison.
_topics/en/swap-in-potentiam.md
Outdated
| SIP is primarily geared towards mobile users who may go offline for extended | ||
| periods of time. The main trick of SIP is splitting the confirmation | ||
| requirements between a pre-commital address and a commited address, allowing | ||
| for the immediate usage of funds when the mobile user comes online. |
There was a problem hiding this comment.
I don't understand what you mean by "splitting the confirmation requirements between a pre-committal address and a committed address".
There was a problem hiding this comment.
In current swaps Alice has to know what she intends to do with onchain btc once she receives it. With SiP, Alice can have an address floating around and decide what she'd like to do with it as soon as money hits. If she's not around, once the money has confirmed and she's online, she can instantaneously decide what to do with it (any of the 3 options I noted in this comment)
By splitting the flow of funds by adding a "waiting room" of sorts, Alice can always receive and decide what to do with the money later.
There was a problem hiding this comment.
If this sentence just restates the previous paragraph, we can probably drop it and eliminate any confusion it causes.
There was a problem hiding this comment.
It provides a short summary and reframes the previous few paragraphs into a succinct conclusion centered around confirmations, while the previous paragraphs are centered around interactions between Alice and Bob.
It certainly adds to readability, it's worth the extra line or two for reader comprehension.
There was a problem hiding this comment.
I also find this sentence more confusing than helpful.
Co-authored-by: Larry Ruane <[email protected]>
Co-authored-by: Larry Ruane <[email protected]>
Co-authored-by: Larry Ruane <[email protected]>
There was a problem hiding this comment.
@arshbot looks like we are pretty close on this PR, thanks for hanging in here!
From what I see there are a couple outstanding feedback items:
-
"I think we need to explain to the reader what baseline trust model we're comparing this to is when we make a claim that this lowers trust requirements" via Topics: Add Swap-in Potentiam (SIP) #1538 (comment)
-
Discrepancy around the classification of sip as a submarine swap. via Topics: Add Swap-in Potentiam (SIP) #1538 (comment) I think if we achieve "if that's a claim supported by its authors" (Topics: Add Swap-in Potentiam (SIP) #1538 (comment)) then we can leave as is. And apologies if youve already make that case sufficiently and I didnt catch it.
-
Confusion resulting from restating of previous information via Topics: Add Swap-in Potentiam (SIP) #1538 (comment)
Let me know what you think @arshbot and hopefully we can get this improved topic up live for folks!
|
@arshbot what do you think about the 3 potentially-outstanding feedback items above? |
jonatack
force-pushed
the
master
branch
3 times, most recently
from
38028a8 to
9db038c
Compare
_topics/en/swap-in-potentiam.md
Outdated
| --- | ||
| SIP is a [submarine swap][topic submarine swaps] | ||
| mechanism that differs from typical purely HTLC-based submarine swaps by | ||
| allowing for a pre-commital stage. This allows for reusable swap addresses and |
There was a problem hiding this comment.
Why is it important for the address to be reusable? Isn’t that a privacy hazard?
There was a problem hiding this comment.
Isn’t that a privacy hazard?
Yes. But still useful, sought after, and a common usecase among retail users. Non-reusable addresses onchain are hard UX for the masses w/o proper education (which is friction).
Not to fight SIP's fights here, but an example where reusable addresses are useful are donation posters.
_topics/en/swap-in-potentiam.md
Outdated
| SIP is a [submarine swap][topic submarine swaps] | ||
| mechanism that differs from typical purely HTLC-based submarine swaps by | ||
| allowing for a pre-commital stage. This allows for reusable swap addresses and | ||
| more flexibility with onchain funds. |
There was a problem hiding this comment.
How does locking up your funds with a prospective channel partner provide more flexibility? It provides an option on a channel open or splice, but wouldn’t the shared control make the funds less flexible for all other purposes?
| allowing for a pre-commital stage. This allows for reusable swap addresses and | ||
| more flexibility with onchain funds. | ||
|
|
||
| In this scheme, the reusable swap address is a contract between Alice and Bob |
There was a problem hiding this comment.
If the "reusable" aspect of the address is important, it should perhaps be further elaborated.
_topics/en/swap-in-potentiam.md
Outdated
| SIP is primarily geared towards mobile users who may go offline for extended | ||
| periods of time. The main trick of SIP is splitting the confirmation | ||
| requirements between a pre-commital address and a commited address, allowing | ||
| for the immediate usage of funds when the mobile user comes online. |
There was a problem hiding this comment.
I also find this sentence more confusing than helpful.
_topics/en/swap-in-potentiam.md
Outdated
| link: https://gist.github.com/t-bast/5fd89979a8088b99d0b95c124902aa56 | ||
|
|
||
| --- | ||
| SIP is a [submarine swap][topic submarine swaps] |
There was a problem hiding this comment.
Sure, happy to streamline here. Removed the direct comparison.
_topics/en/swap-in-potentiam.md
Outdated
| SIP is primarily geared towards mobile users who may go offline for extended | ||
| periods of time. The main trick of SIP is splitting the confirmation | ||
| requirements between a pre-commital address and a commited address, allowing | ||
| for the immediate usage of funds when the mobile user comes online. |
| allowing for a pre-commital stage. This allows for reusable swap addresses and | ||
| more flexibility with onchain funds. | ||
|
|
||
| In this scheme, the reusable swap address is a contract between Alice and Bob |
_topics/en/swap-in-potentiam.md
Outdated
| SIP is a [submarine swap][topic submarine swaps] | ||
| mechanism that differs from typical purely HTLC-based submarine swaps by | ||
| allowing for a pre-commital stage. This allows for reusable swap addresses and | ||
| more flexibility with onchain funds. |
_topics/en/swap-in-potentiam.md
Outdated
| --- | ||
| SIP is a [submarine swap][topic submarine swaps] | ||
| mechanism that differs from typical purely HTLC-based submarine swaps by | ||
| allowing for a pre-commital stage. This allows for reusable swap addresses and |
There was a problem hiding this comment.
Isn’t that a privacy hazard?
Yes. But still useful, sought after, and a common usecase among retail users. Non-reusable addresses onchain are hard UX for the masses w/o proper education (which is friction).
Not to fight SIP's fights here, but an example where reusable addresses are useful are donation posters.
arshbot
force-pushed
the
swap-in-potentiam
branch
from
49e9dc0 to
25ecd24
Compare
Co-authored-by: Mark "Murch" Erhardt <[email protected]>
Co-authored-by: Mark "Murch" Erhardt <[email protected]>
Adding a potentiam as a topic.