Re: [Bitcoin-development] Revisiting the BIPS process, a proposal
On 23/10/13 23:07, Pieter Wuille wrote: In short, consistency is more important than correctness. That's a nice and concise way to put it and any potential protocol documentation should start with a statement like that. 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. One interesting question is whather alternative implementations are more likely to get it wrong because the protocol description is wrong or because the authors misunderstood the reference implementation source code. Extensive documentation of the source code, a la Knuth's literate programming, may be some kind of a middle ground. 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. Ok. Several people expressed an interest in the topic, so I'll give it a try and see how it fares. 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=60135991iu=/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 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=60135991iu=/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=60135991iu=/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 21/10/13 21:47, Luke-Jr wrote: On Monday, October 21, 2013 7:38:37 PM Jean-Paul Kogelman wrote: 1) Should the protocol specification page also be codified into BIP(s)? Probably wouldn't hurt, but it'd likely need a rewrite in a more modular and formal form. I wanted to have a look at how the whole Bitcoin thing works recently. Being a distributed application, I've searched for the protocol spec. What I found were two wiki pages (Protocol ProtocolRules) that looked more like notes someone wrote down while implementing the application. Have I missed something? Is there any effort underway trying to produce a decent spec? If not so, I am willing to help with that. 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=60135991iu=/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 22/10/13 09:03, Gregory Maxwell wrote: On Mon, Oct 21, 2013 at 11:59 PM, Jean-Paul Kogelman jeanpaulkogel...@me.com 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. 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=60135991iu=/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 22/10/13 09:56, Gregory Maxwell wrote: On Tue, Oct 22, 2013 at 12:34 AM, Martin Sustrik sust...@250bpm.com wrote: There's also Security Considerations part in every RFC that is pretty relevant for Bitcoin. Which would say something interesting like If the bitcoin network implements inconsistent behavior in the consensus critical parts of the protocol the world ends. As such, conformance or _non_-conformance with this specification (in particular, sections 4. 5. and 6.) may be required for security. In fact, yes. In the end it boils down to saying something like: Bitcoin is a unique global distributed application and thus all implementations MUST support the version of the protocol currently in use, irrespective of whether it have been documented and/or published. This RFC is meant only for informational purposes and is a snapshot of the protocol as to Oct 22nd 2013. That being said, I understand the idea of not publishing the spec so that everyone is forced to work with live data. A Bitcoin protocol RFC would be a great place to exercise RFC 6919 keywords. ( http://tools.ietf.org/html/rfc6919 ) Heh. Haven't seen that one. 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=60135991iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] A critique of bitcoin open source community
On 21/10/13 08:52, Jean-Paul Kogelman wrote: How about putting them into sub directories that map onto the status of the BIP? Reading BIP 1, that would make: Accepted Active Draft Deferred Final Rejected Replaced Withdrawn Have it been considered to do this via IETF? The process there is hardened by 40 years of experience and 7000+ RFCs. Probably better than anything you can devise yourself. 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=60135031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] A critique of bitcoin open source community
On 21/10/13 09:07, Jean-Paul Kogelman wrote: The list comes from BIP 1. Sorry, I haven't meant you personally. It was just a generic question about using existing process instead of inventing a new one on the go. Have it been considered to do this via IETF? The process there is hardened by 40 years of experience and 7000+ RFCs. Probably better than anything you can devise yourself. 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=60135031iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
