<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">&lt;<a href="mailto:cjp@ultimatestunts.nl" target="_blank">cjp@ultimatestunts.nl</a>&gt;</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="">&gt; On 31 August 2015 at 04:01, CJP &lt;<a href="mailto:cjp@ultimatestunts.nl">cjp@ultimatestunts.nl</a>&gt; wrote:<br>
&gt;         &gt;         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&#39;t know H.<br>
<span class=""></span></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace">​That doesn&#39;t make sense to me -- if A doesn&#39;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="">&gt; Then A sends a txn for H to D as instructed, and D chooses to forward<br>
&gt; 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&#39;t know H, so A can&#39;t tell them. If D&#39;s telling H, then isn&#39;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="">&gt; It also relies on end-to-end communication in realtime, which wouldn&#39;t<br>
&gt; work for paying to a cold-wallet lightning channel that&#39;s only<br>
&gt; 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&#39;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&#39;m thinking about is if you&#39;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&#39;ll want to have some way to &quot;get money from the ATM&quot; once a week or so. And conversely you&#39;ll want some way to put your salary into the &quot;ATM&quot; 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="">&gt;         You could of course ignore source routing for the fines, and<br>
&gt;         distribute<br>
&gt;         the fines as if it is only a non-source routing path. The<br>
&gt;         problem is<br>
&gt;         that an attacker can create an arbitrarily long path with<br>
&gt;         source<br>
&gt;         routing, thereby creating arbitrarily large total damage to<br>
&gt;         the network,<br>
&gt;         corresponding to arbitrarily large total fines.<br>
&gt; ​I don&#39;t think it can go arbitrarily large -- if the recipient is<br>
&gt; paying the fines at each point, then the scenario is:<br>
</span>I don&#39;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&#39;s the payee that can close the transaction early, so if they choose not to, it&#39;s their responsibility. I think that&#39;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&#39;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 &lt;<a href="mailto:aj@erisian.com.au" target="_blank">aj@erisian.com.au</a>&gt;</div>
</div></div>