Blockchain mechanics - Test

Using a native node function to get a random number

By hashing the newest block's content to get a value no one can predict.

Every node must compute the same value, so you can't.

You can't. Generating a random number is too computationally heavy an operation

Exactly one. The fork-choice rule stops a second branch from ever forming.

At most two, which is why a split is called a fork.

A fixed maximum set by the protocol's configuration.

Any number. The protocol sets no limit.

Yes. 6 confirmations is the industry standard and stops any reasonable attacker

Yes. To reverse a 6-deep block, the attacker would need 50%+ capacity

No. A 30% attacker has a real chance of reversing a 6-deep transaction

No. Confirmations don't actually reduce the chance of reversal

Voting between thousands of nodes would be too slow for a real-time network

Anyone can spin up thousands of fake nodes and outvote honest ones

We can vote, but each node first needs to verify its identity with a central authority

Without a designated leader to count votes, the network has no way to declare a winner

The block is moved to long-term storage that cannot be edited

The block's hash would change, breaking the prev_hash in every later block

Old blocks are signed by a majority of nodes once a year and locked

The attacker needs to control 51% of nodes to make a change

Yes, if they have different software versions

Yes, if they receive the transaction at slightly different times

No, validation of the same transaction produces the same result

Yes, if they're located in different timezones