 |
November 29, 2012, 02:49:07 PM |
|
This is great. Thanks for taking it on. I'm very much encouraged by the professionalism of the paper and the website. I'll try the app out later.
Based on reading the paper I have a few comments. I don't know if the design is set in stone by now or if you're still open to modifications.
The streams construction is very clever and I think it could work well. One question is what if I have an old and widely propagated address in a root stream, and eventually it gets overloaded? Some people have to move. But nobody wants to give up their old and well known address.
For thin client nodes, they can't tune into the torrent of all messages (they may be on mobiles). You could consider a Bloom filter construction for them as we are doing for Bitcoin, so nodes can express interest in some probabilistic subset of all messages. Because Bloom filters can be merged, nodes could merge together the filters set by connected clients and provide the superset of them to other connected nodes. As you get closer to the "core" of the network all bits would be set and it'd revert to pure broadcast, but this construction also allows nodes to adapt how much traffic they receive according to how much instantaneous bandwidth they have available (eg, if run on an end user computer they can throttle back their relaying whilst the user is streaming a movie by adjusting the filter FP rate).
Spammers routinely use hacked computers to send spam, so they aren't using their own CPU to calculate PoWs. This doesn't affect Bitcoin much because PoW calculations don't have to be done by users of the network, so specialized equipment can be used to outrun botnets, but in a PoW-to-play scheme you can't rely on users having much CPU. This is especially true if you want to support mobile users, which you do. As you note, your other mitigations are thwarted by crawlers that look for addresses, which is one of the most common ways to gather email addresses today. So I find the anti-spam provisions unconvincing. The magic 2 day storage window is also questionable, many users don't check their mail every two days.
An alternative approach is to link Bitmessage and Bitcoin together. A few approaches present themselves. Nodes on the Bitmessage network, which would hopefully stick around for the long term, could establish micropayment channels between each other. Micropayment channels aren't operational today because we need to re-enable transaction replacement in the main Bitcoin network, but you could certainly experiment with this approach on the testnet. To send a message then, you establish some connections to long-lived peers, send a few millicents to to each node and then submit your message. Nodes relay some of the money you sent along their broadcast paths until eventually it's exhausted. In this way, nodes are incentivized to be online all the time (and possibly store the messages for longer), and message propagation eventually stops due to either flooding the network completely or (in a very large network) exhausting the micropayments.
This means legitimate users can outbid spammers who are flooding the network. Given messages arriving from many nodes and a limited broadcast/storage capacity, nodes would prioritize messages for broadcast by the amount of money provided, and the money would ripple through the network further incentivizing nodes to prioritize the legit messages above those of the spammers.
Bitcoin and PoWs are complementary - you could allow Bitmessage-specific PoWs to start with as a way to bootstrap the network in the early days and simplify on-boarding of new users, but also support Bitcoin micropayment channels in parallel so if/when spammers arrive that have lots of CPU users can smoothly migrate to the other solution.
One issue with this is bogus nodes that accept money but then don't relay or store the messages. Without introducing some notion of node reputation and prefering long term nodes, I don't see a good way to solve that right now. An idea is to abandon IP for this project and build the entire P2P network on top of Tor hidden services. This means that a node can maintain a persistent, long term identity even if the underlying IP addresses change, brand new nodes could be tested by their peers to ensure they're actually performing the services they claim they will, and the amount of traffic (and thus money) trusted to them gradually ramped up.
|
