Can we make quasi-classical thermodyanmic observations of the bitcoin network by measuring the inflow/outflow of Heat (Q) and Work (W)? Can we do it from first principles? Is the information gleaned useful at all? This project aims to answer these questions!
Your thoughtful contributions are most welcome!
Change in Internal Energy of an Isolated System (deltaU) = Work In (W) - Heat Out (Q)
.
Here we adopt the sign convention that W
is positive when work is done on the
system, and Q
is positive when heat is released by the system. This is not
necessarily the traditional sign convention, but it may make more sense for our
purposes.
Now, let us translate this over to the realm of bitcoin. We need a way to measure work and heat in a manner which is compatible with the thermodynamic notion of energy. We can accomplish this by re-interpreting the proof-of-work (PoW) information which is included in valid bitcoin blocks. There are multiple such interpretations, but here is one that we will start with:
The idea illustrated briefly in [1] is similar to what we are envisioning here. Specifically, when a new block is mined, we want the effect to be such that the security provided by the PoW is applied to all existing UTXOs instantly and in a fashion such that older UTXOs effectively receive "more" than younger UTXOs (this is what ensures that it is more difficult for miners to rewrite an older transaction than a younger transaction.
Implementing what is contemplated in [1] pre-supposes the notion of "blocks" and uses the "age" of a utxo in blocks (in blocks) as a means for tracking the accumulated PoW to a UTXO. Here, on the other hand, we are trying to take a different approach and keep the thermodynamic accounting at the per-transaction level as much as possible. If succuessful, the thought is that the approach(es) here might be more scalable and implementable since they rely less on global state.
- When a valid bitcoin block, with work requirement
W
is mined, we treat this as if there has been an amount of workW
performed on the system. - We consider the work
W
as spread evenly over the transaction outputs of the block, weighted according to the number of satoshis in the output relative to the total number of satoshis across all outputs in that block. - These outputs, along with the corresponding amount of work for each is included
in the UTXO set. The
W
has crossed over into the system now and is part of the internal energyU
of the system. In other words, each UTXO has associated with it not just the usual properties (number of satoshis, output script, ...), but also an amount of internal energyu
. - When a UTXO with internal energy
u
is spent, we consider the system as releasing an amountu
of heat.
This naive approach allocates work directly to the outputs for transactions within a block. However, in the event that a block has no outputs whatsoever, then there is no way to actually allocate the work, and it is released as heat. This is unsatisfactory, since this completely discounts any additional security that an empty block confers on the state of the system (the UTXO set).
What about transaction fees? There are a number of ways we can handle transaction fees. Here we opt to treat transaction fees as accumulated/retained work by the system. In other words, the amount of energy associated with fees is not released as heat (at least not right now), but is instead accumulated as internal energy of the system. This particular treatment may not be justified, and it may be more realistic to simply also release the fees as heat. As stated above, there are a number of different ways to perform thermodynamic analysis of this system.
- Ignore them and just release the full amount of heat associated with them.
- Transfer the internal energy associated with fees over to the coinbase outputs.
- Pre-proof-of-concept (aka probably broken).
The application currently being built in this repository is very simple:
- use the Nix package manager to install dependencies by first installing Nix and then running
nix-shell -p scala
which will ensure that you have a decent version of scala/java installed - for the build, we use the
mill
build tool Mill Website, which also requires java - a bootstrap script for mill has been checked into the repository already
./mill -i main.run
runs themain
module of thebulid.sc
project (the-i
allows forreadLine
andctrl+C
to work properly)- Reminder: open a local port (
ssh -L 8332:localhost:8332 [email protected]
) so that the app can communicate with your bitcoin full node, and make sure the values inapplication.conf
are correct.
This project takes inspiration from, and is thankful to: ....
[1] PoW as "Gravity" - https://medium.com/@laurentmt/gravity-10e1a25d2ab2
[2] E.T. Jaynes - Information Theory and Statistical Mechanics, 1957 - One of Jaynes earliest papers. The framework of statistical mechanics is shown to be useful for statistical inference in general, possibly even for non-physical systems/processes. [3] John Baez, Mike Stay - Algorithmic thermodynamics, circa 2010-2013, pdf, blog post The model described here is "interesting" but not very similar to what we are contemplating in this project. Nevertheless, the methodology around how it might look to formalize something like this, along with the list of references, is quite helpful.