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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 285C6C001A
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 29 Jun 2021 21:42:36 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 770956089C
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 29 Jun 2021 21:42:34 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.599
X-Spam-Level:
X-Spam-Status: No, score=-1.599 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, FREEMAIL_FROM=0.001,
FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_MSPIKE_H4=0.001,
RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
dkim=pass (1024-bit key) header.d=protonmail.com
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 PG_iAfBFYfkb
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 29 Jun 2021 21:42:32 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch
[185.70.40.135])
by smtp3.osuosl.org (Postfix) with ESMTPS id 29ED860859
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 29 Jun 2021 21:42:31 +0000 (UTC)
Date: Tue, 29 Jun 2021 21:42:26 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1625002949;
bh=B8tsZ5ZZm/ZpRBg6HygE2lguNwprgnZrg8hrWEAW/kg=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=RHfvf1Q4SWusgdX8B9hP/mofUbpeAV4FOS0cmznFcwDK6jWkCt0fEKDWb9V450+NH
LsFXAiZGC2ZHdxD8MOZp0DqkI4hwaaRSz/UCrFrcPR+eRblOzjuHdF+zvl8OovqHyU
51SztEiN3SztB99f8SjRABucEFJ/2Tahk1QrU19M=
To: "raymo@riseup.net" <raymo@riseup.net>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <vBVgArAP_YhmuuUtZS9nbrx_JI0B-Sw0x3RdBvc7QJ8s_EvnW6hkNpWyu6MdJJBrV3zv5OxZcMMgooG1yNI4naXvgJbIWIOSyVLdoUwwymM=@protonmail.com>
In-Reply-To: <878e0de9f6b08d8aad07fc7b7760e01b@riseup.net>
References: <bea8122aea550f1141170829aac252af@riseup.net>
<ly7o0mtsw7cm0sY-R_TMlTzEDixdQkLhAJJP5-3zEthlJEO9IqUPtb_BkAT-fmltTr1juvZ8SYrQ73-ElSlOfGWlKRTX6FAV5mHQC6NbNt8=@protonmail.com>
<edee179d873eb9db551204561db17e90@riseup.net>
<A5gXRNtpLIWjF8Uq7CRLiwl9mb1eEY7IW7AQfQL_7uW9cXCKLn6FdOyYKBq1Dl1L-vgCBwFUgC873WyEEpS6K9F7ct4mdwRMKco01xsWhHg=@protonmail.com>
<c2e7b6336190c5dae6383abb284c335b@riseup.net>
<zs9XYSRzwoyhcfqXvyXG67bZqNTUt5_0DZwjrsyEKrvFbaxhX6jEAXBXPP01HnkxgApU8oGMXdOBVdgSHXBFrKAYLzCg_OmoIvO2EfsqJJg=@protonmail.com>
<16131549ac084b58fc6cde894e43babe@riseup.net>
<CA+2b5C2m6m2-OHKa7dVGiQcQG-dv82xQQQc45QrmeDz6HS2skQ@mail.gmail.com>
<878e0de9f6b08d8aad07fc7b7760e01b@riseup.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Boost Bitcoin circulation,
Million Transactions Per Second with stronger privacy
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, 29 Jun 2021 21:42:36 -0000
Good morning Raymo,
> Hey Alex,
>
> Your scenario works perfectly unless we put some restrictions on
> accepting transaction by creditor (in our case Bob).
> These are restrictions:
> Alice has to use a UTXO (or some UTXOs) worth at least 40,000 Sat as
> transaction input.
> Alice has to reserve 10,000 Sat as transaction fee (for MT transaction)
> regardless of transaction length or input/output amounts.
> Alice always pays at least 4,000 Sat of BTC-transaction-fee, and the
> 6,000 remined fee must be paid by she and Bob in proportion to their
> outputs amounts)
> Alice can issue a transaction the has maximum 20,000 outputs for
> creditors (Bob and others).
> The rest (if exist) is change back to Alice address.
> The GT is formed based on MT.
> Bob considers a transaction couple (MT, GT) valid only if they respect
> these rules.
>
> Let=E2=80=99s put it in practice using some numbers (although you can fin=
d more
> detailed explanation in paper).
>
> The MT would be like that:
> Input: 40,000 Satoshi
> Outputs:
> Bob: 20,000
> BTC-fee: 10,000
> Change back to Alice: 10,000
>
> Based on this MT the GT will be
> Input: 40,000 Satoshi
> Outputs:
> Bob: 20,000 =E2=80=93 20,00070% =3D 6,000
> BTC-fee: 10,000 + (14,000 of Bob=E2=80=99s output) + (1,500 of Alice=
=E2=80=99s change
> back) =3D 25,500
> Change back to Alice: 10,000 =E2=80=93 10,00015% =3D 8,500
>
> Now if Alice wants to spend UTXO to Charlie with higher fee, she has to
> pay at least 25,500 + 1 Satoshi as BTC fee in order to convince miners
> to put his fraudulent transaction instead the GT in next block.
> Alice already got 20,000 Sat profit from Bob. Now she can earn another
> 14,999 Sat profit from Charlie because of same UTXO worth 40,000
> Satoshi.
> Indeed, she spent 40,000 Sat and in total got equal to 34,999 Sat goods
> or services.
> Is she a winner?
> I am not sure!
> What do you think?
You assume here that Alice the issuer only has a single UTXO and that it cr=
eates a single transaction spending that UTXO.
It is helpful to remember that miners consider fee*rate*, but your security=
analysis is dependent on *fee* and not fee*rate*.
Now consider, what if Alice creates 1000 UTXOs, promises GTs and MTs to 100=
0 different Bobs?
Now, a GT has one input and two outputs.
1000 GTs have 1000 overheads (`nLockTime` and `nVersion` and so on), 1000 i=
nputs, and 2000 outputs.
Now Alice the issuer, being the sole signer, can create a fraudulent transa=
ction that spends all 1000 UTXOs and spends it to a single Carol output.
This fraudulent transaction has 1 overhead, 1000 inputs, and 1 output.
Do you think Alice can get a better fee*rate* on that transaction while pay=
ing a lower aggregate *fee* than all the GTs combined?
Remember, you based your security analysis on Alice being forced to pay a l=
arger *fee*, but neglect that miners judge transactions based on fee*rate*,=
which is subtly different and not what you are relying on.
I am sure that there exists some large enough number of UTXOs where a singl=
e aggregating fraudulent transaction will be far cheaper than the tons of l=
ittle GTs your security analysis depends on.
This is why we do not use 1-of-1 signers in safe offchain protocols.
Not your keys, not your coins.
--
In addition, your analysis is based on assuming that miners are perfect rat=
ional beings of perfect rationality, ***and*** are omniscient.
In reality, miners possess bounded knowledge, i.e. they do not know everyth=
ing.
Even if Alice is in possession of only a single UTXO, Alice can still feed =
miners a transaction with lower feerate than the MT, then feed the rest of =
the network with a valid MT.
Because transactions propagate through the network but this propagation is =
***not*** instantaneous, it is possible for the MT to reach the miners late=
r than the fraudulent transaction.
In this window of time, a block may be mined that includes the fraudulent t=
ransaction, simply because the lucky miner never managed to hear of the cor=
rect MT.
This attack is essentially costless to Alice, especially for big enough tra=
nsactions where mining fees are a negligible part of the payment.
This is why we do not use 1-of-1 signers in safe offchain protocols.
Not your keys, not your coins.
Regards,
ZmnSCPxj
|
