You might try formatting the USB key to FAT32.  Or NTFS.  Or just any reformat.  Sometimes, the way the key is formatted causes seemingly-artificial restrictions on I/O.  I've seen it on Linux a dozen times.  Doesn't surprise me Windows would see the same thing.

Change addresses are just part of the regular chain of addresses in your wallet.  If you have 100 addresses in your keypool and generate 100 new receiving addresses, the following address (in Bitcoin-Qt) will no longer be valid.  If you are sending lots of transactions, each one that requires sending change will eat up another address in your key pool.

This is one reason to use a client with a deterministic wallet like Armory.  There is no keypool.  The seed derives every address that has ever been used and will ever be used.  Change addresses are just pulled as the next address in this infinite chain that are all saved on your print-once paper backup.

Deterministic wallets are coming to other clients.  But Armory and Electrum already use them.  And even so, you should never have to worry about change.  Ever.  Unless you're manually constructing transactions yourself, in which case it's very easy to shoot yourself in the foot.  Established Bitcoin clients have this covered, and mostly transparently.

For reference, when talking about "off-chain transactions" are we talking about Rapidly-adjust (micro)payments?  I would guess so, but just making sure.

Sure, off-chain transactions can replace a lot of the bulk of the blockchain, but there will still clearly be more than 7 tps between previously-unrelated parties if Bitcoin is going to scale to the levels it needs to.  Not to mention, that the RA(M)P referenced above does require two transactions per pair of parties, and needs to be renewed at some regular interval. 

This isn't about microtransactions.  It's about a currency system that is supposed to be global, but can only handle 6 tx/sec.  That's just not enough, even if we somehow limit all transactions to 250B and >10 BTC.

There's no question that blocksize should be limited.  The question is whether 1 MB was the correct answer.  I think the answer is a resounding "no."  Bitcoin can't do what it was supposed to do at 1MB.  All other properties of the system can be maintained with a higher blocksize limit, but Bitcoin can't grow with the current one.

I was a little conflicted on this topic.  I see the "elegance" of just using raw scripts.  But I didn't like the idea that multiple forms of the same "effective" address required separate lookups.  For instance, the same address can be used in the "DUP HASH160 <Addr160> EQUAL CHECKSIG" as well as "<PubKey> CHECKSIG".  And maybe "<message> DROP <pubKey> CHECKSIG".  Or "<message> DROP DUP HASH <Addr160> EQUAL CHECKSIG".  In fact, I don't even have a good way to go search for those message scripts unless I know the message in advance.  It would require a good old-fashioned full-UTXO-set-search, which was something we were hoping to avoid with this whole discussion.

But it's also not feasible to capture all script types that are single-sig spendable.  Adding new "standard" script type representations to the UTXO tree later will require a hard-fork.  Perhaps this is a reason not to have things like "<message> OP_DROP", or it's a reason to be more intelligent about how we represent scripts in this tree.  This is why I was conflicted...

The problem is that there is nothing stopping the miners from taking the solution that you just submitted in a sigscript, and putting it their own transaction to themselves (and dropping yours).  In fact, any of your peers could replace the TxOut to themselves before forwarding to other peers/miners.   It's because there's no signature field that locks the TxOuts (of the redeeming script) into the sigscript. 

You'd have to mine it yourself, so the first time anyone sees it is after it's already in a block.  Better hope it's not orphaned!

I hate the current incarnation of message signing.  This is why I put out a bounty to get a module implemented in Armory that is backwards compatible with the current Bitcoin-Qt signing (v0), but then expands it (v1) with RFC2440-like formatting, both a clearsign and a base64-encoded version.  The idea was that if I implement it in Armory and try to follow an existing standard, the others might follow:

https://bitcointalk.org/index.php?topic=179422.0

So jackjack got the bounty, and it looks like his solution does exactly what was requested.  I just have to integrate it into Armory and then brag about it.  Then maybe the other apps will do it.  For sure, you should never have to type/copy multiple fields, and what you do end up with should spit out a single window that says "The following message has a valid signature from address X: <...>".  And not show the message if it's not a valid signature. 

It's not intended to do that.  I stupidly tested the OSD Keyboard with passwords that didn't have numbers, so I missed that.  This was reported a few weeks ago and I updated it in my major dev branch, but it still may be a couple weeks before it's merged (along with a ton of other changes).

You might just have to wait for the next update when I fix the RAM issues.  I'm a little caught up in some paperwork, but I'm going to try to at least get a beta version out that will work for moving money from an offline computer, without need any special RAM req'ts on the online computer.

Stay tuned!

Because of the incompatibility with Bitcoin-Qt (and thus, lack of usefulness), I haven't really maintained that interface at all.  I was waiting for the message signing bounty, and then I was going to redo the whole interface.

Glad it's working!

I wouldn't hold your breath about message signing, unless it's Armory-to-Armory.  I will eventually merge jackjack's message signing (from a bounty) into Armory... but it's not there yet

There's some documentation on it on the Armory website.

The intention is not to carry anything around.  Offline Armory is your little Bitcoin vault sitting at home.  You use it for storing the bulk of your coins.  You keep a much smaller percentage in hot wallets (online computer, Android, etc).  You can refill those hot wallets using a USB key to shuttle the transaction signature between offline and online computer, without the offline computer ever touching the internet.

It's a text editor for programming that has a pretty steep learning curve.  It's terribly confusing if you don't know how to use it, but becoming proficient at it means that you can code for hours at much higher efficiency, without your fingers ever leaving the keyboard (mouse not required).

I've been using it for years, and at least partially attribute my success in developing Armory to it.  For me, it's like converting brainwaves directly in code modifications


P.S. - Maybe this helps out a frustrated newbie:  one of my biggest gripes with VIM that almost made me give up on it when I was learning, was the seemingly asanine decisiion to use the "ESC" key to exit insert mode, since it forces your left hand to leave the home keys, all the time.  I later found out that you can use Ctrl-[ to exit insert mode, and that was what I needed to be happy.  If you hated because of the escape key, give it another shot now

I'm actually curious about this myself, having no real experience with ASICs (or much HW, at all). 

I would expect that a implementation of scrypt with static parameters would be possible to implement on an ASIC.  I don't know how Litecoin works, but couldn't it be made so that the parameters are floating?  i.e. The compute time and RAM amount would change as more or less power entered the network, or at least as a function of time.  Perhaps, an ASIC could be made to handle up to 256 MB of RAM, to accommodate future growth, but it wouldn't last forever like the current proof-of-work does.

I just sent my pledge of 3 BTC: 

http://blockchain.info/tx/445d905e56c08456b0423faa77118f6c3307d629a08e7f09ea75050328b3bd3d

I assume you can trust the owner of the transaction, because I made sure it came from my own donation address.  I hope that is sufficient identity for you (you can match the address to the one on my homepage:  https://bitcoinarmory.com/).

For reference.  I'm donating money to Bram Molenar.  His work has made my life 100x easier.  It's up to him to do with the money whatever he wants.  If he wants to donate the money to a charity in Africa, that's his decision.  Having made that decision publicly may change people's inclination to donate (knowing the money will ultimately go to whereever he designated), but it doesn't change my decision. 

I assume you're using the latest version?  That was a problem in version 0.87 that was fixed in 0.87.2 and higher.

If it's happening in the latest version... please send me a log file.

I actually don't know what would cause that.  It always goes by the timestamp on the block, which we know can't be more than 2 hours off.  So 2 days would have to be... either a clock issue, or maybe somehow Armory glitched and was getting the wrong value out of "RightNow()"...?


Even if it's unconfirmed, it shouldn't be showing the wrong value like that.  Can you just check the "Transaction Details" and verify which inputs and outputs it thinks are part of your wallet?

Interesting.

First of all, if it says the block is 2 days old, the only way I can see that is if your clock is 2 days fast.    You're right, it's definitely at the latest block.  But having your clock off would interfere with a few things that Armory does.

Second of all, can you double click that strange transaction and you'll see why it thinks it was +0.00000010 BTC instead of the correct amount.  Specifically, it should show you all the inputs and outputs, and then label which ones are part of your wallet.  

I know it can be pain to restart, but I've seen something like what you are showing after a reorg, and I know there was just one in the last few hours.  Have you restarted Armory since then?

If I understand (remember) correctly, Socrates1024 is making the point that someone could theoretically do mining without having the full blockchain.  All they need is the root hash of the last block, and to see the full blocks coming in.  This is because you can verify that the UTXOs being spent by the new transactions are unspent with a simple branch request from a peer.

Right now, if you wanted to do this... you can't.  You can easily prove that a UTXO once existed, but you don't know it was spent since then without downloading all the blocks since then and verifying no spends.  But with this UTXO tree structure, you can prove both inclusion and exclusion of UTXOs on any given block.  It may not be that big of a distinction today, but perhaps in the future when you require TB of storage, that could make a difference. 

But I do question how much is gained -- since only some upper limits ratio of the network could operate like this without being extremely burdensome on the actual full nodes.  And I'm not confident that these lite nodes could expect reliable branch information from each other even if they all "agreed" to hold, say, 1% of the full thing.  I certainly wouldn't want to risk my miner becoming idle because it's having trouble finding some subset of the tree (or large subsets of the network going dark for that reason)

Have I understood this properly?

---

One thing that has come up before, is that I'd like to see an additional piece of information added to the header:  fast-forward data each block.  sipa has already implemented undo data because you need it in the event of a reorg, and I tried to convince him he might as well include fast-forward data, because you save some 75% bandwidth on transmission of block data (to those that request it).  If the OutPoints-removed-and-TxOuts-added data is organized into a merkle tree, then that root could be included in the merkle tree, and such UTXO-only nodes would be able to avoid pulling whole blocks.  sipa didn't like the complexity for a "constant" factor, but I think 75% is worthy constant factor.  Unless I'm missing something...