Topic: Standardizing Wallet/Oracle integration (Read 802 times)
Control of software updates and decentralising it is indeed a huge task that needs to be tackled.
Right now lots of people are interested in this, it looks like it's going to be a very competitive space. Most people are building their own web wallet to go with it
Many of them marketing themselves as ultra-secure storage where the wallet provider can't steal your coins. This is a myth though, since the service controls both your wallet code and co-signature, they could easily obtain a 2nd key and take your money.
I think cryptocorp has the right idea. They are advocating for separation of wallet and oracle. They might lose out though - the market will probably go towards all-in-one solutions under the false belief that they can never steal your coins, until the next goxing happens.
The primary point of P2SH, at least originally, was shorter addresses. With BIP 70 you don't need short addresses any more because the scripts are being moved around in other ways so you could just use regular CHECKMULTISIG outputs. Lately the rationale for P2SH got re-written to be more like "keep the UTXO set slightly smaller at a cost of making the chain larger", but it's unclear if even that will apply if the threshold ECDSA stuff works out.
Anyway. It doesn't matter. Getting BIP 70 widely used will take a long time, maybe years. Until then we just have to suck up the extra complexity from handling P2SH addresses. The code only has to be written once and then it's done. As you can see, it ends up touching a few parts of the wallet.
Right now lots of people are interested in this, it looks like it's going to be a very competitive space. Most people are building their own web wallet to go with it, though running a web wallet comes with a lot of pain points all by itself (a lot of the TREZOR work has been sunk into their myTREZOR web wallet, for example).
I'm not working on the design notes I posted above at the moment. I'm working on regular HD wallets and getting them finalised and launched for real, along with some other things in parallel.
Anyway. It doesn't matter. Getting BIP 70 widely used will take a long time, maybe years. Until then we just have to suck up the extra complexity from handling P2SH addresses. The code only has to be written once and then it's done. As you can see, it ends up touching a few parts of the wallet.
Quote
I am interested in building a RA service as you call it, so would be keen to know when bitcoinj has this implemented.
Right now lots of people are interested in this, it looks like it's going to be a very competitive space. Most people are building their own web wallet to go with it, though running a web wallet comes with a lot of pain points all by itself (a lot of the TREZOR work has been sunk into their myTREZOR web wallet, for example).
I'm not working on the design notes I posted above at the moment. I'm working on regular HD wallets and getting them finalised and launched for real, along with some other things in parallel.
For bitcoinj, the way I think we'll go for now is just standardising some local API bits. It's too early to come up with a client->server protocol standard: we need to wait for things to settle down and best practices to be established. Current bitcoinj plan:
https://groups.google.com/forum/#!topic/bitcoinj/Uxl-z40OLuQ
https://groups.google.com/forum/#!topic/bitcoinj/Uxl-z40OLuQ
Hi Mike,
Thanks for the link to those design notes. I see your point and agree that it makes more sense to provide a plugin interface for oracles and leave the wire protocols to be bespoke until the whole space matures.
One thing that I didn't understand from your document was this line:
Quote
In an ideal world, BIP 70 would be more widely adopted by now and P2SH would not be required or useful.
How does BIP 70 prevent the need for multisig addresses? My understanding was that BIP 70 operates at a higher level on top of the blockchain, by simplifying the workflows involving payments and address management. But we would still need P2SH multisig scripts in order to provide blockchain-level security involving risk analysis services / oracles.
I am interested in building a RA service as you call it, so would be keen to know when bitcoinj has this implemented. Even if you had just a basic sketch of the plugin API so that I know what type of calls would need to be implemented, that would be great for me to get started on trying to build something.
Thanks.
For bitcoinj, the way I think we'll go for now is just standardising some local API bits. It's too early to come up with a client->server protocol standard: we need to wait for things to settle down and best practices to be established. Current bitcoinj plan:
https://groups.google.com/forum/#!topic/bitcoinj/Uxl-z40OLuQ
https://groups.google.com/forum/#!topic/bitcoinj/Uxl-z40OLuQ
Hi,
Has there been any discussion/effort around planning for a standard interface for wallets to integrate with multisig oracles?
There's a company building their own API who have also developed an integration for Electrum and Brainwallet, but I don't think this is using any form of standard API.
https://cryptocorp.co/technology.htm
https://cryptocorp.co/api/
I think it's going to be super important to have this functionality in wallets, *especially* ones on your phone. I can think of so many good use cases but I won't get into them here. I just hope that rather than having bespoke point-to-point integrations between certain wallets and oracles, we could instead have a standardised API so that a wallet user could browse a list of oracles and choose which one they want to use.
Also I would be interested in working on an open source oracle server implementation.
Has there been any discussion/effort around planning for a standard interface for wallets to integrate with multisig oracles?
There's a company building their own API who have also developed an integration for Electrum and Brainwallet, but I don't think this is using any form of standard API.
https://cryptocorp.co/technology.htm
https://cryptocorp.co/api/
I think it's going to be super important to have this functionality in wallets, *especially* ones on your phone. I can think of so many good use cases but I won't get into them here. I just hope that rather than having bespoke point-to-point integrations between certain wallets and oracles, we could instead have a standardised API so that a wallet user could browse a list of oracles and choose which one they want to use.
Also I would be interested in working on an open source oracle server implementation.
Jump to: