bccapi like support on the standard daemon?

[nelisky]

I hope this wasn't covered before, couldn't find any references (but didn't look too hard)...

BitcoinSpinner is a great mobile client, but the real magic happens underneath, in the BCCAPI server that has the blockchain and the pub keys, but no priv keys. It can then prepare transactions but the client, holding the priv key, needs to sign and resubmit to the server so it can then push the signed transaction to the network.

This has many advantages for web services, such as removing the need to either have a separate bitcoind with a full blockchain for each service or share a daemon/blockchain but also the risk of holding all coins together. Also makes upgrading the server much easier, and allows the private key security to be handled by the web app coder instead of the sysadmin holding the bitcoind instance(s). I *really* like this, but I don't like running alternative bitcoin daemons for web services, especially when I can't easily review the critical code or trust that a lot of other people has done so already.

What would it take to allow for this workflow on top of the bitcoind RPC mechanism? All the getbalance is there, we'd need afaict:
- add public keys / addresses
- request a transaction blob
- document (create examples in whatever languages) how to properly verify the transaction blob actually matches what the client requested from the server
- document (as above) how to properly sign the transaction
- submit signed transaction back to server

With this not only would open bitcoin servers be possible for alternate clients (even the standard one?) thus removing a lot of the initial pain for new users (less bloat, much lower initial bootstrap time) but more importantly would make the web service designer life much, much simpler.

Can it be done? Has it been done while I wasn't looking?

[1713867873]

1713867873

[1713867873]

1713867873

[1713867873]

1713867873

[slush]

I don't think this is functionality which should be covered by official client. I feel that official client is already pretty monolithic software which is trying to solve "everything".

However, I'm working on the project which (as I believe) can fulfill your requirements: stratum.bitcoin.cz. Generally it's the protocol (similar to BCCAPI, but I think a little more abstract) + server implementation, which can be run by independent entity (on your computer or as hosted solution).

[nelisky]

I would argue that this kind of functionality is *exactly* what the default client should do, and less of the UI handling which is better left for the UIs

But I'll have a look at stratum, thanks for the pointer!

[weex]

I wish all my bitcoind's had bccapi.

[Mike Hearn]

The client has to trust the server for a BCCAPI type solution. So putting it into bitcoind doesn't make a whole lot of sense given that you have to index the entire chain for it to work (currently bitcoin does NOT do this). It'd just end up being a special mode that hardly anyone uses - might as well keep it as separate software.

Anyway, you can get the performance benefits of the BCCAPI type approach with some protocol extensions useful for mobile/lightweight clients anyway, but without the same privacy issues (you'd be able to use the standard p2p network).

[weex]

The client has to trust the server for a BCCAPI type solution. So putting it into bitcoind doesn't make a whole lot of sense given that you have to index the entire chain for it to work (currently bitcoin does NOT do this). It'd just end up being a special mode that hardly anyone uses - might as well keep it as separate software.

Anyway, you can get the performance benefits of the BCCAPI type approach with some protocol extensions useful for mobile/lightweight clients anyway, but without the same privacy issues (you'd be able to use the standard p2p network).

I'm interested to know what form those protocol extensions would take. How would one start the process of designing said extensions? This is relevant to this recent thread about a potential oncoming rush of tablets preloaded with some Bitcoin software: https://bitcointalk.org/index.php?topic=80531.0

[ThomasV]

I'm interested to know what form those protocol extensions would take.

see https://bitcoinconsultancy.com/wiki/Stratum

[Mike Hearn]

Stratum isn't exactly what I was referring to.

Before Stratum there was a discussion between Gavin, Jeff and myself some time last year. I don't remember exactly when. We talked about protocol extensions useful for SPV / lightweight clients.

It boiled down to letting clients set filters on P2P connections, probably using bloom filters or perhaps some kind of prefix matching on script data elements. Requesting blocks would then cause the remote node to send the header and transactions+merkle branches which matched the given filters.

It's not a complicated extension to the current protocol and is essentially about saving bandwidth. The client would still be expected to manage its local block chain, understand re-orgs, etc. Implementation wise the advantage is the nodes don't have to have any new chain indexes. They'd simply load a block, filter out non-matching transactions and return the rest of the data. It's a natural extension to filter broadcast transactions too.

The protocol wouldn't have any specific knowledge of addresses. You need to be able to select exotic types of transactions that are used in contracts, so a more general design where you do arbitrary filtering on in/out scripts is appropriate. If doing something like bloom filters you can make them more or less specific to select your preferred point on the bandwidth/privacy spectrum. Specify a very tight filter and you give away more about your addresses but have minimal wasted bandwidth. Specify a loose filter and the other end doesn't really know which addresses are yours. Select 10 random peers, use 10 filters and you can have strong deniability whilst remaining efficient enough for phones.

These types of proposals all boil down to similar ideas.