summaryrefslogtreecommitdiff
path: root/e2/bbe0c0a322b7b10862b6599a21e063ac11cd6c
blob: 8faf832d499ce7c12617e629bdd6081a18f97819 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
Return-Path: <pete@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 5862C7A9
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 28 Jan 2017 18:30:10 +0000 (UTC)
X-Greylist: delayed 00:07:12 by SQLgrey-1.7.6
Received: from outmail148098.authsmtp.com (outmail148098.authsmtp.com
	[62.13.148.98])
	by smtp1.linuxfoundation.org (Postfix) with ESMTP id 8E8C6156
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 28 Jan 2017 18:30:09 +0000 (UTC)
Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232])
	by punt21.authsmtp.com (8.14.2/8.14.2/) with ESMTP id v0SIU1YX043513;
	Sat, 28 Jan 2017 18:30:01 GMT
Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com
	[52.5.185.120]) (authenticated bits=0)
	by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id v0SITxIf064366
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 28 Jan 2017 18:30:00 GMT
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by petertodd.org (Postfix) with ESMTPSA id E1B434009A;
	Sat, 28 Jan 2017 18:29:56 +0000 (UTC)
Date: Sat, 28 Jan 2017 18:29:32 +0000
In-Reply-To: <CAAt2M183=L=9N3HKVgGbsFbug4LWkGfMQzzcDQu9xxMJL+L1oA@mail.gmail.com>
References: <201701270107.01092.luke@dashjr.org> <20170127212810.GA5856@nex>
	<CAAy62_KUSNTjivwJT87K9f1c=k-6gdaLXEBJjcy2KK+uLSTWDA@mail.gmail.com>
	<201701280403.05558.luke@dashjr.org>
	<CAAt2M183=L=9N3HKVgGbsFbug4LWkGfMQzzcDQu9xxMJL+L1oA@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: multipart/signed; boundary="----WBMA1F7SJOO6FKDF7QIWA1G4Z1SPBW"; 
	protocol="application/pgp-signature"; micalg="pgp-sha512"
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>
From: Peter Todd <pete@petertodd.org>
Message-ID: <A6A9E83E-6A5A-4583-A4E3-A52DF33DCF4F@petertodd.org>
X-Server-Quench: c757f4cc-e587-11e6-829f-00151795d556
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
	aQdMdAoUElQaAgsB AmEbWlxeU117WWM7 bghPaBtcak9QXgdq
	T0pMXVMcUgULeHhJ f0geVB1xcQMIeXxx Z0UsDXdeWxJ+JhVg
	F0tcEnAHZDJmdWgd WRZFdwNVdQJNdxoR b1V5GhFYa3VsNCMk
	FAgyOXU9MCtqYBhV WAwAZVIbW0oFGSQ/ AgoPGTwzEEFNbQQL NHQA
X-Authentic-SMTP: 61633532353630.1037:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 52.5.185.120/25
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
	anti-virus system.
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Three hardfork-related BIPs
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: Sat, 28 Jan 2017 18:30:10 -0000

------WBMA1F7SJOO6FKDF7QIWA1G4Z1SPBW
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
 charset=utf-8



On 28 January 2017 02:36:16 GMT-08:00, Natanael via bitcoin-dev <bitcoin-d=
ev@lists=2Elinuxfoundation=2Eorg> wrote:
>Den 28 jan=2E 2017 05:04 skrev "Luke Dashjr via bitcoin-dev" <
>bitcoin-dev@lists=2Elinuxfoundation=2Eorg>:
>
>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=2E 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=2E 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=2E
>
>
>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=2E 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=2E

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 necessa=
ry to prove the fraud in the first place=2E

What you actually need are validity challenges, where someone makes a chal=
lenge claiming that part of the block is invalid=2E A failure to meet the c=
hallenge with proof that the rules are followed is considered defacto evide=
nce of fraud=2E

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=2E Even if val=
idity challenges work, they also don't solve censorship: a world of nodes i=
n large datacenters is a world where it's very easy to force the few Bitcoi=
n nodes remaining to follow AML/KYC rules for instance, a risk we wouldn't =
be able to mitigate with a PoW change=2E
------WBMA1F7SJOO6FKDF7QIWA1G4Z1SPBW
Content-Type: application/pgp-signature; name="signature.asc"
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iQE9BAABCgAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJYjOMM
AAoJEGOZARBE6K+yz4MH/iL2PdngP5Z2aKGi6BbafcnlMqGfGGcNiXQAsth7skmp
vDW7qj2YsCYpDbv9YzvcUAfRBFzr1y/pgPfaH++vtoe6E0JXKPL3uq9897ztK9oS
HQsB0wnY3cz8YndOPYTuGq3RyUV4F80naiPD3uaybSFnwFYdBua/vXiSbMEgRBai
KHopVxuqmYBWo8XPaot3Ezo4zNooyXWD/1EcewrwMU2VCw6XPmYhoDMcaSaZNQGk
c9fvTazrWwQce2zJ81ouMaO6Z3tqxUYnKg2vB/iWZVXVU6fc9ENOCjajfHy/Gdnq
I88tg+uinWH2mh1AkGwDEmPg0l2y4B2aSIPF7o6kwvY=
=2eLt
-----END PGP SIGNATURE-----

------WBMA1F7SJOO6FKDF7QIWA1G4Z1SPBW--