From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 552FBCC5 for ; Fri, 6 Jan 2017 21:36:11 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f181.google.com (mail-qk0-f181.google.com [209.85.220.181]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 83FB8108 for ; Fri, 6 Jan 2017 21:36:10 +0000 (UTC) Received: by mail-qk0-f181.google.com with SMTP id u25so472367428qki.2 for ; Fri, 06 Jan 2017 13:36:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=nGgbiCehw6B1dow/1Zp+D2QebCMBInbO7SR8v/lqIFM=; b=QT8W3kHCZw8XH1hcIWIK90G02JXG11cVPzBPeL9fArZMX/J1U6LALx0xfc5D896EkX 33M9dl+Kx5j3wmYDOyeWo0NA6oTmrJl1MwV2a7pUSmPWdpP8WBISyifAhLALbYCh1yvs zpcy99/C/J2hON7tzDH2dIDkdzPHqTD24wHbdJiLimEGO3m7G/6O25Zq2/4DTSh6pi0O Szi2crt0R+8CMMzJCgs2tIjqCtzSzcmCY1pWibqUwsUkKaxjHIFwF3mgaqruwNl9jU3M NeZVk1x7SOdE3EL7rZnuU2LeEH2Tc9//mVJ3xzQPPcEVoF9dqNW06hdiJGIla5z3Mtw6 R68A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=nGgbiCehw6B1dow/1Zp+D2QebCMBInbO7SR8v/lqIFM=; b=AAkvMF5O2Db0xkCokvcqb1jdmWTFqMmistU7srMcLCuK8fvKdZX7WfDqIbnKL4FL0q rA5cTzj270wv8T4unKcnvkNuMRHPNS0Fq+8FkpFfccK4Ujwxj40L/8zTaOOJztD4p926 Xkiw3W4YPXwOly4ZXfre8Trd4mbL2Ho/IUbCFoutgmtqDX1Zff4oenoE9W1VG8/ERXmk HAbi6RpfycNjVUBJ5rdaxpnfM9vq6dG85AzjcrDO4D6E/meodeAPajb2wGPQp7zLAH63 xP4M2ksXNWHR5TXeyJqX+CN5shY3hN5G8KQ1QO5OLB2XiAVFmLyj6t1JyC1oS233Th3r tiYw== X-Gm-Message-State: AIkVDXIbGvo/4ODad96K+FHlpkvTP07R+y+GtBNDUYjxl2DDJrVC1gncRjM6gGAISGUGuFCN7vsumcGtGz5iZw== X-Received: by 10.55.169.216 with SMTP id s207mr14072877qke.211.1483738569548; Fri, 06 Jan 2017 13:36:09 -0800 (PST) MIME-Version: 1.0 References: <71d822e413ac457a530e1c367811cc24@cock.lu> <77b6dd25-0603-a0bd-6a9e-38098e5cb19d@jonasschnelli.ch> <74aeb4760316b59a3db56c0d16d11f28@cock.lu> <347a0909-affd-da0c-f7f8-09fa76bcb279@voskuil.org> In-Reply-To: From: James MacWhyte Date: Fri, 06 Jan 2017 21:35:58 +0000 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=94eb2c0544d260a879054573ce0f X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 21:36:11 -0000 --94eb2c0544d260a879054573ce0f Content-Type: text/plain; charset=UTF-8 It's my opinion that the purpose of this list and bitcoin protocol development in general is to build the base functionality that other companies and individuals require to provide usability to the end-user. The 0-conf debate is a UX issue. If end users shouldn't rely on 0-conf, it is up to wallet developers to hide 0-conf transactions or mark them appropriately. Instead of using this list to debate what wallet designers should or shouldn't do, we should just provide the tools and "let the market sort it out". If wallet developers start getting inundated with complaints that 0-conf transactions are causing confusion and loss, they will find a solution. If the tools they require for the solution don't exist, they will come to this list to request action. Am I wrong? On Fri, Jan 6, 2017 at 12:16 PM Chris Priest via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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 wrote: > > On 01/04/2017 11:06 PM, Chris Priest via bitcoin-dev wrote: > >> On 1/3/17, Jonas Schnelli via bitcoin-dev > >> 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 > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --94eb2c0544d260a879054573ce0f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It's my opinion that the purpose of this list and bitc= oin protocol development in general is to build the base functionality that= other companies and individuals require to provide usability to the end-us= er. The 0-conf debate is a UX issue. If end users shouldn't rely on 0-c= onf, it is up to wallet developers to hide 0-conf transactions or mark them= appropriately. Instead of using this list to debate what wallet designers = should or shouldn't do, we should just provide the tools and "let = the market sort it out". If wallet developers start getting inundated = with complaints that 0-conf transactions are causing confusion and loss, th= ey will find a solution. If the tools they require for the solution don'= ;t exist, they will come to this list to request action.

Am I wrong?

On F= ri, Jan 6, 2017 at 12:16 PM Chris Priest via bitcoin-dev <bitcoin-dev@lists.linuxfoundatio= n.org> wrote:
Its a method f= or 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<= br class=3D"gmail_msg"> 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&= gt; 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 ce= ntralized
>>> verification (maybe use two of them), I guess Copay would be o= ne 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.a= ntpool.com/api/is_in_mempool?txid=3D334847bb...
>> https://www.f2= pool.com/api/is_in_mempool?txid=3D334847bb...
>> https://bw.com/api/is= _in_mempool?txid=3D334847bb...
>> https://bitfury.c= om/api/is_in_mempool?txid=3D334847bb...
>> https://btcc.com/api= /is_in_mempool?txid=3D334847bb...
>>
>> If each of these services return "True", and you know th= ose services
>> so not engage in RBF, then you can assume with great confidence th= at
>> your transaction will be in the next block, or in a block very soo= n.
>> If any one of those services return "False", then you mu= st assume that
>> it is possible that there is a double spend floating around, and t= hat
>> you should wait to see if that tx gets confirmed. The problem is t= hat
>> not every pool runs such a service to check the contents of their<= br class=3D"gmail_msg"> >> mempool...
>>
>> This is an example of mining centralization increasing the securit= y of
>> zero confirm.
>
> A world connected up to a few web services to determine payment validi= ty
> is an example of a bitcoin security catastrophe.
>
> e
>
>
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linu= xfoundation.org/mailman/listinfo/bitcoin-dev
--94eb2c0544d260a879054573ce0f--