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 571F0A15 for ; Wed, 15 Mar 2017 22:36:36 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pf0-f177.google.com (mail-pf0-f177.google.com [209.85.192.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 01D341B4 for ; Wed, 15 Mar 2017 22:36:33 +0000 (UTC) Received: by mail-pf0-f177.google.com with SMTP id v190so14927157pfb.1 for ; Wed, 15 Mar 2017 15:36:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thinlink-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=Z+KBIuJG9VUwuLWBk3JIyyQzXOiXSKwJ7TI5UdHuato=; b=ouKKQcdVcAfY223v9MbhoRPWmVk6l3QnV2c2if37BJyuhHQKfFZPnThSk2S7PlNYMT 2gYzIXM6d4FH5sy51NL9pP3N16EvzN0z4XlsNBLmHBJIs1A6G3OROEZh+0Q2o1wUrNE4 +gX48tXmWspaFeORHR0MglrFMcoGI8uwSph2C3yvnh82RccAzXpvrZ/8yP6/UlC2s7yd u2WBH5/ATHD23RVc1CMKp+jLgD7F2Lfgvq8xQt5DNYSMdG0IrjuSrf0iUKLIVgJrCYGg pVea/KNNS2OXfwEI9U6BBOK6Sm2g/LnQdeOkcrWsHmvALwG2UFDQBTCF7gPxUUD9u9Nd l4KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Z+KBIuJG9VUwuLWBk3JIyyQzXOiXSKwJ7TI5UdHuato=; b=ON3LKlzxDbMebsRZ+eCcudW2IErU4H+bL/eWENEU4KG8GNfhzNF0OnkLw8onGcDVSF wI/mN3GV4j+/e1j6TlchCnLrdPkT74p/KZ4xPduWQkPQhg52/6mF6sgc4NbSVwx0Pjfo Qk92+gDKTP24BMI3CRdjDcQTmL6JMl1od6aGJd+TfsWscr+ol3XKJv+Eip3qoxhOh+BK xOivjsIgXf6HUsvs8bWVVdKeryKfTQUHEfLHM9XmoktSjftVYRF0YUBrw7evJWy5Pa1S UypQAhv+pcFIk7HJD9SAeS4vrAa1YaeCaaaeUXsHwPsh4GQ7wQznN8/EDkMuA8Vr5VpD qXuQ== X-Gm-Message-State: AFeK/H1edowsWqsHij8q4ZJnYt1oa3JkcomY1QYM2IMrGFLJCKLBmUC4COxs98Z7Rrdztx8G X-Received: by 10.84.241.130 with SMTP id b2mr7811165pll.32.1489617392721; Wed, 15 Mar 2017 15:36:32 -0700 (PDT) Received: from [10.100.1.239] ([204.58.254.99]) by smtp.googlemail.com with ESMTPSA id q64sm6216092pga.0.2017.03.15.15.36.31 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Mar 2017 15:36:31 -0700 (PDT) To: bitcoin-dev@lists.linuxfoundation.org References: <71d822e413ac457a530e1c367811cc24@cock.lu> <77b6dd25-0603-a0bd-6a9e-38098e5cb19d@jonasschnelli.ch> <74aeb4760316b59a3db56c0d16d11f28@cock.lu> <045843cb19f03888da10d2954cd1c685@cock.lu> From: Tom Harding Message-ID: <7794520b-43a0-3227-1a68-58d12e432291@thinlink.com> Date: Wed, 15 Mar 2017 15:36:09 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <045843cb19f03888da10d2954cd1c685@cock.lu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,RCVD_IN_SORBS_WEB autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Wed, 15 Mar 2017 22:40:05 +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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 22:36:36 -0000 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 >> 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. >