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
|
Return-Path: <dave@dtrt.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 1F9873C35
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 31 Jul 2019 18:00:48 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from newmail.dtrt.org (li1228-87.members.linode.com [45.79.129.87])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AA288A8
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 31 Jul 2019 18:00:47 +0000 (UTC)
Received: from harding by newmail.dtrt.org with local (Exim 4.89)
(envelope-from <dave@dtrt.org>)
id 1hsstr-0006rW-K6; Wed, 31 Jul 2019 14:00:31 -0400
Date: Wed, 31 Jul 2019 07:59:40 -1000
From: "David A. Harding" <dave@dtrt.org>
To: Chris Belcher <belcher@riseup.net>
Message-ID: <20190731175940.6i57a52jcvkpjodf@ganymede>
References: <985792b1-e7aa-677b-a7a1-6a5f672da884@riseup.net>
<20190727193417.cxf544dbempencql@ganymede>
<96722b03-9aa0-5e3d-25ed-c644c26d5a27@riseup.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <96722b03-9aa0-5e3d-25ed-c644c26d5a27@riseup.net>
User-Agent: NeoMutt/20180716
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
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, 31 Jul 2019 18:18:56 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil
attacks using fidelity bonds
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: Wed, 31 Jul 2019 18:00:48 -0000
On Tue, Jul 30, 2019 at 10:27:17PM +0100, Chris Belcher wrote:
> And any ECC-alternative or hash-function-alternative fork will
> probably take a couple of months to be designed, implemented and
> deployed as well, giving a chance for lockers to move coins.
Probably. A stronger form of my argument would apply to single-wallet
(or wallet library) problems of the type we see with depressing
regularity, such as reused nonces, weak nonces, brainwallets, and weak
HD seeds. In some cases, this leads directly to theft and loss---but in
others, the problem is detected by a friendly party and funds can be
moved to a secure address before the problem is publicly disclosed and
attackers try to exploit it themselves.
If funds are timelocked, there's a greater chance that the issue will
become publicly known and easily exploitable while the funds are
inaccessible. Then, at the time the lock expires, it'll become a race
between attackers and the coin owner to see who can get a spending
transaction confirmed first.
> This scheme could be attacked using address reuse. An attacker could
> create an aged coin on a heavily-reused address, which would force an
> SPV client using this scheme to download all the blocks which contain
> this reused address which could result in many gigabytes of extra
> download requirement.
Good point. There's also the case that some Electrum-style indexers
don't index more than a certain number of outputs sent to the same
address. E.g., I believe Electrs[1] stops indexing by default after 100
outputs to the same address.
[1] https://github.com/romanz/electrs
> So to fix this: a condition for aged coins is that their address has not
> been reused, if the coin is on a reused address then the value of the
> fidelity bond becomes zero.
I don't think that works. If Bob sends 100 BTC to bc1foo and then uses
that UTXO as his fidelity bond, Mallory can subsequently send some dust
to bc1foo to invalidate Bob's bond.
To use compact block filters in a way that prevents spamming, I think
we'd need a different filter type that allowed you to filter by
outpoint.
-Dave
|
