From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id ABFFC16B2 for ; Fri, 18 Sep 2015 20:17:45 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D3B77227 for ; Fri, 18 Sep 2015 20:17:44 +0000 (UTC) Received: by wicfx3 with SMTP id fx3so77912885wic.1 for ; Fri, 18 Sep 2015 13:17:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZbAL2f7yrhPEZenPkXsNxBVQwbybxJ2KwEQGzQk8hWk=; b=G5rKrUXJfnW0ubt2U2ieyfNRS9J1IAiRlhw9Nsw/dxvU2uyZH5Of1W7+E/Dj8LsjAS adVsf+xE4v6i3l0Y2+OKHD5bYBN8R7dSk8G5iswuwpIQu6Ayu03ovoAbx9Hz+VUua62f LWXSA3ZSK8bP57He4Diy3crAzf25uUqyTof+MZ10UOHXUpUUafxB8rJ8WnSpBjWS+JjG Dy/oe9Ni22W6BUnnN6e1ee9i59+1oFIZPOdoESPTQgZI0aYQw9fkX8XxRK2UIsYmvEQ3 5cezbNky8M7yaD4zl71TGABVQoPS1hY1A01axE1LE0FQMGmjAD1wZwjkN8bhuW3h5S6i ziGw== X-Received: by 10.194.175.104 with SMTP id bz8mr9454419wjc.42.1442607463476; Fri, 18 Sep 2015 13:17:43 -0700 (PDT) Received: from [192.168.1.33] ([212.60.121.11]) by smtp.gmail.com with ESMTPSA id p10sm10558358wjx.7.2015.09.18.13.17.42 (version=TLS1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 18 Sep 2015 13:17:42 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: =?utf-8?Q?Rune_Kj=C3=A6r_Svendsen?= In-Reply-To: <55FC6951.9010704@gmail.com> Date: Fri, 18 Sep 2015 22:17:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5D55F6EC-801B-4607-882F-B76CF57298B1@gmail.com> <55FC6951.9010704@gmail.com> To: Patrick Strateman X-Mailer: Apple Mail (2.2104) X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, MIME_QP_LONG_LINE, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] Hash of UTXO set as consensus-critical X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2015 20:17:45 -0000 There are a couple of points I=E2=80=99d like to address. Firstly, yes, >50% attacks are a problem for Bitcoin. Bitcoin does not = function if the majority of mining power is dishonest. There is no way = around that. It=E2=80=99s how proof-of-work functions. And if we lose = proof-of-work, we lose Bitcoin. Secondly, I=E2=80=99m not suggesting that UTXO set hashes *replace* = block hashes, or even that it should be in the block header (probably in = the coinbase somewhere). I suggest it as an *addition* to the existing = consensus rules. Full nodes can still verify the chain with the added = step of hashing the UTXO set for every block. Of course, this can easily = be deferred to after proof-of-work has been verified already, such that = no work is wasted. Unless a 51% attack is in effect. But I argue that = this is a moot point, since Bitcoin is useless anyway under such = circumstances. Lastly, I=E2=80=99m not suggesting miners discard the blockchain = history. A miner has an incentive to be absolutely sure that the chain = he=E2=80=99s building on is the right one. If he=E2=80=99s wrong, he = loses money/income. There=E2=80=99s simply no reason for a professional = miner *not* to do the full initial sync, which only needs to be done = once. Non-miners, who just want to check the balance of their wallet, = however, really don=E2=80=99t need to retrieve information about Hal = Finney sending bitcoins to Satoshi in 2010. In any case, this practice = isn=E2=80=99t sustainable. In the end, it isn=E2=80=99t possible to control whether a miner = verifies the entire blockchain anyway (anyone can send the UTXO set over = the wire). Not letting the proof-of-work cover the UTXO hash doesn=E2=80=99= t solve this problem, it only makes it impossible to know whether a = given UTXO set is the one that the majority is mining on without = retrieving the entire blockchain, and doing the verification yourself. = People can choose to skip that regardless of what we do. Furthermore, all nodes have the option of deciding which level of = security they want. We=E2=80=99re not lessening security of the = protocol, we=E2=80=99re strengthening the security of something that=E2=80= =99s already possible to do (build on top of an unverified blockchain), = but we=E2=80=99d rather want that people not do. /Rune > On 18 Sep 2015, at 21:43, Patrick Strateman via bitcoin-dev = wrote: >=20 > Full nodes using UTXO set commitments is a change to the bitcoin > security model. >=20 > Currently an attacker with >50% of the network hashrate can rewrite = history. >=20 > If full nodes rely on UTXO set commitments such an attacker could = create > an infinite number of bitcoins (as in many times more than the current > 21 million bitcoin limit). >=20 > Before we consider mechanisms for UTXO set commitments, we should > seriously discuss whether the security model reduction is reasonable. >=20 > On 09/18/2015 12:05 PM, Rune Kj=C3=A6r Svendsen via bitcoin-dev wrote: >> Currently, when a new node wants to join the network, it needs to = retrieve the entire blockchain history, starting from January 2009 and = up until now, in order to derive a UTXO set that it can verify new = blocks/transactions against. With a blockchain size of 40GB and a UTXO = size of around 1GB, the extra bandwidth required is significant, and = will keep increasing indefinitely. If a newly mined block were to = include the UTXO set hash of the chain up until the previous block =E2=80=94= the hash of the UTXO set on top of which this block builds =E2=80=94 = then new nodes, who want to know whether a transaction is valid, would = be able to acquire the UTXO set in a trustless manner, by only verifying = proof-of-work headers, and knowing that a block with an invalid UTXO set = hash would be rejected. >>=20 >> I=E2=80=99m not talking about calculating a complicated tree = structure from the UTXO set, which would put further burden on already = burdened Bitcoin Core nodes. We simply include the hash of the current = UTXO set in a newly created block, such that the transactions in the new = block build *on top* of the UTXO set whose hash is specified. This = actually alleviates Bitcoin Core nodes, as it will now become possible = for nodes without the entire blockchain to answer SPV queries (by = retrieving the UTXO set trustlessly and using this to answer queries). = It also saves bandwidth for Bitcore Core nodes, who only need to send = roughly 1GB of data, in order to synchronise a node, rather than 40GB+. = I will continue to run a full Bitcoin Core node, saving the entire = blockchain history, but it shouldn=E2=80=99t be a requirement to hold = the entire transaction history in order to start verifying new = transactions. >>=20 >> As far as I can see, this also forces miners to actually maintain an = UTXO set, rather than just build on top of the chain with the most = proof-of-work. Producing a UTXO set and verifying a block against a = chain is the same thing, so by including the hash of the UTXO set we = force miners to verify the block that they want to build on top of. >>=20 >> Am I missing something obvious, because as far as I can see, this = solves the problem of quadratic time complexity for initial sync: = http://www.youtube.com/watch?v=3DTgjrS-BPWDQ&t=3D2h02m12s >>=20 >> The only added step to verifying a block is to hash the UTXO set. So = it does require additional computation, but most modern CPUs have a = SHA256 throughput of around 500 MB/s, which means it takes only two = seconds to hash the UTXO set. And this can be improved further (GPUs can = do 2-3 GB/s). A small sacrifice for the added ease of initial syncing, = in my opinion. >>=20 >> /Rune >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >=20 >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev