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
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
|
Return-Path: <fresheneesz@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 0E37CC000E
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 7 Jul 2021 06:19:19 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id E456460756
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 7 Jul 2021 06:19:18 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001, TVD_PH_BODY_ACCOUNTS_PRE=0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.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 YYah-P2GlO5y
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 7 Jul 2021 06:19:17 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com
[IPv6:2a00:1450:4864:20::533])
by smtp3.osuosl.org (Postfix) with ESMTPS id D82A860668
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 7 Jul 2021 06:19:16 +0000 (UTC)
Received: by mail-ed1-x533.google.com with SMTP id s15so1797238edt.13
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 06 Jul 2021 23:19:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=fToaoPC16yO64/A8F+Y+Qv5rq92vvo3nAWgrIv1eLEI=;
b=pWzIU5dTpHny5ZI1YCb5sx5O/VtBW/tf52KAvHHaXzjNgmq56gPcDm6a3kDnUHPMIz
LID1L47DvDfbo1nfZEawoBWJEY55eq8FSS0usURY3oFcgkKLj40V6Zpep5Y5tUW54V9c
J/oJ/0xBhK83jZc7R88RHczn+/ehhCDOGrQPHG4c7R5w8AcMiZeeFFs6jU4W5go9ocuH
h4gPp7j//RKJ9Wsw76wgf1sgWJhLPIOVssWoRVsYxvNoceZr2ehjA1ASfVVX21uI3czU
sUmrtahdydAzu/HCm4dnR5GFImxOwRyAeUEDhuhnyjF0MDtgc+3uRRZHuQamdLvpawIp
skgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=fToaoPC16yO64/A8F+Y+Qv5rq92vvo3nAWgrIv1eLEI=;
b=IcHPjZYXIybZVrJlQgsrp0QqrEXV5NdrczsJ8+AlCIJomr8OnX3mUtZgZo/XpJ4uNR
aBX5W7h4zeGb7FkyBmsuir+eAWKsQwZD2UQb9lqrJTz8M3Na0M85eK5puFKTV8VU0Jct
iZV6XIRBUkTVOrYg+0s/h2iofwSapXkMRNXow2dGA2yn0GOVpqdMFe0F4XDhwELs6NBI
uSY29O1DdyKBDaTzPg4K0Rgarwk1bl9jnvAMH8mAtaOip+V583y3UfOS9wWQ7Ok2aekZ
KpqS2NWzeZyuWK+EwwlfiK06+vNYOImWUFha+UlYMv2cMC2+qr5hCzqxw7nrsVnEF4z7
5RfQ==
X-Gm-Message-State: AOAM530MD/gjwQJ4S6UQYCzbRHWAtVehfT/gvL+Y+OI27UHfI79TR7Ds
tUCM2xR1fyRCJvrkv8VdFAvzBAWBisrRUt3ZimU=
X-Google-Smtp-Source: ABdhPJytAx1tNMV9B+fauXHSscIPpcUuyUcU5iw+bBfNqH8x2zugrdXbpUyjjuSksA8WW1JyxGoh/2nEfDe/I4Psgww=
X-Received: by 2002:aa7:dd0d:: with SMTP id i13mr15712842edv.97.1625638754903;
Tue, 06 Jul 2021 23:19:14 -0700 (PDT)
MIME-Version: 1.0
References: <CAGpPWDbTyxMRxX4NM8C3H5+d5+H2PLcnVg_8hw8=TsBgOxLtLA@mail.gmail.com>
<CAJowKgJEJr=LhYhuQs4zOyskdAwjZT6aEFd-3=rsShLUf7yWJw@mail.gmail.com>
In-Reply-To: <CAJowKgJEJr=LhYhuQs4zOyskdAwjZT6aEFd-3=rsShLUf7yWJw@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Tue, 6 Jul 2021 23:18:58 -0700
Message-ID: <CAGpPWDa3uVxa+LR5JMmTjkgYTwFH9wWLChekg=8wCdtQ2=9eQg@mail.gmail.com>
To: Erik Aronesty <erik@q32.com>
Content-Type: multipart/alternative; boundary="00000000000084ebaf05c68284d2"
X-Mailman-Approved-At: Wed, 07 Jul 2021 08:20:40 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Proof of reserves - recording
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: Wed, 07 Jul 2021 06:19:19 -0000
--00000000000084ebaf05c68284d2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
I wanted to relay an interesting related link that Melvin PMed me:
https://petertodd.org/2016/commitments-and-single-use-seals
@Aronesty
Thanks, that system looks interesting, I'll have a closer look!
@Voskuil
I think we must disagree on at least one fundamental point. I'm finding
myself disagreeing with most of what you're saying.
> If perfect is not possible, it=E2=80=99s not possible. It reduces to trus=
t, which
is the status quo.
Let not perfect be the enemy of good. Trust cannot be eliminated.
Perfection cannot be achieved. However trust can be reduced further than it
exists today, and we can clearly make things better than they are now. Are
you really saying that if its not perfect, its worthless?
> All =E2=80=9Cusers=E2=80=9D need to simultaneously share their individual=
and temporary
audits with each other (ie publicly).
This is not the case. In both the mechanism I briefly described and Peter
Todd's mechanism from Melvin's link (top of this message), users need not
share any information with other users unless that information is "my
balance doesn't match the record". It doesn't even need to be in a timely
manner if these records are committed to the blockchain - one could
theoretically look back years and compare their personal records to the
records published by the custodian, and then tell the community about it if
they don't match. All that is required is that a critical mass of users
verify their balance (ideally using software that regularly checks
automatically).
> It is not hard to spot price inflation
I don't know why you think that's the case. Inflation is today vehemently
argued about. Are high real estate prices indications of inflation? What
about recovering stock prices? Is inflation temporary or will we expect it
to last more long term? If one company is inflating perceived supply, this
would almost certainly not show up as significant economy-wide inflation.
And if the majority of companies are doing it, how can you stop it if you
don't have any idea which ones are doing it? I do think spotting the
inflation in any kind of timely manner is indeed hard.
> Stopping or avoiding it is the actual issue. No =E2=80=9Cproof=E2=80=9D o=
f reserve can do
this.
I of course agree that proof of reserves cannot stop inflation/insolvency.
I disagree with the idea that this is the "actual" issue - which seems to
imply to me that its the only issue that matters. Even if we can't stop a
company from promising more coins than they have in reserves, we can limit
how long these events happen for - and how big these bubbles can get. Don't
you agree that would be very helpful, if it were it possible (which it
seems you think it isn't)?
> The federal reserve was clearly insolvent from its early days, as that
was its purpose.
Do you have a source as evidence that it was widely understood that the Fed
was insolvent from its early days? I really don't think it was seen as the
purpose by the vast majority of people in the US. People were lead to
believe every dollar was backed by a unique chunk of gold. Had it been
possible to do a kind of proof of reserves (or estimate of reserves) as
we're talking about, it would have been clear much earlier that the Fed was
doing a lot of shinanigans. I think that would have been very useful
information for the public back then. Perhaps they wouldn't have been able
to do anything about the Fed (or maybe they would have). But people can
certainly pull their money out of companies that can't show solvency.
> Nonsense, any business can fail, regardless of temporal cash reserves.
I agree that any business can fail. But a bank that pretends it can serve
cash on demand is not a normal business, and cash reserves absolutely
relate to their ability to survive as a bank. Its honestly confusing to me
how you could think otherwise. Also, calling my thoughts "nonsense" is
rude, please check yourself, Eric.
> it's hardly an improvement over holding your own keys.
No one is claiming that proof of reserves is "an improvement" over holding
your own keys. Clearly holding your own keys is ideal. However, not
everyone is comfortable with that. The fact of the matter is that many will
choose a custodial wallet, for better or worse. PoR attempts to make thing
on the "better" side than the "worse" side.
On Tue, Jul 6, 2021 at 9:39 AM Erik Aronesty <erik@q32.com> wrote:
> you should check out some of the earlier work done here:
>
> https://github.com/olalonde/proof-of-solvency#assets-proof
>
> to be honest, if any exchange supported that proof, it would be more
> than enough.
>
> there's really no way to prevent a smash-and-grab, but this does
> prevent a slow-leak
>
>
> On Mon, Jul 5, 2021 at 5:10 PM Billy Tetrud via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > I had the idea recently for proof of reserves done in a way that can be
> used to verify reserves are sufficient on an ongoing basis. I'm curious i=
f
> there are any current approaches out there to proof of reserves that are
> similar.
> >
> > The idea is to have users create actual private keys using a seed in
> pretty much the normal way. Users would generate a public key from this
> seed to represent their account, and would give the public key to the
> custodian to represent their account in a public record of account balanc=
es.
> >
> > When a user's account is credited, the custodian would update a map of
> addresses (created from the public key of each account) to balances - thi=
s
> map could be structured into a merkle tree in the usual "merkle approach"=
.
> The custodian would also store funds on one or more HD wallets (each with
> many addresses) and create a proof that they own each HD wallet. The proo=
f
> could be as simple as a single signature created with the xpub for the
> wallet, which would be sufficient for proving ownership over the whole
> list/tree of addresses.
> >
> > These two structures (the map and the HD wallet) would be combined and
> hashed, and the hash published in an on chain transaction (possibly along
> with a URI where the full data can be found), on something like a daily
> basis. Software for each user could continuously validate that their
> account has a balance that matches what it's supposed to have, and could
> also verify that owned addresses have funds that have at least as many
> coins as promised to accounts. If these things aren't verifiable (either
> because the balances total to more than the HD wallet contains, or becaus=
e
> of data unavailability), people can raise hell about it.
> >
> > To give user's additional proving ability, a receipt system could be
> added. Users could request a receipt for any balance update. Eg the user
> would create a message with a timestamp, their custodial "address", and t=
he
> new balance. The user would sign this receipt and send it to the custodia=
n,
> who would also sign it and send it back. This way, if something goes wron=
g,
> a user can use this signed receipt to show that the custodian did in fact
> promise a new updated balance at a particular time (which would cover the
> case that the custodian records the wrong value in their map). Conversely=
,
> the receipt would be useful to honest custodians as well, since they coul=
d
> show the user's signed receipt request in the case a user is trying to li=
e
> about what balance they should have. There is still the case that the
> custodian simply refuses to return a signed receipt, in which case the
> user's only recourse is to yell about it immediately and demand a receipt
> or a refund.
> >
> > Why record it on chain? Doing that gives a clear record of proof of
> reserves that can be verified later by anyone in the future. It prevents =
a
> custodian from being able to change history when it suits them (by creati=
ng
> a new records with false timestamps in the past). Many of these records
> could be aggregated together and recorded in the same transaction (with a
> single hash), so a single transaction per day could record the records of
> all participating custodians. If all custodians are using a standard
> system, one can cross verify that addresses claimed by one custodian aren=
't
> also claimed by another custodian.
> >
> > Even tho the user is responsible for their keys in order to properly
> verify, losing the keys isn't that big of a deal, since they could simply
> create a new seed and give a new public key to the custodian - who would
> have other identifying information they could use to validate that they o=
wn
> the account. So it places less responsibility on the user, while still
> introducing people, in a light-weight way, to self custody of keys.
> >
> > Having a record like this every day would reduce the possibility of
> shenanigans like taking a short term loan of a large amount of
> cryptocurrency. Sure, they could take a 10 minute loan once per day, but =
it
> would also be possible to trace on-chain transactions so you could tell i=
f
> such a thing was going on. I wonder if there would be some way to include
> the ability to prove balances held on the lightning network, but I suspec=
t
> that isn't generally possible.
> >
> > In any case, I'm curious what people think of this kind of thing, and i=
f
> systems with similar properties are already out there.
> >
> >
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--00000000000084ebaf05c68284d2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I wanted to relay an interesting related link that Melvin =
PMed me:=C2=A0
<a href=3D"https://petertodd.org/2016/commitments-and-single-use-seals" tar=
get=3D"_blank">https://petertodd.org/2016/commitments-and-single-use-seals<=
/a><div><br></div><div><div>@<span style=3D"color:rgb(32,33,36);font-family=
:Roboto,RobotoDraft,Helvetica,Arial,sans-serif;font-size:0.875rem;letter-sp=
acing:0.2px;white-space:nowrap">Aronesty</span></div><div><span style=3D"co=
lor:rgb(32,33,36);font-family:Roboto,RobotoDraft,Helvetica,Arial,sans-serif=
;font-size:0.875rem;letter-spacing:0.2px;white-space:nowrap">Thanks, that s=
ystem looks interesting, I'll have a closer look!<br></span></div></div=
><div><br></div><div>@Voskuil</div><div>I think we must disagree on at leas=
t one fundamental point. I'm finding myself disagreeing with most of wh=
at you're saying.</div><div><br></div><div>> If perfect is not possi=
ble, it=E2=80=99s not possible. It reduces to trust, which is the status qu=
o.</div><div><br></div><div>Let not perfect be the enemy of good. Trust can=
not be eliminated. Perfection cannot be achieved. However trust can be redu=
ced further than it exists today, and we can clearly make things better tha=
n they are now. Are you really saying that if its not perfect, its worthles=
s?</div><div><br></div><div>> All =E2=80=9Cusers=E2=80=9D need to simult=
aneously share their individual and temporary audits with each other (ie pu=
blicly).</div><div><br></div><div>This is not the case. In both the mechani=
sm I briefly described and Peter Todd's mechanism from Melvin's lin=
k (top of this message), users need not share any information with other us=
ers unless that information is "my balance doesn't match the recor=
d". It doesn't even need to be in a timely manner if these records=
are committed to the blockchain - one could theoretically look back years =
and compare their personal records to the records published by the custodia=
n, and then tell the community about it if they don't match. All that i=
s required is that a critical mass of users verify their balance (ideally u=
sing software that regularly checks automatically).=C2=A0</div><div><br></d=
iv><div>> It is not hard to spot price inflation</div><div><br></div><di=
v>I don't know why you think that's the case. Inflation is today ve=
hemently argued about. Are high real estate prices indications of inflation=
? What about recovering stock prices? Is inflation temporary or will we exp=
ect it to last more long term? If one company is inflating perceived supply=
, this would almost certainly not show up as significant economy-wide infla=
tion. And if the majority of companies are doing it, how can you stop it if=
you don't have any idea which ones are doing it? I do think spotting t=
he inflation in any kind of timely manner is indeed hard.=C2=A0</div><div><=
br></div><div>> Stopping or avoiding it is the actual issue. No =E2=80=
=9Cproof=E2=80=9D of reserve can do this.</div><div><br></div><div>I of cou=
rse agree that proof of reserves cannot stop inflation/insolvency. I disagr=
ee with the idea that this is the "actual" issue - which seems to=
imply to me that its the only issue that matters. Even if we can't sto=
p a company from promising more coins than they have in reserves, we can li=
mit how long these events happen for - and how big these bubbles can get. D=
on't you agree that would be very helpful, if it were it possible (whic=
h it seems you think it isn't)?=C2=A0</div><div><br></div><div>> The=
federal reserve was clearly insolvent from its early days, as that was its=
purpose.</div><div><br></div><div>Do you have a source as evidence that it=
was widely understood that the Fed was insolvent from its early days? I re=
ally don't think it was seen as the purpose by the vast majority of peo=
ple in the US. People were lead to believe every dollar was backed by a uni=
que chunk of gold. Had it been possible to do a kind of proof of reserves (=
or estimate of reserves) as we're talking about, it would have been cle=
ar much earlier that the Fed was doing a lot of shinanigans. I think that w=
ould have been very useful information for the public back then. Perhaps th=
ey wouldn't have been able to do anything about the Fed (or maybe they =
would have). But people can certainly pull their money out of companies tha=
t can't show solvency.=C2=A0</div><div><br></div><div>> Nonsense, an=
y business can fail, regardless of temporal cash reserves.</div><div><br></=
div><div>I agree that any business can fail. But a bank that pretends it ca=
n serve cash on demand is not a normal business, and cash reserves absolute=
ly relate to their ability to survive as a bank. Its honestly confusing to =
me how you could think otherwise. Also, calling my thoughts "nonsense&=
quot; is rude, please check yourself,=C2=A0Eric.=C2=A0</div><div><br></div>=
<div>> it's hardly an improvement over holding your own keys.</div><=
div><br></div><div>No one is claiming that proof of reserves is "an im=
provement" over holding your own keys. Clearly holding your own keys i=
s ideal. However, not everyone is comfortable with that. The fact of the ma=
tter is that many will choose a custodial wallet, for better or worse. PoR =
attempts to make thing on the "better" side than the "worse&=
quot; side.=C2=A0</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr=
" class=3D"gmail_attr">On Tue, Jul 6, 2021 at 9:39 AM Erik Aronesty <<a =
href=3D"mailto:erik@q32.com" target=3D"_blank">erik@q32.com</a>> wrote:<=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">you should check=
out some of the earlier work done here:<br>
<br>
<a href=3D"https://github.com/olalonde/proof-of-solvency#assets-proof" rel=
=3D"noreferrer" target=3D"_blank">https://github.com/olalonde/proof-of-solv=
ency#assets-proof</a><br>
<br>
to be honest, if any exchange supported that proof, it would be more<br>
than enough.<br>
<br>
there's really no way to prevent a smash-and-grab, but this does<br>
prevent a slow-leak<br>
<br>
<br>
On Mon, Jul 5, 2021 at 5:10 PM Billy Tetrud via bitcoin-dev<br>
<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>
><br>
> I had the idea recently for proof of reserves done in a way that can b=
e used to verify reserves are sufficient on an ongoing basis. I'm curio=
us if there are any current approaches out there to proof of reserves that =
are similar.<br>
><br>
> The idea is to have users create actual private keys using a seed in p=
retty much the normal way. Users would generate a public key from this seed=
to represent their account, and would give the public key to the custodian=
to represent their account in a public record of account balances.<br>
><br>
> When a user's account is credited, the custodian would update a ma=
p of addresses (created from the public key of each account) to balances - =
this map could be structured into a merkle tree in the usual "merkle a=
pproach". The custodian would also store funds on one or more HD walle=
ts (each with many addresses) and create a proof that they own each HD wall=
et. The proof could be as simple as a single signature created with the xpu=
b for the wallet, which would be sufficient for proving ownership over the =
whole list/tree of addresses.<br>
><br>
> These two structures (the map and the HD wallet) would be combined and=
hashed, and the hash published in an on chain transaction (possibly along =
with a URI where the full data can be found), on something like a daily bas=
is. Software for each user could continuously validate that their account h=
as a balance that matches what it's supposed to have, and could also ve=
rify that owned addresses have funds that have at least as many coins as pr=
omised to accounts. If these things aren't verifiable (either because t=
he balances total to more than the HD wallet contains, or because of data u=
navailability), people can raise hell about it.<br>
><br>
> To give user's additional proving ability, a receipt system could =
be added. Users could request a receipt for any balance update. Eg the user=
would create a message with a timestamp, their custodial "address&quo=
t;, and the new balance. The user would sign this receipt and send it to th=
e custodian, who would also sign it and send it back. This way, if somethin=
g goes wrong, a user can use this signed receipt to show that the custodian=
did in fact promise a new updated balance at a particular time (which woul=
d cover the case that the custodian records the wrong value in their map). =
Conversely, the receipt would be useful to honest custodians as well, since=
they could show the user's signed receipt request in the case a user i=
s trying to lie about what balance they should have. There is still the cas=
e that the custodian simply refuses to return a signed receipt, in which ca=
se the user's only recourse is to yell about it immediately and demand =
a receipt or a refund.<br>
><br>
> Why record it on chain? Doing that gives a clear record of proof of re=
serves that can be verified later by anyone in the future. It prevents a cu=
stodian from being able to change history when it suits them (by creating a=
new records with false timestamps in the past). Many of these records coul=
d be aggregated together and recorded in the same transaction (with a singl=
e hash), so a single transaction per day could record the records of all pa=
rticipating custodians. If all custodians are using a standard system, one =
can cross verify that addresses claimed by one custodian aren't also cl=
aimed by another custodian.<br>
><br>
> Even tho the user is responsible for their keys in order to properly v=
erify, losing the keys isn't that big of a deal, since they could simpl=
y create a new seed and give a new public key to the custodian - who would =
have other identifying information they could use to validate that they own=
the account. So it places less responsibility on the user, while still int=
roducing people, in a light-weight way, to self custody of keys.<br>
><br>
> Having a record like this every day would reduce the possibility of sh=
enanigans like taking a short term loan of a large amount of cryptocurrency=
. Sure, they could take a 10 minute loan once per day, but it would also be=
possible to trace on-chain transactions so you could tell if such a thing =
was going on. I wonder if there would be some way to include the ability to=
prove balances held on the lightning network, but I suspect that isn't=
generally possible.<br>
><br>
> In any case, I'm curious what people think of this kind of thing, =
and if systems with similar properties are already out there.<br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> bitcoin-dev mailing list<br>
> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a><br>
> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--00000000000084ebaf05c68284d2--
|