Not so sure. People are greedy. I think the attack would work (although I guess we will not see such an attack in the near future).

For example: Upload a modified Bitcoin client which accepts a bounty of 500000 BTC per block starting from a specific block. Rent Amazon and Google hashing power and produce some 20 blocks faster than the Bitcoin community does. During this time, produce 500000 BTC per fresh block and pay a large number of bitcoin addresses some extra Bitcoins (as a kind of bribery...). Then reduce the bounty again to 100 BTC per block (or, different approach, 50 BTC) and distribute the information on what you just have done to many forums.

Now there is this interesting dilemma: If a user/miner adopts your software and the new block chain...he gets a share of the extra coins. If he does not...he will not get a share of the extra coins. Of course you will also get a big share of extra coins. I am not so sure how many users will stick with the old block chain and not be tempted by the extra share they might get ... if they switch. (Of course, getting the modified software to accept the modified blocks is not a trivial engineering task - but it can be done).

Agree completely.

Assume, Amazon or Google would want to disrupt the Bitcoin network...if they joined forces in their cloud and produced some 10 or 20 new blocks Bitcoin could be severely damaged within a few hours...depending on the transactions they would place into the block, of course. 

I made similar observations and suggest an explanation. Most people here have already decided that Bitcoin is their hobby or investment - wouldn't you be afraid to see your hobby fall apart and much more your investment?

In https://bitcointalk.org/index.php?topic=78374.0 I have been pursuing similar thoughts, though not with the intent of attacking the block chain or modifying the protocol. The discussion there might be of interest for you as well, since I am presenting some possible, though highly unrealistic attacks, which could lead to similar effects than those you are studying here.

Ist geplant.

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?   

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.

Thanx wabber, for the additional contribution.


Sigh.  I did not make a proposal.    I had disclaimers in my OP in three places and stated that I want to understand a part of the concept.

Of course I appreciate your time and I am grateful that you read my questions and care to answer. But before suggesting that my proposal is useless and should be dropped - you could at least read as far as to realize that I did not make one. 

It is Open Source software. So move ahead and contribute a client of your own. That is the solution. :-)

Similar question: Why would a miner include a transaction without fees? As far as I know we have no answer to that one as well. Still the algorithm works.


Do we have a formal, mathematical proof for that? Do we have comprehensive, published experimental test results which show this? If yes, I would like to learn where to find them. Please point out some sources or references so that I can study them.

You throw away work of miners. And electricity.

So the question is: Is there a useful purpose for orphaned blocks?

I realize, in the current form of the algorithm, there is none.

Some time ago we had a discussion in the forum along the lines: Couldn't we include orphan blocks, the transactions of which are compatible with the true block chain also into the block chain. Then some miners could work on one group of transactions, other miners work on other groups of transactions and later we combine two block into one "super block". The idea was that this could improve bandwidth scalability. The idea was not really settled in that thread.

http://bitcoin.uni-rostock.de/

Da das das vermutlich erste akademische Workshop zu Bitcoin sein wird...sind wir da flexibel.  Wir kennen die Resonanz nicht.

Das Optimum wäre: Wissenschaftliches Paper (bis 15 Seiten) und Vortrag. Wenn es ein kurzer Diskussionsbeitrag mit 3 Powerpoint Slides ist - passt das auch. Es kommen alle Einreichungen (siehe Link) ins reviewing und wir nehmen dann die besten. Wenn wir also 300 Einreichungen bekommen, dann werden davon 10 genommen, mehr Zeit haben wir nicht. Die müssen dann TOP sein. Wenn wir 3 Einreichungen bekommen, werden wir die alle nehmen für den Vortrag (publiziert im Tagungsband werden natürlich nur die, die inhaltlich eine gewisse Mindestquälität [sic] haben. Im Vordergrund steht, dass wir uns über Bitcoin austauschen, ein sinnvoller Rahmen muss natürlich gewahrt sein.


Auch das hängt von der Resonanz ab.

Generell aber sind gute state of the art Berichte, Experimente, Vorschläge usw. auch sinnvoll.

Würde mich freuen, wenn Du mitmachst !

And there are quite a number of interesting implementations of this idea.

One of the concepts is SecreC (secret C). There is more on this here: http://sharemind.cyber.ee/research

Another group is in Denmark: http://viff.dk/ or the Sepia guys in Zurich http://www.sepia.ee.ethz.ch/

Actually, this is a fascinating research area 

No. Complete misunderstanding between us 

I asked for reasons against the idea - but I never intended to implement this. Remember the disclaimer at the beginning of my post? I really meant that disclaimer. 

My approach is the following: Whenever a program has to solve a certain task, you will end up with a specific implementation. Some of it's properties will be must-have properties (For example: Bitcoin would not work without some form of randomization. There is a proof on the complexity of deterministic consensus algorithms, which applies here, and which tell us that Bitcoin would not work without a random or pseudo random element in it.) There are other properties, which are nice-to-have or plainly coincidental. Currently I am trying to understand, which parts of Bitcoin are must-have and which parts of the algorithm could be different. If I have answers on this I can come up with different algorithmic schemes. That's the way I do research (which is the way I earn my living) I am into thinking, not into minting - and hopefully this may prove useful after all  Well, I get more pleasure from "ThinkCoins" than from Bitcoins, I guess 

About this orphan block thing. I realize that we need some incentive for miners to work on the most current block. The variant I suggested could enable malicious miners to obtain bounties by only producing orphaned blocks, which is not what we want. Therefore my original concept must be modified a bit - as I wrote in my post - by placing bounds on difficulty or depth. Currently we are seeing miners minting blocks without any transactions all - which could mean that the current implementation has a small incentive-loophole, given the conditions under which these miners (bot-nets ?) operate. The interesting question thus is: WHAT are the minimal conditions we must require for the bounty to work properly?


That is a great way to put it and this comment helps me a lot. We actually can model this part of the algorithm as difficulty (probably not lower but higher, if we take expected payout as constant in our model).

So, let us assume we have a percentage p of orphaned blocks. Now, let's assume we increase block chain speed. This has been discussed in the forum (and it would increase the number of orphaned blocks). According to your idea it would mean different difficulty. So a next question is, whether there are still other aspects in addition to different difficulty...

Could we still couple the limitation mechanism to the number of BTC minted thus far?

Great news, looking forward to the patch. Thanx for the support.

I am writing up a formal specification for the block chain algorithm and came across a question I was not able to settle on my own. (Disclaimer: I am not trying to make yet-another-suggestion for modifying Bitcoin nor am I proposing yet-another alternate chain. Just trying to understand).

When a block becomes orphaned - the bounty for the miners is lost, since the transaction does not make it into the "true" block chain. Life is risky and that is one of the risks of a miner. That said, it would be quite easy to change this: If someone presented this orphaned block (with correct difficulty, target matched properly etc.) to a mining node, this node could accept the coinbase transaction of the orphaned block and include it into the block it currently is working on. If this block wins, there would be 100 BTC created. Of course, there would be some checks (for example, correct difficulty, time stamp not too old, depth not too old - we want to prevent very old orphans from being use for that purpose).

I do not want to suggest that as a modification, but I would like to understand if there is any strong (technical, security, economic etc.) reason against this. (I might have missed the obvious).   

One issue I see is: It would reduce incentive for miners to immediately switch to a new block, if one is found, since they could make money with old blocks. To prevent that could be easy: Pay only half the bounty for orphaned blocks; accept only blocks with with a very small depth difference.

So far as I see, it would not break correctness/security of the algorithm, just mess with miner incentives.

Thanx for listening.

Did you every find a solution to this issue? I have the same problem...

Bump.

Deadline is approaching.