Topic: [ANN] Reality Keys: An oracle letting you use external state in transactions - page 2. (Read 7787 times)

Hm, you're right. In this case I again can't think of a good way to use realitykeys.com. Hopefully some new ideas will appear in this topic.

I think VTC is asking about the 2nd address in that scenario - the one bob funded. He can move his bitcoins before alice finds out the keys have been revealed.

Good question. The 4 public keys of the first address are:

1st public key if < 2000:
044BD2C100F5B52B54217A4B7A1356ABE8352FEF64EDC440BEDE7F14793B79E79F967633189796C A838CB43374563090136FAA3A573BBBDCF3CE8B7130E30A439A

2nd public key if < 2000:
047EE78EE7ED1F7E0E50D3C0585E4C695DC68A2503BA8A5343338CD72F962CA500D5AABD4157739 1294725379CB746CD5F614381951739D17A73DA34C2D134B941

Public key Alice:
0448B9EC5366E8C4DFE9F5599C926220C3FC594CE9322F17FEAF28B59EBA4F3CA3193D7A9DA63AB 975D9BA4642056CCC3C15657B8EB58ED6F45E6663BD8531BFFB

1st public key if >2000:
04501598839906E9782D3EA82AFAFD87839AE6E1DC34061BB17B196B4D9BF4B76BD0F20FE783D87 D995E88774B940866A70B51323AD188AAFFAF51AE30A865882B

Realitykeys will reveal two private keys for this address only if 1BitcoinEaterAddressDontSendf59kuE has less than 2000 millibits. Otherwise, they will reveal only one. Bob can not use the one private key to move the funds, because the address is 2-of-4. He doesn't know Alice's private key. So he needs 1BitcoinEaterAddressDontSendf59kuE to have less than 2000, and this is their original bet anyway.


Another good question. The redemption script is always the same, if you input the same public addresses and required signatures. If Alice knows, that the 4 keys will be the following, she can get the redeem script by herself and see for herself if Bob has deposited coins:
1st public key if > 2000:
04501598839906E9782D3EA82AFAFD87839AE6E1DC34061BB17B196B4D9BF4B76BD0F20FE783D87 D995E88774B940866A70B51323AD188AAFFAF51AE30A865882B

2nd public key if > 2000:
043801DF383779F7EDF643F2F195239032EE00BDC58FE7DD059C72C3E65853C92E926ABE11896C5 09F8D8BAEABD7D7CEC07095472BAA9B231F5E6AAB0E64EA0686

Public key Bob
04EF264DF632BB21AED00BDD2FED565496CBD017CBB59E8CB3B303CF1AB065D42B7205B0C991C54 0F02620AC2DAFBC0CB21D23F4192B68A08E218AED91ED59F71C

1st public key if < 2000:
044BD2C100F5B52B54217A4B7A1356ABE8352FEF64EDC440BEDE7F14793B79E79F967633189796C A838CB43374563090136FAA3A573BBBDCF3CE8B7130E30A439A

You can play around with this website and see for yourself - https://coinb.in/multisig/.

What prevents Bob, or anyone with knowledge of the redemption script, to quickly move 10 of the millibits  before Alice can do so, as soon as realitykeys reveals two of the keys?  If Bob keeps the redemption script private, how can Alice prove that Bob deposited coins for the bet.

Thank you edlund. There is just one thing. 2 of 4 and 3 of 6 addresses are not "standard". I read that people have difficulty spending from such addresses. 3 public keys seems to be the maximum number that is widely supported.

There is a discussion here: https://bitcointalksearch.org/topic/are-multi-sig-m-of-n-transactions-with-n-3-supported-508256

Let's say that Alice wants to bet 10 millibits against Bob's 10 millibits that the address 1BitcoinEaterAddressDontSendf59kuE will have at least 2000 millibits on 03/23/2014.
They create two new events like these:
https://www.realitykeys.com/blockchain/89/
https://www.realitykeys.com/blockchain/90/

Let's say that Alice has a public address corresponding to the private key 5JNsUzxm5gyRybX5GLJ56ccWo45zFT7RPJDoBgffuqq8DiRh7fu and Bob has a public address corresponding to the private key 5KTqVVteW3cUAyXxerB5ho9mkMFg6LJ9ez5mnRx2zLPZsXaoiCD.
They will create two 2-of-4 multisig addresses.
The first one consists of the 2 public keys which realitykeys.com* will reveal if 1BitcoinEaterAddressDontSendf59kuE has less than 2000 millibits on 03/23/2014, the public key of Alice, and 1 public key which realitykeys.com will reveal if otherwise. This gives us the address 39X1TUG2bTJQ4SJ2HRjGMWewdXDoR4sm3R and the redeem script:

5241044bd2c100f5b52b54217a4b7a1356abe8352fef64edc440bede7f14793b79e79f967633189 796ca838cb43374563090136faa3a573bbbdcf3ce8b7130e30a439a41047ee78ee7ed1f7e0e50d3 c0585e4c695dc68a2503ba8a5343338cd72f962ca500d5aabd41577391294725379cb746cd5f614 381951739d17a73da34c2d134b941410448b9ec5366e8c4dfe9f5599c926220c3fc594ce9322f17 feaf28b59eba4f3ca3193d7a9da63ab975d9ba4642056ccc3c15657b8eb58ed6f45e6663bd8531b ffb4104501598839906e9782d3ea82afafd87839ae6e1dc34061bb17b196b4d9bf4b76bd0f20fe7 83d87d995e88774b940866a70b51323ad188aaffaf51ae30a865882b54ae

The second 2-of-4 address consists of the 2 public keys which realitykeys.com* will reveal if 1BitcoinEaterAddressDontSendf59kuE has at least 2000 millibits on 03/23/2014, the public key of Bob, and 1 public key which realitykeys.com will reveal if otherwise. This gives us the address 3MDaf2H76q849GPh45bFkm1smfWE5fij5n and the redeem script:

524104501598839906e9782d3ea82afafd87839ae6e1dc34061bb17b196b4d9bf4b76bd0f20fe78 3d87d995e88774b940866a70b51323ad188aaffaf51ae30a865882b41043801df383779f7edf643 f2f195239032ee00bdc58fe7dd059c72c3e65853c92e926abe11896c509f8d8baeabd7d7cec0709 5472baa9b231f5e6aab0e64ea06864104ef264df632bb21aed00bdd2fed565496cbd017cbb59e8c b3b303cf1ab065d42b7205b0c991c540f02620ac2dafbc0cb21d23f4192b68a08e218aed91ed59f 71c41044bd2c100f5b52b54217a4b7a1356abe8352fef64edc440bede7f14793b79e79f96763318 9796ca838cb43374563090136faa3a573bbbdcf3ce8b7130e30a439a54ae

Alice sends 10 millibits to the first address, Bob sends 10 millibits to the second one.

After 03/24/2014, if 1BitcoinEaterAddressDontSendf59kuE has at least 2000 millibits, 1 public key from the first 2-of-4 address will be revealed, and 2 public keys from the second address. Alice will be able send all 20 millibits to her own address. If 1BitcoinEaterAddressDontSendf59kuE has less than 2000 millibits, 2 public keys from the first 2-of-4 address will be revealed, and 1 from the second address. Bob will be able to send all 20 millibits to his own address.

The beauty of it is that there is no third party involved in storing the millibits. If Alice and Bob fear that realitykeys.com can steal their millibits, they can create 4-of-6 addresses, with 3 public keys from Alice and Bob and the already mentioned 3 from realitykeys.com. This way even the guys from the website will not be able to touch the millibits.

*realitykeys.com shows the public keys in compressed form. In order to get the uncompressed addresses in hex, needed to create multi-sig addresses here, you can use the Bitcoin Address Utility by Casascius. You need to go to Tools > Address Utility > paste in „Public Key Hex“ > click Publick Key > Uncompress Public Key.

Ok this is all nice and everything but could you please explain what n of m combination would be used? Take this for example:

https://www.realitykeys.com/blockchain/52/

Agreed. Script 2.0 is the way to go

Yup, BitRated is a really nice piece of work. I'm just wading through a lot of different stuff trying to work out the most practical thing to say to people who would like to use our keys in contracts and don't where to start; Ideally I'd rather just focus on providing keys that prove facts and let other people figure out how they want to use them, but I guess there are some areas where we could provide a helpful nudge.

Have you seen Bitrated yet? I'd strongly advise you to contact them and see what it'd take to add support for oracle transactions to their escrow service. You could almost even use it as-is right now, except that the system only (currently) lets you set a single pubkey for the escrow agent.

Yes, I think it could be useful in that area. We're missing a couple of features right now in that respect but they're on the todo list:

1) Watching individual transactions - currently we can tell you about total payments coming into addresses and the total balance in an address, but we don't look at specific transactions. I haven't thought much about the kind of things we'd test for, but let us know if anyone has any specific comparisons they'd like to be able to make against these.

2) Monitoring other chains. We're watching blockchain.info for Bitcoin, but we also built some functionality to watch cryptocoin explorer for alt-chains. This is turned off right now because some of their API calls seem to be misbehaving at the moment, and in any case they seem to be down a lot of the time. People who need this functionality might like to consider donating to them.

It's also nice that your blockchain watching functionality allows us to experiment with some of the things we might want to do in a Script 2.0 without too much risk.

I can just as easily construct a spendable txout to tempt the release of a hash-preimage:\

DUP SHA256 EQUALVERIFY CHECKSIG

and send Reality Keys an email informing them of their bounty, if only they'd be dishonest...


Low is my guess among the current set of developers. But if you can come up with a good reason...

Then again, if you used a hash, there wouldn't be any addresses to spend to. One advantage I can see is that doing it with an address rather than a hash is that you don't run afoul of IsStandard. Any other pros or cons?

And speaking of IsStandard, what are the prospects of less restrictive rules any time soon, perhaps only for P2SH scripts?

Ah thanks, that makes sense.


OK, it sounds like for our current purposes we're best sticking with the current thing (a gazillion random key-pairs pre-generated by a plain old vanilla bitcoind with only the public keys accessible to the public web server until an event is settled) and building a bit more verifiability on top. It shouldn't be an impossible problem given that all the data we're talking about is public. We're currently logging all registered events and assigned public keys to an external syslog service, and it should be fairly straightforward to add blockchain notarization or some other form of integrity checking on top of that.


Even on the current scheme I guess it would be possible for us to release keys for an event without knowing the contents unless we needed to adjudicate it; If you gave us a regular hash of the event you want keys for rather than the content, you wouldn't have to give us the content until such time as you needed adjudication. Not a feature I'm inclined to offer at the moment, though.


Right, and I suspect there are lots of other little benefits to this approach that we haven't thought of yet.

You're caution was quite justified in this case! Unfortunately the way ECC math works if you release the secret key for one of these ECC-multiplication-derived pubkeys - as you must in your application - the master secret key can be recovered with some arithmetic if the pubkey key is known - again a must for the public derivation to be useful. Unfortunately there is no known way around this problem with ECC math, and the Bitcoin scripting language is too primitive to check an arbitrary signed message instead. I actually had the same idea when I originally thought of the pubkey derivation, and mentally filed it under "yet another example of BIP32 pubkey derivation is subtly dangerous"

Having said that, if you accept the need for the user to contact you first you can still do this deterministically by just hashing some master seed with the thing the user is asking and using that hash digest to derive a secret key and finally public key. However that version requires you to keep the master secret online on a potentially hackable server - I'd recommend adding at least one more layer of indirection to that system to derive a per-day secret and transferring that secret to the server in question somehow. You probably also want to separate the server holding the secret from the webserver - make the former communicate with the latter (and outside world) by some tightly controlled communication channel and no other means of access.

Finally one curious property of the above is that you can interactively commit to releasing a secret key for a question unknown to you. e.g. you can provide the corresponding pubkey for H(question) without knowing the question itself until the time comes to reveal it. I'm not sure this is necessarily a good thing!


Elliptic Curve Diffie-Hellman key agreement is how that encryption works. Bitmessage implements it here



Note how this is actually an advantage of using revealed secret keys over my earlier proposal of releasing hash pre-images: you can spend such a donation without revealing the secret key.

And of course, it wouldn't bias your decision either way, since you could spend outputs that had been donated to both addresses before destroying the key for the eventuality that didn't happen.

Congrats on the launch! It's looking really great - using Freebase is a fascinating idea.

Probably the nearest term useful app for this would be some kind of currency hedging system. But as you note, it's quite complicated.

As you'd guessed, we want to stay as far away from any actual contract as possible for the reasons you've given. This approach is also nice and simple and transparent. Everybody can figure out what we're doing, all our events are public, and the results are public too, so everybody can see how we settle them.

Also, although we've been talking about this as a bitcoin service, it's not necessarily bitcoin-specific, or even crypto-currency specific, or particular to the use-cases that have been discussed to date. Our keys could be used for encrypting messages (I think they're really designed for signing, but apparently it's possible to encrypt with them - if people want to do this and need another type of key we can talk) to be released in the event that something happens. For example, "Barack Obama has hidden a fish in a big block of ice somewhere under the floorboards in the Oval Office. He's written a message that will be released if the Democrats win the next election, so they can find it and throw it away before it starts to rot. But if the Republicans win nobody will know about it and they'll be going nuts trying to figure out where that smell is coming from."


We'd consider it a donation.

I like the sound of that, I'll give it some thought.

IIUC there's another way we could be approaching this, which would be that rather using individual random key-pairs as we currently do, we'd use key-pairs derived deterministically from a single key-pair, combined with a hash of the event we've registered. If I've got this right, thanks to the magic of ECC multiplication, people would then be able to independently derive the the public keys used in each case, without being able to derive the private keys. That way we can almost get rid of the concept of "registering" an event altogether; If you've got a record of an event (allowing us to recreate the hash) and our corresponding public keys, you can bring them to us at the due date and we can derive the private keys again to release one. People could actually create events independently, without even using our API.

We didn't spend any time looking into doing things this way because I wasn't quite confident enough that we wouldn't screw it up in some subtle way that somebody would discover halfway through 2015 after people had used these keys for a bunch of contracts. But if it can really be done as I've described it the approach would head off all kinds of nasty potential problems, including our losing data after you register a fact, and somebody hacking our public web server and managing to monkey around with the registered events or public key assignations without us detecting them.