public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org, Paul Sztorc <truthcoin@gmail.com>
Subject: Re: [bitcoin-dev] Holdup on Block Alerts / Fraud Proofs ?
Date: Sun, 31 Jul 2016 05:18:18 +0000	[thread overview]
Message-ID: <201607310518.20489.luke@dashjr.org> (raw)
In-Reply-To: <1f12e7bd-72d0-3cd9-735c-10689cff29f3@gmail.com>

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


      parent reply	other threads:[~2016-07-31  5:18 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-30 23:18 [bitcoin-dev] Holdup on Block Alerts / Fraud Proofs ? Paul Sztorc
2016-07-31  1:31 ` Bryan Bishop
2016-07-31  5:18 ` Luke Dashjr [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201607310518.20489.luke@dashjr.org \
    --to=luke@dashjr.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=truthcoin@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox