On the Attempt to Take Over Ethereum Classic (ETC)

TL;DR

Using ETCDEV issues with financing:
• DFG convinced me to give them access to the ETC Github
• DFG was unhappy that I was not going to agree to changes in the ETC core tech in return for them investing in ETCDEV
• Darcy Reno, ETCDEV’s Program Manager, was hired by ETC Labs/DFG and subsequently lured ETCDEV engineers to quit ETCDEV and join ETC Labs
• DFG copied all the ETCDEV code to their account on Github
• DFG took admin control of the ETC Github by removing all other admins

The past month has been very busy for us as we have been experiencing an attempt of a takeover of ETCDEV and ETC. My last post regarding our financing issues was a small part of that. I didn’t want to publish all the details at the time, but now it seems I have no other choice. I’ll try to summarize everything and make it as short as possible.

ETCDEV Funds:

I lost access to funds I was counting on for ETCDEV’s development. These were supposed to cover the next year’s burn rate. This happened right before the ETC Labs launch, so they (ETC Labs and DFG) were the first people I contacted to ask for short term help until I could figure out what to do later. They promised they would help and that I shouldn’t bother anyone else about investments, financing, or donations to ETCDEV.

Darcy Reno:

Darcy Reno was apparently a Trojan Horse in ETCDEV. Not only did he fail to do project management in general, but all he did was to gather internal information, our contacts, roadmap, and try to get control of everything else (like he was insisting to get control of my funds for development). He had his own agenda and side communications with ETC Labs.

Initial Discussions:

For the following 2 weeks we continued discussing a possible grant from ETC Labs/DFG and everything was discussed through voice calls with Terry Culver.

During these discussions he reminded me that DFG was doing a lot for ETC, but that they were not getting the respect they expected. He insisted to add a representative from DFG to the ETC Community organization on Github.

That wasn’t so simple, of course, and I explained why to him, but he was returning to that same issue in every call.

I need to emphasize here that DFG and ETC Labs have actually showed a lot support for ETC for a long time, they have been very nice and helpful, and so on.

After the N-th reminder from Terry, I finally called Cody Burns, who was another owner of the community org, we discussed this request and both agreed that ETC Labs couldn’t do anything damaging, so, why not add them? We are a decentralized community after all.

So, I added an DFG representative (krykoder) to the ETC Community GitHub as an owner. The other owners were trusted people from the beginning of ETC, since 2016.

To be clear, adding the new owner to GitHub was not as an exchange or as part of any agreement of a possible donation from their part. I made that clear to Terry, that even if we added their representative, it wasn’t and couldn’t be as a condition for a possible grant.

Darcy Reno’s switch:

Initially we were getting some progress with a grant agreement and DFG even made a small donation to cover existing expenses. But then, Darcy had an unplanned meeting with Terry Culver, James Wo and Eric Yang in Hong Kong. After that moment all discussions drastically changed and all communications paused. That means we had lost critical time to resolve our issues.

The only call I had after that with Terry Culver was short and basically consisted of one question. He asked if they invested in ETCDEV, will there be a different approach to changes to the ETC core tech, if I would do what they say, or not? I said no.

We didn’t have any communication with DFG anymore after that. They didn’t even reply to my emails and a few days later Darcy Reno said that he was changing jobs to work for ETC Labs.

ETCDEV Takeover:

It seems that they agreed that Darcy would bring ETCDEV under ETC Labs. He had all our short and long term plans, all contacts, and ETC Labs would get much more control over the protocol with him.

Without my knowledge, all the ETCDEV engineers received a call and an offer from ETC Labs with much better terms for what is supposed to be the same job.

Ethereum Classic Takeover:

Today, we also learned what the DFG representative, who was included as an owner by their request, did after joining the ETC community organization on Github.

As it can be seen in the image below, that person removed all the other owners in the organization, becoming the single owner of the ETC community codebase:

Removing an admin is not a simple operation. GitHub asks for a special confirmation and password, and it has to be done several times, and for each admin. This can’t be done by mistake as ETC Labs, together with ETC Coop, are trying to portray no.

Also, the same user copied all the existing ETCDEV projects into his own repo. That takes a lot of time as well. It’s not forking, but copying, so it cannot be made by a mistake.

Preparations before takeover

