I guess I'll repeat what Carlton said:

I was trying to present the XT point of view on the fee market, to which I deduce you adhere (if I did a good job at describing it). I was not expressing my point of view.

Core does not know of the public keys at all. Only Armory is aware of those. The same works vice versa. If you sent those coins to an address generated through BitcoinQt, Armory would not be aware of it. Armory and Core wallets are completely separate entities.

Your coins are here, rest assured. The particular issue your log file is exposing is that Armory believes the blockchain has stopped around block 270XXX, which is like 2 years ago or something. So obviously, it never got to see the blocks from 2015, thus any transaction from that period.

Sorry, you have to build from source right now.

At this point you are better off doing a Rebuild and Rescan.

I'm aware of all these issues and they all been thoroughly fixed in 0.94

No, I speak for myself in all these matters. Etotheipi sets the technical stance for Armory. I've been a bitcointalk member since before Armory even existed, I believe that is sufficient a distinction to signify that my position is personal and does not reflect what Armory as a business believes is the better route.

If this proposal gets enough discussion and refinement, I may implement it myself to speed up the BIP number processing. Historically, Armory has been pretty neutral in consensus discussions, so I do not believe it makes us a big player in this particular field or that my voice as an Armory employee carries more than any other poster in D&DT.

If I believed I had some authority in this matter, I would just go ahead and implement my own proposal.

Nodes cannot orphan blocks, only other miners can. The average node connection is therefor irrelevant.

Large miners do not stand at a significant risk to be orphaned by smaller miners, only the other way around is true. This creates a situation where a few large pools can agree not to orphan each other (and there already are examples of large pools signing on mutual agreements) and they can easily vampirize the smaller pools market share.

The reality is that without limits on the current system, connectivity will become a barrier to entry to the mining market. By nature, barriers to entry are agents of centralization. The stance of the Core team and supporting members of the technical community is that the network needs first be more efficient before it is scaled up. Otherwise, effectively removing the block size limit is akin to amplifying an analog stream with a poor SNR. The only thing you will achieve is to drown the valid signal in noise.

This argument has been laid out several times by people much more versed on the networking layer of Bitcoin than I am. If you want to engage in a discussion with me on this matter, I would appreciate that you do not ignore this criticism to large blocks. Currently, your insistence on the idea that miners will limit themselves because of orphans instead of using it as an edge to predate on their competitors indicates otherwise.

I would also like to remind you that this isn't the topic of this thread. We are here to discuss the underlying fundamentals of XT, essentially the "why XT", not so much the "how". Gavin made it clear in XT, the end all and be all of the "how" is Moore's law.

So now, to get back on topic, your answer does not refute my presentation of XT's stance on the fee market:


Indeed, say I am wrong and miners will softcap block size to limit orphans. In your best scenario, in which your analyze is right, you perceive the fee market as nothing more than the consequence of a technical limitation, not a feature. The fact that there may or may not be a fee market in XT will not be by design but an unwanted consequence of hardware limitation. Therefor, it wouldn't surprise me to see solutions implemented in XT to entirely get rid of the fee market, like implementing LN, which you are proposing.

On the front page of BitcoinXT's website:


There is no such intention to maintain a fee market in XT. Hearn wants to replace miner subsidy with some sort of mining insurance contract (that I have not looked at). Maybe someone familiar with the proposal can pitch in.

What is clear is that XT supporters believe any transaction is worthy of the blockchain and that fee competition is detrimental to the network. They only see fees as serving the purpose of mining subsidy so it is expected their proposals to replace the fee market will only cover this aspect, as the filtering and competition in the transaction market are concepts they are fundamentally opposed to.

Simply put, they don't want a transaction market, they only want the validation layer.


The set of lead developers and their leadership philosophies. The idea is not to only change leaders but to change direction altogether. Hearn puts it quite clearly in his XT FAQ:

I would insist on implementing a decay function for the sake of spam control and to prevent gaming the system.

I will repeat my point: the status quo path, where the current size is maintained if no increase/decrease is triggered is damaging in that it becomes trivial to maintain a size increase after a spam attack or in case a miner wants to game the system. At the same time a decrease becomes quasi impossible with the current thresholds.

An increase should be triggered at 66~75% capacity, not ~50%, and the fees should be at least 20% superior to the cumulated subsidy of the previous period. This is critical as it forces an attacker to compound his effort to inflict several unnatural increase on the network instead of simply giving the network a nudge and maintaining the increase trivially.

The goal of this proposal is to automatically adapt the max block size to the demand, not to offer a voting mechanism where spammers and large miners alike can pump up the block size and keep it there at minimal cost. If this is what you are aiming for, then Garzik's approach makes more sense.

In order to dynamically resize the block ceiling, the algorithm needs to distinguish between spam/attacks and organic growth. The simplest way to one from the other is that spam is acute, organic growth is chronic (or long lasting if you prefer). This means natural growth will always eventually trigger an increase, which is why tighter thresholds make sense. Natural growth will always manage to get to a sane threshold, but the higher the threshold, the more expensive it is to game the system.

However, in case the attacker is willing to pay the price for an upscaling, the effect of that attack should fade once the attack is over, which why we should have a decay function instead of a status quo condition. Only organic growth will be powerful enough to maintain a ceiling increase. With proper thresholds, an attacker would have to keep on spending more fees and increasing the difficultly significantly to keep the ceiling on growing, which is the only way he'd have to force in a lasting effect. At this point he is better off just mining for profit as a sane market actor, which is what a PoW blockchain relies on to begin with: there is more profit in participating to the network than to attack it.

--satoshi-datadir is used to point to the /blocks folder (holding the raw blockchain data), not the binary folder.

All your posts are complaining about default features, which is what auto bitcoind management is meant for. If you learn how to use Armory you can easily come up with a very specific setup suiting your needs. But do not expect the default one size fit all setting to accommodate that.

For Armory to go online, it needs a local instance of Core. If auto bitcoind is failing, you will have to Start BitcoinQt manually prior to starting Armory every time. It is critical that BitcoinQt is fully sync'd before you start Armory, so if you have not run Core in a few days, let it catch up before you start Armory.


Log files please


Probably something to do with your /blocks or binary path (the ones in File -> Settings). It is either getting mangled or it's invalid (non ASCII chars?). Auto bitcoind is a feature for default setups, i.e. you didn't customize your system and installation at all. If you intent to customize (like you did), I strongly suggest against using auto bitcoind.

Sorry I do not know how to use Core for that purpose. You would have to ask on http://bitcoin.stackexchange.com or on IRC. Worst case scenario, there should be some Python tools on github that would do the conversion for you.


The problems are tied together. The old wallets do not support compressed private keys nor unicode characters. We can't allow for internationalization until we come out with the new wallets, because any non ascii text input in the current wallet format has a high chance of corrupting the file.

Not the private keys starting by L nor the public keys starting by 02 or 03. There will be support in later versions. That code is 95% done but it doesn't have a version target yet. There ought to be a way for Core to export uncompressed private keys.

Btw, I don't know why you want to import a private key into Armory but keep in mind that it isn't recommended.

That's a compressed private key. Armory doesn't handle those yet, use the 32 byte private key instead (64 hex characters).

From your log file, it appears bitcoind is crashing when Armory is trying to start it. I guess it probably has something to do with permissions on the folder holding the binary (exec permission probably). That or the blockchain folder Armory passes as an argument is getting mangled somehow.

For now, turn off auto bitcoind management. To do so, start Armory, go to File -> Settings and uncheck the first checkbox (you should also to a Help -> Rebuild and Rescan for the good measure). Close Armory, start BitcoinQt manually, then start Armory again, it should pick up from there.

Did the private key start with L?

Why not? My understanding of pruned blocks is that they keep all UTXOs with the necessary intermediary hashes to compute the merkle root. What pruned blocks get rid of is transaction history, unspent coins scripts are still all there.

Should work now