[Lightning-dev] [BOLT Draft] Onion Routing Spec

Rusty Russell rusty at rustcorp.com.au
Sun Aug 21 20:45:06 UTC 2016


Joseph Poon <joseph at lightning.network> writes:
> On Fri, Aug 19, 2016 at 10:26:31AM +0930, Rusty Russell wrote:
>> >> > 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.
>
> Yeah, for sure, I agree with y'all. By default, there should be a
> requirement that the amount is pre-negotiated by the sender and the
> recipient (pay-to-contract, etc.)

Yes, as your point below makes clear; not agreeing on an amount is
susceptible to theft by prior hops:

> This may not fully solve the problem, since if one presumes that the
> second-to-last hop is malicious, they can re-create a new onion blob
> (presuming consistent hashes for each hop, of course).

Great catch.  Oops...

>> 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.
>
> Either way seems practical for some nodes -- I presume if a small
> percentage of nodes redeem without forwarding, then basically nobody
> would re-use.  Not sure if "steal" is the right word, though.

I also tend to use that term for the collect-all-because-you-cheated
transaction.  Because "rightfully taking what is mine" is too much of a
mouthful :)

Cheers,
Rusty.


More information about the Lightning-dev mailing list