Search Posts

Post

Topic

Board Development & Technical Discussion

Re: Bitcoin must upgrade or fall victim to quantum computing in 5 years

stwenhao

on 19/08/2025, 03:59:31 UTC

Quote

its blockchain is space-limited, and thus a transition to a post-quantum algorithm which requires more space would bring a shift in its economics

It can be solved in two ways: first is hiding quantum signatures behind existing ECDSA signatures. Which means, that quantum-safe addresses will take exactly the same on-chain space as today, as long as ECDSA is still strong, and longer validation time, or bigger signatures will be shared, only when quantum alert will be broadcasted, and when old ECDSA transactions will be non-standard, timelocked, or unspendable.

Another way is signature aggregation: now, Taproot can already be used to aggregate many signatures into one, as long as all of them commit to the same message, and the sum of public keys is equal to the on-chain shared key. Which means, that if quantum signatures will be aggregated, then by having more than one user per UTXO, it can scale, even if the maximum size of the post-quantum chain will be similar to the current version (if you have thousands of users per signature, then a single 50 kB signature means around 50 bytes or less per user).

Also, I think we should focus more on sigops limit, than on the block size limit. We now have 80k sigops per block, where legacy signatures take 4 sigops, and witness signatures take 1 sigop. It is just a matter of setting quantum commitment size, and the number of consumed sigops per quantum signature.

Quote

If we had a quantum secure algorithm with signatures/public keys roughly as large as the ECDSA keys/signatures (and not much costlier to validate like in the case of SQIsign), then it would be also much more straightforward to plan a transition.

It is chicken and egg problem: before SHA-1 was attacked, people didn't know, how to properly make hardened version of it. Which means, that it is quite likely, that ECDSA will behave in a similar way: when practical attacks will materialize (or at least PDFs describing practical attacks), only then we will know, how to turn ECDSA into "hardened ECDSA". And it is quite likely, that something will be already deployed, so we will be stuck with ECDSA, and some slow quantum signature scheme, with big signatures, and only practical attacks will tell us, where to look, and how to protect things. And then, we could have hardened ECDSA, and some inefficient quantum scheme. Which is yet another reason, to think about downgrade from quantum, because it is quite likely, that something better will be invented, and we may need to switch from quantum proposal A, to quantum proposal B.

Post

Topic

Board Development & Technical Discussion

Merits 7 from 2 users

Re: The term orphan block

stwenhao

on 18/08/2025, 09:49:16 UTC

⭐ Merited by pooya87 (5) ,vapourminer (2)

Quote

The term orphan block

It is called "stale", instead of "orphan" in other places. Because "orphan" has no parents, and the only block meeting this definition, is the Genesis Block, where its previous block hash is set to zero.

Quote

When exactly does this orphan block occurs?

I think you should try mining something with signet-like difficulty on CPU, to see that in practice. In general, when hashes are grinded, then from time to time, you can get a close match. And then, you have two pieces of Proof of Work, which are equally valid. The first-seen block header is the one, which miners will work on, but both are valid, until someone will share a new block, which would be created on top of it.

See: https://en.bitcoin.it/wiki/Proof_of_work

Code:

"Hello, world!4250" => 0000c3af42fc31103f1fdc0151fa747ff87349a4714df7cc52ea464e12dcd4e9

Here, some miner successfully grinded "Hello, world!" data, with "nonce", equal to "4250". At the same time, a different miner could find a different text, with a different nonce, but also with 16 leading zero bits.

Code:

"Foo, bar!9764" => 00007a63c3af511785b8f127d4f4e4df3c0dc2e0688cacb5cbcbb1289c47dd6f

And then, you have two valid blocks: one contains "Hello, world!" with nonce "4250", and another one contains "Foo, bar!" with nonce "9764". Which one is valid? Both of them are, and then, the next miner produces the next valid block, and then, everyone switches to the stronger chain, with more Proof of Work.

Some Bash scripts for testing things:

Code:

nonce=0
while [ "$nonce" -lt "20000" ]
do
echo -n "Hello, world!""$nonce" | sha256sum >> hello.txt
((nonce=nonce+1))
done

nonce=0
while [ "$nonce" -lt "20000" ]
do
echo -n "Foo, bar!""$nonce" | sha256sum >> foobar.txt
((nonce=nonce+1))
done

Post

Topic

Board Altcoin Discussion

Re: Bitcoin Testnet price movement tracking & discussion

stwenhao

on 18/08/2025, 07:41:06 UTC

Quote

Wen v5?

https://groups.google.com/g/bitcoindev/c/iVLHJ1HWhoU/m/ydjeTH6rAwAJ

Quote

I propose to fix this by removing the difficulty reset rule from testnet4 through a flag day hard fork on 2026-01-01.

Nothing changed since then. The source code for proposed fork is still, where it was. Time will tell, if developers will decide to hard-fork into a new testnet5, or patch the old testnet4 with soft-forks, or do something else. And because their goal is to keep the price as close to zero as possible, I guess testnet5 will be worth even less than testnet4, so I don't know, if you would want to list networks, where each new version is less and less tradable. Because you didn't want to list signet, and obviously, nobody lists regtest, where six blocks are produced every second.

Quote

However, what happens when those ill-gotten dev coins are effectively frozen/stolen?

And what happens when keys for signet will be stolen? So far, it is running since 2020-09-01, and it has around 265k blocks. If keys for signet will be known by everyone, then it will turn into a network, where signet challenge would be just set to OP_TRUE. So, it would change signet into regular testnet, without 20 minute rule, and with regular difficulty adjustments. And this is also possible: a lot of signet coins are now owned by developers, so if any weakness in ECDSA will be discovered, then it will be very similar to proposed testnet5, where 10.5M coins are premined.

Also note, that the current signet uses 1-of-3 multisig. Which means, that for each public key, there is at least 80k signatures. If there is any weakness, related to address reuse, then it can be exploited on signet. And also, because signet miners sign blocks, filled with transactions, provided by users, then it is possible to do some attacks, by sending particular transaction IDs, to encourage a given signet node, to sign a weakened block header, which can be combined with other ECDSA attacks, and used to discover the private key behind it. Because a signature is just a relation between two public keys. If users can pick z-values, by sending particular transactions to the network, they can potentially alter R-value in a particular way, which could make it easier to attack.

Quote

Or have we outgrown that mentality and are prepared to let this puppy run as a hot potato game for ~10 years or when the block reward is pwned(?)

