Problem of colored-coins/assets and other coins with a parent/child relationship of paying for fees with only the parent currency

Question

I've looked into building out my own coin, but it was best to just piggy back on top of an existing blockchain like how colored coins and counterparty is doing it. But when going on this route, I run into the problem of having to pay the fees of using the blockchain in the native currency.

Say if I was to create a game token based off of the bitcoin blockchain on top of counterparty, I still have to pay the fees in Bitcoin. Which my users will not have even if I distributed my game tokens to them. Now they will be stuck with the game token without being able to send it anywhere.

One solution was to monitor these addresses, and just fund them a small amount of btc just for them to pay for the fees. Is there a service out there that does this?

This issue is also apparent in other coins like ethereum and nxt. They give the ability to create your own child coins within their blockchain but you are stuck with the coin unless the holder has the native currency.

How are others solving this problem?

Answer 1

It's definitely a common problem found in a lot of those platforms that make it easy to create your own colored coin/token. Asking users to acquire the native token, such as Bitcoin with Counterparty and NXT with the Nxt blockchain, is usually not a good way to start off your relationship with that customer. Some people may be fine with it, but it greatly hinders mainstream use.

Ardor solves this problem with child chains that allow child chain creators to have the users on their child chain pay transaction fees in the child chain token. A bundler (could be the child chain creator) would collect these fees and pay the Ardor main chain for transaction processing. So, ARDR tokens would still be needed, but your users wouldn't need to touch it at all.

You would still need to re-distribute your acquired child chain tokens though, but the Asset Exchange that will be on Ardor will be a great way for you to sell them back to your users. If a USD child chain exists (kinda like Tether and USDT), then they could purchase those child chain tokens directly with those USD tokens, much like getting game tokens at the old arcade.

Answer 2

This is a tough one, and I think it's possible to find a solution to it, but it will depend on what your application is and the tradeoffs you're willing to accept.

Today:

Using Bitcoin, you could fund an account for your users, but it is far from ideal. I have done this before, I do not know of a service that offers it, and I don't recommend it. Pretty much you need to anticipate a user's usage and fund accounts before they take actions... If you don't pre-fund accounts they need to wait for transactions to confirm, because if they don't wait for the funding to confirm, then the funding transaction may be malleated and their signed transaction relying on it is invalidated. I guess this isn't the worst thing, but it makes for a very strange user experience where the user has to wait X block confirmations to sign off and actually initiate thier action.

You can ease this a bit by pre-funding an account, but you run into the problem of predicting usage, and if you over-fund your user you are effectively burning coins(in the worst case where they leave your app and never use it). One way to avoid burning is to give the user a 1-of-2 multisig account, where your user has a key, and you have a key to recover funds they don't spend in the future(maybe not acceptable in your use case for you to have a key to the user's account). If you under-fund, your user cannot take actions until you further fund them. On top of all that, pre-funding is messy because you don't know what transaction fees will be in the future.

In the future:

Some of the above problems are eased by the malleability fix of SegWit, assuming it gets activated. I think Covenants may also be worth looking into, but it is probably even further down the road.

What would really solve your problem is the planned account abstraction for Ethereum's Serenity(see "Abstraction and Accounts" section, or this EIP). Essentially the ability for zero fee transactions is introduced, where instead of the user initially paying the fee, the contract the transaction is sent to can pay the fee. This would then just require you to write and fund a contract that funds any transaction sent through it for transferring your tokens.

It is still early days for this stuff. I'm curious to see answers from other people/on other blockchains, but I imagine what you describe will continue to be a problem for 3rd party apps built on blockchains.