...

https://lists.cpunks.org/pipermail/cypherpunks/2020-May/080509.html mid: CAD2Ti282noLJEugQ8dQ6BAnbfxdz8DDy1xUpNAXSXMxHNN

Being potentially applicable to a more abstract generic overlay transport network handling modular applications, one perhaps being 'replacing tor'... bell writes:

'chaff' might have been a problem if the people who host the nodes had some limited-data Internet service, but I am aware that Centurylink now offers 1 gigabit service for $65 monthly, and I think that service has no monthly data limit. (their slower services have a 1 terabyte montly limit). That should be plenty to allow for generous chaff.

Things maybe different from the notion that paying high speeds, enables sufficient chaff, enables sufficient security. Data limits vs bitrate vs network fill chaff vs security. A network normally filled fulltime during user-idle time with right-of-way-Yielding chaff, then yielding way dynamically to user-not-idle traffic demand of right-of-way-Having wheat, an equation is... (rowY chaff + rowH wheat = at all times ensuring the provisioned line rate is full) ...that is self enabling, regardless of bitrate, caps, or money. If user has a 'data limit' specified as a quantity (typically Bytes in a period), they can generally save some quantity for later consumption by... - turn on client, use for whatever, turn off client ...but client must still conform to equation above when running, else no security improvement over todays existing overlay networks. 3TiB/mo = 100GiB/dy = 10Mbps Any data quantity limit per time period breaks down as above into an available constant bitrate. If that bitrate is not enough for user to do whatever within, say voiceconferencing at stupidly offensive codec bitrates, then they must play the on/xfer/off game above to convert more saved quantity into now bitrate, this is simple physics. They only have bitrate up to the max they got from ISP, the maximum even then is up to the hard physical link speed PHY. Both of which are usually higher than any data quantity limits the user bought and got provisioned because the ISP wants to rape user's bill for Bytes (the ISP aggregates and only deals in bitrate pipes upstream anyway, Byte caps are just counters triggering management scripts over pipes). Point is, constant bitrate <=translate=> data quantity. And the constant background of chaff would yield its way packet by packet on the fly upon demand of the quantity of user's wheat flow, whether the demand be for 0% up through 100% of the line, all [re]clocked back out the NIC. Whatever the %, and for the varying duration and amount of its demand, that wheat is in fact become part or all of the fill traffic needed to prevent traffic analysis across the network. Security of the net requires all network nodes to always enforce the above equation when running. So there is probably less notion of this 'allow for generous chaff', only the notion of if the user has purchased enough capacity to do what they want. If they didn't buy enough, nothing will let them dodge their provisioned physics. This physics is no different than with Tor, I2P, bittorrent, IPFS, BTC, this model or anything other, or even plain old raw websurfing straight out user's NIC to their ISP to YouTube. 1Gbps = 300TiB/mo = $65/mo 1TB/mo = 3Mbps = $?/mo Only one of those two ISP plans will allow the user to do 10Mbps of demand. The network is still secure during their use of it regardless of which plan they choose or how they choose to use it. If talking about 'hosting' nodes, meaning configuring them up as transit nodes, possibly in addition to user's own use of them as endpoints, the same equation still applies. People still too often think of chaff by the old fashioned models, they still assume chaff can only be in addtion to or somehow taking up space for or blocking out wheat... the equation above offers a new dynamic yield-right-of-way model to think about. All nodes, whether end user endpoints or any other type, must generate equation conforming fill of their entire virtual connection rates into the overlay [1], else... - Pairs of endpoint traffic patterns can still be matched up. - Overlay cloud will have quieter/unregulated paths that will eventually get randomly chosen by endpoints to path through yielding a traceback match. ... tor tries to game these with noise and aggregation, but that may not be sufficient. Nodes auto negotiating bandwith rates among peers, enforcing those contracts and [re]clocking expectations, else dropping them out as suspect, still applies as usual. Migrating end users from any of today's overlays would set one new thing... the end users subject to data caps would configure their node to sit idle until it detects their call for the network, or just turn it off. Both those and unrestricted users gain access to some more analysis resistance in usual transparent-tor-like sort of way. The model might not depend or care about how traffic moves around inside the network, or what the apps it carries are. It maybe possible to apply to any existing or new overlay network as an external function managing its traffic over the NIC to/from its peer nodes on clearnet, like in old ATM cell bucket brigade fashion. foreach bucket in negotiated_clocked_rate if demand then send demand else send chaff This scheme probably rubbish anyway. [1] The real pipe bought from ISP might have some virtual rates carved from it by user for other clearnet applications. In a router device, this would be the typical red/black ports and rate limit packet filters, so that traffic doesn't impede each other, or provides a dynamic use equation for the real pipe. bought rate = rate allocated to clearnet apps + rate allocated to nextgen overlay app