I think I know, how to make testnets really worthless. One part of the solution is to know upfront, when the network is resetted. Another thing is to switch automatically to the new testnet, in coordinated way.

In existing testnet4, the Genesis Block commits to the mainnet block: https://mempool.space/testnet4/tx/7aa0a7ae1e223414cb807e40cd57e667b718e42aaf9306db9102fe28912b7b4e

Code:

decoderawtransaction 01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff5504ffff001d01044c4c30332f4d61792f323032342030303030303030303030303030303030303030303165626435386332343439373062336161396437383362623030313031316662653865613865393865303065ffffffff0100f2052a010000002321000000000000000000000000000000000000000000000000000000000000000000ac00000000
{
  "txid": "7aa0a7ae1e223414cb807e40cd57e667b718e42aaf9306db9102fe28912b7b4e",
  "hash": "7aa0a7ae1e223414cb807e40cd57e667b718e42aaf9306db9102fe28912b7b4e",
  "version": 1,
  "size": 180,
  "vsize": 180,
  "weight": 720,
  "locktime": 0,
  "vin": [
    {
      "coinbase": "04ffff001d01044c4c30332f4d61792f323032342030303030303030303030303030303030303030303165626435386332343439373062336161396437383362623030313031316662653865613865393865303065",
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 50.00000000,
      "n": 0,
      "scriptPubKey": {
        "asm": "000000000000000000000000000000000000000000000000000000000000000000 OP_CHECKSIG",
        "desc": "raw(21000000000000000000000000000000000000000000000000000000000000000000ac)#8erpcjk9",
        "hex": "21000000000000000000000000000000000000000000000000000000000000000000ac",
        "type": "nonstandard"
      }
    }
  ]
}

As we can see, there is fake public key of all zeroes, and there is some coinbase message, which we can also decode:

Code:

decodescript 04ffff001d01044c4c30332f4d61792f323032342030303030303030303030303030303030303030303165626435386332343439373062336161396437383362623030313031316662653865613865393865303065
{
  "asm": "486604799 4 30332f4d61792f323032342030303030303030303030303030303030303030303165626435386332343439373062336161396437383362623030313031316662653865613865393865303065",
  "desc": "raw(04ffff001d01044c4c30332f4d61792f323032342030303030303030303030303030303030303030303165626435386332343439373062336161396437383362623030313031316662653865613865393865303065)#u9zu8nez",
  "type": "nonstandard",
  "p2sh": "2NBfjyEvWaq5ar91xXJde49BnBPbjf545Tx",
  "segwit": {
    "asm": "0 83b15293cafb892b817401f398f41ad1c80886d24068a577165159ea0f6be439",
    "desc": "addr(tb1qswc49y72lwyjhqt5q8ee3aq668yq3pkjgp522ack29v75rmtusus8k978f)#9sg0m0fj",
    "hex": "002083b15293cafb892b817401f398f41ad1c80886d24068a577165159ea0f6be439",
    "address": "tb1qswc49y72lwyjhqt5q8ee3aq668yq3pkjgp522ack29v75rmtusus8k978f",
    "type": "witness_v0_scripthash",
    "p2sh-segwit": "2N3rvjZzX9cZLTsEnezmj3ZJpuwLfJ4PQdT"
  }
}

And then, we have the message:

Code:

03/May/2024 000000000000000000001ebd58c244970b3aa9d783bb001011fbe8ea8e98e00e

It simply contains the timestamp, and the mainnet block 842000 hash: https://mempool.space/block/000000000000000000001ebd58c244970b3aa9d783bb001011fbe8ea8e98e00e

However, the mainnet block does not contain any information about testnet, it is only used as a timestamp. In theory, new testnets could be resetted every mainnet block, then they would be completely worthless, because 10 minutes after testnet842000, there will be testnet842001, and nobody would buy coins, which would be discarded after 10 minutes.

Some people believe, that resetting testnet that often will discourage any kind of "long-term testing". For that reason, I thought about something different: what about using Merged Mining to produce testnet chain? Then, testnet could be resetted every time, when someone will mine a block, which would be valid for both testnet and mainnet. It would timestamp the new testnet, and at the same time, discard the old one.

Most of the time, testnet miners will produce weaker blocks, and they could just broadcast "shares" in a form of valid testnet blocks, where they could contain some valid hash of the mainnet block, and also some commitment to the testnet data, so it could be verified by everyone, without taking more on-chain bytes, than it would, if someone would produce only mainnet blocks.

Instead people should be calling on and contributing to bitcoin core so that solo mining is a first class supported feature, with good stats so you know its working and can feel excited about it.  There is nothing wrong with things like 'solo pools' existing, and I suppose they'd also make good fallbacks for people's local nodes.... but they're not the gold standard the community should be promoting.

I agree. For that reason, now I have fully synchronized mainnet node, and I installed ckpool software on top of it, to start experimenting with it, and changing the code. I think it should be possible to make a testnet out of it, where nodes would trace the main chain, produce valid shares, with lower difficulty (that could be calculated automatically, based on how many shares are sent to the test network, so it could auto-adjust), and where the whole chain could be resetted every sometimes, when some test miner will reset the chain, get the mainnet block reward, and start the whole testing from scratch.

When I look at testnet chainworks, then I think miners could get a lot of mainnet coins out of it. And all of that potential is wasted, to mine worthless test coins, instead of contributing to the mainchain security. And I think it should be changed. Also, "good stats so you know its working and can feel excited about it" could be just expressed in a number of test coins, that people would receive, so they would know, how close we are to the next testnet reset. But nobody would know for sure, because it is just a probability, and not a certainty.

What do you think about it?

There are many quantum proposals. Some are better, some are worse, but when it comes to deployed things, there is a lot of silence. To change it, I tried to deploy one of competing proposals, in a no-fork way. And it seems that Hourglass can be used right away, without any consensus changes, as long as it will be left optional, and users will voluntarily join, by moving their coins to specific P2WSH scripts.

Here is the optional Hourglass envelope:

Code:

Input: <signature> <pubkey>
Output: OP_SWAP OP_SIZE OP_DUP OP_ADD OP_DUP OP_ADD OP_CHECKSEQUENCEVERIFY OP_DROP OP_SWAP OP_CODESEPARATOR OP_DUP OP_HASH160 <pubkeyHash> OP_EQUALVERIFY OP_CHECKSIG

Execution:

<signature> <pubkey>
<pubkey> <signature>
<pubkey> <signature> <sigSize>
<pubkey> <signature> <sigSize> <sigSize>
<pubkey> <signature> <sigSize*2>
<pubkey> <signature> <sigSize*2> <sigSize*2>
<pubkey> <signature> <sigSize*4>
<pubkey> <signature> <sigSize*4>
<pubkey> <signature>
<signature> <pubkey>
<signature> <pubkey>
<signature> <pubkey> <pubkey>
<signature> <pubkey> <pubkeyHash>
<signature> <pubkey> <pubkeyHash> <pubkeyHash>
<signature> <pubkey>
OP_TRUE

To make it, all that is needed, is to take existing P2WPKH address, where coins are sent to 160-bit hash of the public key, and wrap it into the Script above. For example, if the private key is equal to one, and the public key is equal to the generator, then it can look like that:

Code:

decodescript 210279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798ac
{
  "asm": "0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798 OP_CHECKSIG",
  "desc": "pk(0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798)#gn28ywm7",
  "type": "pubkey",
  "p2sh": "2MvVwHhgE2JyjkjQk72CghrhrJsanKfHfqe",
  "segwit": {
    "asm": "0 751e76e8199196d454941c45d1b3a323f1433bd6",
    "desc": "addr(tb1qw508d6qejxtdg4y5r3zarvary0c5xw7kxpjzsx)#0wnhlaqf",
    "hex": "0014751e76e8199196d454941c45d1b3a323f1433bd6",
    "address": "tb1qw508d6qejxtdg4y5r3zarvary0c5xw7kxpjzsx",
    "type": "witness_v0_keyhash",
    "p2sh-segwit": "2NAUYAHhujozruyzpsFRP63mbrdaU5wnEpN"
  }
}
decodescript 7c8276937693b2757cab76a914751e76e8199196d454941c45d1b3a323f1433bd688ac
{
  "asm": "OP_SWAP OP_SIZE OP_DUP OP_ADD OP_DUP OP_ADD OP_CHECKSEQUENCEVERIFY OP_DROP OP_SWAP OP_CODESEPARATOR OP_DUP OP_HASH160 751e76e8199196d454941c45d1b3a323f1433bd6 OP_EQUALVERIFY OP_CHECKSIG",
  "desc": "raw(7c8276937693b2757cab76a914751e76e8199196d454941c45d1b3a323f1433bd688ac)#9hnlfmtv",
  "type": "nonstandard",
  "p2sh": "2Mzw53ZN8wS8FXvNpMFkGjfP3i3hCTAhcbV",
  "segwit": {
    "asm": "0 3062edde70aad88f218ed97aa51f6003baeb94c4c4d876d86ddf8dce6f5d4c06",
    "desc": "addr(tb1qxp3wmhns4tvg7gvwm9a228mqqwawh9xycnv8dkrdm7xuum6afsrqcuzu88)#y06denaf",
    "hex": "00203062edde70aad88f218ed97aa51f6003baeb94c4c4d876d86ddf8dce6f5d4c06",
    "address": "tb1qxp3wmhns4tvg7gvwm9a228mqqwawh9xycnv8dkrdm7xuum6afsrqcuzu88",
    "type": "witness_v0_scripthash",
    "p2sh-segwit": "2N8BaDhNcPriSpqLqNKWBc1uPXhRMDuA7To"
  }
}

And then, coins can be sent for example to tb1qxp3wmhns4tvg7gvwm9a228mqqwawh9xycnv8dkrdm7xuum6afsrqcuzu88. Then, as long as the private key is unknown, everything will work just like for regular P2WPKH, which is tb1qw508d6qejxtdg4y5r3zarvary0c5xw7kxpjzsx in this case. For signatures taking around 72 bytes, coins will be timelocked to 288 blocks (around two days), but other than that, it can work just like its P2WPKH equivalent (and it can be signed in exactly the same way, because of used OP_CODESEPARATOR, so there is no need to change signing code).

However, when the private key will be known, then coins will be protected by a Proof of Work challenge. Lowering signature size by a single byte will allow moving them 4 blocks earlier. Which means, that even if both secp256k1 and SHA-256 will be fully broken, then 9-byte signature will still timelock coins for 36 blocks (around 6 hours). And if for example only secp256k1 will be broken, then some 40-byte signature will still need to wait 160 blocks, so it usually means more than one day of delay.

What do you think about it? Also, as usual, check things in test networks first, before moving any of your mainnet coins to such addresses.

Note: I slightly modified my idea from my mailing list post, because if the public key is wrapped behind OP_HASH160, and separated from the rest of the Script with OP_CODESEPARATOR, then it is more compatible with P2WPKH, and also, revealing the Script under P2WSH can be done, without revealing the corresponding public key.

Let's assume, that we want to bring back difficulty adjustments into regtest, just to test, if mining works correctly. This is how it can be done:

Code:

$ git diff HEAD~1
diff --git a/src/kernel/chainparams.cpp b/src/kernel/chainparams.cpp
index 0f128d4c56..24ac639698 100644
--- a/src/kernel/chainparams.cpp
+++ b/src/kernel/chainparams.cpp
@@ -530,7 +530,7 @@ public:
         m_chain_type = ChainType::REGTEST;
         consensus.signet_blocks = false;
         consensus.signet_challenge.clear();
-        consensus.nSubsidyHalvingInterval = 150;
+        consensus.nSubsidyHalvingInterval = 210000;
         consensus.BIP34Height = 1; // Always active unless overridden
         consensus.BIP34Hash = uint256();
         consensus.BIP65Height = 1;  // Always active unless overridden
@@ -543,7 +543,7 @@ public:
         consensus.nPowTargetSpacing = 10 * 60;
         consensus.fPowAllowMinDifficultyBlocks = true;
         consensus.enforce_BIP94 = true;
-        consensus.fPowNoRetargeting = true;
+        consensus.fPowNoRetargeting = false;
         consensus.nRuleChangeActivationThreshold = 108; // 75% for testchains
         consensus.nMinerConfirmationWindow = 144; // Faster than normal for regtest (144 instead of 2016)

And then, let's try to generate regtest blocks with just a CPU, in some infinite bash loop, to make it simple:

Code:

while [ 1 ]
do
    ./bitcoin-cli -regtest generatetoaddress 1 bcrt1pfeesnyr2tx 100000000
done

Then, the initial regtest difficulty is set to "207fffff", which we can see, when we explore blocks, up to block number 143:

Code:

$ ./bitcoin-cli -regtest getblockhash 143
561f4c44c9967c922030b7f0f40d7af912ab373dc5b7b8fce64bf1092c2451c8
$ ./bitcoin-cli -regtest getblock 561f4c44c9967c922030b7f0f40d7af912ab373dc5b7b8fce64bf1092c2451c8
{
  "hash": "561f4c44c9967c922030b7f0f40d7af912ab373dc5b7b8fce64bf1092c2451c8",
  "confirmations": 631,
  "height": 143,
  "version": 536870912,
  "versionHex": "20000000",
  "merkleroot": "01b6fd85017ab60caad4c82c0ce7e2c0939330a23e2d20dc6c5c2a5a9c36865f",
  "time": 1756365704,
  "mediantime": 1756365703,
  "nonce": 0,
  "bits": "207fffff",
  "difficulty": 4.656542373906925e-10,
  "chainwork": "0000000000000000000000000000000000000000000000000000000000000120",
  "nTx": 1,
  "previousblockhash": "27f1b07a0c88220ec90617e95dbf92990fcb1c59e5a777efcea599a18113ec75",
  "nextblockhash": "0000b2dd4a19a3f446fc8f3ad8b2ba5472f2fbc962c8ce8c34e234afad91113e",
  "strippedsize": 196,
  "size": 232,
  "weight": 820,
  "tx": [
    "01b6fd85017ab60caad4c82c0ce7e2c0939330a23e2d20dc6c5c2a5a9c36865f"
  ]
}

However, when we check the next block hash, it suddenly has much more leading zeroes, than we would expect, if the difficulty would raise by a factor of four:

Code:

$ ./bitcoin-cli -regtest getblock 0000b2dd4a19a3f446fc8f3ad8b2ba5472f2fbc962c8ce8c34e234afad91113e
{
  "hash": "0000b2dd4a19a3f446fc8f3ad8b2ba5472f2fbc962c8ce8c34e234afad91113e",
  "confirmations": 662,
  "height": 144,
  "version": 805306368,
  "versionHex": "30000000",
  "merkleroot": "3e5394b4f8d0e50c2ff4d268ddabbb942584b501e37701238196f783a24d00a7",
  "time": 1756365704,
  "mediantime": 1756365703,
  "nonce": 186410,
  "bits": "1f00be2e",
  "difficulty": 2.053947215238338e-05,
  "chainwork": "00000000000000000000000000000000000000000000000000000000000159b9",
  "nTx": 1,
  "previousblockhash": "561f4c44c9967c922030b7f0f40d7af912ab373dc5b7b8fce64bf1092c2451c8",
  "nextblockhash": "0000946b847eda6f6ba7dfaf9e4d34538f3983997bcefba73e5f7501de365250",
  "strippedsize": 196,
  "size": 232,
  "weight": 820,
  "tx": [
    "3e5394b4f8d0e50c2ff4d268ddabbb942584b501e37701238196f783a24d00a7"
  ]
}

And now, it raised from "207fffff" to "1f00be2e", which is not just "four times more difficult" (the maximum adjustment), but rather something like "at least 44108 times more difficult":

Code:

bits2diff(207fffff)=7fffff00 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bits2diff(1f00be2e)=0000be2e 00000000 00000000 00000000 00000000 00000000 00000000 00000000
7fffff0000000000000000000000000000000000000000000000000000000000/0000be2e00000000000000000000000000000000000000000000000000000000=ac4c
hex2dec(ac4c)=44108

Do you know, why it is the case? Next adjustments are not as sharp, for example:

Code:

$ ./bitcoin-cli -regtest getblockhash 287
000076f923e02cd924e1e5a5d563e05a6d4dcd34ad0efc08ecd42a13203dfaeb
$ ./bitcoin-cli -regtest getblock 000076f923e02cd924e1e5a5d563e05a6d4dcd34ad0efc08ecd42a13203dfaeb
{
  "hash": "000076f923e02cd924e1e5a5d563e05a6d4dcd34ad0efc08ecd42a13203dfaeb",
  "confirmations": 572,
  "height": 287,
  "version": 805306368,
  "versionHex": "30000000",
  "merkleroot": "88fbb4039268064fa8de221df70271eb823518c84b62dbf1b7d02f857628c423",
  "time": 1756365728,
  "mediantime": 1756365727,
  "nonce": 23879,
  "bits": "1f00be2e",
  "difficulty": 2.053947215238338e-05,
  "chainwork": "0000000000000000000000000000000000000000000000000000000000c1d730",
  "nTx": 1,
  "previousblockhash": "0000795f0a85fe1d65d5b6200416d6e97f6cc578661ab0d796159bc4014d8e79",
  "nextblockhash": "00002b023539977a6b783706829ed05eb5be422c9c318317939262f954d8d016",
  "strippedsize": 196,
  "size": 232,
  "weight": 820,
  "tx": [
    "88fbb4039268064fa8de221df70271eb823518c84b62dbf1b7d02f857628c423"
  ]
}
$ ./bitcoin-cli -regtest getblock 00002b023539977a6b783706829ed05eb5be422c9c318317939262f954d8d016
{
  "hash": "00002b023539977a6b783706829ed05eb5be422c9c318317939262f954d8d016",
  "confirmations": 573,
  "height": 288,
  "version": 805306368,
  "versionHex": "30000000",
  "merkleroot": "693cf9bcbd2100f057cf21e2b9b504dc97746d4261f379c5b4aa20f49c21eaca",
  "time": 1756365728,
  "mediantime": 1756365727,
  "nonce": 207096,
  "bits": "1e2f8b80",
  "difficulty": 8.215788860953354e-05,
  "chainwork": "0000000000000000000000000000000000000000000000000000000000c73996",
  "nTx": 1,
  "previousblockhash": "000076f923e02cd924e1e5a5d563e05a6d4dcd34ad0efc08ecd42a13203dfaeb",
  "nextblockhash": "000028869e8660bb0a0000a27f53a001fce85ed7b0a7baa80a57ce333b09e3f7",
  "strippedsize": 196,
  "size": 232,
  "weight": 820,
  "tx": [
    "693cf9bcbd2100f057cf21e2b9b504dc97746d4261f379c5b4aa20f49c21eaca"
  ]
}

And then, if we count, how many times it raised:

Code:

bits2diff(1f00be2e)=0000be2e 00000000 00000000 00000000 00000000 00000000 00000000 00000000
bits2diff(1e2f8b80)=00002f8b 80000000 00000000 00000000 00000000 00000000 00000000 00000000
0000be2e00000000000000000000000000000000000000000000000000000000/00002f8b80000000000000000000000000000000000000000000000000000000=4

Only four times, as expected. So, why it was not the case during the first adjustment?

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!

Each signature is a relation between two public keys on secp256k1, where 256-bit addition and multiplication can usually demonstrate, that a given entity can control a given private key, if it is done correctly, and if each step is verified according to the specification. However, ECDSA can also be used as a 256-bit calculator. The simplest example of such use case is when signature is placed in the output script, and user have to provide a matching public key, by using public key recovery:

Code:

<signature> OP_SWAP OP_CHECKSIG

If a given signature is signed with SIGHASH_ALL, then it is roughly equivalent to pushing message hash called z-value, converted to some public key, and modified by chosen r-value and s-value from that signature. However, public key recovery can be used more than once, and it is possible to form a chain of such operations. For example:

Code:

OP_DUP <signature> OP_SWAP OP_CHECKSIGVERIFY OP_CHECKSIG

Now, the solution is to put not only some public key, but also yet another signature, which would be valid for recovered public key (which would indirectly prove, that r-value of the signature can be controlled, and k-value is known, if it would be also signed with SIGHASH_ALL).

And that kind of chain can be continued further. We can start from "pubkeyA", allow using any "signatureB", apply public key recovery, and reach "pubkeyC", then again require "signatureD", and use public key recovery, to reach "pubkeyE". The total size of this chain is restricted by consensus rules, like maximum size of the Script, maximum number of sigops, and other similar limits.

However, by starting with some "pubkeyA", and ending the chain with some "pubkeyZ", if the final public key would have a private key, which would be equal to the hash of some arbitrary message, it would emulate OP_CHECKSIGFROMSTACK, without introducing any soft-fork, or other changes in consensus rules. It would allow wiring OP_CHECKSIGFROMSTACK as a virtual opcode, which could be replaced by a chain of opcodes, and by doing some operations on 256-bit numbers, it could be possible to translate some signed message to the proper Script.

Another interesting observation, is that OP_CHECKMULTISIG can enforce using identical z-value for all public keys in the chain. For example, here is how regular 3-of-3 multisig is made:

Code:

Input: <sigA> <sigB> <sigC>
Output: 3 <pubkeyA> <pubkeyB> <pubkeyC> 3 OP_CHECKMULTISIG

But it can also use public key recovery, and it is possible to put all signatures inside the output script:

Code:

Input: <pubkeyC> <pubkeyB> <pubkeyA>
Output: OP_TOALTSTACK OP_TOALTSTACK OP_TOALTSTACK <sigA> <sigB> <sigC> 3 OP_FROMALTSTACK OP_FROMALTSTACK OP_FROMALTSTACK 3 OP_CHECKMULTISIG

And then, different signatures can be executed on the same z-value, so results can be checked, if reached public keys are equal to some specific values, or not.

Another interesting hint is that SIGHASH_SINGLE can force z-value to have a constant value of "one", written in little endian, and that fact can be connected with OP_CHECKMULTISIG or OP_CHECKSIG operations on top of some Script, executed in out-of-bounds index.

Do you know, how to wire OP_CHECKSIGFROMSTACK, and write it as a combination of existing opcodes, like OP_CHECKSIG or OP_CHECKMULTISIG? Because the more I read about ECDSA, the more I am convinced, that it should be possible, and it is just a matter of writing some proper math equations, which would translate a valid signed message into a bunch of opcodes, which would execute it properly, regardless of the "txid:vout", where that Script would be placed.

I know it is possible to make things tick by doing it right, and making a soft-fork, but as more time passes, it is harder and harder to reach consensus, so it can be safely assumed, that in case of any disagreement, status quo will be preserved, so I am thinking about workarounds, if Bitcoin won't be changed in the future, and if "ossification" will be perceived as "no changes policy".

Recently, I shared a puzzle, based on Proof of Work inside Script. It is described in details here: https://bitcointalk.org/index.php?topic=5551080.0

In the shared puzzle, the private key, used to grind solutions, is equal to one. It is done on purpose, to make it easy to recreate by anyone, anywhere. However, Proof of Work can be used in many different places. It can be used to build sidechains, which would be directly pegged into Bitcoin. Then, from the perspective of on-chain node, sidechain transactions will be simplified into one-input-one-output chunks, with attached peg-ins and peg-outs. Any sidechain miner can take any fees out of sidechain users, and pay the rest to the mainchain miners. I think it is a good idea to show some example:

Code:

+-------------------------------------------------+
| Puzzle  0.00050000 BTC -> Miner  0.00053000 BTC |
| Alice   0.01000000 BTC    Bob    0.00999000 BTC |
| Charlie 0.02000000 BTC    Daniel 0.01999000 BTC |
| Elaine  0.03000000 BTC    Frank  0.02999000 BTC |
+-------------------------------------------------+

Here, some unsolved puzzle, with some difficulty, is used as a transaction input. Any sidechain miner can start grinding it, by using SIGHASH_ANYONECANPAY to make sure, that anyone can put more coins in, or bump on-chain fees if needed.

Then, people joining the sidechain will provide their inputs, and people leaving the sidechain will share their outputs. In the example above, the on-chain transaction has zero fee, but it can be higher, if output amounts will be lowered (however, if sidechain miner is also a mainchain miner, then it can decide to prioritize sidechain transactions inside produced Bitcoin blocks). When it comes to sighashes, puzzle solver can use SIGHASH_ANYONECANPAY with SIGHASH_ALL, and other people, who want to join the sidechain, can use SIGHASH_NONE, to sign all inputs, and make sure, that they will be included, only if the Proof of Work puzzle will be solved. Also, they can put any commitment as their r-values inside their signatures, so it could be possible to validate later, if sidechain rules are followed correctly, and if nobody tried to steal any coins.

In this example, we can see the finalization transaction, which is executed every sometimes, depending on picked Proof of Work, which decides, how often new sidechain transactions are broadcasted. It can be done every three months or so, to make it aligned with other sidechain proposals, like BIP-300 or BIP-301, but it depends mainly on users, how much fees they are willing to pay, and how long they want to wait, to get benefits from batching, and pay lower fees, because of that.

In general, the minimal working example, is when every user stays inside sidechain. Then, the whole on-chain representation can be simplified into just this:

Code:

+---------------------------------------------------------------------------+
| SponsorA 0.00010000 BTC -> Puzzle 0.00050000 BTC -> Puzzle 0.00050000 BTC |
| SponsorB 0.00015000 BTC                                                   |
| SponsorC 0.00025000 BTC                                                   |
+---------------------------------------------------------------------------+

In this case, a group of sponsors can start putting their coins in, to transfer them from mainchain to sidechain. The puzzle can be very similar to the original, but committed difficulty and public key can be rotated on-the-fly, depending on things happening inside sidechain mempools. Sidechain users can keep making transactions between themselves, and sponsors can collect this information, and use a merkle root of the next network state, as the private key for grinded signatures (instead of using private key equal to one, like it is in my puzzle). Then, when some sidechain miner will find the solution, it can share a signature, signed with SIGHASH_ANYONECANPAY, and use any coins, to set any fees (or process it for free, if it can also mine mainnet blocks).

Then, during Initial Blockchain Download, Bitcoin nodes don't have to know about sidechain existence at all. From their perspective, there are just some signatures, which are just smaller than usual (which is visible in the Script). However, they don't have to verify the correctness of the sidechain merkle tree, it is treated just like a chunk of bytes, which is only checked from the perspective of ECDSA correctness, and no commitment behind it is ever processed by existing nodes.

For each sidechain, a single UTXO is all we need, to keep it running. All inputs and outputs are needed mainly for peg-ins and peg-outs, when people will want to go between sidechain and mainchain, or even jump directly from one sidechain puzzle to another. Nodes can keep signing different versions of on-chain transactions, similar to how Lightning nodes sign them. The final version is broadcasted to the mainchain nodes, when some sidechain miner can find a solution, claim the reward, push the sidechain difficulty a little higher, and commit the state of the whole sidechain, and make it committed on-chain. As long as everyone is staying inside, it is all about changing one 256-bit number to another, so on-chain transaction size is mainly affected by peg-ins and peg-outs, the internal state of the sidechain is transparent to all mainchain nodes, and can execute any rules inside, as creators would pick.

I think producing a new sidechain header could be compared to consuming a single transaction input and producing a single output in that case (everything else is related to peg-ins and peg-outs; if there are none, then one-input-one-output is all that is needed). Mainchain users can then see each sidechain block header, and check Proof of Work behind it, but everything else can stay inside sidechain. I guess it would scale better than Lightning Network, because then, transactions inside sidechain wouldn't require constantly closing and opening new channels, and could be simplified to just replacing one 256-bit number with another 256-bit number, used for the next puzzle.

Edit: Sidechains can be improved with Optional Hourglass. Then, the private key can just represent the state of the whole sidechain (for example its UTXO merkle tree, or something similar), and sidechain miners can try to create stronger and stronger signatures, which could be confirmed at earlier, and earlier block height. Here is an example of a sidechain using Optional Hourglass envelope, and committing to the "Hello World" content:

Code:

SHA-256("Hello World")=d=a591a6d40bf420404a011733cfb7b190d62c65bf0bcda32b57b277d9ad9f146e
Q=d*G=0298C39AC0D91FF4CEA6E79AE5836E50868C47191BCA0FBFD2A6838D303665F506

And now, we can require at least 13150 ACKs, while also enforcing Optional Hourglass envelope:

Code:

