Let me know if you know how to get the armory client started properly (not in offline mode).
If it has something to do with main/test network, let me know how to configure the Bitcoin client properly.
SRON
Are you running Bitcoin-Qt through a proxy or with any non-standard options? Is it's data directory in a non-standard location? |
|
|
|
Don't you have to login to respond to a message from localbitcoins? I always assumed that you could not respond to the link sent in the email unless you were actually logged in.
You can actually reply to the email notification itself, and your reply will be send to your contact and included in the conversation on the site. |
|
|
|
What about this: I generate a new address and it turns out it already has coins in it. Would sending those coins to another address be illegal?  What are the odds of the happening ?  Probably about the same as you generating a new address that happens to be the answer to the ultimate question of life, the universe, and everything. |
|
|
|
|
I can load the web site, but their bitcoin node(s) appear to be down, which means their wallet isn't working and they're not receiving new block or transaction data.
|
|
|
|
blockchain.info appears to not allow wallet logins at this time. I've tried from a couple different browsers and the iOS app. After clicking the "login now" button, it grinds away for a bit before returning to the originating page. Clearing the browser cache makes no difference.
The site looks to be partially down. At the bottom you can see this: I first noticed something was wrong because my client knew about 2 blocks that blockchain.info didn't... |
|
|
|
Another thing you could do is have Armory automatically create blockchain.info wallets in order to programmatically use the mixing feature. Creating wallets isn't necessary, as the mixer has an API. If you pass $anonymous=true and $receiving_address=$YOUR_ADDRESS, then the funds received to $input_address (returned by the API) are routed through the mixer to your address. Privacy is improved if outputs from different addresses are never combined as inputs to the same transaction. If the user wants to spend a sum larger than any address currently has Armory could warn the user and give him the option to route the transaction through the mixer, incurring a slight delay and fees.
You can also use the mixing feature to help with dust collection in a way that doesn't compromise privacy. If any transaction will create a change output less than a configurable dust amount the change could be sent to an anonymous receiving address, and when the balance of the dust collection wallet reaches a useful amount it could be sent through the mixer back to the Armory wallet. I really don't think that this is a good feature for Armory to incorporate, for the reasons etotheipi mentioned. Instead, you could have two wallets, "clean" and "dirty". The clean wallet has a bunch of small, unconnected inputs. When you send a transaction, you do so from the clean wallet, selecting inputs with the coin control dialog. Instead of having change, you send whatever is left over to a new address in the dirty wallet. When you run out of funds in the clean wallet, you manually (or through the script I posted a while back) run the coins through the mixer, sending them back to the clean wallet in small chunks. |
|
|
|
However, 1GB of RAM is luxurious for offline Armory! Offline Armory probably would work on a system with 256 MB. It works perfectly. The original Pi model B only has 256 MB of memory, though the newer ones have 512. Wallet unlocking takes an order of magnitude more time, but that's to be expected on a low powered chip. |
|
|
|
There doesn't seem to be anything interesting in Armory's log (even with --debug), but when I first start it up I get these notifications in Bitcoin's debug.log... accepted connection 127.0.0.1:57797
accepted connection 127.0.0.1:57798
disconnecting node 127.0.0.1:57797
disconnecting node 127.0.0.1:57798
accepted connection 127.0.0.1:57799
disconnecting node 127.0.0.1:57799
accepted connection 127.0.0.1:57801
accepted connection 127.0.0.1:57802
disconnecting node 127.0.0.1:57802
disconnecting node 127.0.0.1:57801
|
|
|
|
Slush, I'm interested in looking at your BIP 0032 implementation. Is the source code somewhere publicly available?
Btw, I have a BIP 32 implementation in the "newwallet" branch of Armory. It's only the crypto part -- I haven't been able to integrate it into a new wallet format yet (and thus, not usable in Armory yet). But it includes the ChildKeyDeriv() source code, and a unit test for both HMAC-SHA512 and the ChildKeyDeriv(). The unit tests may not be entirely accurate, because I made them before sipa decided that all derivations should use compressed public keys. But the algorithm is otherwise 98% what is described in the BIP. Awesome. I was thinking of implementing BIP32 in BitcoinJ mostly as an exercise for myself but also because I have some use for it in mind. I'll take a look at the newwallet branch. |
|
|
|
|
Slush, I'm interested in looking at your BIP 0032 implementation. Is the source code somewhere publicly available?
|
|
|
|
Also not getting notified by email when ads are replied to.
Are you sure your email is properly configured? I get an email for every contact, and every message for that contact. I can also reply to the email to reply to the contact. |
|
|
|
Not sure if this has been mentioned already, but how do you leave a rating for someone who hasn't used the LocalBitcoins escrow? I just sent directly to a cash-in-hand buyer's address, but see no option for feedback, just a cancel deal button and send message box.
There is not currently a way to leave feedback without using escrow. |
|
|
|
That makes a lot of sense now. Sipa never told me about this because he assumed I watched for block messages on the network instead of watching the files. Oh well.
Why not listen for blocks on the network? |
|
|
|
What about this: I generate a new address and it turns out it already has coins in it. Would sending those coins to another address be illegal? What about this: I buy a new lock and it turns out the key opens the door to someone else's home. Would moving things from that house to mine be illegal? |
|
|
|
James has been really good about replying to me lately, and I'm happy to say that after the claims in process, there will be less than 100 Cognitive shares in limbo  I agree. Nefario seems to be refunding everyone and providing accurate lists. I do not think Nefario deserves the scammer tag. He got the scammer tag for selling shares in his company, and then not honoring the agreement he made with shareholders. Specifically, unilaterally ceasing operations of BitcoinGlobal without shareholder consent. Even if his "cleanest shutdown in the history of Bitcoin" eventually ekes through on the good side of scammer, it doesn't change his actions toward the shareholders. |
|
|
|
etotheipi, I think the "parseNewBlockData did not get enough data..." error is coming from this loop. while(bsb.streamPull())
{
while(bsb.reader().getSizeRemaining() > 8)
{
...
BinaryRefReader brr(bsb.reader().getCurrPtr(), nextBlkSize);
parseNewBlockData(brr, fnum-1, bsb.getFileByteLocation(), nextBlkSize);
blocksReadSoFar_++;
bytesReadSoFar_ += nextBlkSize;
bsb.reader().advance(nextBlkSize);
}
} I made this small change and it drastically reduces the output, my freshly imported wallet still shows the right balance, but I'm sure it's not a real fix, since it looks like there's a bunch of data left unread... if(!parseNewBlockData(brr, fnum-1, bsb.getFileByteLocation(), nextBlkSize))
{
cout << "Next block size: " << nextBlkSize << endl;
cout << "Buffer size remaining: " << bsb.reader().getSizeRemaining() << endl;
cout << "Reader size remaining: " << brr.getSizeRemaining() << endl;
break;
} And here's some sample output with that change: ***ERROR: parseNewBlockData did not get enough data...
***ERROR: parseNewBlockData did not get enough data...
Next block size: 0
Buffer size remaining: 2231
Reader size remaining: 0
***ERROR: parseNewBlockData did not get enough data...
***ERROR: parseNewBlockData did not get enough data...
Next block size: 0
Buffer size remaining: 3349
Reader size remaining: 0
Attempting to read blockchain from file: /home/bitcoin/.bitcoin/blocks/blk00001.dat
/home/bitcoin/.bitcoin/blocks/blk00001.dat is 128 MB
***ERROR: parseNewBlockData did not get enough data...
***ERROR: parseNewBlockData did not get enough data...
Next block size: 0
Buffer size remaining: 9362
Reader size remaining: 0
***ERROR: parseNewBlockData did not get enough data...
***ERROR: parseNewBlockData did not get enough data...
Next block size: 0
Buffer size remaining: 20808
Reader size remaining: 0
Attempting to read blockchain from file: /home/bitcoin/.bitcoin/blocks/blk00002.dat
/home/bitcoin/.bitcoin/blocks/blk00002.dat is 128 MB
***ERROR: parseNewBlockData did not get enough data...
***ERROR: parseNewBlockData did not get enough data...
Next block size: 0
Buffer size remaining: 16391
Reader size remaining: 0
***ERROR: parseNewBlockData did not get enough data...
***ERROR: parseNewBlockData did not get enough data...
Next block size: 0
Buffer size remaining: 28286
Reader size remaining: 0
Attempting to read blockchain from file: /home/bitcoin/.bitcoin/blocks/blk00003.dat
/home/bitcoin/.bitcoin/blocks/blk00003.dat is 128 MB
***ERROR: parseNewBlockData did not get enough data...
***ERROR: parseNewBlockData did not get enough data...
Next block size: 0
Buffer size remaining: 25310
Reader size remaining: 0
***ERROR: parseNewBlockData did not get enough data...
***ERROR: parseNewBlockData did not get enough data...
Next block size: 0
Buffer size remaining: 25309
Reader size remaining: 0
Attempting to read blockchain from file: /home/bitcoin/.bitcoin/blocks/blk00004.dat
/home/bitcoin/.bitcoin/blocks/blk00004.dat is 128 MB
***ERROR: parseNewBlockData did not get enough data...
***ERROR: parseNewBlockData did not get enough data...
Next block size: 0
Buffer size remaining: 3530
Reader size remaining: 0
***ERROR: parseNewBlockData did not get enough data...
***ERROR: parseNewBlockData did not get enough data...
Next block size: 0
Buffer size remaining: 6970
Reader size remaining: 0
Attempting to read blockchain from file: /home/bitcoin/.bitcoin/blocks/blk00005.dat
/home/bitcoin/.bitcoin/blocks/blk00005.dat is 128 MB
***ERROR: parseNewBlockData did not get enough data...
***ERROR: parseNewBlockData did not get enough data...
Next block size: 0
Buffer size remaining: 15835
Reader size remaining: 0
***ERROR: parseNewBlockData did not get enough data...
***ERROR: parseNewBlockData did not get enough data...
Next block size: 0
Buffer size remaining: 24656
Reader size remaining: 0
Attempting to read blockchain from file: /home/bitcoin/.bitcoin/blocks/blk00006.dat
/home/bitcoin/.bitcoin/blocks/blk00006.dat is 128 MB
***ERROR: parseNewBlockData did not get enough data...
***ERROR: parseNewBlockData did not get enough data...
Next block size: 0
Buffer size remaining: 27895
Reader size remaining: 0
***ERROR: parseNewBlockData did not get enough data...
***ERROR: parseNewBlockData did not get enough data...
Next block size: 0
Buffer size remaining: 29726
Reader size remaining: 0
Attempting to read blockchain from file: /home/bitcoin/.bitcoin/blocks/blk00007.dat
/home/bitcoin/.bitcoin/blocks/blk00007.dat is 128 MB
***ERROR: parseNewBlockData did not get enough data...
***ERROR: parseNewBlockData did not get enough data...
Next block size: 0
Buffer size remaining: 14370
Reader size remaining: 0
***ERROR: parseNewBlockData did not get enough data...
***ERROR: parseNewBlockData did not get enough data...
Next block size: 0
Buffer size remaining: 41116
Reader size remaining: 0
|
|
|
|
Ok, not to continue hijacking the threat, but I stayed up all night coding again and I vastly improved the serial communication. Now, Armory tries to listen on the serial device as soon as it's started (rather than only in the offline tx dialog), and it encapsulates its messages to and from the server with protocol buffers. This allowed me to expand the types of messages available (as well as add more robust handling). Currently, you can import a watching only copy of a wallet directly from the offline device. I plan on extending the "Create new wallet" dialog to allow something similar - initiate the creation of a new wallet on the offline device, and send the watching only copy back. Also needed is to make the connection off by default, and enabled in the advanced or expert options, as well as setting the serial device and baud rate. Also, I tested it on the Pi and a rate of 115200 works even better than 9600... Imagine that! I didn't run into any apparent slowness until trying to transfer a wallet over the wire... The diff now has quite a few more changes, but it's still surprising to me how little code it took. I'm really liking python, and etotheipi, your code base is a pleasure to work with! |
|
|
|
Does the watch-only copy derive a new seed that is only capable of generating public keys in the series? What's the process behind this?
That's exactly it. Here is the code that creates a watching-only fork of the wallet. Basically, the root key has a public and private portion. Given only the public portion, you can derive the subsequent public keys, but not the private keys, for the same reason that you can't derive a private key from a public one. |
|
|
|
Piggybacking off my other posts, here are the changes I made to the Pi: In /etc/inittab, change the line that looks like this 1:2345:respawn/bin/agetty ... to this 1:2345:respawn:/bin/login -f pi tty1 </dev/tty1 >/dev/tty1 2>&1 This will automatically log in as the pi user to the first tty device upon boot. Also, remove or comment out the line that looks like this T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100 That disables logging in over the serial port. In /boot/cmdline.txt, remove console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 from dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 This disables outputting boot and debug information over the serial port. Modify /etc/sudoers (with visudo) to include this line pi ALL=NOPASSWD: /sbin/poweroff This lets you you power off the pi without entering your sudo password. Finally, in /home/pi/.bashrc, add the following at the bottom python $armory_directory/offline_serial_server.py /dev/ttyAMA0 9600
sudo poweroff
Voila. Your Pi will now boot into the offline serial server, allowing you to communicate with it from Armory using the patch I posted at the top of the page. When you're finished, hit CTRL-C and the Pi will cleanly power down. |
|
|
|
|
Show Posts
