summaryrefslogtreecommitdiff
path: root/94/4c51eb0d0f85bc89a990a03b209bff794136a1
blob: 39e5e54e88cc4d67bfbceeb2c519944ac37921e9 (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
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
Return-Path: <raymo@riseup.net>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 2F6A9C000E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 28 Jun 2021 16:33:27 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 1CCE6605F4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 28 Jun 2021 16:33:27 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.822
X-Spam-Level: 
X-Spam-Status: No, score=-2.822 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, RCVD_IN_DNSWL_LOW=-0.7,
 RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01,
 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=riseup.net
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 WoujBpTzYyTK
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 28 Jun 2021 16:33:25 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129])
 by smtp3.osuosl.org (Postfix) with ESMTPS id A0FC8605DD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 28 Jun 2021 16:33:25 +0000 (UTC)
Received: from fews2.riseup.net (fews2-pn.riseup.net [10.0.1.84])
 (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
 (Client CN "*.riseup.net",
 Issuer "Sectigo RSA Domain Validation Secure Server CA" (not verified))
 by mx1.riseup.net (Postfix) with ESMTPS id 4GDCpY0NtpzDqgW;
 Mon, 28 Jun 2021 09:33:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak;
 t=1624898005; bh=8ydQprVlGhUe0WG14QDDnijQRFfvQNxwXEhgw9F4mY8=;
 h=Date:From:To:Cc:Subject:In-Reply-To:References:From;
 b=T4d7RQ3w5LvLpgQ9gjzh8bKIjupkLkBFuvCu/z57tohvhKG3NVnua52gF7THx5Jbs
 TvM41ldOTguPlZpPEjbOB1EvvsRgj/2nn296JcDtn8+wwl1GVihFG2ogw0KZmOncEB
 6EF957rTIvAmL5mnWWns7QyxVI2AYI6l1CppqRbQ=
X-Riseup-User-ID: F2A4E0C1EFCA99B14558D1251C3D34BBE935EC64113D4DCB7B2A87521473F727
Received: from [127.0.0.1] (localhost [127.0.0.1])
 by fews2.riseup.net (Postfix) with ESMTPSA id 4GDCpX6FsTz20b5;
 Mon, 28 Jun 2021 09:33:24 -0700 (PDT)
MIME-Version: 1.0
Date: Mon, 28 Jun 2021 09:33:24 -0700
From: raymo@riseup.net
To: James Hilliard <james.hilliard1@gmail.com>
In-Reply-To: <CADvTj4qQ=xcpCZRigkXGm2CzduO=AXc22GjghSe6RA37XjrPzA@mail.gmail.com>
References: <bea8122aea550f1141170829aac252af@riseup.net>
 <6leV9mViysrSOipJqrCM3wbqBOMO2gWI3BuEn0VKmaDf7GpawWyUIWLu-ddypMri7YeVmw94HNSaQYYp8fIkjZ0S3OtFTPQa6h9pkLprKDI=@protonmail.com>
 <9c2cec326adee1f4d4152e2195da0e7b@riseup.net>
 <ly7o0mtsw7cm0sY-R_TMlTzEDixdQkLhAJJP5-3zEthlJEO9IqUPtb_BkAT-fmltTr1juvZ8SYrQ73-ElSlOfGWlKRTX6FAV5mHQC6NbNt8=@protonmail.com>
 <edee179d873eb9db551204561db17e90@riseup.net>
 <A5gXRNtpLIWjF8Uq7CRLiwl9mb1eEY7IW7AQfQL_7uW9cXCKLn6FdOyYKBq1Dl1L-vgCBwFUgC873WyEEpS6K9F7ct4mdwRMKco01xsWhHg=@protonmail.com>
 <c2e7b6336190c5dae6383abb284c335b@riseup.net>
 <CADvTj4rD90A7FeBw8T_SvDupm0z7CfuXKZ2S=hR0A8CFv0-bSg@mail.gmail.com>
 <795618e761cd97c9216533cc82ed4624@riseup.net>
 <CADvTj4qQ=xcpCZRigkXGm2CzduO=AXc22GjghSe6RA37XjrPzA@mail.gmail.com>
Message-ID: <873a11fde1af998012b7f92309e0dfea@riseup.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Mailman-Approved-At: Mon, 28 Jun 2021 16:42:33 +0000
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: Mon, 28 Jun 2021 16:33:27 -0000


Hi James,

> There's only one practical approach I'm aware of for miners to actually
> do this, and that would be to effectively make mining centralized.
> So I would highly discourage this sort of policy when it comes to mining.
I do not know about the approach you talking about it, but my solution
is not centralized at all. In Sabu proposal/architecture you can find
the doc-watchers network. It will be a torrent-like network where nodes
just gossip the very light information about used UTXOs in Sabu
protocol. All nodes will receive information and flood it to other
nodes. So, all nodes just mirror same information.

Two types of information are transferring through this peer-to-peer
doc-watcher network. 
One is a very minimal record history of the UTXOs and a Merkle root of
proper Sabu transactions. This information will be used by mobile wallet
to be ensure issuer didn’t promise same UTXO to different creditors. 

The second data type are moving through doc-watchers nodes are signed
UTXOs in order to signal to miners the fact that this UTXO is promised
to some creditors. So, miners won’t allow this UTXO to be used in other
ways to promise. In order to release (un-pledge) this UTXO the issuer
has to sign it again alongside a release request. 
It is roughly what I suppose to be implemented and be respected by
miners in future. It wouldn’t be centralized unless you believe torrent
is centralized. Miners can/will control UTXOs status (in sense of is
promised to someone or not) before putting them in batch template.

> Miners regularly change block headers, and if they don't broadcast the
> transactions there wouldn't really be a time limit, so even a relatively small
> miner would be able to stealthily mine the transactions given enough time.
It means a miner at least every 10 minutes has to change the header and
re-try to solve the puzzle. Yes, a miner or a mining pool can stealthily
mine transactions given enough time. And we already knew time of solving
a puzzle is almost random. So “maybe” the small miner is enough lucky to
find a block full of fraudulent transaction. But the question is; this
effort to fraud, how much more economically beneficial than
participation in the healthy chain will be? The answer will tell us the
feasibility of Sabu protocol.

There is another protection that won't let the worker and creditor to
mine stealthily a particular UTXO set for unlimited time. 
please read the appendix "V: Recycling UTXOs" for more details.

> Why would they need to solve the block within 10 minutes?
You are right, they are not forced to solve it in 10 minutes but
definitely they have to change the header every 10 minutes. Otherwise,
they would end up in mining an orphan block which has no sense. 
Although it is not linear, but I used to believe changing block header
every 10 minutes will reduce efficiency and chance of solving puzzle
dramatically. 
	

> All that matters is if that extra is more than they would otherwise get.
Yes, while it is true, but it is not enough. We need numbers and
calculation to find if this kind of attack is possible? And how much is
the possibility? And…
An attack with 0.01% of success is obviously a failed plan and no one
consider it as a threat. Although even this small threat will be resolve
by the mentioned BIP absolutely.


About the timing details.
You are right. The less batch update time means more chance to
fraudulent transaction replaced by the GT transaction. 
BTW even this scenario would be improved by suggested BIP
implementation, since the fraudulent transaction won’t be in batch
template at all.

Best


On 2021-06-28 11:28, James Hilliard wrote:
> On Mon, Jun 28, 2021 at 3:52 AM <raymo@riseup.net> wrote:
>>
>>
>> Hi James,
>> Sorry for not responding in detail.
>> So, lets jump in the critiques.
>>
>> > You're making the assumption that miners won't build on top of a block
>> with transactions they have not seen before or transactions that may
>> contain double spends of unconfirmed inputs
>> No, it is a wish. I hope in future miners consider this rule as well.
> 
> There's only one practical approach I'm aware of for miners to actually
> do this, and that would be to effectively make mining centralized.
> So I would highly discourage this sort of policy when it comes to mining.
> 
>> But for now, I absolutely do not count on this restriction. So, miner
>> can/will accept a valid block which contains some valid transactions
>> which they didn’t aware of those transactions in advance.
> 
> Mempools among miners are generally not fully in sync with each other,
> rejecting valid blocks due to disagreements over which transactions were
> broadcast would destabilize the network as you'd get a bunch of network
> forks.
> 
>> In order to explain how economically this won’t happened, I have to
>> refer you to the fact that a conspiracy between a miner(mining pool) and
>> a group of issuers to mine a block full of cheating transaction will
>> makes 1.2 Bitcoin illicit income plus block coinbase income (6.25 BTC
>> now). The 1.2 is coming from average(max) 6,000 transaction per block *
>> max 20K Satoshi cheating benefit for each promised used UTXO in a
>> debt-doc(transaction).
> 
> But there's no risk really for a miner to choose the most profitable
> transactions to mine as long as they are valid per the network rules,
> that is unless you make mining fully centralized.
> 
>> In order to achieve this conspiracy, the mining pool has to mine the
>> block in stealth, lonely and without broadcasting any of transactions to
>> Bitcoin network. They have only 10 minutes to solve puzzle, otherwise
>> they have to change the block header and restart again. After all, if
>> they succeed, they have to divide this extra dirty 1.2 BTC in between. I
> 
> Miners regularly change block headers, and if they don't broadcast the
> transactions there wouldn't really be a time limit, so even a relatively small
> miner would be able to stealthily mine the transactions given enough time.
> 
>>
>>
>> I am not expert in mining pool calculations; you may help me to answer
>> these questions?
>>
>> Consider these given facts:
>>
>> More hashrate = more success chance.
>> More hashrate = more electric cost = less profit per each participator
>> There is a minimum hashrate to have a minimum chance to solve the puzzle
>> in next 10 minutes, otherwise it doesn't make sense to participate in an
>> activity that doesn't fit the minimum hope.
> 
> Why would they need to solve the block within 10 minutes?
> 
>> How much is this minimum hashrate?
> 
> I don't think there is a minimum.
> 
>> How much costs this hashrate?
> 
> Miners just use pools to reduce variance, there isn't a set minimum size to
> solo mine, only how much variance the miner can tolerate.
> 
>> Note the fact that the maximum extra income is a fixed 1.2 BTC. Would it
>> be economically cost effective (risk to reward) to dedicate your
>> hashrate to mine this block? I am not sure. But if you show me the
>> opposite by facts and numbers, I will highly appreciate you.
> 
> All that matters is if that extra is more than they would otherwise get.
> 
>>
>> > What would this BIP look like?
>> > We suppose the miners always control transactions with doc-watchers
>> As I told before, these assumptions are my wishes and I never relayed on
>> these wishes. These are for future. For now, I just count on the
>> calculation that asked you to help.
> 
> The reason I ask is because I don't think this is possible to do
> without massively
> centralizing mining.
> 
>>
>> > there can be significant latency between the time a transaction is
>> actually broadcast and hits the miners mempool and the time the miners
>> actually switch to mining on top it
>>
>> It is great. Although this latency could be lesser (in case of empty
>> mempools), but Sabu likes this latency. Because the creditors will have
>> more time to be aware of a fraudulent activity from issuer and existence
>> of a cheating transaction in mempool, so they have more time to send and
>> broad cast the GT to network. More latency, more chance in batch update.
>> So more chance for miners to face two or three transactions which are
>> using same UTXO but sending to different addresses and paying different
>> fees.
>> More latency increases the chance of putting the higher-fee-payer
>> transaction in next block.
> 
> Actually it's the opposite, if pools updated their templates every second
> the GT transaction could almost immediately replace the fraudulent transaction,
> however due to the batch updating if the fraudulent transaction ended up
> in a template it could take a significant amount of time for it to be purged
> from all the mining pool templates, no matter the fee difference.
> 
> Ultimately this means that one should always expect miners to mine the
> first seen transaction for a significant period of time, with no guarantees
> that it would be replaced.
> 
>>
>> Regards
>> Raymo
>>
>>
>> On 2021-06-28 08:23, James Hilliard wrote:
>> > On Mon, Jun 28, 2021 at 2:09 AM raymo via bitcoin-dev
>> > <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> >>
>> >> Hi ZmnSCPxj,
>> >>
>> >> Why you get the signal “trust the Gazin wallet”?
>> >> Sabu is a protocol and the Gazin wallet will be an implementation of
>> >> that protocol. We will implement it in react-native language to support
>> >> both Android and iPhone. Of course it will be open source and GPL3.
>> >> Here is the repository and yet is empty :)
>> >> https://github.com/raymaot/Gazin
>> >>
>> >> I wonder why you do not look carefully into the proposal! IMHO the Sabu
>> >> will be far better than Lightning.
>> >> Can’t you see the fact that in Sabu you do not need open and close
>> >> channels ever? Can you imagine only this feature how dramatically
>> >> decrease the transactions cost and how increase the distribution of
>> >> nodes and improve privacy level? it makes every mobile wallet act like a
>> >> lightning network.
>> >> Did you note the fact that in Sabu protocol there is no routing? And the
>> >> only people knew about a transaction are issuer and creditor? No one
>> >> else won’t be aware of transactions and million transactions per second
>> >> can be sent and received and repeal dynamically without any footprint on
>> >> any DLT?
>> >>
>> >> The English is not my mother language and probably my paper is not a
>> >> smooth and easy to read paper, but these are not good excuse to not even
>> >> reading a technical paper carefully and before understanding it or at
>> >> least trying to understanding it start to complaining.
>> >
>> > Considering that you have not effectively addressed any of the inaccurate
>> > assumptions made regarding how mining works that I pointed out earlier
>> > I assume your proposal is not viable in practice.
>> >
>> > See:
>> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019091.html
>> >
>> >>
>> >> > All the benefits your scheme claims, are derived from the trust assumption
>> >> No, All the benefits my scheme claims, are derived from economically
>> >> rational decision of both issuer and creditors.
>> >>
>> >> Regards
>> >> Raymo
>> >>
>> >>
>> >>
>> >> On 2021-06-28 05:20, ZmnSCPxj wrote:
>> >> > Good morning Raymo,
>> >> >
>> >> >>
>> >> >> It looks you already missed the entire design of Sabu and its
>> >> >> restrictions. First of all, the Gazin wallet always controls the Sabu
>> >> >> restrictions for every transaction in order to consider it as a valid
>> >> >> transaction in a valid deal. That is, the creditor wallet controls the
>> >> >> MT and GT in first place.
>> >> >
>> >> > Stop right there.
>> >> >
>> >> > From the above, what I get is, "trust the Gazin wallet".
>> >> > Thus, the suggestion to just use Coinbase.
>> >> > At least it has existed longer and has more current users that trust
>> >> > it, rather than this Gazin thing.
>> >> >
>> >> >
>> >> > Is Gazin open-source?
>> >> >
>> >> > * If Gazin is open-source, I could download the source code, make a
>> >> > local copy that gives me a separate copy of the keys, and use the keys
>> >> > to sign any transaction I want.
>> >> > * If Gazin is not open-source, then why should I trust the Gazin
>> >> > wallet until my incoming funds to an open-source wallet I control have
>> >> > been confirmed deeply?
>> >> >
>> >> > Lightning is still superior because:
>> >> >
>> >> > * It can be open-sourced completely and even though I have keys to my
>> >> > onchain funds, I *still* cannot steal the funds of my counterparty.
>> >> > * Even if I connect my open-source node to a node with a closed-source
>> >> > implementation, I know I can rely on receives from that node without
>> >> > waiting for the transaction to be confirmed deeply.
>> >> >
>> >> >
>> >> > All the benefits your scheme claims, are derived from the trust
>> >> > assumption, which is uninteresting, we already have those, they are
>> >> > called custodial wallets.
>> >> > Lightning allows for non-custodiality while achieving high global TPS
>> >> > and low fees.
>> >> > And a central idea of Lightning is the requirement to use an n-of-n to
>> >> > form smaller sub-moneys from the global money.
>> >> >
>> >> > Regards,
>> >> > ZmnSCPxj
>> >> _______________________________________________
>> >> bitcoin-dev mailing list
>> >> bitcoin-dev@lists.linuxfoundation.org
>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev