📅 Original date posted:2023-07-28 🗒️ Summary of this ...

2023-07-31T00:54:54+02:00

In reply to nevent1q…ypyu
_________________________

📅 Original date posted:2023-07-28
🗒️ Summary of this message: ZmnSCPxj proposes a scheme for a multipath payment protocol called "keysend" that allows for splitting payments into multiple parts.
📝 Original message:
Hi ZmnSCPxj,

This sounds very similar to AMP
(https://docs.lightning.engineering/lightning-network-tools/lnd/amp).
Does this scheme offer any improvements over AMP?

- Matt

On Fri, Jul 28, 2023 at 7:24 AM ZmnSCPxj via Lightning-dev
<lightning-dev at lists.linuxfoundation.org> wrote:
>
> Good morning list,
>
> I would like to share a simple scheme for creating a `keysend` protocol that allows for multipath payments.
>
> In `keysend`, the preimage is embedded as TLV 5482373484 with length 32.
>
> In the multipath case, we want the receiver to only be able to claim the payment once all parts have arrived at the receiver.
>
> For example, suppose we want to split the `keysend` into 2 parts.
> Let us select a true preimage `p` at random.
> Then, we generate the payment hash `h = SHA256(p)`.
>
> Then, we generate a new 256-bit scalar, `a`.
> For one part, we send `a` for TLV 5482373484, and for the second part, we send `a ^ p`, where `^` is XOR.
> All parts use the same payment hash `h`.
>
> The receiver, on receiving either part, will find that the supposed preimage does not match the actual HTLC payment hashes.
> Instead of failing, it holds the payment, using the usual basic multipath payment rules.
>
> When the receiver receives another part, it will XOR together the supposed preimages.
> In the above case, it would get `a` and `a ^ p`, which when XORed together result in `a ^ a ^ p` or `p`, which is now the correct preimage, and the receiver can now claim the entire complete funds.
>
> The same technique would work with any number of parts --- if we split into `n` parts, we generate `n - 1` additional random scalars and use it for the first `n - 1` parts, then XOR all of them with the scalar-to-be-split for the `n`th part.
> This scheme also works for dynamic splitting, i.e. if you are splitting a part that was already split off from a part that was already split off from a part etc.
>
> A sender can detect if the receiver does not support multipath `keysend` if a part reaches the receiver and it errors with `incorrect_or_unknown_payment_details`.
> If the receiver is aware of multipath `keysend`, it would hold onto the incoming HTLCs until MPP timeout, and instead error with `mpp_timeout`.
> Thus, support for this on the receiver side does not need to be specially announced via a new feature bit --- an MPP-capable sender can simply try to split, and if it gets an `incorrect_or_unknown_payment_details`, knows that the receiver does not support multipath `keysend`.
> The same feature bit 55 can be reused.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

📅 Original date posted:2023-05-09 🗒️ Summary of this ...

2023-06-09T15:13:15+02:00

In reply to nevent1q…pm64
_________________________

📅 Original date posted:2023-05-09
🗒️ Summary of this message: A proposed solution to protect against liquidity griefing attacks in Lightning Network's dual funded transactions is to never lock UTXOs used in the transactions. Instead, if a remote node goes silent, the UTXOs will be automatically re-used in another instance of the protocol. However, this solution is not safe when multiple contributors are involved. The proposed solution is to lock UTXOs after tx_complete exchange if the channel has only one contributor and to differentiate 0-conf channels prior to UTXO selection to avoid reusing soft-locked UTXOs.
📝 Original message:
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

Nostr notes by

📅 Original date posted:2023-07-28 🗒️ Summary of this ...

📅 Original date posted:2023-05-09 🗒️ Summary of this ...