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 --]
next prev parent 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 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$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=luke@dashjr$(echo .)org \
--cc=natanael.l@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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