Delivery-date: Sat, 28 Jun 2025 09:34:52 -0700
Sender: bitcoindev@googlegroups.com
Received-SPF: pass (google.com: domain of saintwenhao@gmail.com designates 2a00:1450:4864:20::529 as permitted sender) client-ip=2a00:1450:4864:20::529;
MIME-Version: 1.0
References: <a86c2737-db79-4f54-9c1d-51beeb765163n@googlegroups.com>
 <aEdoIvOgNNtT6L4s@mail.wpsoftware.net> <195051b7c393b9a28727e87647ac002b@dtrt.org>
 <CAPfvXf+0M2PPYOAuWNt9EFWBXGspkZ3xDXKb9Tm7MW8RO3X0aA@mail.gmail.com>
 <0B7CEBEE-FB2B-41CF-9347-B9C1C246B94D@sprovoost.nl> <f8220f1b-831a-4459-8dee-7fc81f4b666cn@googlegroups.com>
In-Reply-To: <f8220f1b-831a-4459-8dee-7fc81f4b666cn@googlegroups.com>
From: Saint Wenhao <saintwenhao@gmail.com>
Date: Sat, 28 Jun 2025 18:13:06 +0200
Message-ID: <CACgYNOKE4VmkrMCkSG5WahkJsbw6_9SSuGLzva1c2ER33SD6Kg@mail.gmail.com>
Subject: Re: [bitcoindev] CTV + CSFS: a letter
To: Paul Sztorc <truthcoin@gmail.com>
Cc: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Content-Type: multipart/alternative; boundary="0000000000009116d60638a412e9"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

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

> That is why it is better -- I can activate my own thing, without
bothering you all.

After reading BIP-300 in its current form, I think it is too complex.
Instead, much simpler constructions are already available, without any
soft-forks. What is more: they were possible since 2009, and they can be
implemented by raw Script, if needed, which makes them portable between
many altcoins, which copy-pasted Bitcoin's source code, and also between
different address types (excluding TapScript, because OP_SIZE will work
only with DER signatures).

Example testnet transaction:
https://mempool.space/testnet4/tx/cc159432ffb7a166abeccc79800e9616a09ea9ac6=
937080c2ca37b38671970e5
Example address:
https://mempool.space/testnet4/address/tb1qzsjnew5qcn75e4cqdsc6r9v8fjy5ensa=
ncqmv2l2n82p0q5f5tls758l9d
Example Script: OP_SIZE 60 OP_LESSTHAN OP_VERIFY
0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
OP_CHECKSIG

Here, each coin sender can decide, which difficulty should be picked for a
given transaction output. When the size is required to be less than 60,
then that coin can be moved after grinding around 256 hashes (one byte).
Then, by lowering that value, it can be made 256 times harder, each time
this value is decremented (down to 10, because 9-byte signature is the
smallest valid one).

So, to sum up, the ability to lock output Scripts with Proof of Work is
possible here and now, without any consensus changes. The only need for
further changes is related to Merged Mining, because the way of transaction
hashing is obviously different, than the way of hashing existing block
headers. However, that model given above should be sufficient, to deploy
some real, decentralized sidechains, on top of some existing chains, and
see, how they would be used in practice.

czw., 12 cze 2025 o 02:02 Paul Sztorc <truthcoin@gmail.com> napisa=C5=82(a)=
:

> > What I _would_ oppose is a Python based alternative implementation and
> activation client like co-signer Paul Sztorc proposed.[3]
>
> I have done no such thing.
>
> The bip300301_enforcer is in rust [0]. Furthermore, it is not an
> "alternative" to Core --  it must connect to Bitcoin Core, via ZMQ. (But =
it
> is an "activation client" -- of a kind.)
>
> (Anyone who glanced at the github for 2 seconds, would see all of these
> things, by the way.)
> (Sjors, you may be confusing my project, with Bitcoin Core, which contain=
s
> python, including a siget-mining-script.)
>
> CUSF is clever -- because it **frees** Core from the headache and
> responsibility of soft fork activation (which I know many people here
> hardly enjoy). That is why it is better -- I can activate my own thing,
> without bothering you all. And I don't have to "compete" with CTV to be
> further ahead "in line" (or whatever). So I am free to appraise CTV
> rationally.
>
> We all know that Core is a meritocracy. And that every decision and
> sentence uttered by Core is a perfect work of divine truth -- free of all
> the flaws that have plagued every other organization throughout history.
> Lucky us! Just think, in other organizations, people sometimes allow thei=
r
> prejudice to color their judgement, occasionally jumping to conclusions
> that are incorrect -- not here though. Here it's all based on merit, baby=
.
> No need for a plan B!
>
> Cheers,
> Paul
>
> [0] https://github.com/LayerTwo-Labs/bip300301_enforcer
>
> --
> You received this message because you are subscribed to the Google Groups
> "Bitcoin Development Mailing List" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to bitcoindev+unsubscribe@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/bitcoindev/f8220f1b-831a-4459-8dee-7fc8=
1f4b666cn%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/f8220f1b-831a-4459-8dee-7fc=
81f4b666cn%40googlegroups.com?utm_medium=3Demail&utm_source=3Dfooter>
> .
>

--=20
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
CACgYNOKE4VmkrMCkSG5WahkJsbw6_9SSuGLzva1c2ER33SD6Kg%40mail.gmail.com.

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

<div dir=3D"ltr">&gt; That is why it is better -- I can activate my own thi=
ng, without bothering you all.<br><br>After reading BIP-300 in its current =
form, I think it is too complex. Instead, much simpler constructions are al=
ready available, without any soft-forks. What is more: they were possible s=
ince 2009, and they can be implemented by raw Script, if needed, which make=
s them portable between many altcoins, which copy-pasted Bitcoin&#39;s sour=
ce code, and also between different address types (excluding TapScript, bec=
ause OP_SIZE will work only with DER signatures).<br><br>Example testnet tr=
ansaction: <a href=3D"https://mempool.space/testnet4/tx/cc159432ffb7a166abe=
ccc79800e9616a09ea9ac6937080c2ca37b38671970e5">https://mempool.space/testne=
t4/tx/cc159432ffb7a166abeccc79800e9616a09ea9ac6937080c2ca37b38671970e5</a><=
br>Example address: <a href=3D"https://mempool.space/testnet4/address/tb1qz=
sjnew5qcn75e4cqdsc6r9v8fjy5ensancqmv2l2n82p0q5f5tls758l9d">https://mempool.=
space/testnet4/address/tb1qzsjnew5qcn75e4cqdsc6r9v8fjy5ensancqmv2l2n82p0q5f=
5tls758l9d</a><br>Example Script: OP_SIZE 60 OP_LESSTHAN OP_VERIFY 0279be66=
7ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798 OP_CHECKSIG<br><=
br>Here, each coin sender can decide, which difficulty should be picked for=
 a given transaction output. When the size is required to be less than 60, =
then that coin can be moved after grinding around 256 hashes (one byte). Th=
en, by lowering that value, it can be made 256 times harder, each time this=
 value is decremented (down to 10, because 9-byte signature is the smallest=
 valid one).<br><br>So, to sum up, the ability to lock output Scripts with =
Proof of Work is possible here and now, without any consensus changes. The =
only need for further changes is related to Merged Mining, because the way =
of transaction hashing is obviously different, than the way of hashing exis=
ting block headers. However, that model given above should be sufficient, t=
o deploy some real, decentralized sidechains, on top of some existing chain=
s, and see, how they would be used in practice.</div><br><div class=3D"gmai=
l_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">czw., =
12 cze 2025 o 02:02=C2=A0Paul Sztorc &lt;<a href=3D"mailto:truthcoin@gmail.=
com">truthcoin@gmail.com</a>&gt; napisa=C5=82(a):<br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex">&gt;=20
What I  _would_ oppose is a Python based alternative implementation and=20
activation client like co-signer Paul Sztorc proposed.[3]<br><br>I have don=
e no such thing.<br><br>The bip300301_enforcer is in rust [0]. Furthermore,=
 it is not an &quot;alternative&quot; to Core --=C2=A0 it must connect to B=
itcoin Core, via ZMQ. (But it is an &quot;activation client&quot; -- of a k=
ind.)<br><br>(Anyone who glanced at the github for 2 seconds, would see all=
 of these things, by the way.)<br>(Sjors, you may be confusing my project, =
with Bitcoin Core, which contains python, including a siget-mining-script.)=
<br><br>
CUSF is clever -- because it **frees** Core from the headache and responsib=
ility of soft fork activation (which I know many people here hardly enjoy).=
 That is why it is better -- I can activate my own thing, without bothering=
 you all. And I don&#39;t have to &quot;compete&quot; with CTV to be furthe=
r ahead &quot;in line&quot; (or whatever). So I am free to appraise CTV rat=
ionally.<br><br>We all know that Core is a meritocracy. And that every deci=
sion and sentence uttered by Core is a perfect work of divine truth -- free=
 of all the flaws that have plagued every other organization throughout his=
tory. Lucky us! Just think, in other organizations, people sometimes allow =
their prejudice to color their judgement, occasionally jumping to conclusio=
ns that are incorrect -- not here though. Here it&#39;s all based on merit,=
 baby. No need for a plan B!<br><br>Cheers,<br>Paul<br><br>[0] <a href=3D"h=
ttps://github.com/LayerTwo-Labs/bip300301_enforcer" target=3D"_blank">https=
://github.com/LayerTwo-Labs/bip300301_enforcer</a><br><br>

<p></p>

-- <br>
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com" target=
=3D"_blank">bitcoindev+unsubscribe@googlegroups.com</a>.<br>
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/f8220f1b-831a-4459-8dee-7fc81f4b666cn%40googlegroups.com?utm_med=
ium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">https://groups.googl=
e.com/d/msgid/bitcoindev/f8220f1b-831a-4459-8dee-7fc81f4b666cn%40googlegrou=
ps.com</a>.<br>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/CACgYNOKE4VmkrMCkSG5WahkJsbw6_9SSuGLzva1c2ER33SD6Kg%40mail.gmail=
.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/ms=
gid/bitcoindev/CACgYNOKE4VmkrMCkSG5WahkJsbw6_9SSuGLzva1c2ER33SD6Kg%40mail.g=
mail.com</a>.<br />

--0000000000009116d60638a412e9--