summaryrefslogtreecommitdiff
path: root/96/c948e912fd51ec5b5b21bae9cade5b8eef6672
blob: 4988262504d4d8a37b244bfeaebac1b5ca866a19 (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
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
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 D3608258
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  3 Jan 2017 22:29:00 +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 D06F5196
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  3 Jan 2017 22:28:59 +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=1483482537; bh=cpzXVyEKuggClj0P5u8qxvnVr3/0TwMIHA247OnYeV0=;
	h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
	b=xW1M5h6IKebYZASoY+KCgeYKI5gqzFYowY+D+GPCci8fL4mW8PLW180qZyEEcSlTI
	J20mlxgK3/jJJ9bEpQYF8tDXtsz5qFua7vdCy0MtJA5hU7Nfp/8g0MjSF0YhefjltS
	Vi8L7lTG9l9HooLlGTdgCC6PcuRRqmzpSBJQR4PTcvZNd7Jo3H6L7YVZzeDmQdj1IQ
	4MG7nAT21R+jZ2p2gi9ukDg604VsmFzhZvKxeahJOHScaPCEA9z14DUQbDT1AWjUov
	pgG+d/3YAsPaEUt4MJA5OIpa3EO6+AGusEBRJu3YjgcahAgUaAYOEEJTWgpZY2Qv4u
	2GSjd+KxMjByw==
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Date: Tue, 03 Jan 2017 14:28:56 -0800
From: bfd@cock.lu
To: Aaron Voisine <voisine@gmail.com>
In-Reply-To: <CACq0ZD7XT_h8ADptKA0uBT7617fvvgh3uGndkc08RZUSQM2yQg@mail.gmail.com>
References: <71d822e413ac457a530e1c367811cc24@cock.lu>
	<77b6dd25-0603-a0bd-6a9e-38098e5cb19d@jonasschnelli.ch>
	<74aeb4760316b59a3db56c0d16d11f28@cock.lu>
	<CACq0ZD7XT_h8ADptKA0uBT7617fvvgh3uGndkc08RZUSQM2yQg@mail.gmail.com>
Message-ID: <d57d0f8e0732757d77efdd404170df0d@cock.lu>
X-Sender: bfd@cock.lu
User-Agent: Roundcube Webmail/1.2.3
X-Mailman-Approved-At: Tue, 03 Jan 2017 23:25:59 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.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: Tue, 03 Jan 2017 22:29:01 -0000

The concept was not particularly targeted towards businesses, but
allowing for significantly improved wallet performance and reducing
privacy for lite clients. You would expect that a business has the
capacity to run a fully validating, fully storing node of their own.
If they’re not something is fundamentally broken with Bitcoin, or
their rationale of continuing to use it.


On 2017-01-03 14:18, Aaron Voisine wrote:
> Unconfirmed transactions are incredibly important for real world use.
> Merchants for instance are willing to accept credit card payments of
> thousands of dollars and ship the goods despite the fact that the
> transaction can be reversed up to 60 days later. There is a very large
> cost to losing the ability to have instant transactions in many or
> even most situations. This cost is typically well above the fraud
> risk.
> 
> It's important to recognize that bitcoin serves a wide variety of use
> cases with different profiles for time sensitivity and fraud risk.
> 
> Aaron
> 
> On Tue, Jan 3, 2017 at 12:41 PM bfd--- via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
>> The concept combined with the weak blocks system where miners commit
>> 
>> to potential transaction inclusion with fractional difficulty blocks
>> 
>> is possible. I'm not personally convinced that unconfirmed
>> transaction
>> 
>> display in a wallet is worth the privacy trade-off. The user has
>> very
>> 
>> little to gain from this knowledge until the txn is in a block.
>> 
>> On 2017-01-01 13:01, Jonas Schnelli via bitcoin-dev wrote:
>> 
>>> Hi
>> 
>>>> We introduce several concepts that rework the lightweight Bitcoin
>> 
>>>> client model in a manner which is secure, efficient and privacy
>> 
>>>> compatible.
>> 
>>>> 
>> 
>>>> The BFD can be used verbatim in replacement of BIP37, where the
>> filter
>> 
>>>> can be cached between clients without needing to be recomputed.
>> It can
>> 
>>>> also be used by normal pruned nodes to do re-scans locally of
>> their
>> 
>>>> wallet without needing to have the block data available to scan,
>> or
>> 
>>>> without reading the entire block chain from disk.
>> 
>>> I started exploring the potential of BFD after this specification.
>> 
>>> 
>> 
>>> What would be the preferred/recommended way to handle
>> 0-conf/mempool
>> 
>>> filtering – if & once BDF would have been deployed (any type,
>> 
>>> semi-trusted oracles or protocol-level/softfork)?
>> 
>>> 
>> 
>>> From the user-experience perspective, this is probably pretty
>> important
>> 
>>> (otherwise the experience will be that incoming funds can take
>> serval
>> 
>>> minutes to hours until they appear).
>> 
>>> Using BIP37 bloom filters just for mempool filtering would
>> obviously
>> 
>>> result in the same unwanted privacy-setup.
>> 
>>> 
>> 
>>> </jonas>
>> 
>>> 
>> 
>>> 
>> 
>>> _______________________________________________
>> 
>>> bitcoin-dev mailing list
>> 
>>> bitcoin-dev@lists.linuxfoundation.org
>> 
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> 
>> _______________________________________________
>> 
>> bitcoin-dev mailing list
>> 
>> bitcoin-dev@lists.linuxfoundation.org
>> 
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev