Mats Jerratsch [ARCHIVE] on Nostr: 📅 Original date posted:2015-09-21 📝 Original message: > On Mon, Sep 21, 2015 at ...

📅 Original date posted:2015-09-21
📝 Original message:
> 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 don't know, using the beacon kind of technique does seem a little
bit cumbersome and you really have to think about a lot of possible
attacks that might render the whole network unusable, because all
beacons are maliciously sabotaging the network..


> If you do know the entire graph, you don't need to give away any
> information about who you want to pay prior to sending the transaction.
> Knowing the graph is potentially interesting for commercial and academic
> reasons beyond wanting privacy. (Knowing the fees others charge helps you
> work out what fees you should charge; but just querying your neighbours'
> routes is probably sufficient to work that out too)

I initially thought about going with a Node Directory. That is, a
central server collecting the routing data that could be sent there by
choice. We can work out with signature and if both nodes submit the
route towards the other node, whether this is indeed correct. But as
this isn't too much data in the first place, I am very much in favour
of just using some gossip-protocol. Furthermore, we can also include
some byte for a reputation / web-of-trust system. It is completely
optional, if you are able to figure out how to route the payment
across your nodes you are not forced to use this system, and I don't
think it will have severe privacy problems.

Payer and payee can further work out a rendezvous node. The payee will
send the encrypted routing data from that node on to himself and the
payer can build the rest of the routing from his viewpoint.

Having this data distributed really allows for making payments without
leaving too many visible traces on the network.

I would also spread data about how much can be spent and received with
this route and fees for receiving and spending. Again, this data can
be very vague and does not need to reflect the real world. You can say
you support payments up to 10k satoshis, even though the channel has
5BTC in it.

Is there any plan how we handle connections currently? I am thinking
about sending the current IP address with this update, such that nodes
can connect to each other after one broke down again, and it would
further support dynamic IPs as well. Could be possible to extend this
to hidden service notation, although this would need some more bytes
to store.

The protocol on my side does look like this currently:

General beacon for our node
- pubkey [32]
- timestamp [4]
- IP/connectionDetails [8+...]
- signature [70]

Routing information
- pubkey_from_us [32]
- pubkey_from_you [32]
- fee_sending [4]
- max_sending [4]
- current_reputation [1]
- timestamp [4]
- signature [70]

These two would be spread as one message.
This allows to keep two separate databases, and be able to bootstrap
new nodes with this information, while we do not have to store old
beacon data.
As reputation will be stored for quite some time, we should really
save them with separate signatures. (This will make it more difficult
/ costly to share the complete database with new nodes, and we need to
store old data (reputation should be stored for some time) to validate
the signatures.

I was calculating with two updates a day, but only 100k nodes. Each
node would make a connection to around 10 other nodes, resulting in
114+10*147 = 1.5kB per update. Each node would only use around 3kb/s
up/down and would do around 3 signature verifications per second in
idle mode, while allowing everyone a full copy of the routing. Making
sure messages spread efficiently is another problem, as we have so
many tiny messages. Storing the hashes you received in a bloom table
and asking other peers if they want to receive it as well does work,
but just the hashes of all messages do add up already..

In the end, the nodes themselves don't really need the routing
information, we just need a way to transport the information to the
clients that make payments. Nodes will just stupidly obey the orders
given in the blob of data they'll receive.

This design opens up for some DDoS attacks, as we don't want other
nodes to just spam information all day long that would be relayed
through the complete network. Furthermore, one attacker can just
emulate a complete network that is vouching for him, and he can use
those 'nodes' to push spam through the network as well. This does
screw a little bit with the reputation system, but I think it would be
possible to detect a cluster of nodes that is only connected to the
rest of the network through that one attacker (some graph theory I
guess). Furthermore, we can check nodes by pinging them randomly, and
dropping any reputation if we cannot reach them.

Mats Jerratsch