Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Topics: Add Swap-in Potentiam (SIP) #1538
base: master
Are you sure you want to change the base?
Topics: Add Swap-in Potentiam (SIP) #1538
Changes from 3 commits
6f0a54c
e9cae7a
5982b31
25558d8
9d9e66a
b557295
1b3e735
1e448ad
2e9bc14
25ecd24
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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:
With an additional trapdoor after some long period of time:
Aside from the advantages above, an LSP can support SiP without supporting creating new channels because SiP offers the following advantages
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might be worth illustrating these paths in the article. Is mermaidjs or similar supported?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, happy to streamline here. Removed the direct comparison.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is it important for the address to be reusable? Isn’t that a privacy hazard?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Elaborated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the "reusable" aspect of the address is important, it should perhaps be further elaborated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Elaborated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also find this sentence more confusing than helpful.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed