Bitcoin Forum

Truth be told i am a fun of bitcoin and other crypto technology but utterly disappointed by the quality of code.
There was not even single line of documentation all of the few files I peeked through. In several of the technology companies I worked, code without proper comments along header was considered to be a garbage and not worth a single cent. There are lot of philosophy behind making a good coding practice which I can not start over here, it is even taught in CS101.

If you think it's that bad why don't you contribute to tidy it up? It's an open source project and everyone is welcome to add their expertise.

https://github.com/bitcoin/bitcoin

Well, it was basically an experiment that got superhit,..  the later batches of it should had been properly coded buy yes, first attempt is never good for a new person to read the code..

I am seriously about forking another branch of bitcoin, but no code only comments.
The fork will be called bitcoinComment.

What files are you peeking through that's there no documentation? Sure, I'll admit that there isn't as much documentation as there could be, but to say that there's no documentation at all is just completely false. The code has many comments explaining many of the consensus critical things that it does. But of course there are some places that are lacking and most of those are holdovers from the early days when standards were lower.

And, of course as an open source project, you can write and submit code comments yourself instead of complaining about it.

i dont remember which files it was code to code from first to last lines.
I wish I could contribute but now working on my own mining coin steering platform to be hosted on http server and I am putting my full effort on that. I am planning to make it public in hopes of getting people adopted and most likely be a free to use.

The genius of satoshi was in the cryptographic field, and most importantly, having the vision to put all the (already existing) pieces to form a new thing. PoW was already there, distributed networks with nodes were already there, he just made a pack and it worked. The code was rough, apparently it lacked a lot of fine tuning, but that's not important when the concept is genius and it actually works in practice.

This is why someone that is a better coder could come up with another cryptocurrency, but if it's not a game changer at the scale of what Bitcoin was in 2009 (and still is) then it's not going to get anywhere, the network effect is too strong in Bitcoin.

Whoever wants to challenge Bitcoin must come up with with a completely new way to solve the Byzantine General's problem and do it in a much more efficient way, which I doubt it's going to happen for at least 100 years which is what these big problems usually take for someone to come up with new solutions.

Throwing completely substancesless insults at quality work in order to fool people who couldn't tell for themselves into thinking that you're brilliant seems to be a favorite pastime for folks who feel insecure about their lack of competence adequate enough to accomplish anything themselves.

bitcoin is falling out of favor with outrageous fees and being congested during peak hours. And appears to have become political. There are lot of other coins catching up to fill that avoid. But I agree, it is still the dominant coin but I am almost sure if not something significant being done, another coin will catch up in the next few years. IMO.

My biggest gripe is mining, no longer mineable by small-time GPU-ers like me, and as far as mining concerned, it is not decentralized anymore.
What the core dev-s are doing against the ASIC mining is not certain. I am working on platform to be able to switch many hosts into any coin and bitcoin (and other asic compatible coins) is/are not even in the consideration for obvious reason.

What exactly would you like them to do? Hard-fork and completely change the underlying POW algorithm?

Because that's pretty much the only way to do anything about ASIC mining... SHA-256 is "ASIC friendly", you can't change that.

I don;t know, I haven't been involved. But on the other hand, do you think ASIC friendly is a good thing (mining centralized)?

If I were a CEO of a Bitcoin LLC or Bitcoin Inc., I will do definitely strip out SHA-256 and plug-in GPU friendly algo. Not only that I will start it in a blink of an eye and possibly re-architect so any algorithm can be a "plug-n-play"-ed.

Look at some of the advice and opinion you have received on this:



If you are really a coder, you would get the thing about "Standing on the shoulders of giants". If your work ethic was anywhere near that of the people who have made bitcoin code, network and social phenomena possible, we would be getting valid suggestions and feedback. Maybe some real work too.

But instead you take it upon yourself to become the hypothetical CEO of a hypothetical Bitcoin LLC, completely ignoring the whole decentralization criterion. This is the best you could come up with:

• "I don't know"
• "I haven't been involved"
• "But Yo, I could totally be THE CEO"...LOL

You Sir, are a lot of hot air and no substance. And from post history, it seems you have been that way for a lot of years. What a waste of time and potential!!

so saying that, u must be a better than me, perhaps must be a one of those giant lololol  :D :D :D, when critisizing me, u completely forgot about how big of an loser u re urself, game of critisism is ths tough dude, at least i my critisizm did not directed to you but you ended up being critisizing me for nothing, for that i can only say one thing in reply, fok yo and get the fok out of hyoooo...

Sure, Bitcoin has it's problems, but something that scammers typically claim is how their altcoin is going to solve Bitcoin's problems, only to find out that eventually their altcoins succumb when faced with the same problems and deal with these problems even worse, usually by centralizing the network (huge blocks) or by a system that is exploitable (PoS, DAG-Tangle stuff)

There isn't a single coin out there that is objectively superior to Bitcoin and solves it's problems, if this was the case, everyone would dump and sit on that other network, but guess what, that doesn't exist.

The "Core devs" don't have enough power to do something about mining. All they would create is yet another altcoin, because I doubt the rest of the community would follow, unless the idea was complete genius and long lasting.

You just stated 3 blantant lies and got called out for it, yet you continue to keep trolling or?

That's the thing. It's open source and decentralized. There's no such thing as a "CEO" who controls how bitcoin works. There's consensus that determines the changes.



Asics have nothing to do whether or not the mining is centralized. Sure, it might make the process of mining harder, ( meaning that only big companies will do it, but anyone can buy an asic and operate/mine for themselves. No one is stopping you. (+ There's not 1 company having 51% control right now. ( and there probably won't be.)

I also read the source code. IMVHO (based on 40 years of computer experience) code is pretty reasonably commented.

I looked particularly in  src/primitives, src/rpc, src/wallet and some other subdirs.
In .h files that contain data descriptions, some structures have description of each field.
After reading those files, .cpp files can be easily read and understood.

well, i did not find it reasonable. i have less than 15 yrs exp, but imho, experience does not really count much after 5-6 yrs. In fact, if particular engineer is opinionated about commenting and documentation is NOT necessary it seems it is even harder to have 'em change their habit because he/she becomes more inflexible as person gets aged.

writing a code is easy, documenting what you do is hard, as well as debugging as hard, fixing bug is hard, root causing is hard. i could say most of the engineers i interacted with love writing (shitty)code  but hates debugging, documenting and root causing problems so "brilliant" engineers mostly resist doing anything other than writing shitty code. I dont expect better on this forum either.  so I expected some reasonable code when look through bitcoind but was disappointed.
Anyways I am out of here :D

Seriously is wrong with you. Your post is so retarded I wanna tell you to take some English class as well as some reading comprehension, analytical, reasoning and critical thinking skills.

I can not say for sure, personally I'd rather bitcoin succeed as dominant but the way it is now with super high fees, and other problems, not sure. And it is not jus I am saying many people is concerned about it. I can not say which one will prevail over Bitcoin and/or which technology will prevail, there is no single person that can analyze 1000+ coin's whitepaper make a judgement, so only time will tell. I myself usually interested in gpu mining and managed to go over few dozen coins only, but the way I see now there are several altcoins that are looking better than bitcoin.

That's ironic, you can't even compose grammarly correct sentences yourself, yet this is your counterargument to me? sounds like something a toddler would say.


Lies, lies and lies.


1-5/sat per byte gets your transaction confirmed within an hour currently. https://jochen-hoenicke.de/queue/#1,24h Which means you can transfer 1000$+ for less then a dollar.

This one just got confirmed, with only 0.22$ in fees. https://blockchain.info/tx/d09284762b642d8ceda7d5e12304316d6299362139220b1ed7d81ab023f0424b ( And this transaction wasn't even P2SH-P2WPKH)

I think it is actually becoming more and more preferred that one writes code in a way that does not require comments.  You often will hear things like "good code explains itself."  I'm not too big a fan of this, but that is the direction the industry seems to be going in. 

That being said, bitcoin does still fail here at times--especially when you encounter single lines where boost functions are passed to other boost functions to other boost functions in a way that quickly taxes your senses of what is really happening.  The jazzy naming conventions also are unappealing to me.  (Ex: CConnman.  Just call it ConnectionManager ffs.)  For the longest time everyone seemed to be perfectly okay with AppInit2 as a function name.  Now we have AppInitMain, which isn't at all intuitively different from the name AppInit.  Overall, the code base does seem to be improving.  Two steps forward, one step back.

I dived into the bitcoin code some years ago, and also did quite extensive work on Dash's code (fork from btc). It is true that bitcoin's source code is not the ultimate example of amazingly structured and documented codebases. However, I remember that I was almost impressed by how better than expected it was.

If you take into consideration the age of the code, the language that definitely doesn't help (serialization for example is responsible for a lot of the mess), the number of platforms supported, and the fact that we are talking about a by definition very rigid project due to security implications and consensus, the code base is surely not that bad. There even parts dated back to Satoshi that are plain impressive in design. It's a huge project and can feel overwhelming, but I was able to understand the structure and navigate the code with little effort. That is not common in projects of this scale.   

OK This is the war of personal opinions.  I can understand this code with this amount of comments and you cannot.
The quality of software is determined.
1. Correctness; 2. Security; 3. Performance, not by density of comments.
And again IMHO, I consider  that https://en.bitcoin.it/wiki/Bitcoind is good enough documentation.

 

It's already BEEN done, its called BITCOIN-GOLD aka BTG, and guess what its owned by the same ppl who own the chinese mining asics in china, they covered their bets by owning the GPU variant of BTC

Even here on this forum, but done  its called BITCOIN-Z, btc-z, its here and trades at 0.0000001 cent, and they made 21 billion of them :) Again, it uses the exact same GPU hash as EWBF miner, e.g. zcoin

chinese miners own +90% of the biz, IMHO they own this forum by way of amazon(server), which is tied to alibaba, where Ma is partners with the ASIC guys, ... its all a handful of people that control all,

How can you rectify this? U can't, its too late, ... its like a child growing up and realizing he has to get get a job, and can't live with parents forever, someday the HODL'rs wake up and realize the parents are chinese and own it et-al

Well the OP is a newb, but I will help him,

First of all you are right, Satoshi was not a coder, and nothing in BTC 1.0 is anything a 3rd year CS student hadn't heard of,

IMHO Satoshi was a math-guy, self taught to code,

Here look at the history "Death&taxes" wrote in 2013 here in this forum "Satoshi was a shitty cryptographer, he picked the worst shit around both sha-256 & ecdsa-secp256k1", so there goes the theory that Satoshi was a 'crypto expert' NOT

Sure you look at BTC 1.0 source its terrible, but the reason that 1.5 is clean, is cuz 1,000's of guys have clean up the C++.

Now its been rewritten in python by Buterin, and into GO by others;

The code is NOT commented, for the life of me when people say 'open source' but NO comments I call this obfuscated code, code without comments is just BS, but then nobody is willing to admit this, I'm firmly believe most likely the comments might have been stripped,

BTC was written by a TEAM at NSA, the moniker SATOSHI was just handle to coordinate the dissemination, the actual authors pulled their comments so it would appear the code was written by a solo individual, it was not, this is clear studying 1.0

I agree with the theory that the ppl at NSA weren't smart enough to finish the project, so they released it into the wild.

1.) SHA-256 is NSA
2.) ECDSA SECP256k1 is NSA, paid to certicom, fact
3.) the bitcoin-satoshi white paper is 100% stolen from a 1996 NSA document called 'how to make a mint', funny that NOBODY ever gives NSA the credit for the white-paper? funny huh? http://groups.csail.mit.edu/mac/classes/6.805/articles/money/nsamint/nsamint.htm

Chow  & Maxwell keep the Myths of BTC alive, perhaps paid well by the original, but even more likely they are part of the orginal NSA team, and thus they stand by permanently to 'guide' their child

The above is/was just a little history lesson on btc

I can somewhat agree that industry moving forward self descriptive code and you guys put forth a challenge and argument, but still I believe at most companies I worked, the code sucks, and engineering hours are wasted. For large enterprise where million and billions are at stake poor code become actually unfixable.

Self descriptive code that you can glance through will work with smaller project and/or smaller functions with few dozens or hundreds of code, but I have worked with overly convoluted functions that are several thousands lines work and it is a b** to work with. It is always better to describe in literal language with IN/OUT clearly defined like a black box.

it is always welcoming to challenging opinions here, save for a few crude nuggets who only wants to bash and troll around.

Example of command line processing function header. My english aint no perfect as it is my second language but that is not the point. It is only few hundred lines of code, believe me I don't ever wanna look at the function's code! I guarantee, it will take days or weeks to figure it out!!

#   The pSysArgv is the all values of sys.argv as it is. This is what the
#   users of particular enters in the command line.
#   The pSupportedArgv is the tuple list of supported arguments in dictionary format passed
#   on by scripts and therefore its contents are specific to a particular script's implementation.
#   However following universal convention are used throughout to enable uniform processing
#   for any or almost any types, variants and number of switches and arguments.
#   Dictionary key holds the name of the argument in the naming convention: "--<argName>"
#   Dictionary value holds the tuple list object, serving as an initial indicator implying how many
#   values the arg needs (refer to examples below):
#   Current implementation divides the tuple values as two types in general:
#   1. (<value1>, <value2>) - implies literal processing, which means the supportedArgs lists out the
#   actual values that user can enter in the command line for that particular switches and no other
#   allowed value. Example is if particular scripts --drive switches accepts only C: D: E: drive
#   letters and any other drive letters are not allowed.
#   2. ('__range__', <list>) - implies that there is no restrictions on the values provided by user
#   for particular switch, however the <list> contains the range of number of allowed values for that
#   particular switch. This is useful in case, it is not known what value user will be putting at the
#   command line or there too many possibilities for particular variable.
#   For example, if --ip switches requires one value which is IPv4 address but the range of valid
#   IPv4 is too many to listed out as literal however --ip will accept only one value, in this case
#   supported switch is declared as: ('__range__', 1)
#   if --ip allows up from one to up to 5 different IP address following, (as in the case:
#   --ip 10.24.11.0 10.0.0.1 12.0.0.1 192.168.0.1 172.17.0.0
#   then it should be declared and passed as:
#   ('__range__', 1, 2, 3, 4, 5)
#   or possible:
#   ('__range__', range(0, 5))
#   pSupportedArgs typical examples are below but not limited to:
#   -------------------------------------------------------------------------------------
#   Arg name     Initial indicator of value count, tuple list type   Valid user input
#   -------------------------------------------------------------------------------------
#   '--timeout': (1,),  (needs one and only one value for argument)
#                                                           -> user input --timeout 100
#   '--timeout': ()     (needs no value)                    -> user input --timeout
#   '--timeout': (1,2,3)(needs somewhere between 1 to 3 values, inclusive)
#                                                           -> user input --timeout 1
#                                                           -> user input --timeout 1 100 2
#                                                           -> user input --timeout 1 100
#   !!! This is currently unimplementable, needs to look!!! Currently it is not supported.
#   '--timeout': [1:CONFIG_MAX_ARG_VALUES] (needs somewhere between 1 to CONFIG_MAX_ARG_VALUES
#   number of values, which effectively implies "greater than 1")
#                                                           -> user input --timeout 1
#                                                           -> user input --timeout 1 100 2
#                                                           -> user input --timeout 1 100
#                                                           -> user input --timeout 1 2 3 4 5 6 7
#                                                           -> user input --timeout 1 2 3 4 5 6 7 10 11
#   -------------------------------------------------------------------------------------
#   Once the arguments are processes and validated, the values of the dictionary will be populated
#   with the user supplied values from the command line. If user has not provided the argument, its
#   corresponding dictionary value remain unchanged, tuple list type, implying that the caller script
#   will not process it.
#
#   input:
#   - pSysArgv - sys.argv() as it is.
#   - pSupportedArgs - dictionary type consisting of tuple list of argument that particular calling scripts supports.
#       - key holds the name of the argument.
#       - tuple list type holding indication of how many values are needed for the argument
#        (for details, refer to function header)
#   - helpStringArr - if user input --help argument, use this string to display the help message.
#   output:
#   - pSupportedArgs' values are populated with the validated command line argument values as list type.
#   - if particular argument is not provided by user, value remains unchanged as list tuple type.
#   - EXIT_NO_ERR if --help is supplied.
#     EXIT_ERR on any error condition.

def prepArgs(pSysArgv, pSupportedArgs, helpStringArr):

Again, IMHO to be useful this comment should be 4 - 5 times shorter, while reading it as wanted to scroll down in order to see actual code :).  I do not see much sense in writing comments addressed to person who does not know the language in which the is written.

