Your final statement here is not true. The way in which you keep anonymity with an onion system is as follows: 1. Use a central originating server for onion packet sourcing 2. Make it public who all users are 3. Have onion packet creation contain "token of receipt" for all messages along the chain. 4. Rate limit message origination from users 5. Ban users who refuse to forward encrypted packets at a steady rate 6. Only allow small message sizes ( 10k ) 7. Have all online users constantly originate "bogus" packets to random users 8...

I am currently writing such a system. Some details up at circleofdistrust.com in about a month or so.

How do you rate limit users? Are not originator traffic and pass thru traffic indisquishable, so a receiving peer cannot tell the if a node is just well connected and has a lot of traffic on behalf of others, or is an abuser?

And how to measure forward rates?

There are two types of nodes in the system, "servers" and "users". All servers communicate with each other so that they are all aware of all existing "servers" globally. There will likely be a limit on who is allowed and authorized to be a server. ( likely a list of their public keys published to the main site for the project )

All packets must be hashed and authorized ( signed ) by the server before they can be sent out. Any packet not authorized by a server will be rejected. In this way, servers will rate limit originating packets.

The traffic is distinguishable because the onion layer is identified at each level. If, after unwrapping your layer, you discover the underlying "level" is not 1 less than your own informed level, the ip origination will be flagged back to the server for spamming.

Current estimate for number of onion levels is 100. Actual destination should be somewhere in the middle 60 or so, to prevent government tracing of the packet because all hops.

At each hop, random delays will be implemented, as well as injection of extra data and/or disguising the entire packets as other forms of tcp communication. ( to prevent dropping of the packets through filtering )

The "servers" know that users are sending out origination packets at a specific rate and to whom, but nothing about the layers beyond the first. Additionally, the entire onion packet is never sent to any server, only a hash of it with specific other information. This way, "servers" can never be accused of harboring illegal data of any sort.

Forwarding rates are measured because each onion layer containing a "message of receipt" that is sent back to the server. The server receieves all of those from the originating user before approving the onion packet.

The only think attackers of the system could try to do is attempt to DDOS users of the system. This is prevented inherently by it being known at all types all users logged into the system ( this is public knowledge in the system ). Communication is only allowed from valid behaving users.

It would be great if you could share your thoughts about this earlier.

Its not as though we don't have a spam problem already…

Freshly pulled-out-of-the-air suggestion – anonymous but requiring micro-payments. Say, 500 or 1000 satoshi (around a tenth of a cent) per message delivered – not as a means of generating revenue, but as a way to destroy email's current "if I only get one sale per 100,000 emails I send, that just means I need to send 10,000,000 emails a day to get my desired 100sale/day" vulnerability - if that actually cost the spammer $10,000/day, it just wouldn't happen.

('course that required having hard currency to bitcoin exchanges easy enough for the general public to use, and scalable enough to service a significant proportion of internet-using people)

Yes there have been various attempts at proof-of-work algorithms to fight e.g. spam. http://en.wikipedia.org/wiki/Proof-of-work_system

Bitcoin is itself a proof-of-work system.

However, these again don't work. The abuser has ample resources to actually do the work on: a botnet.

>Freshly pulled-out-of-the-air suggestion

That's not fresh. I think it may have even been entertained by Congress for a while.

Just two points:

- That's why I prefer to think about protocols, as opposed to a system (i.e. global implementation of one or more generalized protocols)

- You don't always have to solve the problem theoretically; solving it practically may be good enough. A system can be usable for a long time, before it collapses under abuse.