Using Armory on the BCH chain

[goatpig]

Great, thank you all.

Assuming i didn't touch my BCH since it was created.

If I just want to send a BCH offline transaction (let's say to my new wallet), Can I broadcast it with an offline node?

You can:

1) Create the transaction with pre fork Bitcoin data (assuming you have air dropped BCH and never touched it).

2) Sign it however you want (offline included)

3) Use a BCH push service to broadcast from there (typically provided by block explorer websites).

[1715079230]

1715079230

[1715079230]

1715079230

[1715079230]

1715079230

[Carlton Banks]

If I just want to send a BCH offline transaction (let's say to my new wallet), Can I broadcast it with an offline node?

You can:

1) Create the transaction with pre fork Bitcoin data (assuming you have air dropped BCH and never touched it).

2) Sign it however you want (offline included)

3) Use a BCH push service to broadcast from there (typically provided by block explorer websites).

Assuming magic bytes are only for finding nodes to connect to on the network (I believe that's so), and other hard fork changes in Bcash don't stop you spending in the old transaction formats (they've done something like 4 hard forks on the Bcash blockchain now, so who knows), then maybe alternatively:

3 b) Use your own Bcash software as your push service


This assumes you trust their software, and all the other assumptions at the start of this post.

The only advantage is that It could increase your privacy a little. Bear in mind that if you push a bunch of transactions to a website acting as BCH push service, then that website could easily collect some tasty data. If you push every output of BCH you own all that in the same browser session, it's reasonable for the website to assume that whoever pushed all the transactions also owns all the associated outputs being sent, and that's effectively deanonymising any corresponding outputs on the original Bitcoin blockchain (that also belong to you). Don't leak that information if you can avoid it!

[alomar]

Trezor can hold BCH, BTC and BTG. It's a good idea to put an extra pass phrase on each Trezor account before sending coins to Trezor. That way even if someone gets your seed words list or device they still can't get the coins. You also want to make sure it hasn't been tampered with. Generate you're own seed words and number phrase.

Apparently, that's a bad idea. There's a way of figuring out that passphrases exist for a given Trezor seed, whereas if you don't use a passphrase, then it can be proved that you don't have any passphrased accounts pertaining to the same seed mnemonic.

can you expound upon this further?  afaik, using passphrases for Trezor specific accounts is considered best practice.  that's one.  two, how can an attacker figure out that passphrases exist for a given seed without you telling him?  and third, how can it be proved you don't have any passphrased accounts w/o you telling him?

[justmyname]

Trezor can hold BCH, BTC and BTG. It's a good idea to put an extra pass phrase on each Trezor account before sending coins to Trezor. That way even if someone gets your seed words list or device they still can't get the coins. You also want to make sure it hasn't been tampered with. Generate you're own seed words and number phrase.

Apparently, that's a bad idea. There's a way of figuring out that passphrases exist for a given Trezor seed, whereas if you don't use a passphrase, then it can be proved that you don't have any passphrased accounts pertaining to the same seed mnemonic.

can you expound upon this further?  afaik, using passphrases for Trezor specific accounts is considered best practice.  that's one.  two, how can an attacker figure out that passphrases exist for a given seed without you telling him?  and third, how can it be proved you don't have any passphrased accounts w/o you telling him?

I don't know what he's talking about either. You can even have diversion accounts with different passphrases and lower amounts of coins, to throw someone off.

From what I understand. Without an extra passphrase..... If someone got a copy of your 20 seed words they can get your coins. Or if they get the device they might be able to get the number phrase off of a chip in the device if they are a hardware engineer. Then they could log on to your device and move the coins. By then you would have probably moved the coins yourself as soon as you discovered your house had been ransacked. 

[HCP]

Apparently, that's a bad idea. There's a way of figuring out that passphrases exist for a given Trezor seed, whereas if you don't use a passphrase, then it can be proved that you don't have any passphrased accounts pertaining to the same seed mnemonic.

can you expound upon this further?  afaik, using passphrases for Trezor specific accounts is considered best practice.  that's one.  two, how can an attacker figure out that passphrases exist for a given seed without you telling him?  and third, how can it be proved you don't have any passphrased accounts w/o you telling him?

I don't know what he's talking about either. You can even have diversion accounts with different passphrases and lower amounts of coins, to throw someone off.

I believe he is talking about the fact that you have to explicitly turn passphrases on with the Trezor... it's in the settings:


Theoretically, if an attacker has your device (and PIN) and they plug your device in open up the Trezor wallet, they will be able to check this setting to see whether or not you have enabled the passphrase protection. It could potentially be a flag that you may have a hidden passphrase that you have not provided. Although, you could argue that you just switched it on to check it out, but never used that feature...

So, while it might indicate that you might have used passphrases, I wouldn't say that having the setting turned on was "conclusive proof" that you did.

[btcpop.co]

So if I understand correctly, starting may 15th, you can't use armory on the BCH chain anymore?

Entirely depends on the span of the new HF. If it's just a block size increase and new opcodes, Armory should still "work" provided the network magic word part is fixed.

Honestly, it would probably take me a single day to deal with this stuff assuming all they did was to increase the block size. I don't do it because I refuse to give up development time for BCH.

Got it, thank you for your hard work!

It works if you just remove some checks for the network magic, those was only added in the last update, peers for other chains will still be banned so it could only lead initial to some more wrong connections from and to your node.

See:
https://bitcointalk.org/index.php?topic=2070058.msg37065819#msg37065819

For now I think its the best solution, its not the optimal solution but that way you could still use armory and also update armory without needing to edit or add own code.
You just need to make sure you remove the checks also in future updates on Bitcoin Cash. ( I assume the checks wont be updated much so should be easy to find and remove it in future versions as well ).

Thanks, the problem is, as stupid as it may sound, that I don't really know how to download the code and build it with the changes, it will probably take me 2-3 days to do just that.
I would have done that don't get me wrong but I think that this is a bad practice.
goatpig don't want to support BCH which is his right and I respect it.
So now for each new version of both armory and BCH you will have to find more and more workarounds to make it work which is really a bad practice.
Armory is for BTC.
I think it is best to just find another wallet for BCH. Any Ideas?

I don't have much time atm else I would create a patch for either BitcoinABC or Armory.
I'm pretty sure that the BitcoinABC devs would include the patch if it only allows Armory to connect without the magic check.
Best practice would be probably if someone with time would fork armory and create and maintain a BCH version.
I don't expect or demand that Goatpig keeps supporting it.
It's also unlikely that the code for the magic checks will be changed in the future as it does what it should do, so on updates you probably only need to update the same file and comment out the same checks.

I know its not the best practice but its pretty quick and works for now.

[TierNolan]

Edit, that change alone isn't enough, armory won't connect to bitcoinABC.

Check your node log, should tell you why Armory is getting rejected.

This is the error message.

Code:

2018-06-26 23:51:31 PROCESSMESSAGE: INVALID MESSAGESTART version peer=127.0.0.1:56606 (53)

The endianess needs to be swapped.  When expressed as an uint32_t, the magic value for Bitcoin Cash is 0xe8f3e1e3 rather than 0xe3e1f3e8.

The updated version of your suggestion is as follows.

https://github.com/goatpig/BitcoinArmory/blob/master/cppForSwig/BlockUtils.cpp#L886

Code:

         networkNode_ = make_shared<BitcoinP2P>("127.0.0.1", config_.btcPort_,
            *(uint32_t*)config_.magicBytes_.getPtr());

Should be changed to:

Code:

         networkNode_ = make_shared<BitcoinP2P>("127.0.0.1", config_.btcPort_,
            0xe8f3e1e3);

This connects properly which I tried it.  I also wiped the contents of the Armory db.  I don't know if that was required.

It looks like Bitcoin Cash clients have 2 magic patterns, one for the network and one for disk storage.  This means that even without any changes, Armory will sync with the blocks stored on the disk.  It just doesn't do online updates (or broadcasts), since it can still read the files on the disk.

[goatpig]

Thanks, good to know.

It looks like Bitcoin Cash clients have 2 magic patterns

What an ugly hack. I don't think wiping the DB is necessary in that light, but I'd say it's preferable (unless you don't have the BCH chain and are just using the BTC one). I'm considering adding an option to stop DB scanning at a user defined height (to scan up to pre fork height without the need to mess with blockchain data).

[mikoslav]

Question:

I have a back up seed for my armory wallet, there is no BTC in it, but there is some Bitcoin Cash there. (prefork wallet, and I moved my BTC from there last december).
I have not updated bitcoin core nor my armory wallet since there.
Now armory doesnt event start.

so my question is, since I want to get my BCH from that prefork address, and I dont want to be forced to synchronize bitcoin core, -
- can I use the Root Key (from my Paper Backup for Armory Wallet that I printed out initially)
in some application/program to recover my private key?

Or I do HAVE to install armory wallet and recover it there?

thanks in advance.

[btcpop.co]

Question:
- can I use the Root Key (from my Paper Backup for Armory Wallet that I printed out initially)
in some application/program to recover my private key?

You can export keys in offline mode, no need to sync with the network for that.

[HCP]

so my question is, since I want to get my BCH from that prefork address, and I dont want to be forced to synchronize bitcoin core, -
- can I use the Root Key (from my Paper Backup for Armory Wallet that I printed out initially)
in some application/program to recover my private key?

Or I do HAVE to install armory wallet and recover it there?

You HAVE to install Armory.

Armory "Root Keys" are proprietary and, as far as I am aware, only work with Armory... there are no other applications that use or can read this format to regenerate a wallet/keys/addresses. However, as mentioned above, you can install Armory (without Bitcoin Core installed and/or synced) and export the private keys... refer here, where the answer to your previous question regarding this was answered : https://bitcointalk.org/index.php?topic=3274219.msg34442580#msg34442580

[TierNolan]

Armory "Root Keys" are proprietary

I don't think the method is actually 'proprietary'.  That would mean that nobody else was allowed to use their method.

and, as far as I am aware, only work with Armory...

Right, but that is only because nobody uses the Armory method.  They could if they wanted.

Instead they use the standard (BIP-32) hierarchical key generation method.

Armory would probably have used BIP-32 as well, but was developed before BIP-32 was created.

[Carlton Banks]

Armory would probably have used BIP-32 as well, but was developed before BIP-32 was created.

Armory's wallet design was based on BIP32 in an early stage of it's evolution, I believe. But BIP32 changed after the fact, and then took a while to get adopted by wallet software.

[goatpig]

Armory would probably have used BIP-32 as well, but was developed before BIP-32 was created.

Armory's wallet design was based on BIP32 in an early stage of it's evolution, I believe. But BIP32 changed after the fact, and then took a while to get adopted by wallet software.

AFAIK, Armory introduced hierarchical deterministic wallets to the ecosystem. This in turn inspired BIP32 which improved the design while standardizing the feature.

[Carlton Banks]

Armory would probably have used BIP-32 as well, but was developed before BIP-32 was created.

Armory's wallet design was based on BIP32 in an early stage of it's evolution, I believe. But BIP32 changed after the fact, and then took a while to get adopted by wallet software.

AFAIK, Armory introduced hierarchical deterministic wallets to the ecosystem. This in turn inspired BIP32 which improved the design while standardizing the feature.

Right, in those days Alan Reiner/etotheipi was pretty active on bitcoin dev mailing lists and places like that, and I'm pretty sure he discussed the ideas with everyone. Was it actually Alan's idea to begin with? I can't remember that exactly.

Alan definitely just went ahead and implemented his design, whereas other wallets took a long time to follow.

[goatpig]

Right, in those days Alan Reiner/etotheipi was pretty active on bitcoin dev mailing lists and places like that, and I'm pretty sure he discussed the ideas with everyone. Was it actually Alan's idea to begin with? I can't remember that exactly.

Alan definitely just went ahead and implemented his design, whereas other wallets took a long time to follow.

Honestly I'm not sure who came up with the idea of HD wallets first. In other ecosystems that require cryptographic material management (think CAs, DNS providers), it is common practice to create one root piece of secure material offline and derive lower schedule keys from that. With this in mind, you can't argue the use of HD wallets in the Bitcoin space is actually a novel invention, as there is prior art in other spheres, even though there was the need for some engineering to suit our use case.

Therefor, with the previous paragraph in mind, while I cannot tell you with certitude who brought the idea of HD wallets to Bitcoin first, I suspect it was floating in many devs mind if not yet in the mailing list, since the practice has been common place in other industries.

The only thing I know for sure is that Armory was the first implementation of this idea in the Bitcoin ecosystem. From what I know, it was ultimately Alan's solo take on the underlying principle. Bitcoin devs with sipa in the lead improved on it to birth BIP32 about a year later (give or take).

[Carlton Banks]

I see, "nothing new under the sun"

[TierNolan]

Honestly I'm not sure who came up with the idea of HD wallets first.

It looks like the original idea came from Greg Maxwell, but Armory was the first implementation to run with it.

It is also possible that it was simultaneously invented / repeatedly invented by multiple people.

[TierNolan]

This might be a Bitcoin Cash only issue (or even Bitcoin Unlimited only issue).

On the other hand, it might be a source of intermittent/hard to track down blockchain stalls with all the other clients.

It looks like the Bitcoin (Cash) Unlimited client manages the block files in an unexpected way.  When I look at the block files, some earlier block files have modified times that are much more recent than they should be.

The equivalent Bitcoin Core code seems to work the same way, but I haven't actually checked.

I did a full resync (deleted all the blk files and chainstate) and left the node running in the background.  Once I noticed that it resynced, I restarted the node (before the 15:57 timestamps) and then started Armory after wiping the Armory databases.

Armory resynced and then stalled.  It said connected to the node.

This is the end of "ls -lrt blk0*" and I assume the node completed resyncing around 6:45am.

Code:

-rw------- 1 tiern tiern 120188494 Nov 19 06:41 blk01037.dat
-rw------- 1 tiern tiern 134182052 Nov 19 06:41 blk01038.dat
-rw------- 1 tiern tiern 134024033 Nov 19 06:42 blk01039.dat
-rw------- 1 tiern tiern 127342200 Nov 19 06:44 blk01040.dat
-rw------- 1 tiern tiern 131259910 Nov 19 06:45 blk01041.dat
-rw------- 1 tiern tiern  83886080 Nov 19 13:14 blk01042.dat
-rw------- 1 tiern tiern 134215061 Nov 19 15:57 blk00001.dat
-rw------- 1 tiern tiern 134215184 Nov 19 15:57 blk00004.dat
-rw------- 1 tiern tiern 134216866 Nov 19 15:57 blk00006.dat
-rw------- 1 tiern tiern 134213458 Nov 19 15:57 blk00007.dat
-rw------- 1 tiern tiern 134198809 Nov 19 15:57 blk00008.dat
-rw------- 1 tiern tiern 134207767 Nov 19 15:57 blk00009.dat

Bitcoin node code was changed to this method pretty early on (in this commit from Aug 2012).

When a new block is received from the network, it scans all the blk files and finds the first one that has enough space to store the new block.

This means that the file systems doesn't act as "append-only" overall.  It is append-only for each file though.

It has a variable called nLastBlockFile.  This variable acts as a lower limit on the scan.  Once it writes to a blk file, it never checks files lower than that anymore.  That is a RAM variable though, so it gets set back to zero each time a node is restarted.

I think the problem with Bitcoin Cash is that the blocks are highly variable in size.  If the current blk file doesn't have enough to store a large block, the client will move on to the next blk index, leaving a large amount of free space.  

The next time the node is started, a few 50kB blocks will probably fit in spaces like that.  It highlights the issue, but I think it could happen on the Bitcoin Core client too.

I think this is not compatible with Armory?  It assumes that the blk files are filled in order and there are no movements backwards.

A solution would be to keep a record of "last-checked time" and then re-scan any old blk files that have a modified time greater or equal to the last-checked time.  This check could be run any time a new block notification is received.  It should only be a few blk files at any one time.

Even better would be to record how much of each file was already processed, but that is probably to much hassle.  

Would re-scanning already scanned blk files cause problems for Armory?

The workaround is to wipe the Armory database and let it re-scan everything if the block stalls but that is a sledge hammer.

[goatpig]

A solution would be to keep a record of "last-checked time" and then re-scan any old blk files that have a modified time greater or equal to the last-checked time.  This check could be run any time a new block notification is received.

Once it writes to a blk file, it never checks files lower than that anymore.  That is a RAM variable though, so it gets set back to zero each time a node is restarted.

Why would it need to check for previous files appends on new blocks? If the issue only happens on fresh node start (when free space in older block files is eligible), as long as Armory sees that one new block, it will work.

Armory does not expect blocks to appear in order in files. It will check block data on disk from the last known block to have extended the chain. Therefor if you have up to blk01000.dat and the last top is in blk00997.dat, it will check #977 to #1000 on every new block notifications until it finds a block that extends the chain again.

Would re-scanning already scanned blk files cause problems for Armory?

DB is designed to whistand being written over. Rescanning is fine. As a matter of fact, on each start Armory rewinds back 100 blocks from the last known top to account for long reorgs occuring while it wasn't running. You can see it here: https://github.com/goatpig/BitcoinArmory/blob/master/cppForSwig/DatabaseBuilder.cpp#L55

Code:

      //rewind the top block offset to catch on missed blocks for db init
      auto topBlock = blockchain_->top();
      auto rewindHeight = topBlock->getBlockHeight();
      if (rewindHeight > 100)
         rewindHeight -= 100;
      else
         rewindHeight = 1;

      auto rewindBlock = blockchain_->getHeaderByHeight(rewindHeight);
      topBlockOffset_.fileID_ = rewindBlock->getBlockFileNum();
      topBlockOffset_.offset_ = rewindBlock->getOffset();

      LOGINFO << "Rewinding 100 blocks";

You can increase this value to try and confirm your theory. On Bitcoin a blk file is ~100 blocks, on BCH idk, try much larger stuff.

The ultimate solution would be blocks over P2P, but idk what kind of mess BCH will be by the time I'm done with that. Chances are Armory won't be compatible anymore at that point.