It isn’t assumed that the “digital prospectus” remains constant throughout the whole lifetime of the “digital financial security”. The “root prospectus” will be included in the root signature block. The implementation will provide a means of recording the “digital prospectus amendments” which in effect will patch the original prospectus. Throughout the lifetime of the “digital financial security” there will be many forks and joins in the DAG (directed acyclic graph) of the prospectuses. The acceptance of forks and joins will be left for the approval of the end user. In case of the competing forks it will be up to the end user to decide whom to trust. The choice needs to be made only when transacting, the peer can participate in multiple simultaneous versions of the amended security. There will be an obvious overhead of the storage and network bandwidth, but the user will not have to make any either-or choices unless actually transacting.

On the network transport layer the peers will locate each other using a DHT (distributed hash table) using both “root prospectus hash” as well as an ordered pair of the “root and amended prospectus hashes”. I don’t envision that the peers in the proposed protocol would need to shun any other peers. The peer-to-peer network will resemble more of Bittorrent peer-to-peer network: all peers share the DHT and make direct connections only when interested in the sharing of the particular torrent.
 
The “digital prospectus” moves the Bitcoin from the equivalent of the “oral contract” to the equivalent of the “written contract”. In the current implementation of Bitcoin there exist an implicit trust in the “core developer team”, their “Satoshi client C++ implementation” and the “consensus of the majority of the miners”. The proposed implementation would spell the requirements exactly and would allow continuing trading of the instruments among those who do not want to trust the consensus of the majority and any future amended prospectuses.

In other words it would change the Bitcoin government from the democracy to the republic.
The last but not least change allowed by the existence of the “digital prospectus” will be the change in scripting engine. Currently Bitcoin uses a simple postfix script language implemented as an automaton with a stack but without loops. The “no loop” requirement was to avoid possibly of attacks by infinite loop. I propose that the same programming language that is used to represent the digital prospectus is used to represent the scripts. If the prospectus writer decides to allow general scripting with looping she can include in the prospectus a relatively simple theorem prover: given the script and N inputs does the script return true or false in at most K*N steps, where K is arbitrary constant chosen by the prospectus writer. This is not a general undecidable stopping problem because the theorem prover can return “undecided within C*L steps”, where L is the length of the script and C another arbitrary constant in the prospectus. The strong syntax and semantic checker for scripts also has obvious benefits for software testing.

(Continued...)

You cannot just make your own BIP and call it 2112. You need to email genjix and he'll assign you a BIP number and help with copy-editing the document. Although first you should email the mailing list with your proposal.

He just did.

Interesting. I've already got this working within our own (not yet publicly released) bitcoin-derived protocol. We also chose LISP as the language for writing "chain definitions", as we call them but I like your phrasing better, as well as replacing the opcode-based scripting system for transactions. We're also using the bittorrent protocol for the P2P overlay network and DHT capabilities, so I can report that works well (and better than bitcoin, I believe, although we haven't the metrics yet). I would add that the prospectus could include rules for accepting or rejecting future modifications. That's how we're handling it, combined with a PKI infrastructure.

It isn't really bittorent versus bitcoin. The early bittorrent implementations had the same problem: you had to run one executable per active torrent and open one port per each active torrent. It is more of a "quality of the implementation" issue.

The discussion why DHT is better than IRC or BT trackers has been done so many times that I won't repeat it here.

Are you planning to patent this?

Can I assume that you are a fan of the Canadian rock band Rush?




Cheers,

Ian.

Thank you for your valuable input.

• It bloats all future client implementations with a complex interpreter

The LISP interpreter is probably 2nd or 3rd smallest interpreter possible: smallest is MUMPS, LISP and Forth vie over the 2nd and the 3rd position. BASIC and Javascript are for sure bigger and more complex than LISP. I still think that LISP with a lean theorem prover as a checker is a better choice than a C++ implementation of an RPN calculator and Gavin's wish for a fuzzer to thoroughly test that calculator.

• raises the bar of transaction rule-verification to the mathematical elite

This is very true. However in 21st century this elite no longer have any financial barrier to entry. The required curricula are available for free online, e.g. http://mitpress.mit.edu/sicp/full-text/book/book.html . The other important observation of the elitism of LISP are the original Yahoo! stores. They were all created with LISP back end. They came out as one of the first e-commerce platforms, were always very secure (anyone heard about any exploits for Yahoo! stores?) and had one of the lowest barriers to entry.

• encourages closed source clients

This point is both true and false, depending on the timeline. Lets compare Bitcoin implementation to the web browsers. Currently Bitcoin is in the stage of NCSA Mosaic. Then Netscape Navigator became a de-facto leader by including a client-side interpreter, among other things. Then the whole web exploded and we now have competing open and closed source implementations.

• further strongly couples the protocol to the default client

Initially probably yes. It really raises the barrier to entry for less-than-competent software vendors. I personally think that this will be a good thing: the quarter-brained client implementations are a plague in the Bitcoin-sphere. Later on the things will change: if there's at least one client that is fully ACID and embeddable then the overall software quality expectation will rise to the level demanded by the serious financial applications.

• removes the ability for the block chain to fork in a democratic manor

This is simply untrue. My BIP actually encourages forking and provides tools to do it in a very safe manner. It also facilitates re-joining of the forks that a willing to do so. It supports all forms of self-governance: democracy, republic, autocracy, corporatism, etc. It all depends on the contents of the initial prospectus.

• No matter what I need to edit my BIP to improve its readability

One thing that needs to be repeated: this BIP isn't an urgent thing. It just shows one possible way forward for Bitcoin. I don't expect it to receive any significant attention until at least one or two knees in the coin-generation curve are behind us.

Actually this sounds like an excellent idea. How much sense would it make to further expand it in order to mix bitcoin-securities straight in the blockchain?

I had a hard time determining from the proposal what problem it was intended to solve.

I also was unable to find where it defines the jargon and neologisms it uses.  To most people, a "digital prospectus" is a document that describes a financial security for potential buyers, available as a PDF download.  It is apparent that this isn't the intended meaning here, and the proposal lacks a definition for what alternate meaning should be understood for this term (as well as numerous other terms).  An improved revision to this proposal would spend its first paragraph concisely describing the benefit expected to be derived from considering the proposal beyond anticipated usefulness in hypothetical patent litigation.