Isn't the simple solution to include the signature of the entire document with each chunk you forward. If the signer claims he provided different text, he will need to produce a document which matches the hash of what he signed, but he can't do that and also lie.
There are usually simpler solutions. Just think out of the box and paradigm shift the problem.
There are usually simpler solutions. Just think out of the box and paradigm shift the problem.
Okay then jl777. Another way to do it is have the originator sign a hash which is a root of a Merkel tree. Then you can break the document into words or even individual characters if you want. And you can send any portions of the document and prove the originator signed those.
jl777, if the originator signed the root hash of the Merkel tree when he provided it to the intermediary, then the intermediary can prove that any fragment(s) of the document was signed by the originator. The originator is the one who breaks the document up into words or characters at the leaves. A Merkel tree is a very efficient structure space wise if the granularity is very high.
I suppose yours of deterministic mapping each hash to a field element and multiplying all together (and the originator signs the product)is more space efficient, but it is I think roughly an order-of-magnitude slower. Why not add instead of multiply since adding is much faster (one assumes hashes are difficult to preimage)?
Correction: the Merkel tree is also more space efficient (as well as being faster), because the intermediary doesn't specify the hashes for all the leaves when writing a proof.
I suppose yours of deterministic mapping each hash to a field element and multiplying all together (and the originator signs the product)
Correction: the Merkel tree is also more space efficient (as well as being faster), because the intermediary doesn't specify the hashes for all the leaves when writing a proof.
What do you think about anonymint's idea of having a user settable coin age requirement for the feetx? The idea is to slow down the annoyance attacks.
That seems reasonable too. You are forcing people to expend a finite resource, so they can't spam.
It could be an issue for people who have just obtained coins and then have to wait a few days to build up coinage.
What I suggested to jl777 in a PM, is that he make it (the coin age, a.k.a. "Coin Days Destroyed") a user-adjustable variable so that users can select the tradeoff between delay for themselves and those counter-parties available to trade with, and depending on the level of jamming present at that time. jl777 referred to it as a "rainy day" insurance, which seems an apt characterization of the suggestion.
I have my strong intuitive (generative essence) sense that I will find a flaw in any method of using a fee to block the attacker who wants to jam the protocol, because the fee can't be atomic with the trade (without also opening a jamming window of interaction), so a window of jamming is always opened. Whereas, the coin age is a finite resource which exists (is committed to) prior to the initiation of any protocol for trading. Also it is impossible to use a mixer to hide the identity of the attacker, since mixing will bump the coin age back to 0.
Note my suggestion hinges on the first interaction with the counter-party in the protocol must bump the coin age to 0 on the block chain (else only a local blacklist can be maintained which is much less robust defense). Otherwise the attacker can reuse the same resource over and over to jam with.
Jamming is the main obstacle I forsee impinging on the viability of TierNolan's decentralized exchange protocol. The next obstacle is the very limited scalability of transaction rate for existing block chains, but that is a holistic problem for crypto right now (meaning it MUST be solved else the crypto currency phenomenon dies).
