summaryrefslogtreecommitdiff
path: root/98/fb6e0c783783fd6d59c90a2b75ea2eaa78175a
blob: 4b93f41bb1fa2369046aa5f1363db5312bbc2d24 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
Return-Path: <bfd@cock.lu>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id CD737BC6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	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 <cp368202@ohiou.edu>
In-Reply-To: <CAAcC9ysdaK1DqBBRvBM=7uHFnM7WW23R61v68xrAMj3rWJfqdg@mail.gmail.com>
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>
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 <bitcoin-dev@lists.linuxfoundation.org>,
	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 <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 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
> <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. 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.