<p>Generally speaking, a larger block leads to more computational resources (tx validation, bandwidth, storage, memory) required for each person who wishes to validate newly confirmed transactions.</p>

<ul>
<li><p>Higher validation cost lead end-users to rely on/trust
centralised services to "validate" their transactions.</p></li>
<li><p>Larger blocks require more time to propagate in the network, 
increasing pooling pressures for more centralized mining-pools.</p></li>
</ul>

<p>The lower the validation cost, the more we can push validation to the edge (end-user) of the network, the more decentralisation we can achieve. Decentralisation is ultimately the source of security, as it is harder for an external force to attack.</p>

CC BY-SA 4.0
2018-12-06T18:56:47.243Z
Also, off-chain transactions can be made for much cheaper without sacrificing security. No need to store the history of daily coffee purchases of everybody on all Bitcoin nodes in the network.
JBaczuk
CC BY-SA 4.0
2018-12-06T19:00:28.583Z
Well - there is a security sacrifice to be 100% fair. There is no insurance against failing to respond to a cheating counter-party in payment channels. The required vigilance is an additional risk that a confirmed transaction does not have.
James C.
CC BY-SA 4.0
2018-12-06T19:12:10.980Z
Can you explain in more detail? Also, even a confirmed transaction still has the small risk of a reorg. There are even users who choose to accept transactions before they have one confirmation (cringe).
JBaczuk
CC BY-SA 4.0
2018-12-06T19:17:43.567Z
That is true. A user can choose how much security he requires from a confirmed transaction before accepting it. Yet a commitment tx, even though it is valid, has not even been confirmed, which is why I mean it has less security. So a lightning payment (a new commitment tx) cannot have the same security as a confirmed tx with a confirmation depth. The entire payment channel capacity amount is in fact still “pending” confirmation.
James C.
CC BY-SA 4.0
2018-12-06T19:20:15.040Z
Right, thanks. It's important that it remain easy to broadcast the state of the channel at any time.
JBaczuk
CC BY-SA 4.0
2018-12-06T19:38:04.230Z
Sorry. I meant “A user can choose how much security [he/she] requires...”
James C.
CC BY-SA 4.0
2018-12-06T11:09:43.630Z
2018-12-06T13:04:49.817Z
2018-12-06T13:04:49.817Z
James C.
<p>I have been doing some research on the Bitcoin Cash hard fork and the main contention of increasing the block size appears to be the possibility of less security on the network. How does an increased block size result in a less secure network?</p>

<security><block>
Why is increasing block size in the Bitcoin network considered to decrease security?
AdaptiveAnalysis
# Why is increasing block size in the Bitcoin network considered to decrease security?

(Asked by: username_0 on 2018-12-06)

I have been doing some research on the Bitcoin Cash hard fork and the main contention of increasing the block size appears to be the possibility of less security on the network. How does an increased block size result in a less secure network?

**Tags:** security, block


---

## 1 answers

### Answer by username_1 on 2018-12-06. Score: 13

Generally speaking, a larger block leads to more computational resources (tx validation, bandwidth, storage, memory) required for each person who wishes to validate newly confirmed transactions.

* Higher validation cost lead end-users to rely on/trust
  centralised services to "validate" their transactions.
* Larger blocks require more time to propagate in the network,
  increasing pooling pressures for more centralized mining-pools.

The lower the validation cost, the more we can push validation to the edge (end-user) of the network, the more decentralisation we can achieve. Decentralisation is ultimately the source of security, as it is harder for an external force to attack.

> **Comments:**
> **username_2**: Also, off-chain transactions can be made for much cheaper without sacrificing security. No need to store the history of daily coffee purchases of everybody on all Bitcoin nodes in the network.  
> **username_1**: Well - there is a security sacrifice to be 100% fair. There is no insurance against failing to respond to a cheating counter-party in payment channels. The required vigilance is an additional risk that a confirmed transaction does not have.  
> **username_2**: Can you explain in more detail? Also, even a confirmed transaction still has the small risk of a reorg. There are even users who choose to accept transactions before they have one confirmation (cringe).  
> **username_1**: That is true. A user can choose how much security he requires from a confirmed transaction before accepting it. Yet a commitment tx, even though it is valid, has not even been confirmed, which is why I mean it has less security. So a lightning payment (a new commitment tx) cannot have the same security as a confirmed tx with a confirmation depth. The entire payment channel capacity amount is in fact still “pending” confirmation.  
> **username_2**: Right, thanks. It's important that it remain easy to broadcast the state of the channel at any time.  
> **username_1**: Sorry. I meant “A user can choose how much security [he/she] requires...”  

---

