There are a lot of great content creators on the internet, but most of them aren’t earning any money. Yours is a a way to solve this problem. By thoughtfully incentivizing payments to creators, we give people a reason to pay for content on the internet. Our app depends on an integrated bitcoin wallet, and this week we have made important progress enabling small payments with low fees: we have broadcast our first micropayment on bitcoin testnet.
In order to understand the significance of this test, it helps to understand an outline of the Yours tech stack. Yours Core is the code that runs both on a server and in the client. It contains a notion of users, posts, messages, and the bitcoin wallet. As of our April tech demo, we had a normal bitcoin wallet integrated into our product. However, it was clear that at 5 cents per bitcoin transaction, the fees were to high, so we began working on micropayments technology to lower the fees to nearly zero. The fees of a transaction on the blockchain are now an average of 14 cents per transaction.
As of last month, we had finished a proof-of-concept of a routed micropayment. That user-to-user micropayment occurred inside a test suite, and did not actually broadcast any transactions to the blockchain. The difference this time is we have integrated our micropayments technology into Yours Core sufficiently far that broadcasting the transactions became possible. The transactions broadcast successfully.
It is instructive to investigate the transactions we broadcast. The first two, the funding transaction and commitment transaction, look very conventional. The funding transaction uses the Yours Core bitcoin wallet to make a payment to a multisig address. The multisig address is mutually controlled by two parties (who we call Alice and Bob). Alice is the one who funds the channel, i.e. she sends bitcoin to the multisig address. The commitment transaction is after Alice makes a tiny payment to Bob. Alice then closes the channel by broadcasting the commitment transaction. Normally, Alice would make many transactions to Bob before closing the channel. But in our test scenario, we want her to close it immediately just to be sure the transactions are working.
The final transaction, or what we call the spending transaction, is the transaction that contains the most sophisticated scripts. Inside its input scripts are the redeem scripts that have all of the logic involving HTLC secrets and revocation secrets. Furthermore, there are some interesting properties set on the spending transaction. It has a version of 2, which is necessary to make use of relative locktime. It also has the sequence number of each input set to something other than 0xffffffff. For testing purposes, we set the sequence number to 0, indicating that the spending transaction can be broadcast right after the commitment transaction. If this were not a test, we would have set the sequence number to 144, which would indicate that the spending transaction could only be broadcast 144 blocks after the commitment transaction (about one day).
The first redeem script
This script locks up the first output of the commitment transaction so that Bob can spend it if he has the HTLC secret. If Bob does not have the HTLC secret, Alice can spend it after one CSV delay unit. Normally the CSV delay would be 144 blocks, but it is zero blocks here to make testing easier. Because the CSV delay is set to zero, Alice is able to spend this output right away. Normally, Bob would spend that output, and Alice would then not be able to spend the output.
The second redeem script
This script sends the remainder of the funded channel back to Alice after one CSV delay unit. Again, the CSV delay is set to zero for testing purposes so Alice can immediately spend that output. Normally, Alice would have to wait about a day.
In summary, we have broadcast the first Yours micropayment on the testnet bitcoin blockchain. This is an important milestone for integrating the Yours micropayments technology into Yours Core. The next steps for us will be to integrate the Yours messaging system into the micropayments wallet so that the micropayments can occur with a few simple commands. Then we will perform further integration tests. Once we are sure the messaging system is working correctly, we will create tests that use realistic CSV delays of 144 blocks. That will be the final micropayments test to know the system is working. We will then proceed to integrate the micropayments technology into the Yours UI. That will be straightforward, as sending micropayments with Yours Core only involves simple actions and will not require significant changes to the Yours UI. After micropayments are integrated into the UI, we can sketch out a realistic launch plan.