The Drivechain OP Code

“Smart Contracts”

Many people think that they want “smart contracts”.

Unfortunately, the phrase “smart contracts” is undefined. Mostly, in my opinion, this is because these people are too confused to know what they want.

I will clarify, on their behalf: the smart contracts we want are called Sidechains. Examples include: The Elements Project, as well as Hivemind.

Two Strategies for Bitcoin Smart Contracts

I will now draw a distinction between:

Here is the distinction visually:

This image is from a presentation I recently recorded, which argues that the Sidechain Method is right and the Ethereum method is wrong.

Getting There From Here

Sidechains need a lot of things. The full code library might be a lot of work.

The Pull Request

The Bitcoin soft fork, in contrast, is very simple. Presented compactly, it would require the following:

1. Generate a "MinerDB"...
	...which scans all coinbase transactions for 'inserted data'...
	...and discriminates the signals in that data as [1] "uninterpretable / something else", [2] "adding a sidechain", [3] "proposing a withdrawal", and [4] "upvoting or downvoting a withdrawal"...
	...and stores/accumulates that data in a database.

2. A new OP Code "OP_CheckWorkScoreVerify"...
	...which freezes coins, such that they can only be moved if...
	...they are spent by a transaction where...
	...the tx-ID matches a Withdrawal Entry in the MinerDB...
 	...and the Withdrawal Entry has achieved the appropriate 'miner score' (see below).

The MinerDB of part (1) checks “Work Score” using the following rules:

Per Sidechain:

A sidechain is added by adding Coinbase data of a certain format. The minimal requirements resemble the following function:

AddSidechain(PrivateKey = 5JQrzT..., WaitingPeriod = 2016, VotingPeriod = 1000, ReqScore = 200).

This is an example of MinerDB item [2] above. I’ll use these specific values throughout the example below.

Per Withdrawal:

1. Withdrawals proposed from the sidechain must meet a few requirements:
   • Each must be the txid of a correctly-formatted Bitcoin transaction.
   • Each must only select inputs ‘from’ the correct sidechain address: GetBitcoinAddress(GetPublicKey(5JQrzT…)).
   • The transaction must be valid (no double-spending, etc).
2. These withdrawals must have a score of zero for 2016 blocks. After this, miners are allowed to increment the score* upwards or downwards by one. This continues, one incriment per block, for 1000 blocks.
3. After a Withdrawl has endured both the 2016 waiting period and the 1000 voting period (3016 blocks total), the database entry would be labeled “ended” or “concluded”, and its score would stop changing.
4. If the statment (required score <= the final score) were TRUE, the transaction could be included in a Bitcoin block.

*Upvote/downvote messages would ideally be very small – details in step 5 here.

Help Wanted

I think that I am too busy to code the OP code myself. Moreover, my relative productivity is not maximized at “write Bitcoin C++ code”. Basic econ says I should cough up some $$$, instead of my time.

Ideally, I would attract someone with commit access to Bitcoin Core, as they -presumably- are most intimately familiar with the quality standards and formatting norms.

I think that $1000 / day is a fair rate, considering the rarity of such individuals. That’s $125/hour ($260K annually).

Moreover, I feel that it would take, at most, 3 days (16 hours). To account for the planning fallacy, we’ll make it 4 days.

Official Terms

To be clear, you get $4000 if one of these conditions are met:

• You code a Drivechain OP_CheckWorkScoreVerify pull request which makes it into Bitcoin Core.
• You code a Drivechain OP_CheckWorkScoreVerity pull request (which is not immediately the subject of ridicule for being invalid, poorly formatted, difficult to understand, etc), but the pull request is rejected because the Drivechain proposal is itself rejected for any reason. (If Drivechain is substantially modified, this might count as a “rejection” of the original.)

These conditions are necessary, because I have a limited ability / availability to review coded submissions. Furthermore, my review would be redundant / irrelevant – what matters is Bitcoin Core process.

Suggested Schedule

My guess is that the first day would be spent groking the concept. The second day would probably be spent experimenting/meditating on the appropriate way to build the MinerDB. The code itself could probably be written in a 5 hour sprint, with 3 hours for breaks. Then a whole fourth day to cover The Unforseen.

Keep in mind, this is only “the Bitcoin piece”. Sidechains require more (for example, the sidechain itself, whatever its features, must be able to scan the mainchain for deposit transactions, and it must be able to form and collate withdrawal transactions).

The Debate – Is Drivechain Good for Bitcoin?

Nothing should make it into Bitcoin without discussion!

Here I will now publish two presentations:

• Sidechain Privatization (maximizing smart contract value, handling net-negative in-fighting among smart contracts)
• The Potentially Detrimental Effects of Sidechains, And What To Do About Them (forthcoming)

For details about Drivechain itself, please consult my lengthy exposition of the proposal.