Topic: Does a Request for Comments (RFC) for the Bitcoin protocol exist? (Read 4582 times)

Lots of refactorings of the code has been merged in, I don't think that's an issue.

It's not that uncommon to put code into header files in C++ however doing so has a specific meaning - the compiler will try to inline the code. Sometimes that's what you want, eg, for property accessors or trivial constructors, and often it's not.

Satoshi does not appear to have cared much for small files or the distinction between inlined/not inlined. Over time the code can definitely be improved that way. Much code was already split out of main.cpp - but smaller refactorings are easier to merge than larger ones. People who go off and create huge reorganizations all by themselves usually end up disappointed. Slow and steady is the way to go.

Historically there has seemed to be much hostility toward making the code more adaptable.

If someone - not saying who - were to make a specs.h header file, and migrate all the specs that make bitcoin bitcoin, as distinct from, say, litecoin or devcoin or groupcoin or i0coin or ixcoin or Crunchy Berry Coin of the Day or any other coin than bitcoin, would a pull of such a creature even be contemplated, let alone entertained, let alone have any chance at all of actually being pulled?

If not, why not? Wrong filename for such a header file, or what?

Things migrated to there would include such things as maximum total number of coins, number of "satoshis" in a coin, number of "satoshis" that constitute dust, lowercase name of coin, uppercase three roman letter currency code of the currency, mixedcase name of the coin (e.g. Bitcoin, distinct from the lowercase bitcoin), favicon denoting the coin, icon denoting the coin, four magic bytes connect handshake, irc server for meetups, irc channel range for such meetups, and so on, all the things that differentiate bitcoin from things that might have some actual or fancied similarity to bitcoin but are not bitcoin.

Already as I write I reallise actually some of that stuff should go in a cosmetics.h file not in a specs.h file.

And speaking of header files, which in C seemed by convention to mean files which specified the prototypes of functions without actually containing the functions themselves... Is it customary in C++ to make as far as a casual or maybe even not so casual glance can see no distinction between header files and code files, putting pretty much anything into either?

Or would it be reasonable to look into the possibility of putting header file type stuff in header files and code (actual functions, for example) in code files? Or am I just showing my C-background ignorance of how C++ is done by thinking such thoughts?

-MarkM-

so wait, bitcoinj have now full verification mode (https://code.google.com/p/bitcoinj/wiki/FullVerification). are you joining me to use it for mining? to replace the majority of the miners which are using the same codebase. this is open source to have the freedom of doing what you want and not to force anybody to do what the minority want. on Monday Bitcoin was very near to die forever!

"In particular UNDER NO CIRCUMSTANCES SHOULD YOU MINE ON A BITCOINJ VALIDATED CHAIN.

It is difficult to overemphasize this risk. To be safe, bitcoinj must match the behavior of Satoshis code exactly, including all the bugs. Any deviation at all can be potentially used to split the consensus. This is problematic if you are a merchant and could put the entire system at risk if you are a miner."

so why it is open source? let us start to use bitcoinj for mining and we will see if Bitcoin will explode!

EDIT: who did tell you that I like C++? I cannot see a reason why the group called "Satoshi Nakamoto" decided to start the project in C++. maybe they had only one developer which was familiar with C++. I prefer Java for distributed software development. The reason why I prefer Java is it is easy to understand and you have not the possibility to do "dirty" things within the code (e.g. pointer and so on).

B.S.

Please browse the source tree and post specific example of coding problems and how you would improve it.

Since you're so incensed by the code, I assume you've already done this and have examples to share. So I expect you'll be back with examples soon.


... in reality, I know you won't do this, but the point is there: It is open source. Go and take it and change it. And, in my experience, open source projects that are poorly managed or coded ALWAYS get forked and fixed.

If there's an opportunity for someone to benefit by fixing an open source project, it will get fixed.

Are you going to fix it? If not, then this is just noise. In my experience the people who kick up the most stink about open code, usually don't understand how to code at all themselves.

yes you are rigth and I am wrong! open source does nothing say about the quality of the codebase. so let us call this an open source project where the minority understand what they are doing and the majority are observers. in the end it tend to closed source. <-- do you agree with that??

Well on the upside, comments abound... even if not requested.

Often enough open source means no one does anything and everyone understands that.

Which is why open source projects in which anyone does anything stand out from the crowd.

It does not seem much of a leap to go from that to if anyone wants anything done they are free to do it.

But there comes that four letter word, free. As in beer?

We've only raked in less than a billion dollars fergoshsakes, and already people start talking about our freedom to pay to have things done? What the!?!

-MarkM-

No, it is an open source project, as in "a project with open sources and open to contribution from anybody". And your definition above makes no sense and is simply wrong, because you invented it right here.

I still think that sitting around all day doing pretend transactions, even if doing it on salary, isn't very motivating. Though maybe with a huge enough salary it could be rendered somewhat tolerable.

That is why I have always leaned more toward the approach of doing it with real "play money" - "real" play money - game money.

The big problem with the testnet for that is the restarts. Players don't like to know all their hard-earned game-money is going to vanish poof gone any time the developers decide to do a restart.

Get a bunch of players using a bitcoin clone for their game currency though and maybe you could build up a large motivated bunch of people who will happily do all kinds of imaginary commerce, lots of transactions, maybe even try to do doublespends against enemy nations' transactions, maybe try for 51% hash power to block enemy nations' blocks completely, all kind of fun stuff.

For example we could apply the merged mining patches to bitcoin 0.8, add a -playnet flag to commandline and config file that activates the merged mining as a secondary chain capability so we could even do it in merged mining mode as a secondary chain, have that flag also change cosmetics such as the name of the coin and its logo and favicon and such, its data directory, its config file. Presto, a playnet alongside the testnet, a playnet that lets players derive motivation from the idea their playcoins are not intended by design to be ripped out from under them at any moment like happens on testnet.

The code needs all those cosmetics such as the name of the coin, its datadir, its IRC channel, its handshake, its ports and so on to all migrate to one easy to find place anyway so the ever growing number of altcoins don't each have to waste time getting directly to the nitty gritty details that make the code run as this that or the other Crunchy Berry Coin of the Day.

Basically the easier it is for altcoins to use the latest bitcoin code, the better such altcoins will be able to serve as testnets, playnets, cornercasenets, edgecasenets and so on and so on; new features can be deployed first in some playcoin or other - a real playcoin, not a vanish gone up in smoke coin like testnet coins are - for some heavy real-play workouts and shakedowns and burn-ins before deployment to the Serious Real Money bitcoin chain.

This is the same stategy I am using for Open Transactions testing and development: use it first for some real game trade and commerce and finance, for real, to see that it all works and load-test it and so on.

-MarkM-

no, it is not an open source project anymore. open source means a large amount of people develop software together and all people understand what they are doing. this is not the case anymore!

avoid useless discussion! we have here a real large issue with change management. so please shut up or give valuable comments.

first step is create a public testnet with many automatic fake transactions. this is very simple. you have now the funds with the bitcoin foundation.

Who is "you"?

This is an open source project. I dislike the "contribute or shut up" train of thought but everything has bugs and this one was well handled.

You are welcome and encouraged to fund a large, professional testing effort.  We need all the help we can get!

second point: start to use testnet extensive before you go on prodnet. create a public testnet environment with massive transaction volume to get a feeling what can happen on prodnet. this is very important. at the moment you use the prodnet as a test and you are surprised if something goes wrong. this is not acceptable and this is not professional.

Bitcoin core developers please start to refactor the original Satoshi code to get a modular and easy maintainable code base for Bitcoin and then do the documentation.

I think you are getting close to understanding the reverse-delta concept.
It is a postfix notation where forward-delta is an prefix notation.

Currently the "block" message consist of header, Merkle tree & array of transactions. Most of the bytes are used for "array of transactions" are aready a duplicates of what had been seen in the "tx" messages.

When doing reverse-delta the "array of transactions" is not send in the block, only the header and the Merkle tree. The transactions had been already sent in the "tx" messages.

I believe Microsoft Research folks have already discussed this change in their "red balloon" papers:

https://bitcointalksearch.org/topic/microsoft-researchers-suggest-method-to-improve-bitcoin-transaction-propagation-51712
https://bitcointalksearch.org/topic/microsoft-paper-on-adjusting-bitcons-transaction-fees-64738

as one of the ways to remove the incentives to hide the transactions from the rest of the network.

In other words: You want to get your mined block accepted really fast? Send all the transactions ahead.

Or maybe another way: the reverse-delta concept affects both the network protocol and the transaction storage. They don't have to be taken both at the same time.

thank you for your candidness! I'm in progress of doing my own intuitive risk analysis about to put some savings into Bitcoin but with this background I will not risk this. As I wrote everthing above 1-2$ per BTC is speculation at the moment in my opinion.

That's exactly what I mean. Unfortunately it's true, and the solution has been to use the code Satoshi wrote, the reference client, as a module by itself to talk to the network, and then write other modules, such as your wallet code and business logic, that interfaces to the Satoshi client.

If my answer results in you not being able to trust Bitcoin, then sell your coins and stop using it.


Alright, so you are talking about either one of two things:

1) The reference implementation should use a reverse-delta scheme to actually store transactions. But as I've said, the current system runs fine.

2) You're suggesting implementing the UTXO concept, probably as a hard-fork change. Funny enough though, I'm actually working on writing a prototype UTXO implementation right now based on TierNolan's suggestion to use Radix/PATRICIA trees. A UTXO set is definitely something the devs want to see in the reference client, although it's a long-term goal, and in any case no-one has even done a prototype yet. If it is adopted, yes, blocks may eventually be 100% reverse-delta, but that's a really long way off because you would need a consensus...



...or maybe you're confusing reverse-delta schemes with the blocksize limit. Reverse-delta doesn't decrease the size of blocks, only the amount of data needed to prove the existence of a given transaction. (this is why I'm doing my prototype; I'll need it for fidelity bonded trusted ledgers eventually) Again, RFCs and alternate implementations have nothing to do with this issue.

Anyway, I've wasted my time enough and have real work to do.

Those arguments about block size are a classic example of strawman argument from the "old money" & "old code" side. The forward-difference state maintenance was good for the proof-of-concept. But in practice nearly everyone does reverse-differencing.

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

It is really old and well researched problem and almost all practical solutions use reverse-delta or some variant involving reverse-differencing.

I fully understand that given current situation there are no human (and other) resources available to move the network protocol and the code base forward.

Just don't say that there's no way forward.

As much as you hate my Bitcoin Airlines story it is a decent analogy: adding "fuel fees" to the "seat ticket transaction price" isn't going to make the Airline more popular and safer.

modularity is the first step to control a complex system.