> Having an explicit motivation ("threat model" in security protocol
parlance) would help in analyzing if this feature provides the desired
benefits. You should also figure out what problems the cluster model
doesn't solve and explicitly identify them. For an example of a threat
model see section 3.1 of
https://svn.torproject.org/svn/projects/design-paper/tor-design.pdf
I do have something similar to this written in Section 7 (on page 13) here:
https://bitmessage.org/Bitmessage%20Technical%20Paper.pdf
It has no threat model for the stream scalability design; this would depend
on when spilling into new streams would be warranted (too much CPU usage?
Disk IO? Sync time after being offline for two days?) I'm not yet sure which
it will be.
> The "proxy ack" feature you describe in section 7 is a single-hop
fixed-usage onion routing mode. How about extending it to arbitrarily
nested messages (with a separate proof-of-work on each one, of course)?
Do you mean for including other types of messages like broadcast or public
key messages? If yes, it can already be used for this and indeed msg
messages can be nested within each other an unlimited number of times.
> Why not include an auto-adjusting network difficulty factor like Bitcoin
rather than requiring a client upgrade?
The upgrade path you've described is indeed what would have to happen. The
difficulty doesn't adjust automatically because spam is subjective. Using
the number of messages broadcast through the stream/cluster to set the
difficulty might be viable although it would leave new and rather empty
streams susceptible to much more spam. This would have the effect of
allowing users to choose the balance between spam protection and PoW time
but it would be much easier for them to simply set a "demanded PoW" value
and attach it to their public key and messages.
> Have you considered replacing your bespoke PoW system with simply
including Bitcoin postage on messages?
The original creator of Bitcoin had this idea as well but the current lead
developer believes that Bitcoin isn't actually very well suited for large
volumes of micropayments because of scalability concerns.
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
