📅 Original date posted:2015-12-09
📝 Original message:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
> I have sort of lost track of preferences regarding what is to be
> sent through onion routing versus what's not...
Agree, it hasn't been on list for quite some time, the last time we
discussed it, we only included the route in there.
http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-October/00
0247.html
Back then only the pubkey of the next hop has been part of the onion
object, with no additional message to the final receiver. For having
the added privacy of changing R value we would probably add a random
number in there as well.
> Originally I had assumed that some out-of-band messaging would be
> taking place (like an equivalent to a BIP70-style payment
> protocol). Rather than a single QR code, I was expecting an
> interactive wallet-to-wallet protocol while both sides are busy
> communicating with the onion routing network for the actual payment
> route negotiation stuff. When they ultimately find that no
> sufficiently cheap route exists, then the wallets would opt to
> create a new payment channel in some circumstances.
Interesting. I think the important term here is 'out-of-band', as I
would implement above using the actual lightning network. But I also
fail to see how to implement a secure and private communications. I
guess one way would be to have wallets open up a hidden service on TOR
and take payment requests on a service listening there. But it would
not exactly reduce complexity nor would provide sufficient defense
against DoS attacks. Everything simplifies a bit when we assume these
communications using non-private way as simple
HTTPS-requests-responses, but I think we are sacrificing too much
privacy on the way.
> Once a path is found, the recipient would then communicate over
> the wallet-to-wallet channel to pass over the fully-constructed
> onion routing information. Sending that data back over the onion
> routing network may not be necessary. Unfortunately this increases
> the complexity of the payment side (wallet-to-wallet), but
> meanwhile makes for less message passing in onion land, which could
> make the problem easier to think about?
Do you mind defining wallet-to-wallet channel a bit more? Which
techniques could/should they use without leaking information?
Yes, we would increase the total load for the nodes if they should
handle these additional messages. But I think we can go with a
simplified message-delivery-system where each hop costs like 1 satoshi.
I call it simplified, because we are not using the a HTLC, but just
rebalancing the unencumbered outputs of the commit transaction.
As the sender of a message you can go to the first node and give him
30 satoshis for opening the onion object and passing the message to
the next node as instructed in the onion object. It would pay the next
node 29 satoshis, and so on. These would not be enforcable on the
blockchain, so a dishonest node could just keep the 29 satoshis and
not deliver anything at all. However, if you receive a message to
relay it, it is a strong indication that there is a payment to follow
up to that message. The general incentive is to relay these messages,
as fees of payment are likely higher. Given that we can have
sub-satoshi payments too, we might want to tune the cost-per-hop to
make it substantially less than any fees you could get of the payment.
If it remains a problem (and some people could just join the network
and not relay anything just for the sake of it), we might either find
a way to proof this behavior or even use HTLCs for these, even though
that would probably be not practical and bloat commit transactions
waay too much.
- --
Mats Jerratsch
Backend Engineer, Blockchain
e: mats.jerratsch at blockchain.com
PGP: https://pgp.mit.edu/pks/lookup?op=get&search=0x7F3EC6CA
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQIcBAEBCgAGBQJWZ/gwAAoJEAYZmwZ/PsbKv4MQAKxoeZ+G3ozifODlY7nhqYeE
GQChU8DyDal8tAn1Bgb44s7SZMltSgpL9RR2G51/Cn0pygPMPUkT9OS5mRNMlEA1
s1JZ3annaxkJslUlFeF86Tw1MC8LhFYi/WbnJoCPElTmR1PljOtCmpUpjlrDMx7N
YNyjD/zUR+N1ZMqZh0q5okoZegyOkgo0biT5RHrjALUEnK3qWh/PCwUHXYdN/l22
h0LaEi0ajTFhEPNygSFz3Z13KmwYvsmsHl9MydweLbKARx6wo7OPxOWbuNVqD7xF
4eGgkniQZgZM+8owYFifXn/XVGj65PLQaqCN0o/gmCKphqjgoPWtbcJtKg8NtShN
6AI54ZqAtqh4IxpOZRBm2OiFW5TTou/XICDrCS/mfCNtv0wYNANop9+WQ/KTfStx
KnL986TDww5XkLws30Q9C6qFpBjwEgmTmGibvCM8z+HPe223kW0ElofLrWmvqyso
Ncj+iKj91cJLbs3XuzZ6pMgBwhW0ERSRj4bUm6r/oApSRyxYNNLVchOFhU9eWJxu
dhJul2ACFpcTql2zQOUhUe3PXD6M3cRpyLgeqRMNGNNs4+3eTnFdNiqWjK+QIIvZ
uFWpUDcPh3TJSh7TBZCHSxtAIHpCUyPL8u/LV6oZ4PHSd5aLMMm5tq95ViDNzAvm
ARTMgJtNA6q4CYlUflr3
=b/hD
-----END PGP SIGNATURE-----
Mats Jerratsch [ARCHIVE] /
npub1hz…q5x8w
2023-06-09 12:45:21
in reply to nevent1q…ducf
Author Public Key
npub1hz386xq4qszumlx5fsxa3kuxpaf8qvfrqqjg8zdl2l892hrcg55q6q5x8wPublished at
2023-06-09 12:45:21Event JSON
{
"id": "1e59ab2f790599095a4d7716282bc6b475b8da742cc9ff93d19473e3d91aa1ae",
"pubkey": "b8a27d18150405cdfcd44c0dd8db860f5270312300248389bf57ce555c784528",
"created_at": 1686314721,
"kind": 1,
"tags": [
[
"e",
"35c3660d96927f20bf015bd7ea4c5c8c4fd0b788eeb33ade931fcd58af52809d",
"",
"root"
],
[
"e",
"e8b7885ae36176bfa5e15149cdfce3cba68316a06da45f675b0afd6b021b1d58",
"",
"reply"
],
[
"p",
"62ddcb547224b421822b62845fb1bbd77c838b924bd022814cfcbe25b7a07475"
]
],
"content": "📅 Original date posted:2015-12-09\n📝 Original message:\n-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA512\n\n\u003e I have sort of lost track of preferences regarding what is to be\n\u003e sent through onion routing versus what's not...\n\nAgree, it hasn't been on list for quite some time, the last time we\ndiscussed it, we only included the route in there.\n\nhttp://lists.linuxfoundation.org/pipermail/lightning-dev/2015-October/00\n0247.html\n\nBack then only the pubkey of the next hop has been part of the onion\nobject, with no additional message to the final receiver. For having\nthe added privacy of changing R value we would probably add a random\nnumber in there as well.\n\n\u003e Originally I had assumed that some out-of-band messaging would be \n\u003e taking place (like an equivalent to a BIP70-style payment\n\u003e protocol). Rather than a single QR code, I was expecting an\n\u003e interactive wallet-to-wallet protocol while both sides are busy\n\u003e communicating with the onion routing network for the actual payment\n\u003e route negotiation stuff. When they ultimately find that no\n\u003e sufficiently cheap route exists, then the wallets would opt to\n\u003e create a new payment channel in some circumstances.\n\nInteresting. I think the important term here is 'out-of-band', as I\nwould implement above using the actual lightning network. But I also\nfail to see how to implement a secure and private communications. I\nguess one way would be to have wallets open up a hidden service on TOR\nand take payment requests on a service listening there. But it would\nnot exactly reduce complexity nor would provide sufficient defense\nagainst DoS attacks. Everything simplifies a bit when we assume these\ncommunications using non-private way as simple\nHTTPS-requests-responses, but I think we are sacrificing too much\nprivacy on the way.\n\n\u003e Once a path is found, the recipient would then communicate over\n\u003e the wallet-to-wallet channel to pass over the fully-constructed\n\u003e onion routing information. Sending that data back over the onion\n\u003e routing network may not be necessary. Unfortunately this increases\n\u003e the complexity of the payment side (wallet-to-wallet), but\n\u003e meanwhile makes for less message passing in onion land, which could\n\u003e make the problem easier to think about?\n\nDo you mind defining wallet-to-wallet channel a bit more? Which\ntechniques could/should they use without leaking information?\n\nYes, we would increase the total load for the nodes if they should\nhandle these additional messages. But I think we can go with a\nsimplified message-delivery-system where each hop costs like 1 satoshi.\nI call it simplified, because we are not using the a HTLC, but just\nrebalancing the unencumbered outputs of the commit transaction.\n\nAs the sender of a message you can go to the first node and give him\n30 satoshis for opening the onion object and passing the message to\nthe next node as instructed in the onion object. It would pay the next\nnode 29 satoshis, and so on. These would not be enforcable on the\nblockchain, so a dishonest node could just keep the 29 satoshis and\nnot deliver anything at all. However, if you receive a message to\nrelay it, it is a strong indication that there is a payment to follow\nup to that message. The general incentive is to relay these messages,\nas fees of payment are likely higher. Given that we can have\nsub-satoshi payments too, we might want to tune the cost-per-hop to\nmake it substantially less than any fees you could get of the payment.\n\nIf it remains a problem (and some people could just join the network\nand not relay anything just for the sake of it), we might either find\na way to proof this behavior or even use HTLCs for these, even though\nthat would probably be not practical and bloat commit transactions\nwaay too much.\n\n\n- -- \nMats Jerratsch\nBackend Engineer, Blockchain\ne: mats.jerratsch at blockchain.com\nPGP: https://pgp.mit.edu/pks/lookup?op=get\u0026search=0x7F3EC6CA\n-----BEGIN PGP SIGNATURE-----\nComment: GPGTools - https://gpgtools.org\n\niQIcBAEBCgAGBQJWZ/gwAAoJEAYZmwZ/PsbKv4MQAKxoeZ+G3ozifODlY7nhqYeE\nGQChU8DyDal8tAn1Bgb44s7SZMltSgpL9RR2G51/Cn0pygPMPUkT9OS5mRNMlEA1\ns1JZ3annaxkJslUlFeF86Tw1MC8LhFYi/WbnJoCPElTmR1PljOtCmpUpjlrDMx7N\nYNyjD/zUR+N1ZMqZh0q5okoZegyOkgo0biT5RHrjALUEnK3qWh/PCwUHXYdN/l22\nh0LaEi0ajTFhEPNygSFz3Z13KmwYvsmsHl9MydweLbKARx6wo7OPxOWbuNVqD7xF\n4eGgkniQZgZM+8owYFifXn/XVGj65PLQaqCN0o/gmCKphqjgoPWtbcJtKg8NtShN\n6AI54ZqAtqh4IxpOZRBm2OiFW5TTou/XICDrCS/mfCNtv0wYNANop9+WQ/KTfStx\nKnL986TDww5XkLws30Q9C6qFpBjwEgmTmGibvCM8z+HPe223kW0ElofLrWmvqyso\nNcj+iKj91cJLbs3XuzZ6pMgBwhW0ERSRj4bUm6r/oApSRyxYNNLVchOFhU9eWJxu\ndhJul2ACFpcTql2zQOUhUe3PXD6M3cRpyLgeqRMNGNNs4+3eTnFdNiqWjK+QIIvZ\nuFWpUDcPh3TJSh7TBZCHSxtAIHpCUyPL8u/LV6oZ4PHSd5aLMMm5tq95ViDNzAvm\nARTMgJtNA6q4CYlUflr3\n=b/hD\n-----END PGP SIGNATURE-----",
"sig": "3df253da131fae91466a11743d71a7a4ec54577767d40631ba37226fa1fd4c2a84b6a0a05d52d27babb72ff6bdbf4d7032fa4312cf1835d4bb7ecbcfa5dcc382"
}