More than GHOST, or DECOR+, allowing and merging chain forks seems more like DagCoin (https://bitcointalksearch.org/topic/dagcoin-a-cryptocurrency-without-blocks-1177633)
The idea of DagCoin is that if you merge two double-spends, the one with higher number of confirmations survive. If you merge two competing blocks, then all transactions in one fork will have the same confirmations than on the other fork. So the transaction in the first block referenced must prevail, and the second must be canceled. This make sense when only when you increase the rate of blocks, so an average block interal is below 10 seconds (comparable with propagation time)
Topic: Scaling beyond block size: allow chain forks! (Read 871 times)
Very interesting, thanks for the links!
Block size increase in itself is not going to increase the number of TPS because of the orphan risk.
To compete on a global scale with just Paypal f.i., bitcoin would need to go from 7 TPS to something like 700 TPS, or 100 MB block size, at which point propagation becomes problematic, and the risk of a block getting orphaned would be very high.
We already see many blocks that are not full, even blocks with just 1 tx or a couple hundred tx.
One way to reduce the orphan block risk could be to allow 1-block fork merging: a block could be allowed to have multiple previous blocks. This way if two blocks come at the same time, rather than one orphaning the other, the next block could accept both.
To compete on a global scale with just Paypal f.i., bitcoin would need to go from 7 TPS to something like 700 TPS, or 100 MB block size, at which point propagation becomes problematic, and the risk of a block getting orphaned would be very high.
We already see many blocks that are not full, even blocks with just 1 tx or a couple hundred tx.
One way to reduce the orphan block risk could be to allow 1-block fork merging: a block could be allowed to have multiple previous blocks. This way if two blocks come at the same time, rather than one orphaning the other, the next block could accept both.
This sounds a lot like GHOST ...
Currently if block B & C are mined based on block A, then only B or C will be accepted by block D being mined on either B or C.
The proposal would be that D could accept both B & C, half the B & C rewards would be lost (so the total reward is unchanged), duplicate transactions in a merge would be ignored/pruned. And probably that part of B & C reward+fee could go to D, to incentivize the merging.
The proposal would be that D could accept both B & C, half the B & C rewards would be lost (so the total reward is unchanged), duplicate transactions in a merge would be ignored/pruned. And probably that part of B & C reward+fee could go to D, to incentivize the merging.
... and DECOR.
Block size increase in itself is not going to increase the number of TPS because of the orphan risk.
To compete on a global scale with just Paypal f.i., bitcoin would need to go from 7 TPS to something like 700 TPS, or 100 MB block size, at which point propagation becomes problematic, and the risk of a block getting orphaned would be very high.
We already see many blocks that are not full, even blocks with just 1 tx or a couple hundred tx.
One way to reduce the orphan block risk could be to allow 1-block fork merging: a block could be allowed to have multiple previous blocks. This way if two blocks come at the same time, rather than one orphaning the other, the next block could accept both.
Currently if block B & C are mined based on block A, then only B or C will be accepted by block D being mined on either B or C.
The proposal would be that D could accept both B & C, half the B & C rewards would be lost (so the total reward is unchanged), duplicate transactions in a merge would be ignored/pruned. And probably that part of B & C reward+fee could go to D, to incentivize the merging.
For miners this would reduce the risk of a block being orphaned completely (and losing the full reward), which may encourage them to fill their blocks more, for users this increases the probability of their transaction getting through (in case they were in one of the blocks and not the other).
This is a quite massive hard-fork though, but I feel that without changes to the propagation and block acceptance, the risk of orphan eventually makes all block size increase discussions as relevant as counting angels on a pinhead.
To compete on a global scale with just Paypal f.i., bitcoin would need to go from 7 TPS to something like 700 TPS, or 100 MB block size, at which point propagation becomes problematic, and the risk of a block getting orphaned would be very high.
We already see many blocks that are not full, even blocks with just 1 tx or a couple hundred tx.
One way to reduce the orphan block risk could be to allow 1-block fork merging: a block could be allowed to have multiple previous blocks. This way if two blocks come at the same time, rather than one orphaning the other, the next block could accept both.
Currently if block B & C are mined based on block A, then only B or C will be accepted by block D being mined on either B or C.
The proposal would be that D could accept both B & C, half the B & C rewards would be lost (so the total reward is unchanged), duplicate transactions in a merge would be ignored/pruned. And probably that part of B & C reward+fee could go to D, to incentivize the merging.
For miners this would reduce the risk of a block being orphaned completely (and losing the full reward), which may encourage them to fill their blocks more, for users this increases the probability of their transaction getting through (in case they were in one of the blocks and not the other).
This is a quite massive hard-fork though, but I feel that without changes to the propagation and block acceptance, the risk of orphan eventually makes all block size increase discussions as relevant as counting angels on a pinhead.
Jump to: