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 ...


9

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 ...


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.


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 ...


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

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

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 ...


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 ...


3

I think all big miners have own developed software to manage mining process and able to switch to recently received block header before validation is complete. Block validation process should not take a lot of time, because most of transactions from block already in mempool and already verified. Validation task is verify missed transactions, verify coinbase, ...


3

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 ...


3

There is no such thing as "the bitcoin memory pool". Every node has its own memory pool; it is not shared across all nodes in the network. A node can certainly add a transaction to its own mempool without validating it, but you cannot force other nodes to add a transaction to its mempool without validation. In fact, you can't force a node to add a ...


3

Existing signature schemes in Bitcoin are already implemented as opcodes (OP_CHECKSIG and OP_CHECKMULTISIG in particular), so this question's formulation seems a bit off. If you don't mind a transaction whose outputs can be taken by anyone, this is trivial - you can just create an output with a script that does not use any signature checking opcodes. ...


3

A bitcoin transaction is valid if it conforms to all of the bitcoin protocol rules. Likewise, a block is valid if it conforms to all of the bitcoin protocol rules (including: all of the transactions it contains are valid). ‘Validation’ of a block or transaction happens at the level of each individual node (miners and regular nodes alike). Validating a ...


3

The rules are set by the nodes on the network. The rules are coded into node software which users run. These rules are not necessarily set by the creator of the network as they can be changed if all of the users agree to change the rules by running different node software.


3

Nodes are just software, at the end of the day. The Bitcoin Core software will automatically relay standard valid transactions provided they meed the minrelayfee. It would be fairly trivial to modify the software to relay only if certain other rules are met, however. You could easily do this without impacting the rest of the node functionality. Usually, ...


3

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, ...


3

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 ...


3

Your question doesn't actually provide enough context even with the proviso that you don't care about which machine specifically. Do you mean cold-cache during initial block download or do you mean at the tip of the chain on a running node? The difference on this point is probably two orders of magnitude in speed. Usually, at the tip almost no transaction ...


3

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 ...


3

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 ...


3

They don't need to. If a block's timestamp is in the future, it won't be accepted - but it also won't be marked as invalid. Once enough time passes, the node will accept the block if it is offered or received again. Effectively, the maximum limit on the timestamp is not a consensus rule, but just a temporary acceptance rule.


3

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. ...


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