I have been trying to get a grip on the Pennykoin CLI code base for some time. One of the problems that I’ve had is that the original developer had a lot of false starts and stops, and there’s a lot of orphan branches like this:
If that wasn’t bad enough, at some point they decided to push the current code to a new repo, and lost the entire starting commit history. Whether this was intentional or not, I can’t say. It’s made it very tricky for me to backtrack through the history of the code and figure out where bugs were introduced. So problem number one that I’m dealing with is how to link these two repos together so that I have a complete history to search through.
Merging two branches
So we had two repos, which we’ll call pk_old and pk_new. I originally tried methods where I tried to merge the repos together using branches, but I either wound up with the old repo as the last commit, or with the new repo and none of the old history. I spent a lot of time going over my bash history file and playing with using my local directories as remote sources, deleting and starting over. Then I was able to find out that there was indeed a common commit between these two repos, and that all I had to do was add the old remote with the –tags option to pull in everything.
Now, I probably could have gotten away by just cloning the pk_new repo instead of initializing an empty directory and adding the remote, but we the end result should be the same. A quick check of the tags between the two original repos and my new one showed that everything was there.
One of the things that we have to do as part of our pk_redux, as we’re calling it, is setup new repos that we actually have control over. This time around, everything will be setup properly as part of governance, so that I’m not the only one with keys to the kingdom in case I go missing. I want to take advantage of GitLab’s integrated CI/CD, as we’ve talked about before, so I setup a new group and pkcli repo. I pushed the code base up, and saw all the tags, but none of the branches were there.
The issue ultimately comes down to the fact that git branches are just pointers to a specific commit in a repository’s history. Git will pull the commits down from a remote as part of a fetch job, but not the pointers to those branches unless I physically checked them out. Only after I created these tracking branches on my local repo could I then push them to the new remote origin.
So now that I’ve got a handle on this repo, my next step is to hunt some bugs. I’ll probably have to do some more work to try and de-orphan some of these early commits in the repo history, cause that will be instrumental in tracking down changes to the Cryptonote parameters. These changes are likely the cause for the boostrap issue that exists. And my other priority is figuring out if we can unlock the bugged coins. From there I’d like to implement a test suite, and make sure that there is are proper branching workflows for code changes.
Knowing when to sell is one of the problems I struggle with as a trader, both in equities and crypto markets. In the past, I’ve relied on what the Motley Fool has referred to as a ‘buy and hold forever’ strategy, and it’s worked out well for me with some of the bigger tech stocks. As someone who’s been focusing more on shorter time frames lately, I’ve been having less success. And after watching my crypto portfolio break six figures in the winter of 2017 before crashing almost ninety percent, I’ve been trying to find a way to ensure that I’m able to actually take some profits when my positions start taking those parabolic runs.
One of the interesting metrics around the USD price of Bitcoin is the Mayer Multiple, which is the multiple of the current BTC price over the 200-day moving average. Trace Mayer determined that, historically speaking, the best long-term strategy was to accumulate BTC when when the Mayer Multiple was under 2.4. For comparison, the last time we hit that level was late June of this year when BTC hit $14K. Now I have traditionally been one to dollar-cost average into BTC, weekly, but I had to stop my contributions for a variety of market and personal reasons, but one plan I have been thinking about is to sell a large share of my position when the MM hits 2.88. This is a number I cam up with just by looking at the charts, and is currently about $26,200.
So I was really interested by this strategy put together by former BlackRock portfolio manager Vishal Karir, on how to take profits before the next bitcoin recession. I’m not going to rehash the entire piece here, suffice to say it sets a static accumulation target, buys when the asset value is below this target, and sells when it’s above it. I wanted to do some backtesting with some of my assets and see what I came up with. So I wrote up the following code in a Google Collab doc so I could start playing around with it.
Instead of looking at BTC directly, I wanted to start by looking at the Grayscale BTC ETF, GBTC, so for this block we’re using Pandas wonderful datareader to pull quotes from AlphaVantage.
from datetime import datetime
import pandas_datareader.data as web
!pip install ipywidgets
import ipywidgets as widgets
from ipywidgets import interact, interact_manual
os.environ['ALPHAVANTAGE_API_KEY'] = 'my_key'
f = ""
time_series = [
("Intraday Time Series", "av-intraday"),
("Daily Time Series", "av-daily"),
("Daily Time Series (Adjusted)", "av-daily-adjusted"),
("Weekly Time Series", "av-weekly"),
("Weekly Time Series (Adjusted)", "av-weekly-adjusted"),
("Monthly Time Series", "av-monthly"),
("Monthly Time Series (Adjusted)", "av-monthly-adjusted")
def get_asset_data (ticker, time_frame="av-weekly", start_date="2017-01-01", end_date="2019-09-30"):
f = web.DataReader(ticker,
start = parse(start_date),
end = parse(end_date))
interact_manual(get_asset_data, ticker="", time_frame=time_series)
We’re using f as a global for our dataframe. It stores the stock data. We’re also using ipywidgets to allow us to easily change parameters for the data we want to run against.
The next cell allows us to pass this previous dataframe to our backtest function. I wanted to play with various parameters such as the amount of capital available, the max contribution, and the ratio of max contributions to max sell amount.
Now there’s a lot here I will do later to clean up this code, making the params available via a widget as I did for the first function, but for now it works just fine. Here’s a test run with $100 contributed weekly from just after the beginning of the BTC bear market till now.
So, not bad on our hypothetical run. That’s a gain of almost $4700 off of $3769 invested, or a 24% return. Now we’re cherry-picking, or course. At the bottom of the market, we would have had over $7K deployed at a break even. But Karir’s strategy opens up a whole slew of possibilities, and what may be a good rule of thumb for scaling out of positions. Since I’ve been able to get this package working, I’ve been looking at other investments that I’ve made in equities markets, and am starting to form some hypotheses that may help guide best practices for both entries and exits.
My next step, after cleaning up this code a bit, is to figure out a way to run some regression tests on the sell multiple. I think a dynamic variable may actually be more helpful in instances where the asset goes on a parabolic run. But the point here is that I have a framework that I can test my assumptions against.
It shouldn’t be too hard also to integrate Karir’s strategy for accumulation of BTC, as well as altcoin pairings as well. It’s an exciting strategy for investment, and one that can be automated via exchange and broker APIs. There may also be some variations that we can deploy, using this kind of targeted portfolio value as a way to layer limit orders. For this simulation we simply used the open price of the time period, but we could calculate the price an asset would have to be for us to sell it next week, and set some orders in the present period. If the high for that period hits that level, we could simulate the trade and see how that affects our gains.
I spent some time Sunday cleaning up all the old coding projects on one of my computers and uploading them to my GitLab page. Most of the repos are private, but I’ll talk about cryptomarketbot shortly. I had to go through everything to make sure all tokens and other identifiable information was moved out. I used the wonderful python_dotenv package for that.
Most of the packages related to campaign finance data, that will likely stay private until I’m ready to dox myself, or crypto or equities related stuff. There were a few commercial projects that I had parked on Bitbucket that have been moved. Now that I’ve been able to inventory what I have, I can start fleshing out the useful stuff a bit more and refining it to something useful for myself and others.
Cryptomarket Bot, as I call it, is not particularly useful. I wanted to track the advance and declines in the top cryptoassests by market value, so I built a small function that queries the CoinMarketCap API and inventories the the top x coins and counts the number that have gone up or down. I think I had the idea while I was reading Alexander Elder’s book Trading For a Living, and it seemed easy enough to implement. I went and bundled that as a Twitter bot, but I haven’t been very motivated to maintain it. I suppose I should figure out a way to park it in a docker container where I can keep it running in-house, or push it to a Heroku hobby instance and leave it there. Maybe there are additional analyses that could be run, and the library could be triggered as a function call via a scheduler, cron or Celery, instead of a never ending Python script.
I have a number of spreadsheets that I use to track my cryptoasset holdings. I have one for mining and masternodes, and a series of others that I use to track investments in alts that I’ve also started using to plan equities trades as well. The general idea follows Elder’s two percent rule, that no trade exposes you to more than two percent total portfolio loss. Calculating that number for a brokerage account is pretty simple, since everything is in cash or equities, but crypto is a whole other story. One has to determine whether portfolio value is going to be pegged against the dollar, or in terms of BTC, (I prefer the latter,) and many assets may have no direct pairings, such as new shitcoins that aren’t listed on exchanges, or ERC20 assets that are only pegged to Ether.
So while figuring out my risk profile for a ethbtc trade may be simple enough, determining that for something like IDEX staking is a bit more difficult. It’s also hard to separate long term buys, (dollar cost averaging BTC,) from more speculative plays like trying to swing-trade PIVX or something. I’ll be spending more time in this space walking through that decision-making process as I figure out ways to model my portfolio.
Tomorrow marks the start of the last quarter of 2019, and we’ll use the date to mark a new snapshot of my holdings, figure out what my strategy is for the quarter, and will walk through the trades as I plan them out, execute them, and track them. Stay tuned.
About two weeks ago, Jerry Howell, the main developer of Pennykoin (Pk), a Cryptonote privacy coin, publicly abandoned the project, citing personal health and financial reasons. As someone who was heavily involved with Pk during its early days, (eighteen months ago!), and probably the only person besides Jerry that has looked under the hood of Pk, I’ve been asked to take up maintenance of the project.
I feel it is necessary to provide some details that should be shared with the Pk community, my assessment of the current state of the project, and why I think Jerry was right to abandon it.
I don’t have much to say about Pk’s origins. Jerry posted an [ANN] link on May 14, 2018, which was the day after he had the release version of the wallet software released. There isn’t really much to say about Pk as a product. Cryptonote is a privacy coin framework. It was developed to allow people to create their own Proof of Work (PoW) coin by manipulating things such as block time and emissions rate. Bytecoin was the first coin made from it, (and is probably a scam), and Monero is based off of it as well.
Pk first came to my attention over the summer through a Tweet of a noted shitcoiner that I followed, and there seemed to be a nice community developing for Pk on Twitter, so I threw some hashrate at it and started mining. Jerry and I started talking, and pretty soon I was heavily involved, setting up the official mining pool and block explorer for Jerry while he worked on the code.
I found Jerry’s backstory very interesting. He worked in the service industry, I want to say it was food-related, but my memory is hazy. He had been sidelined due to health issues and was off his feet, so he started learning to program as a way to pass the time. I was actually impressed with what he had managed to accomplish. He had a vision for Pk, and I was happy to be helping build something, instead of passively investing in a project as I had been up until then.
Signs of trouble
At some point during the summer, it became clear to me that there were some serious issues that were going to hamper Pk in the long run.
The first was a problem with bootstrapping, which is the way in which a freshly copy of the PK software downloaded the historical blockchain data from the other nodes. In short, it didn’t work. Part of the point of a blockchain is the validation process, in which a node verifies that each block is valid and meets the parameters of the chain that have been specified. Now Cryptonote is built to allow these parameters to be changed. So if one initially specifies a mining reward of 10, and later decides to change this to be 6, there is a way to specify versions of the blockchain, that the node can use to validate.
Unfortunately, Jerry made several changes to the Pk code in the first few weeks that didn’t follow this pattern, and as a result, the nodes were unable to download the complete chaindata, and would fail to sync when connecting to the network. Jerry’s response to this was to provide the chaindata as a separate download that needed to be thrown into the application data folder on machines.
I attempted to help fix this, but my knowledge of CN and C++ programming wasn’t up to the task, so I tried to hack our way around it by disabling validation checks on certain blocks. I don’t believe that these workarounds made it into any surviving releases of the Pk source, but the bootstrap issue has only gotten worse and worse, which is now why new installs require a 100+ megabyte download to bootstrap clients to block 130,000 or so, which is around the time of Jerry’s last update around the end of August.
Chain fail #1
Pk started to get noticed around late summer, and we started to see more and more hashpower being added to the network. I forget exactly what algorithm Jerry was using for PoW, but it was GPU-friendly, and available on rental services like NiceHash. Pk wasn’t yet available on any exchanges yet, but we had a healthy over-the-counter (OTC) market going on. (Disclaimer: I was providing escrow services for a fee.) Now, I can’t really say for certain whether what happened next was malicious or not, but we experienced a chain failure to to what I refer to as a difficulty attack.
Without getting too technical, block chains have a target block time, the average time in which a block should be mined. In the case of bitcoin, it’s two minutes. In Pk, it was two. There is an adjustment built into the blockchain algorithms that will determine whether this target block time is being met, and it will adjust the PoW difficulty target accordingly. To explain this in plain language, think of the PoW game as a requirement that n coins must be flipped heads in a row to win the block reward. As more miners join the network, that number will increase, from 10 to 100 to 1000 and so on. As miners leave the network, that number decreases.
What happened with Pk that fall, was that so much hash power was thrown at the network that some individual or individuals were able to mine an immense amount of Pk at a faster than normal rate. This increased the target difficulty immensely, at which point this power was removed from the network. The end result was that the remaining Pk miners did not have enough power available to mine any blocks, or at least at any rate that would have kept the chain running. Miners, not getting the expected rewards, left the network, making the promise even worse.
Now, I give Jerry immense credit for getting things running again. He basically implemented a difficulty adjustment to the code base and swapped the mining algorithm out for one which we could deploy much more powerful ASIC miners. He pushed the changes out after a week, the community threw some hashpower at it, and we were off and running again.
Note that I am being a bit speculative about what happened, without running metrics on block times and other chaindata, one cannot know whether this was a simple difficulty attack or something more nefarious.
You don’t know what you don’t know
In spite of the heroic efforts on the part of Jerry and others to keep Pk moving after this, there were problems with his development style that were due to his novice, that have ultimately hobbled this project. Now, let me be clear, I have nothing but respect for Jerry and am saying none of this to impinge his character. That said, I think there are things that any potential Pk investor needs to know, and that’s why I want to put this on the public record. I am by no means a professional software developer, so while I was ultimately able to spot these problems, I was in no position to correct them myself.
First off, Jerry never caught the hang of version control. When I first started working with him, he had a horrible habit of committing to master, and when he needed to change something, or hit a wall, he would just delete everything and start from scratch, which breaks the commit change and makes tracking changes very difficulty. For example, here’s what the early releases of the PKNode software looks like:
Now, someone with more experience than I could probably rebase these to link them together, but there are dozens and dozens of commits and branches that go no where, and since I stepped away from Pk at the end of fall 2018, I don’t really know what he was doing. There are a few blog updates over the past year that talks about various initiatives, but there’s just too many changes for me to try and reverse engineer.
Technical debt must be paid
Unconfirmed transactions or ill-gotten gains
There are a number of problems with Pk as it stands now. First off, there is was a huge bug that has locked up about seven percent of all of the current coins in circulation. For a quick technical explanation, I need to talk about the unlock_time parameter of a CN transaction. This unlock time is primarily meant as a way to prevent newly mined coins from being spent immediately. I believe it’s meant to discourage forking attacks or something similar. With Pk, this unlock time is normally set to 10 blocks (20 minutes) for block rewards. For standard transactions, this is zero. Normally, anyways.
After Jerry’s disappearance, following the latest release, we started getting reports from people with unconfirmed transactions. According to the information that I’ve gathered, these people withdrew these amounts from the Graviex exchange, and their wallets were not making them available to be sent elsewhere. I was able to get my hands on one of the individual wallets, and confirm the issue.
A number of these transactions were mined to the blockchain with a large unlock time. So large, in fact, that at Pk’s target block time, it will be one hundred and twenty yearsbefore these funds are available to the owners. Now I wrote a program to examine the entire Pk blockchain, and I believe that these transactions were all limited to between November 2 and March 31, which coincides with the release of several version of the Pk software. I do not believe this bug is currently in circulation. However, I have been unable, or more accurately, unwilling, to contact Graviex to see what was going on their end in order to properly establish a root cause. In fact, I don’t think it’s likely that I will.
There are other issues with the current code base that I’m not go into much detail on. There seems to be discrepancies between the CLI and GUI software, which I believe stems from the core CN/Pk libraries existing separately. Wallets amounts are different between the two for some of my older wallets, and I’ve documented at least one transaction that is present in the CLI is not displayed at all in the GUI. From what I can determine, this is not related to deposit functionality, which is not implemented in the CLI at all.
Given the recent vulnerabilities and bugs that have recently been exposed in Cryptonote, I cannot rule out the possibility that this was intentional, whether it was malicious or more benign. I am not accusing anyone specific of any ill behavior, but am just stating that I do not know enough to make that determination at this time.
The Jerry-sized hole
For the most part, up until now I’ve been discussing what are mostly technical challenges that can be overcome with enough time and effort. There is one issue that cannot, and that is the absence of Jerry Howell.
I’m passing no judgement here. Jerry had to chose between health and keeping a roof over his head, and I’m not going to second-guess his decision. Unfortunately, he couldn’t eke out a living from Pk, and priorities is priorities. He did what he had to do. For the future of Pk, that presents us with some problems.
First off, because Jerry still holds the key to the kingdom, so to speak, we would have to recreate much of the public-facing infrastructure: two sets of githubrepos, social media accounts, various Discord instances, &c.. Thankfully, members of the governance committee have access to the web domains and hosting services that are running the main pool. But in order to modify the code, I would have to create new Pk repos, which would present us with a different type of ‘fork’ that could become problematic. The last thing we want is a non-authoritative code source online, and what would happen if we took steps to publish new code to maintain Pk, and Jerry changes his mind and decides to go in a different direction?
To that end, members of the governance committee have decided that it would be best to wait till the end of the month to see if he will resurface. There is no doubt that he has been active; we noticed a new Github repo for an unrelated project that he created a few days after he disappeared. The best thing for Pk is that he will pop up long enough to properly hand off control of these resources so that development can continue without him.
If not, it will likely be the end of ‘Pennykoin’ altogether. The risk of associating with that name is too great, and at a minimum, the community will have to decide on a new name and rebrand.
The future of Pk
Even if Jerry does come back and hands things off, it doesn’t mean that we’ll be out of the woods. I’ve mentioned the technical debt that has to be paid off, and I can tell you right now that I am not the one to lead Pk out of the desert, so to speak. My personal investment in this project is not substantial, and the opportunity cost to me to spend the necessary amount of time needed for me to figure out how to fix what has happened is too great a risk. Unfortunately, there does not seem to be another individual within the community right now that has the technical skills needed to manage a project of this complexity. I simply do not have the time.
A quick calculation of the current Pk supply will give us a market cap of Pennykoin: 1.6b Pk minted over 150k blocks. The ‘price’ as I write this is less than one sat, more like 4/10 of one, which means we’re looking at a total cap of less than 7BTC, or $70,000 in USD. That’s impressive nonetheless, and demonstrates the promise of crypto-based assets, but as Jerry has found, one can’t pay the rent with those kinds of numbers. I just can’t commit to that, and am not willing to take responsibility as the one to fix the numerous problems that exist today. I’m not even sure I know how to fix these problems.
My personal and professional opinion is that the entire codebase should be redeployed from the ground up using test-driven development principles, with features selected from a proper governance process. I also think that inevitably, the existing chain will need to be abandoned completely. I’m not familiar enough with blockchain engineering that I could figure out a way to hard fork the stuck funds back into circulation. It would be something on par to Ethereum undoing the DAO hack, and I’ll admit I’m not up for it. have already been thinking about protocols for an automated chain swap that would allow us to provide current Pk holders with equity in the new chain.
I realize that this post may not be what anyone wants to hear, but I think it is an honest assessment of where Pk stands. I haven’t given much thought to what the fallout of this will be, but I assume that most people will be disappointed, and maybe even angry at me for publishing this. So be it. I’ve been in the cryptospace for almost five years, and I think this is one of the greatest opportunities that our generation will see in our lifetimes. Many of you no doubt agree, else you would not be here at the end of this brutal, brutal bear market. That said, I believe that there is no such thing as failure so long as knowledge is gained. I know I have learned an immense amount about blockchains from working on this, and many others have done so, and stepped up to run nodes, websites, or other parts of the Pk infrastructure.
So there is a way for us all to move forward, utilizing the connections that we have. It may not look like Pk does today, but there’s no reason that the connections and network that we’ve built should go to waste. This space is moving fast, and there are lots of opportunities to form a new type of organization that can help us move forward and build a future that we can all be proud of. I am personally very interested in work being done around Decentralized Autonomous Organizations (DAO) and Decentralized Finance (DeFi), but others may have other suggestions that they may be interested in.
What’s important to me is that the future that the Pk community decides on, whatever the course, is decided in a democratic manner. That is our first challenge, ensuring that what we build is more robust, and can’t be destroyed by the decision of one person to disappear. I have already been in discussions with others on the governance committee about forming a formal, legal entity to help manage this responsibility.
I realize the community is going to need some time to process what I’ve written, and I know there will be lots of discussion around this in the days to come. I hope that enough people will feel it worth their time to stick around, and help decide on next steps, together. There is vast opportunity in the crypto space, and I have already met many people that I would be honored to work with to build the next iteration of blockchain based products.
So there’s been a bit of life in the crypto markets the past day or two. Bitcoin has been trending in a range. Cryptotwitter is debating whether it’s a descending triangle or a wedge, trying to predict whether a breakout up or down is coming. It looks to me that it’s in a consolidation zone. I have been holding off on purchasing much fiat to BTC, since I have other financial responsibilities that are taking precedence. Plus I have too much exposure, in general.
I have begun plans to phase out my use of Lending Club for investment purposes. I had started separate accounts for both of my kids, and was happy with the $25-50/month that I had been setting in there for them, with three to five percent interest. But around the time of the bull run, October 2017, I decided to start putting those funds into BTC, giving both of them their own wallets. I let Lending Club continue to reinvest the returned payments. Until recently.
The big talk in the cryptoasset space right now is in decentralized finance, or DeFi. Most of the major apps in the space rely on Ethereum smart contracts, stable coins like Dai being the most prominent. I became aware of platforms like Compound, which allow lending and borrowing of several assets, like Dai, Ether, and others. The basic premise behind Compound is that people deposit their assets with the smart contract, and can then use those assets as collateral to which they can borrow other assets. The reasons why is something I really can’t explain. I assume most of it is speculative trading; a bit to risky for me given the borrrower APR.
Now with Dai, which tries to maintain a 1:1 parity with USD, has had a 20% stability fee assessed against it. Which is why it had a nearly twelve percentlending interest rate on Compound a few weeks ago. I had to try it out. I had some change on Coinbase, so I bought twenty bucks worth of Dai, transferred it to a Metamask wallet, and had it deposited at Compound in no time.
Now, this is not financial advice, and there is a risk with DeFi and smart contracts. There is the possibility that there is a flaw in either the Compound or Dai contracts, and something could go horribly wrong. But I’ve decided to stop reinvesting the kid’s funds on Lending Club, and will start moving their funds over to Compound as the loans are paid out. There’s no sense in lending USD at less than three percent, given that it’s hardly better than inflation. Now the rates on Compound and other DeFi applications can fluctuate daily as well, so I’ll need to keep an eye on things and make sure nothing crazy happens.
Given that I want to take advantage of this new opportunity, without increasing exposure to BTC directly, gaining high interest on stablecoins pegged to USD seems like a no brainer.
Impostor syndrome is bit of a popular topic in certain professional circles, people being haunted by the nagging feeling that they don’t really know what they’re doing in their chosen field, and that soon someone will expose them as a fraud. It seems to be prevalent among software engineers and other fields where specialization inevitably informs one that the sum of what they know is but a fraction of the sum of knowledge. It’s not something that I content with, for the most part, but I bring it up because I’ve been thinking about when I get to call myself a software engineer.
Not that I’ve ever been lacking for confidence, rather as fair number of people of my gender and complexion, I suffer from an excess of it. I’ve always operated from a place where coming up to an answer to a question, or hypothesizing an answer as a means to discovering one is usually the correct course of action. This is different than having an opinion about something about which I know nothing, of course, but this invariably leads me to question or challenge assumptions to answers from others, some of who may have more expertise in a subject. As one who realizes that many advancements in various fields have been made by outsiders, I don’t see any problem with this. My wife on the other hand, calls it ‘male answer syndrome’ when I inevitably make a statement that runs counter to something that she knows as true, or has been led to believe by someone else with more expertise.
On Twitter, this has become known by the number ofreply guys that plague women’s timelines. I don’t know if this is specific to the professional classes or not, but I assume it happens wherever a woman forms an opinion about anything at all. Around here though, I’ve started correcting my wife’s accusations of male answer syndrome with wrong answer syndrome, as our eldest daughter has picked up the annoying habit of declaring demonstrably false statements about things in the middle of an argument about some parenting slight against her.
A little over a year ago, I became involved with a small blockchain project. I’ll keep it unnamed so as to prevent this from showing up in search engine results for now, but it was a fork of privacy coin framework that was being managed by a single developer. The dev was new to software design and had a lot of time on his hands due to disability, and had done a decent job of establishing a community around this project. I came in a few weeks after it had been launched, and became a part of the community. I set up mining pools, block explorers, and started doing a lot of commits to various side projects associated with this new cryptoasset.
Eventually though, I began to see warning signs. our dev didn’t understand git versioning very well, and had a bad habit of just starting new repos when he got stuck or a feature didn’t work out. The commit and branch graphs had a lot of dead ends and unconnected starts. I was never really sure what he was doing, what he was working on. I tried to help, fixing a couple things in C++ where I could and trying to help him get his workflow under some sort of change management, but there wasn’t a test suite, and several of the changes that he had introduced in the code base seemed to have killed backward compatibility of the existing blockchain.
In all, I think things became too overwhelming for our friend. I had to step out of the picture after a few months to deal with real life issues, and I don’t think anyone else ever stepped in that understood blockchain functionality the way that I had after spending hours looking into the code. In addition to maintaining the code base, trying to introduce new features, our friend had to deal with hash attacks which stalled out the blockchain completely not once, but twice, and had to deal with the constant support issues of pool operators, trading exchanges, and users with wallet or transaction issues.
It all became too overwhelming. In addition to dealing with all of this, our friend was also dealing with both physical and mental health issues, as well as money issues that apparently threatened his housing situation. One day, he published an apology to everyone for failing and went dark.
I hadn’t been active in the community as I had been, but still kept an eye or ear on things. The stalled chain had been restarted and a new version of the wallets released, and things seemed like they were getting back on the right track. There were a couple people that seemed to be having some issues with funds, but nothing serious. Most of the trouble seemed to be with burnout.
There was a panic, of course, among some of the miners and people who had been sticking with the project over the last few weeks of troubles. There were strong words about fraud and exit scams from people who had gotten involved with the project more recently. A few community leaders tried to calm nerves.
But ultimately, there was no one else that had any technical experience with the code itself. None that were willing to speak up, at least, and I don’t know of anyone else that had been interacting at the level that I had. And I still had a bit of financial and emotional stake in this project, which is why I volunteered to take the reins on a technical assessment, to figure out the state of the network and whether there was any chance of getting things back on track.
And that’s how I became responsible for a broken blockchain project. I’m still trying to figure out just how broken things are, whether it can be fixed, or whether a project that was worth hundreds of thousands of dollars is now dead.
So this site has a long history with scammers. One of our most popular posts way back in 2005 was documenting a run in with a scammer on a Yahoo Personals. It got thousands of hits, and is probably the most popular thing I ever wrote here. Anyways, as one who is involved in crypto, and frequents many Discord servers, I get targeted from time to time. One happened earlier this week. I got the following DM on Discord. I ignored it for a few days, then finally decided to take a nibble. My altruism will get me one of these days.
I knew it was a scam at first, but I was curious as to what the game would be, and interested to know if I could waste this asshole’s time and keep him from other marks.
Now I’ve seen this one before. It was about a year ago, maybe two. The play is to get you to sign up on this exchange, but of course it’s fake. There’s usually some sort of deposit required to verify your account or some other trap to remove funds from suckers. My curiosity peaked, so I checked the site out. I DO NOT RECOMMEND YOU DO THIS! I had a lapse in operational security when I did this earlier. My VPN proxy was not activated, and I may have inadvertently exposed my primary public IP to the operators of my house, potentially flagging my address as a high-value target. That said, what I saw on the site was quite impressive.
So, you may be asking, what makes me so sure that this is a scam and not an actual legit site? Well, flag number one: no Twitter. Neither by username, nor by search term. I I did find an ICO platform called CoinPlace, which means the scammers may be trying to count on some association confusion. Or their just lazy. Now this was enough for me, given the Discord message. I was already done. More important things to do. That and I felt I may have already exposed myself.
Of course I wanted to be a bit more sure before posting all this, so I did a bit more homework. Flag number two: the domain is less than 10 days old. This in spite of the assurance that the company has been around since 2013. And flag number three: the name Cryptual, mentioned on the front page. The only hit I could find for that is a LinkedIn page for Cryptual Limited, which was apparently founded in 2017 but links to a dead domain.
So, apologies to the Cryptual team, if they actually exist, but I wanted to write up this dissection of the XCoinPlace scam and help get the word out, maybe save people some hassle. I’ll count success given how quickly this site goes down. And in the off chance that it is legit and not associated with my Discord friend, (notlikely) they can reach out to me on Twitter to convince me otherwise.
In our last part on IDEX, we discussed how the decentralized exchange aims to incentivise their infrastructure roadmap with staking. In this part, we talk about our experiences implementing our node.
For the past 18 months or so we’d been running an XDNA masternode on an Amazon AWS instance. In July, following a 90% drop in price of XDNA during that time, we decided to try and rollout the IDEX node. Unfortunately, we ran into some compatibility issues between XDNA, which was written for the Ubuntu 16 Boost libraries, and IDEX, which was supported on 18. Rather than spend a lot of time trying to enable legacy Boost libraries for Ubuntu 18, we decided to dump the XDNA masternode and just focus on IDEX instead.
The deployment from Github to implementation was simple enough. The only issue that we encountered at first was that we were still holding legacy AURA tokens, which had to be swapped for the newer IDEX tokens. This delayed our staking by 7 days due to the staking requirement, but once we waited and signed our proof of stake we were good to go. All we had to do from there was make sure our server was up, and collect our rewards.
We immediately started having stability issues. The node wasn’t able to keep up with the data and stay in sync. Even though the hardware requirements suggested 2GB of memory, it appeared that others were having problems as well, so I bumped things up to a larger instance. The system was able to run better, but still experienced intermittent issues. While issues on the IDEX Github repo seemed to be going without response, there were several IDEX staff on the project Discord server that actually seemed to respond to people asking for help.
The issue with these small VPS nodes is that IDEX required a connection to a full-fledged Ethereum node, which is a bit much for a VPS with only 2GB of RAM to handle. I was actually referred to Infura, which provides Ethereum and IPFS APIs. Basically, they run the Ethereum node, and provide an API key that you can use for your web 3.0 applications. Ethereum as a service, basically. The free Core tier allows 100,000 requests a day, which is more than sufficient for the IDEX node, which averages about 82,000/day.
Once we implemented Infura, we were able to reduce our AWS instance down to a t2.micro instance. Bring our total monthly cost down to just over $9/month, about a third of what we had been running before.
IDEX payouts are based on two week periods. Nodes earn credits based on their uptime and stake size, and these tier 3 nodes split one quarter of the fees of the IDEX market amongst themselves. Our payout for the minimal stake amount was less than a hundredth of an Ethereum, and our shock at seeing this caused us to do some more research into how the staking model and payouts operated. I was able to find a earnings calculator, but the results weren’t promising.
So it’s obvious that the doing the absolute minimum staking amount is not really worth the effort. And if I had done my due diligence from the start I may have realized this and maybe reconsidered my investment of time and money. I don’t consider this exercise to be a waste though. Beyond the the drawdown in value of the IDEX stake itself, I really haven’t lost much that I’m worried about in and of itself. With the hemorrhaging that altcoins have had over the last 18 months, daily volume on the exchange is down considerably from it’s all time highs. If this Redditor is to be believed, IDEX was doing ‘upward of 25 mil a day in volume’, which would considerably change the value of this calculation. There are lot of factors that need to be taken into consideration as to whether the market will come back and whether IDEX can maintain their lead, but one of my core beliefs is that during a gold rush, the sure money is on those selling the pickaxes. BNB token, IDEX and other tokens that allow taking profits from the trading volume of the exchange itself may be a better long term strategy than many of the various crypto projects that are born and die during the market cycle.
Ultimately, I considered IDEX’s long term roadmap when deciding to increase my stake. Although there has been no official word on when the tier 2 staking application will be available, those participating will earn 33% of the fees rewards, and 42% for the tier 1 when IDEX becomes fully decentralized. Ultimately, if IDEX is successful, ownership of a tier 1 masternode could be very lucrative. Plus I love these type of infrastructure projects, running mining pools and masternodes. I have decided to increase my holding of IDEX tokens to ensure break-even on the tier 3 node, which will hopefully put me into a position where I will be in a position to operate a tier 1 node.
With over two million dollars worth of IDEX tokens currently being staked, I may not be in the best position to participate, but if they do implement pooled staking then I should be in a pretty good position.
There are several concerns that we’re watching, mainly around auditability and the stability of the platform software, which we will leave for another update. For now, we’ll continue layering our limit orders to pick up more IDEX and figure out how we can manage our exposure to any further market downturns.
In the first part of this series, we discuss how decentralized exchanges work, and how IDEX operates their incentive plan.
It’s been a while since we talked about cryptoassets here, so today I want to talk about some of my experiences staking with the IDEX platform. IDEX is a decentralized exchange platform, which means that it is a non-custodial platform for crypto exchanges. This is in contrast to custodial exchanges where your money is kept on the platform itself. This is traditional method of asset exchange, where the exchange holds your assets and executes your trades. This is how the equities markets have worked since for ever, and how the first generation of bitcoin trading sites worked: Mt. Gox, Coinbase, Gemini, Poloniex, et cetera. With the advent of smart contracts on the Ethereum platform, these types of non-custodial brokerages have sprung up, with the first, EtherDelta, being the first.
Instead of the exchange holding custody of the assets, which can lead to theft, as was the case with Mt. Gox and other exchanges, the users retain custody of their tokens. Operations are performed via the smart contract, which, while it does have it’s risks — the DAO hack for example — the exchange operator does not have access to the tokens. Users deposit their funds with the smart contract, buy and sell orders are matched on the order book — more on that shortly — and the smart contract makes the trade, minus a small fee, of course. Users can cancel their open orders and withdrawal funds at any time. Minus the risk of a black swan event like a contract failure or other hack, users funds are completely under their control and are safe at all times.
Now with Etherdelta, the first generation DEX platform, the order book was contained on-chain, meaning that posting buy and sell orders, or cancelling them, cost gas. This was expensive, and was subject to delays when the Ethereum blockchain became congested. What IDEX has done with their exchange is to keep the orderbooks off chain, which removes these two limitations. Now critics will say that this type of centralized order book isn’t decentralized, which is why IDEX has a roadmap to offload this infrastructure in a fully decentralized manner.
Phase one of this three part plan is offloading the trade history, which they’re incentivising through a staking masternode model. Those participating in this process split twenty five percent of all fees on the IDEX platform, which is 0.3 percent of trade volume on the platform. Payouts are about every two weeks, based on node uptime and amount staked. There’s a seven day freeze period on funds as well, which is important to note.
Our initial entry into IDEX was around July of last year. The minimum required staking amount of ten thousand IDEX tokens, was around fifteen hundred dollars at the time, and we averaged into our position over several months for around sixty percent of that. This was several months before the staking software was actually released, and not only was the general altcoin market tanking, but IDEX took a further hit after implementing KYC protocols to stay ahead of regulatory issues. The staking nodes actually went live in January of this year, but by the time we actually started operating our node, the value of our IDEX tokens, (and our stake) had dropped to less than a third of what it had been a year earlier.
In our next part, we’ll talk about our experience setting up our node infrastructure, and our profit results.
During the California gold rush of the 1800’s, the ones who could be counted on to make the most money were the shops that sold the picks, shovels and other mining equipment to the speculators. The same can be argued about the recent cycle in the cryptocurrency space. When Bitcoin took a dive off the all time highs in December 2017, it seemed that the only ones making money were the graphics card and ASIC manufacturers. During the crypto winter which we have just left, one of the biggest success stories was that of Binance, which went on to become one of the largest exchanges in the space. In less than a year, CZ and his team created the premier trading market, and the success of Binance coin (BNB), was one of the few rays of hope in the space, increasing 10x while the rest of the market was tanking.
This reality of the market was not lost on traditional finance players, as even throughout the winter, infrastructure was being built. Coinbase and Gemini continued to expand their offerings and improve their platform, ready to make millions in fees from both the retail and institutional investor.
As an alternative to centralised exchanges, decentralized exchanges (DEX) have held the promise to preserve the decentralization, anonymity and censorship-resistance that the crypto-economy brought. Many of the more libertarian-minded have bemoaned the big money moving into the space, as centralization and regulation have given crypto the flavor of traditional finance.
So when it began to look like infrastructure plays were the best way to hold value during crypto winter, I began looking at ways to use my knowledge to setup staking and masternodes. Our first experiment was with XDNA, which uses a tiered staking system. We setup an AWS instance, fumbled around with the setup, and eventually had a staking masternode setup, which was earning us a nice passive stake. Unfortunately, we made a mistake with the sizing of our instance, which ran up our expenses. And even worse, we had secured our stake before the bottom fell out of the market, meaning our stake lost 90% of it’s value. So while we are still holding this node, along with the additional 25% in masternode earnings, we have discontinued the node and are holding our stake in case XDNA ever 100x back to our entry price.
Our latest play, that we’re currently evaluating, is IDEX. It’s the staking token for the DEX of the same name, which is currently the most popular of its kind. The iDEX staking roadmap has an ambitious plan to eventually migrate all of the exchange hardware to this decentralized model, and the current tier 3 staking model for trade history is just the first step in the plan. We had purchased our stake many months ago, before the staking software was released, and between now and then the market has taken quite the hit due to a number of factors. Including the broader decline in altcoins, iDEX implemented know your customer (KYC) requirements, which caused a revolt among the community. We also made similar issues with hardware selections, and ran into some performance issues that we’ve since rectified. Perhaps the biggest issue that will doom our participation in this project is that the current minimum stake, at current price and volume, is insufficient to generate a profit. Even though our hardware costs are down to nine dollars a month, the staking proceeds for the minimum 10,000 IDEX (about $200-300) is not enough to cover this cost. Based on our calculations, we would need to increase our stake by 3-4 times in order to just break even. Things are complicated by the fact that IDEX is only tradable against ETH.
So for the moment, we’ll leave our node running, and assess whether we want to add the increased exposure to iDEX. We remain bullish on DEXes in general, but operating a staking node at this juncture, given the risk of more price depreciation in ETH and alt markets, make this a tough play from a risk management perspective.