Gijs van Dam [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2020-12-07 to 2021-08-24
💬 Posted a total of 3 messages
📚 Participated in the following categories: Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-10-18 13:02:06

- reply

📅 Original date posted:2023-09-22
🗒️ Summary of this message: Gijs van Dam has developed a proof of concept called Payment Splitting & Switching (PSS) that allows for route and amount changes in Lightning Network payments. PSS could potentially mitigate probing and jamming attacks.
📝 Original message:
Good afternoon list,
I have touched on Link MPP over alternative routes before [0]. The idea is
that a node inside a payment route finds an alternative route to the next
node via one (or more) intermediary nodes. ZmnSCPxj and Christian Decker
were kind enough to discuss the topic with me a bit more, and since it
seemed feasible I went ahead and made a proof of concept by developing a
core-lighting plugin called Payment Splitting & Switching (PSS) [1]. There
is also a screencast showing the plugin in action. [2]
The plugin works as follows. The plugin announces its support for PSS at
`init`. If Alice and Bob both support PSS, and Alice receives a payment to
be relayed to Bob, she can decide to split up the payment into multiple
parts. One part will follow the original route and use the original onion,
but it will commit to an HTLC that carries an amount less than the intended
amount. Upon receiving that HTLC Bob receives the onion that allows him to
forward the payment, but because the HTLC carries less than expected, he
will wait for another payment from Alice. Alice sends that payment like a
normal payment to Bob over an alternative route, e.g. via a single
intermediary node, but contingent on the payment hash of the original
payment. Bob does a little bit of housekeeping to check if the combined
HTLCs are enough for him to forward the payment, and if so, the payment is
forwarded as normal.
My interest in Link MPP and PSS (which is basically Link MPP combined with
JIT-routing [3]) arose through my research in the Balance Discovery Attack
(BDA), aka the probing attack. From the perspective of that attack it is
interesting to note that PSS allows for route changes and amount changes
*without the sender knowing about it*. So when an attacker has to assume
that PSS is used, its interpretation of information obtained through a BDA
changes completely. Using real-world data in an LN simulator I saw up to a
62% drop in information gain when PSS is deployed compared to earlier work
(Alex Biryukov et al.) without PSS [4].
For details I refer to my preprint on the Cryptology ePrint Archive [5].
Any feedback on it would be highly appreciated. I would also love to hear
your thoughts on what role PSS could play, if any, in mitigating probing
and/or jamming.
Because the paper is at times quite technical, I have also written a set of
blog posts introducing the research. [7][8]
Finally, I think PSS would also work with PTLC, but because this post is
long enough as is, I will leave that for another time.
Thank you for your time,
Gijs van Dam
https://www.gijsvandam.nl
[0]:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-August/003144.html
[1]: https://github.com/gijswijs/plugins/tree/master/pss
[2]: https://asciinema.org/a/520416
[3]:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-March/001891.html
[4]: https://link.springer.com/book/9783031182846
[5]: https://eprint.iacr.org/2023/1360
[7]:
https://www.gijsvandam.nl/post/all-types-of-multi-part-payments-in-lightning-network-explained/
[8]:
https://www.gijsvandam.nl/post/the-effect-of-multi-part-payments-on-the-balance-disovery-attack/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230922/0a2a7531/attachment.html>

2023-06-09 13:03:13

- reply

📅 Original date posted:2021-08-07
📝 Original message:
Hi All,
I would like to revisit a topic that has been discussed earlier between
ZmnSCPxj and Christian Decker. [1]
I think it's important to revisit it, because not only does ZmnSCPxj
propose a cool trick, but it can also be used to mitigate certain attacks.
(More on that later)
ZmnSCPxj wrote:
> consider this below graph:
>
> E<---D--->C<---B
> ^ /
> | /
> |L
> A
>
> In the above, B requests a route from B->C->D->E.
>
> However, C cannot send to D, since the channel direction is saturated in
favor of D.
>
> Alternately, C can route to D via A instead. It holds the (encrypted)
route from D to E. It can take that sub-route and treat it as a partial
route-to-payee under rendez-vous routing, as long as node A supports
rendez-vous routing.
>
> This can allow re-routing or payment splitting over multiple hops.
Christian replied by explaining this is not possible because "with this
scheme it is not possible for C to find an ephemeral key that would end up
identical to the one that D would require to decrypt the onion correctly."
Christian is correct but I think this problem can be solved with a simple
change to the setup. Consider the same graph, but now it's not node A that
supports rendezvous routing but it is node D.
To circumvent the saturated channel D-C, C creates the route C->A->D, where
node D supports rendezvous routing. C can create a sub-route from D to E
and treat it as a partial route-to-payee under rendezvous routing by using
the hop payload found when unwrapping the onion of the original route
B->C->D->E . Because every node in a route is able to create the ephemeral
key for the next node by tweaking it with its own shared secret, C is also
able to create the ephemeral key for D. C passes that ephemeral key into
the payload of the rendezvous node D in the alternate route, signaling to D
it needs to swap out the key. D, upon unwrapping its onion sees that it
needs to swap ephemeral keys, does so, and goes on with the route to E.
Under these changed circumstances I don't think Christian's critique still
holds, but I'd love to hear your feedback.
Now as to why I think this is useful:
1. ZmnSCPxj proposed this as kind of atomic JIT rebalancing. The
rebalancing only happens if the payment happens.
2. It can be used to offload HTLC's to another channel, mitigating channel
jamming.
3. It can be used to mitigate Balance Disclosure Attacks, because an
attacker wouldn't necessarily be sure which channels are used for routing.
I think Rusty calls this "sloppy routing".
Thanks for your attention,
Gijs van Dam
[1]:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001573.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210807/28d4e9bf/attachment.html>

2023-06-09 13:01:41

- reply

📅 Original date posted:2020-12-07
📝 Original message:
Hey Lloyd (and others),
I have just been working on something similar. I came up with the following
plan of attack that works within the current protocol:
Create a static channel backup after the fact. I have dubbed this a
synthetic static channel backup. I only use it to trigger the data loss
protection protocol.
By restoring this synthetic SCB a `channel_reestablish` is being sent to
the remote peer. This `channel_reestablish`contains the
`next_commitment_number`and the `next_revocation_number` both set to zero.
This triggers the remote peer to force close the channel dropping its
current commitment transaction to the chain. Using the
`per_commitment_point` received from the remote peer you can now derive the
private key needed for sweeping your funds, using
privkey = basepoint_secret + SHA256(per_commitment_point || basepoint)
We use the basepoint_secret derived (in LND) with
```
basePointSecret, err := keyRing.DerivePrivKey(keychain.KeyDescriptor{
KeyLocator: keychain.KeyLocator{
Family: keychain.KeyFamilyPaymentBase,
Index: 0, // Same commitment index as used by the remote node
},
})
```
I have got this somewhat working in a test setup. (I probably have
overlooked some details). I would be interested in hearing Sjors Provoost
on this, since his question and answer on this topic over on the Bitcoin
StackExchange was really helpful.[1]
He lost his backup in a boating accident as well. (What is it with you guys
and boating? :) )
Your approach covers more cases, and my approach only fits certain edge
cases. But my approach is possible today, without changes to the Lightning
protocol.
Regards,
Gijs
[1]:
https://bitcoin.stackexchange.com/questions/90196/how-to-recover-funds-from-a-force-closed-lnd-lightning-channel/90719#90719
On Mon, Dec 7, 2020 at 8:32 AM Lloyd Fournier <lloyd.fourn at gmail.com> wrote:
> Hi list,
>
> I've been considering the problem of recovering lightning channels after
> losing channel state in a boating accident. The modern way of doing this
> seems to be "static channel backups" -- these are essentially lists of
> channel ids and the nodes you had the channels with.
>
> The idea is that with this backup you can remember who you had channels
> with, connect to them and ask them to force close the channel (can someone
> link me the concrete protocol messages you send to do this?).
>
> It occurred to me that if the lightning protocol were changed slightly you
> could do this without the channel backup at all. Consider the open channel
> message and its two fields `funding_pubkey` and `temporary_channel_id`.
>
>
> https://github.com/lightningnetwork/lightning-rfc/blob/master/02-peer-protocol.md#the-open_channel-message
>
> The reason `temporary_channel_id` is necessarily "temporary" is because we
> don't know the other party's `funding_pubkey`. Instead I propose using
> deterministically randomized version of the node's static public key as the
> `funding_pubkey` so we know it up front. Specifically, when opening a
> channel with a remote node, do a Diffie-Hellman operation with their public
> key and use the resulting shared secret to deterministically produce
> scalars r1 and r2 and use 2-of-2(r1*G + P_local, r2*P_remote) as the script
> pubkey of funding output. Now we know what the funding output would look
> like with any node without interacting with them. Of course, to open
> multiple channels with the same node we would have to generate a new shared
> secret from each one by hashing a counter.
>
> Now that we can figure out what our funding outputs with each node look
> like non-interactively, when we lose our channel state we can find them in
> the UTXO set as long as we can recreate a list of node's we may have had
> channels with. For most non-enterprise users (such as myself) this can be
> done automatically because we exclusively have channels with well known
> reliable public nodes whose public keys can be discovered through routing
> gossip or from public indexes. Therefore if I can just restore my node's
> keypair from my seed I should be able to scan the network for nodes and
> figure out if I have channels open with them and then carry out the
> recovery process. From my perspective this seems to be a rather nice
> improvement in user experience.
>
> Thoughts?
>
> Cheers,
>
> LL
> _______________________________________________
> 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/20201207/d4af1742/attachment.html>

2023-06-09 12:40:44

- reply

2023-06-07 22:58:14

- reply

📅 Original date posted:2021-08-24
📝 Original message:Hi,
Bitcoin does not have a virtual machine. But you do have [Miniscript][1],
[Min.sc][2], [Simplicity][3] and [Sapio][4]. These are all higher level
languages that compile to Bitcoin Script. Sapio is "just" Rust, so that
might fit your setting best.
By the way, this question also has an answer on [Bitcoin Stackexchange][5]
which is a great resource for questions like this.
[1]: http://bitcoin.sipa.be/miniscript/
[2]: https://min.sc/
[3]: https://github.com/ElementsProject/simplicity
[4]: https://learn.sapio-lang.org/
[5]:
https://bitcoin.stackexchange.com/questions/108261/is-there-a-tool-like-ethereum-evm-at-present-for-bitcoin-script
On Tue, Aug 24, 2021 at 2:55 PM Null Null via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi all,
>
> Is there a tool like Ethereum EVM at present? Users can write bitcoin
> scripts in a syntax just like python(or like other programming language);
> through this tool, they can be translated into bitcoin original scripts; it
> sounds like a new programming language has been invented.
>
> In my opinion， Bitcoin script programming is based on reverse Polish
> expression; this is not friendly to programmers;
>
> In fact, Bitcoin's opcode expression ability is very rich, and it may be
> unfriendly, which has affected the promotion of Bitcoin in the technical
> community.
>
> Hope for hearing some voice about this.
>
> Best wish.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210824/233f3b92/attachment.html>