CJP [ARCHIVE] on Nostr: 📅 Original date posted:2015-09-01 📝 Original message: Anthony Towns schreef op ...

📅 Original date posted:2015-09-01
📝 Original message:
Anthony Towns schreef op di 01-09-2015 om 07:08 [+1000]:
> On 31 August 2015 at 04:01, CJP <cjp at ultimatestunts.nl> wrote:
> > A - b - c - D - e - F - g - H
> > H pays 0.003 mBTC to F (explicit source routing fee;
> H
> > selected F for
> > onion-routing towards D, without A's knowledge)
> > You mean "D selected F for onion-routing towards H" here,
> surely?
> No :-)
> Both sides of a payment may value their privacy, so both sides
> may want
> to perform onion routing independently.
> ​ ​
> It's a bit similar to TOR hidden
> services: you route from both sides towards a "meeting point"
> somewhere
> on the route, which is not necessarily one of the end points.
>
>
> Hmm. I would look at that more like:
>
>
> Setup:
> - H wants to be secretive.
> - H establishes a channel with g

Yes.

> - H tells F he can route to H via g
> - H tells D he can route to H via F

No. If H has a routable address (which is optional in this scenario,
since it's not used here), it would be "g tells F he can route to H via
g". But that information isn't used here, and the transaction isn't tied
to H's routable address, since there is no "routing to H" in this
scenario: there is only routing from A to D and from H to D through F.

> Announcement:
> - H tells other people (such as A) they can route to H via D

No. H just tells A he can route this particular transaction to D. A
doesn't know H.
>
> Then A sends a txn for H to D as instructed, and D chooses to forward
> it on via F.

No. The sequence is:
- A establishes a route to D as instructed
- H establishes a route to F, and instructs F to establish a route to D
- F establishes a route to D as instructed
- D matches the two sides, and informs both sides that a route is
present.
- The transaction is locked (HTLC created), starting on the A-b link,
then b-c, and so on, all the way to the g-H link.
>
> (Hmm. In that scenario, if e tried to send a txn to H, she would route
> via D, then find D routed the txn back to it -- using the same R --
> and that F was the next destination. This would be an information
> leak, arguably. Likewise for anyone whose cheapest path to D was
> through e)

Does not apply to the way I describe how it should work.
>
> Note that, because locking of transaction funds is always done
> in payer
> -> payee direction, this requires a separate routing phase
> before the
> locking. So, first you find a route (where all parties say
> they agree to
> fees, tx amount, timeouts and other conditions), and then you
> start
> performing transaction-channel actions.
>
>
> Isn't that a bit circular -- "you obtain the route by sending messages
> along the route" ?

No. Route finding can consist of several attempts, and each attempt
consists of sending messages between nodes. Once you find a route
(probably the first attempt in a well-optimized routing system), you can
send further messages along the route, but you did in fact already send
messages along the route prior to knowing that it will become your
route.
>
> It also relies on end-to-end communication in realtime, which wouldn't
> work for paying to a cold-wallet lightning channel that's only
> occassionally online.

I don't see how lightning could pay to a cold wallet. I assume that, at
least when starting a transaction, all nodes on the route are online.
>
> If you *did* assume everything is in realtime, you could avoid fines
> entirely just by having the protocol be something like:
>
>
> - the official timeout was 4 days, the unofficial timeout is 4
> minutes
> - ...
> - okay 4 minutes is up, do you know R?
> - no, okay, we're revoking the transaction.
> - you don't want to? fine, channel is closed.

I assume the "official" timeout is the one mentioned in the HTLC; it has
to be large (several days) to avoid nodes becoming vulnerable due to
loss of connectivity in the middle of a transaction: it might take you
some time to establish an alternative internet connection, and it has to
happen before the official timeout.

Neighbors can always try to impose shorter unofficial time-outs, with
the sanction that the channel will be closed. The consequence is that
both sides, and the network as a whole, lose a link, so it should be
avoided if possible.
>
> Maybe that's what the default protocol should be anyway, and fines are
> just an extension to that to bribe the payer not to close the
> channel...

Yes.

> You could of course ignore source routing for the fines, and
> distribute
> the fines as if it is only a non-source routing path. The
> problem is
> that an attacker can create an arbitrarily long path with
> source
> routing, thereby creating arbitrarily large total damage to
> the network,
> corresponding to arbitrarily large total fines.
>
>
> ​I don't think it can go arbitrarily large -- if the recipient is
> paying the fines at each point, then the scenario is:

I don't understand how an intermediate point (D or F) can enforce
payment of fines by A or H.

You could of course pre-pay the fines with a separate transaction, which
has D or F as payee endpoint, and send the fines back in case of a
successful transaction. This assumes the intermediate nodes are trusted
with the fine amounts.

CJP