Topic: BIP 2112 (Read 11905 times)

Of course he can. :b he is legendary

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.

What you have in mind is being realized by tauchain

https://bitcointalksearch.org/topic/tau-chain-and-agoras-official-thread-generalized-p2p-network-950309

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.

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

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.

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.

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.

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

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

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.

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.

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.

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://bitcointalksearch.org/topic/m.723630

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.

I don't think that the extension would be needed. Bitcoin-denominated-securities could be supported with just a separate "digital prospectus". Such a prospectus could even do cross-blockchains validation to support truely atomic transactions.

But again: this is a long-term proposal. Lots of water will have to flow in the Alpheus and Peneus rivers to clean filth from the Augeas' stables of cryptocurrencies.

Thank you all for your comments.

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?

Sorry for the necro-thread, but this is an interesting proposal that I hadn't noticed before.


Bitcoin has never really been a democracy, even though it has democratic aspects.  "Demos Kratos" means "people power".  In Bitcoin, the end-users don't have a vote;  only miners do.  So the average people are disenfranchised.  Fiat currencies like the US dollar are, on paper at least, more similar to democracies, with a set rate of inflation tied to population growth effecting wealth redistribution, and with the banking system acting as very corrupt election organizers to distribute these newly-printed "votes", ie. dollars, to each person.  Regardless, democracies are unsustainable anyways, which is the reason that...

The current Bitcoin network is instead similar to a Republic.  "Rei Publica" means the "public things".  That would be the blockchain.  This exists in balance with the "private things", the private keys held by end-users.  Access to the "public things" occurs via the miners, acting as contracted representatives of end-users and ultimately voting in proportion to hashing power on all matters concerning the public blockchain.

It seems to me that your proposal creates more of a technocracy than anything.  It's an interesting, and flexible, technocracy, frighteningly so in certain aspects.  But the defining feature seems to be its deliberate lack of any coherent political philosophy with regards to who, or even what, ultimately controls the Bitcoin network, and how.

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.