With the encoding used (not sure what it's called anymore), uncompressed keys start with 0x04. Compressing the key means to only carry the X value (first 32) bytes, with an extra leading byte to signify parity and compression (in this case, 0x02 and 0x03). This works because since Y is squared, both positive and negative values of X fit a solution.

While the X value remains the same, parity shenanigans can change the canonical order of the keys, since it is the header byte.

Good to hear.

FYI, issue was related to key ordering. Armory orders keys in order to recreate the same multisig script under all circumstances. Legacy Armory MS scripts use uncompressed keys, but all things segwit have to use compressed keys. When compressing the keys, the order may change, and Armory was coded to tie keys to signatures by index (expecting the order to always be enforced). The fix was to assign signatures to their actual keys instead.

Oddly enough, I never ran into that issue when I tested SW lockboxes. For what it's worth, the chance of hitting this bug (compressed keys having a different order than their uncompressed counterparts) is of 25% with 2-of-2 and ~50% chance with 2-of-3.

The end result after the fix is that with SW lockboxes, the key order in script may not necessarily match the order as presented in the GUI (which follows the uncompressed key order always).

That's unrelated. Try the current state of testing and let me know.

I'll look into it this weekend and report back.

Sent. You can keep them for further testing.

Armory connects to your node via the Bitcoin P2P layer. It also needs local disk access to the blockchain data your node maintains. You need to devise a scheme where the blockchain data is natively available to Armory, as network sharing does not work with Armory (it needs to mmap the blockchain files). I do not think Core requires that however, check with them.

After you've figured this part, you need change the hardcoded node IP within Armory's code:

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

At any rate, why do you want to split Armory from bitcoind? Consider that Armory is 2 processes, one db/server that only connects to bitcoind and only has public address data, and one client/gui that does all things wallets and only connects to the db/server. These speak to each other over an unencrypted socket.

If your goal is to keep your wallets in a separate container from bitcoind (which needs WAN access), then the following scheme satisfies that and is easier to setup:

Run ArmoryDB along bitcoind in the same docker container, then expose ArmoryDB to your LAN through nginx. This lets the GUI (with your wallet data) connect from another docker container.

That's my offline signing key for Armory releases, I don't use that for emails. I'm not going to send you the proper key to email. Read further.


That was rhetorical. I do not feel comfortable touching user funds. To make things clear, I don't want to touch your coins, so I'm going to explore other alleys to fix this bug first.

When I reviewed your bug reports prior to the recent commits to the testing branch, you seemed to imply the lockbox signature mismatch issue could happen in any lockbox (I think you claimed to have produce it with a fresh lockbox). Therefor, I have a couple assignments for you:

1) Can you create fresh lockboxes that display this bug using the current state of the testing branch? Please do this on the testnet. If you need testnet coins, post your address here, I'll send you some.

2) If yes, is the issue with SegWit lockboxes only? This thread seems to imply that. I do not remember testing specifically for lockboxes back in August, this could be a key factor.

3) If you manage to reproduce this on testnet lockboxes, I would like to see those.

Means the tx is signing for outputs that do not exist on the chain your node is running on.

I have failed to reproduce this issue on my end, can you elaborate on it? Otherwise I'll have to look at the lockbox directly.

Yes, what you posted is the aggregate log, I want the db specific log now.


Armory's datadir, where your wallets reside.

Post dbLog.txt. If you have to cut it down, I'm more interested in the tail of the file than the head.

You should try with the current state of testing, the lockbox GUI stuff is fixed in there.

This will probably never work in regtest.

Armory has 2 paths to broadcast a transactions:

1) P2P

Armory is connected to your Bitcoin node as a node itself. It uses that to grab zero confirmation tx from the network, new block notifications as well as broadcasting transactions. The P2P layer is not meant to operate according to a client server paradigm however.

When a node broadcasts a transaction on the network, it first announces it has transactions by hash in an inv_tx packet. The recipient nodes then decide at their own discretion if they want any of the transactions in that inventory batch. They will request these tx by hash from the origin node. At this point, the exchange is over.

These 2 steps are the "send" mechanic, where Armory sends to the tx to the node.

Next is the "get" step. In a client/server setup (i.e. Armory operations), you want an ACK on whether the tx was accepted. What we are trying to achieve when broadcasting a transaction from Armory is to get that tx in the Bitcoin network's "mempool". Simply pushing that tx to our node is not enough, we need to know whether that tx was accepted by the node as well, which is a strong enough guarantee the tx will be passed around the entire network in consequence.

To do so, after the node has grabbed our tx, we then try to grab that tx back from the node's own mempool, which demonstrates the node has in fact accepted the new tx. The issue with this method is 2 fold.

a) First, the tx will not be available in the node's mempool until the node pushes the inv packet itself to its connected peers. This process can take a while, as Core like to batch their inv_tx together before pushing that stuff out. This is why P2P broadcast is unreliable on testnet/regtest, as there's not enough traffic to prompt quick inv_tx forwarding.

Keep in mind that your node thinks this tx is just one of many floating around the network, that it may or may not need to bounce it to other nodes for propagation. It has no sense of priority nor duty to push that stuff out. Your node just doesn't know this is its own original tx and it needs to propagate it ASAP, and there is no facility to convey that over the P2P.

b) Next, since Armory pushed that tx to your node, it will never see the inv_tx packet in return. From the perspective of your node, it is wasted bandwidth to return the inv of this tx to its point origin. Therefor, Armory has to poll your node's mempool blindly, hoping to find that tx in there. If it fails to, the result will be a "timeout (get)".

2) RPC

The tx is passed to your node's RPC interface. This is guaranteed behavior with ACK/nACK and error verbose.

-------------------------

- Why not always use the RPC?
   There's no guarantee the user has gone through the steps to enable the RPC, nor that it is desirable. Only the node is required to operate Armory, not the RPC. Also, in terms of performance, the RPC is at least an order of magnitude slower.

- Why use the RPC interface at all then?
   If the RPC is available, ArmoryQt will use it as fallback for tx broadcasting in case the P2P method fails.

- RPC broadcast in armoryd
   There's method for this in armoryd atm. You can add it easily by copying the code in jsonrpc_sendasciitransactionraw and replacing the one line with RPC broadcast (https://github.com/goatpig/armoryd/blob/master/armoryd.py#L323):

You wouldn't have to code per se, you'd have to add the lines I give you at specific spots and run make.

When called from the GUI, the DB is spawned with --regtest. Browse armorylog.txt, you should see the db invocation with the relevant arg.


CLI args overrule the config file. The way it works is the arguments are tokenized and inserted into a map. Then the content of the config file is loaded and passed through the same process. Any insertion of an existing key into the token map will be ignored as per std::map mechanics.

This means most everything in your db config file will be ignored when spawning from the GUI as it passes a pretty exhaustive list of arguments.

This is the first time I hear of this issue. I guess you are left with blindly changing file permissions on new block data files and see where it takes you. If you have some coding in you, I can tell you where to add print statements to debug this thoroughly.

Technically you can't. The multisig script is built from the addresses your provide it. As these don't change per lockbox, neither does the address. However, currently you can get the P2SH legacy multisig and the P2SH P2WPKH segwit variation address for each lockbox. It's a trick that yields 2 different addresses. The redeem scripts on chain will reveal these are one and the same however, i.e. when you spent from both variants, the txin will carry data that will link the addresses together.

Those log entries are only indicative of progress and do not represent an exhaustive list of the block files that have been parsed. Simply put, any thread that manages to grab the verbose lock ouputs whatever file it finished parsing.

You want to run this process with a wallet loaded, as this log indicates the db has no addresses to track atm. It would yield more relevant information in the log.

Just restart the whole stack. If it fails again, post your logs.

Would need to see dbLog.txt