From laolu32 at gmail.com Sat Aug 20 20:32:19 2016 From: laolu32 at gmail.com (Olaoluwa Osuntokun) Date: Sat, 20 Aug 2016 20:32:19 +0000 Subject: [Lightning-dev] [BOLT Draft] Onion Routing Spec In-Reply-To: <20160819183647.GB15105@lightning.network> References: <87oa5byeyf.fsf@rustcorp.com.au> <87oa58ox54.fsf@rustcorp.com.au> <87wpjl3rzh.fsf@rustcorp.com.au> <20160815120647.GA2595@nex> <87h9ajae48.fsf@rustcorp.com.au> <20160818090622.GA28345@nex> <871t1lefuo.fsf@rustcorp.com.au> <20160819183647.GB15105@lightning.network> Message-ID: Rusty Russell wrote: > Which creates a subtle requirement: even the terminal onion should include an > amount. With the current draft specification, all hops receive a per-hop payload (unless we're now abandoning the payload for the final hop due to the "terminal" byte?). This behavior isn't changed for the final hop, so they also extract a payload once they process the onion packet. Christian Decker wrote: > If the recipient does not know the intended amount and accepts anything then > fee-shaving is very profitable. In my mind (although it seems to be handled with the current onion-packet format), this is an issue which should be resolved/negotiated at a higher level. Ignoring the possibility of using the network as a general messaging layer (which seems a bit ambitious, plus brings up DoS concerns), the sender/receiver should have already negotiated all the details of the payment. If the receiver communicated the target r-hash, then they should also be aware of the associated value to be paid out with reveal of the corresponding r-preimage. Joseph's description fits by current thought model. Rusty Russell wrote: > 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. One might say that the concern is a bit "academic" in nature. In theory, within a mix-net (sending emails/messages, not HTLC's), an adversary shouldn't be able to re-inject an arbitrary previously processed packet thereby causing node to process and forward the packet as normal. If they're able to do this, then in conjunction with several nodes participating within the network, the adversary may be able to partially (worse, even fully) re-construct the original path by observing how the replays propagate throughout the network. However, practically, we're currently building something that more resembles an onion routing network rather than a mix-net. Additionally, as all communication links are end-to-end encrypted+authenticated, in reality, the only party able to attempt to replay packet within the network are nodes whom have directly received+processes the onion packet in the past. In our particular context, assuming the onion packet is encapsulated within the message that adds a new HTLC, then an attempt to replay would be foolish as if one assumes nodes remember all r-preimages, then the first hop would just immediately pull the funds (as Rusty points out). Joseph Poon wrote: > 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). First, *all* hops receive a per-hop payload which ideally would includes details such as payment, time-lock value, etc. Second, this is only possible if Bob (the second-to-last hop), *knows* that they are in fact, the second-to-last hop *and* already knows all identities following them within the route. Otherwise, the route will fail as Bob is unable to construct a new fully valid onion packet. Even in the case that Bob if able to do this, it shouldn't affect the payment as a whole assuming Dave (the final receiver) knows the value he's expecting for each particular r-hash (as you detailed earlier). -- Laolu -------------- next part -------------- An HTML attachment was scrubbed... URL: