Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2016-08-18 📝 Original message: Christian Decker ...
📅 Original date posted:2016-08-18
📝 Original message:
Christian Decker <decker.christian at gmail.com> writes:
> On Wed, Aug 17, 2016 at 07:53:03PM +0930, Rusty Russell wrote:
>> Christian Decker <decker.christian at gmail.com> writes:
>> > I agree that the realm byte is a sensible addition. To trigger this we
>> > would need to have multiple channels, on different chains, using the
>> > same identifiers between two nodes. Only in this case we'd have an
>> > ambiguity where to transfer the funds. Assuming we have the route A ->
>> > B => C, where => indicates two channels, one in litecoin and one in
>> > bitcoin, and both channels use the same identity for C. Then the
>> > instruction to forward 0.01 units to C is ambiguous, as it could be
>> > denominated in either litecoin or bitcoin.
>> >
>> > While not dangerous it is rather unfortunate as it results in
>> > guesswork. It is not dangerous because if A transferred litecoin to B
>> > then B will (hopefully) never forward a higher value to C using
>> > bitcoin, and if it were bitcoin then the final recipient would not
>> > sign off an inferior amount than what he expected.
>>
>> Worse case: C is a charity, accepting donations. A's software screwed
>> up and didn't realize C was litecoin, not bitcoin. B collects a huge
>> fee, C gets tiny donation.
>
> True, that's a dangerous scenario. If the recipient does not know the
> intended amount and accepts anything then fee-shaving is very
> profitable.
Which creates a subtle requirement: even the terminal onion should
include an amount.
> In general I'm a bit concerned about rhash re-use, after
> all today it's not uncommon to just publish a bitcoin address, people
> might be tempted to do the same in Lightning.
Hmm, maybe we should implement the code to steal such re-sends? Or more
generously, fail it. That would prevent this from becoming a habit, at
least.
Related: I can't seem to figure out why we're so concerned with onion
reuse? It seems if a node were to retransmit the same onion runs this
same risk.
Thanks,
Rusty.
Published at
2023-06-09 12:46:27Event JSON
{
"id": "af2349dd446f75af24f8430c6cbb2b95d2d320039b13dcf81b0e9741af413f63",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686314787,
"kind": 1,
"tags": [
[
"e",
"f166a20039cde752a8ba4e6cccc22d4b2719f9a29840f0c295641243ae59d83f",
"",
"root"
],
[
"e",
"88749d9071f80fc3f2efa30b0dc654c30ecab9a341bcf55f33c8882ac6dec564",
"",
"reply"
],
[
"p",
"72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057"
]
],
"content": "📅 Original date posted:2016-08-18\n📝 Original message:\nChristian Decker \u003cdecker.christian at gmail.com\u003e writes:\n\u003e On Wed, Aug 17, 2016 at 07:53:03PM +0930, Rusty Russell wrote:\n\u003e\u003e Christian Decker \u003cdecker.christian at gmail.com\u003e writes:\n\u003e\u003e \u003e I agree that the realm byte is a sensible addition. To trigger this we\n\u003e\u003e \u003e would need to have multiple channels, on different chains, using the\n\u003e\u003e \u003e same identifiers between two nodes. Only in this case we'd have an\n\u003e\u003e \u003e ambiguity where to transfer the funds. Assuming we have the route A -\u003e\n\u003e\u003e \u003e B =\u003e C, where =\u003e indicates two channels, one in litecoin and one in\n\u003e\u003e \u003e bitcoin, and both channels use the same identity for C. Then the\n\u003e\u003e \u003e instruction to forward 0.01 units to C is ambiguous, as it could be\n\u003e\u003e \u003e denominated in either litecoin or bitcoin.\n\u003e\u003e \u003e\n\u003e\u003e \u003e While not dangerous it is rather unfortunate as it results in\n\u003e\u003e \u003e guesswork. It is not dangerous because if A transferred litecoin to B\n\u003e\u003e \u003e then B will (hopefully) never forward a higher value to C using\n\u003e\u003e \u003e bitcoin, and if it were bitcoin then the final recipient would not\n\u003e\u003e \u003e sign off an inferior amount than what he expected.\n\u003e\u003e \n\u003e\u003e Worse case: C is a charity, accepting donations. A's software screwed\n\u003e\u003e up and didn't realize C was litecoin, not bitcoin. B collects a huge\n\u003e\u003e fee, C gets tiny donation.\n\u003e\n\u003e True, that's a dangerous scenario. If the recipient does not know the\n\u003e intended amount and accepts anything then fee-shaving is very\n\u003e profitable.\n\nWhich creates a subtle requirement: even the terminal onion should\ninclude an amount.\n\n\u003e In general I'm a bit concerned about rhash re-use, after\n\u003e all today it's not uncommon to just publish a bitcoin address, people\n\u003e might be tempted to do the same in Lightning.\n\nHmm, maybe we should implement the code to steal such re-sends? Or more\ngenerously, fail it. That would prevent this from becoming a habit, at\nleast.\n\nRelated: I can't seem to figure out why we're so concerned with onion\nreuse? It seems if a node were to retransmit the same onion runs this\nsame risk.\n\nThanks,\nRusty.",
"sig": "17b7e5e645ca96a20afaffefc548165711a577df5205cc41c25bb225b620fba529fb05da8e68ce1fc1bc01006978917be409db97cdb1073a560ccf46b67b3590"
}