@kuzetsa: it depends on what you mean by private key. As the wallet is encrypted beforehand and pywallet doesn't ask for the passphrase, what it strips out are encrypted private keys, which are totally meaningless. If you meant something like "it can read my private keys" then it's wrong (that's what I thought you meant the first time). If you were only describing the process and actually meant encrypted private keys then it's right.
@Dabs: yes it's the same trick, I didn't think about making a whole watching wallet at the time
@OP: pywallet with the feature is no more in beta
Topic: "watching wallet" workaround for bitcoind (requires pywallet beta) (Read 14335 times)
August 01, 2013, 01:12:26 AM
This has something to do with the feature I requested a few weeks (or a month) ago to import only the public key, without knowledge of the private key.
We then proceeded to pretend to be Satoshi, and for me to pretend to have a fat wallet with 3 million coins in it.
Those are obviously "watch-only" wallets. So you could do it one key at a time, or now, hundreds of keys. Good job!
We then proceeded to pretend to be Satoshi, and for me to pretend to have a fat wallet with 3 million coins in it.
Those are obviously "watch-only" wallets. So you could do it one key at a time, or now, hundreds of keys. Good job!
July 26, 2013, 05:38:02 AM
((...snip...))
... creates a copy which replaces the encrypted private keys with placeholders...
((...snip...))
... creates a copy which replaces the encrypted private keys with placeholders...
((...snip...))
^ That is just another way of describing what I was referring to when I said:
(self-quote) "... strip private keys out, and rebuild a new wallet..."
If by key you mean private key it's wrong, it doesn't require the passphrase nor knowing the private keys
Anyway, then yes you're wrong
@jackjack: not sure who you're addressing when you say "you're wrong"
The reference I made to "private keys" was talking about the keys which are used to sign and spend UXTOs associated with the wallet
... Based on what you said, somehow I think you thought I was referring to encrypted wallets (using passphrase or otherwise)
Nope. I wasn't referring to encrypted wallets. When I said "private keys" I meant like this:
Code:
5Kb8kLf9zgWQnogidDA76MzPL6TsZZY36hWXMssSzNydYXYB9KF
That is the private key associated with:
Code:
1CC3X2gu58d6wXUWMffpuzN9JAfTUWu4Kj
The watching wallet would not have (stripped out / replaced with placeholder) the private key, and so, couldn't spend any coins sent to 1CC3X2gu58d6wXUWMffpuzN9JAfTUWu4Kj...
July 20, 2013, 12:19:13 PM
Wow, you did write private key... I should really read all the words in a post better quoting it...
Anyway, then yes you're wrong
All you risk is having a useless clone file
Anyway, then yes you're wrong
All you risk is having a useless clone file
July 20, 2013, 11:24:33 AM
"This works and can be used in bitcoind ... but only after using pywallet
... to manipulate your data, strip private keys out, and rebuild a new wallet"
If by key you mean private key it's wrong, it doesn't require the passphrase nor knowing the private keys... to manipulate your data, strip private keys out, and rebuild a new wallet"
Good point. pywallet is well trusted and vetted but even so pywallet doesn't need or ask for the wallet passphrase. It simply creates a copy which replaces the encrypted private keys with placeholders and then changes the encryption key on the copy to prevent accidental unlocking as a precaution. It is making a reduced information copy, it doesn't modify the original ("spending") wallet.dat.
If you are particularly paranoid you could:
1) Make backup of your "spending wallet".
2) Make a throw away copy of the backup in #1.
3) Use pywallet to create a clone of the copy in #2.
4) Delete the copy in #2.
Either that or read the source code.
July 20, 2013, 05:25:49 AM
"This works and can be used in bitcoind ... but only after using pywallet
... to manipulate your data, strip private keys out, and rebuild a new wallet"
If by key you mean private key it's wrong, it doesn't require the passphrase nor knowing the private keys ... to manipulate your data, strip private keys out, and rebuild a new wallet"
July 20, 2013, 12:41:47 AM
Updated OP to use pywallet clone-watchonly option. I have not encountered any issues in testing however pywallet 2.1.0 is in beta and should not be used for production without further testing.
I was very excited when I saw this thread title
"watching wallet" workaround in bitcoind (now/ pywallet beta support)
When I saw the thread title, I jumped at the words:
- "...workaround in bitcoind..."
But I hadn't expected the meaning of:
- "...now/ pywallet beta support"
... to actually instead mean:
- "This works and can be used in bitcoind ... but only after using pywallet
... to manipulate your data, strip private keys out, and rebuild a new wallet"
I live the idea of having watching-only wallets in bitcoind
like...
some version which doesn't involve pywallet AT ALL
Thanks though.
Changed the title. I would like watching wallet in bitcoind without 3rd party tools as well. However that likely isn't going to happen anytime soon.
July 20, 2013, 12:30:15 AM
Updated OP to use pywallet clone-watchonly option. I have not encountered any issues in testing however pywallet 2.1.0 is in beta and should not be used for production without further testing.
I was very excited when I saw this thread title
"watching wallet" workaround in bitcoind (now/ pywallet beta support)
When I saw the thread title, I jumped at the words:
- "...workaround in bitcoind..."
But I hadn't expected the meaning of:
- "...now/ pywallet beta support"
... to actually instead mean:
- "This works and can be used in bitcoind ... but only after using pywallet
... to manipulate your data, strip private keys out, and rebuild a new wallet"
I live the idea of having watching-only wallets in bitcoind
like...
some version which doesn't involve pywallet AT ALL
Thanks though.
July 19, 2013, 09:28:55 PM
Updated OP to use pywallet clone-watchonly option. I have not encountered any issues in testing however pywallet 2.1.0 is in beta and should not be used for production without further testing.
July 19, 2013, 05:09:29 PM
Pywallet 2.1.0b2 should be working: http://pastebin.com/raw.php?i=2FtQDj3v
Please some of you try
Please some of you try
Code:
python pywallet_2.1.0b2.py --clone_watchonly_from /home/jackjack/wallet.dat --clone_watchonly_to /home/jackjack/wallet2.dat
It "worked" for me. The clone had no issues and when I did an encrypted dump of the cloned wallet everything looked correct. Will do some more testing over the weekend but this should help a lot.
July 19, 2013, 03:00:50 PM
Pywallet 2.1.0b2 should be working: http://pastebin.com/raw.php?i=2FtQDj3v
Please some of you try
Please some of you try
Code:
python pywallet_2.1.0b2.py --clone_watchonly_from /home/jackjack/wallet.dat --clone_watchonly_to /home/jackjack/wallet2.dat
July 19, 2013, 11:36:05 AM
I'll put this feature in pywallet. I'm happy if anyone wants to tip me but I'll do this without any bounty.
I think I can implement it in the public realease within 1-2 weeks. I have to implement the encrypted wallets recovery first.
I'll test the concept sooner though.
I think I can implement it in the public realease within 1-2 weeks. I have to implement the encrypted wallets recovery first.
I'll test the concept sooner though.
Thanks JackJack, pywallet is an awesome tool. Having a read-only wallet conversion option in pywallet is a good fit.
I will still work on a "watching wallet" conversion tool for my own use. If nothing else it will be some interesting development.
July 19, 2013, 05:23:32 AM
I'll put this feature in pywallet. I'm happy if anyone wants to tip me but I'll do this without any bounty.
I think I can implement it in the public realease within 1-2 weeks. I have to implement the encrypted wallets recovery first.
I'll test the concept sooner though.
I think I can implement it in the public realease within 1-2 weeks. I have to implement the encrypted wallets recovery first.
I'll test the concept sooner though.
July 19, 2013, 01:09:29 AM
Is it correct that bitcoind will always exhaust the keypool and not refill it under any circumstances when it has an encrypted and locked wallet?
Is is correct that bitcoind will always return an error when requesting a new address when the keypool is exhausted and can't be refilled?
Is is correct that bitcoind will always return an error when requesting a new address when the keypool is exhausted and can't be refilled?
Yes and yes. My little game FlipSide has had some downtime (HTTP 500 errors) because new keys were being used (because of people simply browing the site) and the wallet was kept locked (people didn't bet or win—no need to unlock it) so I eventually run out of keys in the pool.
July 18, 2013, 07:12:02 PM
It looks like pywallet has an option to import a watching address. The public key is entered into the wallet and as a placeholder the encrypted private key is just random data.
Based on that it should be fairly straight forward to have an option where given an existing wallet.dat it will update the wallet.dat to a "watching wallet" by replacing all private keys with random data. Optionally to prevent accidentally unlocking (which may confuse the crap out of bitcoind) the passphrase could at the same time be changed to a random value as well.
https://github.com/jackjack-jj/pywallet/blob/master/pywallet.py#L4176
I have sent jackjack a PM to clarify is this is possible and the possibility of setting up a bounty.
Based on that it should be fairly straight forward to have an option where given an existing wallet.dat it will update the wallet.dat to a "watching wallet" by replacing all private keys with random data. Optionally to prevent accidentally unlocking (which may confuse the crap out of bitcoind) the passphrase could at the same time be changed to a random value as well.
Quote
def render_GET(self, request):
global addrtype
try:
pub=request.args['pub'][0]
try:
wdir=request.args['dir'][0]
wname=request.args['name'][0]
label=request.args['label'][0]
db_env = create_env(wdir)
db = open_wallet(db_env, wname, writable=True)
update_wallet(db, 'ckey', { 'public_key' : pub.decode('hex'), 'encrypted_private_key' : random_string(96).decode('hex') })
update_wallet(db, 'name', { 'hash' : public_key_to_bc_address(pub.decode('hex')), 'name' : "Read-only: "+label })
db.close()
return "Read-only address "+public_key_to_bc_address(pub.decode('hex'))+" imported"
except:
return "Read-only address "+public_key_to_bc_address(pub.decode('hex'))+" not imported"
global addrtype
try:
pub=request.args['pub'][0]
try:
wdir=request.args['dir'][0]
wname=request.args['name'][0]
label=request.args['label'][0]
db_env = create_env(wdir)
db = open_wallet(db_env, wname, writable=True)
update_wallet(db, 'ckey', { 'public_key' : pub.decode('hex'), 'encrypted_private_key' : random_string(96).decode('hex') })
update_wallet(db, 'name', { 'hash' : public_key_to_bc_address(pub.decode('hex')), 'name' : "Read-only: "+label })
db.close()
return "Read-only address "+public_key_to_bc_address(pub.decode('hex'))+" imported"
except:
return "Read-only address "+public_key_to_bc_address(pub.decode('hex'))+" not imported"
https://github.com/jackjack-jj/pywallet/blob/master/pywallet.py#L4176
I have sent jackjack a PM to clarify is this is possible and the possibility of setting up a bounty.
July 18, 2013, 04:16:27 PM
It would be more elegant (and also safer) to literally erase (overwrite with random data) the private keys, instead of encrypting them with the "unbreakable" password.
Maybe jackjack could add such an option to his so useful pywallet tool.
Maybe jackjack could add such an option to his so useful pywallet tool.
Agreed. That would be a useful option "overwrite private keys". If the overwritten wallet is ever unlocked it will cause issues but if the wallet remains locked the private keys are inaccessible and bitcoind doesn't know they are overwritten or missing.
An even better solution would be to create and use a watching wallet in bitcoind itself. The core devs seem reluctant to make changes/improvements to the wallet since it will be made obsolete by deterministic wallets however it would be a useful option. The wallet header could contain a flag to indicate it is a watching wallet only and only contains public keys. To avoid significant code the fact that there are no private keys could be hidden by simply encrypting the wallet (not necessary for a security standpoint but would make all private key functions inaccessible to the wallet without a lot of refactoring).
Quote
The watching wallet cannot create new keys, but the spending wallet can, so in theory you still need to repeat the process once for awhile.
Though in practice, if you told it to used -keypool of thousands, it should take you awhile to consume it all.
Though in practice, if you told it to used -keypool of thousands, it should take you awhile to consume it all.
Agreed we have already used 5,000 key keypools in the past. That should be fine for most use cases.
July 18, 2013, 04:06:14 PM
Your logic seems solid, but I do not see any question in the OP.
Of course bitcoind will not fill the key pool if you don't unlock the wallet - that's kind of obvious.
Unless you have just found a critical bug, but the theory is that it cannot even if it wanted to.
Of course bitcoind will not fill the key pool if you don't unlock the wallet - that's kind of obvious.
Unless you have just found a critical bug, but the theory is that it cannot even if it wanted to.
Sorry I had it phrased as a sentence.
Is it correct that bitcoind will always exhaust the keypool and not refill it under any circumstances when it has an encrypted and locked wallet?
Is is correct that bitcoind will always return an error when requesting a new address when the keypool is exhausted and can't be refilled?
Essentially the security (against lost) of funds depend on those two conditions always being true.
July 18, 2013, 11:22:03 AM
Your logic seems solid, but I do not see any question in the OP.
Of course bitcoind will not fill the key pool if you don't unlock the wallet - that's kind of obvious.
Unless you have just found a critical bug, but the theory is that it cannot even if it wanted to.
Of course bitcoind will not fill the key pool if you don't unlock the wallet - that's kind of obvious.
Unless you have just found a critical bug, but the theory is that it cannot even if it wanted to.
July 18, 2013, 10:47:03 AM
Well since we have covered everything except the question in the OP I am going to assume there is no flaw in the work around logic.
July 18, 2013, 07:22:56 AM
It's just writing code and it doesn't seem so much of work.
/me looking forward to reviewing your patch.
replacing a call to secret.MakeNewKey(fCompressed) with secret.DetermineNewKey(fCompressed, lastKey) would be a very simple hack...
if not for the fact, that getting the lastKey value seems extremely complex, if not impossible, with the current architecture.
so sorry, I ought to take it back; it's not a simple hack. not in this code.
but I see that its getting changed as we speak - good!
Jump to: