Our recent press releases have unfortunately created a lot of attention and noise, which has been focused on Dr Wright and our research team. This is not what we wanted, our team prefers to quitely focus on technical research. We have created this blog to focus on our advanced research, away from all the noise.

Videos of our chief scientist Dr Wright announcing a series of important technical breakthroughs

30th June 2017

Bitcoin’s creator, the legend, Satoshi Nakamoto, is back

The kind message does not extend to everyone - “Some of those will discover the legal consequences very soon”, “Unlike Core, unlike Blockstream, I am not going to shove shit down your throat and make you eat it”

New technical breakthrough: “Reverse the maths” - Transaction malleability is not an issue, however this can be solved by generating an address before generating a public or private key, due to the magic of ECDSA

Dr Wright explains the flaws in payment channels with a brilliant analogy about carrots

SegWit is illegal in the United States for transactions above $500 and anyone running SegWit enabled clients, which illegally removes the signature from transactions, could potentially be prosecuted

20th June 2017

Our technical experts have been reviewing SegWit, in collaboration with our legal scholars. Today, hoaxChain can exclusively reveal that our experts have conclusively determined that SegWit is illegal.

Our technical computer science engineers have determined that SegWit separates the signature from the rest of the transaction data, and our legal scholars have confirmed that this means the remaining data (without the signature) is potentially illegal. Anyone using SegWit, or even running a SegWit client, that separates signatures from transaction, could be prosecuted and convicted of criminal offences.

Firstly, we examined the technical details of SegWit. SegWit is a new technology, which will remove the signature from Bitcoin transactions and allow the distribution of Bitcoin transactions without a signature. This is a nasty trick involving anyone can spend transactions. This results two separate pieces of data, one containing the transaction and another separate piece of data containing only the signatures. This makes it possible that the signatures could go missing, be replaced by faulty signatures, or even become stolen. Even if none of these issues occur, the signature is still separate from the rest of the transaction. Anyone running a SegWit client, such as Bitcoin Core, is actively participating in the separation of the signature from the transaction.

Our legal scholars have been examining the law in respect of the requirement for signatures, when conducting business. As the below text shows, a signature is required for all sales contracts over $500, or the transaction cannot be enforced and is potentially illegal:

§ 2-201 - Formal Requirements, Statute of Frauds
Except as otherwise provided in this section a contract for the sale of goods for the price of $500 or more is not enforceable by way of action or defense unless there is some writing sufficient to indicate that a contract for sale has been made between the parties and signed by the party against whom enforcement is sought or by his authorized agent or broker
Source: Cornell

Therefore SegWit transactions cannot be used for a purchase with a value over $500, otherwise the sale is invalid and not enforceable by the law. However, it gets even worse than this, if anyone uses a SegWit transaction to buy goods for a value over $500, then anyone running a SegWit enabled Bitcoin node will automatically separate the signature from the transaction. This is a more serious offence than merely sending a SegWit transaction for over $500, as this actually makes a legal transaction with a signature, illegal, by removing the signature.

Therefore, anyone running SegWit enabled Bitcoin nodes is taking significant legal risk. All an “attacker” needs to do, is purchase one item over $500 with a SegWit transaction and then all SegWit node operators would be breaching the law, and liable to prosecution in the United States. For this reason, here at hoaxChain, we strongly oppose the ability to use SegWit on Bitcoin and our legal team strongly advises against anyone running SegWit enabled software.

Appeal to authority: A failure of trust

8th May 2017

Today we provide a detailed analysis of the Appeal to authority: A failure of trust paper. The author of this paper is anonymous, however we have reason to believe it may have been written by our CEO and founder, Dr Wright (this is an unofficial comment). This is a very advanced and sophisticated piece of research, involving study in new areas at the forefront of cryptography and mathematics.

The paper discusses one of the four PGP keys in the Tulip Trust document, in particular the signature belonging to our founder, Dr Wright. The PGP key is dated from 2008, however, Mr Maxwell has claimed that "The PGP key being used was clearly backdated: its metadata contains cipher-suites which were not widely used until later software". The research aims to disprove what Mr Maxwell said. Before proving Mr Maxwell wrong, the paper explains that one should not trust Mr Maxwell, but instead verify for oneself, otherwise one is falling for the appeal to authority fallacy. Indeed, "appeal to authority" is the title of the paper. As the document says:

The logical fallacy of an appeal to authority is made whenever we try to justify an idea through the citing of expertise as the reason to hold that idea. However, even experts are subject to validation. The nature of science is of a system derived through empirical proof and evidence. Generally, an appeal to authority is fallacious when we cite those who have no special expertise. This is of greater concern when we have an individual believed or purporting to be an expert who abuses trust.

The importance of this statement is that Maxwell has firmly asserted that the algorithms, “8,2,9,10,11” have only been added from a later period in 2009. It is stated that the code tree was built on the 09th July 2009 and that this was released on the 04th September of the same year. The challenge to the reader is to engage in an independent scientific examination of the evidence presented.
Changes to the default hash algorithm preferences - 9 July 2009

- /* SHA-1 */
-    strcat(dummy_string,"H2 ");
-    if (!openpgp_md_test_algo
-    (DIGEST_ALGO_SHA256))
-    strcat(dummy_string,"H8 ");

+ /* The default hash algo order is:
+ SHA-256, SHA-1, SHA-384, SHA-512, SHA-224.
+ Ordering SHA-1 before SHA-384 might be
+ viewed as a bit strange; it is done because
+ we expect that soon enough SHA-3 will be
+ available and at that point there should
+ be no more need for SHA-384 etc.  Anyway
+ this order is just a default and can easily
+ be changed by a config option.  */
+    if (!openpgp_md_test_algo
+    (DIGEST_ALGO_SHA256))
+    strcat (dummy_string, "H8 ");
+    strcat (dummy_string, "H2 ");
+ /* SHA-1 */
+    if (!openpgp_md_test_algo 
+    (DIGEST_ALGO_SHA384))
+    strcat (dummy_string, "H9 ");
+    if (!openpgp_md_test_algo 
+    (DIGEST_ALGO_SHA512))
+    strcat (dummy_string, "H10 ");
+    if (!openpgp_md_test_algo 
+    (DIGEST_ALGO_SHA224))
+    strcat (dummy_string, "H11 ");

- /* RIPEMD160 */
-    if (!openpgp_md_test_algo
-    (DIGEST_ALGO_RMD160))
-    strcat(dummy_string,"h2 ");

Source: gnupg

Indeed, one should not trust Mr Maxwell, but instead the claims should be verified. As shown above, the default hash algorithms were actually added in July 2009 as Mr Maxwell claimed. By reading the above code you can verify this for yourself. Therefore, although our advanced scientific research suggests that the appeal to authority fallacy is a genuine thing, it happens not to be relevant in this case. One may then question the title of this paper, which after reading the above code, almost seems to be a completely stupid title.

However, although Mr Maxwell was correct about when the algorithms were added to the software, he is still wrong in saying that the key was backdated. As the paper goes on to explain, in 2008 one could still have manually changed the hash functions used to the ones which were specified at a later date, as the default algorithms. Actually all the hash functions specified in 2009 were available in 2008, the paper even provides complex research and analysis proving these hash functions were published as far back as 2007, which is earlier than 2008 , when the key was generated. To further prove this is possible, the paper even provides screenshots which involve changing the preferred hashing algorithms to the ones specified in 2009, with a version of software from 2008. As the paper explains:

Returning to our example, we can issue the “setpref” sub-command at the command line. This allows the owner of a PGP private key to change the set of hash algorithms used by the key. This change is completed using the following command:

> setpref SHA256 SHA1 SHA384 SHA512 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed
hoaxChain can now reveal this amazing sequence of events. For some reason, when creating his PGP key in 2008, Dr Wright manually changed the hashing algorithms used by the software. Then, in a remarkable coincidence, in 2009, the default hashing algorithms for this piece of software happened to change to the ones Dr Wright manually specified a year earlier, including in the exact order Dr Wright used. This is even more of a remarkable coincidence, given that the notes made when the change occurred in 2009 mention that the hashing order "might be viewed as a bit strange". The above implies that Mr Maxwell is wrong and therefore either he is a liar or he is incompetent, or as the paper brilliantly puts it:

We may either conclude that Gregory Maxwell understood what he was asserting and has intentionally misled the community in stating that the PGP keys referenced had been backdated, or that a Bitcoin core developer did not understand the workings of PGP sufficiently.
Statistical analysis of the probability of this coincidence occurring
Now lets move on to some statistical analysis and asses the probability of this coincidence occurring by chance. Let us assume the following:

1. Dr Wright could chose between any of the 7 hashing algorithms listed here;
2. That each algorithm could only be used only once;
3. The number of algorithms chosen could have been between 2 and 7;
4. For some unknown reason, Dr Wright was determined to change the algorithms from the default ciphers.

Therefore, the number of combinations that that could have been chosen is given by the following formula:

  7! + 7!/(7-6)! + 7!/(7-5)! + 7!/(7-4)! 
  + 7!/(7-3)! + 7!/(7-2)! = 13,692

The probability that the chosen algorithms coincided with the ciphers eventually made default, is 1 in 13,692. An incredibly remarkable coincidence.

Explanation for the double hash used to generate for Bitcoin addresses

4th May 2017

For years Bitcoin experts have been baffled as to why the system uses a double hash to generate an address. Finally, our CEO and chief scientist Dr Wright provided a detailed mathematical explanation. Unfortunately it is a bit complicated, so we will need to go into code mode.

Hypothetical example of a collision



In the above example, two different inputs were hashed, but unfortunately there is a collision, which can have very dangerous consequences on the Bitcoin network.

Example (continued) of a how a double hash solves the collision problem



As can be seen above, the double hash has avoided the collision, which is no longer feasible. It is difficult to provide a full technical explanation for how this works here. However, it can be thought of like rolling a dice. When rolling a six sided dice twice, the probability of getting the same number is quite high. However, if one rolls a dice twice twice, one is much less likely to get the same numbers each time. More randomness is added to the thermodynamic system, which reduces the chance of collisions.

As Dr Wright himself succinctly put it:

More, the double hash means that the input to the hash needs to be of a set size. The collision problem allows for scaled solutions. A double hash reduces the input to a hash and makes collisions infeasible
Source: Pastebin

Advanced technical note
It has been pointed out, by one of our technical scientists, that Bitcoin may not actually use double sha256 to generate addresses, but instead uses two different hash functions, sha256 and RIPEMD160. One of our main areas of research going forward will be to try and establish if the advanced double hashing mathematical wizardry explained above, still applies, if two different hash functions are used.

Update on technical terminology and when to use the word "node"

4th May 2017

When Bitcoin was first released, there was only one client. Since there was only one client and therefore one type of node, it was not necessary or meaningful to always draw a distinction between the different types of nodes. Since then node types can be catagorized in various ways, for example:
  • Nodes which try to produce blocks (Mining nodes)
  • Nodes which download all the blocks and data, verify all the rules and relay the blocks to others
  • Nodes which download all the blocks and data and verify all the rules, but no not relay the blocks or transactions to others
  • Nodes which do not download all the block data and only verify a subset of the rules (Light nodes)
  • For some reason, it is now very important to change the terminology and the word "node" should ONLY ever be used to describe a computer connected to the network which is trying to make blocks. If people stop using the word node as a generic term to describe any computer connected to the Bitcoin peer to peer network, this may magically help scale the network and increase the blocksize limit, which is urgently needed. As Dr Wright himself put it:

    Miners are nodes. Nodes are miners. There are NO full non-mining nodes.
    Source: Pastebin

    All computers and software connected to the Bitcoin network, which do not produce blocks, must now ONLY be referred to as "wallets".

    The issue of whether "Scronty" masturbates or not

    4th May 2017

    One of the big challenges facing the Bitcoin community, has been establishing whether of not "Scronty" masturbates. After years of waiting, our CEO and chief scientist Dr Wright, finally revealed that, Scronty does indeed masturbate. As he simply put it:

    Scronty is a wanker
    Source: Pastebin