diff options
| author | Luke Dashjr <luke@dashjr.org> | 2016-07-31 05:18:18 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2016-07-31 05:18:39 +0000 |
| commit | ac40dd4286e7932309eb21bfa750baae561e750a (patch) | |
| tree | 5e78719446d057366093d364963b5ff56b8b6cd5 | |
| parent | 219afc53938ec6ffeebe0f2a1d623cf0ae5d19f4 (diff) | |
| download | pi-bitcoindev-ac40dd4286e7932309eb21bfa750baae561e750a.tar.gz pi-bitcoindev-ac40dd4286e7932309eb21bfa750baae561e750a.zip | |
Re: [bitcoin-dev] Holdup on Block Alerts / Fraud Proofs ?
| -rw-r--r-- | bd/ea2559151e0bc8524fc0fcbd6318a9998ea087 | 79 |
1 files changed, 79 insertions, 0 deletions
diff --git a/bd/ea2559151e0bc8524fc0fcbd6318a9998ea087 b/bd/ea2559151e0bc8524fc0fcbd6318a9998ea087 new file mode 100644 index 000000000..d7d2caf49 --- /dev/null +++ b/bd/ea2559151e0bc8524fc0fcbd6318a9998ea087 @@ -0,0 +1,79 @@ +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 3B9D1723 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 31 Jul 2016 05:18:39 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 +Received: from zinan.dashjr.org (unknown [192.3.11.21]) + by smtp1.linuxfoundation.org (Postfix) with ESMTP id D0E4613A + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 31 Jul 2016 05:18:38 +0000 (UTC) +Received: from ishibashi.localnet (unknown + [IPv6:2001:470:5:265:61b6:56a6:b03d:28d6]) + (Authenticated sender: luke-jr) + by zinan.dashjr.org (Postfix) with ESMTPSA id A47BD38A17C5; + Sun, 31 Jul 2016 05:18:21 +0000 (UTC) +X-Hashcash: 1:25:160731:bitcoin-dev@lists.linuxfoundation.org::ZgGHAY/8+HsbIFtr:ayX=P +X-Hashcash: 1:25:160731:truthcoin@gmail.com::0t7sCQLULXevhZpp:abJmo +From: Luke Dashjr <luke@dashjr.org> +To: bitcoin-dev@lists.linuxfoundation.org, + Paul Sztorc <truthcoin@gmail.com> +Date: Sun, 31 Jul 2016 05:18:18 +0000 +User-Agent: KMail/1.13.7 (Linux/4.1.18-gentoo; KDE/4.14.20; x86_64; ; ) +References: <1f12e7bd-72d0-3cd9-735c-10689cff29f3@gmail.com> +In-Reply-To: <1f12e7bd-72d0-3cd9-735c-10689cff29f3@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-1" +Content-Transfer-Encoding: 7bit +Message-Id: <201607310518.20489.luke@dashjr.org> +X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,RDNS_DYNAMIC + autolearn=no version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +Subject: Re: [bitcoin-dev] Holdup on Block Alerts / Fraud Proofs ? +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: Sun, 31 Jul 2016 05:18:39 -0000 + +On Saturday, July 30, 2016 11:18:36 PM Paul Sztorc via bitcoin-dev wrote: +> In my view, "alerts" are relatively straightforward: a new OP CODE (details +> below) st. the txn only succeeds if it references invalid block content on +> a "pretender block". +> +> However, my background reading seems to reveal that "fraud proofs" (as they +> are now called) require some kind of tremendous engineering overhaul. Can +> anyone point me to these large problem(s)? + +Essentially this comes down to attackers being able to construct a block for +which invalidity cannot be proven. While you could always show a proof for an +invalid transaction within a well-formed block, you cannot show a proof that a +block is not well-formed. For example, the merkle tree that ought to represent +a set of transactions may be corrupted in such a manner that the transaction +paying Alice can have a SPV proof made, but the links in the merkle path have +no known data (transactions) behind them. This could even be a perfectly valid +block, but with some of the transactions withheld until it is stale - full +nodes and miners cannot accept it without knowing the entire block's +transactions. The only solution to this I am aware of, is for Alice to be told +"hey, block XYZHASH is incomplete and cannot be checked", and then Alice +demands the full block from the attacker. But of course this makes it trivial +to DoS Alice by giving her bogus incomplete-block claims and forcing her to +use the same bandwidth as a full node - which is a major problem if she lacks +the bandwidth to run a full node (presumably her reason for using SPV in the +first place). + +Luke + |