Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id D5422C0052 for ; Tue, 1 Dec 2020 16:24:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id C473C86F87 for ; Tue, 1 Dec 2020 16:24:17 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHYYwggs-hEs for ; Tue, 1 Dec 2020 16:24:15 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch [185.70.40.135]) by whitealder.osuosl.org (Postfix) with ESMTPS id AAF2D86EB9 for ; Tue, 1 Dec 2020 16:24:15 +0000 (UTC) Date: Tue, 01 Dec 2020 16:24:11 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1606839852; bh=LxaYH7HdfAlJ/ppfRu5r4HrFA7ksUK05r9Ak749wp/E=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=mUdapecF2+giGjfcWMzhBAnUUos2G1KsEtPQeH9VTvd0lBJ9Hqp8cpCZkI0vOo5ZL uQhI2ydgfhVuO+j16gOymCruuSezf/1fvrCT543WpO3Kg7rV5CFCKaP+VvZp3JTbYu Nz80EoCNq1pTPMQmUA8KK5plQAwUoRH86Gjozyb4= To: ZmnSCPxj , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj 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 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 16:24:17 -0000 Good morning e, and Sebastian, So it seems, the goals are the below: * Someone wants to pay a fee to get a transaction confirmed. * Miners want to know how much they earn if they confirm a transaction. * The one paying for the fee does not want to link its other coins to the t= ransaction it wants confirmed. Would that be a fair restatement of the goal? If so, it seems to me we can make a CoinJoin-like approach using only L1, a= nd combine fees by a kind of FeeJoin. The issue with linking is that if for example the one paying a fee to get a= transaction confirmed wants to CPFP the transaction, it may need to take a= nother UTXO it controls into the child transaction, thereby linking its "an= other UTXO" with the "transaction it wants confirmed". However, if multiple such individuals were to CoinJoin their transactions, = the linking becomes much harder to trace. So a possible mechanism, with a third-party that is trusted only to keep th= e service running (and cannot cheat the system and abscond with the fees an= d leave miners without money) would be: * The third-party service divides its service into fixed-feerate bins. * Clients select a preferred feerate bin they want to use. * For each client: * Connects to the service by Tor to register a transaction it wants to ha= ve CPFPed. * Connects to the service by a different Tor circuit to register a UTXO i= t will use to spend fees. * The server passes through the CPFPed outputs in the whole value. * The server deducts the fee from the fee-paying UTXO and creates an output= with all the fees (CPFP output spend, UTXO input spend, CPFP output re-cre= ation, UTXO output re-creation) deducted from the UTXO. * The server gives the resulting transaction to the clients. * The clients sign the transaction after checking that its interested CPFPe= d outputs and fee-paying UTXOs are present. This results in a transaction with many CPFPed inputs and fee-paying UTXOs,= and no easy way to link the latter with the former. * Miners and chain analysis cannot link them, as they see only the resultin= g tx. * The service cannot link them, as clients talk to them on two separate Tor= connections. The above is blatantly the Wasabi way of CoinJoining; using the JoinMarket = way of CoinJoining should be possible as well, and is left as an exercise t= o the reader. Now, you have mentioned a number of times that you believe Bitcoin will eve= ntually be a settlement layer, and somehow link this with standardized UTXO= sizes. But I think the end goal should be: * To improve Bitcoin blockchain layer privacy. It should not matter how we achieve this, whether it involves standardized = 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 t= han other solutions. For example, the JoinMarket way of CoinJoining does not require any particu= lar standardized UTXO size. The upcoming SwapMarket that Chris Belcher is working on, also does not req= uire such a standardized UTXO size, as it is based as well on the JoinMarke= t technique, where the client can select whatever sizes it wants. Why should the Bitcoin ecosystem adopt a strict schedule of UTXO sizes for = privacy, if apparently JoinMarket and SwapMarket can improve privacy withou= t this? Regards, ZmnSCPxj