With what is he going to attack? The hash power he is using to throw his weight around in LiteCoin or the new ASIC's that are supposed to go to
his customers? This whole BU vs SegWit thing is getting absurd now and people are losing focus on what is most important for Bitcoin. We want
a decentralized and secure Blockchain and not a BugCoin with dodgy code and Bitcoin mining monopolies making ALL the decisions. What is
next... a attack on the Coin Cap?
kprawn your using the reddit script buzzwords "bugcoin".
seems you cannot get passed the BU vs segwit debate.
now ask yourself
if every line of code was the same.. what if hearne invented segwit. would your emotions change
are u defending the code or the devs
secondly taking BU for instance because you mentioned it.. you do realise the "bug" was a core 0.12 bug. and patched in core 0.13
BU patched it in their version. but people in core that knew the consequences of anyone using the core0.12 and so advertised that some people are still using the core 0.12 variant under the title BU. and actually listed how to attack it.
its worth doing research and less time with the reddit buzzwords.
there are many implementations that have different ways of allowing real onchain extra tx capacity.
with segwit. because its reliant on the baseblock and reliant on people using new keypairs, to allow partial data outside base block. maths ans stats shows that only IF 100% of people use segwit keys the network would get ... guess what.. 7tx/s.. emphasis only with 100% certain key utility.. much like the 2009-2017 expectation that never becam a reality.. so even with segwit nothing is really changing capacity wise
yep a one time gesture tx capacity POSSIBILITY with many ifs and maybes. and no guarantee's.. where you cant re segwit a segwit and you are then reliant on waiting another couple years debate to try getting anything else.
the last year and a half have been a waste of time yet those in blockstream, including now recently recruited samson mow want to keep pushing half baked segwit right upto 2019.
core need a plan B
a single merkle proper network upgrade where the blocksize parameter/preference limit can be altered at runtime. so that users and pools are not waiting to be spoonfed by corporate devs.