Topic: How is data integrity ensured on the bitcoin network (Read 278 times)

I hope if I can simplify the question raised in respect to the issue of Data integrity in the Bitcoin ecosystem. Well of course, transactions on this platform is the best by virtue of the fact that industrial revolution has since been overtaken by telecommunication revolution in this age. Most persons are willing to migrate to this clime, but are jittery due to much computer based inputs which majority are still illiterate. Therefore, the integrity of the processes are questioned, so the owners of the system should engage the uniformed public on reliability and sustainability of the transaction details that involves people hard earned money. Otherwise, it is the best medium for financial transaction in this recent times.

It isn't exactly the problem, because Bitcoin solves both double spending and the byzantine general problem. The existence of 51% attack doesn't invalidate both of them.

It is true that you are able to exploit the network and in a sense "reverse" a transaction that was previously included in a longest chain on the network. However, it is also true that in any of the longest chain of the network, you can only spend a single UTXO, or unspent transaction output exactly once. Hence, by the exact technicalities of double spending, it isn't considered double spending.

To the point about double spending, the issue would be whether it is worth it for any attacker to execute such an attack on Bitcoin. The amount of hashpower required to execute the attack is rather high, and for a potentially low reward. Most exchange or big services requires a number of confirmations before they would credit the deposit. Hence, it is likely that an attacker would require 51% of the hashpower to execute a worthwhile attack successfully.

For a sustained attack, you would likely have to invest in tens, or even hundred of millions of resources for an extended period of time. This is very costly and there is no chance that zero precautions would be taken against the attacker, by the merchant for a transaction of this size. In addition, consider that the Bitcoins that are double spent would essentially be worthless after the attack with the community's response. Even if the attacker is a government entity that wants Bitcoin's demise, I doubt the impact would be significant enough such that Crypto would be killed off forever.

One thing about anything digital is there No impossibility but rather the possibility of it happening is sometimes to small like in this case,

Yes should this act be able to possible or carried out, double spending will definitely be possible because all you need is to just remove the old transaction from the altered block and then perform a new transaction again but as it is said above its possibility is nearly zero. Having to recalculate the proof of work on one block isn’t easy and not to talk of other blocks. This one area where the decentralization of bitcoin network and the proof of work protocol is much appreciated. No matter the number of hash power a single node cannot utterly control the network just like that

"Unauthorized" isn't the appropriate adjective to call it. Transactions are timestamped, irreversible. They are not irreversible unless authorized. Any transaction which complies with the consensus rules and has enough confirmations is, by the protocol, authorized-- "valid". An attacker who would use computational power to reverse transactions is authorized as well, again from a protocol perspective.

To authorize, you need to permit. Bitcoin is permissionless.

I actually thought the answer to this would be ‘not possible’ but instead, what I see is means and criteria for this to occur by altering some part of the hash in a supposedly interconnected blockchain network.

Wouldn’t this likely possibility create room for double spending and therefore, allowing counterfeiting which is a problem of currency with this being the exploited option for digital currency?

Blocks have interconnected cryptographic hashes which prevent them from being altered unless some mining entity  would  seize enough computational power  (> 51% of network hashrate) to do this.

It is envisaged that  when Stratum V2 will entirely replace V1 the threat of hashrate concentration will be considerably reduced.

During confirmation (as in when miner/pool create a block)? It's possible since miner/pool can choose to include any valid transaction to their block.
During validation (as in verify transaction/block follow Bitcoin protocol)? No. If you do that, the block would be deemed invalid and rejected by Bitcoin nodes.


Even if you have 51% or more hashrate, you can't make alteration however you want since you still need to create block which doesn't violate Bitcoin protocol.

Yes, miners simply update it on the fly.

Those selected unconfirmed transaction are arranged to build a "Merkle Tree" and hashed in pair to get a "Merkle Root". (more info in the link below)
Then that merkle root hash is included to the "Block Header" which is included to the block itself.
The block header is also hashed with SHA256x2 to generate a hash that's lower than the target (a.k.a.: mining)

Now to the question;
If a miner added or removed a transaction included to that candidate block, the merkle root in its block header will be different from the newly computed merkle root.
In that case, a miner will just have to update the merkle root with the updated merkle tree.
And obviously, it has to be done before the block header is hashed during mining.

Read this to see how the merkle root is computed from the tree and to know why it's not computationally expensive to compute a new merkle root.
Link: https://learnmeabitcoin.com/technical/merkle-root

