📅 Original date posted:2023-05-10
🗒️ Summary of this message: A proposal to lock UTXOs after tx_completes have been exchanged to prevent double-spending in 0-conf channels, but it may not work for splicing.
📝 Original message:
Hey Matt, Zman,
> I propose that we DO lock our UTXOs after tx_completes have been
> exchanged IF we are the only contributor. We don't have to worry
> about liquidity griefing in this case, since the peer has no
> tx_signatures to withhold from us.
While this is true for dual funding, this isn't true for splicing, where
we need the remote `tx_signatures` to spend the channel's current
funding output. But it's not an issue, the untrusted peer will send
their `tx_signatures` first (since they're not contributing to the
transaction) and we can `TryLock()` once we receive that.
> Your proposal basically means "do not dual-fund 0-conf".
> You might as well use the much simpler openv1 flow in that case, just
> because it is simpler.
I also thought that this was the easy way out, but I was hoping we could
do better. The issue with that option (using v1 with locks for 0-conf,
and v2 with soft locks for non 0-conf) is that we need to implement that
soft lock mechanism (we cannot simply rely on bitcoin core, which only
supports hard locks) or use separate bitcoin core wallets for 0-conf and
non 0-conf.
But there is probably no free lunch here! And anyway, this post was also
made to raise awareness for implementers to make sure they don't end up
accidentally double-spending 0-conf channels when implementing dual
funding.
Thanks,
Bastien
Le mer. 10 mai 2023 à 02:07, ZmnSCPxj <ZmnSCPxj at protonmail.com> a écrit :
> Good morning Matt, and t-bast,
>
> Your proposal basically means "do not dual-fund 0-conf".
> You might as well use the much simpler openv1 flow in that case, just
> because it is simpler.
>
> Regards,
> ZmnSCPxj
>
>
>
>
> Sent with Proton Mail secure email.
>
> ------- Original Message -------
> On Tuesday, May 9th, 2023 at 5:38 PM, Matt Morehouse <
> mattmorehouse at gmail.com> wrote:
>
>
> > Hi Bastien,
> >
> > In general, 0-conf is only safe when WE are the only contributor to
> > the channel, otherwise the peer could double spend us.
> >
> > The problem you seem to be describing is that we might double-spend
> > ourselves if we don't lock our 0-conf UTXOs at some point. I propose
> > that we DO lock our UTXOs after tx_completes have been exchanged IF we
> > are the only contributor. We don't have to worry about liquidity
> > griefing in this case, since the peer has no tx_signatures to withhold
> > from us. Of course, the opportunistic upgrade of a regular channel to
> > 0-conf won't work -- we need a way to differentiate 0-conf channels
> > prior to UTXO selection, so that we don't reuse soft-locked UTXOs.
> >
> > All together, what I propose is:
> >
> > 1) If the channel type has option_zeroconf, select UTXOs that are not
> > soft locked.
> > 2) If the peer adds any inputs to the funding transaction, abort
> > (0-conf is unsafe for us in this case).
> > 3) After tx_complete exchange, TryLock() our UTXO inputs and abort if
> > already locked.
> > 4) Broadcast funding transaction and begin using the 0-conf channel.
> >
> > I think this at least enables the common use case for 0-conf: LSPs can
> > use their own funds to open 0-conf channels for clients.
> >
> > - Matt
> >
> >
> >
> >
> > On Sat, May 6, 2023 at 3:16 AM Bastien TEINTURIER bastien at acinq.fr
> wrote:
> >
> > > Good morning list,
> > >
> > > One of the challenges created by the introduction of dual funded
> > > transactions [1] in lightning is how to protect against liquidity
> > > griefing attacks from malicious peers [2].
> > >
> > > Let's start by reviewing this liquidity griefing issue. The dual
> funding
> > > protocol starts by exchanging data about the utxos each peer adds to
> the
> > > shared transaction, then exchange signatures and broadcast the
> resulting
> > > transaction. If peers lock their utxos as soon as they've decided to
> add
> > > them to the shared transaction, the remote node may go silent. If that
> > > happens, the honest node has some liquidity that is locked and
> unusable.
> > >
> > > This cannot easily be fixed by simply unlocking utxos after detecting
> > > that the remote node is fishy, because the remote node would still have
> > > succeeded at locking your liquidity for a (small) duration, and could
> > > start other instances of that attack with different node_ids.
> > >
> > > An elegant solution to this issue is to never lock utxos used in dual
> > > funded transactions. If a remote node goes silent in the middle of an
> > > instance of the protocol, your utxos will automatically be re-used in
> > > another instance of the protocol. The only drawback with that approach
> > > is that when you have multiple concurrent instances of dual funding
> with
> > > honest peers, some of them may fail because they are double-spent by
> one
> > > of the concurrent instances. This is acceptable, since the protocol
> > > should complete fairly quickly when peers are honest, and at worst, it
> > > can simply be restarted when failure is detected.
> > >
> > > But that solution falls short when using 0-conf, because accidentally
> > > double-spending a 0-conf channel (because of concurrent instances) can
> > > result in loss of funds for one of the peers (if payments were made on
> > > that channel before detecting the double-spend). It seems like using
> > > 0-conf forces us to lock utxos to avoid this issue, which means that
> > > nodes offering 0-conf services expose themselves to liquidity griefing.
> > >
> > > Another related issue is that nodes that want to offer 0-conf channels
> > > must ensure that the utxos they use for 0-conf are isolated from the
> > > utxos they use for non 0-conf, otherwise it is not possible to properly
> > > lock utxos, because of the following race scenario:
> > >
> > > - utxoA is selected for a non 0-conf funding attempt and not locked
> > > (to protect against liquidity griefing)
> > > - utxoA is also selected for a 0-conf funding attempt (because it is
> > > found unlocked in the wallet) and then locked
> > > - the funding transaction for the 0-conf channel is successfully
> > > published first and that channel is instantly used for payments
> > > - the funding transaction for the non 0-conf channel is then published
> > > and confirms, accidentally double-spending the 0-conf channel
> > >
> > > This can be fixed by using a "soft lock" when selecting utxos for a non
> > > 0-conf funding attempt. 0-conf funding attempts must ignore soft locked
> > > utxos while non 0-conf funding attempts can (should) reuse soft locked
> > > utxos.
> > >
> > > In eclair, we are currently doing "opportunistic" 0-conf:
> > >
> > > - if we receive `channel_ready` immediately (which means that our peer
> > > trusts us to use 0-conf)
> > > - and we're the only contributor to the funding transaction (our peer
> > > doesn't have any input that they could use to double-spend)
> > > - and the transaction hasn't been RBF-ed yet
> > >
> > > Then we immediately send `channel_ready` as well and start using that
> > > channel (because we know we won't double spend ourselves). This is nice
> > > because it lets us use 0-conf in a way where only one side of the
> > > channel needs to trust the other side (instead of both sides trusting
> > > each other).
> > >
> > > Unfortunately, we cannot do that anymore when mixing 0-conf and non
> > > 0-conf funding attempts, because the utxos may be soft locked,
> > > preventing us from "upgrading" to 0-conf.
> > >
> > > You have successfully reached the end of this quite technical post,
> > > congrats! My goal with this post is to gather ideas on how we could
> > > improve that situation and offer good enough protections against
> > > liquidity griefing for nodes offering 0-conf services. Please share
> > > your ideas! And yes, I know, 0-conf is a massive implementation pain
> > > point that we would all like to remove from our codebases, but hey,
> > > users like it ¯\(ツ)/¯
> > >
> > > Cheers,
> > > Bastien
> > >
> > > [1] https://github.com/lightning/bolts/pull/851
> > > [2] https://github.com/lightning/bolts/pull/851#discussion_r997537630
> > > _______________________________________________
> > > Lightning-dev mailing list
> > > Lightning-dev at lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> >
> > _______________________________________________
> > 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/20230510/1e7a1a83/attachment.html>;
Bastien TEINTURIER [ARCHIVE] /
npub17f…ntr0s
2023-06-19 17:42:20
in reply to nevent1q…5wst
Author Public Key
npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0sPublished at
2023-06-19 17:42:20Event JSON
{
"id": "9496641cc6ec3ad0e0df62e3be77205fda8b36880d3b8a312bad84508325a69b",
"pubkey": "f26569a10f83f6935797b8b53a87974fdcc1de6abd31e3b1a3a19bdaed8031cb",
"created_at": 1687196540,
"kind": 1,
"tags": [
[
"e",
"acdedd1cfdb5604088e466488dc51cd5e92cb63586d3ce388a785b5474fec1d1",
"",
"root"
],
[
"e",
"2a2673efad4f979d887454653be618e66db683887c4b8ca2fcf3676a10e101ec",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2023-05-10\n🗒️ Summary of this message: A proposal to lock UTXOs after tx_completes have been exchanged to prevent double-spending in 0-conf channels, but it may not work for splicing.\n📝 Original message:\nHey Matt, Zman,\n\n\u003e I propose that we DO lock our UTXOs after tx_completes have been\n\u003e exchanged IF we are the only contributor. We don't have to worry\n\u003e about liquidity griefing in this case, since the peer has no\n\u003e tx_signatures to withhold from us.\n\nWhile this is true for dual funding, this isn't true for splicing, where\nwe need the remote `tx_signatures` to spend the channel's current\nfunding output. But it's not an issue, the untrusted peer will send\ntheir `tx_signatures` first (since they're not contributing to the\ntransaction) and we can `TryLock()` once we receive that.\n\n\u003e Your proposal basically means \"do not dual-fund 0-conf\".\n\u003e You might as well use the much simpler openv1 flow in that case, just\n\u003e because it is simpler.\n\nI also thought that this was the easy way out, but I was hoping we could\ndo better. The issue with that option (using v1 with locks for 0-conf,\nand v2 with soft locks for non 0-conf) is that we need to implement that\nsoft lock mechanism (we cannot simply rely on bitcoin core, which only\nsupports hard locks) or use separate bitcoin core wallets for 0-conf and\nnon 0-conf.\n\nBut there is probably no free lunch here! And anyway, this post was also\nmade to raise awareness for implementers to make sure they don't end up\naccidentally double-spending 0-conf channels when implementing dual\nfunding.\n\nThanks,\nBastien\n\nLe mer. 10 mai 2023 à 02:07, ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e a écrit :\n\n\u003e Good morning Matt, and t-bast,\n\u003e\n\u003e Your proposal basically means \"do not dual-fund 0-conf\".\n\u003e You might as well use the much simpler openv1 flow in that case, just\n\u003e because it is simpler.\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e Sent with Proton Mail secure email.\n\u003e\n\u003e ------- Original Message -------\n\u003e On Tuesday, May 9th, 2023 at 5:38 PM, Matt Morehouse \u003c\n\u003e mattmorehouse at gmail.com\u003e wrote:\n\u003e\n\u003e\n\u003e \u003e Hi Bastien,\n\u003e \u003e\n\u003e \u003e In general, 0-conf is only safe when WE are the only contributor to\n\u003e \u003e the channel, otherwise the peer could double spend us.\n\u003e \u003e\n\u003e \u003e The problem you seem to be describing is that we might double-spend\n\u003e \u003e ourselves if we don't lock our 0-conf UTXOs at some point. I propose\n\u003e \u003e that we DO lock our UTXOs after tx_completes have been exchanged IF we\n\u003e \u003e are the only contributor. We don't have to worry about liquidity\n\u003e \u003e griefing in this case, since the peer has no tx_signatures to withhold\n\u003e \u003e from us. Of course, the opportunistic upgrade of a regular channel to\n\u003e \u003e 0-conf won't work -- we need a way to differentiate 0-conf channels\n\u003e \u003e prior to UTXO selection, so that we don't reuse soft-locked UTXOs.\n\u003e \u003e\n\u003e \u003e All together, what I propose is:\n\u003e \u003e\n\u003e \u003e 1) If the channel type has option_zeroconf, select UTXOs that are not\n\u003e \u003e soft locked.\n\u003e \u003e 2) If the peer adds any inputs to the funding transaction, abort\n\u003e \u003e (0-conf is unsafe for us in this case).\n\u003e \u003e 3) After tx_complete exchange, TryLock() our UTXO inputs and abort if\n\u003e \u003e already locked.\n\u003e \u003e 4) Broadcast funding transaction and begin using the 0-conf channel.\n\u003e \u003e\n\u003e \u003e I think this at least enables the common use case for 0-conf: LSPs can\n\u003e \u003e use their own funds to open 0-conf channels for clients.\n\u003e \u003e\n\u003e \u003e - Matt\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e On Sat, May 6, 2023 at 3:16 AM Bastien TEINTURIER bastien at acinq.fr\n\u003e wrote:\n\u003e \u003e\n\u003e \u003e \u003e Good morning list,\n\u003e \u003e \u003e\n\u003e \u003e \u003e One of the challenges created by the introduction of dual funded\n\u003e \u003e \u003e transactions [1] in lightning is how to protect against liquidity\n\u003e \u003e \u003e griefing attacks from malicious peers [2].\n\u003e \u003e \u003e\n\u003e \u003e \u003e Let's start by reviewing this liquidity griefing issue. The dual\n\u003e funding\n\u003e \u003e \u003e protocol starts by exchanging data about the utxos each peer adds to\n\u003e the\n\u003e \u003e \u003e shared transaction, then exchange signatures and broadcast the\n\u003e resulting\n\u003e \u003e \u003e transaction. If peers lock their utxos as soon as they've decided to\n\u003e add\n\u003e \u003e \u003e them to the shared transaction, the remote node may go silent. If that\n\u003e \u003e \u003e happens, the honest node has some liquidity that is locked and\n\u003e unusable.\n\u003e \u003e \u003e\n\u003e \u003e \u003e This cannot easily be fixed by simply unlocking utxos after detecting\n\u003e \u003e \u003e that the remote node is fishy, because the remote node would still have\n\u003e \u003e \u003e succeeded at locking your liquidity for a (small) duration, and could\n\u003e \u003e \u003e start other instances of that attack with different node_ids.\n\u003e \u003e \u003e\n\u003e \u003e \u003e An elegant solution to this issue is to never lock utxos used in dual\n\u003e \u003e \u003e funded transactions. If a remote node goes silent in the middle of an\n\u003e \u003e \u003e instance of the protocol, your utxos will automatically be re-used in\n\u003e \u003e \u003e another instance of the protocol. The only drawback with that approach\n\u003e \u003e \u003e is that when you have multiple concurrent instances of dual funding\n\u003e with\n\u003e \u003e \u003e honest peers, some of them may fail because they are double-spent by\n\u003e one\n\u003e \u003e \u003e of the concurrent instances. This is acceptable, since the protocol\n\u003e \u003e \u003e should complete fairly quickly when peers are honest, and at worst, it\n\u003e \u003e \u003e can simply be restarted when failure is detected.\n\u003e \u003e \u003e\n\u003e \u003e \u003e But that solution falls short when using 0-conf, because accidentally\n\u003e \u003e \u003e double-spending a 0-conf channel (because of concurrent instances) can\n\u003e \u003e \u003e result in loss of funds for one of the peers (if payments were made on\n\u003e \u003e \u003e that channel before detecting the double-spend). It seems like using\n\u003e \u003e \u003e 0-conf forces us to lock utxos to avoid this issue, which means that\n\u003e \u003e \u003e nodes offering 0-conf services expose themselves to liquidity griefing.\n\u003e \u003e \u003e\n\u003e \u003e \u003e Another related issue is that nodes that want to offer 0-conf channels\n\u003e \u003e \u003e must ensure that the utxos they use for 0-conf are isolated from the\n\u003e \u003e \u003e utxos they use for non 0-conf, otherwise it is not possible to properly\n\u003e \u003e \u003e lock utxos, because of the following race scenario:\n\u003e \u003e \u003e\n\u003e \u003e \u003e - utxoA is selected for a non 0-conf funding attempt and not locked\n\u003e \u003e \u003e (to protect against liquidity griefing)\n\u003e \u003e \u003e - utxoA is also selected for a 0-conf funding attempt (because it is\n\u003e \u003e \u003e found unlocked in the wallet) and then locked\n\u003e \u003e \u003e - the funding transaction for the 0-conf channel is successfully\n\u003e \u003e \u003e published first and that channel is instantly used for payments\n\u003e \u003e \u003e - the funding transaction for the non 0-conf channel is then published\n\u003e \u003e \u003e and confirms, accidentally double-spending the 0-conf channel\n\u003e \u003e \u003e\n\u003e \u003e \u003e This can be fixed by using a \"soft lock\" when selecting utxos for a non\n\u003e \u003e \u003e 0-conf funding attempt. 0-conf funding attempts must ignore soft locked\n\u003e \u003e \u003e utxos while non 0-conf funding attempts can (should) reuse soft locked\n\u003e \u003e \u003e utxos.\n\u003e \u003e \u003e\n\u003e \u003e \u003e In eclair, we are currently doing \"opportunistic\" 0-conf:\n\u003e \u003e \u003e\n\u003e \u003e \u003e - if we receive `channel_ready` immediately (which means that our peer\n\u003e \u003e \u003e trusts us to use 0-conf)\n\u003e \u003e \u003e - and we're the only contributor to the funding transaction (our peer\n\u003e \u003e \u003e doesn't have any input that they could use to double-spend)\n\u003e \u003e \u003e - and the transaction hasn't been RBF-ed yet\n\u003e \u003e \u003e\n\u003e \u003e \u003e Then we immediately send `channel_ready` as well and start using that\n\u003e \u003e \u003e channel (because we know we won't double spend ourselves). This is nice\n\u003e \u003e \u003e because it lets us use 0-conf in a way where only one side of the\n\u003e \u003e \u003e channel needs to trust the other side (instead of both sides trusting\n\u003e \u003e \u003e each other).\n\u003e \u003e \u003e\n\u003e \u003e \u003e Unfortunately, we cannot do that anymore when mixing 0-conf and non\n\u003e \u003e \u003e 0-conf funding attempts, because the utxos may be soft locked,\n\u003e \u003e \u003e preventing us from \"upgrading\" to 0-conf.\n\u003e \u003e \u003e\n\u003e \u003e \u003e You have successfully reached the end of this quite technical post,\n\u003e \u003e \u003e congrats! My goal with this post is to gather ideas on how we could\n\u003e \u003e \u003e improve that situation and offer good enough protections against\n\u003e \u003e \u003e liquidity griefing for nodes offering 0-conf services. Please share\n\u003e \u003e \u003e your ideas! And yes, I know, 0-conf is a massive implementation pain\n\u003e \u003e \u003e point that we would all like to remove from our codebases, but hey,\n\u003e \u003e \u003e users like it ¯\\(ツ)/¯\n\u003e \u003e \u003e\n\u003e \u003e \u003e Cheers,\n\u003e \u003e \u003e Bastien\n\u003e \u003e \u003e\n\u003e \u003e \u003e [1] https://github.com/lightning/bolts/pull/851\n\u003e \u003e \u003e [2] https://github.com/lightning/bolts/pull/851#discussion_r997537630\n\u003e \u003e \u003e _______________________________________________\n\u003e \u003e \u003e Lightning-dev mailing list\n\u003e \u003e \u003e Lightning-dev at lists.linuxfoundation.org\n\u003e \u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e \u003e\n\u003e \u003e _______________________________________________\n\u003e \u003e Lightning-dev mailing list\n\u003e \u003e Lightning-dev at lists.linuxfoundation.org\n\u003e \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/20230510/1e7a1a83/attachment.html\u003e",
"sig": "af7b2872e546fbb22f722e080d5ebfed4952286fa10715074d832a00ac15f9e5985af6efc2f7c1d1fafad893377b86208a7844789eb75e6d4095689f6272c7b4"
}