Bitcoin Forum
July 10, 2025, 07:36:25 PM *
News: Latest Bitcoin Core release: 29.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 »
1  Bitcoin / Armory / There's a trello board for Armory development on: May 22, 2023, 08:14:56 AM
For what it's worth, I've been using a trello board recently to plan out Armory development. Obviously it's open, nothing to hide in an open source project =D. Feel free to check it, though don't expect it to progress daily! Also, this is an opportunity to take the development discussions into its own topic, instead of having it scattered across many unrelated topics. Therefor, feel free to ask your questions here, even old, recurrent ones.

https://trello.com/b/wJOsu12D/dev
2  Bitcoin / Armory / Armory 0.96.5 on: December 24, 2018, 08:59:21 AM
Another point release with some bug fixes and the ability to spend to bech32 addresses. Most likely the last update before 0.97, sometimes for Q2 2019.

Changelog
Quote
== Added ==
   - You can now set the database path from the Settings menu.
   - You can now spend to bech32 addresses.
   - Added support for satoshi-port CLI argument in ArmoryDB.
   - Break backwards compatibility for unsigned transactions carrying bech32 outputs.
     Older versions cannot make sense of bech32 addresses, therefor they shouldn't
     be able to sign the tx at all.

== Fixes ==
   - Improved bitcoind path detection.
   - Properly carry thread-count and ram-usage command line arguments from client to automated db process.
   - Custom paths set in the GUI will now properly overrule custom paths from armoryqt.conf.
   - Fixed spending from lockboxes.
   - Fixed deleting lockboxes.
   - Fixed Simulfund promisory note creation and signing.
   - Fixed preview dialog for unconfirmed transactions.
   - Fixed previewing unsigned transactions in offline mode.
   - Properly detect output script type when filtering UTXOs.
   - Use relevant config files with testnet/regtest modes.
   - Properly display bech32 address strings in transaction system tray notification.
   - Fix signing transactions with OP_RETURN outputs.
   - Fix passing satoshi-port argument through ArmoryQt to auto-managed ArmoryDB.

   - Fixed SecurePrint decryption on Windows.
   - Recent updates to the MSVC compiler resulted in invalid decryption of AES-CBC packets. This issue only
     affects the decryption of SecurePrint encrypted backups. Encryption still operates as expected, no
     SecurePrint backups created with the incriminated builds are faulty. Wallets are not concerned, as they
     use AES-CFB.
     
     The solution was to turn off all optimizations in MSVC when buidling CryptoPP. This may impact DB boostrapping
     performance.

     This issue affects all Windows builds of 0.96.4.

== Misc ==
- Use blockstream.info instead of blockchain.info as the external block explorer link.


Binaries
https://github.com/goatpig/BitcoinArmory/releases/tag/v0.96.5

Happy holidays!
3  Bitcoin / Armory / Armory 0.96.5 RC2 on: December 12, 2018, 12:17:09 AM
Fixed all the stuff reported for RC1, this should be the final RC for this version.

Changes
Code:
   - Break backwards compatibility for unsigned transactions carrying bech32 outputs. 
     Older versions cannot make sense of bech32 addresses, therefor they shouldn't
     be able to sign the tx at all.

   - Properly detect output script type when filtering UTXOs.
   - Use relevant config files with testnet/regtest modes.
   - Properly display bech32 address strings in transaction system tray notification.
   - Fix signing transactions with OP_RETURN outputs.
   - Fix passing satoshi-port argument through ArmoryQt to auto-managed ArmoryDB.

   - Use blockstream.info instead of blockchain.info as the external block explorer link.


Binaries

https://github.com/goatpig/BitcoinArmory/releases/tag/v0.96.4.991

RC1 thread

https://bitcointalk.org/index.php?topic=5071932.0
4  Bitcoin / Armory / Armory 0.96.5 RC1 on: November 19, 2018, 02:42:52 PM
This is a minor release with a lot of bug fixes and a couple new features:
    - Spend to bech32 addresses
    - Set DB dir in GUI (File > Settings menu)

Note
   Recent updates to the MSVC compiler broke CryptoPP's AES-CBC optimized decryption. This affects restoring SecurePrint backups on Windows with 0.96.4 only. All backups made with 0.96.4 are valid. Optimizations for CryptoPP have been disabled on Windows. I'm looking to replace it with libbtc sooner rather than later as a result.

Changelog

Code:
v0.96.5
== Added ==
   - You can now set the database path from the Settings menu.
   - You can now spend to bech32 addresses.
   - Added support for satoshi-port CLI argument in ArmoryDB.

== Fixes ==
   - Improved bitcoind path detection.
   - Properly carry thread-count and ram-usage command line arguments from client to automated db process.
   - Custom paths set in the GUI will now properly overrule custom paths from armoryqt.conf.
   - Fixed spending from lockboxes.
   - Fixed deleting lockboxes.
   - Fixed Simulfund promisory note creation and signing.
   - Fixed preview dialog for unconfirmed transactions.
   - Fixed previewing unsigned transactions in offline mode.
   - Fixed SecurePrint decryption on Windows.

   - Recent updates to the MSVC compiler resulted in invalid decryption of AES-CBC packets. This issue only
     affects the decryption of SecurePrint encrypted backups. Encryption still operates as expected, no
     SecurePrint backups created with the incriminated builds are faulty. Wallets are not concerned, as they
     use AES-CFB.
    
     The solution was to turn off all optimizations in MSVC when buidling CryptoPP. This may impact DB boostrapping
     performance.

     This issue affects all Windows builds of 0.96.4.

Binaries:

https://github.com/goatpig/BitcoinArmory/releases/tag/v0.96.4.99

Test away!
5  Bitcoin / Armory / Armory 0.96.4 release on: April 21, 2018, 11:33:15 AM
links:

https://github.com/goatpig/BitcoinArmory/releases/tag/v0.96.4
https://btcarmory.com/0.96.4-release/

changelog:

Quote
== Added ==
   - Updated fee estimate query from node to improve estimateSmartFee call introduced in Bitcoin Core 0.15.
   - The block confirmation target slider now spans from 2 to 100 blocks (previously 2 to 6).
   - You can now pick between 2 fee estimation profiles: conservative and economical. Refer to the estimateRawFee section of
     the Core 0.15 changelog for more information. A tooltip has been added to the GUI with a quick description.
   - If your node does not support the estimateSmartFee method, the code will fallback to the previous estimateFee method.
   - 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 creating offline transactions that mix P2SH and P2PKH UTXOs.
   - Fixed importing wallets progress report and scan resolution in the GUI.
   - Fixed SegWit sighash data serialization with scripts of length > 256 bytes.
   - Fixed multiple RBF transaction bumping issues.
   - 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.
   - Fixed fee calculation when checking "MAX" with SegWit UTXOs
   - The Coin control dialog will no longer spawn invisible
   - When creating a fragmented backup, fragments will no longer be cycled unecessarily
   - Fixed imported address rendering in the Address Book dialog
   - The Transaction Info dialog will now display address comments in the comment field if there is no comment
     attached to the transaction itself
   - The Transaction Info dialog will now properly display fee/byte fee for unconfirmed transactions   
   - The main transaction ledger will now display comments attached to outgoing addresses for each relevant transaction
   - Fixed selecting an arbitrary wallet file in the Recovery Tool dialog.

== Removed ==
   - You cannot sign messages with P2SH addresses. This functionality never existed in Armory to begin with, as it
     did not produce single sig P2SH addresses prior to 0.96. It will be introduced in 0.97

== Minor ==
   - You can now resize the Transaction Info dialog.
6  Bitcoin / Armory / 0.96.4 RC3 on: January 15, 2018, 01:12:28 AM
Binaries: https://github.com/goatpig/BitcoinArmory/releases/tag/v0.96.3.992

Test away.
7  Bitcoin / Armory / 0.96.4 RC2 on: December 28, 2017, 11:43:09 PM
Binaries:

https://github.com/goatpig/BitcoinArmory/releases/tag/v0.96.3.991

Notes:
This is mostly fixes, notably:
   - All things RBF
   - Unsigned tx creation with a mix of P2SH and P2PKH outputs
   - Some lockbox signing issues

Also, the auto fee GUI has been updated to use the reworked estimatesmartfee method from Core 0.15. People using older nodes won't see that change.

Test away =D
8  Bitcoin / Armory / 0.96.4 RC1 on: October 02, 2017, 06:56:22 PM
Binaries:

https://github.com/goatpig/BitcoinArmory/releases/tag/v0.96.3.99

Changelog:

Quote
== 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


9  Bitcoin / Armory / Armory 0.96.3 released on: September 22, 2017, 05:04:05 PM
Notes

This is a point release to fix a vulnerability with fragmented backups. If you are using fragmented backups on for your wallets, read the dedicated topic:

https://bitcointalk.org/index.php?topic=2199659.0

Binaries

https://github.com/goatpig/BitcoinArmory/releases/tag/v0.96.3

Changelog

Quote
== Vulnerability Fix ==
   - Fragmented backups were using a faulty implementation of Shamir's Secret Sharing (SSS).
     One of the requirement of SSS security parameters is that the coefficients of the curve are chozen randomly. The implementation
     up to this point was deriving these coefficients deterministically.

   - While it is hard to determine how far the deterministic coefficient generation erodes the security of SSS, and how exploitable
     the vulnerability is, the recommendation for users of fragmented backups is to treat the wallets backed up in this fashion as
     compromised and to migrate all funds to a new wallet.

   - The fragmented backup code now properly randomizes the SSS coefficients. Fragmented backups created with version 0.96.3 and later
     are safe to use.

   - The result of this change is that fragmented backups will no longer be deterministic. The previous behavior guaranteed a given
     wallet will always return the same set of fragments for a given M-of-N scheme. Since it deteriorates SSS security properties,
     the behavior has to be rolled back.
   - Fragment sets are now generated randomly, therefor an unique ID has been added to each set to identify them. You cannot mix
     and match sets.
   - While Armory can no longer generate deterministic fragments, it can still restore wallets from deterministic fragments.

   - Many thanks to Gregory Maxwell (greg@xiph.org) for identifying and reporting the vulnerability as well as reviewing the fix.

== Fixed ==
   - Fixed faulty version packet deserialization revealed by Core 0.15.0.1
10  Bitcoin / Armory / FRAGMENTED BACKUPS VULNERABILITY!! IF YOU USE THEM, READ THIS!! on: September 22, 2017, 05:03:40 PM
TLDR:

Fragmented backups in Armory use a broken implementation of Shamir's Secret Sharing (SSS). All users of fragmented backups need to treat the wallets backed up in this fashion compromised and migrate all funds to a fresh wallet.

1) The story

A couple days ago I was warned by Gregory Maxwell that the implementation for Shamir's Secret Sharing Armory uses is broken. After reviewing the code in question, I've concluded the implementation of SSS introduces a vulnerability in fragmented backups that requires not only an immediate fix but also a community wide warning to alert all fragmented backup users.

These users need to sweep all funds from these wallets. All version starting 0.96.3 will have the vulnerability fix.

2) A high level look at SSS

SSS is a scheme that takes a secret and outputs a set of N fragments. M of these fragments are sufficient to reconstruct the secret.

In order to do so, you first constructs a polynomial f of degree M over a finite field, in which M-1 of the coefficients are random values, and the last one is the secret itself. You then compute N points of f. Each point, which is a pair (x, f(x)), constitutes a fragment.

To reveal the secret, you need to reconstruct the polynomial, which you do by interpolating M points together.

I will not go into the details of the interpolation, but one element here is crucial: The effect of a partial interpolation is to narrow down the possible candidates for valid coefficients. In other words, the more points on the curve you interpolate, the clearer a picture of the curve you get. The curve is constructed around your secret, a more refined interpolation results in an ever increasing leak of information, to the point where you can brute force the secret.

This property of the interpolation is counteracted by the use of a finite field. Since all points generated with the polynomial belong to the underlying finite field, the cyclic nature of finite fields widens the range of possible solutions that would yield your particular polynomial from a partial interpolation (by making them infinite), in such a way that you simply cannot brute force your way out of the interpolating at least M points.

A simple way to demonstrate that property is as follows:

Consider the equation:

Code:
8 = 5 + x

It's obvious that x is 3, and that this is the only solution. Now add this variation to the equation:

Code:
8 = (5 + x) mod 11

Suddenly x can be 3, 14, 25, 36... and so on. There is now an infinite amount of solutions for x, due to the introduction of the modulo operation. This is essentially the effect the finite field has on the interpolation equations.

3) The vulnerability

The whole point of the previous section was to demonstrate how SSS is constructed to prevent partial information leaking. One of the requirements to insure that property is that all of the polynomial coefficients but the secret are chosen at random.

This is precisely what Armory's implementation breaks, by rolling deterministic and chained coefficients, where the first coefficient is deterministically derived from the secret, and the subsequent ones are derived successively from one another.

If you look at it in the context of the previous paragraph, where SSS was crafted to deny any alley to gather information about coefficients short of M fragments, the newly introduced deterministic relationship between all coefficents provides a path that potentially dumbs down the security of SSS to that of the hash function used to generate the coefficients.

This can ultimately lead to a subset of fragments leaking information about coefficients where none should be.

4) In the code

Code wise, there were 2 instances of this implementation, both of which are faulty.

a) The first version

It did 2 things wrong, one more aggravating than the other:

The coefficients were not picked at random, instead they were derived as hashes of the secret, in a fashion that boils down to this:

Code:
coefficient_0 = hash(secret) 
coefficient_(n+1) = hash(coefficient_n)

The fragments themselves were constructed as the following points on the curve:

Code:
fragment_n = (coefficient_n, f(coefficient_n))

There are 2 important issues with this setup. First of all, the coefficients are not selected at random, therefor it breaks SSS security assumptions.

Next, and most aggravating, the coefficients were provided as is on the fragments, since you need to provide the pair (x, f(x)), and x in this case were the actual coefficients.

Note that since the coefficients were derived from each other, the second mistake is twice as aggravating, as anyone with fragment n would have coefficient n and could derive all coefficients n+1.

The second mistake was caught and fixed eventually. I was not involved with anything regarding cryptography and security in Armory at the time, therefor I have no recollection of the event. I expect there was a write up of the issue and people were told to cycle wallets, but I can't remember any of it.

You can look at the code in its original form here:
https://github.com/etotheipi/BitcoinArmory/commit/80e373a#diff-27fe88d2c6032fecb93912a17d72081bR1615

b) The second version

The second version only made sure points were generated using the [1...N] sequence for x instead of coefficient themselves. At this point fragmented backups where no longer as broken but the code still did not implement SSS correctly.

Notably the assumption that no amount of fragments less than M can leak any data about the secret is not true with that faulty implementation.

One way to look at it is that this implementation introduces a deterministic relationship between the coefficients in a way that it can effectively reduce the security of the system to that of a single pass of HMAC512 provided an amount L of fragments, with L < M.

Here is the commit for the second version:

https://github.com/etotheipi/BitcoinArmory/commit/0824b632600116bd6395cec939fa6fd398efeb19#diff-27fe88d2c6032fecb93912a17d72081bR1915

5) Affected versions

Fragmented backups were introduced in version 0.88 (04/18/2013) and the first fix was deployed in version 0.90 (11/26/2013).

The final fix was introduced in v0.96.3 (9/21/2017)

6) The fix

The coefficients were made deterministic in order to present deterministic fragments to the user when fragmenting a wallet over a given scheme. In other words, fragmenting wallet W over a M-of-N scheme would always yield the save fragment values for the same fragment index.

This introduces scenarios where any amount of fragments can be recomputed from the private wallet root without invalidating fragments still in the wild.

The fix was to randomize the coefficients at the cost of the deterministic characteristic of the fragments.  The choice was fairly simple:

a) The deterministic attribute gained by bastardizing SSS is worthless in the face of how it damages its security properties.

b) Even if a change to SSS is designed so that it does not so obviously erode its security properties, this is still an act of rolling a custom cryptographic function, which commands a level of review and security analysis that will most likely not be performed at the adequate level.

c) There are no scenarios I can think of in which the feature of determinism in fragments is actually necessary and central to this type of backups. Introducing it at the cost of security is therefor doubly unacceptable. Backups are supposed to be forever afterall, lacing solid crypto with any kind of bootlegged algorithm does not stand to reason.

Therefor, it is without hesitation that the faulty feature was undone, and the faulty code removed from the repo so as to prevent unaware users from copying it into their own projects.

The changes can be seen here:

https://github.com/goatpig/BitcoinArmory/commit/94d2a7556d25cf788da639d81a7162694982f6b7
https://github.com/goatpig/BitcoinArmory/commit/7bd9887891ac88e2e49954ef034bedef88f23eaf

7) GUI changes

Since the fragments are not deterministic anymore, they are now generated with a unique set ID which is reflected on the backup strings and printed backups. Fragments are only useful within a their own set. Another way to put it is that you cannot mix and match fragments from different sets. This is the only difference between the pre and post fix implementation.

The fixed version is compatible with fragments generated from the deterministic version. You will still be able to restore from these with version 0.96.3+

8 ) Recommendations

It is hard to say exactly how effectively this custom take on SSS breaks security at the fragment level. How fewer fragments would it take to reproduce a secret than intended? Honestly, I don't know, but while the first implementation was effectively breaking all security assumptions of SSS, the second version is SSS at least theoretically.

I don't expect an attacker can snatch a single fragment and reveal the secret the next minute with minimal code. This vulnerability reduces the overall complexity of the problem that of a hash function, it doesn't outright bypass all complexity.

Since we're talking 32 byte integers, breaking the scheme isn't trivial, but it has certainly been weakened to a state that is difficult to precisely assess. Therefor, to remain on the conservative side, my recommendation is as follows:

If you created a fragment backup of your wallet, consider that wallet compromised. Create a new wallet and sweep the funds from the compromised wallet to the new one. You can redo your fragmented backup scheme on the new wallet provided you use Armory 0.96.3 and newer.

If you do not use fragmented backups, you have nothing to do.

9) Notes

Special thanks to Gregory Maxwell for finding the vulnerability and helping with the review of the fix.

11  Bitcoin / Armory / Armory 0.96.2 is out (SegWit enabled) on: August 29, 2017, 11:20:35 PM
0.96.2 is out. The use of SegWit has been enabled on the mainnet starting this release. SegWit availability is checked through your node's WITNESS service bit, i.e. connecting Armory to a node that does not advertise this bit will disable SW in the GUI.

Changes:

Code:
== Added ==
   - Enabled SegWit on the mainnet. Running against a node with WITNESS service bit flagged will allow you to create SegWit addresses.
   - Improved DB scan speed (~80% faster) and stability.
   - Reduced DB memory usage (~20% less).
   - Supernode DB mode. This isn't optimized for consumer grade computers, use at your own risk.
   - The MAX button in the Send dialog has been changed to a checkbox, effect is now binding.
     Maximum value will be calculated on any change.
   - You can now create OP_RETURN outputs from the Send dialog. This feature is only available in Expert mode.
   - You can now pick the signer of your choosing in Expert mode.
   - Added BCH on top of the legacy and 0.96 C++ signer.
   - Improved verbose on ZC broadcast failure.

== Fixed ==
   - Fixed benchmark timers on POSIX systems.
   - Fixed several Linux build configure bugs.
   - Properly update RPC state in GUI on connect/disconnect events.
   - Various zero conf bugs.
   - Scan progress notification.
   - Properly display comments for non legacy addresses.
   - Digital exports will be saved under the proper file extention in Windows.

== Removed ==
   - Removed armoryd from the repository. armoryd was moved to its own repository (https://github.com/goatpig/armoryd)

Binaries:

https://github.com/goatpig/BitcoinArmory/releases/tag/v0.96.2

Note:

OSX and offline RPi packages are on the way.
12  Bitcoin / Armory / Using Armory on the BCH chain on: August 06, 2017, 11:26:32 PM
With the BCH signer done, here is a guide on how to use it and keeping your stash secure.

-------- The signer --------

In order to sign for BCH, you have to pick your signer manually. This is a new feature, and is only available in Expert mode, so first thing first, set user mode to Expert.
To pick the signer, you need to get to the "Confirm Transaction" dialog. Once there, you should see the signer select frame, click it and pick the signer for the chain you want to spend on. The default option only picks between Bitcoin signers, to sign for BCH you HAVE to pick the BCH signer manually.

Screenshots for the good measure: https://imgur.com/a/9zXGD

Once you've picked the signer, the rest is business as usual. Note that this step only occurs at the point of signing, i.e. if you sign offline, you have to pick the signer on your offline machine.

-------- Security --------

The process is relatively safe. If you mess up and pick the wrong signer for you chain, the transaction will be invalid for that chain anyways. That transaction is valid for the chain signer is for however, example:

Armory is running against a BCH node. You create a tx and sign it with a Bitcoin signer. That transaction will fail to broadcast to the BCH network. However, if you try to broadcast this same transaction with an instance of Armory connected to a Bitcoin node, it will succeed and your coins will be moved on that chain.

This may sound confusing but this is how Armory operates by design, it trusts the underlying node to be honest and the Bcash devs made a point of not changing network ports, magic number identifiers nor script hash prefixes, so you end up with this mess.

As for why I didn't go further out of my way to try and make this distinction stronger in my own code, I'm trying to think for the future with all changes to mission critical code (such as signers), and let's be real, Bcash has no future. Therefor the changes were minimal, with an explicitly paying attention to:

1) Trying to salvage as much code as possible from this effort (OP_RETURN outputs and signer selection).

2) Making it easy to prune the useless bits once miners pull the plug on this nonsense.

3) Be prepared for the next gonzo debacle (2x?).

At any rate, if you do not care about Bcash, this feature is transparent to you, as the signer will always default to Bitcoin.

-------- Splitting your coins ---------

As stated previously, BCH sigs are invalid on the Bitcoin chain, and vice versa. Therefor there's nothing more to splitting your prefork coins but to spend them post fork.

-------- Testing --------

I've moved coins on the BCH chain. Here's a tx created with Armory:

2cc2b1f4578e6c0b42c5de396ca43eb0fe6868509bd19d9bd5e14a0b4f2c5166

I've also used the opportunity to test the OP_RETURN feature on a mainnet. If you inspect the transaction, you should be able to read "signed with armory" in the op_return message.