In the "Block" "Chain", the previous block's hash is included to the 'block header' of the block next to it.
So, if you change something in any of the block, its block hash will be different from the hash in the next block, that'll break the chain.

RBF doesn't actually result in the transactions being changed. RBF is used as a method for a transaction to be replaced in the mempool, neither the original transaction or the new transactions are modified. In fact, you don't even have to use RBF if a miner is directly able to mine another transaction for you.

You cannot change the consensus rules of Bitcoin even if you control all of the miners on the network. However, if you were to build blocks faster than the rest of the network, you can execute a 51% attack with a 100% certainty. That doesn't mean that you cannot do so with hashrates below 51%, it would just mean that the success rates would be lower.

Cryptographic hash functions are an one-way (usually not reversible) digest of some input data. E.g. SHA-256 gives you a 256 bits digest of your input data, where the input data can be of any length. A common property of such hash functions is that if you change a single bit in the input data, leaving everything else the same - i.e. input data length, the hash digest changes completely and significantly.
Another inevitable property of hash funcions is the existence of so-called hash collisions. Because the input data space is vastly larger than the hash digest space, there must exist multiple different input data that generates the same hash digest. But it is computationally very expensive to find such hash collisions. To my knowledge this has been achieved for SHA-1 and MD-5 but not yet for SHA-256 or RIPMD-160.

What secures a Bitcoin block? Hashes...
A Bitcoin block consists of an 80-byte header and transaction data. Such a block header contains some data and most importantly the previous block's header hash and a so-called Merkle tree root hash of all transactions in the block and some additional data, I'll try to be brief here. Transaction data is hashed via a Merkle tree into before mentioned Merkle tree root hash and this ensures that no single transaction can be modified in a block without invalidating the Merkle tree root hash.

A Bitcoin block is valid when its double SHA-256 hash of the block header is smaller than a defined target value where the target value is also part of the block header.

This is very brief and maybe need some time to sink in but in essence you can't change any single bit in a Bitcoin block without being noticed or invalidating some specific hashes. This makes the blockchain immutable because blocks are linked together by the fact that every block has the block hash of the previous block (with the exception of the Genesis block because it doesn't have any predecessor block).

If someone wants to change the blockchain they would need to recalculate and do all the vast amount of Proof of Work for the block they want to change and all its following blocks while all the miners on this planet don't care about their nefarious change and continue to do hash work from the tip of the blockchain. Unlikely someone is able to outcompete fair miners as Proof of Work encourages fair mining.

From the little knowledge I have, hashing algorithms ensure data integrity by producing a digest of a message, such as MD5 or SHA-1.However, without additional measures, it is likely that the message could be intercepted and modified. To prevent this from occurring, both parties establish a mutual secret key, combining it with the message to calculate a digest. This combined key-message digest ensures both message integrity and authentication.

I don’t quite get this question but if you’re asking weather if a transaction before confirmation can be changed I will say in a way yes it can be done and an example is an RBF done on a transaction to another transaction, this is a change since it is transferred to another other address other than the first intended one by increasing the transaction fee.

But if your question is about weather block can be altered after it has been added to the blockchain, I will say it is possible but definitely hard most especially if the block is down on the blockchain (multiple blocks have been built upon it) this is because blocks that comes after there predecessors usually have the details (block hash or header) of the previous block. So altering one particular block on the blockchain can actually affect the ones built upon it that’s why you see that people simply say it is better to accept transactions with Atleast six confirmations, because the deeper the block In the blockchain harder the alteration.


I will say alterations doesn’t happen due to decentralization of the bitcoin network, if a particular node wants to carry out something not proper on the network other nodes will simply reject and since bitcoin works on consensus you can alter any thing like that maybe till you control more than or 52% of the total network hash power

Not being encrypted means that the public can read the information, making it a public server. This does not mean that the public can alter the data which is stored on it.

as I take on my journey to understand bitcoin I once again faced with a little difficulty and I would appreciate more explanation....
According to my study and previous question, I was made to understand that blocks and transactions are not encrypted on the blockchain. If this is so, Is it possible or allowed to make changes to a block when transactions are included during confirmation or validation?

Also Since transactions are being recorded, what means prevent unauthorised data changes or modifications to ensure data integrity on the network? Because during my research I learned about cryptographic hashes being the reason why blockchain is immutable but understanding hashes and cryptography is very challenging for me I need a little help here