From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 To: Eric Martindale 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 Subject: Re: [Bitcoin-development] ChainDB Whitepaper X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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--