Topic: How new code changes are made to the Bitcoin protocol (Read 250 times)

the 'voting' is much of the powers of merchants. devs. pools

bitcoin code is not some self enabling AI. its wrote by devs and implemented based on economic nodes desire

devs dont really listen to random users varying opinions on change as well just said varying opinions on change..

also users dont have much control. if a small users wants to reject something. it affects only their data. and because they are not in much receipt of lots of users funds, individual decisions dont impact others spending.
thus it doesnt matter if a individual is out of sync. no one sent funds to them or received frunds from then to be any debate.

merchants/exchanges however have the loudest voices.
much more then pools do
if merchants say they want to only accept transactions of a particular tx format. users end up having to upgrade to match else the users wont get their transactions seen by exchanges. meaning cant spend

if pools blocks contain unwanted transactions merchants reject the blocks and so pools adapt else never able to spend their block rewards

users generally have no power. they are followers of merchants and nodes.
pools have limited power but risk having their rewards rejected

so most of the power is in the relationship between merchants and devs agreeing a feature is needed and coding it. then coercing the rest of the network to follow

..
if users/pools. continued accepting normal blocks and merchants only accepted new blocks.
a split and 2 varying chans are created.

the merchants then decide if the want to use the new feature chan or the old chain that split off..
and everyone follows which ever chain merchants call bitcoin at the exchanges

I tried it and it works. Obviously i didn't mine any block, but one thing i notice it only use 1 core/thread. So while theoretically it's possible to mine Bitcoin on mainnet on Bitcoin core, it's not practical because
1. ASIC not supported, only CPU is supported which only use 1 core/thread.
2. Only solo mining is available.
3. There's no option to modify coinbase transaction or select transaction you wish to include on block.

Even for testnet it's hardly practical since hashrate still growing over time, unless you only wish to mine when there's no block mined in last 20 minutes (which reduce difficulty to 1).

Yes, it still can, even in the newest Bitcoin Core. You can still run some node offline, don't synchronize it, and mine some blocks after the Genesis Block to see how it works.

To be honest I haven't checked it myself but I'm referring to this reply from Pieter Wuille saying generatetoaddress can still work for mining mainnet blocks. https://bitcoin.stackexchange.com/questions/106537/is-it-possible-not-feasible-to-mine-bitcoins-with-bitcoin-core-v0-21-1

Bitcoin uses consensus to determine which rules to follow, which also tells nodes which chain to follow, what transactions and blocks to accept. As long as your node is following consensus rules, and has the ability to communicate with other nodes that follow the same consensus rules, it will be on the same blockchain as the rest of the network. 

Generatetoaddress does not work on mainnet or testnet at all, not just useless.

The mining component has been deprecated for quite a while now.

Corrected below. I might've remembered wrongly but I thought they completely removed the mining logic related to mainnet and testnet in 0.13.0. Anyways, the max tries has to be changed to get any hash with a decent difficulty.

The generatetoaddress RPC call is still there but it's completely useless on mainnet or testnet since it's hashrate is very tiny, you can only really use it on regtest which has a very small difficulty.

The idea of Bitcoin is to verify the ledger you keep which is made up from others' work, who made their own decisions, but they each make the same decisions as one another. In the example above, the nodes run make different decisions which means that there's no consensus.

The C node would consider the overflow incident block valid, while the other two wouldn't. It'd require a hard fork to finalize what they'll agree upon.

What? My generatetoaddress works fine.

Doesn't that mean potentially all nodes on the network have their own chains (in the simplified example A and B have different chains to C)? I thought the idea of Bitcoin is every node shares the same ledger of transactions?

This is tricky to answer because it doesn't clarify why node C rejected that block and more importantly was the rejected block valid or not?

For example if we had a node of type C back in 2010 (the overflow case I posted above) that would have meant detection of the chain split right away by anyone running both client types (such as a miner) and they could have potentially avoided building on top of the invalid chain in first place. More importantly someone could build a valid chain while nodes A and B continued building on an invalid chain.

And @ranochigo covered the rest.

It does have mining capabilities, in fact it makes no sense for a "full" node to not have such a feature. Also without it testnet and regtest would not be possible.

Nodes A and B continues on the chain that includes that block.

Node C does not accept that block and treats it as invalid. It is thus -1 block Nodes A and B. Node C will not continue until a new block that is compliant with their rule continues on that height in their chain. Even if subsequent blocks built ontop of the rejected block were somehow compliant with the rules of node A, B and C, only Nodes A and B will accept that block for obvious reasons, a continuation of the block that is deemed invalid by C.

A more relevant example would be to think of realistic hard forks. In a hypothetical scenario that we were to increase the raw block size to 8MB today, assuming nodes A and B upgrades and are aware of the new rules. If an 8MB block were to be mined, nodes A and B accepts it because they know that 8MB blocks are valid while node C doesn't. Node A and B expects an additional block that references that 8MB block while node C awaits for a block at that height which isn't more than 8MB.

Say for example, the network only has 3 nodes (A, B and C).

A and B are running reference client and C is running some other client.

If the next block comes in and the rules based on the reference client accepts the block (A and B accept), but the other client rejects the block (C rejects), then what happens to the block? And what happens to nodes A, B and C? 

1.As far as I know, if the Bitcoin protocol is changed through the code, a fork will be formed. It is a very complicated project from idea proposal, to community discussion, to code design, to publicity and promotion, to deployment by miners and users. Very difficult.

2.Bitcoin's code is open source, and GITHUP will be released. High-level programmers saw this bitcoin code repository, copied it to form a branch, added the features they wanted to the branch, and submitted an application to the main code manager (Pull request). The programmer applied to merge his modified part into the main code repository. If it passes, he will merge this part of the code into the main code base (merge)

3.Finally, after everyone’s discussion and unanimous approval, everyone can install a version of the Bitcoin software or install a compatible version. Then the Bitcoin fork is successfully completed, and the Bitcoin network will be upgraded to the new version.


This is my simple understanding of the Bitcoin protocol change. I don't know if it is accurate. Because I am not a technical talent, I can only describe it to you in simple words. I hope it will be helpful to you. I know that every fork is a heated debate. Bitcoin itself is a great experiment.

Nodes are supposed to be enforcing Bitcoin rules not their own rules and their usefulness is about their contribution to the bitcoin network.

Somewhat yes.

Additional/different features.
Security.
Flexibility.
For fun!

No and no.
Most miners run a modified version of the reference implementation to satisfy their needs. And I strongly believe some of them run multiple software to avoid running into issues such as these [1] [2], that's the "security" reason I mentioned above.
As for the reward, miner will get the reward if their block is valid, it doesn't matter how they mined it.

If someone doesn't run the reference client, doesn't that make their node is useless to the network since it won't be accepted? Is running the node kind of like a voting mechanism? Just trying to understand why someone would run another client.

But miners would all run the reference client right? Otherwise they wouldn't be able to get any rewards?

Each node in the network runs their own specific set of rules. If someone runs a node that doesn't follow those set of rules, the other nodes would consider those transactions/blocks,etc violating their set of rules and will not. Majority of the network runs the reference client (Bitcoin Core), for which the rules are defined in the client.
Most high level changes involves quite a bit of discussion either on the IRC or the mailing list. The procedure is outlined in the link below.

https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md
Neither. Each node runs their own set of rules. If a new protocol code change that affects compatibility with older clients is implemented, then the older clients wouldn't recognize the new rules and simply wouldn't follow them, ie. a hard fork.

My high-level understanding is that if one person decides to make a malicious change to the Bitcoin software code, then others in the network will reject it.

1) How exactly does this process work? How do I submit or propose a code change?
2) And does every node need to agree with the code change for it to pass or just the majority?