Anyone can release any test network, at any moment. It is just a matter of convincing the community to use your network for testing. In the past, developers had a problem with testnet3, so they made testnet4, to fix bugs. Now, they have two problems: one is buggy testnet3, and another is buggy testnet4. They can stop supporting old test networks in the future, but they cannot "turn them off", if there will still be some users, willing to maintain it. Then, old testnets will become just some altcoins, maintained outside of Bitcoin Core (or they will die, if nobody will want to fix bugs, and if old clients will be exploited by new attacks).

Post

Topic

Board Development & Technical Discussion

Re: Emulating OP_CHECKSIGFROMSTACK with a chain of OP_CHECKSIG operations

stwenhao

on 18/08/2025, 03:54:16 UTC

Quote

Create a 4-of-4 multisig address using these 4 public keys and send some sats to the address

In that case, all you need, is just the simplest 2-of-2 multisig. The first public key can be set to anything, and the second one can have the private key, set to the hash of the message. Which means:

Code:

SHA-256("TEST")=94ee059335e587e501cc4bf90613e0814f00a7b08bc7c648fd865a2af6a22cc2
d=94ee059335e587e501cc4bf90613e0814f00a7b08bc7c648fd865a2af6a22cc2
Q=03DD3E1A26D56446C4D09D1A72D545599603519B34165352054D0DF2F6D453F93D

And then, if you want to use some multisig, you can just do that:

Code:

2 <yourPubkey> 03DD3E1A26D56446C4D09D1A72D545599603519B34165352054D0DF2F6D453F93D 2 OP_CHECKMULTISIG

However, in that case, it can be even simplified to a single signature: https://gnusha.org/pi/bitcoindev/ZVcdKupXU+wjawRI@erisian.com.au/

Code:

Sign-to-contract looks like:

* generate a secret random nonce r0
* calculate the public version R0 = r0*G
* calculate a derived nonce r = r0 + SHA256(R0, data), where "data"
is what you want to commit to
* generate your signature using public nonce R=r*G as usual

And then, for any existing public key, you can commit to any message, by just tweaking your R-value, so all interested parties can see, that you signed this transaction, and committed to a given message, at the same time.

However, this is not the end goal, because then, how do you want to meet some use cases of OP_CHECKSIGFROMSTACK? One of them is allowing to move your coins, if a given message is signed. Which means, that you have for example some transaction:

Code:

SHA-256("txdata")=6c25cd565b52a36694c131a9ec0385dd2854532c8cbbe05c574a73eea6fe6268
SHA-256(6c25cd565b52a36694c131a9ec0385dd2854532c8cbbe05c574a73eea6fe6268)=f98412627d319e88ca3b80540a9c94338cd6bea9d39e0ff07377f3d1757b0cdd
z=f98412627d319e88ca3b80540a9c94338cd6bea9d39e0ff07377f3d1757b0cdd

And then, you want to make your coins spendable, only if someone will sign a transaction, where z-value is set to f98412627d319e88ca3b80540a9c94338cd6bea9d39e0ff07377f3d1757b0cdd, with a given public key. How do you want to use multisig tricks, or R-value tweaking tricks, to get there? Because the whole point of OP_CHECKSIGFROMSTACK is to allow spending a given coin, if some arbitrary message with a given z-value is signed. Which means, that you want to put for example f98412627d319e88ca3b80540a9c94338cd6bea9d39e0ff07377f3d1757b0cdd as a message in OP_CHECKSIGFROMSTACK, which then would be hashed, would give us f98412627d319e88ca3b80540a9c94338cd6bea9d39e0ff07377f3d1757b0cdd, and would be checked for ECDSA correctness for a given public key.

In the meantime, I figured out, how to make a chain of public key recovery operations:

Code:

+--------+----------------------------------------------------------------+------------------------------------+
| Sigops | Address | Script |
+--------+----------------------------------------------------------------+------------------------------------+
| 1 | tb1qae4ms66yxwfe9whxx8y0v8wc7qyjg0rrttdtx0qtyzfr5fu5hu3qv5lwmj | ac |
+--------+----------------------------------------------------------------+------------------------------------+
| 2 | tb1qlp50wauhzxnn05km0sz7hhpu636v28a4gezl77hf2t0gtc3caepswac0k3 | 6ead757c ac |
+--------+----------------------------------------------------------------+------------------------------------+
| 3 | tb1qasxq9f4t9m9udu0ykm7g8t7qhrk32k75mxlg62cvr78a7208282qrhccmv | 6ead757c 6ead77 ac |
+--------+----------------------------------------------------------------+------------------------------------+
| 4 | tb1qkwv68xranw4hzs0vd2d4dqmgk5ktw6ezc2aeeggtlkp6mt7tj6es0hcndm | 6ead757c 6ead77 6ead757c ac |
+--------+----------------------------------------------------------------+------------------------------------+
| 5 | tb1qqjjya57d88tc8gzl8jhmmpzg5tg0lkydnvn6r65p2vewwk0y3etqd5hy5t | 6ead757c 6ead77 6ead757c 6ead77 ac |
+--------+----------------------------------------------------------------+------------------------------------+
| 6 | tb1q9430nrfs7w4k8y3kk9snvf5xn9hu2sg9773tnhhx4dpp08mlu60s33w8w3 | 6ead757c 6ead77 6ead757c 6ead77 |
| | | 6ead757c ac |
+--------+----------------------------------------------------------------+------------------------------------+
| 7 | tb1q9dhhr3vk42gz8q3fugyy5fkh4d9jr00t8yq2uus7jw4j78xgryfqjcz2gz | 6ead757c 6ead77 6ead757c 6ead77 |
| | | 6ead757c 6ead77 ac |
+--------+----------------------------------------------------------------+------------------------------------+
| 8 | tb1qd34ywwtlsu0gmqugfu6jqyk47ztrdtrjj483yn5sdhk3ewge89qq70dw5q | 6ead757c 6ead77 6ead757c 6ead77 |
| | | 6ead757c 6ead77 6ead757c ac |
+--------+----------------------------------------------------------------+------------------------------------+
| 9 | tb1quumhtnq5xafms4dwls582vspvqhwa5nzywmcsag7dk296g9kvkyq6gz6p8 | 6ead757c 6ead77 6ead757c 6ead77 |
| | | 6ead757c 6ead77 6ead757c 6ead77 ac |
+--------+----------------------------------------------------------------+------------------------------------+
| 10 | tb1qw7a6954v45jk3kawdx0m6z8ycjs0w9x3445hhva2hz8zpymgv00sqd8pew | 6ead757c 6ead77 6ead757c 6ead77 |
| | | 6ead757c 6ead77 6ead757c 6ead77 |
| | | 6ead757c ac |
+--------+----------------------------------------------------------------+------------------------------------+

