Topic: Does a Request for Comments (RFC) for the Bitcoin protocol exist? - page 2. (Read 4563 times)

haha you mean there is no one which is fully understand the "whole thing"?? and you expect that "the rest" will trust the "whole thing"??

so who is the "Linus Torvalds" of Bitcoin?? I don't want to hear "Satoshi Nakamoto" because he is disappear.

 

EDIT: so demand can go down now... everthing above 1-2$ per BTC is overpriced for such a "thing" without a clean foundation...

You can troll all you want, but fundamentally the reference client runs great on fairly modest computers and because of the 1MiB block size Moore's law this will continue to be true. As I've posted elsewhere raising that limit is not an option. Right now I can run a Bitcoin node just fine on a $5/month VPN server with very little CPU power or memory. Even if your RFC specification somehow resulted in a Bitcoin node that used 10x less resources, frankly I don't care about the difference between $5/month and $0.5/month. On the other hand, I do care about network splits, and using the Satoshi codebase for full validating nodes will be the best way to prevent them for the foreseeable future.

Talking about "old money" and "new money" as somehow having anything to do with the issue of what codebase you should us to run a validating node is bizzare. The only financial interest the "old money" has is to keep Bitcoins valuable, and the best way to do that is to keep the network secure and well-used. Other than validating nodes there are lots of reasons to promote alternative implementations - I personally use Armory as a wallet and am working on a project that would create ledger services to process transactions entirely off the blockchain, while providing for a mechanism where these services could be both anonymous and trusted.

Of course, I can't think of any projects you've actually created, so I don't have any reason to think you've actually run into any the supposed serious limitations inherent in the satoshi implementation that only a complete re-write can solve.

^^epic!  

so come on guys let us change the current situation and let Bitcoin become an Internet standard like email...

EDIT: if you want... 

Oh, I assure you that I get the "old money" vs. "new money" split in the Bitcoin millieu really well. I can even commiserate with the plight of the "old money" people like you: you've staked everything on the support of the proof-of-concept quality code, and things aren't looking good.

https://bitcointalksearch.org/topic/m.1113732
https://bitcointalksearch.org/topic/m.1147050

 

Bitcoin Airlines 2012 Annual Report:

1) The founder and CEO had split and we are still unable to locate him. Interim CEO is in charge until then.

2) The original paper plane has been covered in many layers of varnish and we have declared it fit for the regular service.

3) We've sold many passenger tickets for our Airline and the regular scheduled flights have started.

4) Unfortunately the cruise speed of our planes is barely above stall speed. The engines are weak and we cannot upgrade to the professional state-of-the-art engines that other airlines use. None of our mechanics know how to maintain them and we don't have money to hire some help.

5) Moreover the oxygen supply on our planes isn't working right and the passengers are passing out while onboard. Frequently the conscious passengers rob the passed-out passengers. Sometimes even the plane crew takes into temptation and plunders the unconscious passengers.

6) Fortunately the in-flight entertainment systems on our planes are the best. No-one else is even getting close to what we have to offer: neither on the land nor on the sea nor in the air.

7) Unfortunately almost all the fuel and engine thrust goes into powering the in-flight entertainment systems.

 

So getting back to the question in the title: RFC protocol for Bitcoin does exist. But in order to operate effectively it has to gain the "economic majority". The current "economic majority" already has the title to over the half of the real estate in the Bitcoin-landia. Do you think that they will give the single bird in their hands for the promise of a share of two birds in the bush?

You just don't get it do you? Bitcoin is a consensus system and we don't yet know how to create diverse implementations that meet the incredibly strict requirement of every implementation acting exactly the same way. For now, specifying the "Bitcoin standard" as source code is unfortunately the best we can do, and even that is difficult. This is why the recommended way to create a Bitcoin-using service is to run one or more full nodes using the reference (Satoshi) implementation to have some trusted nodes to connect to, and then use either the reference client or an alternative implementation as the base for your actual business logic. The reference node insulates your custom code from the network, especially malicious actors, and ensures that the rules for what are valid blocks and valid transactions are followed correctly. Your code can assume that anything the reference node communicates to it is accurate. (though you do need to handle re-orgs)

Ultimately that the GUI and the Bitcoin node were implemented in the same codebase was a big design mistake by Satoshi, but we have to live with it. Satoshi should have written a very small, very simple, validating node core and then wrote a separate client library and UI/wallet app as a separate code-base using that core. I think all the developers want to work towards that goal, but doing so is a huge project with a lot of risks. Not worth it given there aren't many disadvantages to just running bitcoind.

I think it's notably that you don't see the core devs complaining about Mike Hearns bitcoinj or jgarzik's pynode, neither of which claims to be a full validating node. The former especially has been used as the basis for a lot of services - satoshidice is built on bitcoinj IIRC. I have working on pynode on my todo list myself; we don't have enough people working on libraries to make it easy to explore new types of transactions. What we do have is people wasting a lot of time and effort attempting to make fully validating node re-implementations that are downright dangerous to their users and the network as a whole, yet don't provide any benefits.

You know gmaxwell has asked me a few times about my progress on pynode - not exactly the actions of someone trying to clamp down on alternatives. But he knows I understand the consensus problem.

Actually you are 100% right when you say that I'm "too vague". I definitely need to elaborate on how half-defined standards are used for the purpose of gaming benchmarks and competition.

Lets start with an example that turns out to be mostly good. TCP/IP is a reasonably well-defined protocol with an not-well-defined "congestion avoidance" algorithm. This opening is well-publicised and there are many choices available: Tahoe, Reno, Vegas, BIC, CUBIC, etc. Even Microsoft has its entry: Compound TCP that has been ported to Linux. http://en.wikipedia.org/wiki/TCP_congestion_avoidance_algorithm

In the above example there is a scope for gaming benchmarks by calling everything "the TCP/IP", but underneath using "TCP/IP X" or "TCP/IP Y" depending on the results you want to get. But probably close to 50% of benchmark readers are familiar with the fact that there's no single "TCP/IP" and will ask further questions.

Now lets step into the pits. The perceptual compression codecs are good candidate to "less-than-half-define": just standardize the decoding algorithm and leave the coding side open-ended. Ostensibly the open-endedness will allow further gains in efficiency. But in practice it will be used to confuse the users/developers and game the benchamrks. Someone wants to show "MPEG from vendor X is slow?" Crank up all the compressor settings! Someone wants to show "MPEG from vendor Y is low-quality?" Pull all the compressor sliders down! If a benchmark reviever proclaims: "That was unfair!" then the answer is: "It conforms to MPEG standard!" Market for MPEG encoders is particularly problematic in the way described. But many others have caught on their way and are getting good at gaming comparisons by using various "hidden features" in the "authoring" portion of the "standard-conforming" implementation. Please learn to watch for it.

So what is the moral of the story above? Standards are tools (like axes), they can be used for good and bad purposes. The good question to ask yourself is:

1) is the particular vendor interested in interoperability and promoting the market by encouraging diverse implementation?

or

2) is the particular vendor known for promoting exclusivity, discouraging alternatives and always hyping his own implementation?

Please take your time to review the posting history and make a smart choice.

Needs a bit more than a bounty; it would take thousands of coins per year to support even one student to work on this sort of thing (and for the forseeable future you would not be able to get away with giving someone coins, you would need to sell them). The Bitcoin Foundation apparently has some bounties for development, but there seems to be no interest by anyone to support pure research (even directly applicable to Bitcoin), which is understandable: the Bitcoin economy is too marginal. There are no billionaires to give away million-dollar endowments here and there.

Anyway, obviously the desirable state of affairs would be to generate production code automatically from a verified specification, or to verify suitably-annotated source code. If that cannot be done, however, it does not mean that specifications or model-checking are useless. Subtle bugs do get found that way. But for immediate practical purposes it may be more beneficial to publish the existing reference implementation using literate-programming techniques.

What stops us doing lots of useful stuff is scarcity of resources.

This could perhaps be addressed by assigning a bounty by those who think it is a good idea. I wish we had crowd funding for projects like this.

In any case, for everyone who thinks an RFC or similar specification document is such a great idea, nobody is stopping you from writing one yourself. If you write a good one that manages to address the issues raised by Mike Hearn and gmaxwell, and keep it updated, it has a chance of being adopted and in any case the process will teach you a lot about how Bitcoin really works.

You appear to be claiming that I misquoted RFC 6716. You do realize that I wrote (and revised in many subsequent revisions) that section of the RFC, right? It's not clear to me specifically how you're misunderstanding that sentence but what it's saying is no different there than what we might say about Bitcoin: only the code that defines how a node responds to a block is normative, not the code that actually authors a new block.  I'll consider accepting an apology— but after all the other times you've been a jerk spewing adhominem and vague allegation about subject matter you were totally wrong about you're going to have to phrase your apology very nicely.

And would you cut with the allegations that you need to quote me for any particular reason? If for some bizarre reason I wanted to edit my comments I could edit them right inside your posts. As far as I can tell you're doing that to imply that I'm dishonest in order to piss me off. Congratulations, you've been successful. I'm wondering if you behave like this in person, and if so— do you get a discount on cold-compresses for all the black eyes you must inspire people to give you?

An argument can be made for that, but I am very skeptical.  Bitcoin is a distributed consensus system. The deepest and most fundamental definition of correctness— above _all_ other considerations— is that they actually achieve global consistency.  It is more important the Bitcoin nodes achieve a consensus than behave in any accordance to an other particular definition of "correct" (though, other forms of correctness matter of course, but they is a dim flicker to the furnace of consistency).  A specification can say many things, but if the installed nodes behave differently from the specification but consistently with each other and its over a matter which would cause a failure to achieve a consensus then it is the specification which is wrong in any practical sense, not the nodes, and the specification which must be changed. In effect any not-practically-executable specification is a dead letter, pure fodder for rules-lawyers to debate, and not something that would exert influence on the real world.

A parallel formal description may be good for additional confidence, but unless it can be extracted (e.g. like the software to extract code from COQ proofs) into reasonably performant production grade code it cannot practically be the normative specification.  Sure, you could call it that— but the claim would be a lie. It's worth noting that suitably authored (e.g. ACSL annotated) C is machine checkable, and also runnable— allowing a who layer of additional tests (e.g. catching some cases where a checker can prove that the algorithm will complete, but failing to warn you that it would take 2^64 operations or words of memory to get there...)— and also allowing it to be an actual normative specification which could functionally define the behavior on the network both on rules-layer paper but also in practice by actually defining the behavior of real nodes which must be exactly matched.

Quoted for future reference. I'm not going to bold the "eventually" in the last paragraph for emphasis. It is a raw quote.

I just wanted to point out that gmaxwell is again spreading FUD and false information.



Almost any discussion where gmaxwell makes a statement takes the same trajectory. Here is the example of discussion about Stratum&Mining vs. getblocktemplate&longpoll:

https://bitcointalksearch.org/topic/m.1403446

You may have missed it because it was hidden in a relatively less oftern read subforum about mining software.

Algorithms and protocols are typically specified in machine-checkable form using languages such as +CAL/TLA+ and PROMELA. Not C code. The implementation should follow the specification: "a program is an algorithm plus an implementation of its data operations".

An RFC would be perfectly capable of documenting the protocol rules, it would just be very hard to do, and very hard to gain confidence that you got it right.

In RFC6716 we went the route of using source code as the primary normative specification: "For the practical reasons of compatibility and testability, it would be advantageous to give the reference implementation priority in any disagreement.  The C language is also one of the most widely understood, human-readable symbolic representations for machine behavior.  For these reasons, this RFC uses the reference implementation as the sole symbolic representation of the codec."

Opinion's differ on this being the best thing to have done for RFC6716, but the argument applies much more strongly for Bitcoin— where even the smallest disagreements can break the software for everyone in the world, not just the users of the oddball software— than a multimedia codec.

It may be the case that future refactoring, cleanups, and modularization eventually end up segregating the protocol rules part of the reference client into isolated parts that seldom change (only when changing the rules!), and then they'd act (either internally or pulled out and stuck in a digital-dead-tree) as better specifications than we have today.

I had initially misunderstood your post, thinking it meant my suggestion to split RFC had some element of self-interest involved with respect to my physical coins.  (and while I realize that it doesn't, I actually really do have an agenda when it comes to making physical bitcoins useful in the real world, and really would put effort into bending protocols to accommodate that, though mostly what I have in mind is the variety of physical notes you can print yourself, rather than my coins)

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.

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.

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.

We surely want to leave the RFC open for physical transactions and gold plated blocks

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.

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.