📅 Original date posted:2020-02-20
📝 Original message:
René Pickhardt <r.pickhardt at googlemail.com> writes:
> Hey Rusty,
>
> I was very delighted to read your proposal. But I don't see how you prevent
> message spam. If I understand you correctly you suggest that I can
> communicate to any node along a path of peer connections (not necessarily
> backed by payment channels but kind of only known through channel
> announcements of gossip) via onions and these onions which are send within
> a new gossip message are not bound to any fees or payments.
It doesn't handle spam, but OTOH it's far cheaper than the HTLC system
(which also doesn't handle spam). I'd be delighted to add an up-front
1msat payment, as soon as we can figure out how to do that.
The non-persistent storage costs for remembering how to forward the
reply are the 200 bytes in my implementation (one pointer to the source
peer, two SHA256s, and the shared secret).
> Let's assume I just missed some spam prevention mechanism or that we can
> fix them. Do I understand the impact of your suggestion correctly that I
> could use this protocol to
>
> 1.) create a fee free rebalancing protocol? Because I could also attach a
> new lightning message inside the onions that would allow nodes without
> direct peer connection to set up a circular rebalancing path.
> 2.) have the ability to communicate with nodes further away than just my
> peers - for example to exchange information for pathfinding and / or
> autopilots?
Indeed. I haven't prevented it, precisely because we *can't*. This
proposal merely gives a more efficient method than encoding via HTLCs.
Cheers,
Rusty.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 12:59:00
in reply to nevent1q…274j
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 12:59:00Event JSON
{
"id": "70ef050c6a13f49891d23f9ae718794610135d7793cdd51a0c1077c8fa0fb0ab",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686315540,
"kind": 1,
"tags": [
[
"e",
"42cfc200e7833f933bf8544e61c12de15ea87116a820ad682a285378ff7c555e",
"",
"root"
],
[
"e",
"5f82f8d52d5eff9bf18156102e733d75e82ddcf83e9b8f5ab23342220698273c",
"",
"reply"
],
[
"p",
"17ccd89be295c0ae65f1cd3740a9dad84ec8b6d7050712a7f04ae5284b2fab99"
]
],
"content": "📅 Original date posted:2020-02-20\n📝 Original message:\nRené Pickhardt \u003cr.pickhardt at googlemail.com\u003e writes:\n\u003e Hey Rusty,\n\u003e\n\u003e I was very delighted to read your proposal. But I don't see how you prevent\n\u003e message spam. If I understand you correctly you suggest that I can\n\u003e communicate to any node along a path of peer connections (not necessarily\n\u003e backed by payment channels but kind of only known through channel\n\u003e announcements of gossip) via onions and these onions which are send within\n\u003e a new gossip message are not bound to any fees or payments.\n\nIt doesn't handle spam, but OTOH it's far cheaper than the HTLC system\n(which also doesn't handle spam). I'd be delighted to add an up-front\n1msat payment, as soon as we can figure out how to do that.\n\nThe non-persistent storage costs for remembering how to forward the\nreply are the 200 bytes in my implementation (one pointer to the source\npeer, two SHA256s, and the shared secret).\n\n\u003e Let's assume I just missed some spam prevention mechanism or that we can\n\u003e fix them. Do I understand the impact of your suggestion correctly that I\n\u003e could use this protocol to\n\u003e\n\u003e 1.) create a fee free rebalancing protocol? Because I could also attach a\n\u003e new lightning message inside the onions that would allow nodes without\n\u003e direct peer connection to set up a circular rebalancing path.\n\u003e 2.) have the ability to communicate with nodes further away than just my\n\u003e peers - for example to exchange information for pathfinding and / or\n\u003e autopilots?\n\nIndeed. I haven't prevented it, precisely because we *can't*. This\nproposal merely gives a more efficient method than encoding via HTLCs.\n\nCheers,\nRusty.",
"sig": "6762d1c10a287bc583b5cf9d92a282c480616277169ab436a39ea7210d1905a1056b98c4f9fdd322e803fbe4c4ee9924dafaf0c2fd96887362392ddac82ed6ca"
}