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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id B10C0C000E
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 27 Jun 2021 04:54:08 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 89EA44033B
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 27 Jun 2021 04:54:08 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level:
X-Spam-Status: No, score=-1.601 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
dkim=pass (1024-bit key) header.d=protonmail.com
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 Rr8qO4JHJn2E
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 27 Jun 2021 04:54:06 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-40138.protonmail.ch (mail-40138.protonmail.ch
[185.70.40.138])
by smtp4.osuosl.org (Postfix) with ESMTPS id 5BDC4402C6
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 27 Jun 2021 04:54:06 +0000 (UTC)
Date: Sun, 27 Jun 2021 04:53:52 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail; t=1624769642;
bh=Y266dpzedqlN+nv/Ldl0kw7+ZbJN91IstvSnKWdhc/k=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
b=aaOl5Cy1TmhTCxqSKazzjtYEScfthArguUG/410A4LP2Uq37xCNqX6pt7IhRqmT+f
w8GcdWzZzW1hpb+Ky2Cj/O9ONj9MhKQo/RtILJA4JjevXYdNsgIP48TRkf4GqHPRQu
8oiv4vA+fEqlyYZleDwna5lssvPck8/fyI2Lx6Cs=
To: "raymo@riseup.net" <raymo@riseup.net>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <ly7o0mtsw7cm0sY-R_TMlTzEDixdQkLhAJJP5-3zEthlJEO9IqUPtb_BkAT-fmltTr1juvZ8SYrQ73-ElSlOfGWlKRTX6FAV5mHQC6NbNt8=@protonmail.com>
In-Reply-To: <9c2cec326adee1f4d4152e2195da0e7b@riseup.net>
References: <bea8122aea550f1141170829aac252af@riseup.net>
<6leV9mViysrSOipJqrCM3wbqBOMO2gWI3BuEn0VKmaDf7GpawWyUIWLu-ddypMri7YeVmw94HNSaQYYp8fIkjZ0S3OtFTPQa6h9pkLprKDI=@protonmail.com>
<9c2cec326adee1f4d4152e2195da0e7b@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: Sun, 27 Jun 2021 04:54:08 -0000
Good morning Raymo,
> Good morning ZmnSCPxj
> Sorry for late reply.
>
> > Guarantee Transactions (GT) being higher-fee is not assured.
>
> The question is =E2=80=9Cassuring what?=E2=80=9D.
> The whole point of my proposal is the fact that issuers and creditors
> act rationally and won't harm their selves. The numbers (input and
> output amounts), the relation between inputs and outputs amounts, the
> minimum and maximum of inputs and outputs amounts, and conditions of a
> valid trans-action in Sabu protocol are all designed precisely to
> leading the rational users toward the making profit from the system. And
> irrationals (either issuer or creditor) can harm the others and
> inevitably in con-sequence will hurt themselves too. So, there is a fair
> and just transaction (MT).
> The creditor can send the GT to Bitcoin network and lose 70% of his
> money and damage 15% of is-suer money!
> Vice versa the issuer can send GT to Bitcoin network and harm itself 15%
> in cost of hurt creditors 70% which is none sense. Or issuer can pay
> even more money directly to miner and hurt itself even more which is
> even more irrational! Or the miner will ignore the transaction fees of a
> GT and put the fraudulent transaction in next block, which I cannot
> imagine a miner that pass up his legal and legiti-mate income in favor
> of a greedy issuer!
> Please write me a scenario (preferably with clear amount of inputs and
> outputs) by which the cheater (either issuer or creditor) gains more
> profit than playing honestly.
> Only in this case we can accept your claim about weakness of protocol.
>
> > Every offchain protocol needs the receiver as a signatory to any unconf=
irmed transaction. the receiver must be a signatory --- the receiver cannot=
trust an unconfirmed transaction where the spent UTXO has an alternate bra=
nch that does not have the receiver as a signatory.
>
> I intentionally decided to not using 2 of 2 signature, because I didn't
> want to fall in same trap as Light-ening. I wanted to avoid this long
> drilling 2 of 2 signings and routing. Instead, I just proposed to
> cre-ate and sign a valid Bitcoin transaction between only 2 people in a
> pure-peer-to-peer communication. The only signer is the issuer (the UTXO
> owner).
> Again, same logic. Please write me a scenario by which the cheater
> (issuer or creditor) can cheat this only-issuer-signed transactions and
> gains more profit than playing honest. Due to numbers and trans-action
> restrictions and the insignificance of the amount of each transaction
> this scenario of fraud will fail too.
As the issuer is the only one signing, it can trivially create a self-payin=
g transaction by itself that is neither a valid MT nor a valid GT.
Suppose I have an MT that pays 1 BTC to you and has a 1 BTC change output b=
ack to me.
After you hand over the equivalent of 1 BTC in other resources, I then crea=
te an alternative transaction, signed only by myself, paying 0.5 BTC to min=
ers and 1.5 BTC to myself, and since the fee is so high, the miners have ev=
ery incentive to mine it.
Yes, that is not a valid MT or GT, but nothing in the Bitcoin blockchain la=
yer requires that the *single* signer follow the protocol.
The point here is that a single signer can sign anything, including a trans=
action that is not an MT or a GT, but has arbitrary numbers that are neithe=
r a valid GT nor a valid MT.
That is the reason why every trust-minimized offchain system requires 2-of-=
2, somebody else has to countercheck the validity of a protocol that is *no=
t* directly on the blockchain.
The blockchain only cares about signature and timelock validity; it does no=
t care about (and check for validity) MTs and GTs.
In essence, this is a trusted system where every creditor trusts every issu=
er to *only* sign GTs and MTs, thus uninteresting --- you might as well jus=
t use Coinbase as your offchain if you are going to inject trust.
Now you can counterargue that you intend this system to be used for small p=
ayments and thus the fee for this non-MT non-GT clawback can approach the s=
ecurity levels you so carefully computed for GT and MT, but again --- the *=
largest* safe payment will vary depending on onchain mempool state, and if =
the mempool is almost empty, the largest safe payment will be much smaller =
than at other times.
This uncertainty is not handled well by most users, thus I think your UX wi=
ll be fairly awful.
Regards,
ZmnSCPxj
|
