Good to hear, thanks.
Would you recommend creating new wallets for this? And/or will this coincide with the migration to the new wallet format?
Ente
Most likely I'll add support for this in mirror wallets before the new wallets are out. |
|
|
|
|
AFAIK bech32 is only for v0 native SW scripts. I'll get it in there at some point.
|
|
|
|
|
I believe it's some sort of OP_RETURN output. You can create those in Armory if you are set to expert mode.
|
|
|
|
is it true that i can simply scan a BCH encumbered private key into a BCH enabled wallet, like Electron Cash, to claim my BCH even after i've sent the BTC away?
if true, wouldn't that be a simpler method to claim BCH than fiddling with all the truncated blockchain tricks?
If you export private keys, you have to consider the wallet compromised and cycle it. That means your backups are done for too. Choose accordingly. |
|
|
|
|
Nothing in there that's really helpful, sorry
|
|
|
|
What is the new memory usage limit for wallet decryption?
Was never changed. |
|
|
|
I assume that if I use any of the new P2SH-based addresses in Armory, I no longer have that option; i.e. I can get my private keys out of Armory but I cannot make the corresponding scripts in another wallet, and therefore cannot (easily) spend the funds.
The P2SH-P2PK script is most likely unique to Armory. The P2SH-P2WPKH one is actually "standard" as it appears in the original BIP as one of the script types required for SegWit support. Other wallets out to provide that. EDIT: I don't think the risk is vanishing. If goatpig had not picked it up, Armory development would have stopped after etotheipi stopped working on the open source version. And at least once did the Bitcoin network implement a soft fork that required an Armory update before it could sign transactions again.
1) Someone could just as easily look at the code and make it spit all script variations if support disappears. 2) If the wallet you are using stop being developed, do yourself a favor and move your coins out before the most recent version turns obsolete. 3) Eventually there will be someone who'll figure there's demand for wallet interchangeability and will write an offline tool. |
|
|
|
|
I'm aware of this, should be fixed in the testing branch.
|
|
|
|
I doubt that side-channel attacks are at all relevant for paper backups. That normally requires statistical data on the timing or the amount of power it takes to do the operation. It might be a worry that a compromized computer can gain information from a hardware wallet through side channels, but not when restoring a wallet.
My guess is that the main problem with SSS is that it is one of the few cryptographic operations that are simple enough that people implement it themselves, instead of getting it from a peer-reviewed and well-debugged library.
If you are using constant time AES and ECDSA, the only time to perform a timing attack is at restore time, which only applies to SSS in this case (assuming it's not in constant time). SSS does not just have a plausible deniability edge over multisig scripts (I am sure it does, although I cannot see how).
1) You have assume any skilled/well equipped attacker will always get access to your watching only wallet (think law enforcement raiding your home). 2) This means an attacker will know not only of all your coins on chain, but also have access to all the script hash preimage. Therefor, if you used multisig, they will know of this as well. 3) On the other hand, SSS allows you to split your backups without reflecting that on chain, i.e. you could have all your coins in single sig scripts and there is no way for the attacked to know this just with your WO wallet. |
|
|
|
|
I don't get it, you still having the issue or not?
|
|
|
|
can you name some of the lightweight clients
I don't use light wallets myself. People in here tend to recommend Electrum, so ask them or go with that straight up. Ideally, you could also research light wallets a bit, since you probably have coins stuck in Armory because you did not research the wallet at all before using it. any instructions on how to sweep the private keys from armory client
You can get to your private keys from the "Backup Center". You get access to that from the wallet properties dialog, clicking the "Backup this wallet" button on the left side of the window. As for importing them into another wallet, do your research, or ask the community of the receiving wallet. Bottom line, you need to invest some time researching the software you're going to use in this space. That will save everybody time and for you specifically, a whole lot of grief. |
|
|
|
|
I'm no OSX expert. At this point I'd suggest you just run a Ubuntu VM and run Armory off of that.
|
|
|
|
another question related to this, since we are already discussing about segwit address.
If one private key can generate a P2PKH address and a segwit address, when you spend from the P2PKH address, will the spending also reflect on the segwit address? I mean you are spending from the same private key, which hold just one amount of bitcoin right?
That's not how it works. Read up on UTXOs. The wallet won't let you mismatch script types for a given private key anyways. |
|
|
|
|
You may want to push the discussion on BIP124, which is the closest proposal to something like this. ATM there's no standard amount wallet services on what script types to process for which derivation scheme and/or private key.
Your target wallet service will most likely not even carry the code to produce the relevant script as it stands.
|
|
|
|
|
The addresses are p2sh, that's not gonna do you much good if you dont have the hash preimage either. What are you trying to achieve here? Check balances on an explorer?
|
|
|
|
|
Priceless =D
Chances are your coins are fine, but with an attitude like yours, chances are no one will ever care to help you recover them either. God speed to you, friend.
|
|
|
|
|
I'd have to see some logs.
|
|
|
|
In case I am 100% sure that the fragments have not been compromised (sealed envelopes, under the custody of people whom I trust), would it be possible to :
- install Armory 0.96.3 on a fresh machine,
- restore the current wallet here (originally generated with Armory 0.93.3)
- print new "secure" fragments of the same wallet,
- destroy the old fragments and the machine ?
You should cycle the wallets if you're going to bother printing new fragments. Better safe that sorry. Who knows where sha256 will be 30 years from now. Would Armory 0.93.3 be able to restore a newly printed wallet in case of need ?
The restoration code is the same, but the fragment IDs are not deterministic anymore, so it's possible the GUI will refuse to proceed further with newly generated fragments until you comment out that check from the Python code. In other words, it can work if you're willing to deal with a little Python. |
|
|
|
|
Start the DB manually with your custom paths (consider using armorydb.conf for that), then run the client.
|
|
|
|
|
Show Posts
