From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9D60AC0052 for ; Tue, 1 Dec 2020 19:14:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 8B85B87670 for ; Tue, 1 Dec 2020 19:14:41 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0-s8gQx1bS7U for ; Tue, 1 Dec 2020 19:14:39 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch [185.70.40.133]) by hemlock.osuosl.org (Postfix) with ESMTPS id CEB8B8766C for ; Tue, 1 Dec 2020 19:14:38 +0000 (UTC) Date: Tue, 01 Dec 2020 19:14:26 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gnet.me; s=protonmail; t=1606850076; bh=ca2+6oj3AGdrUA4NAlkH0T+Vc/3EZ0j4e3u73zLs4fk=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From; b=CEPYZNlP1irFROlN0jgpdA3chrJzksni65ID4IQYL6jyeY8oCYzl9+KCq9gdtPzvP Zx0WqYyORC06GYFrUoE6BO9jo5ENrUP/NEUXA5U0gyFeBjoJlAyf9h9/23RVj3lNLy Oz9nkAINjqiAAfpVf0SJxuU7QS3uLqALFS/FPMbY= To: ZmnSCPxj , Bitcoin Protocol Discussion From: Sebastian Geisler Reply-To: Sebastian Geisler Message-ID: In-Reply-To: References: <9a068476-855e-0dd7-4c9c-264d5d8bf60a@gnet.me> <00e301d6c77e$2a4eeab0$7eecc010$@voskuil.org> <3f172428-fb03-755f-3020-43817fdb1897@gnet.me> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 01 Dec 2020 20:04:23 +0000 Subject: Re: [bitcoin-dev] Out-of-band transaction fees X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Dec 2020 19:14:41 -0000 Hi ZmnSCPxj, thank you for your detailed comments. I agree that the centralization risk is a big problem. I didn't fully take into account how hard it might be to distinguish honest service providers, which makes that problem so much worse. I think I'll not pursue this approach for that reason. While such a system can't be prevented I don't need to encourage it= . I might look into the "pay someone to add their UTXO to a tx for fees and give them back the remainder" approach though, it doesn't seem as hazardous and might even be possible to do in a decentralized fashion. > Now, you have mentioned a number of times that you believe Bitcoin will e= ventually be a settlement layer, and somehow link this with standardized UT= XO sizes. > But I think the end goal should be: >=20 > * To improve Bitcoin blockchain layer privacy. >=20 > It should not matter how we achieve this, whether it involves standardize= d UTXO sizes or not; if you want to use this solution, you need to present = a good reason why this is the best solution for Bitcoin privacy, and better= than other solutions. I completely agree. > For example, the JoinMarket way of CoinJoining does not require any parti= cular standardized UTXO size. > The upcoming SwapMarket that Chris Belcher is working on, also does not r= equire such a standardized UTXO size, as it is based as well on the JoinMar= ket technique, where the client can select whatever sizes it wants. > Why should the Bitcoin ecosystem adopt a strict schedule of UTXO sizes fo= r privacy, if apparently JoinMarket and SwapMarket can improve privacy with= out this? These efforts are great! Yet all CoinJoin based protocols I have seen (mostly academic ones tbh, that provide strong guarantees) have some amount of overhead in the form of creating more UTXOs and bigger transactions than minimally possible or even "toxic waste" we don't know what to do with. As far as I understand it there's now way around that without relaxing anonymity guarantees. Maybe I'm not up to date in that regard. I also think that the privacy properties/the actual anonymity set of unequal output size CoinJoins (i.e. knapsack mixing) is not as well understood as for evenly-sized output CoinJoins. If we are only talking about user-defined CoinJoin output sizes it comes down to efficiency again. This will nearly always lead to change and not many parties will be interested in the particular output size so you even need to pay them to participate. Please bear with me as the following part is _very_ speculative: I believe that if Bitcoin becomes mainstream (I take no stance whether this is good or not, but consider it a possibility) transaction prices are bound to increase dramatically, which would make such protocols uneconomical. This also means most people will rely on some L2 technology. But the fees might even make Lightning nodes uneconomical for the majority of people. So if we are lucky federated L2 systems, or if we are unlucky centralized ones, will play an important role imo. In such an environment, where on-chain transactions are mostly used as settlements between somewhat big players, having (multiple tiers of) evenly sized UTXOs makes a lot of sense. You don't need exact valued transfers and get free/cheaper than free and effective mixing on spends if you just combine your transactions. So imo the pros of this technique are: * as simple as possible (easy to assess exact anonymity set) * cheap, so it could be made a default, leading to a large anon set while the cons are: * only makes sense when exact values aren't important (e.g. L2 funding) * needs fee hacks I don't want to derail this any further. I agree that my initial idea bears too great risks of regulatory capture. While I find the evenly-sized UTXO idea intriguing I'd be even happier about a arbitrary-amount scheme that gives the same strong assurances in an _efficient_ manner, I just haven't seen a way to achieve this so far. Best, Sebastian