On Tue, May 19, 2015 at 09:13:49AM -0700, Eric Martindale wrote:
Hello all,
BitPay has just released our first whitepaper on ChainDB, a new
peer-to-peer database system backed by the Bitcoin blockchain. This
paper outlines our intended consensus mechanism, proof of fee.
Please take a look at the paper here: https://bitpay.com/chaindb.pdf
We are seeking comments and feedback on this mechanism. I am happy to
answer any questions about the paper itself.
I'm quite disappointed to see that you still haven't fixed the problem
that transaction fees prove nothing at all. Among other things, you risk
creating a system where miners can much more cheaply sell the service of
including the requisite high-fee transactions in blocks they mine for
the much lower cost of the risk of the blocks being orphaned and other
miners getting those fees. In particular, the more hash power you have,
the lower that cost is - exactly the opposite kind of incentive than we
want. As described this is an extremely dangerous project, both to its
users, and Bitcoin as a whole; in general the idea of anything that
tries to use transaction fees as proof is highly dangerous.
You should implement this with direct provably unspendable OP_RETURN
sacrifices for now, and perhaps in the future, sacrifice to
any-one-can-spend-in-the-future scriptPubKeys once CLTV is deployed. If
you do this the interval needs to be long enough to robustly get past
business cycles - e.g. 1 year - to avoid the well-known problem that
large miners can sell these proofs cheaply.
Other comments:
* Bitcoin does not securely store data; Bitcoin proves the publication of
data.(1) This can be seen by the recently added(2) pruning functionality
which allows full nodes to discard all blockchain data other than the
UTXO set and some number of recent blocks. (to handle reorganizations
efficiently) Additionally even the UTXO set can be discarded in
principle if my TXO commitments proposal is implemented. Between both
proposals there's no guarantee that data published to the Bitcoin
blockchain will be stored by anyone at all, let alone be readily made
available.
* The paper lacks a clear statement about what exactly the ChainDB
proposal is attempting to accomplish, and what ChainDB attempts to
prevent from happening. Are we trying to prove that data existed before
a certain time? (timestamping) Are we trying to prove that data reached
a certain audience? (proof-of-publication) Are we trying to come to
consensus on some type of mapping? (key:value consensus) What are we
assuming from miners? Might miners attempt to censor ChainDB
transactions? For instance you say In the second rule, applying an
unpredictable order for selecting the best chain mitigates certain
attacks by Bitcoin miners but you don't say what those attacks are. A
key question related to that is whether or not the ChainDB chains are or
are not private, both recent and historical history.
* A comprehensive ordering of all transactions also makes it possible
to select a block even when some blocks are being withheld. Keep in
mind that what has been withheld depends on what blocks you have
access too; from the point of view of one ChainDB user the withheld
blocks may be the blocks another ChainDB user has access too and
vice-versa. Again, the Bitcoin consensus is a way to prove publication
of data with strong sybil attack detection - the cost to sybil attack
ChainDB will be quite low in many situations as miners have the
priviledged position of having very low costs to include a transaction.
* To minimize the risk that a builder loses bitcoin in the bidding
process, builders coordinate to select a common UTXO that all bid
transactions use as an input. In so doing, bid transactions are created
such that they deliberately conflict. This is a clever idea; I believe
Jeff Garzik deserves credit for this. (his auction proposal) Note too
that with SIGHASH_ANYONECANPAY the consensus scheme could be arranged
such that anyone can also add additional funds to a proposed consensus
that they agree with. Better yet, with SIGHASH_SINGLE by stacking
additional inputs to the transaction you would ensure all bids end up in
the same transaction, simplifying the consensus logic. (otherwise the
total bid is the sum of potentially multiple transactions sacrificing
funds in support of the same consensus)
* Speaking of, proof-of-sacrifice or proof-of-burn is the common term
used for a cryptographically provable expenditure. (e.g. for a fidelity
bond(3)) Although in this case, it's not a true sacrifice as fee-paying
transactions by themselves can be trivially collected by miners.
* And Factom [8] has advanced the concept of using the Bitcoin block
chain directly for timestamping data Factom goes well beyond simply
timestamping data. (something my much earlier OpenTimestamps project did
among many others) Rather Factom acts as a proof-of-publication layer
that allows the proving of the negative.(4)
Zookeyv
