I have a doubt about Bitcoin

[AicecreaME]

Updates are necessary to make things more better than before, that's normal to the technology, it is evolving. Technology without updates or can't be updated is small, or we can say that it's not technology at all. Bitcoin is revolutionary, that's why it keeps on surprising people, it is awesome in my opinion. If you have doubt about it, then simply don't invest on it, simple as that.

[yhiaali3]

These are views, so differences and divisions occur. Some people believe that things should remain exactly as they are when Satoshi wrote the Bitcoin code. Others see that things are developing and there are problems that appear and new needs that we have to develop Bitcoin according to these needs. Perhaps you see that this A problem, but others do not see this as a problem. Rather, they see it as a duty to change. Some may agree with you and others do not. This is very normal.

[goldkingcoiner]

There seem to be too much development taking place on bitcoin. Changes always being proposed. How are we ever going to be able to trust that bitcoin will never change if people are always trying to propose changes to it and get it implemented.

#1: that kind of ruins the idea that bitcoin is going to be the same today as it was yesterday and tomorrow. today they might be proposing a change to some fee mechanism. tomorrow it might be changing the max supply.

#2: anytime you introducing new changes to bitcoin, you run the possibility that you are introducing bugs. apparently the ability to foresee bugs is not absolute so they don't know what bugs they might be introducing when they introduce major changes like Taproot https://www.investopedia.com/bitcoin-taproot-upgrade-5210039.

You can't just keep changing bitcoin trying to make it better and better forever. At some point, it needs to become immutable. So people can know what they are getting. In full. I'm not sure but I'd imagine the codebase for bitcoin is a mishmash of hard to read files. Another not so nice thing. But that's a result of its development style. Adding on new things on top of old things. Or alongside. Ideally you lay out a full blueprint of the entire thing at the very outset and design and develop it once. Done. The rest is bug fixes if necessary but no more.

Anyone that's ever tried and program some simple software and then later on come back and add new things into it it can end up being a nightmare to try and understand and maintain the code...there's alot of bitcoin users out there who don't understand this aspect of bitcoin at all!

The very beauty of Bitcoin, aside from the fact that it is truly decentralised, is that it can improve and become better. And the ones who make and vote on these improvements are the good people of the Bitcoin community. So basically you have two elements here: Financial Freedom and Financial Democracy.

That alone is something that makes it immutable in my eyes. As well as in the eyes of many Bitcoiners on this forum, I would say.

And obviously the codebase is hard to read, especially for people who have never learned how to read them. But the same can be said for almost any big software. Is the coding of photoshop easy childs play? No, its the result of thousands of people working together to create insane amount of code. The code someone made is stacked on top of code someone else made.

[kryptqnick]

There's a somewhat helpful distinction (in philosophy) between essential and accidental properties. To me, essential properties of Bitcoin are that there's a fixed supply, there's a consensus mechanism, there's no making a fake Bitcoin (like fake fiat banknotes), and there's no central authority issuing Bitcoin or regulating the price. The rest are important tweaks, and they can change a lot over time, but as long as, in essence, Bitcoin remains the same, I'm fine with it. And I also believe that if something essential gets changed, that will cause a hard fork and that essential change will just make a Bitcoin close that does something differently but isn't really Bitcoin. I'm fine with how the changes are implemented and how Bitcoin is doing.

[larry_vw_1955]

I don't think bitcoin code is very well documented and structured.

I'm assuming you are talking about bitcoin core when you talk about code, in that case it is very well structured although core like many other open source software does not have enough documentation.

I'm talking about bitcoin things like taproot. Say I wanted to look over the source code for it. I have no idea where that would be. And looking at https://github.com/bitcoin/bitcoin didn't help at all. So it's not well documented about how to find things.

Also, there's alot of "open issues" 479 of them right now. Check it: https://github.com/bitcoin/bitcoin/issues

That can't be good. Hopefully none of those bugs makes its way into bitcoin. Or did it already get into bitcoin?

i don't think it's very well structured in the sense that I think I understand the secp256k1 curve and how it works but trying to understand how they broke it down and put it into a zillion different files, doesn't make much sense. https://github.com/bitcoin/bitcoin/tree/master/src/secp256k1

I think it would be easier for someone to learn how secp256k1 works mathematically and then programming it themself than to try and go through the bitcoin core implementation of it to try and understand how it works. because they put it into so many files you can't really understand what's going on. you get a headache just looking at the list of so many files.

And obviously the codebase is hard to read, especially for people who have never learned how to read them.

as i said before, i heard someone say that bitcoin is spaghetti codehttps://en.wikipedia.org/wiki/Spaghetti_code and they said it more than once and they had a negative implication when they said it. are they wrong? obviously i'm no expert on bitcoin core but when i hear someone talking like that, i need to know why they think that way.

because if bitcoin is spaghetti code i don't see how they can fix that. its always easier to design something right the first time than try and go back and restructure it to make it more modular/readable/understandable later on. as well, when you have to go back and try and restructure it, you run the risk of introducing bugs.

[gunhell16]

There seem to be too much development taking place on bitcoin. Changes always being proposed. How are we ever going to be able to trust that bitcoin will never change if people are always trying to propose changes to it and get it implemented.

#1: that kind of ruins the idea that bitcoin is going to be the same today as it was yesterday and tomorrow. today they might be proposing a change to some fee mechanism. tomorrow it might be changing the max supply.

#2: anytime you introducing new changes to bitcoin, you run the possibility that you are introducing bugs. apparently the ability to foresee bugs is not absolute so they don't know what bugs they might be introducing when they introduce major changes like Taproot https://www.investopedia.com/bitcoin-taproot-upgrade-5210039.

You can't just keep changing bitcoin trying to make it better and better forever. At some point, it needs to become immutable. So people can know what they are getting. In full. I'm not sure but I'd imagine the codebase for bitcoin is a mishmash of hard to read files. Another not so nice thing. But that's a result of its development style. Adding on new things on top of old things. Or alongside. Ideally you lay out a full blueprint of the entire thing at the very outset and design and develop it once. Done. The rest is bug fixes if necessary but no more.

Anyone that's ever tried and program some simple software and then later on come back and add new things into it it can end up being a nightmare to try and understand and maintain the code...there's alot of bitcoin users out there who don't understand this aspect of bitcoin at all!

How Bitcoin has lasted in this industry from 2008 until now 2022 and in the years to come are you still doubting? I think you should not doubt my friend. Many people have indeed given suggestions since the creation of Bitcoin, and in those times the only change that I have seen in bitcoin is that it has a so-called BTC segwit address, which is the only change that has been seen in Bitcoin. If it is okay, then there are a lot of suggestions or proposals, are they all done in bitcoin? Is that approved? Yes, I know that at any time there can be a change, but for a long time, those behind this Bitcoin also keep in mind what should be done right and what should not be done, so let's just trust the concept that bitcoin has and I know it's not that will change.

[NotATether]

I don't think bitcoin code is very well documented and structured.

I'm assuming you are talking about bitcoin core when you talk about code, in that case it is very well structured although core like many other open source software does not have enough documentation.

I'm talking about bitcoin things like taproot. Say I wanted to look over the source code for it. I have no idea where that would be. And looking at https://github.com/bitcoin/bitcoin didn't help at all. So it's not well documented about how to find things.

Also, there's alot of "open issues" 479 of them right now. Check it: https://github.com/bitcoin/bitcoin/issues

That can't be good. Hopefully none of those bugs makes its way into bitcoin. Or did it already get into bitcoin?

i don't think it's very well structured in the sense that I think I understand the secp256k1 curve and how it works but trying to understand how they broke it down and put it into a zillion different files, doesn't make much sense. https://github.com/bitcoin/bitcoin/tree/master/src/secp256k1

I think it would be easier for someone to learn how secp256k1 works mathematically and then programming it themself than to try and go through the bitcoin core implementation of it to try and understand how it works. because they put it into so many files you can't really understand what's going on. you get a headache just looking at the list of so many files.

And obviously the codebase is hard to read, especially for people who have never learned how to read them.

as i said before, i heard someone say that bitcoin is spaghetti codehttps://en.wikipedia.org/wiki/Spaghetti_code and they said it more than once and they had a negative implication when they said it. are they wrong? obviously i'm no expert on bitcoin core but when i hear someone talking like that, i need to know why they think that way.

because if bitcoin is spaghetti code i don't see how they can fix that. its always easier to design something right the first time than try and go back and restructure it to make it more modular/readable/understandable later on. as well, when you have to go back and try and restructure it, you run the risk of introducing bugs.

Code =/= documentation. Systemd and the Linux kernel both tried that, the resulting speghetti that came out of it made it difficult for anybody to understand what was going on. Also, modularity has nothing to do with this issue - even fully modular codebases without docs are hard to understand.

Bitcoin Core does not attempt to make the code easy to read. IMO, that is the whole purpose of Doxygen, where you can just put "doc-comments" above a function or class, and a special make target turns that into HTML documentation. Which Core makes some use of BTW.

Secp256k1, is, in fact, is not contained inside the main Bitcoin codebase - it is offset to a separate library.

Most BIPs that get Finalized often only have a Bitcoin Core pull request as their reference implementation. Some authors are trying to change that by making standalone implementations.

Ultimately, software engineering is a complex task, and changing the language to easy-to-read Python (for example) won't change a thing about its complexity. Developers must suppliment the code with extensive documentation, but this project doesn't have enough active devs for that.

[larry_vw_1955]

Ultimately, software engineering is a complex task, and changing the language to easy-to-read Python (for example) won't change a thing about its complexity. Developers must suppliment the code with extensive documentation, but this project doesn't have enough active devs for that.

So it would be impossible to have a functioning cryptocurrency in say just one big file with only say 1000 lines of code? What if that was possible? Wouldn't that be better? Why does it have to be millions of lines of code broken into thousands of files?

Complex doesn't have to mean large does it?

[NotATether]

Ultimately, software engineering is a complex task, and changing the language to easy-to-read Python (for example) won't change a thing about its complexity. Developers must suppliment the code with extensive documentation, but this project doesn't have enough active devs for that.

So it would be impossible to have a functioning cryptocurrency in say just one big file with only say 1000 lines of code? What if that was possible? Wouldn't that be better? Why does it have to be millions of lines of code broken into thousands of files?

Complex doesn't have to mean large does it?

You misunderstood my point. This post (the one I'm replying to) seems to be talking about complexity but is actually referring to modularity.

There are many modular codebases on Github that are easy for developers to read and understand what is going on. Core is not one of them (almost all include and source files in the top level src/ dir, and parts of features grouped into a single file with arcane filenames and functions makes it difficult to find what you are looking for).

There are large projects out there like Chrome which are also modular because all the files have an organization. A 1000-line single-file project like the entire SQLite3 source code is not modular (that would be a PITA to extend in a code editor).

Of course, complexity increases with codebase size - complexity simply means that there is more stuff that devs have to learn to know the whole project. But Core could do a much better job in organizing the files and functions in such a way that it is easier to find what you are looking for.

[danadc]

Doubts about bitcoin are considerable, many have doubts about its development, but everything becomes clear when they understand that Bitcoin's limit is what makes the difference in all this, it means that there is never inflation, and that it is reduced to the half is for the miners, there will come a time when all the bitcoins will be mined and it will be another story, and it is possible that I have a very high value in fiat, there is still a long time to see it, but if a study is made of bitcoin every day it will be valued much more.

[2stout]

There will always be doubts with Bitcoin, but many of these have been put to bed over time.  Of course new ones pop up from time to time- some real and some imagined; however, Bitcoin's track record and adherence to the vision since its inception should provide some solace.

[franky1]

So it would be impossible to have a functioning cryptocurrency in say just one big file with only say 1000 lines of code? What if that was possible? Wouldn't that be better? Why does it have to be millions of lines of code broken into thousands of files?

Complex doesn't have to mean large does it?

the problems i see with the code is not that its in lots of files
infact of certain functions and variables were organised and described well. having them in separate files makes it easier to find them,

its the naming practice of them files that does not always meet the descriptions of the functions variable contained inside

its the cludge of over reusing the same things in many places rather than using a reference variable from one location that then allows easy change without having to look for every instance of its use.

take how they use the /4 as the preset for the silly "weight" cludge math of ignoring actual bytes to fake cheap discount tx's.. this /4 is used everywhere
if there ever was a time to remove the /4 to finally actually utilise the full 4mb of a block.. for actual full tx length and stop miscounting/disregarding bytes. they should not have to read every single file for the /4 usage and instead just change a variable in a header file that then sorts out all instances of the usage of /4

there are other bad coding techniques used. yep lack of comments to explain what each code section function does.
also the naming of certain aspects has no real descriptive meaning.

EG "weight" data/code has no tangible weight(no physical weight). yet they call it weight rather than length/size

EG "witness" a witness is a third party used as WEAK evidence(questionable/able to lie) that the first party done something.. sorry but a signature is not a witness. a signature is made by the person in control. its not a witness statement from some random person walking passed something he just happened to have seen someone else do

for something that declared itself the DEFACTO reference client. they have done a bad job of being a reference client

[larry_vw_1955]

its the cludge of over reusing the same things in many places rather than using a reference variable from one location that then allows easy change without having to look for every instance of its use.

take how they use the /4 as the preset for the silly "weight" cludge math of ignoring actual bytes to fake cheap discount tx's.. this /4 is used everywhere
if there ever was a time to remove the /4 to finally actually utilise the full 4mb of a block.. for actual full tx length and stop miscounting/disregarding bytes. they should not have to read every single file for the /4 usage and instead just change a variable in a header file that then sorts out all instances of the usage of /4

just awful. maybe that's one reason why i heard someone call bitcoin spaghetti code. but i'm sure he had other reasons too. a beginning programmer doesn't even do silly things like that. unless they want to got fired. right?

now the problem is, when they go back, if they ever do go back and try and rectify this then they run the risk of introducing a bug or not making the change in all the places where /4 appeared not that it would cause a huge problem but later down the line it could. the more i hear about how bitcoin core is written with examples like this the more i don't ever want to look at it at all. i hope other people don't feels that way because bitcoin needs all the eyeballs on its code it can get.

there are other bad coding techniques used. yep lack of comments to explain what each code section function does.
also the naming of certain aspects has no real descriptive meaning.

EG "weight" data/code has no tangible weight(no physical weight). yet they call it weight rather than length/size

EG "witness" a witness is a third party used as WEAK evidence(questionable/able to lie) that the first party done something.. sorry but a signature is not a witness. a signature is made by the person in control. its not a witness statement from some random person walking passed something he just happened to have seen someone else do

for something that declared itself the DEFACTO reference client. they have done a bad job of being a reference client

i understand those issues you're talking about too. but what i cannot accept is if the bitcoin codebase is not well structured and professionally written. there are programming guidelines that lead to readable and maintainable code and i'm not sure how well bitcoin has abided by those things. that's a serious concern because well it just is. yes bitcoin just works but I think it's more of a miracle than we imagine.

https://dzone.com/articles/how-do-you-write-code-that-is-extensible-and-maint anyone can google search this kind of stuff and realize it is common sense and even more importantly, essential for larger projects.

we can't rewind the clock though on bitcoin core code. it is what it is. that's one of the problems that happens if you start out on the wrong foot it's hard to get back onto the right one.

[bestcoins1]

There will always be doubts with Bitcoin, but many of these have been put to bed over time.  Of course new ones pop up from time to time- some real and some imagined; however, Bitcoin's track record and adherence to the vision since its inception should provide some solace.

I have never placed any doubts on Bitcoin since I got to know it even though there were people who laughed at me when I was new to Bitcoin. Well if nowadays there are still people who place their doubts on Bitcoin when they are new to Bitcoin, I think it is still in a reasonable category because someone might need to learn more to know everything about Bitcoin. But if those who have known Bitcoin for a long time, and they still doubt Bitcoin. I thought it was a mistake.

[Doan9269]

There seem to be too much development taking place on bitcoin. Changes always being proposed. How are we ever going to be able to trust that bitcoin will never change if people are always trying to propose changes to it and get it implemented

what kinds of challenges are you referring to here, because i see nothing changing about bitcoin we all have known, it's never centralized, and if what you're talking about is on the Bitcoin Improvement Proposals (BIPs) then you might be getting it all wrong, because if you build a house, you will always want to decorate and beautify it from time to time, such as painting, cleaning and protecting it against Intruders with maximum security. etc. same is applicable here, if am right about what you meant.

#1: that kind of ruins the idea that bitcoin is going to be the same today as it was yesterday and tomorrow. today they might be proposing a change to some fee mechanism. tomorrow it might be changing the max supply.

bitcoin has a network protocols that work concisely with the blockchain technology and follows the consensus within the network of blockchain such that nothing is manipulated or will have any tendencies of such.

You can't just keep changing bitcoin trying to make it better and better forever. At some point, it needs to become immutable

the blockchain is immutable already, such that even the developer cannot alter anything from it, that's why every data is widely distributed across many computer systems connected to the network and same information is displayed all over, no one can manipulate,

[franky1]

the blockchain is immutable already, such that even the developer cannot alter anything from it, that's why every data is widely distributed across many computer systems connected to the network and same information is displayed all over, no one can manipulate,

no individual can just change the network(especially those outside of the core dev team). correct..
as those individuals just end up throwing themselves off the network or stalling out their nodes by just producing rejected blocks thus not building on new blocks from peers

however
because everyone relies on the core code. if core make a code change, that snowball effect rolls down to everyone meaning core can make changes (and they do)
it has got to a point that only core can decide what should be changed even if the community ask for something else. core have banished lots of people in the community that do not want to follow cores "roadmap".
there have been many manipulative tactics to ensure the core roadmap gets implemented even at the sacrifice of many users.

core have been careful at times to not completely break bitcoin when they add their changes EG not 100% pushing to disable legacy tx formats in favour of 100% segwit. thus allowing people a bit of freedom to remain able to use bitcoin without having to be forced into using segwit. but it only takes one bad decision by core that can ruin the network.

which is why we actually need to be aware of who does and can change the rules. and not treat them as gods that can do as they please, but instead call them out when they do certain things against the community. to atleast keep them from taking things a step too far
EG let the dogs walk in the park, but keep them on a leash..

we should not use emotion of TRUST that they will be honourable. we should use critical thinking and logic and actually be caring more about protecting the protocol, rather then defending the dev like idols

better yet, get back to the practice of decentralisation, rather than just distrubtion
where by multiple brands work at the same level. they have their own gateway for proposals and they share proposals with each other so all brans release a implementation candidate offering the same future feature. and where if the majority of users, no matter the brand choose the implementation of a certain feature. then it activates and all software brands are ready to validate the new change (instead of the current situation of follow the leader)

devs come and go and devs have their own motives. we should not just give them a free pass to do as they please with fake rhetoric that "bitcoin cannot change and no one can change it) you need to be aware that bitcoin is not AI, there are devs that write code and its those devs we have to be mindful of
bitcoin does not write itself

[CoinEraser]

-snip-
tomorrow it might be changing the max supply.
-snip-

Surely nobody would change that. That would be the end of bitcoin and I think everyone knows that. Therefore this limit will remain forever. Small changes are ok as long as the fundamentals are not changed. 

[Mr.right85]

I think OP raises a sensitive argument even though we believe some many changes could not be effected on the frame as opposed to what we've experienced before hand.

It's no doubt that, the cryptosphere is continually changing and with that, there are needs to adjustment of certain elements to ensure proper functioning of the cryptospace.

Most of the users or adopters of bitcoin  today never truly understands especially the truly newbies and a few others  like myself who is on the path of knowledge upgrade into the technical but, we rather viewed bitcoin to be rigid at all forms and isn't subject to any change or manipulation not being under any individual or groups control. Not like it is anyway buy the possibility of changes on its network if ever would result in people breaking faith.

[franky1]

if core devs ever stepped over the line by introducing changes that can affect the rules of:
the ~21m btc cap.
the (current) 625000000 units created as a blockreward
or
where they introduced a feature whereby , lets say it allowed a certain person to just move UTXO value out of someone elses control without the associated key.

we would truly hope that the community would just avoid using that version of the software and hope core dont find a way to activate the feature.
(eg by including it in every update/sub version they release for next few years where people end up having to download it rather then stay at an old version from years prior)

 or if it did activate, it would just cause rejected blocks where core fanatics find themselves on a altcoin that has only core fanatics on it and no meaningful merchants/exchanges treated that core alt as bitcoin

but instead of relying on the "trust", "hope" and human emotion of adoration, loyalty of honourable intent. we need to actually ensure it doesnt happen by protecting the protocol from certain rules not being allowed to be altered.

yes core dev teams make promises (human emotion) to never let in any code merges that can do such. but we should not use trust and idolism(human emotion) as a tool

[DooMAD]

People have previously moaned that Bitcoin isn't developed fast enough and now people are moaning that it is being developed too fast?  Just goes to show you can't please everyone.

I suppose it's good that people are curious and want to have a look "under the hood".  But try to keep in mind that. just because it may seem complicated to you on first impression, chances are there's probably a justifiable reason why it's like that.

*screeching crybaby noises*

just awful. maybe that's one reason why i heard someone call bitcoin spaghetti code. but i'm sure he had other reasons too. a beginning programmer doesn't even do silly things like that. unless they want to got fired. right?

now the problem is, when they go back, if they ever do go back and try and rectify this then they run the risk of introducing a bug or not making the change in all the places where /4 appeared not that it would cause a huge problem but later down the line it could. the more i hear about how bitcoin core is written with examples like this the more i don't ever want to look at it at all. i hope other people don't feels that way because bitcoin needs all the eyeballs on its code it can get.

*screeching crybaby noises*

i understand those issues you're talking about too. but what i cannot accept is if the bitcoin codebase is not well structured and professionally written. there are programming guidelines that lead to readable and maintainable code and i'm not sure how well bitcoin has abided by those things. that's a serious concern because well it just is. yes bitcoin just works but I think it's more of a miracle than we imagine.

https://dzone.com/articles/how-do-you-write-code-that-is-extensible-and-maint anyone can google search this kind of stuff and realize it is common sense and even more importantly, essential for larger projects.

we can't rewind the clock though on bitcoin core code. it is what it is. that's one of the problems that happens if you start out on the wrong foot it's hard to get back onto the right one.

It's worth pointing out that the person you're speaking to there is wholly incapable of objectivity or impartiality in their assessment on this matter.  They hold a petty grudge and, as such, most people don't find that user remotely credible on this subject.  There's also a perfectly justified reason why this code works the way it does, which was to avoid a hardfork.  It was actually considered a rather elegant solution by most in the community.