Topic: Bitcoin & Tragedy of the Commons - page 7. (Read 21878 times)

I thought the 80% / 20% proposal was in this thread or the other, certainly I read it in this span of being awake. But I cannot find it.

Thanks for the link, I will go check that out.

Things I saw while looking for the 80% / 20% thing though made me realise there probably are a bunch of complications that will pop up in actually trying to code though. Not in the code itself initially but in all kinds of sneaky problems that need to be thought out.

One thing I liked about the proposal though was it scaled so that pooling together basically ended up increasing the stake you'd need, so you might as well solo mine with a tiny stake or maybe even no stak in coin form (hashes count) instead of ganging up with others to pile up a stake between the lot of you. It seemed that might actually even potentially be able to be tuned to address the LiTeCoin people's concern that the little guy keeps losing the ability to make a few pennies at home over and above electricity costs.

-MarkM-

Can you link to the 0.8 & 0.2 proposal? My current design is described here, I think it's not complicated at all.

No problem, it is CRCoin not RCCoin I am thinking of first off anyway, since the 0.8 & 0.2 proposal seems concrete enough and simple enough, gosh knows how complicated whatever you want to "collect signatures" for will turn out to be. I was thinking of going really simple, the address the reward is to go to either contains enough stake or it doesn't, no licensed miner / licensed mining, just put the reward where the stake is if there is enough stake already there or invalidate the block.  Maybe make sure at least stake plus reward is still there 120 blocks later or don't mature the reward.

-MarkM-

I assumed the participating pools would reject conflicting blocks, because if not, the weakness is even clearer. Joe makes a double-spend, one to Walmart and one to himself. Walmart pays 51% of the pools to commit to the transaction to Walmart. Meanwhile Joes pays the other 49% (or 20%, or whatever) to commit to the send-back. Walmart thinks the transaction is safe and gives the product to Joe, when in fact there's a 49% chance that the next block found will have the payment to Joe, and Walmart will lose the money.


I am a critic of the majority of existing alt coins. Alts have their place but they really need to be thought out and have a reason to exist, I'm not eager to rush an alt of my own.

There's still some work to be done with the design. The design I currently have should work against double-spending, but not necessarily against denial of service.

I can work on the design from a high-level perspective, but I don't think I'll be able to lead the development and promotion efforts in the near future. Someone would have to volunteer for that (and to create a new thread for further discussion).

Possibly, but that's not strictly necessary, test attacks should work well for testing resilience.

Actually there has already been a rush to implement pretty much "anything", ha ha.

I want to push merged mining further, it seems to me I could mine at least a few more chains than I am currently mining, so given a choice between this or just a bunch of boring old identical clones this concept might be worth trying.

We have a bunch of pennystock-like chains already, lets see if a penny-CRCoin can beat out the other penny-chains.

If it can emerge a clear leader "in its class" then that should lend at least a couple of pennyweights to the theory, yes?

I don't expect you to write code, I don't expect Cunicula to write code. It was a very very pleasant surprise to me that Unthinkingbit does write code, in fact a whole lot more of DeVCoin's code than I wrote. (Heh "than I hacked a little" is more like it, I didn't really "write" anything, I just hacked away some at what was already written, enough to get it to at least look like it runs.)

So don't worry about coding. We can bribe codemonkeys with DeVCoins, or just make up the code, it doesn't sound real hard. And it sounds like an interesting idea.

-MarkM-

P.S. Hey maybe we should also accelerate the decay of the block-rewards in it so we can get to the juicy bits sooner?

I can certainly imagine a scenario where Bitcoin fails due to this problem, and an alt proof-of-stake coin will be there to pick up the pieces. But I fear that people will attribute the failure to the concept of cryptocurrency itself, rather than to solvable problems that were foreseen in advance.

I don't expect an alt to rise to prominence before Bitcoin failing, so by the time people will be convinced to make the change, it will arguably be too late.

Which is why I hope people will give more weight to theoretical considerations. Empirical testing is great but it's not always feasible.

This needn't be an immediate all-or-nothing change. You could start by collecting people's signatures and ignoring them. Then you could try reasoning what would happen if we used these signatures in branch selection.

I'm not going to be writing code to implement this anytime soon, if that's what you mean. But I'm putting a lot of personal resources into Bitcoin on the hope that its challenges will eventually be overcome, so it's not "purely theoretical" to me.

Anyway, this problem probably won't manifest for a long time. Discussion of the problem and solutions should be out there, but as long as uncertainty of the future prospects isn't holding back adoption, there's no rush to implement anything.

Ha ha, good luck with that without proof of concept.

So, back to proof of concept... I do not want to detract from bitcoin with altchains, so we can maybe make sure it is clear from the outset that if it takes off too darn well Bitcoin itself is free to set some block number at which it adopts a similar system.

But to drive Bitcoin to do so, we really should demonstrate that failing to do so could indeed prove a competitive threat to Bitcoin's value rather than being a harmless companion-coin or hanger-on or, indeed, merely yet another of the many currencies used by various civilisations of the Galactic Milieu.

I am losing track, are you both in favour of making such a change to Bitcoin on purely theoretical grounds, or is at least one of you at least a little more empirically oriented than that?

-MarkM-

Thanks, but I'd much rather see this change implemented while keeping the Bitcoin name and the current blockchain.

PS. AFAIK, the first mention of using proof-of-stake in Bitcoin was by QuantumMechanic, in this appropriately named post.

Thanks! So then maybe we call it CMRcoin or MRCcoin? (Cunicula/Meni Rosenfeld or vice versa; I know normally it'd be just one initial for each of you but I have this bias for three-letter currency-symbols...)

-MarkM-

EDIT: Oh wait, duh, CRCoin or RCCoin (Cunicula-Rosenfeld Coin or Rosenfeld-Cunicula Coin).

The protocol doesn't say that if there are two conflicting transactions (whether a fraudulent double-spend attempt or something else) you have to reject both and reject any block that contains either. It says you go with the one you encountered first, unless a block is found that contains the other and then you go with that. In your scenario (especially if there is a dedicated denial-of-service attack), every block will be rejected by every miner because it contains some transaction the miner committed to reject.

In December the block reward will be 25 BTC. The problem is when block reward is close to 0. We're no going to have any empirical evidence for a long time.

I'm not saying the problem isn't solvable; I'm saying it's silly to think of it as "not a problem" when it was never tested, and when the proposed ideas of how the ecosystem will work depart completely from how Bitcoin works now and from its design principles.


Yes, people will contribute more than what the immediate incentives can account for, due to altruism, fear of a snowball effect, superrationality, etc. But they will only do so by a small amount, not enough to sustain the expenditure that will be required. If you really want to be future-proof, you need to align the immediate incentives properly.


A big unless. You'd want to attack the network either for profiting from double-spending, or for harming Bitcoin (political agenda, destroying competition, short-selling bitcoins). There's a tradeoff, some things you can do to protect against the former makes you more vulnerable to the latter.


They are (arguably) too high now for the current value of Bitcoin. As the impact of Bitcoin rises, so will the incentives to attack it. Since the attack incentive is more or less proportional to the purchase power of a bitcoin, it is safe to assume that the BTC reward per block is the invariant security factor. 50 BTC is high, but 1 BTC - which may very well be the future equlibrium - is not.

This will certainly help. Decoupling compensation from individual transactions is a positive direction. But I think the fundamental problem remains. Someone would want to pledge his own funds only if he thinks there's a good chance he will tip the scale to passing the threshold. Which means the network will always walk on the edge in which there's a chance for everything to crumble.


Game theory isn't a model of what people do. It's a model of what people should do. Even if 99% of people do "better" than what game theory prescribes, there can still be 1% who are selfish and rational and exploit the system. Having a system that is secure in theory can go a long way to preventing unpleasant surprises in practice.

By the way, "failures of game theory predictions" are commonly not problems with the theory, but with the game that was chosen to model the specific real-world situation.


I am still of the opinion that all the ideas proposed could account for some level of hashing, but not enough for proof-of-work to completely secure the network. Which is why proof-of-stake will need to augment it to pick up the slack.

Hmm I guess SolidCoin's take-away from your proposals was proof of stake.

Somehow I don't think he quite got it right, though.

This 0.8 / 0.2 you propose doesn't sound particularly difficult to code, but if yet another altcoin is to be launched to implement the concept the coin or chain should have a name...

-MarkM- (I hesitate to suggest CUNcoin, though maybe it is kind of an easy one to arrive at...)

I prefer to call an attack a takeover. Attack suggests a hostile intent towards the technology. I expect that when someone or some group takes over that they will do their best to foster broad use of bitcoin. In fact, if anything I expect the technology to benefit from a takeover. They will only want to 'attack' competing miners.


1) A takeover will be profitable. A monopolist will be able to increase his bitcoin earnings per unit of mining expenditure by several-fold. This is motivation enough.

2a) I'm concerned that an irrational fear of monopoly could lead to a destructive panic in the event of takeover. I would prefer a smooth transition because I like bitcoin and want it to succeed. People need to get prepared to accept the coming monopoly. Right now everyone is prepped to respond like Chicken-little.
 
2b) I would like to promote a mixed proof-of-stake and proof-of-work system. The system will lead to lower equilibrium txn fees and make cryptocurrency technology more competitive with other payment platforms. Lower fees with proof-of-stake occur under both monopoly and competition.

2bi) The case for proof-of-stake becomes stronger if you believe that a takeover is likely to occur.

2bia)If you fear takeover, then proof-of-stake makes takeover much more difficult (perhaps an order of magnitude).

2bib) If you are willing to accept takeover, then you will likely feel more comfortable with proof-of-stake. The monopolist will have even stronger incentives to behave benevolently if he is required to hold a near majority of the bitcoin money supply in order to retain his position.

That isn't the issue.

Say instead:
There IS a lot of interest in Bitcoin but the reward system is borked so difficulty falls.
Entrenched interests see this as an easy opportunity to kill a competitor and make a 51% attack.

If there's not enough interests in bitcoin,
and the difficulty falls,
and it's easy to make a 51% attack,
then it raise two questions:

1.  Are you sure there will be any interests in attacking it ?
2.  Why do you even care ?

Not fully utilising the full merged-mining capacity seems like a tragedy too, maybe it is not technically exactly a tragedy of the commons per se, but all that open potential being dog-in-the-manger fenced away from the commoners instead of being expansive and accomodating as many chains as it can seems not unlike some steps in how commons got fenced off.

We're lucky we even still have rights of way along rivers and beaches in some juridictions let alone any actual commons.

Its my power, mine to waste, I profit by denying it to others... Familiar tune.

-MarkM-

What you need out of the network speed depends on what you are trying to secure the network against. I'm not concerned about double spends either. However, I think it will become relatively easy for a single miner to acquire 51% and exclude all other miners. This will be profitable because:

a) he will be able to acquire 100% of block generations as opposed to 51%
b) he will be able to acquire 100% of txn fees as opposed to 51%
c) he will be able to charge higher txn fees than would occur in under competition.

This is already pretty feasible for a wealthy individual or group of individuals. Later, it will become easy vis-a-vis the potential rewards. I think you will need something like the current block reward to prevent a monopoly from forming. It is worth nothing that because of (c), fee-based rewards are more conducive to monopoly than currency generation. I don't think bitcoin will fail when mining becomes a monopoly. In my view, the profits of an honest monopoly likely greatly exceed those due to double spending. This is a good thing because it means that there is no reason to fear a monopoly.

Despite all this, I believe proof-of stake is much better than proof-of-work because it results in a lower marginal cost of txn verification and therefore lower fees under both monopoly and competition.

I don't understand the assumption that you have to keep network speeds at the current level (argument 2). It seems to me very likely that network speeds are too high currently and could fall a lot without reversal attacks becoming overly problematic.

By the way, some people believe that a single transaction reversal, ever, will kill Bitcoin. I don't agree with that perspective, but there's only one way to find out, and that's for network speeds to drop to the point where we see one.

No, it is not a repeated game. The participants are anonymous, so there is no way conditioning strategies on the actions of past players. Moreover, even if the game were not anonymous, improved outcomes in repeated games rely on punishments that can be inflicted on players who behave poorly. There is no strong punishment that can be meted out here, so even the repeated setting wouldn't help that much.

As far as your other responses go, I can't refute them with a logical argument. In some sense they are empirical questions rather than theoretical questions. Nevertheless, I remain extremely skeptical and see assurance contracts as a dead-end/red herring. It will be interesting to see the assurance contracts implemented because I am curious as to what will be the primary mechanisms of failure.

I like this discussion.


It is possible that the lack of real world examples of assurance contracts is because of the overhead and inefficiency. With Bitcoin, they can be very efficient and simple to use, and this might make the difference. Lack of existing prior cases is not a disproof of the method's effectiveness.


You speak with high confidence ... I just don't know yet. If Bitcoin's valuation becomes significantly larger than it is today, then a relatively minor portion of it will suffice to incentive miners.


Large Bitcoin stakeholders are likely to be well informed of its mechanics. Remember, this is a good few years into the future ... this is ample time for plenty of detailed economics studies to be conducted, and for the "correct" security requirements to be very well known. Institutionl investors will understand the value of security ... the knowledge will "seep in" and ample warning will be given when hash rate approaches critical levels. The key thing here is that (I believe) BTC holders will really understand this aspect, and will known it's in their best interest to fund security.


There are many people with a large stake in Bitcoin. Those people will devote the ample time and resource to initiate assurance contracts and educate others about them. I believe we'll actually see a strong "non-profit" Bitcoin Foundation form pretty soon.



This is an iterated game (compare it to iterated prisoners dilemma vs single round). In an iterated game of assurance contracts, people will understand it's really in their best interest to get a mutual buy in, and will not necessarily do the short term selfish thing of withholding from investing. Also, we could blur the line with "vague contracts" - some amount of BTC and a deadline are chosen in advance, but the exact numbers are not published beforeahand, but rather only some estimates. "I donate 10 BTC, provided X amount of BTC, between 1000 and 1500 is gathered up by block Y, between 2,000,000 and 2,150,000". This vagueness might reduce the possibility of knowing whether you are the marginal contributor, and might solve this problem completely. This is like in prisoner's dilemma, if the number of rounds is known in advance, the rational analysis suggests you should betray at round 1, while if the exact number of rounds is not known, this is not the case. Also, as Mike and others have commented, game theory is just a model of real people's behavior, and is often very very wrong, as numerous studies have shown.


Thanks, I'll take a look at that thread.

I have several reasons for doubting that assurance contracts will be useful. In order of perceived importance:

1) [lack of proven usefulness] assurance contracts are not widely used to fund public good production. If they were effective, we would see them operating more frequently in the wild. Instead, the vast majority of public goods are funded by large, centralized entities such as governments, churches, and corporations.

2) [amount of money necessary] the amount of donations necessary to sustain a hash rate-currency valuation ratio like the current one is extremely large (maybe 10% of all extant bitcoin need to be donated each year). I am extremely skeptical that assurance contracts could muster this type of support.


3) [uncertainty about security need, boy who cried wolf] it will only be apparent to people that security is necessary if a successful attack takes place. People will quickly weary of contributing to some cause which has no proven usefulness. Once you are able to prove to people that the contract is necessary, it will already be too late. After an attack has occurred, assurance contracts cannot be enforced.

4) [entrepreneurship] establishing assurance contracts is costly for the initiator. Some private individual has to gather information about blockchain security and decide when a contract is necessary. If he initiates a contract when it is not necessary, then he has wasted his money. The incentives for atomistic individuals to perform this entrepreneurial function are extremely weak. They are much more likely to default to not doing anything.

5) [dynamic waiting problem] Under an  assurance contract, there is a marginal contributor whose contribution puts the contract into effect. If you are considering making a contribution, it is always better to wait to the last minute to try to avoid being the marginal contributor. If the contract is fulfilled before the last minute, then you will benefit from withholding your contribution. Thus the contract is unlikely to motivate many contributions until very nearits deadline. Even though incentives to contribute improve at the very end, I doubt that everyone will be able to coordinate at the last minute to fulfill the contract. Last minute coordination is difficult.


On another note: Ripper, you asked about proof-of-stake. I provide some more details about my ideas for proof-of-stake in this thread: https://bitcointalk.org/index.php?topic=55184.20
There are ideological objections (read FUD) to proof-of-stake, but I am not aware of any logical flaws. I think the ideological concerns would fall away in the face of a proof-of-concept. After all, most people have ideological objections to bitcoin when they first hear about it.