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
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
|
Return-Path: <ecurrencyhodler@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 39B1AC002A
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 25 May 2023 16:07:14 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 14A2283AAD
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 25 May 2023 16:07:14 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 14A2283AAD
Authentication-Results: smtp1.osuosl.org;
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
header.a=rsa-sha256 header.s=20221208 header.b=Oe6XWv+j
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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] autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id Z2ZCQRBGBlkA
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 25 May 2023 16:07:12 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 8575483A9E
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com
[IPv6:2a00:1450:4864:20::22a])
by smtp1.osuosl.org (Postfix) with ESMTPS id 8575483A9E
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 25 May 2023 16:07:11 +0000 (UTC)
Received: by mail-lj1-x22a.google.com with SMTP id
38308e7fff4ca-2afb2874e83so8486121fa.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 25 May 2023 09:07:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20221208; t=1685030829; x=1687622829;
h=to:subject:message-id:date:from:in-reply-to:references:mime-version
:from:to:cc:subject:date:message-id:reply-to;
bh=Y3dJpoSEf25O8mHSnAO3XgHybLUQCqMYFNyu0gw8AQA=;
b=Oe6XWv+j1ZOEUdHVR1ggUSbOP5v1bRueE/hEOKbAsbwnf6U94lYqUqtCwDpcMcBTkR
ndau2rClB62+IzIgErXNmbOOddbjFhiSCJ2IM4PSYQGap2TRID9llJA8DZ7Xw5mbLq0H
H8LayuwFy+mpPTbqBmTdZyBU0GczCzlLBwgDQWDuXONkPG9gW+wYGYbz40crHSBuMw3o
kYe9E3Ydo3A1zhI+AtWxC3R9MdYOtUAqPSPZtTSvqGZHZOj6gShCeJ6+q3a1xnnGpsXn
MAhhtNczaLv8n1BKaLBuImoRuQ+kOkwnF601E7OLmTzqg62SSt1btLDtr8tN3NSR4eTn
MWag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20221208; t=1685030829; x=1687622829;
h=to:subject:message-id:date:from:in-reply-to:references:mime-version
:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
bh=Y3dJpoSEf25O8mHSnAO3XgHybLUQCqMYFNyu0gw8AQA=;
b=eIergTkacQpxONi0FQSgPldrB2BYtM568Qg6bOxbW1gpQwbySI+GReuoYEtZeG9AHz
voJGniEN+iN+NIk9qhE3lej6LpSrxYDqmrorjo55Lsn60wXzS/xNQYymR/1O2SXlpsRz
Hb3VXZPHWVy9Pc0x7shjhs9TRUbHJTHL6k2EBRSlRKgEaX9QgETdm0o+WmdZpjXeg1rk
aO2sfBUJkDVdFcZlCtup11yOO9mZ09/3tdOj7K6cDWzEA93bJ/aa9sjc8PYKYcGwAoh2
0OeAD2ZK2dW5K2hHLSWzF0tPBW3mTVTE4zBDOPH7iMl9eYpYZ7TtXCrBgfN21uLw9YbL
3gvg==
X-Gm-Message-State: AC+VfDyoE1UfuPtmxOj0cH24qwn8cqwcJXoG6xHI+z7WImuYyhQ4vgaf
/R8oxF8QMuDR3Q3F+d1Tist3o8e+KmjOoQlDU3E9bVOAUFQ=
X-Google-Smtp-Source: ACHHUZ467JO2RsWr6qpqo8lqaK84HGkR1/PFx9cC46FXEPOhw7zb/a+n5x+M+OGMH5AANHurJvg5PEWowC/DtoOZjBo=
X-Received: by 2002:a05:651c:144:b0:2ad:275a:44b6 with SMTP id
c4-20020a05651c014400b002ad275a44b6mr1075695ljd.52.1685030828334; Thu, 25 May
2023 09:07:08 -0700 (PDT)
MIME-Version: 1.0
References: <mailman.17.1685016003.20381.bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <mailman.17.1685016003.20381.bitcoin-dev@lists.linuxfoundation.org>
From: ecurrencyhodler <ecurrencyhodler@gmail.com>
Date: Thu, 25 May 2023 09:06:31 -0700
Message-ID: <CAKFmrWM7DXEnsSg0FWbwFR8GUhky+xDE+SsOFeF=O7LsqnT0xQ@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary="000000000000f5646c05fc86cf30"
X-Mailman-Approved-At: Thu, 25 May 2023 17:06:10 +0000
Subject: Re: [bitcoin-dev] bitcoin-dev Digest, Vol 96, Issue 58
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: Thu, 25 May 2023 16:07:14 -0000
--000000000000f5646c05fc86cf30
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 24 May 2023
From: ecurrencyhodler<ecurrencyhodler@gmail.com>
To: Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving
Second Layer Solution (ecurrencyhodler)
Thanks David for your write up. Clear, concise, and super understandable as
always.
It sounds like to me that ARK is using PSBT's + covenants to secure
unconfirmed txns.
I see how this significantly reduces onchain footprint. But wouldn't this
also have a massive impact at scale to the mempool filling it with
unconfirmed txns? Couple concerns I have are:
1. It would create an ever growing fee environment within the 10-minute
block. Therefore it would be possible for the first settlement txn in th=
e
first 5 seconds to get pushed out of the mempool by later settlement txn=
s
closer to the 10 minute mark.
2. Mempools would have to drastically increase their size to capture all
the 5-second settlement unconfirmed txns and default bitcoin core nodes
would get flooded.
Thanks again burak for your ARK proposal. There seems to be a good amount
of excitement about what this could unlock in the future which is quite
refreshing to see.
On Thu, May 25, 2023 at 5:01=E2=80=AFAM <
bitcoin-dev-request@lists.linuxfoundation.org> wrote:
> Send bitcoin-dev mailing list submissions to
> bitcoin-dev@lists.linuxfoundation.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> or, via email, send a message with subject or body 'help' to
> bitcoin-dev-request@lists.linuxfoundation.org
>
> You can reach the person managing the list at
> bitcoin-dev-owner@lists.linuxfoundation.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bitcoin-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: Ark: An Alternative Privacy-preserving Second Layer
> Solution (adiabat)
> 2. Re: Ark: An Alternative Privacy-preserving Second Layer
> Solution (David A. Harding)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Wed, 24 May 2023 16:20:35 -0400
> From: adiabat <rx@awsomnet.org>
> To: Bitcoin Protocol Discussion
> <bitcoin-dev@lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving
> Second Layer Solution
> Message-ID:
> <CAKEeUhg1qeZOv-Lk8SSTxdkgfSee_E6_4fwNV=3D
> hfwsxLgwWkUw@mail.gmail.com>
> Content-Type: text/plain; charset=3D"UTF-8"
>
> Hi - thanks for the Ark write up; I have a bunch of questions but here's =
2:
>
> ---
> Q1:
> "Pool transactions are created by ark service providers perpetually
> every 5 seconds"
>
> What exactly happens every 5 seconds? From the 15.44.21-p-1080.png
> diagram [1], a pool transaction is a bitcoin transaction, with all the
> inputs coming from the ASP. My understanding is that every 5 seconds,
> we progress from PoolTx(N) to PoolTx(N+1). Does the ASP sign a new
> transaction which spends the same ASP funding inputs as the previous
> pool transaction, which is a double spend or fee bump? Or does it
> spend the outputs from the previous PoolTx?
>
> In other words, does PoolTx(2) replace PoolTx(1) RBF-style, spending
> the same inputs (call this method A), or does PoolTx(2) spend an
> output Of Pooltx(1) such that PoolTx(1) must be confirmed in order for
> PoolTx(2) to become valid (method B)? Or are they completely separate
> transactions with unconflicting inputs (method C)?
>
> When the ASP creates a pool transaction, what do they do with it? Do
> they broadcast it to the gossip network? Or share it with other pool
> participants?
>
> With method A, if the ASP shares pool transactions with other people,
> there Doesn't seem to be any way to ensure which PoolTx gets
> confirmed, invalidating all the other ones. They're all valid so
> whichever gets into a block first wins.
>
> With method B, there seems to be a large on-chain load, with ~120
> chained transactions trying to get in every block. This wouldn't play
> nicely with mempool standardness and doesn't seem like you could ever
> "catch up".
>
> With method C, ASPs would need a pretty large number of inputs but
> could recycle them as blocks confirm. It would cost a lot but maybe
> could work.
>
> ---
> Q2:
>
> The other part I'm missing is: what prevents the ASP from taking all
> the money? Before even getting to vTXOs and connector outputs, from
> the diagram there are only ASP inputs funding the pool transaction.
> If the pool transaction is confirmed, the vTXOs are locked in place,
> since the vTXO output cannot be changed and commits to all
> "constrained outs" via OP_CTV. If the pool transaction is
> unconfirmed, the ASP can create & sign a transaction spending all ASP
> funding inputs sending the money back to the ASP, or anywhere else.
> In this case, users don't have any assurance that their vTXO can ever
> turn into a real UTXO; the ASP can "rug-pull" at any time, taking all
> the money in the pool. Adding other inputs not controlled by the ASP
> to the transaction wouldn't seem to fix the problem, because then any
> user removing their inputs would cancel the whole transaction.
>
> More detail about how these transactions work would be appreciated, thank=
s!
>
> -Tadge
>
> [1]
> https://uploads-ssl.webflow.com/645ae2e299ba34372614141d/6467d1f1bf91e0bf=
2c2eddef_Screen%20Shot%202023-05-19%20at%2015.44.21-p-1080.png
>
>
> ------------------------------
>
> Message: 2
> Date: Wed, 24 May 2023 13:02:40 -1000
> From: "David A. Harding" <dave@dtrt.org>
> To: Burak Keceli <burak@buraks.blog>, Bitcoin Protocol Discussion
> <bitcoin-dev@lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving
> Second Layer Solution
> Message-ID: <3c6c3b8b562bb56bbb855dc2b2b71f78@dtrt.org>
> Content-Type: text/plain; charset=3DUS-ASCII; format=3Dflowed
>
> Hi Burak,
>
> Thanks for this really interesting protocol! I tend to analyze
> complicated ideas like this by writing about them in my own words, so
> I've pasted my summary of your idea to the end of this email in case
> it's useful, either to other people or to you in helping understand my
> one concern.
>
> My concern is the same one I think Olaoluwa Osuntokun mentioned on
> Twitter[1] and (less clear to me) might be related to ZmnSCPxj's
> concern[2]:
>
> It seems to me that receiving a payment on the protocol, including
> conditional payments using HTLC, PTLC, or Anchor-TLC, requires waiting
> for the transaction containing that payment to confirm to a sufficient
> depth (e.g., I'd wait 6 blocks for small payments and longer for huge
> payments). Am I missing something?
>
> My summary of how I think that part of the protocol works is in the
> sections labeled "Make an unconditioned payment" and "Make a conditional
> payment" below. In short, it's clear to me how the service provider and
> the customer can make instant atomic swaps with each other---they can
> either spend instantly cooperatively, or they have to wait for a
> timeout. But how can a receiver of funds be assured that they will
> actually get those funds unless there's already a timelock and
> cooperative spend path placed on those funds?
>
> -Dave
>
> Rough initial summary of Ark protocol:
>
> Alice runs an Ark service provider. Every 5 seconds, she broadcasts a
> new unconfirmed onchain transaction that pays three outputs (the
> three Cs):
>
> 1. *Change Output:* money not used for the other two Cs that gets sent
> back to the the transaction creator.
>
> 2. *Connector Output:* an output that will be used in a future
> transaction created by Alice as protection against double spends.
>
> 3. *Commitment Output:* a CTV-style commitment to a set of outputs that
> can be published later in a descendant transaction (alternatively,
> the commitment output may be spent unilaterally by Alice after 4
> weeks).
>
> Bob wants to deposit 1 BTC with Alice. He sends her an unsigned PSBT
> with an input of his and a change output. She updates the PSBT with a
> commitment output that refunds Bob the 1 BTC and a connector output with
> some minimum value. They both sign the PBST and it is broadcast. We'll
> ignore fees in our examples, both onchain transaction fees and fees paid
> to Alice.
>
> From here, there are several things that Bob can do:
>
> - *Unilaterally withdraw:* Bob can spend from the commitment output to
> put his refund onchain. The refund can only be spent after a 24-hour
> time delay, allowing Bob to optionally come to an agreement with Alice
> about how to spend the funds before Bob can spend them unilaterally
> (as we'll see in a moment). For example, the script might be[3]:
>
> pk(B) && (older(1 day) || pk(A))
>
> - *Collaboratively withdraw:* as seen above, Bob has the ability to come
> to a trustless agreement with Alice about how to spend his funds.
> They can use that ability to allow Bob to trade his (unpublished) UTXO
> for a UTXO that Alice funds and broadcasts. For example:
>
> - Alice creates an unsigned PSBT that uses as one of its inputs the
> connector from Bob's deposit transaction. This will ensure that
> any attempt by Bob to double-spend his deposit transaction will
> invalidate this withdrawal transaction, preventing Bob from being
> able to steal any of Alice's funds.
>
> Also included in Alice's unsigned PSBT is another connector
> output plus the output that pays Bob his 1 BTC.
>
> - Bob receives Alice's unsigned PSBT and creates a separate PSBT
> that includes his unpublished UTXO as an input, giving its value
> to Alice in an output. The PSBT also includes as an input the
> connector output from Alice's PSBT. This will ensure that any
> attempt by Alice to double spend her transaction paying him will
> invalidate his transaction paying her.
>
> - Bob signs his PSBT and gives it to Alice. After verifying it,
> Alice signs her PSBT and broadcasts it.
>
> - *Collaboratively trade commitments:* as mentioned, the commitment
> output that pays Bob may be claimed instead by Alice after 4 weeks, so
> Bob will need to either withdraw or obtain a new commitment within
> that
> time. To trade his existing commitment for a new commitment looks
> similar to the collaborative withdrawal procedure but without the
> creation of an immediately-spendable onchain output:
>
> - Alice creates an unsigned PSBT that uses as one of its inputs the
> connector from Bob's deposit transaction, again preventing double
> spending by Bob. Alice also includes a new connector and a new
> commitment that again allows Bob to later claim 1 BTC.
>
> - Bob receives Alice's PSBT and creates a PSBT transferring his
> existing commitment to her, with the new connector again being
> included as an input to ensure atomicity.
>
> - Bob signs; Alice signs and broadcasts.
>
> - *Make an unconditioned payment:* using the mechanisms described above,
> it's possible to make either an onchain payment or an offchain
> payment---just have Carol receive the new output or commitment rather
> than Bob. That payment would have no conditions (except its
> atomicity).
>
> - *Make a conditional payment:* imagine that Carol knows a secret (e.g.
> a preimage) that Bob is willing to pay for.
>
> - Alice creates an unsigned PSBT depending on the connector from
> Bob's deposit transaction and creating a new connector. The PSBT
> includes an output paying Carol (either onchain or via a
> commitment) with an HTLC, allowing Carol to claim the funds if
> she
> reveals the secret or allowing Bob to claim the funds after a
> timeout.
>
> - Bob receives Alice's PSBT and creates a PSBT transferring his
> existing commitment to her with the HTLC condition attached and,
> again, with connectors being used to ensure atomicity.
>
> - Bob signs; Alice signs and broadcasts.
>
> - Carol can settle her HTLC by either revealing the secret onchain
> or by trading her commitment containing the HTLC clause for a
> commitment from Alice that doesn't contain the clause (which
> Alice will only accept by learning the secret, since Alice has
> to settle with Bob). Alice can then either settle onchain or
> trade commitments with Bob after giving him the secret.
>
> - *Do nothing for 4 weeks:* if Bob does nothing for four weeks, Alice
> can claim the funds from the commitment output (i.e., takes his
> money).
>
> If Bob did actually do something, and if every other user who also
> had an unpublished output in the commitment transaction did
> something, then they all exchanged their portion of the funds in
> this output to Alice, so Alice can now claim all of those funds
> onchain in a highly efficient manner.
>
> Regarding the connector outputs, although all of the examples above show
> Alice directly spending from the connector output in Bob's deposit
> transaction, atomicity is also ensured if Alice spends from any output
> descended from Bob's connector output. Connector outputs from different
> deposits can be used as inputs into the same transaction, merging their
> histories. This allows all operations made by Alice to be fully atomic,
> ensuring that she doesn't lose any money during a reorg of any length.
>
> Users are not so well protected during reorgs, e.g. if Bob double-spends
> a transaction whose funds were later used in a payment to Carol, then
> Carol loses the money. For this reason, Alice will probably want to
> prove to users that no funds they receive in a payment derive from any
> deposit less than safe_confirmation_depth blocks.
>
> [1] https://twitter.com/roasbeef/status/1661266771784126464
>
> [2]
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021710.h=
tml
>
> [3]
>
> https://min.sc/#c=3Dpk%28B%29%20%26%26%20%28older%281%20day%29%20%7C%7C%2=
0pk%28A%29%29
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> ------------------------------
>
> End of bitcoin-dev Digest, Vol 96, Issue 58
> *******************************************
>
--000000000000f5646c05fc86cf30
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Date: Wed, 24 May 2023=C2=A0<br>From: ecurrencyhodler=
<<a href=3D"mailto:ecurrencyhodler@gmail.com">ecurrencyhodler@gmail.com<=
/a>><br>To: Bitcoin Protocol Discussion<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 &=
lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lis=
ts.linuxfoundation.org</a>><br>Subject: Re: [bitcoin-dev] Ark: An Altern=
ative Privacy-preserving<br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Second =C2=A0Layer =
Solution (ecurrencyhodler)<br></div><div><br></div><div>Thanks David for yo=
ur write up. Clear, concise, and super understandable as always.</div><div>=
<br></div><div>It sounds like to me that ARK is using PSBT's=C2=A0+ cov=
enants to secure unconfirmed txns.=C2=A0</div><div><br></div><div>I see how=
this significantly reduces onchain footprint. But wouldn't this also h=
ave a massive impact at scale to the mempool filling it with unconfirmed tx=
ns? Couple concerns I have are:</div><div><ol><li>It would create an ever g=
rowing fee environment within the 10-minute block. Therefore it would be po=
ssible for the first settlement txn in the first 5 seconds to get pushed ou=
t of the mempool by later settlement txns closer to the 10 minute mark.=C2=
=A0</li><li>Mempools would have to drastically increase their size to captu=
re all the 5-second settlement unconfirmed txns and default bitcoin core no=
des would get flooded.</li></ol><div>Thanks again burak for your ARK propos=
al. There seems to be a good amount of excitement about what this could unl=
ock in the future which is quite refreshing to see.</div></div></div><br><d=
iv class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, May =
25, 2023 at 5:01=E2=80=AFAM <<a href=3D"mailto:bitcoin-dev-request@lists=
.linuxfoundation.org">bitcoin-dev-request@lists.linuxfoundation.org</a>>=
wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Send bit=
coin-dev mailing list submissions to<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:bitcoin-dev@lists.linuxfounda=
tion.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"https://lists.linuxfoundation.org/ma=
ilman/listinfo/bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://li=
sts.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
or, via email, send a message with subject or body 'help' to<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:bitcoin-dev-request@lists.lin=
uxfoundation.org" target=3D"_blank">bitcoin-dev-request@lists.linuxfoundati=
on.org</a><br>
<br>
You can reach the person managing the list at<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:bitcoin-dev-owner@lists.linux=
foundation.org" target=3D"_blank">bitcoin-dev-owner@lists.linuxfoundation.o=
rg</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of bitcoin-dev digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
=C2=A0 =C2=A01. Re: Ark: An Alternative Privacy-preserving Second Layer<br>
=C2=A0 =C2=A0 =C2=A0 Solution (adiabat)<br>
=C2=A0 =C2=A02. Re: Ark: An Alternative Privacy-preserving Second Layer<br>
=C2=A0 =C2=A0 =C2=A0 Solution (David A. Harding)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Wed, 24 May 2023 16:20:35 -0400<br>
From: adiabat <<a href=3D"mailto:rx@awsomnet.org" target=3D"_blank">rx@a=
wsomnet.org</a>><br>
To: Bitcoin Protocol Discussion<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <<a href=3D"mailto:bitcoin-dev@lists.linuxfo=
undation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&g=
t;<br>
Subject: Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Second=C2=A0 Layer Solution<br>
Message-ID:<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <CAKEeUhg1qeZOv-Lk8SSTxdkgfSee_E6_4fwNV=3D<a=
href=3D"mailto:hfwsxLgwWkUw@mail.gmail.com" target=3D"_blank">hfwsxLgwWkUw=
@mail.gmail.com</a>><br>
Content-Type: text/plain; charset=3D"UTF-8"<br>
<br>
Hi - thanks for the Ark write up; I have a bunch of questions but here'=
s 2:<br>
<br>
---<br>
Q1:<br>
"Pool transactions are created by ark service providers perpetually<br=
>
every 5 seconds"<br>
<br>
What exactly happens every 5 seconds?=C2=A0 From the 15.44.21-p-1080.png<br=
>
diagram [1], a pool transaction is a bitcoin transaction, with all the<br>
inputs coming from the ASP.=C2=A0 My understanding is that every 5 seconds,=
<br>
we progress from PoolTx(N) to PoolTx(N+1).=C2=A0 Does the ASP sign a new<br=
>
transaction which spends the same ASP funding inputs as the previous<br>
pool transaction, which is a double spend or fee bump?=C2=A0 Or does it<br>
spend the outputs from the previous PoolTx?<br>
<br>
In other words, does PoolTx(2) replace PoolTx(1) RBF-style, spending<br>
the same inputs (call this method A), or does PoolTx(2) spend an<br>
output Of Pooltx(1) such that PoolTx(1) must be confirmed in order for<br>
PoolTx(2) to become valid (method B)?=C2=A0 Or are they completely separate=
<br>
transactions with unconflicting inputs (method C)?<br>
<br>
When the ASP creates a pool transaction, what do they do with it?=C2=A0 Do<=
br>
they broadcast it to the gossip network?=C2=A0 Or share it with other pool<=
br>
participants?<br>
<br>
With method A, if the ASP shares pool transactions with other people,<br>
there Doesn't seem to be any way to ensure which PoolTx gets<br>
confirmed, invalidating all the other ones.=C2=A0 They're all valid so<=
br>
whichever gets into a block first wins.<br>
<br>
With method B, there seems to be a large on-chain load, with ~120<br>
chained transactions trying to get in every block. This wouldn't play<b=
r>
nicely with mempool standardness and doesn't seem like you could ever<b=
r>
"catch up".<br>
<br>
With method C, ASPs would need a pretty large number of inputs but<br>
could recycle them as blocks confirm.=C2=A0 It would cost a lot but maybe<b=
r>
could work.<br>
<br>
---<br>
Q2:<br>
<br>
The other part I'm missing is: what prevents the ASP from taking all<br=
>
the money?=C2=A0 Before even getting to vTXOs and connector outputs, from<b=
r>
the diagram there are only ASP inputs funding the pool transaction.<br>
If the pool transaction is confirmed, the vTXOs are locked in place,<br>
since the vTXO output cannot be changed and commits to all<br>
"constrained outs" via OP_CTV.=C2=A0 If the pool transaction is<b=
r>
unconfirmed, the ASP can create & sign a transaction spending all ASP<b=
r>
funding inputs sending the money back to the ASP, or anywhere else.<br>
In this case, users don't have any assurance that their vTXO can ever<b=
r>
turn into a real UTXO; the ASP can "rug-pull" at any time, taking=
all<br>
the money in the pool.=C2=A0 Adding other inputs not controlled by the ASP<=
br>
to the transaction wouldn't seem to fix the problem, because then any<b=
r>
user removing their inputs would cancel the whole transaction.<br>
<br>
More detail about how these transactions work would be appreciated, thanks!=
<br>
<br>
-Tadge<br>
<br>
[1] <a href=3D"https://uploads-ssl.webflow.com/645ae2e299ba34372614141d/646=
7d1f1bf91e0bf2c2eddef_Screen%20Shot%202023-05-19%20at%2015.44.21-p-1080.png=
" rel=3D"noreferrer" target=3D"_blank">https://uploads-ssl.webflow.com/645a=
e2e299ba34372614141d/6467d1f1bf91e0bf2c2eddef_Screen%20Shot%202023-05-19%20=
at%2015.44.21-p-1080.png</a><br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Wed, 24 May 2023 13:02:40 -1000<br>
From: "David A. Harding" <<a href=3D"mailto:dave@dtrt.org" tar=
get=3D"_blank">dave@dtrt.org</a>><br>
To: Burak Keceli <burak@buraks.blog>, Bitcoin Protocol Discussion<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <<a href=3D"mailto:bitcoin-dev@lists.linuxfo=
undation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&g=
t;<br>
Subject: Re: [bitcoin-dev] Ark: An Alternative Privacy-preserving<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Second Layer Solution<br>
Message-ID: <<a href=3D"mailto:3c6c3b8b562bb56bbb855dc2b2b71f78@dtrt.org=
" target=3D"_blank">3c6c3b8b562bb56bbb855dc2b2b71f78@dtrt.org</a>><br>
Content-Type: text/plain; charset=3DUS-ASCII; format=3Dflowed<br>
<br>
Hi Burak,<br>
<br>
Thanks for this really interesting protocol!=C2=A0 I tend to analyze<br>
complicated ideas like this by writing about them in my own words, so<br>
I've pasted my summary of your idea to the end of this email in case<br=
>
it's useful, either to other people or to you in helping understand my<=
br>
one concern.<br>
<br>
My concern is the same one I think Olaoluwa Osuntokun mentioned on<br>
Twitter[1] and (less clear to me) might be related to ZmnSCPxj's<br>
concern[2]:<br>
<br>
It seems to me that receiving a payment on the protocol, including<br>
conditional payments using HTLC, PTLC, or Anchor-TLC, requires waiting<br>
for the transaction containing that payment to confirm to a sufficient<br>
depth (e.g., I'd wait 6 blocks for small payments and longer for huge<b=
r>
payments).=C2=A0 Am I missing something?<br>
<br>
My summary of how I think that part of the protocol works is in the<br>
sections labeled "Make an unconditioned payment" and "Make a=
conditional<br>
payment" below.=C2=A0 In short, it's clear to me how the service p=
rovider and<br>
the customer can make instant atomic swaps with each other---they can<br>
either spend instantly cooperatively, or they have to wait for a<br>
timeout.=C2=A0 But how can a receiver of funds be assured that they will<br=
>
actually get those funds unless there's already a timelock and<br>
cooperative spend path placed on those funds?<br>
<br>
-Dave<br>
<br>
Rough initial summary of Ark protocol:<br>
<br>
Alice runs an Ark service provider.=C2=A0 Every 5 seconds, she broadcasts a=
<br>
new unconfirmed onchain transaction that pays three outputs (the<br>
three Cs):<br>
<br>
1. *Change Output:* money not used for the other two Cs that gets sent<br>
=C2=A0 =C2=A0 back to the the transaction creator.<br>
<br>
2. *Connector Output:* an output that will be used in a future<br>
=C2=A0 =C2=A0 transaction created by Alice as protection against double spe=
nds.<br>
<br>
3. *Commitment Output:* a CTV-style commitment to a set of outputs that<br>
=C2=A0 =C2=A0 can be published later in a descendant transaction (alternati=
vely,<br>
=C2=A0 =C2=A0 the commitment output may be spent unilaterally by Alice afte=
r 4<br>
=C2=A0 =C2=A0 weeks).<br>
<br>
Bob wants to deposit 1 BTC with Alice.=C2=A0 He sends her an unsigned PSBT<=
br>
with an input of his and a change output.=C2=A0 She updates the PSBT with a=
<br>
commitment output that refunds Bob the 1 BTC and a connector output with<br=
>
some minimum value.=C2=A0 They both sign the PBST and it is broadcast.=C2=
=A0 We'll<br>
ignore fees in our examples, both onchain transaction fees and fees paid<br=
>
to Alice.<br>
<br>
=C2=A0From here, there are several things that Bob can do:<br>
<br>
- *Unilaterally withdraw:* Bob can spend from the commitment output to<br>
=C2=A0 =C2=A0put his refund onchain.=C2=A0 The refund can only be spent aft=
er a 24-hour<br>
=C2=A0 =C2=A0time delay, allowing Bob to optionally come to an agreement wi=
th Alice<br>
=C2=A0 =C2=A0about how to spend the funds before Bob can spend them unilate=
rally<br>
=C2=A0 =C2=A0(as we'll see in a moment).=C2=A0 For example, the script =
might be[3]:<br>
<br>
=C2=A0 =C2=A0 =C2=A0pk(B) && (older(1 day) || pk(A))<br>
<br>
- *Collaboratively withdraw:* as seen above, Bob has the ability to come<br=
>
=C2=A0 =C2=A0to a trustless agreement with Alice about how to spend his fun=
ds.<br>
=C2=A0 =C2=A0They can use that ability to allow Bob to trade his (unpublish=
ed) UTXO<br>
=C2=A0 =C2=A0for a UTXO that Alice funds and broadcasts.=C2=A0 For example:=
<br>
<br>
=C2=A0 =C2=A0 =C2=A0- Alice creates an unsigned PSBT that uses as one of it=
s inputs the<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0connector from Bob's deposit transaction.=C2=
=A0 This will ensure that<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0any attempt by Bob to double-spend his deposit t=
ransaction will<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0invalidate this withdrawal transaction, preventi=
ng Bob from being<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0able to steal any of Alice's funds.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Also included in Alice's unsigned PSB=
T is another connector<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0output plus the output that pays Bob his =
1 BTC.<br>
<br>
=C2=A0 =C2=A0 =C2=A0- Bob receives Alice's unsigned PSBT and creates a =
separate PSBT<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0that includes his unpublished UTXO as an input, =
giving its value<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0to Alice in an output.=C2=A0 The PSBT also inclu=
des as an input the<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0connector output from Alice's PSBT.=C2=A0 Th=
is will ensure that any<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0attempt by Alice to double spend her transaction=
paying him will<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0invalidate his transaction paying her.<br>
<br>
=C2=A0 =C2=A0 =C2=A0- Bob signs his PSBT and gives it to Alice.=C2=A0 After=
verifying it,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0Alice signs her PSBT and broadcasts it.<br>
<br>
- *Collaboratively trade commitments:* as mentioned, the commitment<br>
=C2=A0 =C2=A0output that pays Bob may be claimed instead by Alice after 4 w=
eeks, so<br>
=C2=A0 =C2=A0Bob will need to either withdraw or obtain a new commitment wi=
thin <br>
that<br>
=C2=A0 =C2=A0time.=C2=A0 To trade his existing commitment for a new commitm=
ent looks<br>
=C2=A0 =C2=A0similar to the collaborative withdrawal procedure but without =
the<br>
=C2=A0 =C2=A0creation of an immediately-spendable onchain output:<br>
<br>
=C2=A0 =C2=A0 =C2=A0- Alice creates an unsigned PSBT that uses as one of it=
s inputs the<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0connector from Bob's deposit transaction, ag=
ain preventing double<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0spending by Bob.=C2=A0 Alice also includes a new=
connector and a new<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0commitment that again allows Bob to later claim =
1 BTC.<br>
<br>
=C2=A0 =C2=A0 =C2=A0- Bob receives Alice's PSBT and creates a PSBT tran=
sferring his<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0existing commitment to her, with the new connect=
or again being<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0included as an input to ensure atomicity.<br>
<br>
=C2=A0 =C2=A0 =C2=A0- Bob signs; Alice signs and broadcasts.<br>
<br>
- *Make an unconditioned payment:* using the mechanisms described above,<br=
>
=C2=A0 =C2=A0it's possible to make either an onchain payment or an offc=
hain<br>
=C2=A0 =C2=A0payment---just have Carol receive the new output or commitment=
rather<br>
=C2=A0 =C2=A0than Bob.=C2=A0 That payment would have no conditions (except =
its<br>
=C2=A0 =C2=A0atomicity).<br>
<br>
- *Make a conditional payment:* imagine that Carol knows a secret (e.g.<br>
=C2=A0 =C2=A0a preimage) that Bob is willing to pay for.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 - Alice creates an unsigned PSBT depending on the conn=
ector from<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Bob's deposit transaction and creating a ne=
w connector.=C2=A0 The PSBT<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 includes an output paying Carol (either onchain=
or via a<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 commitment) with an HTLC, allowing Carol to cla=
im the funds if <br>
she<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 reveals the secret or allowing Bob to claim the=
funds after a<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 timeout.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 - Bob receives Alice's PSBT and creates a PSBT tra=
nsferring his<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 existing commitment to her with the HTLC condit=
ion attached and,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 again, with connectors being used to ensure ato=
micity.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 - Bob signs; Alice signs and broadcasts.<br>
<br>
=C2=A0 =C2=A0 =C2=A0 - Carol can settle her HTLC by either revealing the se=
cret onchain<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 or by trading her commitment containing the HTL=
C clause for a<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 commitment from Alice that doesn't contain =
the clause (which<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Alice will only accept by learning the secret, =
since Alice has<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 to settle with Bob).=C2=A0 Alice can then eithe=
r settle onchain or<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 trade commitments with Bob after giving him the=
secret.<br>
<br>
- *Do nothing for 4 weeks:* if Bob does nothing for four weeks, Alice<br>
=C2=A0 =C2=A0can claim the funds from the commitment output (i.e., takes hi=
s<br>
=C2=A0 =C2=A0money).<br>
<br>
=C2=A0 =C2=A0 =C2=A0If Bob did actually do something, and if every other us=
er who also<br>
=C2=A0 =C2=A0 =C2=A0had an unpublished output in the commitment transaction=
did<br>
=C2=A0 =C2=A0 =C2=A0something, then they all exchanged their portion of the=
funds in<br>
=C2=A0 =C2=A0 =C2=A0this output to Alice, so Alice can now claim all of tho=
se funds<br>
=C2=A0 =C2=A0 =C2=A0onchain in a highly efficient manner.<br>
<br>
Regarding the connector outputs, although all of the examples above show<br=
>
Alice directly spending from the connector output in Bob's deposit<br>
transaction, atomicity is also ensured if Alice spends from any output<br>
descended from Bob's connector output.=C2=A0 Connector outputs from dif=
ferent<br>
deposits can be used as inputs into the same transaction, merging their<br>
histories.=C2=A0 This allows all operations made by Alice to be fully atomi=
c,<br>
ensuring that she doesn't lose any money during a reorg of any length.<=
br>
<br>
Users are not so well protected during reorgs, e.g. if Bob double-spends<br=
>
a transaction whose funds were later used in a payment to Carol, then<br>
Carol loses the money.=C2=A0 For this reason, Alice will probably want to<b=
r>
prove to users that no funds they receive in a payment derive from any<br>
deposit less than safe_confirmation_depth blocks.<br>
<br>
[1] <a href=3D"https://twitter.com/roasbeef/status/1661266771784126464" rel=
=3D"noreferrer" target=3D"_blank">https://twitter.com/roasbeef/status/16612=
66771784126464</a><br>
<br>
[2] <br>
<a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May=
/021710.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfound=
ation.org/pipermail/bitcoin-dev/2023-May/021710.html</a><br>
<br>
[3] <br>
<a href=3D"https://min.sc/#c=3Dpk%28B%29%20%26%26%20%28older%281%20day%29%2=
0%7C%7C%20pk%28A%29%29" rel=3D"noreferrer" target=3D"_blank">https://min.sc=
/#c=3Dpk%28B%29%20%26%26%20%28older%281%20day%29%20%7C%7C%20pk%28A%29%29</a=
><br>
<br>
<br>
------------------------------<br>
<br>
Subject: Digest Footer<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
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/mail=
man/listinfo/bitcoin-dev</a><br>
<br>
<br>
------------------------------<br>
<br>
End of bitcoin-dev Digest, Vol 96, Issue 58<br>
*******************************************<br>
</blockquote></div>
--000000000000f5646c05fc86cf30--
|