15

Yes, one validation per block, but not one signature per block. To clear up confusion, there are 3 distinct technologies involved here: (1) non-interactive aggregation is the ability for a third party (who does not hold any private keys) to combine multiple signatures, each with their own message and public key, into a single signature that can be verified ...


12

There are several questions here. Please correct me if I'm wrong: The miner validates the newly received block before using it themself and sending it to their other connected peers. Yes and no. Note that by miner we're talking about people who build blocks themselves - that includes solo miners, pool operators, and p2pool users. Hashers that only ...


12

You're right that the elliptic curve multiplication is indeed the most expensive operation in the validation algorithm. And as both single signature validation and batch validation require two EC multiplication per signature, it would seem that no speedup can be gained from batching. However, several algorithms are known for computing the sum of multiple EC ...


11

SPV mining is the term commonly used for 'less-than-full-node-validation' mining. It usually means that miners skip the verification of the block and the transactions within, and immediately start mining a new block referencing the just-solved block header. However, since they don't know what is in the last block, they have to mine without any transactions (...


8

A is protected by adding coinbase transaction with himself's bitcoin address. from https://en.bitcoin.it/wiki/Block_hashing_algorithm The body of the block contains the transactions. These are hashed only indirectly through the Merkle root. Because transactions aren't hashed directly, hashing a block with 1 transaction takes exactly the same amount of ...


7

When you spend from a Bitcoin address, your transaction includes both the public key corresponding to the hashed address you're trying to spend from, as well as a signature that can be verified with that public key. Your link is to a block, which is not signed itself. However, let's look at a transaction from your block: https://www.blockchain.com/btc/tx/...


7

How strict are the time validation rules? Very. If the next block is mined more than 2 hours after the current block, would this not stall the blockchain? No. It doesn't break the rule "Full nodes will not accept blocks with headers more than two hours in the future according to their clock." Nor does it break the rule "Must be strictly ...


6

A transaction can go in a block if it's valid (references inputs that are already in the same or previous blocks, scripts are legal and return success, and signatures validate ok), regardless of whether any other nodes have ever seen it before or not. So if a "selfish" node associated with a particular miner receives a transaction, it's perfectly free to ...


6

If you call bitcoin.address.toOutputScript(address, bitcoin.networks.bitcoin) It will throw an error if the address cannot be parsed as P2SH or P2PKH, or if the checksum is not valid. Replace the second argument with bitcoin.networks.testnet for testnet.


6

you can find explanation here: https://bitcointalk.org/index.php?topic=5095376.msg49150302#msg49150302 the issue was actually with OP_RETURN. What OP_RETURN used to do is it would skip to the end of the script so whatever was on the stack was interpreted for the final script result. So what you could do was create a scriptSig that was just OP_TRUE ...


6

Bitcoin Core does validate all signatures after a certain point, and can be configured to validate all signatures in history if so desired. The assumevalid feature only disables signature validation for blocks prior to a specific configured block which is updated for each version. This block is typically several (tens of) thousand blocks deep by the time the ...


6

I think you have a misconception about what this clause means: Full nodes will not accept blocks with headers more than two hours in the future according to their clock. You appear to be interpreting this as, if a new block is more than two hours later than the previous block, then do not accept it. That is incorrect. This clause is not about gaps in time ...


5

1, 2 and 3. Transactions that arrive through inventory announcements on the network are validated completely by checking the form of the transaction for sanity, executing the script, checking signatures, ensuring that the outputs they are spending actually exist, and that the transaction doesn't end up making negative values anywhere. If they are accepted ...


5

A transaction that has been included in a block does not need to be in a node's mempool in order for that node to validate the block. Each block contains the transactions, so by downloading and validating a block, the node will have received a copy of all transactions in it (so that it can validate the transactions, as part of validating the block). As you ...


5

This is intentionally not possible. If a transaction would be valid in block X, we want it (absent double spend) to remain valid in any successor of X. This guarantees that (temporary, otherwise harmless) forks that result in small reorgs will never invalidate unrelated transactions - and they will just be able to be mined again in the new branch. It also ...


4

This seems a lot of effort for absolutely no benefit. In the Bitcoin pruning model you discard ALL those old blocks anyway, and JUST keep the utxo set. It doesn't matter whether a utxo is in an old block or a new block, you're still keeping it in the utxoset. Any blocks you keep around is merely for convenience and to assist other nodes that request those ...


4

If it is the format and the checksum then that can be easily done. Specifically you can use steps 4 to 9 in the technical description of Addresses to check for typos. Beyond that however it gets difficult If you want to access blockchain information such as the current balance you cannot unless you have a copy of the blockchain somewhere, and on a phone or ...


4

Whomever originates the transaction (the sender) wants their transaction completed as quickly as possible, especially if they attached a big "incentive" (fee) to it. So they will announce their transaction to many other nodes. Nothing really forces those nodes to share the transaction with all other nodes, although they are supposed to share it. But the ...


4

A schnorr signature, without key prefixing, is a tuple {pubkey (P), message (m), R, s} where the equation R == sG + H(R||m)P holds. Now, assume you have pubkeys P and P2 who's discrete logs differ by c which is known to me, as is the case for non-hardened BIP 32 when I know the extended pubkey (P2 == P + cG). If I know a signature by pubkey P of message m, ...


4

A block consists of a header, and then a number of serialised transactions. The block header contains no script, it only contains data such as the merkle root of the transactions in the block (so the header commits to the list of transactions), nonce, version number, etc. Note that a block isn't encoded with JSON, it has its own serialisation format which ...


4

Speedup in well optimized cryptographic functions are hard to come by. In libsecp256k1 we'll usually celebrate a 4% algorithmic speedup. Figures on the order of 2x are reasonable for the usage in Bitcoin, though larger might be possible in the future during initial block download since much larger batches could be used. A single validation on a single core ...


4

I think your confusion comes from a slight misunderstanding of the reason a node validates all transactions/blocks. This validation is done so that the user running the node can join the network and verify the current state without needing to trust anyone else in order to do so. Importantly, it allows sovereignty, you do not need someone else’s permission ...


4

Nodes maintain multiple databases, they do not just store the blockchain and scan it every time it wants to do something. These databases include a block index (so that it knows where to find a block) and the UTXO set. The database containing the UTXO set is what matters here. That database contains the identifiers for every single UTXO and the UTXO itself. ...


4

When you spend Bitcoin in a transaction, the transaction must reference at least one existing unspent transaction output (UTXO) and provide a valid signature proving that you are authorized to spend it. The transaction then consumes the UTXOs in the inputs, and assigns value to newly created UTXOs in the outputs. Other network participants running a type of ...


4

The process of a transaction being created and included in the blockchain is as follows: The sender creates, signs, and broadcasts the transaction All Bitcoin full nodes, including miners and regular users, receive the transaction and validate it by making sure it follows the Bitcoin protocol rules Nodes temporarily store the unconfirmed/yet-to-be-mined ...


4

A bitcoin transaction will create outputs, which can later be used as input to a new transaction. Each output will be locked to what is called a scriptpubkey, which basically sets up the cryptographic puzzle that must be satisfied (ie, return true when run) in order for those coins to be spent. Any transaction spending those coins will need to provide a ...


3

There is no way to know which node created a transaction or block, unless they publish that information themselves. Nodes should not have an identity that leaks into transaction or block data. So banning for relaying invalid blocks or transactions always applies to the peer that gave you the information, based on their IP address. The protocol requires you ...


3

1) A Bitcoin address is between 25 and 34 characters long 2) the address always starts with a 1 (in this case) 3) an address can contain all alphanumeric characters, with the exceptions of 0, O, I, and l. (ref: https://thomas.vanhoutte.be/tools/validate-bitcoin-address.php) Now here comes the hard part: The last four bytes of the address are the first ...


3

Yes, but that is hard. This is known as a collision, and you would be finding a collision in SHA256. Because you would be reusing a known hash, what you would be doing is performing a preimage attack. Since SHA256 has no known preimage attack for all 64 rounds done in a normal SHA256 hash, you would need to do 2^256 hashes in order to be guaranteed to have ...


3

First, what you defining as public key and private key are actually a bitcoin address and a private key encoded in Wallet Import Format (WIF). In order to check that the WIF and the bitcoin addresses are from the same key pair, we will need to decode the private key from its WIF format (checking that the encoding is ok), derive the public key from the ...


Only top voted, non community-wiki answers of a minimum length are eligible