Re: [bitcoin-dev] A Modified Version of Luke-jr's Block Size BIP
I looked at the discussions about the block size and about Luke-Jr's proposal on Reddit and Bitcointalk. From what I observed of all of the discussions is that few users are in favor of the status quo, and even fewer are in favor of decreasing the block size. The majority of users favored Segwit because it was a block size increase (that was a commonly used reason in support of it and in arguments about increasing the block size). Discussions about Luke-Jr's proposal indicated that many users disagreed with the decrease in block size and the time that it took to increase again to 1 MB. There was not only disagreement but explicit ridicule and mocking of that aspect of the proposal. On 2/6/2017 3:28 PM, Thomas Kerin wrote: > "Many users are of the opposite opinion, that the block size is too > small." - That is newspeak, the users can speak for themselves. > > From whom did you gather feedback from before you changed Luke-Jrs BIP? > > If people don't agree with the proposal, changing it an infinite > number of times light well lead to the same result. > > Have the users spoken, in their response to what Luke-Jr proposed? > > On 6 February 2017 00:53:03 CET, Andrew C via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: > > On 2/5/2017 6:02 PM, Luke Dashjr wrote: > > My BIP draft didn't make progress because the community > opposes any block size increase hardfork ever. > > From what I have observed, it seems to be that people are more so > opposed to a hard fork when there is a comparable soft fork available > than simply opposed to any block size increase hard fork ever. From the > various threads discussing your proposal, it seemed that many would > favor it if it increased over 1 MB sooner or if it never even decreased > in the first place. > > Your version doesn't address the current block size issues > (ie, the blocks being too large). > > Many users are of the opposite opinion, that the block size is too > small. I understand that the decrease is to allow the blockchain size to > grow more slowly thereby allowing users to be more likely to run full > nodes. Unfortunately, I think that we are way past the point of no > return on that. The blockchain is already 100+ GB. Decreasing the block > size is not going to make that any smaller and is not going to make it > any less painful to run a full node. Given that in order to start up a > new full node will still require downloading at least 100 GB of data, I > don't think that decreasing the block size will better facilitate full > node creation. Furthermore, the current trend with ISPs (at least in the > US) is implementing data and bandwidth caps so users are still unlikely > to start up new full nodes regardless of any changes that we can > currently do. > > So you've retained the only certain- DOA parts of my proposal, > and removed the most useful part... I'm not sure the point. > Also, your version is now EXCLUSIVELY a hardfork, so it makes > no sense to keep the BIP 9 deployment at all - either it gets > consensus or it doesn't, but miners have no part in deployment > of it. > > Yes, I know deployment needs to be fixed. I was more proposing this for > comment on the modified block size schedule. I just kept the deployment > as it was originally. However, we could use a modified version of BIP 9 > by using one of the top three bits and a longer locked-in period as a > grace period for all users to upgrade. > > On Sunday, February 05, 2017 9:50:26 PM Andrew C via > bitcoin-dev wrote: > > Hello all, Many people have expressed discontent with > Luke-jr's proposed block size BIP, in particular with the > decrease in size that would occur if it were to be > activated prior to 2024. I have decided to modify the > proposal to instead begin the increase steps at the > current 100 byte limit. The increases and the time > spam of each increase will remain the same, just that the > increase begins from 100 bytes instead of 30 > bytes. Furthermore, instead of a fixed schedule from a > fixed point in time, the increases will instead be > calculated off of the MTP of the activation block (the > first block to be in the active state for this fork). > While this proposal shares many of the same issues with > the one it modifies, I hope that it will be slightly less > controversial and can allow us to move forward w
Re: [bitcoin-dev] A Modified Version of Luke-jr's Block Size BIP
On 2/5/2017 6:02 PM, Luke Dashjr wrote: > My BIP draft didn't make progress because the community opposes any block > size > increase hardfork ever. >From what I have observed, it seems to be that people are more so opposed to a hard fork when there is a comparable soft fork available than simply opposed to any block size increase hard fork ever. From the various threads discussing your proposal, it seemed that many would favor it if it increased over 1 MB sooner or if it never even decreased in the first place. > Your version doesn't address the current block size > issues (ie, the blocks being too large). Many users are of the opposite opinion, that the block size is too small. I understand that the decrease is to allow the blockchain size to grow more slowly thereby allowing users to be more likely to run full nodes. Unfortunately, I think that we are way past the point of no return on that. The blockchain is already 100+ GB. Decreasing the block size is not going to make that any smaller and is not going to make it any less painful to run a full node. Given that in order to start up a new full node will still require downloading at least 100 GB of data, I don't think that decreasing the block size will better facilitate full node creation. Furthermore, the current trend with ISPs (at least in the US) is implementing data and bandwidth caps so users are still unlikely to start up new full nodes regardless of any changes that we can currently do. > So you've retained the only certain- > DOA parts of my proposal, and removed the most useful part... I'm not sure > the > point. Also, your version is now EXCLUSIVELY a hardfork, so it makes no sense > to keep the BIP 9 deployment at all - either it gets consensus or it doesn't, > but miners have no part in deployment of it. Yes, I know deployment needs to be fixed. I was more proposing this for comment on the modified block size schedule. I just kept the deployment as it was originally. However, we could use a modified version of BIP 9 by using one of the top three bits and a longer locked-in period as a grace period for all users to upgrade. > > On Sunday, February 05, 2017 9:50:26 PM Andrew C via bitcoin-dev wrote: >> Hello all, >> >> Many people have expressed discontent with Luke-jr's proposed block size >> BIP, in particular with the decrease in size that would occur if it were >> to be activated prior to 2024. >> >> I have decided to modify the proposal to instead begin the increase >> steps at the current 100 byte limit. The increases and the time spam >> of each increase will remain the same, just that the increase begins >> from 100 bytes instead of 30 bytes. >> >> Furthermore, instead of a fixed schedule from a fixed point in time, the >> increases will instead be calculated off of the MTP of the activation >> block (the first block to be in the active state for this fork). >> >> While this proposal shares many of the same issues with the one it >> modifies, I hope that it will be slightly less controversial and can >> allow us to move forward with scaling Bitcoin. >> >> The full text of the proposal can be found at >> https://github.com/achow101/bips/blob/bip-blksize/bip-blksize.mediawiki. >> My implementation of it is available at >> https://github.com/achow101/bitcoin/tree/bip-blksize >> >> >> Andrew >> >> ___ >> 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] The Soft Fork Deception
On 10/27/2016 11:38 AM, Andrew via bitcoin-dev wrote: > I have been reading recently through the history of soft forks > provided by Bitcoin Core: > https://bitcoin.stackexchange.com/questions/43538/where-can-i-find-a-record-of-blockchain-soft-forks. > > It has led me to think that there is a deceiving notion that soft > forks do not force Bitcoin users to upgrade software. Yes, it's true > that the past soft forks still allow old nodes to accept blocks under > the tighter rules as valid, but what about miners who are still using > old software? What about users who want to make a transaction using > the old rules? Those people are no longer able to do those things. And > if they want to do those things, a hard fork will result. A soft fork means that a transaction using the old rules will still work. Look at segwit, you can still make the original style of transactions with P2PK, P2PKH, and P2SH outputs. There is nothing here to cause a hard fork. > Remember what happened when BIP 66 was activated? Luckily, it was > short lived, but this is just the beginning. If you keep tightening > the rules, you are building up more and more pressure for a split in > the network to occur. You can call this split a "hard fork" or just a > "fork", but it is dangerous either way, and it leads to basically the > creation of two coins when before we just had one, people instantly > lose value, and the trust in Bitcoin's store of value dies. BIP 66's hard fork was not due to the soft fork making transactions invalid. Rather it was because miners were not properly validating blocks before building on top of them. That fork was because a non-upgraded miner created a block invalid under the new rules and upgraded miners did not check the block and built on top of it. That invalid block was only invalid because the isSuperMajority mechanism specified that the new version number must be used otherwise the block was invalid, and that was what happened: the invalid block had the old version number. This is not an issue for BIP 9 Versionbits soft forks because no such rule exists. > > Obviously every one can debate about what should be the definition of > a soft fork, but whatever that is, I think it is unacceptable how > sloppily the past soft forks have been deployed. In what way have these forks been sloppily deployed? The fork caused by previous a soft forks (there was only one that caused that had an actual chain split issue) was due to the isSuperMajority mechanism which is not a good mechanism for deployment. It has been superseded by BIP 9 Versionbits. Furthermore, that fork was not due to "sloppy deployment" by the devs but rather due to greedy miners who were SPV mining. > I can think of many ways in which we could have these new features > that the soft forks provided, but without forcing the new rules, and > simply making them features that can be used on an individual miner or > transaction signer basis. Is there a document from Bitcoin Core that > outlines the philosophy of soft forks and why it is acceptable to > force the tightening of rules and cause such risks? And please give me > another reason other than "it removes a few if statements from the code". Can you explain what other risks you think there are with soft forks? > > Now that Segregated witness is scheduled to be deployed on November > 15, we should take a look at this "soft fork" as well. I like the idea > of Segregated Witness, but from conversations on Reddit and IRC, I see > people saying that this soft fork will be like the others: requiring a > hard fork in order to revert it. Is this true? If you are reading r/btc, you are doing something wrong. Like with all soft forks, the only way to revert them is by a hard fork. Soft forks make previously valid things invalid, hard forks make previously invalid things valid. In order to revert a soft fork which made something invalid, you need to hard fork to make it valid again. > I am getting conflicting messages by reading the BIP. It says that if > all transactions are non-segwit, then a node will validate the block > as before. But if we pass the threshhold (usually 95 % for 1000 > blocks) will miners mining non-segwit blocks be ignored? This is not > good... I really think we should make it optional. Miners will have an > incentive to mine segwit blocks, since it allows for more transactions > per block, so why force them? No. This is incorrect. There is no requirement to include the witness commitment in the coinbase if no transactions in the block contain witnesses. Because transactions that contain witnesses are considered non-standard transactions by the old rules, if a miner who did not upgrade continues to follow those standardness rules, their blocks will not be invalid and they are not forced to upgrade. > What if we want to slightly modify the Segwit protocol in the future? > What if we want to replace segwit with something much different? We > will be forced to do a hard fork in order to
Re: [bitcoin-dev] Start time for BIP141 (segwit)
On 10/17/2016 7:17 AM, Tom Zander via bitcoin-dev wrote: > As Marek wrote just minutes before your email came in; companies will not > roll out their updates until it locks in. Peter Todd says the same thing. > So your assumption that the lock-in time is the END of the upgrading is > false. Thats only the case for miners. But again, how does having a longer fallow period make this any safer? As was mentioned before, a lot of the wallets listed as WIP have code ready and tested, just not officially released, so not listed as ready. It doesn't take 2 months to roll out a software update that is already prepared beforehand. > The entire point here is that SegWit is much bigger than just full nodes > (including miner). > An entire ecosystem of Bitconin will have a need to upgrade. > > I understand people saying that non-miners don't *need* to upgrade in order > to avoid being kicked of the network, but truely, thats a bogus argument. > > People want to actually participate in Bitcoin and that means they need to > understand all of it. Not just see anyone-can-spend transactions. > I think its rather odd to think that developers on this list can decide > the risk profile that Bitcoin using companies or individuals should have. I think it's rather odd that no major Bitcoin companies have raised any such issues with Segwit and in fact many already have the upgrade in the works. I think it's rather odd that individuals who are not opposed to segwit would choose to not upgrade even though it has been actively discussed for the past year. > There are a bunch of really large assumptions in there that I disagree with. > First of all, miners running the latest software doesn't mean the software > is free from flaws. Everyone makes mistakes. People that see a way to abuse > the system may have found things and are not reporting it because they want > to abuse the flaw for their own gains. Which is exactly what happened with > Etherium. While flaws can still be found, unlike the DAO, Segwit has been tested extensively for a much longer period of time. Waiting any longer isn't likely to help given that so much testing and review has already been done. Even so, that is a pointless argument as it is impossible to know whether waiting a little longer would reveal an issue. > > The amount of code and the amount of changes in SegWit makes this a very > dangerous change in (of?) Bitcoin. I counted 10 core concepts in Bitcoin > being changed with it. We don't yet know how they will interact. We can’t. Really? How so? It's been active on 4 different segwit specific testnets and it has been active on the Testnet for the past several months. People have been spamming segwit transactions and extensively testing Segwit since its deployment on Testnet. I think we know how segwit transactions and all aspects of the changes work together as it has been tested as such for several months now. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Start time for BIP141 (segwit)
On 10/16/2016 4:58 PM, Tom Zander via bitcoin-dev wrote: > Lets get back to the topic. Having a longer fallow period is a simple way to > be safe. Your comments make me even more scared that safety is not taken > into account the way it would. Can you please explain how having a longer grace period makes it any safer? Once the fork reaches the LOCKED_IN status, the fork will become active after the period is over. How does having a longer grace period make this any safer besides just adding more waiting before it goes active? You said something about rolling back the changes. There is no mechanism for roll backs, and the whole point of the soft fork signalling is such that there is no need to roll back anything because miners have signaled that they are supporting the fork. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Completing the retirement of the alert system
On 9/10/2016 5:41 AM, Johnson Lau via bitcoin-dev wrote: > 3. After a few months or so, publish the private key. Why wait a few months? Why not just publish the key a few days after the final alert? ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] nSequence multiple uses
With 0.12 and opt-in RBF, nSequence will have multiple uses. It can be used for locktime and now signaling for opting in to RBF. However, there is nothing that I could find that distinguishes the uses for nSequence. Spending a time locked output requires setting nSequence to less than MAX_INT but opting into RBF also requires setting nSequence to less than MAX_INT. By spending a time locked output, you would also be opting into RBF, which may not be desired behavior. Since using nSequence to signal a certain behavior will probably be used in the future, is there any plan to change nSequence so that the features the transaction is using can be distinguished? Perhaps something like version bits? Thanks, Andrew ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] nSequence multiple uses
Ahh. I see. Thanks, I must have missed that when going through the BIP. Guess I need to read more carefully next time. Thanks, Andrew On Fri, Jan 22, 2016 at 11:11 PM David A. Harding <d...@dtrt.org> wrote: > On Fri, Jan 22, 2016 at 04:36:58PM +0000, Andrew C via bitcoin-dev wrote: > > Spending a time locked output requires setting nSequence to less than > > MAX_INT but opting into RBF also requires setting nSequence to less than > > MAX_INT. > > Hi Andrew, > > Opt-in RBF requires setting nSequence to less than MAX-1 (not merely > less than MAX), so an nSequence of exactly MAX-1 (which appears in > hex-encoded serialized transactions as feff) enables locktime > enforcement but doesn't opt in to RBF. > > For more information, please see BIP125: > > https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki > > -Dave > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] What is OpenSSL still used for?
In the release notes for 0.12, it says that we have moved from using OpenSSL to libsecp256k1 for signature validation. So what else is it being used for that we need to keep it as a dependency? Thanks, Andrew ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Questiosn about BIP100
I have been reading the pdf and one thing I can't figure out is what you mean by most common floor. Is that the smallest block size that has a vote or the block size with the most votes or something else? On Mon, Aug 24, 2015 at 10:40 AM Jeff Garzik jgar...@gmail.com wrote: Great questions. - Currently working on technical BIP draft and implementation, hopefully for ScalingBitcoin.org. Only the PDF is publicly available as of today. - Yes, the initial deployment is in the same manner as size votes. On Fri, Aug 21, 2015 at 7:38 PM, Andrew C via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Hi all, Is there any client or code that currently implements BIP 100? And how will it be deployed? WIll the initial fork be deployed in the same manner that the max block size changes are deployed described in the bip? Thanks ___ 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] Questiosn about BIP100
Hi all, Is there any client or code that currently implements BIP 100? And how will it be deployed? WIll the initial fork be deployed in the same manner that the max block size changes are deployed described in the bip? Thanks ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
