So far in bitcoin RFC-6979 has been used (my almost all implementations) to generate the ephemeral elliptic curve key pair needed in signing operations. BIP-340 on the other hand proposed using two SHA-256 hashes called "tagged hash" in Schnorr signatures. The only benefit of this alternative that I can think of is speed as compared to RFC-6979 it computes less number of SHA-256 hashes (at least 22 SHA-2 blocks vs fixed 4 SHA-2 blocks).

Is speed the only reason? If so does it even matter as we are talking about nano-seconds here and it is for the "signing" operation not verification?

[Table of Contents]

Table of Contents

__________

Introduction How to use Features Links To Do List Updates

Introduction
The FinderOuter is a bitcoin recovery tool that focuses on making the recovery process easy for everyone with any level of technical knowledge. It uses a simple user interface with a list of recovery options. Each option has an explanation and many hints helping user figure out what is needed. It always consist of filling some text boxes and selecting some options and finally clicking the Find button. This eliminates the need to read long guide pages on how to use the application. Each option also has some example cases that can show a simple preview of how each option should be filled for different cases.
FinderOuter is specialized for maximum efficiency, each recovery option and their parts are written from scratch and all those parts down to the basic cryptography used (such as SHA, ECC,...) are specialized for that operation.

Thanks to .Net core and AvaloniaUI FinderOuter can run on all operating systems.
This project is written fully in C# and is 100% open source and will always remain free to use. You can make a donation if you found this tool useful..
FinderOuter is still in beta and under development. New features are slowly added and everything is optimized.
Contribution is always welcome. Please report any bugs you find or any improvement suggestions you have by creating a new issue.


Quick guide

• Select an option from this list depending on what you want to recover
• Read the instructions
• Fill in the required information
• Select appropriate available options according to the entered data
• There are some useful advanced options to speed up the recovery
• Click Find button
• See the progress and the reports
• Progressbar showing the progress percentage shows up for options that use multi-threading (take more than a couple of seconds to complete)
• All recovery options come with examples, click this button repeatedly to cycle through them
• Some parts have a help button that brings up the respective FinderOuter knowledge base page

↑

Features
1. Message signature verification
User can enter a message signature here to verify it. In case there is a problem with the message (except being an actually invalid signature), the code can search to find the common issues that some signing tools have and fix them.

2. Missing Base-58 characters
This option can be used to recover any base-58 encoded string with a checksum that is missing some characters. For example a damaged paper wallet where some characters are erased/unreadable. The position of missing characters must be known.
It works for (1) WIFs (Base-58 encoded private key) (2) Addresses (Base-58 encoded P2PKH or P2SH address) (3) BIP-38 (Base-58 encoded encrypted private key).

3. Missing Base-16 characters
This option is similar to previous feature but works for base-16 (hexadecimal) private keys. Since there is no checksum in this encoding it requires an additional input to check each permutation against. It accepts any address type and public keys. This option is slower in comparison because it uses ECC and that is not yet optimized.

4. Missing mini-privatekey characters
This option is similar to 2 and 3 but works for mini-privatekeys (eg. SzavMBLoXU6kDrqtUVmffv). It requires the corresponding address or public key of the minikey to check each possible key against, as a result it is also slower since it depends on ECC and has 2 additional hashes.

5. Missing mnomonic (seed) words
This option works for both BIP-39 and Electrum mnemonics that have some missing words. It requires knowing one child (private/public) key or address created from that seed and the exact derivation path of it.

6. Missing mnemonic passphrase
This option is used to recover the extension words (aka passphrase) used in mnemonics. It works for both BIP-39 and Electrum mnemonics algorithms. The available passphrase recovery modes are:
a. Alphanumeric: This is when the passphrase consists of letter, numbers and symbols and is random. Example: OT!pA?8i
b. CustomChars: This mode allows user to define their own set of characters to be used in the passphrase. c. soon

7. Missing BIP-38 password
This option can recover passwords used in encrypting bitcoin private keys using the BIP-38 proposal. The available password recovery modes are the same as mnemonic passphrase option.

8. Missing BIP-32 derivation path
This option could be used to find derivation path of a child key (private key, public key or the address) by having the mnemonic or the extended master keys (xprv or xpub). It only checks a hard-coded list of popular derivation paths.

9. Missing characters in Armory recovery phrase
This option is used to recover Armory paper backups (containing 2 or 4 lines of 36 characters in Base-16 with custom char-set) that are missing some of their characters. Since the last 4 characters of each line is the checksum this option can be very fast (1 trillion keys/sec) if the checksum is available or extremely slow (100 key/sec) if not.

10. Missing string encoding
This option could be used to determine the encoding of an arbitrary text. It currently supports Base-16, Base-43, Base-58, Base-58 with checksum and Base-64. All inputs will be converted to hexadecimal.
↑


Links
Source code on GitHub: https://github.com/Coding-Enthusiast/FinderOuter
Want to help?
Review the code and leave your feedback in this topic about the code, features any possible bug(s), ...
Contributions are always welcome. Here is the conventions that FinderOuter adheres to.

If You found this tool helpful consider making a donation:
1Q9swRQuwhTtjZZ2yguFWk7m7pszknkWyk
bc1q3n5t9gv40ayq68nwf0yth49dt5c799wpld376s
↑


To Do List (aka future features!)
See roadmap here: https://github.com/Coding-Enthusiast/FinderOuter/issues/47

• [ ]Optimize, Optimize and more Optimize.
• [ ]Utilize SIMD.
• [ ]Add support for other base-58 strings such as extended private keys.
• [X]Add BIP32 path finder.
• [X]Add password recovery.
• [X]Add BIP-39 passphrase recovery.
• [X]Add BIP-38 password recovery.

↑

Edit: This puzzle is solved and the reward was claimed by hatshepsut93, congratulations. You can read the technical details in this post. Hope everyone enjoyed this and maybe learned a thing or two.

A couple of days ago I found myself among kindred souls in a topic in meta board talking about signing messages and whatnot. Kudos to DdmrDdmr that gave an idea for a fun little brain teaser for those who have a keen sense of adventure, a knack for solving puzzles and are not afraid to peep through the keyhole to kick start the year with their knowledge increased or boost your karma.
In order not to kidnap that thread anymore, I’ve started a new topic here.
As we approach 2020, whether you are celebrating Christmas with pine kones or Kwanzaa with a kerosene candle you can still kneel beside the fire with a keg of eggnog while warming your knuckles with kindling to solve a puzzle.

Code:

-----BEGIN BITCOIN SIGNED MESSAGE-----
Even Santa owns bitcoin.
-----BEGIN SIGNATURE-----
14B3NsuKDk5piqnw71U9kDuSmvMJnYprnr
IDe7ItP3r+hmjpsoVhMy2eNzSoE5v+E50sCUdBRWQDYJUMpKPv3rhuklK0wyEU13rnGRH09e084T5fgr39MGWKs=
-----END BITCOIN SIGNED MESSAGE-----

As the year us 2020, 20 merit reward shall be waiting for he who can figure out what two mysteries are hidden in this. 10 per mystery
Happy 2020 everyone...

[test]

TestNet is an alternate network with the same consensus rules as MainNet and some differences such as being easier to mine, allowing non-standard transactions,... as the name suggests, it exists to help developers test their code without worrying about the costs.

Because of that, the TestNet coins have no value. Be careful not to get scammed like this.

TestNet coins are also easily distinguished since the wallets are different (need to create a new special TestNet wallet) and the addresses use different format (start with: m or n instead of 1 for P2PKH, 2 instead of 3 for P2SH, and tb1 instead of bc1 for Bech32).

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

I'm always a fan of simplifying things and building GUIs and ever since I saw the Miniscript project I wanted to make that happen. Since I recently resumed working on one of my oldest projects (Bitcoin Transaction Tool) I decided to add it as a new feature to that project, for writing and running scripts at the same time.

It can be found under Tools > Script builder (or press F3). It currently supports all OP codes except the disabled ones (for obvious reasons) and *checksig OPs (since to support them I had to copy about 6000 lines of code into this project) and 2 locktime related OPs and CodeSeparator (because I haven't had time to understand how they work!). OPs are also categorized and can be filtered by using the ComboBox on top for ease of finding them.
Writing the script will also run it, the result of it is shown in a text box and the "box" at the bottom right is a list representing the "stack".

I plan on working on it and add more more features such as adding pre-defined script that only need filling up the data part. But before that I wanted to get some feedback about what you think about something like this, how can I improve it,...

Here is a preview:

I am currently exploring parallelization of SHA256 algorithm using SIMD based on a paper I've found which is basically parallelization of the "message scheduling" step that according to the authors takes up 26% of the computation time.

If I understand bitcoin core's code (eg. AVX2), it seems like it doesn't support computing SHA256 of a large data using SIMD (eg. SHA256 of a single 512+ byte long data), but only has the code for computing SHA256 of multiple messages in parallel (ie. SHA256 of m1, m2, ..., m8) and return multiple hashes (ie. h1, h2, ... h8).

If I am reading the code wrong, please explain how it does that.
And if I am right then is there any reason why they didn't add this feature? It seems to be useful for computing the message digest of a big transaction specially the legacy ones which could easily be bigger than 512 bytes.

P.S. If you have any scientific paper about this topic that is newer than 2012 please let me know.

Scripts are being evaluated/run so that we can verify the validity of the given transaction. Depending on the script itself and the implementation, this evaluation could take a much longer time than normally expected.
As a challenge, try to come up with such scripts that could take longer than normal (could be 10 second, minute or hour!). There are also some rare examples out there on the internet from old days that you can find and post here.

• The script doesn't have to be standard but it has to be valid (eg. no disabled OPs).
• It doesn't have to be in a full transaction. It could be as scriptPub, scriptSig and if available redeemScript or witnesses. Or simply 1 script from start to end.
• It should also include the expected time that it takes to evaluate in addition to the device hardware and platform used.

This topic is self-moderated to prevent it from going off-topic.

[01000000000102fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f00000000494830450221008b9d1dc26ba6a9cb62127b02742fa9d754cd3bebf337f7a55d114c8e5cdd30be022040529b194ba3f9281a99f2b1c0a19c0489bc22ede944ccf4ecbab4cc618ef3ed01eeffffffef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a0100000000ffffffff02202cb206000000001976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac9093510d000000001976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac000247304402203609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a0220573a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee0121025476c2e83188368da1ff3e292e7acafcdb3566bb0ad253f62fc70f07aeee635711000000]

As you may know there are many numeric values used in the bitcoin blockchain, each representing a different thing: version, script lengths, locktime,... and since a block is just a sequence of octets (bytes) that is transferred between nodes and stored on disk, we have to convert these integer values into octet strings (byte arrays) and back.
But what you may not have ever noticed is that in bitcoin, depending on what that integer represents a different approach is chosen for its conversion to bytes, resulting in 6 different ways of encoding integers!

The following is an example transaction from BIP-143 containing 5 out of 6 methods listed below with each one highlighted according their type:

01000000000102fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f
00000000494830450221008b9d1dc26ba6a9cb62127b02742fa9d754cd3bebf337f7a55d114c8e
5cdd30be022040529b194ba3f9281a99f2b1c0a19c0489bc22ede944ccf4ecbab4cc618ef3ed01
eeffffffef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a010000
0000ffffffff02202cb206000000001976a9148280b37df378db99f66f85c95a783a76ac7a6d59
88ac9093510d000000001976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac000247
304402203609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a022057
3a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee0121025476c2e831
88368da1ff3e292e7acafcdb3566bb0ad253f62fc70f07aeee635711000000



1. Fixed length little endian
This is the easiest and most common way. It is used for block/transaction version, block time, block target, block nonce, TxIn.Outpoint.Index, TxIn.Sequence and TxOut.Amount and locktime.
The integer will be converted to a little endian byte array of fixed 4 bytes length, with the exception of TxOut.Amount which is 8 bytes.

2. Variable length big endian
This is only used for bigger values in signatures (R and S) using signed notation (most significant bit indicates sign) and public keys (X and Y coordinate). They are always preceded by their length using StackInt (scripts) or CompactInt (witnesses) format.

3. CompactInt
This is a special format used in bitcoin only that can encode from 0 to 2⁶⁴-1 values. It is used for script lengths, input/output count, witness item count and witness item length.

4. DerInt
(Not an official name) This method is used in DER encoding and can encode from 0 to 2¹⁰⁰⁸ length integers. This is only used for encoding signatures (only uses up to 33 bytes lengths). It indicates the length part in DER's Tag-Length-Value encoding scheme.

5. StackInt
(Not an official name) This method is used in bitcoin only to indicate length of the data that is supposed to be pushed onto the stack. It can encode from 0 to 2³²-1 values.

6. Short form integers inside scripts
In bitcoin script language, the stack is an array of bytes. Sometimes these bytes could be interpreted as integers, or an integer could be pushed to the stack. To do that a special format is used:
if there is an OP code for the value (OP_0, OP_NegativeOne,...) that single byte is used.
if there is no OP code, integer is converted to byte array in little endian order in shortest form (no extra zeros) and sign is determined based on most significant bit.

Example: How does 254 (0b11111110) look like in each encoding?
Spoiler (select/highlight to see text):
1. 0xfe000000
3. 0xfdfe00
4. 0x81fe
5. 0x4cfe
6. 0xfe00

Considering the code and implementation of the blockchain technology, which altcoin do you think has the most differences compared to bitcoin? Please explain these differences and include a link to the "documentation" of the coin if possible. I'll try to research the coin and reply back with my findings.

Things I don't exactly consider as differences: Using different hash function, mining algorithm, asymmetric cryptography (different curve, different signature scheme), and obviously: different supply, block time, block size,...

I'm trying to figure out how numbers are interpreted inside scripts. Could someone check if the following test cases are correct?
"bytes" is only the data part, I'm skipping the size part which would be 0x01, 0x02 and 0x03 for 1, 2 and 3 byte data respectively.

Code:

Integer --- bytes
17       { 17 }
75       { 75 }
76       { 76 }
127      { 127 }
128      { 128, 0 }
129      { 129, 0 }
255      { 255, 0 }
256      { 0, 1 }
32767    { 255, 127 }    // 32767 = 0xff7f = 0b11111111 01111111 
32768    { 0, 128, 0 }   // 32768 = 0x0080 = 0b00000000 10000000 
32769    { 1, 128, 0 }   // 32769 = 0x0080 = 0b00000001 10000000
65535    { 255, 255, 0 } // 65535 = 0xffff
-2       { 0b10000010 }  // 0b10000010 = 0x82 = 130
-127     { 0b11111111 }  // 0b11111111 = 0xff = 255
-128     { 128, 128 }    // 128 = 0b10000000
-129     { 129, 128 }    // 128 = 0b10000000

[The FinderOuter]

Recently I started working on a new project called The FinderOuter¹ and whenever I implement an algorithm, I go around comparing it with others to see how others have tackled it compared to my approach. Unfortunately in this case I could only find 2 solution (1 & 2) and both are simple loops, not exactly the best approach.

So if you know of any code that could recover something like the following, please post it here:

Code:

5HueCGU*rMjxEXxi*uD5*Dku*MkF*eZyd4dZ1jvhTVqvbTLvyTJ

Example is from bitcoin wiki

Alternatively if you have done this in the past and have any benchmark (the time it took to find the correct key) please post your time here for comparison.

Sneak peek of what I'm building in pure c# (1.25 million/sec is with core i3 CPU):



1. Name is inspired by the TV show called Futurama

[signing the third input]

I'm testing edge cases:

Code:

signrawtransaction "0100000003993c71b921a95716fa0edfe46d0facd246b8b4d3ee3f0147c526194a1bc5654a01000000009bfffffffa8c89ca6adf7e05fbe85cd84a8c876943aad26c2a1fa39fe00af2e20789e584000000000037ffffff56756fc8abc4b063a2bfbd1890a3c50c77c20bd7d0040002b1324d618f41140a0100000000d3feffff0230561a00000000001976a91433504f2fb2c368480cfba7530757d14c41c8960788ac40420f00000000001976a9147adb657ea875b9d684bbb43e528d7f120ffa67f988ac060d1800" '[{"txid":"0a14418f614d32b1020004d0d70bc2770cc5a39018bdbfa263b0c4abc86f7556","vout":1, "scriptPubKey":"76a91435d70ed960e3f83f83251a519cbc40178ff90d0788ac"}]' '["_key_removed_on_purpose_"]' 'SINGLE'

It is signing the third input with Sighash_Single (same with |AnyoneCanPay added) while having 2 outputs

This was bitcoin core 16.3 and it fails:

Code:

"Unable to sign input, invalid stack size (possibly missing key)"

Signing works with other SigHashTypes

The way I understand, this is allowed in protocol, it just doesn't make sense to sign this way (not having an actual txout to sign with Single!) and it should sign 32 byte long "1" instead.
Am I missing something or is it intentionally being rejected since it doesn't make sense to sign like this? If intentional is there any workaround other than signing with my code and broadcasting to see if it is rejected?

[privacy]

If you have ever used Electrum's console tab and written anything there (not just successful commands), it is stored on your disk and you may want to clear it for either privacy reasons (eg. used ismine() and don't want to have that public information ie address here be stored on disk unencrypted) or for security reasons (eg. in case you used any of the functions like convert_xkey that involve something sensitive like your private key,...)

