Solution to the Block Size Debate for Miners

[Hyena]

I just came to this exciting idea what miners could do to help to solve the block size debate without losing their profits.

Every Bitcoin node can change the maximum block size the way they see fit. Just because it is a hard-coded constant does not mean we can't change it and still run the same old Bitcoin. So, one would download the Bitcoin-core and simply increase the maximum block size to whatever number. Before you start yelling the word "fork", read some more.

If I am not wrong, miners can mine blocks for multiple chains in parallel without losing anything. All a miner has to do is to track the forks of bitcoin and mine for all of them in parallel. For example if there exists 2 forks of Bitcoin, one with 1 MiB block size limit and the other one with 2 MiB block size limit, then the miner has to compile blocks for both of them.

The miner will compile one block that is not larger than 1 MiB and the other block that is not larger than 2 MiB, having 2 different blocks. Next, the miner will try to find a hash that satisfies the protocol constraints for any of those blocks. When mining the miner gets a lot of random SHA256 hashes. Should they run into a hash that satisfies the 1 MiB block, it's a success. The miner can get the reward and confirm it. Should they run into a hash that satisfies the 2 MiB block it's also a success. The miner does not care. They are still earning block rewards and transaction fees regardless of which chain is longer.

Finally, to save up some memory the miner has to forget a fork that gets too far behind the leading fork. For example if a particular fork is 4 blocks shorter than the leading chain then it is safe to forget it as a losing fork. This is what miners could already implement. It is a win-win situation.

By the way, does anyone know if SegWit serves any other purpose than just increasing the block capacity? It would be a shame to discard it after it's ready, so maybe we could have variable length blocks and segwit at the same time? Is it possible?

[1714642160]

1714642160

[1714642160]

1714642160

[franky1]

unlike your last topic of the same title.
by mining different chains.. a different chain is infact an altcoin.

so i find it strange that the biased moderators would move your previous topic to altcoin section, when it was talking about an implementation currently and continually running on bitcoins mainnet and using bitcoins own mechanisms to stay on bitcoins main net to grow bitcoin. yet have not moved this topic to the altcoin section, which is talking about different chains

but hey the mods are very biased about wanting their favourite implementation to have dictatorial control. and have shown their hand of wanting to centralize the network decisions, by forcing others away from bitcoins mainnet

i feel sorry for the mod that moved it, as that mod is obviously not a bitcoiner or lacks basic bitcoin understanding. a third option is that the mod which moved the other topic is a shill for the banking cartel. but hey, how dare we call them out on their own bullcrap.

i now sense replies will return by those biased people who will celebrate your idea of you wanting to intentionally split to a different chain so they can double their coin. while also claiming anyone saying not to intentionally split, but to grow bitcoins capacity within one chain must strangely be a bank loving altcoiner.. (hypocrisy cries from the fiat cartels)

[Lauda]

This is what miners could already implement. It is a win-win situation.

Splitting chains is a terrible idea.

By the way, does anyone know if SegWit serves any other purpose than just increasing the block capacity?

SegWit was designed to fix transactions malleability, not increase the throughput (this comes as a bonus). Some of the benefits: Simpler secure signature generation, linear scaling of sigash operations (very important for any block size increases), improved multisig security, script versioning. You can read the full details in this post.

[franky1]

This is what miners could already implement. It is a win-win situation.

Splitting chains is a terrible idea.

By the way, does anyone know if SegWit serves any other purpose than just increasing the block capacity?

SegWit was designed to fix transactions malleability, not increase the throughput (this comes as a bonus). Some of the benefits: Simpler secure signature generation, linear scaling of sigash operations (very important for any block size increases), improved multisig security, script versioning. You can read the full details in this post.

lauda, i see you are trying to break out of the shell of blockstream love. have you noticed that the bait of fixing malleability is no longer about double spending, but switched to just being about smart contracts. due to RBF, CPFP, GOP are the new double spend mechanisms ADDED. thus double spends are still an issue.

[Hyena]

This is what miners could already implement. It is a win-win situation.

Splitting chains is a terrible idea.

By the way, does anyone know if SegWit serves any other purpose than just increasing the block capacity?

SegWit was designed to fix transactions malleability, not increase the throughput (this comes as a bonus). Some of the benefits: Simpler secure signature generation, linear scaling of sigash operations (very important for any block size increases), improved multisig security, script versioning. You can read the full details in this post.

