Re: [Bitcoin-development] Revisiting the BIPS process, a proposal
On 22/10/13 16:08, Jeff Garzik wrote: > All that is good practice, but we should avoid adding burdensome > process that might discourage BIP writing. > > Consider a distributed approach: if you feel a draft needs more > sections or better language, submit a pull request yourself and help > community-edit the document. I would love to do so. However, from what Peter Todd said above, my feeling was that spec is deliberately vague to force compatibility with the reference implementation rather than with a document. While that kind of compatibility-via-obscurity won't probably work in a long run, in short run it can prevent proliferation of implementations and thus give protocol more space and flexibility to evolve (I've done the same trick with ZeroMQ myself once). Anyway, if my impression was wrong I am happy to give it a try. Martin -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] "Bitcoin codebase is actually really simple and readable."
From: "bitcoin-development-requ...@lists.sourceforge.net" To: bitcoin-development@lists.sourceforge.net Sent: Wednesday, October 23, 2013 3:38 AM Subject: Bitcoin-development Digest, Vol 29, Issue 20 Send Bitcoin-development mailing list submissions to bitcoin-development@lists.sourceforge.net When replying, please edit your Subject line so it is more specific than "Re: Contents of Bitcoin-development digest..." Today's Topics: 2. Re: Revisiting the BIPS process, a proposal (Peter Todd) -- On Tue, Oct 22, 2013 at 09:34:57AM +0200, Martin Sustrik wrote: > On 22/10/13 09:03, Gregory Maxwell wrote: > > On Mon, Oct 21, 2013 at 11:59 PM, Jean-Paul Kogelman > > wrote: > >> Have you seen: https://en.bitcoin.it/wiki/Protocol_specification ? > > > > Take care, the information in the wiki is woefully incomplete. > > Imagine myself, with no prior knowledge of Bitcoin looking at the > document. It starts with "Hashes". What hashes? No idea what's going on. > Etc. > > Now compare that to a well written RFC. It starts with introduction, > description of the problem, explains the conceptual model of the > solution, then dives into the details. There's also Security > Considerations part in every RFC that is pretty relevant for Bitcoin. > > As I said, I am willing to help with writing such document, it would be > a nice way of learning the stuff, however, help from core devs, such as > answering question that may arise in the process, or reviewing the > document would be needed. Writing such RFCs is dangerous due to the consensus nature of Bitcoin - it makes people think the standard is the RFC, rather than the code. I hear one of the better intros to Bitcoin is the Khan academy videos, but I've never watched them myself. Once you understand how it works, start reading source code - the Bitcoin codebase is actually really simple and readable. However remember that the implications of that codebase are anything but simple; there's lots of reasons to think Satoshi himself didn't understand Bitcoin all that well, even by the time he left the project. -- 'peter'[:-1]@petertodd.org 000f155e7a648e84a83589048ae1cacb0c60bfce2437553b6af4 -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 685 bytes Desc: Digital signature -- I feel that I must respond to the statements that 1. the Bitcoin codebase is actually really simple and readable. 2. However remember that the implications of that codebase are anything but simple; there's lots of reasons to think Satoshi himself didn't understand Bitcoin all that well, even by the time he left the project. On point one: if it was/is so readable, why hasn't it been documented better, if at all? Why haven't the obscure names of important items been globally searched and replaced? Why are there still mixed formatting "styles" still in the code. I think it is the fear that C++ is so brittle, that one change may bring the whole house of cards down. I feel that it is the language (C++) that is hindering the expression of ideas in the code. This goes to your point two about Satoshi's understanding. I think just the opposite: that he knew what he wanted but that C++ hindered him in expressing and implementing it. I think that if anything, C++ was what Satoshi "didn't understand all that well". But then who does understand C++, really? See https://groups.google.com/forum/#!msg/comp.lang.lisp/7xCvdzijzgU/4xCFzLc3d5EJ and the quote: Whenever I solve a difficult problem with C++, I feel like I’ve won a bar fight. — Michael Fogus I don't think readability is attainable easily in C++. It requires intentionally writing so that others may understand your code. How many programmers have ever done that? And this is like swimming upstream in C++, where things are designed to be hidden! Ron -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] "Bitcoin codebase is actually really simple and readable."
On Wed, Oct 23, 2013 at 08:02:07AM -0700, Ron wrote: > I feel that I must respond to the statements that > 1. > the Bitcoin codebase is actually really > simple and readable. > > 2. > However remember that the implications of that > codebase are anything but simple; there's lots of reasons to think > Satoshi himself didn't understand Bitcoin all that well, even by the > time he left the project. > > On point one: if it was/is so readable, why hasn't it been documented better, > if at all? > Why haven't the obscure names of important items been globally searched and > replaced? > Why are there still mixed formatting "styles" still in the code. I think it > is the fear that C++ > is so brittle, that one change may bring the whole house of cards down. The nature of Bitcoin is that in any language one change could accidentally bring the whole house of cards down. Also the time and effort it takes to review changes for maliciously or accidentally added exploits. > I feel that it is the language (C++) that is hindering the expression of > ideas in the code. > This goes to your point two about Satoshi's understanding. I think just the > opposite: > that he knew what he wanted but that C++ hindered him in expressing and > implementing it. > I think that if anything, C++ was what Satoshi "didn't understand all that > well". > > But then who does understand C++, really? See > https://groups.google.com/forum/#!msg/comp.lang.lisp/7xCvdzijzgU/4xCFzLc3d5EJ > and the quote: > Whenever I solve a difficult problem with C++, I feel like I’ve won a bar > fight. — Michael Fogus > > I don't think readability is attainable easily in C++. It requires > intentionally writing so that > others may understand your code. How many programmers have ever done that? > And this > is like swimming upstream in C++, where things are designed to be hidden! I'm making the statement that "the Bitcoin codebase is actually really simple and readable." based on personal experience: for what the reference client does - solve a previously thought unsolvable problem in cryptography - the code is simple and readable. (try reading the OpenSSL source-code sometime as a comparison) My experience has consistently been that understanding what the code does is by far the easiest part of understanding Bitcoin; understanding what the effect of what the code does in terms of the system as a whole is at least another one or two orders of magnitude more difficult. -- 'peter'[:-1]@petertodd.org c9e44ec3cb95d6ea51b7e8d29901be451ce3a2bd7b0ed8ae signature.asc Description: Digital signature -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Revisiting the BIPS process, a proposal
On Wed, Oct 23, 2013 at 09:38:31AM +0200, Martin Sustrik wrote: > On 22/10/13 16:08, Jeff Garzik wrote: > > All that is good practice, but we should avoid adding burdensome > > process that might discourage BIP writing. > > > > Consider a distributed approach: if you feel a draft needs more > > sections or better language, submit a pull request yourself and help > > community-edit the document. > > I would love to do so. > > However, from what Peter Todd said above, my feeling was that spec is > deliberately vague to force compatibility with the reference > implementation rather than with a document. > > While that kind of compatibility-via-obscurity won't probably work in a > long run, in short run it can prevent proliferation of implementations > and thus give protocol more space and flexibility to evolve (I've done > the same trick with ZeroMQ myself once). The reference implementation is the specification - the "specification" on the wiki is best thought of as a set of Coles Notes on the real specification. If you don't already understand that and the nuance of that statement you should assume the protocol is fixed in stone and doesn't evolve at all; that statement is not quite true, but it's very close to the truth. I gotta get around to writing a "Developers" section for the FAQ explaining this stuff -- 'peter'[:-1]@petertodd.org 0007362b283ac07839aba795dbfb3c5c4e831d80df9cf3bea2d5 signature.asc Description: Digital signature -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Revisiting the BIPS process, a proposal
On 23/10/13 21:40, Peter Todd wrote: > The reference implementation is the specification - the "specification" > on the wiki is best thought of as a set of Coles Notes on the real > specification. If you don't already understand that and the nuance of > that statement you should assume the protocol is fixed in stone and > doesn't evolve at all; that statement is not quite true, but it's very > close to the truth. Does that imply that the notes are deliberately obscured to force everyone to check the source code? Martin -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Revisiting the BIPS process, a proposal
On Wed, Oct 23, 2013 at 10:05:56PM +0200, Martin Sustrik wrote: > On 23/10/13 21:40, Peter Todd wrote: > > >The reference implementation is the specification - the "specification" > >on the wiki is best thought of as a set of Coles Notes on the real > >specification. If you don't already understand that and the nuance of > >that statement you should assume the protocol is fixed in stone and > >doesn't evolve at all; that statement is not quite true, but it's very > >close to the truth. > > Does that imply that the notes are deliberately obscured to force > everyone to check the source code? What's on the wiki is mostly the work of people who aren't working on the reference implementation, so no, you can't say that. -- 'peter'[:-1]@petertodd.org 0003c1d48b638b9857cb56b6fe9188a60c481fbc9b738ccb4663 signature.asc Description: Digital signature -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Revisiting the BIPS process, a proposal
On Wed, Oct 23, 2013 at 10:27 PM, Peter Todd wrote: > On Wed, Oct 23, 2013 at 10:05:56PM +0200, Martin Sustrik wrote: >> On 23/10/13 21:40, Peter Todd wrote: >> >> >The reference implementation is the specification - the "specification" >> >on the wiki is best thought of as a set of Coles Notes on the real >> >specification. If you don't already understand that and the nuance of >> >that statement you should assume the protocol is fixed in stone and >> >doesn't evolve at all; that statement is not quite true, but it's very >> >close to the truth. >> >> Does that imply that the notes are deliberately obscured to force >> everyone to check the source code? > > What's on the wiki is mostly the work of people who aren't working on > the reference implementation, so no, you can't say that. Indeed, I know of few people who are familiar with the source code that use the wiki. I do think that is a pity. The openness and transparency of the protocol is essential to trusting the system (and shouldn't be limited to those digging through the source code), and for that reason alone I think it needs to be well-documented. I also do agree with earlier comments, that due to the nature of the consensus problem Bitcoin solves, it will always be the network that dictates what the actual rules are - anything else can result in inresolvable forks. If a "formal" specification were written, and we would find out that the majority of nodes on the network deviate from it in a subtle way, those nodes would be buggy in the sense that they aren't doing what was expected, but it would be the specification that is incorrect for not following the rules of the network. In short, consistency is more important than correctness, and for that reason, writing alternate implementation will always be hard and dangerous. However, I do not think that making it hard to find information about the details of the system is the way to go. Alternate implementations are likely inevitable, and in the long run probably a win for the ecosystem. If effort is put into accurately describing the rules, it should indeed carry a strong notice about it being descriptive rather than normative. If someone is willing to work on that, I am (and likely many people in #bitcoin-dev are) available for any questions about the protocol and its semantics. -- Pieter -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Revisiting the BIPS process, a proposal
I think formalizing the specification could go a long way and encouraging alternate implementations is going to be the best way to reduce unexpected small bugs having a bad effect except on the "buggy" node. That being said, it's a huge chicken and egg problem. No one wants to go off the reference client since it could lead to working on a forked chain as a miner or having bad data as a client. I don't know if there is a good way to try to take small pieces, get consensus, possibly have some type of universal test cases and running on testnet that would solve the problem. I wouldn't mind taking on parts of this when I have time, specifically transactions/scripting. Obviously if there are better qualified people who are interested, have at it! On Wed, Oct 23, 2013 at 4:07 PM, Pieter Wuille wrote: > On Wed, Oct 23, 2013 at 10:27 PM, Peter Todd wrote: > > On Wed, Oct 23, 2013 at 10:05:56PM +0200, Martin Sustrik wrote: > >> On 23/10/13 21:40, Peter Todd wrote: > >> > >> >The reference implementation is the specification - the "specification" > >> >on the wiki is best thought of as a set of Coles Notes on the real > >> >specification. If you don't already understand that and the nuance of > >> >that statement you should assume the protocol is fixed in stone and > >> >doesn't evolve at all; that statement is not quite true, but it's very > >> >close to the truth. > >> > >> Does that imply that the notes are deliberately obscured to force > >> everyone to check the source code? > > > > What's on the wiki is mostly the work of people who aren't working on > > the reference implementation, so no, you can't say that. > > Indeed, I know of few people who are familiar with the source code > that use the wiki. > > I do think that is a pity. The openness and transparency of the > protocol is essential to trusting the system (and shouldn't be limited > to those digging through the source code), and for that reason alone I > think it needs to be well-documented. > > I also do agree with earlier comments, that due to the nature of the > consensus problem Bitcoin solves, it will always be the network that > dictates what the actual rules are - anything else can result in > inresolvable forks. If a "formal" specification were written, and we > would find out that the majority of nodes on the network deviate from > it in a subtle way, those nodes would be buggy in the sense that they > aren't doing what was expected, but it would be the specification that > is incorrect for not following the rules of the network. In short, > consistency is more important than correctness, and for that reason, > writing alternate implementation will always be hard and dangerous. > > However, I do not think that making it hard to find information about > the details of the system is the way to go. Alternate implementations > are likely inevitable, and in the long run probably a win for the > ecosystem. If effort is put into accurately describing the rules, it > should indeed carry a strong notice about it being descriptive rather > than normative. > > If someone is willing to work on that, I am (and likely many people in > #bitcoin-dev are) available for any questions about the protocol and > its semantics. > > -- > Pieter > > > -- > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most > from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Revisiting the BIPS process, a proposal
On Wednesday, October 23, 2013 9:42:14 PM Allen Piscitello wrote: > That being said, it's a huge chicken and egg problem. No one wants to go > off the reference client since it could lead to working on a forked chain > as a miner or having bad data as a client. Thankfully, miners are incentivised to run one of every widespread node to ensure their blocks are accepted by the network. Eloipool already supports cross-referencing block templates between multiple clients and using the one that is accepted by most/all (and logging any discrepancies with coredump-like details). Luke -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
