From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4D2E3C0859 for ; Tue, 1 Dec 2020 15:50:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 3E5772746F for ; Tue, 1 Dec 2020 15:50:07 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfZQwu-9d3sd for ; Tue, 1 Dec 2020 15:50:01 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch [185.70.40.130]) by silver.osuosl.org (Postfix) with ESMTPS id AF2DA20415 for ; Tue, 1 Dec 2020 15:50:00 +0000 (UTC) Date: Tue, 01 Dec 2020 15:49:49 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1606837797; bh=7laeopxQp89ccP+V7ByoFHVN/NCGbhMN0sRUp3H9GhU=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=RiI6lJSEt/kO4DZ7zSM8MRd/PKnDdM6XRj4RBfvoS288MqYKc/oSW8BLInHPrQ/11 a6NpVzICEXopLqSaR6DbtkQIHLYDaL/zi1vwHThmmFP+Pad7Ow39zAD2aFPcli51WL aVds2h+Fwg/VMUFy/lHudzMnf8Psiu9wZpziyq90= To: Sebastian Geisler , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: <3f172428-fb03-755f-3020-43817fdb1897@gnet.me> 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 15:50:07 -0000 Good morning Sebastian and e, > Hi Eric, > > > In paying fees externally one must find another way to associate a fee = with its transaction. This of course increases the possibility of taint, as= you describe in part here: > > I'm not sure I follow, do you see a problem beyond the facts that miners > would need to authenticate somehow? This can be done in a privacy > preserving way per block. I don't think transactions would need to > change in any way. The bounty-transaction link is upheld by a third > party service which the miners have to trust that it will pay out if the > transaction is included (not perfect, but a business decision they can > make). There has to be an association of "how much do I get if I include *this* pa= rticular transaction" to "*this* particular transaction", so that the miner= s have an informed decision of how much they stand to earn. Unless fees are also standardized, this can be used to leak the same inform= ation ("sombody offered this specific amount of money to the bounty server,= and the bounty server associated this particular amount to this particular= transaction"). More concerningly, [a trusted third party is hard to get out of](https://na= kamotoinstitute.org/trusted-third-parties/). If there are only a few of them, it becomes easy to co-opt, and then a part= of the mining infrastructure is now controllable from central points of fa= ilure. If there are many of them, then evaluating which ones cheat and which ones = do not will take a lot of effort, and the system as a whole may not provide= benefits commensurate to the overall system cost in finding good third par= ties. > > It is also the case that the "bounty" must be associated with the trans= action. Even with miner and payer mutual anonymity, the fee inputs and outp= uts will be associated with the transaction inputs and outputs by the miner= , rendering the proposal counterproductive. > > Total transaction sizing is not reduced by paying fees externally, in f= act it would be increased. The only possible reduction would come from aggr= egation of fees. Yet it is not clear how that aggregation would occur priva= tely in less overall block space. At least with integral fees, it's possibl= e to spend and pay a fee with a single input and output. That is not the ca= se with externalized fees. > > I should have made this more clear, I don't imagine anyone to pay these > fees with L1 transactions, but rather some L2 system like Lightning or a > BTC backed chaumian token issued for that purpose by the bounty service > provider. Even Lightning would be far more private for the use cases I > described that don't allow fee deduction from inputs. But if one accepts > more counter party risk with e.g. some centrally pegged chaumian token > it can be anonymous. Since such L2 mechanisms themselves are dependent on L1 and require a facil= ity to bump up fees for e.g. commitment transactions in Lightning Network, = this brings up the possibility of getting into a bootstrapping problem, whe= re the security of L2 is dependent on the existence of a reliable fee-bumpi= ng mechanism at L1, but the fee-bumping mechanism at L1 is dependent on the= security of L2. Not impossible, but such strange loops give me pause; I am uncertain if we = have the tools to properly analyze such. > > I see that this might not be very useful today, but I imagine a future > in which Bitcoin is mostly a settlement and reserve layer. This would > make it feasible to keep most UTXOs in common sizes. Only large, round > transactions happen on-chain, the rest can happen on L2. This would > allow tumbling these already evenly-sized UTXOs on spend without toxic > waste if we can somehow tackle the fee payment problem. I know of the > following solutions: > > - everyone has to add a second UTXO per input > - Someone is chosen fairly at random to pay the total fee > - pay a service on L2 to add an input/output for fee payment > - out-of-band L2 fee payments > > Only L2 fee payments can hide who is involved in such a tumbling > operation as additional fee inputs that get reused would indicate the > same entity was present in two tumbling operations. The out-of-band > approach saves one input and one output and appears more general (e.g= . > could be used like rbf). > > This is also not a general solution for fee payments. In many cases i= t > will still be preferable to pay on-chain fees. But having the option = to > avoid that in a standardized way could help some protocols imo. > > Best, > Sebastian > > > > -----Original Message----- > > From: bitcoin-dev bitcoin-dev-bounces@lists.linuxfoundation.org On Beha= lf Of Sebastian Geisler via bitcoin-dev > > Sent: Monday, November 30, 2020 3:03 PM > > To: bitcoin-dev@lists.linuxfoundation.org > > Subject: [bitcoin-dev] Out-of-band transaction fees > > Hi all, > > the possibility of out of band transaction fee payments is a well known= fact. Yet it has been mostly discussed as an annoying inevitability that c= an be problematic if on-chain fees are to be used as a consensus parameter.= The potential use cases have seen little interest though (please correct m= e if I'm wrong). > > One such use case is sending UTXOs "intact". Let's assume we get to a p= oint where Bitcoin is primarily a settlement layer for L2 systems. > > These L2 systems might want to protect their privacy and keep UTXOs of = a common sizes (e.g. 1 BTC, 10 BTC, =E2=80=A6). For certain settlement appl= ications these can be transferred as a whole, but currently fee requirement= s force the system to add another input for fees which will introduce taint= (because it's used repeatedly). If instead a fee could be paid out of band= in a privacy preserving way the TXO chain would leak little about the inte= rmediate holders. > > Taking this concept even further CoinJoin-like protocols could also be = used to introduce further ambiguity without leaking that a certain entity t= ook part in the CJ (which fee inputs/reused "toxic waste" > > inevitably do afaik). Such a mechanism would probably also make CJ tran= sactions much smaller as no fee inputs had to be provided (assuming the inp= uts already have the right size). > > Out-of-band transaction "accelerators" already exist and taking fee pay= ment out-of-band can not be effectively prevented. So even though any such = proposal will probably have slight centralizing effects I believe that havi= ng a standard for it is preferable to having every pool implement their own= API making it harder for small pools to get into the market. > > Imo the central questions are: > > > > - how to build such a out-of-band "transaction bounty" system > > - how to standardized it > > - how can the centralizing effects from it be mitigated > > > > Imo fees are small enough to not really care about counter party risk t= hat much. It's more important that it is easy to run so that there is some = choice for users and miners. In that sense I consider single-operator servi= ces providing both standardized user and miner APIs as well as an optional = UI suitable. I would still take into account that this could change and mig= ht consider the needs of federated services in the protocol. > > Each such service would need to announce which means of payment it supp= orts and allow users and miners to choose when paying/redeeming fees. Users= should be able to submit transactions and either be presented with a singl= e payment method dependent "invoice" or one per input (for the CoinJoin use= case). As soon as all invoices are paid the bounty goes live and is visibl= e to miners through an API. > > Miners that included a transaction need a way to authenticate when clai= ming the bounty. One possibility would be to optionally include a unique pu= blic key e.g. in the coinbase scriptsig after the height push (is this feas= ible?). This could be used to claim any bounties after 100, 120, or even a = user-defined confirmation threshold is met. If the key is unique for every = block there won't be a problem with pool accountability which might become = a risk down the road (so this should also be enforced at least in the bount= y protocol to avoid lazy implementations leading to dangerous precedents). > > Any feedback is welcome :) > > tl;dr Out-of-band fee payment services are inevitable and useful, so we= should at least standardize them and mitigate negative effects as much as = possible. > > Best, > > Sebastian > > > > 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