Transactions malleability is something that I can actually relate to. From a developer's point of view it is a pain in the ass problem. Splitting chains is fundamentally no different than double spends and conflicting transactions. How is it that you can tolerate the existence of conflicting transactions but you cannot tolerate conflicting blocks? I see there's a gap you need to fill there.

[spartacusrex]

If I am not wrong, miners can mine blocks for multiple chains in parallel without losing anything. All a miner has to do is to track the forks of bitcoin and mine for all of them in parallel. For example if there exists 2 forks of Bitcoin, one with 1 MiB block size limit and the other one with 2 MiB block size limit, then the miner has to compile blocks for both of them.

Not sure that's going to work.

When you mine you have to hash a block header with a random nonce. The block header has the hash of the previous block. The Previous block hash will be different for the different chains.

So you cannot mine multiple chains at once.. as your header will either point to one block or another, and you can't solve for 'both' (you can in POS, but not in POW)

[Hyena]

If I am not wrong, miners can mine blocks for multiple chains in parallel without losing anything. All a miner has to do is to track the forks of bitcoin and mine for all of them in parallel. For example if there exists 2 forks of Bitcoin, one with 1 MiB block size limit and the other one with 2 MiB block size limit, then the miner has to compile blocks for both of them.

Not sure that's going to work.

When you mine you have to hash a block header with a random nonce. The block header has the hash of the previous block. The Previous block hash will be different for the different chains.

So you cannot mine multiple chains at once.. as your header will either point to one block or another, and you can't solve for 'both' (you can in POS, but not in POW)

Ah yes, you are right. That's a pity.

[spartacusrex]

If I am not wrong, miners can mine blocks for multiple chains in parallel without losing anything. All a miner has to do is to track the forks of bitcoin and mine for all of them in parallel. For example if there exists 2 forks of Bitcoin, one with 1 MiB block size limit and the other one with 2 MiB block size limit, then the miner has to compile blocks for both of them.

Not sure that's going to work.

When you mine you have to hash a block header with a random nonce. The block header has the hash of the previous block. The Previous block hash will be different for the different chains.

So you cannot mine multiple chains at once.. as your header will either point to one block or another, and you can't solve for 'both' (you can in POS, but not in POW)

Ah yes, you are right. That's a pity.

Not to be contentious.. but your previous post about bitcoin Unlimited, and the Free market, seems the way to go for me.. The Problem with that is that the miner does risk losing his block reward if he tries to build a chain with a block size that the rest of the network doesn't accept.

The 3 options a miner has are :

1) Don't forward a block. (Block size too big)

2) Forward a block, but don't personally build on it. (Block size big, but you are prepared to see if someone else builds on it)

3) Forward and build on it. (Block size just right, you build on it)

Other than the risk of losing your reward, this is a nice setup. Need to find a clever fix though.. like if you were using a GHOST chain, and orphaned blocks were also paid. (Since in GHOST they would still add to the overall 'weight' of the chain)

That might be interesting.

[Hyena]

Not to be contentious.. but your previous post about bitcoin Unlimited, and the Free market, seems the way to go for me.. The Problem with that is that the miner does risk losing his block reward if he tries to build a chain with a block size that the rest of the network doesn't accept.

The 3 options a miner has are :

1) Don't forward a block. (Block size too big)

2) Forward a block, but don't personally build on it. (Block size big, but you are prepared to see if someone else builds on it)

3) Forward and build on it. (Block size just right, you build on it)

Other than the risk of losing your reward, this is a nice setup. Need to find a clever fix though.. like if you were using a GHOST chain, and orphaned blocks were also paid. (Since in GHOST they would still add to the overall 'weight' of the chain)

That might be interesting.

Here's an idea. Let's make a TX that is so huge it requires a block larger than 1 MiB. The TX fee for that particular TX should be enough to motivate miners switching to Bitcoin Unlimited in order to mine it. The named large TX should have A LOT OF near-dust outputs to a Bitcoin address for which everyone knows a private key. Then, using the child-pays-for parent method, everyone can spend one such output and include a large TX fee. This way people could freely donate Bitcoins to the first miner that is willing to confirm the parent TX in order to receive the fees from its children. If the reward is big enough it will be profitable for a miner to try to mine that large block.

[franky1]

Not to be contentious.. but your previous post about bitcoin Unlimited, and the Free market, seems the way to go for me.. The Problem with that is that the miner does risk losing his block reward if he tries to build a chain with a block size that the rest of the network doesn't accept.

