Counterparty as an asset platform is booming. We are on 13 days in a row with 1000+ transactions. This has never happened before.
It’s repeated EVM promises that have not been delivered, which causes damage to XCP’s reputation.
I see the point that implemented a buggy, preliminary EVM would be much worse. A platform crash at this point will cause financial losses.
Ethereum’s frequent attacks, followed by hasty hardforks, is also something that should make us wonder if the EVM is a good idea in the first place?
So I’m raising the question whether it would be better just to implement new features periodically, like every six months? These would be simple, well document, thoroughly discussed, and (as has to be with decentralized platforms) uncontroversial.
We all ready have the CIP system with some proposals that are everything I mentioned above. E.g. subassets and ability to change divisibility for unused assets.
In the future maybe there will be demand for selling random tokens (like you can buy a pack of random cards) or some simple lottery, or anything of this nature. Why not add such features on a semi annual basis?
P.S. Features will require anti-spam XCP fees, and for those whose primary concern is the XCP price, this is a good thing.
Let’s look at your example of “buy a pack of random cards”. I think is a good illustration of the tradeoffs involved.
Let’s say we hard-code that feature. SoG wants to sell 6 cards for a fixed price, say 30 XCP. But then Force of Will wants to sell 8 cards for 50 XCP, or 10 cards for 60 XCP with a 10% chance of getting 20 cards. Then another game wants to add a “stretch goal” to a card pack promotion. If 100 people buy 5 cards for 10 XCP, then everyone gets a bonus 5 cards.
You could hard code enough features to make all of these things possible. Then in the next 6 months, another use case gets hard-coded in. Soon the Counterparty code base becomes so bloated with so many features that it becomes unmaintainable and insecure. That is not a sustainable path.
There is a lot of development effort going into the EVM right now. We need to wait for it to stabilize. When (if?) that happens, then we should merge it into Counterparty. In the long term, Counterparty will be better in the long run. But it is going to take some time - probably longer than any of us want.
We need to have patience. And we’re going to need more developer help either way…
BTCPAY is a special feature for when BTC orders match on the DEX. It’s been used almost 2000 times. It’s really a lot, considering limited wallet support.
Dividends let the asset owner distribute any asset proportional to all asset holders. I don’t have statistics but I recall it being used.
The Rock-Paper-Scissor game was introduced in 2014 as a proof of concept. It worked as intended but was not popular and later disabled.
Betting on oracle feeds is a feature that was used by a couple of websites in the beginning. Neither took off and betting is not used at all anymore.
Some lessons:
The features that have to do with asset trading or transfer are popular (DEX, BTCPAY and to some extent dividends)
Betting and Rock-Paper-Scissor are probably too slow to gain traction. With the 10 min block time (sometimes 30+ min) anything that require to wait for an action, then a reaction, then a third action, etc, simply won’t be used (???)
Someone broke the entire platform by a wrong bet input this spring (ehmmm, it was I who did it ). Thankfully, it took Adam Krellenstein only an hour to fix. What happened is that I set the oracle fee at 4600% (not sure about the exact number but the magnitude is what matters here). So when the bet settled the oracle was paid 46x the initial bet. The code (not the betting code, rather somewhere else in the core code) snapped out that this is impossible and crashed. The bug was due to a confusion with percentages. It was assumed that 46% was the highest possible fee, which was supposed to be the implied highest value of the number format. For every new hard coded feature there is risk of a bug like this.
Also, every new feature will use computing resources, so a XCP fee should be considered to prevent spam.
Here’s a brainstorm for advanced conditional asset trades:
). Thankfully, it took Adam Krellenstein only an hour to fix. What happened is that I set the oracle fee at 4600% (not sure about the exact number but the magnitude is what matters here). So when the bet settled the oracle was paid 46x the initial bet. The code (not the betting code, rather somewhere else in the core code) snapped out that this is impossible and crashed. The bug was due to a confusion with percentages. It was assumed that 46% was the highest possible fee, which was supposed to be the implied highest value of the number format. For every new hard coded feature there is risk of a bug like this.