User:Airbreather

My name is Joe Amenta.

Evercoin

At the time of writing (2014-03-10), I am working on yet another alternative Bitcoin node implementation on the called Evercoin. It's written in C# and runs on the .NET Framework. Please don't use it yet until I formally announce it somewhere; right now, it's just a WIP, and I'm still unsure if I'm ever going to finish it.

The core aim of this project is to provide a flexible and extensible set of abstractions that separate out the different responsibilities of a cryptocurrency application into well-defined pieces. In doing so, I intend to enable a heterogenous system capable of using the best available implementation of each of the subsystems and allow them to be wired together to produce something that's at least as good as the sum of its parts.

A few exciting consequences:

• Once Evercoin is feature-compatible with Bitcoin-QT, then it would be feasible for someone to develop some sort of hardware device that can sign transactions, then implement the appropriate Evercoin interfaces (e.g., "here's the list of public keys whose private keys I can prove ownership of" / "sign this data using the private key for this public key"). The end user could then just drop the corresponding DLL files in the Evercoin "signer-plugins" folder, plug their device into a USB port, and then the client would operate exactly as though the user had the key stored in their wallet.dat file.
• If I end up coming up with the right abstraction, developers could experiment with innovative ways to prune the data stored in the blockchain that is overkill for the actual work that is intended to be done by the node.
  • Here's an intentionally contrived example of why this might be useful. I picked it not because it's realistic, but rather because it helps illustrate how my dream of Evercoin can be used in situations other than intended, and without requiring the user to fork and rewrite the software to meet unanticipated needs.
    • Suppose a hypothetical merchant has some strange accounting requirement that all transaction inputs must be traced all the way back to the generation transaction. Suppose further that this merchant is allowed to trust a third-party oracle that is able to identify utxos that will definitely not show up in inputs in the future.
    • That merchant would only need to implement the Evercoin interface that corresponds to "pruned blockchain storage", or maybe even just "something that can identify prunable transactions". The storage cost would still be much more than SPV because of the traceability requirement, but less than the cost of a full node. In fact, it could even be cheaper than running a node that prunes provably unspendable utxos: the third-party oracle could be an external service that specializes in maintaining a list of utxos that are "for all intents and purposes unspendable", which is a superset of "provably unspendable", but also includes coins that are probably unspendable based on perhaps reports of lost wallets.
    • We can argue all day about whether or not it's reasonable in the general case to just take such a third-party's word for it that these outputs will never show up as inputs we can spend, but at the end of the day, if the combined costs of implementing this sub-system in Evercoin, hiring such a third-party to do the pruning, and third-party incorrectly pruning a utxo (weighted by probability of this event occurring) are all less than the minimum cost of either running a full node or modifying non-Evercoin software to do what is needed, then the difference is Evercoin's value-added.