Re: [bitcoindev] CTV + CSFS: a letter

[Saint Wenhao <saintwenhao@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4378 bytes --]

> 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/cc159432ffb7a166abeccc79800e9616a09ea9ac6937080c2ca37b38671970e5
Example address:
https://mempool.space/testnet4/address/tb1qzsjnew5qcn75e4cqdsc6r9v8fjy5ensancqmv2l2n82p0q5f5tls758l9d
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ł(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 contains
> 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 their
> 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-7fc81f4b666cn%40googlegroups.com
> <https://groups.google.com/d/msgid/bitcoindev/f8220f1b-831a-4459-8dee-7fc81f4b666cn%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>

-- 
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/CACgYNOKE4VmkrMCkSG5WahkJsbw6_9SSuGLzva1c2ER33SD6Kg%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 5404 bytes --]