ArmoryDB.exe lingers in a couple of Windows 7 machine after exiting ArmoryQT per Windows Task Manager. I never had this behavior before 0.96.3. Must "End Process" manually. Otherwise, it hangs right after Wallet Consistency Check.
How long is "linger"? |
|
|
|
|
You should remove rpcuser from your .conf, it conflicts with the cookie file.
|
|
|
|
i hope i'm being clear.
Sorry no. |
|
|
|
|
Offline just means the binary is bundled with the dependencies required to setup up Armory on a fresh install of the target OS. The build does not change.
|
|
|
|
how do you deal with miner fees and change when claiming BCH?
let's say your wallet pre fork has ten UTXO's with 1BTC/BCH each. post fork, you perform a 1BTC tx to buy something and your wallet automatically pulls the miner fee from one of the other nine UTXO's and dumps the change into a new address. weeks later, you go to claim the BCH via Coin Control. how do you set this tx up using the blockchain truncating Trick?
You don't, that UTXO does not exist on the backtracked copy of the chain you have. will Armory actually dump it into the same change address created from the original BTC tx?
No there's no guarantee of that. If you use the same wallet file, you will get a fresh address every time, otherwise, who knows. You're doing it wrong with the fees. Go into coin control, pick the outputs you want to spend, then in the recipient frame, click "MAX". This will guarantee it will move all the coins it can to the target address without leaving anything for change. That's how you want to go about moving that stuff. |
|
|
|
Damn, you are on fire! :-)
Interesting, now I might connect armory-db and armory-qt directly via FCGI? I was under the impression this is not the suggested way, and to always have some ngnix or comparable in between?
Cheers,
Ente
This is a convenience change to let people connect within their LAN without the need of running a HTTP deamon. Makes the setup simpler basically. DO NOT use this to expose your DB to the WAN, that's a bad idea through and through. I still believe you should use the proper setup within your own LAN, i.e. DB locked on localhost -> nginx -> LAN -> clients, but at this point it's nitpicking, so there you go, easier setup options. |
|
|
|
|
There is no sorting feature atm.
|
|
|
|
|
Uncheck the parent section.
|
|
|
|
Binaries:https://github.com/goatpig/BitcoinArmory/releases/tag/v0.96.3.99Changelog:== Added ==
- SegWit lockbox creation.
- BCH lockbox spending.
- Coin selection will now limit itself to change outputs when spending to external addresses you've spent to in the past.
- You will receive a warning about privacy loss if coin selection fails to satisfy the previous condition.
- Added the following CLI args:
- Client side:
--force-enable-segwit: when paired with --offline, allows the creation of SegWit types recipient addresses.
--force-fcgi: forces the client to use FCGI socketing when connecting to a remote DB IP.
- Server side:
--listen-all: FCGI server will listen on :80 instead of 127.0.0.1:80
== Fixed ==
- Fixed ledger based fee bumping.
- Fixed RBF control dialog spawning.
- Fixed node sync progress bar.
- Fixed node status notification flicker during node sync.
- Fixed fragment ID generation mismatching the fragment on backup when restoring non deterministic fragments. This fix only
applies to fragments generated with versions 0.96.4 and later.
- When in offline mode, the default signer option will now pick the proper signer for SegWit transactions.
- Fixed --ram-usage control. --ram-usage=1 will no longer hang the DB during bootstrap scans.
- As a result, --ram-usage defaults to 50 no instead of 4.
== Minor ==
- You can now resize the Transaction Info dialog.
Notes:SegWit lockboxes use compressed keys as opposed to the legacy ones, therefor they are sensibly smaller while also being a whole lot cheaper. Users looking to try them out should test around on testnet first. Linux users that were having trouble with older CPUs, try the noasm .deb
|
|
|
|
how does one correlate block height with blockfile.dat?
Since headers first (Core 0.10), crap shoot. |
|
|
|
Looking in my bitcoin.conf I see I have a line "prune=550" will this cause problems?
I don't think the pruning is tanking your node, but it won't work with Armory anyways. |
|
|
|
... This piece of the puzzle is easy and already well-understood. I had assumed that btc1 was going to insist on it's forking-block being over 4MB in weight, a simple and elegant solution to the wipeout risk.... They couldn't possibly be stupid enough to not do that, could they?
No idea. How can I tell SINCE THERE'S NO TESTNET TO WORK AGAINST? I don't understand? If I have a pre-split UTXO, and I send it back to myself with their magic value in an OP_RETURN the transaction is not valid on the btc1 chain, and the resulting UTXO may be spent freely with no risk of replay, and can also be used to taint other UTXOs [At the expense of privacy]. Once the BTC transaction is confirmed, the same UTXO may be spent freely on btc1 with no risk as the UTXO is already spent on Bitcoin....
1) The OP_RETURN stuff makes the tx non standard, not invalid. In other words, nodes won't propagate it, but angry enough attackers can choose to mine them anyways. 2) With any form of opt-in tainting, the only sane path forward is sending coins back to yourself on both ends until you can verify your UTXO set divergence has confirmed on both sides of the split. Whether you do this with their convenience OP_RETURN method, or through RBF, LockTime, using coinbase transactions or whatever else you can think of, the end result is the same: You can only demonstrably prove your coins are tainted after you have confirmations of a divergent UTXO on both chains. Bitcoin transactions are final, replay attacks are a real threat! Therefor, there is no reasonable argument for simply trusting the opt-in protection when you can actually verify its effect. |
|
|
|
|
I've got it fixed, will be part of 0.96.4
|
|
|
|
Should Armory enforce the opt-in (if it gets added, which I suppose will happen at the last minute), and explicitly require users to opt out?
I'm not adding GUI elements to hand hold if that's what you're referring to. The opt-out is simple enough to use: send coins back to yourself until you're sure you have correctly tainted, regardless of the tainting method. If a users lack the patience to execute this, or the knowledge to understand what he is doing, he will need to take time to educate himself on the matter. I'll put out a guide as with BCH. What I could do, since 2x insists upon the lack of 2 way replay protection, could be to detect the fork by its fork point and issue a message box warning whenever someone is trying to spend a UTXO that predates the fork point. However, not knowing if 2x has wipeout protection, detection may get a whole lot harder than just hardcoding a header hash and checking against it. The two proposals I've seen are a magic OP_RETURN value [which is not supported by most wallets, but is supported by Armory], or an output to a magic P2SH address [Much more bloat, and it bloats the UTXO-set too], which can be done with any existing wallet.
Both are shit. The bare minimum requirements for a clean HF are (in descending order): 1) wipeout protection 2) 2-way mandatory replay protection 3) make testnet available about a year before the HF (you should FF then) 4) change script hash prefixes to reflect the new mainnet and testnet, and change network ports I don't even know if 2X is trying to get 1) right. As for the details, the second method is sensibly worst than the first since it naturally suggests a UTXO consolidation strategy that will result in a massive privacy leak. Fungibility be damned! Both methods fail anyways, since they do not provide a strong guarantee of replay protection to begin with. Therefor you are left with spending coins back to yourself until you get lots of confirmations on an actual taint. Therefor, these methods, whichever they end up going with, are basically pointless shortcuts that do not significantly impact the complexity of a "raw" tainting procedure. |
|
|
|
|
This is what you need to know to treat your private key exports properly: you can reveal the private root of an Armory wallet with:
1) A chain of public keys tracing back to the public root.
2) The chaincode (that's treated the same as public keys).
3) Any corresponding private key on that public chain.
The most conservative position is to consider the entire wallet compromised if you export even a single private key, and that's the position I hold both personally and officially.
|
|
|
|
AFAIK bech32 is only for v0 native SW scripts. I'll get it in there at some point.
bech32 works for all segwit versions. It encodes the witness version number. I meant it as a way to distinguish from nested segwit scripts. |
|
|
|
|
Show Posts
