Topic: the blocksize debate (Read 5439 times)

What you describe is called SPV mining. It means that miners skip the verification of the block and the transactions within, and immediately start mining a new block referencing the just-solved block header.
There could be many types of issues due to SPV mining:
- Since miners receiving only 'ping' & not complete data, they don't know what is in the last block, they have to mine without any transactions (except for the coinbase transaction), to be sure that they don't mine a block with
transactions that conflict with transactions in the previous block. This means they are not helping the bitcoin network at all!
- There were other issues like July 2015 fork which you can read about here : https://en.bitcoin.it/w/index.php?title=July_2015_chain_forks

A solution could be as simple as a 'ping' message. I don't have a programming mind and I wont pretend to understand how the internal wiring or Bitcoin works in technical terms but the issue here is basically this "the block size is too big, by the time rest of the world uploads/downloads this mined block information someone else would get headstart"

Can't we simply send a proof of work 'ping' to the rest of the world. This 'ping' would carry an irrefutable proof that a block has been mined and ID's the block?? So the rest of the world can stop mining that block and move on. Theoretically this 'ping' message could be few bytes.

Couldn't this be done? Or is it way more complicated?

Maybe Bitcoin should look at Monero which has dynamic block size, but for that to work the hard limit has to be changed to a tail emission which will never happen

The BitcoinXT activation date was yesterday but the fork could not gather support (0 BIP101 blocks in last 1000 blocks, reaching a peak of 8 out of last 1000 in August).

For the near future here is the Scalability Road Map that bitcoin will be following : https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html

Exactly.  After a fork, all new transactions are on a new block chain like a new altcoin.  Transactions prior to the fork could be on both chains though.

After split one chain does not care about the transactions on other. Each will only consider its own transactions.

Lol seriously  

It does not work this way. You need to pick a chain

Umm, yeah now the issue would be with the newly generated coins after those two chains fork. They can only get confirmed on the same chain but never on the other.

The exchanges should credit your wallet only after it sees confirmations on both chains. Not just one chain.

Very nice post regarding the problem Bitcoin facing in Blocksize, through your post i have understanded the concept of minning and how the bitcoin is working.


If that happens that both transaction are verified from seperated exchanges then what you said will become that if i have 1 bitcoins i can use it in 2 exchanges and enjoy other bitcoin amount freely, if that happens then in near future it will be a very big scam.

Correct but the broadcasted transaction would get included in both chains unless i have the wrong understanding.

Both versions wont be mining each other's coins and individually disentanglement of coins is a problem.

Else the receiver should wait till he gets 6 confirmations from both versions of bitcoin.

If this happens then old coins can be spent twice; once to merchants accepting core & then again to XT merchants.

Does the exchange have possibility of having both bitcoin core and XT?

Very Good and Interesting Post

which explains the details about what is Blocksize and how it works , after reading this message i came to know about the whole dept of bitcoin mining and its process

It really helps new commers to the Bitcoin world about what is bitcoin and how it works,

thanks   

Very good post, thanks for such a good Explanation

Though i understand debate has been going about the increase in Blocksize, but i don't think it will effect the price in long run , at last - we all want bitcoin to go up.

Yes this is not the same when we reach that large limit but for cases smaller than that it is the same. Anyways, I corrected myself in the thought process down the post where I write "This is same as having no blocksize limit" by which I meant "lets have no limits and lets simply keep the blocksize whatever the current demand is."

Yes, the max cap. Of course we are talking about the max cap in all of this discussion because miners can mine empty blocks anyways. Stop nitpicking!


"But, if they are full, no one opposes block size max cap increase." Nope. Read my OP for the reason why big blocks are a problem.



Many of them have accounted for the previous block size to increase and decrease max cap. The list I mentioned are the advanced changes, after the discussions have happened on this proposal.
I hope it gets its due merit too, but googling 'dynamic bitcoin blocksize' will tell you why it already has.

The suggestion is not at all same as keeping a fixed large block size. This is a demand driven approach, which might take down the max cap as well. For a fixed 50 MB max cap, one miner can clean the mempool while others will be forced to mine empty blocks and thereby losing economically. For this proposal, this wont happen as block size max cap will come down in next difficulty.

I dont understand, why you are saying this ? He has suggested the max cap to be dynamic, not block size. A miner can always mine empty blocks if he wishes so.

Nopes. It seems you did not get the problem. Almost everyone agrees that blocksize need to be increased if blocks are full. The contradiction is in the process of scaling. Both core devs Jeff Garzik & Pieter Wuille, who are opposed to XT, have suggested BIPs (100 & 103) to increase block size max cap. Gmaxwell, Peter Todd and Luke Dash Jr have questioned many times in Reddit that how fast the blocks will be full. But, if they are full, no one opposes block size max cap increase. As per XT's algorithm, block size will keep rising in a periodic manner without accounting for the real demand. In this proposed algorithm, block size may increase as well as decrease. You are assuming transactions will only rise, which may or may not happen in reality. We need an algo that is adaptive to the reality, not assumption. It is no way similar to having no block size max cap.

Yes, dynamic block size max cap has been proposed before and I think, the proposal we are discussing now, has also listed many of those other solutions. But, none of them has accounted for the previous block size to increase and decrease max cap. This is an unique proposal and I hope it gets its due merit.

How, Sir?


Upal, the suggestion you make is to make the blocksize dynamic. This is same as keeping a large block size. For eg, if the block size was 50 mb, it does not mean that each block is 50mb even if it is not filling up. 50 mb is the 'upper limit'. So all the blocks, after calculation & decision as suggested by you, would be equal to the size of transactions in queue, a.k.a mempool.

I think you are concentrating on the wrong part of the problem. People are not saying that blocks sometimes are not full. Everybody agrees that that in future the blocks would get full as the transaction rises. So as per your algorithm it will simply keep rising to meet the demand. This is same as having no blocksize limit.

Anyways, dynamic blocksize has been proposed and discussed many times and there are many variations of dynamic block-size limits here : http://bitcoin-development.narkive.com/cr8x2evb/bitcoin-development-various-block-size-proposals

Very good explanation Skang. It will immensely help newcomers to get the inside picture of block size controversy.

To solve the blocksize problem, I wrote a proposal - http://upalc.com/maxblocksize.php. This is now being discussed among devs. If any of you have any input to provide, feel free to share.