|
kolinko (OP)
|
 |
June 13, 2014, 09:51:11 PM |
|
@AssymetricInformation - uh, what? What I'm saying is that the trust in oracles should come from the community. You find 15 people who both you and the other person trust to not cheat, and use them as arbiters. The only "centralised" part here is oracles.li, which keeps the lists, but it's as central to the whole system as PirateBay is to BitTorrent. If it goes down, the contacts remain intact, the mirrors remain intact, and anyone can create yet another list of oracles without a help or need for oracles.li.
@Anotheranonlol - I haven't heard about CounterParty broadcast. Will check them out. Bitmessage is far from perfect
|
|
|
|
|
|
|
|
|
|
|
|
You get merit points when someone likes your post enough to give you some. And for every 2 merit points you receive, you can send 1 merit point to someone else!
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
|
|
|
|
edmundedgar
|
|
June 19, 2014, 04:20:33 AM |
|
Hm, so it seems there are two possible approaches to the m of n oracle problem. Aside from the "who signs the keys" technicality.
One is that oracles promise to deliver as good results as possible. And you trust they will do so. (this is Reality Keys)
Another one is that oracles promise to run software and not interfere with it, and keep it secure - leaving the algorithm verification on the user's side. (this is Orisi as we described it in the paper, but perhaps we should change it?).
Yup, that sounds right. The second approach reduces the amount you have to trust the oracle to be competent to do (as opposed to honest, where it doesn't help), since you can check the code they'll be running. It doesn't completely remove the need for competence because it's still possible to screw up the setup and operations, but the more completely you specify and automate the recommended setup and operations the closer you get to removing it. What would make this approach really useful would be if there was a way to verify that the oracle really is running what they say they are. I've occasionally fruitlessly pestered cloud hosting providers to provide a service like this, where they'd give you a virtual machine that would only install the software you publicly specified, and would publish a record of what it was installing. Obviously this only shifts the need for trust along rather than getting rid of it, but cloud providers might be good people to shift the trust to because their businesses depend on strong existing reputations and they have a lot of skin in the game. The usefulness of this kind of service would go well beyond oracles - it would be useful for pretty much any case where you have some open source software that you need to run on a server and you need some kind of trust from your users. As for the "who signs transactions" - I discussed it with the developers today. For now we want to wrap up the alpha / proof of concept where oracles are the ones doing the signing, so people can start playing with it as soon as possible.
But the concept of oracles just delivering the keys is very interesting. Aside from the legal stuff, it would make it easier to gather all the signatures (right now oracles have to send partially signed txs between them - it's a pain), and it would allow Orisi to easily interact with other systems. I'll get back to you via e-mail on this one, ok?
Sounds good. I like this approach a lot but TBF there are some real practical advantages to signing the transactions: 1) People are more used to the signing model, and some clients can do it already without modification. 2) A lot of the patterns you need for the key-publishing model are either non-standard (so you have to send them to a miner like Eligius instead of broadcasting to the network) or need some rather unorthodox ECC voodoo to shoe-horn them into the standard script patterns, which makes me a little bit uncomfortable. 3) If you sign the transaction, you have more flexibility over what you sign, beyond what you could get into a bitcoin script. For example, you may want to say, "This transaction pays out (X * the BTC-USD) rate to Alice, and the rest to Bob". Whereas as far as I can figure conditions on the key-publishing model basically have to be binary. A quick update to this: Gavin has written a pull request that will make the transactions that allow you to do the key-issuing model cleanly standard. Assuming this gets pulled, it makes this model very attractive compared to transaction-signing. It's clear, transparent, involves oracles in less potentially regulated activity and gets rid of all kinds of coordination headaches. It also makes the oracles compatible with other systems to bitcoin, which they don't even have to know about. Just issue keys and let the client deal with the signing. The oracle doesn't need to know anything about the transaction, or about other oracles. I would strongly advise anyone thinking of running an oracle to look at this model. |
|
|
|
|
|
kolinko (OP)
|
|
June 20, 2014, 07:58:29 AM |
|
Gavin has written a pull request that will make the transactions that allow you to do the key-issuing model cleanly standard.
Wow, this is great news for smart contracts altogether. Do you know when it will get pulled, and what's the e.t.a. on this reaching the stable bitcoind release? Even with this update though, there's a problem with transaction size, right? IIRC we had problems submitting anything above 3 of 3 sig to pools other than Eligius due to the transaction size exceeding 500 bytes. |
|
|
|
|
|
BetMoose
|
|
June 20, 2014, 08:33:41 AM |
|
I am also interested in applying this into BetMoose.
(We really don't want to be holding coin)
Following this closely. PM me if anyone has merging ideas with our platform.
Adam
|
BetMoose.com - Wager on real world events. Profit from predicting the future. Create and share your own contracts.
|
|
|
|
edmundedgar
|
|
June 20, 2014, 09:09:04 AM |
|
Gavin has written a pull request that will make the transactions that allow you to do the key-issuing model cleanly standard.
Wow, this is great news for smart contracts altogether. Do you know when it will get pulled, and what's the e.t.a. on this reaching the stable bitcoind release? Even with this update though, there's a problem with transaction size, right? IIRC we had problems submitting anything above 3 of 3 sig to pools other than Eligius due to the transaction size exceeding 500 bytes. I don't know any more than anyone else does from watching the mailing list and I don't know of an ETA but assuming nobody disagrees I'd guess it would be in the next minor release. Maybe a few months until then? It'll still be a while before most miners upgrade after that but I don't think you need a lot of uptake to get something relayed? As for the current rules, make sure you're compressing your keys and including a sufficient fee for the transaction size. IIUC you should currently be able to do 15 on the current network without becoming non-standard. I doubt that will be increased any time soon because signature operations are expensive and potentially cause DoS risk. You may be able to cram more authorities in by using hash locking instead of signing. Instead of doing what Reality Keys currently does and saying, "I will release the privkey to pubkey Y if X happens" the oracle says, I will release the string that hashes to hash Y if X happens". Hashes should be shorter, and avoid using up sigops. The benefits of keys over hashes are: 1) They can be combined with other keys using ECC maths to get through the standard checks. (Hopefully soon moot) 2) They can be similarly combined with keys held only by the parties for privacy. 3) You can use the built in m of n logic without having to script it. |
|
|
|
|
|
kolinko (OP)
|
|
June 24, 2014, 06:23:42 PM |
|
Hashes should be shorter, and avoid using up sigops. Yeah, on the other hand, the problem with hashes is that they are "all or nothing", and they don't really allow for locking in the output address. The no output address lock is problematic, because there's of an obvious attack vector. I lock in my funds on an address protected by a hash. Once I want to redeem them, I publish a transaction, and a potential attacker can grab my transaction, replace the address with his, and try to race me to miners. The issue can be solved, and such an attack is hard to pull off, but still - a threat. But the bigger issue is that "all or nothing". We have contracts in the pipeline that will withdraw only a part of money from a multisig. For example, in case when you want to use oracles to handle a trusted wallet system (where oracles allow you to withdraw only a part of money per given day), or for term contracts, where the receiver gets from 0 to X bitcoins depending on details of the condition (e.g. he's to receive an equivalent of USD$1000, and the rest should go to the sender). Or a scenario where oracles are used to build a distributed mixer - everyone puts in money into a multisig address, and at a later date withdraws that money. (btw. if there's anyone willing to do a mixer, or a trusted wallet, or term contracts, contact me at kolinko@gmail.com, we'll help you do that using Orisi).There are ways to mitigate "all or nothing", but not in all scenarios (not in the mixer scenario), and in other scenarios it's quite problematic (you'd have to create multiple multisig addresses holding various denominations). |
|
|
|
|
|
edmundedgar
|
|
June 24, 2014, 11:19:05 PM |
|
Hashes should be shorter, and avoid using up sigops. Yeah, on the other hand, the problem with hashes is that they are "all or nothing", and they don't really allow for locking in the output address. The no output address lock is problematic, because there's of an obvious attack vector. I lock in my funds on an address protected by a hash. Once I want to redeem them, I publish a transaction, and a potential attacker can grab my transaction, replace the address with his, and try to race me to miners. The issue can be solved, and such an attack is hard to pull off, but still - a threat. That's not how you do them. You combine the hash with private key of the party so you can redeem with "(Alice-priv + data-hashing-to-yes-hash) OR (Bob-priv + data-hashing-to-no-hash)". But the bigger issue is that "all or nothing". We have contracts in the pipeline that will withdraw only a part of money from a multisig. For example, in case when you want to use oracles to handle a trusted wallet system (where oracles allow you to withdraw only a part of money per given day), or for term contracts, where the receiver gets from 0 to X bitcoins depending on details of the condition (e.g. he's to receive an equivalent of USD$1000, and the rest should go to the sender). Or a scenario where oracles are used to build a distributed mixer - everyone puts in money into a multisig address, and at a later date withdraws that money. (btw. if there's anyone willing to do a mixer, or a trusted wallet, or term contracts, contact me at kolinko@gmail.com, we'll help you do that using Orisi).There are ways to mitigate "all or nothing", but not in all scenarios (not in the mixer scenario), and in other scenarios it's quite problematic (you'd have to create multiple multisig addresses holding various denominations). Yes, there are some scenarios that require oracles to sign. |
|
|
|
|
|
kolinko (OP)
|
|
June 26, 2014, 02:51:30 PM |
|
That's not how you do them. You combine the hash with private key of the party so you can redeem with "(Alice-priv + data-hashing-to-yes-hash) OR (Bob-priv + data-hashing-to-no-hash)". That assumes that you know is in advance either the receiver's key, or receiver's address. There are contracts that say: "The first person to perform X will receive bitcoins protected by oracles". |
|
|
|
|
|
kolinko (OP)
|
|
June 27, 2014, 08:53:51 AM |
|
Regarding the compressed keys that should make the transaction standard. Did you test that, Edmund? We're compressing the keys, but tx is still too big to be accepted by anything besides Eligius.
|
|
|
|
|
|
|
|
