Two things:

(1) When referring to blockchain.info please use .info.  "The blockchain" is the heart of the decentralized bitcoin network, and is completely different than blockchain.info which is a centralized service that helps people like you access data in the blockchain.

(2) The string you've highlighted in red is Base64 used to pass data in a URL.  Any two-character sequences preceded by a "%" is an "escape" character that otherwise would muck up your URL.  In this case, %3D is actually an equals-sign "=".    It's usually the end of the base64 string that explains how much padding to use.  Anywhere you see the %3D is simply a way to pass equals signs in a URL without actually confusing any other URL interpreters that otherwise use equals signs for other things.

If those characters are being stripped, you might just have to try it with 0, 1 or 2 equals signs, and then decode the base64.  I believe there is only ever 0, 1 or 2, depending on how many bytes of padding are on the end of the string.  If you use the wrong number, you either error out (unlikely) or just get the wrong answer (more likely).  But one of them will work.

THANK YOU!

I have been receiving substantial donations recently, but donors frequently don't identify themselves, so I have no one to thank!  In recent past I have gotten quite a a few 0.2-1.0 donations, and been taking my fiancée out to nice dinners with it .  I have been meaning to broadcast a thank-you post, then this donation from yesterday reminded me to do it!


People in this community are quite generous, and I'm thrilled to see people are impressed enough with Armory to make such substantial donations!  It means a lot to me.

So thank you!
-Alan


P.S - If you want to identify yourself to me--publicly or privately--I'll be happy to send you a T-shirt and Armory-branded USB key.  This goes for anyone donating the equiv of $50 or more.  I have only a few T-shirts left from the original crowdfunding a year ago, all black, L or XL (and maybe an XXL).  >= $20 gets a USB key (I'd do it for less, but these branded USB keys are surprisingly expensive when you don't order 10,000 of them!).

If you look at the code, I do have a condition that warns about compressed keys... but I guess the "This number is too big" warning somehow takes precedence.  So I had thought about it... I guess I just didn't do a good job

https://github.com/etotheipi/BitcoinArmory/blob/master/qtdialogs.py#L2427

Ah yes.  Armory doesn't support compressed keys, yet.  They were going to be supported with the new wallet format, but that got put on hold for obvious reasons.  Once RAM-reduction is done, maybe I'll finally be able to finish that.

Until then, Armory can't handle compressed keys.  At all.

For reference on the synchronization question, I will reference one of my previous posts.  It was a thought-experiment to figure out how to download the Reiner-tree between nodes, given that the download will take a while and you'll get branch snapshots at different block heights:

https://bitcointalk.org/index.php?topic=88208.msg1408410#msg1408410

I just wanted to make sure it wasn't something to be concerned about (like all sorts of hidden complexity).  It looks like it's workable.

Gah.  This is familiar.  I think jl2012 had a similar problem at one point.  The issue had to do with Bitcoin-Qt being detected, but failure to successfully open a connection.  It had turned out to be a problem with a timeout parameter. 

It's also possible that there's a problem with the blockfile location...change anything recently?

There's issues with the way Armory currently works, and I'm looking forward to leaving those all behind with the next major update.  Instead of "Pick RAM or pick HDD", the first release will use a lot of RAM while I implement the easiest way storing all the data, but the next update should have a semi-pruned version that saves both RAM and HDD space.  Basically, because high-volume-low-access data makes up most of the bulk, and needed so infrequently, I can choose not to store most of it, and retrieve it (inefficiently) when occasionally necessary.  But that's more of an optimization of the current high-HDD-storage design.  I'm going to get that one out first and get it stable before optimizing it.

I don't have any real understanding of SCIP, but I did talk to the guys behind it, at the conference.  They are very excited about their research, and it clearly is quite powerful if it works.  However, they did say that it is extremely complicated,  and even if it does work, it may have a tough time getting confidence from any security-conscious community due to its complexity.   I imagine it will need years of fielding in order for it to actually become an option for any important application.

And of course, I have my doubts that it really works.  It sounds too good to be true, but admittedly, I haven't had time to try to understand it at the technical level yet.   One day I'll try to find some time to dig into it.  But until then, we certainly can't count on it being available for the Reiner-tree.

I'd be extremely interested to see someone with the correct background dig into it and provide a technical overview of how it works.

Make sure you are using the latest 64-bit version of the software available at the downloads page.  If not, make sure you uninstall the old version first, before installing the new version.  Your wallets are safe through an uninstall-reinstall cycle.

