diff options
| author | Peter Todd <pete@petertodd.org> | 2015-05-20 02:26:11 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-05-20 06:26:28 +0000 |
| commit | 0f2b969251bd147103e8b23edbecdc52b0c881d9 (patch) | |
| tree | d802c11c8cbed8db874be44fe177655130d95312 | |
| parent | dfec041f7854db25eae9a867adec17aaabb9fed9 (diff) | |
| download | pi-bitcoindev-0f2b969251bd147103e8b23edbecdc52b0c881d9.tar.gz pi-bitcoindev-0f2b969251bd147103e8b23edbecdc52b0c881d9.zip | |
Re: [Bitcoin-development] ChainDB Whitepaper
| -rw-r--r-- | a1/b2b8578a1717a683d539520b81a162238c5439 | 239 |
1 files changed, 239 insertions, 0 deletions
diff --git a/a1/b2b8578a1717a683d539520b81a162238c5439 b/a1/b2b8578a1717a683d539520b81a162238c5439 new file mode 100644 index 000000000..c5a15b914 --- /dev/null +++ b/a1/b2b8578a1717a683d539520b81a162238c5439 @@ -0,0 +1,239 @@ +Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] + helo=mx.sourceforge.net) + by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <pete@petertodd.org>) id 1YuxSW-0005HG-HY + for bitcoin-development@lists.sourceforge.net; + Wed, 20 May 2015 06:26:28 +0000 +Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org + designates 62.13.149.115 as permitted sender) + client-ip=62.13.149.115; envelope-from=pete@petertodd.org; + helo=outmail149115.authsmtp.co.uk; +Received: from outmail149115.authsmtp.co.uk ([62.13.149.115]) + by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) + id 1YuxSU-0003gV-IT for bitcoin-development@lists.sourceforge.net; + Wed, 20 May 2015 06:26:28 +0000 +Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) + by punt18.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t4K6QIKe015797; + Wed, 20 May 2015 07:26:18 +0100 (BST) +Received: from muck (us1x.mullvad.net [199.241.145.219]) + (authenticated bits=128) + by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t4K6QBol057354 + (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); + Wed, 20 May 2015 07:26:15 +0100 (BST) +Date: Wed, 20 May 2015 02:26:11 -0400 +From: Peter Todd <pete@petertodd.org> +To: Eric Martindale <eric@bitpay.com> +Message-ID: <20150520062611.GA11204@muck> +References: <555B613D.8030208@bitpay.com> +MIME-Version: 1.0 +Content-Type: multipart/signed; micalg=pgp-sha256; + protocol="application/pgp-signature"; boundary="J2SCkAp4GZ/dPZZf" +Content-Disposition: inline +In-Reply-To: <555B613D.8030208@bitpay.com> +X-Server-Quench: 1f2c2424-feb9-11e4-9f74-002590a135d3 +X-AuthReport-Spam: If SPAM / abuse - report it at: + http://www.authsmtp.com/abuse +X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR + aAdMdAIUFVQNAgsB AmMbW1NeUlt7WGQ7 agNYcwdZY1RPWwB0 + UklAXVdaExppT1gF fRh/IEYudwBBe3t0 K0RkXHlZEkUsdxV/ + RkxQCDtTN259aWFK VF1RIQRQbQNKfBpM agF+V3ZZYitlM3Bw + LCUyIzs2PDMaJClL TwUKNVcfR1o+VhU8 ThEEMR9nIk0EWygr JgQrMDYB +X-Authentic-SMTP: 61633532353630.1024:706 +X-AuthFastPath: 0 (Was 255) +X-AuthSMTP-Origin: 199.241.145.219/587 +X-AuthVirus-Status: No virus detected - but ensure you scan with your own + anti-virus system. +X-Spam-Score: -1.5 (-) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. + -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for + sender-domain + -0.0 SPF_PASS SPF: sender matches SPF record +X-Headers-End: 1YuxSU-0003gV-IT +Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net> +Subject: Re: [Bitcoin-development] ChainDB Whitepaper +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Wed, 20 May 2015 06:26:28 -0000 + + +--J2SCkAp4GZ/dPZZf +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +Content-Transfer-Encoding: quoted-printable + +On Tue, May 19, 2015 at 09:13:49AM -0700, Eric Martindale wrote: +>=20 +> Hello all, +>=20 +> 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. +>=20 +> Please take a look at the paper here: https://bitpay.com/chaindb.pdf +>=20 +> 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 +------- + +ChainDB has a lot of similarities with my Zookeyv(5) proposal, as well +as some key differences. To recap the idea was to come to consensus on a +key:value mapping, such that there was a well-defined cost to change any +particular k:v pair, and such that 'uncontroversial' key:value pairs +would become more expensive to change over time as latter k:v pairs +would add to the cost to change of previous ones. + +My original proposal was create a DAG of sacrifices, each committing a +key:value pair, and one or more previous nodes. (the case where n=3D1 +being a linear chain) Nodes that set a key:value already assigned would +be considered invalid. For any tip you'd be able to determine a sum +sacrifice, and equally, a sum sacrificed on top of any key:value pair. +In hindsight, the rule set could be extended to all kinds of situations +akin to a blockchain. (as you propose) + +A key question I came up with was whether or not the minimal data +required to prove the shape of the graph be published directly in the +blockchain. e.g. if a node consists of {H(key), H(value), +prev_node_hash[]} do you require those values to be themselves published +in the blockchain, or are they hidden behind a hash? The latter is more +efficient and censorship resistant, while the former makes it possible +to detect possible 51% attacks and outspend them. (Note how this notion +of "reactive security" can be efficiently used to fend off attackers by +outspending them after the fact, while keeping sacrifices low in the +general case; the sacrifice could even be crowdfunded with +SIGHASH_ANYONECANPAY transactions) + + +1) "[Bitcoin-development] Disentangling Crypto-Coin Mining: Timestamping, P= +roof-of-Publication, and Validation" + Peter Todd, Nov 19th, 2013, + http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/ms= +g03307.html + +2) https://github.com/bitcoin/bitcoin/pull/5863 + +3) https://en.bitcoin.it/wiki/Fidelity_bonds + +4) "Factom - Business Processes Secured by Immutable Audit Trails on the Bl= +ockchain" + Paul Snow et. al, Nov 17th 2014, + https://github.com/FactomProject/FactomDocs/blob/master/Factom_Whitepape= +r.pdf + +5) #bitcoin-wizards discussion, May 31st 2013 + +--=20 +'peter'[:-1]@petertodd.org +00000000000000000e7980aab9c096c46e7f34c43a661c5cb2ea71525ebb8af7 + +--J2SCkAp4GZ/dPZZf +Content-Type: application/pgp-signature; name="signature.asc" +Content-Description: Digital signature + +-----BEGIN PGP SIGNATURE----- + +iQGrBAEBCACVBQJVXCkAXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw +MDAwMDAwMDAwMDAwMDAwZTc5ODBhYWI5YzA5NmM0NmU3ZjM0YzQzYTY2MWM1Y2Iy +ZWE3MTUyNWViYjhhZjcvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 +ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udwaQwf/QDE3+r4AVhJxkWz7SLytiqB4 +4PwYWtsLWrPs5uOLiPTFzvWnmVKmqVdtqhPWlLgWyGVfK5OCddyAOVfIghv7hwev +pRILbjBV4UJhyxyUiHk6u3y/rnYMJdzRGQkkyrI8Uwf62nuC9d4apl/b91zCrT9O +1uHvR0YcZ6Dt8eelfQM5MNPWodS7B5jvD3Wa/7sp9u6Da4tSK9dSdYnYu1xGuAPv +zX7eMinS4DKoDCLPYDX+N/+sZBBoUM5JHuYxkpmkIVjFXgAqD3JMWFdgeVrhfAjh +2RHBHZ/h3Tp1hd9PaeFBUz+Ou8HU+HOWMOpjmIp/V0p0ogjGhncKq2VHpxKOow== +=dx7u +-----END PGP SIGNATURE----- + +--J2SCkAp4GZ/dPZZf-- + + |