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 55713C0052 for ; Tue, 1 Dec 2020 02:43:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 399A62D002 for ; Tue, 1 Dec 2020 02:43:40 +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 XWpf5+66JOmb for ; Tue, 1 Dec 2020 02:43:38 +0000 (UTC) X-Greylist: delayed 00:39:00 by SQLgrey-1.7.6 Received: from mail-vk1-f176.google.com (mail-vk1-f176.google.com [209.85.221.176]) by silver.osuosl.org (Postfix) with ESMTPS id BA905274D1 for ; Tue, 1 Dec 2020 02:43:38 +0000 (UTC) Received: by mail-vk1-f176.google.com with SMTP id b190so102667vka.0 for ; Mon, 30 Nov 2020 18:43:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20150623.gappssmtp.com; s=20150623; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=fTvIKZ8njj2xmG7dNU7SLRT5afpELzlpKGXIV5pqYZw=; b=WroVTcOaCOPQ7MAICxeYV8Y38Iz/pKtZfseOBXebACYxXQfCMkiC05gl2Jshe8YDMl EC8Lh51ADpmg6JsrNMn0nhd8YpQEI3eP/9Q18WqAHHaGAtFMMOsjA496kgvS6rcE1MVf QHeAQaaNf95GDmaAPYEz9nu0lDPSUWcH6zaDPHWrVCHM9NNX5+BiPgPG5V15+/PV2bsp b4z7uWTAMispGwC/eS+KMaAt5Y3PyfgjUZSIKhaZ3J8pqg0bWNrGLCL+DfqHnlac58qA fU3R96mnS5xqJl4t+iD+cKYJFBIh5U0xe9WT2U3AXpI5vUseMrh+pjs32Y5Cn9eDQrZK /1qQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=fTvIKZ8njj2xmG7dNU7SLRT5afpELzlpKGXIV5pqYZw=; b=ife9AltRcGtXQ2CePwcO48OqU3dgWi03MxQ9Hp9WxtJqMhNoxivK7/kp0/EcvHesMe 1fpzyah44/RfYha154/o4JhK1xiwiXY7PKNAO/AjLPSP35um2digXMNo7S2V+7aCZ7p6 NgXkpFk8CS68z270uE+7Vka/ky+Bs9C3XyEPqOo6D6jkgG/q9Wm7/fRjHhLGRn9qH/IV qczy2NktENXmmC3R1SGA+6+Cl/dqGujYASw3lAVM2U9Zxj+7ZsmCtwtrF87DoQSMNtZ0 h6eNGVq/ndQ8PnTEcerrsxHkb3ItyuD+BpoLNufmSejPvErp3OOMuTN/ZxDtdeP3TwGQ EhhA== X-Gm-Message-State: AOAM533Fv5ELQ9LRhh7Ubi20cQCjqNnx2CBJS8C12DrMSBWDlYFtUnUs dZs5ciK4yaL8r0vSp0gPSTAoAw2OSjQj+9G5 X-Google-Smtp-Source: ABdhPJyBDoG2+GCuR3r6mPw3LPTSG7pZyI6EPs3ve3cuXrrU+hGUaY7WCPvXWKWN+wxw7xtKBzI3XA== X-Received: by 2002:a05:6a00:848:b029:197:e659:e236 with SMTP id q8-20020a056a000848b0290197e659e236mr168960pfk.74.1606784774010; Mon, 30 Nov 2020 17:06:14 -0800 (PST) Received: from ERICPC ([50.229.64.228]) by smtp.gmail.com with ESMTPSA id m7sm209515pfh.72.2020.11.30.17.06.13 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Nov 2020 17:06:13 -0800 (PST) From: To: "'Sebastian Geisler'" , "'Bitcoin Protocol Discussion'" References: <9a068476-855e-0dd7-4c9c-264d5d8bf60a@gnet.me> In-Reply-To: <9a068476-855e-0dd7-4c9c-264d5d8bf60a@gnet.me> Date: Mon, 30 Nov 2020 17:06:13 -0800 Message-ID: <00e301d6c77e$2a4eeab0$7eecc010$@voskuil.org> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLv93ubyT21AA8J26luR0feJHDJbKevAsrw Content-Language: en-us X-Mailman-Approved-At: Tue, 01 Dec 2020 08:28:40 +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 02:43:40 -0000 Hi Sebastian, It's important to consider here that anonymity is the reason fees are = incorporated into transactions. One must generally trust the party with = whom one transacts. But since integral fees are paid to any miner, this = does not apply to fees. 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: > Miners that included a transaction need a way to authenticate when = claiming the bounty. It is also the case that the "bounty" must be associated with the = transaction. Even with miner and payer mutual anonymity, the fee inputs = and outputs 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 = fact it would be increased. The only possible reduction would come from = aggregation of fees. Yet it is not clear how that aggregation would = occur privately in less overall block space. At least with integral = fees, it's *possible* to spend and pay a fee with a single input and = output. That is not the case with externalized fees. e -----Original Message----- From: bitcoin-dev On = Behalf 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 = can 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 me if I'm wrong). One such use case is sending UTXOs "intact". Let's assume we get to a = point 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 = applications these can be transferred as a whole, but currently fee = requirements 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 intermediate holders. Taking this concept even further CoinJoin-like protocols could also be = used to introduce further ambiguity without leaking that a certain = entity took part in the CJ (which fee inputs/reused "toxic waste" inevitably do afaik). Such a mechanism would probably also make CJ = transactions much smaller as _no_ fee inputs had to be provided = (assuming the inputs already have the right size). Out-of-band transaction "accelerators" already exist and taking fee = payment out-of-band can not be effectively prevented. So even though any = such proposal will probably have slight centralizing effects I believe = that having 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 = that 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 services 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 might consider the needs of federated services in = the protocol. Each such service would need to announce which means of payment it = supports and allow users and miners to choose when paying/redeeming = fees. Users should be able to submit transactions and either be = presented with a single 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 visible to miners through an API. Miners that included a transaction need a way to authenticate when = claiming the bounty. One possibility would be to optionally include a = unique public key e.g. in the coinbase scriptsig after the height push = (is this feasible?). 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 bounty 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