From: Peter Todd <pete@petertodd•org>
To: Luke Dashjr <luke@dashjr•org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Three hardfork-related BIPs
Date: Sat, 28 Jan 2017 16:54:00 -0500 [thread overview]
Message-ID: <20170128215400.GA1246@fedora-23-dvm> (raw)
In-Reply-To: <201701281943.49975.luke@dashjr.org>
[-- Attachment #1: Type: text/plain, Size: 2795 bytes --]
On Sat, Jan 28, 2017 at 07:43:48PM +0000, Luke Dashjr via bitcoin-dev wrote:
> On Saturday, January 28, 2017 10:36:16 AM Natanael wrote:
> > 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.
So, in that particular type of case, the ZK proof may show that the block
itself is valid and follows all the rules; there'd be no need to get the block
data to know that.
The issue here is other miners being able to mine. Exactly what happens here
depends on the exact construction of the ZK proofs, but at best the missing
data will mean that part of the UTXO state can no longer be updated by other
miners, and thus they can't mine all transactions; at worst they'd be
completely preventing from mining at all.
This is why part of the economic pressure that users exert on miners is
subverted by SPV/lite-clients: users that can transact without sufficient
blockchain data to allow others to mine aren't exerting pressure on miners to
allow other miners to mine - particularly new entrants to mining. In that
respect, ZK proofs are in fact quite harmful to the security of the system if
applied naively.
Equally, I'll point out that if ZK proofs can be made sufficiently powerful to
do all the above, genuinely scalable sharded systems like my own Treechains are
far easier to implement, changing the discussion entirely. Currently it is far
from proven that ZK proofs can in fact accomplish this; I hear that Zcash will
soon have to upgrade their ZK-SNARK scheme due to advances in cryptographic
analysis that may result in a full system break in the near future. We really
don't want to be depending on that technology for Bitcoin's security until
events like that become much less common.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
next prev parent reply other threads:[~2017-01-28 21:54 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
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 [this message]
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=20170128215400.GA1246@fedora-23-dvm \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=luke@dashjr$(echo .)org \
/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