Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2019-11-08 📝 Original message: Anthony Towns <aj at ...
📅 Original date posted:2019-11-08
📝 Original message:
Anthony Towns <aj at erisian.com.au> writes:
> On Thu, Nov 07, 2019 at 02:56:51PM +1030, Rusty Russell wrote:
>> > What you wrote to Zmn says "Rusty decrypts the onion, reads the prepay
>> > field: it says 14, LLLL." but Alice doesn't know anything other than
>> > ZZZZ so can't put LLLL in the onion?
>> Alice created the onion. Alice knows all the preimages, since she
>> created the chain AAAAA....ZZZZZ.
>
> In your reply to Zmn, it was Rusty (Bob) preparing the nonce and creating
> the chain AAAA...ZZZZ -- so I was lost as to what you were proposing...
Oops. Don't trust that Rusty guy, let's stick with Alice.
[ Snip summary, which is correct ]
> As far as the "fair price" goes, the spitballed formula is "16 - X/4"
> where X is number of zero bits in some PoW-y thing. The proposal is
> the thing is SHA256(blockhash|revealedonion) which works, and (I think)
> means each step is individually grindable.
>
> I think an alternative would be to use the prepayment hashes themselves,
> so you generate the nonce AAAA as the value you'll send to Dave then
> hash it repeatedly to get BBBB..QQQQ, then check if pow(AAAA,BBBB) has
> 60 leading zero bits or pow(AAAA,CCCC) has 56 leading zero bits etc.
> If you made pow(a,b) be SHA256(a,b,shared-onion-key) I think it'd
> preserve privacy, but also mean you can't meaningfully grind unfairly
> cheap routing except for very short paths?
>
> If you don't grind and just go by luck, the average number of hashes
> per hop is ~15.93 (if I got my maths right), so you should be able to
> estimate path length pretty accurate by dividing claimed prepaid funds by
> 15.93*25msat or whatever. If everyone grinds at each level independently,
> I think you'd just subtract maybe 6 hops from that, but the maths would
> mostly stay the same?
>
> Though I think you could obfusticate that pretty well by moving
> some of the value from the HTLC into the prepayment -- you'd risk losing
> that extra value if the payment made it all the way to the recipient but
> they declined the HTLC that way though.
Yeah, and doesn't help obscure in the in-the-middle failure case unf.
Which is really bad with current payment_hash since you can spot
multiple attempts so easily. Hence my attempt to roll in some PoW to
obscure the amounts.
The ideal prepay range would be wider, so you can believably have
payments between 16 and 4 per hop, say. But if I can grind it I'll
naturally restrict the range to the lower end, and if it's ungrindable
(eg. based on nodeid and payment_hash or recent block hash) then
everyone on the path knows what it so too.
So, hashcash here is better than nothing, but still not very good.
>> >> Does Alice lose everything on any routing failure?
>> > That was my thought yeah; it seems weird to pay upfront but expect a
>> > refund on failure -- the HTLC funds are already committed upfront and
>> > refunded on failure.
>> AFAICT you have to overpay, since anything else is very revealing of
>> path length. Which kind of implies a refund, I think.
>
> I guess you'd want to pay for a path length of about 20 whether the
> path is actually 17, 2, 10 or 5. But a path length of 20 is just paying
> for bandwidth for maybe 200kB of total traffic which at $1/GB is 2% of
> 1 cent, which doesn't seem that worth refunding (except for really tiny
> micropayments, where paying for payment bandwidth might not be feasible
> at all).
>
> If you're buying a $2 coffee and paying 500ppm in regular fees per hop
> with 5 hops, then each routing attempt increases your fees by 4%, which
> seems pretty easy to ignore to me.
True, but ideally we'd have lots of noise even if people are trying to
minimize fees (which, if they're sending messages rather than payments,
they might).
Cheers,
Rusty.
📝 Original message:
Anthony Towns <aj at erisian.com.au> writes:
> On Thu, Nov 07, 2019 at 02:56:51PM +1030, Rusty Russell wrote:
>> > What you wrote to Zmn says "Rusty decrypts the onion, reads the prepay
>> > field: it says 14, LLLL." but Alice doesn't know anything other than
>> > ZZZZ so can't put LLLL in the onion?
>> Alice created the onion. Alice knows all the preimages, since she
>> created the chain AAAAA....ZZZZZ.
>
> In your reply to Zmn, it was Rusty (Bob) preparing the nonce and creating
> the chain AAAA...ZZZZ -- so I was lost as to what you were proposing...
Oops. Don't trust that Rusty guy, let's stick with Alice.
[ Snip summary, which is correct ]
> As far as the "fair price" goes, the spitballed formula is "16 - X/4"
> where X is number of zero bits in some PoW-y thing. The proposal is
> the thing is SHA256(blockhash|revealedonion) which works, and (I think)
> means each step is individually grindable.
>
> I think an alternative would be to use the prepayment hashes themselves,
> so you generate the nonce AAAA as the value you'll send to Dave then
> hash it repeatedly to get BBBB..QQQQ, then check if pow(AAAA,BBBB) has
> 60 leading zero bits or pow(AAAA,CCCC) has 56 leading zero bits etc.
> If you made pow(a,b) be SHA256(a,b,shared-onion-key) I think it'd
> preserve privacy, but also mean you can't meaningfully grind unfairly
> cheap routing except for very short paths?
>
> If you don't grind and just go by luck, the average number of hashes
> per hop is ~15.93 (if I got my maths right), so you should be able to
> estimate path length pretty accurate by dividing claimed prepaid funds by
> 15.93*25msat or whatever. If everyone grinds at each level independently,
> I think you'd just subtract maybe 6 hops from that, but the maths would
> mostly stay the same?
>
> Though I think you could obfusticate that pretty well by moving
> some of the value from the HTLC into the prepayment -- you'd risk losing
> that extra value if the payment made it all the way to the recipient but
> they declined the HTLC that way though.
Yeah, and doesn't help obscure in the in-the-middle failure case unf.
Which is really bad with current payment_hash since you can spot
multiple attempts so easily. Hence my attempt to roll in some PoW to
obscure the amounts.
The ideal prepay range would be wider, so you can believably have
payments between 16 and 4 per hop, say. But if I can grind it I'll
naturally restrict the range to the lower end, and if it's ungrindable
(eg. based on nodeid and payment_hash or recent block hash) then
everyone on the path knows what it so too.
So, hashcash here is better than nothing, but still not very good.
>> >> Does Alice lose everything on any routing failure?
>> > That was my thought yeah; it seems weird to pay upfront but expect a
>> > refund on failure -- the HTLC funds are already committed upfront and
>> > refunded on failure.
>> AFAICT you have to overpay, since anything else is very revealing of
>> path length. Which kind of implies a refund, I think.
>
> I guess you'd want to pay for a path length of about 20 whether the
> path is actually 17, 2, 10 or 5. But a path length of 20 is just paying
> for bandwidth for maybe 200kB of total traffic which at $1/GB is 2% of
> 1 cent, which doesn't seem that worth refunding (except for really tiny
> micropayments, where paying for payment bandwidth might not be feasible
> at all).
>
> If you're buying a $2 coffee and paying 500ppm in regular fees per hop
> with 5 hops, then each routing attempt increases your fees by 4%, which
> seems pretty easy to ignore to me.
True, but ideally we'd have lots of noise even if people are trying to
minimize fees (which, if they're sending messages rather than payments,
they might).
Cheers,
Rusty.