path: root/a0/18847465e46d9509459f60dcd0f2f08ae69846

Return-Path: <eric@voskuil.org>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 55713C0052
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  1 Dec 2020 02:43:38 +0000 (UTC)
Received: by mail-vk1-f176.google.com with SMTP id b190so102667vka.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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: <eric@voskuil.org>
To: "'Sebastian Geisler'" <sebastian@gnet.me>,
 "'Bitcoin Protocol Discussion'" <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <bitcoin-dev-bounces@lists.linuxfoundation.org> 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