Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 500D9C0052 for ; Mon, 30 Nov 2020 23:03:16 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 3D3718708E for ; Mon, 30 Nov 2020 23:03:16 +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 B6s3UnESw4mb for ; Mon, 30 Nov 2020 23:03:14 +0000 (UTC) X-Greylist: delayed 00:16:31 by SQLgrey-1.7.6 Received: from mail-40131.protonmail.ch (mail-40131.protonmail.ch [185.70.40.131]) by hemlock.osuosl.org (Postfix) with ESMTPS id DAF3287064 for ; Mon, 30 Nov 2020 23:03:13 +0000 (UTC) Date: Mon, 30 Nov 2020 23:03:06 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gnet.me; s=protonmail; t=1606777390; bh=jORp0D3CpflHgySgWzvFuBYptjExU6rl78jR/A5Uc7I=; h=Date:To:From:Reply-To:Subject:From; b=JVs2utmw3d+I+SVInSwMwlRxOuaVMRWO/F6Rdoo22r2wpaDhz+me0keye6HhbDCm2 m3+Gp0SyiKuJfqSl6ZMGmv+h7QbWAOLuTVNVP0FWltWtIfGMcjUDdRH7enLfzulKeh owlLgV1TNnMJieT7f59SlDXIQO1PQnzSOhIAR+gs= To: bitcoin-dev@lists.linuxfoundation.org From: Sebastian Geisler Reply-To: Sebastian Geisler Message-ID: <9a068476-855e-0dd7-4c9c-264d5d8bf60a@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 00:26:20 +0000 Subject: [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: Mon, 30 Nov 2020 23:03:16 -0000 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