{"type":"rich","version":"1.0","author_name":"npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4","author_url":"https://nostr.ae/npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2023-01-04\n🗒️ Summary of this message: A proposal for a faster way to move funds from an on-chain address to the Lightning Network using regular swaps, which simplifies the process and reduces trust requirements.\n📝 Original message:\nHi Z,\n\n\u003e * Submarine swap/peerswap: Requires confirmation before the swap service\n\u003e will send out the HTLC on Lightning.\n\nI might be missing something, but I don't see how this is different from a\nnormal on-chain to off-chain swap (calling this Loop In for short in the\nremainder of the email).\n\nGiven some static swap server params (server key, user key, preimage), a\nuser can derive a tapscript tree and use that to make addresses that any 3rd\nparty can send to. Services like Loop return a few addrs (including P2TR!)\nthe client can use depending on their wallet sophistication [1] (in this\ncase the command is: `loop in --amt=X --external\\, external means a 3rd\nparty will send to the addr). After a 3rd party sends to the script, the\nswap can be completed at anytime as soon as the client is online (assuming\nswap server is always there).\n\nIn the scenario above, the newly created outputs to our swap addr need to be\nconfirmed before the swap server will initiate the swap. As you mention,\nthis could even be zero conf assuming all sides take w/e precautions they're\ncomfortable with. If the swap server goes away for w/e reason, a long\ntimeout in the swap can let the user sweep the funds via some other\nmeans eventually. This doesn't need to be a direct swap either, and it can\nflow multi-hop like any other swap.\n\nIn your scheme you say that:\n\n\u003e If so, then the \"timer for confirmation\" starts as soon as the wallet\n\u003e receives on the blockchain, not as soon as the wallet decides to move\n\u003e funds from blockchain to Lightning.\n\nWhich seems to be the exact same as the flow I described above. For our\nnewer musig2-enabled swaps, the top level keyspend can be spent by both\nparties, so you also emulate the ability for Alice to move the funds on\nchain anywhere else w/ the server's cooperation.\n\nUsing regular swaps also simplified the \"Bob Security\" section a lot, as Bob\nsends out an HTLC w/ the corresponding swap hash (he watches the chain for\nthe scripts, then initiates the swap once they're seen).\n\n[1]: https://lightning.engineering/api-docs/api/loop/swap-client/loop-in\n\n-- Laolu\n\nOn Tue, Jan 3, 2023 at 5:58 AM ZmnSCPxj via Lightning-dev \u003c\nlightning-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Subject: Swap-in-Potentiam: Moving Onchain Funds \"Instantly\" To Lightning\n\u003e\n\u003e by Jesse Posner, ZmnSCPxj\n\u003e\n\u003e Introduction\n\u003e ============\n\u003e\n\u003e Moving funds from an onchain-only address to Lightning Network is slow,\n\u003e especially if you desire trust-minimization (which removes solutions\n\u003e relying on 0-conf).\n\u003e\n\u003e Basically, to reduce trust requirements in all onchain transactions,\n\u003e onchain receivers *MUST* ensure confirmation of the onchain transaction\n\u003e that creates their UTXO.\n\u003e In practice, the minimum should be at least 3 blocks, since reorgs of\n\u003e up to 2 blocks are common occurences, but even 1 confirmation can\n\u003e take an inordinately long time in the real world due to the random\n\u003e nature of mining.\n\u003e\n\u003e This is particularly acute for mobile phone use-cases.\n\u003e As mobile phones run on a battery, mobile phone OSs often greatly\n\u003e restrict CPU and other resource consumption when an app is not\n\u003e currently open by the user.\n\u003e\n\u003e Now consider this user story, for a wallet app that supports both\n\u003e Bitcoin blockchain and Lightning Network operations:\n\u003e\n\u003e * The user wants to be paid over the Bitcoin blockchain.\n\u003e * The user gets an address from their wallet and provides it to\n\u003e   some other party to receive their payment.\n\u003e * The user closes their wallet app, which causes the mobile phone\n\u003e   OS to kill all its threads.\n\u003e * The other party sends their payment over blockchain while the\n\u003e   user is asleep.\n\u003e * The blockchain transaction confirms and time passes.\n\u003e * The user wakes up and checks their favorite blockchain explorer,\n\u003e   and sees they received funds on their wallet address.\n\u003e * The user opens their wallet app and decides they need a coffee,\n\u003e   so they buy coffee over Lightning.\n\u003e\n\u003e For current solutions to move funds from the blockchain layer to\n\u003e Lightning, however, the above user story would need to complete\n\u003e over a long time, possibly measurable in dozens of minutes or\n\u003e even hours in the worst case, due to the need for confirmation:\n\u003e\n\u003e * Channel open: Requires confirmation, many nodes require 6 or\n\u003e   more confirmations.\n\u003e * Submarine swap/peerswap: Requires confirmation before the swap\n\u003e   service will send out the HTLC on Lightning.\n\u003e * Splice-in: Channel remains operational, but until the splice\n\u003e   transaction confirms, the channel operates in \"dual mode\"\n\u003e   where both pre-splice and post-splice state is valid, and\n\u003e   that means only the lower amount of the pre-splice and\n\u003e   post-splice can be used in the mean time.\n\u003e   For splice-in, the pre-splice amount will be lower, thus\n\u003e   the amount being spliced in will not be credited until\n\u003e   the splice transaction is confirmed.\n\u003e\n\u003e In this writeup, we present a novel protocol, swap-in-potentiam,\n\u003e that can be used for immediate transfer from the blockchain\n\u003e layer to the Lightning layer, in the above user story.\n\u003e\n\u003e Advantages And Limitations\n\u003e --------------------------\n\u003e\n\u003e To whet your appetite, here are the advantages:\n\u003e\n\u003e * Immediate transfer of already-confirmed-received onchain\n\u003e   funds to Lightning.\n\u003e * Onchain funds can also be transferred to another onchain\n\u003e   address (subject to normal onchain confirmation rules).\n\u003e   * This can be \"immediate\" if sending to a receiver that\n\u003e     accepts the risk of 0-conf onchain transactions.\n\u003e * Minimized trust requirement.\n\u003e\n\u003e The disadvantages, to help convince you that yes, this is\n\u003e technology and not magic beans (and to not oversell this\n\u003e tech, Bitcoin media reporting often tend to oversell\n\u003e new technologies because the disadvantages are often\n\u003e hidden away behind technical minutae):\n\u003e\n\u003e * Requires a cooperating LSP.\n\u003e   If LSP is down or refuses to cooperate, onchain funds\n\u003e   are locked for some time.\n\u003e   This has a timeout (so if the LSP never comes online\n\u003e   again, you just wait out the timeout) and the timeout\n\u003e   starts from when the receiving UTXO is confirmed in a\n\u003e   blocks, so it will not cause loss of funds, only loss\n\u003e   of opportunity (i.e. \"involuntary HODLing\").\n\u003e * If you have multiple LSPs, when you generate an address\n\u003e   you *have to* select one of them at that point, you\n\u003e   *cannot* commit to multiple LSPs and select one of them\n\u003e   later when your phone wakes up again.\n\u003e   This exacerbates the above disadvantage, since you have\n\u003e   to select one of your LSPs and hope that when your\n\u003e   phone wakes up the LSP you selected is also up and\n\u003e   cooperative.\n\u003e * The onchain-received funds have to be confirmed first,\n\u003e   otherwise we still need to wait for confirmation of the\n\u003e   onchain-received funds.\n\u003e   This is generally true for many blockchain-only wallets\n\u003e   anyway and is thus not a worsening, but is also not an\n\u003e   improvement.\n\u003e * If the timeout is too near, actions must be performed\n\u003e   onchain that require confirmation.\n\u003e\n\u003e Swap-in-Potentiam\n\u003e =================\n\u003e\n\u003e All onchain fund movements, as noted, require confirmation.\n\u003e These include onchain fund movements to the Lightning network.\n\u003e\n\u003e If the onchain address that the wallet provides was controlled\n\u003e solely by that wallet, then any action that requires cooperation\n\u003e with a Lightning Network participant --- channel open, swap, or\n\u003e splice --- would require an onchain transaction that commits to\n\u003e that specific Lightning Network participant.\n\u003e Only when the new onchain transaction is confirmed, can that\n\u003e Lightning participant rely on the transaction output without\n\u003e having to trust the initiator.\n\u003e\n\u003e From there, we can consider: what if the wallet provides an\n\u003e address that *already* commits to that specific Lightning Network\n\u003e participant?\n\u003e\n\u003e If so, then the \"timer for confirmation\" starts as soon as\n\u003e the wallet receives on the blockchain, not as soon as the wallet\n\u003e decides to move funds from blockchain to Lightning.\n\u003e\n\u003e This is a significant difference for a mobile wallet: the mobile\n\u003e environment does not support the mobile wallet being online for\n\u003e long.\n\u003e Thus, the mobile wallet may not have any CPU to make the decision\n\u003e to move funds from blockchain to Lightning, until the actual user\n\u003e explicitly opens the mobile wallet app.\n\u003e\n\u003e It has already been generally accepted that due to the limitations\n\u003e of the mobile phone environment, a mobile phone wallet with\n\u003e Lightning support would need some LSP anyway.\n\u003e Thus, a mobile wallet that can receive on the blockchain layer\n\u003e and then send on the Lightning layer can commit to a specific,\n\u003e different, Lightning participant: the LSP it has channels with.\n\u003e\n\u003e Thus, the mobile wallet can provide an address that commits to\n\u003e one particular Lightning Network participant: its LSP.\n\u003e\n\u003e The mobile wallet can then initiate a single-hop swap with the\n\u003e LSP when the mobile wallet app is in the foreground and has CPU\n\u003e to think with.\n\u003e If it received funds into the address that have already been\n\u003e confirmed, then it can do this single-hop swap immediately with\n\u003e its LSP.\n\u003e The LSP can immediately resolve this swap, crediting funds to\n\u003e channel, while atomically ensuring it has sole claim to the\n\u003e onchain UTXO.\n\u003e\n\u003e The Contract\n\u003e ------------\n\u003e\n\u003e The contract has two participants: Alice the funds owner, and\n\u003e Bob its potential swap partner.\n\u003e\n\u003e Once *any* funds have been confirmed received into an address\n\u003e committing to this contract, Alice owns the funds and can\n\u003e dispose of them as it likes (with cooperation from Bob).\n\u003e The source of the funds need not be Alice, it could be a third\n\u003e party that has an obligation to pay Alice onchain.\n\u003e\n\u003e The contract has only 2 branches:\n\u003e\n\u003e * Onchain/channel branch: Alice and Bob.\n\u003e * Timelock branch: Alice plus a relative timelock (`OP_CSV`)\n\u003e   measurable in weeks.\n\u003e\n\u003e Astute readers will realize that the above is really a variant\n\u003e of [CLTV-style unidirectional time-limited channels][1],\n\u003e themselves a variant of Spilman-style channels:\n\u003e\n\u003e * Uses an explicit opcode to simplify channel setup (no need\n\u003e   to pre-sign a timeout transaction between Alice and Bob,\n\u003e   can just send funds directly to the address).\n\u003e * Uses a relative locktime instead of an absolute one to\n\u003e   allow funding of the channel address (= receive onchain\n\u003e   funds ready to spend over Lightning) at any time.\n\u003e\n\u003e The use-cases this enables are:\n\u003e\n\u003e * If Alice wants to pay to another onchain address, and Bob\n\u003e   is also online and cooperative, Alice can ask Bob to help\n\u003e   sign the Onchain/channel branch to move the funds in any\n\u003e   arbitrary onchain manner.\n\u003e * If Alice wants to pay to a Lightning invoice / keysend, and\n\u003e   has insufficient Lightning outgoing capacity (but has\n\u003e   sufficient *total* capacity), it can swap with Bob, by\n\u003e   offerring a transaction that spends via the Onchain/channel\n\u003e   branch and instantiates a fresh onchain HTLC that Bob can\n\u003e   then forward over Lightning.\n\u003e   As soon as Alice offers its signature of that transaction,\n\u003e   Bob can immediately offer an in-Lightning HTLC to Alice on\n\u003e   their channel, and then Alice can immediately resolve it\n\u003e   (thus immediately getting its funds into Lightning).\n\u003e * If Bob is offline or uncooperative, Alice can unilterally\n\u003e   recover its funds after the timeout in the Timelock\n\u003e   branch.\n\u003e\n\u003e Trust is required only to the extent that Alice trusts Bob to\n\u003e be cooperative so that Alice can dispose of its funds immediately.\n\u003e In case Bob turns out to be non-trustworthy, Alice can recover\n\u003e its funds via the timelock branch after the timeout period.\n\u003e There is no scope for Bob to steal funds (indeed, it is easier\n\u003e for Bob to steal Lightning funds than to steal swap-in-potentiam\n\u003e funds).\n\u003e\n\u003e The intent here is that the mobile wallet is Alice, while the\n\u003e LSP is Bob.\n\u003e\n\u003e ### Bob Security\n\u003e\n\u003e Bob *MUST* ensure that, for each UTXO, it is either asked to\n\u003e sign an arbitrary onchain transaction (i.e the first use-case\n\u003e above) *OR* it gets offered an onchain HTLC from that UTXO.\n\u003e Once Alice has asked Bob to cooperate in either case for a\n\u003e particular UTXO, Bob *MUST* ensure that it does not sign the other\n\u003e case (and Bob *MUST* refuse to cooperate in the other case once\n\u003e one case has been requested).\n\u003e\n\u003e In addition, Bob *MUST* ensure that, if it is used in the\n\u003e \"channel\" case (i.e. the second use-case above), the timeout of\n\u003e the Timelock branch is far enough in the future that it is likely\n\u003e that spends using the Onchain/channel branch have confirmed by\n\u003e then.\n\u003e\n\u003e With both invariants enforced by Bob, Bob can ensure that, if\n\u003e Alice requests a swap using the Onchain/channel branch, only Bob\n\u003e can spend the UTXO (at least before the timeout), and thus can\n\u003e safely offer a Lightning HTLC to Alice immediately without any\n\u003e additional waiting for onchain confirmations.\n\u003e\n\u003e As Bob needs to know the UTXO in the first use-case above, this\n\u003e requirement prevents the use of blind signing techniques when\n\u003e implementing the first use-case.\n\u003e Basically, when being asked to sign, Bob must generate the entire\n\u003e `SIGHASH` from data that Alice provides, so that Bob is able to\n\u003e keep track of UTXOs it is signing for.\n\u003e\n\u003e ### Remote Swap\n\u003e\n\u003e While Bob is generally considered \"the\" LSP of the mobile wallet\n\u003e Alice, nothing in the Lightning protocol actually requires that\n\u003e Bob be a direct peer of Alice.\n\u003e The only real requirement is that Bob is able to send funds to\n\u003e Alice over Lightning in exchange for possession of the equivalent\n\u003e onchain funds.\n\u003e\n\u003e Against this, we should note that the mobile wallet is already\n\u003e dependent on one or more LSPs anyway, so it may as well just use\n\u003e its direct peer LSPs instead of a remote node.\n\u003e\n\u003e ### Address Derivation\n\u003e\n\u003e Swap-in-potentiam addresses can be derived from a root public or\n\u003e private key.\n\u003e\n\u003e We only need one keypair each from Alice and Bob.\n\u003e Alice can use standard derivation paths for its keypair.\n\u003e\n\u003e As Bob is intended to be an LSP, we can just use its Lightning\n\u003e node ID as the public key.\n\u003e Bob needs to be in possession of the corresponding private key\n\u003e anyway in order to set up BOLT 8 encrypted transports.\n\u003e\n\u003e As LSPs are part of the public network, Alice can simply try to\n\u003e scan for all published nodes that advertise support for\n\u003e swap-in-potentiam.\n\u003e Alternately if the wallet has a short list of fixed LSPs it\n\u003e will use, it can simply refer to that list.\n\u003e\n\u003e Thus:\n\u003e\n\u003e * Alice uses a derived keypair.\n\u003e * Bob uses a fixed keypair (its Lightning node ID).\n\u003e\n\u003e The above is sufficient to derive swap-in-potentiam addresses\n\u003e from an `xprv` or `xpub` root key.\n\u003e\n\u003e Swap-in-potentiam For LSPs\n\u003e ==========================\n\u003e\n\u003e While the original design of swap-in-potentiam has the mobile\n\u003e wallet in the \"Alice\" role and its LSP in the \"Bob\" role, it\n\u003e turns out that LSPs can provide special service to improve\n\u003e receiving mobile wallets.\n\u003e\n\u003e Suppose that the LSP keeps track of statistics, and thus has\n\u003e an idea of which of its mobile wallet clients are likely to\n\u003e be net receivers.\n\u003e\n\u003e Net receivers will often have low inbound capacity (since the\n\u003e inbound capacity has been used up during previous LN receives).\n\u003e\n\u003e During times of low onchain fees, an LSP can check which of its\n\u003e offline mobile wallet clients have low inbound capacity, and are\n\u003e likely to come online in the future to receive.\n\u003e In those cases, the LSP can commit funds to a swap-in-potentiam\n\u003e with the mobile client, with the LSP as \"Alice\" and the mobile\n\u003e client as \"Bob\".\n\u003e This at least lets the LSP set up half of a swap during a time of\n\u003e low fees.\n\u003e\n\u003e If the transfer to swap-in-potentiam addresses is confirmed by\n\u003e the time the mobile wallet client comes online, the LSP can\n\u003e immediately initiate a swap, giving inbound capacity towards the\n\u003e mobile client.\n\u003e This swap can be immediately resolved, and allows the mobile\n\u003e wallet client to immediately receive funds over Lightning.\n\u003e\n\u003e In particular, if \"offline receive\" as designed by TheBlueMatt\n\u003e is implemented, then the LSP already has indication of a pending\n\u003e payment towards an offline mobile wallet client.\n\u003e The LSP can check if the offline mobile wallet client has\n\u003e insufficient incoming capacity to receive the funds, and if so,\n\u003e arrange to fund a swap-in-potentiam with that client.\n\u003e Then, when the mobile wallet client comes online, the LSP can\n\u003e initiate the swap with them, and once the swap completes (and\n\u003e thus the mobile wallet client has sufficient incoming capacity)\n\u003e the LSP can contact the sender LSP to complete the payment.\n\u003e\n\u003e In particular, this use-case allows for *immediate* receives as\n\u003e soon as the mobile wallet client gets foregrounded and has CPU\n\u003e time, **without** requiring 0-conf trusted transactions and\n\u003e thus without requiring any kind of semi-custodial trust, even\n\u003e if the mobile wallet client had insufficient incoming capacity.\n\u003e A channel still has to be set up beforehand (without 0-conf, if\n\u003e trusting funds to the LSP is undesirable).\n\u003e\n\u003e Implementation Sketch\n\u003e =====================\n\u003e\n\u003e The intent is to use Taproot with Schnorr signatures, but\n\u003e **without** using the keyspend path (at least initially).\n\u003e\n\u003e The plan currently is to use a `MuSig(A, B)` as the internal\n\u003e pubkey, but with the branches still explicitly laid out as\n\u003e tapleaves.\n\u003e That is, there are two tapleaf SCRIPTs corresponding to the\n\u003e two branches described above:\n\u003e\n\u003e * `\u003cA\u003e OP_CHECKSIGVERIFY \u003cB\u003e OP_CHECKSIG`\n\u003e * `\u003ctimelock\u003e OP_CHECKSEQUENCEVERIFY OP_DROP \u003cA\u003e OP_CHECKSIG`\n\u003e\n\u003e Using an explicit 2-of-2 branch rather than a MuSig allows\n\u003e for a simple protocol at least for initial deployment:\n\u003e we can have Alice send the signature using `A` in a single\n\u003e half-round without having to engage in a 2-round MuSig2 signing\n\u003e ritual.\n\u003e\n\u003e We intend to use Taproot since the mobile wallet client\n\u003e may need to use a 2-of-3 or 2-of-2 signing scheme, similar\n\u003e to Blockstream Green.\n\u003e This allows either Alice or Bob in the contract to secretly\n\u003e be a FROST 2-of-3 or MuSig 2-of-2 (or any FROST k-of-n or\n\u003e MuSig n-of-n).\n\u003e This is also another reason for avoiding a 2-of-2 MuSig\n\u003e keyspend path between Alice and Bob, as there is (to our\n\u003e knowledge) no publicly-reviewed security proof that\n\u003e FROST-in-MuSig and MuSig-in-MuSig are safe (or the\n\u003e corresponding variants using MuSig2 for the signing\n\u003e ritual).\n\u003e\n\u003e Later, when we are more confident of the use of MuSig2 and\n\u003e FROST inside a MuSig2, and with using MuSig2 with possibly\n\u003e untrusted outsiders (who might exploit any mis-implementation\n\u003e of the MuSig2 signing protocol if we are not careful with\n\u003e designing it), we can seamlessly upgrade the protocol\n\u003e to use the keyspend path later, to save witness bytes.\n\u003e\n\u003e For the Onchain use-case (i.e. Alice wants to spend the UTXO\n\u003e to an onchain address), the protocol betweeen Alice and Bob\n\u003e would be:\n\u003e\n\u003e * `request_arbitrary_signature` Alice-\u003eBob: Requests Bob\n\u003e   to sign a PSBT spending a swap-in-potentiam address\n\u003e   using the Onchain branch.\n\u003e * `response_arbitrary_signature` Bob-\u003eAlice: Response to\n\u003e   the above, returning the requested signature.\n\u003e * `reject_arbitrary_signature` Bob-\u003eAlice: Sent in\n\u003e   response to `request_arbitary_signature` if Bob refuses\n\u003e   to cooperate (e.g. the UTXO being spent has already\n\u003e   been accepted by Bob in a Channel use-case below).\n\u003e\n\u003e For the Channel use-case (i.e. Alice wants to spend the UTXO\n\u003e to a Lightning receiver), we operate the swap-in-potentiam\n\u003e UTXO(s) as a Spilman-like channel over two states:\n\u003e\n\u003e * HTLC-offering: Offering an amount `N` HTLC from Alice to\n\u003e   Bob, with any remaining amount to a change address to\n\u003e   Alice.\n\u003e * Resolved: Giving the amount `N` outright to Bob, with any\n\u003e   remaining amount to a change address to Alice.\n\u003e\n\u003e The intention is that the channel is initially put into\n\u003e the HTLC-offerring state.\n\u003e Then Bob offers a corresponding in-Lightning HTLC to Alice\n\u003e over their channel.\n\u003e When Alice resolves the in-Lightning HTLC, it can then\n\u003e send a new signature for the Resolved state.\n\u003e Once the channel is in a Resolved state, Bob *SHOULD* sign\n\u003e the last state and broadcast it on the blockchain, thereby\n\u003e closing the Spilman-like channel.\n\u003e\n\u003e The protocol messages for the Channel use-case are:\n\u003e\n\u003e * `request_swap_in` Alice-\u003eBob: Tell Bob the UTXOs with\n\u003e   the same swap-in-potentiam address to spend, how\n\u003e   much to put into the Alice-\u003eBob channel direction,\n\u003e   what channel to move into, and (optionally) a change\n\u003e   address for Alice.\n\u003e * `reject_swap_in` Bob-\u003eAlice: Sent in response to\n\u003e   `request_swap_in` if Bob refuses to cooperate (e.g.\n\u003e   one of the UTXOs on offer was already signed with\n\u003e   `response_arbitrary_signature`, or Bob cannot legally\n\u003e   accept control of funds from one or more of the UTXOs\n\u003e   offerred).\n\u003e * `accept_swap_in` Bob-\u003eAlice: Sent in response to\n\u003e   `request_swap_in`, containing the Bob-side address to\n\u003e   send funds to later once the state is Resolved.\n\u003e * `swap_in_signed` Alice-\u003eBob: Response to\n\u003e   `accept_swap_in`, containing the Alice-side signature\n\u003e   for the HTLC-offering state transaction.\n\u003e   Once Bob receives this, Bob can safely construct a\n\u003e   new on-Lightning HTLC using BOLT1\n\u003e   `update_offer_htlc`.\n\u003e * `swap_in_resolved` Alice-\u003eBob: Sent after Alice has\n\u003e   acquired the funds via `update_fulfill_htlc` of the\n\u003e   corresponding on-Lightning HTLC, containing the\n\u003e   Alice-side signature for the Resolved state\n\u003e   transaction.\n\u003e   The Resolved state transaction spends to the Bob-side\n\u003e   address given in `accept_swap_in`, and any change to\n\u003e   the Alice-side change address in `request_swap_in`.\n\u003e\n\u003e The plan is to reserve only one odd BOLT1 message ID,\n\u003e and to embed the actual swap-in-potentiam message ID\n\u003e as the first 2 bytes of the BOLT1 message, to reduce\n\u003e pollution of the limited BOLT1 message ID space and to\n\u003e allow more flexibility for swap-in-potentiam to expand\n\u003e to new messages inside its own message ID space.\n\u003e\n\u003e For a richer future protocol, we will want to consider\n\u003e how a swap-in can be combined with a splice-in.\n\u003e This is useful if the current total capacity of the\n\u003e channel is lower than the available onchain funds.\n\u003e The swap-in can be credited immediately (and is limited\n\u003e to the current total capacity) while additional funds\n\u003e can be added to the channel via splice-in (which is\n\u003e credited only once the splice-in is confirmed).\n\u003e\n\u003e As-is, a similar result can be obtained using openv1,\n\u003e wherein a swap-in is combined with a channel open,\n\u003e with the swap-in immediately credited while the channel\n\u003e open is awaiting confirmation:\n\u003e\n\u003e * Alice and Bob currently have one or more existing\n\u003e   channels, and Alice has a UTXO in a swap-in-potentiam\n\u003e   address whose value exceeds the incoming capacity of\n\u003e   the existing channel(s).\n\u003e * Alice-\u003eBob `open_channel`.\n\u003e * Bob-\u003eAlice `accept_channel`.\n\u003e * Alice-\u003eBob `request_swap_in` with the \"change address\"\n\u003e   being the funding address of the channel.\n\u003e * Bob-\u003eAlice `accept_swap_in` provides the TXID of the\n\u003e   funding transaction (Alice now knows the \"change\n\u003e   address\" and the Bob final Resolved address, letting it\n\u003e   know the final Resolved state transaction TXID).\n\u003e * Alice-\u003eBob `funding_created` with the TXID.\n\u003e * Bob-\u003eAlice `funding_signed`.\n\u003e * Alice-\u003eBob `swap_in_signed` to provide the signature\n\u003e   spending the swap-in-potentiam address to Bob.\n\u003e * Bob then constructs an HTLC over the existing channel,\n\u003e   which Alice claims, revealing the preimage.\n\u003e * Alice-\u003eBob `swap_in_resolved`.\n\u003e * Bob then broadcasts the Resolved state transaction,\n\u003e   which is also the funding transaction of the new channel.\n\u003e * Both Alice and Bob await confirmation of the transaction\n\u003e   in order to use the new channel.\n\u003e   Alice can still use the existing channel, which has been\n\u003e   topped-up with fresh outgoing capacity by the swap-in.\n\u003e\n\u003e (The above is not safe, as Bob can complete the protocol\n\u003e by using the HTLC-offerring state transaction; this can\n\u003e be fixed by having Alice open *2* channels with the same\n\u003e amount, one with the HTLC-offering state transaction as\n\u003e the funding tx, the other with the Resolved state\n\u003e transaction as the funding tx, and later `error`ing the\n\u003e channel corresponding to the transaction that is not\n\u003e confirmed; this is left as an exercise to the reader,\n\u003e though note that it requires two different change addresses\n\u003e for Alice for both HTLC-offerring and Resolved states,\n\u003e which can be arranged for the protocol)\n\u003e\n\u003e --\n\u003e\n\u003e [1]:\n\u003e https://en.bitcoin.it/wiki/Payment_channels#CLTV-style_payment_channels\n\u003e\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230103/5b5b2cad/attachment-0001.html\u003e"}