And here is how it can be decoded for five sigops:

Code:

decodescript 6ead757c6ead776ead757c6ead77ac
{
"asm": "OP_2DUP OP_CHECKSIGVERIFY OP_DROP OP_SWAP OP_2DUP OP_CHECKSIGVERIFY OP_NIP OP_2DUP OP_CHECKSIGVERIFY OP_DROP OP_SWAP OP_2DUP OP_CHECKSIGVERIFY OP_NIP OP_CHECKSIG",
"desc": "raw(6ead757c6ead776ead757c6ead77ac)#8lv7zd9x",
"type": "nonstandard",
"p2sh": "2MyDk9pDzL17MXvFHydFdAEKNwFhauqza4z",
"segwit": {
"asm": "0 04a44ed3cd39d783a05f3cafbd8448a2d0ffd88d9b27a1ea815332e759e48e56",
"desc": "addr(tb1qqjjya57d88tc8gzl8jhmmpzg5tg0lkydnvn6r65p2vewwk0y3etqd5hy5t)#zrvc4p8m",
"hex": "002004a44ed3cd39d783a05f3cafbd8448a2d0ffd88d9b27a1ea815332e759e48e56",
"address": "tb1qqjjya57d88tc8gzl8jhmmpzg5tg0lkydnvn6r65p2vewwk0y3etqd5hy5t",
"type": "witness_v0_scripthash",
"p2sh-segwit": "2N7uvJnvanFT2L4jEAuanbhM9FbFaygTWvb"
}
}

Any witness stack push can take up to 520 bytes, which means, that the upper limit is something like 149 sigops. However, the shorter the chain, the cheaper it is, so I am trying to make it smaller, to not consume hundreds of sigops for a simple OP_CHECKSIGFROMSTACK.

Post

Topic

Board Development & Technical Discussion

Merits 2 from 1 user

Re: Bitcoin must upgrade or fall victim to quantum computing in 5 years

stwenhao

on 17/08/2025, 15:52:32 UTC

⭐ Merited by d5000 (2)

Quote

How fast can the Core Developers react IF an actual Quantum Computer is projected start breaking SHA-256 in one year?

If people will be in a hurry, then everyone can agree, that vulnerable coins should be timelocked for example for a few years, and in the meantime, the transition plan can be prepared. Which means, that even if unexpected things will happen, then still: freezing coins for a while, and giving developers more time, to prepare a proper transition, is something that can be done, in the worst case. And by seeing existing discussions, I doubt there will be no proposal: I'd rather expect a lot of different competing versions, and many discussions, related to activating BIP-X, BIP-Y, or BIP-Z.

Also, it is very unlikely, that everything will be broken at once, because different people use different keys, which means, that if breaking a single key takes for example a day, then still: it will take a whole year to break 365 keys. And also, even if keys can be broken instantly, in seconds, then still, the maximum block size can limit the damage, because nobody will be able to confirm more than 4 MB of data per 10 minutes, even if all private keys will be publicly known.

Quote

Time to implement is not really a concern.

Exactly. Many times, it took much longer to decide, how to activate a given BIP, than writing the actual implementation. And even in quantum scenarios, today's discussions are more focused on "how to activate things", rather than "which algorithm should be picked". Because for the latter, there are many options, and if people will be in a hurry, then they will just take their favourite signature scheme, and the one, who will be the fastest to make the Pull Request, will likely win. And the more time we have, the more quality can be put into picked solutions.

Quote

Why worry about such stuff today, you won't even be alive to see it?

Yes, for hash functions, we don't have preimages even for broken MD5 or SHA-1. And by seeing how SHA-1 was patched, I wouldn't worry too much about attacks on SHA-256, because this hash function is very similar, so can be hardened in the same way, based on discovered attacks (also, breaking ECDSA through SHA-256 requires preimages; even if ECDSA would use MD5 inside, you wouldn't break it, by having only collisions).

Post

Topic

Board Bitcoin Technical Support

Merits 4 from 3 users

Re: [Aug 2025]Mempool empty, Consolidate your small inputs @0.10 sat/vbyte (???)!

stwenhao

on 16/08/2025, 06:48:57 UTC

⭐ Merited by ABCbits (2) ,philipma1957 (1) ,Cricktor (1)

It is now merged into Bitcoin Core: https://github.com/bitcoin/bitcoin/pull/33106

Which means, that if you use the latest version from master, then it will be available by default. I guess other wallets will follow these changes, but it will take some time, and there will probably also be nodes, which will keep using 1 sat/vB anyway.

Post

Topic

Board Bitcoin Discussion

Merits 1 from 1 user

Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it

stwenhao

on 15/08/2025, 14:07:14 UTC

⭐ Merited by Cricktor (1)

Quote

Did the puzzle creator specify what "real solving" means?

No.

Quote

A grinding solver broadcasting a vulnerable transaction in the public doesn't own the coins until the transaction is actually confirmed. Am I wrong with this? I'd love to hear why, seriously!

Then, it is similar to this puzzle: https://bitcointalk.org/index.php?topic=293382.0

Quote

Exposing a vulnerable public key in public mempools opens the opportunity to use faster methods than brute-force grinding of the private key. If a real grinding solver ignores this, whoes fault is this, seriously?

Of course it is solver's fault. However, there are ways to do it in trustless way, they are just not used, because trusting centralized pools is sufficient in practice, at least for now. But it can be done differently, if needed.

Quote

What exactly is wrong or unethical or whatnot to use publicly available data to find a private key faster that allows you to sign a transaction to move coins that are "controlled" by such a vulnerable low entropy private key?

1. The puzzle creator can always sweep all coins, at any time. There are other puzzles, where it is not the case.
2. People have to trust, that private keys have N leading zero bits, and that someone really solved it, and the creator didn't sweep it just to raise some panic. If DLEQ proofs would be available, or other similar proofs, then everyone could validate it, without trusting anyone.
3. When it comes to hashed puzzles, there is a trustless way to prove, that N-bit hashed keys are no longer safe. It is currently done by using vanity addresses, but it could be potentially improved, by wrapping it into Script somehow (I don't know yet, how exactly, because this feature is not supported directly; but technically, it can be done).

Quote

How do we define "ownership" of coins?

By looking at the Script. There is nothing else. If someone can break ECDSA, then that person owns almost all coins, which have known public keys (almost, because it is possible to make a Script, where knowing the private key is not enough to move it).

Post

Topic

Board Development & Technical Discussion

Re: Proof of Work transaction puzzle, based on DER signature size

stwenhao

on 15/08/2025, 10:31:06 UTC

Some untested ideas for other Proof of Work scripts:

Code:

decodescript 82013d0146a569210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac
{
"asm": "OP_SIZE 61 70 OP_WITHIN OP_VERIFY 0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798 OP_CHECKSIG",
"desc": "raw(82013d0146a569210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac)#mes5v53f",
"type": "nonstandard",
"p2sh": "2Mw2fy8vwiyUKhVFrrD6VzXUahLTwr6P2nZ",
"segwit": {
"asm": "0 55582b7319de48ac18d654fba1400d417fa9249e3ba454fdb033b8937f5363d7",
"desc": "addr(tb1q24vzkucemey2cxxk2na6zsqdg9l6jfy78wj9fldsxwufxl6nv0tspelg8s)#5rzugfva",
"hex": "002055582b7319de48ac18d654fba1400d417fa9249e3ba454fdb033b8937f5363d7",
"address": "tb1q24vzkucemey2cxxk2na6zsqdg9l6jfy78wj9fldsxwufxl6nv0tspelg8s",
"type": "witness_v0_scripthash",
"p2sh-segwit": "2NEBNyCcTMriMw346rwgvQ7yxPHZ5PUQVUH"
}
}

Assuming standardness rules are enforced properly, and signatures should be minimal, or they are otherwise invalid, it should give an incentive to grind alternative points to half of the generator:

Code:

And also, some hash-based Proof of Work:

Code:

In this case, some message is hashed first, and then, the hash should form a valid DER signature, which means grinding something around 56 bits (maybe a bit less, because there are six valid sighashes, so it is more like 54-bit hash).

Code:

decodescript a67cac
{
"asm": "OP_RIPEMD160 OP_SWAP OP_CHECKSIG",
"desc": "raw(a67cac)#03cp3pdm",
"type": "nonstandard",
"p2sh": "2N56nsSzfvJTvdtXmfyRg8PiUDD9X4BrkFD",
"segwit": {
"asm": "0 f7eb8f18129e29c30baee3e7cf2fed3a3ca794d8db0e6049f681cf5ac925c417",
"desc": "addr(tb1q7l4c7xqjnc5uxzawu0nu7tld8g7209xcmv8xqj0ks8844jf9cstsz8ule9)#hltrrgm6",
"hex": "0020f7eb8f18129e29c30baee3e7cf2fed3a3ca794d8db0e6049f681cf5ac925c417",
"address": "tb1q7l4c7xqjnc5uxzawu0nu7tld8g7209xcmv8xqj0ks8844jf9cstsz8ule9",
"type": "witness_v0_scripthash",
"p2sh-segwit": "2MzT76E56RTHJVcjjMZG5dUe8XC56Dj5hdT"
}
}

Post

Topic

Board Development & Technical Discussion

Merits 2 from 2 users

Re: Tools for creating testing Bitcoin chains?

stwenhao

on 15/08/2025, 03:54:08 UTC

⭐ Merited by ABCbits (1) ,vapourminer (1)

https://en.bitcoin.it/wiki/Signet

Post

Topic

Board Development & Technical Discussion

Re: [Draft BIP] Quantum-Resistant Transition Framework for Bitcoin

stwenhao

on 14/08/2025, 04:16:26 UTC

Quote

doesn't make much sense to use quantum-resistant hashing along with ECDSA

Why not?

1. As long as ECDSA is safe, it will work, and will take small amount of on-chain bytes.
2. When it will be unsafe, then spending only by ECDSA can be blocked, in exactly the same way, as spending only by key in P2TR can be.
3. If some quantum proposal will be broken classically, it will be possible to downgrade it, and old nodes will still understand it.
4. It is strictly connected with sigops limit, so you can handle the same number of signature checking operations, as old nodes did.

Quote

we can completely ignore old nodes and simply "kick them off" from the network

Sure, but it shouldn't be your starting point, but rather your end goal. First, things should be optional, because if they will be mandatory from the start, then it will be quickly turned into hard-fork, and will end in the same way as BCH, and other forks. So, the first thing to do, is to get a compatible client, which will work on the same chain, as existing clients. And because they cannot understand bigger blocks than 4 MB, then new signatures should be somehow attached to the existing ones. And it is much easier to attach them through R-value, than through additional OP_RETURN, because then, it takes less on-chain bytes, and can provide the same security (if someone can fake R-value, then that person can fake OP_RETURN entry as well).

Post

Topic

Board Development & Technical Discussion

Re: [Draft BIP] Quantum-Resistant Transition Framework for Bitcoin

stwenhao

on 13/08/2025, 17:57:46 UTC

Quote

I don't understand how ECDSA and the R-values comes here into play.

In the same way, as quantum-resistant signatures can be hidden behind P2TR.

https://gnusha.org/pi/bitcoindev/ZVcdKupXU+wjawRI@erisian.com.au/

Quote

Code:

In general, if you have ECDSA signature, then you have some public key Q, and signature (R,s), which can connect public key R with public key Q. If ECDSA is broken, then still: "data" behind a given commitment will still be possible to verify. Knowing private key won't invalidate old signatures: if some hash was confirmed on-chain, and hidden behind R-value of some signature, then it will be still possible to verify later.

Quote

I think "block size" need to be increased to accommodate larger signatures.

Old nodes won't understand it anyway. Which means, that only quantum resistant nodes will see it. And for that reason, ECDSA verification can be just extended: first, ECDSA signature will be checked normally, and after that, quantum data can be hashed, and checked, if it matches R-value of a given signature. And then, new limit don't have to be based on block size, but on commitment size instead, and based on existing sigops limit.

Post

Topic

Board Development & Technical Discussion

Re: [Draft BIP] Quantum-Resistant Transition Framework for Bitcoin

stwenhao

on 13/08/2025, 17:01:16 UTC

Quote

Can you explain this in details? How you make 50 byte from 50 KB?

And how you make 4 MB out of 1 MB? You have 32 bytes for Segwit commitment in the coinbase transaction, and this is all you need, to go from 1 MB legacy space to 4 MB witness space. Here, it is similar: you have 32 bytes for R-value of ECDSA signature, and you can store everything behind it, including a quantum resistant 50 kB signature, for each and every R-value you currently have, when OP_CHECKSIG or its equivalent is called in the Script.

Of course, all old nodes won't notice block size increase, in the same way, as non-Segwit nodes still think, that the maximum block size is 1 MB.

Post

Topic

Board Development & Technical Discussion

Merits 1 from 1 user

Re: Bitcoin must upgrade or fall victim to quantum computing in 5 years

stwenhao

on 13/08/2025, 12:56:17 UTC

⭐ Merited by ABCbits (1)

Quote

Do you think that an average person will have access to quantum computer?

No. Or: at least not at the beginning.

Quote

By the way, how does quantum computer beat a good 2FA and a password.

It doesn't, because 2FA uses hash functions, and not public key cryptography. More than that: you can use three hash functions inside Script: OP_SHA1, OP_RIPEMD160, and OP_SHA256. And also, it is possible to add more restrictions, by using OP_CHECKLOCKTIMEVERIFY or OP_CHECKSEQUENCEVERIFY. Which means, that even if the whole public key cryptography will be broken, then still, the system can be safely used by miners, as long as block reorganizations won't be too deep. And again: users can lock their coins with Proof of Work, if needed.

Quote

Am I saying nonsense or does it actually make a sense?

Currently, it is very difficult to break many hash functions, when it comes to their preimage resistance. Even if you use MD5, and you can generate collisions in seconds on a CPU, then nobody still knows, how to make MD5 preimages fast. And to successfully break ECDSA through SHA-256, preimage attack is needed.

When it comes to quantum algorithms, they can break things based on public key cryptography. But they are very far from breaking any hash functions, and it is quite likely, that they won't beat existing ASICs, when it comes to mining, and grinding double SHA-256 hashes.

Post

Topic

Board Development & Technical Discussion

Merits 1 from 1 user

Re: [Draft BIP] Quantum-Resistant Transition Framework for Bitcoin

stwenhao

on 11/08/2025, 10:14:26 UTC

⭐ Merited by ABCbits (1)

Quote

Although the fact there are blocks that contain QC-resistant signature means some mining pool support the upgrade.

They don't have to get support from existing miners, focused on mining 80-byte block headers. They can do that behind Proof of Work on DER signatures, so legacy nodes will check only the size of the signature, and nothing else. And all other rules can be executed only by quantum nodes, and nobody else. If their miners will produce more Proof of Work, that any attacker will do in 10 minutes, then they will get it confirmed on-chain faster, than it will be attacked by anyone. And if their quantum proofs will be good enough, then nobody will even discover a public key behind the puzzle, before it will be broadcasted on-chain. It can be unknown for all participants, even behind quantum nodes, if done correctly, and Proof of Work can protect them from short exposure attacks, as long as ECDSA is still strong (and even later, SHA-256 will still protect them, even if ECDSA will be broken, just Proof of Work will raise accordingly).

Quote

It's not fully true though, since non-SegWit node still store TX created by Ordinal without witness data.

Yes, there is some data, related to a particular address. But: seeing OP_TRUE, and some 32-byte data push for Taproot address, is not that much. And similar things can be done here: a small signature on-chain, which would take for example 50 bytes, is a small price to pay for committing to some 50 kB signature, which would be visible only by upgraded nodes, and which can be ignored by anyone else.

Post

Topic

Board Development & Technical Discussion

Merits 2 from 1 user

Re: [Draft BIP] Quantum-Resistant Transition Framework for Bitcoin

stwenhao

on 11/08/2025, 09:33:05 UTC

⭐ Merited by vapourminer (2)

Quote

No, it would open gateway to massively bloat Bitcoin blockchain at relative low cost.

And that cost will be paid only by upgraded nodes, so they can do that, if they want to. The rest of the users will still enjoy 4 MB limit. And then, if it will turn out, that all quantum FUD was unjustified, and there is no danger, then these new nodes will have their own bloated version, which they voluntarily picked, so they can leave legacy traffic unaffected.

Quote

Ordinals hype in past have proven this.

Only Segwit nodes are affected by Ordinals. Old, legacy nodes, see smaller blocks in practice, when witness space is fully filled. And the same will happen, if Ordinals will move their data into quantum signatures: we will see smaller than 4 MB blocks in witness space, which is good.

Quote

There are other technical issue such as time to verify and propagate block with such massive size.

It is possible to use more than one layer of verification. Currently, there are at least two: one is legacy data verification, and another is witness data verification. If we would have a third layer of quantum commitments, then Segwit nodes will be unaffected, and process only ECDSA signatures, without checking, what is behind R-value of each and every signature.

So, to sum up: if quantum enthusiasts want to have enormously huge blocks, then it is their choice. If they raise it by too much, then only their nodes will suffer, so we shouldn't stop them from shooting themselves in their feet. And if one quantum proposal with big signatures will lose competition with another quantum proposal with smaller signatures, then again, it is their choice, if they want to consume more space, or if they want to spend more time on verifying smaller signatures. They should compete with each other, so that Segwit users will be unaffected, and they will pick the final winner, if we will see, who did it in the best way.

Post

Topic

Board Polski

Topic OP

Puzzle wymagające Proof of Work, oparte o rozmiar sygnatury DER

stwenhao

on 11/08/2025, 08:02:49 UTC

Oryginalny temat: Proof of Work transaction puzzle, based on DER signature size

Myślę, że OP_SHA256 OP_CHECKSIG jest zbyt prostym skryptem, jeśli chodzi o komputery kwantowe. Jeśli ktoś przesunie takie środki w ten sposób, to dowiemy się, że klasyczne algorytmy ECDSA zostały złamane, ale nie dowiemy się, jak blisko tego momentu jesteśmy. Z tego powodu przygotowałem coś, co pozwoli na uzyskanie stopniowej informacji zwrotnej:

Code:

+--------+----------------------------------------------------------------+----------------------------------------------------------------------------------+
| Liczba | Adres | Script |
+--------+----------------------------------------------------------------+----------------------------------------------------------------------------------+
| 60 | bc1qzsjnew5qcn75e4cqdsc6r9v8fjy5ensancqmv2l2n82p0q5f5tlsfu3slz | 82013c9f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
+--------+----------------------------------------------------------------+----------------------------------------------------------------------------------+
| 59 | bc1qk3endeq6x0xj4pjt4zwag8wf3a629rzqr8jxd7jnmlac902wa5yshwd25y | 82013b9f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
| 58 | bc1q22jvaveydlwxczfvgmsj8rguuk5x7j5xta78ztstnpckt0ajzevqggqgpd | 82013a9f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
| 57 | bc1qsckg4lg74jyvjnzn4vnfu6e232gsq4drhl6e8qdze6j86c7htxgqu2gfum | 8201399f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
| 56 | bc1qqe4wgykwnk2x0rgvc0qlvplcv7l2kjjcfpsmkmtedelzx0p9zkssvcsvl4 | 8201389f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
| 55 | bc1qxnlp3emwhluxa3sr85s8xw49mgfzx45dsh0thn5vhpjhk36d6v7str4tjt | 8201379f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
+--------+----------------------------------------------------------------+----------------------------------------------------------------------------------+
| 54 | bc1qts0jh2d2nesmketmw3thedwrx939k2tqu04gy90x9hd4049g4uhs83ltjx | 8201369f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
| 53 | bc1qn9vp8l5rs7huyl237s4q9lhrzcs0mzaajt528ysq3wgnzvlkay5sdfz6am | 8201359f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
| 52 | bc1qcuawvnrfa2lleaf5u5qyxk7d34xn0m0kakqt7k3wac4700vxzg9q06p65d | 8201349f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
| 51 | bc1q2hr46qhfdum4zpvnx3rvupsk0canzuxd9gtslzx58lexly6n20xs63sszw | 8201339f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
| 50 | bc1qndpzf7522jtn7mfstwjqcn55rrlqxpzmqadyv3h4mgtk2m23xhtq2ae05f | 8201329f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
+--------+----------------------------------------------------------------+----------------------------------------------------------------------------------+
| 49 | bc1qn09x79u0vfzwlygk90zj0wtwuvvaw6nzlky3atp8lwqhshvswl0qzdn94s | 8201319f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
| 48 | bc1qd3fff42rjrsj97pkt0jqt9gd7qr9yc3yuphemmxus0023jgclppsyklcns | 8201309f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
| 47 | bc1qs4z4dg07f6r4w46g5j5lj5en65tafszdg7mfxk5n4wfuglzyzjas6yl326 | 82012f9f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
| 46 | bc1qlskhz869r6ea7e7yvhnnx0lcgf7ylqkvkgu5ks7h48kht9t5fk8sq2anky | 82012e9f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
| 45 | bc1qaea8zwfp8cm3hffuj29de6hzy6kuar4xz7cvykzff6rdg474d37sjr8ea5 | 82012d9f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
+--------+----------------------------------------------------------------+----------------------------------------------------------------------------------+
| 44 | bc1q5f3sv9p2urcu90c22ewv6jg6g4jspzvfu78svxjprjhtddn5tylsglq5q2 | 82012c9f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
| 43 | bc1quct724atm82ssvd0273v3mwzu84tnevtt8magv4qywqx98t9cdaq8k8uv6 | 82012b9f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
| 42 | bc1qcj7mnlddf0fagvwsxk8gzvu9ae6a02ktjwkm5u6a6kv7z07v8d0q64ac0v | 82012a9f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
| 41 | bc1qpqzzh9lt29z6p559d3ajh6qsg0m2s47fc9nty3s8yk8kjq9fcm5qa87v82 | 8201299f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
| 40 | bc1qc6zv4w8g3dqqmkrm9gan46837gnvzw6nhccrxqleuywpghpjxvpsqzmksu | 8201289f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
+--------+----------------------------------------------------------------+----------------------------------------------------------------------------------+
| 39 | bc1qh48gekh2u5qh825tnsql3l3qg350672p8ms5apgqjfuyy8z766fsqt8pwm | 8201279f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
| 38 | bc1qrhssslwre409nny7lk49z8hf56tzpywuwq0ykt4qqg9plnhk3n9sgs54jr | 8201269f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
| 37 | bc1qvsstwz7q5nc2l5gfy46ecrq4gly7fdutl3v6mneaesrl4q42p5aqs79sxd | 8201259f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
| 36 | bc1q5nnrkrwpunlrt37hdc09slw6x8tmtefgkcf3rvfj8tmlj3knydqs642y54 | 8201249f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
| 35 | bc1q5y3zsqws75klm272qjv7tw723k0pkq4amz7s9277vt7vx0tqe4vqr2h75a | 8201239f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
+--------+----------------------------------------------------------------+----------------------------------------------------------------------------------+
| 34 | bc1q8qqtmlxnhxkhlud29ulckef8zqntupn2yfukrqsuts9yksefxagqqnxfmt | 8201229f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
| 33 | bc1qxnv03h6x787qmplzj9l36st3tlsj0vcmhvzxa848zhqxwcd6ev5sk2a275 | 8201219f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
| 32 | bc1qm2w0cm93vuwzdj4s9j4r2h760pkcz5fh6mrvyuem9rdgv65v2a5sw8hw6g | 8201209f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
| 31 | bc1qq2f268tl7294y6mwggpxxlpkzhwgeflwu6xkyayvp49tfy8xjsaqmmrkmv | 82011f9f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
| 30 | bc1q84chz6u2ayuvkkvjz68myuj4edjajctpl0sja9uw7hjq22przm2srnwcgc | 82011e9f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
+--------+----------------------------------------------------------------+----------------------------------------------------------------------------------+
| 29 | bc1qmh7307pkmdxdmd663pt2sukxpl2r44ck7ctj9fp2n2t4ddm695cqth6pla | 82011d9f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
| 28 | bc1qzd6pdkrhyw9nvmm7qf40323ktsdut7tk9d9mjhc0m7x3g29x98tsvgtdn9 | 82011c9f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
| 27 | bc1qq357t0u28ppmn6jz2j2fsmw56aydfxyygdlxs6xl5g748lnt6j4swtqfe6 | 82011b9f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
| 26 | bc1qdwrwvl6rsxdscsg0vu3v6kryvynrzxlqu8f6m5z5sgccxdxfj96qe5ws8f | 82011a9f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
| 25 | bc1qunjltqwtzw2c2lretp638tkxwxp88h33tt4kl9efzaklttjlg3gqw6wcke | 8201199f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
+--------+----------------------------------------------------------------+----------------------------------------------------------------------------------+
| 24 | bc1ql6mlplvx8aqwytl9a7esxaaxqdzdehkxg2pv494ga9dajtw0uxgs6ax9t7 | 8201189f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
| 23 | bc1qs4kcykg0mu35axecxl33e2aem04p0he98madx22dxysuwugpryqsdgs94u | 8201179f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
| 22 | bc1qtlnrv6xm7wk22sphlmwtv53r2pw4q4gztq4z0u8n6w8hvdmxulrs693x83 | 8201169f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
| 21 | bc1qwhnww50d0h5c3exftpsqpyt7lgtzaala46rztf6n8eche2qz8vnqrnavst | 8201159f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
| 20 | bc1qwlamdvj56rkzgcdlycp902dw4m5cny8ajthkd3vdt98v7v99k08s27pmya | 8201149f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
+--------+----------------------------------------------------------------+----------------------------------------------------------------------------------+
| 19 | bc1qkxuzs6e8n5rv292xsqgvus35ul39kec2d20wwhqgwv7a69v7tpjq72clg4 | 8201139f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
| 18 | bc1qak0qjcx0fq593l4j05rt6jl5qg5xp0ecvd4avfn6meda6yamqhkq63uz4e | 8201129f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
| 17 | bc1q00ztwmcdh405ykw8qx0w6a9c8cxgu7j2ksavss0nca73x5eehdzsnkstf6 | 8201119f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
| 16 | bc1q9ndnp3pkzejhswjjvcr0trzs78r4sg69cfr6yvqemzyd6wnusezs9y9hjm | 82609f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
| 15 | bc1qtnwqzgrwe59md6hpury7tjeu0c5g2kq0y3cws5qgghz2398v44kqdcv5p0 | 825f9f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
+--------+----------------------------------------------------------------+----------------------------------------------------------------------------------+
| 14 | bc1qj5wmccmayunu3tylyemjfnj4fhr9lg0zqc3t7kr5r0qd0p0vxk3stk8plt | 825e9f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
| 13 | bc1qqzxea5twr35sv0wcpmvnqtxwxnq0t6qpfzewry4u5zjsmzrqefvqkjx7c6 | 825d9f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
| 12 | bc1q2wk3xlj3agqnsc60px0d9h8x24l2ell383agp9zvn5s89afut70qa3lskk | 825c9f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
| 11 | bc1qfcy96sdnu2yed6k02x84q09a3cs5lr57j6la7auc27e2u5cu6xyqw9upas | 825b9f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
| 10 | bc1qss67lljllhph4wnmzn7f8qpc3wh6q48hlpfpznt9sz2lntw963nssn6kzm | 825a9f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac |
+--------+----------------------------------------------------------------+----------------------------------------------------------------------------------+

Jak już wcześniej napisałem w sieci testnet4: Warto pamiętać o minimalnym zakodowaniu CScriptNum, kiedy używasz Proof of Work!

Puzzle zaczynają się od 60, ponieważ w tym przypadku, wykopanie pojedynczego bajtu jest wszystkim, czego potrzeba, aby przesunąć te monety i można to łatwo zrobić na CPU. Potem, całość staje się coraz trudniejsza. Na początku, ludzie będą zapewne wykopywać tylko coraz mniejsze hashe SHA-256, ale po dojściu do pewnego momentu, wykopywanie niskich wartości x-value w kluczach publicznych secp256k1 będzie coraz bardziej opłacalne, gdy okaże się, że połowa generatora jest już niewystarczająca. Puzzle kończą się na 10, ponieważ 9-bajtowa sygnatura jest najmniejszą z możliwych, gdy r-value i s-value ma dokładnie jeden bajt. W przypadku osiągnięcia najmniejszej możliwej sygnatury, OP_CHECKSIG będzie całkowicie złamany jako opkod i wówczas może być używany jako taki 256-bitowy kalkulator, jeśli ktoś to osiągnie bez odzyskiwania klucza publicznego z sygnatury, w normalnych warunkach, gdzie klucz publiczny jest z góry ustalony w skrypcie wyjściowym i nie może być zmieniany przez kogoś, kto przesuwa te monety.

Warto pamiętać o tym, że jeśli ktokolwiek chce dołożyć się do nagrody, to każda moneta wymaga osobnego wykopania. Oznacza to tyle, że jeśli mamy jedną monetę, na której jest 10 tysięcy satoshi, to łatwiej to zgarnąć, niż 10 monet, gdzie każda ma tysiąc satoshi, ponieważ nawet gdy klucz prywatny jest znany i równy jeden, to nie będę w stanie pozbierać drobnicy i zakumulować je w większe nominały, bez samodzielnego rozwiązania zagadki. Przykład, który pokazuje, jak poprawnie dołożyć więcej monet, bez utrudniania zagadki, jest w dalszej części tematu oraz w transakcji 8349df0753e80cce322322f1b76789e1d0fd6693aed2f4de4e49576423081ae7.

Myślę, że najbardziej sensowne jest dokładanie się do najbliższego nierozwiązanego adresu, a następnie przełączanie się na kolejne, gdy ktoś to rozwiąże. Jeśli wszystkie monety będą zawsze zgarniane, to cały postęp może być łatwo śledzony z transakcji początkowej aba3c2ae442aa20150996ee68f9aa4da83b57a4312891078be0c2e68c50b2801.

Komenda "decodescript" w Bitcoin Core pozwala na uzyskanie wszelkich szczegółów, które są potrzebne do rozwiązania zagadki. Na przykład przy pierwszym adresie wygląda to następująco:

Code:

decodescript 82013c9f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac
{
"asm": "OP_SIZE 60 OP_LESSTHAN OP_VERIFY 0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798 OP_CHECKSIG",
"desc": "raw(82013c9f69210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac)#y8swm8mh",
"type": "nonstandard",
"p2sh": "3FarrwpVXsTxdscrDhZ97WVgu4jknxsPgc",
"segwit": {
"asm": "0 14253cba80c4fd4cd7006c31a195874c894cce1d9e01b62bea99d4178289a2ff",
"desc": "addr(bc1qzsjnew5qcn75e4cqdsc6r9v8fjy5ensancqmv2l2n82p0q5f5tlsfu3slz)#lnwxtrcf",
"hex": "002014253cba80c4fd4cd7006c31a195874c894cce1d9e01b62bea99d4178289a2ff",
"address": "bc1qzsjnew5qcn75e4cqdsc6r9v8fjy5ensancqmv2l2n82p0q5f5tlsfu3slz",
"type": "witness_v0_scripthash",
"p2sh-segwit": "3Hmzt3jtw9grgoCFM6RpzWrkEVEj7iz1FM"
}
}

Powodzenia!

Post

Topic

Board Development & Technical Discussion

Re: Bitcoin must upgrade or fall victim to quantum computing in 5 years

stwenhao

on 11/08/2025, 06:54:32 UTC

Quote

Let's pretend that a Quantum Computer that could break the encryption and steal Satoshi's coins is close to being built - in one year let's say, how long can the Core Developers code a patch and have it merged?

The simplest patch can be coded quite quickly. All old coins can be timelocked by consensus, up to a given block number. And then, a future soft-fork can decide, how these coins should be unlocked, by meeting old ECDSA conditions, and any new conditions, introduced by the next soft-fork.

Quote

It would probably fair to say that we are not ready?

Ready for what? There is a difference between bug like Value Overflow Incident, bug like SIGHASH_SINGLE, a weakness in ECDSA, which would allow getting private key after 2^80 operations, another weakness, which would allow going from any public to any private key instantly, a weakness in SHA-256, which would allow collisions, a weakness which would allow preimages, and so on, and so forth. For which attack do you want to be prepared? There is no tool, which can protect you from everything. Depending on a particular attack, it can be trivial to fix it, or impossible.

Quote

what should actually be assumed is every participant/entity should be acting according to their own incentives

Of course. But you don't have attacks, which breaks everything at once, and you don't have protections, which fixes all bugs at once. There are always particular attacks, and particular fixes. If you think, that SHA-256 is weak, then prove it, by claiming some of the puzzles (not necessarily created by me, because there are many others). If you believe, that there is not enough reward in existing puzzles, then put more coins in. And if you think, that existing scripts cannot measure the progress correctly, then make a better puzzle. A Script can do a lot of things, and even if it cannot, then still, you can write a version, where new feature is activated, and convince people, that a given soft-fork is needed. Or: you can make a sidechain, which can have any rules, and peg it into Bitcoin. And also, you can make LN nodes, which will execute existing rules, and also some new ones, which would be available only in L2, only between selected clients.

Post

Topic

Board Development & Technical Discussion

Re: [Draft BIP] Quantum-Resistant Transition Framework for Bitcoin

stwenhao

on 11/08/2025, 05:23:27 UTC

Quote

Yes, let's create a second Bitcoin SV with 2 GB (or 275 MB, doesn't matter) blocks, but with quantum safe signatures ...

Fortunately, the maximum block size for legacy nodes is 1 MB, and for Segwit nodes is 4 MB. If someone wants bigger blocks than 4 MB, then by running the current version, you simply won't see their data. And in general, I think no matter if block size will be bigger or smaller than today, quantum signatures should not be processed by existing nodes, because they don't know, how to handle it (and different quantum proposals may have different needs). Unless you know, how to re-write any quantum signature as a bunch of OP_CHECKSIG operations, along with other Script opcodes, then it could be visible by non-quantum nodes.

Also, I guess if OP_CHECKSIG will be really broken, then it could be possible to activate quantum signatures on top of OP_CHECKSIG directly. Because then, if quantum signatures use some 256-bit numbers internally, then OP_CHECKSIG can be used as their 256-bit calculator, and then, any public keys could be used anywhere, because going from public to private key can be just part of the process. Because even in Shor's algorithm, going from public to private key doesn't have zero cost: even if it is solvable, then it still require N quantum operations. Which means, that by creating dependencies between public keys and signatures, it can be made much harder, than just "<pubkey> OP_CHECKSIG".

Post

Topic

Board Development & Technical Discussion

Merits 4 from 3 users

Re: [Draft BIP] Quantum-Resistant Transition Framework for Bitcoin

stwenhao

on 10/08/2025, 17:21:04 UTC

⭐ Merited by Mia Chloe (2) ,NotFuzzyWarm (1) ,vapourminer (1)

Quote

I don't see why it cannot be increased to the extreme, let's say to 2100000000 bytes (2.1 GB).

It could be. But: non-upgraded nodes should not process all of that data. And, you don't have to increase maximum block size specifically. Instead, quantum commitment size can be restricted.

For example: if quantum signatures will take 50 kB per signature, then let's make it as a commitment limit per sigop. Then, for a block sigops limit of 80k, we would have 4 GB limit per block. And if there would be any need to do a downgrade, then coins could be moved in a way, which would be understood by old nodes.

In this case, each and every OP_CHECKSIG call will check two things: one, which is ECDSA correctness, and another one, which is quantum proof correctness. Then, private keys can stay as they are, and R-value of a given ECDSA signature can contain SHA-256 commitment to any quantum signature, which would be handled only by quantum enthusiasts, while everyone else could enjoy 4 MB limit, and see just regular ECDSA signatures.

If hashrate majority will run quantum-resistant version, then the block size limit would be just 80k sigops * max quantum signature size. And then, for different quantum proposals, that limit can be different, while keeping the same sigops limit per block, so handling roughly the same number of individual on-chain users per block.

Post

Topic

Board Bitcoin Discussion

Re: Bitcoin puzzle transaction ~32 BTC prize to who solves it

stwenhao

on 10/08/2025, 16:47:29 UTC

Quote

YMMV, I'm genuinely interested how others see it. Please, try to explain if your opinion differs. I might be wrong with my own opinion and if so, I'd like to learn why!

I think it is technically possible to prove, that you are the real solver. Which means, that everyone would know, if coins were stolen or not. Solvers just don't use such proofs, but it can be done.

First, any solver can deposit any coins into its own, strong key, and a proof of being the one, who solved the puzzle. The output Script is:

Code:

<strongPubkey> OP_CHECKSIGVERIFY OP_RIPEMD160 <puzzleHash> OP_EQUAL

Then, the solver can wrap it behind P2WSH, and wait for getting enough confirmations. After a while, a solver can move the coins from this Script, to the desired destination of the puzzle. It can even be done in the same transaction, which would sweep the puzzle, if desired.

And then, it won't prevent coins from being stolen, but it would prove to the outside world, if they were stolen or not.

Another thing is proving knowledge of some public key with ZK-proofs, DLEQ proofs, or something similar. It can be done, and it could be battle-tested on puzzles, before introducing any "quantum-resistant" things globally.