(This part was not published initially in this post, added later)

To my knowledge, DFG and ETC Cooperative representatives had multiple secret meetings with ETCDEV engineers since the middle of summer 2018. Not only calls, but they also traveled around the world to meet people in person, make agreements and obtain some loyalty. And they were paying money to ETCDEV engineers to get such loyalty, sabotage the work and get insider information.

It’s clear now that it was a long term plan to take control of ETC and they were waiting for the right moment.

Conclusion:

We are experiencing a social attack on ETC itself right now. Unfortunately this attack is being perpetrated by internal members of the community, such as ETC Labs/DFG. ETC is a valuable asset and currently a public blockchain without a single owner. That makes it a perfect target for a takeover, even at the cost of destroying the main development group of the network.

 

Alternative to Smart Contracts term

Term Smart Contract is current standard name for a code deployed to a blockchain. Originally proposed by Nick Szabo, and later adopted by Ethereum Foundation. It may be a good name, but apparently it brings some confusion and I think changes the path of the industry.

For me, as non-native english speaker, it was just a term without any extra meaning. I mean we have a very rich terminology in software engineering, and for most of the people outside of english speaking countries nobody thinks about literal meaning. Similar to “San Francisco” which is a name of the city now, and I believe nobody associate it with a religious place.

I started to realize that there is something wrong with the Smart Contract term at 2017, when I noticed that when I talk to people in US about Ethereum they quickly switch to a discussion about legal aspects and agreements between people enforced on blockchain. It was even common to hear something like “Oh, it must be for criminals, [as they can’t use traditional court to resolve disputes]”. Em, what??

The problem that it influences how people think about technology use cases. Once they got into the box of a contract they can’t think outside of it. All the talks are about digital assets, finance, escrow, insurance, tokenization, binary options, logistics, etc. Even Ethereum Foundation, which were originally talking about “world computer” is more focused on tokens and ICOs now. There are not technology talks in blockchain conferences anymore. All talks about legal aspects, regulations, jurisdictions and so on.

While it’s fine to develop something related to legal contracts, it moves technology into one narrow path. There is nothing wrong with Smart Contracts, but it’s just a subset of all possible solutions that can be deployed to blockchain. Maybe other things can leverage decentralized computing? Honestly I don’t think many of contracts needs any decentralization, most of current tokens/ICOs are pretty centralized with a single switch right in a smart contract. But nobody cares, so [for a contract] a decentralized trustless ledger not a critical feature at all.

In 90s there were a lot of talks about “Workstations”, instead of “Personal Computer”. Fortunately PC won, and we have games, internet, Twitter, Instagram, and other totally non-work things now. Maybe we wouldn’t have any of this if we’d use Workstations, who knows.

So, if not Smart Contract, what would be a good name for a code deployed to a blockchain which is not necessary associated with legal aspects?

Blockend follows idea of Frontend, Backend. Ledgerware is from Hardware, Firmware, etc. And Chaincode is used by IBM Hyperledger already.

Basically there are few common prefixes and suffixes, which can be mixed. “Block-”, “Chain-”, “Ledger-” and “-end”, “-ware”, “-code”.

It seems that people liked Chaincode, though I think it has some problems with using it in a common software engineering context. I like Ledgerware, but maybe it doesn’t sound great too.

What could be other options?

 

BitEther Coin on Ethereum Classic

Some time ago I deployed a token contract called BitEther Coin (BEC). The idea is simple — an ETC miner participating in this experiment is getting an additional BitEther token reward to Ether reward received from a block. The Miner gets both Ether (5 ETC per block) and BitEther (2 BEC per block).

This is not a modification of the protocol, nor is it a hard fork or soft fork. It is just a standard feature provided by the existing technology and capability of the ETC system.

By doing this I am trying to show that Ethereum Classic is not the same chain as others: it has more powerful technology which allows you to build your own blockchain layer on top of it. Security of the network can be supported by any participant or by any business building on top of the chain.

BitEther Supply Model

The BitEther Token follows the Monetary Supply of Bitcoin. My initial goal was to make it issue 50 tokens every 10 minutes, with a halving every 4 years.

In practice, BitEther «big block» time is less that 10 minutes, because an additional goal was to reach 99% of total token production at about same time as Bitcoin will. As a result, BitEther issues 50 BEC coins every 6–7 minutes, and halves every 3 years.


… 

 

Problems of Java ORM in a microservice architecture

By microservice architecture here I mean an app split in independent parts, connected via MQ, database, internal RPC or independent APIs. Usually deployed as containerized microapps onto a horizontally scaled cluster.

Main problems with ORM

Different technology stack

Most likely you have a mixed tech stack, using different tech/framework/language for different services. Some parts are JVM apps, but others are easier to write using Golang or Python. In some cases you use an external 3rd party app, customized for your needs.

Lifecycle and backward compatibility

You probably don’t want to restart whole cluster, every single service, just to upgrade some part of the db layer. So you have to deal with different versions of Data Models, that should live together in same shared environment (remember «caching»)

Subset of data

Another important moment that each microservice operates own subset of data, and does different types of operations against the data. It’s even common to split app into microservices that do only following:

  • put data into db from a 3rd party storage
  • process/transform stored data
  • display data for end user

… 

 

Why I’m against Ethereum fork

Please note that this post was written long before Hard Fork happened, it wasn’t clear how it will be implemented, there were no final decision at the moment of the post

I’ve never invested in The Dao, and even was against this idea.

I worried because people just gave money without understanding in what they’re investing. Too many people decided to risk their money just because they thought that it’s cool, without any due diligence or anything.
… 

 

SaaS for Google Cloud monitoring and analytics

I’ve been using Google Cloud since the yearly days, I think it was year 2009 when I’ve deployed my first website to the App Engine. Since then I was doing consulting, made many projects, experiments, and so on. For past few months I’ve been working on TipTop.io, it’s a SaaS solution for analytics and monitoring for applications hosted on Google Cloud Platform.

The project in the early stage currently, and it supports only Google App Engine at this moment. But support for Cloud Containers/GKE is coming soon (and probably plain Kubernetes in near future).
… 

 

Take your seat

A quick note about office desks, seats, people and team spirit.

I’ve spend almost 15 years on software development, saw different companies, different people, different teams and different offices. Maybe hundred of them. Where I used to work, or my friends did. Some offices were small, some large. Cubicles, rooms and open spaces. Noisy and quiet. Cool startups and boring enterprise. Sometimes different offices that belongs to same organization.

At some point I’ve noticed a small difference, a difference in team members as I think is correlates with difference in how theirs work desks are placed. Remember when the same people have moved from one office to another, they started to conduct themselves differently.
… 

 

Setup Let’s Encrypt SSL on Google Appengine

Let’s Encrypt is a new Certificate Authority: It’s free, automated, and open.

“Let’s Encrypt” is a really great initiative (and a tool) that, I hope, will improve security of the modern web. It have very nice client, that will do all work automatically (unfortunately it’s not yet supported by Google Appengine). It’s supposed to run on target server, where it can validate domain and configure your Apache/Nginx/etc. But in of Appengine we don’t have such server, so have to generate and upload SSL certificate manually. I’ll show you how.
… 

 

Analyze Appengine logs with Kibana

Google Cloud have a nice Log Service, with some cool features (like Traces, I wrote before), but it lacks real analytics based on this logs. Like Kibana.

Fortunately Google Cloud can export logs to Cloud Storage. What’s cool is that this logs are in JSON format, so we could easily import them into ELK, without any complex Logstash configuration (honestly I cannot say that JSON schema fits well ELK, but still it’s easy to import).

I’ve prepared a basic Docker container with Elasticsearch, Logstash and Kibana configured for Appengine logs. Run ELK container with:

(you can get sources of this Docker image there).
… 

 

Trace Reports for Performance Tuning in Appengine

Fixing webapp speed is really hard job, mostly because it’s hard to find a bottleneck. And I want to show some tools that Google Appengine gives you for this job. Actually i’m going to tell about combination of two tools, that works just perfectly together.

First thing is Traces (under Monitoring tab in Cloud Console). It’s kind of a new tool, and I didn’t pay much attention earlier, just played a little. I thought it’s just another view to your logs, from Appengine APIs point of view:

gae traces - details - full

It shows you details about requests, with information about which API calls were made, how much time server spent on them, how much it did cost, etc. Pretty useful information btw.

…