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 882A7C74 for ; Fri, 6 Jan 2017 20:15:49 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f45.google.com (mail-oi0-f45.google.com [209.85.218.45]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 856D2130 for ; Fri, 6 Jan 2017 20:15:47 +0000 (UTC) Received: by mail-oi0-f45.google.com with SMTP id 128so433092410oig.0 for ; Fri, 06 Jan 2017 12:15:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=BWvncfZBDBCn82/ewofxBPK539qiMlMNzQ3dsNx7isQ=; b=m517M/WT9FPFDeWHYaipxei7XOFKZtXmpBqejPWkbcr0OOBlSR023nm3xib79fkRoL S4StC1HtVRVP8ffC1Dsv5s5qAvGxhZi2lLbi+Q5eu1NXHa4u93f+Z3tBNDc1gU5CcX9E axmqDRy/rhesIRWXbYRLU5mwUZy8Gv9HPPo2FUeSEeHEfYDbFdRt9gt0hDpC4EdAbXvx oGwlYMKFLlUEUaKNovIlozq5mjRfF8oRBM3AncqdRyh1PzIlfXB7GhIeg8S8udQyujbT HKOZv662tvwWORJKoJXCYp84cUyBRgsjb+BpmzJQIbed2DuoHEsFFaIClLcUOybcTVP/ ptMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=BWvncfZBDBCn82/ewofxBPK539qiMlMNzQ3dsNx7isQ=; b=aqP4og7ZuEuYppdsoeDeXr65rYcSIv/SlSxX+VN2cjQyLaBJGn/9j+3/iN0E5/8BOK LFX102n10tN5TP4wv9XRUDrZh+g+PIbsAE9ve/wKJj+VlxfmkNYYOvrm5SjAOoYcxrDV zNhbuG40uFx7zl5hu1A0jNpe0IV20q5XFOlExGnP0OPbjM6xY1Sh9xYt19NCuMdRJBGc WcETI1Xsq23wd7D/JUgx4ATAiCkmTnJSQWE2IMTeVZ5d+uwrYJgbr2HXvVdG4iSD/gU4 vQAxGyqyhVz7C0huI7oe/kPAX+M84b1TiGG1g1sUMKfWjPz0RysiYVUTF60UE42riBgi dRDg== X-Gm-Message-State: AIkVDXKXc5kllXsvpfHEFwYa8ahVCumZyt/d6rHKXwxnkmKHd3bbBFkXatRAVPYDnW5BiEVQVR9oYZzOySRdBg== X-Received: by 10.157.10.202 with SMTP id 68mr1787535otq.51.1483733746762; Fri, 06 Jan 2017 12:15:46 -0800 (PST) MIME-Version: 1.0 Sender: nbvfour@gmail.com Received: by 10.182.56.79 with HTTP; Fri, 6 Jan 2017 12:15:46 -0800 (PST) In-Reply-To: <347a0909-affd-da0c-f7f8-09fa76bcb279@voskuil.org> References: <71d822e413ac457a530e1c367811cc24@cock.lu> <77b6dd25-0603-a0bd-6a9e-38098e5cb19d@jonasschnelli.ch> <74aeb4760316b59a3db56c0d16d11f28@cock.lu> <347a0909-affd-da0c-f7f8-09fa76bcb279@voskuil.org> From: Chris Priest Date: Fri, 6 Jan 2017 12:15:46 -0800 X-Google-Sender-Auth: 3OpqP2lBVnRPbZGr3u1lcQDTIGY Message-ID: To: Eric Voskuil Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, 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 Cc: Bitcoin Protocol Discussion 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 20:15:49 -0000 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 > >