decodescript 210298c39ac0d91ff4cea6e79ae5836e50868c47191bca0fbfd2a6838d303665f506ac
{
  "asm": "0298c39ac0d91ff4cea6e79ae5836e50868c47191bca0fbfd2a6838d303665f506 OP_CHECKSIG",
  "desc": "pk(0298c39ac0d91ff4cea6e79ae5836e50868c47191bca0fbfd2a6838d303665f506)#ryjv7lc4",
  "type": "pubkey",
  "p2sh": "2NEhtT2UPFkvRgMCQ4azmNMEGtVQfmy33vL",
  "segwit": {
    "asm": "0 d35986305ce10537dc781e795e734673035c4160",
    "desc": "addr(tb1q6dvcvvzuuyzn0hrcreu4uu6xwvp4cstqk89zqn)#lgthsn5s",
    "hex": "0014d35986305ce10537dc781e795e734673035c4160",
    "address": "tb1q6dvcvvzuuyzn0hrcreu4uu6xwvp4cstqk89zqn",
    "type": "witness_v0_keyhash",
    "p2sh-segwit": "2N4ZPqUwLBg1FiBuUKyiVckfH63n71KamNG"
  }
}
decodescript 7c8276937693025e3393b2757cab76a914d35986305ce10537dc781e795e734673035c416088ac
{
  "asm": "OP_SWAP OP_SIZE OP_DUP OP_ADD OP_DUP OP_ADD 13150 OP_ADD OP_CHECKSEQUENCEVERIFY OP_DROP OP_SWAP OP_CODESEPARATOR OP_DUP OP_HASH160 d35986305ce10537dc781e795e734673035c4160 OP_EQUALVERIFY OP_CHECKSIG",
  "desc": "raw(7c8276937693025e3393b2757cab76a914d35986305ce10537dc781e795e734673035c416088ac)#mrd0n6f8",
  "type": "nonstandard",
  "p2sh": "2Muhrn2Y5PgHQZRzL9fevf7j34s8aaXwmbg",
  "segwit": {
    "asm": "0 419e580de6345f1ebb6253682f62716098d3ad1bda5b631a752f2484c2342913",
    "desc": "addr(tb1qgx09sr0xx303awmz2d5z7cn3vzvd8tgmmfdkxxn49ujgfs359yfs8fyrcn)#yqw84xvm",
    "hex": "0020419e580de6345f1ebb6253682f62716098d3ad1bda5b631a752f2484c2342913",
    "address": "tb1qgx09sr0xx303awmz2d5z7cn3vzvd8tgmmfdkxxn49ujgfs359yfs8fyrcn",
    "type": "witness_v0_scripthash",
    "p2sh-segwit": "2N1tpGp3eEKZgjxXesbk2RFebaLwqY6QWAF"
  }
}

And then, people can try to mine addresses like tb1qgx09sr0xx303awmz2d5z7cn3vzvd8tgmmfdkxxn49ujgfs359yfs8fyrcn constantly, while sharing their ACKs between themselves. The final winner is the miner, who will produce the smallest signature during three months.

I think OP_SHA256 OP_CHECKSIG is too simple for a quantum test. It will tell us, that things are broken, but won't tell us about the progress. For that reason, here is something more gradual, that I made:

Code:

+--------+----------------------------------------------------------------+----------------------------------------------------------------------------------+
| Number | Address                                                        | 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   |
+--------+----------------------------------------------------------------+----------------------------------------------------------------------------------+

As I said in testnet4: Remember about minimally encoded CScriptNum, when you use Proof of Work scripts!

The puzzle starts from 60, because in that case, grinding a single byte is all you need, and it can be done on CPUs. Later, it gets harder and harder. First, it would probably require grinding only SHA-256 hashes, but after reaching a certain point, grinding low x-values in secp256k1 public keys will be profitable, and finding alternatives for half of the generator. The puzzle ends at 10, because 9-byte signature is the smallest valid one, where r-value and s-value has exactly one byte. It is the smallest valid signature, which would mean, that OP_CHECKSIG is fully broken, and can be used just as some 256-bit calculator, if it would be reached without public key recovery, in normal network circumstances.

Also, if you want to deposit something, then remember, that each and every coin requires a new Proof of Work, grinded from scratch. So, it is more profitable to send one output with 10k sats, than 10 outputs with 1k sats each, because even though the private key is known, and equal to one, I wouldn't be able to accumulate smaller deposits into bigger ones, without solving the puzzle by myself.

For that reason, I think depositing to the nearest unsolved address makes the most sense, and then switching to the next one, if that will be cleared. As long as every coin will be swept, the overall progress can be traced from the initial transaction.

By using "decodescript", you can get all needed details, for example for the first address from the puzzle:

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"
  }
}

Good luck!

Just some observation, which can be interesting for some testnet3 users: there are many transactions, displayed on https://mempool.space/testnet which stay unconfirmed for days, even though some blocks, mined by some miners, are far from being full, and these transactions could easily be included by them (because they already include transactions with lower fee rates).

So, why a lot of blocks are empty? Because a lot of users just send their transactions once, and close their clients.

And, what happens, when their nodes are offline? Well, these transactions are never re-broadcasted by anyone. So, when new miners come in, then they don't receive those transactions. They don't include them in their block templates, and they are waiting longer and longer, until some old miner include it in some block.

Some example: https://mempool.space/testnet/tx/882cf91eb089fd83ae26f6f557dc0d5ff4a670b07b405282200c5fd963267329#vin=0

This transaction was unconfirmed for 4 days. And it would probably stay unconfirmed for much longer than that. However:

Code:

$ ./bitcoin-cli -testnet sendrawtransaction 020000000001016e8cdd2c2715e1c9453929489182ab9af4cd8d74241518155a000faa29e96d920200000000fdffffff0242d813000000000022512043d25bc290142d1031a0b22367991bfe1a9f1334c2b232e230377bcf11cdcec642d8130000000000225120d7e7bc85cc1012351c33fc2211ce46a8edba5aa204d75334643a1210f65020da0140853bf59989a9e3a21ec7af6f558626287f14c1e7e48bd590bc22310f09811758044191b7f23c300e8d98cd23fe2f07941e6e49766261ddf762cf4ee3c565c1e700000000
882cf91eb089fd83ae26f6f557dc0d5ff4a670b07b405282200c5fd963267329

And, just one minute later, it is confirmed! (the same was true for more than this one transaction, so I am sure, that it is not just some coincidence; everything I rebroadcasted, was confirmed in minutes, even if it was first seen days ago)

Conclusions: it is a good idea to run a full node (even in pruning mode), if you want to get your transactions confirmed sooner than later. You can have "fee rate" of 856 sat/vB, and "effective fee rate" of 3,048 sat/vB, and wait days for a single confirmation. However, if you just run a full node, and it will re-broadcast your transactions periodically, then not only you can get it confirmed sooner, but also you can make it cheaper, when you hit a miner, who just joined, and don't have fully filled mempool yet (not to mention about full-RBF potential, where you can replace more expensive transaction with some cheaper version, if some miner does not have the properly synchronized mempool state).

