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
Curious Jun 22 11:03 3
Wondering Jun 22 10:12 2
Bitmessage over OnionCat hidden services layer Jun 21 02:41 2
Question about PoW Jun 21 02:16 2
Any predictions? Jun 20 18:18 6
Free software makes millions for Richard Stallman's cult Jun 20 07:40 11
Streams? Jun 20 03:16 3
Support (connections are "stuck" when using TOR+iptables) Jun 20 03:01 6
test 14.06.2017 19:44 london time Jun 17 15:27 17
regular stats about the BitMessage network (in TZAG) Jun 17 07:17 2
DEMONSAW Believe in the Right to Share Jun 17 06:43 3
Are these types of errors normal? Jun 14 09:14 11
tor hidden service DoS vuln Fixes 20170608+ codebases Jun 13 03:16 8
MiNode experimental I2P support. Jun 11 07:35 2
Abit problems Jun 7 03:41 1
easy way to deactivate msgpack Jun 7 01:33 6
active nodes in BM Jun 6 13:36 11
Default known nodes Jun 6 08:49 3
BM good practices Jun 6 01:54 7
Bitmessage peer discovery status Jun 5 17:43 12
PyBitmessage laggy Jun 5 16:39 4
error: uncaptured python exception Jun 5 16:08 7
The Stallman Tax Jun 4 16:55 3
ransomware "crisis" Jun 4 12:57 1
RE: Hi, there is a problem Jun 2 04:09 7
[chan] memory-hard proof of work BM-2cVnsDNQJeDYoqvrSuQKEn3B6yLuMC24n3 Jun 1 10:41 1
Sorting the inbox May 31 14:59 2
Bitmessage snapshots for testing May 30 22:32 3
RE: Hi Chris! May 30 06:02 1
Broken May 29 17:03 6
HOWTO Enable asyncore in PyBitmessage 0.6 May 29 04:28 3
HOWTO Enable asyncore in PyBitmessage 0.6 May 29 01:00 2
[Feature Request] Send Later at time of day May 28 19:15 1
Fixed width font in bitmessage May 28 19:08 2
for your feature request bucket May 28 19:08 6
vanity generator May 28 15:51 12
Asyncore and Peer discovery work :-) May 28 11:38 2
What is a cyberguerilla? May 28 11:36 1
How to cancel a message? May 27 14:09 1
API TTL May 27 05:56 8
knownnodes.dat structure May 26 09:00 23
WTF? May 26 04:24 5