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 1F9873C35 for ; 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 ; Wed, 31 Jul 2019 18:00:47 +0000 (UTC) Received: from harding by newmail.dtrt.org with local (Exim 4.89) (envelope-from ) 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" To: Chris Belcher 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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