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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id D5422C0052
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 1 Dec 2020 16:24:17 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id C473C86F87
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 1 Dec 2020 16:24:17 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id PHYYwggs-hEs
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 1 Dec 2020 16:24:15 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch
[185.70.40.135])
by whitealder.osuosl.org (Postfix) with ESMTPS id AAF2D86EB9
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 1 Dec 2020 16:24:15 +0000 (UTC)
Date: Tue, 01 Dec 2020 16:24:11 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1606839852;
bh=LxaYH7HdfAlJ/ppfRu5r4HrFA7ksUK05r9Ak749wp/E=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=mUdapecF2+giGjfcWMzhBAnUUos2G1KsEtPQeH9VTvd0lBJ9Hqp8cpCZkI0vOo5ZL
uQhI2ydgfhVuO+j16gOymCruuSezf/1fvrCT543WpO3Kg7rV5CFCKaP+VvZp3JTbYu
Nz80EoCNq1pTPMQmUA8KK5plQAwUoRH86Gjozyb4=
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <OM9jyMUsRukofhHIun9Ij-pmypjN1OjySaKgDjlkDvUleZ13aXRxjltx8nxh_GHQbYmlp2toHhUyANMEbrk1Xp2NVOp_1a2HQcLz27oFlJA=@protonmail.com>
In-Reply-To: <a_ytmG7wahHYE15SU_JER_s2dLFVpI8fRLBZTuV32QuXVOoOq2r7Dyof1tugJUFoE1bDAbYMffJ21HGNPVhh2dLGIWPkIPfEryT2Jk_sg3Y=@protonmail.com>
References: <9a068476-855e-0dd7-4c9c-264d5d8bf60a@gnet.me>
<00e301d6c77e$2a4eeab0$7eecc010$@voskuil.org>
<3f172428-fb03-755f-3020-43817fdb1897@gnet.me>
<a_ytmG7wahHYE15SU_JER_s2dLFVpI8fRLBZTuV32QuXVOoOq2r7Dyof1tugJUFoE1bDAbYMffJ21HGNPVhh2dLGIWPkIPfEryT2Jk_sg3Y=@protonmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [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 <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: Tue, 01 Dec 2020 16:24:17 -0000
Good morning e, and Sebastian,
So it seems, the goals are the below:
* Someone wants to pay a fee to get a transaction confirmed.
* Miners want to know how much they earn if they confirm a transaction.
* The one paying for the fee does not want to link its other coins to the t=
ransaction it wants confirmed.
Would that be a fair restatement of the goal?
If so, it seems to me we can make a CoinJoin-like approach using only L1, a=
nd combine fees by a kind of FeeJoin.
The issue with linking is that if for example the one paying a fee to get a=
transaction confirmed wants to CPFP the transaction, it may need to take a=
nother UTXO it controls into the child transaction, thereby linking its "an=
other UTXO" with the "transaction it wants confirmed".
However, if multiple such individuals were to CoinJoin their transactions, =
the linking becomes much harder to trace.
So a possible mechanism, with a third-party that is trusted only to keep th=
e service running (and cannot cheat the system and abscond with the fees an=
d leave miners without money) would be:
* The third-party service divides its service into fixed-feerate bins.
* Clients select a preferred feerate bin they want to use.
* For each client:
* Connects to the service by Tor to register a transaction it wants to ha=
ve CPFPed.
* Connects to the service by a different Tor circuit to register a UTXO i=
t will use to spend fees.
* The server passes through the CPFPed outputs in the whole value.
* The server deducts the fee from the fee-paying UTXO and creates an output=
with all the fees (CPFP output spend, UTXO input spend, CPFP output re-cre=
ation, UTXO output re-creation) deducted from the UTXO.
* The server gives the resulting transaction to the clients.
* The clients sign the transaction after checking that its interested CPFPe=
d outputs and fee-paying UTXOs are present.
This results in a transaction with many CPFPed inputs and fee-paying UTXOs,=
and no easy way to link the latter with the former.
* Miners and chain analysis cannot link them, as they see only the resultin=
g tx.
* The service cannot link them, as clients talk to them on two separate Tor=
connections.
The above is blatantly the Wasabi way of CoinJoining; using the JoinMarket =
way of CoinJoining should be possible as well, and is left as an exercise t=
o the reader.
Now, you have mentioned a number of times that you believe Bitcoin will eve=
ntually be a settlement layer, and somehow link this with standardized UTXO=
sizes.
But I think the end goal should be:
* To improve Bitcoin blockchain layer privacy.
It should not matter how we achieve this, whether it involves standardized =
UTXO sizes or not; if you want to use this solution, you need to present a =
good reason why this is the best solution for Bitcoin privacy, and better t=
han other solutions.
For example, the JoinMarket way of CoinJoining does not require any particu=
lar standardized UTXO size.
The upcoming SwapMarket that Chris Belcher is working on, also does not req=
uire such a standardized UTXO size, as it is based as well on the JoinMarke=
t technique, where the client can select whatever sizes it wants.
Why should the Bitcoin ecosystem adopt a strict schedule of UTXO sizes for =
privacy, if apparently JoinMarket and SwapMarket can improve privacy withou=
t this?
Regards,
ZmnSCPxj
|
