public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: bfd@cock.lu
To: Tom Harding <tomh@thinlink.com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Committed bloom filters for improved wallet performance and SPV security
Date: Thu, 16 Mar 2017 11:25:01 +1100	[thread overview]
Message-ID: <48d3940ab1a2bd53c6e056ce7fbcd361@cock.lu> (raw)
In-Reply-To: <7794520b-43a0-3227-1a68-58d12e432291@thinlink.com>

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


  reply	other threads:[~2017-03-16  0:25 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-09  8:26 [bitcoin-dev] Committed bloom filters for improved wallet performance and SPV security bfd
2016-05-09  8:57 ` Gregory Maxwell
2016-05-11 20:06 ` Bob McElrath
2016-05-11 20:29   ` Bob McElrath
2016-07-28 21:07     ` Leo Wandersleb
2017-01-06 22:07       ` Erik Aronesty
2017-01-03 20:24     ` bfd
     [not found] ` <77b6dd25-0603-a0bd-6a9e-38098e5cb19d@jonasschnelli.ch>
2017-01-03 20:18   ` bfd
2017-01-03 22:18     ` Aaron Voisine
2017-01-03 22:28       ` bfd
2017-01-03 23:06       ` adiabat
2017-01-03 23:46         ` Aaron Voisine
2017-01-04  0:10           ` bfd
2017-01-04  0:36             ` Aaron Voisine
2017-01-04  6:06               ` Eric Voskuil
2017-01-04 16:13         ` Leo Wandersleb
2017-01-04  7:47       ` Jonas Schnelli
2017-01-04  8:56         ` Aaron Voisine
2017-01-04 10:13           ` Jorge Timón
2017-01-04 11:00             ` Adam Back
2017-01-06  2:15           ` bfd
2017-01-06  7:07             ` Aaron Voisine
2017-01-05  7:06         ` Chris Priest
2017-01-05  7:45           ` Eric Voskuil
2017-01-05 14:48             ` Christian Decker
2017-01-06 20:15             ` Chris Priest
2017-01-06 21:35               ` James MacWhyte
2017-01-06 21:50                 ` Eric Voskuil
2017-01-06  2:04           ` bfd
2017-03-15 22:36             ` Tom Harding
2017-03-16  0:25               ` bfd [this message]
2017-03-16 15:05                 ` Tom Harding
2017-02-17  0:28 ` Chris Belcher
2017-04-01 23:49   ` bfd

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=48d3940ab1a2bd53c6e056ce7fbcd361@cock.lu \
    --to=bfd@cock.lu \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=tomh@thinlink.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