Skip to content
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

Open
wants to merge 10 commits into
base: master
Choose a base branch
from
73 changes: 73 additions & 0 deletions _topics/en/swap-in-potentiam.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,73 @@
---
title: Swap-in Potentiam (SIP)

## Optional. test Shorter name to use for reference style links e.g., "foo"
## will allow using the link [topic foo][]. Not case sensitive
shortname: swap-in potentiam

## Optional. An entry will be added to the topics index for each alias
#aliases:
# - Foo

## Required. At least one category to which this topic belongs. See
## schema for options
categories:
- Contract Protocols
- Lightning Network

## Required. Use Markdown formatting. Only one paragraph. No links allowed.
## Should be less than 500 characters
excerpt: >
**Swap-in-Potentiam (SIP)** is a protocol designed to enable the immediate transfer
of already-confirmed onchain Bitcoin funds to the Lightning Network, lowering
trust requirements by precommitting to an LSP and incorporating a timeout
arshbot marked this conversation as resolved.
Show resolved Hide resolved
mechanism for unilateral access.

## Optional. Produces a Markdown link with either "[title][]" or
## "[title](link)"
primary_sources:
- title: Moving Onchain Funds "Instantly" To Lightning (Jesse Posner, ZmnSCPxj)
link: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-January/003810.html

- title: LSPS C= Extension, Swap-in-Potentiam
link: https://github.com/ZmnSCPxj-jr/swap-in-potentiam/blob/master/doc/swap-in-potentiam.md

## Optional. Each entry requires "title", "url", and "date". May also use "feature:
## true" to bold entry
optech_mentions:
- title: "Swap-in Potentiam Announced"
url: /en/newsletters/2023/12/20/#swap-in-potentiam

- title: Non-interactive LN channel open commitments
url: /en/newsletters/2023/01/11/#non-interactive-ln-channel-open-commitments
arshbot marked this conversation as resolved.
Show resolved Hide resolved

## Optional. Same format as "primary_sources" above
see_also:
- title: Hash Time Locked Contracts from Bitcoin Wiki
link: https://en.bitcoin.it/wiki/Hash_Time_Locked_Contracts
arshbot marked this conversation as resolved.
Show resolved Hide resolved

- title: Swap-in potentiam for Phoenix
link: https://gist.github.com/t-bast/5fd89979a8088b99d0b95c124902aa56

---
SIP is a [submarine swap][topic submarine swaps]
Copy link
Collaborator

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

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?

Copy link
Contributor Author

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

Copy link
Collaborator

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.

Copy link
Collaborator

@murchandamus murchandamus Mar 21, 2024

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.

Copy link
Contributor Author

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.

Copy link
Collaborator

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.

Copy link
Contributor Author

@arshbot arshbot Nov 17, 2024

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.

mechanism that differs from typical purely HTLC-based submarine swaps by
allowing for a pre-commital stage. This allows for reusable swap addresses and
Copy link
Collaborator

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

more flexibility with onchain funds.
Copy link
Collaborator

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Elaborated


In this scheme, the reusable swap address is a contract between Alice and Bob
Copy link
Collaborator

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Elaborated

that allows for two spend paths; Alice and Bob cosign, or timeout before Alice
can spend unilaterally.
arshbot marked this conversation as resolved.
Show resolved Hide resolved

Once the swap address is funded and confirmed, Alice can choose one of the
following options; swap the funds into a new or existing lightning network
channel with the help of Bob, or send the funds to a new onchain address with
the help of Bob. Alice also has the third option of waiting for the recovery
timeout if Bob is offline or uncooperative.

SIP is primarily geared towards mobile users who may go offline for extended
periods. The main trick of SIP is splitting the confirmation
requirements between a pre-commital address and a committed address, allowing
for the immediate usage of funds when the mobile user comes online.
Copy link
Collaborator

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".

Copy link
Contributor Author

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.

Copy link
Collaborator

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.

Copy link
Contributor Author

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.

Copy link
Collaborator

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed


{% include references.md %}