OrpheanBeholder
OrpheanBeholder on Hacker News
"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...
It seems you and him disagree, he says ZCash couldn't/wouldn't have happened in Bitcoin and you say it could.
Is your blog post about this still coming?
https://twitter.com/matthew_d_green/status/78153309118155571... https://twitter.com/matthew_d_green/status/78154154453702656... https://twitter.com/matthew_d_green/status/78154374789720064... https://twitter.com/matthew_d_green/status/78153489377171865... https://twitter.com/matthew_d_green/status/78154782708016742...
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.
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).
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.
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
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.
You can however access the release notes (or any other file/page from the website for that matter) over SSH using CVS
$ cvs -d [email protected]:/cvs get www/openssh/txt/release-7.3Digging into the comments on that gist, it says that the bcrypt benchmark used a workfactor of 5 (= 32 rounds). The lowest possible bcrypt workfactor is 4 (= 16 rounds).
For comparison, the default for the login hashes on OpenBSD is 8 (= 256 rounds) for standard accounts and 9 (= 512 rounds) for the root account, and OpenBSD's bcrypt_pbkdf(3) function uses a workfactor of 6 (= 64 rounds) and that's intended to be called with multiple rounds itself eg. in signify(1) it uses 42 rounds (a bit over the equivalent of bcrypt with a workfactor of 11) and ssh-keygen(1) defaults to 16 (roughly equivalent to bcrypt with a workfactor of 10 (= 1024 rounds).
The point I'm trying to make here is that bcrypt benchmark uses a ridiculously low workfactor, and it looks like the scrypt and pbkdf2 ones did to.