<div dir="ltr"><div class="gmail_default" style="font-family:monospace"><span style="font-family:arial,sans-serif">On 1 September 2015 at 17:07, CJP </span><span dir="ltr" style="font-family:arial,sans-serif"><<a href="mailto:cjp@ultimatestunts.nl" target="_blank">cjp@ultimatestunts.nl</a>></span><span style="font-family:arial,sans-serif"> wrote:</span><br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Anthony Towns schreef op di 01-09-2015 om 07:08 [+1000]:<br>
<span class="">> On 31 August 2015 at 04:01, CJP <<a href="mailto:cjp@ultimatestunts.nl">cjp@ultimatestunts.nl</a>> wrote:<br>
> > A - b - c - D - e - F - g - H<br></span>No. H just tells A he can route this particular transaction to D. A<br>
doesn't know H.<br>
<span class=""></span></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace">That doesn't make sense to me -- if A doesn't know H, how can H tell A anything?</div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> Then A sends a txn for H to D as instructed, and D chooses to forward<br>
> it on via F.<br>
<br>
</span>No. The sequence is:<br>
- A establishes a route to D as instructed<br>
- H establishes a route to F, and instructs F to establish a route to D<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace">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?</div></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- F establishes a route to D as instructed<br>
- D matches the two sides, and informs both sides that a route is<br>
present.<br>
- The transaction is locked (HTLC created), starting on the A-b link,<br>
then b-c, and so on, all the way to the g-H link.<br>
<span class=""></span></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> It also relies on end-to-end communication in realtime, which wouldn't<br>
> work for paying to a cold-wallet lightning channel that's only<br>
> occassionally online.</span> </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
</span>I don't see how lightning could pay to a cold wallet.</blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace">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,</div><div class="gmail_default" style="font-family:monospace"><br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> You could of course ignore source routing for the fines, and<br>
> distribute<br>
> the fines as if it is only a non-source routing path. The<br>
> problem is<br>
> that an attacker can create an arbitrarily long path with<br>
> source<br>
> routing, thereby creating arbitrarily large total damage to<br>
> the network,<br>
> corresponding to arbitrarily large total fines.<br>
> I don't think it can go arbitrarily large -- if the recipient is<br>
> paying the fines at each point, then the scenario is:<br>
</span>I don't understand how an intermediate point (D or F) can enforce<br>
payment of fines by A or H.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace">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).</div></div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">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.</div><div class="gmail_default" style="font-family:monospace"><br></div><div class="gmail_default" style="font-family:monospace">Cheers,</div><div class="gmail_default" style="font-family:monospace">aj</div></div><div><br></div>-- <br><div class="gmail_signature">Anthony Towns <<a href="mailto:aj@erisian.com.au" target="_blank">aj@erisian.com.au</a>></div>
</div></div>