Author

Topic: Arbitrary block size increase via soft-fork (Read 954 times)

newbie
Activity: 28
Merit: 165
October 13, 2016, 04:01:36 AM
#5
Quote
I wasn't talking about separate blockchains or sidechains, etc. I am talking about literally a separate data structure tacked onto the block that allows any sort of transaction to go inside of it

Yes I haven't explained myself correctly.

Thanks for the answer.
staff
Activity: 3458
Merit: 6793
Just writing some code
October 11, 2016, 07:20:55 PM
#4
I wasn't talking about separate blockchains or sidechains, etc. I am talking about literally a separate data structure tacked onto the block that allows any sort of transaction to go inside of it. That would break backwards compatibility, and it is the naive implementation of such a size increase. There of course has to be plenty of other things to be done in order to maintain compatibility, and for just a block size increase, is too complex and still a bad idea. It would be easier to do just a hard fork to increase the block size at that point.
newbie
Activity: 28
Merit: 165
October 11, 2016, 07:14:16 PM
#3
I can't figure out why it's an horrible idea, I mean, old clients could still validate transactions in 1mb block. Only newer clients will be aware of transactions in >1mb new blocks. Also, you can make addresses between the two blocks not compatible: if only bitcoins can be transferred from (current) 1mb block chain to >1mb new blockchain (and not in reverse), the amount of bitcoins in 1mb blockchain decreases as it increases in >1mb blockchain. You transfer wealth from one blockchain to the other gracefully.

When all bitcoins are transfered to the >1mb new block set, current (old) blockchain is only in charge of verifiying the proof of work and collect block rewards which can be transfered ¿immediately? to the new >1mb blockchain. To validate >1mb blocks, its merkle root hash can be included as an obligatory (via soft- fork) op_return transaction with zero fees in current blockchain. Fees for transactions in >1mb blockchain could be sent to the same coinbase address than 1mb block. It's like a one-way peg sidechain that uses the current mainchain proof of work.

Also note that bitcoin users that do not want to upgrade, still can use the 1mb blockchain if they want. They only see that an increasing amount of bitcoins are moving to (new blockchain's) addresses that can't be sent back to current blockchain because miners agreed to forbid it (via softfork)

I hope I'm explaining myself correctly. I've been thinking all day about it and I think that having old clients unaware of the other blockchain transactions it's a fair (¿and inevitable?) price to pay for scaling via soft-fork.

Do I have missed something?

Also I apologize for my English grammar. Thanks in advance for the answers.
staff
Activity: 3458
Merit: 6793
Just writing some code
October 11, 2016, 05:38:20 PM
#2
In theory a soft fork could be made where there is a so called "extra block" which would contain additional transactions. It's a horrible idea because it isn't actually backwards compatible since old nodes may not know that a transaction has confirmed if it were in the "extra block"
newbie
Activity: 28
Merit: 165
October 11, 2016, 05:12:05 PM
#1
Hi there, I hope not to ask a stupid question but...

Is there any way to arbitrary increase the block size via softfork? I mean, apart from Segregated Witness, Schnorr signatures or MAST which optimizes transaction size, and regardless of storage/bandwidth problems like the Great Firewall of China. Has anybody discovered/studied how to do that via softfork?

Jump to: