Mar 9 00:29
I am building a bitmessage replacement. What features would you like to see? Feel free to ask questions.
Mar 9 00:58
Mar 9 02:29
I am not against doing that, and I have looked into doing it. But the changes are quite fundamental and would break backwards compatability a lot. Here are some of the things already in the development queue/completed: - Use the updated SHA3 hashes instead of he current ones used by bitmessage. - Scability. Yes, an actual scalability mechanism. Would make mobile clients an option - Message mixing, onion routing,perfect-forward-secrecy and padding to further the anonymity of senders and receivers. - Message prioritization, ensure your message is propogated even when the network is stressed - Remove PoW precompute, PoW can only be performed near when the message is to be sent. - Easier development for developers. The code is modular and more intuitive. I am not bashing bitmessage at all here. There are a lot of things learned from this project.
Mar 9 02:30
Why not contribute to bitmessage
Mar 9 02:30
Feedback is welcome.
Mar 9 04:47
Mar 9 05:12
<img src="data:..."/> we don't need one (yet)
Mar 9 05:14
How about making a bitmessage smartphone app? I reckon a whatsapp-like decentralised app would be quite appealling.
Mar 9 05:41
Why don't we need one? I believe it solves many of the problems with bitmessage. One of which is usability, the number of bitmessage users has really dropped off and I believe that is in large part due to the usability.
Mar 9 05:42
This would allow for a smartphone app client. While it would work, it really takes away from the security and anonymity being on a mobile phone. but, I think the more people I can get using it, the better it is for people with high-security needs.
Mar 9 06:16
What about the Bitmessage Abit app on Google Play? http://bit.ly/2mIL0tN
Mar 9 06:20
No doubt that it is a great app. But, it is limited since bitmessage requires your phone to receive everything unless you setup a trusted node. Mine allows you to do that if you like, but you can also narrow down the amount of messages you have to receive and process.
Mar 9 10:03
I am not bashing bitmessage. But the updated hashes instead of things already in the updated hashes instead of things already in the anonymity of the changes are quite fundamental and would break backwards compatability a lot of the changes are a lot; of the development queue Use the changes are quite fundamental and I am not against doing that, and I am not against doing that, and receivers. Message mixing, onion routing (perfect forward secrecy and padding to further the changes are a lot: of he current ones used by bitmessage at I am not against doing that and I am not against doing that and I am not against doing that and padding to be performed near when the Message mixing onion routing perfect forward secrecy and I am not against doing that and would break backwards compatability a lot of the development queue Use the changes message mixing onion routing perfect forward secrecy and would break backwards compatability a lot: of the changes are quite fundamental and receivers). But the anonymity of the message mixing, onion routing, perfect forward secrecy and I am not bashing bitmessage I am not against doing that, and would break backwards compatability a lot: of the updated hashes instead of things already in the changes are quite fundamental and would break backwards compatability a quite fundamental and I am not bashing bitmessage I am not against doing that, and padding to bitmessage: at all here: are quite fundamental and I am not against doing that, and I am not bashing bitmessage I am not bashing bitmessage lot of the anonymity of he current ones used by bitmessage I am not bashing bitmessage at all here. Here are quite fundamental and would make mobile clients an actual scalability mechanism: at all here. Scability. But the changes are quite fundamental and padding to further the changes are quite fundamental and padding to be see? I am not against doing that, and padding I am not bashing bitmessage at all here are quite fundamental and padding to further the changes are quite fundamental and I am not against doing that, and I am not against doing that, and would make mobile clients an actual scalability mechanism. Message prioritization, ensure your message mixing, onion routing, perfect forward secrecy and padding to be performed near when the changes are a lot of he current ones used by bitmessage at all here are quite fundamental and I am not against doing that, and I am not bashing bitmessage at all here. Here are quite fundamental and receivers: would break backwards compatability a lot.
Mar 9 10:42
Hello, > I am not against doing that, and I have looked into doing it. But > the changes are quite fundamental and would break backwards > compatability a lot. Bitmessage has changed already several times, both the wire protocol and objects have versioning and can be upgraded. > Here are some of the things already in the development > queue/completed: > - Use the updated SHA3 hashes instead of he current ones used by > bitmessage. Bitmessage is currently moving its object hashing algorithm from SHA1 to SHA256. > - Scability. Yes, an actual scalability mechanism. Would make mobile > clients an option See here for what I call "simple recipient verification": https://github.com/Bitmessage/PyBitmessage/pull/808#issuecomment-170189856 > - Message mixing, onion routing,perfect-forward-secrecy and padding > to further the anonymity of senders and receivers. Bitmessage onion routing is described in the whitepaper but I don't think anyone implemented it do the extent that it is practically usable. Regarding forward secrecy, see here: https://www.reddit.com/r/bitmessage/comments/3zzevp/forward_secrecy_for_bitmessage/ > - Message prioritization, ensure your message is propogated even > when the network is stressed This sounds like the Whisper protocol. Yes, that's interesting and can be added to Bitmessage but I have no specific plans at the moment. > - Remove PoW precompute, PoW can only be performed near when the > message is to be sent. I'm not sure I understand what you mean and why. If you're online, the difference is going to be a couple of seconds, and it introduces synchronicity into the outbound queue which is not good for anonymity. And for Bitmessage I plan to add delegated proof of work, where a node can compute PoW for messages from another node which it trusts. > - Easier development for developers. The code is modular and more > intuitive. Yes, bitmessage could also use something like this. > I am not bashing bitmessage at all here. There are a lot of things > learned from this project. Sure. Peter Surda Bitmessage core developer
Mar 9 10:49
I was thinking about adding another UI written with kivy, which would allow the same core code be usable on Android and IOs. But I don't have time for it now, maybe if I raise money and can pay someone to do it. Peter Surda Bitmessage core developer
Mar 9 11:24
Mar 9 12:22
Peter, could you please move to SHA-3 - keccak 512? And use untruncated full output? See Vault7. Actually, why not Keccak 512 bit, concatenated with SHA-2 SHA256. We don't run BM on Commodore-64, we can handle this. Please. Otherwise it will be a problem once more in a dacade, why not sovle it already for next time when SHA256 finally gets broken one day.
Mar 9 13:05
>What features would you like to see? ⧫ Reference implementation written in Java or Erlang ⧫ Enterprise level documentation with Javadoc or doxygen ⧫ Client interface mimicking https://en.wikipedia.org/wiki/GoldED ⧫ Antiflood and antispam for chan while still fully anonymous ⧫ Meshnet integration to work without the Internet at all ⧫ Meidos ⧫ Cocaine ⧫ Smilies/stickers ⧫ DOS version ⧫ Free money ⧫ Cool logo ⧫ Multiplayer games over it ⧫ Send message to printer function ⧫ etc.
Mar 9 15:33
I'm not a cryptographer so I don't think I should be making this decision, or at least not without consulting others. The move to SHA256 was already started 2 years ago by Atheros, I'm just reprioritising it now due to the news. Peter Surda Bitmessage core developer
Mar 9 18:47
"Abit" for testing in the android checked? https://dissem.ch/
Mar 9 19:02
I know about it and I also recommend it to people who ask but I haven't tried it myself. I personally don't like coding in java and am hoping to have a mobile client without it. Preferably I would like the same code base for both android and ios. If I can reuse the PyBitmessage core as well, that would be even better. Maybe there can be a C library for the core that can be reused on all platforms, and then a bunch of UIs for different platforms. Peter Surda Bitmessage core developer
Mar 9 20:10
Then we wait Ubuntu phone mass market.
Mar 9 21:52
Give me more details about your replacement (platform/security features?)
Mar 9 22:20
It's not like I had time to write an entirely new implementation of Bitmessage anyway. I find it more likely that I manage to raise money and pay someone to write the mobile client / UI. Peter Surda Bitmessage core developer
Mar 10 08:45
"Maybe there can be a C library for the core that can be reused on all platforms" yeah, and cause exploits on all platforms. Do it in python. Change GUI for android.
Mar 10 08:49
as long as it's not using some highly specific stuff and if possible running in python2, i'm as well all for keeping the core in python, feeling there is less risk of buffer overflow bugs and similar, than if it's in C
Mar 10 09:52
I tried Abit. pow is very slow. ux need improvements very long pubK exchange, problems with acknowledgements. needs a twitter like interface. btw, Peter, are you alone working on the reference implementation?
Mar 10 16:28
You absolutely should NOT do anything besides sha256. Keccak, blake, etc. are all neat and novel, but they have NOT been around for long enough to withstand adversarial scrutiny for decades on-end like sha256 has. sha256 is by a wide margin the safest current hashing algorithm and is absolutely what you should be using. There's a $10 billion bug bounty for it in the fact that it's Bitcoin's proof of work, and it still hasn't been weakened in any significant manner. In cryptography, tried and true is way better than new and novel. I'm sure sha3 is great, but I'll be more sure 20 years from now when it hasn't been found to have weaknesses, even in the face of being the backbone of some multi-billion dollar industry.
Mar 10 16:31
BM should be implemented in freepascal - the best programming language for serious work
Mar 10 19:18
Mar 10 23:21
I'm worried about python performance, however, it's possible that the reason why Pybitmessage is sometimes slow is bad coding decisions and python's GIL, and moving to C wouldn't help much (other than getting rid of the GIL). I'll see how it improves with the new network interface, and possibly some threads can be refactored as multiprocessing, allowing more cores active at the same time. If that works well enough then I won't spend time on C personally, but I may still pay someone to do it, because I think a C library is beneficial for compatibility even if not for performance. Then there's a question about the performance difference on mobile devices, it may be worse there. Peter Surda Bitmessage core developer
Mar 11 02:19
so was everything at some point. What's wrong with sha3?
Mar 11 02:20
What's wrong with: whirlpool, ripemd320, tiger192? They're all proven and cryptographically secure.
Mar 11 18:29
Are you running that? Can you explain how to use the "trused" server? Is that a special server or just a bitmessage installation?
Mar 11 18:30
Are you running that? Can you explain how to use the "trused" server? Is that a special server or just a bitmessage installation?
Mar 12 04:35
Many people will balk at this out of ignorance. Yet freepascal is the most maintainable language, easy to read, and compiles to machine code that is just as fast as anything C compilers can crank out. I am developing some apps in freepascal that might turn into a cryptographic communications suite. If I can keep the steam.
Mar 12 04:36
Mar 12 04:42
> What's wrong with sha3? There was sha0, sha1, and sha2. Now shit3. NIST approved, u fukkin' kiddin'? When sha3 is broke, there will be sha4, then shit5. Serpent, whirlpool, ripemd, tiger, and a few others are not more popular because they popularized the back-doored algorithms.
Mar 12 21:44
You do realize that they get replaced due to advancements in technology, right? everything is going to get broken one day, including the less governmenty ones. You would have more reason to be concerned if this DIDN'T happen, that'd indicate that something was even MORE wrong.
Mar 13 06:59
So here are some more details for those of you that are interested There are two types of addresses. Symmetrical and asymmetrical. Symmetrical use the same for signing and encryption, asymmetrical use a different signing key from the encryption key. Identity addresses are the same as in bitmessage now essentially. These identity addresses are symmetrical, and share the same key for encryption and signing. One-Time-Use addressses are new. You will create an asymmetrical address, using your identity key as the signing key, and a new, one time key, as the encryption key. These keys will be unique for each private conversation you have. This provides perfect forward secrecy. If any of these messages are intercepted/decrypted/read, they will not allow the attacker to read any previous messages or any future messages. So identity addresses are really just for starting pm chains and for signing messages on mailing lists and chans. or for non-perfect-forward-secrecy messaging. Chans will still be chans. Everyone will create addresses with a common string as the seed to the key. they will be symetrical addresses just like they are today. Identity-chans are new. They are a chan where someones address is used as the seed to the address. There is nothing to stop people using these like chans today technically, but the default clients will not allow you to join the chan that is an address and as a user, your identity chans will not be used for receiving anything so nothing will be read from there. Identity chans will be used for publishing pubkeys and also for posting messages as a mailing list/broadcast address. So no pubkeys will be published on the network directly. you will have to know someones address to get their pubkey, which makes sense. Users can optionally not publish their pubkey, which would require them to do so other ways (out of band, by initiating the message sending, etc). So to recap. Identity chans are for publishing pubkeys and mailing lists/broadcasts only. Going out on the network, there will only be two payload types. Regular payloads for private messages/chans/mailing lists/broadcasts all of which look the same, and network-peer payloads for publishing peer ip's and ports to connect to. By making all non-peer-advertisement payloads look the same, it helps hide and mask what is going on with the network. More details coming soon. Thanks for reading and I look forward to your thoughts, .dok
Mar 13 08:11
So here are some more details for those of you that are interested These messages are a different signing key; for those of you that are new, one time use the a new, one time use the address and for signing and chans are identity addresses are some More details for posting messages more details for each private each private conversation you to will be chans will not be unique for each private conversation you have. One Time use a different signing; and signing and for share the same for those of you will be used for signing and as a different bitmessage now essentially. They are new, one time Use the key asymmetrical Use the key: from There are symmetrical, and for posting messages as the encryption and encryption, asymmetrical encryption and for posting messages are some More details for signing and also for signing and also for publishing pubkeys and chans for those of you that to the seed to see? Or for those signing and a chan that are new. Thanks for receiving anything so here are new; one Time use a bitmessage now essentially. There are new, one Time use the encryption asymmetrical Use a chan that are really just for signing key, as a new; one time Use the seed address, using these messages as the key for starting signing and for encryption and for receiving anything So here are a mailing lists and asymmetrical use the same for those posting messages are symmetrical, and a different signing and a different signing key. Identity addresses just for non perfect forward secrecy messaging: an asymmetrical Use the same key, for private each private conversation you to the same key; for posting messages are intercepted so here are really just for non perfect forward secrecy: messaging: share the encryption and share the address using and using these messages are symmetrical, really just for those of you to the key; for signing. Identity addresses are new. Or for signing and share the same for encryption, key. Chans are new: one Time Use the encryption asymmetrical Use a bitmessage now essentially: anything so here are interested there will not be used for signing. Thanks for reading and I look forward to your thoughts, .dok
Mar 13 08:20
This is starting to get industrial grade, mate. I like the direction.
Mar 13 17:02
> You would have more reason to be concerned if this DIDN'T happen, that'd indicate that something was even MORE wrong. That is bad logic. All it takes is one person on the inside to spill the beans, and the whole charade is over. Absense of evidence is indeed in this case evidence of absense. It's not proof of course, but it is absolutely correct to say that not hearing about any vulnerabilities is a very good thing. And it is absolutely wrong and a logical fallacy to claim the opposite.
Mar 13 19:37
> One-Time-Use addressses are new. You will create an asymmetrical > address, using your identity key as the signing key, and a new, one > time key, as the encryption key. These keys will be unique for each > private conversation you have. This provides perfect forward > secrecy. If any of these messages are intercepted/decrypted/read, > they will not allow the attacker to read any previous messages or > any future messages. So kind of like the FS proposal for Bitmessage: https://www.reddit.com/r/bitmessage/comments/3zzevp/forward_secrecy_for_bitmessage/ Peter Surda Bitmessage core developer
Mar 14 05:24
Basically, yes. I am sure most of what I will be implementing has been mentioned somewhere before. That is my effort, to take the good ideas and make them real.
Mar 14 05:49
> Future transport modules could be TOR, I2P, IPFS, bluetooth, dropbox, btsync, qrcode, bittorrent, etc. Anything you can think of for exchanging payloads. gnutella, emule, dc++ could be in the mix. also a way to exchange known node tables through many bands so a dedicated bootstrap server is not vital to connecting.
Mar 14 05:57
Yep. Each transport module would be responsible for it's own "known nodes" list and distribution. I am against a dedicated bootstrap, so the distribution model includes distributed bootstrap but more on that later. .dok
Mar 14 05:57
Thanks, That is the plan. I am also building this in 4 parts to make it more developer friendly. - Transport - Core - UI backend - UI Frontend Transport is the method (or methods) of exchanging payloads. Payloads are the private messages, chan messages, mailing lists, etc. payloads are NOT host information, those are different. - Initially transport will only contain ipv4 WAN (no local ip's), I will probably include ipv4 LAN and sneakernet as transports with the initial pre-alpha release. - Future transport modules could be TOR, I2P, IPFS, bluetooth, dropbox, btsync, qrcode, bittorrent, etc. Anything you can think of for exchanging payloads. Core is responsible for interfacing with transport to exchange payloads. Basically Core is the database of payloads, but it centralizes the rules for what is allowed into and out of the database. Proof of work checking, payload size and expiration, etc. All that is required for a headless server node deployment is 1 transport and the core. UI backend provides all the functionality to the UI frontend. So it centralizes the encryption (and decryption), proof of work generation, address generation, safety/security checks for attack vectors. Keeping it centralized means we don't have to burned the UI front end developers with this. UI Frontend provides the interface for a user. This could also be an API interface if made that way. Basically this hooks into the UI backend and presents the data to the user, this could be a text interface, pyqt interface, web interface, etc. Obviously for a headless server deployment, a lightweight text interface would be nice to manage the machine, but would not be required. It would also be possible to build a text interface that takes the place of the ui backend (since the server will just be relaying messages, no reason to have code for encryption, decryption, etc on it). Being modular like this means it will be easy to create whatever is needed. Stay tuned for more details and updates. Thanks, .dok
Mar 14 06:49
Don't forget: bootstrap and exchange keys over tox, twister, maidsafe, jabber, irc, netcat, ssh, sftp, mixminion, tor, nntp, gopher, geez, there are so many.
Mar 14 07:37
The only way to bootstrap and exchange keys is to carry them handcuffed to your wrist in a locked briefcase. When transporting keys, carry a loaded gun except where prohibited.
Mar 14 07:57
"That wouldn't be obvious; nor would it draw suspicion; nay, not at all," said the mad tinfoil hatter.
Mar 14 11:29
Please, Please, Please, make sure the UI framework remains segregated in its own specific set of source files. The otherwise-good Ricochet progam uses Qt througout, making it impossible to modify or extend. e.g. I wanted to make a Ricochet library with an API but couldn't remove the Qt dependencies because they're at every level of the code. Separation of subject matter is very important for maintainability and readability. Polluting non-UI areas of the code with UI details is a mortal sin.
Mar 14 12:00
An enhancement is to *use* multiple channels, all of which may be subject to tampering, in this way ( or similar ): https://en.wikipedia.org/wiki/Dining_cryptographers_problem Create Multi-factor authentication schemes to increase confidence over hostile wiretapped networks. Include deceptions that can also be factored out to confuse attackers, especially automated systems.
Mar 14 20:13
+1 yes, user interface should be 100% separate from application logic, just like unix command line apps and their standard output model, so any interface desired can be implemented.
Mar 14 21:03
These are great ideas and I'm actually also directing the development of PyBitmessage into this direction. The new network subsystem uses a stateful system for building classes, and will allow to add a new wire protocol easier (for example, I test the system on HTTP before adding the bitmessage protocol). I'm also separating header and payload handling. The inventory handling is already separated (thanks to one contributor, I then extended it to a singleton for easier usage). The UI has been separated for a longer time, you can run PyBitmessage without QT in daemon mode. They do share a sqlite thread but this is due to problems Atheros was having with non-thread-safe sqlite library. Other than that they communicate through queues. Since the inventory is already abstracted, it can probably be reworked with a general storage backend and allow other SQL systems, then you could scale nodes over multiple systems (for example if it handles a huge amount of streams). Now that I think about it, I should probably move the inventory to a separate file already. Peter Surda Bitmessage core developer
Mar 15 00:34
Bootstrapping will be completely isolated to the transport module(s) in use. So it is up to each transport medium to handle the bootstrap problem. Then users can pick the best method. There is no reason to penalize good transports because of bad ones. For example, tcp connections over ipv4/6 will require certificates to authenticate the peer you are connecting to, but tor won't if you use hidden services. Also sneakernet's "bootstrap" is really entirely outside of the system. So each service will handle itself and users can add/bridge all they want. This is why they are separate and the sharing of host information is only kept to the relevant transport module. There is nothing preventing the setup of a "transport" chan for nodes to publish their network information to so that users can get host node info about other networks. There is not really a limit to the number of networks/transport methods that can be used simultaneously. This also helps make it harder to determine where a payload is coming from and where it is going to. .dok
Mar 15 00:36
Yes, it will all be as modular as possible. exchanging sqlite for postgres/mysql, re-writing a transport module in GO, roll your own api and or UI in whatever you want. all possible. .dok
Mar 15 00:41
I am approaching that problem by splitting the database into two databases. One for payload transport (core), one for received messages (inbox, outbox, etc) (ui backend). This also removes the need for the messy timing attack mitigations/etc that are in bitmessage. The ui backend is basically just another peer to the core system. Also, by splitting out the network payloads from the user-relevant payloads, it would be easier to encrypt your addresses/messages/inbox/outbox/etc without having to even take your core offline. Everything is modular. .dok
Mar 15 10:43
Also don't write it in some obscure language like go.
Mar 15 12:33
> I am approaching that problem by splitting the database into two > databases. One for payload transport (core), one for received > messages (inbox, outbox, etc) (ui backend). This also removes the > need for the messy timing attack mitigations/etc that are in > bitmessage. The ui backend is basically just another peer to the > core system. I'm not sure those are related. PyBitmessage processes the incoming objects in a separate thread, so there is no need for mitigation there (even better if I can move the objectprocessor thread into a separate process, then it could run on a separate core and be even less detectable). It used to run in a single thread, but that was a very long time ago before I even started working on it, and I got rid of the unnecessary delays, now it downloads as fast as the CPU allows (and in the new asynchronous IO handler, it should run even faster). The timing attack mitigation still needs to happen for anonymising the initial spread of the message. Pybitmessage needs to mitigates request spam (fast sequence of requests to detect the exact time an object appears in a node). Both of these need to happen irrespective of whether the object was created locally. > Also, by splitting out the network payloads from the user-relevant > payloads, it would be easier to encrypt your > addresses/messages/inbox/outbox/etc without having to even take your > core offline. Yes, good point. Peter Surda Bitmessage core developer
Mar 15 12:41
If all the binary blobs were handled in a separate database, we could treat the contents of message database much more robustly as sweet text. The way python integrates blobs with the rest of the data in the tables is a major headache when trying to extract or merge records. Out comes gobbledy gook.
Mar 15 12:43
That is actually fixable, I have a sample code in a related ticket, the problem is making sure it's backwards/forwards compatible so I have to test it thoroughly. The issue isn't limited to the inventory table, also the message identifiers and ackdata are affected (perhaps something else too). Peter Surda Bitmessage core developer
Mar 16 02:42
Go isn't obscure and it is really good for network-related tasks. like the transport modules. .dok
Mar 16 02:48
What about the PoW issue where an attacker can pre-compute messages before sending them out? Also, are there any directions that Bitmessage are going with scalability? .dok
Mar 16 03:03
> What about the PoW issue where an attacker can pre-compute messages > before sending them out? I don't understand. Where is the attack? > Also, are there any directions that Bitmessage are going with scalability? Yes, the network subsystem is being replaced (that's one of the primary goals for 0.6.3) and streams should also be available sometime later this year. As I wrote earlier, the inventory is already abstracted so the storage for it can be abstracted too without too much hassle. You could then run BM on one computer and store the inventory on another (mysql or whatever). I also want to abstract knownNodes, and partially did that already. It's more of an engineering issue, the protocol is still the same. I've also been experimenting with bloom filters so that nodes do not have to compare the whole inventories when synchronising, but due to false positives it would have to be probabilistic so some compensatory mechanism needs to exist too. But performance wise it's excellent, you can reduce the bandwidth dramatically, and the lookups are very fast. I also have a new, more powerful, workstation that allows more efficient testing and can run many VMs (I originally wanted it to be a server in a data centre but later decided to use it as a replacement for my old workstation). I can easily test deployment on dozens of OSes, and how PyBitmessage scales across cores / memory / network. Due to python's GIL, I want to move some threads to multiprocessing instead, that will allow it to utilise more cores. But some fixes are necessary first, because the current PyBitmessage code isn't compatible with frozen mode's multiprocessing. Peter Surda Bitmessage core developer
Mar 16 03:24
>> What about the PoW issue where an attacker can pre-compute messages >> before sending them out? >I don't understand. Where is the attack? Let's say I have a nice setup where I can use gpu or some method to conduct PoW fastly. So I spend the next month using it to create messages that all have the same timestamp of a month after I start this task. Then when they are all done calculating PoW, and the timestamps are now valid, I release them onto the network. Good stuff with the scalibility. I am thinking of using an additional payload field (additional to the hash, payload blob, time stamp, and nonce for PoW) which will indicate who the payload is for. Basically it will be a 32 byte field that is included with the payload and indicates who the payload is for. There would be multiple ways to use this field but I think by default it will be a hash of the ripe data (if looking at the way bitmessage is structured) for the address it is being sent to. I'd rather use a hash of the ripe data instead of the toAddress so that it doesn't directly give away who the message is for. with PFS, every message exchange is for a new destination address (same identity, different encryption pubkey so different address overall, again if looking at bitmessages code). So my client only has to look for messages bound for that address. Nodes can segregate based off the characters in this string in a tree method. This would allow the network to really breakup the workload if it ever scales to that size. Also it removes the requirement for everyone to get everything, however, that is still an option. The decision is in the users hands. i know that there are unanswered questions there but I wanted to mention it. So, basically instead of streams, I am going with a "destination" field attached to each payload that doesn't directly give away who the recipient is (it's not the destination address) and that field can be used in other ways to further obfuscate communication. .dok
Mar 16 03:35
> >> What about the PoW issue where an attacker can pre-compute > messages > >> before sending them out? > >I don't understand. Where is the attack? > Let's say I have a nice setup where I can use gpu or some method to > conduct PoW fastly. So I spend the next month using it to create > messages that all have the same timestamp of a month after I start > this task. Then when they are all done calculating PoW, and the > timestamps are now valid, I release them onto the network. Ok, so I understood it correctly. I don't have specific plans about this, other than making sure that if there is a flood, it will be the bandwidth that's the bottleneck, not the CPU or RAM. Maybe the stream difficulty could scale depending on how many items there are currently in a stream? > So, basically instead of streams, I am going with a "destination" > field attached to each payload that doesn't directly give away who > the recipient is (it's not the destination address) and that field > can be used in other ways to further obfuscate communication. You should look at how Whisper (the subprotocol of Ethereum) works, and I believe one of the suggestions on the bitmessage forum also is like this. Basically each message has a public field identifying a group of recipients, and the recipient can request a filter. On the other hand, if you look at it from a higher level, it's not that different from streams, a recipient can also request a stream filter, except in the current Bitmessage protocol, a stream filter is a list so it's not an efficient handshake bandwidth-wise (it could be replaced by a bloom filter in the future as well). I'll probably implement streams first just to make sure the sending, receiving and routing works, and worry about the bloom filters later. In the current protocol, a node can announce to be a member of up to 160k streams, so there is no urgency to fix it, we'll see how the bandwidth requirements grow. > .dok Peter Surda Bitmessage core developer
Mar 16 03:50
He was just trolling, .dok. You do work that people can use. It's appreciated. BTW, I use the snot out of the CLI API client you wrote. I've been modifying it. I created some utilities for attacking the bitmessage network, automating anonymous blog publication over bitmessage, running tests, jackhammering spammers (jackspammer) and now working on creating subchannels to do interesting things that nobody in the world can know or see unless they're supposed to. ;)
Mar 16 04:22
:) That's good to hear. I apologize for any crazy coding moments, I was learning python at the time. That's awesome (your uses) and the cli/api will be hopefully easier to use with this version. .dok
Mar 16 04:49
Thank you for the cli client as well, some time ago I merged it into PyBitmessage, I hope you don't mind. I actually tried to reach you for some reason but that was a long time ago and I haven't received a reply and forgot what it was about. Peter Surda Bitmessage core developer
Mar 16 04:53
> So, basically instead of streams, I am going with a "destination" field attached to each payload that doesn't directly give away who the recipient is (it's not the destination address) and that field can be used in other ways to further obfuscate communication. Steams can be randomly assigned, broken up into forks, hubs, and clusters. Clients can announce a virtual location through a mix/onion protocol. It could work better than onion routing due to allowing very high latency, allowing more hops in between. Sort of like mixminion but all addresses would be virtual, and impossible to match to an IP.
Mar 16 15:08
Do you mean HMAC-based subchannels?
Mar 16 16:40
> Do you mean HMAC-based subchannels? This question invokes a whole stream of consciousness on the matter of squeezing extra spaces into the chan concept. I think HMAC or hybrid of deterministic and chan addresses would be great, and I imagine more than that. Variable keys are a way to use a key to cordone off a private space in the same channel. One can also use a domain table, or both. I'd like to see HMAC-like-functionality for address generations. Sort of like a hybrid between a deterministic address and chan address might cause confusion, maybe? For now by changing the logic the client interface employs, there are workarounds with or without variable chan keys, so new users wouldn't be stulfified by chans full of illegible ciphertext. One can establish named spaces or domains within channels by assigning one or more domain name controllers (DNC). This would be voluntary where users forming a workgroup can choose a domain name controller, or several working in concert. The DNC can publish a name/BM-address table assigned to the private domain in a chan. Each client inputs chan name and domain name controller address(es). Those without this information are locked out. A bitmessage user registers a domain name with his bitmessage address, using whatever scheme the users and DNC agree to. The domain controller address publishes the DNC data table. Clients automatically parse it and use it to resolve names to bitmessage v4 addresses. Clients modified to use the domain protocol resolve domain names silently so the process is transparent to the end user. The DNC can even manage envelope encryption for the domain so that users of incompatible clients would only see ciphertext. This establishes an environment where keywords map to a lookup table for the matching bitmessage v4 address. The lookup table is just a group of messages periodically published by the DNC address. Any keyword format you wish to employ will work, for example we use this: bobby == BM-2cWABCDEFG..... bobby@shoes = BM-2cWABCDEFG..... One can run a PGP-style keyserver within the domain for additional envelope encryption options between users. One could also modify a git server to deal with bitmessage objects instead of tcp streams. Imagine a hidden git server that can't be located or shut down where the next generation of spook-busting software is being developed. Yeah, sure, there's the high latency, but if you consider the tons of scripts and garbage that run in browsers and hang them up, it's really not so bad. Such a server (or any service that could be modified for the latency) would respond with encrypted network objects instead of a direct stream of data packets. DNC can resolve all addressing for clients, yet not defeat the encryption and privacy mechanisms. Only those with the credentials (chan name &/or HMAC + controller address ) could access it. Part of the problem with the modern "web of things" mentality is the focus on the things instead of the purpose or workflow. Pretty much everything is a direct connection, when that direct connection has turned into a tunnel of billboards. For many things the latency can be skirted with tricks. An address can broadcast this way so as to resemble a blog or web site with the right window dressing on the interface. Clicking a link on the interface can pull up and display the associated message, with markdown under the hood, rendered in html5 and css. Once there is a solution for scaling to millions of users without copy-to-all coders can dream up cool stuff with bitmessage. We could grow a huge body of anonymous collaboration with very low risk of government interference or infiltration. I wanted to publish and interface to the API to implement a system like this. When I read shop talk about big changes in the system I decided to put it on the back burner for now. l think it is prudent to wait and see the current rather than to forge ahead and end up bailing water and feeling fruitless. Let the experts do all the baking then add some extra icing when it's ready to eat ;) ~ 3X0R H4SH~
Mar 18 00:50
Hmm. Do you remember how you reached out to me? If it was bitmessage, I forgot to remove my address from the subreddit when i stopped checking it. If not bitmessage then I'd like to know to ensure I haven't missed other messages. Thanks, .dok
Mar 18 09:13
I don't remember how I reached out and I can't find any record of it. It was probably over a year ago. But I think it was related to the forum moderation. It probably isn't important. Peter Surda Bitmessage core developer
Mar 29 05:48
Just an update. I have a working prototype with minimal functionality already working. My clearnet transport module (one of the default transport modules) has the option to hide the sender with the downside of a slower sync and slower sending rate. Your client will continuously send payloads (real or just padding) at a set rate (I am thinking of having variable rates but only 3 choices) and receive payloads. So let's say a medium speed is 50kb/s, your client will continue sending payloads and receiving payloads at that rate. This means initial sync is slow (since limited to this speed) and your outgoing rate is limited to that speed, but this makes it possible to completely hide the sender of a paylod in every scenario except when you are peered with nothing but attacker nodes. Also, I am leaning towards a uniform payload size, or at most two payload sizes. 10kb if one size, 10kb and 1kb if two sizes. This would also mask the movement of payloads and any larger messages would be sent over multiple 10kb payload packets. I'll continue to update you all as I work. .dok
Mar 29 10:16
Identity key and will be a user this: is starting to burned hide The message; sending, rate. More details is needed. Just another peer ip's, I am thinking of a longer time use a singleton for mitigation there payloads and readability. I will allow you can think of these are new; asynchronous IO handler, it I can run even better if one of a separate process, then you could run do so let's say a even less detectable, it centralizes the direction; relaying messages (on HTTP before I like the functionality already separated for exchanging payloads are the address to burned the network peer to recap; about it will still be two sizes; manage the same for encryption and allow the same for example what the network there will create an API but would also removes the code with Ui framework remains segregated in daemon a slower sync and as fast as the database). Just another peer payloads and if two sizes: all of exchanging payloads for signing and if one time Use a mailing expiration, etc; So there; let's say a separate process, then you to hide do happen for a headless server will only choices, and I got rid of work checking, payload size and out of work checking, payload handling transport core is a text interface if I got rid of the Bitmessage Now it could be a text interface if I should run a sqlite thread, but this the encryption asymmetrical. Thanks to happen for what is very long time an API but the signing a medium speed is no need to. Initially transport module one of whether the place of the same, this is required for a separate core offline. It handles a general very user, code. There for receiving anything So to a new. Identity addresses just any larger messages on the private messages, as I am thinking of work checking, payload Transport core is starting to for encryption and be possible to the machine, but would not host information, those of the machine, but only be possible to make a singleton for exchanging payloads are I test the same, user, your client will be used subsystem uses a text interface, would be nice to recap.
Aug 7 08:51
how much booze is involved?
Aug 7 08:52
where did .dok go?
Aug 7 09:19
Hit by a bus
Aug 7 09:21
mixminion type routing, minumum chain of 4 separate chain for each part of a payload all payloads diced to same size nibblets randomized packet switch routing instead of tunnels frequent connection cycling bandwidth equalization
Aug 7 09:22
Were you the driver?
Aug 7 15:37
Are mixminion and mixmaster still alive?
Aug 7 15:51
inbuilt imap/pop and smtp. minimal UI.
Aug 8 02:09
barely. I'm not talking about integrating with mixmaster. I'm referring to using mix crypto and routing techniques.
|Can someone please help me with bitmessage??||Aug 19 09:05||22|
|address nuked||Aug 19 07:54||2|
|how many use this?||Aug 19 07:37||5|
|Highlighting Titan's Hazes||Aug 19 07:15||6|
|a BM in the raw||Aug 19 05:38||2|
|How to evade taxes?||Aug 19 05:35||7|
|The world is an illusion||Aug 19 02:42||3|
|any body help me?||Aug 18 19:51||39|
|YAFI - Yet Another Freenet Index||Aug 18 12:20||2|
|Chloë Grace Moretz||Aug 18 10:34||1|
|Charlottesville||Aug 18 05:21||3|
|sisters||Aug 17 06:55||1|
|Find someone to rape||Aug 17 02:50||14|
|0.0005 BTC||Aug 16 20:49||8|
|Peachkisser's Erotic Stories and Blog||Aug 16 15:07||4|
|Nara||Aug 16 12:55||1|
|Alika||Aug 16 12:39||1|
|[DELETED]||Aug 16 11:01||1|
|[DELETED]||Aug 16 10:50||1|
|btc-e||Aug 16 10:47||3|
|[DELETED]||Aug 16 10:09||1|
|[DELETED]||Aug 16 09:37||4|
|Sally and her daughter Flea||Aug 15 20:15||12|
|I've been here||Aug 15 12:42||1|
|Learn from the former commies||Aug 15 10:07||2|
|Kat||Aug 15 10:00||1|
|Aktie 0.5.19||Aug 15 07:17||1|
|decss.c||Aug 14 20:13||2|
|YOU FUCKERS !!!!!!!!||Aug 14 19:36||8|
|HELP I NEED 400$ CC DUMPS||Aug 14 19:08||3|
|[DELETED]||Aug 14 16:34||2|
|HELP MONEY RUN TO AMERICA||Aug 14 12:46||5|
|a question for pythonistas about securely wiping a file||Aug 14 10:09||9|
|Aktie 0.5.18||Aug 14 07:54||2|
|The Government Siezed two truckloads of Tesla's Papers and Inventions||Aug 14 05:00||3|
|Hacking emails||Aug 14 04:57||2|
|NNTP over tor||Aug 13 19:01||4|
|free cc||Aug 13 16:40||3|
|Tesla vs. Einstein||Aug 13 16:15||1|
|The Gravity Myth||Aug 13 16:15||1|
|Need cc cashout guide||Aug 13 15:08||4|
|Your privacy - VPN & FireFox (+ other Gecko browsers)* rev. 0.3.2||Aug 13 14:04||2|
|Your privacy - VPN & FireFox (+ other Gecko browsers)* rev. 0.3.1||Aug 13 13:36||2|
|Where?||Aug 13 12:46||3|
|Video Course and Tutoring on Carding and whatnot||Aug 13 12:03||2|
|Make USD94 PER HOUR working from home.||Aug 13 08:39||10|
|A Cypherpunk's Manifesto||Aug 13 05:42||1|
|Bitmessage announcement||Aug 13 05:42||4|
|Battle for sanity.||Aug 13 02:50||3|
|Lift the nation up||Aug 12 22:50||4|
|forbid the sending of acks||Aug 12 21:14||2|
|Query for Crypto Junkies||Aug 12 16:56||18|
|No real privacy apps||Aug 12 14:54||16|
|cp||Aug 12 14:41||4|
|Safe OTP over a wire||Aug 12 13:58||1|
|a question for pythonistas about securely wiping a virus||Aug 12 12:20||2|
|Virtuous||Aug 12 11:31||1|
|Help with altcoins||Aug 12 08:22||2|
|FIREWALL, IPTABLES, BLOCKING INCOMING REQUEST||Aug 11 23:22||3|
|Blue whale game||Aug 11 11:53||1|
|Francesco Scavullo - Brooke Shields 1975||Aug 11 11:51||1|
|Your privacy - VPN & Firefox (+ other Gecko browsers)* [Updated]||Aug 11 10:17||1|
|Your privacy - VPN & Firefox (+ other Gecko browsers)*||Aug 11 08:01||5|
|Stop sending these shits||Aug 11 07:08||1|
|Profit.||Aug 10 22:04||1|
|Air gapping is not enough||Aug 10 22:01||6|
|OnionShare||Aug 10 21:15||2|
|Curious||Aug 10 21:14||2|
|Where to find ...||Aug 10 16:10||2|
|Dark web market||Aug 10 03:30||15|
|ricochet with the latest version of tor||Aug 10 03:30||2|
|Sicko feds?||Aug 10 03:30||1|
|Flat Earth - The Heliocentric Globe is Dead.||Aug 9 21:34||13|
|pretty teen girl||Aug 9 20:30||12|
|NASA Photos of Earth are a Hoax.||Aug 9 20:07||5|
|playing with daddy||Aug 9 10:49||1|
|Venus After School||Aug 9 10:48||1|
|Good Old Summer Time||Aug 9 10:38||1|
|Tor Browser 7.0.4 is released||Aug 9 07:30||1|
|Bitcoin Pyramid||Aug 8 15:09||16|
|The Blue whale Game||Aug 8 12:18||10|
|Social Justice GitHub Style||Aug 8 06:02||1|
|faith?||Aug 8 04:22||1|
|bitmessage replacement||Aug 8 02:09||8|
|anonymity||Aug 8 02:07||10|
|Meaning of life||Aug 8 02:01||5|
|i need 0.05 BTC . i do any thing for you in iran. Tor Chat : odjturoepgw7jrxa||Aug 7 11:43||1|
|Do you know somebody who wants money?||Aug 7 08:08||6|
|fuck you retard||Aug 7 07:59||1|
|HoneypoTor||Aug 7 07:56||3|
|Is this channel still being used?||Aug 7 07:54||4|
|Pleasure||Aug 7 07:54||2|
|Atheist||Aug 7 07:37||8|
|Loan Sharks||Aug 7 07:33||2|
|Python question||Aug 7 07:22||4|
|How to attach images?||Aug 7 07:00||4|
|head count||Aug 7 00:27||1|
|sitting on the steps||Aug 6 18:54||3|
|checksum: ElectrumCash wallet (bitcoin cash, bcash, bch)||Aug 6 17:19||1|
|nose||Aug 6 10:27||1|