On Tue, Nov 19, 2013 at 9:45 AM, Wladimir wrote:
> Talking about complete, BIP 40 and 41 don't even have an associated
> document:
> https://github.com/bitcoin/bips
> I agree that was over-eager number assigning.
Maybe! The subject matter its assigned for is already _widely_
deployed, for better
On Tue, Nov 19, 2013 at 6:01 PM, Gregory Maxwell wrote:
> On Tue, Nov 19, 2013 at 8:53 AM, Drak 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
On 19 November 2013 17:01, Gregory Maxwell wrote:
> On Tue, Nov 19, 2013 at 8:53 AM, Drak 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 g
On Tue, Nov 19, 2013 at 05:32:55PM +0100, Wladimir wrote:
> On Mon, Oct 21, 2013 at 4:30 PM, Jeff Garzik 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,
On Tue, Nov 19, 2013 at 8:53 AM, Drak 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 IETF makes
On 19 November 2013 16:32, Wladimir wrote:
>
> On Mon, Oct 21, 2013 at 4:30 PM, Jeff Garzik 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
On Mon, Oct 21, 2013 at 4:30 PM, Jeff Garzik 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 current
BIPs from
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
#b
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 en
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 wrote:
> On 23/10/13 23:07, Pieter Wuille wrote:
>
>> In short,
>> consistency is more important than correctness.
>
> That's a nice
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
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
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 referenc
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
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 understan
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 protoco
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
> > se
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
> communi
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 3:
On 22/10/13 09:56, Gregory Maxwell wrote:
> On Tue, Oct 22, 2013 at 12:34 AM, Martin Sustrik 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 beh
On Tue, Oct 22, 2013 at 12:34 AM, Martin Sustrik 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 protoc
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
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 loo
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.
--
October Webinars: Code fo
> 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.
>
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
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. Som
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. Som
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 have some more questions.1) Should the protocol specification page also be codified into BIP(s)?2) Should the current wiki pages be taken down / forwarded to the git repo or be auto updated from the git repo?3) Even though the information in BIP 50 is valuable, should it really be considered a BI
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, Jeff
On Mon, Oct 21, 2013 at 11:46 AM, Andreas Schildbach
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 a boring administr
On 10/21/2013 04:34 PM, Jeff Garzik wrote:
> I'll volunteer as the BIPS editor.
>
> There needs to be some backups with commit access to bips.git, in case
> the BIPS editor is hit by a bus or goes crazy or on vacation. This
> can be some core devs, but I would like at least one or two folks who
>
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 editor
This summarizes some rambling on IRC about revising the BIPS process.
Right now, the BIPS process is a bit haphazard. Previously, BIPS were
in a git repo, and the BIPS on the wiki were locked against editing.
The BIPS editor at the time started off well, but was eventually
M.I.A. So the BIPS "ho
35 matches
Mail list logo
