It has been 4 days and we've already got 332 BCH in pledges (44%) for our project to dramatically simplify the development for Bitcoin Cash network, which is awesome.
I wanted to tell a bit more about our project adding to what you can read on the homepage. 👈 If you haven't read that yet, please do.
Right now for donations we're using Flipstarter, which is pretty awesome, but it has a few limitations. First of all, the minimum pledge is about 1/100th of the total amount. If you want to collect 750 BCH that means that the minimum pledge is 7.5 BCH (which is a pretty big amount ~$2,000). The upper bound is also limited to the total amount, which means we can't collect more than we originally planned even if some nice people wanted to give us more (wink-wink!) This is a limit of the contract that is used in Flipstarter. The current implementation also requires a plugin for Electron Cash (which isn't hard to install, but still a deal breaker for some people) and also not super-easy copy-pasting (doable, but not super easy).
I thought about these limitations for some time and came up with this instead (see video below, it's not a mock-up, it is a working prototype... well, read futher):
Nice, huh? No plugins, no minimums, no maximums, cancel right from the site, also non-custodial. It uses the so-called "blind escrow" contracts on Bitcoin Cash (popularized by local.bitcoin.com) via CashScript, so that the arbiter (we, in this case) can only forward money to recipient (if the full amount is reached) or refund it to sender. Arbiter can't steal and doesn't even hold the money.
Why didn't we use it?
Because after about 30 runs we've got 2 runs where some money (a few cents) was completely stuck in a contract. I have no idea why.
This is exactly the reason why I want to do the mainnet project. I wan't blind escrow contracts be as simple as this:
const escrow = arbiter.contracts.blindEscrow.create( seller, manufacturer, [0.01, 'USD'] ); escrow.refund();
I want to get it developed, documented and automatically tested daily to ensure that it still works as expected (using TestNet satoshis, of course).
Ok, maybe a little bit harder than that, since you need to store that contract in a database for some time and show a QR code, but you get the idea.
A few days ago I was talking to someone and thought about kind of two-factor-like authentication protection for Bitcoin Cash. The idea was to have something like 2-of-2 or 2-of-3 multisignature wallet, where you would have your desktop with one key and a mobile phone with a simple HTML5 application as a second factor.
When you want to send a transaction you sign a transaction with your first key on the desktop and scan a QR code on your mobile to sign it using the second key.
Surely, something like that should be trivial to build (i.e. this HTML5 signing application). Unfortunately, looking through docs for most popular libraries I can't even find how to do multisig.
Ok, I found this. Here goes.. How to sign a multisig transaction in Bitcoin Cash (actually in BTG, but it should be pretty similar in Bitcoin Cash):
No, seriously, click it and scroll to the end!
Did you get it? Sending multisig is easy!
Did I make your eyes bleed? I'm sorry, I had to! I've been reading this stuff for 2 years. It's pretty close to what you have to go through as a Bitcoin Cash developer unless you do something really trivial.
Do we really expect new users to deal with this?
Why not this?
const wallet1 = new HDWallet(); const wallet2 = new HDWallet(); // create 2-of-2 wallet const publicKeys = [wallet1.masterPublicKey(), wallet2.masterPublicKey()]; const multisig = new MultisigWallet(2, 2, publicKeys); // first signature tx = wallet1.multisig.sign(['bitcoincash:qrecipient', 2, 'USD']) txString = tx.toString();
Seems a bit complicated? Ok, multisig is hard. But we don't need to make it any more complicated than this.
That's what you REALLY need to do. The library should do the rest!
Then your HTML5 signer application just needs to do this:
wallet2.transactionFromString(txString) .sign() .send();
Ok, the exact syntax/workflow might be a little different and a bit harder than this, for example you need to generate wallet2 on mobile and transfer public key to desktop somehow, but it's a good task for a developer to solve.
Maybe even solvable this way...
Imagine if you could simply send an encrypted message from Alice to the owner of the wallet
qqbob.. like this?
const alice = new HDWallet(); const msg = 'Hi, Bob! Private key for the treasure is 1Lk...'; // off it goes to the blockchain! (via encrypted OP_RETURN that only Bob can decrypt) await alice.encryptedMessages.send(['bitcoincash:qqbob...', msg]);
Then Bob could also do:
const bob = new HDWallet(); const messages = await bob.encryptedMessages.retrieve('last', 5); console.log(messages); // Hi, Bob! Private key...
How many applications could benefit from this?
Why not support sending to CashAccounts?
const recipient = new HDWallet(); const sender = new HDWallet(); await recipient.address(0).registerCashAddress('Jimmy'); // returns something like Jimmy#19270 await sender.cashaccount.send(['Jimmy#19270', 1, 'USD']);
Sent! Done! Nice, huh?
We can probably even support Vin Armani's cointext and allow sending to SMS numbers!
wallet.cointext.send(['+15553333333', 1, 'USD']);
There's really no reason why we can't do that (Electron Cash does it).
Frankly, we could even create(use?) something like tips.bitcoin.com (expiring tips) and send them right to user's email!
wallet.unnamedApp.send( ['email@example.com', 100, 'USD'], 'Here is something for your great work!' );
I would certainly like that! Think about the number of applications that could benefit from these integrations!
Even if this service doesn't exist yet, it's not that hard to build it.
By the way, expiring tips contract is also a nice candidate to add.
I would also like to remind that the plan is to build something that will be cross-language, so you'll be able to use it from C#, Java, PHP, Go, Ruby, or any other major language, server-side node.js and client-side in browser.
Also the plan calls for translation of docs to major languages, like Chinese, German, etc.. (or at least some parts of it) and recording of video tutorials (though these will probably be in English only).
There are more ideas for tutorials too. How about a tutorial on how to build a provably fair on-chain dice? I mean just to show some of the ideas in action!
...to be clear, these all are very ambitious plans. I don't know how many of them it will be possible to do well. I stress well, because we need to make sure that our features work and are stable. It won't make sense to add multisig if we can't even reliably send BCH. But I think we'll be able to manage a lot of this.
Having said that...
Should we do this? It really depends on you!