Open ztnark opened 7 years ago
Yeah, I've actually seen this sporadically in local development too. Given our pretty direct usage of ecdsa
, I wonder if it's a problem there? The extent of what we do with the key bytes is a file(..., 'wb').write()
, so I'm not sure where things could be going awry.
At any rate, the easy workaround is to restart the containers which causes new wallet generation (as you've probably figured out). Would like to get to the bottom of this, though.
Unable to reproduce locally, so I'm betting this has something to do with container -> host issues.
In [6]: def check_key():
...: with open('/tmp/foo', 'wb') as f:
...: f.write(ecdsa.SigningKey.generate(curve=ecdsa.SECP256k1).to_string())
...: with open('/tmp/foo', 'rb') as f:
...: assert len(f.read()) == 32
...:
...:
In [7]: for i in range(10000):
...: check_key()
...:
...:
We could probably use binascii
to encode/decode the on-disk private key to avoid this.
i have the same issue running on osx. renaming wallet1.dat and wallet2.dat and restarting the containers doesn't seem to help. it generates new wallets but spits out the same assert error.
We could use
docker cp Node2ID:/wallet.dat ./wallet2.dat
to replace
docker-compose exec node2 cat wallet.dat > wallet2.dat
This error may be caused by docker.
Just like this: vim ./bin/sync_wallets
#!/bin/bash
docker-compose exec node1 cat wallet.dat > wallet1.dat
echo "Synced node1's wallet:"
./client.py balance --wallet wallet1.dat
echo
node2id=$(docker ps | grep 'node2' | awk '{print $1}')
docker cp ${node2id}:/wallet.dat ./wallet2.dat
echo "Synced node2's wallet:"
./client.py balance --wallet wallet2.dat
I get the following error after running:
./bin/sync_wallets