From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 09B9CC000B for ; Sun, 13 Jun 2021 14:16:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id DD5D3403B1 for ; Sun, 13 Jun 2021 14:16:39 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUj_227kjY2H for ; Sun, 13 Jun 2021 14:16:38 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by smtp4.osuosl.org (Postfix) with ESMTPS id ACEB140393 for ; Sun, 13 Jun 2021 14:16:38 +0000 (UTC) Received: from mail-il1-f176.google.com (mail-il1-f176.google.com [209.85.166.176]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 15DEGagr031289 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Sun, 13 Jun 2021 10:16:37 -0400 Received: by mail-il1-f176.google.com with SMTP id b9so9955498ilr.2 for ; Sun, 13 Jun 2021 07:16:37 -0700 (PDT) X-Gm-Message-State: AOAM531RUAFZX1G40yCkRaO2l4lH+sHlPbmsWPW87PDHirGyKLdNgQea wBTcvXDpkILeaSRd2JZQkeoqm74V62eX+5D5b2M= X-Google-Smtp-Source: ABdhPJwoZhaGX036XmyinJZR0A+BAOQW3Zs7ydTxvqFQ/Ajy19C0D52oUqNEHcoqQjBD5RPAndsP59u/nfttyoUhx5E= X-Received: by 2002:a05:6e02:14cd:: with SMTP id o13mr2833434ilk.49.1623593796347; Sun, 13 Jun 2021 07:16:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jeremy Date: Sun, 13 Jun 2021 10:16:24 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000007db24e05c4a663fb" Subject: Re: [bitcoin-dev] A Stroll through Fee-Bumping Techniques : Input-Based vs Child-Pay-For-Parent 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: Sun, 13 Jun 2021 14:16:40 -0000 --0000000000007db24e05c4a663fb Content-Type: text/plain; charset="UTF-8" The API of a sponsor-like mechanism is close to ideal in my opinion: - compatible with non malleable transactions - 0 overhead if fees accurately estimated - watchtower friendly - post hoc, requires minimal 'protocol awareness' - friendly with most mempool eviction policies, not much new required - can work to atomically bump multiple txns - can be bumped cooperatively by multiple sponsors w/o coordination - 0 'rebroadcast overhead' (e.g., for a large batch) leasing to cascading retransmission fees for replacement - can be piggy backed with other future transactions or protocols (e.g. coinjoin) - compatible with change being in cold storage The main drawback is it is chain space - wise less efficient, as an additional transaction gets made. However, I think the API benefits 'product market fit' over alternative solutions outweigh other concerns, and if the 'sponsorship efficiency hypothesis' holds true, then most transactions will not require sponsors and therefore the savings of not needing to preplan a few bumping mechanism will be more efficient overall (efficient market will drive accuracy in estimating fees rather than needing to sponsor). --0000000000007db24e05c4a663fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The API of a sponsor-like mechanism is close to ideal in = my opinion:

- compatible with = non malleable transactions
- 0 overhead if fees accu= rately estimated
- watchtower friendly
- post hoc, requires minimal 'protocol awareness'
- friendly with most mempool eviction policies, not much ne= w required
- can work to atomically bump multiple tx= ns
- can be bumped cooperatively by multiple sponsor= s w/o coordination
- 0 'rebroadcast overhead'= ; (e.g., for a large batch) leasing to cascading retransmission fees for re= placement
- can be piggy backed with other future tr= ansactions or protocols (e.g. coinjoin)
- compatible= with change being in cold storage

The main drawback is it is chain space - wise less efficient, as= an additional transaction gets made. However, I think the API benefits = 9;product market fit' over alternative solutions outweigh other concern= s, and if the 'sponsorship efficiency hypothesis' holds=C2=A0true, = then most transactions will not require sponsors and therefore the savings = of not needing to preplan a few bumping mechanism will be more efficient ov= erall (efficient market will drive accuracy in estimating fees rather than = needing to sponsor).


--0000000000007db24e05c4a663fb--