Gyrsur (OP)
Legendary
 Offline
Activity: 2856
Merit: 1518
Bitcoin Legal Tender Countries: 2 of 206
|
 |
February 17, 2013, 03:02:10 PM |
|
There are RFCs for SMTP ( RFC 821), E-Mail-Format ( RFC 822) and others. Is this also existing for the Bitcoin protocol? |
|
|
|
|
|
|
|
|
|
|
In order to get the maximum amount of activity points possible, you just need to post once per day on average. Skipping days is OK as long as you maintain the average.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
|
|
|
|
grau
|
 |
February 17, 2013, 03:25:22 PM |
|
Yes we should start working on a standard, since diversity of node code bases is inevitable.
Adoption of new releases of the standard client will never be 100% and there are use cases
it does not serve well, so people are patching or using alternate implementations.
Creating a precise standard is something the bitcoin foundation should consider sponsoring.
|
|
|
|
|
DannyHamilton
Legendary
Offline
Activity: 3374
Merit: 4606
|
|
February 17, 2013, 04:16:07 PM |
|
Yes we should start working on a standard, since diversity of node code bases is inevitable.
Adoption of new releases of the standard client will never be 100% and there are use cases
it does not serve well, so people are patching or using alternate implementations.
Creating a precise standard is something the bitcoin foundation should consider sponsoring.
In my experience, developers are really good at either ignoring documentation or interpreting it in a way different than the way the author intended.
And spec authors are really good at getting details wrong, no matter how careful they are. And they're really bad at keeping track of changes.
That's why I spent a lot of time over the past year developing test cases and tools that you can run your code against instead of writing specs.
I may just be cynical because I spent so much time in 1997 working on the ISO/IEC-14772-1 Official, Formal Standard.
It bothers me that this topic keeps coming up. The fact that Bitcoin is different to other technologies isn't intuitive but by the time you're writing an actual implementation, it should be obvious. Maybe it's worth reading the thread with grau about his reimplementation also?
The fact is that re-implementing Bitcoin exposes not only you, but all participants, to a class of "chain splitting" bugs that don't really exist in other network technologies, or at least are nowhere near as severe . . . When you reimplement Bitcoin, it's not enough to build things as you think they should work. You have to implement them exactly as Satoshi did, including all his bugs. And because some parts of the protocol are directly exposed to underlying libraries like OpenSSL, you have to match their behaviour exactly as well, including all their bugs. Failure to do so can lead to people losing money.
At some point, if you realize you have to match the behaviour of another codebase exactly, down to the tiniest detail, you realize that the only precise enough specification for that is the source code . . .
|
|
|
|
|
|
grau
|
|
February 17, 2013, 04:33:22 PM |
|
I do see the validity of Gavin's and Mike's arguments as well as think it is not realistic to assume node code base will remain or is homogenous.
The standard we need is likely not (just) plain text like RFCs, but elaborate test cases and test tools that set the standard for all implementations and releases. We are actually moving into that direction. Every test case that is created is a piece of standard.
|
|
|
|
|
Gyrsur (OP)
Legendary
Offline
Activity: 2856
Merit: 1518
Bitcoin Legal Tender Countries: 2 of 206
|
|
February 17, 2013, 04:37:26 PM |
|
Yes we should start working on a standard, since diversity of node code bases is inevitable.
Adoption of new releases of the standard client will never be 100% and there are use cases
it does not serve well, so people are patching or using alternate implementations.
Creating a precise standard is something the bitcoin foundation should consider sponsoring.
In my experience, developers are really good at either ignoring documentation or interpreting it in a way different than the way the author intended.
And spec authors are really good at getting details wrong, no matter how careful they are. And they're really bad at keeping track of changes.
That's why I spent a lot of time over the past year developing test cases and tools that you can run your code against instead of writing specs.
I may just be cynical because I spent so much time in 1997 working on the ISO/IEC-14772-1 Official, Formal Standard.
It bothers me that this topic keeps coming up. The fact that Bitcoin is different to other technologies isn't intuitive but by the time you're writing an actual implementation, it should be obvious. Maybe it's worth reading the thread with grau about his reimplementation also?
The fact is that re-implementing Bitcoin exposes not only you, but all participants, to a class of "chain splitting" bugs that don't really exist in other network technologies, or at least are nowhere near as severe . . . When you reimplement Bitcoin, it's not enough to build things as you think they should work. You have to implement them exactly as Satoshi did, including all his bugs. And because some parts of the protocol are directly exposed to underlying libraries like OpenSSL, you have to match their behaviour exactly as well, including all their bugs. Failure to do so can lead to people losing money.
At some point, if you realize you have to match the behaviour of another codebase exactly, down to the tiniest detail, you realize that the only precise enough specification for that is the source code . . .
the question is not about habits of developers and their implementations of the protocol it is about standardization of the Bitcoin protocol rules ( https://en.bitcoin.it/wiki/Protocol_rules) to take it out from group of interests and make it available as a standard as part of the Internet standards. |
|
|
|
DannyHamilton
Legendary
Offline
Activity: 3374
Merit: 4606
|
|
February 17, 2013, 04:40:17 PM |
|
the question is not about habits of developers and their implementations of the protocol it is about standardization of the Bitcoin protocol rules ( https://en.bitcoin.it/wiki/Protocol_rules) to get it out from group of interests and make it available as a standard as part of the Internet standards. And the point being made by the quotes I attached aren't about the habits of developers and their implementations of the protocol. It's pointing out that the source code of the reference client is the standardization of the Bitcoin Protocol rules, and that a really good set of test cases is the best way to ensure that any new code base properly implements that standard. |
|
|
|
|
Gyrsur (OP)
Legendary
Offline
Activity: 2856
Merit: 1518
Bitcoin Legal Tender Countries: 2 of 206
|
|
February 17, 2013, 04:46:40 PM |
|
the question is not about habits of developers and their implementations of the protocol it is about standardization of the Bitcoin protocol rules ( https://en.bitcoin.it/wiki/Protocol_rules) to get it out from group of interests and make it available as a standard as part of the Internet standards. And the point being made by the quotes I attached aren't about the habits of developers and their implementations of the protocol. It's pointing out that the source code of the reference client is the standardization of the Bitcoin Protocol rules, and that a really good set of test cases is the best way to ensure that any new code base properly implements that standard. is open source. it does not prevent to have fork implemetations in the future which will dominate in the wild. |
|
|
|
|
grau
|
|
February 17, 2013, 04:49:54 PM |
|
the question is not about habits of developers and their implementations of the protocol it is about standardization of the Bitcoin protocol
The Bitcoin wire protocol is a cake that can be defined in plain text like RFCs, but the requirement that it has to converge to the same internal state at every node (that is ultimately the UTXO set) is a non-trivial algorithm that likely needs creative ways of standardizing including using programs to define. What I claim is that the standard can not be simple the Satoshi client, since that is not a constant either. |
|
|
|
|
Gyrsur (OP)
Legendary
Offline
Activity: 2856
Merit: 1518
Bitcoin Legal Tender Countries: 2 of 206
|
|
February 17, 2013, 04:51:54 PM |
|
the question is not about habits of developers and their implementations of the protocol it is about standardization of the Bitcoin protocol
The Bitcoin wire protocol is a cake that can be defined in plain text like RFCs, but the requirement however that it has to converge to the same internal state at every node (that is ultimately the UTXO set) is a non-trivial algorithm that likely needs creative ways of standardizing including using programs to define. What I claim is that the standard can not be simple the Satoshi client, since that is not a constant either. agree completely. |
|
|
|
DannyHamilton
Legendary
Offline
Activity: 3374
Merit: 4606
|
|
February 17, 2013, 04:54:18 PM |
|
the source code of the reference client is open source. it does not prevent to have fork implemetations in the future which will dominate in the wild.
And a written standard that is not the reference client also does not prevent fork implementations in the future that will dominate in the wild. So what do you gain from having a written standard that is not the reference client? |
|
|
|
|
DannyHamilton
Legendary
Offline
Activity: 3374
Merit: 4606
|
|
February 17, 2013, 04:56:51 PM |
|
. . . What I claim is that the standard can not be simple the Satoshi client, since that is not a constant either.
Standards get updated. The reference client gets updated. What's the difference? If we print out the source code for the reference client and put a "Bitcoin Standard Number #####" on top of the print out, isn't that a "written" definition of the current standard? |
|
|
|
|
|
Schleicher
|
|
February 17, 2013, 05:01:22 PM |
|
Some people think that if it can't be standardized then the whole thing is a bad hack and has no future.
|
|
|
|
|
grau
|
|
February 17, 2013, 05:03:45 PM |
|
. . . What I claim is that the standard can not be simple the Satoshi client, since that is not a constant either.
Standards get updated. The reference client gets updated. What's the difference? The difference is that network nodes are not upgrading atomically to 100%. Therefore even the Satoshi client can cause a fork if changing behavior. The method we avoid this is testing. The tests actually capture the behavior of old versions and therefore converge to a standard. |
|
|
|
|
Gyrsur (OP)
Legendary
Offline
Activity: 2856
Merit: 1518
Bitcoin Legal Tender Countries: 2 of 206
|
|
February 17, 2013, 05:04:48 PM |
|
the source code of the reference client is open source. it does not prevent to have fork implemetations in the future which will dominate in the wild.
And a written standard that is not the reference client also does not prevent fork implementations in the future that will dominate in the wild. So what do you gain from having a written standard that is not the reference client? there should be common accepted standard by several group of interests which are operate with the Internet. EDIT: please understand that this is a base of wide adoption of a certain subject.  |
|
|
|
Mike Hearn
Legendary
Offline
Activity: 1526
Merit: 1128
|
|
February 17, 2013, 05:17:42 PM |
|
I think one day we could have an RFC, but it'd have to be very, very long and detailed, and it doesn't really make sense to try writing one today because we don't fully understand the protocol ourselves (as it's defined by the existing code).
As alternative implementations make progress and people get burned by chain splitting bugs, we'll be able to flesh out more and more of the subtle details and eventually there'll be none left - software is finite, after all. But I think it'll take years. Until then, source code is it.
|
|
|
|
|
casascius
Mike Caldwell
VIP
Legendary
Offline
Activity: 1386
Merit: 1136
The Casascius 1oz 10BTC Silver Round (w/ Gold B)
|
|
February 17, 2013, 05:32:28 PM
Last edit: February 17, 2013, 05:43:24 PM by casascius |
|
Before even considering drafting RFC's for Bitcoin, I would submit that there are two very different sub-protocols in Bitcoin that should be distinguished and documented separately. They can definitely be implemented separately, but when implemented as an on-net client, "SHOULD" be implemented together.
One RFC should propose the definition of the block chain, transactions, blocks, and should define what one node's view of the network should look like having received these objects... without defining how these might be received. This RFC should clearly define what constitutes a valid vs. invalid transaction (or any other object). This RFC should cover the scripting engine, the rules for accepting vs. orphaning blocks, the concept of mining difficulty, forking and splitting and resolution of splits, etc.
The other RFC should define the peer-to-peer transport as currently implemented in the Satoshi client, and the particular messages and expectations. This RFC should cover relaying, how/when to relay/not relay, etc., as well as what data nodes maintain, and the nuances for requesting that data and advertising its availability to peers. Only at this level should any relationship be made between transaction fees and whether a message should be relayed.
The main reason for this is that there's a great value in not hitching Bitcoin to any specific IP transport mechanism. Specifically, the possibility of using one-to-many technologies such as radio/satellite broadcasting and IP multicasting to transmit block/transaction data to nodes will be vital and valuable to Bitcoin's future scalability, as well as adoptability in remote areas where internet connectivity is sparse. You'd want the ability to completely replace the transport, as well as set the expectations among other engineers that transport (or transports) may evolve separately from the core objects.
|
Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable. I never believe them. If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins. I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion. Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice. Don't keep coins online. Use paper or hardware wallets instead.
|
|
|
|
grau
|
|
February 17, 2013, 05:52:07 PM |
|
The main reason for this is that there's a great value in not hitching Bitcoin to any specific IP transport mechanism.
We surely want to leave the RFC open for physical transactions and gold plated blocks |
|
|
|
|
Gyrsur (OP)
Legendary
Offline
Activity: 2856
Merit: 1518
Bitcoin Legal Tender Countries: 2 of 206
|
|
February 17, 2013, 06:17:33 PM |
|
The main reason for this is that there's a great value in not hitching Bitcoin to any specific IP transport mechanism.
We surely want to leave the RFC open for physical transactions and gold plated blocks why not. the possibility to operate Bitcoin offline is maybe not very practical but will gain trust the system is also verifiable if up to date technology is not available in the case of cases. only theoretical thoughts. |
|
|
|
casascius
Mike Caldwell
VIP
Legendary
Offline
Activity: 1386
Merit: 1136
The Casascius 1oz 10BTC Silver Round (w/ Gold B)
|
|
February 17, 2013, 06:37:36 PM |
|
The main reason for this is that there's a great value in not hitching Bitcoin to any specific IP transport mechanism.
We surely want to leave the RFC open for physical transactions and gold plated blocks Not sure how a gold plated brick has anything to do with IP transport. The brick can't adhere to either RFC, it's just a number with a decoration on it. What we really want is to leave the RFC open so that someone can invent a POS system for use in a remote African village, that passively keeps its block chain updated from a data side-channel on a satellite feed (sort of how Sirius/XM sends out traffic, weather, stock quotes, and aviation data to those equipped to receive it). Such a station could broadcast its own outgoing transactions over terrestrial radio to some faraway service that relays it back to the main IP transport used by the majority of the network. |
Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable. I never believe them. If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins. I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion. Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice. Don't keep coins online. Use paper or hardware wallets instead.
|
|
|
|
grau
|
|
February 17, 2013, 06:45:52 PM |
|
I apologize, I should not try to be funny. I actually love your physical coins and notes, since they enhance usability, build bridges and are actually really nice collectibles.
Yes, Bitcoin has the meat for multiple RFCs and communication is a subject clearly distinct from the tx and block rules.
As you know, I work to decompose this genuine thing into modules and the standards should do the same.
|
|
|
|
|
|
