Pages:
Author

Topic: Not Bitcoin XT (Read 21886 times)

legendary
Activity: 3948
Merit: 3191
Leave no FUD unchallenged
February 26, 2017, 08:08:39 AM


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.
legendary
Activity: 2156
Merit: 1072
Crypto is the separation of Power and State.
February 24, 2017, 04:47:05 PM
Is that Marine LePen? 

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?   Cheesy
legendary
Activity: 1638
Merit: 1001
February 24, 2017, 12:03:17 AM
Can we get an update to NotBitcoinUnlimited please?   Grin

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



Is that Marine LePen? 
legendary
Activity: 2156
Merit: 1072
Crypto is the separation of Power and State.
February 23, 2017, 08:32:20 PM
Can we get an update to NotBitcoinUnlimited please?   Grin

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

legendary
Activity: 3948
Merit: 3191
Leave no FUD unchallenged
February 23, 2017, 01:37:00 PM
Can we get an update to NotBitcoinUnlimited please?   Grin

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?
legendary
Activity: 2156
Merit: 1072
Crypto is the separation of Power and State.
February 23, 2017, 07:40:08 AM
Can we get an update to NotBitcoinUnlimited please?   Grin
legendary
Activity: 2702
Merit: 1468
February 06, 2016, 02:14:29 AM
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.
legendary
Activity: 1762
Merit: 1011
February 06, 2016, 01:13:14 AM
So, what's stopping someone from creating Not Bitcoin Classic?
legendary
Activity: 1022
Merit: 1003
𝓗𝓞𝓓𝓛
August 29, 2015, 11:15:22 PM
What kind of thing is this, whether this is the third party of Core between XT. Grin
legendary
Activity: 2156
Merit: 1072
Crypto is the separation of Power and State.
August 29, 2015, 10:15:11 PM
The focus on 32MB seems arbitrary and silly. XT (for example) has the 32MB limit removed - there's no reason core couldn't remove it at the same time as a block size hard fork.

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?   Cheesy
legendary
Activity: 1442
Merit: 1001
August 29, 2015, 09:18:00 PM
... a supermajority needs to agree to set it in motion and a supermajority would need to change it after the fact.
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 ...

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...
*me looks at BIP100 ...

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?
Some users have said they want bigger blocks ... even though they have no direct vote in the hard fork change.
BIP100 gives bigger blocks ...

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.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
August 29, 2015, 09:15:28 PM
... a supermajority needs to agree to set it in motion and a supermajority would need to change it after the fact.
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 ...

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...
*me looks at BIP100 ...

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?
Some users have said they want bigger blocks ... even though they have no direct vote in the hard fork change.
BIP100 gives bigger blocks ...
legendary
Activity: 1442
Merit: 1001
August 29, 2015, 09:07:30 PM
... a supermajority needs to agree to set it in motion and a supermajority would need to change it after the fact.
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 ...

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...
*me looks at BIP100 ...

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?
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
August 29, 2015, 09:05:17 PM
... a supermajority needs to agree to set it in motion and a supermajority would need to change it after the fact.
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 ...

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...
*me looks at BIP100 ...
legendary
Activity: 1442
Merit: 1001
August 29, 2015, 09:04:18 PM
... a supermajority needs to agree to set it in motion and a supermajority would need to change it after the fact.
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 ...

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.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
August 29, 2015, 08:53:42 PM
... a supermajority needs to agree to set it in motion and a supermajority would need to change it after the fact.
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 ...
legendary
Activity: 1442
Merit: 1001
August 29, 2015, 08:18:33 PM
...
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?
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.

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.
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
August 29, 2015, 07:16:41 PM
...
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?
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.
legendary
Activity: 1442
Merit: 1001
August 29, 2015, 01:06:31 PM

BIP100 gives decentralised control of the block size up to 32MB, and indeed some time before the 32MB point (which according to BIP101's invalid extrapolation is ... 4.4 years away) some more discussion will prevail in a sane manner to deal with that 2nd hard fork and how to go beyond it.
Blah blah blah
Translated:
Damn, we lost the vote by a land slide, OK now how else can we come up with some DIFFERENT criteria vs the one WE HAD, to make us win ...

When did Bitcoin cede consensus changes to miners? Remember those other nodes, exchanges, merchants? They aren't going to be overridden so easily.
Bitcoin has always had the consensus changes done by the miners. Technically, nodes, exchanges and merchants have no direct control over the consensus. It has always been and will always be the miners who make the consensus changes because the consensus changes are in the blocks, which are made by miners. Exchanges, merchants, and users have indirect control by giving miners incentives to mine for one consensus change versus another because if miners end up on a fork that no one else uses, they lose money.

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?
legendary
Activity: 1762
Merit: 1011
August 29, 2015, 12:21:00 PM
So ... you studied the copious amount of code changes in XT for your BIP101 decision? i.e. didn't base your choice on the BIP itself?

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.
Pages:
Jump to: