Bitmessage: A decentralized and trustless P2P communications protocol | Hacker News Reader

Bitmessage: A decentralized and trustless P2P communications protocol

wiki.bitmessage.org

Played around with bitmessage for a bit and worked on an alternative for a bit. Here's some thoughts:

1. Like most gossip networks, it uses tcp. Since most consumer devices won't allow for incoming tcp connections, the end result is that most traffic gets routed through the small fraction of nodes on cloud servers. While this is true for most gossip networks, it is particularly problematic when you're using it bandwidth intensive applications (a twitter/parler alternative).

2. Using PoW for spam prevention is better than nothing, but the PoW algorithm is a simple sha256 hash. Sha256 ASICs will keep spam cost effective. Not sure if there's any solution. I think using some kind of crypto based incentive would be better economics, though of course have an increased user burden of acquiring crypto.

3. Bitmessage IMHO tries to be too many things with a message storage/rebroadcast protocol on top of a gossip network. All of these suffer from less than great documentation.

For 2, the system is just broken. There's no balance between a message that's acceptable in terms of time to be able to send for a user (say, 10 minutes of proof of work), that would reduce spam. If someone sends me a message every 10 minutes the service is unusable, but making the proof of work more expensive means it's unusable as well. This is why the original proof of work for email was broken as well.

Someone has to know your public key to send you a message in the first place.

Nah, they can be sniffed.

Regarding PoW: I think that there are two improvements that could be implemented.

1. Allow sending messages without PoW to friends. If you want to send a message to a stranger, you still need to do PoW. That should not happen often, so PoW bar could be higher.

2. Mobile clients probably won't be able to perform adequate PoW, so there should be an option to delegate PoW to some server for money. That's not a protocol issue, though.

2.1. May be instead of paying for PoW, it would be better to send money directly to the receiver. That would complicate the protocol, though.

HOw does this compare with Jami - https://jami.net/ ?

Re: point 1. The bittorrent protocol somehow manages to get around this problem. I wonder if that mechanism could be used here.

> Since most consumer devices won't allow for incoming tcp connections

I am curious why do you say that?

Bitmessage is a really cool project because it relies on PoW (proof-of-work) to send messages. Hence for spammers to flood the network would require lots of computing power. This means that the network should be full of healthy messages that should be human written. You don't need complex social trusted networks (like scuttlebutt does) to just enter the network and start relaying messages around - you trust they're not spam since there's PoW behind them.

However the PoW requirement when I last used this was quite low hence spam was somewhat still present. I'm also not sure how long a message is kept around the network: say I enter the network and send a message to Alice; how long will the message be kept alive in the network by peers so that Alice can still read it when she joins?

Edit: I guess my last concern is simply validated by the fact that the sender can just enter the network again and resend it. From paper:

>. If the sender of a message did not receive an acknowledgement and wishes to rebroadcast his message, he must update the time and recompute the proof‐of‐work.

I feel like a tinier, more constrained version of this would have worked better. E.g.,

* normalized 128 byte message content size

* defaults to sending all messages during a one-hour window each day

* no acks until next one-hour sending window

That's quite ascetic. But I think you get certain privacy properties that way which aren't otherwise possible. It would interesting to see if there are practical uses for those properties.

Edit: Oops, forgot:

* when the client is opened, fill a 128-byte buffer with random garbage. When the one-hour send window arrives, if no message has been set in the UI then send the garbage (and reset the buffer to new garbage).

Again, super crude but this PIR is a kind of brute-force approach anyway.

This reminds me of mixmaster/mixminion[1] networks

[1] https://github.com/mixminion/mixminion

Any examples of services that only allow a 1 hour daily window?

I haven't taken a look at the protocol itself, but I just want to comment on the foul and bitter taste the word "trustless" leaves in my mouth.

It could be the case that this protocol is the bee's knees, but seeing this makes me want to immediately write it off as bullshit. "Trustless" is not a thing that exists in real life, or rather, it only exists in the minds of people who fundamentally misunderstand "trust".

Not trying to troll here. Genuinely curious... Can you explain this take? From what I understand bitmessage is a p2p/decentralized protocol for e2e encrypted communication and is fully open source. What sort of 3rd party trust is required?

The short version would be this:

It takes a bastardized definition of "trust" to make this statement true, and it's a definition that is most often seen in the wild when used to "sell" blockchain stuff as having technical capabilities they do not, in fact, possess. It is a dishonest and misleading definition.

There are several mechanisms of trust that exist, authorities are just one of them. Reputation is another, so are proofs, and so is consensus (which is the most interesting one for the case at hand). Blockchains are essentially "Paxos, but for a massive peer count, and with some mechanisms that allow it to operate in an adversarial networks", but it is fundamentally still just a consensus algorithm (in Bitcoin's case, one where people "agree" that John Doe has X amount of money).

Shifting to P2P essentially just means that:

- You will trust a bunch of random people instead of a centralized authority;

- You will trust that these random people don't have enough "power" to subvert the protocol;

- In this context "power" refers to computational power in the case of PoW and Sybil Attacks, or access to backdoors;

- You will trust that the protocol is sound, as well as the implementation of it;

There's plenty of trust going around in there, claiming to "do away with trust" is dishonest at best, and fraudulent at worst. To add insult to injury: PoW based peer networks that haven't achieved significant scale can likely be trivially overtaken by an adversarial actors, and making a system P2P tends to open it up to all kinds of forensic network analysis.

---

For the long version of the argument I'd recommend this post from Bruce Schneier:

https://www.schneier.com/blog/archives/2019/02/blockchain_an...

> Most blockchain enthusiasts have a unnaturally narrow definition of trust. They’re fond of catchphrases like “in code we trust,” “in math we trust,” and “in crypto we trust.” This is trust as verification. But verification isn’t the same as trust.

> What blockchain does is shift some of the trust in people and institutions to trust in technology. You need to trust the cryptography, the protocols, the software, the computers and the network. And you need to trust them absolutely, because they’re often single points of failure.

Bitcoin is trustless. OK, “optimized to work in adversarial environment”. You have to trust their encryption, but that’s it (nobody managed to hack the encryption yet, despite immense gains to be obtained immediately).

Of course, you have to manage your keys properly, but that’s not about trust, that’s about skills and precautions.

Ah yes, the system that until very recently ran eval() on every incoming text message. Super trustworthy.

First thing a read was the red message about the remote code execution, didn't really increase my trust either.

Reply on news.ycombinator.com