Topic: Magic numbers == trust someone (Read 812 times)

what devs need to do is have all variables changeable within the compiled GUI/command prompt.
EG not just the transaction fee defaults.. but other things too
USERS should have the options. like the blocklimit should be an option a user can change within the compiled release of all different implementations.

the problem is not that one dev team should be trusted more then another.. its that even if you only trust one dev team. the users should have some self control of what the rules should be.

EG not rely on electing a team based on a fixed pledge that once elected you dont have any ability to hold them to their pledge for a few years.. instead. the user gets to dictate the rules whereby the team have provided them the open platform to vote on each rule.

EG at the moment its more of a 'go for trump if you want separate minorities(witness)'. or go for Hillary if you dont want walls(no 1mb limit),
where each side is a overall pledge of many laws.

rather then an open system where each law is votable,
where all you are electing a team for is to have the best team that will follow the independent consensus decision best.
not electing which team who decides which consensus should be best or should be ignored.

I'm inclined to take issue with the both the subject title and one of your replies on reddit:


If we had a closed-source project then this would be accurate, but we don't.  It's an open system and any developer can add any "magic limits" they choose.  However, developers can only provide the code.  If users don't agree with those magic limits, they won't run that code.  The evolution of the network is decided by the code people freely choose to run.

Some people tend to compare competing codebases to a vote for governance, loosely akin to democracy (or dictatorship, depending on who you listen to   ).  But I've never been fond of this comparison.  It's far cleaner to see competing codebases as products fighting for market share.  Developers design their product however they like, with whatever magic numbers they like, in an attempt to provide the superior product.  The market then selects via consensus.  If there's a resulting gap in the market, where users aren't happy with the code, or the magic limits contained therein, it's only natural that competition in the market will provide some alternative code for users to run.  

That means the thread title can't be correct.  We're not trusting "someone", we're trusting the *market*.  If SegWit doesn't deliver on its potential, the market could well react to that and select a change to the codebase.  If there is ever an imbalance in the alignment of incentives, it certainly won't stay that way for long.  Embrace the chaos, as it were.  

Development centralisation is concerning to many.  Everyone seems to doubt the motives of everyone else.  People fear "takeovers" on both sides.  It's easy to get bogged down in all that negativity and it's easier still to start casting aspersions on those you see as a hazard to the well-being of the ecosystem.  But the whole thing gets a lot less scary when you remember that the code can't lie.  Neutral and transparent wins every time and that's what Bitcoin is.  Whatever you think about the developers, their intent or their proposals, trust the market to choose the best code available at the time.

anyone can change anything. the point is if the majority disagree, it gets ignored.

there is a very strong reason not to do this. so dont expect the cap to change. the majority have reasons not to do it.
its worse then shooting yourself in the foot and then your head if the majority were to do this.

although any rule can be changed certain rules are deemed golden rules that should never be changed and permission is given to slap anyone with a wet fish that wants to change the golden rules

Why would anyone do this, it would just be stupid

just to counter achow101

right now.
we could have 20 different implementations
a. baseblock 1mb max
b. baseblock 1mb weight 4mb max
c. baseblock 2mb max
d. baseblock 2mb weight 4mb max
e. baseblock 2.2mb max
f. baseblock 2.2mb weight 4mb max
g. baseblock 3mb max
h. baseblock 2.5mb weight 4mb max
i. baseblock 4mb max
j. baseblock 4mb weight 8mb max
k. baseblock 5mb max
l. baseblock 5mb weight 8mb max
m. baseblock 6mb max
n. baseblock 6mb weight 10mb max
o. baseblock 7mb max
p. baseblock 7mb weight 12mb max
q. baseblock 8mb max
r. baseblock 8mb weight 14mb max
s. baseblock 9mb max
t. baseblock 9mb weight 16mb max

and they can all run right now on bitcoin mainnet. fully accepting blocks because, guess what..
the rule is "anything below limit is acceptable"
the rule is not "block needs to be near limit to be acceptable"

that means a 250byte block is just as acceptable as a 990kb block to all them 20 implementations
miners will not risk making blocks at 2mb because there is a 10%(a)(b)(2 of 20 disagree) chance of getting orphaned so they will stay in the healthy area of under 1mb where the chances of orphaning wont happen. yet all 20 rules still allow those small blocks. and everyone is communicating to each other.

why avoid orphan risk you may ask.. well if it gets orphaned and the network settles for a competitors smaller block as the best new height to have.. the miner making the larger block loses the reward (no income essentially).
a flip side is that the 10% may not be objecting enough and the other 90% may stand their ground and keep the larger block meaning (a)(b) no longer sync to the latest block height. thus they either just become tx relay nodes or they change their setting to be able to sync blocks again

but as i said miners may not want to risk this even if it is just 10% of nodes getting affected

now if (a)(b) were to give in and move to 2mb.. this doesnt not mean the other 18 nodes have to change.
this is important.. so ill say it again
this doesnt not mean the other 18 nodes have to change.

it just means that now the threshold can move forward and miners see that 2mb is no longer going to get orphaned due to (a)(b) no longer protesting for small <1mb blocks.
so miners can now make any block between 250byte -1.99mb without orphan risk.
yes if miners tried to make blocks bigger than 2mb they would get some orphan risks from (a)(b)(c)(d) due to their opposition now set at 2mb.
with now a 20% risk...  miners will stay below 2mb to avoid such orphan risks.

why avoid orphan risk you may ask.. well if it gets orphaned and the network settles for a competitors smaller block as the best new height to have.. the miner making the larger block loses the reward (no income essentially).
also its a 20% risk so they definitely wont be stupid. at a 20% risk

but like i said.. it wont require all implementations to routinely ask devs to spoon feed them updated implementations. instead its a user setting.

as for how and when a miner decides/knows the risks.. well thats easy the rules can be transmitted as part of the handshake or even the useragent or rpc as part of the lets say an updated 'getaddr'

all without needing every implementation needing consent from devs every couple years. all done independently by nodes

the only risk i can see is the opposition will sybil attack the network by having several nodes setting it to 0.1mb limit. in which case there is always the ban IP which surprisingly i have seen core fanboys use, to not communicate with non core nodes for no other reason than not being a core node.

summary
nodes can have any rules they like. but miners will only produce a block that fits the majority and wont risk their income.
miners have a moral and economic incentive to not push the boundary, because the boundary may push back and lose them their reward.

Since the original release there have been multiple consensus rule changes, mostly via soft forks. There were certainly users when those rules changed. Those soft forks were "forced" onto the users.

What I am trying to say is that there are no incentives for miners to want to change the consensus rules. Any change that they make runs the risk of having their blocks orphaned and thus their effort wasted. There is absolutely no reason that miners would want to change the consensus rules without some pre-defined agreed upon rules so that they are sure that their blocks will not be orphaned when they enforce the changed rules. The point is is that consensus will not emerge unless something is proposed and everyone agrees.

How do you know? Take for example Bitcoin Unlimited. They have the option to set the block size to whatever they want. But, they have a failover state where once a chain with blocks larger than the setting reaches a certain length, the client will automatically accept the change. This forces the new consensus rules onto the user. If clients follow this example in order to help users not be forked off of the network, then miners can still force changes onto the users. They could, in theory, just constantly change the consensus rules and all other nodes will follow.

No group has the power to freely change the rules. None. With "emergent consensus", the miners can freely change the rules at will and all other nodes will follow.

Because no one has proposed a sane alternative deployment method.

They still have the ability to choose by choosing which versions to run. But yes, Bitcoin does not have emergent consensus and never has.

Miners can run other software that are not the ones produced by the devs. In fact, most do. Most miners are developers them selves and write (or at least modify) their own software to suit their own needs.

The block size limit being reached does not mean that consensus is broken. It is exactly following the consensus rules. Furthermore, the "original consensus" no longer exists. It has already been modified by both Satoshi and soft forks deployed previously.

---

One thing that emergent consensus does not consider is the introduction of new features. How does emergent consensus allow for the introduction of features that may be necessary (e.g. replace ECDSA with Quantum Safe algo)? It still requires top-down rule changing; one group of devs must create the code for said feature, and it must be deployed in a specific and safe way because coins can actually be at risk if deployment is done improperly. Changing constants is relatively safe compared to the rollout of a new feature.

No.
There weren't any users when Satoshi has made these choices, so it wasn't a choice over the will of anyone.

Users have chosen to agree with these rules, and then, they've started to use bitcoin (as I did).
The consensus was that miners were the servants guards of the rules, because of their incentive to do good.

Stop.
Did you read? I said corrupted.

You will never know which are the current incentives/goals of a dev. He can be working for the NSA or any other malicious group o just having a common conflict of interest (breaking the network and taking money from holders to repair it with other solutions)
If the team is corrupted, the cost to partecipate to the team is zero (other than being a good developer). Devs will only need to agree with the new goal, and he will also be paid!

Miners instead will never be able to play any hidden goals because of physics.


The first team was following the original consensus, that has been working good until the last year, when the limit has been reached.

You keep stating that, yet I see no elaboration as to why. Seems like the statement is going in circles ("Magic numbers alert consensus" -> "Consensus alerted because of magic numbers").

Untested? Segwit is a lot of things, but untested is not one of them.


Even if it's going to work one time, it is still a power of few, with unknown incentives. It is completely different from what has make bitcoin working until today.
Anyway, the answer to this your wrong assertion is already on the first post.

You are free to say that, but that is very well wrong.

Really? Isn't the fact that the vast majority of consensus was designed by Satoshi himself basically the deffinition of "choice of a few sorcerers over the will of every possible user"? The goal of consensus is to have everyone agree to use the same rules. Consensus cannot emerge. If all users have the ability to easily choose their own consensus rules, consensus will just be the status quo, otherwise people will be breaking consensus and thus their version of Bitcoin will be useless. There is no incentive or reason that people would try to change consensus, there is an incentive to not.

Now you may argue that forks are similar and people support those consensus changes. However, the big difference is that forks have deployment parameters. Without any form of deployment, there is an incentive to not change because any change will result in you forking off. With deployment, it means that everyone is actually agreeing and that it is safe to fork, you will not be wasting any effort.

The cost of becoming a contributor of Bitcoin Core is time. You need to have time to learn and write code. To have any major say in any consensus related code, you need to have several months, if not years, of contribution to Bitcoin. Your code will need to pass stringent peer review and testing.

The cost of joining blockstream is at least 4 years of college education, an interview process, and a demonstration of your technical ability.

Bitcoin has been working under the "power of few". The developers have, and developers will continue to, decide what makes Bitcoin work. First it was Satoshi, then Gavin and a few other people, now Wladimir and the many contributors to Bitcoin Core.

I am even free to say to everyone that this can become a big loss of their found and the utility of the network.

Bitcoin Consensus is not alerted by this number. It does not do anything wrong, does it? Just because you or a minor group of people disagree with the number (that is kind of arbitrary), that doesn't make it wrong.

That is *fine* I guess. You are free to not-run a Segwit client and not show support for it. However, if the majority of the system adopts Segwit then that is 'Bitcoin Consensus' (your words) on a new soft fork.

@Lauda

"Nakamoto is long gone"
This isn't relevant, I can call it the Bitcoin's consensus if you prefer. It wasn't a call for an authority.

Yes, and this is because I'm saying that making this kind of changes is a utterly bullshit, that will damage the future of Bitcoin.

It's going to move completely the power on the network from something that have the biggest incentive to make it working (miners) to a group that you will never know which are their true incentives/goals.

Wrong. You really have to be *not okay* to have a problem with this (either misinformed deeply or something like that). You keep using the words "Nakamoto consensus" which is nonsense. Nakamoto is long gone, and consensus should be based on the current participants of the system. This is really simple, as there are two options:
1) People disagree with these "magic numbers" (as you call them) -> they don't run Segwit -> Segwit soft fork fails.
2) People agree with these "magic numbers" -> Consensus has been reached -> Segwit soft fork activates.


You can run some pretty old versions so claims that it's an "altcoin", "hard fork" or whatever are just nonsense. It's backwards compatible. However, I would not recommend running outdated code (this includes BU as it's not even based on 0.13.0 yet IIRC).

I'm just going to keep my original Bitcoin-QT it seems to be working fine. 

These numbers are here from the start, are part of the consensus and they doesn't need to be changed every X time to adeguate to the market demand.

Anyway, I think that many of them can even become changeable freely from the user on his own client (even then 21M coins limit).

Some stupids will probably change it (and they will leave the main chain), mainly users that aren't really invested on bitcoin.

But most of all truly invested users (and miners) will never change the 21M limit, even if it costs only few clicks on the interface.

The Nakamoto's consensus system wasn't based on the continue choice of few sorcerers over the will of every possible users. As I wrote even the 1MB limit wasn't.

Currently you will never know which are the real incentives of those devs, and many are blindly following their decisions because "they are expert". Follow the authority!

I'm sure that even the Federal Reserve is "full of economy expert"! We should abandon Bitcoin and go back following their instructions.  

Which is the cost to become a dev of a possible corrupted Bitcoin Core / Blockstream team? Nearly zero.
Which is instead the cost to become a miner? Always milions and much more.

You have to be really blind to not seeing the problem here.

The Nakamoto's consensus is based on this, that miners are mostly not corruptible, because of their opportunity cost.

Bitcoin is full of these "magic numbers" (arbitrarily chosen numbers). Here is a brief list:

• 10 minute block time
• 50 Bitcoin block reward
• Block reward halving every 210000 blocks
• Retarget period every 2016 blocks
• The lowest difficulty of one
• Sigop limit
• Transaction size limit
• P2P message size limit

And probably a ton more that I can't think of off the top of my head. Some of these numbers are in fact not chosen by Satoshi but by other developers.

Are you suggesting that we should get rid of all of these arbitrarily chosen numbers in order to be "trustless"?

The 75% discount of Segwit IS a magic number.

Even the 1MB block size limit was a magic number, but it wasn't chosen to limit the market, it was temporary chosen by Satoshi because he was afraid of the huge difference of mining power from the new GPU/FPGA miners and the CPU miners of the time. He was afraid of an attack from a malicius miner with a huge mining power. (we were still at the beginning of the project)

He said that it was temporary, and that could be removed just 6 months after! (block 115000 - October 04, 2010)

The market didn't reach the limit until the last year. It was like a not existing limit.

It wasn't a part of the consensus rules.

Having a network that require every time someone that will choose some magic numbers ... require trust!

It will not anymore a project which aim to become a trustless network.

If you are a company that is working/thinking about developing on the Bitcoin network, then you will give trust on those magic numbers, and the people that are going to choose them.

Are you going to buy bitcoins? So you are going to invest on those magic numbers, on the future choices of the people that have the power to do it.

It will be not anymore a real-time-market-choice.

Don't you see something that you already know?

There are many projects, constitutions, foundations, associations, that have started with the greatest people on the world ... "at the time".  But the people are cycling, people change,  incentives change!

Miners are deeply invested on the network for the longest time, they can't just pivot away easily. But what about a bunch of devs!?

Why have you got interest on the Bitcoin project?


https://np.reddit.com/r/btc/comments/5c3m2r/magic_numbers_trust_someone/
https://np.reddit.com/r/Bitcoin/comments/5c3pmb/magic_numbers_trust_someone/