I'm working on the "persistent blockchain" stuff that will resolve all these issues.  I have been completely consumed by other important things, so this has been slower than I expected.  But it's top of my priority list, for when I do eventually get enough development time to do it.

There's a couple ways that this can be done, but they won't ever be as pleasant as it is with your bank account:  when a withdrawal is made from you bank account, it doesn't matter which $X is taken, as long as $X is available.  Bitcoin is a bit different, in that you must select which BTC to spend, and then you sign the transaction with the coin selection as part of it.  This kind of removes one possibility, which is pre-signing transactions.

That's not to say that pre-signing transactions won't work, but you'd have to "lock" those funds in your wallet and not touch them.  With a bank account, you could have a monthly recurring payment of $1,000, and it doesn't matter if you have $200 at some point, as long as you get back to $1,000 by the time the withdrawal is made.  It won't work that way in  Bitcoin.

And just for completeness, I should mention that the fact that each transaction requires your authorization is one of the primary reason to use Bitcoin!  No one else has control over it except you.  This is why people have credit cards stolen when a merchant's database is compromised, because you're trusting them to secure your CC number, which gives someone access to the credit behind the card.  When you pay with Bitcoin, there is no way for the merchant to "do another pull."  You have to initiate it, and they get no information that can compromise your funds.  With extra security comes extra responsibility...

As such, there's a few ways to do what you are requesting.  But all of them require you to pre-allocate all the funds ahead of time, and not touch them.  If you needed to use those funds with the intention of replacing them, the app would warn you that you will invalidate your pre-signed payments.   Maybe it won't be a big deal with a decent interface... but it doesn't change the fact that you will break the auto payment and have to recreate it when the funds are available again.  And if you are receiving monthly payments to your wallet, you obviously can't pre-sign payments from coins you haven't received yet...

So if you have enough laying around to allocate, you can:

(1) Just "lock" the coins in your wallet, and pre-sign 12 transactions of X BTC each.  Your system will automatically broadcast one per month.
(2) You put the money into escrow -- a 2-of-2 tx between you and the merchant.  This is more of a deposit-like system though, where you are required to prove ahead of time that the funds are available, and the funds may be returned to you later, but you can't just take it back unless they provide you a signature.  Your app would pre-sign 12 transactions, which would only be one of two signatures needed for the tx to be valid.  Once per month your system sends it to their server, they add the second signature, and you're done.
(2a) You use Rapidly Adjusted (Micro)Payments which does the same as the 2-of-2 transaction above, but reduces the necessity to actually broadcast each transaction.  The entire 12 payments will be bundled into 2 transactions (one at the beginning, and one at "settlement").

There's options, but they're probably not exactly what people want.  If you're going to run your wallet yourself, anything you try to do to get exactly what you are seeking, will likely negate many benefits of Bitcoin that we value.

Have you seen this?

https://bitcoinarmory.com/using-offline-wallets-in-armory/

Sorry CanadianGuy,

I'm super overwhelmed with things, I think I will have time to return to being more responsive soon.   My apologies. 

It sounds like there is a bug.  Perhaps someone who has this problem, who isn't so concerned about the privacy, could make a watching-only copy of their wallet for me, so that I could catch the select-coins bug in a debugger.  This would help me find the problem, because I've never actually had this happen to me before.

For now, you might consider moving the coins in a couple transactions, perhaps 0.5 BTC each.  I don't know if there's a specific input that is a problem, or if it's just the overall size (in kB) of the resulting tx.    You'll pay a few extra cents in tx fees, but at least you'll get access to those coins...

You're right, it doesn't show your balance offline.  But it doesn't need to know your balance.  You only need that to create the transaction, which is done from the online computer.  Once the transaction is created (and a bunch of other verification data is bundled with it), the offline computer has everything it needs to know to determine "This wallet is sending X BTC to address Y with fee Z."  Then it allows you to sign it.

That's all the offline computer does:  lets you confirm the transaction details, and sign it. 

You can think of it like writing a checking that requires the signature of someone locked in a vault.  The person in the vault doesn't know how much money is in the bank account because they have no access.  But the check isn't valid without their signature.  So you go into the vault and they say "This check is sending X BTC to addr Y, is this what you intended?".  You approve, they sign it, and then you leave the vault and take the check to the bank (broadcast to the network). 

I've seen this a couple times.  It does not prove that someone owns a particular public key:  it proves that the owner of the particular public key approves of the message that was signed.  It's similar to [the intention of] a regular hand-written signature -- you don't sign blank sheets of paper to prove who you are, but you do sign sheets of paper that identify something you agree with.

Hah, you just jumped all the way to the other side.  I was actually just suggesting that if we're not going to do anything fancy with the scripts, we should use the exact script as the key instead of its hash.  That way we don't have to store the script itself in the key and value of the leaf node (even though actually only the hash160(rawscript) would be in the key).

If we're going to use "essentially" raw script, we'll save quite a bit of space by making it the key of the tree, then we don't have to store the actual script at the leaf nodes.  I am blanking on all the other data that needs to be stored, but it might be considerable savings (I haven't thought about this in a while).   Well, it would save exactly 20 bytes per leaf.  Right now I think there are 6 million UTXOs, so that would be 120 MB of savings.   

The constant keysize would be important in a trie, but in a level-compressed PATRICIA-like tree, it shouldnt' make a difference. 

Okay, I was proposing a change to the way the UTXO tree was keyed, for the purposes of having a consistent way to look up balances/UTXOs for hash160 values instead of raw scripts.  You are proposing we keep it keyed/indexed by raw script, but the nodes can store their own meta data for those addresses as they see recognizable scripts.   It would not be a requirement to serve the entirety of all UTXOs spendable by someone with the private key of a given hash160, but it can still be useful. 

Is that a correct interpretation of what you're saying?

My problem with that is that it isn't determinisitc whether you will be able to find all your coins.  Maybe it doesn't matter:  "Use standard scripts if you want to be able to find all your coins efficiently.  Otherwise, you're on your own."  With the way you suggest it:  if you get lucky, nodes have the data pre-indexed for you, and have all of it.  But you can't count on it and they can't prove whether they supplied you everything.  This makes it considerably less useful, and possibly not useful (nodes need to be able to know if they have everything, or they'll do something else that guarantees it).

I think ultimately the raw script indexing is the correct answer.  I'm just exploring alternatives, that make the multi-script-single-address problem a little more efficient (and reliable).

I created "armoryd" which is included, but it's extremely minimal.  I was waiting for some of the stability issues to go away before expanding it any more.  But it will run for multiple days at a time before crashing, so it may still be useful for some low-importance activities   (the crashing is an artifact of the way it tracks the blk*.dat files, which is going away with the upcoming update).

I removed it because it's no longer a testing release!  It's now available on the BitcoinArmory download page.

It doesn't work for everyone.  But if it does work for you, it seems to be flawless.  Otherwise it won't even start.  Good luck!

There's two problems with this logic:
(1) Every request is X-fold more work for the serving peer just to catch the 0.01% of addresses that have multiple forms in the blockchain.  It has to do multiple lookups for each request.
(2) Something like "<message> OP_DROP ..." is a serious problem for this proposal.  The task of "find all UTXOs to address/pubkey X, which have a message prefixed to it" requires a full search of the UTXO space.   Such scripts lose all benefit of this proposal.  In fact, any node using these kinds of scripts will have to use the original full-node-but-pruned logic, unless the extraneous data is totally deterministic/predictable.

Number 2 is concerning, because even if nodes somehow know all the messages they are expecting to see, the proofs of existence (or non-existence) are on isolated branches and require quite a bit more data to prove than if they were all clustered on one branch.   And if they don't know what the messages (or other data unrelated to addr/pubkey), then the peer might be expected to do the UTXO search.  They might end up adding extra metadata to their database just to accommodate these kinds of requests. 

On the other hand, since address re-use is a bad idea, maybe the argument about isolated branches are irrelevant. 

I have an idea that is beyond infeasible, but it's good food for thought.  Maybe it's useless, but what the hell:

For a given script, if it contains a single public key or single hash160 value (how do we define this?), then we use the hash160 value or compute it (from the public key) and prefix that to the script, replacing the value actually in script with a 0xff byte (or something unused).  This is okay technically (if it were possible to identify what values will be used as pubkeys/hash160s), because it's technically not a requirement for the lookup key to match the script.  The real script will still be stored at the leaf node.   So "DUP HASH160 <addr160> EQUALVERIFY CHECKSIG" would be keyed:  "<addr160> DUP HASH160 0xFF EQUALVERIFY CHECKSIG". 

This theoretically solves all the problems at once, because it doesn't really matter what else is in the script, as long as the "controlling address" is first.  Then it's trivial to prove inclusion or exclusion of data for a given address.    But of course, it's probably intractible to figure out how to reduce arbitrary scripts to "controlling addresses."