Topic: Consensus Reached (Read 5216 times)

Actually that isn't something that is going to take that long if there is consensus for the proposal. Miners could activate it quickly. However, we're looking at a grace period of 9 - 12 months here.

Actually (uneducated) people think that increasing the block size limit is just 1 line of code. However, it is far beyond that and agreeing to the terms is hard. Look at BIP109 (Classic); ~500 lines of code.

That's a different roundtable.

Consensus cancelled:
https://news.bitcoin.com/no-consensus-reached-during-satoshi-roundtable-san-francisco/ 

Welp, I guess I was misinformed; thanks for the heads-up. As you said though, even with the grace period (which isn't expressly mentioned in anything I've read about the newest proposal, though you're probably right that there will be one), the actual activation time of the fork will vary depending on how quickly the activation threshold is reached. What I was trying to address were the concerns that the Core devs are looking to intentionally, "stall", the implementation of the newly agreed upon fork when in reality they're just setting parameters to increase the probability of a (fairly) clean fork.

core is making progress. very nice!

I heard that lots of software have to be written to make it work. All the payment processors have to rewrite their software.

Could u plz point me to the test results ?

That is not what it means. Do you even know how HF's are deployed? Do you not know what a grace period is? Judging from what we know so far, the grace period is going to be anywhere between 6 to 12 months. This means that once you reach the activation threshold, you have to wait additional X amount of time before the activation occurs. It is highly unlikely that we are going to see a HF in 2016. It is definitely not entirely dependent on the miners.

Why? It has been in extensive testing.

Just want to clear up one point that some people might be missing (or intentionally misrepresenting to create FUD). In the roundtable plan, it is stated that, "If there is strong community support, the hard-fork activation will likely happen around July 2017". This is not, as I am interpreting it, a declaration that the hard-fork will be scheduled to activate in July 2017, but that July 2017 is merely the prediction for how long it will take the network to reach consensus (950 of the last 1000 blocks, I'm assuming) and activate the fork; the code which will allow miners to signal support of the fork is scheduled to be available in July 2016. What this means is that the hard-fork could occur any time after the Core release in July 2016 and will be entirely dependent at that point on how quickly miners update to the new version of Core--July 2017 is merely an estimate of when this might occur. If miners really do see the issue as something which needs to be addressed immediately and therefore update quickly, the fork could occur at a much earlier date (1000 blocks is approximately 1 week of mining, so the first week where 95% of miners agree to fork should activate it). Regardless, the delay is not something which Core (or any other implementation) can control, and certainly isn't some nefarious plan to, "cripple", Bitcoin by delaying the changes being agreed upon.

I'd be very happy if this decision could bring a bit of peace back to the Bitcoin community, though all the conspiracy theory stuff probably will take some time to make itself scarce...

It would be better if the hard fork of 2MB comes earlier than the SegWit. I think the latter is more risky.

You're being hyperbolic here and asking too many obvious questions. I've told you how it is. People who were at that meeting (Core/Blockstream) represent themselves as individuals, and in no way possible can they represent (in this case) everyone else (Core).

Those have signed it in the name of their respective companies/pools. Also keep in mind that both Garzik and Gavin were invited (allegedly 'busy').

The problem is that you're not spending enough time reading and trying to understand. You'd rather go around and make accusations. Similar questions have been asked thousands of time. Segwit will give a capacity boost that should be similar to a 2 MB block size limit (exact numbers depend on adoption and type of transactions). How is 'adding capacity' equal to "stalling"? Some calculations:

  I think its a good plan and I can see its merit. All I did was explain why I think its good and what I think is the rationale. Maybe you disagree.  I did not mean to offend you.

AH HA!
thank you
its nice to understand their reasoning behind the decision.
i would like to apologise  for my ignorance, and most incorrect analogy. i am but a simple bitcoiner, shame on me for questioning the validity of the agreement.
it sure FEELS like they are stalling and acting in their own self interest (blockstream), but that is only because I do not understand the details.

If you implement 2mb hardfork it will delay segwit significantly. segwth plus 2mb hardfork will give around 4mb blocks which will mean too high orphan rates for miners, and it would require devs to work on hardfork instead of segwit now.

Segwit gives similar block increase to hard-fork can be rolled out immediately and has many important additional benefits. It also is the quickest way to increase block-size as  devs rightly believe that a hard-fork needs long activation time.

Also if fork is done later we can add some other improvements that also require hard-fork.

i guess, implementing 2MB first probably feels like admitting they were wrong.

it feels like we just convinced a child to do eat his supper, let's not push it and make sure he eats the meat first.

The "longer than normal" confirmation times are not being caused by the blocks being too small. If they were, then the blocks would always be full when this happens but that isn't the case.

If only 80% of the available space is used then doubling the space isn't going magically make transactions added that weren't included when there was space to include them.

I pay more than minimum, that is true, but it still works out to less than a nickel for every transaction - hell, often around a penny.

Maybe some transactions cost more because the user has a wallet full of micro-payments from gambling or from faucets etc. and lots of small inputs really increases the size increasing the cost. That could be fixed by making a button consolidate small inputs into bigger inputs, and that transaction may take awhile.

Maybe some clients are having problems because the client is not well connected, I don't have a solution for that other than maybe manually connecting to well connected nodes.

The blocks are rarely at full capacity though, so its not a block size problem.

https://blockchain.info/charts/avg-block-size

Yes at some point it will start being a problem, though segwit may delay when it is, but it isn't a problem now, ergo people with delayed transactions won't benefit from an increase now. It's simply not the cause of their delay.

I think the bottom line is that there is no good reason not to immediately implement 2 MB blocks. A lot of people are already having much longer than normal transaction confirmation times, and it's going to get a lot worse as the transaction volume continues to grow.

It just makes no sense whatsoever not to implement a simple solution immediately.

So why the fuck are the blockstream devs so opposed to a blocksize increase? It just seems completely devoid of logic.

market reacted very well to the news, economic majority likes this.

the operators said it themselves they CANNOT act without the consent of their clients. they knew what there clients wanted coming in and they got that.and one of the operators is actually a private pool.

for that last point, miners will switch to classic in that case, thats what they said coming in, "we are so fed up with you we will switch to classic if you don't listen to us" or somthing to that effect. I think that is the general sentiment for mostly everyone, so if the  blockstream core devs give us a hard time, we will HF AS SCHEDULED without them.



we'll be fine,  blockstream core devs are learning that the only power they really have is the ability to let there voice be heard, and if they choose to ignore our voice, they will get  what they deserve.

The issue is not with the hashing power (the operators of the pools actually), it is with the blockstream devs. The economic majority of Bitcoin and (most likely) the majority of the mining pools (which currently have the majority of the mining power pointed at them) have wanted larger blocks for a long time. The same is most likely true for much of the userbase. It is the blockstream core devs that are opposed to increasing the maximum block size. If the blockstream core devs oppose a HF then such HF will have a difficult time in getting it's way into production.

Do you think there was a reason why the blockstream core devs only agreed to submit a HF proposal and did not agree to deliver a consensus (especially among the other blockstream core devs)? Do you think there was a reason why SegWit is to be implemented prior to the HF proposal is even released? Do you think there is a reason why Adam Black signed the agreement as an individual and not as the CEO of blockstream (he should have the authority to sign on behalf of blockstream as the CEO, and if blockstream as an entity agrees with the document then someone from the company should sign the document)?

Did you notice that several people signed on behalf of various pools and Bitcoin related companies? Do you think they also only represented themselves? Were these people only agreeing to not run classic on their own person equipment and not on their company's/pool's  equipment?

Already took mine. And seeing the current price trend, seems like most investors did the same.