Also, it is an interesting observation, when you notice, that people are shouting about Ordinals as "not a spam", but they don't even care about re-broadcasting their own transactions, and they end their journey, when their transactions are displayed in block explorers.

When we try to re-generate curves secp160k1, secp192k1, secp224k1, and secp256k1, we start from "2^n-2^32", and decrement p-value, to get some prime number, forming a curve. In case of secp192k1, secp224k1, and secp256k1, the first matching value was picked. However, in case of secp160k1, the p-value is actually the fifth below 2^160-2^32:

Code:

p=0xfffffffffffffffffffffffffffffffefffff0a7   n=0xffffffffffffffffffff66fcc05801f00e15f6a5    b=12
p=0xfffffffffffffffffffffffffffffffeffffbde9   n=0xfffffffffffffffffffe280724f449253bc2e9ab    b=11
p=0xfffffffffffffffffffffffffffffffeffffb88b   n=0xfffffffffffffffffffe206e5eb5194f32e3ca55    b=2
p=0xfffffffffffffffffffffffffffffffeffffb0ab   n=0xfffffffffffffffffffe01cf87c16ee51306af13    b=17
p=0xfffffffffffffffffffffffffffffffeffffac73   n=0x100000000000000000001b8fa16dfab9aca16b6b3   b=7
...

Why those four p-values were skipped? All of them have some matching b-value, where n-value is a prime.

This is how it looks for secp192k1:

Code:

p=0xfffffffffffffffffffffffffffffffffffffffeffffee37   n=0xfffffffffffffffffffffffe26f2fc170f69466a74defd8d    b=3
p=0xfffffffffffffffffffffffffffffffffffffffeffffccb9   n=0x1000000000000000000000001e58d67ad78297d7bbd3171ab   b=5
p=0xfffffffffffffffffffffffffffffffffffffffeffff9eb1   n=0xffffffffffffffffffffffffa52c5f9d6368c4ecfda4b679    b=7
p=0xfffffffffffffffffffffffffffffffffffffffeffff9e45   n=0xfffffffffffffffffffffffebaf27eff4602ec4421c5be6b    b=2
p=0xfffffffffffffffffffffffffffffffffffffffeffff91eb   n=0x10000000000000000000000008b5b258a479c4ec50f0453fb   b=3
...

secp224k1:

Code:

p=0xfffffffffffffffffffffffffffffffffffffffffffffffeffffe56d   n=0x10000000000000000000000000001dce8d2ec6184caf0a971769fb1f7   b=2
p=0xfffffffffffffffffffffffffffffffffffffffffffffffeffffc2a5   n=0x100000000000000000000000000017b648f48e73e5bad81df9899f021   b=5
p=0xfffffffffffffffffffffffffffffffffffffffffffffffeffffb29d   n=0xffffffffffffffffffffffffffff59d54bf3175c3f7aa7dd7cf534bd    b=6
p=0xfffffffffffffffffffffffffffffffffffffffffffffffeffff9671   n=0x10000000000000000000000000001fcadd7fc4b7f91a2f7f7dab61a81   b=29
p=0xfffffffffffffffffffffffffffffffffffffffffffffffeffff75dd   n=0xffffffffffffffffffffffffffffe2716c960d555bc3a98c1a97cd15    b=6
...

secp256k1:

Code:

p=0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f   n=0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141    b=7
p=0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffeffffe117   n=0xffffffffffffffffffffffffffffffffc0ad397ea94d65ed5001a2f3f2812f4d    b=10
p=0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffeffffbaef   n=0x100000000000000000000000000000000f2cfcb48012d9e76586a1c1564109bed   b=12
p=0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffeffffb0ed   n=0x100000000000000000000000000000000f35b461eedf9baf1d8393eecc2fef1ff   b=5
p=0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffeffffa33d   n=0x100000000000000000000000000000001f2cfdf190f0eff9bfa36ca2fe9add651   b=15
...

Also, I wonder why b=5 was picked for secp224k1, where b=2 would work as well, and would lead to the same n-value. Are there any hidden constraints, that should be considered, when picking b-value?

We start with four elliptic curves, which were constructed together (because of how the half of the generator is set in all of them). We have secp160k1, secp192k1, secp224k1, and secp256k1. When we want to compute square roots and cube roots, then for three of them, it works fine for their p-values:

secp160k1:

Code:

p=0xfffffffffffffffffffffffffffffffeffffac73
n=0x0100000000000000000001b8fa16dfab9aca16b6b3
(p+1)/4=0x3fffffffffffffffffffffffffffffffbfffeb1d
(p+2)/9=0x1c71c71c71c71c71c71c71c71c71c71c55554c0d
0x1000000000^0x3fffffffffffffffffffffffffffffffbfffeb1d^0x1c71c71c71c71c71c71c71c71c71c71c55554c0d=0x40 (mod p)

secp192k1:

Code:

p=0xfffffffffffffffffffffffffffffffffffffffeffffee37
n=0xfffffffffffffffffffffffe26f2fc170f69466a74defd8d
(p+1)/4=0x3fffffffffffffffffffffffffffffffffffffffbffffb8e
(p+2)/9=0x1c71c71c71c71c71c71c71c71c71c71c71c71c71aaaaa8b1
0x1000000000^0x3fffffffffffffffffffffffffffffffffffffffbffffb8e^0x1c71c71c71c71c71c71c71c71c71c71c71c71c71aaaaa8b1=0x40 (mod p)

secp256k1:

Code:

p=0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f
n=0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141
(p+1)/4=0x3fffffffffffffffffffffffffffffffffffffffffffffffffffffffbfffff0c
(p+2)/9=0x1c71c71c71c71c71c71c71c71c71c71c71c71c71c71c71c71c71c71c555554e9
0x1000000000^0x3fffffffffffffffffffffffffffffffffffffffffffffffffffffffbfffff0c^0x1c71c71c71c71c71c71c71c71c71c71c71c71c71c71c71c71c71c71c555554e9=0x40 (mod p)

However, the same method won't work for p-value in secp224k1 for some reason:

Code:

p=0xfffffffffffffffffffffffffffffffffffffffffffffffeffffe56d
n=0x10000000000000000000000000001dce8d2ec6184caf0a971769fb1f7
p%4=1 (failed, expected 3)
p%9=1 (failed, expected 7)

If all of those curves were generated together, then why p-value for secp224k1 was picked differently, than for three other curves? And how to efficiently compute square roots and cube roots for this curve? Also, how to proceed with all n-values? I heard there are some algorithms, to compute those results for any values, but if those curves were selected specifically, to make operations like that "fast", then everything should be solvable by simple equations like "(p+x)/y", similar to "(p+1)/4" and "(p+2)/9", right?

Do you know, how to spend "OP_SHA256 OP_CHECKSIG" TapScript? Is it spendable at all?

As far as I understand, it requires "<signature> <message>" as an input. And then, the hash of the message could be converted into x-value of the public key. However, after reading CAT and Schnorr Tricks I, it seems it could be possible, if the "<message>" would contain for example "HASH(G||G||txdata)".

Also, because any "<signature>" is just a combination of "<r,s>" values, it could be a combination of "<r1+r2,s1+s2>". Which means, it may be possible to create separate signatures upfront, and then join them in this way, just by tweaking some values. What do you think? Do you have any ideas, how to spend that TapScript?

Why this value can be rotated like in a clock?

Code:

1dba45ae684199cd23ab3f4de753d962f7a4e79060df26e4ed19c677b4a37800^1=1dba45ae684199cd23ab3f4de753d962f7a4e79060df26e4ed19c677b4a37800
1dba45ae684199cd23ab3f4de753d962f7a4e79060df26e4ed19c677b4a37800^2=ac9c52b33fa3cf1f5ad9e3fd77ed9ba4a880b9fc8ec739c2e0cfc810b51283cf
1dba45ae684199cd23ab3f4de753d962f7a4e79060df26e4ed19c677b4a37800^3=70ad49ae7f8574ecab641a42b3a24f22d6374023944cc665a6bcaeb0f37bbf78
1dba45ae684199cd23ab3f4de753d962f7a4e79060df26e4ed19c677b4a37800^4=ac9c52b33fa3cf1f5ad9e3fd77ed9ba4a880b9fc8ec739c2e0cfc810b51283ce
1dba45ae684199cd23ab3f4de753d962f7a4e79060df26e4ed19c677b4a37800^5=52f304001743db1f87b8daf4cc4e75bfde925893336d9f80b9a2e8393ed84778
1dba45ae684199cd23ab3f4de753d962f7a4e79060df26e4ed19c677b4a37800^6=fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364140
1dba45ae684199cd23ab3f4de753d962f7a4e79060df26e4ed19c677b4a37800^7=e245ba5197be6632dc54c0b218ac269bc309f5564e697956d2b898151b92c941
1dba45ae684199cd23ab3f4de753d962f7a4e79060df26e4ed19c677b4a37800^8=5363ad4cc05c30e0a5261c028812645a122e22ea20816678df02967c1b23bd72
1dba45ae684199cd23ab3f4de753d962f7a4e79060df26e4ed19c677b4a37800^9=8f52b651807a8b13549be5bd4c5db0dbe4779cc31afbd9d61915afdbdcba81c9
1dba45ae684199cd23ab3f4de753d962f7a4e79060df26e4ed19c677b4a37800^a=5363ad4cc05c30e0a5261c028812645a122e22ea20816678df02967c1b23bd73
1dba45ae684199cd23ab3f4de753d962f7a4e79060df26e4ed19c677b4a37800^b=ad0cfbffe8bc24e07847250b33b18a3edc1c84537bdb00bb062f7653915df9c9
1dba45ae684199cd23ab3f4de753d962f7a4e79060df26e4ed19c677b4a37800^c=0000000000000000000000000000000000000000000000000000000000000001

Are there other such values? How to get them? Is it possible to reach them for some other value like 2 or 3, for example to get it in five moves or in seven moves? Also, it is true for "n=fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141", is it possible to get it based on "p=fffffffffffffffffffffffffffffffffffffffffffffffffffffffefffffc2f"?

Podstawowe informacje o tokenie: https://www.mintme.com/token/Disasm

PL: Disasm jest tokenem, który będzie używany do wspierania DisasmWiki (obecnie umieszczonej na stronie disasm.pl) oraz do tworzenia narzędzi służących do inżynierii wstecznej. Zaczęliśmy od rozkładania architektury x86 w C++, ale obecnie nasze narzędzia są wystarczająco ogólne, aby pozwoliły rozszerzyć nasz kod o nowe architektury. Strona jest pisana po polsku.

Jednym z używanych przez nas narzędzi jest Ghidra, jesteśmy dumni z wspierania twórców poprzez dzielenie się ich logiem i zachęcanie ludzi do używania ich oprogramowania. Koniecznie odwiedź ich stronę!

Usually, people think about Merged Mining in the context of Proof of Work. But it seems to be possible to create a merge-mined chain that will be based on Proof of Stake. For example, it could start with zero initial coins and be pushed forward by providing a valid Bitcoin transaction. Then, people would earn that altcoin during moving their bitcoins. So, instead of getting Bitcoin headers and pushing that chain forward by providing 80-byte block headers, people could do that by pushing their signed transactions.

Also, there is no need to create additional commitments on-chain by making things like "OP_RETURN <commitment>", as described on that mailing list. People could just tweak their public keys and reveal their commitments on the merge-mined chain. In this way, it is possible to make some Taproot address with some "OP_RETURN <commitment>" TapBranch, that will never be used on Bitcoin, but that could be used as a proof that such commitment is connected with this address (so also this amount, that is signed in the Bitcoin spending transaction, that means this altcoin can have consensus rules that will distribute coins based on such commitments).