For the more paranoid, you can trace the history of the outpoint on the Bitcoin chain and verify that it has been spent to a completely different transaction, therefor demonstrating the split. The order I went was Bitcoin tx first, Bcash second, but it should work the other way around as well.

-------- Privacy ---------

In order to reduce privacy leakage, you should pick non KYC pure crypto exchanges. In this case, spend UTXO per UTXO in order to not link your coins on chain. If you're using a KYC exchange, it doesn't matter as much, as the exchange knows these coins are linked and who controls them, even though it wouldn't be obvious on chain if you went a UTXO at a time.

Whether you have sent your coins to a KYC exchange or not, you want to cycle your wallets on the other chain afterwards, i.e. if you dumped BCH, you want to move all these coins on BTC chain to a fresh wallet.

The reason for this is that your public keys will be exposed on at least one chain. One of the security layers of Bitcoin is that public keys are behind hashes up until you spend the coin. Once you sign coins on one of the chains, you lose this layer. This is a major reason why you do not reuse addresses in Bitcoin. This is particularly relevant if you have coins in long term cold storage: cycle them if you touch the keys!

As for how to cycle your wallets, it depends on the scenario:

1) If you used a KYC exchange, create a new wallet and send coins over whichever way you want, you have no privacy at this point. To regain fungibility, you will have to mix your coins or swap to fungible alt coins and back. This is out of the scope of this post, do your research if you value your financial privacy.

2) You used a non KYC exchange or some sort of cross chain swap scheme. You should move your coins to your new wallet utxo per utxo, or (1 in -> 2-3 outs), over the course of several weeks.

-------- Requirements --------

You need to update both your signer and online machine with a version of Armory capable to sign for BCH in order to spend the coins.

You need a copy of the chain, a running node and DB per side of the fork. You cannot mix ANY of these or you will corrupt your data. As a safety, make a backup of your Bitcoin chain before fiddling with the BCH stuff.

-------- Tricks --------

If you want to dump BCH but don't want to bother with the BCH node/don't trust their code, you can get around it with this trick:

1) You know all your prefork coins are also available on the BCH chain, therefor you only need blockchain data up to the fork point to move these coins.

2) You have all this data already in the form of the Bitcoin blockchain pre fork, so why not just use that?

3) You'll want to create a copy of your blockchain data then remove blkXXXXX.dat files up until the fork point . I don't know which file this is, something around 950~960, I'm sure someone will figure out the exact file. Note that if you did not move any coins post fork yet, you do not need to delete anything.

4) With this done, you want to sync a fresh DB against this blockchain folder. Do not run a node against it, just start ArmoryDB against this folder, then start ArmoryQt, it will pick up on that DB.

5) Once you're synced (it will show you as offline), you can create your transactions. You should pick utxos manually and keep track of them so as to not create conflicting transactions.

6) Once your tx is ready, make sure to create it as unsigned, even if your private keys are online. You will get a blob of text that you can feed back into the offline tx GUI. There you will get to sign the tx (make sure to pick the BCH miner), and you will get another blob of text. On the right side of that dialog, you will have a button that's called "Copy Raw Tx (Hex)". This is what you are after. This hex string is your signed tx.

7) With the signed tx, all you need now is some online service that will broadcast it to the BCH network for you, and voila.

-------- Advice --------

At first, before you try to fund an exchange account, send coins back to yourself on both chains and wait for a few confirmations to be sure you aren't shooting yourself in the foot. Cross check on the other chain to make sure you send the coins to the chain you intended.

-------- Disclaimer --------

It only makes sense but I'll remind it here: use this code at your own risk!
13  Bitcoin / Armory / 0.96.2 RC2 on: August 03, 2017, 06:02:02 AM
Time to test 0.96.2:

https://github.com/goatpig/BitcoinArmory/releases/tag/v0.96.1.2

Changes:

Quote
v0.96.2
== Added ==
   - Improved DB scan speed (~80% faster) and stability.
   - Reduced DB memory usage (~20% less).
   - Supernode DB mode. This isn't optimized for consumer grade computers, use at your own risk.
   - The MAX button in the Send dialog has been changed to a checkbox, effect is now binding.
     Maximum value will be calculated on any change.
   - You can now create OP_RETURN outputs from the Send dialog. This feature is only available in Expert mode.
   - You can now pick the signer of your choosing in Expert mode.
   - Added BCH on top of the legacy and 0.96 C++ signer.

== Fixed ==
   - Fixed benchmark timers on POSIX systems.
   - Fixed several Linux build configure bugs.
   - Properly update RPC state in GUI on connect/disconnect events.

== Removed ==
   - Removed armoryd from the repository. armoryd was moved to its own repository (https://github.com/goatpig/armoryd)


BCH miner howto: https://bitcointalk.org/index.php?topic=2070058.0

Happy testing =)
14  Bitcoin / Armory / Armory 0.96.1 is out! on: July 28, 2017, 02:41:07 AM
Builds available on the Github release page, as usual:

https://github.com/goatpig/BitcoinArmory/releases/tag/v0.96.1

Changelog (https://github.com/goatpig/BitcoinArmory/blob/v0.96.1/changelog.txt):

Quote
== Added ==
   - Raised default fee to 200 satoshi/Bytes. This fee will apply when using defaults and the node RPC is down.
     Any applied fee lower than that rate will trigger a warning message box. Users have to actively choose to
     bypass the warning.
   - Split unit tests building from default autotools setup. To build tests, use:
      ./configure --enable-tests.
   - You can now disable GUI in the autotools build system. Use:
      ./configure --without-gui
   - When spawned with a cookie file, the DB now randomizes its listen port to (49150 + [0-15000]) and reports it in the cookie file.
   - Added --fcgi-port command line argument to the DB
   - Address comments are now visible again in the Coin Control GUI
   - DB messages now have checksums; this improves error and version mismatch detection
   - Transactions that failed to broadcast throug the P2P layer will now be pushed to the RPC afterwards, if it's enabled
   - Refresh address view in Wallet Properties dialog on several user interactions.
   - RPC status is now signaled in the bottom right corner status bar. Disabled RPC will result in bold purple text.
   - Highly improved DB corruption self diagnosis and automated fixing.
   - Zero confirmation parser pool now is now capped at 100 threads.
     You can modify this value with the --zcthread-pool command line argument.

== Fixed ==
   - ZC parsing will no longer occur while the BDM is initializing
   - Wait on cookie file creation before connecting to auto managed DB
   - Fixed registration/callback premature garbage collection
   - Translation patch issues
   - Fixed "Fund from wallet" lockbox GUI
   - Fixed TxIn/Out pretty printing
   - Tied init phase spinning icon rotation to progress notifications. The icon will not spin when no progress data is received, correctly
     indicating the DB is hanging.   
   - Fixed cryptopp build against older CPUs (no AES or PCLMUL archs).
   - Fixed RBF bumping with no change.
   - Improved timestamps granularity in logs.
   - Improved transaction broadcast consistency.
   - Improved error message verbose of timed out transaction broadcasts.
   - ./configure --prefix now propagates correctly to Makefiles.
   - Fixed several memleaks in the database code.
   - Fixed false positive throws over bad packet detection in socketing layer.
   - Fixed coin selection edge cases.
   - Fixed the displaying of address comments in the lobby ledger.

== Removed ==
   - Python-twisted dependency. This should remove the underlying openSSL dependency as well.
   - Database command prompt will no longer appear when auto managing the DB on Windows

Note:

0.96.2 is in tow with lots of DB fixes and improvements and offline builds.
15  Bitcoin / Armory / 0.96.1 testing build #4 on: May 14, 2017, 09:32:57 PM
Third testing builds are out.

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

Binaries:
https://github.com/goatpig/BitcoinArmory/releases/tag/v0.96.0.4

Fixes/Changes:

Code:
v0.96.1

== Added ==
   - Split unit tests building from default autotools setup. To build tests, use:
      ./configure --enable-tests.
   - You can now disable GUI in the autotools build system. Use:
      ./configure --without-gui
   - When spawned with a cookie file, the DB now randomizes its listen port to (49150 + [0-15000]) and reports it in the cookie file.
   - Added --fcgi-port command line argument to the DB.

== Fixed ==
   - ZC parsing will no long occur while the BDM is initializing
   - Wait on cookie file creation before connection to auto managed DB
   - Fixed registration/callback premature garbage collection
   - Translation patch issues
   - Fixed "Fund from wallet" lockbox GUI
   - Fixed TxIn/Out pretty printing
   - Tied init phase spinning icon rotation to progress notifications. The icon will not spin when no progress data is received, correctly
     indicating the DB is hanging.  
   - Fixed cryptopp build against older CPUs (no AES or PCLMUL archs)
   - Fixed RBF bumping with no change

== Removed ==
   - Python-twisted dependency. This should remove the underlying openSSL dependency as well.

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

Linux users:

If the build fails to run on your setup (unknown instructions), it means your CPU is missing SSE4/AES/PCLMUL instructions. There will be a fail safe gcc4.7 build without any of those instructions for the actual release, but for the testing phase, you'll want to build the code directly on your machine. The build process has been fixed so you should have an easy time with it.

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

OSX users:

Added a build for this version.
16  Bitcoin / Armory / Armory 0.96 is out on: May 01, 2017, 09:35:25 PM
Binaries:

https://github.com/goatpig/BitcoinArmory/releases/tag/v0.96

changelog

https://github.com/goatpig/BitcoinArmory/blob/master/changelog.txt

Notable changes:

1) SegWit
2) RBF & CPFP
3) Translations
4) Compressed public keys
5) Reworked coin control and address tree UI
6) Fleshed out fee and privacy features

Better description on the webpage: https://btcarmory.com/0.96.0-release/

Notes:

Only putting out Windows x64 and Linux x64 builds atm. Offline bundles, RPi and OSX builds for 0.96.1, once I get rid of the twisted/openssl dependency. Eta 1-2 weeks.

Thanks:

achow101 for the support and translation PR, droark for the OSX support and the testers for helping tiddy things up.

Enjoy =)



17  Bitcoin / Armory / Armory 0.96 third testing builds on: March 31, 2017, 07:55:27 PM
Third testing builds, updated changelog. Added RBF auto fee bump from the ledger (right click a RBF zc to see the option)

Binaries: https://github.com/goatpig/BitcoinArmory/releases/tag/v0.95.99.3-testing

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

The changelog covers most of what's new with a couple caveats:

- Added CPFP and RBF. CPFP is accessible from the coin control GUI, RBF has its own. CPFP and RBF are mutually exclusive. The RBF GUI is up for change, this is just a tentative approach for now.

- Auto bitcoind woes should be fixed, give it a spin

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

I'll repeat the warning in the changelog for the good measure:

This version introduces new address types. These address types are not compatible with previous versions of Armory. Any version of Armory (or any wallet for that matter) can pay to these addresses, but only Armory 0.96 can spend from them. Naturally, the new features are opt-in, even code wise.

Legacy P2PKH addresses are untouched and can still be signed by anything 0.92+.

The SegWit address type is locked to testnet only.

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

I've spent to and from the new nested compressed key script on the mainnet. Regardless, I recommend to start with small amounts at first, as a precaution.
18  Bitcoin / Armory / 0.96 preliminary testing on: February 10, 2017, 12:19:43 AM
This time again.

Looking for people willing to build and try the dev branch. Changes can be seen here:

https://github.com/goatpig/BitcoinArmory/blob/dev/changelog.txt

This still needs some polish, but it's getting to the point where it's about done. SegWit is currently hardcoded disabled on mainnet, and enabled on testnet.

Due to the newly introduced script types, I strongly suggest people test this on testnet first before moving the mainnet.

Here is a list of what's missing/known as buggy, so that the testers can focus on what is supposed to be fully functional:

- The initialization progress bars are wacky atm.
- Still have to add a slider to the auto fee byte feature
- no .conf for the client yet
- have to redo the path settings GUI to go with the .conf addition
- still missing BIP9 rules detection to enable/disable SW
- armoryd is fubar

I'll be away from Friday to Monday, so don't expect me to reply to bug reports until then.

Happy testing!
19  Bitcoin / Armory / Armory 0.95.1 is out on: November 04, 2016, 02:48:46 AM
Just a few fixes, listed in the changelog:

https://github.com/goatpig/BitcoinArmory/releases/tag/v0.95.1

Code:
v0.95.1

== Added ==
   - Pass client datadir to auto spawned DB

== Fixed ==
   - Fixed coin control GUI
   - Fixed base58 decode edge case
   - Fixed db version detection
   - Fixed db error message reporting in GUI
   - Fixed explicit db port overwrite in testnet
20  Bitcoin / Armory / Armory 0.95 is out on: October 21, 2016, 08:27:47 PM
No changes since the last testing release (0.94.99.1). I've decided to sticky the latest stable release thread from now. Enjoy

Binaries:

https://github.com/goatpig/BitcoinArmory/releases/tag/v0.95.0

Changelog:

https://github.com/goatpig/BitcoinArmory/blob/v0.95.0/changelog.txt

- Forgot to bump the version and add the date in the changelog, will do for 0.95.1
- On windows, the automated DB will spawn a command line dialog. This wasn't the intention originally, but it goes a long way conveying the change in architecture. I've decided to leave it as is until 0.95.1.

*************************************

Botched auto bitcoind management on Windows,
you'll have to turn it off until I get a fix out.

**************************************
Pages: [1] 2 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!