Hard-Fork to make us have a have a FREE Universal lottery system

[remotemass]

I think this would be possible but I am not sure so I would like to know what developers say about this.
There would be a change in the protocol so that a specific address could not be used to send coins. It could only receive them. This way it could be used to burn coins and everyone would be sure that no one could ever own that address and spend those coins.
Then - for every block - the amount of coins that were sent - during that 10 minutes in between block creation - to that "burn address" would be given as a reward with coins entering circulation, making it a lottery.
This means that there would be no limit of bitcoins entering circulation but the extra coins entering circulation other than the ones from mining would be balanced by the ones burned, so no one would loose anything and we could talk about live coins that would still be limited to 21 million and dead coins.

The winner of this lottery mining would always be ruled by the following:

For every amount sent you would have that number of satoshis sent make you have your bitcoin address virtually listed in an ordered list of all the participations as many times as satoshis sent.

So for example if 1KyDtBCT6Vj7VdRP32reeNycrGnVvEjNDV sent 0.00000005 BTC, and after 1n6mSy5xptF8NpF5Nvoy3k1p1vapmZJb3 sent 0.00000003 BTC, and after 112adnFHbxDD9F72gRECPfxL3j62Ktrcm1e sent 0.00000009 BTC

The virtual list with the entries of participations would get to be:

 1 => 1KyDtBCT6Vj7VdRP32reeNycrGnVvEjNDV
 2 => 1KyDtBCT6Vj7VdRP32reeNycrGnVvEjNDV
 3 => 1KyDtBCT6Vj7VdRP32reeNycrGnVvEjNDV
 4 => 1KyDtBCT6Vj7VdRP32reeNycrGnVvEjNDV
 5 => 1KyDtBCT6Vj7VdRP32reeNycrGnVvEjNDV
 6 => 1n6mSy5xptF8NpF5Nvoy3k1p1vapmZJb3
 7 => 1n6mSy5xptF8NpF5Nvoy3k1p1vapmZJb3
 8 => 1n6mSy5xptF8NpF5Nvoy3k1p1vapmZJb3
 9 => 112adnFHbxDD9F72gRECPfxL3j62Ktrcm1e
10 => 112adnFHbxDD9F72gRECPfxL3j62Ktrcm1e
11 => 112adnFHbxDD9F72gRECPfxL3j62Ktrcm1e
12 => 112adnFHbxDD9F72gRECPfxL3j62Ktrcm1e
13 => 112adnFHbxDD9F72gRECPfxL3j62Ktrcm1e
14 => 112adnFHbxDD9F72gRECPfxL3j62Ktrcm1e
15 => 112adnFHbxDD9F72gRECPfxL3j62Ktrcm1e
16 => 112adnFHbxDD9F72gRECPfxL3j62Ktrcm1e
17 => 112adnFHbxDD9F72gRECPfxL3j62Ktrcm1e
...
N => xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

It would then be computed:

( LAST_HASH_VALUE Mod N ) + 1

(where mod is the modulus operation, that is, the remainder of the integer division).
It would be looked up that result in such virtual list of entries and the corresponding bitcoin address would be the winner.

And would get the same amount of coins as was sent to the lottery burn address in between that block creation.

This would allow for a universal lottery with the bitcoin network.
Very simple to use. The lottery address would always be the same as it would be hardwired in the software.

Even, if it won't happen with bitcoin, maybe it could be implemented in some altcoins.
What do you think?
I think it is a really good idea. Imagine the most popular lottery in the world that payed 0% taxes and had 0% revenue for the lottery house.

Such a Free Universal lottery appeals a lot to me!!!

[deepceleron]

There is already such a system. Send a transaction with 1 BTC in fees. Since a miner can collect the fee of any transaction they include in a block, the fees would then, like you say, "be given as a reward with coins entering circulation, making it a lottery".

The failure with your system (besides zero interest) is that miners make the blocks and decide what goes into them. Transactions are stateless, they have no order in which to be processed. The miner can order them however they wish, and can quickly determine a transaction solution that would make their entry always win.

[franky1]

you might want to look at how currently tx fee's end up as being part of the block reward. as the solution to your lottery is much more simpler then remaking a whole new protocol

EG
address from
1P3r5on5W4ll3t4ddr3ss contents 1.00000000btc
send to
1P3r5on5W4ll3t4ddr3ss amount 0.99999999btc

this puts 1 satoshi to the block and the rest returns to original address

all you have to do is program how to dispurse the funds afterwards. maybe each tx is numbered from 1 to 4000 (rough transaction total limit per 1mb block) and then just have a random number generator that sends reward to the address of winning random number

[remotemass]

There is already such a system. Send a transaction with 1 BTC in fees. Since a miner can collect the fee of any transaction they include in a block, the fees would then, like you say, "be given as a reward with coins entering circulation, making it a lottery".

That's very different from what I am proposing because in my proposed system you don't have to be a miner and the probability of winning is completely separated from the likelihood of miners to win the mining rewards.
What you are saying makes no sense. You cannot use transaction fees to participate in such a lottery as you said.  

The failure with your system (besides zero interest) is that miners make the blocks and decide what goes into them. Transactions are stateless, they have no order in which to be processed. The miner can order them however they wish, and can quickly determine a transaction solution that would make their entry always win.

You may not see anything interesting in my proposal but a lottery that doesn't drag any of your money into taxes or revenues to the owner of the game, and that has the potential to become the most popular lottery in the world, is certainly interesting.
Besides you are missing my point because it doesn't matter the order of the transactions that goes into the block because the hash of the block will be random and unpredictable and so the result is completely unpredictable. There is no way the miners could determine the outcome.

[-ck]

Amusing idea. Chance of it getting majority support for a hard fork and being implemented though? Zero.

[remotemass]

you might want to look at how currently tx fee's end up as being part of the block reward. as the solution to your lottery is much more simpler then remaking a whole new protocol

EG
address from
1P3r5on5W4ll3t4ddr3ss contents 1.00000000btc
send to
1P3r5on5W4ll3t4ddr3ss amount 0.99999999btc

this puts 1 satoshi to the block and the rest returns to original address

all you have to do is program how to dispurse the funds afterwards. maybe each tx is numbered from 1 to 4000 (rough transaction total limit per 1mb block) and then just have a random number generator that sends reward to the address of winning random number

My proposal wouldn't affect the tranaction fees. Miners would get exactly the same rewards and no one would be affected at all as the extra coins for the lottery would be in the same amount as those sent to the hardwired burnt address.

[remotemass]

Amusing idea. Chance of it getting majority support for a hard fork and being implemented though? Zero.

Well, this would be an extra to an hard-fork that would implement some other more important features.
We can start by simply having a burn address that everyone can trust. That would already be an interesting feature.
Or we can think of such a feature being implemented in some other cryptocurrency.
It would certainly become an allure of it.

[franky1]

the reason i thought of showing you a alternative method was because your idea has a few flaws.
1) an address that no one can then spend, is an address where funds cannot move out of (because spending IS moving)
2) having half a dozen deposit addresses makes coding the protocol alot harder
3) if miners did not deal with the reward disbursement.. then who would?? and how would you make it trustless and unable to be manipulated
4) you cant just send 1sat to an address (satoshi dust limit)
5) the collecting funds and random disbursment would be much more easier to code if done as a tx fee method and a random number generated between 1 <> total transactions of block.

it was only a quick 5 minute thought to try to find the simplest solution to making a new alt have a lottery.

it also confused me where your reply to me says it wouldnt affect tx fee's... yet your OP post says

given as a reward with coins entering circulation, making it a lottery.

which to me read as the same principle of how tx fee's work

[andytoshi]

There would be a change in the protocol so that a specific address

Addresses do not appear in the protocol.

could not be used to send coins. It could only receive them.

This is already the case.

This way it could be used to burn coins

You can burn coins by use of provably unspendable outputs.

and everyone would be sure that no one could ever own that address and spend those coins.

It is possible to create addresses for which "everyone is sure" that nobody owns corresponding key material, by use of nothing-up-my-sleeve numbers or "hashes" with too much structure to have possibly been found by searching. But you cannot make them provably unownable, so doing this is strictly inferior to using ordinary provably unspendable outputs.

Then - for every block - the amount of coins that were sent - during that 10 minutes in between block creation - to that "burn address" would be given as a reward with coins entering circulation

This is already the fee semantics, and has nothing to do with addresses.

, making it a lottery.

Fees are not a lottery. You later indicate that this new reward has a fixed miner-independent destination determined by the protocol, so I suppose I am misunderstanding. In future, I advise you to not use the term "reward" to describe coinbase outputs which are not miner rewards, since this will only cause confusion.

The winner of this lottery mining would always be ruled by the following:

For every amount sent you would have that number of satoshis sent make you have your bitcoin address

Who lists your address? Every validator, I suppose. How do they know it? Was it encoded in the burn address somehow?

virtually listed in an ordered list of all the participations as many times as satoshis sent.

So for example if 1KyDtBCT6Vj7VdRP32reeNycrGnVvEjNDV sent 0.00000005 BTC, and after 1n6mSy5xptF8NpF5Nvoy3k1p1vapmZJb3 sent 0.00000003 BTC, and after 112adnFHbxDD9F72gRECPfxL3j62Ktrcm1e sent 0.00000009 BTC

The list with the entries of participations would get to be:

<snip>

It would then be computed:

LAST_HASH_VALUE Mod N

How is the ordering of these addresses determined? Why have you chosen a probability distribution so that the ones near the front of the list are more likely to be selected than ones on the last? (The difference is negligible, but totally unnecessary.) Also, miners would always take this reward since they control what goes into the list of addresses, so the distribution is irrelevant.

<snip>
This would allow for a universal lottery with the bitcoin network.

Have you investigated any of the other research into trustless lotteries? For example this one?

<snip>
Even, if it won't happen with bitcoin, maybe it could be implemented in some altcoins.

Wouldn't surprise me.

[remotemass]

the reason i thought of showing you a alternative method was because your idea has a few flaws.
1) an address that no one can then spend, is an address where funds cannot move out of (because spending IS moving)
2) having half a dozen deposit addresses makes coding the protocol alot harder
3) if miners did not deal with the reward disbursement.. then who would?? and how would you make it trustless and unable to be manipulated
4) you cant just send 1sat to an address (satoshi dust limit)
5) the collecting funds and random disbursment would be much more easier to code if done as a tx fee method and a random number generated between 1 <> total transactions of block.

it was only a quick 5 minute thought to try to find the simplest solution to making a new alt have a lottery.

You don't seem to have a clue of what I am talking about.

1) and 2) Doesn't make sense
3) The extra coins entering circulation would be extra, that means rewards from mining and transaction fees would be exactly the same

4) I never said you would send a single satoshi. You send ANY amount that you want and a purely virtual list is taken into account to have a numbered list of participations. Each participation will regard one satoshi only associated with a bitcoin address but coins are sent all at the same time. Is just that if you send 1 BTC you are buying 100, 000 000 entries. If you send 0.05 BTC you "buy" 5 million entries. Etc. You get the idea. But these entries are purely virtual. Is just for the software to know the winner, calculating the winner entry and the corresponding address.

5) Seems nonsense, also.

Do you really understand my idea? I suggest you read it more thoroughly and ask me questions. It seems you have no clue of what I am talking about.
Maybe would be good someone that actually understands what I am proposing explains it in a better way... I understand that it may be confusing at first and/or that I am not explaining it in the best way.

[franky1]

fine questions

1) do you want the lottery funds to be merged in with block rewards and transaction fee's?
if yes then your idea is simply.. THE TRANSACTION FEE'S... you dont need special addresses to add funds into the reward pot..
2) if the lottery pot is to be separate from the mining reward pot. and dispersed away from mining (QUOTE: inbetween blocks) then who is dispersing it if its done between blocks?
3) if the lottery pot is separate from mining reward pot but dispersed AT block creation. then explain how and who gets the lottery pot where miners cant manipulate the code or make it so that a preferential winner is chosen

[deepceleron]

There is already such a system. Send a transaction with 1 BTC in fees. Since a miner can collect the fee of any transaction they include in a block, the fees would then, like you say, "be given as a reward with coins entering circulation, making it a lottery".

That's very different from what I am proposing because in my proposed system you don't have to be a miner and the probability of winning is completely separated from the likelihood of miners to win the mining rewards.

That part was a joke, I was only pointing out that the quoted paragraph is fulfilled by mining fee.

The failure with your system (besides zero interest) is that miners make the blocks and decide what goes into them. Transactions are stateless, they have no order in which to be processed. The miner can order them however they wish, and can quickly determine a transaction solution that would make their entry always win.

Besides you are missing my point because it doesn't matter the order of the transactions that goes into the block because the hash of the block will be random and unpredictable and so the result is completely unpredictable. There is no way the miners could determine the outcome.

What you describe is so different from the way that Bitcoin works it is hard to fathom in technical details what you are saying. Bitcoin is only comprised of transactions with ECDSA-signed spends, and UXTOs to a new address. A generate transaction is the only unique one, because Bitcoin allows for an additional transaction per block with no inputs, which pays to an address(es) or a public key, and the maximum that payment can be is MAX_REWARD + FEES.

You seem to be proposing another kind of "virtual" transaction as unique as the generate transaction, where Bitcoin sees another amount as spendable from the calculated lottery winner. The winner would be able to spend the "won" amount with the same privkey as entered. A whole new way of referring to this transaction number when spending would need to be thought of though, if you know how UXTOs are specified in transactions. The "entrant" transactions would only be unusual in that they are sending normal bitcoins to a new type of unspendable address, recognizable as being a lottery entrance, say any address with a network byte of 77.

The first critique is that hash % number of tickets = winning ticket is not fair. There are solutions to this, in fact I wrote them: http://we.lovebitco.in/raffle.html

Now the second inaccuracy - you say that entries will be made "during that 10 minutes in between block creation" - that's not how bitcoin works. Entering the contest takes a spending transaction. Miners choose what transactions to include in a block, and transactions must be included in a block in order to be spent or burnt. Transactions may have a large queue, miners may ignore some or all lottery transactions, etc. They might not be included in the next block, nor is there really a promise that they would be included in any particular order or in any block at all if miners all conspire to ignore them.

Then it all breaks down when you say "last hash" which I interpret to be the hash of the previous block.

So now we know that miners can pick and choose transactions, can include them in the Merkle tree in any order that they want, and that the "picking mechanism", the hash, is already known. It is a simple matter to gather up as many entrant transactions as possible, add one more transaction as the miner's entrance to get N, and determine the "winning ticket number". The miner just moves around the transactions until his is the winning number. If there is no solution, the miner just adds more satoshis or BTC to re-sort things until there is. Then he starts hashing that block.

Let's say you weren't so naive and that "last hash" meant the top hash of the current block, the one including the entrance transactions. This is not so manipulable in Bitcoin, because the hashed data includes the Merkle tree including the entrant transactions. This would still be subject to miner attack. The miner can include 9999 BTC of his own entrance transaction, vs the 1 BTC he includes from other entrants, so he will win 99.99% of the time and collect the 1 BTC. If a block is mined where he's not the winner, it can be discarded and he continues mining. He will never lose because his lottery entry is not published on the rest of the network.

[remotemass]

There would be a change in the protocol so that a specific address

Addresses do not appear in the protocol.

could not be used to send coins. It could only receive them.

This is already the case.

Well, I mean to originate a transaction signed by the private key to which that  address corresponds. I'd rather not play word games here. It will only confuse the discussion.

The miners would have to include the new extra lottery coins (minted) to the address of a winner that burnt their coins in a previous (confirmed) block.

The important thing is that you can burn the coins and that the coins burnt cannot be spent. I'm not sure in what sense it would be different with provable unspendable outputs. Can you please clarify that?

The order of the transactions will be that order that they have in the blockchain.

All the participants have a probability of winning corresponding to the amount they sent. Probability is simply: amount sent/total_of_amounts_sent.
Prize is: total_of_amounts_sent.

I have no idea why you say the probability distribution I chose is so that the ones near the front of the list are more likely to be selected than ones on the last.
Do you care to explain why do you say that?

[andytoshi]

Well, I mean to originate a transaction signed by the private key to which that  address corresponds. I'd rather not play word games here. It will only confuse the discussion.

Signing a transaction with a private key to which an address corresponds is nothing like "sending from an address" the way than any English speaker would understand "sending". Did you read the linked article?

The miners would have to include the new extra lottery coins (minted) to the address of a winner that burnt their coins in a previous (confirmed) block.

How many blocks back? From which block(s) are you extracting randomness? Can you describe the ways that various parties would try to game this system and what the costs to them would be?

The important thing is that you can burn the coins and that the coins burnt cannot be spent. I'm not sure in what sense it would be different with provable unspendable outputs. Can you please clarify that?

Provably unspendable outputs do not need to be stored by every single full node on the network for eternity. Non-provably unspendable (but unspendable) outputs do have this property.

I have no idea why you say the probability distribution I chose is so that the ones near the front of the list are more likely to be selected than ones on the last.
Do you care to explain why do you say that?

Suppose the blockhashes were to lie in [0, 9] rather than [0, 2^256-1], and that there were nine participants. Do you see why taking RNG([0, 9]) mod 9 will result in zero appearing twice as often as every other number?

[remotemass]

What you describe is so different from the way that Bitcoin works it is hard to fathom in technical details what you are saying. Bitcoin is only comprised of transactions with ECDSA-signed spends, and UXTOs to a new address. A generate transaction is the only unique one, because Bitcoin allows for an additional transaction per block with no inputs, which pays to an address(es) or a public key, and the maximum that payment can be is MAX_REWARD + FEES.

You seem to be proposing another kind of "virtual" transaction as unique as the generate transaction, where Bitcoin sees another amount as spendable from the calculated lottery winner. The winner would be able to spend the "won" amount with the same privkey as entered. A whole new way of referring to this transaction number when spending would need to be thought of though, if you know how UXTOs are specified in transactions. The "entrant" transactions would only be unusual in that they are sending normal bitcoins to a new type of unspendable address, recognizable as being a lottery entrance, say any address with a network byte of 77.

The first critique is that hash % number of tickets = winning ticket is not fair. There are solutions to this, in fact I wrote them: http://we.lovebitco.in/raffle.html

Now the second inaccuracy - you say that entries will be made "during that 10 minutes in between block creation" - that's not how bitcoin works. Entering the contest takes a spending transaction. Miners choose what transactions to include in a block, and transactions must be included in a block in order to be spent or burnt. Transactions may have a large queue, miners may ignore some or all lottery transactions, etc. They might not be included in the next block, nor is there really a promise that they would be included in any particular order or in any block at all if miners all conspire to ignore them.

Then it all breaks down when you say "last hash" which I interpret to be the hash of the previous block.

So now we know that miners can pick and choose transactions, can include them in the Merkle tree in any order that they want, and that the "picking mechanism", the hash, is already known. It is a simple matter to gather up as many entrant transactions as possible, add one more transaction as the miner's entrance to get N, and determine the "winning ticket number". The miner just moves around the transactions until his is the winning number. If there is no solution, the miner just adds more satoshis or BTC to re-sort things until there is. Then he starts hashing that block.

Let's say you weren't so naive and that "last hash" meant the top hash of the current block, the one including the entrance transactions. This is not so manipulable in Bitcoin, because the hashed data includes the Merkle tree including the entrant transactions. This would still be subject to miner attack. The miner can include 9999 BTC of his own entrance transaction, vs the 1 BTC he includes from other entrants, so he will win 99.99% of the time and collect the 1 BTC. If a block is mined where he's not the winner, it can be discarded and he continues mining. He will never lose because his lottery entry is not published on the rest of the network.

>> What you describe is so different from the way that Bitcoin works

I know how bitcoin works. You don't have to explain me that.

>> You seem to be proposing another kind of "virtual" transaction

I mean a generation transaction that creates new coins from nothing.
There would be the coins entering circulation for mining, as usually, and
(roughly, 25 BTC every 10 minutes) plus the new lottery coinbase coins (same amount
recently burnt)

>>recognizable as being a lottery entrance, say any address with a network byte of 77

There is no need for that.

>> Now the second inaccuracy - you say that entries will be made

Maybe my explanation was not very good but what I mean is that each block would be
having one of these lottery contests.
The transactions must be in the blockchain and with 6 confirmations or so, and only
then miners will pay the prize minting a number of coins equivalent to the amount
of coins that are confirmed to be burned on that contest.

[franky1]

as you can tell.. many are confused. and as more read the OP the more confused people will be. so it might be worth editing the OP and being a little more detailed about:
how the coins are produced/gathered up
how they are dispursed (by miners or separate entities)
how someone is eligible to 'win' (random winner selection)
how to prevent manipulation.

afterall the mining block reward as it is, is a form of manipulation. because the miners can put in their own address as the destination for the block reward. but of course they have to solve the block for the block reward to get to their destination.. and if someone else solves it, it would go to that persons chosen destination because the miners code the mining protocol to their own preferential destinations (self rewarding mining, which is acceptable form of manipulation seeing as they do the work)

so how would you stop a miner changing the destination of the lottery winner.....

[deepceleron]

>> You seem to be proposing another kind of "virtual" transaction

I mean a generation transaction that creates new coins from nothing.
There would be the coins entering circulation for mining, as usually, and
(roughly, 25 BTC every 10 minutes) plus the new lottery coinbase coins (same amount
recently burnt)

There is no need for an actual transaction. This only allows miners to omit the lottery reward transaction or pay it to arbitrary individuals, requiring "validation rules" for the transaction. Given the list of entrants from a block and a winner-picking hash from another, any Bitcoin client can determine the winner, recognize the balance and owner, and determine the validity of it being spent.


>>recognizable as being a lottery entrance, say any address with a network byte of 77

>There is no need for that.

You cannot make a normal bitcoin address unspendable. There are quadrillions of private keys that may equal that particular address and be generated offline by any of hundreds of tools in existence. While the chance of generating the same address is infinitesimal, it must be considered. It is one thing to to be able to send coins to an address that might be spendable by two people, it's another thing entirely to be able to send (or expect to receive) coins to an address that can be spendable by nobody or would be given to someone else.


>> Now the second inaccuracy - you say that entries will be made

>Maybe my explanation was not very good but what I mean is that each block would be having one of these lottery contests.
>The transactions must be in the blockchain and with 6 confirmations or so, and only then miners will pay the prize minting a number of coins equivalent to the amount of coins that are confirmed to be burned on that contest.

Again, we don't need a transaction to make the winnings. However you hint at the solution to most miner-based attacks. The hash of block X+10 picks the winner of block X. For example, let's say block 300,000 included your lottery payment; block 300,010's hash will determine the winner of block 300,000. When the list of entrants is buried under a few blocks before the winner-choosing hash occurs, the only miner attack method is block discarding (discarding block finds that don't pick the miner as winner), which could be very costly depending on the economics of the coin, and the influence of a miner is only proportionate to their percentage of the hashrate.

It is also probable that there will be many blocks with no entries or just a single entry. You could even say blocks 300,001-300,144 are one contest period (every 144 blocks), and block 300,154 picks the winner, making it a daily or weekly drawing.

[remotemass]

<snip>

>> There is no need for an actual transaction

I disagree. Although clients are able to determine the winner you would need someone to have a private key to spend the funds to pay the prize.
That makes it impossible to be sure he will pay the prize so it really makes more sense to enforce the prize payment with minted coins.
Those minted coins wouldn't affect anyone because they would correspond to the same amount of coins burnt.

>>You cannot make a normal bitcoin address unspendable.

Yes you can. You just need the protocol to be saying that transactions from that address are to be considered invalid.

>> Again, we don't need a transaction to make the winnings. However you hint at the solution to most miner-based attacks. The hash of block X+10 picks the winner of block X. For example, let's say block 300,000 included your lottery payment; block 300,010's hash will determine the winner of block 300,000. When the list of entrants is buried under a few blocks before the winner-choosing hash occurs, the only miner attack method is block discarding (discarding block finds that don't pick the miner as winner), which could be very costly depending on the economics of the coin, and the influence of a miner is only proportionate to their percentage of the hashrate.

>> It is also probable that there will be many blocks with no entries or just a single entry. You could even say blocks 300,001-300,144 are one contest period (every 144 blocks), and block 300,154 picks the winner, making it a daily or weekly drawing.


Exactly.

[remotemass]

I have to agree that using the hash of a block is prone to miners manipulation as they would be able to discard blocks that didn't make them winners.

Since *difficulty* changes every 2016 blocks, what about running the contest on the
first block after difficulty changes and use as random number the hash of: (all the following 2015 block hashes + new difficulty). Wouldn't that be a good random number for the winner draw?
The lottery would run every two weeks and you would have to place your bets during the first block.

Can you think of something even better?

[EDIT] I think Twitter could also be used as a third party to avoid that miners could discard blocks to manipulate the results. The random number mentioned just needs to be affected by a twitter-ID generated afterwards.
"Bitmillions" uses Twitter as a third party for a bitcoin lottery and it seems it works fine. https://en.bitcoin.it/wiki/BitMillions

[EDIT] Other reliable third parties for the the random number generation could be used, like Random.org, that has a good API.

[itod]

It looks like the OP is heavily misunderstood. His proposal doesn't have anything to do with the transaction fees. He just proposed an alternative coinbase included in every block, with the difference that this alternative coinbase would not be fixed to current 25BTC, but would be the exact sum of inputs in that block which have unspendable destination address.

Distribution of this alternative coinbase would not depend on the miner who mined a block, but would be spendable only by the private key corresponding to one of the public keys which sent BTC to unspendable address. Miners would gladly include such a lottery transactions in blocks because nothing stops those lottery trabsactions to have normal transaction fees.

Chances that the core devs would accept such a large change are close to zero, but the idea is very interesting and in general quite doable. It's at least worth a BIP, since such a lottery would really be great incentive for people to buy BTC.