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
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
|
Return-Path: <bfd@cock.lu>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 2864EBED
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 16 Mar 2017 00:25:06 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from cock.li (cock.li [185.100.85.212])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E23E516A
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 16 Mar 2017 00:25:04 +0000 (UTC)
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Spam-Level:
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU autolearn=ham version=3.3.1
MIME-Version: 1.0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cock.lu; s=mail;
t=1489623901; bh=crxzTR2TXDj0MR5EnXHeL+F7Gd7Uv02Nddmw8mbRqDI=;
h=Date:From:To:Subject:In-Reply-To:References:From;
b=dfjzyjYdMBqL+gUMKPV0E5/nORF2fM8rL6ocDERxK6x0UzzsfmL8O+7S/gjtb9Fzo
TW+HC7TLNvIadrMmqQ4tgqd/QnS8qaYn1y9x+3pB3uqK5ZQhuOA7Bk7IQY/Zb/ImG1
MAgevCAy9Oi8OXREA3h4m97HqRPiK2gayBCd63CNGOj5uvpG867iQ4u66oqjIfnsGd
pCAmGqTl5yy8FaT1SN6zRupc7t2bLxsYNgQDJIEek8Qnb3t9lIIN/rDobEG1x/fNo8
HX2HDAol5WZpu5IS6R+c6Av0redYLzgL2z6in3gAoZ1jm+O+EgooFVWmaMACU1YMoA
o28iU4Cpbl4nQ==
Content-Type: text/plain; charset=US-ASCII;
format=flowed
Content-Transfer-Encoding: 7bit
Date: Thu, 16 Mar 2017 11:25:01 +1100
From: bfd@cock.lu
To: Tom Harding <tomh@thinlink.com>, Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <7794520b-43a0-3227-1a68-58d12e432291@thinlink.com>
References: <71d822e413ac457a530e1c367811cc24@cock.lu>
<77b6dd25-0603-a0bd-6a9e-38098e5cb19d@jonasschnelli.ch>
<74aeb4760316b59a3db56c0d16d11f28@cock.lu>
<CACq0ZD7XT_h8ADptKA0uBT7617fvvgh3uGndkc08RZUSQM2yQg@mail.gmail.com>
<f335731c-3928-6694-5ed8-aa1999b401f1@jonasschnelli.ch>
<CAAcC9ysdaK1DqBBRvBM=7uHFnM7WW23R61v68xrAMj3rWJfqdg@mail.gmail.com>
<045843cb19f03888da10d2954cd1c685@cock.lu>
<7794520b-43a0-3227-1a68-58d12e432291@thinlink.com>
Message-ID: <48d3940ab1a2bd53c6e056ce7fbcd361@cock.lu>
X-Sender: bfd@cock.lu
User-Agent: Roundcube Webmail/1.2.3
X-Mailman-Approved-At: Thu, 16 Mar 2017 00:51:22 +0000
Subject: Re: [bitcoin-dev] Committed bloom filters for improved wallet
performance and SPV security
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: Thu, 16 Mar 2017 00:25:06 -0000
Sorry, this is not the case.
Your slides gloss over the simple fact that compact fraud proofs in
Bitcoin aren't possible, and that the "SPV" implemented today bears
absolutely no resemblance in security properties to the version
described in the Bitcoin white paper. In the white paper SPV clients
have the same security as fully validating nodes, in the implementation
of BIP37 they have absolutely no security except the vague hope that
they are not being lied to, and that the chain with the most work they
are seeing is actually valid, both are very weak assumptions.
The suggested solution in no way precludes unconfirmed transactions from
being used with a commitment scheme, my comments and others are just
recognising that they are an almost useless indicator for people who
aren't validating.
During the validationless mining failure around the BIP66 activation
miners produced 6 invalid blocks in a chain, and many more invalid
blocks in isolated bursts for a period lasting several months. Due to
the instability of the network you are completely unreasonable to accept
anything except multiple confirmations, the true number for safety is
probably more like 60 or 120, not 6, or 3, or 1 as some Bitcoin
exchanges use today.
0000000000000000009cc829aa25b40b2cd4eb83dd498c12ad0d26d90c439d99.bin
bad-version(0x00000002)
0000000000000000032527aa796d3672e32e5f85a452d3a584a28fc7efbcd5d0.bin
bad-version(0x00000002)
000000000000000003ae1223f4926ec86100885cfe1484dc52fd67e042a19b12.bin
bad-version(0x00000002)
0000000000000000083cbdbb25c1607527c8f3fdb16f0d048c4439a73b501cb6.bin
bad-version(0x00000002)
00000000000000000954ed93eda1e79e8261137548fa9ccf4d516bb384a3660b.bin
bad-version(0x00000002)
00000000000000000afc9fbe7cfe8a6b50502d509ba626beb2e2d6c15d1d3ee3.bin
bad-version(0x00000002)
00000000000000000b6adf92bc192b3c21210f456ab21b5e46951665c74cfab2.bin
bad-version(0x00000002)
00000000000000000c9bb4a508fff34f5450d9c62ef2cb833e53909a4c549de5.bin
bad-version(0x00000002)
0000000000000000116322b5f25826787b01f7a70fb322837b68dff8216cefc4.bin
bad-version(0x00000002)
000000000000000012aac0664cd8b6cbc3ea485921a05f2c4340f928b0226d3c.bin
bad-version(0x00000002)
"SPV" like you're describing can exist, or validationless mining can
exist, both can not simultaneously.
On 2017-03-16 09:36, Tom Harding via bitcoin-dev wrote:
> Agreed.
>
> In contrast, BIP37 as used today is totally decentralized, and can me
> made much more secure, private, and scalable -- without giving up the
> utility of unconfirmed transactions.
>
> Please don't read into this statement a belief that all the coffees
> should go on the chain, or that the security or privacy of BIP37
> compare favorably to any other particular thing.
>
> https://docs.google.com/presentation/d/13MzUo2iIH9JBW29TgtPMoaMXxeEdanWDfi6SlfO-LlA
>
>
>
> On 1/5/2017 6:04 PM, bfd--- via bitcoin-dev wrote:
>> You might as well replace Bitcoin with a system where these parties
>> sign transactions and skip mining altogether, it would have the same
>> properties and be significantly more effient.
>>
>>
>> On 2017-01-04 23:06, Chris Priest wrote:
>>> On 1/3/17, Jonas Schnelli via bitcoin-dev
>>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>>
>>>> There are plenty, more sane options. If you can't run your own
>>>> full-node
>>>> as a merchant (trivial), maybe co-use a wallet-service with
>>>> centralized
>>>> verification (maybe use two of them), I guess Copay would be one of
>>>> those wallets (as an example). Use them in watch-only mode.
>>>
>>> The best way is to connect to the mempool of each miner and check to
>>> see if they have your txid in their mempool.
>>>
>>> https://www.antpool.com/api/is_in_mempool?txid=334847bb...
>>> https://www.f2pool.com/api/is_in_mempool?txid=334847bb...
>>> https://bw.com/api/is_in_mempool?txid=334847bb...
>>> https://bitfury.com/api/is_in_mempool?txid=334847bb...
>>> https://btcc.com/api/is_in_mempool?txid=334847bb...
>>>
>>> If each of these services return "True", and you know those services
>>> so not engage in RBF, then you can assume with great confidence that
>>> your transaction will be in the next block, or in a block very soon.
>>> If any one of those services return "False", then you must assume
>>> that
>>> it is possible that there is a double spend floating around, and that
>>> you should wait to see if that tx gets confirmed. The problem is that
>>> not every pool runs such a service to check the contents of their
>>> mempool...
>>>
>>> This is an example of mining centralization increasing the security
>>> of
>>> zero confirm. If more people mined, this method will not work as well
>>> because it would require you to call the API of hundreds of different
>>> potential block creators.
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
