📅 Original date posted:2016-08-18
📝 Original message:
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. 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.
Cheers,
Christian
Christian Decker [ARCHIVE] /
npub1wt…gtuyn
2023-06-09 12:46:27
in reply to nevent1q…670r
Author Public Key
npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynPublished at
2023-06-09 12:46:27Event JSON
{
"id": "88749d9071f80fc3f2efa30b0dc654c30ecab9a341bcf55f33c8882ac6dec564",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686314787,
"kind": 1,
"tags": [
[
"e",
"f166a20039cde752a8ba4e6cccc22d4b2719f9a29840f0c295641243ae59d83f",
"",
"root"
],
[
"e",
"c13e8ec28978d1043ebd1f152ed72ce8133caa2d3ca13bb61695b294af13d4c8",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2016-08-18\n📝 Original message:\nOn Wed, Aug 17, 2016 at 07:53:03PM +0930, Rusty Russell wrote:\n\u003e Christian Decker \u003cdecker.christian at gmail.com\u003e writes:\n\u003e \u003e I agree that the realm byte is a sensible addition. To trigger this we\n\u003e \u003e would need to have multiple channels, on different chains, using the\n\u003e \u003e same identifiers between two nodes. Only in this case we'd have an\n\u003e \u003e ambiguity where to transfer the funds. Assuming we have the route A -\u003e\n\u003e \u003e B =\u003e C, where =\u003e indicates two channels, one in litecoin and one in\n\u003e \u003e bitcoin, and both channels use the same identity for C. Then the\n\u003e \u003e instruction to forward 0.01 units to C is ambiguous, as it could be\n\u003e \u003e denominated in either litecoin or bitcoin.\n\u003e \u003e\n\u003e \u003e While not dangerous it is rather unfortunate as it results in\n\u003e \u003e guesswork. It is not dangerous because if A transferred litecoin to B\n\u003e \u003e then B will (hopefully) never forward a higher value to C using\n\u003e \u003e bitcoin, and if it were bitcoin then the final recipient would not\n\u003e \u003e sign off an inferior amount than what he expected.\n\u003e \n\u003e Worse case: C is a charity, accepting donations. A's software screwed\n\u003e up and didn't realize C was litecoin, not bitcoin. B collects a huge\n\u003e fee, C gets tiny donation.\n\nTrue, that's a dangerous scenario. If the recipient does not know the\nintended amount and accepts anything then fee-shaving is very\nprofitable. In general I'm a bit concerned about rhash re-use, after\nall today it's not uncommon to just publish a bitcoin address, people\nmight be tempted to do the same in Lightning.\n\nCheers,\nChristian",
"sig": "caf31a5a722a04ad7569e5b8aab6289ecc814cf1e8c597bca23cb42d6d46bf0a8caeb7e9be0846310f899f9aa145fd938be9015fb6aa5a69cd918a749e512bd9"
}