I would forget about Turing Complete EVM development for now. Projects that need this functionality will naturally gravitate to Ethereum. It would be nice for Counterparty to have this functionality eventually but should not be the focus in the near term.
A simple Counterparty-specific VM would be great, as it would provide a unique benefit to using Counterparty. There are many developers who would like to develop simple decentralized applications but learning Solidity and the nuances of Ethereum are a hindrance. This is a big project though. Are there enough people and resources available to make this work in a reasonable amount of time? There will be no benefit if a few people volunteering their time make a buggy mediocre VM that no one uses. This option should be explored if a team of top notch developers could work on it full time. If the resources aren’t available it should be shelved for a later date.
Hard coded features should be the main focus. The project could gain traction quickly if the right features are available and simple to use. Counterparty’s simplicity should be its strength.
I think a lottery would attract a lot of interest. The auction idea is interesting as well; instead of a limit order to sell a token maybe you could have the option to send an order to DEX that accepts the highest offer price submitted during some number of blocks.
An updated roadmap would be helpful and informative.
Finally a lot could be done if a simple contract or application could receive and own BTC, XCP and other tokens, enter orders on DEX, and distribute token assets according to certain criteria like a timed interval, block number, or a request from a specific address. This functionality would cover escrow agreements and collateral based lending, two very important functions with widespread use cases.
Good. I’ve heard others say the same, so this should likely be the focus.
Cool. What do you think of my lottery suggestion? Auction, too, is a very good idea. Tokens with very low trade volume would really benefit from this. Like if I own an ultra rare Pepe and I have no idea what it’s value is, I can put it out for auction. I guess this would be separate from the DEX, and the parameters could be as following:
Asset to auction off
Lot_size (amount of tokens to auction off (special case 0 would be the token issuance ownership))
Currency (the asset to get in return, e.g. XCP or PEPECASH)
Currency_amount (the minimum bid)
Bit_increment (the required increase in bid)
Wait (number of blocks to wait for higher bid)
Expire (number of blocks the auction is active)
Cancel_fee (if currency is BTC and payment is not made, charge this XCP fee)
BTC_pay_deadline (if currency is BTC, allow this many blocks to make payment)
Ideally all these parameters should fit within an 80 byte op_return, which I think they will do.
BTC is a special case. The protocol cannot escrow or send BTC. Therefore there must be some sort of logic; if you send X BTC to address Y before block Z then you get asset in return.
Having a lottery might attract some interest to Counterparty but it’s also a tricky subject. The way the CIP is laid out makes a lottery happen automatically as a function of the protocol. This could be taken to imply that Counterparty is sponsoring a lottery.
If users could use Counterparty functions to create their own lottery using the protocol I think this would be a good solution. A function could be made available similar to what is outlined in the CIP but require a user to initiate it and specify the details like number of participants, bet size, number of blocks, ect.