public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd.org>
To: Natanael <natanael.l@gmail.com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>,
	Natanael via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>,
	Luke Dashjr <luke@dashjr.org>,
	Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Three hardfork-related BIPs
Date: Sat, 28 Jan 2017 18:29:32 +0000	[thread overview]
Message-ID: <A6A9E83E-6A5A-4583-A4E3-A52DF33DCF4F@petertodd.org> (raw)
In-Reply-To: <CAAt2M183=L=9N3HKVgGbsFbug4LWkGfMQzzcDQu9xxMJL+L1oA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2116 bytes --]



On 28 January 2017 02:36:16 GMT-08:00, Natanael via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> 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.

That's a perfect example of why fraud proofs aren't as secure as expected: the miner who created such a block wouldn't even give you the data necessary to prove the fraud in the first place.

What you actually need are validity challenges, where someone makes a challenge claiming that part of the block is invalid. A failure to meet the challenge with proof that the rules are followed is considered defacto evidence of fraud.

But validity challenges don't scale well and pose DoS attacks issues; it's far from clear that they can be implemented in a useful way. Even if validity challenges work, they also don't solve censorship: a world of nodes in large datacenters is a world where it's very easy to force the few Bitcoin nodes remaining to follow AML/KYC rules for instance, a risk we wouldn't be able to mitigate with a PoW change.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 500 bytes --]

  reply	other threads:[~2017-01-28 18:30 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-27  1:06 [bitcoin-dev] Three hardfork-related BIPs Luke Dashjr
     [not found] ` <CAAy62_L-mLhokVy4_WeLBVnxM0Y76dtFBaaDrRvQozxw=J1Ctw@mail.gmail.com>
     [not found]   ` <CAAy62_+1OjF3V5g4wpOyW0KtNGodddJu_cxOfG-f+8LB7D=rPA@mail.gmail.com>
2017-01-27  3:04     ` Andrew Johnson
2017-01-27  4:14       ` Luke Dashjr
     [not found]         ` <CAAy62_LHtrx7k73kznMpPvheA--0T9YiHkjHArf2KK0Qt+ViUg@mail.gmail.com>
2017-01-27  6:13           ` Andrew Johnson
     [not found]             ` <CAMZUoKnxqxvPQehdWo1ZaHB-1-od4cHvJRDTmF5x7ty1CdLbUQ@mail.gmail.com>
     [not found]               ` <CAMZUoK=eb3jgA7Rwt38tvZt0tYk7gRVPc_2=HUWg1L_vaD93uw@mail.gmail.com>
2017-01-27 20:34                 ` Russell O'Connor
2017-01-27 20:47                   ` Greg Sanders
2017-01-27 21:28                     ` Christian Decker
2017-01-27 23:53                       ` Andrew Johnson
2017-01-28  4:03                         ` Luke Dashjr
2017-01-28 10:36                           ` Natanael
2017-01-28 18:29                             ` Peter Todd [this message]
2017-01-29 19:15                               ` Tom Harding
2017-01-29 19:37                                 ` Eric Voskuil
2017-02-11 15:26                                   ` Staf Verhaegen
2017-01-29 19:39                                 ` David Vorick
2017-01-28 19:43                             ` Luke Dashjr
2017-01-28 21:54                               ` Peter Todd
2017-02-06 16:24                           ` mbtc-dev
2017-02-07 20:32                             ` Eric Voskuil
2017-01-28 18:22                         ` Peter Todd
2017-01-27  4:21 ` Johnson Lau
2017-01-27 18:54 ` t. khan
2017-01-27 12:12 Daniele Pinna

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=A6A9E83E-6A5A-4583-A4E3-A52DF33DCF4F@petertodd.org \
    --to=pete@petertodd.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=luke@dashjr.org \
    --cc=natanael.l@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