BitCoinJ already implements lightweight mode, which works on for Android smart phones. It can (and will) go even lighter in future. Right now you need about 12-15mb of disk storage, which is much better than a regular client but still a bit much for smartphones - people accept it for games but not wallets.
Currently it has to download full blocks, but it then throws away their bodies after scanning them. So it's bandwidth but not CPU or disk intensive.
Topic: Constructing transactions without access to the block-chain (Read 1021 times)
synchronization doesn't mean storing the whole blockchain... just occasionally connecting to some peers and downloading new blockdata and only keeping what's relevant
How hard is it to implement downloading of only relevant info in the protocol? Also, sorry for my ignorance but is it impossible to validate without downloading complete blocks, and all of them since the last known good block hash? If it is indeed impossible, is it too naive to trust a consensus of random peers (since there is nothing to be gained from providing false data)?
Regarding clumsy users, I now imagine a very basic wallet card, which only has a display that shows the amount to be payed and an OK button (maybe not even that). It only interacts with a cashout machine it is physically connected to, just like a credit card. It has only one address, and the change goes back to the same address. A sync can be initiated by the cashout machine just before the payment if we can assume that there isn't a good motive to provide false information at that point. Regardless, the user is always certain that only the amount displayed has been spent.
At the moment transactions can be created just given the intended recipient's address and knowledge of the details of unspent TxOuts for which one is able to satisfy the scriptPubKey. Your client can create the transaction and you could potentially print it out and send it in a letter.
Could be useful in cases where only the recipient has full access to the blockchain and network, like POS situations. The buyer needs access to neither the Internet nor the blockchain, which could make a very light handheld wallet possible. The wallet device needs only create the transaction, keep its own accounts and be able to undo a transaction when the user knows it's not actualized.
This is a great idea in concept, until you actually try using it. Your phone will have to occasionally synchronize with the network, because it needs to know if it received money/refill, and to know what transactions actually made it into the blockchain. Requiring the user to do the record keeping is a recipe for unusable software... the user always fails at this : forgets to click a button, clicks the wrong button, etc. If the phone has the wrong information, it will start trying to sign transactions with TxOuts that have already spent and you spend 10 minutes trying to figure out why 7-11 won't accept your transaction for a candy bar -- not to mention that you just created 10 new transactions while trying to figure it out, and now the your phone wallet is hosed. Or you phone tells you have no money because the you forgot to cancel a transaction that didn't actually go through, and now you can't remember which one it was. If you get it wrong, you end up with the other problem. Users are busy/clumsy/lazy and always breaks a system that requires any kind of regular maintenance/record-keeping.
On the other hand, most phones now (smartphones, at least) have internet access, so periodic synchronization isn't too bad. But I do believe that the ability to use BTC from your handheld device is critical to the future of BTC. Therefore, it's critical that BTC is usable without the entire blockchain. But I think periodic synchronization to find out the "truth" state of your wallet will be required. (EDIT: synchronization doesn't mean storing the whole blockchain... just occasionally connecting to some peers and downloading new blockdata and only keeping what's relevant)
At the moment transactions can be created just given the intended recipient's address and knowledge of the details of unspent TxOuts for which one is able to satisfy the scriptPubKey. Your client can create the transaction and you could potentially print it out and send it in a letter.
Could be useful in cases where only the recipient has full access to the blockchain and network, like POS situations. The buyer needs access to neither the Internet nor the blockchain, which could make a very light handheld wallet possible. The wallet device needs only create the transaction, keep its own accounts and be able to undo a transaction when the user knows it's not actualized.
I'm not really sure what context you're talking about. The "standard" use-case for Bitcoin is address-to-address transactions requiring the 20-byte hash of the public key of the recipient. This is what Satoshi referenced in his paper when talking about the future and lightweight clients. If you don't have at least this much information, you're not going to be using standard scripts to send money without the whole blockchain. If this isn't acceptable, you shouldn't be using something like FirstBits in the first place (which, btw, I don't know for sure, but I'm assuming it shortens a BTC address by only keeping the first X bits of the recip address)
If you want to go outside the box and use something else, you could make this work with non-standard transactions: I believe you could use OP_LSHIFT/OP_RSHIFT in the TxOut script if all you have is the first few bits (I'm pretty sure this works) -- i.e. create the script to check only the first X bits of the publickey hash match the data in the TxOut script . Something like
If you're asking about the necessity of future BTC protocols to support not holding the whole blockchain, I would argue that it is critical. Any degree of success in BTC will lead to blockchain files way too big for users' computers, and it's even currently too big now for smartphones--which are also critical to the BTC success. I think we'd be burning a huge bridge if we allowed "standard" to include any procedure requiring the entire blockchain to operate.
EDIT: I just notices OP_LSHIFT and OP_RSHIFT are disabled, so the above script wouldn't work
If you want to go outside the box and use something else, you could make this work with non-standard transactions: I believe you could use OP_LSHIFT/OP_RSHIFT in the TxOut script if all you have is the first few bits (I'm pretty sure this works) -- i.e. create the script to check only the first X bits of the publickey hash match the data in the TxOut script . Something like
Code:
OP_DUP
OP_HASH160
100
OP_LSHIFT
OP_EQUALVERIFY
OP_CHECKSIG
If you're asking about the necessity of future BTC protocols to support not holding the whole blockchain, I would argue that it is critical. Any degree of success in BTC will lead to blockchain files way too big for users' computers, and it's even currently too big now for smartphones--which are also critical to the BTC success. I think we'd be burning a huge bridge if we allowed "standard" to include any procedure requiring the entire blockchain to operate.
EDIT: I just notices OP_LSHIFT and OP_RSHIFT are disabled, so the above script wouldn't work
At the moment, everyone using Bitcoin runs a full-weight network connected client when creating transactions. We hope that this will not be the case in future. In particular it is anticipated that most people will only need to run lightweight clients which don't store the block chain.
I think it's worth agreeing what facilities must be made available in order to have certain functionality.
Firstly, I'd like to discuss creating transactions to new addresses.
At the moment transactions can be created just given the intended recipient's address and knowledge of the details of unspent TxOuts for which one is able to satisfy the scriptPubKey. Your client can create the transaction and you could potentially print it out and send it in a letter.
As an example of the contrary situation, if you just have a FirstBits address as the recipient's address then you no longer have enough information to create a safe transaction. You'd need to either scan the blockchain to work out the full address or (more likely) consult the FirstBits website
So the client doesn't need the block chain or any access to the network. Is the lack of dependence considered vital? How acceptable would it be for the default method of creating a transaction to a new address to require a successful query of the block chain?
ByteCoin
I think it's worth agreeing what facilities must be made available in order to have certain functionality.
Firstly, I'd like to discuss creating transactions to new addresses.
At the moment transactions can be created just given the intended recipient's address and knowledge of the details of unspent TxOuts for which one is able to satisfy the scriptPubKey. Your client can create the transaction and you could potentially print it out and send it in a letter.
As an example of the contrary situation, if you just have a FirstBits address as the recipient's address then you no longer have enough information to create a safe transaction. You'd need to either scan the blockchain to work out the full address or (more likely) consult the FirstBits website
So the client doesn't need the block chain or any access to the network. Is the lack of dependence considered vital? How acceptable would it be for the default method of creating a transaction to a new address to require a successful query of the block chain?
ByteCoin
Jump to: