public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Chris Priest <cp368202@ohiou.edu>
To: Eric Voskuil <eric@voskuil.org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Committed bloom filters for improved wallet performance and SPV security
Date: Fri, 6 Jan 2017 12:15:46 -0800	[thread overview]
Message-ID: <CAAcC9ysioO0wZMWxQF1wAzjB7qUyx_6MSbmd-4sh3UtfieVb4Q@mail.gmail.com> (raw)
In-Reply-To: <347a0909-affd-da0c-f7f8-09fa76bcb279@voskuil.org>

Its a method for determining the probability that a valid tx will be
mined in a block before that tx actually gets mined, which is useful
when accepting payments in situations when you can't wait for the full
confirmation. No one is saying all tx validation should be performed
by querying miners mempools, that's ridiculous. Obviously once the tx
gets it's first confirmation, you go back to determining validity the
way you always have. There is no "security catastrophe".

Even if you're running a full node, you can't know for certain that
any given tx will make it into a future block. You can't be certain
the future miner who finally does mine that tx will mine your TXID or
another TXID that spends the same inputs to another address (a double
spend). The only way to actually know for certain is to query every
single large hashpower mempool.

On 1/4/17, Eric Voskuil <eric@voskuil.org> wrote:
> On 01/04/2017 11:06 PM, Chris Priest via bitcoin-dev 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.
>
> A world connected up to a few web services to determine payment validity
> is an example of a bitcoin security catastrophe.
>
> e
>
>


  parent reply	other threads:[~2017-01-06 20:15 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 [this message]
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
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=CAAcC9ysioO0wZMWxQF1wAzjB7qUyx_6MSbmd-4sh3UtfieVb4Q@mail.gmail.com \
    --to=cp368202@ohiou.edu \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=eric@voskuil.org \
    /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