I've already opened an issue: https://github.com/spesmilo/electrum/issues/5563

To see this history you have to find your "config" file. It is located in the same place where your wallet folder is. On windows it will be

Code:

%APPDATA%\Electrum

On Linux or Mac:

Code:

~/.electrum

The file is simply called config (without an extension) and can be opened with any text editor. The content would look like this:

Code:

{
    "alias": "",
    "auto_connect": true,
    "check_updates": true,
    "config_version": 3,
    "console-history": [
        "random stuff",
        "ismine(\"Some address that you may not want to remain on disk for privacy reasons\")",
        "convert_xkey(\"master private key that holds your funds\", \"\")"
    ],
    "decimal_point": 8,
.....
}

The problem is the contents of console-history key. As you can see I wrote some examples already to show how it works.
In order to clean it manually you should first close your Electrum if it is open then delete everything after "console-history": [ starting after the opening bracket up to before the closing bracket without removing the brackets themselves. The result should be like this:

Code:

{
    "alias": "",
    "auto_connect": true,
    "check_updates": true,
    "config_version": 3,
    "console-history": [],
    "decimal_point": 8,
.....
}

When signing a transaction, before passing the data to ECDSA related function it is hashed using SHA256^x2, BIP143 refers to them as "sigHash". I was wondering if there was a way to get them for any given transaction using bitcoin core, or if they could be found among test cases.
They are very useful for testing specific part of the code instead of just testing the end result (signed transaction).


I also need help figuring out why bitcoin core can not sign the following:

Code:

signrawtransactionwithkey "0200000002aecc62c5db92bb213a0bfdfd3e15aab7367c06ce995ec30936b08b40c513b0560100000000ffffffffaecc62c5db92bb213a0bfdfd3e15aab7367c06ce995ec30936b08b40c513b0560200000000ffffffff0160e31600000000001976a91468cfed146aced22f422a68015ff8ca180761912a88acffffffff" '["_removed_base58_privatekey_"]' '[{"txid":"56b013c5408bb03609c35e99ce067c36b7aa153efdfd0b3a21bb92dbc562ccae", "vout":1, "scriptPubKey":"4104692d8520af5ac174143a928998fd9e8bd767bfd90fc1815e927bc84fdaf912e6687fe598ea324f25890abceb8d99040f70c35f8fd9e82ee206d19f963922dc16ac"}]'

I can sign the other output (vout=2) with the scriptpubkey of 2102fbbd836e18cb88f6dad65ca12dee3270b57818dd91a1cd500dd4c812ed93651cac and a different private key but this one (vout=1) which has a scriptpubkey with an uncompressed public key, fails.
The error message is:

Code:

Unable to sign input, invalid stack size (possibly missing key)

... using Bitcoin Core v0.18.0 (64-bit) testnet on Ubuntu 14.04, offline (no blockchain) and the private key is the correct one (will give the same public key)

Since I am coding all these things without "translating" it from anywhere, I sometimes face some oddity in decisions that were made. Sometimes I am missing the rationale so here I am...

When looking at P2PKH scripts it all makes perfect sense:

Code:

<PushData-sig><PushData-pubkey>|<Dup><Hash160><PushData-20_byte_hash><EqualVerify><CheckSig>

Every "operation" does exactly what it says, they either push some data on top of stack or consume a number of items from the stack and interpret them specifically and give some result.

But then we have multisig/P2SH design the script stops making sense to me (a 2of3 example):

Code:

<0><PushData-sig1><PushData-sig2><PushData-redeem_script>|<Hash160><PushData-20_byte_hash><Equal>

Every operation is doing exactly what they are supposed to except the final PushData operation inside scriptsig! That one is not exactly pushing data, it is pushing a script which I also have to keep a copy of without the script telling me to!!! Which means my script runner now has to have (what I will be calling from now on) a "hack" that copies this last PushData first then runs the whole thing and then runs this last PushData as a script!

Logically running this script (without the hack) should be like this:
<OP_0> => stack has 1 item (emptyBytes)
<PushData-sig1> => stack has 2 item (empty-sig1)
<PushData-sig2> => stack has 3 items (empty-sig1-sig2)
<PushData-redeem_script> => stack has 4 items (empty-sig1-sig2-redeemScr)
<Hash160> => pop top item, hash it, push => stack has 4 items (empty-sig1-sig2-hashresult)
<PushData-20_byte_hash> => stack has 5 items (empty-sig1-sig2-hashresult-givenHash)
<Equal> => pop 2 and compare => stack has 4 items (empty-sig1-sig2-true/false)
Without the hack we are left with a stack with 4 items in it and no more operations left to run!

Now here is another question. Why not simply do this instead:

Code:

<PushData-sigs><PushData-redeem_script>|<Dup><Hash160><PushData-20_byte_hash><EqualVerify><CheckMultiSig>

Now this would not only make sense but also stick to the already existing design. The script "tells me" to duplicate the redeem script with its OP_DUP so I don't do it on my own, then perform the rest and finally the OP_CHECKMULTISIG consumes 2 items (just like its CheckSig counterpart) and interprets the first as a redeem script and the second as the number of required signatures. It also requires less number of push operations so the transaction can be a little smaller the more signatures it has! That could have maybe solve the OP_0 bug(?)

If nBits is 0x1b0404cb the target according to wiki is calculated as

Code:

0x00000000000404CB000000000000000000000000000000000000000000000000

so does this mean if the block hash was the following it would be rejected?

Code:

0x00000000000404CB000000000000000000000000000000000000000000000001

or do we set the remaining bytes in target to 0xff and then compare it with hash result? (Which means the above block hash could be accepted)

Code:

0x00000000000404CBFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

I've started a new project: https://github.com/Autarkysoft/LearnMining
It serves 3 purposes:
1. Helps with learning how mining works
2. It works with the hash algorithm under the hood
3. Explores optimization of code written in C#

It is a work in progress and I have written everything from scratch purely based on documentations without any kind of "code translation" or "code copying" from other projects so it might contain some mistakes.
Currently it only has bitcoin mining (double SHA256). But I plan on adding other hash algorithms, possibly Scrypt (what LTC uses) be next. I am open to suggestions.
The code has tons of comment on it and I believe it is easy to understand what is going on, I can add more if something is unclear.
Since this is obviously not meant for actually mining anything, parallelization is avoided and it works only on CPU.

Please check it out and tell me what you think. Specially the part about Target here and here, not sure if I'm missing some endian swaps there.

I am having trouble with some numbers, they don't make sense!

Let's say it is 2009, difficulty is 1, you are mining with your Core 2 duo E7300 CPU (the CPU of that time [1]) which gives you a hashrate of 3 (rounded up from 2.52) MHash/s [2] to find block #3 [3]
Nonce max value is 4,294,967,295 and to go through a whole set of hashes takes:
4,294,967,295 hash / 3,000,000 Hash/sec = 1,431 sec = 23 minutes.

Block #3 was found in ~7 minutes which is the result of calculating 4,294,967,295 hashes more than once (since the nonce in coinbase was changed).

[1] https://www.computerhope.com/history/processor.htm
[2] https://en.bitcoin.it/wiki/Non-specialized_hardware_comparison
[3] https://www.blockchain.com/btc/block-height/3

Something like this would be great:

Code:

IF
  [statements]
  IF
     [statements]
  ELSE
     [statements]
  [statements]
ELSE
  [statements]

I can come up with tests myself but then I wouldn't know if it is actually correct (does bitcoin-core RPC work for checking?).
Checked bitcoin-core tests[1] but couldn't find any test cases for non-regular scripts, all of them seem to be for normal (standard) scripts used in regular transactions.

[1] https://github.com/bitcoin/bitcoin/blob/63b9efa73d6bec280241fe0fa06abf7e5b4dde8d/src/test/script_tests.cpp
and txcreatescript... files here https://github.com/bitcoin/bitcoin/tree/master/test/util/data

The SHA256 implementation that bitcoin-core is using has a different set of functions for CH and MAJ operations done in this hash function. While they both are nice little optimizations for skipping 1 bitwise operation, I can't figure out the mathematical proof for them being the same.

For reference:

Code:

CH = (x & y) | ((~x) & z)
CH_alt = z ^ (x & (y ^ z))

Code:

MAJ = (x & y) ^ (x & z) ^ (y & z)
MAJ_alt = (x & y) | (z & (x | y))

CH and MAJ are the functions from FIPS 180-3 while CH_alt and MAJ_alt are from bitcoin-core source code