[HN Gopher] Bitmessage: A decentralized and trustless P2P commun...
___________________________________________________________________
Bitmessage: A decentralized and trustless P2P communications
protocol
Author : generalizations
Score : 61 points
Date : 2021-01-11 16:44 UTC (5 hours ago)
(HTM) web link (wiki.bitmessage.org)
(TXT) w3m dump (wiki.bitmessage.org)
| sktrdie wrote:
| 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.
| jancsika wrote:
| 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.
| snissn wrote:
| Any examples of services that only allow a 1 hour daily window?
| magicconch wrote:
| This reminds me of mixmaster/mixminion[1] networks
|
| [1] https://github.com/mixminion/mixminion
| luizfelberti wrote:
| 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".
| rdbell wrote:
| 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?
| luizfelberti wrote:
| 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;
|
| 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.
| atemerev wrote:
| 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.
| aakilfernandes wrote:
| 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.
| vbezhenar wrote:
| 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.
| RL_Quine wrote:
| 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.
| lostmsu wrote:
| > Since most consumer devices won't allow for incoming tcp
| connections
|
| I am curious why do you say that?
| webmobdev wrote:
| HOw does this compare with Jami - https://jami.net/ ?
| generalizations wrote:
| Re: point 1. The bittorrent protocol somehow manages to get
| around this problem. I wonder if that mechanism could be used
| here.
| RL_Quine wrote:
| Ah yes, the system that until very recently ran eval() on every
| incoming text message. Super trustworthy.
| worstenbrood wrote:
| First thing a read was the red message about the remote code
| execution, didn't really increase my trust either.
___________________________________________________________________
(page generated 2021-01-11 22:02 UTC)