In the years following our fork from BTC, negative events have confronted us affecting the stewardship of a successful cryptocurrency. Loosely, such a stewardship comprises making technical decisions, growing engineering relationships, building the user community, and protecting the essential qualities of BCH. Most of these negative events have not alone been serious enough to risk or cause a fork, except for the Infrastructure Funding Plan (IFP) and the issues leading up to the BSV fork.

But on the technical front, we have failed to deliver many meaningful end-user innovations, instead mostly focusing on internal, janitorial work and introducing purposeless complexity…

Quasi-consensus is a term that was coined recently[1] for a well-known problem: there exists network wide configuration values that, if inconsistent, cause undesirable network behavior (but do not cause a fork).

For example, the minimum fee required to relay transactions is quasi-consensus because “Mallory” could more easily double spend transactions by first creating a transaction below the minimum fee of some nodes, and then a double spend above that minimum fee that will propagate to all nodes that rejected the first transaction.

I have written a thorough description of that problem here[2] for readers who are interested in more detail.

The blockchain spam debate is rearing up again with similar arguments and divisions. To come to some clarity on the subject it is first important to understand that participants are not even talking about the same thing that both call “spam”. The word spam is being used in two contexts, and for lack of a better description let’s call these contexts “humanist” and “machinist”.

In the humanist approach, a person looks at a transaction within the wider ecosystem and concludes that it is spam because it was created in attempt to stress or break the network, because it encourages incorrect…

Abstract

There are two broadly different consensus strategies being employed by blockchain technologies today: miner and client consensus. Miner consensus is what is implemented in Bitcoin, so should be familiar to readers. In the client consensus model, the blockchain does not enforce validity rules. Its job is simply to unambiguously order a set of messages, letting each client determine their validity.

Understanding this difference and the client consensus security model is increasingly relevant today because many “layer 2” protocols have been developed that place their data into the OP_RETURN field of transactions, notable protocols implement tokens and human-friendly identity. …

Description

OP_UNIQUE is an attribute or attribute opcode that associates a piece of miner-enforced unique data with a TXO. In a manner similar to how the UTXO set prevents doublespends, all blockchain validators must keep a UUDO (unspent unique data output) set to disallow any transaction that associates an already-associated piece of data from being committed in a block. Therefore, implementation of OP_UNIQUE is a consensus change.

A transaction may spend a UUDO UTXO to give up “ownership” of the unique data, or atomically spend a UUDO UTXO and create another OP_UNIQUE tagged output with the “spent” data to transfer ownership…

In the weeks approaching the fork, ad-hominem attacks were tweeted and positions were taken that made the BSV fork inevitable. But fracturing of the community is by definition counter to our goal of one worldwide cash, so we should not be happy about this outcome. For people who are still confused and shaken by the experience, let me try to offer an interpretation and philosophical structure around what happened.

First, as I mentioned in BUIP098, the proposed changesets were mutually compatible so this split did not need to happen at this time.

Layer 2 “smart” contracts typically spend participant’s money to an N of N multisig controlled by all participants, and/or an arbiter. To be a bit sardonic, in this architecture you get to use cool, trendy “smart contracts” up until someone honest thinks something went wrong, or someone dishonest thinks that they can take advantage of you, and at that point you are back to human negotiation and the judicial system. For example, given a 2 party contract based on top of 2-of-2 multisig, let us presume that the contract execution awards the money to party A. Party B can simply…

Where’s the Beef?

You have been told that Bitcoin is a Turing decider, or Turing complete (within script size and stack limits), so where are the all the smart contracts? Forget about “smart” ones, where are the “dumb” ones? Where are the simplest scripts that have conditional payments based on something other than signatures? Its time to cut through the hype and lies around smart contracts, by proving what’s not possible in Bitcoin Cash today. From there we can start to have an intelligent conversation about how far we want to travel down the road of enabling smart contracts. …

(originally published on google docs July 19, 2018)

Tokeda is being heavily promoted to the public as an alternative to Group tokenization, so I would like to offer the following detailed review. For your reference, the Tokeda specification is located at: http://media.lokad.com/bitcoin/tokeda-2018-04-30.pdf. Although this specification marks itself as “Early Draft: Incomplete” it is being presented as a viable technology so needs to be analyzed now.

Blockchain and Network Utilization

One of the primary criticisms of on-chain tokenization is that it consumes precious blockchain and UTXO space so I’ll lead off with that. Let’s see how Tokeda compares.

“Alice signals a token transfer intent to…

(originally posted on yours.org in Oct 2018)

It may not be immediately apparent, but permissionless innovation of layer 2 blockchain features and reliable acceptance of payment before confirmation (0-conf) are in conflict. The conflict arises around the concept of “standard transactions”. Standard transactions are ones that are relayed between bitcoin nodes, whereas non-standard transactions are allowed in blocks but not relayed.

To defeat 0-conf, one strategy is to pay the merchant with a standard transaction but inject an unrelayed non-standard transaction directly to miners. The merchant only sees the standard transaction, but the miner mines the non-standard transaction. …

Andrew Stone

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store