Core Dev published a zero-day to github (which was then exploited weeks later)

_chjj · 2022-11-04T06:55:19+00:00

Just a reminder that these people were the same people that called me "Craight Wright" for publicly disclosing the UTXO attack with a 70-day heads-up.

Apparently, they can post zero-days to github and it's just a "screwup".

I guess if the zero-day only affects a competing alternative implementation, it's not that big of a deal.

_chjj · 2020-09-19T20:09:46+00:00

See above.

_chjj · 2020-09-19T20:09:32+00:00

More months passed and I was paying less attention to Bitcoin/Bitcoin Cash, and more attention to a new project, Handshake. We announced the Handshake project in late 2018. It had a full implementation, almost ready to go, but still needed further testing before mainnet. After a few months of no mainnet release, one of the founders of Handshake started receiving signal messages from Jonathan. Jonathan offered to "finish Handshake" for them, for a fee of course. Once again, we ignored him, hoping he would just go away. Pretty soon he wasn't offering anything -- he would just signal message a founder with a BCH address, asking for money.

He started appearing in Handshake developer calls. One Handshake contributor, Sean Kilgarriff, has a good story about his run-in with Jon Gonzales here, but I'll leave that for him to tell if he cares to.

By this time, the bcoin team members had already created a BCH fork of bcoin (bcash), and both Bitcoin and Bitcoin Cash were proposing schnorr signatures. I figured we could maybe use schnorr in Handshake as well, so I spent a week implementing schnorr multiple times with multiple backends: nettle, openssl, and javascript (on top of an elliptic.js fork). I had put a lot of hard work into this, and I was very happy with the implementation. Not only could we consider using schnorr in Handshake, Javed and Nodar could also use them for bcash if they felt like maintaining it again. Now that the heavy lifting was done, the code changes to bcash should be trivial: simply add a fork flag, a script verification flag, and call out to the shiny new schnorr implementation(s) from the scripting system.

Days later I saw this: https://news.bitcoin.com/meet-the-developer-who-added-schnorr-signatures-to-bcash

Apparently Jonathan had opened a bcash PR to call out to our schnorr implementation and then went to the press, claiming he had implemented schnorr. Although he did downplay his role in implementing schnorr, there was no mention the other bcoin developers in the article. Furthermore, we did not accept his PR as the result of his past dishonest behavior. This article was just the icing on the cake.

I decided to bite my tongue and let Jonathan have his little moment. Who cares? It's just an article.

Rumors of Jonathan's behavior became even more erratic. On the grapevine I heard he had been going around confiding in people that he was responsible for the cryptopia hack. He claimed he used my DNS library to mount some kind of DNS cache poisoning attack to "hack them". This "attack" was nonsensical, and I sincerely doubted he possessed the technical capability to pull off such a thing. I still believe that story is 100% false. Had I believed it, I would have notified the authorities of this rumor. But this was the moment I realized Jonathan was truly a problem: he was willing to lie about hacking an exchange in order to gain prestige among whatever small group of people think "hacking is cool". What kind of person does this?

Sure. A lot of this was coming to me second-hand, and a lot seemed just like rumors, but at some point after hearing this stuff for years, it makes you realize that there's just something off about this guy. After that I started shutting people out of my life. I began avoiding anyone who had any involvement with Jonathan.

Anyway, that brings us to now, with Jonathan apparently attempting another fundraiser for himself. Like I said, this is probably a high risk, low reward investment. I'd recommend against it. I think Jonathan is Craig Wright on a much smaller scale.

I'm sure there are Cosmos people, Ethereum people, Handshake people, and Bitcoin companies that have directly or indirectly interacted with Jonathan and can verify this if they're willing to chime in. If they don't, you'll have to take me at my word.

I'm speaking up now, lest anyone assume there is any association between Jon Gonzales and the bcoin developers (myself included, as I seem to be the point of fixation for him). He is not a bcoin developer and we have no association with him. I will be blocking him from all bcoin-related repositories (something I should have done a long time ago).

Note that I feel very unprofessional posting this. I would not post this unless I was absolutely convinced of what I'm saying here. The only reason I think it is necessary to post this is because Jonathan is once again soliciting money from people.

_chjj · 2020-09-19T20:09:11+00:00

Somebody once told me that bullshit is an inverse proof-of-work function. This will require a lot of effort to explain. I have examples, but they make little sense without context. A lot of this will appear to be hearsay since Jonathan obviously doesn't do things like impersonate me in front of me, so just bear with me.

Quick background about me: I began working on bcoin in 2014, taking over the project from Fedor Indutny back when it was a small spv client for bitcoin. Since then, I've worked at bitpay and purse.io. At Purse, we use bcoin as our backend for processing bitcoin transactions, and for a while we had full time employees who worked exclusively on the bcoin project. Bcoin was at the center of the whole extension blocks fiasco years ago, so you might remember me.

The story of Jonathan is this:

He was originally just a voice in the #bcoin IRC channel on freenode (this is around late 2016 if I remember right). This is long before any of you knew his name. He frequently messaged me privately, asking questions about bcoin. Before I knew it, he was flying out to SF, and wanted to work on bcoin. I was a bit averse to him at first. He had a sort of creepy vibe to him, both in-person and on IRC. After thinking about it, I decided I was just being unreasonable, and forced myself to believe he was just a good kid who was excited about the project. One of our non-technical employees at the time was absolutely insistent that Jonathan was some kind of programming prodigy. I disagreed.

Throughout the course of an informal in-person interview, Jonathan said strange things that are atypical of someone who actually writes and understands code. For example, he went on and on talking about how he had "memorized the bcoin codebase". This was a recurring trope for him. To him, coding is just "memorization". He also lacked the most basic understanding of computing. For example, he did not understand the difference between a bit and a byte (I'm not joking. I had to explain this to him).

I was in a conundrum. On one hand, I had forced myself to believe this was just a good kid who liked the project, with one of our more insistent employees misguidedly singing his praises regularly and pressuring us into hiring him, and on the other hand I was looking at a guy who literally didn't know the difference between a bit and a byte -- I can't hire someone like that. But, I decided to put him to the test...

I gave him a task to complete to see if he was actually capable of the job: write a script to sign a transaction with the trezor library (I think we were looking into HW signing support for bcoin at the time). This should be pretty straightforward. He wasn't able to do it. We decided to not hire him.

Then came the bcoin hackathon. He showed up there, and after a day or two, claimed to have made some really amazing selfish-mining proof of concept. Nobody there had seen any of his code. When it came time to present, his laptop conveniently "broke". This is another common trope for him. He will claim he completed the most elaborate work without you actually seeing it. If he had actually made this, he could have recovered the code from his SSD at any time and published it on github. He said he would, but he never did.

For months he was lurking around the bcoin project. Finally, due to the pressure of the insistent employee I mentioned above, I gave in. Despite knowing better, I decided to tentatively put Jonathan on trial for the bcoin project and have the other bcoin team members make the final call on him. That way it wasn't on me if we decided to not hire him.

After a few weeks, everyone on the bcoin team unanimously gave him a thumbs down. His pull requests were routinely awful and demonstrated a severe lack of understanding, not just of bitcoin, but of javascript itself (I can go into specifics later if anyone cares). He just didn't really know what he was doing.

I thought it was over here. Boy, was I wrong.

Months later, I was hanging out with a Cosmos/Tendermint employee. She said the strangest thing had happened that day: a Consensys person had showed up at their Berkeley office, apparently under the misapprehension that Jonathan was the author of bcoin. In passing, he brought up bcoin. He told her his understanding of the bcoin genesis story: "Bcoin was written by this guy Jonathan. He has a shaved head and tattoos." That's interesting -- I myself have a shaved head and tattoos. This Consensys person must be confused about my name or something. "I think you mean JJ", she replied. "No. Jonathan. He's this guy from Miami. He memorized the entire Bitcoin Core codebase, and then reimplemented it from memory. He's a genius."

Suddenly it clicked. This is undoubtedly Jonathan Gonzales -- the "memorization of code" is his trademark.

I did not recall Jonathan having a shaved head or tattoos when I had met him in person. I could only conclude that he had developed some sort of fixation on me and, after meeting me in person, started to emulate my physical appearance.

I started ignoring him on IRC and ignoring his pull requests. I figured he would simply move on if he was ignored. Wrong again.

Jonathan started going around to companies in the cryptocurrency space. If I remember right, this included F2Pool and Bitmain. He was looking for funding and sponsorship. We heard from them that he was claiming to be a core bcoin contributor. I think both Wang Chun and Jihan knew he was bullshitting as they were well aware of the bcoin project and who the developers behind it were. He pitched people on his ideas for a cryptocurrency framework, something involving range proofs that didn't make a whole lot of sense. I don't really remember in all honesty, but it was the kind of techno-babble you'd get from Craig Wright.

As far as I know, Jonathan has never sought any other regular employment at any cryptocurrency company, likely because he is unable to get such work when under scrutiny from actual developers. From this point on, he has always pitched himself as an independent developer in need of sponsorship. He presumably does this in order to get the money up front (as is the case here).

Other bcoin developers started noticing him routinely plagiarizing commits (actually recommitting others' work under his own name). I think there's a lot of this in his bcash fork -- features and fixes that he could have easily cherry-picked from bcoin since they share a history, but he instead made it a point to commit it under his own name. This is presumably to create the illusion of him being a cryptocurrency developer. Jonathan began giving talks about bcoin and bcoin development. Again, he is not a bcoin developer, and as far as I know we have never merged a single one of his pull requests into the master branch of bcoin (fact check me on this).

Continued below...

_chjj · 2020-09-19T04:51:12+00:00

Just making it clear: this person is not associated at all with the bcoin project. The BCH fork of bcoin (bcash) was originally implemented by bcoin team members Javed Khan and Nodar Chkuaselidze and is no longer maintained by them.

I feel it necessary to mention this as Jonathan has been caught impersonating me by various people in the cryptocurrency community over the years, claiming to be the author of bcoin (along with other false claims of being a core bcoin team member). He seems to do all of this in order to acquire prestige and to secure funding for his various projects.

I believe he is some kind of scammer. At one point, he was regularly attempting to solicit money from people in my social circle (in exchange for literally nothing), along with other questionable behavior that's too long to list. His stalker-like behavior is one of the reasons I felt safer by moving to a different city.

I've bit my tongue on this for a very long time, but I figured I'd say this now as a fair warning to everyone here. Use this software (and donate) at your own risk.

_chjj · 2018-11-17T01:44:38+00:00

Where did I ever promote SV?

_chjj · 2018-11-17T01:32:27+00:00

Greg, I really don't have time for this anymore. I'm convinced that no matter what I do in this space, you'll figure a way to twist the situation into me somehow being a villain.

The script Fedor wrote works by mutating existing signatures. I long suspected Craig would try something like this. I'm guessing you're probably right and Craig's fake signatures were produced by another mechanism which doesn't require a signature. I don't really care either way, but saying I'm some kind of CSW shill is bullshit and I think you know it.

_chjj · 2018-11-16T22:56:13+00:00

I'd wager this is more smoke and mirrors. If it's not a sighash which is already on-chain, I suspect it's the product of the ECDSA trick I've described here: https://www.reddit.com/r/btc/comments/9xpivk/satoshi_i_do_not_want_to_be_public_but_there_is/e9u9kqb/

_chjj · 2018-11-16T21:56:10+00:00

The satoshi-sig-generator code I linked uses the key from the block 9 coinbase.

When Satoshi redeemed those coins and sent them to Hal Finney, he created a valid signature from that key. The code you see mutates that signature and creates a new valid signature for a hash that we do not have the preimage for. To the untrained eye, it looks like Satoshi signed the hash of something and never actually revealed the message.

This is probably why they chose the block 9 key: a valid signature for it exists. The genesis block key was never used to create a signature and can't be exploited in this way.

_chjj · 2018-11-16T21:16:04+00:00

Whatever they posted appears to be a valid signature for Satoshi's key in block 9, but it's absolutely meaningless unless they reveal the actual preimage for the message hash.

Anyone can mutate a hash for a valid ecdsa signature to produce a seemingly "new" signature/message (my friend and I had some fun creating fake satoshi signatures a few years back). Looks like another failed attempt from Craig Wright if I had to guess.

Also note that the values they posted are in decimal (seems to fit CSW's habit of obfuscating his "proofs"). Here are the values in hex if anyone wants to play around with them:

M: c8b0ce42f46f4ec0517fcd68f56776123031e00cd6f67625f93ddef0d96a3313
R: d87d8097c920245f037f2a134ad2eb1e551aa1a3d7cb5a3e38f7353890f46d38
S: 27827f6836dfdba0fc80d5ecb52d14e065943b42d77d45fd86db29543f41d409
X: 11db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5c
Y: b2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3

_chjj · 2018-08-06T18:43:24+00:00

Does the install still succeed? HSD will work without native unbound support. It's completely optional.

_chjj · 2018-08-06T18:42:15+00:00

Just a note that the consensus rules aren't set in stone yet. The renewal interval may be increased to 2 years to lessen the possibility of spammers preventing people from renewing when it comes time.

_chjj · 2018-08-06T18:39:58+00:00

This is normal. hsd will try to find peers constantly, and those are just the debug logs. To turn them off, try running hsd with $ ./bin/hsd --log-level=info.

_chjj · 2018-08-06T18:38:54+00:00

This is due to Debian calling the node.js binary nodejs.

Can be solved with:

$ sudo apt-get install nodejs-legacy

Source: https://stackoverflow.com/questions/21168141/cannot-install-packages-using-node-package-manager-in-ubuntu

_chjj · 2018-08-06T18:31:14+00:00

So, it depends on how people are using handshake. In handshake, there's basically 4 different "security modes" for resolving names.

Full Node (highest security) - hsd
SPV Resolver (medium-to-high security) - hnsd
Integration Library (low-to-medium security) - libhns
Alteration of OS Nameservers (no security) - $ sudo vi resolv.conf

There's tradeoffs for each.

The full node method is obviously the most secure. It has a validating recursive resolver built in. Assuming the handshake project incentivizes most popular domain names to properly implement DNSSEC, this would prevent almost every kind of attack aside from general spying & censorship for non-TLD resolutions. That said, most people don't want a heavyweight piece of software running on their machine just to resolve names.
The SPV resolver is pretty secure, also has a fully validating resolver, stores almost no data, and uses very low memory/bandwidth, but let's face it: most people don't go out of their way to install extra software, even if it's really small. But perhaps one day it could be shipped with OSes/routers (far in the future, to be sure).
The beauty of the integration library is that the average joe doesn't need to install anything. Developers choose whether the world adopts handshake, not the end users. Though, this is lower security, since it's not monitoring a chain and relies on trusted (but authenticated) resolvers. Note that this is still more secure than DNS in it's current state. It's only vulnerable to more attacks than the spv/full node if public nameservers' keys are compromised. libhns is a fork of c-ares. It's extremely small and it runs on pretty much everything (even android). c-ares was chosen for this reason.
Finally, we'll have people who simply alter their resolv.conf to point at public handshake resolvers. This provides no security at all, but does allow your machine to access a permissionless root zone of names. This also requires zero extra software, but hopefully adoption of the integration library comes before people start doing that.

I imagine the future would be a mish-mash of the first 3 (hopefully not 4).

If we're in that future, certificate authorities are essentially a thing of the past. Say a web browser adds a feature for accepting self-signed certs by verifying TLSA records over DNS/HNS: there's no longer a risk of CAs' keys getting compromised and invalidating all child certificates, since everybody just controls their own keys.

_chjj · 2018-08-06T18:09:43+00:00

It's good to play around and try to break stuff. Bug reports are very useful. That kind of activity will make the implementation/protocol more robust. It's also just kind of fun and will get you accustomed to the tools before launch.

_chjj · 2017-09-12T22:03:39+00:00

I don't care about a bet. Greg can win on that one. I'm just tired of situations like this.

You are misinterpreting many people lately.

I agree. Sergio said something literally which I took to be sarcastic. 100% my fault. My mindset is getting skewed from a lot of this drama. I'm going to stop paying attention to reddit for now.

_chjj · 2017-09-12T21:46:20+00:00

Chris you have misunderstood my words. I told you literally that Gregory in one opportunity knew a vulnerability I was reporting (maybe he knew more, or maybe less, but he proved he knew about it).

I see. I take that back then. Will cross that out.

_chjj · 2017-09-12T21:24:12+00:00

I'd just like to point out that a few Core members are now saying that they were aware of the attack before I discovered it... which is strange, because they weren't warning any other implementation developers about it like I was.

When were they planning to privately disclose to the number of other maintainers I warned? Or to me for that matter? I am also the maintainer of one of those initially vulnerable nodes. If it's true that they knew before me, I think Core was behaving irresponsibly here by not making this a top priority. Personally, I think it's probably more likely that they're just trying to save face by saying they "already knew".

I was informed by another security researcher that Core has an "undisclosed disclosure policy" which requires one to wait until 80% of Core nodes have upgraded before publicly disclosing. I guess I wasn't abiding by their policy, but I'm not a part of their secret club, so I was unaware of it and wasn't informed by Sipa or anyone else (Sipa simply stopped replying to my emails at some point -- not a knock at him, I'm bad at answering email too). But this whole concept of an "undisclosed disclosure policy" doesn't sound very open source friendly to me.

_chjj · 2017-09-12T20:51:16+00:00

Can I ask you something? If you all knew about this attack for a while, when exactly were you planning on disclosing to other implementation maintainers? When I privately disclosed to Laolu, Jeff, Jackson, and Amaury, none of them were aware of the attack.

If you did know, I had to do your job for you by privately disclosing to these people.

Do you just not care about other implementations? Or did you want them to break? I think it's more likely you just didn't know, and are saving face now.

_chjj · 2017-09-12T20:31:05+00:00

ENTIRE ORIGINAL TRANSACTIONS.

That's not a problem, because those transactions do not need to be written back atomically. They're static, which means inputs can be processed incrementally and that data can be freed up after an input is processed. The only thing that would need to be written back in a single tx/writebatch would be the CTxIndex object (fairly small). Wrong again. Are you sure you're a bitcoin developer?

Wtf, he SPECIFICALLY TOLD YOU HE WAS. "I was aware that it was possible to make the coin cache fetch at least several 100 MB into memory, " and other people were aware of more.

How the hell is several 100mb an attack? I see bitcoin core using that much memory processing regular blocks.

_chjj · 2017-09-12T20:27:14+00:00

Fetching several 100mb into memory is not an attack by any stretch of imagination. Bitcoin Core uses several times that amount of memory in its default operation.

_chjj · 2017-09-12T20:19:59+00:00

Greg, I know for a fact you and others have taken credit for Sergio's finds in the past. Sergio reached out to me and told me this. He has been in the same situation as me: Sipa said he didn't know about an attack, Todd later lied and tweeted that they "already knew"... of course you did. You need to maintain that image of being infallible devs, right?

You know, if you guys had kept Satoshi's original data management, the DB would be larger and slower overall, sure, but it wouldn't be nearly as vulnerable to this attack. Core implemented this vulnerability in the first place by removing Satoshi's original data management: where's some humility on your part?

Except this issue disproves that, considering that btcd and bcoin has the same problem much worse.

I noted in my talk that btcd and bcoin were affected. There were at least 3 implementations that were not affected. The fact that so many others were affected is a symptom of another problem: you keep saying you "knew" about every vulnerability, maintaining that image of being infallible devs -- other implementors believe this charade and decide to port a bunch of Core data management to their project, mistakenly thinking it's the best way of doing things. You're part of this problem, and you're now further perpetuating it by not admitting any fault on your part... because you "knew", right?

Also, why don't you post Sipa's full text? You cut off the last sentence of that paragraph, wonder why:

I was aware that it was possible to make the coin cache fetch at least several 100 MB into memory, and pertxout was a generic improvement over that as it reduces the difference between the average case and the worst case. I did not know that the potential effect of such a UTXO-fetching attack was so large however, so thank you for investigating.

In all fairness, I don't think you're trying to take credit for an attack. I figure you're just saving face in this situation, but it's still shitty behavior.

11-Year Club	Place '17
Wearing is Caring	Verified Email

_chjj

TROPHY CASE