Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2015-09-24 📝 Original message: Anthony Towns <aj at ...
📅 Original date posted:2015-09-24
📝 Original message:
Anthony Towns <aj at erisian.com.au> writes:
>> > Finally for (g), I don't think you want to store fees in the routes
>> Well, propagating fee updates for (say) 1200 routes isn't too bad,
>> as long as they're not changing too fast.
>
> So forgetting the DHTs, then fee updates take effect via the
> dijkstra-routing-gossip protocol. I don't have any idea how well that
> would perform... If an average channel's fee updates U times per day,
> there are C channels, and N nodes, does that mean a background noise of
> O(log(N)*U*C) fee update traffic or something? (dividing by N to get the
> traffic an individual node sees)
That sounds about right. There's a tradeoff between redundancy,
bandwidth and latency.
> It does mean that the "payment info" has to be provided by the payee
> "shortly" before the transaction; otherwise the route and fee information
> would be out of date and the payment becomes "likely" to fail due to
> closed channels or raised fees.
True. Though in the case of raised fees you get feedback, and can
adjust.
>> >> There are some twisty details here:
>> >> 1) How many beacon nodes?
>> >> 12, and increase on a log scale with network size. That size can
>> >> be derived from previous beacons.
>> > I think it's also something you could set per-node, like the
>> > minrelaytxfee.
>> That doesn't make sense, since we need to agree on who is a beacon.
>
> If you have the top 10 beacons and I have the top 14 beacons, we have
> the top 10 beacons in common. During the gossip phase, if either of us
> see someone in the top 10, we pass it along; I pass along a few more as
> well.
If I want to pay you, and you give me those 4 beacons I don't accept, we
break down.
>> >> 2) How long between selection and a beacon becoming active?
>> >> 10 blocks. That gives time for others to connect to beacon node.
>> > Beacons can be "active" as soon as you can route through them, and that's
>> > just a DHT lookup to determine, and then a matter of comparing fees to
>> > what the old beacons give you. So I think no artificial delay is needed,
>> > and the real question is just when you expire your routes to/from the
>> > old beacons?
>> No. Beacons will get saturated fast unless they have a chance to
>> prepare.
>
> Sure. I was thinking you have to volunteer to be a beacon, ie something
> like:
>
> 1) commit to node id (anchor transaction in blockchain)
> 2) commit to ordering (abs difference of node id versus
> sha of latest blockchain block with (depth % 2016 == 0))
> 3) volunteer to be a beacon (sign "imma beacon! depth $n anchor
> $txid")
> 4) gossip (including your signed volunteer statement) and hope you're
> in the top 12
>
> Any preparation (opening new channels etc happens between (2) and (3)),
> transactions happen immediately after (4).
We don't want to have to maintain a table of volunteers, hence 3 & 4 are
merged (simple optimization: delay advertising yourself as a beacon
longer if it's less likely).
Then by convention you delay 10 blocks before using a beacon. By that
time, routes should be sufficient.
So, it comes down to the following if you want to be a beacon:
1) Use same key anchor tx to sign a message linking your node id to the
tx.
2) Broadcast that, and signed routes as normal.
>> In particular, the network will want to establish channels
>> with new beacons, and beacons may well want to bring offline funds
>> online to handle the anticipated capacity.
>
> So... doesn't this provide a /really/ juicy target for hackers? Either
> of the "let's steal funds" variety, or of the "let's find out as much
> info about every transaction as we can" type?
>
> If you just have to hack 12 systems to observe/DoS 100% of lightning
> network transactions, that seems worrying to me. I think I'd want to avoid
> being a beacon in that case, just to avoid painting a target on my system.
>
> I'm not sure if it's a realistic attack model, but if you can observe:
>
> Bob -> Alice: pay me $20 to R (routes to current beacons: ...)
>
> and have control of the beacon Alice ends up using, then you can both
> observe that Alice is trying to make the payment (you see an HTLC with
> $20 and R), and prevent Alice from making the payment (you can just not
> forward any transactions involving R).
Sure. But if you can observe the private conversation between Bob and
Alice, *and* you control enough nodes that you're likely to be the
beacon they choose, you don't need to be a beacon to block them :)
> Without beacons (but routing still being possible somehow!), Bob could
> anonymously post prices and R values in public; Alice could observe them
> anonymously without giving away that she was observing them, and Mallory
> could not prevent Alice from paying Bob, without controlling Alice or Bob,
> or a large proportion of the lightning network as a whole. Bob could be
> a dissident asking for donations in this scenario, eg.
Yes! I've been wondering about this kind of "donation address"
scenario. Turns out you can encode the R value in the onion routed
message you send, too. Only the final recipient can read it anyway.
That doesn't help with routing to the donation address; maybe we will
need a best-effort DHT for that?
> ie, nodes do payment forwarding; wallets just spend/recieve. You'd use
> your phone as just a wallet, but you might run a node at home or in
> the cloud. Wallets still do the lightning protocol themselves, they just
> don't earn fees by forwarding payments.
I think you do want to
>
> Aside: "mesh network" seems to be a much better description than
> hub-and-spoke... cf
>
> https://www.reddit.com/r/Bitcoin/comments/3lo8mb/serious_question_for_blockstreamcom_will_you_let/
Thanks for that: I'd somehow missed that troll.
>> That's a very different architecture,
>
> I'm just using it as terminology (I think...).
>
> The only architectural implication is that I'm assuming "most" people
> (24999 out of 25000) don't end up doing routing. Given routing nodes
> have to be online with hot keys and thus risk being hacked and having
> their funds drained, I think that's fairly plausible?
But that risk also describes a wallet. And if you route, you
potentially gain funds as well as privacy. It's more a connectivity
issue, I think.
> (Or going the other way; if you're making money running a node, I think
> it's pretty reasonable you'll try to serve on the order of 100k users
> -- much less than that and you'll be under utilising your hardware. But
> with only 8B potential customers, there's a limit on the number of nodes
> that can actually do that, as calculated above. I'm assuming economics
> somehow ends up enforcing that limit effectively)
>
>> which uses hosted wallets or something? I don't think that's very
>> interesting.
>
> Not hosted wallets; more along the lines of SPV clients, where you're
> relying on the network to do most of the work (in this case working out
> a cheap route, rather than verifying txns)?
But the "give me a cheap route" question is exactly the same whatever
your role. It's "give me all your routes to beacons". That's a few
hundred routes. If we're clever it's "give me changes since last time",
which is easy given that it's finite.
This has the advantage that you can't even tell if I'm routing or not.
Cheers,
Rusty.
📝 Original message:
Anthony Towns <aj at erisian.com.au> writes:
>> > Finally for (g), I don't think you want to store fees in the routes
>> Well, propagating fee updates for (say) 1200 routes isn't too bad,
>> as long as they're not changing too fast.
>
> So forgetting the DHTs, then fee updates take effect via the
> dijkstra-routing-gossip protocol. I don't have any idea how well that
> would perform... If an average channel's fee updates U times per day,
> there are C channels, and N nodes, does that mean a background noise of
> O(log(N)*U*C) fee update traffic or something? (dividing by N to get the
> traffic an individual node sees)
That sounds about right. There's a tradeoff between redundancy,
bandwidth and latency.
> It does mean that the "payment info" has to be provided by the payee
> "shortly" before the transaction; otherwise the route and fee information
> would be out of date and the payment becomes "likely" to fail due to
> closed channels or raised fees.
True. Though in the case of raised fees you get feedback, and can
adjust.
>> >> There are some twisty details here:
>> >> 1) How many beacon nodes?
>> >> 12, and increase on a log scale with network size. That size can
>> >> be derived from previous beacons.
>> > I think it's also something you could set per-node, like the
>> > minrelaytxfee.
>> That doesn't make sense, since we need to agree on who is a beacon.
>
> If you have the top 10 beacons and I have the top 14 beacons, we have
> the top 10 beacons in common. During the gossip phase, if either of us
> see someone in the top 10, we pass it along; I pass along a few more as
> well.
If I want to pay you, and you give me those 4 beacons I don't accept, we
break down.
>> >> 2) How long between selection and a beacon becoming active?
>> >> 10 blocks. That gives time for others to connect to beacon node.
>> > Beacons can be "active" as soon as you can route through them, and that's
>> > just a DHT lookup to determine, and then a matter of comparing fees to
>> > what the old beacons give you. So I think no artificial delay is needed,
>> > and the real question is just when you expire your routes to/from the
>> > old beacons?
>> No. Beacons will get saturated fast unless they have a chance to
>> prepare.
>
> Sure. I was thinking you have to volunteer to be a beacon, ie something
> like:
>
> 1) commit to node id (anchor transaction in blockchain)
> 2) commit to ordering (abs difference of node id versus
> sha of latest blockchain block with (depth % 2016 == 0))
> 3) volunteer to be a beacon (sign "imma beacon! depth $n anchor
> $txid")
> 4) gossip (including your signed volunteer statement) and hope you're
> in the top 12
>
> Any preparation (opening new channels etc happens between (2) and (3)),
> transactions happen immediately after (4).
We don't want to have to maintain a table of volunteers, hence 3 & 4 are
merged (simple optimization: delay advertising yourself as a beacon
longer if it's less likely).
Then by convention you delay 10 blocks before using a beacon. By that
time, routes should be sufficient.
So, it comes down to the following if you want to be a beacon:
1) Use same key anchor tx to sign a message linking your node id to the
tx.
2) Broadcast that, and signed routes as normal.
>> In particular, the network will want to establish channels
>> with new beacons, and beacons may well want to bring offline funds
>> online to handle the anticipated capacity.
>
> So... doesn't this provide a /really/ juicy target for hackers? Either
> of the "let's steal funds" variety, or of the "let's find out as much
> info about every transaction as we can" type?
>
> If you just have to hack 12 systems to observe/DoS 100% of lightning
> network transactions, that seems worrying to me. I think I'd want to avoid
> being a beacon in that case, just to avoid painting a target on my system.
>
> I'm not sure if it's a realistic attack model, but if you can observe:
>
> Bob -> Alice: pay me $20 to R (routes to current beacons: ...)
>
> and have control of the beacon Alice ends up using, then you can both
> observe that Alice is trying to make the payment (you see an HTLC with
> $20 and R), and prevent Alice from making the payment (you can just not
> forward any transactions involving R).
Sure. But if you can observe the private conversation between Bob and
Alice, *and* you control enough nodes that you're likely to be the
beacon they choose, you don't need to be a beacon to block them :)
> Without beacons (but routing still being possible somehow!), Bob could
> anonymously post prices and R values in public; Alice could observe them
> anonymously without giving away that she was observing them, and Mallory
> could not prevent Alice from paying Bob, without controlling Alice or Bob,
> or a large proportion of the lightning network as a whole. Bob could be
> a dissident asking for donations in this scenario, eg.
Yes! I've been wondering about this kind of "donation address"
scenario. Turns out you can encode the R value in the onion routed
message you send, too. Only the final recipient can read it anyway.
That doesn't help with routing to the donation address; maybe we will
need a best-effort DHT for that?
> ie, nodes do payment forwarding; wallets just spend/recieve. You'd use
> your phone as just a wallet, but you might run a node at home or in
> the cloud. Wallets still do the lightning protocol themselves, they just
> don't earn fees by forwarding payments.
I think you do want to
>
> Aside: "mesh network" seems to be a much better description than
> hub-and-spoke... cf
>
> https://www.reddit.com/r/Bitcoin/comments/3lo8mb/serious_question_for_blockstreamcom_will_you_let/
Thanks for that: I'd somehow missed that troll.
>> That's a very different architecture,
>
> I'm just using it as terminology (I think...).
>
> The only architectural implication is that I'm assuming "most" people
> (24999 out of 25000) don't end up doing routing. Given routing nodes
> have to be online with hot keys and thus risk being hacked and having
> their funds drained, I think that's fairly plausible?
But that risk also describes a wallet. And if you route, you
potentially gain funds as well as privacy. It's more a connectivity
issue, I think.
> (Or going the other way; if you're making money running a node, I think
> it's pretty reasonable you'll try to serve on the order of 100k users
> -- much less than that and you'll be under utilising your hardware. But
> with only 8B potential customers, there's a limit on the number of nodes
> that can actually do that, as calculated above. I'm assuming economics
> somehow ends up enforcing that limit effectively)
>
>> which uses hosted wallets or something? I don't think that's very
>> interesting.
>
> Not hosted wallets; more along the lines of SPV clients, where you're
> relying on the network to do most of the work (in this case working out
> a cheap route, rather than verifying txns)?
But the "give me a cheap route" question is exactly the same whatever
your role. It's "give me all your routes to beacons". That's a few
hundred routes. If we're clever it's "give me changes since last time",
which is easy given that it's finite.
This has the advantage that you can't even tell if I'm routing or not.
Cheers,
Rusty.