1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
|
Return-Path: <jlrubin@mit.edu>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 09B9CC000B
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>; Sun, 13 Jun 2021 10:16:37 -0400
Received: by mail-il1-f176.google.com with SMTP id b9so9955498ilr.2
for <bitcoin-dev@lists.linuxfoundation.org>;
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: <CALZpt+FvLb=N5Qygs+dPmh1o9QCwXj8RoznF5n47opOq7CG_0g@mail.gmail.com>
<CAH5Bsr2gmqqS1LWuT679vzOEywo=gCdNdOX-Jb9aFFb=EPZcHg@mail.gmail.com>
<CALZpt+Hj-KdiuQueAhkeTwzJvu5Wo9zdBQ39aZGrSmjJvgbkDQ@mail.gmail.com>
<CAH5Bsr0V6r3+GsDg=CbDshj=QnpAr+saXftG_pazkWvL=m-W3g@mail.gmail.com>
In-Reply-To: <CAH5Bsr0V6r3+GsDg=CbDshj=QnpAr+saXftG_pazkWvL=m-W3g@mail.gmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Sun, 13 Jun 2021 10:16:24 -0400
X-Gmail-Original-Message-ID: <CAD5xwhjSN1LX_8L90UYy-r=sMPCRTonHetxKY4C0f1ghw548SA@mail.gmail.com>
Message-ID: <CAD5xwhjSN1LX_8L90UYy-r=sMPCRTonHetxKY4C0f1ghw548SA@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <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: 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
<div dir=3D"auto">The API of a sponsor-like mechanism is close to ideal in =
my opinion:<div dir=3D"auto"><br></div><div dir=3D"auto">- compatible with =
non malleable transactions</div><div dir=3D"auto">- 0 overhead if fees accu=
rately estimated</div><div dir=3D"auto">- watchtower friendly</div><div dir=
=3D"auto">- post hoc, requires minimal 'protocol awareness'</div><d=
iv dir=3D"auto">- friendly with most mempool eviction policies, not much ne=
w required</div><div dir=3D"auto">- can work to atomically bump multiple tx=
ns</div><div dir=3D"auto">- can be bumped cooperatively by multiple sponsor=
s w/o coordination</div><div dir=3D"auto">- 0 'rebroadcast overhead'=
; (e.g., for a large batch) leasing to cascading retransmission fees for re=
placement</div><div dir=3D"auto">- can be piggy backed with other future tr=
ansactions or protocols (e.g. coinjoin)</div><div dir=3D"auto">- compatible=
with change being in cold storage</div><div dir=3D"auto"><br></div><div di=
r=3D"auto">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).</div><div dir=3D"auto"><br></div><div dir=3D"auto"><br=
></div><div dir=3D"auto"><br></div></div>
--0000000000007db24e05c4a663fb--
|
