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
|
Return-Path: <jlrubin@mit.edu>
Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 10826C0051
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Sep 2020 16:16:42 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by silver.osuosl.org (Postfix) with ESMTP id EA72820396
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Sep 2020 16:16:41 +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 2ybSfKwQXflA
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Sep 2020 16:16:40 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
by silver.osuosl.org (Postfix) with ESMTPS id 06D2D20379
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Sep 2020 16:16:39 +0000 (UTC)
Received: from mail-ej1-f43.google.com (mail-ej1-f43.google.com
[209.85.218.43]) (authenticated bits=0)
(User authenticated as jlrubin@ATHENA.MIT.EDU)
by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 08JGGbjU027646
(version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
for <bitcoin-dev@lists.linuxfoundation.org>; Sat, 19 Sep 2020 12:16:38 -0400
Received: by mail-ej1-f43.google.com with SMTP id z22so12087405ejl.7
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Sep 2020 09:16:38 -0700 (PDT)
X-Gm-Message-State: AOAM533GqkICokW1FrfBTGMdb1xrCZhgUSefIRvI0RQeJPSjCTFnScbP
5fmrgPQOmy7ijXeXLfg1wq3qWTqtXwviaXpJ2lU=
X-Google-Smtp-Source: ABdhPJxOAnQzVkirOvcQcFD1a/aOgdSaGdI6Ok8B/o4YapLCuQuvQLXhr22EwJaEF3YvYLH6Lpc0z0Fg/HiO+NuAk50=
X-Received: by 2002:a17:906:d936:: with SMTP id
rn22mr42130587ejb.4.1600532197301;
Sat, 19 Sep 2020 09:16:37 -0700 (PDT)
MIME-Version: 1.0
References: <CAD5xwhi6+Q-UX2xVnD4TE9uEbe-omQ748tpJJpYdrMNnG6D5vA@mail.gmail.com>
<CAApLimiFXmX6OPe6wsvvV3YeL8i0-Y7RVvugzLBeADh3go-BzQ@mail.gmail.com>
In-Reply-To: <CAApLimiFXmX6OPe6wsvvV3YeL8i0-Y7RVvugzLBeADh3go-BzQ@mail.gmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Sat, 19 Sep 2020 09:16:25 -0700
X-Gmail-Original-Message-ID: <CAD5xwhhmA9C4aF4fybfObzdGY752r74ByUfQBZzQ5rz-sR+qoQ@mail.gmail.com>
Message-ID: <CAD5xwhhmA9C4aF4fybfObzdGY752r74ByUfQBZzQ5rz-sR+qoQ@mail.gmail.com>
To: lists@coryfields.com, adam.ficsor73@gmail.com
Content-Type: multipart/alternative; boundary="00000000000012620f05afacf1b8"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] A Replacement for RBF and CPFP: Non-Destructive
TXID Dependencies for Fee Sponsoring
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: Sat, 19 Sep 2020 16:16:42 -0000
--00000000000012620f05afacf1b8
Content-Type: text/plain; charset="UTF-8"
Hi Cory!
Thanks for taking a look. CC nopara as I think your questions are the same.
I think there are a few reason we won't see functionally worse privacy:
1. RBF/CPFP may require the use of an external to the original transaction
to pay sufficient fee.
2. RBF/CPFP may leak which address was the change and which was the payment.
In addition, I think there is a benefit in that:
1. RBF/CPFP requires access to the keys in the same 'security zone' as the
payment you made (e.g., if it's a multi-sig to multi-sig requires m of N to
cpfp/or RBF, whereas sponsors could be anyone).
2. Sponsors can be a fully separate arbitrary wallet.
3. You can continually coinjoin the funds in your fee-paying wallet without
tainting your main funds.
4. You can keep those funds in a lightning channel and pay your fees via
loop outs.
--00000000000012620f05afacf1b8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div style=3D"font-family:arial,helvetica,sans-serif;font-=
size:small;color:rgb(0,0,0)" class=3D"gmail_default">Hi Cory!</div><div sty=
le=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,=
0)" class=3D"gmail_default"><br></div><div style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">T=
hanks for taking a look. CC nopara as I think your questions are the same.<=
/div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"font-famil=
y:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gma=
il_default">I think there are a few reason we won't see functionally wo=
rse privacy:</div><div style=3D"font-family:arial,helvetica,sans-serif;font=
-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
" class=3D"gmail_default">1. RBF/CPFP may require the use of an external to=
the original transaction to pay sufficient fee.</div><div style=3D"font-fa=
mily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"=
gmail_default">2. RBF/CPFP may leak which address was the change and which =
was the payment.</div><div style=3D"font-family:arial,helvetica,sans-serif;=
font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div st=
yle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0=
,0)" class=3D"gmail_default">In addition, I think there is a benefit in tha=
t:</div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:smal=
l;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"font-fa=
mily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"=
gmail_default">1. RBF/CPFP requires access to the keys in the same 'sec=
urity zone' as the payment you made (e.g., if it's a multi-sig to m=
ulti-sig requires m of N to cpfp/or RBF, whereas sponsors could be anyone).=
</div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:rgb(0,0,0)" class=3D"gmail_default">2. Sponsors can be a fully separa=
te arbitrary wallet.<br></div><div style=3D"font-family:arial,helvetica,san=
s-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">3. You ca=
n continually coinjoin the funds in your fee-paying wallet without tainting=
your main funds.</div><div style=3D"font-family:arial,helvetica,sans-serif=
;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">4. You can keep =
those funds in a lightning channel and pay your fees via loop outs.</div><d=
iv style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rg=
b(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"font-family:arial=
,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_defa=
ult"><br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-si=
ze:small;color:rgb(0,0,0)" class=3D"gmail_default"></div><br></div>
--00000000000012620f05afacf1b8--
|
