📅 Original date posted:2023-10-17
🗒️ Summary of this message: Enabling lightning withdrawals from exchanges to user wallets efficiently requires the use of covenants. Batching multiple transactions into one is a possible solution, but it requires signatures from multiple users.
📝 Original message:
Hi Bastien,
> The naive way of enabling lightning withdrawals is to make the user
> provide a lightning invoice that the exchange pays over lightning. The
> issue is that in most cases, this simply shifts the burden of making an
> on-chain transaction to the user's wallet provider: if the user doesn't
> have enough inbound liquidity (which is likely), a splice transaction
> will be necessary. If N users withdraw funds from an exchange, we most
> likely will end up with N separate splice transactions.
It is uncertain to me if secure fee-bumping, even with future mechanisms
like package relay and nversion=3, is robust enough for multi-party
transactions and covenant-enable constructions under usual risk models.
See test here:
https://github.com/ariard/bitcoin/commit/19d61fa8cf22a5050b51c4005603f43d72f1efcf
Appreciated expert eyes of folks understanding both lightning and core
mempool on this.
There was a lot of back and forth on nversion=3 design rules, though the
test is normally built on glozow top commit of the 3 Oct 2023.
Best,
Antoine
Le mar. 17 oct. 2023 à 14:03, Bastien TEINTURIER <bastien at acinq.fr> a
écrit :
> Good morning list,
>
> I've been trying to design a protocol to let users withdraw funds from
> exchanges directly into their lightning wallet in an efficient way
> (with the smallest on-chain footprint possible).
>
> I've come to the conclusion that this is only possible with some form of
> covenants (e.g. `SIGHASH_ANYPREVOUT` would work fine in this case). The
> goal of this post is to explain why, and add this usecase to the list of
> useful things we could do if we had covenants (insert "wen APO?" meme).
>
> The naive way of enabling lightning withdrawals is to make the user
> provide a lightning invoice that the exchange pays over lightning. The
> issue is that in most cases, this simply shifts the burden of making an
> on-chain transaction to the user's wallet provider: if the user doesn't
> have enough inbound liquidity (which is likely), a splice transaction
> will be necessary. If N users withdraw funds from an exchange, we most
> likely will end up with N separate splice transactions.
>
> Hence the idea of batching those into a single transaction. Since we
> don't want to introduce any intermediate transaction, we must be able
> to create one transaction that splices multiple channels at once. The
> issue is that for each of these channels, we need a signature from the
> corresponding wallet user, because we're spending the current funding
> output, which is a 2-of-2 multisig between the wallet user and the
> wallet provider. So we run into the usual availability problem: we need
> signatures from N users who may not be online at the same time, and if
> one of those users never comes online or doesn't complete the protocol,
> we must discard the whole batch.
>
> There is a workaround though: each wallet user can provide a signature
> using `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` that spends their current
> funding output to create a new funding output with the expected amount.
> This lets users sign *before* knowing the final transaction, which the
> exchange can create by batching pairs of inputs/outputs. But this has
> a fatal issue: at that point the wallet user has no way of spending the
> new funding output (since it is also a 2-of-2 between the wallet user
> and the wallet provider). The wallet provider can now blackmail the user
> and force them to pay to get their funds back.
>
> Lightning normally fixes this by exchanging signatures for a commitment
> transaction that sends the funds back to their owners *before* signing
> the parent funding/splice transaction. But here that is impossible,
> because we don't know yet the `txid` of the batch transaction (that's
> the whole point, we want to be able to sign before creating the batch)
> so we don't know the new `prevout` we should spend from. I couldn't find
> a clever way to work around that, and I don't think there is one (but
> I would be happy to be wrong).
>
> With `SIGHASH_ANYPREVOUT`, this is immediately fixed: we can exchange
> anyprevout signatures for the commitment transaction, and they will be
> valid to spend from the batch transaction. We are safe from signature
> reuse, because funding keys are rotated at each splice so we will never
> create another output that uses the same 2-of-2 script.
>
> I haven't looked at other forms of covenants, but most of them likely
> address this problem as well.
>
> Cheers,
> Bastien
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20231017/65951f73/attachment-0001.html>;
Antoine Riard [ARCHIVE] /
npub1vj…4x8dd
2023-10-18 13:02:10
in reply to nevent1q…su52
Author Public Key
npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8ddPublished at
2023-10-18 13:02:10Event JSON
{
"id": "9227ddfc90eddb194fe03d05b4d4a21744bda13081ed8cccf7308169d3e40d8c",
"pubkey": "6485bc56963b51c9043d0855cca9f78fcbd0ce135a195c3f969e18ca54a0d551",
"created_at": 1697634130,
"kind": 1,
"tags": [
[
"e",
"303d86ebef1a784bb747472377f5307787a976a50931422891c11afd889fa9d5",
"",
"root"
],
[
"e",
"98979fe91043ba737c778f9de403be0afb489edac1b7d06d29890cc4411c5caf",
"",
"reply"
],
[
"p",
"f26569a10f83f6935797b8b53a87974fdcc1de6abd31e3b1a3a19bdaed8031cb"
]
],
"content": "📅 Original date posted:2023-10-17\n🗒️ Summary of this message: Enabling lightning withdrawals from exchanges to user wallets efficiently requires the use of covenants. Batching multiple transactions into one is a possible solution, but it requires signatures from multiple users.\n📝 Original message:\nHi Bastien,\n\n\u003e The naive way of enabling lightning withdrawals is to make the user\n\u003e provide a lightning invoice that the exchange pays over lightning. The\n\u003e issue is that in most cases, this simply shifts the burden of making an\n\u003e on-chain transaction to the user's wallet provider: if the user doesn't\n\u003e have enough inbound liquidity (which is likely), a splice transaction\n\u003e will be necessary. If N users withdraw funds from an exchange, we most\n\u003e likely will end up with N separate splice transactions.\n\nIt is uncertain to me if secure fee-bumping, even with future mechanisms\nlike package relay and nversion=3, is robust enough for multi-party\ntransactions and covenant-enable constructions under usual risk models.\n\nSee test here:\nhttps://github.com/ariard/bitcoin/commit/19d61fa8cf22a5050b51c4005603f43d72f1efcf\n\nAppreciated expert eyes of folks understanding both lightning and core\nmempool on this.\nThere was a lot of back and forth on nversion=3 design rules, though the\ntest is normally built on glozow top commit of the 3 Oct 2023.\n\nBest,\nAntoine\n\nLe mar. 17 oct. 2023 à 14:03, Bastien TEINTURIER \u003cbastien at acinq.fr\u003e a\nécrit :\n\n\u003e Good morning list,\n\u003e\n\u003e I've been trying to design a protocol to let users withdraw funds from\n\u003e exchanges directly into their lightning wallet in an efficient way\n\u003e (with the smallest on-chain footprint possible).\n\u003e\n\u003e I've come to the conclusion that this is only possible with some form of\n\u003e covenants (e.g. `SIGHASH_ANYPREVOUT` would work fine in this case). The\n\u003e goal of this post is to explain why, and add this usecase to the list of\n\u003e useful things we could do if we had covenants (insert \"wen APO?\" meme).\n\u003e\n\u003e The naive way of enabling lightning withdrawals is to make the user\n\u003e provide a lightning invoice that the exchange pays over lightning. The\n\u003e issue is that in most cases, this simply shifts the burden of making an\n\u003e on-chain transaction to the user's wallet provider: if the user doesn't\n\u003e have enough inbound liquidity (which is likely), a splice transaction\n\u003e will be necessary. If N users withdraw funds from an exchange, we most\n\u003e likely will end up with N separate splice transactions.\n\u003e\n\u003e Hence the idea of batching those into a single transaction. Since we\n\u003e don't want to introduce any intermediate transaction, we must be able\n\u003e to create one transaction that splices multiple channels at once. The\n\u003e issue is that for each of these channels, we need a signature from the\n\u003e corresponding wallet user, because we're spending the current funding\n\u003e output, which is a 2-of-2 multisig between the wallet user and the\n\u003e wallet provider. So we run into the usual availability problem: we need\n\u003e signatures from N users who may not be online at the same time, and if\n\u003e one of those users never comes online or doesn't complete the protocol,\n\u003e we must discard the whole batch.\n\u003e\n\u003e There is a workaround though: each wallet user can provide a signature\n\u003e using `SIGHASH_SINGLE | SIGHASH_ANYONECANPAY` that spends their current\n\u003e funding output to create a new funding output with the expected amount.\n\u003e This lets users sign *before* knowing the final transaction, which the\n\u003e exchange can create by batching pairs of inputs/outputs. But this has\n\u003e a fatal issue: at that point the wallet user has no way of spending the\n\u003e new funding output (since it is also a 2-of-2 between the wallet user\n\u003e and the wallet provider). The wallet provider can now blackmail the user\n\u003e and force them to pay to get their funds back.\n\u003e\n\u003e Lightning normally fixes this by exchanging signatures for a commitment\n\u003e transaction that sends the funds back to their owners *before* signing\n\u003e the parent funding/splice transaction. But here that is impossible,\n\u003e because we don't know yet the `txid` of the batch transaction (that's\n\u003e the whole point, we want to be able to sign before creating the batch)\n\u003e so we don't know the new `prevout` we should spend from. I couldn't find\n\u003e a clever way to work around that, and I don't think there is one (but\n\u003e I would be happy to be wrong).\n\u003e\n\u003e With `SIGHASH_ANYPREVOUT`, this is immediately fixed: we can exchange\n\u003e anyprevout signatures for the commitment transaction, and they will be\n\u003e valid to spend from the batch transaction. We are safe from signature\n\u003e reuse, because funding keys are rotated at each splice so we will never\n\u003e create another output that uses the same 2-of-2 script.\n\u003e\n\u003e I haven't looked at other forms of covenants, but most of them likely\n\u003e address this problem as well.\n\u003e\n\u003e Cheers,\n\u003e Bastien\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/20231017/65951f73/attachment-0001.html\u003e",
"sig": "62f609a5180bac851746e606ec17b5458a461fc8d89ed0623303b9bf43d00eb28fc092d41138c17df3965455acc0b513add2205fa8493ef29cfe808e3d563334"
}