summaryrefslogtreecommitdiff
path: root/7d/9eff95b900a5b1949f4a5a127815298e72db16
blob: ea68c2af4cad9d5c21bc1ff6c41ec5f4d53561b3 (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
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
Return-Path: <zachgrw@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 8EC1EC002F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 30 Mar 2023 10:39:55 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 56C5E60B06
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 30 Mar 2023 10:39:55 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 56C5E60B06
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=XMFOjg8z
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 smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 7kT4YhoiukQe
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 30 Mar 2023 10:39:53 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 44A3A60AF0
Received: from mail-yb1-xb34.google.com (mail-yb1-xb34.google.com
 [IPv6:2607:f8b0:4864:20::b34])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 44A3A60AF0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 30 Mar 2023 10:39:53 +0000 (UTC)
Received: by mail-yb1-xb34.google.com with SMTP id e65so22798963ybh.10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 30 Mar 2023 03:39:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20210112; t=1680172792;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=TqYRwaODfWDI06Q58hQVztQbAPPbCiv4GB7G+C0yHa0=;
 b=XMFOjg8zkjoN69rU9lU60afKu8iGYZRtNrH2gE8j5Ee9lwmAQuQWZ/TqahkTDdd216
 v9vjpGGyZMT7k0P6h9wuDOI6AWphppTLWZw7Jb9r7ELv9yHO2koEUJjM5ybKZ6yozGve
 G24e2j7D7pz/p0mQXz/n1BOQHbccDi6sWE4sTQzrP32qPJU+1fiuMiTPRz72/TgVKvUW
 m2YAhRXJ5y9+HPQOOjnAYP8Os1QNKWOYob1JAAPNBdR4WcDsDfaMOEM7apbYjebOb5mj
 FxNg2mFMvUiAcMxu5ZvP0W/sthiX5KflPSOabNGs4NxRjGh/0Ey3qKU/Z9FG4nw0xsrg
 Ulwg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112; t=1680172792;
 h=cc: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=TqYRwaODfWDI06Q58hQVztQbAPPbCiv4GB7G+C0yHa0=;
 b=iHaCbwdI4eImfRRq6ZZj8OCk/lMf16hZGonxc8G3p6actdrDf2Obe9bEslERfX2pvm
 UohyqAXEazTfEs9w/ruzW4krutNWC3usM1XiV4SZfZhVJL7MFFDEMrs1cqbsAKKMSppy
 KDW1CxVzeEt4TNpZUCuO7Y5I3mhRVu8sU/0rVe/L/u+46y3x/dnR5qezsKOv1tijqHW7
 PZ4JOhpiCwxJO1h1JnVBnqqLR/rVjuD6sJP5IKPpsQ9aOYw7niv1ynuznxSbVQ9gfhG5
 qg8voMJ8T310kKR1hi/vZ9Ef2Q536Ax/ajxe4LbJwk1/AwAuA/o9MjQYQMLC4i/OaWQ+
 r/sw==
X-Gm-Message-State: AAQBX9f8HsmvBLHJNiBesjACXpC0NbFfQFnqGlJWLWsC0uAm56+MRmJy
 PSIWOctCEAUV1Dsd+Xzj0FPw3sVerrVOraGX6HM=
X-Google-Smtp-Source: AKy350btrrwoBSJ5/QahRcHfEkSi1Y1BIrJPiyIYmSV4W0Vha+t2gS+b45tdjphFVxD0TsWrRQ7bv0pkJJSdkhSUBO0=
X-Received: by 2002:a05:6902:102b:b0:b46:4a5e:3651 with SMTP id
 x11-20020a056902102b00b00b464a5e3651mr14738697ybt.9.1680172792014; Thu, 30
 Mar 2023 03:39:52 -0700 (PDT)
MIME-Version: 1.0
References: <CAPfvXfJQKb7i8GBvTEvTTz-3dU_5mH8jOv8Nm4Q8gPt=KxrqLQ@mail.gmail.com>
 <CAB3F3DveCDz6yy-rd3ttV8+4sMufsvB+9J-qVK95yh9aLYX+Mw@mail.gmail.com>
 <ZAAqIZZO1KK32Th9@erisian.com.au>
 <CAB3F3DtGpVHkyT_=KLS42rvdP=dgnMvChhR1Rs0BHO5yOEabmw@mail.gmail.com>
 <CAPfvXf+4iX0h-nSuyTai_VvJHkDvAyKtgSk6DsaEwE8N3wnYEg@mail.gmail.com>
 <ZAcx7oEZxC9BiWvg@erisian.com.au> <ZB2THW3WT2wiU7Ni@erisian.com.au>
 <CAJ4-pEAyuHi-1iBzYWbpUNi2-YkxFLVBKAWTV=TyP1TVTFYMfA@mail.gmail.com>
 <C4SV8-jdNABNgVA8aE8Du6WITwynrcq9st7wkSN4k6Px4zhWKWZdSlAvYhTLRXe3yDMC5uNhRNoMGAdMqKReVYUjr-0dGGv9H2u2L9v7gtY=@protonmail.com>
In-Reply-To: <C4SV8-jdNABNgVA8aE8Du6WITwynrcq9st7wkSN4k6Px4zhWKWZdSlAvYhTLRXe3yDMC5uNhRNoMGAdMqKReVYUjr-0dGGv9H2u2L9v7gtY=@protonmail.com>
From: Zac Greenwood <zachgrw@gmail.com>
Date: Thu, 30 Mar 2023 18:39:40 +0800
Message-ID: <CAJ4-pEDq7kqLR9bAguShazdH6H92Y-pgNsOdEuqj=HaTWom88w@mail.gmail.com>
To: alicexbt <alicexbt@protonmail.com>
Content-Type: multipart/alternative; boundary="0000000000006deb2d05f81bb69d"
X-Mailman-Approved-At: Fri, 31 Mar 2023 09:54:10 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Anthony Towns <aj@erisian.com.au>
Subject: Re: [bitcoin-dev] BIP for OP_VAULT
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, 30 Mar 2023 10:39:55 -0000

--0000000000006deb2d05f81bb69d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi alicexbtc,

Under no circumstance should Bitcoin add any functionality intended to
support private businesses that rely on on-chain storage for their business
model.

Regarding =E2=80=9CFees paid: 150 BTC=E2=80=9D (uh, *citation needed*):

To optimize for profitability a business would generally attempt to operate
using zero- or low-fee transactions. Therefore they tend to contribute
 comparatively little fees but are depriving public use of these cheap
transactions. Worse, they exert a constant upward pressure on fee levels,
making it more expensive for everyone else to transact.

Unlike miners, node operators do not receive any compensation. They however
incur additional cost for bandwidth, electricity and processing time to not
only support some current business but all businesses in the past that ever
tried to turn a profit at their expense, so also after such business failed
and has been long gone. They foot the bill.

Lastly, I don=E2=80=99t believe there is any value in having for instance O=
rdinals
spam the blockchain with images of wojaks, bored apes and other crap but
perhaps you wish to clarify why this might be something to be =E2=80=9Cexci=
ted
about=E2=80=9D.

Your other arguments are nonsensical so excuse me for ignoring them.


Zac


On Thu, 30 Mar 2023 at 03:57, alicexbt <alicexbt@protonmail.com> wrote:

> Hi Zac,
>
> Let me share what those parasites achieved:
>
> - Fees paid: 150 BTC
> - Lot of users and developers trying bitcoin that either never tried or
> gave up early in 2013-15
> - Mempools of nodes of being busy on weekends and got lots of transaction=
s
> - PSBT became cool and application devs are trying their best to use it i=
n
> different ways
> - Some developers exploring taproot and multisig
> - AJ shared things how covenants could help in fair, non-custodial,
> on-chain auction of ordinals that is MEV resistant although I had shared =
it
> earlier which involves more steps:
> https://twitter.com/1440000bytes/status/1634368411760476161
> - Investors exploring about funding projects
> - Bitcoin more than Bitcoin and people excited about it
>
> We can have difference of opinion, however I want bitcoin to be money and
> money means different things for people in this world. Please respect tha=
t
> else it will become like Linux, something used by 1% of world.
>
> /dev/fd0
> floppy disk guy
>
> Sent with Proton Mail secure email.
>
> ------- Original Message -------
> On Wednesday, March 29th, 2023 at 12:40 PM, Zac Greenwood via bitcoin-dev=
 <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>
> > I=E2=80=99m not sure why any effort should be spent on theorizing how n=
ew
> opcodes might be used to facilitate parasitical use cases of the blockcha=
in.
> >
> > If anything, business models relying on the ability to abuse the
> blockchain as a data store must be made less feasible, not more.
> >
> > Zac
> >
> >
> > On Fri, 24 Mar 2023 at 20:10, Anthony Towns via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > > On Tue, Mar 07, 2023 at 10:45:34PM +1000, Anthony Towns via
> bitcoin-dev wrote:
> > > > I think there are perhaps four opcodes that are interesting in this
> class:
> > > >
> > > > idx sPK OP_FORWARD_TARGET
> > > > -- sends the value to a particular output (given by idx), and
> > > > requires that output have a particular scriptPubKey (given
> > > > by sPK).
> > > >
> > > > idx [...] n script OP_FORWARD_LEAF_UPDATE
> > > > -- sends the value to a particular output (given by idx), and
> > > > requires that output to have almost the same scriptPubKey as this
> > > > input, _except_ that the current leaf is replaced by "script",
> > > > with that script prefixed by "n" pushes (of values given by [...])
> > > >
> > > > idx OP_FORWARD_SELF
> > > > -- sends the value to a particular output (given by idx), and
> > > > requires that output to have the same scriptPubKey as this input
> > > >
> > > > amt OP_FORWARD_PARTIAL
> > > > -- modifies the next OP_FORWARD_* opcode to only affect "amt",
> > > > rather than the entire balance. opcodes after that affect the
> > > > remaining balance, after "amt" has been subtracted. if "amt" is
> > > > 0, the next OP_FORWARD_* becomes a no-op.
> > >
> > > The BIP 345 draft has been updated [0] [1] and now pretty much define=
s
> > > OP_VAULT to have the behaviour specced for OP_FORWARD_LEAF_UPDATE
> above,
> > > and OP_VAULT_RECOVER to behave as OP_FORWARD_TARGET above. Despite
> > > that, for this email I'm going to continue using the OP_FORWARD_*
> > > naming convention.
> > >
> > > Given the recent controversy over the Yuga labs ordinal auction [2],
> > > perhaps it's interesting to consider that these proposed opcodes come
> > > close to making it possible to do a fair, non-custodial, on-chain
> auction
> > > of ordinals [3].
> > >
> > > The idea here is that you create a utxo on chain that contains the
> ordinal
> > > in question, which commits to the address of the current leading
> bidder,
> > > and can be spent in two ways:
> > >
> > > 1) it can be updated to a new bidder, if the bid is raised by at leas=
t
> > > K satoshis, in which case the previous bidder is refunded their
> > > bid; or,
> > >
> > > 2) if there have been no new bids for a day, the current high bidder
> > > wins, and the ordinal is moved to their address, while the funds
> > > from their winning bid are sent to the original vendor's address.
> > >
> > > I believe this can be implemented in script as follows,
> > > assuming the opcodes OP_FORWARD_TARGET(OP_VAULT_RECOVER),
> > > OP_FORWARD_LEAF_UPDATE(OP_VAULT), OP_FORWARD_PARTIAL (as specced
> above),
> > > and OP_PUSHCURRENTINPUTINDEX (as implemented in liquid/elements [4])
> > > are all available.
> > >
> > > First, figure out the parameters:
> > >
> > > * Set VENDOR to the scriptPubKey corresponding to the vendor's addres=
s.
> > > * Set K to the minimum bid increment [5].
> > > * Initially, set X equal to VENDOR.
> > > * Initially, set V to just below the reserve price (V+K is the
> > > minimum initial bid).
> > >
> > > Then construct the following script:
> > >
> > > [X] [V] [SSS] TOALT TOALT TOALT
> > > 0 PUSHCURRENTINPUTINDEX EQUALVERIFY
> > > DEPTH NOT IF
> > > 0 10000 FORWARD_PARTIAL
> > > 0 FROMALT FORWARD_TARGET
> > > 1 [VENDOR] FWD_TARGET
> > > 144
> > > ELSE
> > > FROMALT SWAP TUCK FROMALT
> > > [K] ADD GREATERTHANOREQUAL VERIFY
> > > 1 SWAP FORWARD_TARGET
> > > DUP FORWARD_PARTIAL
> > > 0 ROT ROT
> > > FROMALT DUP 3 SWAP FORWARD_LEAF_UPDATE
> > > 0
> > > ENDIF
> > > CSV
> > > 1ADD
> > >
> > > where "SSS" is a pushdata of the rest of the script ("TOALT TOALT TOA=
LT
> > > .. 1ADD").
> > >
> > > Finally, make that script the sole tapleaf, accompanied by a NUMS poi=
nt
> > > as the internal public key, calculate the taproot address correspondi=
ng
> > > to that, and send the ordinal to that address as the first satoshi.
> > >
> > > There are two ways to spend that script. With an empty witness stack,
> > > the following will be executed:
> > >
> > > [X] [V] [SSS] TOALT TOALT TOALT
> > > -- altstack now contains [SSS V X]
> > > 0 PUSHCURRENTINPUTINDEX EQUALVERIFY
> > > -- this input is the first, so the ordinal will move to the first
> > > output
> > > DEPTH NOT IF
> > > -- take this branch: the auction is over!
> > > 1 [VENDOR] FWD_TARGET
> > > -- output 1 gets the entire value of this input, and pays to
> > > the vendor's hardcoded scriptPubKey
> > > 0 10000 FORWARD_PARTIAL
> > > 0 FROMALT FORWARD_TARGET
> > > -- we forward at least 10k sats to output 0 (if there were 0 sats,
> > > the ordinal would end up in output 1 instead, which would be a
> > > bug), and output 0 pays to scriptPubKey "X"
> > > 144
> > > ELSE .. ENDIF
> > > -- skip over the other branch
> > > CSV
> > > -- check that this input has baked for 144 blocks (~1 day)
> > > 1ADD
> > > -- leave 145 on the stack, which is true. success!
> > >
> > > Alternatively, if you want to increase the bid you provide a stack wi=
th
> > > two items: your scriptPubKey and the new bid [X' V']. Execution this
> > > time looks like:
> > >
> > > [X] [V] [SSS] TOALT TOALT TOALT
> > > -- stack contains [X' V'], altstack now contains [SSS V X]
> > > 0 PUSHCURRENTINPUTINDEX EQUALVERIFY
> > > -- this input is the first, so the ordinal will move to the first
> > > output
> > > DEPTH NOT IF ... ELSE
> > > -- skip over the other branch (without violating minimalif rules)
> > > FROMALT SWAP TUCK FROMALT
> > > -- stack contains [X' V' X V' V], altstack contains [SSS]
> > > [K] ADD GREATERTHANOREQUAL VERIFY
> > > -- check V' >=3D V+K, stack contains [X' V' X]
> > > 1 SWAP FORWARD_TARGET
> > > -- output 1 pays to X (previous bidder's scriptPubKey), and the
> > > entire value of this input goes there; stack contains [X' V']
> > > DUP FORWARD_PARTIAL
> > > -- execute "V' FORWARD_PARTIAL", stack contains [X' V']
> > > 0 ROT ROT
> > > -- stack contains [0 X' V']
> > > FROMALT DUP 3 SWAP FORWARD_LEAF_UPDATE
> > > -- execute "0 X' V' SSS 3 SSS FORWARD_LEAF_UPDATE" which checks
> > > that output 0 spends at least V' satoshis back to the same
> > > script (because that's how we defined SSS), except the first
> > > three pushes (previously X V SSS) are replaced by X' V' SSS.
> > > 0
> > > ENDIF
> > > CSV
> > > -- "0 CSV" requires nSequnce to be set, which makes the tx rbf'able,
> > > which hopefully makes it harder to pin
> > > 1ADD
> > > -- ends with 1 on the stack; success!
> > >
> > > (The "SSS n SSS FORWARD_LEAF_UPDATE" construct is more or less a quin=
e,
> > > ie a program that outputs its own source code)
> > >
> > > I think that script is about 211 witness bytes, with an additional 40
> > > witness bytes for X'/V', so when making a bid, your tx would be
> > > something like:
> > >
> > > tx header, 10vb
> > > input 0: 103vb for the old bid including witness and control block
> > > input 1: 58vb for a taproot key path spend
> > > output 0: 43vb for the new bid
> > > output 1: 43vb for your change
> > >
> > > for a total of about 257vb -- slightly larger than a regular 2-in-2-o=
ut
> > > transaction, but not terribly much. Mostly because input 0 doesn't
> require
> > > a signature -- it's size is effectively 6 pubkeys: X, X' VENDOR twice=
,
> > > and the script code twice, along with a little extra to encode the
> > > various numbers (10000, 144, K, V, V').
> > >
> > > This approach seems pretty "MEV" resistant: you pay fees via input 1 =
if
> > > your bid succeeds; if it doesn't, you don't pay any fees. A potential
> > > scalper might want to put in an early low ball bid, then prevent
> > > higher bidders from winning the auction, take control of the ordinal,
> > > and resell it later, but unless they can prevent another miner from
> > > mining alternative bids for 144 blocks, they will fail at that. The b=
id
> > > is fixed by the bidder and committed to by the signature on input 1, =
so
> > > frontrunning a bid can't do anything beyond invalidate the bid
> entirely.
> > >
> > > Obviously, this is a pretty limited auction mechanism in various ways=
;
> > > eg maybe you'd rather specify K as a percentage than an absoute
> increment;
> > > maybe you'd like to have the auction definitely finish by some
> particular
> > > time; maybe you'd like to be able to have the auction be able to
> continue
> > > above 21.47 BTC (2**31 sats); maybe you'd like to do a dutch auction
> > > rather than an english auction. I think you can probably do all those
> > > things with this set of opcodes and clever scripting, though it
> probably
> > > gets ugly.
> > >
> > > I don't think this is easily extensible to taro or rgb style assets,
> > > as rather than being able to ensure the asset is transferred by
> > > controlling the input/output positions, I think you'd need to build
> > > up merkle trees and do point tweaks beyond what's supported by
> > > OP_FORWARD_LEAF_UPDATE/OP_VAULT. Of course, without something like
> > > OP_PUSHCURRENTINPUTINDEX I don't think you could do it for ordinals
> > > either.
> > >
> > > Cheers,
> > > aj
> > >
> > > [0]
> https://github.com/bitcoin/bips/blob/7f747fba82675f28c239df690a07b75529bd=
0960/bip-0345.mediawiki
> > >
> > > [1] https://twitter.com/jamesob/status/1639019107432513537
> > >
> > > [2]
> https://cointelegraph.com/news/scammers-dream-yuga-s-auction-model-for-bi=
tcoin-nfts-sees-criticism
> > >
> > > [3] Inscriptions remain a wasteful way of publishing/committing
> > > to content, however!
> > >
> > > [4]
> https://github.com/ElementsProject/elements/blob/master/doc/tapscript_opc=
odes.md
> > >
> > > [5] Setting K too low probably invites griefing, where a bidder may b=
e
> > > able to use rbf pinning vectors to prevent people who would be willin=
g
> > > to bid substantially higher from getting their bid confirmed on
> > > chain.
> > > _______________________________________________
> > > bitcoin-dev mailing list
> > > bitcoin-dev@lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--0000000000006deb2d05f81bb69d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div><div dir=3D"auto">Hi alicexbtc,</div><div dir=3D"auto"><br></div><div =
dir=3D"auto">Under no circumstance should Bitcoin add any functionality int=
ended to support private businesses that rely on on-chain storage for their=
 business model.=C2=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">R=
egarding =E2=80=9CFees paid: 150 BTC=E2=80=9D (uh, *citation needed*):</div=
><div dir=3D"auto"><br></div><div dir=3D"auto">To optimize for profitabilit=
y a business would generally attempt to operate using zero- or low-fee tran=
sactions. Therefore they tend to contribute =C2=A0comparatively little fees=
 but are depriving public use of these cheap transactions. Worse, they exer=
t a constant upward pressure on fee levels, making it more expensive for ev=
eryone else to transact.</div><div dir=3D"auto"><br></div><div dir=3D"auto"=
>Unlike miners, node operators do not receive any compensation. They howeve=
r incur additional cost for bandwidth, electricity and processing time to n=
ot only support some current business but all businesses in the past that e=
ver tried to turn a profit at their expense, so also after such business fa=
iled and has been long gone. They foot the bill.</div><div dir=3D"auto"><br=
></div><div dir=3D"auto">Lastly, I don=E2=80=99t believe there is any value=
 in having for instance Ordinals spam the blockchain with images of wojaks,=
 bored apes and other crap but perhaps you wish to clarify why this might b=
e something to be =E2=80=9Cexcited about=E2=80=9D.</div><div dir=3D"auto"><=
br></div><div dir=3D"auto">Your other arguments are nonsensical so excuse m=
e for ignoring them.</div></div><div><div dir=3D"auto"><br></div><div dir=
=3D"auto"><br></div><div dir=3D"auto">Zac</div><div dir=3D"auto"><br></div>=
<div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">O=
n Thu, 30 Mar 2023 at 03:57, alicexbt &lt;<a href=3D"mailto:alicexbt@proton=
mail.com" target=3D"_blank">alicexbt@protonmail.com</a>&gt; wrote:<br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:=
rgb(204,204,204)">Hi Zac,<br>
<br>
Let me share what those parasites achieved:<br>
<br>
- Fees paid: 150 BTC<br>
- Lot of users and developers trying bitcoin that either never tried or gav=
e up early in 2013-15<br>
- Mempools of nodes of being busy on weekends and got lots of transactions<=
br>
- PSBT became cool and application devs are trying their best to use it in =
different ways<br>
- Some developers exploring taproot and multisig<br>
- AJ shared things how covenants could help in fair, non-custodial, on-chai=
n auction of ordinals that is MEV resistant although I had shared it earlie=
r which involves more steps: <a href=3D"https://twitter.com/1440000bytes/st=
atus/1634368411760476161" rel=3D"noreferrer" target=3D"_blank">https://twit=
ter.com/1440000bytes/status/1634368411760476161</a><br>
- Investors exploring about funding projects<br>
- Bitcoin more than Bitcoin and people excited about it <br>
<br>
We can have difference of opinion, however I want bitcoin to be money and m=
oney means different things for people in this world. Please respect that e=
lse it will become like Linux, something used by 1% of world. <br>
<br>
/dev/fd0<br>
floppy disk guy<br>
<br>
Sent with Proton Mail secure email.<br>
<br>
------- Original Message -------<br>
On Wednesday, March 29th, 2023 at 12:40 PM, Zac Greenwood via bitcoin-dev &=
lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blan=
k">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
<br>
<br>
&gt; I=E2=80=99m not sure why any effort should be spent on theorizing how =
new opcodes might be used to facilitate parasitical use cases of the blockc=
hain.<br>
&gt;<br>
&gt; If anything, business models relying on the ability to abuse the block=
chain as a data store must be made less feasible, not more.<br>
&gt;<br>
&gt; Zac<br>
&gt;<br>
&gt;<br>
&gt; On Fri, 24 Mar 2023 at 20:10, Anthony Towns via bitcoin-dev &lt;<a hre=
f=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoi=
n-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt; On Tue, Mar 07, 2023 at 10:45:34PM +1000, Anthony Towns via bitco=
in-dev wrote:<br>
&gt; &gt; &gt; I think there are perhaps four opcodes that are interesting =
in this class:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; idx sPK OP_FORWARD_TARGET<br>
&gt; &gt; &gt; -- sends the value to a particular output (given by idx), an=
d<br>
&gt; &gt; &gt; requires that output have a particular scriptPubKey (given<b=
r>
&gt; &gt; &gt; by sPK).<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; idx [...] n script OP_FORWARD_LEAF_UPDATE<br>
&gt; &gt; &gt; -- sends the value to a particular output (given by idx), an=
d<br>
&gt; &gt; &gt; requires that output to have almost the same scriptPubKey as=
 this<br>
&gt; &gt; &gt; input, _except_ that the current leaf is replaced by &quot;s=
cript&quot;,<br>
&gt; &gt; &gt; with that script prefixed by &quot;n&quot; pushes (of values=
 given by [...])<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; idx OP_FORWARD_SELF<br>
&gt; &gt; &gt; -- sends the value to a particular output (given by idx), an=
d<br>
&gt; &gt; &gt; requires that output to have the same scriptPubKey as this i=
nput<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; amt OP_FORWARD_PARTIAL<br>
&gt; &gt; &gt; -- modifies the next OP_FORWARD_* opcode to only affect &quo=
t;amt&quot;,<br>
&gt; &gt; &gt; rather than the entire balance. opcodes after that affect th=
e<br>
&gt; &gt; &gt; remaining balance, after &quot;amt&quot; has been subtracted=
. if &quot;amt&quot; is<br>
&gt; &gt; &gt; 0, the next OP_FORWARD_* becomes a no-op.<br>
&gt; &gt;<br>
&gt; &gt; The BIP 345 draft has been updated [0] [1] and now pretty much de=
fines<br>
&gt; &gt; OP_VAULT to have the behaviour specced for OP_FORWARD_LEAF_UPDATE=
 above,<br>
&gt; &gt; and OP_VAULT_RECOVER to behave as OP_FORWARD_TARGET above. Despit=
e<br>
&gt; &gt; that, for this email I&#39;m going to continue using the OP_FORWA=
RD_*<br>
&gt; &gt; naming convention.<br>
&gt; &gt;<br>
&gt; &gt; Given the recent controversy over the Yuga labs ordinal auction [=
2],<br>
&gt; &gt; perhaps it&#39;s interesting to consider that these proposed opco=
des come<br>
&gt; &gt; close to making it possible to do a fair, non-custodial, on-chain=
 auction<br>
&gt; &gt; of ordinals [3].<br>
&gt; &gt;<br>
&gt; &gt; The idea here is that you create a utxo on chain that contains th=
e ordinal<br>
&gt; &gt; in question, which commits to the address of the current leading =
bidder,<br>
&gt; &gt; and can be spent in two ways:<br>
&gt; &gt;<br>
&gt; &gt; 1) it can be updated to a new bidder, if the bid is raised by at =
least<br>
&gt; &gt; K satoshis, in which case the previous bidder is refunded their<b=
r>
&gt; &gt; bid; or,<br>
&gt; &gt;<br>
&gt; &gt; 2) if there have been no new bids for a day, the current high bid=
der<br>
&gt; &gt; wins, and the ordinal is moved to their address, while the funds<=
br>
&gt; &gt; from their winning bid are sent to the original vendor&#39;s addr=
ess.<br>
&gt; &gt;<br>
&gt; &gt; I believe this can be implemented in script as follows,<br>
&gt; &gt; assuming the opcodes OP_FORWARD_TARGET(OP_VAULT_RECOVER),<br>
&gt; &gt; OP_FORWARD_LEAF_UPDATE(OP_VAULT), OP_FORWARD_PARTIAL (as specced =
above),<br>
&gt; &gt; and OP_PUSHCURRENTINPUTINDEX (as implemented in liquid/elements [=
4])<br>
&gt; &gt; are all available.<br>
&gt; &gt;<br>
&gt; &gt; First, figure out the parameters:<br>
&gt; &gt;<br>
&gt; &gt; * Set VENDOR to the scriptPubKey corresponding to the vendor&#39;=
s address.<br>
&gt; &gt; * Set K to the minimum bid increment [5].<br>
&gt; &gt; * Initially, set X equal to VENDOR.<br>
&gt; &gt; * Initially, set V to just below the reserve price (V+K is the<br=
>
&gt; &gt; minimum initial bid).<br>
&gt; &gt;<br>
&gt; &gt; Then construct the following script:<br>
&gt; &gt;<br>
&gt; &gt; [X] [V] [SSS] TOALT TOALT TOALT<br>
&gt; &gt; 0 PUSHCURRENTINPUTINDEX EQUALVERIFY<br>
&gt; &gt; DEPTH NOT IF<br>
&gt; &gt; 0 10000 FORWARD_PARTIAL<br>
&gt; &gt; 0 FROMALT FORWARD_TARGET<br>
&gt; &gt; 1 [VENDOR] FWD_TARGET<br>
&gt; &gt; 144<br>
&gt; &gt; ELSE<br>
&gt; &gt; FROMALT SWAP TUCK FROMALT<br>
&gt; &gt; [K] ADD GREATERTHANOREQUAL VERIFY<br>
&gt; &gt; 1 SWAP FORWARD_TARGET<br>
&gt; &gt; DUP FORWARD_PARTIAL<br>
&gt; &gt; 0 ROT ROT<br>
&gt; &gt; FROMALT DUP 3 SWAP FORWARD_LEAF_UPDATE<br>
&gt; &gt; 0<br>
&gt; &gt; ENDIF<br>
&gt; &gt; CSV<br>
&gt; &gt; 1ADD<br>
&gt; &gt;<br>
&gt; &gt; where &quot;SSS&quot; is a pushdata of the rest of the script (&q=
uot;TOALT TOALT TOALT<br>
&gt; &gt; .. 1ADD&quot;).<br>
&gt; &gt;<br>
&gt; &gt; Finally, make that script the sole tapleaf, accompanied by a NUMS=
 point<br>
&gt; &gt; as the internal public key, calculate the taproot address corresp=
onding<br>
&gt; &gt; to that, and send the ordinal to that address as the first satosh=
i.<br>
&gt; &gt;<br>
&gt; &gt; There are two ways to spend that script. With an empty witness st=
ack,<br>
&gt; &gt; the following will be executed:<br>
&gt; &gt;<br>
&gt; &gt; [X] [V] [SSS] TOALT TOALT TOALT<br>
&gt; &gt; -- altstack now contains [SSS V X]<br>
&gt; &gt; 0 PUSHCURRENTINPUTINDEX EQUALVERIFY<br>
&gt; &gt; -- this input is the first, so the ordinal will move to the first=
<br>
&gt; &gt; output<br>
&gt; &gt; DEPTH NOT IF<br>
&gt; &gt; -- take this branch: the auction is over!<br>
&gt; &gt; 1 [VENDOR] FWD_TARGET<br>
&gt; &gt; -- output 1 gets the entire value of this input, and pays to<br>
&gt; &gt; the vendor&#39;s hardcoded scriptPubKey<br>
&gt; &gt; 0 10000 FORWARD_PARTIAL<br>
&gt; &gt; 0 FROMALT FORWARD_TARGET<br>
&gt; &gt; -- we forward at least 10k sats to output 0 (if there were 0 sats=
,<br>
&gt; &gt; the ordinal would end up in output 1 instead, which would be a<br=
>
&gt; &gt; bug), and output 0 pays to scriptPubKey &quot;X&quot;<br>
&gt; &gt; 144<br>
&gt; &gt; ELSE .. ENDIF<br>
&gt; &gt; -- skip over the other branch<br>
&gt; &gt; CSV<br>
&gt; &gt; -- check that this input has baked for 144 blocks (~1 day)<br>
&gt; &gt; 1ADD<br>
&gt; &gt; -- leave 145 on the stack, which is true. success!<br>
&gt; &gt;<br>
&gt; &gt; Alternatively, if you want to increase the bid you provide a stac=
k with<br>
&gt; &gt; two items: your scriptPubKey and the new bid [X&#39; V&#39;]. Exe=
cution this<br>
&gt; &gt; time looks like:<br>
&gt; &gt;<br>
&gt; &gt; [X] [V] [SSS] TOALT TOALT TOALT<br>
&gt; &gt; -- stack contains [X&#39; V&#39;], altstack now contains [SSS V X=
]<br>
&gt; &gt; 0 PUSHCURRENTINPUTINDEX EQUALVERIFY<br>
&gt; &gt; -- this input is the first, so the ordinal will move to the first=
<br>
&gt; &gt; output<br>
&gt; &gt; DEPTH NOT IF ... ELSE<br>
&gt; &gt; -- skip over the other branch (without violating minimalif rules)=
<br>
&gt; &gt; FROMALT SWAP TUCK FROMALT<br>
&gt; &gt; -- stack contains [X&#39; V&#39; X V&#39; V], altstack contains [=
SSS]<br>
&gt; &gt; [K] ADD GREATERTHANOREQUAL VERIFY<br>
&gt; &gt; -- check V&#39; &gt;=3D V+K, stack contains [X&#39; V&#39; X]<br>
&gt; &gt; 1 SWAP FORWARD_TARGET<br>
&gt; &gt; -- output 1 pays to X (previous bidder&#39;s scriptPubKey), and t=
he<br>
&gt; &gt; entire value of this input goes there; stack contains [X&#39; V&#=
39;]<br>
&gt; &gt; DUP FORWARD_PARTIAL<br>
&gt; &gt; -- execute &quot;V&#39; FORWARD_PARTIAL&quot;, stack contains [X&=
#39; V&#39;]<br>
&gt; &gt; 0 ROT ROT<br>
&gt; &gt; -- stack contains [0 X&#39; V&#39;]<br>
&gt; &gt; FROMALT DUP 3 SWAP FORWARD_LEAF_UPDATE<br>
&gt; &gt; -- execute &quot;0 X&#39; V&#39; SSS 3 SSS FORWARD_LEAF_UPDATE&qu=
ot; which checks<br>
&gt; &gt; that output 0 spends at least V&#39; satoshis back to the same<br=
>
&gt; &gt; script (because that&#39;s how we defined SSS), except the first<=
br>
&gt; &gt; three pushes (previously X V SSS) are replaced by X&#39; V&#39; S=
SS.<br>
&gt; &gt; 0<br>
&gt; &gt; ENDIF<br>
&gt; &gt; CSV<br>
&gt; &gt; -- &quot;0 CSV&quot; requires nSequnce to be set, which makes the=
 tx rbf&#39;able,<br>
&gt; &gt; which hopefully makes it harder to pin<br>
&gt; &gt; 1ADD<br>
&gt; &gt; -- ends with 1 on the stack; success!<br>
&gt; &gt;<br>
&gt; &gt; (The &quot;SSS n SSS FORWARD_LEAF_UPDATE&quot; construct is more =
or less a quine,<br>
&gt; &gt; ie a program that outputs its own source code)<br>
&gt; &gt;<br>
&gt; &gt; I think that script is about 211 witness bytes, with an additiona=
l 40<br>
&gt; &gt; witness bytes for X&#39;/V&#39;, so when making a bid, your tx wo=
uld be<br>
&gt; &gt; something like:<br>
&gt; &gt;<br>
&gt; &gt; tx header, 10vb<br>
&gt; &gt; input 0: 103vb for the old bid including witness and control bloc=
k<br>
&gt; &gt; input 1: 58vb for a taproot key path spend<br>
&gt; &gt; output 0: 43vb for the new bid<br>
&gt; &gt; output 1: 43vb for your change<br>
&gt; &gt;<br>
&gt; &gt; for a total of about 257vb -- slightly larger than a regular 2-in=
-2-out<br>
&gt; &gt; transaction, but not terribly much. Mostly because input 0 doesn&=
#39;t require<br>
&gt; &gt; a signature -- it&#39;s size is effectively 6 pubkeys: X, X&#39; =
VENDOR twice,<br>
&gt; &gt; and the script code twice, along with a little extra to encode th=
e<br>
&gt; &gt; various numbers (10000, 144, K, V, V&#39;).<br>
&gt; &gt;<br>
&gt; &gt; This approach seems pretty &quot;MEV&quot; resistant: you pay fee=
s via input 1 if<br>
&gt; &gt; your bid succeeds; if it doesn&#39;t, you don&#39;t pay any fees.=
 A potential<br>
&gt; &gt; scalper might want to put in an early low ball bid, then prevent<=
br>
&gt; &gt; higher bidders from winning the auction, take control of the ordi=
nal,<br>
&gt; &gt; and resell it later, but unless they can prevent another miner fr=
om<br>
&gt; &gt; mining alternative bids for 144 blocks, they will fail at that. T=
he bid<br>
&gt; &gt; is fixed by the bidder and committed to by the signature on input=
 1, so<br>
&gt; &gt; frontrunning a bid can&#39;t do anything beyond invalidate the bi=
d entirely.<br>
&gt; &gt;<br>
&gt; &gt; Obviously, this is a pretty limited auction mechanism in various =
ways;<br>
&gt; &gt; eg maybe you&#39;d rather specify K as a percentage than an absou=
te increment;<br>
&gt; &gt; maybe you&#39;d like to have the auction definitely finish by som=
e particular<br>
&gt; &gt; time; maybe you&#39;d like to be able to have the auction be able=
 to continue<br>
&gt; &gt; above 21.47 BTC (2**31 sats); maybe you&#39;d like to do a dutch =
auction<br>
&gt; &gt; rather than an english auction. I think you can probably do all t=
hose<br>
&gt; &gt; things with this set of opcodes and clever scripting, though it p=
robably<br>
&gt; &gt; gets ugly.<br>
&gt; &gt;<br>
&gt; &gt; I don&#39;t think this is easily extensible to taro or rgb style =
assets,<br>
&gt; &gt; as rather than being able to ensure the asset is transferred by<b=
r>
&gt; &gt; controlling the input/output positions, I think you&#39;d need to=
 build<br>
&gt; &gt; up merkle trees and do point tweaks beyond what&#39;s supported b=
y<br>
&gt; &gt; OP_FORWARD_LEAF_UPDATE/OP_VAULT. Of course, without something lik=
e<br>
&gt; &gt; OP_PUSHCURRENTINPUTINDEX I don&#39;t think you could do it for or=
dinals<br>
&gt; &gt; either.<br>
&gt; &gt;<br>
&gt; &gt; Cheers,<br>
&gt; &gt; aj<br>
&gt; &gt;<br>
&gt; &gt; [0] <a href=3D"https://github.com/bitcoin/bips/blob/7f747fba82675=
f28c239df690a07b75529bd0960/bip-0345.mediawiki" rel=3D"noreferrer" target=
=3D"_blank">https://github.com/bitcoin/bips/blob/7f747fba82675f28c239df690a=
07b75529bd0960/bip-0345.mediawiki</a><br>
&gt; &gt;<br>
&gt; &gt; [1] <a href=3D"https://twitter.com/jamesob/status/163901910743251=
3537" rel=3D"noreferrer" target=3D"_blank">https://twitter.com/jamesob/stat=
us/1639019107432513537</a><br>
&gt; &gt;<br>
&gt; &gt; [2] <a href=3D"https://cointelegraph.com/news/scammers-dream-yuga=
-s-auction-model-for-bitcoin-nfts-sees-criticism" rel=3D"noreferrer" target=
=3D"_blank">https://cointelegraph.com/news/scammers-dream-yuga-s-auction-mo=
del-for-bitcoin-nfts-sees-criticism</a><br>
&gt; &gt;<br>
&gt; &gt; [3] Inscriptions remain a wasteful way of publishing/committing<b=
r>
&gt; &gt; to content, however!<br>
&gt; &gt;<br>
&gt; &gt; [4] <a href=3D"https://github.com/ElementsProject/elements/blob/m=
aster/doc/tapscript_opcodes.md" rel=3D"noreferrer" target=3D"_blank">https:=
//github.com/ElementsProject/elements/blob/master/doc/tapscript_opcodes.md<=
/a><br>
&gt; &gt;<br>
&gt; &gt; [5] Setting K too low probably invites griefing, where a bidder m=
ay be<br>
&gt; &gt; able to use rbf pinning vectors to prevent people who would be wi=
lling<br>
&gt; &gt; to bid substantially higher from getting their bid confirmed on<b=
r>
&gt; &gt; chain.<br>
&gt; &gt; _______________________________________________<br>
&gt; &gt; bitcoin-dev mailing list<br>
&gt; &gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt; &gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bit=
coin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundatio=
n.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>
</div>

--0000000000006deb2d05f81bb69d--