summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorLuke Dashjr <luke@dashjr.org>2017-01-28 19:43:48 +0000
committerbitcoindev <bitcoindev@gnusha.org>2017-01-28 19:45:01 +0000
commita739eb1dcb0766c1417e601505655dc47a3ae9cb (patch)
tree1cf3398f6a053d87aa91a9c67dc083fa991f5c14
parent42dab80c51b155c8510da8fc5741e7ae010c76ca (diff)
downloadpi-bitcoindev-a739eb1dcb0766c1417e601505655dc47a3ae9cb.tar.gz
pi-bitcoindev-a739eb1dcb0766c1417e601505655dc47a3ae9cb.zip
Re: [bitcoin-dev] Three hardfork-related BIPs
-rw-r--r--9b/72e64aee8c3cb4c573c0f3b55c84a17d430c3d96
1 files changed, 96 insertions, 0 deletions
diff --git a/9b/72e64aee8c3cb4c573c0f3b55c84a17d430c3d b/9b/72e64aee8c3cb4c573c0f3b55c84a17d430c3d
new file mode 100644
index 000000000..b2411e5c8
--- /dev/null
+++ b/9b/72e64aee8c3cb4c573c0f3b55c84a17d430c3d
@@ -0,0 +1,96 @@
+Return-Path: <luke@dashjr.org>
+Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
+ [172.17.192.35])
+ by mail.linuxfoundation.org (Postfix) with ESMTPS id 946438EE
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Sat, 28 Jan 2017 19:45:01 +0000 (UTC)
+X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
+Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21])
+ by smtp1.linuxfoundation.org (Postfix) with ESMTP id E389714D
+ for <bitcoin-dev@lists.linuxfoundation.org>;
+ Sat, 28 Jan 2017 19:45:00 +0000 (UTC)
+Received: from ishibashi.localnet (unknown
+ [IPv6:2001:470:5:265:a45d:823b:2d27:961c])
+ (Authenticated sender: luke-jr)
+ by zinan.dashjr.org (Postfix) with ESMTPSA id 1544E38A0087;
+ Sat, 28 Jan 2017 19:43:51 +0000 (UTC)
+X-Hashcash: 1:25:170128:natanael.l@gmail.com::L0DQGrovLa4AHXS=:cYl8w
+X-Hashcash: 1:25:170128:bitcoin-dev@lists.linuxfoundation.org::P5bOZxpTJVSQDFD+:E35T
+X-Hashcash: 1:25:170128:andrew.johnson83@gmail.com::XzSn2jSIbhL5tLaP:bk+m=
+From: Luke Dashjr <luke@dashjr.org>
+To: Natanael <natanael.l@gmail.com>
+Date: Sat, 28 Jan 2017 19:43:48 +0000
+User-Agent: KMail/1.13.7 (Linux/4.4.39-gentoo; KDE/4.14.24; x86_64; ; )
+References: <201701270107.01092.luke@dashjr.org>
+ <201701280403.05558.luke@dashjr.org>
+ <CAAt2M183=L=9N3HKVgGbsFbug4LWkGfMQzzcDQu9xxMJL+L1oA@mail.gmail.com>
+In-Reply-To: <CAAt2M183=L=9N3HKVgGbsFbug4LWkGfMQzzcDQu9xxMJL+L1oA@mail.gmail.com>
+X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F
+X-PGP-Key-ID: BD02942421F4889F
+X-PGP-Keyserver: hkp://pgp.mit.edu
+MIME-Version: 1.0
+Content-Type: Text/Plain;
+ charset="iso-8859-15"
+Content-Transfer-Encoding: 7bit
+Message-Id: <201701281943.49975.luke@dashjr.org>
+X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD
+ 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 <bitcoin-dev@lists.linuxfoundation.org>
+Subject: Re: [bitcoin-dev] Three hardfork-related BIPs
+X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
+X-Mailman-Version: 2.1.12
+Precedence: list
+List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
+List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
+ <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
+List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
+List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
+List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
+List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
+ <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
+X-List-Received-Date: Sat, 28 Jan 2017 19:45:01 -0000
+
+On Saturday, January 28, 2017 10:36:16 AM Natanael wrote:
+> Den 28 jan. 2017 05:04 skrev "Luke Dashjr via bitcoin-dev" <
+> bitcoin-dev@lists.linuxfoundation.org>:
+> > Satoshi envisioned a system where full nodes could publish proofs of
+> > invalid blocks that would be automatically verified by SPV nodes and used
+> > to ensure even they maintained the equivalent of full node security so
+> > long as they were not isolated. But as a matter of fact, this vision has
+> > proven impossible, and there is to date no viable theory on how it might
+> > be fixed. As a result, the only way for nodes to have full-node-security
+> > is to actually be a true full node, and therefore the plan of only having
+> > full nodes in datacenters is simply not realistic without transforming
+> > Bitcoin into a centralised system.
+>
+> Beside Zero-knowledge proofs, which is capable of proving much so more than
+> just validity, there are multi types of fraud proofs that only rely on the
+> format of the blocks. Such as publishing the block header + the two
+> colliding transactions included in it (in the case of double spending), or
+> if the syntax or logic is broken then you just publish that single
+> transaction.
+
+Why would someone malicious follow the format sufficiently to make those
+proofs possible?
+
+> There aren't all that many cases where fraud proofs are unreasonably large
+> for a networked system like in Bitcoin. If Zero-knowledge proofs can be
+> applied securely, then I can't think of any exceptions at all for when the
+> proofs would be unmanageable. (Remember that full Zero-knowledge proofs can
+> be chained together!)
+
+ZK proofs do to a large extent simplify the situation, but still fail in one
+case (and one case is all an attacker needs, since he can choose how he
+attacks). Specifically, the attacker can create a block which is 100% well-
+formed and valid (or not - nobody will really ever know), and simply withhold
+a single transaction in it, such that nobody ever has the complete block's
+data. Full nodes will of course not accept such a block until they have the
+complete data to validate, but they similarly cannot prove it is invalid
+without the complete data, and any non-full nodes cannot prove there is data
+missing without fetching and (to an extent) checking the entire block
+themselves.
+
+Luke
+