Quote from: coins101 on April 03, 2015, 09:50:45 AM

For SPR, the devs will need to give feedback on the framework to enable apps to plug into the servicenodes, when they are ready.

No plugins will be required per se, once a viable solution for the core problem is in sight ...

Obligatory prefatory admonishment: DYR, ofc.

https://en.bitcoin.it/wiki/Contracts

Example 4: Using external state

Quote

Scripts are, by design, pure functions. They cannot poll external servers or import any state that may change as it would allow an attacker to outrun the block chain. What's more, the scripting language is extremely limited in what it can do. Fortunately, we can make transactions connected to the world in other ways.

c.f. Early Temple project https://earlytemple.com:8181/

and also https://github.com/orisi/wiki/wiki/Mastering-Distributed-Oracles

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