BIP 2112

[2112]

I also was unable to find where it defines the jargon and neologisms it uses.

Yeah, you are 100% right. As written the document pretty much assumes that the reader has a Master of Science in Computer Engineering or equivalent and some past experience reading patent applications in the relevant field.

The more plain-spoken description of "digital prospectus" is: a cryptographically signed machine-executable description of the rules of the block validity. As opposed of the solemny sworn human-language statements of the core development group that they aren't going to materially change the rules for the valid blocks.

As with all "far-looking forward statements" the readability here is low. But the law is what it is and readability comes second after unambiguity.

I'm planning to re-edit the document in the future, once I collect enough feedback how to do it without transoforming it into a meaningless marketing drivel. It isn't an offer to sell anything.

Edit: and by the way, here's the pointer with explanation why it stays 2112 as opposed to the number that it go assigned.

https://bitcointalk.org/index.php?topic=61575.msg723630#msg723630

[casascius]

I also was unable to find where it defines the jargon and neologisms it uses.

Yeah, you are 100% right. As written the document pretty much assumes that the reader has a Master of Science in Computer Engineering or equivalent and some past experience reading patent applications in the relevant field.

If you only want comments, suggestions, and ridicule from others with the same particular degree and experience, you ought to consider adding those specific qualifications to your signature line directing us here so that others outside of your assumed audience don't have to waste their time with it.

Little old lowly me, the main ridicule I'd have to offer is that your ability to convey ideas in written form sucks balls and is definitely not on par with the technical aptitude you claim, and that your principal point you seem to be looking to make (if your insistence on a vanity BIP number doesn't make that strikingly clear) is that you consider yourself a badass.

[Bitcoin Oz]

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.

[Bitcoin Oz]

You might have something there but I didn't really understand it at all.

Any chance you could describe what you want to achieve in a simpler style ?

I assume he means a prospectus embedded in the genesis block. So a new block chain would be a sort of IPO with the contract locked in  forevermore.

[2112]

I assume he means a prospectus embedded in the genesis block. So a new block chain would be a sort of IPO with the contract locked in  forevermore.

Well, not "locked forevermore". The only thing locked like this is "root prospectus". Every implementation would need to support "prospectus ammendments" that form tree branches. So every "digital security" is defined by a pair (hash(root prospectus),hash(tip of branch steming from the root)).

http://en.wikipedia.org/wiki/Tree_(data_structure)

Edit: I guess the point of this can be summarized: it makes the changes to the algorithms explicit and verifiable in linear time, very much like git does to any general source code.

Edit2: Also, like git and like normal securities exchanges this will allow for orderly and verifiable backtracking and reversal, once the "economic majority" decides that certain branch of the prospectus was erroneous, fraudulent or otherwise undesired.

[marcus_of_augustus]

The choice of the programming language for the “digital prospectus” needs to be made early. The primary requirement is that the language needs to have very strong theoretical underpinnings: it must be able to efficiently express its own interpreter and there must be existing programs that are capable of proving simple theorems expressed in this language.

The more plain-spoken description of "digital prospectus" is: a cryptographically signed machine-executable description of the rules of the block validity. As opposed of the solemnly sworn human-language statements of the core development group that they aren't going to materially change the rules for the valid blocks.

Just musing if Coq, Haskell or even Fortran are worth a look ...

[MPOE-PR]

If you only want comments, suggestions, and ridicule from others with the same particular degree and experience, you ought to consider adding those specific qualifications to your signature line directing us here so that others outside of your assumed audience don't have to waste their time with it.

Little old lowly me, the main ridicule I'd have to offer is that your ability to convey ideas in written form sucks balls and is definitely not on par with the technical aptitude you claim, and that your principal point you seem to be looking to make (if your insistence on a vanity BIP number doesn't make that strikingly clear) is that you consider yourself a badass.

Ah come now, it's not that bad is it.

[2112]

Just musing if Coq, Haskell or even Fortran are worth a look ...

Another proposed language was Lua. Apparently it rapidly spreads in the computer science departments in Latin America. Unfortunately I'm illiterate in both Portugese and Spanish, so I can't read the most recent research papers.

[2112]

Ah come now, it's not that bad is it.

I took "suck balls" as a sort of backhanded compliment from Casascius. If he really wanted to put me down, he would've written e.g. "sucks dead Easter bunnies through a bent straw" or "could suck-start a Harley through the exhaust pipe."

English is a virtual minefield of smoothly readable, but ambiguous sentences, e.g. pharmacist dispensed with accuracy.

[aantonop]

I suggested recently that the 8.1 patch be evolved (which hard codes certain parameters for all clients), is evolved into a schema validation engine for the protocol and transactions, so that the behavior of the node and client has prescribed and defined edges, defineed by a computable  definition.

Different words form yours, same basic concept - a core interpreter that validates protocol and transactions and is the agreed, reference, signed implementation that is authoritative for testing, QA, interop and attestation of client validity.

[Un zafado cualquiera]

if it comes real, I up vote for lisp...not like emacs one but a Foss one

[kingcoin]

if it comes real, I up vote for lisp...not like emacs one but a Foss one

Emacs is FOSS. However, I would never write software in elisp other than simple utility snippets for use in Emacs. There are several FOSS Common Lisp implementations available. Personally I prefer SBCL. Common Lisp is an ANSI/ISO standard so you don't get into the creeping featurism that you have in many of the dictator languages, like Python (where the semantics suddenly change even though the syntax is the same). Lisp was a dictator language in 1958 but became a standard in 1994.

But why an interpreter? There are quite a few open source Common Lisp compilers out there. Of course they also include an interpreter and compiler since you at any point can dynamically build a s-expr and call eval (eval (cons '+ '(1 2 3))) or even (progn (defun somefun () (+ 1 2 3)) (compile 'somefun) (list (somefun) (compiled-function-p #'somefun)))

When writing Lisp code is quite common to design a domain specific language (DSL) on top of Common Lisp to fit the problem domain. Macros are quite handy in this process. Then you describe the problem using the DSL.

There are some open source Common Lisp based formal tools available, like ACL2: http://www.cs.utexas.edu/~moore/acl2/ ACL2 was used by AMD to prove the floating point operations in some earlier CPU design, etc. A quite fascinating piece of software IMHO.

[tromp]

What you have in mind is being realized by tauchain

https://bitcointalk.org/index.php?topic=950309.0

[2112]

What you have in mind is being realized by tauchain

https://bitcointalk.org/index.php?topic=950309.0

No, really no. The similarities are superficial only.

To clarify the difference I'm saying that this project/idea is scoped to be fully implemented in approximately 1MB of executable code. Somewhat limited implementation could probably be made on the historical CPUs like Intel 8086 or Hitachi HD64180. Fully featured implementation will for sure fit in a CPU with 16MB of address space like Intel 80286 or Zilog eZ80 (the new one, not the historical Z80) or the modern compatibles to the historical PDP-11/LSI-11. Basically any CPU supporting multiple banked/segmented 64kB address spaces is the satisfactory target.

The segmented/banked 16-bit-ness is not a requirement. The implementation could as well use the modern flat 32-bit or 64-bit addressing. However it is my experience that explicitly segmented 16-bit address spaces are a great aid in enforcing security and safety of the code. They are also aids in mechanical proving of the code correctness (even if only partial proofs).

I'm not actually advocating the use of those historical CPUs running with clocks in the single MHz range. I'm thinking of drop-in cores to be synthesized using modern FPGA or ASIC processes with the modern clock rate of high hundreds of MHz . The physical package of such cryptographic kernel device would be similar to the (nano-)SIM card or (micro-)SD card.

The supporting blockchain data is a different story. It would have to be either local storage in the present terabyte ranges or a networked access to the remote storage at single megabits per second speeds.

Edit: Anyway, I've read the tauchain whitepaper as well as all the 18 pages of the tauchain thread with interest. Thank you very much.