Joseph Poon [ARCHIVE] on Nostr: 📅 Original date posted:2016-08-19 📝 Original message: On Fri, Aug 19, 2016 at ...

📅 Original date posted:2016-08-19
📝 Original message:
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.)

Sufficient percentages of senders to a charity should be interested in
getting a receipt to prove funds were sent to a charity that I don't
think pre-sending it without generating a proof shouldn't be a normal
case. By default, I don't think clients should even send funds until
they have a signed receipt before cross-chain is supported for safety.

However, I'm not too concerned with cross-chain. As long as there's some
identifier between each hop, I suspect that should be sufficient. Is the
intent of the realm byte to indicate protocols? I think it's reasonable
to have some kind of byte for identifying the message (e.g. using this
as a transport layer for other things), but I think there should already
be sufficient information for cross-chain, presuming pay-to-contract.

> > 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.

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).

There may be a requirement from deriving the fee amount for the last
hop, though.

> > 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.

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.

--
Joseph Poon