The “exclusive OR” operation, XOR, is an operation between two binary bits that returns 1 if and only if one of the input bits is equal to 1, otherwise, the operation returns 0. The operation is denoted by the symbol ⨁. The operation is summed up by the following truth table:

Thus, given a secret key S and message M of equal byte lengths, we can see the result M’ given the XOR operation between S and M:

Because the XOR operation is reversible, we can calculate M given M’ and S:

Thus we can see how S acts as an encryption/decryption key. The process of utilizing the secret key S in this manner is known as a One-Time Pad. By utilizing the public nature of the blockchain, the method outlined in the WP removes the primary risk of transmitting cyphertext over public networks — the malleability of binary strings in the case of attack of an intercepting party.

Alice and Bob generate a shared secret as described in WP042, but the initial derived key is instead used as the One-Time Pad instead of as use as a private key. The One-Time Pad combined with message M enables Alice and Bob to validate their shared secret given message M where M’ is published on the blockchain:

The use of XOR as a cipher can be utilized in various ways in Bitcoin transactions, but we will focus on one specific use case inside Bitcoin Script where the ciphertext is XOR’ed inside the locking script of a transaction:

OP_DUP OP_HASH256 ⟨ℎ(𝑆1 )⟩ OP_EQUALVERIFY ⟨ℎ(𝑃𝐵)⨁𝑆1⟩ OP_XOR OP_SWAP OP_DUP OP_HASH256 OP_ROT OP_EQUALVERIFY OP_CHECKSIG

And the input script is

<SigP_B> <P_B> <S_1>

The locking script first ensures that the correct shared secret is used by checking it against a hash puzzle. The script then uses the secret to decrypt <h(P_B)> and then checks the signature as in a standard transaction.

This type of transaction has a use case where Alice wants to create a transaction redeemable by Bob or a third party, Charlie. Some additional redemption condition for Charlie can be included in the identical way as it was for Bob alongside OP_OR, and the identities of Bob and Charlie are completely hidden until the transaction is redeemed. When it is redeemed, only the identity of the one who redeems the transaction is exposed. Thus we have created a mask where multiple parties can compete to satisfy a condition, but only the winner’s identity is exposed.

The main benefit of using XOR as an encryption/decryption tool is that it allows for secure and rapid decryption even on low processing power devices. This is beneficial for smart cards and IoT devices, for example.

You can play with these types of transactions using this golang repo as a starting point. You can see a transaction onchain of the script type above here.

Key Derivation Schemes

While Bitcoin has standardized key derivation around the BIP32 standard, there are many downsides to the approach. A future article will talk about these downsides, but the important thing to note is that BIP32 is not the only way to have hierarchically derived keys . There are new key derivation schemes that are being created for BSV, and one such scheme involves utilizing a hash chain and XOR. Note in this example that this scheme is not being used necessarily for coin storage, but instead used for decryption of messages. However, it points to a wide variety of possibilities in defining new key derivation schemes.

Utilizing our handy Secret Value Distribution technique, two parties, Alice and Bob, will calculate a shared secret S_1 where it is the x coordinate of the shared secret generated:

Remember, since S_1 is a 256 bit number, it can be utilized as a private key from which further keys can be derived. We will derive n keys such that:

And keys 2 and 3:

And so forth until:

This set of keys is generated using only the initial shared secret and only a single initial elliptic curve point calculation. These keys can then be used to encode the n messages, starting with S_n:

As we can see, the initial shared secret is never used on its own to encrypt a message. Thus, a single compromised message will not destroy the security of all the encrypted messages. The use of a hash chain in the key calculations prevents reversal of the calculation. This property means also that keys can safely be reused.

We can imagine, for instance, a use case whereby a large block of data is broken up into n chunks and streamed to a customer. We can structure the communication of the data such that n keys are securely created between the server and client to allow continuous decryption of content as it is streamed. The server can revoke access as needed by simply stopping the streaming of the content. This would enable applications like Streamanity to enable pay as you go content.

Future articles will expand on these techniques for the purpose of creating a “Blockchain Message Authentication Code” (BMAC), as well as further key derivation schemes that can be used.

See the below gist for two example functions for deriving these keys from a shared secret that has been imported as a bec.PrivateKey:

import (
    "github.com/libsv/go-bk/bec"
    "github.com/libsv/go-bk/crypto"
)

func DeriveNKeysFromMaster(n int, masterSecretKey *bec.PrivateKey) ([]*bec.PrivateKey) { 
    matrix := make([]*bec.PrivateKey, n)  
    secretKey := masterSecretKey  
    for i := 0; i < n; i++ {  
        secretKey, _ := DeriveNextKey(masterSecretKey, secretKey)     
        matrix = append(matrix, secretKey) 
    }
    return matrix
} 

func DeriveNextKey(masterKey, secretKey *bec.PrivateKey) (*bec.PrivateKey) {
    curve := bec.S256() 
    secretKeyBytes := secretKey.Serialise() 
    masterKeyBytes := masterKey.Serialise()
    secretHash := crypto.Sha256(secretKeyBytes)
    newKeyBytes := make([]byte, len(masterKeyBytes)) 
    for i := range secretKeyBytes {  
        newKeyBytes[i] = masterKeyBytes[i] ^ secretHash[i] 
    } 
    key, _ := bec.PrivKeyFromBytes(curve, newKeyBytes)  
    return key 
}

Secret Value Distribution — the title for nChain’s “White Paper 42” — is a building block upon which many of nChain’s other public inventions are based on. In this article we will cover the technique and publish a simple golang gist using the go-bk library to allow you to play with it. Credit goes to nChain for the white paper — this article will simply summarize the content of the paper for a general audience.

The paper describes a method in which Alice and Bob can exchange information to generate a shared secret that acts as a master key from which an unbounded number of deterministic keys can be derived. The technique is an improved way of performing a Diffie-Hellman Key Exchange. A Diffie-Hellman Key Exchange is an innovative process by which two participants can exchange credentials to create a common shared secret between both participants.

The shared secret created in the WP42 method is an improvement upon the DH Key Exchange because of the ability to quickly derive new keys from the initial shared secret that is generated, and because the public nature of the blockchain ensures near-perfect security when generating the secret.

To generate the shared secret, each party agrees on a standard Elliptic Curve Cryptography System, such as secp256k1 as used in Bitcoin, to ensure a common generator point, G, is used. Alice then creates a master private key S_AM that is kept secret by herself. The corresponding public key P_AM is shared with Bob. Bob does the same, generating master private key S_BM and keeping it secret, and sharing the corresponding public key P_BM with Alice.

Alice then creates a message M and uses a standard algorithm (such as SHA256) to create a hash of the message resulting in a 256-bit integer. Alice then generates a new private key S_A1 where:

Where the addition that is performed is scalar addition between the two integers.

Since this initial private key is not a random number but is derived from Alice’s master key, the corresponding public key P_A1 is derivable from her master public key:

Thus, although Alice’s new private key is not known by Bob, he can derive her new public key as long as the message is shared.

Alice then signs the message M and sends this to Bob:

Since Bob now has a signature corresponding with Alice’s derived private key and the message, he can validate the signature against the calculated P_A1. Further checks can be performed against the message itself if required as well.

Now that Alice and Bob have each other’s derived public keys, they can each independently calculate the shared secret K as follows:

Because this shared secret is derived from the scalar multiplication of the two values, it is in the form of an elliptic curve point:

This can be converted into any standard key format using standard publicly known operations as agreed by both parties. Since x_k is a 256-bit integer, this alone can be used as a derived Bitcoin private key.

Note that once the shared secret K is calculated, Alice and Bob’s derived private keys can be discarded and never have to be stored. The shared secret can be discarded after a one time use or can be used as a master key from which further derived keys can be generated. We will cover those techniques in future articles.

The code below assumes Alice’s Private Key was derived per the steps taken above, and Bob’s Public Key was derived the same way.

// per WP042, generates a shared secret using Alice's private key and Bob's public key 
// shared secret can be x or y

import "github.com/libsv/go-bk/bec"

func SharedSecret(privKeyA *bec.PrivateKey, pubKeyB *bec.PublicKey) ([]byte, []byte) { 
    curve := bec.S256() 
    x, y := curve.ScalarMult(pubKeyB.X, pubKeyB.Y, privKeyA.D.Bytes())
    return x.Bytes(), y.Bytes()
}

A hash chain is a method whereby a successive application of a hash function can be used to produce many one-time keys from a single key or password. Traditional applications of a hash chain utilize the technique so that a client can act in a secure manner with a server, and the server needs only to keep the last used key by the client to validate the next used key. We will implement the technique using the Bitcoin blockchain as the server, and any token issuer as the client.

For this implementation we require that each token issued is related to the token before it through the use of a hash function:

To generate the token, the issuer (Alice) and the blockchain (Miners) agree on a number n of events requiring a token to access. This can be done in Script when issuing the first token. Alice generates a 256-bit number t_0. We can do this utilizing a hash function on a piece of data or utilizing a random number. This token (t_0) will be the last used token. Alice stores this token and no other value.

This value is hashed n times to generate t_n:

We now have created an access chain of tokens that satisfy:

And so forth until:

The token t_n is sent to the blockchain in an issuance transaction and acts solely for verification purposes. Note that any miner or other actor listening to the blockchain cannot calculate any other tokens from this value.

Alice can now calculate the value of her first token:

And activate it by creating a transaction that contains the token. In a traditional sense, the server would now validate that Alice has activated the correct token by checking that t_n = H(T_{n-1}). If it has, the server now stores t_{n-1} and discards t_n. This process can be repeated iteratively until t_0 is revealed.

Using Bitcoin Script, we can use the miners as the validators of the hash chain by structuring our transaction whereby the token is revealed in the unlocking script of the transaction to satisfy a condition in the input’s locking script.

I will outline an example whereby n = 5 and t_0 = 4bc1e4b940e46fe42bfe00f2be03d5a41c0f312478d2a31e32d1864c75ce0e2d

Using SHA256 as our hashing function, Alice generates t_n = 4036ec7b619e9c1d8abd72dc20a884da46cd798d0b4b2c2ee9ad74650d673a67

As such, she structures a transaction that includes in the locking script:

OP_SHA256 4036ec7b619e9c1d8abd72dc20a884da46cd798d0b4b2c2ee9ad74650d673a67

OP_EQUALVERIFY

Her first token t_{n-1} is then calculated= 9dff79932e69a4c3857df7796e44bde0d46cba94c239b46582e3f36cb7ef6f7d

Alice now publishes a new transaction that includes this value in the unlocking script. In order for this transaction to be accepted by the mining network, the script must evaluate to true. This replaces our server in the traditional architecture with the blockchain itself. We can also include further logic in our script to enforce that only n tokens can be spent.

To demonstrate this onchain we’ve created the above access chain in the following transaction. The input defines the access chain with t_n, and the output is the first spend of the first token t_{n-1}. You can follow index 0 in the outputs to see the full chain of spends for the 5 tokens.

Remember — in the previous article we outlined how we can enforce a common script template between inputs and outputs by hashing our script template. Since the token (t_{n-m}), where m = the number of activated tokens, is data of a fixed size that can be stripped from our script template, we can combine the technique used in that article to now enforce a structure as each token is activated.

There also exist techniques to transfer tokens to a new owner, such that Alice can sell her remaining tokens t_{n-m-1} to Charlie. This can be done securely using a technique that will be covered in a future article.

Combining Hash Chain Tokens with Public Keys

We can also link tokens to public keys such that the tokens are embedded in P2PKH transactions and a validator needs only to check the public key that is exposed in the locking script.

Looking at the chain of transactions we created above, the issuing transaction is made with an input from the key associated with address 1KJ4nEze9Z3ntVHLLoZY1zqEqhvZpcXpfF. The tokens are then sent back and forth between that address and the key associated with 1B31pjTLB7XhGUgdoGiA4xdALxNwfUuKkY.

There exists a way in which we can create these tokens offline and generate deterministic keys from the tokens themselves. Recall that a public key P_0 is the private key S_0 multiplied by G, the generating point of an elliptic curve.

Alice can share P_0 with Bob or another validator. Using her first token, t_{n-1}, Alice can calculate P_1:

Since only Alice knows t_{n-1}, only she can create this public key. P_1 can now be provably linked with the first token in Alice’s access chain. Alice can initiate a transaction to the address associated with P_1 and send t_{n-1} to Bob. Bob can now verify that the token t_{n-1} has been activated by checking that Alice made a transaction to P_1.

Using the same token chain above, we can calculate for P_0 = 0264863783b52d6fce816fb6cbd8f2917344341b14dc93269f855e5ea5c777fdf1, P_1 = 030d084486d4e7d54594f5400102cc9a106555061e296678978b61c44204276a30.

We can calculate more public keys for values up to P_5.

For this issuing transaction and the subsequent spends at outpoint 0, we used the same token access chain and the same keypairs as the transactions outlined above. This allows us to use the hash chain technique with regular P2PKH transactions.

The possibilities from here grow endlessly…

Play with hash chains and recreate the example transactions above using this golang library.

1. Efficiently retrieve a subset of transactions from the UTXO set and/or the blockchain
2. Enforce a specific transaction structure across inputs/outputs

Credit for this filtering technique goes to Dr. Craig Wright who outlined some of these things in the following video.

Up until this point the injection of data protocols into Bitcoin have largely been centered around the use of OP_FALSE OP_RETURN outputs. Protocols like MAP, B://, and even the Metanet protocol itself define data structures that can be attached after the use of OP_RETURN in transactions to allow applications to emerge that consume and interpret the data in useful ways. When OP_RETURN was made unbounded on BSV, we saw a Cambrian explosion of data protocols and applications emerge that made use of this functionality. This began the emergence of overlay networks on Bitcoin where layers on top of Bitcoin could begin interpreting a common dataset.

The use of OP_RETURN for data brings three downsides:

1. Anything in OP_RETURN can be pruned by nodes on the network at any time
2. The data in OP_RETURN cannot be consumed by Bitcoin Script itself, limiting the ability to perform validation on the data or otherwise utilize Script to interact with the data. This means we cannot enforce restrictions on who can spend an output based on the data inserted into the transaction.
3. Data structures can be interrupted by attackers, where junk that follows a certain data protocol can be inserted in OP_RETURN to confuse the overlay nodes

The purposes of this article will focus on (2) and (3). To create an overlay network in Bitcoin it is important that there is some mechanism to validate that new transactions consumed by the overlay network are valid. There should also be an easy way for new nodes entering the overlay network to fetch all of the data relevant to the overlay network without having to sort through junk data. The solution was identified years ago by Satoshi Nakamoto himself in 2010 when describing Bitcoin Script:

The script is actually a predicate. It’s just an equation that evaluates to true or false. Predicate is a long and unfamiliar word so I called it script.

The receiver of a payment does a template match on the script. Currently, receivers only accept two templates: direct payment and bitcoin address. Future versions can add templates for more transaction types and nodes running that version or higher will be able to receive them. All versions of nodes in the network can verify and process any new transactions into blocks, even though they may not know how to read them.

The design supports a tremendous variety of possible transaction types that I designed years ago. Escrow transactions, bonded contracts, third party arbitration, multi-party signature, etc.

Currently there is no distinction between transaction templates across the network aside from a basic boolean between standard and nonstandard. As Bitcoin SV continues to utilize Bitcoin Script for more advanced transactions, this entire concept needs to move towards identifying templates.

To create overlay networks we propose a filtering mechanism using Bitcoin Script that loosely follows the following format:

Unlocking Script: <unlocking script for transaction template><preimage of transaction>

Locking Script: <Hash of Transaction Template> <Filter Mechanism> <OP_PUSH_TX> <Transaction Template>

To help the reader understand the concept we will outline a filtering mechanism for P2PKH transactions, the most common transaction template in use across the network. We will utilize the mechanism to enforce across a chain of transactions that they must be a P2PKH template.

For every P2PKH transaction, the locking script follows a common format:

OP_DUP OP_HASH160 <public key hash> OP_EQUALVERIFY OP_CHECKSIG

Where the public key hash is 20 bytes of data that varies for each transaction. Thus, our transaction template — the transaction format stripped of data — is the following:

OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG

To enforce that all transactions follow this format, we will take a SHA1 hash of this data which turns out to be 464ac09fd447f94b321b0c351ae652ad39bb9c5f. We will insert this hash at the beginning of our locking script and use it in our filter check. While this hash could be of any type, SHA1 has a few distinct advantages in the creation of HMACs and because of the low compute required.

We utilize the OP_PUSH_TX technique to push the current transaction to the stack to validate that the filter checking is being performed on the current transaction. The OP_PUSH_TX technique requires us to include the preimage of the transaction in the unlocking script of a transaction. Since the previous transaction’s locking script is included in the preimage of a transaction, we can simultaneously use the preimage to enforce that every UTXO used as an input must be of the same template.

Our filter is going to be different for every transaction template we use, but it will follow a similar format:

<Get Locking Script From Preimage> <Strip Data From Template> OP_SHA1 OP_EQUALVERIFY

Stripping the data from our P2PKH template is quite simple:

OP_2 OP_SPLIT OP_1 OP_SPLIT OP_SWAP OP_SPLIT OP_NIP OP_CAT

You can use the link above to see how our filter strips the public key hash from the locking script. We can validate by appending OP_SHA1 to the script that the script template properly hashes to 464ac09fd447f94b321b0c351ae652ad39bb9c5f.

Note that in practice our hash won’t actually be this value, because our locking script is going to include the opcodes above as well as the OP_PUSH_TX script, so we will want to include those opcodes to complete our transaction template before taking our hash to compare with. As an example of bringing all of this together, see this transaction on the blockchain. Any extensions to this chain of transactions will require the same transaction template. You can build your own transaction using this golang repository.

Remember, our goal is to enforce a common transaction template across inputs and outputs:

Because the preimage of a transaction only contains a hash of the transaction outputs, every transaction can only validate that the input for the transaction contains the proper hash. Because the checking of the hash is done in Script using the OP_SHA1 opcode, it means that when syncing data for our overlay from the blockchain we can trust that every transaction in a block utilizing that hash and script template has been validated by the miners. Since Script is a predicate, we can be certain that any failed script would not be accepted by the mining network. This means that attackers can only succeed in confusing our overlay network for any outputs that have not been spent yet.

As new transactions are received by the overlay node, a simple check for the hash at the beginning of the script can be employed. As a second layer of security for unspent transactions, any transactions found can then be further checked by performing a SHA1 hash against the template (thus our use of a low-compute hashing algorithm such as SHA1). For security concerns regarding any particular hashing algorithms, extraneous hashing can be performed or other algorithms can be used.

This is the simplest filtering mechanism that can be used. Masking and other techniques can enable vastly more complicated enforcement of transaction templates and data insertion. We will outline those techniques in future articles.

Today we are formally launching Britevue, our online review platform that is built to properly align incentives in the online review space. Today there exists virtually no good incentive to leave reviews for the businesses that we patronize. Negative online reviews are largely driven by vengeance, and positive online reviews are largely driven by altruism and a desire to go the extra mile for a business owner. In today’s world reviews are king — businesses with a positive ranking on online review platforms have a level of marketing that can’t be bought through any marketing agency. As a result, there exists many problems in the review space today — fake reviews, third party companies monetizing reviewers hard work, and reviewers getting largely no monetary benefit for taking time out of their day to write honest reviews.

Britevue, formerly known as True Reviews, is solving all of these problems. Today with the launch of britevue.com we are targeting online reviewers with a better platform than traditional sites. Britevue has been rebuilt from the ground up using the Metanet protocol and in partnership with HandCash.

On Britevue, reviewers own their intellectual property. We want you to spend as much time as possible to give an honest and in depth review of businesses you patronize, but time is money! Every interaction with your reviews on Britevue earns you money, and power users have the option of putting their content behind paywalls. Travel influencers and the like now have a way of generating revenue streams from their content in an easily searchable fashion.

Britevue looks and feels like a traditional review site, but the technology underneath is cutting-edge. By utilizing blockchain technology and fast and frictionless digital cash Britevue allows for micropayments to be sent and received by users.

Sign up on Britevue today, and once you link your Handcash wallet to your account you can fill out a quick survey about your hometown and earn some money to get started! We are flipping the traditional structure upside down — Britevue is paying you for your data.

If you are a business owner that wants to pilot our business portal, please reach out to us at info@britevue.com to be one of the first to utilize our business dashboard.

Contact us at support@britevue.com for any questions or ideas about Britevue. This is just our first necessary step in utilizing the BitcoinSV blockchain to change the online review world.

Our talk at Coingeek London 2020 was all about tokens, and how we can re-envision what a token is through the power of Bitcoin. We are doing this with True Reviews and Veritas, but we will illuminate why tokens are more complicated than they appear on the surface.

There are a number of tokenization platforms available and the one that we really like today is Run. We will show you how drop dead simple it is to issue a pointless ICO token on BSV today:

Step 1: Download Run.

Step 2: Download NodeJS.

Step 3: Open a new folder, put run.node.min.js in the current directory and run npm install bsv

Step 4: Write 5 lines of code:

const Run = require(‘./run.node.min’)

// Run on mockchain for development
const run = new Run({ network: ‘mock’ })

// Create my token class
class ICOCoin extends Token { }

// Set some arbitrary fields on the token
ICOCoin.tokenIssuer = ‘Scam Artist’

// Mint Tokens
const mintedCoins = new ICOCoin(100)

// Log the token object
console.log(mintedCoins)

And just like we have minted ICOCoin! Minting tokens on BSV is simple.

But now what? Let’s try and use these tokens. Let’s assume we created a token that actually has some utility, like a concert ticket.

const Run = require(‘./run.node.min’)

// Run on mainnet setting appropriate keys
const run = new Run({ network: ‘main’, owner: myOwner, purse: myPurse})

// Create my token class
class ConcertTicket extends Token { }

// Set some arbitrary fields on the token
ConcertTicket.issuer = ‘Murray Distributed Technologies’
ConcertTicket.venue = 'Royal Albert Hall'
ConcertTicket.artist = 'Bob Dylan'

// Mint Tokens
const newTickets = new ConcertTicket(100)

// Log the token object
console.log(newTickets)

Great! We have 100 concert tickets. So I guess we are now a concert ticket company. So let’s say I’ve created a way to sell these tickets to consumers, and Alice buys one ticket. We need to transfer ownership of one ticket from our company to Alice. Let’s send the ticket to Alice’s Bitcoin wallet. She gives us a public key (pubKey) to initiate the transfer:

//Send Ticket to Alice
const sendTicket = ConcertTicket.send(pubKey, 1)

Great! Alice’s Bitcoin wallet now has the ticket.

It’s now the night of the show, and Alice wants to redeem her ticket for entry into the concert.

Now what do we do?

There are probably 100 different ways we can solve this problem, but they all require a combination of a few things:

1. A direct wallet integration for receiving and sending tokens
2. A business that issues and manages these concert tickets
3. An ecosystem of participants using the services

The problem on BSV isn’t how to issue tokens. It is creating the businesses and services that get real tokens into the hands of consumers. Creating the next ICO on BSV is possible today with a web wallet and a few lines of code, but what utility has an ICO brought to the world over the last 5 years?

Tokens are a tool that enable new business models and use-cases, and we can’t wait for them to be used across the BSV ecosystem.

How to Mint Tokens on BSV was originally published in Rustbelt Innovators on Medium, where people are continuing the conversation by highlighting and responding to this story.

We recently took the time to lay out a factual timeline of Craig Wright’s involvement with Bitcoin using publicly available information. While the list is not exhaustive, the bulk of information comes starting in 2014 as everything prior to that date has been scrubbed from the internet. When digging in to try and fill in the gaps between 2009–2013, you find a long and bitter battle between Wright and the Australian Tax Office. The BBC first asked Wright about his dealings with the ATO in his famous interview around May 2016. Here is his response:

I have companies that are under audit. The reason for that is that we have told the ATO everything. We have told them about the tax issues and implications. We actually put in everything with the auditors… We had an internal audit and we supplied that to the tax office so that we could pay the correct amount of tax. And because no one really understands Bitcoin very well, and no one understands the timing or anything like that, then it’s still an ongoing matter.

While many news organizations have used Wright’s dealings with the ATO to make accusations of “fraud”, an examination of the facts and evidence paints a different story. We have obtained private documents that contradict the prevailing narratives about Wright’s history and dealings with the Australian Tax Office:

1. Wright‘s saga with the ATO dates back as early as the 2009 tax season.
2. Wright was working with the Australian Tax Office to properly report tax on his Bitcoin businesses.
3. Questions are raised about the Australian Tax Office’s handling of the various audits against Wright’s companies — specifically forensic analysis suggests fraudulent documents were used as evidence against Wright and a large security vulnerability existed in the ATO’s networks allowing modification and altering of records.

Background

As part of Wired/Gizmodo’s initial doxxing of Craig Wright, a leaked 2014 transcript between the Australian Tax Office and Craig Wright and his legal team gave us a glimpse into the long saga between Craig Wright’s various business dealings and the ATO. This document is authentic and is cited as evidence in the current lawsuit between Ira Kleiman and Craig Wright. In this transcript we are given some key insight into the various audits Craig Wright’s companies underwent as a result of his Bitcoin businesses dating back to 2009. Two days prior to the date of the transcript, Investor Daily reported that Wright was working with the ATO to “have a full banking licence from APRA based on Bitcoin” with his company Hotwire PE. The transcript shows that this was not Wright’s first experience with the Australian Tax Office surrounding his Bitcoin businesses, and specifically that he “gained a little bit of paranoia” from his prior experience with the ATO “in 2010 or whatever it was”:

In working to obtain information about this previous interaction, we have obtained exclusive documents showing Wright’s initial 2011 objection decision against an amended assessment for the tax year ending 30 June 2009. The audit for the 2008–2009 income tax year was commenced on 10 February 2010.

The document details that Wright “purportedly sold [his] personal intellectual property to Information Defense and Integyrs”, two of Wright’s companies.

Information Defense was created on 29 January 2009, 19 days after the mining of the first Bitcoin block, and the domain information-defense.com was registered on 23 January 2009. The domain for Integyrs.com was registered on 25 April 2009.

It’s noteworthy that Wright’s initial tax return claimed a net capital gains upon which he would have owed taxes — refuting many claims that Wright was trying to get money out of the Australian Tax Office. After audit, the ATO took up issues with Wright’s claimed deductions to which he filed an objection. While the objection was initially disallowed, the objection decision was later reversed (as shown in another document dated 11 February 2013) and the deductions were finally granted to Wright. It is noted that “the Tribunal is requested to note that this decision is in favour of the Applicant”:

The 2 year delay in approving Wright’s initial tax return for the 2009 tax season outlines the troubles Wright had in running his companies while under audits that he viewed as invasive and unfair. In the 2014 meeting he presciently tells the auditors “I did my best to try and hide the fact that I’ve been running bitcoin since 2009 but… by the end of this I think half the world is going to bloody know.”

During the middle of this audit in an alleged email between Craig Wright and Dave Kleiman dated 22 May 2012, Wright expresses frustration with the ATO’s “BS’ing” where he guesses “that they want to get a result out of attrition rather than honesty” and that “they will drain all I have if they can”. Wright continues venting his frustrations saying “They lost evidence and use my temper against me. I hate their lies. I did everything right and I am STILL punished.”

Craig’s aforementioned paranoia is on display in the early parts of the February 2014 meeting when Wright identifies that a private ruling issued by the ATO on 30 September 2013 was actually issued on 29 November 2013 and backdated. The backdating of the ruling was only discovered once Wright went to Internal Fraud and Investigations and had the authorization number investigated. Des McMaster, one of the auditors, shows frustration that Wright had obtained this information:

To add on to the dispute, Wright and his attorneys asserted that they had not received notice of the ruling

Questionable Evidence

Two months after this February 2014 meeting with the ATO, on 15 April 2014 the ATO reached out to Ira Kleiman and provided Ira with copies of purported agreements between Wright and Dave Kleiman. Ira begins to distrust Wright from this point on, and it is two weeks later where Wright, in a message to Ira, accuses the ATO of fabricating documents:

In this, I have a GST debt, the company has a gain. On the software from WK to Coin-Exch, I have an overall GST debt owed of $3.7 million (give or take). The company gets a return of 3.7 million. The net outcome is zero tax as they cancel.

What the tax office can do is use this and hold payments back to the company. They are trying to fish. They want information that they are not legally entitled to have. So far, they have fabricated documents (and been caught), used half-truths to make it seem as if things are wrong to others and more.

We have exclusively obtained two Computer Forensics Reports performed on behalf of Wright’s company Demorgan Ltd where computer forensics expert Dr. Nick Sharples and digital forensics expert Alan Batey were independently appointed to examine email messages used in the ATO’s probe of Wright. These emails were used as evidence in the continuing audits and probes of Wright’s business dealings that culminated in the ATO raid on his Australian residence in December 2015, one day after Wired published an article accusing him of being one of the people behind the Satoshi Nakamoto team.

Sharples Report

Dr. Sharples performed his forensic analysis on November 2015:

Of the four emails examined by Sharples, there is one email in particular that we will focus on for the purpose of this piece. This email, named DM5 in the forensic report, is given the title “ Private Ruling application Hotwire Preemptive Intelligence Pty Ltd DLM FOROFFICIAL-USE-ONLY .msg” and dated 01 November 2013. The title suggests the email is related to the notice of the private ruling supposedly issued on 30 September 2013 that Wright alleged was actually issued on 29 November 2013 and backdated. In the original 2014 transcript, Wright’s lawyers argue this ruling was never received:

Sharples notes immediately that there are two different Content-Type fields contained in the headers with different values. He notes that he does not know “how such a message could have been constructed.”

To understand the forensic report, we must become familiar with two pieces of email authentication. Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) are email authentication methods designed to detect forged sender addresses in emails (email spoofing). SPF allows the receiver to check that an email claiming to come from a specific domain comes from an IP address authorized by that domain’s administrators. DKIM allows the receiver to check that an email claimed to have come from a specific domain was indeed authorized by the owner of that domain.

Sharples notes that there is no SPF check or DKIM signature for this email:

In his conclusion, Sharples reiterates that the first (of two) Content-Type header fields contains an encoded date that is not consistent with the date the email was sent. This implies the email was not sent at the same time it was constructed.

Finally, Sharples concludes that the “inconsistencies with the email header values… raise questions in my mind concerning the provenance of the message.”

Similar analysis is performed on the other three emails in the report, and similar inconsistencies are found. Sharples notes specifically that “the ato.gov.au email system is configured to include the email header field ‘content-transfer-encoding’, and that none of the emails… have that field present, despite having purportedly originated from that domain.”

Batey Report

Dated 11 November 2015, Alan Batey also performed an independent analysis on a set of emails. He also performed analysis on email DM5.

Batey confirms that there is “neither an SPF or DKIM record present” for DM5, yet passes the SPF test “possibly due to their parent SPF record” (meaning it passed the SPF test for sge.net). Further analysis of “information available in the header of DM5 shows that the email was delayed for 2 days while in transit… [and] given the delay and the lack of signing of the email there is no assurance that the email has not been altered at the final hop.”

With all of this said, Batey comes to an even further startling conclusion: “The SPF record of DM5 shows that an additional 544 host are able to send on behalf of ATO.GOV.AU” and specifically that “any address from sge.net is permitted to send on behalf of ATO.GOV.AU”.

Batey’s analysis shows a potentially massive security hole once existent in the ATO and raises serious questions about the authenticity of the email used as evidence against Wright. Batey notes that “the email DM5 originates from sge.net and its SPF record contains an IP range’s of over 130,000 IP addresses… whereas the ATO address is limited to 4 IP addresses… This large IP range could be considered a potential security flaw as it allows emails to be sent from any one of these IP addresses and still pass the SPF test.” You can read Batey’s conclusion here:

Conclusion

Authenticity of Documents are Called Into Question

The independent analysis done by Sharples and Batey indicates that there was a potential security vulnerability in the ATO’s networks while handling Wright’s case and specifically that there are legitimate questions regarding the provenance of individual emails used as evidence in the Wright case. It is noteworthy that Wright commissioned the independent forensic analysis just one month prior to the leaking of information about Wright’s supposed identity as Satoshi Nakamoto to Wired. As Ian Grigg has implied coordination between Wired and the ATO during these events, the timeline in light of this new information does raise questions themselves.

Looking at the analysis of email DM5 and the surrounding timeline of events, there are three insights that emerge:

1. It appears that the ATO backdated a private ruling to Wright’s company Hotwire PE, a clear violation of law.
2. There are many questions raised about the authenticity of many emails used as evidence against Wright, but specifically in regards to one email that appears to be related to a notice of the private ruling that Wright’s attorneys never received notice of.
3. Independent forensic analysis showed a large security vulnerability in the Australian Tax Office’s networks that allowed for records to be altered and forwarded without being recorded.

With all of this said, it also raises questions about the authenticity of documents provided to Ira Kleiman by the ATO. These documents are being used as evidence in Kleiman’s lawsuit against Wright — some of which Wright has denied the authenticity of.

When it comes to scale, he was clear that scale was never an issue:

There is only one global chain.

The existing Visa credit card network processes about 15 million Internet purchases per day worldwide. Bitcoin can already scale much larger than that with existing hardware for a fraction of the cost. It never really hits a scale ceiling. If you’re interested, I can go over the ways it would cope with extreme size. By Moore’s Law, we can expect hardware speed to be 10 times faster in 5 years and 100 times faster in 10. Even if Bitcoin grows at crazy adoption rates, I think computer speeds will stay ahead of the number of transactions.

• Satoshi Nakamoto to Mike Hearn in April 2009

Satoshi believed that scaling was something that was solved by market forces, and not centrally planned solutions:

The fee the market would settle on should be minimal. If a node requires a higher fee, that node would be passing up all transactions with lower fees. It could do more volume and probably make more money by processing as many paying transactions as it can. The transition is not controlled by some human in charge of the system though, just individuals reacting on their own to market forces.

• Satoshi Nakamoto to Mike Hearn in April 2009

Satoshi Nakamoto understood from the beginning that the desire to mine coins would become an “arms race” that he hoped to avoid in the network’s earliest stages:

We should have a gentleman’s agreement to postpone the GPU arms race as long as we can for the good of the network.

• Satoshi Nakamoto in December 2009

Satoshi Nakamoto understood that the incentive to mine Bitcoins would force miners to become creative and smart about how energy would be expended to mine Bitcoins. Did Satoshi understand just how much mining would drive research and development into renewable energy sources?:

Bitcoin generation should end up where it’s cheapest. Maybe that will be in cold climates where there’s electric heat, where it would be essentially free.

• Satoshi Nakamoto in August 2010

At “large scale”, Satoshi Nakamoto understood that large businesses would be the ones responsible for mining and users could “just be users”:

The current system where every user is a network node is not the intended configuration for large scale. That would be like every Usenet user runs their own NNTP server. The design supports letting users just be users. The more burden it is to run a node, the fewer nodes there will be. Those few nodes will be big server farms. The rest will be client nodes that only do transactions and don’t generate.

• Satoshi Nakamoto in July 2010

Satoshi Nakamoto always knew that eventually we shouldn’t care about how big the blockchain would get and an (as yet created) implementation of SPV would solve the problem of new users entering the network:

It would be nice to keep the blk*.dat files small as long as we can.

The eventual solution will be to not care how big it gets.

But for now, while it’s still small, it’s nice to keep it small so new users can get going faster. When I eventually implement client-only mode, that won’t matter much anymore.

• Satoshi Nakamoto in August 2010

Satoshi Nakamoto understood that the core of the network would reach a limit in the number of (mining) nodes. This is what we have come to realize is the hyper-connected small-world mining core:

I anticipate there will never be more than 100K nodes, probably less. It will reach an equilibrium where it’s not worth it for more nodes to join in. The rest will be lightweight clients, which could be millions.

• Satoshi Nakamoto in July 2010

Finally, and maybe most importantly, Satoshi Nakamoto understood the urgent need to scale. He understood that the economics of the system meant that we either needed large transaction volume to sustain the incentive for miners to secure the network, or we would have nothing at all.

I’m sure that in 20 years there will either be very large transaction volume or no volume.

• Satoshi Nakamoto in February 2010

In a private correspondence with Satoshi Nakamoto, Mike Hearn asks Satoshi where he has been. In one of the last messages known of from Satoshi Nakamoto, he responds:

I’ve moved on to other things. It’s in good hands with Gavin and everyone.

• Satoshi Nakamoto in April 2011

It seems weird that Satoshi Nakamoto would have moved on past Bitcoin, especially with all of these quotes showing that Satoshi Nakamoto always thought big about Bitcoin. When the world has been thinking so small about Bitcoin, why would Satoshi Nakamoto leave it abandoned, doomed to die with inevitably no transaction volume?

But perhaps he never did. Perhaps there was a piece of Satoshi Nakamoto that never stopped working.

Metanet is simply Bitcoin scaled to the globe as the single global ledger. It is everything as Bitcoin. Satoshi’s vision is alive and well with Bitcoin SV.

We’ve written previously on Bitcoin as a complex social network, inspired by a textbook of a similar name. In that piece we examined three inherent properties of social networks:

Robustness

Search

Diffusion

We explored how the Bitcoin network displays remarkable tendencies to outperform every other known social network with respect to these three properties.

We will use this piece to focus on the property of search. A reminder on what search is:

Search is the procedure by which individual nodes may look for, access, and disperse information. Is the effectiveness of search influenced by network topology? Are different search algorithms better suited to alternative topologies? Can one design the network architecture so that search is optimized?

On Wednesday night of CoinGeek Week, I was fortunate enough to have some beers with a number of people, one of which was Alex Fauvel. As we were speculating about the ideas of metanet, he asked me if I had heard of a Mandala Network. I replied no and he got wide eyed and sent me a link to a paper and began talking about how the introduction of the paper described Bitcoin and dumped more information on me of which I was too tipsy to absorb. The next morning I was so engrossed by the paper I elegantly sent him a message expressing my fascination with the paper. You can imagine my delight when Dr. Craig Wright immediately referenced a Mandala Network when we sat down with him to talk about the structure of metanet.

We will be exploring Mandala Networks in depth further in this series, but we will briefly touch on them as it is important to understand why we are referencing them to begin with. If you look back at our original piece describing searchability of a network, we reference that searchability improves in a multidimensional network where we can organize the nodes in a network in a hierarchy. In the piece we describe this hierarchy as miners, merchants, and users. In the above diagram, the miners are the core of the network, the merchants are the middle layer, and users are the outer layer.

Miners

↑

Merchants

↑

Users

On the whole, each group will behave in the network differently. As we’ve discussed, miners are heavily incentivized to cluster together with other miners. Merchants monitor for double spend attempts and in the hierarchical system we have defined, miners assist merchants with their search attempts. Merchants reach “up” to the miner hierarchy to check the transactions waiting to be confirmed in the mempool. On the whole, each group in the hierarchy knows where they can look to find the information they are looking for. The robustness of the miner hierarchy aides in the search, as does the diffusion of the information across the network.

Metanet becomes the overlay network of “merchant nodes” (M-Nodes) that interact with the blockchain but are not miners. We can expand the scope of what a “merchant” is to encompass all nodes that have a high degree of connectivity with miners and are capable of efficiently monitoring and searching the blockchain. The high searchability of the Bitcoin network allows for us to use transactions efficiently for the purposes of interacting with devices and other peers in the network in the same way we interact with the internet today. The M-Nodes in the network become a way for users on the outside of the network to search the blockchain effectively. You can see in the layout of our Mandala Network, the M-Nodes act as intermediaries between users and the blockchain that allow for data from the blockchain to be accessed efficiently while not relying on every user to monitor the blockchain. We will examine Mandala Networks in the future, but understand that the design is optimal for our purposes of building a new internet.

Keeping this in mind, if you are confused about what metanet is, simply view it as a layer that makes interfacing with the blockchain easier. The “M-Nodes” in the middle layer of the network allow us to build applications that monitor, search, and interact with the blockchain in a highly efficient manner that allow for endless opportunity for Bitcoin at scale.

A few use case examples were listed with a diagram of how each can be structured in the blockchain were shown on one of Dr. Wright’s slides:

Let’s take the first example of supply chain. Let’s say that we can automate an entire supply chain for a company like Walmart or Amazon. The Playstation 4 that I want to purchase is a tokenized asset on the blockchain. When I hit purchase, the assembly line monitors the tokenized asset on the blockchain and immediately recognizes that it has been purchased. The assembly line packages the product for shipping and scans it as it is loaded onto the truck. Immediately my app sees on the blockchain that my tokenized asset (Playstation) has been loaded on the truck and notifies me. I don’t want to wait around to sign for my package all day, so I provide a digital signature at my front door. The courier scans my digital signature and leaves the package at the door upon which my app, continually monitoring the blockchain, notifies me. I get home and find out that my Playstation is defective and notify the company through my app. The company is now able to look at the entire history of the tokenized asset on the blockchain to determine what went wrong.

This is a minute example of what is possible with the world running on top of Bitcoin, but it is made incredibly more efficient due to the searchability inherent to the network. There is a simple example of this already that we are all familiar with:

This is a device that is continually monitoring the blockchain for any money that is sent to an address. As a transaction occurs, the device makes an action to feed the chickens.

How can we use Bitcoin at scale to improve upon this setup? Perhaps every grain of feed can be tokenized on the Bitcoin blockchain? Every chicken, monitored on the blockchain from birth to death with sensors monitoring their blood temperature every step of the way, recorded on the blockchain daily. Every egg, tokenized and monitored through incubation to hatching. Imagine the data that emerges from this monitoring process. Imagine the ability to search through this data and what can be learned from it. Imagine how this will change the world into the future.

This is the beginning of what the peer to peer nature of Bitcoin at scale allows.

At CoinGeek Week we had the pleasure of sitting down with Ryan X Charles of Yours Inc and Jason Chavannes of Memo.cash to talk about social media and Bitcoin. A central question I wanted to ask the two was how they envisioned we could solve the trolling problem with Bitcoin. Ryan’s presentation had a central idea to it that has not left my mind since hearing it: “Every problem with Bitcoin can be solved with Bitcoin”. Going back to the founding of /r/btc, the big blocker Bitcoin community was united in their hatred of the censorship found on /r/Bitcoin. The Bitcoin subreddit was given so much power over the direction of Bitcoin that censorship was able to actually affect its development. /r/btc has been committed to “free and open discussion”, and yet the quality of discussion is so poor that most people who have opinions worth listening to have stopped looking at it. The problem is an inherent problem with Reddit itself, and one that Bitcoin can solve.

When I first discovered Reddit, it was one of the few times I have felt like the internet as a resource of information could truly change the world. This was in the early days of Reddit, and I remember being amazed that a platform was able to turn data into information with the use of upvotes and deliver content that was valuable to me based on the things I was interested in. I remember reading a personal account from a girl in Pakistan who was sharing her experience living in a war-torn country. I remember the next second reading first-hand accounts about the effects of tax policies in Australia. I was learning new things about programming. I was seeing the world through a global lense, and anyone could contribute by creating an account and posting. This was a time when people actually thought it was “special” to meet other people who knew what Reddit was. There were stupid (cringey) jokes about how to identify other redditors in real life. The content you saw was valuable because the nodes in the Reddit network were real nodes. They were real people with real interests determining what was actually valuable. Of course, this couldn’t last forever, and Reddit quickly became a lesson in Sybil attacks.

A subreddit called /r/hailcorporate arose over time and was devoted to calling out highly upvoted posts on the Frontpage that were clearly part of marketing campaigns for large corporations. It became clear to me just how bad the entire website had gotten as I used it to follow the 2016 election in the United States. I saw valuable and factual information quickly downvoted anytime it was posted. I saw articles and opinion pieces that obviously favored certain candidates’ agendas get a suspicious number of upvotes in a small amount of time. It became clear to me that the Reddit network was a failure. There was no way to guarantee that the content that was brought to the top was actually valuable — it was simply information that someone wanted to be made highly visible and could pay for enough nodes in the network to get it to the center of the network. Tim Pool, an independent journalist, exposed Reddit for this when he made a video about easy it was to make fake news and game Reddit and paid for it to be on the Frontpage. In an ironic twist, the Reddit administrators deleted the video for astroturfing.

In Bitcoin, the non-business minded focus of the community has led us to believe that Reddit matters. Because of this, the moderators of subreddits like /r/Bitcoin and /r/btc have convinced themselves that what they are doing is important to the future of Bitcoin. Since /r/Bitcoin has been examined to death, we can take a look at /r/btc and examine how Bitcoin can (and will) make it irrelevant. There is a paranoia inherent to the moderators of the subreddit that it is constantly under attack by “CSW shills”. The irony of this is that if it were true, then for a very rich man, CSW is terrible at hiring shills. If you watched Tim Pool’s video above, you would see just how easy it is to actually get information to the top of Reddit, let alone small subreddits like /r/btc. In the weeks leading up to the hashwar, there was a clear bias in the subreddit towards Bitcoin ABC. Every time we post in the subreddit, it is downvoted extremely quickly and the same 5 Reddit accounts poke their heads out to let us know how they feel about us. Of course, we are paid shills that have no opinions of our own. Weirdly enough (not really), comments on YouTube, Memo, and Twitter are much more reasonable (even if they disagree), and that is having only blocked one or two accounts on Twitter.

At the root of this is the inherent problem with thinking of Bitcoin as a “community”. When the community is at the whim of a network that can be Sybil attacked for $30, then it is no community at all. Bitcoin was designed to be resilient to Sybil attacks. It is a network free from the grasps of Proof of Social Media, but only if miners wield the power given to them to be businesses ignorant of the whims of Reddit users. Reddit “communities” like /r/btc have succeeded in doing one thing only: allowing an outlet for users to have their “5 minutes of hate” for whoever has been deemed the enemy of the day. Whether that is Craig Wright, Ryan X Charles, or Unwriter, all gather around the fake community to direct their anger at who is next to betray the Bitcoin community.

So, we have Bitcoin — how can we make information valuable again?

Yours.org is the first experiment in making content curation an economic system. Users can spend money getting things to the top of the site, and if other users also deem it valuable, the initial voters on the content can get their money back and even profit. Content creators can charge people money to view content, and purchasers can review the content to let others know if the content was worth the money. It is a fantastic service, but it is only the beginning of what Bitcoin allows for.

The problem of determining whether a node in the network is a real node is something that Bitcoin brings: Pseudonymous identities backed by reputation of past events competing in a free market to deliver value to other identities. Those that get valuable content to others get rewarded. Value is an inherent property of all data that lives in the blockchain, determined by the natural economic forces of the metanet. Censorship is impossible as everything recorded is immutably stored in the chain. One YouTube commenter sarcastically compared the discussion we had with the Chinese social credit system that has emerged. Again, this misses the promise of what Bitcoin brings.

Craig Wright had a fantastic article about how Bitcoin is designed to prevent the social credit system envisioned by the Black Mirror episode “Nosedive” from destroying value from the economy. The thing that scares us all about the social credit system implemented by the Chinese government is that it is possible for all governments (or large corporations) to implement similar systems today. Google could start rate-limiting your searches if you are a heavy user or a consistent searcher of content deemed inappropriate by Google. Amazon could start delaying your packages based on the purchases you make. We see this behavior already from large social media companies like Twitter and Facebook.

As we covered in our introduction, humanity and big data are an inevitable pairing. Bitcoin allows us to “take everything socialist about the internet and make it capitalist”. This means allowing us to have a reputation system based on open markets, and not determined by trusted third parties. In the Black Mirror episode the main character’s social credit rating is constantly being determined by an algorithm run by a trusted third party based on the opinion of other users in the network. Bitcoin doesn’t care who you are — it only cares what value you create. This is what the real promise of the fourth industrial revolution brings — value and proof of work. If you create value, you win. If you stagnate, you regress.

There is an obsession in Bitcoin that the opinions of the “OG’s” matter more than others. An old bitcointalk thread describes the “ranks of nobility” of Bitcoiners based on how many Bitcoins one holds. This idea is just another way to ignore the value of what people are offering and to instead rely on some outside social credit ranking deemed by an arbitrary group of “OG Bitcoiners”. This manifests itself entirely in Reddit. Users with no skin in the game relying on their given social credit score to spread the 5 minutes of hate on the next “enemy of Bitcoin”.

The cancer of Proof of Social Media is being removed from Bitcoin. We are going to make Bitcoin SV cash for the world, and you are free to join us as long as you create value. Start thinking of how you can bring more value to peoples’ lives, and ignore the trolls who wish nothing but to direct their hate at your vision.