BitPay only supports BIP101, NOT BitcoinXT

[SebastianJu]

Why couldn't one of the core developers simply include the 8mb code into the core and publish it? Did the blockstream developers block that from happening? Then gavin should have done this and create his own fork and not join forces with hearn and his dangerous ideas.

[CounterEntropy]

Why couldn't one of the core developers simply include the 8mb code into the core and publish it? Did the blockstream developers block that from happening? Then gavin should have done this and create his own fork and not join forces with hearn and his dangerous ideas.

Jumping from 1mb to 8mb wont solve the problem. It'll just delay it. After a few years, the controversy will pop again, but with increased adoption, it'd be harder to control. In my opinion, the most logical solution so far to the block size controversy is BIP 106.

[meono]

Why couldn't one of the core developers simply include the 8mb code into the core and publish it? Did the blockstream developers block that from happening? Then gavin should have done this and create his own fork and not join forces with hearn and his dangerous ideas.

Because bitcoin community is smart enough to check bitcoinXT source code and see there is nothing "dangerous"

Dont let the anti big blockers smear BS on your judgment.

[meono]

Why couldn't one of the core developers simply include the 8mb code into the core and publish it? Did the blockstream developers block that from happening? Then gavin should have done this and create his own fork and not join forces with hearn and his dangerous ideas.

Jumping from 1mb to 8mb wont solve the problem. It'll just delay it. After a few years, the controversy will pop again, but with increased adoption, it'd be harder to control. In my opinion, the most logical solution so far to the block size controversy is BIP 106.

BIP106 does not solve a simple solution, network tx capacity. Its a complex solution with uncertainty. If the blocksize limit can be set dynamically in an efficient way. We should not have the limit at all.

Ppl generally confuse between the network difficulty which is a "target" and blocksize limit which is a "capacity". The BIP106 is a perfect example of this misunderstanding.
 

[CounterEntropy]

Why couldn't one of the core developers simply include the 8mb code into the core and publish it? Did the blockstream developers block that from happening? Then gavin should have done this and create his own fork and not join forces with hearn and his dangerous ideas.

Jumping from 1mb to 8mb wont solve the problem. It'll just delay it. After a few years, the controversy will pop again, but with increased adoption, it'd be harder to control. In my opinion, the most logical solution so far to the block size controversy is BIP 106.

BIP106 does not solve a simple solution, network tx capacity. Its a complex solution with uncertainty. If the blocksize limit can be set dynamically in an efficient way. We should not have the limit at all.

Ppl generally confuse between the network difficulty which is a "target" and blocksize limit which is a "capacity". The BIP106 is a perfect example of this misunderstanding.
 

Wrong. Network tx capacity is a different factor. It has its share in determining the max block size cap in BIP 106. But, max block size cap can not have any influence on network tx capacity. If you think otherwise, please explain with example.

[SebastianJu]

Why couldn't one of the core developers simply include the 8mb code into the core and publish it? Did the blockstream developers block that from happening? Then gavin should have done this and create his own fork and not join forces with hearn and his dangerous ideas.

Jumping from 1mb to 8mb wont solve the problem. It'll just delay it. After a few years, the controversy will pop again, but with increased adoption, it'd be harder to control. In my opinion, the most logical solution so far to the block size controversy is BIP 106.

Personally i would remove this artificial restriction completely. The all feared spam simply won't happen, it did not happen all the time, why should it then suddenly?

And even when, simply implement a smarter protection against spam.

[SebastianJu]

Why couldn't one of the core developers simply include the 8mb code into the core and publish it? Did the blockstream developers block that from happening? Then gavin should have done this and create his own fork and not join forces with hearn and his dangerous ideas.

Because bitcoin community is smart enough to check bitcoinXT source code and see there is nothing "dangerous"

Dont let the anti big blockers smear BS on your judgment.

Still, even when the prioritizing would not lead to tor banned, in case of ddos, it still is something he should not have included. That was incredibly stupid, though we are known stupid things from hearn. So nothing new here.

Might be that this is not really dangerous yet but hearn itself is dangerous with all his ideas. I would like to be as far as possible from him though unfortunately there is no other way yet to support a higher blocksize.

[MicroGuy]

I was watching an interview with Gavin a little while ago and he said at least 5 or 6 times during the video that Coinbase and Bitpay should have the greatest input over the block size decision. Here's the video: https://www.youtube.com/watch?t=2&v=B8l11q9hsJM

So a company that can't manage to stay afloat and has an executive sending millions of dollars to the wrong person should have the most input? This is the kind of thinking that is killing Bitcoin.

In my view, Gavin should simply rejoin core and lobby for 8MB blocks now with no auto doubling. Then they can fork again down the road. The XT project should probably be scrapped altogether.

[BillyBobZorton]

Why couldn't one of the core developers simply include the 8mb code into the core and publish it? Did the blockstream developers block that from happening? Then gavin should have done this and create his own fork and not join forces with hearn and his dangerous ideas.

Because raising the blocksize while there is a huuge gap of unused mb's raises tons of exploits and problems, thats why raising the blocksize is such an huge debate.
Bitpay fucked up big time  anyway, im not taking these guys serious anymore and I don't like a third party to deal with my transactions.

[notbatman]

Why couldn't one of the core developers simply include the 8mb code into the core and publish it? Did the blockstream developers block that from happening? Then gavin should have done this and create his own fork and not join forces with hearn and his dangerous ideas.

Because bitcoin community is smart enough to check bitcoinXT source code and see there is nothing "dangerous"

Dont let the anti big blockers smear BS on your judgment.

OpenSSL has been open source for years and years and years...

[Nancarrow]

Why couldn't one of the core developers simply include the 8mb code into the core and publish it? Did the blockstream developers block that from happening? Then gavin should have done this and create his own fork and not join forces with hearn and his dangerous ideas.

Because bitcoin community is smart enough to check bitcoinXT source code and see there is nothing "dangerous"

Dont let the anti big blockers smear BS on your judgment.

OpenSSL has been open source for years and years and years...

This is a good point. The simple fact that anyone CAN check the source code and find critical bugs is, as the openssl clusterfuck showed, not a sufficient guarantee that enough competent people WILL check the source code and find critical bugs.

Of course, that caveat applies equally well to both XT and Core.

[figmentofmyass]

Why couldn't one of the core developers simply include the 8mb code into the core and publish it? Did the blockstream developers block that from happening? Then gavin should have done this and create his own fork and not join forces with hearn and his dangerous ideas.

Because bitcoin community is smart enough to check bitcoinXT source code and see there is nothing "dangerous"

Dont let the anti big blockers smear BS on your judgment.

OpenSSL has been open source for years and years and years...

This is a good point. The simple fact that anyone CAN check the source code and find critical bugs is, as the openssl clusterfuck showed, not a sufficient guarantee that enough competent people WILL check the source code and find critical bugs.

Of course, that caveat applies equally well to both XT and Core.

indeed. however, one aspect that comes into play here is a more rigorous auditing/testing process for pulls. the fact that the XT code was primarily peer-reviewed by one person before it was released was reason enough never to run it.

indeed, Peter Todd exhibited this point well when he pointed out this bug in an XT patch:

https://www.reddit.com/r/Bitcoin/comments/3kenp1/stress_test_commence_as_of_now_were_seeing_23/cuwxvbz

Your mempool limiting technique creates a cheap network bandwidth DoS attack.

The problem is Gavin's patch evicts random transactions (and their descendants) from the mempool without regard to what fees anything paid; in Bitcoin we use paying fees to limit DoS attacks, so anytime a transaction can be broadcast without having a high probability of eventually paying the fee is very bad. Evicted transactions aren't recorded, so if a peer rebroadcasts them to you you'll redownload them. Equally that makes up a bunch of space for different rebroadcasted transactions respending UTXO's that were previously spent. Either way, bandwidth is being used that isn't being paid for.

This is all very well known stuff, and dealing with it is most of the reason why Core is actively working towards implementing a mempool sorted by fees. That you quickly merged Gavin's patch is a sign you don't have much peer review, given that a multiple simpler, working, alternatives exist if you just want something fast to implement. (e.g. the feerate tier idea discussed on IRC/github)

[LiteCoinGuy]

"BitPay only supports BIP101, NOT BitcoinXT "


okay, then please add BIP 101 and XT is dead     ....(hint: both are the same)

[gentlemand]

Bitpay's opinion may no longer be relevant pretty soon.

[SebastianJu]

Why couldn't one of the core developers simply include the 8mb code into the core and publish it? Did the blockstream developers block that from happening? Then gavin should have done this and create his own fork and not join forces with hearn and his dangerous ideas.

Because raising the blocksize while there is a huuge gap of unused mb's raises tons of exploits and problems, thats why raising the blocksize is such an huge debate.
Bitpay fucked up big time  anyway, im not taking these guys serious anymore and I don't like a third party to deal with my transactions.

That is no answer to my question. It would have been better gavin would have done this instead merging with hearn and his dangerous ideas. The implemention of his "DDOS Protection" shows how stupid hearn acts. It was so clear what will happen, though maybe not for him.

Sometimes it even makes the most sense to me that he worked for the NSA at google and now works for the NSA at bitcoin xt. Yeah, tinfoil hat. But i don't understand his stupid acts otherwise.

What kind of exploits do you mean? You realize that we lived all the time with blocks that weren't nearly filled? Now where suddenly should all the attacks come from?

[SebastianJu]

Why couldn't one of the core developers simply include the 8mb code into the core and publish it? Did the blockstream developers block that from happening? Then gavin should have done this and create his own fork and not join forces with hearn and his dangerous ideas.

Because bitcoin community is smart enough to check bitcoinXT source code and see there is nothing "dangerous"

Dont let the anti big blockers smear BS on your judgment.

OpenSSL has been open source for years and years and years...

This is a good point. The simple fact that anyone CAN check the source code and find critical bugs is, as the openssl clusterfuck showed, not a sufficient guarantee that enough competent people WILL check the source code and find critical bugs.

Of course, that caveat applies equally well to both XT and Core.

I think so too. Especially for small projects it might be unlikely that the code get's checked correctly. The next thing is that no one reverse engineers code. Building a software from source might protect you but who protects all the users that use the executables? You will never get the same exe file when creating your exe from source. So you can't be sure that the exe has the same sourcecode.

[MicroGuy]

Bitpay's opinion may no longer be relevant pretty soon.

Gavin has said repeatedly that Bitpay's opinion is paramount and takes precedence over the mining majority and users. In his mind, Bitpay (along with Coinbase) IS God.

[Hazir]

Bitpay's opinion may no longer be relevant pretty soon.

Gavin has said repeatedly that Bitpay's opinion is paramount and takes precedence over the mining majority and users. In his mind, Bitpay (along with Coinbase) IS God.

Is not BitPay compromised? Recently it was reported that BitPay was the target of a hacking incident where it lost over 5000 bitcoins.
I am not sure if CEO fucked up or hackers really stole their coins, but nonetheless their credibility as a company is shattered.