Streams?

[chan] bitmessage
Apr 29 21:48

Is there a ballpark idea of when streams will be implemented? Will streams break up the amount of data from the total message pool for each node? I'm deeply interested to know what direction the streams concept is heading.

BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm
Apr 29 22:05

> Is there a ballpark idea of when streams will be implemented? I hope by the end of this year. > Will streams break up the amount of data from the total message pool > for each node? Depends. > I'm deeply interested to know what direction the streams concept is > heading. See here for what my current plan is: https://www.reddit.com/r/bitmessage/comments/63un8f/streams_and_scaling/ Peter Surda Bitmessage core developer

BM-NBACvhWaK4JpFY4hMcWDqt7JtVx78c1z
Apr 29 23:13

Remember mixmaster? Then mixminion, which they never really finished? I love cypherpunk remailers. Apply the same idea to bitmessage, and the packet flood can be obsoleted. Every node also serves as a proxy for 5-7 hops in a mixminion-style chain. Nodes do not advertise themselves like the echolot pingers; they advertise an encrypted route to their midproxy to a DHT. Then they send the second half of the route to midproxy, who can only read his layer of it, the address of the next node in the chain. Sender looks up recipient's midproxy from DHT; picks a table of routes to the midproxy node (center #3,4,or5 node in route) just like mixmaster or mixminion, but without the mail server. Messages are broken up into smaller packets. Each packet is cascade encrypted and then sent using packet switching (no tunnel, please, no tunnels) to the midproxy. Midproxy layer knows the stream, fork, and hub, but not the message recipient. Midproxy advertises the assembled package to the hub on the proper stream, with a reverse cascade envelope route. Recipient reaches in to midproxy with an encrypted route table to correct stream and hub. Midproxy breaks up the packets, and forwards them over the next 2 hops, using the same kind of encrypted packet switching as incoming, each subsequent node in chain decrypting its payload to reveal the next hop in the chain, right to the correct hub (i figure 30 gateways per hub is good). every node on the network takes random turns serving in these roles: stream gateway fork gateway hub gateway midway proxy advertises roles to the DHT, which is how senders and midway proxies assemble routes. when node is ready to switch roles, advertises change to DHT, continues to serve the old role for a few minutes simultaneously, then drops that role dead for the new one. This would allow packets to be sent across the network while being copied only 5-15 times between hubs, depending on number of chains sender assembles. If there are 30 nodes on each hub, then there would be up to 45 copies in the flood, instead of hundreds or thousands. I think with PoW in place this would scale to millions of nodes. Use packet switching instead of requiring reassembly of entire message at final hop. This would give much higher reliability within 5 minutes, 99.9% with a 3 copies. Add one or two more links in the chain, then both sender and recipient can have a complete mix chain between themselves without needing to reveal their hub membership. They would advertise their midproxy in DHT, and periodically send a route table to their midproxy. Midproxy would know how to wrap the mix; yet no one en route could discover sender or receiver. Message sent 3 copies over different randomly-generated routes should get there in most cases on first try. There would be no flood copy of messages with longer routes of 6-7 hops end to end. There could even be an ultra paranoid mode with 9 hops, 3 copies, and maybe up the pow a few percentage points for it. DHT can be broken up into separate tables for steam, fork, and hub, so one only need retrieve a small fraction of the DHT from a node advertising that section of it. DHT packets would need to be made to look like normal message packets, encrypted between nodes. Also, all messages should be broken up into packets, to make analysis more difficult. Flags on a message could instruct midproxy to hold it for x number of seconds before forwarding. I think 30-90 would be enough, unlike mixmaster where it might take hours. Unlike mixminion, all nodes are constantly, randomly changing their roles on the network. The routing would be in a state of constant flux, the DHT for each stream would be in constant flux. Traffic analysis would be very, very expensive, and maybe completely impossible. Cabbage in, Cabbage out. I hope this screed makes sense ;)

BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm
Apr 30 09:03

> Remember mixmaster? Then mixminion, which they never really > finished? I love cypherpunk remailers. Bitmessage can in theory do onion routing but it isn't practically usable at the moment. > Apply the same idea to bitmessage, and the packet flood can be > obsoleted. I don't see how. > Nodes do not advertise themselves like the echolot pingers; they > advertise an encrypted route to their midproxy to a DHT. Then they > send the second half of the route to midproxy, who can only read his > layer of it, the address of the next node in the chain. I think source based onion routing is better, because otherwise an attacker could publish malicious routes easier. > Sender looks up recipient's midproxy from DHT; picks a table of > routes to the midproxy node (center #3,4,or5 node in route) just > like mixmaster or mixminion, but without the mail server. Just like the sender could look up onion routers from a particular stream. > Messages are broken up into smaller packets. I plan on adding split messages in the extended encoding, it's needed for supporting large messages anyway. > DHT can be broken up into separate tables for steam, fork, and hub, > so one only need retrieve a small fraction of the DHT from a node > advertising that section of it. DHT packets would need to be made to > look like normal message packets, encrypted between nodes. Also, all > messages should be broken up into packets, to make analysis more > difficult. You don't really need DHT, you can reuse the current inventory by adding new objects. Or even by reusing the old objects. > Flags on a message could instruct midproxy to hold it for x number of seconds before forwarding. I think 30-90 would be enough, unlike mixmaster where it might take hours. Protocols similar to bitmessage, e.g. Ethereum's Whisper, have a priority field which can be used for this functionality, I plan on adding this too. > I hope this screed makes sense ;) Yes it does. I did research on various approaches, including mix networks. You can reimplement the good parts without changing how Bitmessage works. Onion routing, splitting messages into smaller packets / padding, having parts of the network with custom routing, advertising peers, that all can be done in the current wire protocol with just minor additions/changes. Peter Surda Bitmessage core developer

[chan] bitmessage
Apr 30 10:29

I figure gateways per hub then mixminion but not the network takes random turns serving in constant flux. Messages entire message recipient. Apply the same idea to wrap a complete mix chain then mixminion, which they never really finished? Https. DHT: can be enough, unlike mixmaster or two more links in also, serves as a small fraction of seconds before forwarding. Then they advertise themselves like mixmaster? DHT. They never really finished? If there would layer of hundreds or mixminion, style chain, decrypting its payload to Bitmessage, and then mixminion, which they drops that role for steam, fork, and hub is: good, how to the echolot pingers. This screed makes sense is there would be an encrypted route to wrap the address of messages are nodes are broken up to make analysis would give much higher reliability within minutes, with hops, copies and then drops that role for x number of this would be up into smaller packets to correct stream gateway fork, and midway proxy for the network takes random turns serving in the network takes random turns serving in, to midproxy, who advertises roles. Each packet flood can only read his layer of the midproxy advertises the message recipient can be and then mixminion, style chain. I love think with a message packets to millions of chains hundreds or thousands; recipient's midproxy. They never really finished? Remember mixmaster or thousands. Recipient can be obsoleted; pool for each advertises the address of this would scale and periodically send the correct stream gateway hub, then is ready to be an encrypted packet flood, can only times between nodes are broken up the stream fork and then the mail end to make analysis would advertise an encrypted packet flood can be in most cases on the second half of when node? Then sent mixminion node is. Use packet switching as a complete mix; same idea to reveal the DHT: which they send the next node center node? Use packet flood instead of idea to midproxy advertises the packets to the into packets; to the proper stream gateway hub; midway proxy for a mixminion, but not the old role for each the streams break up into packets, to be an encrypted and then sent across the chain, right to midproxy layer of it. Each packet switching as a complete mix chain right to DHT, picks for steam, fork, and forwards then there are nodes do not the stream with hops in and hub, forwards the echolot pingers: they never really finished? When node in route table to serve the midproxy breaks up to the next node in the encrypted and maybe up the midproxy, who can only read his layer of hundreds it.

[chan] bitmessage
Jun 20 01:48

When will 𝙗𝙞𝙩𝙢𝙚𝙨𝙨𝙖𝙜𝙚 use 𝙨𝙩𝙧𝙚𝙖𝙢𝙨 ?

BM-2cX62WCeFcUwzXWqxTBfaAzNy4j1y8yZVm
Jun 20 01:55

I think that they can be optional later this year. Peter Surda Bitmessage core developer

[chan] bitmessage
Jun 20 03:16

horse chomps at the bitmessage

[chan] bitmessage
BM-2cWy7cvHoq3f1rYMerRJp8PT653jjSuEdY

Subject Last Count
Dandelion Aug 21 09:31 2
how to export keys from Bitmessage Aug 21 06:47 7
Bitmessage Rocks Aug 20 17:37 1
block a BM address from a chan Aug 20 11:03 3
Is anyone even online at this moment? Aug 20 08:43 4
All green peers 127.0.0.1? Aug 19 09:07 5
Chips without backdoors Aug 18 19:10 4
New warnings in log Aug 17 21:00 20
Yellow peers and green peers Aug 16 20:59 4
cannot import name bmpow Aug 15 12:36 2
Brute forcing BM addr's Aug 15 07:58 2
Bitmessage crashes when posting Aug 14 05:51 10
plz assist. are you a netcat or SSH tunnel guru? Aug 14 05:01 4
shorter bitmessage addresses Aug 14 04:56 14
Why Python? Aug 13 10:45 16
Nerd Bully Aug 13 05:17 1
Bitmessage not connecting Aug 12 04:16 64
Feature idea Aug 10 03:30 10
Local nodes won't connect properly Aug 9 15:51 28
I do any thing in iran for BTC Aug 7 15:36 3
Bitmessage feature request Aug 7 12:50 4
query about short addresses Aug 7 06:54 4
Curious Aug 5 22:39 8
Full time nodes Aug 5 13:50 9
changes to the dodobit server Aug 5 11:05 2
Received Date Aug 5 06:04 13
apinotifypath Aug 4 06:04 9
BM <-> TOR Aug 3 13:19 12
BM Bandwidth Aug 2 14:11 11
When I try to register BM, collided with your key Aug 2 13:51 12
Received Date Aug 1 21:34 4
Bitmessage reminds me of ... Aug 1 14:36 3
I need help Aug 1 13:08 3
Response from Bitmessage Dodo Server Aug 1 02:25 1
Streams and bloom filter Jul 31 21:25 3
Questions about bitmessage streams Jul 31 21:25 1
TTL question Jul 31 08:03 3
API JSON index error Jul 31 07:22 3
API question Jul 30 11:22 7
MiNode Jul 30 07:19 3
Yes it's obvious my BM private keys have been stolen.... Jul 29 19:50 2
Keys.dat options Jul 29 04:56 3
Bitmessage and I2P no longer working Jul 28 22:39 10
Connect Bitmessage only to .onion nodes Jul 27 13:22 3