What end users can do is either learn a programming language and read the code themselves or trust hundreds of others who are doing it.
many do know programming languages. but if the code uses undescribed variables or just randomly selected characters as variables, where no comments describe what the function does.. it is a headache
there is a major difference between quickly reading code to see if it has any "kill commands" and reading it line by line to see what the code does.
it took many people alot of time to read line for line and translate it in their head into 'pseudocode' and then work out what a function does by simulating it. which all can be solved by some basic etiquette. most of the people that actually bother reading it line by line and do simulations are those that then make their own implementations that run better. due to the boysclub of core being close minded to outside criticism.
the issues arise when one coder does stuff that 'works' but does so in a fancy way which could have been done in other ways. though passing a review test, the peers are not simulating it to think of other ways it can be written. they just put their thumbs up and move on. 'trusting' the dev that wrote it.
there have been many times we have seen bitcoin toyed around with later purely because one function passed a review, but later finding out if a function was wrote differently it would work better.
just because 90 spell checkers put their thumbs up, doesnt mean the code is perfect. doesnt mean all 90 spell checkers have run simulations or thought of different strategies. most of they time they quickly browse the code doesnt have 'kill commands' and then "TRUST!!!!" the dev that wrote it knows what he is doing, thus resulting in a fake positive peer review
its why there are all the core fanboys throwing out doomsdays. they dont run real simlations or actually read code, they just read summaries and other peoples opinions and trust.. trust of one person who trusts another who trusts another even when all 3 have not read a line of code. makes things go wrong.
take a notable name in the forum.. Lauda.. he doesnt know C++ yet has been very vocal of his trust of core code and core devs. and people then trust him. all because the code is not laid out.
take the way devs implemented the tx fee.. not only subverting coded methods of 'priority' which would have alleviated the war, but also using 'averages' which dont make the fee's drop reactively when demand is low. but actually keeps fee's up. even when one block is low demand.
EG take a 25 block average.. imagine first 24 are 0.0001 and the 25th is 0.0025 then look at the 'average' after that.. even if demand was near 0 and no one was pushing the fee up.... the "average" itself pushes up
so although the tx fee passes 'peer review' its sloppily coded in a way that is not reactive to low demand. or cares about using code logic to show real priority. all its doing is pushing/maintaining a high price even when demand is low.
it requires pools to avoid using the 'average' and to accept cheap tx's just to break the cycle that the 'average' fee war game is playing.
Show Posts
