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


10

It has no transactions other than the coinbase transaction. However, the transaction's coinbase output is 0 BTC. Here's the valuable piece of information that you are looking for: Coinbase outputs may be set lower than the max. value (12.5 currently), and the block will be valid (if the difficulty is lower than the target, as always) Also look at: https:/...


9

You can't delete the block data themselves, but you can reset the blockchain state to a specific block by using the invalidateblock command. This command will mark a specific block and its descendants as invalid thus setting the chainstate to the block immediately before it. Note that this may not necessarily work to switch to a blockchain fork and may still ...


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


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

Invalid transactions are never included in valid blocks. They can be included in a block, but that block would be rejected as invalid (and not classified as an orphan block).


4

This isn't possible because every node in the network enforces the consensus rules. A miner is only allowed to include 1 transaction that moves coins with no previous inputs, which is the coinbase transaction. The output value of the coinbase transaction must not exceed the block reward plus any transaction fees from transactions in that block. If the ...


4

Can anyone elaborate on what it means exactly, please? It just seems like a weird phrasing for saying that the miner has complete control over which transactions are included in the blocks they mine. Does it really mean that those particular miners who mined the block can do whaterver they want with that block, like setting txs fees and putting txs? What ...


4

what happens if my transaction is in the fake block? It is also in the memory pool (mempool) of pending transactions at other nodes run by more honest people and will be included in a new and valid block in the normal way. Let’s suppose I am buying a Tesla car. Should I wait 6 blocks to be generated to be sure? But I have to wait 1 hour! Yes. There are ...


4

An attacker can forge fake block. Yes, but an invalid block would be rejected by all other participants that see it, and not relayed. Thus, such a block has little to no impact. This is great but what happens if my transaction is in the fake block? Let’s suppose i am buying a car. Should i wait 6 blocks to be generated to be sure? But I have to wait one ...


4

The hash is a result of computing two rounds of SHA256 on the block header. If you set the hash yourself, when other nodes try to verify the hash by performing the aforementioned computation, it will not (however, there is an infinitesimal chance) result in "63 zeros followed by a 1". I suggest reading about hash functions. The only reliable way to create ...


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 rule is that the longest* valid chain is considered the active one. If you build a forking branch with invalid transactions in it, the network (in particular, all full nodes - including miners) will simply ignore it. If it's invalid, it does not exist. Blocks are not relayed to peers before validating them entirely. You may be able to temporarily fool ...


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

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

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

No, miners can't do what they want. The miners operate within the tight rules of what is accepted as a valid block. Instead of the "temporary dictator" phrasing, one could say that the mining process randomly elects an author for each block. Every time a miner attempts to create a block, they create a new block template with what they perceive or want to ...


3

By definition a node's idea of the blockchain is among all valid versions of history the one with the most total proof of work. Because chains are required to be valid, it is not possible to have a block in there that violates consensus rules. It doesn't matter what miners do; full nodes will still ignore the block entirely, as if it was never created.


2

As stated above many miners today already start mining using only the new blockheader before the block is validated and downloaded. This is why you sometimes see newly generated block with only one transaction (the coinbase transaction). An example of this is the following block: https://blockchain.info/block/...


2

As long as everyone follows the same rules, mining is convergent, because the expected interval of ten minutes allows every full node to catch up to the current state of the network. Separate p2p networks (altcoins) derive from a different set of rules, where one of the rules is the Genesis block of the blockchain. Since their Genesis block is different and ...


2

Block contains "RSKBLOCK:Ý¿QzßýKÊwQP[9É: ÔyüN9ÝW³GÆ$", so I think that it is related to www.rsk.co. Probably Sidechains synchronization. EDIT: Binary hex: "52534b424c4f434b3addbf517adf8ffd4bca7751505b39c9013a0d1fd479fc4e901b39dd57b347c624" Source: https://blockchain.info/tx/9bf8853b3a823bbfa1e54017ae11a9e1f4d08a854dcce9f24e08114f2c921182?show_adv=true


2

No, each block must reference it's predecessor block in the header, and the blockchain has only a single block at each height. The second miner must therefore modify the block template that they are mining with to build on top of the just discovered block. They need to update the hash of the predecessor block and the blockchain height in the Coinbase ...


2

The mining algorithm does nothing to prevent this. However, the mining algorithm is just a part of the larger consensus algorithm. This is the algorithm that is not just implemented by a single participant, but by the network as a whole. If a block includes a transaction that says "Alice sent me 100 bitcoins", it would need to contain a valid signature ...


2

There is no guarantee that when a full node adds a block to its main chain that other full nodes have done so. However there is no need for a node to know that in order to add a block to its main chain; it simply has to validate the block according to its consensus rules before adding it to its main chain. If everyone follows the same consensus rules, then ...


2

First of all, proof of stake is not a single algorithm. There are many different implementations. For example, the algorithm that is used in Cardano is completely different from the one that is used in Peercoin, which is quite close but still different from e.g. Blackcoin algorithm, which has been derived from Peercoin. Qtum, for example uses Blackcoin ...


2

Edit: this answer is written assuming you are asking about ‘SPV’ or ‘light wallet’ implementations, not a full node implementation How do I know that that particular (malicious) node has the most recent or valid blockchain? This is two separate questions: are you up to date? And is the info valid? Up to date: it is possible for light wallets to query ...


2

But the Merkle Root is not enough to prove a transaction is in a block. All the sibling-values up the Merkle Tree are needed. Where do these values come from if they aren't already stored? Any full node that has a complete copy of the block can construct a merkle proof that proves a requested transaction identifier (txid) connects to the merkle root in a ...


1

This is a good question. Your best bet is two-fold: Connect to known peers. These are hard coded as DNS seeds in the full-node application. See chainparams.cpp #L132 Connect to many peers to get as much of a view into the network as possible. If you don't do these 2 things it's possible you get connected to an invalid side-chain rather than the more ...


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