"Last I checked - a few months back - it was just a bunch of ideas. No code on main." "And more importantly, no schedule on when it was going to go live. You can't build something that doesn't exist." - https://twitter.com/matthew_d_green/status/78154605479791821...
> Is this the one that forked off BitCoin due to differences centered around how it didn't make its investors/founders enough money
You must be thinking of something else. Matthew Green has said he would have much rather got this implemented in BitCoin.
ZCash forked off of BitCoin because BitCoin core wouldn't accept it. The proposed solution was a "side chain" to BitCoin. Side chains have been being talked about since around 2009, and that's all that is happened: talking. There is no code and no agreement on how they should work.
The fork happened when it became apparent that this would never make it into Bitcoin in any form.
According to Matthew Green, they tried for years to get this (or one of the earlier versions) into Bitcoin and Bitcoin weren't having it. Their options were to make an entirely new coin, with the problems you point out, or to let the crypto they had developed die.
> (a) Previously unknown TOR endpoints get found out because they invariably are the source of vandalism and/or spam.
The English Wikipedia uses the MediaWiki TorBlock extension to automatically block Tor exits from editing, it has since June 2008, and before then they were mostly all automatically blocked by various bots so I don't understand how vandalism would be happening from them. Also, the Tor Project publishes a DNSBL and makes relays with the exit flag available through the ONIONOO API (which TorBlock uses). There are no "unknown endpoints", they are all publicly known.
> I have never seen a good edit from a TOR endpoint. Ever.
This is likely true since they are all automatically blocked before they can edit.
> (c) I have never seen accounts created via TOR or that edited through TOR that weren't demonstrably block evasion, vandalism or (most often) spamming.
You can't create accounts via Tor or edit while logged in via Tor -- not even Administrators can (although I think you can get a special exemption by jumping through enough hoops).
Okay, let's have a sensible conversation about your completely idle suggestion to create a new library in some other language, that would have to maintain compatibility with the OpenSSL API otherwise no one will use it, or rewrite everything that currently uses OpenSSL.
To me your "LibreSSL is no such thing" came across as dismissing the efforts of LibreSSL, even though it's not vunerable to this latest one, because it doesn't use Erlang.
Oh, so you were just blowing a bunch of hot air on the internet, while not offering to do any work and while shitting on the LibreSSL developers who are doing work to make things better.
No one is claiming that LibreSSL has fixed all the OpenSSL bugs, the parent certainly didn't. LibreSSL has historically been vulnerable to less of the bugs than OpenSSL and, for a long time, none of the sev:high bugs.
Some TLS implementations return a randomised date for the handshake anyway, which is why constraints works the way it does. TLS 1.3 killing it is just gravy.
If you're worried about a caching proxy you can set the constraint to a URL that returns something dynamic. Although it would be interesting to see what % of the top TLS-enabled webservers don't return something recent for HEAD / HTTP/1.1
> There have been efforts to augment NTP with authentication, but they still assume a world where each client trusts one or more time servers absolutely.
OpenNTPD has "constraints" where it makes HTTP requests (using TLS) to webservers and checks that the time provided by the NTP server is within a certain threshold of the time returned in the HTTP Date header.
Much simpler and doesn't require dedicated servers.
The OpenBSD project doesn't have the resources to provide this so m:tier employs a couple of OpenBSD developers to provide this option for people who want it. Not sure what is embarrassing about this.
"Let me reiterate, I would 10,000x rather have put Zerocash in Bitcoin." - https://twitter.com/matthew_d_green/status/78154154453702656...
> He was especially concerned about difficulties monetizing any other path.
"Rewards doesn't even start the discussion. I'd have done it for free just to see it used." - https://twitter.com/matthew_d_green/status/78153489377171865...
admittedly he does bring up monetization: "And even when you got the code, nobody ever answered the problem of how you pay miners and devs." https://twitter.com/matthew_d_green/status/78154634460341043...
>sidechain right here.
"Last I checked - a few months back - it was just a bunch of ideas. No code on main." "And more importantly, no schedule on when it was going to go live. You can't build something that doesn't exist." - https://twitter.com/matthew_d_green/status/78154605479791821...
"A cynical part of me came to think the whole thing was just a put-on designed to squash competing coins." - https://twitter.com/matthew_d_green/status/78154720002742681...