summaryrefslogtreecommitdiff
path: root/10/37ba31115aae871214c96d1239a3c0d81e844d
blob: 26d2960e35624c57dc74758f1fc2fce8801b4d32 (plain)
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
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
Return-Path: <daniel@gap600.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 7F75CC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 11 Dec 2022 20:24:13 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 4460E60BDA
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 11 Dec 2022 20:24:13 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 4460E60BDA
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=gap600.com header.i=@gap600.com
 header.a=rsa-sha256 header.s=google header.b=L0ybJAoW
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 8EFzLn5QdB6D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 11 Dec 2022 20:24:12 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 2D73A60A93
Received: from mail-il1-x130.google.com (mail-il1-x130.google.com
 [IPv6:2607:f8b0:4864:20::130])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 2D73A60A93
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 11 Dec 2022 20:24:12 +0000 (UTC)
Received: by mail-il1-x130.google.com with SMTP id y2so2493622ily.5
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 11 Dec 2022 12:24:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gap600.com; s=google;
 h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
 :date:message-id:reply-to;
 bh=It7p3XJfIUfUObx/iQINgMhs1gzLGC+bMf3IYmWRL8A=;
 b=L0ybJAoWxGBF1CFFSuJueRNoqUydPT64ZLMMOc5ZIVRus1b/bxtQVV5Hp3DJ4J/xVn
 J7mlG/CqzcWL/WtkqtQxnlGqe5BlpDjTzEZIYNPZzme5pOuuLOoVNg/Ac+utK/eMWwiw
 a+cw5g66U/KV3W9AeA6ZdEJZlckUrbjwq9KCAwE2UUxZyb2T0DtZZHNfti4EIyks0m/O
 vp8d6mGG0K6U8T48tkXsXxyovut5xsgMHvpm1dkE2ftsCsFjxPz1oma0viUbYM3A3oDg
 sBVdlJSaSQsu7jrgi22yB9fi0d5aFa93tMXpKy4sVlFKziU2zehGlhM1r3haYbePEJTg
 KClw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=to:subject:message-id:date:from:mime-version:x-gm-message-state
 :from:to:cc:subject:date:message-id:reply-to;
 bh=It7p3XJfIUfUObx/iQINgMhs1gzLGC+bMf3IYmWRL8A=;
 b=aj66N7ToRDpoXD3WknZzNbywYgJ2Lnx8EdPH7GP5K5tmprtoQQk7i2c894YyC8vDA3
 lcf8VSXbwcN1FX/Jp+I0XZaj+3PiJ0hQhK9woJqg9sZgKrkwiyRRts5Hqc4QDoK24Qox
 RYCv4usjkHlCdVcJv1HEkl3zFkzdm07GVm+J1EfGf7m/PG82u5kMmzpt+runEHaO1e5G
 QxZrG/X0w4jpOpyWHygvrrMq0ccYKpSM5IqibKtgmM0sgA4NP8d5pA7ChoE0t0woJPf8
 iO0mr0PWMvQAlyo7BBEzTo+efEPGj8iXBiItnxmPe5Ja59fpEXWO5btJNfGYsRqz2mwC
 Q7qA==
X-Gm-Message-State: ANoB5pkMKqYiEkNz5AxZA4ej0TzQxPWpRJHiiJTIImilQjKxEHuB07oq
 W4uezguxALzAOrmavew+CmcJmTfFW/l6OnuZ85hQeE2Cj/u8XbDQ
X-Google-Smtp-Source: AA0mqf5FzsYFOep8vf5YX9K+1LWWptr8sDAIy7SUy4vQ6eYB/dkTWywVEoiP5YeOUsiCBf8STKlqESnHbvo5WXdrZ2w=
X-Received: by 2002:a92:c68a:0:b0:304:b728:fe19 with SMTP id
 o10-20020a92c68a000000b00304b728fe19mr131909ilg.204.1670790250826; Sun, 11
 Dec 2022 12:24:10 -0800 (PST)
MIME-Version: 1.0
From: Daniel Lipshitz <daniel@gap600.com>
Date: Sun, 11 Dec 2022 22:24:00 +0200
Message-ID: <CACkWPs_F94t9Q8TfyYYGxQANUT78SWFGkTOh6qRwnt=6ct7aig@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000065295005ef932b89"
X-Mailman-Approved-At: Mon, 12 Dec 2022 22:58:35 +0000
Subject: [bitcoin-dev] A proposal for Full RBF to not exclude Zero Conf use
	case
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, 11 Dec 2022 20:24:13 -0000

--00000000000065295005ef932b89
Content-Type: text/plain; charset="UTF-8"

Intro
Currently there is a significant use case of 0-Conf acceptance of
transactions. Merchants and service providers are fully aware of the risks
related to 0-conf. Full RBF if it would be significantly enabled would most
likely make 0-conf not possible and significantly limit this current use
case. A primary motivation for full RBF is to enable an increase of fee of
trxs and enable faster acceptance in Block should it be required.

Motivation
To enable full RBF adoption without this impeding the 0-conf use case. This
can be done by enabling the primary use of case full RBF i.e increase the
fee, while keeping the outputs of TRX1 to be included within TRX2.

Method
TRX1 is the trx first published and held in Mempool, TRX2 is the trx which
comes to replace TRX1.

In order for a TRX2 to  replace TRX1 in the Mempool it will require the
following

   - 1. Outputs (addresses and amounts) are the same TRX1 and TRX2

Or


   - 2. TRX2 Outputs include Outputs of TRX1 i.e TRX2 has additional
   Outputs to TRX1

Both cases would require the addition of at least one Input in order to
increase the fee.

In such a case 0-conf acceptance of TRX1 will result in a harmless double
spend since TRX1 will not be included in the valid UTXO set; however
the address beneficiaries of TRX1 will still be credited by TRX2.

This rule would enable the increasing of network fees post publication of
trx without the loss of 0-conf use case.

Drawbacks
Does require access to another Input inorder to take advantage of Full RBF.


Summary
Access to OptinRBF and FullRBF(with above limitation) would give actors
full access to increasing fees as an option. The 0-conf whose risks are
very much understood in the market can continue to exist as is, with the
0-conf ongoing choices being continuing to be available to actors.
________________________________

Daniel Lipshitz
GAP600| www.gap600.com
Phone: +44 113 4900 117
Skype: daniellipshitz123
Twitter: @daniellipshitz

--00000000000065295005ef932b89
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Intro</div><div>Currently there is a significant=C2=
=A0use case of 0-Conf acceptance of transactions. Merchants and service pro=
viders are fully aware of the risks related to 0-conf. Full RBF if it would=
 be significantly enabled would most likely make 0-conf not possible and si=
gnificantly=C2=A0limit this current=C2=A0use case. A primary motivation for=
 full RBF is to enable an increase of fee of trxs and enable faster=C2=A0ac=
ceptance in Block should it be required.</div><div><br></div>Motivation<div=
>To enable full RBF adoption without this impeding=C2=A0the 0-conf use case=
. This can be done by enabling the primary use of case full RBF i.e increas=
e the fee, while keeping the outputs of TRX1 to be included within TRX2.</d=
iv><div><br></div><div>Method</div><div>TRX1 is the trx first published and=
 held in Mempool, TRX2 is the trx which comes to replace TRX1.=C2=A0</div><=
div><br></div><div>In order for a TRX2 to=C2=A0 replace TRX1 in the Mempool=
 it will require the following=C2=A0</div><div><ul><li>1. Outputs (addresse=
s and amounts) are the same TRX1 and TRX2</li></ul><blockquote style=3D"mar=
gin:0 0 0 40px;border:none;padding:0px"><div>Or</div></blockquote><div><ul>=
<li>2. TRX2 Outputs include Outputs of TRX1 i.e TRX2 has additional Outputs=
 to TRX1</li></ul></div><span style=3D"font-size:12.8px">Both cases would r=
equire the addition of at least one Input in order to increase the fee.=C2=
=A0</span></div><div><span style=3D"font-size:12.8px"><br></span></div><div=
><span style=3D"font-size:12.8px">In such a case 0-conf acceptance of TRX1 =
will result in a harmless double spend since TRX1 will not be included in t=
he valid UTXO set; however the=C2=A0address beneficiaries of TRX1 will stil=
l be credited by TRX2.</span></div><div><span style=3D"font-size:12.8px"><b=
r></span></div><div><span style=3D"font-size:12.8px">This rule would enable=
 the increasing of network fees post publication of trx without the loss of=
 0-conf use case.</span></div><div><span style=3D"font-size:12.8px"><br></s=
pan></div><div><span style=3D"font-size:12.8px">Drawbacks=C2=A0</span></div=
><div><span style=3D"font-size:12.8px">Does require access to another Input=
 inorder to take advantage of Full RBF.=C2=A0</span></div><div><br></div><d=
iv><span style=3D"font-size:12.8px"><br></span></div><div><span style=3D"fo=
nt-size:12.8px">Summary</span></div><div><span style=3D"font-size:12.8px">A=
ccess to OptinRBF and FullRBF(with above limitation) would give actors full=
 access to increasing fees as an option. The 0-conf whose risks are very mu=
ch understood in the market can continue to exist as is, with the 0-conf on=
going choices being continuing to be available to actors.<br>______________=
__________________</span><br><div><div dir=3D"ltr" class=3D"gmail_signature=
" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div dir=3D"ltr"><div=
 style=3D"font-size:12.8px"><br></div><div style=3D"font-size:12.8px"><font=
 face=3D"tahoma, sans-serif">Daniel Lipshitz</font></div><div style=3D"font=
-size:12.8px;color:rgb(0,0,0)"><font face=3D"tahoma, sans-serif">GAP600|=C2=
=A0<a href=3D"http://www.gap600.com/" target=3D"_blank">www.gap600.com</a><=
/font></div><div style=3D"font-size:12.8px;color:rgb(0,0,0)"><font face=3D"=
tahoma, sans-serif">Phone:=C2=A0</font><span style=3D"font-family:tahoma,sa=
ns-serif;font-size:12.8px">+44 113 4900 117</span></div><div style=3D"font-=
size:12.8px;color:rgb(0,0,0)"><font face=3D"tahoma, sans-serif">Skype: dani=
ellipshitz123</font></div><div style=3D"font-size:12.8px;color:rgb(0,0,0)">=
<font face=3D"tahoma, sans-serif">Twitter: @daniellipshitz</font></div></di=
v></div></div></div></div></div>

--00000000000065295005ef932b89--