[Bitcoin-ml] business considerations for the adoption of Bitcoin Cash

[Ryan X. Charles]

Dear Bitcoin Community,

At Yours, our mission is to get creators and curators paid for good content and to improve the quality of content on the internet for consumers. In order to make the economics of our system work, we built an L2 for bitcoin to enable p2p micropayments. We made news recently when we were forced to switch from bitcoin to litecoin due to the fee situation on bitcoin. Even with payment channels, fees are so high on bitcoin right now that they are prohibitively expensive for the acquisition of new users (and are likely to get worse).

We are very optimistic about Bitcoin Cash and are exploring the possibility of supporting it as an alternative to litecoin.

I have written an article describing the relevant issues with Bitcoin Cash we are researching from the point of view of our business:

https://www.yours.org/content/80d01701980a5490bd1984f589b82c2bf92b95e045634b6b35bf87f3c48b3d90 <https://www.yours.org/content/80d01701980a5490bd1984f589b82c2bf92b95e045634b6b35bf87f3c48b3d90>

I would like to add one additional point that I forgot to list in the article: It is extremely valuable for us if the dust limit were less than 1 cent, and ideally zero. It is OK if the fees on a transaction must be higher in order to broadcast a 1 cent output.

The reason for this is that when you use payment channels for micropayments, you might want to close the channel after sending only 1 cent. On litecoin, this is currently quite cumbersome as their dust is about 5 cents, and as such with our current system all outputs must be greater than 5 cents or you cannot close the channel.

To our understanding, dust limits on Bitcoin Cash are only .00001 per kb, which is about 0.15 cents (or 0.0015 USD) for an output in a 500 byte tx at current prices. That is acceptable to us and would relieve us the burden for finding a workaround for small outputs as compared to litecoin.

Here are the other issues with Bitcoin Cash we are monitoring as we iterate towards our beta and consider a switch:

- Mining Support: It is important that Bitcoin Cash has mining support that continues past the August 15th deadline set by Via BTC. We need to make sure the chain doesn't ground to a halt.

- Mining Decentralization: Currently, Via BTC is the primary miner behind Bitcoin Cash. We would like to see a diversity of miners support Bitcoin Cash so that the chain is not subject to centralization concerns.

- Security: Since Bitcoin Cash has the same proof-of-work function as Bitcoin, the chain is subject to fluctuations in mining support due to changing profitability and the possibility of mining attacks from the miners on the other chain. We need to see sufficient security to support our use-case, which would ideally occur by improved mining power.

- Cashing In: We were able to switch to Litecoin because our users can buy it with a credit card via Coinbase and other services. We need to see credit card onboarding for Bitcoin Cash - either in production, or commitments from businesses to support that.

- Cashing Out: Can users easily cash out to fiat currency? Fortunately, this already works as well for our users as Litecoin and Bitcoin by selling the currency on an exchange. Even better would be to see offboarding widgets to make it as easy as possible.

- Spending: Even better than cashing out is spending Bitcoin Cash to purchase things directly. If services like BitPay support Bitcoin Cash, that would be a fantastic offboarding option for our users. Fortunately we have seen some good signs in this direction, like support from Living Room of Satoshi to pay bills in Australia with Bitcoin Cash.

- Wallets: Our users need to have options to manage the Bitcoin Cash they withdraw from Yours. Fortunately, there is already widespread support for Bitcoin Cash with hardware wallets like Ledger and Trezor, and there is a great deal of committed support from other wallets like Jaxx and Breadwallet.

- Long-Term Scaling Roadmap: Although the thesis behind Bitcoin Cash is to continuously raise the block size as needed, we would like to see a more thorough roadmap with broad support from the Bitcoin Cash community. The worst thing would be for Bitcoin Cash to undergo the same block size stalemate that Bitcoin is currently facing.

- Software Infrastructure: Yours currently uses litecore (based on bitcore) and we have long planned a migration to lcoin (based on bcoin). It would be much easier for us to migrate if these tools and others add support for Bitcoin Cash.

- Multiple Implementations: We would like to avoid the developer centralization of Bitcoin to defer the possibility of continued inability to iterate the protocol, so seeing multiple implementations of Bitcoin Cash that are used in the wild is very important. Fortunately, this is already the case with support from Bitcoin Unlimited and Bitcoin Classic.

- Standards Body: The best way to prevent protocol stalemates is with a formal governance structure to direct protocol standards like IEEE or W3. This standards body would have representatives from miners, businesses, and users and would have mechanisms to make decisions even in the face of controversial issues. This ensures protocol changes (or non-changes) have a clear process to resolve disputes. This would most likely involve clear standards for hard forks (and splits) in the presence of widespread disagreement.

- Uncensored Communication: It would be great to have an uncensored communications platform for discussing issues in the Bitcoin Cash community. Maybe this could be Yours :)

- Happiness and Optimism: One of the biggest problems with Bitcoin is that the communications have devolved into vitriol and trolling. We would love to see happiness and optimism instead of negativity. Fortunately, we see this in abundance already in the Bitcoin Cash community :)

Ryan X. Charles
Cofounder & CEO of Yours
https://www.yours.org



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-ml/attachments/20170810/28acd0e0/attachment-0001.html>