Pages:
Author

Topic: Creating an "official" protocol specification for the Bitcoin internet currency - page 4. (Read 4701 times)

legendary
Activity: 1232
Merit: 1094
Meanwhile, there is still no formal specification.  And the damn thing is complicated.  If you've been in the source much and followed the discussions here and in IRC, you can start to believe the devs when they say that your choices for a specification are either 1) wrong, or 2) nearly as complex as the source code itself.

As long as everything that the spec allows is acceptable by the reference client, then it won't cause a fork.

If > 50% of miners reject all blocks that aren't valid according to the spec, then the chain will remain consistent with the spec, even if the reference client would accept blocks that are invalid according to the spec.

Effectively, the spec must define a sub-set of blocks that the official client will accept and also must not define any blocks that are in the chain as illegal.  The second condition could be achieve with exceptions, if necessary.

Quote
Let me give you one odd example.  The coinbase from the genesis block is unspendable.  At first, it was a bug that kept the txid out of the index, but now, we have to explicitly flag that transaction as unspendable.  If we don't, then Satoshi has the power to fork the network at will by redeeming it.  Basically, that bug has to be part of the specification, when one is written.

Not necessarily, you could make it so that the ref client won't mine those blocks, but would accept them, as long as they occur far enough into the future.

Another one is that apparently the acceptable encodings for the public keys is "whatever openSSL accepts".  The spec would have to have a clear definition of what encodings are acceptable.
jr. member
Activity: 42
Merit: 11
It can be solved. I'd tackle it this way:
mark blocks 1-xxxx "specification v1" (satoshi client code being the one)
xxxx-yyyy "specification v2" ("written spec")
yyyy-zzzz, where zzzz is some point in the future - specification v3
zzzz-aaaa specification v4 (bitcoin-next)
and so on.
To assist it, all clients must follow deprecation policy: every release has life span, and refuse to work
past this set date. GUI applications should spew warnings in advance with instructions how to upgrade,
and daemons should send their admins e-mails (and refuse to start without valid mail configured).
In this way we can escape "satoshi code" deadlock.
kjj
legendary
Activity: 1302
Merit: 1026
Heh, this topic has plenty of threads, not just the one you found.

Basically, Satoshi needed to write the whole thing before he could be sure it worked.  And then we all started using it.  And now bitcoins are downright valuable.

Meanwhile, there is still no formal specification.  And the damn thing is complicated.  If you've been in the source much and followed the discussions here and in IRC, you can start to believe the devs when they say that your choices for a specification are either 1) wrong, or 2) nearly as complex as the source code itself.

Let me give you one odd example.  The coinbase from the genesis block is unspendable.  At first, it was a bug that kept the txid out of the index, but now, we have to explicitly flag that transaction as unspendable.  If we don't, then Satoshi has the power to fork the network at will by redeeming it.  Basically, that bug has to be part of the specification, when one is written.  And there are more and stranger things that any node has to faithfully reproduce to keep the network sane, and we have no way of knowing that we've found them all.
sr. member
Activity: 451
Merit: 250
All the debate about the Maxblocksize limit, and the criticism of the dev team for using "magic numbers" in their code has brought up an important point, and that is that satoshi's white paper is not a full or detailed specification of how the bitcoin protocol is actually defined. It's really more of a proposal + example.

For this reason, I think it would make sense to begin work (and it will be a lot of work!) on developing a working document, or some kind of mutually agreed upon standard that goes into greater depth than satoshi's paper on defining the nuts and bolts of what exactly Bitcoin is.

The creation of early internet protocols happened in much the same way as is happening with bitcoin, organized by enthusiastic volunteers. The difference is that the protocols ended up being defined in "official" protocol specifications, written in nice, clear, technical language. Here is an example, the ipv4 protocol specification. This can be used by developers as a reference, and lots of people can independently write software within the protocol specifications.

I think the idea of having a "reference implementation" is fundamentally flawed. The reason is that routine updates to this implementation are not separate from the definition of the protocol itself, which can result in the kind of catastrophes we saw on 3/11 (never forget). Imagine that IPv4 had been defined in this way: here is our "internet" open source project. Run this program to use the internet. You are free to write your own, but all disputes will be resolved by what this one piece of software decides. This would have been a disaster, if that program contained bugs.

tldr: I think a formal protocol specification is essential to making Bitcoin the rock-solid currency system that we want it to be. I'm willing to help by working on this. Post thoughts here.

edit: just found the other post about this
Pages:
Jump to: