diff options
| author | James MacWhyte <macwhyte@gmail.com> | 2017-01-06 21:35:58 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2017-01-06 21:36:11 +0000 |
| commit | ea7b75e84aa5d22e49108b78b00cf7faa99ba688 (patch) | |
| tree | 135bfe425b286915181b599c897f714911a2ac00 | |
| parent | 3655057d08daaa7f22d911d9a68f4fbc0200cf6b (diff) | |
| download | pi-bitcoindev-ea7b75e84aa5d22e49108b78b00cf7faa99ba688.tar.gz pi-bitcoindev-ea7b75e84aa5d22e49108b78b00cf7faa99ba688.zip | |
Re: [bitcoin-dev] Committed bloom filters for improved wallet performance and SPV security
| -rw-r--r-- | f3/6b9ba5d3f9a6a5dadd1bc5793ee70a2637c3bf | 280 |
1 files changed, 280 insertions, 0 deletions
diff --git a/f3/6b9ba5d3f9a6a5dadd1bc5793ee70a2637c3bf b/f3/6b9ba5d3f9a6a5dadd1bc5793ee70a2637c3bf new file mode 100644 index 000000000..f05474266 --- /dev/null +++ b/f3/6b9ba5d3f9a6a5dadd1bc5793ee70a2637c3bf @@ -0,0 +1,280 @@ +Return-Path: <keatonatron@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 552FBCC5 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + Fri, 6 Jan 2017 21:36:10 +0000 (UTC) +Received: by mail-qk0-f181.google.com with SMTP id u25so472367428qki.2 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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> + <CACq0ZD7XT_h8ADptKA0uBT7617fvvgh3uGndkc08RZUSQM2yQg@mail.gmail.com> + <f335731c-3928-6694-5ed8-aa1999b401f1@jonasschnelli.ch> + <CAAcC9ysdaK1DqBBRvBM=7uHFnM7WW23R61v68xrAMj3rWJfqdg@mail.gmail.com> + <347a0909-affd-da0c-f7f8-09fa76bcb279@voskuil.org> + <CAAcC9ysioO0wZMWxQF1wAzjB7qUyx_6MSbmd-4sh3UtfieVb4Q@mail.gmail.com> +In-Reply-To: <CAAcC9ysioO0wZMWxQF1wAzjB7qUyx_6MSbmd-4sh3UtfieVb4Q@mail.gmail.com> +From: James MacWhyte <macwhyte@gmail.com> +Date: Fri, 06 Jan 2017 21:35:58 +0000 +Message-ID: <CAH+Axy7-Vox0F9EsotiXqCAhs7NGNsHPvnjEEvcx+6Ft+GBHKg@mail.gmail.com> +To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +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 <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: 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 <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 +> > +> > +> _______________________________________________ +> 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 + +<div dir=3D"ltr">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.<div><br></div><div= +>Am I wrong?</div><div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On F= +ri, Jan 6, 2017 at 12:16 PM Chris Priest via bitcoin-dev <<a href=3D"mai= +lto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundatio= +n.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"ma= +rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Its a method f= +or determining the probability that a valid tx will be<br class=3D"gmail_ms= +g"> +mined in a block before that tx actually gets mined, which is useful<br cla= +ss=3D"gmail_msg"> +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<br cla= +ss=3D"gmail_msg"> +by querying miners mempools, that's ridiculous. Obviously once the tx<b= +r class=3D"gmail_msg"> +gets it's first confirmation, you go back to determining validity the<b= +r class=3D"gmail_msg"> +way you always have. There is no "security catastrophe".<br class= +=3D"gmail_msg"> +<br class=3D"gmail_msg"> +Even if you're running a full node, you can't know for certain that= +<br class=3D"gmail_msg"> +any given tx will make it into a future block. You can't be certain<br = +class=3D"gmail_msg"> +the future miner who finally does mine that tx will mine your TXID or<br cl= +ass=3D"gmail_msg"> +another TXID that spends the same inputs to another address (a double<br cl= +ass=3D"gmail_msg"> +spend). The only way to actually know for certain is to query every<br clas= +s=3D"gmail_msg"> +single large hashpower mempool.<br class=3D"gmail_msg"> +<br class=3D"gmail_msg"> +On 1/4/17, Eric Voskuil <<a href=3D"mailto:eric@voskuil.org" class=3D"gm= +ail_msg" target=3D"_blank">eric@voskuil.org</a>> wrote:<br class=3D"gmai= +l_msg"> +> On 01/04/2017 11:06 PM, Chris Priest via bitcoin-dev wrote:<br class= +=3D"gmail_msg"> +>> On 1/3/17, Jonas Schnelli via bitcoin-dev<br class=3D"gmail_msg"> +>> <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" class= +=3D"gmail_msg" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&= +gt; wrote:<br class=3D"gmail_msg"> +>>><br class=3D"gmail_msg"> +>>> There are plenty, more sane options. If you can't run your= + own full-node<br class=3D"gmail_msg"> +>>> as a merchant (trivial), maybe co-use a wallet-service with ce= +ntralized<br class=3D"gmail_msg"> +>>> verification (maybe use two of them), I guess Copay would be o= +ne of<br class=3D"gmail_msg"> +>>> those wallets (as an example). Use them in watch-only mode.<br= + class=3D"gmail_msg"> +>><br class=3D"gmail_msg"> +>> The best way is to connect to the mempool of each miner and check = +to<br class=3D"gmail_msg"> +>> see if they have your txid in their mempool.<br class=3D"gmail_msg= +"> +>><br class=3D"gmail_msg"> +>> <a href=3D"https://www.antpool.com/api/is_in_mempool?txid=3D334847= +bb." rel=3D"noreferrer" class=3D"gmail_msg" target=3D"_blank">https://www.a= +ntpool.com/api/is_in_mempool?txid=3D334847bb.</a>..<br class=3D"gmail_msg"> +>> <a href=3D"https://www.f2pool.com/api/is_in_mempool?txid=3D334847b= +b." rel=3D"noreferrer" class=3D"gmail_msg" target=3D"_blank">https://www.f2= +pool.com/api/is_in_mempool?txid=3D334847bb.</a>..<br class=3D"gmail_msg"> +>> <a href=3D"https://bw.com/api/is_in_mempool?txid=3D334847bb." rel= +=3D"noreferrer" class=3D"gmail_msg" target=3D"_blank">https://bw.com/api/is= +_in_mempool?txid=3D334847bb.</a>..<br class=3D"gmail_msg"> +>> <a href=3D"https://bitfury.com/api/is_in_mempool?txid=3D334847bb."= + rel=3D"noreferrer" class=3D"gmail_msg" target=3D"_blank">https://bitfury.c= +om/api/is_in_mempool?txid=3D334847bb.</a>..<br class=3D"gmail_msg"> +>> <a href=3D"https://btcc.com/api/is_in_mempool?txid=3D334847bb." re= +l=3D"noreferrer" class=3D"gmail_msg" target=3D"_blank">https://btcc.com/api= +/is_in_mempool?txid=3D334847bb.</a>..<br class=3D"gmail_msg"> +>><br class=3D"gmail_msg"> +>> If each of these services return "True", and you know th= +ose services<br class=3D"gmail_msg"> +>> so not engage in RBF, then you can assume with great confidence th= +at<br class=3D"gmail_msg"> +>> your transaction will be in the next block, or in a block very soo= +n.<br class=3D"gmail_msg"> +>> If any one of those services return "False", then you mu= +st assume that<br class=3D"gmail_msg"> +>> it is possible that there is a double spend floating around, and t= +hat<br class=3D"gmail_msg"> +>> you should wait to see if that tx gets confirmed. The problem is t= +hat<br class=3D"gmail_msg"> +>> not every pool runs such a service to check the contents of their<= +br class=3D"gmail_msg"> +>> mempool...<br class=3D"gmail_msg"> +>><br class=3D"gmail_msg"> +>> This is an example of mining centralization increasing the securit= +y of<br class=3D"gmail_msg"> +>> zero confirm.<br class=3D"gmail_msg"> +><br class=3D"gmail_msg"> +> A world connected up to a few web services to determine payment validi= +ty<br class=3D"gmail_msg"> +> is an example of a bitcoin security catastrophe.<br class=3D"gmail_msg= +"> +><br class=3D"gmail_msg"> +> e<br class=3D"gmail_msg"> +><br class=3D"gmail_msg"> +><br class=3D"gmail_msg"> +_______________________________________________<br class=3D"gmail_msg"> +bitcoin-dev mailing list<br class=3D"gmail_msg"> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" class=3D"gmail_msg= +" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br class=3D"g= +mail_msg"> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" class=3D"gmail_msg" target=3D"_blank">https://lists.linu= +xfoundation.org/mailman/listinfo/bitcoin-dev</a><br class=3D"gmail_msg"> +</blockquote></div></div></div> + +--94eb2c0544d260a879054573ce0f-- + |