Make your algorithms to derive private keys. For example,
Passphrase: Who is Satoshi?
H1 = SHA512(Who)
H2 = SHA512(is)
H3 = SHA512(Satoshi)
H4 = SHA512(?)
Seed = SHA512(H1+H2+H3+H4)
Serial number: 1,2,3…
Private key 1: SHA256(Seed + SHA512(1))
Private key 2: SHA256(Seed + SHA512(2))
You also can make replacement or cropping modifications to the hash values. This brain wallet generator can convert the seed to mnemonics according to BIP39. You can make your derivation algorithms to generate private keys. Download this brainwallet program onto an offline device, and then generate private keys.
You should record the key information of your algorithms in a certain place and practice the process of generating private keys at regular intervals to ensure that you can firmly remember your brain wallet. At the same time, compile the seed mnemonics into a story to facilitate memorizing the mnemonics and achieve a double insurance for memorizing the brain wallet.
Warning: Don't use the private key = SHA256(Who is Satoshi?) to generate your address!!! That's very dangerous. Some people have created large databases of phrase-address correspondences and constantly monitor the balances on these addresses. Once you transfer Bitcoin to these addresses, it will be instantly stolen.
First, download this brain wallet program onto an offline mobile phone. And then,
Step 1: Online transaction construction. This brain wallet program can construct Bitcoin transactions online, and generate hexadecimal strings of unsigned transactions and corresponding QR codes.
Step 2: Offline transaction signing. Scan the QR code generated in the first step with an offline phone, and use this brain wallet program downloaded on the phone to generate the corresponding private key to sign the unsigned transaction, and generate a signed transaction string and its corresponding QR code.
Step 3: Online transaction broadcasting. Scan the QR code generated in the second step with an online phone and broadcast the transaction.
Entropy of mnemonic words: The entropy of 12 mnemonic words is taken from the first 32 bits of 【Entropy】, and the entropy of 24 mnemonic words is taken from the first 64 bits of 【Entropy】.
Almost all 64 bit hex strings can be used as private keys. The range of values for legitimate private keys is (0,FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141)
0x80(Main Net)，0xef(Test Net)
0x01 - Compressed Private Key, Empty Value - Uncompressed Private Key.
Add the version number prefix and compression flag suffix to the private key, and then perform SHA256 twice (before SHA256 each time, the hexadecimal string needs to be converted to 256 bytes, rather than directly hashing the hexadecimal string twice), taking the first 4 bytes.
Compressed public key: Prefix (if y is even, prefix is 02; if y is odd, prefix is 03)+X coordinate (32 bytes); Uncompressed public key: Prefix (04)+X coordinate (32 bytes)+Y coordinate (32 bytes).
0x00 - Main Net; 0x6f - Test Net.
Add the version number prefix to the address, and then perform SHA256 twice (before SHA256 each time, the hexadecimal string needs to be converted to 256 bytes, rather than directly hashing the hexadecimal string twice), taking the first 4 bytes.
Balance API URL
Balance (BTC)
UTXO API URL
Enter the sequence number or range of UTXOs used to construct transactions, separated by commas in English, for example: 1,4-10,12.
The sum of the balances of the selected UTXO (BTC)
1. For situations where there is change, the default change address is the issuing address!
2. If the public key is filled in, the locking script is P2PK.
Received Amount (BTC)
By default, set the nSequence of all inputs in a transaction to the same value of 0xfffffffd (2^32 - 3 = 4294967293). This activates both the Replace-By-Fee (RBF) function and the absolute time lock (nLockTime).
RBF Function Activation: When a transaction with a low fee remains unpacked, users can initiate a new transaction with a higher fee to replace the previously broadcast low-fee transaction. This allows dynamic fee adjustment to ensure timely block confirmation.
Absolute Time Lock Activation: The nLockTime feature can be used to construct transaction strings for inheritance planning, enabling transactions to be executed only after a specified absolute time or block height.
If different values are required, manually modify them in the JSON transaction string.
The interlocking relationship between the relative time lock (nSequence) and the absolute time lock (nLockTime):
(1) If the nSequence of all inputs (UTXOs) in a transaction is equal to 0xffffffff (2^32 - 1 = 4294967295): Neither nSequence nor nLockTime is activated. The nLockTime set in the transaction will be ignored, which means the absolute time lock is ineffective.
(2) If the nSequence of one or more inputs in a transaction is less than 0xffffffff and greater than or equal to 0x80000000 (2^31 = 2147483648): nSequence is not activated, and only nLockTime is activated.
(3) If the nSequence of one or more inputs in a transaction is less than 0x80000000: Both nSequence and nLockTime are activated.
Prerequisite for the effectiveness of nLockTime: In a transaction, at least one input (UTXO) must have a nSequence value less than 0xffffffff (2^32 - 1 = 4294967295).
The value of nLockTime has the following meanings:
nLockTime = 0: It means no locking.
nLockTime < 500 million: It represents the absolute block height.
nLockTime >= 500 million: It represents time, with the unit being seconds.
A transaction will only be accepted by the network when the block height is equal to or greater than the specified block value, or when the time is equal to or after January 1st, 1970, 00:00:00 plus the number of seconds specified by nLockTime.
1. Transaction Hash (tid): (1) Does not include the HashType. (2) For witness transactions, does not include the witnessFlag (0x0001) or the witness signature portion.
2. Locking Script:
(1) P2PK (Pay-to-Public-Key): OPCODE_LEN pubKey OP_CHECKSIG (0xac)
(2) P2PKH (Pay-to-Public-Key-Hash): OP_DUP (0x76) OP_HASH160 (0xa9) OPCODE_LEN pubKeyHash OP_EQUALVERIFY (0x88) OP_CHECKSIG (0xac)
(3) P2MS (M-N Multi-Signature): OP_M OPCODE_LEN pubKey_1 OPCODE_LEN pubKey_2 … OPCODE_LEN pubKey_N OP_N OP_CHECKMULTISIG (0xae)
(4) P2SH (Pay-to-Script-Hash): OP_HASH160 (0xa9) OPCODE_LEN redeemScriptHash OP_EQUAL (0x87)
P2SH can implement various transaction types. The redeemScript matches the locking script of the target transaction type, and the unlocking script always ends with the redeemScript.
(4.1) P2SH-P2PK redeemScript: OPCODE_LEN pubKey OP_CHECKSIG (0xac)
(4.2) P2SH-P2PKH redeemScript: OP_DUP (0x76) OP_HASH160 (0xa9) OPCODE_LEN pubKeyHash OP_EQUALVERIFY (0x88) OP_CHECKSIG (0xac)
(4.3) P2SH-P2MS (M-N Multi-Signature) redeemScript: OP_M OPCODE_LEN pubKey_1 OPCODE_LEN pubKey_2 … OPCODE_LEN pubKey_N OP_N OP_CHECKMULTISIG (0xae)
(4.4) P2SH-P2WPKH redeemScript: VER (0x00) OPCODE_LEN (0x14) pubKeyHash
(4.5) P2SH-P2WSH redeemScript:: VER (0x00) OPCODE_LEN (0x20) P2WSHredeemScriptHash
P2WSHredeemScriptHash is the SHA-256 hash of the P2WSHredeemScript, not the Hash160 hash.
(5) P2WPKH (Pay-to-Witness-Public-Key-Hash): VER (0x00) OPCODE_LEN (0x14) pubKeyHash
(6) P2WSH (Pay-to-Witness-Script-Hash): VER (0x00) OPCODE_LEN (0x20) redeemScriptHash
4. OPCODE_LEN in Locking Scripts is not reflected in JSON format but is present in Raw format.
5. SegWit Version Number in P2WPKH: The leading "0" in the P2WPKH locking script is the SegWit program version number, which can be parsed as OP_0 (0x00).
6. OP_EQUALVERIFY vs. OP_EQUAL
OP_EQUALVERIFY = OP_EQUAL + OP_VERIFY:
* OP_EQUAL pushes the judgment result (true: 1 or false: 0) onto the stack.
* OP_VERIFY pops the result from the stack and aborts the script if the result is false (no value is pushed back).
P2PKH uses OP_EQUALVERIFY to pop true (1) and proceed to OP_CHECKSIG.
P2SH uses OP_EQUAL because P2SH executes in two stages: the first-stage result is checked via OP_EQUAL before executing the deserialized redeem_script in the second stage.
7. Input Amount in SegWit Signing
Due to SegWit's requirement to use the input amount during signing, the amount is appended to the end of the JSON format.
1. Signature Hash Types (4 bytes):
(1) ALL (1): This is the default signature type. It signs all inputs and outputs of the transaction.
(2) NONE (2): It only signs all inputs of the transaction and does not sign the outputs. Meanwhile, it sets the sequence of non - signing inputs to 0.
(3) SINGLE (3): It signs all inputs of the transaction and only signs the output with the same index value as the signing input. At the same time, it sets the sequence of non - signing inputs to 0.
(4) ANYONECANPAY (128, i.e., 0x80): Only the signing input is retained among the inputs. It is an optional attribute (not used by default), and this attribute is not used alone.
(5) ALL | ANYONECANPAY (129, i.e., 0x81): A combination of ALL and ANYONECANPAY.
(6) NONE | ANYONECANPAY (130, i.e., 0x82): A combination of NONE and ANYONECANPAY.
(7) SINGLE | ANYONECANPAY (131, i.e., 0x83): A combination of SINGLE and ANYONECANPAY.
2. After converting the SIGHASH flags (4 bytes) to little-endian encoding (such as 0x01000000), append them to the end of the Raw transaction string and sign them together.
3. Each input contains a signature in its unlocking script. Therefore, a transaction with multiple inputs can have multiple signatures with different SIGHASH flags, and these flags commit to different parts of the transaction in each input.
For source addresses starting with 3 (P2SH), since it is impossible to determine the locking type based on the "redeem script hash value" in the locking script, users are required to select the locking script type. (The default is P2SH-P2WPKH, which is an embedded single-signature SegWit address.) As the RAW formats of transactions with and without SegWit are different, it is necessary to know in advance whether there are SegWit inputs.
1. Serialization Order: version: 4 bytes (little-endian); witnessFlag: 4 bytes (marker: 0x00, flag: 0x01) (big-endian); tx_in_count: varint (little-endian); tx_hash: 32 bytes (little-endian); index: 4 bytes (little-endian); script_length: varint (little-endian); script: string (big-endian); sequence: 4 bytes (little-endian); tx_out_count: varint (little-endian); value: 8 bytes (little-endian); script_length: varint (little-endian); script: string (big-endian); witness: string (big-endian); locktime: 4 bytes (little-endian); hashtype: 4 bytes (little-endian).
(1) For non-SegWit transactions, both witnessFlag and witness do not exist.
(2) witness serialization order: stack_items_num: varint; item_1_length: varint; item_1: string; item_2_length: varint; item_2: string; … item_n_length: varint; item_n: string.
Each input corresponds to a witness item. For non-SegWit inputs, there is only stack_item_num, and its value is 0x00.
2. The following Raw transaction string is fully converted from the above JSON and contains all the information required for signing, but it cannot be directly used for signing.
(2.1) Serialization rules for non-SegWit transactions used for signing:
(1) ALL(1): Before signing a certain input, the script of other inputs needs to be set to empty, and script_length should be set to 0.
(2) NONE(2):
Input part: Before signing a certain input, the script of other inputs needs to be set to empty, script_length should be set to 0, and sequence should be set to 0.
Output part: The output should be set to empty, and tx_out_length should be set to 0.
(3) SINGLE(3):
Input part: Before signing a certain input, the script of other inputs needs to be set to empty, script_length should be set to 0, and sequence should be set to 0.
Output part: Outputs with an index lower than the index of the signing input are set to empty, i.e., value is set to - 1 (equivalent to 0xffffffffffffffff because it is the complement of - 1), script is set to empty, and script_length is set to 0. Outputs with an index higher than the index of the signing input are deleted. Special case: When the number of inputs is greater than the number of outputs, for the "extra" inputs, directly sign 0x0000000000000000000000000000000000000000000000000000000000000001.
(4) When used in combination with ANYONECANPAY:
Input part: Only the input to be signed is retained, i.e., the value of tx_in_length is 1.
Output part: The same as above.
(2.2) Serialization rules for SegWit transactions (WitnessV0) used for signing:
(2.2.1) ALL(1):
(1) nVersion of the transaction (4-byte little-endian)
(2) hashPrevouts (32-byte hash)
(3) hashSequence (32-byte hash)
(4) outpoint (32-byte hash + 4-byte little-endian)
(5) scriptCode of the input (serialized as scripts inside CTxOuts)
(6) value of the output spent by this input (8-byte little-endian)
(7) nSequence of the input (4-byte little-endian)
(8) hashOutputs (32-byte hash)
(9) nLocktime of the transaction (4-byte little-endian)
(10) sighash type of the signature (4-byte little-endian)
【Very important】For P2WPKH and P2SH-P2WPKH, scriptCode is filled with the script length + P2PKH; for P2WSH and P2SH-P2WSH, scriptCode is filled with the script length + SegWit script.
(2.2.2) When used in combination with ANYONECANPAY, hashPrevouts is set to 0000000000000000000000000000000000000000000000000000000000000000.
(2.2.3) When used in combination with ANYONECANPAY, NONE or SINGLE, hashSequence is set to 0000000000000000000000000000000000000000000000000000000000000000.
(2.2.4) (NONE) or (SINGLE and the output index is higher than the signing input index), hashOutputs is set to 0000000000000000000000000000000000000000000000000000000000000000.
3. The Raw transaction string to be signed already contains the SIGHASH flag.
4. Since the input amount is required during SegWit signing, the amount is appended to the end of the RAW format.
The default private key can be used to simulate signatures to confirm whether the transaction fee is reasonable.
1. The "signature hash type" (occupying 1 byte) will be appended to the end of the signature information string.
2. Signature Formats:
(1) P2PK (Pay-to-Public-Key): OPCODE_LEN Signature
(2) P2PKH (Pay-to-Public-Key-Hash): OPCODE_LEN Signature OPCODE_LEN pubKey
(3) P2MS (M-N Multi-Signature): OP_0 OPCODE_LEN Signature_1 OPCODE_LEN Signature_2 … OPCODE_LEN Signature_M OPCODE_LEN redeemScript
(4) P2SH (Pay-to-Script-Hash):
P2SH can be used to implement various transactions. Its redeemScript is the same as the locking script of various transactions, and the unlocking script is the unlocking script of various transactions plus the redeemScript.
(4.1) P2SH-P2PK: OPCODE_LEN Signature OPCODE_LEN redeemScript
Where the redeemScript is: OPCODE_LEN pubKey OP_CHECKSIG(0xac)
(4.2) P2SH-P2PKH: OPCODE_LEN Signature OPCODE_LEN pubKey OPCODE_LEN redeemScript
Where the redeemScript is: OP_DUP(0x76) OP_HASH160(0xa9) OPCODE_LEN pubKeyHash OP_EQUALVERIFY(0x88) OP_CHECKSIG(0xac)
(4.3) P2SH-P2MS (M-N Multi-Signature): OP_0 OPCODE_LEN Signature_1 OPCODE_LEN Signature_2 … OPCODE_LEN Signature_M OPCODE_LEN redeemScript
The extra OP_0 here is due to a bug in OP_CHECKMULTISIG, where the actual number of parameters to be popped is 1 more than expected.
Where the redeemScript is: OP_M OPCODE_LEN pubKey_1 OPCODE_LEN pubKey_2 … OPCODE_LEN pubKey_N OP_N OP_CHECKMULTISIG(0xae)
(4.4) P2SH-P2WPKH (Pay-to-Script-Hash-Pay-to-Witness-Public-Key-Hash): OPCODE_LEN redeemScript
Where the redeemScript is: VER(0x00) OPCODE_LEN(0x14) pubKeyHash
witness: stack_item_num(varint:0x02) signature_length(varint) Signature pubkey_length(varint:0x21) pubKey
(4.5) P2SH-P2WSH (Pay-to-Script-Hash-Pay-to-Witness-Script-Hash): OPCODE_LEN redeemScript
Where the redeemScript is: VER(0x00) OPCODE_LEN(0x20) P2WSHredeemScriptHash
The P2WSHredeemScript of P2SH-P2WSH-P2MS: OP_M OPCODE_LEN pubKey_1 OPCODE_LEN pubKey_2 … OPCODE_LEN pubKey_N OP_N OP_CHECKMULTISIG(0xae)
The witness of P2SH-P2WSH-P2MS: stack_item_num(varint:1+M+1) OP_0 signature_1_length(varint) signature_1 signature_2_length(varint) Signature_2 … signature_M_length(varint) Signature_M P2WSHredeemScript_length(varint) P2WSHredeemScript
(5) P2WPKH: Empty (script_length:0x00, reflected in the raw format)
witness: stack_item_num(varint:0x02) signature_length(varint) Signature pubkey_length(varint:0x21) pubKey
(6) P2WSH: Empty (script_length:0x00, reflected in the raw format)
The witness of P2WSH-P2MS: stack_item_num(varint:1+M+1) OP_0 signature_1_length(varint) signature_1 signature_2_length(varint) Signature_2 … signature_M_length(varint) Signature_M P2WSHredeemScript_length(varint) P2WSHredeemScript
Fees: sat/vB
Check the reasonable fees on https://bitcoinfees.net
Mainnet Broadcast URL: https://blockstream.info/tx/push
Testnet Broadcast URL: https://blockstream.info/testnet/tx/push
This only supports signing and verifying hexadecimal information. If the information you provide is not in hexadecimal, you can convert the information to be signed into hexadecimal through binary conversion or hash function before signing.
1. Actually, it is to sign the double hash value SHA256 (hexTobytes (SHA256 (hexTobytes) to be signed). 2. For security reasons, random numbers are introduced during the signature process. When signing the same information, the signature value changes every time, but each signature value is valid.