One of the best proposal I have seen in recent times to end the consensus controversy. Have you tried to post it in the bitcoin-dev mailing list?
bitcoin-dev mailing list owner asked me to post it in bitcoin-discuss mailing list first. So, it is there - http://lists.linuxfoundation.org/pipermail/bitcoin-discuss/2016-February/000080.html. So how exactly is this constitution suppose to be enforced?
Why would anyone obey it?
Neither it needs to be enforced, nor anyone needs to obey it. It'll do good as an unofficially defined process for consensus resolution. And once, a hard fork proposal passes through the process stated in this constitution, it'll have the majority of hash power with majority of coins backing it. The majority of hash power with the backing of the majority coins is what makes the longest chain ticking in bitcoin ecosystem. Everyone else 'obeys' it. |
|
|
|
In the light of recent disagreements that is going on regarding consensus, I thought of if we can define a mathematically verifiable process to achieve the same. Hence I have put up my idea in details at http://upalc.com/bitcoin-constitution.php. The basic is as follows... 1. At least 21 bitcoin should support a hard fork proposal to be discussed. A poll, created on www.bitcoinocracy.com and backed by 21 bitcoins, will suffice for Hard Fork to be discussed by miners. Please note that, 21 is an arbitrary figure. The exact figure can be discussed or voted on by the community before accepting this proposal. 2. More than 50% hash power should support the proposal for at least 21 difficulty period. This can be determined using www.blocktrail.com/BTC/blocks/1 or www.coin.dance/blocks. Please note that, both 50% and 21 are arbitrary figure. The exact figure can be discussed or voted on by the community before accepting this proposal. 3. More than 50% coin must support the proposal, where the total amount of coins participating in the poll is more than 1% of the total supply. This can be determined using a poll on www.bitcoinocracy.com. Please note that, both 50% and 1% are arbitrary figure. The exact figure can be discussed or voted on by the community before accepting this proposal. Any hard forking change should give the network enough time to be aware, test and upgrade. Hence, I propose, all hard forking changes are pushed together only at the time of block reward halving, i.e. once in every four year. Please feel free to rationally criticize and provide your valuable feedback on this proposal. |
|
|
|
Anyone else means are you going as well?
Yah... I was there. Did you present BIP 106? No. Jeff covered it. |
|
|
|
Anyone else means are you going as well?
Yah... I was there. From Unocoin, we have our chief scientist and the creator of saffroncoin going for this conference.
It was nice to meet Roshan. |
|
|
|
|
Bitcoin network does not have any direct incentive to run a full node. But it is healthy for the network to have more nodes securing it. Hence I was toying with the idea that how a bitcoin node can be incentivized without disturbing the existing bitcoin protocol.
It appears to me that sidechains can be used for this purpose. If bitcoin nodes can be equipped in a way so that it can perform as a gateway between bitcoin blockchain and an altcoin blockchain, i.e. validating the altcoin blockchain with bitcoin network with every bitcoin block found, then this concept might work. These nodes will be super node for the altcoin network, but normal for bitcoin network. Those altcoin blockchain or sidechains may incentivize the nodes, like it happen in PoS and in return can be secured by the huge hashing power of the bitcoin network. The altcoins, secured by the bitcoin network, may also help to solve the ~10 minutes delay of bitcoin confirmation.
As I am not an expert of the sidechain technology, I'd like to know from people with knowledge, whether an altcoin blockchain can be pegged to a bitcoin blockchain using a common node ?
|
|
|
|
Hi
Can i know what was the result of the Meetup, how was the response and how many members attended, because i am also thinking of doing meetups in my area. please share you experience here.
3 people attended, they had never heard about bitcoin before. It was just the basic introduction about bitcoin. I distributed paper wallets and demonstrated use of address and private key, through mycelium. One person was interested about low transaction fee remittances from abroad. I explained him the current bitcoin exchange options. Good start. Keep it up. It would be great if you could do something in East India in a larger scale. |
|
|
|
|
আমরা যারা কলকাতা বা তার আসেপাশে থাকি তারা নিজেরা একদিন দেখা করতে পারি নাকি ?
|
|
|
|
I can probably do this. Just for clarification, you want two graphs, one for each proposal, which charts the maximum block size as if your proposals had been implemented since the genesis block. Also assuming 1 MB was the initial limit for the genesis block. Is there a reward  BTW, this doesn't belong in tech support, I have already reported this so it should be moved. Yes, you are right. Nopes, there is no reward as such... |
|
|
|
I proposed BIP 106 to solve the Block Size Max Cap issue - https://github.com/bitcoin/bips/blob/master/bip-0106.mediawiki. The graphs I need are regarding this BIP. Blockchain.info currently provides a graph plotting the historical data of block size for each block, which can be found at https://blockchain.info/charts/avg-block-size?timespan=all&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address=I need two similar graphs plotting max block size cap against each block, calculated as per my two proposal... Proposal 1: Depending only on previous block size calculationThe basic idea in alogorithmic format is as follows... If more than 50% of block's size, found in the first 2000 of the last difficulty period, is more than 90% MaxBlockSize
Double MaxBlockSize
Else if more than 90% of block's size, found in the first 2000 of the last difficulty period, is less than 50% MaxBlockSize
Half MaxBlockSize
Else
Keep the same MaxBlockSize
Proposal 2: Depending on previous block size calculation and previous Tx fee collected by minersThe basic idea in alogorithmic format is as follows... TotalBlockSizeInLastButOneDifficulty = Sum of all Block size of first 2008 blocks in last 2 difficulty period
TotalBlockSizeInLastDifficulty = Sum of all Block size of second 2008 blocks in last 2 difficulty period (This actually includes 8 blocks from last but one difficulty)
TotalTxFeeInLastButOneDifficulty = Sum of all Tx fees of first 2008 blocks in last 2 difficulty period
TotalTxFeeInLastDifficulty = Sum of all Tx fees of second 2008 blocks in last 2 difficulty period (This actually includes 8 blocks from last but one difficulty)
If ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016 > 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty > TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty > TotalBlockSizeInLastButOneDifficulty) )
MaxBlockSize = TotalBlockSizeInLastDifficulty * MaxBlockSize / TotalBlockSizeInLastButOneDifficulty
Else If ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016 < 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty < TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty < TotalBlockSizeInLastButOneDifficulty) )
MaxBlockSize = TotalBlockSizeInLastDifficulty * MaxBlockSize / TotalBlockSizeInLastButOneDifficulty
Else
Keep the same MaxBlockSize
Is it possible to provide these two graphs assuming max block size cap for block 1 was 1mb ? |
|
|
|
Have you submitted this to gmaxwell yet for bip number assignment? If you did, what was his response?
I did. On August 18, 2015 he said that normal procedure is to allow some time for discussion on the list and asked me to post the draft text as well. I did not have the draft text ready by then. As you'll see the draft ( https://github.com/UpalChakraborty/bips/blob/master/BIP-DynamicMaxBlockSize.mediawiki) was made on August 24, 2015. So, after posting the draft text, I contacted him again for BIP no. Since then, I have not heard of him. |
|
|
|
|
Also, please let us know if you are at or around Kolkata...
|
|
|
|
Yes, that is what I mean. BTW, I tried to contribute to your redit thread, but the formating and linebreaks there are mess, I hed to redelet my post 4 times :-). So I hope I did not cause any problems. Well, upalc.com is my personal blog and there are many common sections in the article pages. Hence I coded them in PHP. Regarding the reddit post, it is not mine. I posted the BIP draft in bitcoin dev-list as per GMaxwell's suggestion. Someone read it there and posted it in reddit. But, I dont think, posting and editing your own post will create any problem for anyone. |
|
|
|
Thanks to everyone for providing good arguements for improvement of the proposal. I have derived a second proposal and updated OP accordingly. If you have any counter-arguement to this proposal, feel free to put it here or in the comment section of the article - http://upalc.com/maxblocksize.phpI don't thing it is a good idea to include TX fees in the calculation. See this charts {1}, {2} and {3}Now consider and old miner consolidating his coins and a spammer attacking the network - both will cause increased volume of transactions (more or less in {1}) for a short period, but to succeed in the attack, the spammer (see 10 July and after) will include larger fees {3} and have less days destroyed {2}, while the old miner may 'donate' larger fees (as on 27 April) or use the fact that he may transfer them without fees (end of November), because they are old enough. With your proposal of including the fees in the calculation the block size after 10 July will increase, thus helping the attacker even more, as it will keep increasing the block size (even now), just because others add more fees to mitigate the attack and prioritise their own transactions. Thanks for your input. I was thinking the same and hence modified Proposal 2. This time the max cap increase is depndent on block size increase, but still Tx fee is taken care of, so that miners can be compensated for with decreasing block reward. Please check both Proposal 1 & 2 and share your opinion. It is good if someone can do a simulation with Proposal 1 & 2 and from Block 1 and share the result for both against last difficulty change. |
|
|
|
Thanks to everyone for providing good arguements for improvement of the proposal. I have derived a second proposal and updated OP accordingly. If you have any counter-arguement to this proposal, feel free to put it here or in the comment section of the article - http://upalc.com/maxblocksize.php |
|
|
|
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. |
|
|
|
I have got some very good arguements in the bitcoin-dev list and hence updated the main article. If you have any counter-arguement to this proposal, feel free to put it here or in the comment section of the article - http://upalc.com/maxblocksize.php |
|
|
|
I have tried to solve the maximum block size debate in two different proposal. i. Depending only on previous block size calculation. ii. Depending on previous block size calculation and previous Tx fee collected by miners. BIP 106: https://github.com/bitcoin/bips/blob/master/bip-0106.mediawikiProposal in bitcoin-dev mailing list - http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010285.htmlProposal 1: Depending only on previous block size calculationThe basic idea in alogorithmic format is as follows... If more than 50% of block's size, found in the first 2000 of the last difficulty period, is more than 90% MaxBlockSize
Double MaxBlockSize
Else if more than 90% of block's size, found in the first 2000 of the last difficulty period, is less than 50% MaxBlockSize
Half MaxBlockSize
Else
Keep the same MaxBlockSize
Proposal 2: Depending on previous block size calculation and previous Tx fee collected by minersThe basic idea in alogorithmic format is as follows... TotalBlockSizeInLastButOneDifficulty = Sum of all Block size of first 2008 blocks in last 2 difficulty period
TotalBlockSizeInLastDifficulty = Sum of all Block size of second 2008 blocks in last 2 difficulty period (This actually includes 8 blocks from last but one difficulty)
TotalTxFeeInLastButOneDifficulty = Sum of all Tx fees of first 2008 blocks in last 2 difficulty period
TotalTxFeeInLastDifficulty = Sum of all Tx fees of second 2008 blocks in last 2 difficulty period (This actually includes 8 blocks from last but one difficulty)
If ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016 > 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty > TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty > TotalBlockSizeInLastButOneDifficulty) )
MaxBlockSize = TotalBlockSizeInLastDifficulty * MaxBlockSize / TotalBlockSizeInLastButOneDifficulty
Else If ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016 < 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty < TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty < TotalBlockSizeInLastButOneDifficulty) )
MaxBlockSize = TotalBlockSizeInLastDifficulty * MaxBlockSize / TotalBlockSizeInLastButOneDifficulty
Else
Keep the same MaxBlockSize
Details: http://upalc.com/maxblocksize.phpRequesting for comment. |
|
|
|
|
Show Posts
