Wisdom Engine

The creation and transfer of Bitcoin is based on an open-source cryptographic protocol (essentially, a software program that is free to download, with users having access to the source code and ability to modify it), and utilises a peer-to-peer computer network made up of its users’ machines (Bitcoin network) to validate transactions by solving complex mathematical equations.[[1]](#_ftn1)

The Bitcoin white paper (Wright, 2008, p. 1) references a system that provides “small casual payments,” allowing for the dissemination of transactions across the internet. Understanding both micropayments and the nature of sending small casual payments across the internet necessitates describing and analysing micropayments and referencing Bitcoin and blockchain technology in the same context. In this analysis, the term micropayments will be used to describe transactions that may be made efficiently—for under 50 US cents. In such a functional specification, the cost of systems, including M-Pesa (Mbiti & Weil, 2013), will be demonstrated as too large to be incorporated into usage of micropayment solutions.

Pseudonymity and Privacy: Blockchain systems, including Bitcoin, often provide a level of pseudonymity, where users are identified by cryptographic addresses instead of their real-world identities. While such pseudonymity offers privacy benefits, it can also pose challenges in implementing AML controls. For example, linking specific transactions to real-world entities becomes difficult, making tracing illicit activities and identifying money laundering patterns challenging (De Filippi, 2016).

It is well known that Bitcoin solves the byzantine distribution problems through a probabilistic risk algorithm. In this scenario, it is proven that Bitcoin is safe as long as 50% of the miners respect the rules of the system. The system is economically incentivised. Any company that has gained 51% of the hash rate quickly lost controlling share of the network. Time and again we see that the so-called experts in Bitcoin have failed to understand the primary controls that govern the system. It is not cryptography, it is economic incentives.

“According to the Satoshi’s whitepaper, nodes were miners. The hijacking of the word seems to have placed unneeded importance on these validating nodes. But what would Bitcoin look like without these ‘nodes’, and how centralized would mining be, with the removal of the blocksize limit?”

In order to create a Bitcoin vending machine, we need to think about risk. This is not a desire for perfect security, but “good enough”. To start, we allow 0-conf. This is not as risky as many falsely tout. A 0-conf transaction, that is a transaction that has not been included into a block and confirmed by a miner is secure enough for most purposes.

In a fair exchange protocol two parties either both honour an exchange (such as a contract), or neither of them do. It is known that deterministic fair exchange is impossible without a trusted third party (Even and Yacobi 1980). However, under the Bitcoin protocol, a validated blockchain acts as a trusted third party.

There are people who try and tell you that Bitcoin is not about incentives or economics. The structure of Bitcoin is one that allows competition to determine a stable monetary system. Miners (nodes) have skin in the game unlike developers, and thus, are in competition for the block reward and transaction fees. The result is they will seek to maintain the protocol and not to debase and alter the currency.

``` There are two ways to send money. If the recipient is online, you can enter their IP address and it will connect, get a new public key and send the transaction with comments. If the recipient is not online, it is possible to send to their Bitcoin address, which is a hash of their public key that they give you. They'll receive the transaction the next time they connect and get the block it's in. This method has the disadvantage that no comment information is sent, and a bit of privacy may be lost if the address is used multiple times, but it is a useful alternative if both users can't be online at the same time or the recipient can't receive incoming connections. ```

The first problem to be addressed concerns the nature of lawful money. In the United States, the Stamp Payments Act of 1862[[1]](#_ftn1) was enacted to stop the circulation of private tokens that were in competition with federal postage stamps. It has been argued that the language of the statute may apply to electronic transactions[[2]](#_ftn2) extending the derivation of “note, check, memorandum, token” as money. Even the notion of Bitcoin as an obligation comes into question as we need to define the concept of a third-party issuer. The peer-to-peer nature of the currency means that obligations are derived in a manner unlike that of other monetary sources[[3]](#_ftn3).

Miners can choose to accept no single CTOR block. They can mine and set a rule that the block deserves only to include a transaction where it is unlikely that one will ever meet their high standards (as ABC is of no use as money). Basically, the point is; as a user, no, you have NO rights. Miners do. Users make an offer to a miner. Users make a unilateral offer of a fee to any miner who validates their transactions (and thus includes them in a block). The miners can choose to accept this or leave it for one of the competing miners, who in many cases will take it.

The nature of Bitcoin is such that once version 0.1 was released, the core design was set in stone for the rest of its lifetime. Because of that, I wanted to design it to support every possible transaction type I could think of. The problem was, each thing required special support code and data fields whether it was used or not, and only covered one special case at a time. It would have been an explosion of special cases. The solution was script, which generalizes the problem so transacting parties can describe their transaction as a predicate that the node network evaluates. The nodes only need to understand the transaction to the extent of evaluating whether the sender’s conditions are met.

Using the API (RPC) call to a Bitcoin node, the merchant can use the call gettxout. If it returns anything, then the output is unspent (at least as reported by that node). If nothing is returned, we know that the output either never existed or has already been spent. In an SPV, where we know the transaction path, and we know it existed, the option is that a transaction has not been spent, or a merchant could have a double spend.

One part of the hijacking of Bitcoin stems from the manufacturing of ASIC chips. The purpose of a node is not simply to find a puzzle that gives you the block subsidy. I will say subsidy again here as it is a diminishing incentive and not a reward. The Bitcoin white paper defines the process conducted by nodes in section 5. Nodes do not merely solve a simple hash puzzle — a process that ASIC devices help with — but they order transactions in chronological sequence, verify the integrity of transactions, and ensure the propagation of blocks and transactions.

In a fair exchange protocol, two parties either both honour an exchange (such as a contract), or neither of them do. It is known that deterministic fair exchange is impossible without a trusted third party (Even and Yacobi 1980). But under the Bitcoin protocol, a validated blockchain acts as a trusted third party.

The Bitcoin Wiki (2014) includes a page on ‘Atomic cross-chain trading’ which describes a protocol where two parties own coins in different cryptocurrencies and want to exchange them without having to trust a third party or centralised exchange. There also exists a BIP (Bitcoin Improvement Proposal), entitled Atomic Cross Chain Transfers (Tiernan, 2014), that describes the method. Others have hinted that by combining secrets, a more symmetric solution is possible. We demonstrate how it can be achieved in Bitcoin.

The only method to maintain decentralisation of power is to set the protocol and lock it. It must be set in stone.

Bitcoin is a simple protocol. As such, the security of the system is protected as miners cannot update the protocol. A miner can choose to not accept a transaction, and can seek to reject blocks with the same transaction at the risk of losing and the orphaning of anything they win. Even if they choose to do so, it merely delays a transaction. A transaction can be replayed a week later, a month later, a year later, a decade later, or whenever the user decides. It is a key strength of Bitcoin. Miners don’t set protocol, rather the protocol is set in stone. If you change the protocol, you move away from Bitcoin. Protocol changes are not forks but rather new competing protocols with a possible airdrop.

Bitcoin is practical for smaller transactions than are practical with existing payment methods. Small enough to include what you might call the top of the micropayment range. But it doesn’t claim to be practical for arbitrarily small micropayments.

He demonstrated how history was relative and fundamentally unreliable. The distortion in the written word over time became a central issue and area of study that Nakamoto used in his thesis that history was unstable. The constant change and variation to history is in effect an unchanging alteration to the protocol of how we as humans communicate. It is both language and the full meaning of words that we see change. Instability when coupled with human ambition and desire leads people to manipulate language. The making of myths can be seen in the Bitcoin white paper. People have argued that miners could make rules and lead us to a system without government, even though the white paper makes it clear that miners enforce the rules — the difficulty here being that an enforcer is not a creator.

The Bitcoin blockchain is an immutable audit trail, which does not mean that money cannot be seized or that illicit images and other material cannot be filtered. Immutability does not require non-assignability. An immutable object is something that remains unchanging over time, and once a block is sufficiently deep, any transaction within Bitcoin or any blockchain is unable to be changed. The scenario is analogous to an Oracle database running an account system in write once read many (WORM) formats. It is used in all public companies in the US. Such a system does not preclude the correcting of mistakes; it requires that a mistake is noted and followed.

You should note that the only decentralised system that fulfils the described condition is Bitcoin, as defined by BSV. The definition, “not controlled or not able to be controlled or unilaterally changed by any group of persons”, in effect means that the protocol is set in stone and stable. Too many developers seem to be obsessed with technical change. Bitcoin is not merely a technical system, but one that acts both in economically powerful ways and within the law. When I made it clear that Bitcoin’s core design was set in stone for the rest of its lifetime [1], it wasn’t because of technical issues. Every group behind every single competing system, including CoreCoin* (BTC), has ignored this simple fact, and demonstrated that their developers are capable of altering the system they are trying to create. Whether we are talking about changes by “Bitcoin” Core designed to increase anonymity and encourage illicit transactions (creating a system radically distinct from Bitcoin) or the changes continuously being conducted by the Ethereum group, we see alterations in their systems by small groups of developers.

The solution to problems with crime and money laundering always existed within Bitcoin. In the white paper itself, it is explained many times that attackers could be controlled by honest nodes. When I launched Bitcoin, I had not yet completed implementing the system of the alert key, and I still had not fully determined how it would best work. It was always envisioned. When I said that there was a strategy to protect systems based on simplified payment verification (SPV) using alerts from nodes, I was not limiting the nature of alerts to the same one possible form of attack. The difficulty in the implementation, at the time, lay in determining which nodes should be trusted. It involved not the core approach of proofs, but rather one of determining the voting strategies of nodes. Remember here, of course, that nodes are miners.

In an exchange using digital token systems, the same logic would apply. Again, it depends; it is not a matter of law, but of fact. In an exchange of Bitcoin transactions, the nature of the transaction and how it was transferred determine the time and location of acceptance. For instance, in a peer-to-peer exchange where a buyer and seller directly exchange a Bitcoin transaction using the original IP-to-IP protocol, the transaction would be said to be instantaneous and, as such, would occur at the location where the recipient resides. Conversely, a Bitcoin transaction sent directly to the blockchain and a recipient’s published address would mirror the condition of the postal acceptance rule.

I used the word vote in the Bitcoin white paper three times. I used the notion of anthropomorphism in explaining the concept of proof-of-work. In noting that proof-of-work was “essentially one-CPU-one-vote”, I was attempting to make the point that any system running the “honest” version of the software presented, in consequence, a vote for a non-criminal or non-attacker version of Bitcoin.

The Bitcoin system described in the white paper is not ambiguous. It is not open to interpretation. It is a peer-to-peer system of electronic cash. Cash means utility and practicality for daily use to make Internet commerce payments, including for “small casual transactions”, as noted on page 1 of the white paper. Cash means the network must be able to scale to support a high volume of transactions at high speeds and very low costs. For it to work, the underlying protocol must be set in stone, and not open to repeated revision by constantly tinkering developers who do not understand the system they may break. The system described in the white paper is clearly not one whose primary purpose and promotional message involves the storing of value or “digital gold” as a reserve asset.

There are two ways to send money. If the recipient is online, you can enter their IP address and it will connect, get a new public key and send the transaction with comments. If the recipient is not online, it is possible to send to their Bitcoin address, which is a hash of their public key that they give you. They’ll receive the transaction the next time they connect and get the block it’s in. This method has the disadvantage that no comment information is sent, and a bit of privacy may be lost if the address is used multiple times, but it is a useful alternative if both users can’t be online at the same time or the recipient can’t receive incoming connections.

There are always arguments over scaling blockchain networks. Most of them end in ad hominem attacks, and very few address the prime issues that need to be discussed and understood. None of it is new, either. In 2008, during a rather infuriating argument with James Donald, I gave an explanation concerning block sizes and how Bitcoin would scale [1]. The reality is much simpler than people make it out to be. There is nothing to analyse when it comes to the size of transactions or the size of blocks beyond calculating them using simple algebra.

Abstract. A system such as Bitcoin operates using a proof-of-work-based consensus mechanism that many individuals have falsely claimed to limit the ability for the system to scale. As a result, alternative proposals based on proof of stake are misleadingly being promoted as scaling solutions. Yet, it will be demonstrated that proof of stake is not a scaling solution but rather a means of reintroducing ownership and equity control through a back-door creation of a digital bearer share. Here, an equity system based on anonymous holdings is constructed that allows the digital control of a corporate entity outside the provisions of regulatory controls.

The Bitcoin white paper is a contract (Caruso, 2018). Whether you’re using Bitcoin or some poor copy of Bitcoin, such as the BTC Core network, the terms of the document are binding, and include all the nodes and all of the developers (Tiersma, 1992).

The solution to the double-spending problem involves more than merely noticing that an attempted attack was made; it required that the system could be traced (Lee et al., 2003). Bitcoin broadcasts every transaction, and every transaction attempt, to every node (Wright, 2008, p. 3). Such a requirement is the first step in running a node; for a network node to function, it must ensure that “New transactions are broadcast to all nodes”. While nodes don’t require that a transaction is immediately found, the primary purpose of Bitcoin nodes is to act as a “time-stamp server to generate computational proof of the chronological order of transactions” (Wright, 2008, p. 1).

Presently, the term decentralisation is used extensively and with conflicting meanings (Walch, 2018). For blockchain technology to become part of existing accounting and reporting systems, it must shed its deceptive terminology and embrace the concept of regulation and law. Doing so requires that the description of the system and the problems associated with the misrepresentation of node connectivity be corrected and that the system is described in a way that allows regulators to monitor and maintain control over such systems.

In fact, a consistent block is not even maintained across a single mining entity, let alone across a pool of miners or in the overall network. Individual blocks are not consistent series of transactions with a nonce; rather, each block is a series of transactions that changes moment by moment. In addition, there is no need for consistency within a block before it is mined. Each attempt to solve the next block remains independent of the previous attempt. Therefore, adding a transaction to a block has no effect on the overall time required for solving that block. The result is that individual miners experience discrepancies in the information that they are solving.

The order in which miners receive information leads to radically different solutions to the block puzzle. For example, if two miners were to receive two separate transactions that were released from slightly different locations and at slightly different times, it is likely that one miner would exhibit a different transactional order than the other miner in the block that they were attempting to solve.

The reason for this is that the miners on the network create blocks as transactions are propagated and updated within the ledger inside blocks. So, contrary to popular wisdom, there is absolutely no advantage in running a full node unless you are a merchant monitoring the double spends or a miner. In fact, even were 90% of the nodes to initially reject the transaction in favour of a double spend, as the majority of miners will have worked on the initial transaction, the transaction in a wallet will be reorganised when the new block comes.

“There are around 15000 banks. Add financial organisations including savings and loans… We are up to 60,000. Then add in all the major merchants and operations that need to have transaction data by law, and that’s around 17 million organisations. That is decentralised do you not think?”

Dealings and transactions that formulate or initiate contractual negotiations are not restricted to the written word. The law of offer and acceptance applies to new technology in the same way that it applied to technological advances of the past. This series of posts explores the issues that have created uncertainty around contractual dealings with the advent of Bitcoin. It is necessary both to consider the origins of contractual law and to investigate cases that will apply too and formulate the conditions necessary to create contractual certainty in commerce when answering this dilemma.

This is a very quick summary of why scaling on-chain works. In 2009, the effective limit in software was 32MB — although this was only due to the limits of the software. For a commercial server, this would not have been an issue. I will address this in the field of a commercial server, and I am sorry, I do not care about Raspberry Pi(e) or laptop nodes.

γ = 0, the honest miners always publish and propagate their block first, and the threshold is at 1/3. With γ = 1/2 the threshold is at 1/4. Figure 3 shows the threshold as a function of γ.

“An entity that provides an algorithm, run on a computer program or on a smart contract using blockchain technology, as a means to bring together or execute orders, could be providing a trading facility. As another example, an entity that sets execution priorities, standardizes material terms for digital asset securities traded on the system, or requires orders to conform with predetermined protocols of a smart contract, could be setting rules.”*

The postal acceptance rule states that where an acceptance is to be sent by post, the contract associated with that acceptance is considered as concluded at the moment of posting the letter, not when the letter is received (or in fact if the letter is received). If the offeror does not wish to conclude the contract through acceptance via the post, s/he may stipulate the form of acceptance. (The “postal acceptance rule” was introduced to present assurance to the “new” British penny post. It dates back to Adams v. Lindsell, 1 Barnewall and Alderson 681, In the King’s Bench (1818); see also Household Fire Insurance Co v Grant [1879] 4 Ex D 216).

Contractual acceptance through e-mail has been settled by judicial review and decision. As such, the high degree of uncertainty surrounding the issues of offer and acceptance related to the formation of contracts through e-mail-based communication is long past. In the US, this issue has been determined through statutory intervention (Uniform Electronic Transactions Act, 1999; USA). In the UK, the issue remains clear following the ECA. For this post, I will assert that the exchange of a transaction and payment for settlement and exchange using Bitcoin mirror that postal acceptance rule in e-mail.

It has been argued that the digital contract may appear on the computer screen to consist of words in a written form but merely consist of a virtual representation (Allison et al, 2003). The ECA has removed the uncertainty and doubt surrounding the question as to the nature of electronic form used in the construction of a contract. In this, the ECA specifies that the electronic form of a contract is to be accepted as equivalent to a contract in writing.

In this situation, Bob first creates a deterministic sub-key from his public key (see “A method and system for verifying ownership of a digital asset using a distributed hash table and a peer-to-peer distributed ledger” for details of this process) to represent the asset. This asset then publishes details about itself onto the Blockchain.

- How a contract, or structured control condition, can be published and certified on the Blockchain in the form of a token; - How this token will be able to reference an external repository holding a complete representation of the contract; - How a contract can be structured in a manner to support wholly or partly automated enforcement; - How interested parties can enquire as to the current state of the contract; - How to configure sub-contracts, or sub-conditions, to contracts that can be derived from the parent contract.

It was said in a response to an earlier post that “Electronic contracts do not have to be re-read when they are returned because there’s generally no mechanism (unless it’s built into the electronic process) to alter the contract terms, scratch out a line, insert text, etc. What you send is what is being signed.”

The Bitcoin Wiki (2014) includes a page on ‘Atomic cross-chain trading’ which describes a protocol where two parties own coins in different cryptocurrencies, and want to exchange them without having to trust a third party or centralised exchange. There also exists a BIP (Bitcoin Improvement Proposal) entitled ‘Atomic Cross Chain Transfers’ (Tiernan 2014), that describes the method. Maxwell (2012) hints that by combining secrets a more symmetric solution is possible.

Alice and Bob wish to trade entities of value, such as bitcoins, other currencies, contracts, goods or services. They have agreed that Alice shall give Bob e1, and Bob shall give Alice e2. Let H(x) be the OP_HASH160 Bitcoin script hash of x. Note also that in the Bitcoin script, as used here, a non-zero locktime indicates the earliest time that the transaction may be added to the block chain and in practice is expressed in Unix time (the number of seconds that have elapsed since 00:00:00 UTC 1 January 1970), whilst a zero locktime is interpreted as no locktime (for immediate broadcast). The protocol is described in Table 1, and the transactions are given in full in the appendix.

In the conventional way of regarding such a machine, states are defined statically (a priori) and represent some particular configuration of the system or have some particular meaning, for example they can be given a set or names, be associated with a set of tags, or with a set of unspent transaction outputs (UTXO) as proposed in [3] for a blockchain-based DFA. This is enough for the system to work, since the (output of) computation itself is determined by how the system moves between states while it accepts the chain of inputs.

This document is intended to provide an overview on Decentralised Autonomous Corporations (DAC) based on the blockchain technology. Note, Bitcoin is covered by the ticker BCH. BTC is not Bitcoin following the addition of SegWit.