On Mon, Oct 21, 2013 at 4:30 PM, Jeff Garzik jgar...@bitpay.com wrote:
BIP drafts are stored in git://github.com/bitcoin/bips.git/drafts/ and
are not automatically assigned a BIPS number.
Are we going to move ahead with this?
If so, I'm volunteering to create the repository and import the
On 19 November 2013 16:32, Wladimir laa...@gmail.com wrote:
On Mon, Oct 21, 2013 at 4:30 PM, Jeff Garzik jgar...@bitpay.com wrote:
BIP drafts are stored in git://github.com/bitcoin/bips.git/drafts/ and
are not automatically assigned a BIPS number.
Are we going to move ahead with this?
On Tue, Nov 19, 2013 at 8:53 AM, Drak d...@zikula.org wrote:
It's quite normal for standards bodies to allocate numbers when in draft
status. If they don't pass, they don't pass - they are clearly labelled
DRAFTs.
+1 on having things in a github repository. Much better for collaboration,
The
On 19 November 2013 17:01, Gregory Maxwell gmaxw...@gmail.com wrote:
On Tue, Nov 19, 2013 at 8:53 AM, Drak d...@zikula.org wrote:
It's quite normal for standards bodies to allocate numbers when in draft
status. If they don't pass, they don't pass - they are clearly labelled
DRAFTs.
+1
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
Yes. I had pointed people in IRC to Knuth's literate programming, as
an example of how we might document bitcoin.
On Thu, Oct 24, 2013 at 3:03 AM, Martin Sustrik sust...@250bpm.com wrote:
On 23/10/13 23:07, Pieter Wuille wrote:
In short,
consistency is more important than correctness.
I'd like to add some historical background about how the protocol
specification came to be in the first place.
A bit over three years [1] ago I started an attempt to document the
network protocol, by reverse engineering it from the satoshi
client. My goal, back then, was to enable like-minded
Thanks Christian, this is a really interesting bit of history. My own
personal experience from when I wrote my own client and BCCAPI-ish server
was that the protocol specification on the Wiki was hugely valuable, and
rarely sent me astray. Supplement that with the occasional questions on
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
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
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
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
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
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
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
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.
--
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
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
jeanpaulkogel...@me.com wrote:
Have you seen: https://en.bitcoin.it/wiki/Protocol_specification ?
Take care, the information in
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
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
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.
On Tue, Oct 22, 2013 at
Continuing. (grumble gmail grumble)
As with the IETF, there will be a great many drafts that do not make
it to BIPS status. That is normal, and a sign of a healthy process.
I'll volunteer as the BIPS editor.
There needs to be some backups with commit access to bips.git, in case
the BIPS
On Mon, Oct 21, 2013 at 11:46 AM, Andreas Schildbach
andr...@schildbach.de wrote:
I accept the nomination as a backup (-:
Cool.
So the duty of the editor is merging pull requests and/or proxying
between email and git for those who do not use git?
Correct. And assigning BIP numbers. Ideally
Added: I'm happy with gmaxwell as BIP editor as well, as he is
apparently the current BIP-number-assigner-in-chief. :)
The goal is to improve the process, hash-seal our specs, and create an
easy way for anyone with at least an email address to participate.
On Mon, Oct 21, 2013 at 10:30 AM,
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.
2) Should the current wiki pages be taken down / forwarded to the
I believe a better solution would to use a gitlab clone such as gitlab,
which sits on top of the git repo, and allows for custom code around the
BIP process. Potentially one could even build Bitcoin into such a BIP
system. If somebody wants to support a BIP he donates Bitcoins to that
proposal.
I believe a better solution would to use a github clone such as gitlab,
which sits on top of the git repo, and allows for custom code around the
BIP process. Potentially one could even build Bitcoin into such a BIP
system. If somebody wants to support a BIP he donates Bitcoins to that
proposal.
27 matches
Mail list logo
