Today, the blockchain space was rocked by a release from the 'Financial Crimes Enforcement Network' (FinCEN), a U.S. government agency that presides over financial transactions (specifically).
For reference, the full text of the proposed order can be found here: https://public-inspection.federalregister.gov/2020-28437.pdf
Reviewing the Text of the Order
Many of the important statements from the order will be re-quoted in this article verbatim for the sake of ensuring that users have an understanding of what the order *
actually states before receiving an interpretation of it.
While Librehash finds FinCEN"s actions to be a gross overstep, it is more than possible that the reader may disagree. And that's okay. So rather than tilting / spinning the narrative on the situation, we're going to dig into the "raw meat" of the order.
Below is the first part of the summary:
"FinCEN is issuing this notice of proposed rulemaking to seek public comments on a proposal to require banks and money service businesses ("MSBs") to submit reports, keep records, and verify the identity of customers in relation to transactions involving convertible virtual currency or digital assets with legal tender status ('legal tender digital assets' or 'LTDA') held in unhosted wallets (as defined below), or held in wallets hosted in a jurisdiction identified by FinCEN. FinCEN is proposing to adopt these requirements pursuant to the Bank Secrecy Act ('BSA').
To effectuate certain of these proposed requirements, FinCEN proposes to prescribe by regulation that CVC and LTDA are 'monetary instruments for purposes of the BSA. However, FinCEN is not proposing to modify the regulatory definition of 'monetary instruments' or otherwise alter existing BSA regulatory requirements applicable to 'monetary instruments' in FinCEN's regulations, including the existing currency transacting reporting ("CTR") requirement and the existing transportation of currency or monetary instruments reporting requirement."
What's written above is a ton of legalese, but the most important thing for us to get an understanding of is the concept of "unhosted wallets".
FinCEN Inaccurately Characterizes the Actual Blockchain Transfer Process
When the request for comments do open, Librehash will be front and center to request that FinCEN strongly reconsider their stance on this proposed rule for no greater reason than the fact that it appears that they do not have a comprehensive understanding of how Bitcoin works, which is made evident further on in the proposed ruling under the 'Technology Overview' section.'
Under this section, it is stated:
"CVC is a medium of exchange, such as a cryptocurrency, that either has an equivalent value as currency, or acts as a substitute for currency, but lacks legal tender status. Blockchain-based types of CVC are peer-to-peer systems that allow any two parties to transfer value directly with each other without the need for a centralized intermediary."
So far this description of Bitcoin is accurate enough.
But from this point onward, it gets extremely shaky.
Inaccuracy Number One
*"As a technical matter, blockchain-based CVC generally consist of computers operating the network software (nodes) that enable, and store transaction records on a distributed ledger (a blockchain)."
Sorting the Inaccuracies:
- There is more than one 'network software' (known as a client). The reference implementation is Bitcoin Core, but there are other clients that can be used (while remaining compatible with the broader blockchain network.
- Stating that the nodes store the transactions on a distributed ledger is a bit of an awkward way to explain how this process is conducted. Miners aggregate a certain number of transactions into a 'block template', then compete to see who can find the nonce value the quickest. The "nonce" is a special number that, when hashed the aggregated transactions in a 'block template', produce an output value that is below the "target". When a miner discovers this value, they broadcast their block with transactions as well as the correct nonce value to the network with nodes. Those nodes then assess whether the submitted block is "correct" (i.e., the transactions are valid, contain the correct nonce value and also represent an extension to the chain with the greatest known Proof of Work). Each node stores their own copy of the blockchain on the basis of what information is known to them on the network.
Following point #2, there is nothing within the description by FinCEN that mentions the act of mining on the network - which is a critical part of the functionality of blockchain.
Inaccuracy Number Two
"To transfer an asset on a blockchain, a person enters an alphanumeric code known only to the transferor (a private key) into a cryptographic hash function enabled by network software, which allows the transferor to request that the network software validate a new entry on the ledger showing that control of an asset has been assigned to the recipient. Once the network has validated this transfer, the ledger is altered and the recipient may transfer the asset to another recipient using their own private key."
There are an astounding number of inaccuracies in this description from top to bottom that must be corrected if FinCEN expects to create a coherent enforcement regime that must be followed by all participants in the digital currency space.
The first sentence in this section states, "To transfer an asset on a blockchain, a person enters an alphanumeric code known only to the transferor (a private key) into a cryptographic hash fucntion enabled by the network software."
This is completely inaccurate.
- To begin, the process of crafting a transaction is entirely stateless. That means that one can craft a transaction offline (rather than connecting to the network).
- In addition, the only information that is necessary for a transaction to be crafted are the outputs (who the funds are going to), as well as the inputs (who the funds are coming from).
- Once this information has been put added, the transaction itself gets hashed with SHA256 to form a transaction ID.
To demonstrate the inaccuracy of FinCEN's statements regarding how transactions are sent, we decided to manually craft one on the internet using the tool 'coinb.in' (this is a website; https://coinb.in).
Upon visiting the website, we selected the option to create a new transaction by clicking the 'new' tab at the top of the page and scrolling down to transaction:
Upon clicking on this button, we were brought to the following page:
As the page's prompts suggest, one can provide an address in the omnibox depicted in the middle of the screenshot above (underneath where it says, 'Address, WIF key, Redeem Script, or Transaction ID').
Luckily, we have a Bitcoin address on hand with a nominal amount fo funds on it still (a little under $2, so not too much).
The address is: 17cJJPF1J7SGHAjmrHg51ZeV2HPehTU8c
Let's see what happens when we enter that address into the omnibox above:
Awesome, mission success.
We're natural jerks so we're going to waste everyone's time by crafting a transaction directly to ourselves (with no fee attached):
Then hit the submit button, which should generate a transaction ID for us:
For the record, that transaction ID = 01000000013f36c71f3bc3c8674....63647cd38c88ac00000000 (truncated for formatting purposes)
Now, we could broadcast that transaction to the network at this very point in time - but the transaction would not be accepted because the transaction does not have a signature attached to it (and there's also no fee on it, qualifying it as spam / dust).
Why Would a Signature be Mandated?
A signature is necessary in this instance because of the type of address that is holding the funds. This is not a mandatory feature of the blockchain, however as the FinCEN descriptoin suggests - but rather a default.
What we're doing in creating an address is manifesting an encoded set of conditions that must be adhered to in order to spend the relevant funds.
Those conditions are enforced by a set of 'op_codes' (which are attached to every transaction). These op_codes create a mini-finite state machine that executes without loop with a definitive "ending" that is resolved when the stack either pushes 'true' or 'false'.
A list of potential op codes that can be used with each transactoin can be found on the "Bitcoin Wiki" here: https://en.bitcoin.it/wiki/Script#Opcodes
These op codes can generate some curious results when arranged in a certain manner and there is a considerable amount of flexibility that Bitcoin users have to do so.
The actual script itself runs with a stateless execution (again, this is a finite state machine) that cannot be interrupted before its conclusion.
It is up to the prospective spender to provide an input into the Script operation that will result in a "true" being pushed to the top of the stack at the conclusion of the script's execution.
Below is a visual example of this process:
Panning Back to the Inaccuracy of the FinCEN Statement
In light of all that was mentioned above, it is clear that FinCEN is way off base by stating:
"To transfer an asset on a blockchain, a person enters an alphanumeric code known only to the transferor (a private key) into a cryptographic hash function enabledo by the network software..."
The "code" does not necessarily need to be alphanumeric (assuming that they're referring to a compressed private key here?)
Nothing is entered directly into a cryptographic hash function. By virtue of the address where funds have been spent to (i.e., the address holding the unspent funds), there are certain conditions that are imposed upon the would-be spender that can vary significantly from one transaction to the next and is in many ways arbitrary. In order to "spend" the funds, the user must provide an input into the Script function (directed by the wallet address itself) that results in the executed script pushing a "true" to the stack. Notably, the sender of the transaction does not execute this function, but rather the miners do in order to ensure that the actual transaction is a valid spend before including it in a block template.
This is a stateless, offline process - not one that is enabled by the network software and this process is not what "allows the transferor to request that the network software validate a new entry on the ledger showing that control of an asset has been assigned to the recipient."
Inaccuracy Number Three
Let's double back to the last couple of sentences by FinCEN where they state that:
"To transfer an asset on a blockchain, a person enters an alphanumeric code known only to the transferor (a private key) into a cryptographic hash function enabled by the network software, which allows the transferor to request that the network software validate a new entry on the ledger showing that control of an asset has been assigned to the recipient."
Specifically, in that last part (bolded above), there are a number of inaccuracies (in addition to the ones that were isolated and corrected in the previous section), that must be addressed before we can even assess the merit of the proposal by FinCEN.
A) One does not "request that the network software validate a new entry on the ledger", because no requests are made. Rather full nodes broadcast crafted transactions to other nodes that they are connected with on the network. Those other nodes may also choose to accept that node into a 'waiting area' called a "mempool" (memory pool) until their status changes. The state of these transactions has not changed. As more blocks are appended to the network, miners may or may not elect to include that prospective transaction into their block template. Therefore, unless one of these mining entities is contacted with a direct request to include a specific transaction in one fo their blocks, there is no way to specifically "request" that the network "validate a new entry on the ledger showing that cointrol of an asset has been assigned to the recipient."
B) There Are No Recipients: Once again, this concept is a difficult one for many to wrap their heads around, but there are no concrete recipients on the blockchain due to the nature of how Bitcoin and cryptography both work. As stated earlier, every transaction is spent to an output address that, in itself, is a set of conditions for the spending of those funds.
In most cases, yes, the condition to spend the funds is for one to provide a public key that matches a certain pre-determined output when hashed with SHA256, with that output being hashed once more with ripemd160.
Once that process has completed itself, a signature must be provided (which can only be curated via the private key) that, when analyzed against the public key, provides a "match" (i.e., confirms that the signature was generated by the private key associated with the aforementioned public key that needed to have its sha256 hash output hashed with ripemd160).
Confusion on the Part of FinCEN is Understandable
It is absolutely understandable if FinCEN fails to wrap their heads around Bitcoin in its entirety at this current point in time as it is a very complex concept.
But attempting to pass sweeping legislation / restrictions on the usage of Bitcoin without adequate knowledge of how the technology works is simply inexcusable and, objective speaking, creates a significant risk of them only exacerbating the problem that they are attempting to solve as a result of the significantly increased propensity for them to craft a proposal that inadequately addresses the matter at hand - resulting in legitimate users of blockchain being punished while the criminals / terrorists whom FinCEN wishes to truly target, end up "getting away" or finding further loopholes in the weak language in their report.
Inaccuracy Number Four by FinCEN
Not sure what number we're on at this point, but we're going to plow through the entire proposal if need be, because it is important that someone does so (for the reasons stated above).
At the end of the 'Technolog Overview' passage, FinCEN states:
"Ledger entries are cryptographically secured, and accounts are identified on a blockchain by alphanumeric 'public keys' - not by the owner's name"
Again, this is not entirely true.
In fact, recently Librehash published research on its blog that showed users how to craft a Bitcoin address from an arbitrary word - making the effective equivalent address that was created just a "hashed output" of the original word that we used (librehash).
That report can be found here:
This proves (once again) that FinCEN's description of wallet addresses on the blockchain is wholly inaccurate and puts their true understanding of how blockchain works into serious question.
Given the importance of this proposal, there will be significantly more information, thoughts and ideas dumped on this topic, which will ultimately be sent over to the EFF as well as the ACLU to assist in our fight for ensuring the privacy rights of all those in the blockchain space.
What FinCEN is proposing is draconian, at best. The reasons given for doing so seem flimsy, especially in light of the restrictions that are already in place for cryptocurrency exchanges (i.e., they must register as an MSB in order to conduct business in the United States).
In many ways, it seems like the United States is attempting to make up for its half-hearted attempts to regulate the blockchain space when they had a chance to do so years earlier by passing down heavy handed legislation that they believe will solve the problem of "financial terrorism" (or whatever they're describing it as now).
But when considering the fact that FinCEN failed to demonstrate an adequate knowledge of the basic principles of blockchain technology throughout the first part of their proposal, one must question whether they're even in the position to draft any sweeping proposals regarding the nature of Bitcoin and blockchain.
Librehash will be on the front lines to fight this absurd government overreach as hard as possible. And if we do not prevent the proposal, then we'll take the case to the Supreme Court if need be.