Pages:
Author

Topic: BitPay only supports BIP101, NOT BitcoinXT (Read 1570 times)

legendary
Activity: 1596
Merit: 1005
★Nitrogensports.eu★
September 28, 2015, 09:10:22 AM
#38
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.
legendary
Activity: 2506
Merit: 1030
Twitter @realmicroguy
September 28, 2015, 09:03:09 AM
#37
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.
legendary
Activity: 2674
Merit: 1082
Legendary Escrow Service - Tip Jar in Profile
September 28, 2015, 09:01:47 AM
#36
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.
legendary
Activity: 2674
Merit: 1082
Legendary Escrow Service - Tip Jar in Profile
September 28, 2015, 08:58:15 AM
#35
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. Roll Eyes 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?
legendary
Activity: 2590
Merit: 3014
Welt Am Draht
September 25, 2015, 04:39:18 PM
#34
Bitpay's opinion may no longer be relevant pretty soon.
legendary
Activity: 1148
Merit: 1011
In Satoshi I Trust
September 25, 2015, 02:22:08 PM
#33
"BitPay only supports BIP101, NOT BitcoinXT "


okay, then please add BIP 101 and XT is dead  Cheesy   ....(hint: both are the same)
legendary
Activity: 1652
Merit: 1483
September 25, 2015, 02:02:10 PM
#32
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
Quote from: Peter Todd
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)
hero member
Activity: 492
Merit: 500
September 25, 2015, 12:47:40 PM
#31
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.
legendary
Activity: 2212
Merit: 1038
September 25, 2015, 10:43:58 AM
#30
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...
legendary
Activity: 1204
Merit: 1028
September 25, 2015, 10:32:27 AM
#29
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.
legendary
Activity: 2506
Merit: 1030
Twitter @realmicroguy
September 25, 2015, 10:22:56 AM
#28
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.
legendary
Activity: 2674
Merit: 1082
Legendary Escrow Service - Tip Jar in Profile
September 25, 2015, 09:47:39 AM
#27
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.
legendary
Activity: 2674
Merit: 1082
Legendary Escrow Service - Tip Jar in Profile
September 25, 2015, 09:44:12 AM
#26
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.
full member
Activity: 214
Merit: 278
September 21, 2015, 06:20:01 PM
#25
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.
full member
Activity: 196
Merit: 100
September 21, 2015, 05:56:59 PM
#24
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.
 
full member
Activity: 196
Merit: 100
September 21, 2015, 05:54:38 PM
#23
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.
full member
Activity: 214
Merit: 278
September 21, 2015, 05:52:11 PM
#22
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.
legendary
Activity: 2674
Merit: 1082
Legendary Escrow Service - Tip Jar in Profile
September 21, 2015, 05:44:58 PM
#21
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.
newbie
Activity: 42
Merit: 0
I'm pushing for BIP101. XT or Core I don't give a damn. I want bitcoin to scale. The blacklisting thing is just an OPTIONAL Ddos protection. Stop with all that paranoid FUD.

So please stop mentioning XP in your topics. BIP101 is not equal to XT.

XT is the only implementation that support BIP101 right now so be it.

Yet... They released it without waiting for consensus. It can be treated as just another altcoin fork.


The blacklisting thing is just an OPTIONAL Ddos protection. Stop with all that paranoid FUD.

Yes, this leaves an option for NSA/CIA to start attack in order to de-anonymize all the Tor users.


How so?

This:
Quote
Connections are made over clearnet even when using a proxy or
onlynet=tor, which leaks connections on the P2P network with the real
location of the node. Knowledge of this traffic along with uptime metrics
from bitnodes.io can allow observers to easily correlate the location and
identity of persons running Bitcoin nodes. Denial of service can also be
used to crash and force a restart of an interesting node, which will
cause them to make a new request to the blacklist endpoint via the
clearnet on relaunch at the same time their P2P connections are made
through a proxy. Requests to the blacklisting URL also use a custom
Bitcoin XT user agent which makes users distinct from other internet
traffic if you have access to the endpoints logs.
source: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010379.html

It was a false alert:

Quote
So I checked, and the code described *does not* run when behind a
proxy of any kind, including tor:

https://github.com/bitcoinxt/bitcoinxt/commit/73c9efe74c5cc8faea9c2b2c785a2f5b68aa4c23#diff-11780fa178b655146cb414161c635219R265

At least based on my admittedly weak understanding of how the internal works.

Hopefully I save the next reader of your post from also having to dig
around to find the code and realize this is a false alert.

On Tue, Aug 18, 2015 at 6:36 PM F L via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

Source: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010384.html
hero member
Activity: 700
Merit: 501
There will not be a hard fork until January 2016 at the earliest. BIP 101 patch can be implemented in Bitcoin Core as well, and I hope it is and soon. What bothers me is that Mike Hearn used his commit privileges to publish Bitcoin XT with only a 75% adoption threshold by miners. Hard forks are dangerous, and the threshold for adoption should have been 90% or even safer 95%. I suspect he set the threshold too low because he realized chances of 90% consensus approval for Bitcoin XT was slim.

Well they better hurry up with the BIP101 in Core because they are so slow to take measures that XT guys may end up taking the cake. Im all for making things slow and right but right now Core is under pressure.
Pages:
Jump to: