Olaoluwa Osuntokun [ARCHIVE] on Nostr: 📅 Original date posted:2016-08-20 📝 Original message: Rusty Russell <rusty at ...

📅 Original date posted:2016-08-20
📝 Original message:
Rusty Russell <rusty at rustcorp.com.au> 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 <decker.christian at gmail.com> 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 <rusty at rustcorp.com.au> 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 <joseph at lightning.network> 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160820/81e0955d/attachment.html>;