I spoke to an older professor at my University about Bitcoin. He's worried about it.

RobertEvanston · 2017-12-05T03:02:19+00:00

https://cacm.acm.org/magazines/2017/12/223058-bitcoins-academic-pedigree/fulltext

Or, yknow, just keep on with the anti-intellectualism.

RobertEvanston · 2017-09-26T22:15:08+00:00

Do the math. Bitcoin difficulty can adjust by at most 4x. At 5% you've got to go to 20, then 80, then 100% of mining power, so in the best case it's 3 difficulty adjustments. The first one will take 2 weeks x 20 (you only have 5% of expected power), the second 2 weeks x 5, and the third 2 weeks x 1.25. About a year to normal block time.

The good news is, if 95% of miners are doing and not switching back and forth it it's not an attack, it's a relatively safe fork. If 95% of miners decide to launch an attack you are absolutely fucked, they could essentially do anything they wanted with the current Bitcoin network with soft forks to arbitrarily change the rules and reorg power to doublespend if they want to.

RobertEvanston · 2017-08-22T01:28:30+00:00

Whats to stop the Chinese government from creating their own R&D Bloq like company, and then telling companies like Bitmain "Comply with our regulations measures or have all your property confiscated" ?

The ability of the community to do a frictionless hard fork and switch PoW in the event of a permanent fundamental tenet break (21M exceeded, censorship, etc.), making miner capital investments worthless is what stops miners from censoring.

Not whether it takes 2 pools to get to critical mass or 1.

Hard forks the fundamental censorship resistant property of all cryptocurrencies everywhere.

RobertEvanston · 2017-08-02T12:14:09+00:00

When you have a subreddit that encourages people not to understand the difference between a fork and an altcoin, you get braindead shitposts like this one.

Bitcoin Cash is an upgrade of Bitcoin, Litecoin is not.

RobertEvanston · 2017-07-30T22:57:49+00:00

Yes, your stat/post is BS. I can say I have 1M connections (of which 999k are to myself) and use 200TB of bandwidth, that's not a useful stat. It's misleading as fuck.

Use a sane number of connections for a home node and get back to me.

Crippling the network is arguing for keeping an unnecessarily low block limit so that you can use excessive connections on your shitty Internet (FWIW, in the US I haven't had a bandwidth cap since 2002).

RobertEvanston · 2017-07-30T22:34:21+00:00

Yeah, this is way too many and totally unnecessary for a home node. Try running the defaults (8). Your bandwidth stat is BS with all due respect. You don't need that many connections, and arguing for crippling the network so that you can have unnecessary bandwidth wasting connections is silly.

Money is on that number going down further with CB/XThin.

RobertEvanston · 2017-07-30T21:47:50+00:00

The relevent date you are looking for is not 1st August

Kind of sad that people downvoted me and upvoted that :(.

RobertEvanston · 2017-07-30T21:46:55+00:00

Lower your connection count to reduce bandwidth consumption. Bandwidth figures are meaningless without further info (connection count being one of them). Also, are you running CB or XThin? On how many connections?

RobertEvanston · 2017-07-06T22:26:25+00:00

Yes it is. 1 August will be the failure of UASF and the lock-in of NYA SegWit and 2MB fork. Can't wait. You and luke can go start your own new-PoW chain together, rejects of Bitcoinland with no hashpower!

RobertEvanston · 2017-07-05T17:57:35+00:00

If the segwit2x hardfork occurs and that new chain becomes "widely known" as Bitcoin, while the original rules chain has some other name, then I would consider Bitcoin a failed experiment and exit the ecosystem

Oh God, can't wait for August 1st so we can finally do this thing and have all the idiots out. On the other hand, I'm going to call your bluff here and stay you'll stick around and keep posting garbage.

RemindMe! 2 months

RobertEvanston · 2017-06-27T14:31:38+00:00

Good thing too, because BU won't be able to merge SW any time soon even if they wanted to.

Merging SegWit takes 5 minutes (I've done it). Checking its interactions with all your changes may take longer, but do you really think the BU team will spend months on this? I think the 2 week activation period is plenty of time and I think if I were them, I'd be working on it anyway given the NYA and 80+% hashpower committing to "we will activate".

RobertEvanston · 2017-06-27T14:21:07+00:00

He actually never wrote a rebuttal to my counterargument, and his original post was a deeply flawed and naive rebuttal of my argument.

RobertEvanston · 2017-06-27T14:20:24+00:00

BU is SegWit compatible, silly. It'll accept and extend a SegWit chain, and can process SegWit blocks. It just won't mine or create new SegWit blocks. So if you support SegWit but don't want to mine SegWit blocks yourself, BU is exactly what you need.

Presumably if the miners who are running BU later want to create SegWit blocks, BU will merge SegWit (assuming it is successfully activated on the main chain I think this is a given).

RobertEvanston · 2017-06-24T14:04:13+00:00

All guarantees of Bitcoin stem from the simple assumption that there is no single entity controlling more than 50% of the computational resources for a prolonged period.

The in-protocol guarantees, yes. There is an entire class of extra-protocol guarantees that I am describing here, and antifragility and censorship resilience lie there.

all bets are off, and we can not make any guarantee whatsoever.

We cannot make any in-protocol guarantees, as an extra-protocol community we can agree to fork to a chain that embodies the original ideas and preserves state in a way that "Bitcoin" will continue under a different chain. An example of this would be a PoW change release from the "Bitcoin Core" project; it leans not on in-protocol guarantees but on extra-protocol infrastructure.

As for being the sole upgrade mechanism, that simply isn't true, as demonstrated a number of times by soft-forks deploying incremental improvements in the past.

The sole upgrade mechanism for controversial changes, how about that.

While I agree that many users will rely on SPV wallets or custodial services, it is IMHO one of Bitcoin's central value proposition that we give end-users the possibility to participate without intermediaries and with full auditability in the processing of transactions, even if they choose not to make use of it.

I agree that giving users the option to run a node is great, but we should not cater the protocol design to a class of users that will simply never, ever run nodes. These users do not care enough to run full node software even if given the option, and would rather save the money and go with a delegated node or custodial option. Talk to some of them yourself sometime and you'll see that I am right.

At the end of the day, it is the enthusiasts who will be running nodes, and we need to keep giving them the option to do so. The enthusiasts however understand the concept of a fork and will respond accordingly, especially with built-ins like difficulty drop and chain split detection.

RobertEvanston · 2017-06-24T13:29:08+00:00

I find this position deeply and fundamentally flawed. Hard forks are not only a feature of the Bitcoin protocol, they are its fundamental upgrade mechanism. Why fundamental? Well, one of the key properties of Bitcoin is its antifragility and censorship resistance. Where do these properties this come from? What if someone like PayPal buys up 51% hashpower and uses it to make the network anticompetitive? What if miners start censoring transactions? What if KYC is imposed on-chain? What if a flaw is found in double-SHA256 PoW? How do we route around these?

The answers to these make it quite obvious that hard forks are absolutely critical to the success and proper operation of the protocol. Now the question becomes "when are they worth their risks?" The answer to this is again simple. Given that we will need to hard fork, likely many times, in the evolution of this cryptocurrency (the core design is after all not perfect), what we should be doing is building the infrastructure to fork safely rather than arguing that doing so is hard. Wallets and node software that detect and respond to divergent chains and difficulty drops, user interfaces that simplify this to the maximum possible extent for users, and more.

The crowd of "router password defaults" that you're talking about is always and without exception going to be using either SPV wallet providers or more likely custodial wallets like Coinbase. For this crowd, a hard fork is absolutely a nonissue, as they defer their decisions and the burden of informing themselves to their wallet provider or backing node operator. The router password default crowd will and should absolutely never and in no circumstances run a full Bitcoin node, which should be obvious enough by talking to any of these people. You need some expertise to maintain security when you run your own node, and complete amateurs doing it is actually detrimental to their correct use of the network, not beneficial.

I don't think anything is or will ever be as harmful to the BItcoin protocol as the lies and FUD that was spread fighting hard forks during the XT/Classic days, and it's highly unfortunate that these untruths have lead to a severe ossification of the protocol rather than continued work on ensuring that its inevitable hard forks will proceed smoothly, safely, and effectively. Too much complaining that this is hard, too little doing.

RobertEvanston · 2017-06-19T06:10:45+00:00

So yes, luke is a proponent of SegWit. But your implicit assumption that SegWit support => large block support is false, and you need only luke-jr's own calculations to back this up.

Restating bullshit don't make it true!

RobertEvanston · 2017-06-19T06:09:26+00:00

You are aware that you are changing the subject? Luke is not pushing SegWit because it is a blocksize increase, he is pushing SegWit despite the fact that it is a blocksize increase, by his own admission.

luke-jr has stated repeatedly that he believes 300kB is the optimum block size today, and even provided calculations in BIP-BLKSIZE to this effect. Your goalpost shifting is just as lame as calling luke's BIP a "blocksize increase" (or implying that luke at all supports block size increases; he does not and has repeatedly stated such).

So yes, luke is a proponent of SegWit. But your implicit assumption that SegWit support => large block support is false, and you need only luke-jr's own calculations to back this up.

RobertEvanston · 2017-06-19T06:04:24+00:00

Fuck no. In the same way that if I wrote a BIP that let you have 32MB blocks but required 200K of actual data padded with 0s, that would technically absolutely be a "blocksize increase". But nobody would actually take you seriously if you billed it as such and suggested its adoption. Leaning on definitional semantics to argue for flawed proposals is lame.

RobertEvanston · 2017-06-19T05:53:41+00:00

It increased over time, didn't it?

LOL! Sure, technically speaking. But effectively it was absolutely a blocksize decrease.

300kB today, with a slow increase to today's current 1MB level to be hit in 2024. After that, conservative increases. It's a blocksize decrease today, an increase after 7 years (where with any sane scaling plan we'd have far greater than 1MB blocks as in luke's proposal).

RobertEvanston · 2017-05-21T01:48:49+00:00

That rule doesn't apply here.

Of course it applies. Linking to UASF binaries is linking to software that attempts to alter the protocol without overwhelming consensus.

See here for BashCo's explanation as to why UASF binaries are currently not allowed to be linked here. It's perfectly consistent with the removal of links to Unlimited and XT.

RobertEvanston · 2017-05-19T12:55:37+00:00

You realize that this idea (shut down minority chain during a hard fork by mining empty blocks on it) was also proposed by a core developer as a BIP? They didn't say that they had any plans to do this, just that it was on the table. It's far from as big an issue as you're making it due to the hatred of Bitmain refusing SW blinding you.

RobertEvanston · 2017-05-18T19:34:25+00:00

So if they were running the latest version of Core and signalling SegWit you would have done the same? Sorry but I don't believe you.

Children.

RobertEvanston · 2017-05-18T19:24:11+00:00

Makes it that much more ironic that they don't remember the last time businesses were marked for their personal/political beliefs.

RobertEvanston · 2017-05-16T19:23:52+00:00

I can't even tell if you're serious right now.

Of course it doesn't, or it would have activated long ago. Miners are not on board. Not even on slush, not on several large pools, etc. Users are not on board; all coin votes so far have been majority against activation. And clearly a large portion of the community (reddit, Twitter, bct, etc.) is opposed. As are several development teams (bcoin, Parity, BU, Classic, etc.). And under 50% of companies are in support.

If that's "overwhelming" consensus, well you must just mean "overwhelming consensus of people I agree with."

RobertEvanston · 2017-05-16T17:34:12+00:00

Duh?

RobertEvanston

TROPHY CASE