Topic: Using Armory on the BCH chain - page 17. (Read 46022 times)
Got it - thanks!
This is what you need to know to treat your private key exports properly: you can reveal the private root of an Armory wallet with:
1) A chain of public keys tracing back to the public root.
1) A chain of public keys tracing back to the public root.
So if you dumped the BCH from all of your public keys on a single exchange, they could derive your private root from that info?
This is what you need to know to treat your private key exports properly: you can reveal the private root of an Armory wallet with:
1) A chain of public keys tracing back to the public root.
2) The chaincode (that's treated the same as public keys).
3) Any corresponding private key on that public chain.
The most conservative position is to consider the entire wallet compromised if you export even a single private key, and that's the position I hold both personally and officially.
1) A chain of public keys tracing back to the public root.
2) The chaincode (that's treated the same as public keys).
3) Any corresponding private key on that public chain.
The most conservative position is to consider the entire wallet compromised if you export even a single private key, and that's the position I hold both personally and officially.
This is what you need to know to treat your private key exports properly: you can reveal the private root of an Armory wallet with:
1) A chain of public keys tracing back to the public root.
1) A chain of public keys tracing back to the public root.
So if you dumped the BCH from all of your public keys on a single exchange, they could derive your private root from that info?
Are all 3 of the above required to compromise the private root?
Yes. That's what several here did, me included.Quote
AFAIK no, any of those should be considered a compromise.
Are you safe from the above if you sign the BCH transactions offline, and just broadcast the transactions using a block explorer? Or broadcast with your own bcash node, if you have one.
Ente
This is what you need to know to treat your private key exports properly: you can reveal the private root of an Armory wallet with:
1) A chain of public keys tracing back to the public root.
2) The chaincode (that's treated the same as public keys).
3) Any corresponding private key on that public chain.
The most conservative position is to consider the entire wallet compromised if you export even a single private key, and that's the position I hold both personally and officially.
1) A chain of public keys tracing back to the public root.
2) The chaincode (that's treated the same as public keys).
3) Any corresponding private key on that public chain.
The most conservative position is to consider the entire wallet compromised if you export even a single private key, and that's the position I hold both personally and officially.
Are all 3 of the above required to compromise the private root?
Are you safe from the above if you sign the BCH transactions offline, and just broadcast the transactions using a block explorer?
This is what you need to know to treat your private key exports properly: you can reveal the private root of an Armory wallet with:
1) A chain of public keys tracing back to the public root.
2) The chaincode (that's treated the same as public keys).
3) Any corresponding private key on that public chain.
The most conservative position is to consider the entire wallet compromised if you export even a single private key, and that's the position I hold both personally and officially.
1) A chain of public keys tracing back to the public root.
2) The chaincode (that's treated the same as public keys).
3) Any corresponding private key on that public chain.
The most conservative position is to consider the entire wallet compromised if you export even a single private key, and that's the position I hold both personally and officially.
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 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.
let's say the online computer one uses to import the private key containing the BCH has malware. even if the key is compromised, it doesn't help the attacker derive your other private keys without him also having the chain code, correct?
does this change if one imports several private keys to claim BCH, all of which get compromised, even though they don't have the chain code? IOW, can the master private key be derived by using correlation? i wouldn't think so since that's the point of the chain code; to make each deterministic key function like a totally randomized key.
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 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.
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 true, wouldn't that be a simpler method to claim BCH than fiddling with all the truncated blockchain tricks?
Start the DB manually with your custom paths (consider using armorydb.conf for that), then run the client.
Thanks goatpig. that really helps conceptually.
i'm having trouble connecting to that USB connected drive with the truncated /.bitcoin/blocks folder from the genesis block to blk00660.dat. no tx's have taken place between 660 and post fork.
Bitcoin is installed here: /home/debian/Downloads/bitcoin-0.15.0/bin
Armory is installed here, with a fresh empty Databases folder inside: /home/debian/.armory
when trying to run ArmoryQT with controlling bitcoin, i get this. :
any help would be appreciated.
i'm having trouble connecting to that USB connected drive with the truncated /.bitcoin/blocks folder from the genesis block to blk00660.dat. no tx's have taken place between 660 and post fork.
Bitcoin is installed here: /home/debian/Downloads/bitcoin-0.15.0/bin
Armory is installed here, with a fresh empty Databases folder inside: /home/debian/.armory
when trying to run ArmoryQT with controlling bitcoin, i get this. :
Code:
debian@debian:~/.armory$ armory --satoshi-datadir=/media/debian/UNTITLED/.bitcoin
/home/debian
(ERROR) ArmoryUtils.py:3716 - Unsupported language specified. Defaulting to English (en)
/usr/local/lib/armory/armoryengine/Transaction.py:2882: SyntaxWarning: import * only allowed at module level
def PyCreateAndSignTx_old(srcTxOuts, dstAddrsVals):
(WARNING) SDM.py:439 - Spawning bitcoind with command: /usr/local/bin/bitcoind -datadir=/media/debian/UNTITLED/.bitcoin
(WARNING) SDM.py:396 - Spawning DB with command: ArmoryDB --db-type="DB_FULL" --cookie --satoshi-datadir="/media/debian/UNTITLED/.bitcoin/blocks" --datadir="/home/debian/.armory/" --dbdir="/home/debian/.armory/databases"
(ERROR) ArmoryQt.py:1198 - 8 attempts to load blockchain failed. Remove mempool.bin.
(ERROR) ArmoryQt.py:1203 - File mempool.bin does not exist. Nothing deleted.
-ERROR - �R��: (StringSockets.cpp:351) FcgiSocket::writeAndRead FcgiError: unexpected fcgi header version
-ERROR - �R��: (StringSockets.cpp:351) FcgiSocket::writeAndRead FcgiError: unknown fcgi header request byte
-ERROR - �R��: (StringSockets.cpp:351) FcgiSocket::writeAndRead FcgiError: unknown fcgi header request byte
-ERROR - �R��: (StringSockets.cpp:351) FcgiSocket::writeAndRead FcgiError: unknown fcgi header request byte
-ERROR - �R��: (StringSockets.cpp:351) FcgiSocket::writeAndRead FcgiError: unknown fcgi header request byte
-ERROR - �R��: (StringSockets.cpp:351) FcgiSocket::writeAndRead FcgiError: unknown fcgi header request byte
-ERROR - �R��: (StringSockets.cpp:351) FcgiSocket::writeAndRead FcgiError: unknown fcgi header request byte
-ERROR - �R��: (StringSockets.cpp:351) FcgiSocket::writeAndRead FcgiError: unknown fcgi header request byte
-ERROR - �R��: (StringSockets.cpp:351) FcgiSocket::writeAndRead FcgiError: unknown fcgi header request byte
any help would be appreciated.
Granted, the only thing you are actually after is the blk file with the first post fork block. If that one is taken out, Armory can compute the chain past the fork point and you should be good.
since i have done some tx's of BTC post fork, i have to use your trick of this truncated blockchain from what i understand. will this block file range work?Only if you have not moved coins on the prefork chain past that point.
The logic is as follows: your last set of valid utxos pre fork is still valid on the Bcash chain (up until the point you move your bcash). If you roll back the BTC blockchain to a point in time where it stands past your last valid utxo set state and before you moved coins post fork on the BTC chain, these utxos are also valid on the Bcash chain.
Graphically, it would look like this:
Code:
]--------V------------F-------M--------[
- F is the fork point. Anything past F is the Bitcoin side of the fork on this graphic.
- V is the last block you transacted in pre fork. This is your last valid utxo set state pre fork.
- M is the first block you transacted in post fork on the Bitcoin side.
- Transacted means both sending and receiving coins.
Any chain tip between V and M has the utxo set state you need to move coins on the Bcash side of the fork (as there is no divergence in utxo sets yet in between the 2 sides of the fork).
So what you want to do is to feed Armory a copy of the chain with the tip belonging to [V, M[
Granted, the only thing you are actually after is the blk file with the first post fork block. If that one is taken out, Armory can compute the chain past the fork point and you should be good.
i'm not sure i follow what you're saying here. are you saying i have to load a blockchain btwn zero and the "one block file with the first post fork block" to make your trick work?
i was under the impression that if i loaded a blockchain that was anywhere pre-fork, let's say btwn block files 0-660, that would be sufficient. the reason i say this is that i found an old USB stick with a copy of the blockchain in that block file range. since i have done some tx's of BTC post fork, i have to use your trick of this truncated blockchain from what i understand. will this block file range work?
rev files shouldn't matter at all, they're only relevant for Core's reorgs. What you need to nuke as well is your ArmoryDB (if you're not going to use a fresh folder).
Also, there's no guarantee file 949 will do it for you. Core does not download files sequentially, there's a chance post fork blocks are embedded somewhere deeper down your blk files. This file # is only relevant if your node was running at the time of the fork. If you caught up for more than a day of blocks after the fork, chances are you have post fork blocks all over the place. Granted, the only thing you are actually after is the blk file with the first post fork block. If that one is taken out, Armory can't compute the chain past the fork point and you should be good.
Also, there's no guarantee file 949 will do it for you. Core does not download files sequentially, there's a chance post fork blocks are embedded somewhere deeper down your blk files. This file # is only relevant if your node was running at the time of the fork. If you caught up for more than a day of blocks after the fork, chances are you have post fork blocks all over the place. Granted, the only thing you are actually after is the blk file with the first post fork block. If that one is taken out, Armory can't compute the chain past the fork point and you should be good.
OK it all worked for me now. Thanks for the help. One of the issues was that I had only deleted one type of file from the blocks folder and not the other. So file 0949 was actually OK in the end. Broadcasted the raw tx and currently receiving BCH. Now almost done consolidating all my BCH....
are you saying we also have to delete the rev*****.dat files from today back to 00949 from the blocks directory/file?
is that all we have to delete to claim BCH?
Read the "Tricks" section
it appears to me that BCH isn't going anywhere. is it possible to make an easier to use BCH claim tool that doesn't involve building a custom blockchain, similar to what Trezor has done?
Thanks for the explanation!
-------- Privacy ---------
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:
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.
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:
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.
Could you elaborate on this? In what sense is BTC privacy compromised after dumping BCH?
At the time of the fork, you had BTC and bcash 1:1 on the same addresses. So if someone learns your bcash addresses, she knows you have the same amount in BTC on the same BTC address. Prime example, of course, would be an exchange. They might learn your bcash = BTC addresses as well as your bcash = BTC holdings.
Basically all the same as privacy concerning Bitcoin before.
Ente
-------- Privacy ---------
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:
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.
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:
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.
Could you elaborate on this? In what sense is BTC privacy compromised after dumping BCH?
Jump to: