Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2015-09-23 📝 Original message: On Wed, Sep 23, 2015 at ...
📅 Original date posted:2015-09-23
📝 Original message:
On Wed, Sep 23, 2015 at 12:12:57PM +0930, Rusty Russell wrote:
> Anthony Towns <aj at erisian.com.au> writes:
> > On Mon, Sep 21, 2015 at 11:46:13AM +0930, Rusty Russell wrote:
> >> We regularly choose a dozen "beacon" nodes at random (using proximity to
> >> the SHA of latest block hash or something). Everyone propagates the
> >> cheapest route to & from those nodes (which is pretty efficient, similar
> >> to your scheme).
> > I think what you're implicitly assuming here is:
> > a) global p2p network of lightning nodes; at a minimum each node has
> > a connection to every node it has a channel open with
> > b) consensus protocol for choosing an ordering of potential beacons
> > c) potential beacons have to have committed to a beacon id prior to
> > ordering being chosen (with spam/flooding protection)
> > d) gossip protocol to announce potential beacons and compare against
> > ordering, keeping the top few in memory.
> > e) sharing routes to beacons with direct neighbours
> > f) distributed hash to store/lookup route recommendations, keyed by
> > beacon/endpoint
So this one's incorrect. I think instead you're assuming:
f) when asking for a payment to be made to you, you provide your
lightning public key, and a set of low-cost paths from the current
beacons to you. (ie, your "address" for payments includes full
routing and fee info)
> > g) distributed hash to lookup fees for hops keyed by hop ends
When fees change, which path to a beacon is low cost will often change
too, so this really doesn't do you any good.
> > 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)
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.
> >> 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.
> >> 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).
If other nodes can "force" you to be a beacon, I think that causes
problems anyway (maybe you just don't have the bandwidth to deal with
a high transaction volume), so I think the "volunteering" step is needed.
> 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).
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.
With beacons, Mallory could somewhat plausibly gain control of the beacons
Bob is advertising, and then block any payments with those published
R values from going through. This could happen by subpoena or national
security letter rather than buffer overflow too.
> > Hmm. Counterproposal: no beacons or routing DHT, just fees by gossip
> > protocol (or IRC channel as prototype hack). Everyone has a complete
> > (but possibly slightly out of date) database of node-node (but not
> > node-wallet) channel fees, and changes are propogated by gossip. Back
> > of the envelope maths:
> >
> > everyone uses lightning ==> 8B wallets (5B teens/adults, 3B businesses)
> > every wallet has ~4 channels ==> 32B node-wallet channels
> > 100k wallet channels per node on average ==> 320k nodes
> Um, so each wallet isn't a node?
Err, yeah; I've been using those terms mutually exclusively, ie "you're
running a full node, or you're just a wallet, you're never both":
13:47 <rusty> kanzure: Aside: Joseph has been avoiding the term hub in
favour of simply "nodes". I've been following suit, since I
think it directs thinking in the right non-centralized direction.
13:47 <kanzure> but hub is more fun to pronounce
13:47 <kanzure> bah fine i'll use node then
13:48 <rusty> kanzure: Me too. I have a bub, he likes to say hub.
But I'll just have to teach him....
13:48 <aj> rusty: i feel like "just spending/receiving money with as
little thought/effort as possible" and "being an active
participant" needs different words... leaf node and node
don't really work for me
13:48 <kanzure> "wallet"
13:49 <aj> wallets and nodes? hmm
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.
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/
> 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?
(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)?
Does that make it more interesting?
Cheers,
aj
📝 Original message:
On Wed, Sep 23, 2015 at 12:12:57PM +0930, Rusty Russell wrote:
> Anthony Towns <aj at erisian.com.au> writes:
> > On Mon, Sep 21, 2015 at 11:46:13AM +0930, Rusty Russell wrote:
> >> We regularly choose a dozen "beacon" nodes at random (using proximity to
> >> the SHA of latest block hash or something). Everyone propagates the
> >> cheapest route to & from those nodes (which is pretty efficient, similar
> >> to your scheme).
> > I think what you're implicitly assuming here is:
> > a) global p2p network of lightning nodes; at a minimum each node has
> > a connection to every node it has a channel open with
> > b) consensus protocol for choosing an ordering of potential beacons
> > c) potential beacons have to have committed to a beacon id prior to
> > ordering being chosen (with spam/flooding protection)
> > d) gossip protocol to announce potential beacons and compare against
> > ordering, keeping the top few in memory.
> > e) sharing routes to beacons with direct neighbours
> > f) distributed hash to store/lookup route recommendations, keyed by
> > beacon/endpoint
So this one's incorrect. I think instead you're assuming:
f) when asking for a payment to be made to you, you provide your
lightning public key, and a set of low-cost paths from the current
beacons to you. (ie, your "address" for payments includes full
routing and fee info)
> > g) distributed hash to lookup fees for hops keyed by hop ends
When fees change, which path to a beacon is low cost will often change
too, so this really doesn't do you any good.
> > 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)
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.
> >> 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.
> >> 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).
If other nodes can "force" you to be a beacon, I think that causes
problems anyway (maybe you just don't have the bandwidth to deal with
a high transaction volume), so I think the "volunteering" step is needed.
> 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).
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.
With beacons, Mallory could somewhat plausibly gain control of the beacons
Bob is advertising, and then block any payments with those published
R values from going through. This could happen by subpoena or national
security letter rather than buffer overflow too.
> > Hmm. Counterproposal: no beacons or routing DHT, just fees by gossip
> > protocol (or IRC channel as prototype hack). Everyone has a complete
> > (but possibly slightly out of date) database of node-node (but not
> > node-wallet) channel fees, and changes are propogated by gossip. Back
> > of the envelope maths:
> >
> > everyone uses lightning ==> 8B wallets (5B teens/adults, 3B businesses)
> > every wallet has ~4 channels ==> 32B node-wallet channels
> > 100k wallet channels per node on average ==> 320k nodes
> Um, so each wallet isn't a node?
Err, yeah; I've been using those terms mutually exclusively, ie "you're
running a full node, or you're just a wallet, you're never both":
13:47 <rusty> kanzure: Aside: Joseph has been avoiding the term hub in
favour of simply "nodes". I've been following suit, since I
think it directs thinking in the right non-centralized direction.
13:47 <kanzure> but hub is more fun to pronounce
13:47 <kanzure> bah fine i'll use node then
13:48 <rusty> kanzure: Me too. I have a bub, he likes to say hub.
But I'll just have to teach him....
13:48 <aj> rusty: i feel like "just spending/receiving money with as
little thought/effort as possible" and "being an active
participant" needs different words... leaf node and node
don't really work for me
13:48 <kanzure> "wallet"
13:49 <aj> wallets and nodes? hmm
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.
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/
> 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?
(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)?
Does that make it more interesting?
Cheers,
aj