Anthony Towns [ARCHIVE] on Nostr: đź“… Original date posted:2015-09-01 đź“ť Original message: On 1 September 2015 at ...
đź“… Original date posted:2015-09-01
đź“ť Original message:
On 1 September 2015 at 17:07, CJP <cjp at ultimatestunts.nl> wrote:
> 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
> No. H just tells A he can route this particular transaction to D. A
> doesn't know H.
>
​That doesn't make sense to me -- if A doesn't know H, how can H tell A
anything?
> > 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
>
​Same here; how does H know to do anything? A doesn't know H, so A can't
tell them. If D's telling H, then isn't D already using the F/g route to do
so?​
- 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.
>
> > 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.
​Maybe. The case I'm thinking about is if you're doing most of your
day-to-day transactions over lightning (buying coffee and lunch and
groceries and bus tickets and fuel and whatnot), then your channels will
empty out pretty quickly; so you'll want to have some way to "get money
from the ATM" once a week or so. And conversely you'll want some way to put
your salary into the "ATM" as well. Doing that via the blockchain works
fine of course, but then your average lightning user is doing a blockchain
transaction once every week or three, rather than once every two years,
> 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.
>
I think fines have to be paid on the payee side, so H not A -- it's the
payee that can close the transaction early, so if they choose not to, it's
their responsibility. I think that's independent of whether the routing was
source/non-source (though for source routing, the original payer might add
some fees to cover the potential fines).
Then doesn't it just reduce to enforcing payments from your direct
neighbour, and relying on them transitively doing the same? ie, D forces e
to pay a fine, and in order to cover those costs e forces F to pay a larger
fine, F forces g to pay an even larger fine, and g forces H to cover all of
that.
Cheers,
aj
--
Anthony Towns <aj at erisian.com.au>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150901/b6387f72/attachment.html>;
đź“ť Original message:
On 1 September 2015 at 17:07, CJP <cjp at ultimatestunts.nl> wrote:
> 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
> No. H just tells A he can route this particular transaction to D. A
> doesn't know H.
>
​That doesn't make sense to me -- if A doesn't know H, how can H tell A
anything?
> > 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
>
​Same here; how does H know to do anything? A doesn't know H, so A can't
tell them. If D's telling H, then isn't D already using the F/g route to do
so?​
- 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.
>
> > 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.
​Maybe. The case I'm thinking about is if you're doing most of your
day-to-day transactions over lightning (buying coffee and lunch and
groceries and bus tickets and fuel and whatnot), then your channels will
empty out pretty quickly; so you'll want to have some way to "get money
from the ATM" once a week or so. And conversely you'll want some way to put
your salary into the "ATM" as well. Doing that via the blockchain works
fine of course, but then your average lightning user is doing a blockchain
transaction once every week or three, rather than once every two years,
> 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.
>
I think fines have to be paid on the payee side, so H not A -- it's the
payee that can close the transaction early, so if they choose not to, it's
their responsibility. I think that's independent of whether the routing was
source/non-source (though for source routing, the original payer might add
some fees to cover the potential fines).
Then doesn't it just reduce to enforcing payments from your direct
neighbour, and relying on them transitively doing the same? ie, D forces e
to pay a fine, and in order to cover those costs e forces F to pay a larger
fine, F forces g to pay an even larger fine, and g forces H to cover all of
that.
Cheers,
aj
--
Anthony Towns <aj at erisian.com.au>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150901/b6387f72/attachment.html>;