.

[Cuidler]

Segwit is not ready now, this statement is true. You are attempting to twist the truth. I do not think we should bet the future of Bitcoin on unfinished technology.

Neither is 2 MB. Do we have experience with that? No. Nobody is betting any future on anything; Bitcoin works regardless of the block size.

If that was true, Core could increase the blocksize limit to two megabytes now, and resolve this entire debate. Instead of expecting us to "trust" them to do it at a unspecified time, while at the same time realizing they have a conflict of interest to keep the blocksize small and have a strong ideology to not increase the blocksize, contrary to Satoshi's vision.

Satoshi's vision is irrelevant. Why would they do that? There isn't enough consensus for 2 MB.

Yes that is how Bitcoin works. It might seem counter intuitive from an engineering perspective, but from the perspective of freedom and decentralization it is great.

This has nothing do to with decentralization and will end up centralizing Bitcoin which is obviously one of the underlying goals behind both BU and Classic.

Brain washed? Bitcoin Core approves SegWit blocks up to 4 MB are ok and no problem for decentralization. Gosh, SegWit is not magic here, and  Bitcoin Core supporting up to 4 MB SegWit blocks invalidate every one of your argument here...

[MicroGuy]

Satoshi's vision is irrelevant.

Honestly never thought I'd hear that statement from a bitcointalk staff member.

[VeritasSapere]

2 MB can be achieved now with Bitcoin Unlimited. Bitcoin Classic will be released soon as well.

There's a Segwit test-net. Again, no experience with a 2 MB block size.

I do not think consensus is even necessary, this I know is a technical fact. Satoshi's vision is very relevant that does not mean he had to be right, I just happen to agree.

Then why are you trying to split the network in the sake of "decentralization" and underlying visions of nonsense? Fork off now and the market will move to the implementation if the economic majority agrees with you, will it not?

Based on what? Bitcoin unlimited is very much is in the spirit of decentralization. Bitcoin Classic can represent a community take over, reflecting the will of the economic majority.

Based on logic and common sense. Storing hundreds of GB of video and other useless data that nobody needs nor wants on their node is not going to centralize the network? I will be the first to exit the decentralization process shall that happen. Classic represents nothing but a bad attempt of a takeover.

"Of course Classic represent a take over of the network because they dare to increase the blocksize to 2 megabyte without the "permission" of Core, therefore it must be their plan to centralize Bitcoin"

I am sure that I am not the only one that thinks that sounds ridiculous.

[Lauda]

Brain washed? Bitcoin Core approves SegWit blocks up to 4 MB are ok and no problem for decentralization. Gosh, SegWit is not magic here, and  Bitcoin Core supports for up to 4 MB SegWit blocks invalidate every one of your argument here...

Effective 4 MB with Segwit? That is just wishful thinking. Don't post nonsense. This has nothing to do with my arguments.

Honestly never thought I'd hear that statement from a bitcointalk staff member. Very sad!

Satoshi is not some all knowing god; most of the Bitcoin code was changed/rewritten in one way or another. If there was a possibility to redesign Bitcoin from scratch we would, but it is too late for that. We're trying to fight for one of the fundamental ideas of Bitcoin which is decentralization. Big blocks do not help with this, especially not with an already stagnating node count.

"Of course Classic represent a take over of the network because they dare to increase the blocksize to 2 megabyte without the "permission" of Core, therefore it must be their plan to centralize Bitcoin"
I am sure that I am not the only one that thinks that sounds ridiculous.

Who mentioned 'Core', 'permission'? Nobody. You're making your own conclusions to indirectly attack me or try to weaken my arguments. If Core suggested a rushed hard fork (especially if we had no experience with this like we currently don't) with a 75% consensus threshold, I'd be against it. If we disregard the people behind the implementations, a 75% HF is still a network split and definitely harmful.

[Spoetnik]

I'm sorry for the ignorance, but does this mean a hard-fork is coming soon?

This is code that has been submitted to Core for their review. A hard fork would only occur if this code were implemented and 75% mining power agreed. This would be followed by a 28-day grace period after which time older clients would not be compatible with the network.

I think this proposal will be given serious consideration. For all intents and purposes, this is the "Satoshi BIP." It's what Satoshi would have done in this situation.

People claim he made it the way it is now so how can you say that ?

[franky1]

We're trying to fight for one of the fundamental ideas of Bitcoin which is decentralization. Big blocks do not help with this, especially not with an already stagnating node count.

so 2mb blocks are not good for decentralization?? .. hmmm blockstream 0.13SW full archival mode effectively 2mb(same thing different packaging)

also you were trying to state on many other threads that not updating was ok and compatible, stating that you want users to be ok with not being full archive mode. is actually a recipe that turns alot of full nodes into compatible blind, pass the parcel nodes. which is actually going to stagnate the FULL node count.

so we agree that 2mb is not a problem (because of your love for segwit which for full nodes is 2mb) we debunked your theory about processing time because any implementation can use the same libsecp256k1.

so your problem seems to be more about if your friends remain in control of the commit keys

[Cuidler]

Brain washed? Bitcoin Core approves SegWit blocks up to 4 MB are ok and no problem for decentralization. Gosh, SegWit is not magic here, and  Bitcoin Core supports for up to 4 MB SegWit blocks invalidate every one of your argument here...

Effective 4 MB with Segwit? That is just wishful thinking. Don't post nonsense. This has nothing to do with my arguments.

Up to 4 MB if filled with 15of15 multisig Segwit transactions - but you need to test worst case scenario which is 4 MB blocks processed, relayed and stored, of which at least 3 MB are signatures. Bitcoin Core feels it is safe for full nodes and decentralization, so what part you dont agree with?

The same 2 MB blocksizes is just limit and will not be filled everytime, but it needs to be tested for processing, relaying and storing of 2 MB blocksizes, even though it is just worst case scenario.

[Lauda]

so we agree that 2mb is not a problem (because of your love for segwit which for full nodes is 2mb) we debunked your theory about processing time because any implementation can use the same libsecp256k1.

Libsecp256k1 has nothing to do with the validation time; your idiocy is astounding. Your employer will fire you if you keep being so obvious.

In 0.12 validation is switched to libsecp256k1, and it makes validation much faster (especially on x86_64). It doesn't help with the O(n^2) hashing problem, because that's about the computation of the hashes that are being verified. However, segwit does contain a solution for that (which only applies to transactions choosing to use it, but the other ones are limited to 1 MB).

Also know as BIP 143, not some workaround as Gavin proposed and classified as a fix.

so your problem seems to be more about if your friends remain in control of the commit keys

A) They are not my friends; B) Blockstream has 1 person with commit access. Is Andreas Schildbach another 'Blockstream shill' because he actually knows what he's talking about and is supportive of Segwit?  

[bargainbin]

...
A) They are not my friends;

So... "employers," "owners," or "masters"?
*Like yourself, I'm certain anyone disagreeing with me is doing it for money.

[Lauda]

So... "employers," "owners," or "masters"?

No. You're implying that I'm biased even though I have stated several times that I'd strongly disapprove of a contentious HF proposed by Core. I have barely had any interaction with any of the developers (aside of asking technical questions). Nobody knows my identity.

[ldrapeau]

Good news - who thinks this action justified a $15.00 price hike (2015-02-03 ~ 08:00 EST)  or does it have nothing to do with it?

[Lauda]

Good news - who thinks this action justified a $15.00 price hike (2015-02-03 ~ 08:00 EST)  or does it have nothing to do with it?

Estranged Core Developer Gavin Andresen Finally Makes Sensible 2MB BIP Proposal!
January 28, 2016, 10:02:43 PM

You're a few days late.

[bargainbin]

So... "employers," "owners," or "masters"?

No. You're implying that I'm biased here even though I have stated that I'd strongly disapprove of a contentious HF proposed by Core a number of times. I have barely had any interaction with any of the developers (aside of asking technical questions). Nobody knows my identity.

I'm asking a simple "pick one out of three" question. You outright call your opponents shills, I'm offering you a choice [albeit, understandably, limited].

[BlindMayorBitcorn]

so we agree that 2mb is not a problem (because of your love for segwit which for full nodes is 2mb) we debunked your theory about processing time because any implementation can use the same libsecp256k1.

Libsecp256k1 has nothing to do with the validation time; your idiocy is astounding. Your employer will fire you if you keep being so obvious.

In 0.12 validation is switched to libsecp256k1, and it makes validation much faster (especially on x86_64). It doesn't help with the O(n^2) hashing problem, because that's about the computation of the hashes that are being verified. However, segwit does contain a solution for that (which only applies to transactions choosing to use it, but the other ones are limited to 1 MB).

Also know as BIP 143, not some workaround as Gavin proposed and classified as a fix.

so your problem seems to be more about if your friends remain in control of the commit keys

A) They are not my friends; B) Blockstream has 1 person with commit access. Is Andreas Schildbach another 'Blockstream shill' because he actually knows what he's talking about and is supportive of Segwit?  

Do you realize you quoted this: Schildbach shared the concerns as presented by Bitcoin Classic, and believes a hard fork to be the preferred solution.
“Blocks are full, and I don’t agree that a hard fork solution would be short notice. We’ve been discussing this issue for years now! I would prefer we roll out a hard fork,” he said.

[Lauda]

Do you realize you quoted this: Schildbach shared the concerns as presented by Bitcoin Classic, and believes a hard fork to be the preferred solution.
“Blocks are full, and I don’t agree that a hard fork solution would be short notice. We’ve been discussing this issue for years now! I would prefer we roll out a hard fork,” he said.

Yes; however that's not why I quoted the article and is a straw-man if used as an argument. He never mentions anything about the problematic consensus threshold, but I don't want to discuss this again.

That said, I can live with a soft fork, too. And I hope one day a hard fork will be used to clean up the soft-forking mess we leave behind.

Eventually we must/should do a HF.

[franky1]

we debunked your theory about processing time because any implementation can use the same libsecp256k1.

Libsecp256k1 has nothing to do with the validation time; your idiocy is astounding. Your employer will fire you if you keep being so obvious.

i said PROCESSING TIME.. you assume i meant hashing time as i can only guess thats what you meant by your.. "validation time". because maybe you dont know the difference.

by the way your allegience to blockstream is too obvious. yet i have not shown an allegience to gavin coin or toomin coin or blockstream. my personal opinion is purely on a clean coded implementation of 2mb blocks, without any corporate backers running the show. and without any crappy roadmaps that divert users away from bitcoin.. that goes for all 3 shellgames.. r3, toomin and blockstream

to me i think blockstreams early plan was to send out 2 scape-goats to make people hate them and then concede defeat to let blockstream win by default, before people notice blockstreams corporate backers.

and lastly lauda.. blocks on the majority are 900k full (only a few miners are ignorant to stay below 500k).. so knowing blocks are 900k, and knowing you have found some good news about 70million WoT gamers may start accepting bitcoin.. how are they going to transact without bottlenecks.. afterall it was you that said that there isnt a problem with full blocks yet..
when is yet?

maybe you need to learn the word BUFFER

[BlindMayorBitcorn]

Do you realize you quoted this: Schildbach shared the concerns as presented by Bitcoin Classic, and believes a hard fork to be the preferred solution.
“Blocks are full, and I don’t agree that a hard fork solution would be short notice. We’ve been discussing this issue for years now! I would prefer we roll out a hard fork,” he said.

Yes; however that's not why I quoted the article and is a straw-man if used as an argument. He never mentions anything about the problematic consensus threshold, but I don't want to discuss this again.

That said, I can live with a soft fork, too. And I hope one day a hard fork will be used to clean up the soft-forking mess we leave behind.

Eventually we must/should do a HF.

If the fullblocalyse isn't reason enough, what will be?

[youhgt2]

Where can I find more info about this proposal?

[Lauda]

i said PROCESSING TIME..

I never talked about processing time, I was always talking about validation time and thus your idiocy is astounding. Clever move though, I didn't even read that one properly. So even the assumption is wrong.

by the way your allegience to blockstream is too obvious. yet i have not shown an allegience to gavin coin or toomin coin or blockstream. my personal opinion is purely on a clean coded implementation of 2mb blocks, without any corporate backers running the show. and without any crappy roadmaps that divert users away from bitcoin.. that goes for all 3 shellgames.. r3, toomin and blockstream

You obviously have some problems as I have stated otherwise multiple times (I don't support a contentious HF regardless of who's behind it). Yeah and Classic isn't run by the brothers that are trying hard to push their product Consider.it.   You've changed stances pretty quickly like a few other individuals which makes it pretty obvious that there is "no allegiance". Enough of this, I'm putting you back on ignore list, that's where you belong after so much ad hominem.

If the fullblocalyse isn't reason enough, what will be?

Once it is safe to deploy a increase of the block size (between 2-4 MB I'd say). This HF now does not do anything necessary besides a block size increase. If we're going to do one, then we might as well include other changes (if needed). Obviously this is just my opinion, I can't tell you when this is going to happen as I have no idea.

Where can I find more info about this proposal?

BIP.

[ldrapeau]

Good news - who thinks this action justified a $15.00 price hike (2015-02-03 ~ 08:00 EST)  or does it have nothing to do with it?

Estranged Core Developer Gavin Andresen Finally Makes Sensible 2MB BIP Proposal!
January 28, 2016, 10:02:43 PM

You're a few days late.

Oops - sorry about that, thought it was a new topic.  Any idea when this could be implemented?