Reverse Lottery for Bitcoin Generation

[epaulson]

I'm a relatively new user, I generated 100 bitcoins, and since then... nothing. From what I've read, the difficulty for generating coins has increased dramatically. This is great, however it has the potential to limit the appeal for new users, who set up their system and then get nothing for days or weeks on end. I understand that the point of bitcoins is not to generate them, but for now it seems an important incentive for new users.

My guess is that changing the protocol for how many bitcoins are received (50) for the hash "winner" is unlikely. I had a thought on how we could effectively change the payout without changing anything about the bitcoin program or protocol -- a sort of "reverse lottery" for generating bitcoins.

If people registered for this "reverse lottery" they would pledge to donate their bundle of bitcoins to the reverse lottery if and when they successfully managed to generate them. This bundle would then be chopped up and distributed in varying proportions to other users who have registered for the reverse lottery. I don't know what the fairest or best way to distribute them would be, and I suppose it doesn't matter, because multiple reverse lotteries could be run simultaneously, for example, with the bundle being distributed to the 100 lowest hashes, or with the bundle being donated to everyone registered equally (the .01 bitcoin limit might be a problem for this, though). People could independently decide which lottery they wanted to register for.

I don't know how to enforce the donation of a full bundle for the anti-winner. One method would be to require donating a full bundle in advance in order to register, however this would leave out new users, which is part of the point of the whole thing. I suppose the other lottery members could agree to blacklist any registered reverse lottery member who doesn't donate his or her bundle after generating it. This blacklist might be circumventable if a person just generates a new bitcoin address, however.

Any thoughts would be appreciated!

[1715020840]

1715020840

[1715020840]

1715020840

[1715020840]

1715020840

[vess]

One thought on this would be to keep the test network at a low difficulty, and have a big "TEST" vs "REAL" button in the client.

This would let someone futz around with the system and when they're ready move over to REAL, with the associated warnings (it can take a long time, we estimate it will take blah days..)

Also helps solve the abandoned bitcoin deflation problem.

[llama]

I was actually doing a thing with Unorth for a while that was very similar.  Basically, I bought Unorth's computing time ahead of time, with the promise that I would get to keep any coins generated.

Of course, knowing the difficulty, his khash/s rate, and the number of hours I was buying, I was able to determine the expected value of my purchase.  However, I actually paid him slightly less than that number, since I was assuming the risk.  The role I was playing was not unlike that of an insurance company.

This was a fun experiment, but I think this sort of thing would have a very limited appeal for bitcoin.  The risk is so small that most nodes could easily absorb it and would prefer not to pay a fee for a third party to absorb the risk.  And, if any node was large enough (i.e. spent enough money on computation) that the dollar values involved were larger, then the central limit theory will kick in and the node's actual dollar volatility will be a very small fraction of their money spent on computation.