Can I assume that you are a fan of the Canadian rock band Rush?
90125!
Topic: BIP 2112 - page 2. (Read 11905 times)
Can I assume that you are a fan of the Canadian rock band Rush?
Cheers,
Ian.
Cheers,
Ian.
IMO this doesn't sound like a good thing.
It bloats all future client implementations with a complex interpreter, raises the bar of transaction rule-verification to the mathematical elite, encourages closed source clients, further strongly couples the protocol to the default client and removes the ability for the block chain to fork in a democratic manor.
It bloats all future client implementations with a complex interpreter, raises the bar of transaction rule-verification to the mathematical elite, encourages closed source clients, further strongly couples the protocol to the default client and removes the ability for the block chain to fork in a democratic manor.
Are you planning to patent this?
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.
Thanks for the heads up. Good luck in your venture. I'll revise my proposal to flesh out the details and make it more readable to a broader group of people than just persons having oridinary skill in the art. What are the advantages of the bittorrent protocol over bitcoin's current P2P scheme?
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.
What are the advantages of the bittorrent protocol over bitcoin's current P2P scheme?
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.
If you are talking about a new root block, you want to start a new blockchain then right? Is this about Bitcoin or a new alt-chain? How is it compatible with existing coins if it requires a new genesis block?
Do you have the technical abilities to write this LISP client yourself? If not, who do you propose to do it? Does Gavin know LISP?
Do you think the LISP client can be written perfectly the first time, never needing revision? Won't it be locked in forever, killing the whole chain if a bug is ever found?
Sorry if these are dumb questions, a lot of this is over my head.
Do you have the technical abilities to write this LISP client yourself? If not, who do you propose to do it? Does Gavin know LISP?
Do you think the LISP client can be written perfectly the first time, never needing revision? Won't it be locked in forever, killing the whole chain if a bug is ever found?
Sorry if these are dumb questions, a lot of this is over my head.
You cannot just make your own BIP and call it 2112.
He just did.
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 ?
Any chance you could describe what you want to achieve in a simpler style ?
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.
Another benefit of using LISP (or any similar language) for scripting lies in its transformability. There exist a body of research of ultra-reliable computing that used “SIMD-like” and/or “Hamming distance 3 or higher” coding for error detection and correction. Ultimately no LISP computers were used in the deep space probes because of overall power requirements. For the terrestrial finance transactions the absolute power used by the computer is not really limiting, but the invulnerability to the various side-channel attacks like differential fault analysis becomes a tremendous benefit. Those fault-hardening and SIMD-like transformations could be applied mechanically to the scripts so long as they are represented appropriately.
Obviously Bitcoin stack automaton scripts can be automatically translated to the prefix s-expression notation and undergo the same transformations as above. But I don’t see the benefit it requiring this additional step aside from backward compatibility.
Overall the program implementing the current proposal could be compatible with Bitcoin and all currently existing alternative block-chain currencies, including Litecoin, IxCoin, I0Coin, Tenebrix, and Fairbrix. It would be up to the Bitcoin core development team to commit to the precise rules regarding fees and checkpoints. It could even transact Solidcoin version 2 and would conceivably prevent any closed-source modifications that plague that clone of Bitcoin. The network transport protocols are currently incompatible, but the network adaptation layer would be very simple.
In summary this proposal encompasses three main changes: (1) explicit cryptographically signed and software-executable contract included in the root block, (2) cooperative DHT-based networking protocol that does away with IRC, dedicated ports and 4-byte identifiers, (3) general prefix script notation backed by strong syntax and semantic checkers.
Because of this proposal is very far-reaching I suggest that it will be immediately placed in the dormant state. Initially we can work on clarifying its wording, but the full implementation will require a lot of discussion and research. Hopefully the information included here will stay in public domain and will spread amongst the cryptography research community.
(End.)
Obviously Bitcoin stack automaton scripts can be automatically translated to the prefix s-expression notation and undergo the same transformations as above. But I don’t see the benefit it requiring this additional step aside from backward compatibility.
Overall the program implementing the current proposal could be compatible with Bitcoin and all currently existing alternative block-chain currencies, including Litecoin, IxCoin, I0Coin, Tenebrix, and Fairbrix. It would be up to the Bitcoin core development team to commit to the precise rules regarding fees and checkpoints. It could even transact Solidcoin version 2 and would conceivably prevent any closed-source modifications that plague that clone of Bitcoin. The network transport protocols are currently incompatible, but the network adaptation layer would be very simple.
In summary this proposal encompasses three main changes: (1) explicit cryptographically signed and software-executable contract included in the root block, (2) cooperative DHT-based networking protocol that does away with IRC, dedicated ports and 4-byte identifiers, (3) general prefix script notation backed by strong syntax and semantic checkers.
Because of this proposal is very far-reaching I suggest that it will be immediately placed in the dormant state. Initially we can work on clarifying its wording, but the full implementation will require a lot of discussion and research. Hopefully the information included here will stay in public domain and will spread amongst the cryptography research community.
(End.)
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...)
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...)
Bitcoin Improvement Proposal #2112
Ownership: Public domain
Status: Draft ->Deferred
Type: Informational
The purpose of this document is purely informative and not normative. It aims to spread to the wider cryptographic community the various improvements to the well-known Bitcoin design that would address some limitations of the existing implementation that prevent its wider adoption. The proposed changes are far-reaching and as such are not suitable for immediate implementation. They are so extensive that it is certain that a complete reimplementation will be required. No matter what is the immediate fate of this proposal, I’m remaining hopeful that the ideas explained will remain public domain knowledge and will serve as a prior-art counterclaim in any future patent litigation.
The centerpiece of this proposal is the idea of “digital prospectus”: a program whose main functionality is to do perform a verification of the submitted blocks and transactions. This program will be cryptographically hashed and will become a “root prospectus hash” in this proposal and an equivalent of the newspaper headline in the present Bitcoin genesis block. In addition the “root prospectus hash” will become the identifier for the “digital financial security” in the transactional transport protocols. As such it will replace 4-byte integer 1 in the current Bitcoin protocol.
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. It seems to me that some dialect of LISP would be suitable choice. LISP s-expressions maintain very close relationship between the human-readable text of the program (which will be hashed to form the digital prospectus) and the internal data structures that represent the program and which will be interpreted and verified many times during its lifetime. The runtime efficiency is pretty much immaterial; the properties that are tremendously important are (1) well-defined semantics; (2) the ability of the program to analyze and transform its own text; (3) possibility of secure implementations that are resistant to the cryptographic side-channel attacks like “differential fault analysis”, “differential power analysis”, “timing attack”, etc.
The exact content of the “digital prospectus” would depend on the type of the “digital financial security” that it describes. For the security like Bitcoin it would define the rules for the validity of the block and the transaction. It would exactly specify the fees that need to be paid for the inclusion of the transactions in the block and who is allowed to specify checkpoints for the longest chain of blocks. In the current Bitcoin implementation fees are pretty much left unspecified (with the exception of “dust spam defense”) and two block-chain checkpoints were signed by “fabianhjr”, who is pretty much unknown in the community.
(continued...)
Ownership: Public domain
Status: Draft ->Deferred
Type: Informational
The purpose of this document is purely informative and not normative. It aims to spread to the wider cryptographic community the various improvements to the well-known Bitcoin design that would address some limitations of the existing implementation that prevent its wider adoption. The proposed changes are far-reaching and as such are not suitable for immediate implementation. They are so extensive that it is certain that a complete reimplementation will be required. No matter what is the immediate fate of this proposal, I’m remaining hopeful that the ideas explained will remain public domain knowledge and will serve as a prior-art counterclaim in any future patent litigation.
The centerpiece of this proposal is the idea of “digital prospectus”: a program whose main functionality is to do perform a verification of the submitted blocks and transactions. This program will be cryptographically hashed and will become a “root prospectus hash” in this proposal and an equivalent of the newspaper headline in the present Bitcoin genesis block. In addition the “root prospectus hash” will become the identifier for the “digital financial security” in the transactional transport protocols. As such it will replace 4-byte integer 1 in the current Bitcoin protocol.
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. It seems to me that some dialect of LISP would be suitable choice. LISP s-expressions maintain very close relationship between the human-readable text of the program (which will be hashed to form the digital prospectus) and the internal data structures that represent the program and which will be interpreted and verified many times during its lifetime. The runtime efficiency is pretty much immaterial; the properties that are tremendously important are (1) well-defined semantics; (2) the ability of the program to analyze and transform its own text; (3) possibility of secure implementations that are resistant to the cryptographic side-channel attacks like “differential fault analysis”, “differential power analysis”, “timing attack”, etc.
The exact content of the “digital prospectus” would depend on the type of the “digital financial security” that it describes. For the security like Bitcoin it would define the rules for the validity of the block and the transaction. It would exactly specify the fees that need to be paid for the inclusion of the transactions in the block and who is allowed to specify checkpoints for the longest chain of blocks. In the current Bitcoin implementation fees are pretty much left unspecified (with the exception of “dust spam defense”) and two block-chain checkpoints were signed by “fabianhjr”, who is pretty much unknown in the community.
(continued...)
Jump to: