Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2019-11-05 📝 Original message: On Tue, Nov 05, 2019 at ...
📅 Original date posted:2019-11-05
📝 Original message:
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...
> 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?
> 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? You're
giving a linear discount for exponentially more luck in hashing which
also seems odd.
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; so the
incentive there seems to be to do a large depth, so you might hash
AAAA 1000 times, and figure that you'll find a leading eight 0's once
in the first 256 entries, then another by the time you get up to 512,
and another by the time you get to 768, which gets you discounts on
three intermediaries. But the cost there is that your intermediaries
collectively have to do the same amount of hashing you did, so it's not
proof-of-work, because it's as hard to verify as it is to generate.
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. 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?
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.
I think that approach makes sense.
Cheers,
aj
📝 Original message:
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...
> 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?
> 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? You're
giving a linear discount for exponentially more luck in hashing which
also seems odd.
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; so the
incentive there seems to be to do a large depth, so you might hash
AAAA 1000 times, and figure that you'll find a leading eight 0's once
in the first 256 entries, then another by the time you get up to 512,
and another by the time you get to 768, which gets you discounts on
three intermediaries. But the cost there is that your intermediaries
collectively have to do the same amount of hashing you did, so it's not
proof-of-work, because it's as hard to verify as it is to generate.
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. 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?
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.
I think that approach makes sense.
Cheers,
aj