<oembed><type>rich</type><version>1.0</version><title>Rusty Russell [ARCHIVE] wrote</title><author_name>Rusty Russell [ARCHIVE] (npub1zw…hkhpx)</author_name><author_url>https://yabu.me/npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpx</author_url><provider_name>njump</provider_name><provider_url>https://yabu.me</provider_url><html>📅 Original date posted:2019-11-05&#xA;📝 Original message:&#xA;Anthony Towns &lt;aj at erisian.com.au&gt; writes:&#xA;&gt; On Tue, Nov 05, 2019 at 07:56:45PM +1030, Rusty Russell wrote:&#xA;&gt;&gt; Sure: for simplicity I&#39;m sending a 0-value HTLC.&#xA;&gt;&gt; ZmnSCPxj has balance 10000msat in channel with Rusty, who has 1000msat&#xA;&gt;&gt; in the channel with YAIjbOJa.&#xA;&gt;&#xA;&gt; Alice, Bob and Carol sure seem simpler than Zmn YAI and Rusty...&#xA;&#xA;Agreed, I should not have directly answered the q.&#xA;&#xA;&gt;&gt; Rusty prepares a nonce, AAAAA and hashes it 25 times = ZZZZZ.&#xA;&gt;&gt; ZmnSCPxj prepares the onion, but adds extra fields (see below).  &#xA;&gt;&#xA;&gt; It would have made more sense to me for Alice (Zmn) to generate&#xA;&gt; the nonce, hash it, and prepare the onion, so that the nonce is&#xA;&gt; revealed to Dave (Rusty) if/when the message ever actually reaches its&#xA;&gt; destination. Otherwise Rusty has to send AAAAA to Zmn already so that&#xA;&gt; Zmn can prepare the onion?&#xA;&#xA;The entire point is to pay *up-front*, though, to prevent spam.&#xA;&#xA;Bob/ZmnSCPxj doesn&#39;t prepare anything in the onion.  They get handed the&#xA;last hash directly: Alice is saying &#34;I&#39;ll pay you 50msat for each&#xA;preimage you can give me leading to this hash&#34;.&#xA;&#xA;&gt;&gt; He then&#xA;&gt;&gt; sends the HTLC to Rusty, but also sends ZZZZZ, and 25x50 msat (ie. those&#xA;&gt;&gt; fields are in the update_add_htlc msg).  His balance with Rusty is now&#xA;&gt;&gt; 8750msat (ie. 25x50 to Rusty).&#xA;&gt;&gt; &#xA;&gt;&gt; Rusty decrypts the onion, reads the prepay field: it says 14, LLLLL.&#xA;&gt;&gt; Rusty checks: the hash of the onion &amp; block (or something) does indeed&#xA;&gt;&gt; have the top 8 bits clear, so the cost is in fact 16 - 8/2 == 14.  He&#xA;&gt;&gt; then hashes LLLLL 14 times, and yes, it&#39;s ZZZZZ as ZmnSCPxj said it&#xA;&gt;&gt; should be.&#xA;&gt;&#xA;&gt; I&#39;m not sure why lucky hashing should result in a discount?&#xA;&#xA;Because the PoW adds noise to the amounts, otherwise the path length is&#xA;trivially exposed, esp in the failure case.  It&#39;s weak protection&#xA;though.&#xA;&#xA;&gt; You&#39;re giving a linear discount for exponentially more luck in hashing&#xA;&gt; which also seems odd.&#xA;&#xA;Because you really want some actual payment, not just PoW.  Botnets are&#xA;really good at PoW, less good at sending msats.  And the PoW is hard to&#xA;calibrate (I guessed: real numbers will be necessary)/&#xA;&#xA;&gt; You&#39;ve only got two nonce choices -- the initial AAAA and the depth&#xA;&gt; that you tell Bob and Carol to hash to as steps in the route;&#xA;&#xA;No, the sphinx construction allows for grinding, that was my intent&#xA;here.  The prepay hashes are independent.&#xA;&#xA;&gt; I think you could just make the scheme be:&#xA;&gt;&#xA;&gt;   Alice sends HTLC(k,v) + 1250 msat to Bob&#xA;&gt;   Bob unwraps the onion and forwards HTLC(k,v) + 500 msat to Carol&#xA;&gt;   Carol unwraps the onion and forwards HTLC(k,v) + 250 msat to Dave&#xA;&gt;   Dave redeems the HTLC, claims an extra 300 msat and refunds 200 msat to Carol&#xA;&gt;   Carol redeems the HTLC and refunds 200 msat to Bob&#xA;&gt;   Bob redeems the HTLC and refunds 200 msat to Alice&#xA;&gt;&#xA;&gt; If there&#39;s a failure, Alice loses the 1250 msat, and someone in the&#xA;&gt; path steals the funds.&#xA;&#xA;This example confuses me.&#xA;&#xA;So, you&#39;re charging 250msat per hop?  Why is Bob taking 750?  Does Carol&#xA;now know Dave is the last hop?&#xA;&#xA;Does Alice lose everything on any routing failure?&#xA;&#xA;If so, that is strong incentive for Alice to reduce path-length privacy&#xA;by keeping payments minimal, which I was really trying to avoid.&#xA;&#xA;&gt; You could make the accountable by having Alice&#xA;&gt; also provide &#34;Hash(AAAA, refund=200)&#34; to everyone, encoding AAAA in the&#xA;&gt; onion to Dave, and then each hop reveals AAAA and refunds 200msat to&#xA;&gt; demonstrate their honesty.&#xA;&gt;&#xA;&gt; Does that miss anything that all the hashing achieves?&#xA;&#xA;It does nothing if Carol is the one who can&#39;t route.&#xA;&#xA;&gt; I think the idea here is that you&#39;re paying tiny amounts for the&#xA;&gt; bandwidth, which when it&#39;s successful does in fact pay for the bandwidth;&#xA;&gt; and when it&#39;s unsuccessful results in a channel closure, which makes it&#xA;&gt; unprofitable to cheat the system, but doesn&#39;t change the economics of&#xA;&gt; lightning much overall because channel closures can happen anytime anyway.&#xA;&#xA;Not at all.  You can still fail to route, and still get paid.  You can&#39;t&#xA;steal *more* money without channel closure though.&#xA;&#xA;&gt; I think that approach makes sense.&#xA;&gt;&#xA;&gt; Cheers,&#xA;&gt; aj&#xA;&#xA;Cheers,&#xA;Rusty.</html></oembed>