Oh yeah, I actually started doing that in a VM a month ago and totally forgot.  I probably don't even have it anymore.  I'll take another shot at it...  That would certainly make the release process easier, to not have to outsource the compiling to a separate physical device.

You could make one pretty easily out of armoryengine (obviously what Armory is based on).  It scans and indexes the blockchain and allows for arbitrary header and tx-lookup.  Within a python script, you can traverse the entire blockchain in any way you want to (though you'd want to use the lower-level C++ stuff if you want to do full blockchain scans in less than an 30 min).  There's a bunch of examples of it in the extras/sample_armory_code.py in the github project.  I know znort had done something similar.

At one point, I had created a block explorer with an ancient version of armoryengine, but there's no way that works anymore.  It would require more work upgrading it probably, than just making your own wrapper around armoryengine that serves your purposes. 

No idea if that's what you're looking for.  But it's out there.

Your "wallet" is "you", and your "addresses" are "one-time payment codes" to pay "you".  These one-time payment codes could be reused to go to the same person, but it's really bad practice unless they explicitly request it

gmaxwell pointed out the obvious flaw in this proposal:  you can supply the input branches to prove that the TxOuts that you are spending exist, but you can't supply the destination branches.  Otherwise, full nodes have no idea how to update the sub-branches of the target address.  Even if they know that this is the first UTXO for that address, there may be lots of other branches on the way down to that node which are unknown to it.

There's not a way around this, other than just having full nodes store the entire trees.  Which means we're back to square one

Ack, that's quite a long compile time!  I didn't realize that it couldn't be compiled in the available RPi RAM.  You have A or B pi?   I guess I'll download the Raspbian image and take a shot at it... in a little bit.  At the moment, I gotta focus on some other development activities. 

For the unlocking, there's not much you can do about it.  Armory does a bunch of verification checks when unlocking to make sure there's no corruption.  Although it takes a while, it's saved my bacon in a couple instances (and for other users) when it did actually find something was corrupted.  This will prevent you from using a corrupted wallet and potentially using addresses that were based on a faulty chain calculation. The downside is that there's a lot of EC-multiply operations being performed when you unlock, which does take a while, especially on slower HW.

I suppose you could run with a much smaller keypool on the offline computer, since it doesn't need any lookahead  (because it's not looking anywhere for transactions).  That would speed up unlocking in the short-term.

grau, I think the part you are missing is that there is a "convention" tied in with BIP 32.  You could do arbitrary things with BIP 32, and use key gaps of 1,000,000 keys, or use arbitrary 32-byte strings for your child indices, or go deeper than three levels.

But a "standard" implementation of BIP 32 will not do that.  BIP 32 specifies a set of tools that let you do all these arbitrarily complex things, but also describes a convention that avoids the problems you are talking about.  Don't skip wallets, don't use arbitrary 32-byte IDs, don't go past level 3.  If you violate any of these things, you won't be compatible with other implementations of BIP 32, and you'll be forced to address all the problems you are bringing up.  

Look at BIP 32 as a flexible, extensible language for addresses tress and also a prescription for using that is generally accepted.  By generally accepted, I mean that if you follow this prescription, you should be able to import your root private key into Armory, Bitcoin-Qt, Electrum, Multibit, etc, and it will work.  

EDIT: But the simplicity and flexibility of the design allows for us to expand into more complicated things, later, or for devs to do their own "proprietary" deviation of this prescription, and not have to come up with a whole new deterministic wallet algorithm (if they don't mind being incompatible with other apps). 

Fwhew!  The issues are slowly fading away...

Still problems that need to be cleaned up, but at least the problems people are having have workarounds. 

Working on the RAM-reduced, instant-startup upgrades now.  The new design will actually remove direct dependence on the blk*.dat files entirely!  There's just been way too many problems with it.  I'll simply retrieve and process data directly from Bitcoin-Qt/bitcoind as a peer using regular getdata/getheaders/getblocks requests and maintain my own database.  And that database will start out duplicating everything, but I am doing it in such a way that it will gracefully support various subsets of that data, like pruned blockchain, lite-node, address-indexed, etc.  This way, users will have the capability to run using remote [trusted!] bitcoind instances, and use as much RAM as they desire.

Might be some time before I iron all of it out, though...

Good to know about the CPU "model name".  Oh well.  I really don't need it, I just need to add a default value for that completely informational-not-functional piece of code...

I didn't realize there was a new release of Crypto++ recently.  I will look into it.  There was a bug in the old version that I had to manually fix, but it was so long ago, I don't remember what it was.  I may have to do some git-blaming to figure it out.

Honestly, I was hoping to just eventually release an offline bundle for the RPi.  But I'm not sure if I can support that at this time.  I finally have an RPi, but I haven't really had time to set it up.  Maybe someone could help me figure out what is needed for the offline bundle...?  (and a good way to set it up, like what image to install, etc)

I see what's going on.  It fails to set the CpuStr variable because platform.processor() is empty.  I forgot to set a default value.  I guess that will be fixed in the next release. 

The installation directory is completely separate from your home directory.  All your wallets and settings will be untouched through a software upgrade.  It's like that by design. The two never mix.

Armory gets installed to:   C:\Program Files (x86)\Armory
Armory home directory:    C:\Users\<username>\AppData\Roaming\Armory

Thanks for that.   Just for myself, I copied it below, adding sub tags for subscripts, and bolding EC points (but not scalars)

As currently in BIP32 you would still have I=HMAC-SHA512(Key=c_par, Data=K_par || i)
And then:

k_i=k_par+I_L
K_i=K_par+G*I_L
c_i=I_R


Pieter: what's the difference between what you just posted and what iddo posted?

Also, aren't timing attacks supposed to already be "covered" if you are using a vetted implementation?  I'm not opposed to making it easier to implement, but I thought that was part of the reason to use, say, OpenSSL, because they already diligently covered a bunch of these side-channel concerns.

On the RPi, when you run python, what is the return value of "import platform; print platform.system(), platform.processor()" ?

It looks like a completely unnecessary piece of code is causing the problem, though it looks to me that it should work if ".system()" returns "Linux" as I expect.  Either way, that problem can be solved by finding the line:


Just add a single line before it, saying "raise".  That will cause it to error out and set default/unknown for all those member variables.   If the RPi registers as a different OS than the ones I look for already, that would be good to know!

Can someone precisely specify the additive variant of the CKD function?  I'm fairly certain I know, but I don't want to end up missing a detail and evaluating something else.

By the way, there is a problem with downloads. I had accidentally mixed the architectures.  I reuploaded them last night.   If you had problems, try downloading again.  It should be correct now.

When did you download it?  I updated the offline bundles last night space because I mixed up the architectures.

Yeah, that's GPG being pedantic.  It doesn't truly trust a signature unless the GPG key has been explicitly set as "Fully Trusted", or it is signed by another GPG key that is "Fully Trusted."  It's trying to encourage the whole Web-of-Trust thing, where everyone signs everyone else's keys to help prevent man-in-the-middle attacks.  But the web-of-trust thing never hit critical mass.  Though in small community's like ours, maybe the major developers should make some effort to do this...

Okay, I guess need to update those instructions.  "Detached signatures" would look like this:

     armory_win32.msi
     armory_win32.msi.sig


Then your command-line would work, because the .sig file explicitly contains the signature of only the .msi file.

But I didn't make a detached signature.  I simply hashed all the installers, listed them in the .asc file, and signed that file.  Here's what the file looks like:


So, there's two steps to verification:
(1) Execute "sha256sum armory_0.88.1-beta_win32.msi" from the command line.  Compare it to the contents of the .asc file, make sure it matches
(2) Verify the signature of the .asc file:  "gpg -v armory_0.88.1-beta_sha256sum.txt.asc"


Note: for your question about the debian package, I highlighted the important part of your post.  You successfully verified the .deb signature.  This is useful for just downloading the .deb and verifying it before you install it.  But in the case of the offline bundle, I don't sign all the packages because I only created one of them.  Instead, you should follow the procedure I just explained for the .msi files, but for the appropriate tar.gz file.

I bring this up, because as long as we've committed ourself to a [potential] hardfork in the next month, I think the following should be seriously considered.  Why?  Because "cold storage" is becoming a major force in the Bitcoin world.  More and more people and companies are looking at the benefits and trying to get it setup.  More people are finding themselves wealthy and want to protect it.  It is the holy grail of wallet security (multi-sig, too, but that will probably include offline wallets, instead of replacing it).    But implementation suffers from one extraordinary hurdle.


Example:

Let's say I want to create a $10 offline signing device.  I will put 32 kB of RAM and a small screen and a tiny embedded chip that is just powerful enough for ECDSA signing.   It will sign transactions for me after asking me to physically confirm with a button press.  But the device has so little RAM, it can't support arbitrary transactions.  So, I'll just make sure my online computer software never produces transactions bigger than 10 kB, and just do multiple transactions if necessary.  In Armory, I'll happily make that a configurable parameter.

But there's a serious problem here:  this isn't possible (and the Trezor ran into this).  Because of a tiny little oversight by Satoshi, nothing about the 10kB transaction indicates what the transaction fee is.  Without access to the blockchain, my tiny little device doesn't know whether it's signing 1 BTC input, or 1000 BTC input.  To accommodate this, you must supply all supporting transactions along with the one to be signed (and BIP 10 does this).  By doing this, the offline device can hash the supporting transaction, verify it matches the TxIn it is signing, and then record the 8-byte amount/value from that transaction.   It's a lot of work to verify those 8 bytes...

Worse, I don't have control over this.  I can choose never to create transactions bigger than X kB, and pick X based on my HW.  But if my wallet contains a UTXO that comes from a 100 kB transaction, I have to upload 100 kB to my offline device, just to verify those 8 bytes.  This forces devices like the Trezor, to implement streaming calculations, complicating the protocol 10-fold.  

If you don't do this, an attacker compromising the online computer could trick your offline computer into signing away your entire wallet to transaction fee.  While it's not the most direct way for the attacker to make money, it's the most direct way to ruin you by sending your life savings to some lucky miner (and they may have a way to benefit from it, like owning some mining power).

EDIT: I shouldn't focus entirely on the signing hardware.  Another major problem is bandwidth:  there's a lot of good ways to transfer a few kB securely between an online and offline computer, but not on the order of megabytes.  QR codes are such a method that I keep shooting down, because I have no idea how to make it work with MB of data.


Raw Technical Solution:

All this because Satoshi made one little oversight in the OP_CHECKSIG procedure:  the TxOut script is copied into the input being signed, but not the value.  If the value was copied prepended to the TxOut script, then the offline system only needs to be given the 8 bytes, and it could securely present the correct fee to the user and sign it.  If an attacker compromises the online computer and puts incorrect values into there to trick the offline computer, the offline signature will be invalid (because full nodes verifying the transaction will use the correct value the signature won't match).  

So the technical solution is simple:  Add a new SIGHASH type, which I dub SIGHASH_WITHINPUTVALUE.  This would have hashcode 0x10.  This would be OR'd with the existing hash types.  i.e. Currently all "regular" transactions are signed with (SIGHASH_ALL), now anyone who wants the benefit would sign with (SIGHASH_ALL | SIGHASH_WITHINPUTVALUE).  It is compatible with the existing hash types.

Analogy:
Right Now:  "I, the offline computer, sign this input to be sent to this address, no matter how much this input is worth"
Proposal:  "I, the offline computer, have been told this input is worth 13.28 BTC.  This signature is only valid if that's how much it's actually worth"


Considerations:

This solution has some nice properties:

• Simple!  For the signing and verification procedures, it's probably only a few lines of code.
• I have full control over data sizes to be exchanged with the offline device, down to the minimum of being able to sign a one-input-one-output transaction.  Currently, there's no way to avoid having to deal with 100kB-200kB of transaction data transfer (and if you want to be able to sign multi-input tx, you need to be able to handle megabytes)
• Also makes it resistent to changes at the network level: we plan to allow only 100 kB transactions right now.  So without this new SIGHASH, I design my device to handle up to 100kB.  But in two years, the limit is raised and people start mining 1 MB transactions, and I find that one of my inputs was from a 1 MB transaction.  Hardware upgrade?  Remember, the offline wallet needs to handle 100.0% of all transactions!  
  
• No problems with backwards compatibility:  Once the change goes into effect, new devices can be made and wallet software updated, to only use the new SIGHASH type.  It can be used even on wallets that already contain coins... because it only changes what is being signed.
• Should be completely non-controversial (technically):  this adds an optional restriction to transaction validity.  It doesn't change overall network topology or philosophy at all.  It's like asking the network to confirm, for the signer, that they were given the right value when signing.  That's all.

Downsides:

• Hardfork (of course).  But we've committed ourselves to a hard-fork next month, anyway.  And the extra hashtype would simply be "present" next month, but not become usable for 6-12 months, to allow time for upgrades.  I think this change has the right combination of simplicity and benefit to be worth throwing in
• Other clients would break if they're not paying attention and they are in the habit of verifying their own transactions.  Oblivious nodes would still be able to sign transactions, just not verify them.  Not so important for nodes that already trust the network to verify validity of transactions, but I'm sure things would break.

Anyone who has worked on offline wallets knows what a PITA it is to have to deal with supporting transactions.  Most of the ideas proposed in the Improving Offline Tx thread, were shot down because the solution needs to support multi-megabyte transfers.  This solution would eliminate that necessity.

Just to clarify:  tries/patricia trees/de la brandais trees do not have balancing issues.  They are all tightly bounded to a maximum number of operations to do queries, inserts, deletes.  It's just that the optimizations of PATRICIA/Brandais bring you far below that constant upperbound.  Thus, "unbalancing" simply removes optimization, but you're still operating well within the confines of constant time, no matter what the tree structure looks like.  

The distinction only matters if there was reason to believe that those optimizations are necessary to make this idea feasible.  I do not believe that is the case, here.   In terms of access times, I believe even a regular-old trie (forcing full traversal of each path) would still work. 

That's a super interesting idea.  I'll have to sleep on that one.

Right now, everyone tracks everyone's coins, and you are responsible for maintaining your own private keys.  In your system, you are maintaining your own private keys and the subtree information about the coins contained within.   Nodes don't have to keep that information, because they only need it when the coins are being spent, and you are the only who ever spends the coins.  

Sure part of the UTXO set could be "lost" if your computer crashes, but those coins are lost, too, so it doesn't really matter...?  If the coins will never be spent, the sub-tree never changes, and so nodes don't care what's inside that subtree, as they have its fingerprint.   I have not had time to think through the implications (or complications) of it, but it's a super-interesting thought-experiment.  


P.S. -- This is yet another area where the trie-based structures win -- since there is branch independence in tries, peers don't have to store what's below a certain node as long what's below it is not changing (they only need the fingerprint of that node after the last update to it).  If you use a BST, this doesn't work, because updates in neighboring branches can cause rebalances, forcing you to know what's in this branch so that nodes can be shuffled between branches.