{"type":"rich","version":"1.0","author_name":"npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l","author_url":"https://nostr.ae/npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2023-01-03\n🗒️ Summary of this message: A new protocol called swap-in-potentiam allows for immediate transfer of onchain funds to Lightning Network, reducing the time required for confirmation.\n📝 Original message:\nSubject: Swap-in-Potentiam: Moving Onchain Funds \"Instantly\" To Lightning\n\nby Jesse Posner, ZmnSCPxj\n\nIntroduction\n============\n\nMoving funds from an onchain-only address to Lightning Network is slow,\nespecially if you desire trust-minimization (which removes solutions\nrelying on 0-conf).\n\nBasically, to reduce trust requirements in all onchain transactions,\nonchain receivers *MUST* ensure confirmation of the onchain transaction\nthat creates their UTXO.\nIn practice, the minimum should be at least 3 blocks, since reorgs of\nup to 2 blocks are common occurences, but even 1 confirmation can\ntake an inordinately long time in the real world due to the random\nnature of mining.\n\nThis is particularly acute for mobile phone use-cases.\nAs mobile phones run on a battery, mobile phone OSs often greatly\nrestrict CPU and other resource consumption when an app is not\ncurrently open by the user.\n\nNow consider this user story, for a wallet app that supports both\nBitcoin blockchain and Lightning Network operations:\n\n* The user wants to be paid over the Bitcoin blockchain.\n* The user gets an address from their wallet and provides it to\n  some other party to receive their payment.\n* The user closes their wallet app, which causes the mobile phone\n  OS to kill all its threads.\n* The other party sends their payment over blockchain while the\n  user is asleep.\n* The blockchain transaction confirms and time passes.\n* The user wakes up and checks their favorite blockchain explorer,\n  and sees they received funds on their wallet address.\n* The user opens their wallet app and decides they need a coffee,\n  so they buy coffee over Lightning.\n\nFor current solutions to move funds from the blockchain layer to\nLightning, however, the above user story would need to complete\nover a long time, possibly measurable in dozens of minutes or\neven hours in the worst case, due to the need for confirmation:\n\n* Channel open: Requires confirmation, many nodes require 6 or\n  more confirmations.\n* Submarine swap/peerswap: Requires confirmation before the swap\n  service will send out the HTLC on Lightning.\n* Splice-in: Channel remains operational, but until the splice\n  transaction confirms, the channel operates in \"dual mode\"\n  where both pre-splice and post-splice state is valid, and\n  that means only the lower amount of the pre-splice and\n  post-splice can be used in the mean time.\n  For splice-in, the pre-splice amount will be lower, thus\n  the amount being spliced in will not be credited until\n  the splice transaction is confirmed.\n\nIn this writeup, we present a novel protocol, swap-in-potentiam,\nthat can be used for immediate transfer from the blockchain\nlayer to the Lightning layer, in the above user story.\n\nAdvantages And Limitations\n--------------------------\n\nTo whet your appetite, here are the advantages:\n\n* Immediate transfer of already-confirmed-received onchain\n  funds to Lightning.\n* Onchain funds can also be transferred to another onchain\n  address (subject to normal onchain confirmation rules).\n  * This can be \"immediate\" if sending to a receiver that\n    accepts the risk of 0-conf onchain transactions.\n* Minimized trust requirement.\n\nThe disadvantages, to help convince you that yes, this is\ntechnology and not magic beans (and to not oversell this\ntech, Bitcoin media reporting often tend to oversell\nnew technologies because the disadvantages are often\nhidden away behind technical minutae):\n\n* Requires a cooperating LSP.\n  If LSP is down or refuses to cooperate, onchain funds\n  are locked for some time.\n  This has a timeout (so if the LSP never comes online\n  again, you just wait out the timeout) and the timeout\n  starts from when the receiving UTXO is confirmed in a\n  blocks, so it will not cause loss of funds, only loss\n  of opportunity (i.e. \"involuntary HODLing\").\n* If you have multiple LSPs, when you generate an address\n  you *have to* select one of them at that point, you\n  *cannot* commit to multiple LSPs and select one of them\n  later when your phone wakes up again.\n  This exacerbates the above disadvantage, since you have\n  to select one of your LSPs and hope that when your\n  phone wakes up the LSP you selected is also up and\n  cooperative.\n* The onchain-received funds have to be confirmed first,\n  otherwise we still need to wait for confirmation of the\n  onchain-received funds.\n  This is generally true for many blockchain-only wallets\n  anyway and is thus not a worsening, but is also not an\n  improvement.\n* If the timeout is too near, actions must be performed\n  onchain that require confirmation.\n\nSwap-in-Potentiam\n=================\n\nAll onchain fund movements, as noted, require confirmation.\nThese include onchain fund movements to the Lightning network.\n\nIf the onchain address that the wallet provides was controlled\nsolely by that wallet, then any action that requires cooperation\nwith a Lightning Network participant --- channel open, swap, or\nsplice --- would require an onchain transaction that commits to\nthat specific Lightning Network participant.\nOnly when the new onchain transaction is confirmed, can that\nLightning participant rely on the transaction output without\nhaving to trust the initiator.\n\n\u003eFrom there, we can consider: what if the wallet provides an\naddress that *already* commits to that specific Lightning Network\nparticipant?\n\nIf so, then the \"timer for confirmation\" starts as soon as\nthe wallet receives on the blockchain, not as soon as the wallet\ndecides to move funds from blockchain to Lightning.\n\nThis is a significant difference for a mobile wallet: the mobile\nenvironment does not support the mobile wallet being online for\nlong.\nThus, the mobile wallet may not have any CPU to make the decision\nto move funds from blockchain to Lightning, until the actual user\nexplicitly opens the mobile wallet app.\n\nIt has already been generally accepted that due to the limitations\nof the mobile phone environment, a mobile phone wallet with\nLightning support would need some LSP anyway.\nThus, a mobile wallet that can receive on the blockchain layer\nand then send on the Lightning layer can commit to a specific,\ndifferent, Lightning participant: the LSP it has channels with.\n\nThus, the mobile wallet can provide an address that commits to\none particular Lightning Network participant: its LSP.\n\nThe mobile wallet can then initiate a single-hop swap with the\nLSP when the mobile wallet app is in the foreground and has CPU\nto think with.\nIf it received funds into the address that have already been\nconfirmed, then it can do this single-hop swap immediately with\nits LSP.\nThe LSP can immediately resolve this swap, crediting funds to\nchannel, while atomically ensuring it has sole claim to the\nonchain UTXO.\n\nThe Contract\n------------\n\nThe contract has two participants: Alice the funds owner, and\nBob its potential swap partner.\n\nOnce *any* funds have been confirmed received into an address\ncommitting to this contract, Alice owns the funds and can\ndispose of them as it likes (with cooperation from Bob).\nThe source of the funds need not be Alice, it could be a third\nparty that has an obligation to pay Alice onchain.\n\nThe contract has only 2 branches:\n\n* Onchain/channel branch: Alice and Bob.\n* Timelock branch: Alice plus a relative timelock (`OP_CSV`)\n  measurable in weeks.\n\nAstute readers will realize that the above is really a variant\nof [CLTV-style unidirectional time-limited channels][1],\nthemselves a variant of Spilman-style channels:\n\n* Uses an explicit opcode to simplify channel setup (no need\n  to pre-sign a timeout transaction between Alice and Bob,\n  can just send funds directly to the address).\n* Uses a relative locktime instead of an absolute one to\n  allow funding of the channel address (= receive onchain\n  funds ready to spend over Lightning) at any time.\n\nThe use-cases this enables are:\n\n* If Alice wants to pay to another onchain address, and Bob\n  is also online and cooperative, Alice can ask Bob to help\n  sign the Onchain/channel branch to move the funds in any\n  arbitrary onchain manner.\n* If Alice wants to pay to a Lightning invoice / keysend, and\n  has insufficient Lightning outgoing capacity (but has\n  sufficient *total* capacity), it can swap with Bob, by\n  offerring a transaction that spends via the Onchain/channel\n  branch and instantiates a fresh onchain HTLC that Bob can\n  then forward over Lightning.\n  As soon as Alice offers its signature of that transaction,\n  Bob can immediately offer an in-Lightning HTLC to Alice on\n  their channel, and then Alice can immediately resolve it\n  (thus immediately getting its funds into Lightning).\n* If Bob is offline or uncooperative, Alice can unilterally\n  recover its funds after the timeout in the Timelock\n  branch.\n\nTrust is required only to the extent that Alice trusts Bob to\nbe cooperative so that Alice can dispose of its funds immediately.\nIn case Bob turns out to be non-trustworthy, Alice can recover\nits funds via the timelock branch after the timeout period.\nThere is no scope for Bob to steal funds (indeed, it is easier\nfor Bob to steal Lightning funds than to steal swap-in-potentiam\nfunds).\n\nThe intent here is that the mobile wallet is Alice, while the\nLSP is Bob.\n\n### Bob Security\n\nBob *MUST* ensure that, for each UTXO, it is either asked to\nsign an arbitrary onchain transaction (i.e the first use-case\nabove) *OR* it gets offered an onchain HTLC from that UTXO.\nOnce Alice has asked Bob to cooperate in either case for a\nparticular UTXO, Bob *MUST* ensure that it does not sign the other\ncase (and Bob *MUST* refuse to cooperate in the other case once\none case has been requested).\n\nIn addition, Bob *MUST* ensure that, if it is used in the\n\"channel\" case (i.e. the second use-case above), the timeout of\nthe Timelock branch is far enough in the future that it is likely\nthat spends using the Onchain/channel branch have confirmed by\nthen.\n\nWith both invariants enforced by Bob, Bob can ensure that, if\nAlice requests a swap using the Onchain/channel branch, only Bob\ncan spend the UTXO (at least before the timeout), and thus can\nsafely offer a Lightning HTLC to Alice immediately without any\nadditional waiting for onchain confirmations.\n\nAs Bob needs to know the UTXO in the first use-case above, this\nrequirement prevents the use of blind signing techniques when\nimplementing the first use-case.\nBasically, when being asked to sign, Bob must generate the entire\n`SIGHASH` from data that Alice provides, so that Bob is able to\nkeep track of UTXOs it is signing for.\n\n### Remote Swap\n\nWhile Bob is generally considered \"the\" LSP of the mobile wallet\nAlice, nothing in the Lightning protocol actually requires that\nBob be a direct peer of Alice.\nThe only real requirement is that Bob is able to send funds to\nAlice over Lightning in exchange for possession of the equivalent\nonchain funds.\n\nAgainst this, we should note that the mobile wallet is already\ndependent on one or more LSPs anyway, so it may as well just use\nits direct peer LSPs instead of a remote node.\n\n### Address Derivation\n\nSwap-in-potentiam addresses can be derived from a root public or\nprivate key.\n\nWe only need one keypair each from Alice and Bob.\nAlice can use standard derivation paths for its keypair.\n\nAs Bob is intended to be an LSP, we can just use its Lightning\nnode ID as the public key.\nBob needs to be in possession of the corresponding private key\nanyway in order to set up BOLT 8 encrypted transports.\n\nAs LSPs are part of the public network, Alice can simply try to\nscan for all published nodes that advertise support for\nswap-in-potentiam.\nAlternately if the wallet has a short list of fixed LSPs it\nwill use, it can simply refer to that list.\n\nThus:\n\n* Alice uses a derived keypair.\n* Bob uses a fixed keypair (its Lightning node ID).\n\nThe above is sufficient to derive swap-in-potentiam addresses\nfrom an `xprv` or `xpub` root key.\n\nSwap-in-potentiam For LSPs\n==========================\n\nWhile the original design of swap-in-potentiam has the mobile\nwallet in the \"Alice\" role and its LSP in the \"Bob\" role, it\nturns out that LSPs can provide special service to improve\nreceiving mobile wallets.\n\nSuppose that the LSP keeps track of statistics, and thus has\nan idea of which of its mobile wallet clients are likely to\nbe net receivers.\n\nNet receivers will often have low inbound capacity (since the\ninbound capacity has been used up during previous LN receives).\n\nDuring times of low onchain fees, an LSP can check which of its\noffline mobile wallet clients have low inbound capacity, and are\nlikely to come online in the future to receive.\nIn those cases, the LSP can commit funds to a swap-in-potentiam\nwith the mobile client, with the LSP as \"Alice\" and the mobile\nclient as \"Bob\".\nThis at least lets the LSP set up half of a swap during a time of\nlow fees.\n\nIf the transfer to swap-in-potentiam addresses is confirmed by\nthe time the mobile wallet client comes online, the LSP can\nimmediately initiate a swap, giving inbound capacity towards the\nmobile client.\nThis swap can be immediately resolved, and allows the mobile\nwallet client to immediately receive funds over Lightning.\n\nIn particular, if \"offline receive\" as designed by TheBlueMatt\nis implemented, then the LSP already has indication of a pending\npayment towards an offline mobile wallet client.\nThe LSP can check if the offline mobile wallet client has\ninsufficient incoming capacity to receive the funds, and if so,\narrange to fund a swap-in-potentiam with that client.\nThen, when the mobile wallet client comes online, the LSP can\ninitiate the swap with them, and once the swap completes (and\nthus the mobile wallet client has sufficient incoming capacity)\nthe LSP can contact the sender LSP to complete the payment.\n\nIn particular, this use-case allows for *immediate* receives as\nsoon as the mobile wallet client gets foregrounded and has CPU\ntime, **without** requiring 0-conf trusted transactions and\nthus without requiring any kind of semi-custodial trust, even\nif the mobile wallet client had insufficient incoming capacity.\nA channel still has to be set up beforehand (without 0-conf, if\ntrusting funds to the LSP is undesirable).\n\nImplementation Sketch\n=====================\n\nThe intent is to use Taproot with Schnorr signatures, but\n**without** using the keyspend path (at least initially).\n\nThe plan currently is to use a `MuSig(A, B)` as the internal\npubkey, but with the branches still explicitly laid out as\ntapleaves.\nThat is, there are two tapleaf SCRIPTs corresponding to the\ntwo branches described above:\n\n* `\u003cA\u003e OP_CHECKSIGVERIFY \u003cB\u003e OP_CHECKSIG`\n* `\u003ctimelock\u003e OP_CHECKSEQUENCEVERIFY OP_DROP \u003cA\u003e OP_CHECKSIG`\n\nUsing an explicit 2-of-2 branch rather than a MuSig allows\nfor a simple protocol at least for initial deployment:\nwe can have Alice send the signature using `A` in a single\nhalf-round without having to engage in a 2-round MuSig2 signing\nritual.\n\nWe intend to use Taproot since the mobile wallet client\nmay need to use a 2-of-3 or 2-of-2 signing scheme, similar\nto Blockstream Green.\nThis allows either Alice or Bob in the contract to secretly\nbe a FROST 2-of-3 or MuSig 2-of-2 (or any FROST k-of-n or\nMuSig n-of-n).\nThis is also another reason for avoiding a 2-of-2 MuSig\nkeyspend path between Alice and Bob, as there is (to our\nknowledge) no publicly-reviewed security proof that\nFROST-in-MuSig and MuSig-in-MuSig are safe (or the\ncorresponding variants using MuSig2 for the signing\nritual).\n\nLater, when we are more confident of the use of MuSig2 and\nFROST inside a MuSig2, and with using MuSig2 with possibly\nuntrusted outsiders (who might exploit any mis-implementation\nof the MuSig2 signing protocol if we are not careful with\ndesigning it), we can seamlessly upgrade the protocol\nto use the keyspend path later, to save witness bytes.\n\nFor the Onchain use-case (i.e. Alice wants to spend the UTXO\nto an onchain address), the protocol betweeen Alice and Bob\nwould be:\n\n* `request_arbitrary_signature` Alice-\u003eBob: Requests Bob\n  to sign a PSBT spending a swap-in-potentiam address\n  using the Onchain branch.\n* `response_arbitrary_signature` Bob-\u003eAlice: Response to\n  the above, returning the requested signature.\n* `reject_arbitrary_signature` Bob-\u003eAlice: Sent in\n  response to `request_arbitary_signature` if Bob refuses\n  to cooperate (e.g. the UTXO being spent has already\n  been accepted by Bob in a Channel use-case below).\n\nFor the Channel use-case (i.e. Alice wants to spend the UTXO\nto a Lightning receiver), we operate the swap-in-potentiam\nUTXO(s) as a Spilman-like channel over two states:\n\n* HTLC-offering: Offering an amount `N` HTLC from Alice to\n  Bob, with any remaining amount to a change address to\n  Alice.\n* Resolved: Giving the amount `N` outright to Bob, with any\n  remaining amount to a change address to Alice.\n\nThe intention is that the channel is initially put into\nthe HTLC-offerring state.\nThen Bob offers a corresponding in-Lightning HTLC to Alice\nover their channel.\nWhen Alice resolves the in-Lightning HTLC, it can then\nsend a new signature for the Resolved state.\nOnce the channel is in a Resolved state, Bob *SHOULD* sign\nthe last state and broadcast it on the blockchain, thereby\nclosing the Spilman-like channel.\n\nThe protocol messages for the Channel use-case are:\n\n* `request_swap_in` Alice-\u003eBob: Tell Bob the UTXOs with\n  the same swap-in-potentiam address to spend, how\n  much to put into the Alice-\u003eBob channel direction,\n  what channel to move into, and (optionally) a change\n  address for Alice.\n* `reject_swap_in` Bob-\u003eAlice: Sent in response to\n  `request_swap_in` if Bob refuses to cooperate (e.g.\n  one of the UTXOs on offer was already signed with\n  `response_arbitrary_signature`, or Bob cannot legally\n  accept control of funds from one or more of the UTXOs\n  offerred).\n* `accept_swap_in` Bob-\u003eAlice: Sent in response to\n  `request_swap_in`, containing the Bob-side address to\n  send funds to later once the state is Resolved.\n* `swap_in_signed` Alice-\u003eBob: Response to\n  `accept_swap_in`, containing the Alice-side signature\n  for the HTLC-offering state transaction.\n  Once Bob receives this, Bob can safely construct a\n  new on-Lightning HTLC using BOLT1\n  `update_offer_htlc`.\n* `swap_in_resolved` Alice-\u003eBob: Sent after Alice has\n  acquired the funds via `update_fulfill_htlc` of the\n  corresponding on-Lightning HTLC, containing the\n  Alice-side signature for the Resolved state\n  transaction.\n  The Resolved state transaction spends to the Bob-side\n  address given in `accept_swap_in`, and any change to\n  the Alice-side change address in `request_swap_in`.\n\nThe plan is to reserve only one odd BOLT1 message ID,\nand to embed the actual swap-in-potentiam message ID\nas the first 2 bytes of the BOLT1 message, to reduce\npollution of the limited BOLT1 message ID space and to\nallow more flexibility for swap-in-potentiam to expand\nto new messages inside its own message ID space.\n\nFor a richer future protocol, we will want to consider\nhow a swap-in can be combined with a splice-in.\nThis is useful if the current total capacity of the\nchannel is lower than the available onchain funds.\nThe swap-in can be credited immediately (and is limited\nto the current total capacity) while additional funds\ncan be added to the channel via splice-in (which is\ncredited only once the splice-in is confirmed).\n\nAs-is, a similar result can be obtained using openv1,\nwherein a swap-in is combined with a channel open,\nwith the swap-in immediately credited while the channel\nopen is awaiting confirmation:\n\n* Alice and Bob currently have one or more existing\n  channels, and Alice has a UTXO in a swap-in-potentiam\n  address whose value exceeds the incoming capacity of\n  the existing channel(s).\n* Alice-\u003eBob `open_channel`.\n* Bob-\u003eAlice `accept_channel`.\n* Alice-\u003eBob `request_swap_in` with the \"change address\"\n  being the funding address of the channel.\n* Bob-\u003eAlice `accept_swap_in` provides the TXID of the\n  funding transaction (Alice now knows the \"change\n  address\" and the Bob final Resolved address, letting it\n  know the final Resolved state transaction TXID).\n* Alice-\u003eBob `funding_created` with the TXID.\n* Bob-\u003eAlice `funding_signed`.\n* Alice-\u003eBob `swap_in_signed` to provide the signature\n  spending the swap-in-potentiam address to Bob.\n* Bob then constructs an HTLC over the existing channel,\n  which Alice claims, revealing the preimage.\n* Alice-\u003eBob `swap_in_resolved`.\n* Bob then broadcasts the Resolved state transaction,\n  which is also the funding transaction of the new channel.\n* Both Alice and Bob await confirmation of the transaction\n  in order to use the new channel.\n  Alice can still use the existing channel, which has been\n  topped-up with fresh outgoing capacity by the swap-in.\n\n(The above is not safe, as Bob can complete the protocol\nby using the HTLC-offerring state transaction; this can\nbe fixed by having Alice open *2* channels with the same\namount, one with the HTLC-offering state transaction as\nthe funding tx, the other with the Resolved state\ntransaction as the funding tx, and later `error`ing the\nchannel corresponding to the transaction that is not\nconfirmed; this is left as an exercise to the reader,\nthough note that it requires two different change addresses\nfor Alice for both HTLC-offerring and Resolved states,\nwhich can be arranged for the protocol)\n\n--\n\n[1]: https://en.bitcoin.it/wiki/Payment_channels#CLTV-style_payment_channels"}