Topic: Resisting the "Completely Open Source" Attack or: Swarm Social Dynamics (Read 1377 times)

Exactly. But somehow it looks like it is much easier for the "first" open source project in a specific area to reach consensus than for later branches. Which, I think, is sad, since chances are high that you will not get the architecture right upon first attempt...and then you are in for fighting for consensus.

Maybe http://en.wikipedia.org/wiki/Asch_conformity_experiments also plays a role here, as well.

That is exactly my problem: There is no such (centralized) thing as "community", just a number of other nodes whose "average" behavior I might call "community". This can be nicely described by game theory. However, even very simple games may exhibit chaotic behavior when some participants are acting irrational and other participants adapt their behavior to maximize profit. I do not yet see the proper formal modeling for this "inertia" described in the thread.

I agree: Human behavior or rather human non-behavior and inertia, human tendency not to deviate from a once chosen behavior - might be the driving factor here.

Remains the question: How do you model or describe this mathematically?

I tried to model a network of Bitcoin nodes by game theoretic methods: Every node is an agent with possible choices of behavior, trying to maximize its own profit. The tricky thing is: You do not get a stable pay-off matrix (as is the usual case in game theory), since profit depends on the (future) behavior of the other nodes (whether they accept certain brands of coins or not and how the coin values translates into "real" values, such as a "gold" or "bread" standard). These attempts seem to fail miserably since the entire model becomes way too complex, too stochastic, too complicated. And: It looks like this model would allow for some wilde fluctuations in block chain parameters (as described in my OP).

What is the proper model to grasp this form of human inertia?   

The entire premise of bitcoin is that to participate in the system, you agree to its rules. Those are not enforced by the software - you can change it - but by the community.

If the software would be easier to modify, nothing would change. Maybe a few more alternative blockchains would appear, but those who are willing to start such an experiment can already do so today.

Go, do your own version of client and bitcoin. Call it ForpCoin
No one will use it. You will be alone in using it. What then?

You won't get a majority for some arbitrary change like that. But majority isn't the standard required for that type of change. You need the people with the stuff you want (dollars, services, goods) to want your wacky coin.

There's a concept which explains why bitcoin, and any other open source project, is what it is and not anything else, and why they will evolve on relatively stable paths over time: consensus.

You can make anything with any of them, but for your changes to achieve some success, you have to reach some consensus, and this isn't an easy task. It makes them something interesting to analyze under the light of some fields of the social sciences.

And for the sudden changes which could bring benefits for those which make them, we have an alt chain which is hardly trying of enforce something like that (and this is one of the values of alt chains, being like guinea pigs which show us what could happens under several circumstances). SolidCoin 2 tried to benefit greatly from a sudden, centrally enforced cut on the supply. And it just didn't worked as expected...

The problem with this idea is that original clients, or just those who do not want it to change, will not accept invalid blocks like these. This can become a problem quickly when MtGox for example decides resolutely to stay on the 50BTC (or 25.. etc.) chain. If something like this were to happen, it needs to be a possibility from the start. And it kind of has to be that way because miners can't be allowed to control things like this as they will always do what is in their best interest, not the best interest of the currency.

go code your own client.

i will not use yours.

Suppose for a moment that Bitcoin software would be " 'completely' open source". Would it survive?  

Currently Bitcoin is "theoretically open source", which means that - in principle - everybody is able to modify the client, to setup an alternative chain with a different block chain speed, with a larger or smaller bounty, with different behavior regarding fees, with different script mechanisms and so on and so on. However, setting up an alternative chain in practice is a completely different thing. It requires quite some programming skills to be able to read the Satoshi client or the few other implementations such as libbitcoin; it requires GUI programming skills; it requires a working tool chain environment for compilation; it requires version control skills, regression testing skills, time to deal with your growing user base - and, as a result, it is not so easy. And, even if you succeed, you would still have to convince the big mining pools to adopt the changes, because otherwise your changes will never be reflected in the block chain.  

Now, assume the situation would be different. For example, imagine software, in which a large number of parameters could be changed very easily, at the click of a mouse button. For example, all the essential parameters of the algorithm could be set by a script kiddie or by grandma in an "Options..." dialogue. Let us look at a concrete example: You would, as part of your wallet software as well as part of your mining software, have an option tab, where it says "mining bounty per block". You may decide on your own (1) which blocks you would be willing to accept as correct blocks (when your wallet software checks the block chain for correctness) and (2) which blocks you would hand out to fellow mining pool members, in case you operate a pool, and (3) which shares you would be mining on, in case you participate in a pool.

Alternatively, we could assume a perfectly computer-literate world, we teach C++ and assembler in kindergarden and if you wanted to have you own version of the wallet / mining software you would just write that up between breakfast and lunch.  

I am completely aware that this would probably not work in the current protocol structure and would, no doubt, generate quite some chaos, because block compatibility would be broken. Nodes which changed the parameters in a stupid way would lose all their coins and much more nasty stuff. Still, please stay with me for a moment for the following thought experiment.

One day my electricity bill goes up - and I feel tempted to change the bounty parameter from 50 to 60 BTC: I would accept every block as valid, if the coin base was 50 BTC (to maintain compatibility) but I would also accept blocks with a bounty up to 60 BTC. I would have a small number of my GPUs do mining on 60 BTC bounty blocks and I would publish this change on the web page of the pool I operate. (Remember, we assume that all this does not take a lot of programming, web page redesign, pool software redesign...it is just an experiment I can start with two clicks in my options dialogue). Interesting enough, since I am a medium sized pool and my mining community lives in the same region with increased electricity bill, my fellow users adopt this move. We are even lucky and win two or three blocks in a row with this new strategy. Now, other mining pools watch this with some attention: Since my fellow miners just split a 60 BTC block in my pool, some miners leave their pools and join my 60 BTC pool. After a while some pools move on and adopt my 60 BTC policy. More and more users, miners and pool participants adopt the change: It is easy to set up (just a click with the mouse) and it can be undone quickly, if it proves a bad idea. After 4, 5, 6, days a majority has moved to a 60 BTC chain (of course, back compatible to the original 50 BTC chain).

NOW someone comes up with this idea of setting this parameter to 200 BTC. At first, many are sceptical. But as soon as a pool wins the first two or three 200 BTC blocks in a row...again some miners change their mind. After some 4, 5, 6 days...

OK. By now you have got the idea. (And, again, the disclaimer: It is not a request for changing the algorithm but a request for comment !)

NOW my issue: I would like to understand if there is a mechanism which would prevent such a "drift" in the parameters of the algorithm. Right now the though experiment is absurd, because it takes many days of hard work to get a different algorithm running, and even much more work to convince even a small number of miners or fellow poolers to spend their electricity bill on the different algorithm. BUT WHAT IF? Is there any additional mechanism which would prevent such a drift from happening - beyond human laziness of programming and testing the different algorithm and beyond that human inertia and resistance against innovation("I have mined using the original Satoshi parameters for 2 years and I will mine using these parameters until I die").

With regard to the amount of the bounty, there might be an obvious mechanism: Inflation. As soon as we change the bounty from 50 BTC to 500 BTC, the real-world value measured in dollars or working-hours should drop to 1/10.

So, maybe a different move might be more interesting. A few miners might decide to drop the bounty from 50 BTC to 1 BTC. Why should they? Well, that's easy. IF they do so and succeed to convince a sufficient number of fellow BTC millionaires, Bitcoin would enter a fast deflationary development, which is beneficial to all those, who already own many BTCs. All of a sudden the value of their BTCs rises and rises - all they have to do is organize a sufficient number of fellow miners who follow their modification, a bit of luck to win some blocks and catch the attention of more miners.

But what about the other parameters? For example, block chain speed (we would double the chain speed and half the bounty, so that there would be no bounty effect). Or, somebody might suggest using SHA512 instead of SHA256 as hash.

My incentive for this thread is not a modification of the algorithm but an understanding of it's social mechanism. The Bitcoin nodes form a swarm of networked individuals. Currently, they all use the Satoshi client, simply because it is there and working and everybody does so. If a small number of nodes in the swarm follows a different course and benefits from this change - others might join in. If the number of others, which join in, is too small, this development will die down again. If the number of others is large enough for a short period of time, the development might grow and prevail in the long run. The swarm will soon fly into a different direction.