Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/19/2015 04:06 AM, Jorge Timón wrote: On Wed, Aug 19, 2015 at 12:14 PM, odinn odinn.cyberguerri...@riseup.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Firstly, XT is controversial, not uncontroversial; XT it's just a software fork. You must be really tired. Please read the whole pull request discussing this loathsome subject her e: https://github.com/bitcoin-dot-org/bitcoin.org/pull/899 It was fairly detailed and conclusive. I'm not being a dumdum when I say that it is controversial. BIP101 (as currently implemented in Bitcoin XT) is a Schism hardfork (or an altcoin), but BIP101 could be modified to be deployed like an uncontroversial hardfork (in current bip99's draft, a given height plus 95% mining upgrade confirmation after that). Everybody here is well aware of what this sad proposal is. See detailed reply to the moaning and groaning of Hearn on this subject, where he claimed that the difference between hard and soft forks is actually quite small, has got smaller with time and is thus hardly the policy-founding chasm you seem to think it is. He was wrong, of course. Thus, my reply to that, which I won't bother to quote in detail but which you can read here: https://github.com/bitcoin-dot-org/bitcoin.org/pull/899#issuecomment-117 815987 Third, it poses major risks as a non-peer reviewed alt with a number of problematic features (with the privacy problems recently mentioned on this list being just one of them) Fourth, it has not followed any semblance of process in terms of the development funnel or BIPS process, with XT developers instead choosing instead a dangerous path of hard forking bitcoin while being well aware of miner voting on viable solutions which have followed process. I'm not defending the Schism hardfork being proposed. I am very worried about it and I have publicly said so several times. If Bitcoin XT didn't contained the Schism bip101 hardfork I wouldn't be so worried: users are free to use software that is less reviewed at their own risk. The following proposals http://bipsxdevs.azurewebsites.net/ regardless of what you think of any one of them, are deserving of attention (BIP 100 / BIP 101) and are being voted on as you read this by miners. (BIP sipa is not yet numbered, and BIP 102 is a backup /fallback option.) BIP 100 is probably the best of these (note, in part, it schedules a hardfork on testnet in September). It's users and not miners who decide the consensus rules. Contentious hard forks are bad for Bitcoin. https://bitcoin.org/en/posts/hard-fork-policy You may want to read this again if you haven't recently. You may want to read BIP99 to understand that I know this, but still think that Schism hardforks may be necessary in some situations (I don't think this one is reasonable though). Given the state in which bitcoin is in now, one could say that things are fairly horrible, but by no means necessitating, as you put it, a schism hardfork. It is clear and evidenced by my previous posts and others that Hearn's efforts are an attack on the bitcoin network. There is no basis for further promoting XT by suggesting that it should even be tested. All I'm saying is that Bitcoin XT the software fork is totally fine (like other alternative Bitcoin implementations). It's not totally fine at all. It shouldn't even exist. People are doing other unsuspecting users a disservice by even suggesting that it should be downloaded. The big problem is BIP101 being deployed as a Schism hardfork. This is certainly a problem. #GAVEL - -- http://abis.io ~ a protocol concept to enable decentralization and expansion of a giving economy, and a new social good https://keybase.io/odinn -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJV1GevAAoJEGxwq/inSG8CJXwH/3XX7Osr48MmcJ9mrPyOJ4Zn WxRmdJ99mbO5KhrjD8+eRtFjURQNsQYAJ6ftnQEGaksuprSYCPQQR6WsV9mqRKZ2 /zdSz/5RjdADsjB2FDN6gWpwpyg7tzUpB6D4rCjuL1fcRmieCxwNUxnnFTbedxpE MdT2oj9uSB7tTvU4AYs2VzJq0QeRn/c0pTJkBDwU0c4PN1tv/IQnOzmS+LnQDQJJ eaunhpbmphRzqC9Mh8N7pD40ZyVoM5ysxVv86OaqmsOQL4W01CahQKADB4T/pBla AOPh3LLxp7aamC9aYnBfxIaWXj28BZCwVasDkJdQ/Qg/rV5/Kze7TjJs9G2sowc= =OvDj -END PGP SIGNATURE- ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?
odinn via bitcoin-dev 於 2015-08-19 07:25 寫到: The big problem is BIP101 being deployed as a Schism hardfork. This is certainly a problem. No, BitcoinXT won't become a Schism hardfork, or may be just for a few days, at most. There is one, and only one scenario that BitcoinXT will win: it is supported by major exchanges, merchants, and investors, and they request miners to support it. When BIP101 is activated, these exchanges will refuse to accept or exchange tokens from the old chain. Miners in the old chain can't sell their newly generated coins and can't pay the electricity bill. They will soon realize that they are mining fool's gold and will be forced to switch to the new chain or sell their ASIC. The old chain will be abandoned and has no hope to revive without a hardfork to decrease the difficulty. The dust will settle in days if not hours. Will the adoption of BitcoinXT lead by miners? No, it won't. Actually, Chinese miners who control 60% of the network has already said that they would not adopt XT. So they must not be the leader in this revolution. Again, miners need to make sure they could sell their bitcoin in a good price, and that's not possible without support of exchanges and investors. What about that Not-Bitcoin-XT? The creator of the spoof client may stay anonymous, but the miners cannot. 95% of the blocks come from known entities and they have to be responsible to their actions. And again, they have real money in stake. If bitcoin is destroyed, their ASIC serves at best as very inefficient heaters. So Bitcoin-XT is basically in a win-all-or-lose-all position. It all relies on one condition: the support of major exchanges, merchants, and investors. Their consensus is what really matters. With their consensus, that could not be a Schism hardfork. Without their consensus, nothing will happen. --- Or let me analyse in a different angle. BitcoinXT is in no way similar to your examples of Schism hardforks. All of your examples, ASIC-reset hardfork, Anti-Block-creator hardfork, and Anti-cabal hardfork, are hostile to the current biggest miners and will destroy their investment. These miners have no choice but stick to the original protocol so 2 chains MUST coexist. However, BIP101 has no such effect at all and miners may freely switch between the forks. They will always choose the most valuable fork, so only one fork will survive. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?
On Wed, Aug 19, 2015 at 1:25 PM, odinn odinn.cyberguerri...@riseup.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/19/2015 04:06 AM, Jorge Timón wrote: On Wed, Aug 19, 2015 at 12:14 PM, odinn odinn.cyberguerri...@riseup.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Firstly, XT is controversial, not uncontroversial; XT it's just a software fork. Please read the whole pull request discussing this loathsome subject her e: https://github.com/bitcoin-dot-org/bitcoin.org/pull/899 It was fairly detailed and conclusive. I'm not being a dumdum when I say that it is controversial. And I'm not trying to be a dumdum (whatever that is) when saying that Bitcoin XT the softfork and BIP101 implemented as a schism hardfork in Bitcoin XT are different things. One existed before the other. And if there wasn't a schism hardfork in the making there wouldn't be any warning about Bitcoin XT in bitcoin.org because Bitcoin XT implemented the same consensus rules (and I think was largely ignored). When we say Bitcoin XT is bad some users read Bitcoin Core devs think any code fork to Bitcoin Core is back because they lose control over it. The second is not the case: nobody complained or cared about Bitcoin XT when it implemented the same consensus rules. BIP101 (as currently implemented in Bitcoin XT) is a Schism hardfork (or an altcoin), but BIP101 could be modified to be deployed like an uncontroversial hardfork (in current bip99's draft, a given height plus 95% mining upgrade confirmation after that). Everybody here is well aware of what this sad proposal is. See detailed reply to the moaning and groaning of Hearn on this subject, where he claimed that the difference between hard and soft forks is actually quite small, has got smaller with time and is thus hardly the policy-founding chasm you seem to think it is. He was wrong, of course. Thus, my reply to that, which I won't bother to quote in detail but which you can read here: https://github.com/bitcoin-dot-org/bitcoin.org/pull/899#issuecomment-117 815987 I'm not sure I will learn anything by reading this link (I didn't reading the previous link). Have you read BIP99 already? Can you tell me where you disagree with what's in BIP99 in one of its 2 threads? https://github.com/bitcoin/bips/pull/181 Given the state in which bitcoin is in now, one could say that things are fairly horrible, but by no means necessitating, as you put it, a schism hardfork. It is clear and evidenced by my previous posts and others that Hearn's efforts are an attack on the bitcoin network. Again, I'm against this Schism hardfork but maybe I'm in favor of an Schism hardfork in the future, I don't know. We're both against the Schism hardfork but somehow you think I'm in favor and are trying to change my mind. What are we even discussing about? There is no basis for further promoting XT by suggesting that it should even be tested. All I'm saying is that Bitcoin XT the software fork is totally fine (like other alternative Bitcoin implementations). It's not totally fine at all. It shouldn't even exist. People are doing other unsuspecting users a disservice by even suggesting that it should be downloaded. Right now it shouldn't be downloaded because it contains this quite irrational Schism hardfork. When it was only a not-up-to-date-bitcoin/master + the commits (non-consensus changes) Hearn would like to see in Bitcoin Core nobody was specially worried about it. The big problem is BIP101 being deployed as a Schism hardfork. This is certainly a problem. So what are we discussing about? ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?
On Wed, Aug 19, 2015 at 4:22 PM, jl2012 via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Will the adoption of BitcoinXT lead by miners? No, it won't. Actually, Chinese miners who control 60% of the network has already said that they would not adopt XT. So they must not be the leader in this revolution. Again, miners need to make sure they could sell their bitcoin in a good price, and that's not possible without support of exchanges and investors. So, the exchanges get together to encourage the miners to start running bitcoin-XT. What would they do? One scheme would be to create a taint system. All non-XT coinbases outputs are marked as tainted. All outputs are tainted if any of the inputs into a transaction are tainted. Tainted coins can only be un-tainted by sending 0.5% of their value to the public address of one of the participating exchanges (or to OP_RETURN). They could slowly ratchet up the surcharge. Exchanges in the cartel agree not to exchange tainted coins. Even if some still do, the tainted coins are still inherently less valuable, since fewer exchanges accept them. Schemes like that are the main way for non-miners to flex their muscles, even if they seem unsavory. Taint tracking would allow merchants to participate. They could give less credit for tainted bitcoins, even if the exchanges are trying to remain neutral. If that happens, the exchanges could run 2 prices, BTC and BTC-tainted. On the other hand, implementing taint machinery is a bad thing for fungibility. It can also be accomplished with checkpointing. They need to create 1 big block and then agree to checkpoint it. A less strict rule rule could be that blocks after the first big block count as double POW. That means that the big block chain only needs 34% of the hashing power to win. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?
On Wed, Aug 19, 2015 at 7:30 PM, Danny Thorpe danny.tho...@gmail.com wrote: How do big-block testnet nodes running this 6382 rev recognize each other on the peer network? If I set up a 2MB block limit testnet node and -addnode another 2MB block testnet node (say, JornC's node) to it, and my node mines a block stuffed with 1.3MB of test txs, the other big-block node should accept my mined block, but it will be rejected / immediately orphaned by the rest of the testnet network because it exceeds their notion of block size limit, correct? I have (hopefully) answered your questions in the other thread. Review/testing of #6235 would be also appreciated (to hopefully eventually merge the full #6382 branch into bitcoin/master). ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Firstly, XT is controversial, not uncontroversial; Second, this issue has been beat to death quite a while ago https://github.com/bitcoin-dot-org/bitcoin.org/pull/899#issuecomment-117 815987 Third, it poses major risks as a non-peer reviewed alt with a number of problematic features (with the privacy problems recently mentioned on this list being just one of them) Fourth, it has not followed any semblance of process in terms of the development funnel or BIPS process, with XT developers instead choosing instead a dangerous path of hard forking bitcoin while being well aware of miner voting on viable solutions which have followed process. The following proposals http://bipsxdevs.azurewebsites.net/ regardless of what you think of any one of them, are deserving of attention (BIP 100 / BIP 101) and are being voted on as you read this by miners. (BIP sipa is not yet numbered, and BIP 102 is a backup /fallback option.) BIP 100 is probably the best of these (note, in part, it schedules a hardfork on testnet in September). Contentious hard forks are bad for Bitcoin. https://bitcoin.org/en/posts/hard-fork-policy You may want to read this again if you haven't recently. There is no basis for further promoting XT by suggesting that it should even be tested. #GAVEL On 08/19/2015 02:29 AM, Jorge Timón via bitcoin-dev wrote: On Tue, Aug 18, 2015 at 11:06 PM, Danny Thorpe via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Ya, so? All that means is that the experiment might reach the hard fork tipping point faster than mainnet would. Verifying that the network can handle such transitions, and how larger blocks affect the network, is the point of testing. And when I refer to testnet, I mean the public global testnet blockchain, not in-house isolated networks like testnet-in-a-box. I would expect any uncontroversial hardfork to be deployed in testnet3 before it is deployed in bitcoin's main chain. In any case, you can already do these tests using https://github.com/bitcoin/bitcoin/pull/6382 Note that even if the new testchains are regtest-like (ie cheap proof of work) you don't need to test them in-a-box: you can run them from many different places. Rusty's test ( http://rusty.ozlabs.org/?p=509 ) could have been perfectly made using #6382, it just didn't existed at the time. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev - -- http://abis.io ~ a protocol concept to enable decentralization and expansion of a giving economy, and a new social good https://keybase.io/odinn -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJV1FcVAAoJEGxwq/inSG8CAd8H/R9khvHJJaNKrq7tjzksyc6V jNN8ApaYUOE/i+goKd7XaeW0LM0aUC5vdqOCud632zb9XGo6awlk0fML4FV+wsE0 e5EfVDKZJxQ7zbaNCXXKTUfC+XRpJlhJgfF9jDgTsKv2l8fALbz+U6tn65Ke8F4+ 9A4jJCe8yjttjBkX+8wLsSeDkDsPxo7f29rPfI6YMtN4MYbdxGiLjrTuRWrVje8q l+3IFxrqGwKQl3LygRQHmLosvcW8UZzGYIM7hCleE9NUpc9TdpyTXPB3+9O9h4ty 5vY9jZ6t2Ww9CeljzD8S+1Nycz7sHqeoBCie+WexY7aT/QV2WQxFp4qnpO7PMSs= =UNYA -END PGP SIGNATURE- ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?
On Wed, Aug 19, 2015 at 12:14 PM, odinn odinn.cyberguerri...@riseup.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Firstly, XT is controversial, not uncontroversial; XT it's just a software fork. BIP101 (as currently implemented in Bitcoin XT) is a Schism hardfork (or an altcoin), but BIP101 could be modified to be deployed like an uncontroversial hardfork (in current bip99's draft, a given height plus 95% mining upgrade confirmation after that). Third, it poses major risks as a non-peer reviewed alt with a number of problematic features (with the privacy problems recently mentioned on this list being just one of them) Fourth, it has not followed any semblance of process in terms of the development funnel or BIPS process, with XT developers instead choosing instead a dangerous path of hard forking bitcoin while being well aware of miner voting on viable solutions which have followed process. I'm not defending the Schism hardfork being proposed. I am very worried about it and I have publicly said so several times. If Bitcoin XT didn't contained the Schism bip101 hardfork I wouldn't be so worried: users are free to use software that is less reviewed at their own risk. The following proposals http://bipsxdevs.azurewebsites.net/ regardless of what you think of any one of them, are deserving of attention (BIP 100 / BIP 101) and are being voted on as you read this by miners. (BIP sipa is not yet numbered, and BIP 102 is a backup /fallback option.) BIP 100 is probably the best of these (note, in part, it schedules a hardfork on testnet in September). It's users and not miners who decide the consensus rules. Contentious hard forks are bad for Bitcoin. https://bitcoin.org/en/posts/hard-fork-policy You may want to read this again if you haven't recently. You may want to read BIP99 to understand that I know this, but still think that Schism hardforks may be necessary in some situations (I don't think this one is reasonable though). There is no basis for further promoting XT by suggesting that it should even be tested. All I'm saying is that Bitcoin XT the software fork is totally fine (like other alternative Bitcoin implementations). The big problem is BIP101 being deployed as a Schism hardfork. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?
On Wed, Aug 19, 2015 at 12:34 PM, jl2...@xbt.hk wrote: You misunderstand my intention. The experiment is not about a random hardfork. It's about a block size increase hardfork. One of your goals is show the world that reaching consensus for a Bitcoin hardfork is possible, right? BIP99 can achieve that goal without touching the block size (thus probably less controversial). The data will help us to design further hardfork on block size. The data can be collected using testchains. See #6382 To make it less controversial, the size must not be too big. That makes the data less interesting, doesn't it? To allow a meaningful experiment, the size must not be too small. Technically we could make it 1.01MB but that defeats all objectives I listed and there is no point to do it. It wouldn't defeat the show the world that reaching consensus for a Bitcoin hardfork is possible objective though. But again, we don't need to touch the block size to achieve that goal. That's why I suggest 1.5MB. But that wouldn't be uncontroversial (unless it was accompanied with data that somehow quantifies the risks, in which case maybe another bigger size is acceptable). 1. Today, we all agree that some kind of block size hardfork will happen on t1=*1 June 2016* I disagree with this. I think it should be schedule at least a year after it is deployed in the newest versions. Maybe there's something special about June 2016 that I'm missing. I hope the fork could be done before the halving, which (hopefully) we may have a new bitcoin rush There was only 2 months for the BIP50 hardfork. You may argue that's a bug fix but practically there is no difference: people not fixing the bug in 2 months was forked off. Four months of grace period (Feb to June 2016) is already a double of that. Yes, emergency hardforks are a different case as explained in BIP99's draft. In any case, we all agree that some kind of block size hardfork will happen on June 2016 it's clearly false since I can find many counter-examples besides myself. Also, if we could have zero grace period for softfork, why must we have a ultra-long period for hardfork? (Unless you also agree to have an 1-year grace period for softfork. I don't buy the softfork is safer than hardfork theory. The recent BIP66 fork has clearly shown why it is wrong: non-upgrading full nodes are not full nodes) I don't think giving 1 year for everybody in the world to upgrade is an ultra-long period. I'm proposing 5 years for the hardfork proposed in bip99. I do think softforks are safer than hardforks, that doesn't mean softforks don't have serious risks as well. The problem is many people won't update until they must do so. So 4 months or 1 year make little difference I disagree with this conclusion as well (it doesn't follow from the first sentence, non sequitur). ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?
On Tue, Aug 18, 2015 at 11:54 AM, jl2012 via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: As I understand, there is already a consensus among core dev that block size should/could be raised. The remaining questions are how, when, how much, and how fast. These are the questions for the coming Bitcoin Scalability Workshops but immediate consensus in these issues are not guaranteed. Could we just stop the debate for a moment, and agree to a scheduled experimental hardfork? Objectives (by order of importance): 1. The most important objective is to show the world that reaching consensus for a Bitcoin hardfork is possible. If we could have a successful one, we would have more in the future Apart from classifying all potential consensus rule changes and recommend a deployment path for each case, deploying an uncontroversial hardfork is one of the main goals of bip99: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009837.html 2. With a slight increase in block size, to collect data for future hardforks The uncontroversial hardfork doesn't need to change the maximum block size: there's plenty of hardfork proposals out there, some of them very well tested (like the proposed hardfork in bip99). 1. Today, we all agree that some kind of block size hardfork will happen on t1=*1 June 2016* I disagree with this. I think it should be schedule at least a year after it is deployed in the newest versions. Maybe there's something special about June 2016 that I'm missing. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?
On Tue, Aug 18, 2015 at 11:06 PM, Danny Thorpe via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Ya, so? All that means is that the experiment might reach the hard fork tipping point faster than mainnet would. Verifying that the network can handle such transitions, and how larger blocks affect the network, is the point of testing. And when I refer to testnet, I mean the public global testnet blockchain, not in-house isolated networks like testnet-in-a-box. I would expect any uncontroversial hardfork to be deployed in testnet3 before it is deployed in bitcoin's main chain. In any case, you can already do these tests using https://github.com/bitcoin/bitcoin/pull/6382 Note that even if the new testchains are regtest-like (ie cheap proof of work) you don't need to test them in-a-box: you can run them from many different places. Rusty's test ( http://rusty.ozlabs.org/?p=509 ) could have been perfectly made using #6382, it just didn't existed at the time. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?
A smaller block size would make this a soft fork, as unupgraded nodes would consider the new blocks valid. It would only make things that were allowed forbidden, which is the definition of a soft fork. For a hard fork, you need to allow something that was previously invalid. On Tuesday, August 18, 2015, jl2012 via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: s = 1.5MB. As the 1MB cap was set 5 years ago, there is no doubt that all types of technology has since improved by 50%. I don't mind making it a bit smaller but in that case not much valuable data could be gathered and the second objective of this experiment may not be archived. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?
Ya, so? All that means is that the experiment might reach the hard fork tipping point faster than mainnet would. Verifying that the network can handle such transitions, and how larger blocks affect the network, is the point of testing. And when I refer to testnet, I mean the public global testnet blockchain, not in-house isolated networks like testnet-in-a-box. On Tue, Aug 18, 2015 at 1:51 PM, Eric Lombrozo elombr...@gmail.com wrote: Problem is if you know most of the people running the testnet personally (as is pretty much the case with many current testnets) then the deployment amounts to “hey guys, let’s install the new version” On Aug 18, 2015, at 1:48 PM, Danny Thorpe via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Deploying experimental code onto the live bitcoin blockchain seems unnecessarily risky. Why not deploy a blocksize limit experiment for long term trials using testnet instead? On Tue, Aug 18, 2015 at 2:54 AM, jl2012 via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: As I understand, there is already a consensus among core dev that block size should/could be raised. The remaining questions are how, when, how much, and how fast. These are the questions for the coming Bitcoin Scalability Workshops but immediate consensus in these issues are not guaranteed. Could we just stop the debate for a moment, and agree to a scheduled experimental hardfork? Objectives (by order of importance): 1. The most important objective is to show the world that reaching consensus for a Bitcoin hardfork is possible. If we could have a successful one, we would have more in the future 2. With a slight increase in block size, to collect data for future hardforks 3. To slightly relieve the pressure of full block, without minimal adverse effects on network performance With the objectives 1 and 2 in mind, this is to NOT intended to be a kick-the-can-down-the-road solution. The third objective is more like a side effect of this experiment. Proposal (parameters in ** are my recommendations but negotiable): 1. Today, we all agree that some kind of block size hardfork will happen on t1=*1 June 2016* 2. If no other consensus could be reached before t2=*1 Feb 2016*, we will adopt the backup plan 3. The backup plan is: t3=*30 days* after m=*80%* of miner approval, but not before t1=*1 June 2016*, the block size is increased to s=*1.5MB* 4. If the backup plan is adopted, we all agree that a better solution should be found before t4=*31 Dec 2017*. Rationale: t1 = 1 June 2016 is chosen to make sure everyone have enough time to prepare for a hardfork. Although we do not know what actually will happen but we know something must happen around that moment. t2 = 1 Feb 2016 is chosen to allow 5 more months of negotiations (and 2 months after the workshops). If it is successful, we don't need to activate the backup plan t3 = 30 days is chosen to make sure every full nodes have enough time to upgrade after the actual hardfork date is confirmed t4 = 31 Dec 2017 is chosen, with 1.5 year of data and further debate, hopefully we would find a better solution. It is important to acknowledge that the backup plan is not a final solution m = 80%: We don't want a very small portion of miners to have the power to veto a hardfork, while it is important to make sure the new fork is secured by enough mining power. 80% is just a compromise. s = 1.5MB. As the 1MB cap was set 5 years ago, there is no doubt that all types of technology has since improved by 50%. I don't mind making it a bit smaller but in that case not much valuable data could be gathered and the second objective of this experiment may not be archived. If the community as a whole could agree with this experimental hardfork, we could announce the plan on bitcoin.org and start coding of the patch immediately. At the same time, exploration for a better solution continues. If no further consensus could be reached, a new version of Bitcoin Core with the patch will be released on or before 1 Feb 2016 and everyone will be asked to upgrade immediately. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?
Again, I'm not suggesting further testing in sterile environments. I'm suggesting testing on the public global testnet network, so that real-world hazards such as network lag, bandwidth constraints, traffic bottlenecks, etc can wreak what havoc they can on the proposed implementation. Also, a test deployment would give more people an opportunity to see how the proposed implementation works and kick the tires, which might help to reduce some degree of angst about the proposals. Your point appears to be that the biggest challenge facing Bitcoin is not technical, but political. Sadly, you may be right. On Tue, Aug 18, 2015 at 2:17 PM, Eric Lombrozo elombr...@gmail.com wrote: People have already been testing big blocks on testnets. The biggest problem here isn’t whether we can test the code in a fairly sterile environment. The biggest problem is convincing enough people to switch without: 1) Pissing off the other side enough to the point where regardless of who wins the other side refuses to cooperate 2) Screwing up the incentive model, allowing people to sabotage the process somehow 3) Setting a precedent enabling hostile entities to destroy the network from within in the future etc… These kinds of things seem very hard to test on a testnet. On Aug 18, 2015, at 2:06 PM, Danny Thorpe danny.tho...@gmail.com wrote: Ya, so? All that means is that the experiment might reach the hard fork tipping point faster than mainnet would. Verifying that the network can handle such transitions, and how larger blocks affect the network, is the point of testing. And when I refer to testnet, I mean the public global testnet blockchain, not in-house isolated networks like testnet-in-a-box. On Tue, Aug 18, 2015 at 1:51 PM, Eric Lombrozo elombr...@gmail.com wrote: Problem is if you know most of the people running the testnet personally (as is pretty much the case with many current testnets) then the deployment amounts to “hey guys, let’s install the new version” On Aug 18, 2015, at 1:48 PM, Danny Thorpe via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Deploying experimental code onto the live bitcoin blockchain seems unnecessarily risky. Why not deploy a blocksize limit experiment for long term trials using testnet instead? On Tue, Aug 18, 2015 at 2:54 AM, jl2012 via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: As I understand, there is already a consensus among core dev that block size should/could be raised. The remaining questions are how, when, how much, and how fast. These are the questions for the coming Bitcoin Scalability Workshops but immediate consensus in these issues are not guaranteed. Could we just stop the debate for a moment, and agree to a scheduled experimental hardfork? Objectives (by order of importance): 1. The most important objective is to show the world that reaching consensus for a Bitcoin hardfork is possible. If we could have a successful one, we would have more in the future 2. With a slight increase in block size, to collect data for future hardforks 3. To slightly relieve the pressure of full block, without minimal adverse effects on network performance With the objectives 1 and 2 in mind, this is to NOT intended to be a kick-the-can-down-the-road solution. The third objective is more like a side effect of this experiment. Proposal (parameters in ** are my recommendations but negotiable): 1. Today, we all agree that some kind of block size hardfork will happen on t1=*1 June 2016* 2. If no other consensus could be reached before t2=*1 Feb 2016*, we will adopt the backup plan 3. The backup plan is: t3=*30 days* after m=*80%* of miner approval, but not before t1=*1 June 2016*, the block size is increased to s=*1.5MB* 4. If the backup plan is adopted, we all agree that a better solution should be found before t4=*31 Dec 2017*. Rationale: t1 = 1 June 2016 is chosen to make sure everyone have enough time to prepare for a hardfork. Although we do not know what actually will happen but we know something must happen around that moment. t2 = 1 Feb 2016 is chosen to allow 5 more months of negotiations (and 2 months after the workshops). If it is successful, we don't need to activate the backup plan t3 = 30 days is chosen to make sure every full nodes have enough time to upgrade after the actual hardfork date is confirmed t4 = 31 Dec 2017 is chosen, with 1.5 year of data and further debate, hopefully we would find a better solution. It is important to acknowledge that the backup plan is not a final solution m = 80%: We don't want a very small portion of miners to have the power to veto a hardfork, while it is important to make sure the new fork is secured by enough mining power. 80% is just a compromise. s = 1.5MB. As the 1MB cap was set 5 years ago, there is no doubt that all types of technology has since improved by 50%. I don't mind making it a bit smaller but in that case
[bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?
As I understand, there is already a consensus among core dev that block size should/could be raised. The remaining questions are how, when, how much, and how fast. These are the questions for the coming Bitcoin Scalability Workshops but immediate consensus in these issues are not guaranteed. Could we just stop the debate for a moment, and agree to a scheduled experimental hardfork? Objectives (by order of importance): 1. The most important objective is to show the world that reaching consensus for a Bitcoin hardfork is possible. If we could have a successful one, we would have more in the future 2. With a slight increase in block size, to collect data for future hardforks 3. To slightly relieve the pressure of full block, without minimal adverse effects on network performance With the objectives 1 and 2 in mind, this is to NOT intended to be a kick-the-can-down-the-road solution. The third objective is more like a side effect of this experiment. Proposal (parameters in ** are my recommendations but negotiable): 1. Today, we all agree that some kind of block size hardfork will happen on t1=*1 June 2016* 2. If no other consensus could be reached before t2=*1 Feb 2016*, we will adopt the backup plan 3. The backup plan is: t3=*30 days* after m=*80%* of miner approval, but not before t1=*1 June 2016*, the block size is increased to s=*1.5MB* 4. If the backup plan is adopted, we all agree that a better solution should be found before t4=*31 Dec 2017*. Rationale: t1 = 1 June 2016 is chosen to make sure everyone have enough time to prepare for a hardfork. Although we do not know what actually will happen but we know something must happen around that moment. t2 = 1 Feb 2016 is chosen to allow 5 more months of negotiations (and 2 months after the workshops). If it is successful, we don't need to activate the backup plan t3 = 30 days is chosen to make sure every full nodes have enough time to upgrade after the actual hardfork date is confirmed t4 = 31 Dec 2017 is chosen, with 1.5 year of data and further debate, hopefully we would find a better solution. It is important to acknowledge that the backup plan is not a final solution m = 80%: We don't want a very small portion of miners to have the power to veto a hardfork, while it is important to make sure the new fork is secured by enough mining power. 80% is just a compromise. s = 1.5MB. As the 1MB cap was set 5 years ago, there is no doubt that all types of technology has since improved by 50%. I don't mind making it a bit smaller but in that case not much valuable data could be gathered and the second objective of this experiment may not be archived. If the community as a whole could agree with this experimental hardfork, we could announce the plan on bitcoin.org and start coding of the patch immediately. At the same time, exploration for a better solution continues. If no further consensus could be reached, a new version of Bitcoin Core with the patch will be released on or before 1 Feb 2016 and everyone will be asked to upgrade immediately. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin is an experiment. Why don't we have an experimental hardfork?
- You need to take into account the reward halving, likely to be in 3Q2016. Forks and reward halving at the same time would possibly be a bad combination. - The original proposed date for the fork was December 2015. It was pushed back to January as December is a busy period for a lot of people and businesses. Likewise, June is a busy period for people. July / August is a good period as it is quiet because people go on holiday. A window of 2 months during holiday periods is better than starting in June. January 2016 is better, mainly because of the excessive reward halving chatter likely to be going on.. .. Proposal (parameters in ** are my recommendations but negotiable): 1. Today, we all agree that some kind of block size hardfork will happen on t1=*1 June 2016* 2. If no other consensus could be reached before t2=*1 Feb 2016*, we will adopt the backup plan 3. The backup plan is: t3=*30 days* after m=*80%* of miner approval, but not before t1=*1 June 2016*, the block size is increased to s=*1.5MB* 4. If the backup plan is adopted, we all agree that a better solution should be found before t4=*31 Dec 2017*. .. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
