The only reason BU exists, it to block off Segwit and its LN banking layer that would kill the lucrative miner fee market, on which the future crazy security of bitcoin's PoW has to rely. BU proponents (miners) don't want it activated either ; they only use it to block off segwit.
The only remaining option is to keep things as they are, which is called "consensus immutability".
Topic: Why can't the NITWITS understand that SEGWIT IS DEADWIT (Read 522 times)
BTU holds 30%
Segwit requires 95%,
Now follow me here, Absolutely NO MATTER WHAT
100-30= 70
While you are right here with your numbers, you also don't account for people switching sides. Segwit requires 95%,
Now follow me here, Absolutely NO MATTER WHAT
100-30= 70
It is not like we can't change our mind and switch from Bitcoin Unlimited ans start supporting SegWit instead.
Bitcoin Unlimited still feel more amateurish for me than Core, after more and more bugs are discovered it may lose supporters.
Deadwit have never gotten even 40%, their will be no groundswell movement for deadwit, the miners are not so stupid as to give away their transaction fee income.
If you think they are, then send me your paycheck as proof and keep working the same job.
(See when put that way , you can see why deadwit has failed.)
The things you are calling out explicitly there, the taking coins and creating coins-- those were flaws in the very first release of Bitcoin-- many of them design flaws in the algorithms, not just software bugs. (and several of those items aren't bugs at all-- but just updates for past softforks.)
And they were issues in the whole large program, not just a "few" changes recently made.
The resource exhaustion attacks are things that BU even refuses to fix, e.g. BU has a trivial dos of xthin via collision attack and they just won't fix it. ::shrugs:: In fact, one of the items there "A transaction that takes at least 3 minutes to verify" BU reintroduces but zillions of times worse.
BTU is the third of these absurd amateur hour clones of Bitcoin Core. All the other ones have fizzled when the people realized that they are a lot of hard work when you can't just count on copying from Bitcoin Core.
There were larger miners than now actively opposing P2SH, not just not using it yet. Have patience. Bitcoin is forever, not just for next week.
And they were issues in the whole large program, not just a "few" changes recently made.
The resource exhaustion attacks are things that BU even refuses to fix, e.g. BU has a trivial dos of xthin via collision attack and they just won't fix it. ::shrugs:: In fact, one of the items there "A transaction that takes at least 3 minutes to verify" BU reintroduces but zillions of times worse.
BTU is the third of these absurd amateur hour clones of Bitcoin Core. All the other ones have fizzled when the people realized that they are a lot of hard work when you can't just count on copying from Bitcoin Core.
There were larger miners than now actively opposing P2SH, not just not using it yet. Have patience. Bitcoin is forever, not just for next week.
It shows You make mistakes.
Or are you claiming to be the 2nd Coming?
FYI:
You could have just lowered the block speed instead of being part of blockstream's coup trying to seize control of BTC with deadwit & LN.
IE: https://bitcointalksearch.org/topic/m.18206691
BTU holds 30%
Segwit requires 95%,
Now follow me here, Absolutely NO MATTER WHAT
100-30= 70
While you are right here with your numbers, you also don't account for people switching sides. Segwit requires 95%,
Now follow me here, Absolutely NO MATTER WHAT
100-30= 70
It is not like we can't change our mind and switch from Bitcoin Unlimited ans start supporting SegWit instead.
Bitcoin Unlimited still feel more amateurish for me than Core, after more and more bugs are discovered it may lose supporters.
BU has 30% now but they can still decide to switch to SegWit (for example if more problems occur), so it's still possible to reach 95%.
And yes And yes Core has had its problems as BU had recently one, but the important question is who do you think will have fewer and less crucial ones in the future.
And yes And yes Core has had its problems as BU had recently one, but the important question is who do you think will have fewer and less crucial ones in the future.
The things you are calling out explicitly there, the taking coins and creating coins-- those were flaws in the very first release of Bitcoin-- many of them design flaws in the algorithms, not just software bugs. (and several of those items aren't bugs at all-- but just updates for past softforks.)
And they were issues in the whole large program, not just a "few" changes recently made.
The resource exhaustion attacks are things that BU even refuses to fix, e.g. BU has a trivial dos of xthin via collision attack and they just won't fix it. ::shrugs:: In fact, one of the items there "A transaction that takes at least 3 minutes to verify" BU reintroduces but zillions of times worse.
BTU is the third of these absurd amateur hour clones of Bitcoin Core. All the other ones have fizzled when the people realized that they are a lot of hard work when you can't just count on copying from Bitcoin Core.
There were larger miners than now actively opposing P2SH, not just not using it yet. Have patience. Bitcoin is forever, not just for next week.
And they were issues in the whole large program, not just a "few" changes recently made.
The resource exhaustion attacks are things that BU even refuses to fix, e.g. BU has a trivial dos of xthin via collision attack and they just won't fix it. ::shrugs:: In fact, one of the items there "A transaction that takes at least 3 minutes to verify" BU reintroduces but zillions of times worse.
BTU is the third of these absurd amateur hour clones of Bitcoin Core. All the other ones have fizzled when the people realized that they are a lot of hard work when you can't just count on copying from Bitcoin Core.
There were larger miners than now actively opposing P2SH, not just not using it yet. Have patience. Bitcoin is forever, not just for next week.
For the NITWITS that failed 1st grade math. (You know who you are. ) 
BTU holds 30%
Segwit requires 95%,
Now follow me here, Absolutely NO MATTER WHAT
100-30= 70
So there is no way on God's Green Earth segwit could ever attain 95% ,
(FYI: Deadwit can't even get 35%)
So all together Let's make it Official
DEADWIT is Done!
So that leaves Bitcoin Unlimited or a yet to be name lower blockspeed solution. =>https://bitcointalksearch.org/topic/m.18206691
So for Pete Sake , Core / Blockstream get off your ass and fix the transactions issue by increasing blocksize or lowering blockspeed.
Either would work, or be prepared for BTU to take over development of Bitcoin.
And for any of you whinners that want to claim core makes no errors.
I give you https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures (A list of BTC Core's Fuck Ups.)
So for all that claim BTC Core never makes mistakes, History Proves you Wrong!
BTU holds 30%
Segwit requires 95%,
Now follow me here, Absolutely NO MATTER WHAT
100-30= 70
So there is no way on God's Green Earth segwit could ever attain 95% ,
(FYI: Deadwit can't even get 35%)
So all together Let's make it Official
DEADWIT is Done!
So that leaves Bitcoin Unlimited or a yet to be name lower blockspeed solution. =>https://bitcointalksearch.org/topic/m.18206691
So for Pete Sake , Core / Blockstream get off your ass and fix the transactions issue by increasing blocksize or lowering blockspeed.
Either would work, or be prepared for BTU to take over development of Bitcoin.
And for any of you whinners that want to claim core makes no errors.
I give you https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures (A list of BTC Core's Fuck Ups.)
Quote
Common Vulnerabilities and Exposures
CVE Announced Affects Severity Attack is... Flaw Net
CVE-2010-5137 2010-07-28 wxBitcoin and bitcoind DoS[1] Easy OP_LSHIFT crash 100%
CVE-2010-5141 2010-07-28 wxBitcoin and bitcoind Theft[2] Easy OP_RETURN could be used to spend any output. 100%
CVE-2010-5138 2010-07-29 wxBitcoin and bitcoind DoS[1] Easy Unlimited SigOp DoS 100%
CVE-2010-5139 2010-08-15 wxBitcoin and bitcoind Inflation[3] Easy Combined output overflow 100%
CVE-2010-5140 2010-09-29 wxBitcoin and bitcoind DoS[1] Easy Never confirming transactions 100%
CVE-2011-4447 2011-11-11 wxBitcoin and bitcoind Exposure[4] Hard Wallet non-encryption 100%
CVE-2012-1909 2012-03-07 Bitcoin protocol and all clients Netsplit[5] Very hard Transaction overwriting 99%
CVE-2012-1910 2012-03-17 bitcoind & Bitcoin-Qt for Windows Unknown[6] Hard MingW non-multithreading 100%
BIP 0016 2012-04-01 All Bitcoin clients Fake Conf[7] Miners[8] Mandatory P2SH protocol update 99%
CVE-2012-2459 2012-05-14 bitcoind and Bitcoin-Qt Netsplit[5] Easy Block hash collision (via merkle root) 99%
CVE-2012-3789 2012-06-20 bitcoind and Bitcoin-Qt DoS[1] Easy (Lack of) orphan txn resource limits 99%
CVE-2012-4682 bitcoind and Bitcoin-Qt DoS[1] 98%
CVE-2012-4683 2012-08-23 bitcoind and Bitcoin-Qt DoS[1] Easy Targeted DoS by CPU exhaustion using alerts 98%
CVE-2012-4684 2012-08-24 bitcoind and Bitcoin-Qt DoS[1] Easy Network-wide DoS using malleable signatures in alerts 98%
CVE-2013-2272 2013-01-11 bitcoind and Bitcoin-Qt Exposure[4] Easy Remote discovery of node's wallet addresses 97%
CVE-2013-2273 2013-01-30 bitcoind and Bitcoin-Qt Exposure[4] Easy Predictable change output 97%
CVE-2013-2292 2013-01-30 bitcoind and Bitcoin-Qt DoS[1] Hard A transaction that takes at least 3 minutes to verify 0%
CVE-2013-2293 2013-02-14 bitcoind and Bitcoin-Qt DoS[1] Easy Continuous hard disk seek 97%
CVE-2013-3219 2013-03-11 bitcoind and Bitcoin-Qt 0.8.0 Fake Conf[7] Miners[8] Unenforced block protocol rule 100%
CVE-2013-3220 2013-03-11 bitcoind and Bitcoin-Qt Netsplit[5] Hard Inconsistent BDB lock limit interactions 97%
BIP 0034 2013-03-25 All Bitcoin clients Fake Conf[7] Miners[8] Mandatory block protocol update 99%
BIP 0050 2013-05-15 All Bitcoin clients Netsplit[5] Implicit[9] Hard fork to remove txid limit protocol rule 97%
CVE-2013-4627 2013-06-?? bitcoind and Bitcoin-Qt DoS[1] Easy Memory exhaustion with excess tx message data 57%
CVE-2013-4165 2013-07-20 bitcoind and Bitcoin-Qt Theft[10] Local Timing leak in RPC authentication 57%
CVE-2013-5700 2013-09-04 bitcoind and Bitcoin-Qt 0.8.x DoS[1] Easy Remote p2p crash via bloom filters 61%
CVE-2014-0160 2014-04-07 Anything using OpenSSL for TLS Unknown[6] Easy Remote memory leak via payment protocol Unknown
CVE-2015-3641 2014-07-07 Bitcoind and QT prior to 0.10.2 DoS[1] Easy (Yet) Unspecified DoS
Attacker can disable some functionality, for example by crashing clients
Attacker can take coins outside known network rules
Attacker can create coins outside known network rules
Attacker can access user data outside known acceptable methods
Attacker can create multiple views of the network, enabling double-spending with over 1 confirmation
Extent of possible abuse is unknown
Attacker can double-spend with 1 confirmation
Attacking requires mining block(s)
This is a protocol "hard-fork" that old clients will reject as invalid and must therefore not be used.
Local attacker could potentially determine the RPC passphrase via a timing sidechannel.
CVE Announced Affects Severity Attack is... Flaw Net
CVE-2010-5137 2010-07-28 wxBitcoin and bitcoind DoS[1] Easy OP_LSHIFT crash 100%
CVE-2010-5141 2010-07-28 wxBitcoin and bitcoind Theft[2] Easy OP_RETURN could be used to spend any output. 100%
CVE-2010-5138 2010-07-29 wxBitcoin and bitcoind DoS[1] Easy Unlimited SigOp DoS 100%
CVE-2010-5139 2010-08-15 wxBitcoin and bitcoind Inflation[3] Easy Combined output overflow 100%
CVE-2010-5140 2010-09-29 wxBitcoin and bitcoind DoS[1] Easy Never confirming transactions 100%
CVE-2011-4447 2011-11-11 wxBitcoin and bitcoind Exposure[4] Hard Wallet non-encryption 100%
CVE-2012-1909 2012-03-07 Bitcoin protocol and all clients Netsplit[5] Very hard Transaction overwriting 99%
CVE-2012-1910 2012-03-17 bitcoind & Bitcoin-Qt for Windows Unknown[6] Hard MingW non-multithreading 100%
BIP 0016 2012-04-01 All Bitcoin clients Fake Conf[7] Miners[8] Mandatory P2SH protocol update 99%
CVE-2012-2459 2012-05-14 bitcoind and Bitcoin-Qt Netsplit[5] Easy Block hash collision (via merkle root) 99%
CVE-2012-3789 2012-06-20 bitcoind and Bitcoin-Qt DoS[1] Easy (Lack of) orphan txn resource limits 99%
CVE-2012-4682 bitcoind and Bitcoin-Qt DoS[1] 98%
CVE-2012-4683 2012-08-23 bitcoind and Bitcoin-Qt DoS[1] Easy Targeted DoS by CPU exhaustion using alerts 98%
CVE-2012-4684 2012-08-24 bitcoind and Bitcoin-Qt DoS[1] Easy Network-wide DoS using malleable signatures in alerts 98%
CVE-2013-2272 2013-01-11 bitcoind and Bitcoin-Qt Exposure[4] Easy Remote discovery of node's wallet addresses 97%
CVE-2013-2273 2013-01-30 bitcoind and Bitcoin-Qt Exposure[4] Easy Predictable change output 97%
CVE-2013-2292 2013-01-30 bitcoind and Bitcoin-Qt DoS[1] Hard A transaction that takes at least 3 minutes to verify 0%
CVE-2013-2293 2013-02-14 bitcoind and Bitcoin-Qt DoS[1] Easy Continuous hard disk seek 97%
CVE-2013-3219 2013-03-11 bitcoind and Bitcoin-Qt 0.8.0 Fake Conf[7] Miners[8] Unenforced block protocol rule 100%
CVE-2013-3220 2013-03-11 bitcoind and Bitcoin-Qt Netsplit[5] Hard Inconsistent BDB lock limit interactions 97%
BIP 0034 2013-03-25 All Bitcoin clients Fake Conf[7] Miners[8] Mandatory block protocol update 99%
BIP 0050 2013-05-15 All Bitcoin clients Netsplit[5] Implicit[9] Hard fork to remove txid limit protocol rule 97%
CVE-2013-4627 2013-06-?? bitcoind and Bitcoin-Qt DoS[1] Easy Memory exhaustion with excess tx message data 57%
CVE-2013-4165 2013-07-20 bitcoind and Bitcoin-Qt Theft[10] Local Timing leak in RPC authentication 57%
CVE-2013-5700 2013-09-04 bitcoind and Bitcoin-Qt 0.8.x DoS[1] Easy Remote p2p crash via bloom filters 61%
CVE-2014-0160 2014-04-07 Anything using OpenSSL for TLS Unknown[6] Easy Remote memory leak via payment protocol Unknown
CVE-2015-3641 2014-07-07 Bitcoind and QT prior to 0.10.2 DoS[1] Easy (Yet) Unspecified DoS
Attacker can disable some functionality, for example by crashing clients
Attacker can take coins outside known network rules
Attacker can create coins outside known network rules
Attacker can access user data outside known acceptable methods
Attacker can create multiple views of the network, enabling double-spending with over 1 confirmation
Extent of possible abuse is unknown
Attacker can double-spend with 1 confirmation
Attacking requires mining block(s)
This is a protocol "hard-fork" that old clients will reject as invalid and must therefore not be used.
Local attacker could potentially determine the RPC passphrase via a timing sidechannel.
So for all that claim BTC Core never makes mistakes, History Proves you Wrong!
Jump to: