Just to give you something to chew on ... this is a very rough sketch of a thought experiment for an automated lottery that I don't yet know how to implement:
1. A global burn address is created and hard-coded into the app.
2. Wallet owners can send max(one) coin to the burn address, where it is irrecoverably lost.
3. Entrants are the list of the sending addresses of coins burned since the last draw.
4. Drawing occurs when prevBlock.nHeight mod 1440 == 0
5. Winners are the owners of the n addresses that are hex-within(prevblock.merklehash +/- a calculated range)
7. An amount of totalburnedcoins is added to the block reward.
8. totalburnedcoins - commission coins are paid to winning addresses in amounts according to a predetermined scale.
9. The house receives the predefined commission.
Even something as drop-dead simple as this is infeasible. As a distributed open source app, its cryptography is inherently pellucid, i.e. there's no opaque locus in which to vest control of a private key. It may be possible to model an opaque locus via a complex cryptography gavotte performed by Alice and Bob (and maybe Charles, if you're into that kind of thing). Or maybe the solution lies in recruiting the services of an oracle to take advantage of the opacity it provides --- at the cost of introducing potential exploit scenarios and of losing the protection provided by a 100% cryptography solution.
Cheers
Graham
1. A global burn address is created and hard-coded into the app.
2. Wallet owners can send max(one) coin to the burn address, where it is irrecoverably lost.
3. Entrants are the list of the sending addresses of coins burned since the last draw.
4. Drawing occurs when prevBlock.nHeight mod 1440 == 0
5. Winners are the owners of the n addresses that are hex-within(prevblock.merklehash +/- a calculated range)
7. An amount of totalburnedcoins is added to the block reward.
8. totalburnedcoins - commission coins are paid to winning addresses in amounts according to a predetermined scale.
9. The house receives the predefined commission.
Even something as drop-dead simple as this is infeasible. As a distributed open source app, its cryptography is inherently pellucid, i.e. there's no opaque locus in which to vest control of a private key. It may be possible to model an opaque locus via a complex cryptography gavotte performed by Alice and Bob (and maybe Charles, if you're into that kind of thing). Or maybe the solution lies in recruiting the services of an oracle to take advantage of the opacity it provides --- at the cost of introducing potential exploit scenarios and of losing the protection provided by a 100% cryptography solution.
Cheers
Graham
Forgive me if I'm being dense, but there is no need surely to make the whole shebang decentralised. Could the example you gave be achieved by using the MN network as a consensus mechanism for choosing the locus/loci, then let that selected MN/those selected MNs do the things that need a central control point?
Much like Darksend - it's not really decentralised in terms of parallelism, it's just a method of sequential MN subset selection, the MNs selected do their bit discretely, the code for which they all possess and the data for which gets pulled from the network, then pass the process onwards until the result is achieved and subsequently broadcast to everyone.
The processing doesn't need to be completely distributed.
I was thinking along the same lines.
Include randomness to the processing so its harder to pinpoint which nodes do what and to some degree when. But essentially an application initiated from, lets say inside the wallet, is broadcast to the servicenode network. Available servienodes are chosen at random to handle the service that is requested of them.
If you think about it, as mentioned before, Apple and Google started an app store and now they are trying to add mobile payments. With spreadcoin you have a currency and you are adding an app store.
