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 CD737BC6 for ; Fri, 6 Jan 2017 02:04:27 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from cock.li (cock.li [185.100.85.212]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C78AB131 for ; Fri, 6 Jan 2017 02:04:26 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU autolearn=ham version=3.3.1 MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cock.lu; s=mail; t=1483668263; bh=uEGj+MR7awJMG0MRhRrumdRq7pYCcDmuLS7PCIjwdBY=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=yOgiaEawGwBtN1i8rGsSJ71lb1PE8laeDKyR8ubeV00Hgomf6uI8qwKO6gmNs0zUE fNo0d4K5LY2iYcNczouhbxHdvcNpNE93KHgQLZGXDm8Rs75xX0UkJHoQe/09+aZuIc KkrelxfST2wDqyS4XXlJj2AHzfXJchUCg/KMJjTMUoI9Ka/6dOmAC5nWvNKvQq9h44 eVACoMAWuSXdLmTKgIBtgM04e/i67c1JtnMKoR1JuV5KF2G1sNYiqP3oAJFaZELR0A b3pIbJNLKF+YuuCWa+Qt23c21BS8B3zUfJJf26Aa5a0+4/HSQTZk5ceuZ7Zf4H0Zp2 wwl2uzBv7ndrQ== Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 05 Jan 2017 18:04:22 -0800 From: bfd@cock.lu To: Chris Priest In-Reply-To: References: <71d822e413ac457a530e1c367811cc24@cock.lu> <77b6dd25-0603-a0bd-6a9e-38098e5cb19d@jonasschnelli.ch> <74aeb4760316b59a3db56c0d16d11f28@cock.lu> Message-ID: <045843cb19f03888da10d2954cd1c685@cock.lu> X-Sender: bfd@cock.lu User-Agent: Roundcube Webmail/1.2.3 X-Mailman-Approved-At: Fri, 06 Jan 2017 08:56:12 +0000 Cc: Bitcoin Protocol Discussion , nbvfour@gmail.com 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 02:04:27 -0000 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.