The 3 options a miner has are :

1) Don't forward a block. (Block size too big)

2) Forward a block, but don't personally build on it. (Block size big, but you are prepared to see if someone else builds on it)

3) Forward and build on it. (Block size just right, you build on it)

Other than the risk of losing your reward, this is a nice setup. Need to find a clever fix though.. like if you were using a GHOST chain, and orphaned blocks were also paid. (Since in GHOST they would still add to the overall 'weight' of the chain)

That might be interesting.

Here's an idea. Let's make a TX that is so huge it requires a block larger than 1 MiB. The TX fee for that particular TX should be enough to motivate miners switching to Bitcoin Unlimited in order to mine it. The named large TX should have A LOT OF near-dust outputs to a Bitcoin address for which everyone knows a private key. Then, using the child-pays-for parent method, everyone can spend one such output and include a large TX fee. This way people could freely donate Bitcoins to the first miner that is willing to confirm the parent TX in order to receive the fees from its children. If the reward is big enough it will be profitable for a miner to try to mine that large block.

bribing wont work.
no point accepting a tx of over 1mb into block right now even if there was a fee of 1million btc. because it would still get orphaned by >3000 of 5000 nodes. thus it wont be spendable and would disappear. and pools wont get paid a single sat.
so pools would just let it sit in mempool until dropping it.

if however the majority of nodes moved their limits. then pools would happily make bigger blocks even without being bribed because they know it wont get orphaned so no risk to freely make blocks over 1mb for all implementations to accept.

the only option to "force" this would be an intentional split by adding in some ban IP code to ban nodes with only 1mb limits (much like how ethereum intentionally split by banning old nodes from new nodes (--oppose-dao-fork))
but you are then creating an altcoin.

bitcoin unlimited and other implementations have never and will never want to play with an altcoin they want to remain part of bitcoin and keep bitcoin diverse, rather than handing it into the hands of a single corporation paid team, with 90+ unpaid interns used as spell checkers to appear open.
its core that are holding the limit down and core devs asking bitcoinU to split off.. (bad bad bad)

but until those holding the limit of the base block at 1mb move their limit. they are holding back the blocksize growth and will continue doing so until their agenda has been met.

lets jsut hope now that segwit has no more need to be coded and should be set in stone. those holding back the block limit can now concentrate on increasing the block limit:
eg 2mb base 4mb weight. instead of 1mb base 4mb weight, thus they get their cake and the community can eat it. rather then trying to invite everyone over to their house to all eat from their plate.

[ArticMine]

Maybe a more appropriate question here is:

Is decentralized blocksize scaling in Bitcoin actually viable without a violation the 21,000,000 XBT limit?

Changing the blocksize from 1 MB to 4MB via a hard fork does not change anything. It only pushes the problem down the road. I responded to the other thread in the altcoin section, https://bitcointalk.org/index.php?topic=1666646.msg16746609#msg16746609, with respect to BItcoin unlimited.

[Hyena]

Maybe a more appropriate question here is:

Is decentralized blocksize scaling in Bitcoin actually viable without a violation the 21,000,000 XBT limit?

Changing the blocksize from 1 MB to 4MB via a hard fork does not change anything. It only pushes the problem down the road. I responded to the other thread in the altcoin section, https://bitcointalk.org/index.php?topic=1666646.msg16746609#msg16746609, with respect to BItcoin unlimited.

I think the block size issue is actually a no-issue. It will sort itself out eventually. When all BTC wallets implement floating fees that are based on the unconfirmed transactions then TX fees will start to rise naturally. At the same time block reward keeps halving and BTC price climbs higher. Eventually miners will realize that they are missing out a lot of profits because of the block size limit. They will then switch to Bitcoin Unlimited.

[spartacusrex]

Maybe a more appropriate question here is:

Is decentralized blocksize scaling in Bitcoin actually viable without a violation the 21,000,000 XBT limit?

Can you explain that Artic ? How could block size affect the total number of coins ?

Changing the blocksize from 1 MB to 4MB via a hard fork does not change anything. It only pushes the problem down the road. I responded to the other thread in the altcoin section, https://bitcointalk.org/index.php?topic=1666646.msg16746609#msg16746609, with respect to BItcoin unlimited.

I respectfully disagree..

There are many solutions to 'full' pruning that we could implement at a later date. So size of Storage is a non-issue. We could remove all the txns and only keep the UTXO for one. (I know this has implications, but since we are going Segwit anyway, and losing the signatures, the spent txns seem less important now)

As for the Bandwidth required and latency involved in transmitting the blocks, they could put ONLY the txn hash in the block, not the whole txn. (the txn will have been sent across the network already.) So a bump to 2 or 3 megabytes may be ALL that is ever required. Since once the txn hash and not the whole txn is added to the block, the capacity in a single block will jump to 10x-100x more.. at the same size..

[ArticMine]

Maybe a more appropriate question here is:

Is decentralized blocksize scaling in Bitcoin actually viable without a violation the 21,000,000 XBT limit?

Can you explain that Artic ? How could block size affect the total number of coins ?

Changing the blocksize from 1 MB to 4MB via a hard fork does not change anything. It only pushes the problem down the road. I responded to the other thread in the altcoin section, https://bitcointalk.org/index.php?topic=1666646.msg16746609#msg16746609, with respect to BItcoin unlimited.

I respectfully disagree..

There are many solutions to 'full' pruning that we could implement at a later date. So size of Storage is a non-issue. We could remove all the txns and only keep the UTXO for one. (I know this has implications, but since we are going Segwit anyway, and losing the signatures, the spent txns seem less important now)

As for the Bandwidth required and latency involved in transmitting the blocks, they could put ONLY the txn hash in the block, not the whole txn. (the txn will have been sent across the network already.) So a bump to 2 or 3 megabytes may be ALL that is ever required. Since once the txn hash and not the whole txn is added to the block, the capacity in a single block will jump to 10x-100x more.. at the same size..

It comes down to the more fundamental question: How does one secure Bitcoin once the the block reward runs out or becomes minimal? The theory is that transaction fees will fill this void; however the question of how this is supposed to happen has not been answered in Bitcoin. This goes back to the original Satoshi design and very few people are actually prepared to question Satoshi on  this implicit transaction fee assumption.

If transaction fees are supposed to eventually secure the Bitcoin network then how are transaction fees supposed to rise? The response from the "small block" proponents is to force transaction fees to rise by keeping the blocksize small. The alternative is to create a permanent blockreward a la Monero / Dogecoin but that violates the 21,000,000 XBT limit. The proposals above regarding segwit, pruning and various compression schemes are in effect from the perspective of a fee market equivalent to increasing the blocksize to a greater fixed limit. The result of this is to "push the problem" down the road. These type of proposals may have merit from the perspective of improving network efficiency and slowing down or preventing centralization, but they do not address the fundamental transaction fee market as a means of securing Bitcoin issue.

We now come to the Bitcoin unlimited / orphan blocks solution. This may in fact be a solution to a different problem; namely restricting the blocksize to prevent Bitcoin from becoming uneconomical due to bandwidth, storage, CPU processing costs, etc. If however as has been historically the case these costs continue to fall at an exponential rate then there is no realistic expectation that these costs will restrict the blocksize sufficiently to  cause transaction fees to rise to a degree that transaction fees alone can be used to secure the network.

At this point what I see a series of unpalatable choices for Bitcoin:
1) Keep the blocksize small at a fixed limit to force TX fees up. This prevents the growth of Bitcoin
2) Allow the blocksize to grow to meet market demand. This runs the risk of an insecure Bitcoin
3) Violate the 21,000,000 XBT limit with a permanent block reward. (Monero / Dogecoin). Major violation of the Bitcoin social covenant.
4) Keep the 21,000,000 XBT limit but impose demurrage (Freicoin) in order to generate coins for the permanent block reward. Major violation of the Bitcoin social covenant.
5) Have a mining cartel set TX fees by controlling the blocksize. Loss of decentralization.
6) Set a fixed TX fee with an unlimited blocksize (Ethereum). This means a hard fork to change TX fee. We replace the fixed blocksize problem with a fixed TX fee problem. In addition there is no way for the miners to be prevented from rebating the fee off chain.

Most of the debate has centered on 1, 2 and 5 (somewhat) above. 3, 4 and 6 are various alt-coin solutions.

Edit 1: We must ask another question. Is there a fundamental flaw in the original Satoshi Bitcoin design?
Edit 2: I consider 3 to be the viable alt-coin solution. 4 is theoretically viable but unsaleable. 6 is not viable because it creates a whole new set of problems.
Edit 3: I consider 5 to be the most viable non alt-coin solution.

[unamis76]

"Dual" mining would split users. There would be a need for exchanges to deal with both chains and payment channels and websites to accept payments in both chains. Mining whatever fits the miner best at the given time would also create a few problems as nobody would really know what that miner supports (bigger or smaller blocks). I have no further ideas regarding this, but I do not think this is the way to go. We either raise blocks or we don't, it would be difficult to keep people "in between". Meanwhile we have SegWit to hold us a few more months.

[Hyena]

It comes down to the more fundamental question: How does one secure Bitcoin once the the block reward runs out or becomes minimal? The theory is that transaction fees will fill this void; however the question of how this is supposed to happen has not been answered in Bitcoin. This goes back to the original Satoshi design and very few people are actually prepared to question Satoshi on  this implicit transaction fee assumption.

this is offtopic by far. It has nothing to do with block size debate. You either believe in satoshis plan or not. If you don't then why are you here?

[ArticMine]

It comes down to the more fundamental question: How does one secure Bitcoin once the the block reward runs out or becomes minimal? The theory is that transaction fees will fill this void; however the question of how this is supposed to happen has not been answered in Bitcoin. This goes back to the original Satoshi design and very few people are actually prepared to question Satoshi on  this implicit transaction fee assumption.

this is offtopic by far. It has nothing to do with block size debate. You either believe in satoshis plan or not. If you don't then why are you here?

It has everything to do with the block size debate because many in the Bitcoin community including many in the Bitcoin core team see keeping the block size small as solution to this question, at least on an interim basis until a permanent solution is found. Dismissing the small bloc side of the debate as "conflict of interest" ignores the reality that there are very strong and legitimate arguments on both sides of the block size debate. Furthermore one can legitimately argue that the reason why there in no consensus is because there is no solution or the solution is highly elusive.

Yes this is the elephant in the room many in the Bitcoin community would rather not talk about. Shooting at the messenger by calling my post off topic in very much an indication of this sentiment.

Edit: One must also keep in mind that Satoshi added the 1 MB blocksize limit as a hard fork in 2010. This was well over 1 year since the launch of Bitcoin in 2009.

[franky1]

Edit: One must also keep in mind that Satoshi added the 1 MB blocksize limit as a hard fork in 2010. This was well over 1 year since the launch of Bitcoin in 2009.

satoshi also suggested to move it to 2mb for ~2011. but dispeared before that. and now all the consensus back tracking and delays have caused years of debate.

funny thing is core are now the big blockers deeming 4mb bloats as safe.. yet still suppressing the potential transactions allowable within that bloat.

[Hyena]

It has everything to do with the block size debate because many in the Bitcoin community including many in the Bitcoin core team see keeping the block size small as solution to this question, at least on an interim basis until a permanent solution is found. Dismissing the small bloc side of the debate as "conflict of interest" ignores the reality that there are very strong and legitimate arguments on both sides of the block size debate. Furthermore one can legitimately argue that the reason why there in no consensus is because there is no solution or the solution is highly elusive.

Yes this is the elephant in the room many in the Bitcoin community would rather not talk about. Shooting at the messenger by calling my post off topic in very much an indication of this sentiment.

Edit: One must also keep in mind that Satoshi added the 1 MB blocksize limit as a hard fork in 2010. This was well over 1 year since the launch of Bitcoin in 2009.

I have to admit I laugh when I read your text. I cannot take it seriously.

Take this sentence for example:

the reality that there are very strong and legitimate arguments on both sides of the block size debate.

Why is it so that I see no strong and legitimate arguments on the SegWit/Core side then?

The 1 MiB limit was a joke even when Satoshi came out with it but I guess he was a bit too much afraid of possible attacks on a young network. So okey, I don't blame him too much for that. The only reason why Bitcoin Unlimited is not the most popular full node yet is this constant censoring, trolling and suppression which you are obviously involved in.

Let me remind you again and again and on and on that miners are not obliged to include all TXs in a block. Even if there was no maximum block size limit miners would still produce rather small blocks. Hell, some miners are even known to mine empty blocks. But of course, a competing altcoin proponent would like Bitcoin to stop growing so that their shitcoin could steal some of Bitcoin's market cap.

Seeing a label "Monero Core Team" under your avatar just proves the fact that you have a dog in this fight and that dog ain't Bitcoin.