> 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.
Hi. Who are you? You're saying a number of things which are outright untrue, and I think it would be helpful to know who I'm speaking to here.
Matthew Green was _insistent_ about making an altcoin. I believe can substantiate this with DKIM-signed emails by Google, if it's actually being refuted. He was especially concerned about difficulties monetizing any other path.
In particular, later I begged for access to the efficient SHA256 circuits which had been created and benchmarked as part of their publications, which were held back from publication with libsnark. ... so that I could begin working on applications of them with Bitcoin, only to be blown off.
> and that's all that is happened: talking. There is no code and
"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...
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.
That's simply not true. I was actually hired as a consultant by Green, and he did hardly anything with that contract. I know of no proposal actually made to any Bitcoin devs for inclusion, and in any case, it took a long time to improve the tech to the point where resource requirements were low enough for either Zerocoin or Zerocash to be viable in any currency.
> I went and dug up where I had read Green talk about this and it turns out it was in a conversation with you.
Ha!
> It seems you and him disagree, he says ZCash couldn't/wouldn't have happened in Bitcoin and you say it could.
Yeah, I'm just surprised he feels so strongly about that, given how little I remember him actually doing along those lines. Like I said, I actually was hired by him on a monthly retainer to do consulting... and he did almost nothing at all with that contract. :(
> Is your blog post about this still coming?
Yes, although holy fuck I have a lot on the todo list. :( I also need to writeup my part of the trusted setup ceremony too.
And a blog post on that isn't paid work, so doesn't get as high priority as paying rent. :)
I can see the tension there. In a certain sense it's a shame to see good crypto languish.
It's also highlights why I feel the concept of a "decentralized" currency is essentially impossible. Someone always controls some facet of it, be it features of the currency, supply, restrictions, or value.
In the case of cryptocurrencies, the authors of the protocol and governance put in place to maintain it are the central authority. For zcash, the central bitcoin authority (whoever you referenced as 'Bitcoin') wouldn't/couldn't integrate features they wanted so they rolled their own currency of which now THEY are the central authority.
> (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).
I am not volunteering because while being fluent in C, I am not very knowledgeable in the realm of crypto. I'd be stupid to do otherwise. I can still point out that there is a big need for such a project.
This is a piece of software that is so core to our computer ecosystem that I am sure plenty of companies would contribute financially and with developer time. Heck, if this couldn't get enough funding for at least 5 fulltime devs plus external audits then we're in a sad state of an ecosystem. IMHO this actually should receive public funding. It would be more useful than many other things that get public funds.
Sigh. Please improve your reading comprehension. I didn't "shit on the LibreSSL developers". Anyways, you sound not like someone one can have a sensible conversation with. So I wont be replying further.
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.
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.
> LibreSSL has historically been vulnerable to less of the bugs than OpenSSL and, for a long time, none of the sev:high bugs.
You say this like LibreSSL has been out for a long time. It's just barely crossed it's 2 year mark... and for most of it's life, it's difficult to call it "production ready".
Coupled with its low adoption rate (really only some select BSD's, and some adventurous linux folks), it's not surprising more vulnerabilities haven't been discovered (yet).
The OpenBSD folks do good work, but let's not pretend they are infallible.
> 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.
tlsdate is a much cleaner implementation of this idea, taking the time from the handshake. TLS 1.3 as it stands makes sending the server time optional.
The 'Date' header is tricky because it is a timestamp of when the document was generated, not when it was served. Caching proxies have no obligation to (and in most cases shouldn't) update the value.
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
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.
The fact that virtually every other nix system, large and small, can provide this standard functionality, and the OpenBSD project cannot. Having to rely on third parties for convenient updates is an obvious potential security issue. Firstly because it discourages updates in the first place, but secondly because I now have to trust m:tier as well as the OpenBSD devs.
That is why I say embarrassing - they are one of very few projects to lack this feature, and this feature is an important part of a secure system. OpenBSD is all about being "hands off" and "sane by default" and yet paradoxically their update process is much more involved and hands-on!
If openbsd developers do it, why don't they make it official and provide it from openbsd.org? They could still plaster "this is thanks to funding from mtier" on the site prominently.
The OpenBSD developers are unwilling to do anything that makes some architectures better than others, and M:Tier is unwilling to build stable updates for everything. Perhaps this will change one day as hardware continues to consolidate, but that's the way it is for now.
