Ray Dillinger wrote:
Okay I'm going to summarize this protocol as I
understand it.
I'm filling in some operational details that aren't in
the paper by supplementing what you wrote with what my
own design sense tells me are critical missing bits
or obvious methodologies for use.
There are a number of significantly different ways this
could be implemented. I have been working on my own
version based on Patricia hash trees, (not yet ready to
post, will post in a week or so) with the consensus
generation being a generalization of file sharing using
Merkle hash trees. Patricia hash trees where the high
order part of the Patricia key represents the high order
part of the time can be used to share data that evolves
in time. The algorithm, if implemented by honest
correctly functioning peers, regularly generates
consensus hashes of the recent past - thereby addressing
the problem I have been complaining about - that we have
a mechanism to protect against consensus distortion by
dishonest or malfunctioning peers, which is useless
absent a definition of consensus generation by honest
and correctly functioning peers.
First, people spend computer power creating a pool of
coins to use as money. Each coin is a proof-of-work
meeting whatever criteria were in effect for money at
the time it was created. The time of creation (and
therefore the criteria) is checkable later because
people can see the emergence of this particular coin
in the transaction chain and track it through all its
consensus view spends. (more later on coin creation
tied to adding a link).
When a coin is spent, the buyer and seller digitally
sign a (blinded) transaction record, and broadcast it
to a bunch of nodes whose purpose is keeping track of
consensus regarding coin ownership.
I don't think your blinding works.
If there is a public record of who owns what coin, we
have to generate a public diff on changes in that
record, so the record will show that a coin belonged to
X, and soon thereafter belonged to Y. I don't think
blinding can be made to work. We can blind the
transaction details easily enough, by only making hashes
of the details public, (X paid Y for
49vR7xmwYcKXt9zwPJ943h9bHKC2pG68m) but that X paid Y is
going to be fairly obvious.
If when Joe spends a coin to me, then I have to have the
ability to ask Does Joe rightfully own this coin, then
it is difficult to see how this can be implemented in a
distributed protocol without giving people the ability
to trawl through data detecting that Joe paid me.
To maintain a consensus on who owns what coins, who owns
what coins has to be public.
We can build a privacy layer on top of this - account
money and chaumian money based on bitgold coins, much as
the pre 1915 US banking system layered account money and
bank notes on top of gold coins, and indeed we have to
build a layer on top to bring the transaction cost down
to the level that supports agents performing micro
transactions, as needed for bandwidth control, file
sharing, and charging non white listed people to send us
communications.
So the entities on the public record are entities
functioning like pre 1915 banks - let us call them
binks, for post 1934 banks no longer function like that.
But if they recieve a _longer_ chain while working,
they immediately check all the transactions in the new
links to make sure it contains no double spends and
that the work factors of all new links are
appropriate.
I am troubled that this involves frequent
retransmissions of data that is already mostly known.
Consensus and widely distributed beliefs about bitgold
ownership already involves significant cost. Further,
each transmission of data is subject to data loss, which
can result in thrashing, with the risk that the
generation of consensus may slow below the rate of new
transactions. We already have problems getting the cost
down to levels that support micro transactions by
software agents, which is the big unserved market -
bandwidth control, file sharing, and charging non white
listed people to send us communications.
To work as useful project, has to be as efficient as it
can be - hence my plan to use a Patricia hash tree
because it identifies and locate small discrepancies
between peers that are mostly in agreement already,
without them needing to transmit their complete data.
We also want to avoid very long hash chains that have to
be frequently checked in order to validate things. Any
time a hash chain can potentially become enormously long
over time, we need to ensure that no one ever has to
rewalk the full length. Chains that need to be
re-walked can only be permitted to grow as the log of
the total number of transactions - if they grow as the
log of the transactions in any one time period plus the
total number of time periods, we have a problem.
Biggest Technical Problem:
Is there a mechanism to make sure that the chain
does not consist solely of links added by just the 3
or 4 fastest
