 Show Posts
|
|
Pages: [1] 2 »
|
|
0.97 RC1 is ready. You can find the *one* binary on the github release page.
There's a ton that's changed and no changelog yet. The purpose of this release is to get some testing and bug reports. Do not expect something plug and play.
This phase is to provide a stable and solid baseline of Armory features on modern operating systems. Fancy features will be reintroduced via minor versions of 0.97.
New stuff will come in 0.98.
Here's a quick summary of what's going on in this release candidate:
- Startup -
There's a new settings manager that pops before the lobby. It will help you navigate your setup before starting Armory.
It comes with 3 tabs, the features should be self explanatory:
. wallets: lets you manage your wallets before loading them into the lobby. For now this mostly helps with migrations, but it will also be needed to unlock wallets later. That's a new feature, you can ignore it for now.
. database: this helps you with managing your connection to the db. You can let it automate the db for you or try to connect to an existing instance, either local or remote. All modes encrypt the traffic, nothing is in clear text.
Recommendation for now is to let it automate. If that fails, you can run the db manually then connect to it through this tab, before starting the lobby. UI is still a bit wonky and mileage may vary.
. core: disabled for now, nothing implemented yet.
- Wallets -
There is a new wallet format with a requirement to migrate your old wallets to it. Setup manager will help you with that but you can also skip that step and import from the wallet menu in the lobby.
Old wallets cannot be loaded as is, you have to either import them from the respective files, or restore from the backup string. Migration does not affect the old files, it only creates new files.
New wallets have a .lmdb extention and do not carry the same wallet id as the old ones. This is a quirk of the new format and does not affect what keys the wallet carries.
When migrating from a wallet file, you will be asked to unlock to private keys (if it has any). You can choose not to, at which point you'll receive a watching only version of the wallet. Migration is preferable to restoring from seed, as it will carry over chain length, comments and timestamps, which a string backup cannot provide.
New wallets are fully encrypted. That means both public and private data. There are 2 passwords as a result, one for the private keys, and one for the public keys. There is currently no GUI implemented to set public data passwords. The feature is transparent to users for now. Eventually I'll add the GUI.
New wallets can also carry much more than just key data. There's a plan to let them carry block data, so that wallet balance and history can be viewed while offline, and that data can be carried over across wallets as well, meaning you could eventually check your history up to the last known block on your offline machine, as well as generate transactions in a purely offline setup, with no db.
BIP32/39/44 support has been added, but there is once again no GUI for it. I hate GUI development and end up doing other stuff everytime I'm faced with it. I had a guy helping me with that for a while but he dissapeared a couple months ago, so here we are.
- Signer -
There's of course a new signer format, but there's also a compability mode. If you're spending from a legacy format address, i.e. anything generated by 0.96.5 and prior, there's an option to generate a legacy unsigned tx. This means you can test this stuff out without messing with your offline setup, for the most part.
- database -
Entirely new design, leaner and meaner, you will have to let it build from scratch. Simplest thing is to delete your old 0.96.5 database, or copy it to some other place, or point to a new db path via the setup manager. Eventually I'll add version detection and fail safes, but this isn't for this cycle IMO.
DB_BARE has been reintroduced. This is now the default mode. It builds the whole thing in about 20min on my desktop (5950x, 32GB RAM, gen4 nmve). The final db is ~1GB in size. RAM usage should be a lot lower, it idles around 2GB for me atm. The goal is to get this mode to setup on my laptop (5700U, 16GB RAM, gen3 nvme) in under 2 hours.
DB_FULL is still there, it comes with full tx resolution. I'm still working on that and while it is functional, I highly recommend you stay away from this for now. It needs a lot of optimizations yet. It isn't useful for day to day Bitcoin operations at any rate, this is more of a mode for Lightning support. I'll get to that eventually (TM).
DB_SUPER is disabled, will rework as well at some point.
- builds -
. Linux: there is no build for linux in this cycle. IDK what distro to target nor do I have the time to generate packages. I'll get around to that eventually, but for now, Linux testers will have to build from source. Pull the tag and read the build instructions. As far as my own testing goes, I dev on arch and have moved coins on the mainnet with this code multiple times.
. Windows: the RC comes with a Windows build. This was built on baremetal win11 (i shoved a ssd into my desktop and installed win11 there). It starts, loads wallets and whatnot, but I have not tried mainnet with it (the ssd is too small). Looking to feedback on this platform.
The build is a stand alone zip. Check the hash/signature, then unzip it and browse into it. Run ArmoryQt.exe and pray. This is built with mingw now instead of msvc.
Note that one Windows, there is some quirk where file operation may hang for up to a couple minutes. I have an idea of what's going on but have yet to debug it.
. OSX: I do not own a Mac nor have an the faintest idea how to build on that platform. Open to contributions!
- Notes -
I have to go away for at least 5 weeks for personal matters. I wont have access to my windows setup as well as my offline signer for that period of time. I'm taking a second SSD with me and I'll try to setup windows on it for my laptop, but no guarantees. I've pushed the RC hoping to get feedback and bug reports, which I'll try to fix in the 5 weeks window, at which point I'll be able to deliver RC2 once I get back home.
|
|
|
|
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 |
|
|
|
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== 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.
Binarieshttps://github.com/goatpig/BitcoinArmory/releases/tag/v0.96.5Happy holidays! |
|
|
|
Fixed all the stuff reported for RC1, this should be the final RC for this version. Changes - 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.
Binarieshttps://github.com/goatpig/BitcoinArmory/releases/tag/v0.96.4.991RC1 threadhttps://bitcointalk.org/index.php?topic=5071932.0 |
|
|
|
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. Changelogv0.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.99Test away! |
|
|
|
links: https://github.com/goatpig/BitcoinArmory/releases/tag/v0.96.4https://btcarmory.com/0.96.4-release/changelog: == 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.
|
|
|
|
Binaries:https://github.com/goatpig/BitcoinArmory/releases/tag/v0.96.3.991Notes: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
|
|
|
|
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
|
|
|
|
NotesThis 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.0Binarieshttps://github.com/goatpig/BitcoinArmory/releases/tag/v0.96.3Changelog== 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
|
|
|
|
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 storyA 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 SSSSSS 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: 8 = 5 + x
It's obvious that x is 3, and that this is the only solution. Now add this variation to the equation: 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 vulnerabilityThe 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 codeCode wise, there were 2 instances of this implementation, both of which are faulty. a) The first versionIt 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: coefficient_0 = hash(secret)
coefficient_(n+1) = hash(coefficient_n)
The fragments themselves were constructed as the following points on the curve: 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-27fe88d2c6032fecb93912a17d72081bR1615b) The second versionThe 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-27fe88d2c6032fecb93912a17d72081bR19155) Affected versionsFragmented 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 fixThe 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/94d2a7556d25cf788da639d81a7162694982f6b7https://github.com/goatpig/BitcoinArmory/commit/7bd9887891ac88e2e49954ef034bedef88f23eaf7) GUI changesSince 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 ) RecommendationsIt 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) NotesSpecial thanks to Gregory Maxwell for finding the vulnerability and helping with the review of the fix. |
|
|
|
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: == 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.2Note: OSX and offline RPi packages are on the way. |
|
|
|
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/9zXGDOnce 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! |
|
|
|
Time to test 0.96.2: https://github.com/goatpig/BitcoinArmory/releases/tag/v0.96.1.2Changes: 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.0Happy testing =) |
|
|
|
Builds available on the Github release page, as usual: https://github.com/goatpig/BitcoinArmory/releases/tag/v0.96.1Changelog ( https://github.com/goatpig/BitcoinArmory/blob/v0.96.1/changelog.txt): == 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. |
|
|
|
Third testing builds are out. ------------------ Binaries:https://github.com/goatpig/BitcoinArmory/releases/tag/v0.96.0.4Fixes/Changes: 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. |
|
|
|
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. |
|
|
|
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.txtThis 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! |
|
|
|
Just a few fixes, listed in the changelog: https://github.com/goatpig/BitcoinArmory/releases/tag/v0.95.1v0.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
|
|
|
|
|