May be it makes sense to rewrite whole bitcoin kernel using some modern language, like Ethereum did already?
Or favor C++14 and get rid of Boost library? :)

it can not be shorter because function itself has a broad range of usage parameters to be explained, it is not like "hello world()" function. If you wanted to look at function, it appears you are conditioned to work with code that continually keep breaking and/or needs fixing (which of course not a good practice considering what the function is designed for). Function are normally designed to be bug free or near bug free to make useful.

I still disagree with you.
Your comments look like user's help. And probably that many examples are good for user's manual.

But one gets into source code for two reasons: 1. tox fix the bug; 2. to modify the program.
For the person who has to support this program description of fields as comments within the code probably will be more helpful.

But we are speaking about bitcoin code that is successfully running and is being modified from version to version.
And to call this shitcode I consider indecent for the programer.

i am not saying that it needs to be maintenance free, but to minimize time on maintenance code comment is essential and it is not actual my opinion rather inherited practice that i have worked with respected engineers who is 20-30 years more experience than me were respected by peers. Too many times I have seen software projects eat up endless cycles and resources and it is always done by shitty practices and shoddy design. Of course I am not lecturing you to do the same but the your way of doing will undoubtedly put in the majority of software engineers in the industry who does a poor job. If you involved in a large software project or your own project will grow large and eating more and more of your cycles , you will certainly will feel the need to do a proper commenting. I can not lecture all these stuff here may be you can read through if it makes you interested if not interested i will end the argument here.

https://javarevisited.blogspot.com/2011/08/code-comments-java-best-practices.html

The design of bitcoin took a complicated problem and made it as complicated as it could possible get
and then spent time fixing design flaws of its own making.

Bit-Torrent produces a useful output of about (Guessing here) 100 gigabytes per second and also had to overcome
design changeless and has stood the test of time but Bitcoin only got as far as 8K per second and most the design
of hashing a file was borrowed from Bit-Torrent and put out as something completely new when it was a re-hash of
something that had already been discovered.

Yes sure mr moderator I know my reply was "off-Topic" again right ! 

Please try to read the text to which you are responding.
I wrote about maintaining  the code, not about maintenance free code.

Please try be logical
Few posts above you said that my 40+ years of programing experience do not matter.
and now you bring the argument about "respected engineers who is 20-30 years more experience than me".

You reference to a a post which states
quite opposite to verbal diarrhea in your example of comments.
 

lease try to read the text to which you are responding.
I wrote about maintaining  the code, not about maintenance free code.

Please try be logical
Few posts above you said that my 40+ years of programing experience do not matter.
Quote
...experience does not really count much after 5-6 yrs...
and now you bring the argument about "respected engineers who is 20-30 years more experience than me".

Firstly, I was referring to the average and below ones who does no grow and stay current with his/her skillset.

For later, I was referring to the top engineers who continually improve their skillset. It has been implied wish you had been noticed it.
This is getting savage.  :D

Hm, I do not think that I will continue discussion with a person who consider himself a programer but cannot even put "quote /quote" brackets correctly.

Hm, I do not think that I will continue discussion with a person who consider himself a -->>>>>programer<<<<<--  ;D ;D  ??? ??? but cannot even put "quote /quote" brackets correctly.
Saddened, instant karma.  :D

Stated above i am welcoming arguments not some crackerjack trolls but now you started to picking me on my ass, why don't you get fuck out of my back, wy'a? i am not interested in troll fight with loser like you.

Oh LOL, and you are speaking about trolls :) :)

You did not answer a single question I asked you. Instead you have concentrated on my modest person. Actually you are trying to troll Bitcoin devs and myself. So I am in good company :) :)

You could not read bitcoind code, you could not read the its documentation.
So what else is left to you but to blame others for that.

Maybe (but with very low probability) you will realize that code that you consider "shitcode" successfully runs for almost ten years.

So, go ahead and write your "comments only" coin :)

 

U re such an idiot no decent programmer argues against clean code, but i have to concede i do expect to run into tons of idiots on online forum.

I see the person who continues to argue against working, secure and efficient code. How will you call such a person?

You expect many similar to yourself in this forum. You are wrong again.
Morons like you constitute an absolute minority here.

And thank god, this one is especially painful to read. Not sure it's worth anyone's energy.