Topic: Not Bitcoin XT (Read 21883 times)

Is this where I'm supposed to make a 'pouring salt on ice being effective' gag?  Seeing as it's all a joke to you.

Also, you lousy farceur, you haven't thought this through to conclusion.  Why would you even need to spoof a client that allows you to choose your own blocksize anyway?  Just run BU and set your preferred blocksize to 1mb.  Job done.  You don't need to ask someone to code up NotBU.  Or even stick it at 0.3mb if you want to take the lukejr approach (and don't mind getting forked).  The world is your salty oyster.

Why would MLP be salty?  She's leading in the polls.

Only savage-coddling terrorsymp cucks are salty about that fact.

Are you ready for #FREXIT?   

Is that Marine LePen? 

Can you get an upgrade to maybe having a shred of moral fortitude?  Spoofing clients is an attack on Bitcoin's consensus mechanism and should be condemned by honest users.  Why would you endorse such behaviour unless you are deliberately trying to cause havoc?  Your behaviour is far more potentially damaging to the network that any non-core developer could ever be.  You are reprehensible.  Then again, you probably endorse DDOS attacks on alternative client nodes too, so it's pretty much par for the course, right?

Can we get an update to NotBitcoinUnlimited please?   

What is wrong with just adding user agent, protocol peer node filtering?

Satoshi:0.xx.x nodes would have configurable entry to specify which UAs and protocol versions to allow connections from?  This would screw up any statistics about nodes as everyone would have to run with 'satoshi' ua and only specific protocol levels would be allowed.

satoshi nodes would not accept or initiate connections to non satoshi nodes, not matching protocol versions defined in the config file.

Classic and XT can run as truly alt coins on their own network.

So, what's stopping someone from creating Not Bitcoin Classic?

What kind of thing is this, whether this is the third party of Core between XT.

One does not simply remove the 32MB limit.

What is it with Gavinistas and their adorably naive (yet misleading) pipe dreams of scaling Bitcoin by using find/replace in a code editor?   

Sure and in the absence of any other options, I'd vote for BIP100 too. In the short term, there's enough disagreement amongst all the various parties that the 1MBers are going to get their wish...for the rest of 2015 at least.

Some users have said they want bigger blocks ... even though they have no direct vote in the hard fork change.
BIP100 gives bigger blocks ...

C'mon...I think that you'll agree that BIP100 is lacking just a bit of indicated industry support at this point. No? Miners marking blocks is one thing. Need some others like, oh, users to go along with it too, right?

*me looks at BIP100 ...

Ha...c'mon Kano, you've been around long enough to answer that one yourself. Can you point to the last intentional hard fork? I think that by their very nature they will be contentious. Even if all the core devs got together, sang kumbaya and pushed BIPxxx for a 2MB block it'd be hard to get 95% adoption.

Hell, devs haven't even gotten a test hard fork with a 1.1MB block size increase just to prove that hard forks will be adopted.

A smaller majority than used in core ... hmm the "excuse" Gavin used was to disallow a larger pool from stopping it.
Odd how that's not been an issue before ... when certain pools had a much higher % of the network ...

Miners already control block size by the soft limits - I see no reason to give them exclusive control over the max hard limits too. No, miners as a whole aren't stupid but they often do run lazy code (SPV mining fork, Jul 4th) and they also may choose short term personal profit over the greater longterm good.

To me BIP101 seems a better decision where a supermajority needs to agree to set it in motion and a supermajority would need to change it after the fact.

Or to give another example, lets say a BIP666 comes along to set the miner reward per block to 1,000,000 BTC
Of course all miners would vote for it since they are all stupid morons who only want 1,000,000 BTC per block.

Yes my example is as silly as yours.

You need to notice the blatantly obvious ...

Miner rewards depends on the health of bitcoin.
Most of them aren't stupid enough to come up with, or vote for, either your example or mine.

... and ... miners confirm blocks and transactions, no one else does. That's how bitcoin works. If you don't like that, then you are in the wrong place.

This is different. Hard forks are difficult to pull off since they require a supermajority of the entire ecosystem to agree. This hard fork essentially takes a rule that used to be very hard to change and instead makes it relatively easy to change while taking away any input from merchants or users.

BIP 101: miners vote on it once, larger blocks are allowed but no miner would create >1MB blocks unless they believe that enough other miners AND merchants AND users have adopted the change.
BIP 100: The exact same process, except: once BIP 100 is in place miners can vote repeatedly without ANY concern that merchants and users have to adopt the subsequent changes. Only a new hard fork would veto miners from keeping blocks at 1MB or maxing out at 32MB.

Just to give you an example of why BIP 100 is so flawed, imagine for a minute that we aren't talking about block size and imagine that instead we're talking about the block reward schedule. Say that BIP 100 would give miners the ability to vote to accelerate or decelerate the halving process. If miners voted, they could keep the 25 BTC rewards going for 8 years or 12 or more. They could do this without merchants or users having any say, besides introducing a new hard fork taking the vote away from miners. Does that sound like a good idea?

I haven't personally looked at the code, but it's available to read and to run. I didn't base my choice on the BIP language by itself, I based it on the BIP, *and* all the various descriptions by others, *including* that the code does specifically what is described in the BIP. If you've got evidence that the various BIP101 implementations *don't* do what they are said to do, please provide it. In contrast, there is no code available from the other proposals that can be read or run by anyone at the moment, and time keeps moving right along.