Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2019-11-07 📝 Original message: On Thu, Nov 07, 2019 at ...
📅 Original date posted:2019-11-07
📝 Original message:
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...
Here's what I now think you're saying, which I think mostly hangs
together:
Alice sends a HTLC with hash X and value V to Dave via Bob then Carol
Alice generates a nonce AAAA, and calculates H^25(AAAA) = ZZZZ.
Alice creates an onion, and sends the HTLC to Bob, revealing ZZZZ and
6,TTTT to Bob, along with 2500 msat (25 for the hashing ops between
AAAA and ZZZZ, and *100 for round numbers). Bob calculates "6" is a
fair price.
Bob checks H^6(TTTT)=ZZZZ. If not, Bob refunds the 2500 msat, and fails
the HTLC immediately. Otherwise, Bob passes the onion on to Carol, with
1900 msat and TTTT; Carol unwraps the onion revealing 15,EEEE. Carol
calcualtes "15" is a fair price.
Carol checks H^15(EEEE)=TTTT, and fails the route if not, refunding
1900msat to Bob. Otherwise, Carol passes the onion on to Dave, with 400
msat and EEEE. Dave unwraps the onion, revealing 2,CCCC, so can claim
200 msat as well as the HTLC amount, etc.
After the successful route, Dave passes 2,CCCC and 200msat back to Carol,
who validates and continues passing things back.
If Carol instead passes, say, 3,CCCC back, then she also has to refund
300msat to avoid Bob closing the channel, which would be fine, because
Bob can just pass that back too -- Carol's the only one losing money in
that case.
If Carol wants to close the channel anyway and collect the HTLC on
chain, then Bob's situation is:
channel with Alice: +2500 msat
channel with Carol: -1900 msat , -fees , -HTLC funds
If Carol isn't cooperative, Bob only definitely knows TTTT, so to keep
the channel open with Alice, has to refund 1900msat, so:
channel with Alice: +600 msat , +HTLC funds
channel with Carol: -1900 msat , -fees , -HTLC funds
(or Bob could keep the 2500 msat at the cost of Alice closing the channel
too:
channel with Alice: +2500 msat , -fees , +HTLC funds
channel with Carol: -1900 msat , -fees , -HTLC funds
)
So Bob and either keep the channel open but is out 1300 msat because of
Carol, or can gain 600 msat at the cost of closing the channel with
Alice?
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.
> >> 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.
Cheers,
aj
📝 Original message:
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...
Here's what I now think you're saying, which I think mostly hangs
together:
Alice sends a HTLC with hash X and value V to Dave via Bob then Carol
Alice generates a nonce AAAA, and calculates H^25(AAAA) = ZZZZ.
Alice creates an onion, and sends the HTLC to Bob, revealing ZZZZ and
6,TTTT to Bob, along with 2500 msat (25 for the hashing ops between
AAAA and ZZZZ, and *100 for round numbers). Bob calculates "6" is a
fair price.
Bob checks H^6(TTTT)=ZZZZ. If not, Bob refunds the 2500 msat, and fails
the HTLC immediately. Otherwise, Bob passes the onion on to Carol, with
1900 msat and TTTT; Carol unwraps the onion revealing 15,EEEE. Carol
calcualtes "15" is a fair price.
Carol checks H^15(EEEE)=TTTT, and fails the route if not, refunding
1900msat to Bob. Otherwise, Carol passes the onion on to Dave, with 400
msat and EEEE. Dave unwraps the onion, revealing 2,CCCC, so can claim
200 msat as well as the HTLC amount, etc.
After the successful route, Dave passes 2,CCCC and 200msat back to Carol,
who validates and continues passing things back.
If Carol instead passes, say, 3,CCCC back, then she also has to refund
300msat to avoid Bob closing the channel, which would be fine, because
Bob can just pass that back too -- Carol's the only one losing money in
that case.
If Carol wants to close the channel anyway and collect the HTLC on
chain, then Bob's situation is:
channel with Alice: +2500 msat
channel with Carol: -1900 msat , -fees , -HTLC funds
If Carol isn't cooperative, Bob only definitely knows TTTT, so to keep
the channel open with Alice, has to refund 1900msat, so:
channel with Alice: +600 msat , +HTLC funds
channel with Carol: -1900 msat , -fees , -HTLC funds
(or Bob could keep the 2500 msat at the cost of Alice closing the channel
too:
channel with Alice: +2500 msat , -fees , +HTLC funds
channel with Carol: -1900 msat , -fees , -HTLC funds
)
So Bob and either keep the channel open but is out 1300 msat because of
Carol, or can gain 600 msat at the cost of closing the channel with
Alice?
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.
> >> 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.
Cheers,
aj