RBF gets much further than it used to, but I still can't RBF a transaction from a Watch-only wallet.

I get to the Sending from Wallet: / Enter Recipients: screen, and I can enter my details and click Continue, click Yes on the Insufficient Fee warning, and nothing happens - I'm back at the Wallet/Recipients screen, when I think I should be looking at the Review Offline Transaction screen to save it to my USB flash drive...

If I enter a huge fee to skip the Insufficient Fee warning, the Continue button just doesn't do anything - I can click it all day long.

I think your pathing is screwed up, unless A:\ and C:\ refer to your external drive.

See https://btcarmory.com/docs/pathing

Any idea when Armory will support sending to and receiving at the new "bc1" address type?

Armory is running on Windows.  It's connected via http to ArmoryDB running on an Ubuntu machine.

This Windows install does have a functioning install of Python 2.7.14

I've anonymized this log output -- let me know if you need the un-anonymized output, or if you need to see the entire logfile rather than the output from the troubled period.  I'd want a confidential way of getting that to you.

https://pastebin.com/AEtpcSHM

The transaction had 3 Segwit inputs, and one Segwit output (change) and one legacy address output.

Ignore the errors at the top -- I had an issue with the flashdrive, after I realized this and used a different drive I was able to save/sign/broadcast the transaction normally.  I was never able to make RBF work -- no errors or crashes, Armory just didn't do anything when I clicked on "Bump fee" on the context menu.

Is it possible to RBF-bump offline transactions?

I see the "right-click to bump", but when I right-click and select "Bump Fee" nothing happens.  I was hoping/expecting for an offline transaction window to create an updated unsigned transaction....

... 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?

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....

I vote for the fewest possible changes involving the least-possible amount of programming time to enable users to split their UTXOs. BCH announced to the world that the wallet community will bend over backwards to support whatever broken shit the hard-forkers spew out at the last moment.  I'd suggest not reinforcing that message.

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.

The question ultimately cannot be answered until we actually know for sure what will be implemented.

My understanding is btc1 has implemented one-way replay protection, where transactions that include some magic value are not valid on the btc1 chain.

Does anyone know any details about how this is implemented, and what the status of Armory support for it will be?

Bitcoin's made me enough money that I'd be delighted to run such a service.

Assuming the supernode is running on an isolated host running only bitcoind plus armorydb, can you think of any security risks from allowing internet connections to armorydb (More specifically, to the http proxy that is used)? Can you offer any kind of guidance as to what the bandwidth usage would be like, both upload and download?

I've always and only managed bitcoin-qt manually in my instances. Have you considered just removing the functionality for managing Bitcoin Core automatically, and just replacing it with a "Tell me how to connect to your bitcoind [Default 127.0.0.1:8333]" and "Where do the blocks live [Default %USERDATA%\bitcoin or whatever]" in Options?

Add a note to the documentation that Armory requires a locally running bitcoind, and will need to be told how to connect and where the blocks live?  At least then people having trouble with bitcoind wont be bugging you....

Really? The thing that changed is the chainstate directory, which Armory doesn't use afaik? The blocks database format should be unchanged...

Transaction fees are calculated differently for SegWit transactions. I'm not going to get into all the details, but look up "Block Weight". I presume Armory will receive a UI update in the future to properly reflect this, but there is currently a disconnection between "Satoshis/Byte" and "Satoshis/Effective Byte"

Specifically, you are specifying the actual Satoshi/Byte with your fee, but with the SegWit discount your "effective" fee is the larger value.

Nope!

Minor annoyance -- Offline Armory appears unable to sign transactions from SegWit addresses unless manually put into Expert mode and select C++ signer.

Specifically, from a SegWit UTXO to two SegWit addresses plus an OP_RETURN

Running armory against a BCH full-node will result in armory seeing your BCH balances.

You should be aware that no version of Armory can spend BCH inputs yet due to changes in transaction format. You will need to update your BCH armory instance to a more recent version, if and when such a version becomes available.

Check permissions? If Armory and Bitcoind are running as different users on unix-like systems, there can be issues because of Bitcoin's default owner-only permissions.  If you're running as different users, you'll need to fix Bitcoin's blocks/ directory to have an other-read (or group-read, if you put them in the same group) bit, then set sysperms=1 in bitcoin.conf

 

With some pretty substantial VM re-allocation and re-partitioning, I've got one machine that _mostly_ meets that.

I presume the advantage of this is that you can throw any wallet or any private key at it and not have to wait to re-scan the blockchain to find any txs?

You need to understand there's two software pieces at work.... Armory relies on bitcoind (nominally, Bitcoin Core) for it's block history and transaction and block validation.

You'll need to download the hardfork node software (BitcoinABC I believe it's called), create a copy of your existing bitcoind data directory, and configure bitcoinABC to work against the copied data directory.  I would expect (as much as I expect anything in bullshit-hardfork-land to work) that bitcoinABC would start up, validate the blockchain, hit the point where they hardforked, then reach out to the network and fetch the new hardfork blocks.

Once the new bitcoind is synced up and happy, you'll need to take a copy of your armory environment, and point that copy at the new bitcoind. That will let you see your balances on the BCH chain.  Note that Armory is currently not capable of creating valid BCH transactions, so you will not be able to spend the coins yet.

You need to be very careful here. Ideally you want each of these pieces running in its own VM.  If you run a misconfigured bitcoinABC instance on a machine with a normal Core installation, bitcoinABC will munge Core's data directory.  Likewise, if you take an Armory instance and flip-flop it between Core and ABC, you're likely to break Armory's understanding of history and will have to re-scan the blockchain to have a correct transaction history and spendable balance.

Can you elaborate on "Supernode DB mode"? What it does, how to enable and configure it, and a rough explanation of its resource requirements?