https://twitter.com/kanzure/status/784783992478466049

You have a network. Anyone can join the network. You have two points and you want to do route finding between those two points. To be clear, this is a network of channels. It is similar to the internet, but it is not the internet. How do you find such a route? It's easy when you find all the implements of the network. Some of the information changes frequently. Payments change the balance of the channels so that other payments become impossible. There's scalability issues there. And there is a privacy issue as well. You tell information about how many payments, how much expense you have, this is undesirable in some circumstances. Another thing is that it shows who you are connected to, which might not be desirable to show in some situations. If there are two nodes in the network and one node says I hate hte other node and you must not make that connection... so then other nodes have to make a decision, and then if you want to make a connection between two parts of the network, then you might have to hide one connection from the other network.

We may end up with levels of publishing of routes. In some cases, don't publish the route. There's a local and global publication. Nobody knows what you know, and such. Your peers already know. There would presumably be some publication method to show hey this is the routing information. Your comment that this doesn't scale-- the first million channels scales okay. A hundred megabytes is fine. A hundred bytes is fine. If you have an ID associated with each node, and some transaction associated with it, if you want to prove that then you need SPV proofs and it's even bigger. If you run a full node, it's never bigger than the UTXO set size. So for the short to medium term, at least global knowledge of the static route is possible. But then there are dynamic questions, as you said. I prefer the idea that-- if you are two precise with your broadcast, you're linking a lot of information. You could use the fee to communicate information. Some people think that fees will not change. I think fees will change all the time. You could have a rate limit on fee changes. So in this case it would be more of a "consensus" rule for fees. So then you would rate limit the number of fee changes -- which might limit incentives to improve lightning-related hardware.

You could have natural background radiation where you are continuously testing your routes with different amounts. But this is worse scalability. And you need a fee to ask the other channels what their fees are-- well it would be better if people commit to fees. If you are continuuously bumping up against one side, you're probably screwing up somewhere. You have the global capacity, the static information. You start exponentially punishing that route. If I'm going to try to use a path channel, I might know the success rate is low-- so those heuristics mean you have small payments flowing through and the network should stay reasonably balanced. They might try to do hyper-aggressive fee adjustments.

You would use the block count as a timer. Yes. Changing it 10 times per block. But I'm talking about formalizing the problem. There's another problem here which is that someone is false advertising-- and then they fail all the transactions. Ideally the failure message should be usable as a valid broadcast. If their replies are required to be a valid thing, you could broadcast that and lose some privacy there. Since that has to be unique, so it has to be a block number, a counter, you cannot have two that conflicts. This would prove that they were lying. If they are lying, then you eliminate them from the route map. It's how they claim they are using one fee, and then they try to take another, or try to pick another. When they fail a payment, they should have to reply with a reason. That reason is either the fee rate has changed, or it has gone up, or they have taken your money, and you should be able to prove this to the rest of the network. Nobody can corrupt that.

What about a fixed fee structure? Just over pay with fees. Bootstrap the network. Pay for the potential closure. Pick a really high number. Problem solved for now. Should you be able to advertise the minimum fee? And should that be policy of a local node's routing information? If you have a minimum, then it has to be placed in the routing information. You don't want to create a perverse incentive where you--- say J sends through a route 300 outstanding, none of which actually comes out, and he just takes the money. You never know, you never know. Exactly. So you don't want it to be too preserve. Some sane...

I wonder if there's some fundamental trust in the routing system like you can make the fact that nobody steals from you, you can make that trust free. But the fact that you can make a route, that cannot be made trust-free. When a specific route is advertised, that advertisement cannot be a proof. And there's valid reasons that things might change. That's why a failure message must be something you can broadcast on the network provably. If the conditions have changed, then you show the new fee update, that's fine. You don't want that to be able to just say -- information collect, free channels everywhere and the NSA says thank you very much. On lightning, maybe the fee thing will be punted because someone will offer lots of liquidity. C D thinks that fees won't ever change.

You can imagine two routes, one that drops fees and so as a result I drop my fees. If you rate limit it, then someone gets the last word. In a well-designed network, you get that so that it's not possible-- you could get where people have t... you don't want to encourage fee sniping. If you want to change a lot, then just set a high fee and be done with it. No reason to have a high rate of change of fee.

... you are probing for their balance. Say you make a 0.1234 payment, and Pablo wants to figure it out... so you... and now it's different from last time, and your... and you fail it because it's free. By succeeding with routing, you're effecting your balance. You did it beforehand, you did it again, and you saw a capacity change. You know that probabilistically the candidate routes are whatever. Another possibility is to offer a balance range. Just offer 4 bits or something. And whether that number is a fee or a balance and you derive a fee from that, I don't know. It's a question of do you want the client to figure out the fee in order to pay. If not, it could be a feature. Overpay is super sane. Anyone trying to send 10% of a channel thorugh a channel, has dramatically higher chance of failure. Myabe they just don't care.

If you only have one channel, then you're sort of-- if it's you, not an intermediary, you can sort of say hey I'm making this HTLC. It's only the ones that aren't your channel that you have to worry about. If they have one dollar in each of their chanels, they are probably trying to ... don't try to send 10 cents, send 1 cent. I don't think we will see many one dollar channels. I think we will see a few dozen maybe. Your fees are too high anyway right now. I think there are many people who live who have their finances sorted out so that in the beginning of the month they get salary, and then they spend the salary. So the capacity is the same as get spent during the month.

Advertizing capacity is possible, but you have to be careful. Maybe 4 bits for capacity or something, with some fuzz so you can't systematically figure this out. What you care about is are you close to the edge, because if you are then you're high risk. Just based on fees, if oyu're close to the edge then your fees increase. Maybe some sort of rounded balance, not actually the exact number. The transmission point is somewhere less than a few seconds.

For peer selection, you should pick a random subset of peers, some that are closest in time, and some that are random, and that's your peer neighborhood. So you have a connection to something close; you have a connection to your merchants in your neighborhood, and your employer, and then some random choices.

For users, you use global knowledge of routes. Your client automatically connects. That's how this works for users right now. Our RPC is two commands: getroute, whih requires a risk factor and an amount to send. The risk factor is the probability that the node goes down and how much your money is worth per time. So it's basically an interest rate. Non-source routing has privacy implications. You don't have to share... what your channels are about. You only have to share aggregate information.

Where is the implementation of hornet? Well it's a private implementation. It's been 2 years since the lightning network paper came out. So what can we cut out? So that's why hornet is exciting. We already have sphinx and stuff, let's do this now. I think that's a lot of it. If we had something like hornet already working, we could just use it. You could run the data through hornet -- as a separate daemon. Hornet is specced out by roasbeef; maybe done by next year. 2/3rds done maybe on a custom implementation.

No preferential attachment in such a graph. Stars are probably the most unlikely case for such a graph. It has really nice bootstrapping properties, because you just sample the nodes around and then randomly select them, and take no locality information into consideration. Also has the smallest information leak; we all know it's random. So we don't try to infer anything by it. Would a random graph be something to aim for?