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