Bitcoin Vaults, Cold Storage, Hot Wallets - What's your cryptocurrency solution?
425 views
Skip to first unread message
k.c.l....@gmail.com
Oct 24, 2015, 11:35:12 PM10/24/15
to qubes-users
tl;dr - Create air-gapped cold wallet appvm with Bitcoin Armory. Create Tor connect Hot wallet from cloned template. Use hardware encrypted USB backup to deep freeze your wallet.
I have been in the process of building Bitcoin VMs and trying to find elegant solutions for hot and cold wallets.
I am using Bitcoin Armory (https://github.com/etotheipi/BitcoinArmory) for my wallet software, which I am a big fan of.
My current solution has been to build Bitcoin Armory from source in a fedora-21-minimal TemplateVM.
This TemplateVM is then cloned. Inside the TemplateVM clone, I build bitcoind (https://github.com/bitcoin) from source. (Alternatively, BitcoinArmory will also securely download and install bitcoind for you).
Store blockchain and armory databases on root.img, so they can be shared with all appvms:
Once the entire blockchain has been synchronized, Bitcoin Armory creates its own database, which will be stored in /usr/share/armory/databases. This will be the same size as the blockchain.
This means, in your HOT WALLET template, you will need > 90GB of free space in your root.img.
In Dom0:
Now you can start armory, to download blockchain and/or build your database:
This will cause Armory to run, which automatically starts bitcoind. Click through, and skip creating a wallet. If you downloaded bootstrap.dat ahead of time, it will automatically detect the symlinked bootstrap.dat file in /usr/share/bitcoin if you place it there. You can also have bitcoind download the blockchain, and it will automatically be saved to /usr/share/bitcoin/blocks.
Once you have the entire blockchain synchronized, and your database built, it's time to create the AppVMs, and set their NetVMs. Your cold wallets will never touch the internet, and the hot wallets will use whonix to connect to tor.
Now with your new BTC-Cold-VM, you can create Cold, Offline Wallets. To accomplish this, we will create a brand new wallet in BTC-Cold-VM. We create encrypted backups (Both digital and paper). The backups can be stored inside your KeePassX-2b2 database in your BTC-VaultVM. (KeePassX 0.4.3 does NOT allow for multiple attachments per entry).
I use the KeePassX database to store a copy of my password, the wallet itself, and the PDF backup. Along with any notes, such as the word matrix that can be used to rebuild the wallet (PGP Signed), and PGP Signed Paper Wallet encryption keys. The database is kept in my air-gapped BTC-VaultVM. I send my encrypted backups to the BTC-VaultVM using Qubes' secure file transfer. The BTC-VaultVM is backed up with encryption to a hardware encrypted USB drive.
I also use a Key file for each of my KeePassX databases. Those keys are stored in a separate Key-VaultVM, which gets backed up to a SEPARATE Hardware Encrypted USB Drive. (This vault also stores backups of PGP Keys, and other keyfiles for other locked containers. ie Tomb Key Files)
Now we create our WATCH-ONLY copy of our wallet. Once the watch-only copy is created, we right-click on the file in Nautilus, and hit "Move to AppVM", and type in BTC-Hot-VM. We have now sent a watch-only copy to our VM with our Hot Wallet.
See: https://bitcoinarmory.com/tutorials/armory-advanced-features/offline-wallets/
Now we can import an existing wallet and point it to ~/QubesIncoming/BTC-Cold-VM/Watch_Only.wallet
You will want to tell Armory that this wallet belongs to you.
Now, Armory can and will generate payment addresses for the cold storage wallet, but it will NOT be able to spend them. So even if your BTC-Hot-VM becomes compromised, they will not be able to spend any of the BTC, which will be residing securely in your air-gapped cold storage wallet, on your hardware encrypted USB drive, and your BTC-VaultVM.
Because we connected our hotwallet to Whonix-Gateway, our BTC transactions will not be tied to our IP address.
In order to spend BTC from our Cold Wallet, we will need to create an OFFLINE TRANSACTION with our Online Wallet. The transaction is then sent via Secure File Transfer or Secure Copy/Paste, to be signed by our offline wallet. The transaction is then sent back to the online wallet to be finalized and broadcast to the network (via Tor).
We can also create new AppVMs based on the BTC-Hot-Wallet, and generate spending wallets. These AppVMs can then be attached to various ProxyVMs VPN-VMs, Whonix-Gateways, or whatever is appropriate for your use case. These are for immediate spending.
In order to "Deep Freeze" your Cold Wallet, create a new DispVM based on your Cold Wallet Template. Now, create a new wallet with armory, and create your encrypted backups, and your watch-only backup. Send your encrypted backups to your USB drive. Send your watch-only to your BTC-Hot wallet.
Once your backups are securely in place, close your disposable VM.
Now there is no wallet even for offline transactions. The BTC sent to the cold wallet cannot be spent without restoring your wallet from your encrypted backup (which should be stored off site, with family and/or attorney).
Now, if you are receiving regular BTC, you can send X% to Deep Frozen Storage, for long term savings, Y% to offline cold wallet for mediem term savings, and Z% of BTC to Hot Wallet for immediate spending.
Notes:
When this system was created, I was unaware of how to install debian-8-minimal in R3.0. Bitcoind is in the debian sid repos, but not Jessie, and not anywhere in Fedora. So, building everything from the github source in fedora-21-minimal, caused the "minimal" image to balloon up. Now, if it's your hot wallet, and it's going to be 100GB anyway, maybe this is no big deal. But if you are like me, and like to keep everything as lean as possible, you either want to remove all the build tools after you are done, or you want to just get some trusted signed binaries from a repo that stays up to date. To get bitcoind installed in Debian Jessie, what I usually do is a dist-upgrade with the Jessie repos, and then switch my main repo to sid, run:
This way I don't forget to change back to Jessie, before doing another dist-upgrade.
(I have a habit of running the following command, and then walking away a lot)
WCGW, right?
Anyway, this will not allow you to get fast updates for bitcoind. But on the bright side, Armory has a little announcement panel that will tell you whenever there's updates for Bitcoin or Armory. Unfortunately, only if you're using an online wallet, AND not connected through tor. That being said, if you're installing from GitHub, you're probably not getting updates pushed to you anyway.
The point is, you should make sure you are keeping your software up to date. I install all my software to /opt/ (keepassx2, bitcoinarmory, bitcoind, apt-fast, etc etc), so I have to make an effort to keep those things up to date.
What i would like to discuss now is the security implications of using multiple wallets within the same AppVMs. If they are all cold offline wallets, does it matter? Might it be a better solution then to use a standalone VM?
For online wallets, can Tor Stream Isolation be reliably implemented to make it unnecessary for multiple hot wallet VMs? What are the security and anonymity implications of using multiple Bitcoin based AppVMs connected to the same NetVm/ProxyVM/FirewallVM?
What I am still investigating, is pointing Armory Hot Wallets to the Whonix Gateway Socks Port, in order to take advantage of stream isolation. Rather than using a transparent proxy. If other VMs are connected to same Whonix-Gateway with transparent proxificatin , you are probably risking identity correlation.
So for the time being, I am recommending a dedicated Whonix-Gateway for each Hot Wallet. In the Armory Preferences, you can turn on Tor Support. But it does not seem to give you the option to choose your server, or port. This needs to be investigated.
This should probably be tested by disabling transparent proxy in your Whonix-Gateway, and then trying to get Armory to connect.
What is your preferred BTC-VaultVM OS Template? Debian? Fedora? Arch?
I know Electrum is a much more popular wallet cient. I haven't used it much. What are peoples' thoughts on it? It doesn't need to download the blockchain, right? So, that would save me 100GB. Is it as secure? I would have to assume not, but it's packaged with Tails now, so maybe it's worth another look.
I have been in the process of building Bitcoin VMs and trying to find elegant solutions for hot and cold wallets.
I am using Bitcoin Armory (https://github.com/etotheipi/BitcoinArmory) for my wallet software, which I am a big fan of.
My current solution has been to build Bitcoin Armory from source in a fedora-21-minimal TemplateVM.
This TemplateVM is then cloned. Inside the TemplateVM clone, I build bitcoind (https://github.com/bitcoin) from source. (Alternatively, BitcoinArmory will also securely download and install bitcoind for you).
Store blockchain and armory databases on root.img, so they can be shared with all appvms:
$ sudo mkdir /usr/share/bitcoin/ && ln -s /usr/share/bitcoin/bootstrap.dat ~/.bitcoin/bootstrap.dat && ln -s /usr/share/bitcoin/blocks ~/.bitcoin/blocks && chown user:user /usr/share/bitcoin -R
$ sudo mkdir /usr/share/armory/databases && ln -s /usr/share/armory/databases ~/.armory/databases && chown user:user /usr/share/databases -R
$ ln -s /opt/BitcoinArmory/ArmoryQt.py /usr/bin/armory ## make it a little easier to start armory using qvm-run.
Once the entire blockchain has been synchronized, Bitcoin Armory creates its own database, which will be stored in /usr/share/armory/databases. This will be the same size as the blockchain.
This means, in your HOT WALLET template, you will need > 90GB of free space in your root.img.
In Dom0:
$ truncate -s 100G /var/lib/qubes/vm-templates/BTC-Hot-Template/root.img
$ qvm-run -a BTC-Hot-Template "sudo resize2fs /dev/mapper/dmroot && sudo reboot"Now you can start armory, to download blockchain and/or build your database:
$ qvm-run -a BTC-Hot-Template armory
This will cause Armory to run, which automatically starts bitcoind. Click through, and skip creating a wallet. If you downloaded bootstrap.dat ahead of time, it will automatically detect the symlinked bootstrap.dat file in /usr/share/bitcoin if you place it there. You can also have bitcoind download the blockchain, and it will automatically be saved to /usr/share/bitcoin/blocks.
Once you have the entire blockchain synchronized, and your database built, it's time to create the AppVMs, and set their NetVMs. Your cold wallets will never touch the internet, and the hot wallets will use whonix to connect to tor.
$ qvm-create BTC-Hot-VM -t BTC-Hot-Template -l red && qvm-create BTC-Cold-VM -t BTC-Cold-Template -l green && qvm-prefs -s BTC-Cold-VM netvm none && qvm-prefs -s BTC-Hot-VM netvm Whonix-GatewayNow with your new BTC-Cold-VM, you can create Cold, Offline Wallets. To accomplish this, we will create a brand new wallet in BTC-Cold-VM. We create encrypted backups (Both digital and paper). The backups can be stored inside your KeePassX-2b2 database in your BTC-VaultVM. (KeePassX 0.4.3 does NOT allow for multiple attachments per entry).
I use the KeePassX database to store a copy of my password, the wallet itself, and the PDF backup. Along with any notes, such as the word matrix that can be used to rebuild the wallet (PGP Signed), and PGP Signed Paper Wallet encryption keys. The database is kept in my air-gapped BTC-VaultVM. I send my encrypted backups to the BTC-VaultVM using Qubes' secure file transfer. The BTC-VaultVM is backed up with encryption to a hardware encrypted USB drive.
I also use a Key file for each of my KeePassX databases. Those keys are stored in a separate Key-VaultVM, which gets backed up to a SEPARATE Hardware Encrypted USB Drive. (This vault also stores backups of PGP Keys, and other keyfiles for other locked containers. ie Tomb Key Files)
Now we create our WATCH-ONLY copy of our wallet. Once the watch-only copy is created, we right-click on the file in Nautilus, and hit "Move to AppVM", and type in BTC-Hot-VM. We have now sent a watch-only copy to our VM with our Hot Wallet.
$ qvm-run -a BTC-Hot-VM armory
See: https://bitcoinarmory.com/tutorials/armory-advanced-features/offline-wallets/
Now we can import an existing wallet and point it to ~/QubesIncoming/BTC-Cold-VM/Watch_Only.wallet
You will want to tell Armory that this wallet belongs to you.
Now, Armory can and will generate payment addresses for the cold storage wallet, but it will NOT be able to spend them. So even if your BTC-Hot-VM becomes compromised, they will not be able to spend any of the BTC, which will be residing securely in your air-gapped cold storage wallet, on your hardware encrypted USB drive, and your BTC-VaultVM.
Because we connected our hotwallet to Whonix-Gateway, our BTC transactions will not be tied to our IP address.
In order to spend BTC from our Cold Wallet, we will need to create an OFFLINE TRANSACTION with our Online Wallet. The transaction is then sent via Secure File Transfer or Secure Copy/Paste, to be signed by our offline wallet. The transaction is then sent back to the online wallet to be finalized and broadcast to the network (via Tor).
We can also create new AppVMs based on the BTC-Hot-Wallet, and generate spending wallets. These AppVMs can then be attached to various ProxyVMs VPN-VMs, Whonix-Gateways, or whatever is appropriate for your use case. These are for immediate spending.
In order to "Deep Freeze" your Cold Wallet, create a new DispVM based on your Cold Wallet Template. Now, create a new wallet with armory, and create your encrypted backups, and your watch-only backup. Send your encrypted backups to your USB drive. Send your watch-only to your BTC-Hot wallet.
Once your backups are securely in place, close your disposable VM.
Now there is no wallet even for offline transactions. The BTC sent to the cold wallet cannot be spent without restoring your wallet from your encrypted backup (which should be stored off site, with family and/or attorney).
Now, if you are receiving regular BTC, you can send X% to Deep Frozen Storage, for long term savings, Y% to offline cold wallet for mediem term savings, and Z% of BTC to Hot Wallet for immediate spending.
Notes:
When this system was created, I was unaware of how to install debian-8-minimal in R3.0. Bitcoind is in the debian sid repos, but not Jessie, and not anywhere in Fedora. So, building everything from the github source in fedora-21-minimal, caused the "minimal" image to balloon up. Now, if it's your hot wallet, and it's going to be 100GB anyway, maybe this is no big deal. But if you are like me, and like to keep everything as lean as possible, you either want to remove all the build tools after you are done, or you want to just get some trusted signed binaries from a repo that stays up to date. To get bitcoind installed in Debian Jessie, what I usually do is a dist-upgrade with the Jessie repos, and then switch my main repo to sid, run:
$ sudo apt-get install bitcoind -y && sudo nano /etc/apt/sources.list
This way I don't forget to change back to Jessie, before doing another dist-upgrade.
(I have a habit of running the following command, and then walking away a lot)
$ sudo apt-get update && sudo apt-get upgrade -y && sudo apt-get dist-upgrade -y && sudo apt-get autoremove -y && sudo apt-get autoclean && clear && history -cw && exit/halt
Anyway, this will not allow you to get fast updates for bitcoind. But on the bright side, Armory has a little announcement panel that will tell you whenever there's updates for Bitcoin or Armory. Unfortunately, only if you're using an online wallet, AND not connected through tor. That being said, if you're installing from GitHub, you're probably not getting updates pushed to you anyway.
The point is, you should make sure you are keeping your software up to date. I install all my software to /opt/ (keepassx2, bitcoinarmory, bitcoind, apt-fast, etc etc), so I have to make an effort to keep those things up to date.
What i would like to discuss now is the security implications of using multiple wallets within the same AppVMs. If they are all cold offline wallets, does it matter? Might it be a better solution then to use a standalone VM?
For online wallets, can Tor Stream Isolation be reliably implemented to make it unnecessary for multiple hot wallet VMs? What are the security and anonymity implications of using multiple Bitcoin based AppVMs connected to the same NetVm/ProxyVM/FirewallVM?
What I am still investigating, is pointing Armory Hot Wallets to the Whonix Gateway Socks Port, in order to take advantage of stream isolation. Rather than using a transparent proxy. If other VMs are connected to same Whonix-Gateway with transparent proxificatin , you are probably risking identity correlation.
So for the time being, I am recommending a dedicated Whonix-Gateway for each Hot Wallet. In the Armory Preferences, you can turn on Tor Support. But it does not seem to give you the option to choose your server, or port. This needs to be investigated.
This should probably be tested by disabling transparent proxy in your Whonix-Gateway, and then trying to get Armory to connect.
What is your preferred BTC-VaultVM OS Template? Debian? Fedora? Arch?
I know Electrum is a much more popular wallet cient. I haven't used it much. What are peoples' thoughts on it? It doesn't need to download the blockchain, right? So, that would save me 100GB. Is it as secure? I would have to assume not, but it's packaged with Tails now, so maybe it's worth another look.
Axon
Oct 25, 2015, 12:31:08 AM10/25/15
to k.c.l....@gmail.com, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
k.c.l....@gmail.com:
As you know, I'm one of those "never transfer from less trusted to
more trusted domains" folks. So, my (admittedly simplistic) setup is
as follows:
btc-vault:
- AppVM based on fedora-21
- Satoshi client
- No networking
- Generates receiving addresses
btc-hot:
- AppVM based on fedora-21
- Satoshi client
- Connected to a torvm
I mostly just receive bitcoin for long-term storage purposes, so my
workflow is like this:
1. Generate a receiving address in btc-vault.
2. Inter-VM copy/paste the address from btc-vault into some VM where
it can be communicated to the sender.
3. Verify transaction independently (e.g., view on blockchain.info).
4. Create encrypted wallet backup file.
5. Qvm-backup btc-vault and/or copy out encrypted wallet backup file.
Advantages:
- Nothing ever goes into btc-vault except PGP-verified Satoshi client
blobs.
- btc-vault never gets connected to any kind of netvm.
Disadvantages:
- The value of the BTC in btc-vault can't easily be tracked. (I just
use a spreadsheet for this.)
- BTC can't easily be spent. (This is OK for me, because I rarely
spend BTC. If I need to do so, I'll qvm-copy a wallet backup from
btc-vault to btc-hot, restore from the backup in btc-hot, then spend
as usual.)
Any suggestions for improvements on this system, given my modest needs?
(I like the idea of having a watching-only wallet, but I didn't want
to create a Debian template just to be able to use Bitcoin Armory.
Maybe someday, though.)
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJWLFqhAAoJEJh4Btx1RPV8e2gP/0Q0nTdUaT/YNaq6ExPpwG1w
A6oamxYJz3uauDncVUAtyLPXIVvYvEJyEclvcjUgH2sz+G92mzB60ZDLe5nzgxe/
axxt5L5YGIz7lJZyImevFd8wcOMhccxqL95PN3EL8lzVriXCZHeFB7YVOiibeM3W
yiINXrDBwnOZJtM/SVARLLngLNVzq6cBqhBv1t+cjBg86SCyQzYr3q74YxMkjmQk
X0lMJIHQlO0yACrY1H5hBAWa39XnEZZ8FlhBnwoK0aCSsruXXRITIRqQZpeO0oat
tjBrna8RoTyIOBMalfkaAGkeKfVEKiwz+ozZU0dIOw8adAFqGhQ5DSI5u2OdBayc
m0KWVnflg1aFdCMt5p2SDUb5svD6jEg0rcPoaH8wy9R9uPGihZIx8NAaTwPZvLKX
tvWKshLLMoseX3L5JKu8/+JHCA+mhDxgES/j3scTCtBvGlDPH9M0zX3O9BfmKA1C
r44c5mjSN0yPJGfTvalPZ1VLU19YyIHvGVSDGrS3Z9FY1m9ev3DAQH2hqKpo2kzc
ywvt8ej70akzK5JaFyKXIhLXevQVamD3cckf+sBzvKebVJ/lpyNlWNHwAMZTs16K
dzZNgsFQ/GvUtonqd+V35uFAOI1AcarUzDaOF4sOyDnozwH0sEmsqbwEOvU1TrF2
L9HTuKsgyCz+QqhwRHEY
=86yK
-----END PGP SIGNATURE-----
Hash: SHA512
k.c.l....@gmail.com:
> tl;dr - Create air-gapped cold wallet appvm with Bitcoin Armory.
> Create Tor connect Hot wallet from cloned template. Use hardware
> encrypted USB backup to deep freeze your wallet.
>
>
> I have been in the process of building Bitcoin VMs and trying to
> find elegant solutions for hot and cold wallets.
>
> I am using Bitcoin Armory
> (https://github.com/etotheipi/BitcoinArmory) for my wallet
> software, which I am a big fan of.
>
> My current solution has been to build Bitcoin Armory from source in
> a fedora-21-minimal TemplateVM.
>
> This TemplateVM is then cloned. Inside the TemplateVM clone, I
> build bitcoind (https://github.com/bitcoin) from source.
> (Alternatively, BitcoinArmory will also securely download and
> install bitcoind for you).
>
> Store blockchain and armory databases on root.img, so they can be
> shared with all appvms:
>
> $ sudo mkdir /usr/share/bitcoin/ && ln -s
> /usr/share/bitcoin/bootstrap.dat ~ /.bitcoin/bootstrap.dat && ln -s
> Create Tor connect Hot wallet from cloned template. Use hardware
> encrypted USB backup to deep freeze your wallet.
>
>
> I have been in the process of building Bitcoin VMs and trying to
> find elegant solutions for hot and cold wallets.
>
> I am using Bitcoin Armory
> (https://github.com/etotheipi/BitcoinArmory) for my wallet
> software, which I am a big fan of.
>
> My current solution has been to build Bitcoin Armory from source in
> a fedora-21-minimal TemplateVM.
>
> This TemplateVM is then cloned. Inside the TemplateVM clone, I
> build bitcoind (https://github.com/bitcoin) from source.
> (Alternatively, BitcoinArmory will also securely download and
> install bitcoind for you).
>
> Store blockchain and armory databases on root.img, so they can be
> shared with all appvms:
>
> $ sudo mkdir /usr/share/bitcoin/ && ln -s
more trusted domains" folks. So, my (admittedly simplistic) setup is
as follows:
btc-vault:
- AppVM based on fedora-21
- Satoshi client
- No networking
- Generates receiving addresses
btc-hot:
- AppVM based on fedora-21
- Satoshi client
- Connected to a torvm
I mostly just receive bitcoin for long-term storage purposes, so my
workflow is like this:
1. Generate a receiving address in btc-vault.
2. Inter-VM copy/paste the address from btc-vault into some VM where
it can be communicated to the sender.
3. Verify transaction independently (e.g., view on blockchain.info).
4. Create encrypted wallet backup file.
5. Qvm-backup btc-vault and/or copy out encrypted wallet backup file.
Advantages:
- Nothing ever goes into btc-vault except PGP-verified Satoshi client
blobs.
- btc-vault never gets connected to any kind of netvm.
Disadvantages:
- The value of the BTC in btc-vault can't easily be tracked. (I just
use a spreadsheet for this.)
- BTC can't easily be spent. (This is OK for me, because I rarely
spend BTC. If I need to do so, I'll qvm-copy a wallet backup from
btc-vault to btc-hot, restore from the backup in btc-hot, then spend
as usual.)
Any suggestions for improvements on this system, given my modest needs?
(I like the idea of having a watching-only wallet, but I didn't want
to create a Debian template just to be able to use Bitcoin Armory.
Maybe someday, though.)
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJWLFqhAAoJEJh4Btx1RPV8e2gP/0Q0nTdUaT/YNaq6ExPpwG1w
A6oamxYJz3uauDncVUAtyLPXIVvYvEJyEclvcjUgH2sz+G92mzB60ZDLe5nzgxe/
axxt5L5YGIz7lJZyImevFd8wcOMhccxqL95PN3EL8lzVriXCZHeFB7YVOiibeM3W
yiINXrDBwnOZJtM/SVARLLngLNVzq6cBqhBv1t+cjBg86SCyQzYr3q74YxMkjmQk
X0lMJIHQlO0yACrY1H5hBAWa39XnEZZ8FlhBnwoK0aCSsruXXRITIRqQZpeO0oat
tjBrna8RoTyIOBMalfkaAGkeKfVEKiwz+ozZU0dIOw8adAFqGhQ5DSI5u2OdBayc
m0KWVnflg1aFdCMt5p2SDUb5svD6jEg0rcPoaH8wy9R9uPGihZIx8NAaTwPZvLKX
tvWKshLLMoseX3L5JKu8/+JHCA+mhDxgES/j3scTCtBvGlDPH9M0zX3O9BfmKA1C
r44c5mjSN0yPJGfTvalPZ1VLU19YyIHvGVSDGrS3Z9FY1m9ev3DAQH2hqKpo2kzc
ywvt8ej70akzK5JaFyKXIhLXevQVamD3cckf+sBzvKebVJ/lpyNlWNHwAMZTs16K
dzZNgsFQ/GvUtonqd+V35uFAOI1AcarUzDaOF4sOyDnozwH0sEmsqbwEOvU1TrF2
L9HTuKsgyCz+QqhwRHEY
=86yK
-----END PGP SIGNATURE-----
Anonymous
Oct 25, 2015, 1:20:55 AM10/25/15
to qubes-users, k.c.l....@gmail.com, ax...@openmailbox.org
On Sunday, October 25, 2015 at 4:31:08 AM UTC, Axon wrote:
Any suggestions for improvements on this system, given my modest needs?
If you aren't spending BTC regularly, you probably use too much fiat currency. I recommend fixing that.
(I like the idea of having a watching-only wallet, but I didn't want
to create a Debian template just to be able to use Bitcoin Armory.
What is wrong with running armory in fedora? I don't recall having that much of an issue getting it installed from GitHub.
Maybe someday, though.
Armory is slick. I highly recommend it.
If your cold wallet VM is airgapped, what is the danger of transferring files to your vault? The only thing ever sent to that cold VM should be Qubes Copy/Paste of offline transactions to be signed.
Jake
Oct 26, 2015, 9:38:59 AM10/26/15
to qubes...@googlegroups.com
On 10/25/2015 03:35 AM, k.c.l....@gmail.com wrote:
tl;dr - Create air-gapped cold wallet appvm with Bitcoin Armory. Create Tor connect Hot wallet from cloned template. Use hardware encrypted USB backup to deep freeze your wallet.
I have been in the process of building Bitcoin VMs and trying to find elegant solutions for hot and cold wallets.
...
What i would like to discuss now is the security implications of using multiple wallets within the same AppVMs. If they are all cold offline wallets, does it matter? Might it be a better solution then to use a standalone VM?
typically, the term "cold" in the context of a wallet means
exclusively offline storage, so these wallets could be more
accurately described as "chilly" when they aren't fully offline,
e.g. a vm without network.
i expect that it's ok to have multiple chilly wallets in a single vm without network since if your machine (dom0) is compromised, all your offline vms are owned. since pasting/transmitting a signed tx from an offline vm to a hot wallet is typically a one-way operation, you gain nothing by splitting up the wallets, assuming they are selecting utxos independently.
i expect that it's ok to have multiple chilly wallets in a single vm without network since if your machine (dom0) is compromised, all your offline vms are owned. since pasting/transmitting a signed tx from an offline vm to a hot wallet is typically a one-way operation, you gain nothing by splitting up the wallets, assuming they are selecting utxos independently.
For online wallets, can Tor Stream Isolation be reliably implemented to make it unnecessary for multiple hot wallet VMs? What are the security and anonymity implications of using multiple Bitcoin based AppVMs connected to the same NetVm/ProxyVM/FirewallVM?
since you're using armory, which requires a full bitcoind node
underneath it, i would recommend sticking with independent hot
wallet vms to protect against a successful attack on the particular
bitcoind instance that is running a given wallet. i'm not familiar
with the details of how tor stream isolation works, so that may
allow you to safely run multiple wallets in a single vm.
What I am still investigating, is pointing Armory Hot Wallets to the Whonix Gateway Socks Port, in order to take advantage of stream isolation. Rather than using a transparent proxy. If other VMs are connected to same Whonix-Gateway with transparent proxificatin , you are probably risking identity correlation.
So for the time being, I am recommending a dedicated Whonix-Gateway for each Hot Wallet. In the Armory Preferences, you can turn on Tor Support. But it does not seem to give you the option to choose your server, or port. This needs to be investigated.
i would expect the tor settings to be accessible directly via
bitcoind instead of armory's gui. you can likely turn the tor knobs
from bitcoind.conf or similar. iirc you don't get stream isolation
from a torvm unless you connect to a particular port on your torvm,
but i could be wrong, there's lots of details about torvm setup.
This should probably be tested by disabling transparent proxy in your Whonix-Gateway, and then trying to get Armory to connect.
What is your preferred BTC-VaultVM OS Template? Debian? Fedora? Arch?
I know Electrum is a much more popular wallet cient. I haven't used it much. What are peoples' thoughts on it? It doesn't need to download the blockchain, right? So, that would save me 100GB. Is it as secure? I would have to assume not, but it's packaged with Tails now, so maybe it's worth another look.
if it's a vault vm, the OS shouldn't really matter since it's not
exposed to network.
electrum and other spv clients are definitely nice in that they don't require a full chain. however, they are coded with non-technical users in mind, so i would expect them to be less secure from a coding quality/style standpoint. also, since you're all about tor, running an spv client puts you at increased risk of an organized attacker manipulating your view of the bitcoin network. there are some proposals that would make spv much more secure, but they are still WIPs.
overall, i would take caution posting such detail about how your btc/cryptocurrency setup is configured. the more information there is out in public, the easier it is for someone to engineer an attack against you.
electrum and other spv clients are definitely nice in that they don't require a full chain. however, they are coded with non-technical users in mind, so i would expect them to be less secure from a coding quality/style standpoint. also, since you're all about tor, running an spv client puts you at increased risk of an organized attacker manipulating your view of the bitcoin network. there are some proposals that would make spv much more secure, but they are still WIPs.
overall, i would take caution posting such detail about how your btc/cryptocurrency setup is configured. the more information there is out in public, the easier it is for someone to engineer an attack against you.
--
You received this message because you are subscribed to the Google Groups "qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users...@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e55035d7-709c-49ea-b5e8-6c29f3eab56c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Axon
Oct 27, 2015, 5:56:19 AM10/27/15
to Jake, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Jake:
Hash: SHA512
> On 10/25/2015 03:35 AM, k.c.l....@gmail.com wrote:
>> [...] What i would like to discuss now is the security
>> implications of using multiple wallets within the same AppVMs.
>> If they are all cold offline wallets, does it matter? Might it be
>> a better solution then to use a standalone VM?
>
> typically, the term "cold" in the context of a wallet means
> exclusively offline storage, so these wallets could be more
> accurately described as "chilly" when they aren't fully offline,
> e.g. a vm without network.
>
To be fair, I think the existence of Qubes opens the appropriate
>> If they are all cold offline wallets, does it matter? Might it be
>> a better solution then to use a standalone VM?
>
> typically, the term "cold" in the context of a wallet means
> exclusively offline storage, so these wallets could be more
> accurately described as "chilly" when they aren't fully offline,
> e.g. a vm without network.
>
application of this term to debate. Joanna has argued rather
persuasively that a network-disconnected Qubes VM is in many ways more
secure than a physically airgapped device.[1] Even if we're talking
about paper wallets, I think we could point out many weak points in
the process of moving coins from a hot wallet to a paper wallet, then
later back to a hot wallet for spending--weaknesses which are obviated
by a carefully set up vault VM system. So, I don't think we should
automatically assume that "physically offline" is always more secure
than "Qubes offline."
Not that you were necessarily making that assumption. :)
> [...] overall, i would take caution posting such detail about how
> your btc/cryptocurrency setup is configured. the more information
> there is out in public, the easier it is for someone to engineer
> an attack against you.
>
OTOH, we don't want to encourage security through obscurity. The setup
> there is out in public, the easier it is for someone to engineer
> an attack against you.
>
should be secure even if an attacker knows exactly how it works.
[1]: http://www.invisiblethingslab.com/resource/2014/
Software_compartmentalization_vs_physical_separation.pdf
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJWL0orAAoJEJh4Btx1RPV8RwUQAIHu7eSOKCeHglYlkBpRGB7+
bQo/fRoYOcE+lEYMKumhePW8ptYX98sUY5o4sQUgOpwJHGxXUEopmyQCJ/oHpCLI
8SDWaxiqndmU2M49Yfq6FTxCFVPoFeoDAGEwmLGHAarv+krKO9fOP2UIQUBRp1PM
lQGu+c7i3mOolOOr4V/LqRiRIi6eRSCBF0EMhpPfcOsgghQw9atE2WLHMTpcBp3w
3H4gS/6rl2lwoQRkGdQFxqIwwcfpx7SJ8wANagB8u7CZGY4LNRN44NaPOuEPj1GR
F5whnapni8kTZvS3x9v+1opT8/kMhCTIeL0hj2irM7VPh6NTS6sXBT8eeYgu17eo
+8SYUwIbzNeC+DZWJJmbCAPuZJma64k7wTxWlk6fWGxFJ7Sbw0ziHKOpW76KYbop
rjekjRkxydZjspiq6/5xmvv6RR2vPj6X2YHxR4358gb2/S0JdTMbqS3Y6bXi7WS7
EpkRL+LDb1gGcSlnn2jnYFLs/qxs/di4aoFXwaTEnw4f26feqqjzaicqVD1GUETe
7BqNIVAKan3XxeYiTdofa06tA4vnhao+F8AxvgmgNSMh4eX6itfdeTi3/Nhl9thJ
WMcR02KHsbB1aqpU29QnqMwpL24VyDg/Zdczuc93Z2lYzCRM0yVkxK3afa9AKhsD
EiJZzfxd6/1siaRGZhHG
=SwBJ
-----END PGP SIGNATURE-----
Jake
Oct 27, 2015, 1:04:48 PM10/27/15
to Axon, qubes...@googlegroups.com
On 10/27/2015 09:55 AM, Axon wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Jake:
>> On 10/25/2015 03:35 AM, k.c.l....@gmail.com wrote:
>>> [...] What i would like to discuss now is the security
>>> implications of using multiple wallets within the same AppVMs.
>>> If they are all cold offline wallets, does it matter? Might it be
>>> a better solution then to use a standalone VM?
>> typically, the term "cold" in the context of a wallet means
>> exclusively offline storage, so these wallets could be more
>> accurately described as "chilly" when they aren't fully offline,
>> e.g. a vm without network.
>>
> To be fair, I think the existence of Qubes opens the appropriate
> application of this term to debate. Joanna has argued rather
> persuasively that a network-disconnected Qubes VM is in many ways more
> secure than a physically airgapped device.[1] Even if we're talking
> about paper wallets, I think we could point out many weak points in
> the process of moving coins from a hot wallet to a paper wallet, then
> later back to a hot wallet for spending--weaknesses which are obviated
> by a carefully set up vault VM system. So, I don't think we should
> automatically assume that "physically offline" is always more secure
> than "Qubes offline."
>
> Not that you were necessarily making that assumption. :)
i'm just rolling with how "cold" is typically defined for wallets, as in
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Jake:
>> On 10/25/2015 03:35 AM, k.c.l....@gmail.com wrote:
>>> [...] What i would like to discuss now is the security
>>> implications of using multiple wallets within the same AppVMs.
>>> If they are all cold offline wallets, does it matter? Might it be
>>> a better solution then to use a standalone VM?
>> typically, the term "cold" in the context of a wallet means
>> exclusively offline storage, so these wallets could be more
>> accurately described as "chilly" when they aren't fully offline,
>> e.g. a vm without network.
>>
> To be fair, I think the existence of Qubes opens the appropriate
> application of this term to debate. Joanna has argued rather
> persuasively that a network-disconnected Qubes VM is in many ways more
> secure than a physically airgapped device.[1] Even if we're talking
> about paper wallets, I think we could point out many weak points in
> the process of moving coins from a hot wallet to a paper wallet, then
> later back to a hot wallet for spending--weaknesses which are obviated
> by a carefully set up vault VM system. So, I don't think we should
> automatically assume that "physically offline" is always more secure
> than "Qubes offline."
>
> Not that you were necessarily making that assumption. :)
not connected to a networked machine. while i would agree that, for most
people and scenarios, you and joanna are correct to argue that an
offline domU is more secure than an airgapped machine, there certainly
exist scenarios where this is not the case. by using qubes and assuming
offline domUs are secure, you are putting an enormous amount of trust in
VT-d, which may be misplaced. too bad we can't audit silicon so easily
as code.
>
>> [...] overall, i would take caution posting such detail about how
>> your btc/cryptocurrency setup is configured. the more information
>> there is out in public, the easier it is for someone to engineer
>> an attack against you.
>>
> OTOH, we don't want to encourage security through obscurity. The setup
> should be secure even if an attacker knows exactly how it works.
someone hacks your samba server by reading some howto you posted, it's
not the end of the world. however, if someone steals all your btc, that
is a pretty epic failure mode.
him sharing the nitty gritty details of his setup is very unlikely to
help a casual reader, but it could greatly benefit an attacker. there is
a lot to be said for the value of selective omission and the asymmetry
of sharing information.
coming from someone who doesn't share their name or identity, i find you
calling me down for supposedly encouraging security through obscurity
pretty ridiculous.
Axon
Oct 27, 2015, 6:09:32 PM10/27/15
to Jake, qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Jake:
Hash: SHA512
Jake:
that VT-d works the way we think, or anything like that. All I said is
that we shouldn't *automatically assume* that a physical airgap is
*always* more secure than a Qubes OfflineVM. In some cases, it is. In
some cases, it is not. As I said, a Qubes OfflineVM is *in many ways*
more secure than a physicall airgapped device, but of course "in many
ways" does not mean "in every way," and there are certainly *some*
respects in which a physical airgap is more secure than an OfflineVM.
In the end, I don't think we disagree. I realize you're just using
"cold" as other people use it. I just wanted to point out that most
other people who use "cold" in that way are probably laboring under
the old, questionable assumption that a physical airgap is the
absolute pinnacle of security.
>
>>>> [...] overall, i would take caution posting such detail
>>>> about how your btc/cryptocurrency setup is configured. the
>>>> more information there is out in public, the easier it is
>>>> for someone to engineer an attack against you.
>>>>
> OTOH, we don't want to encourage security through obscurity. The
> setup should be secure even if an attacker knows exactly how it
> works.
>
>> my advice has everything to do with the threat model and
>> context: if someone hacks your samba server by reading some howto
>> you posted, it's not the end of the world. however, if someone
>> steals all your btc, that is a pretty epic failure mode.
>
>> him sharing the nitty gritty details of his setup is very
>> unlikely to help a casual reader, but it could greatly benefit
>> an attacker. there is a lot to be said for the value of
>> selective omission and the asymmetry of sharing information.
>
>> coming from someone who doesn't share their name or identity, i
>> find you calling me down for supposedly encouraging security
>> through obscurity pretty ridiculous.
>
I was just playing devil's advocate, presenting an alternative point
of view. It was not meant personally and should not have been taken
that way.
In fact, I agree strongly with your point that "him sharing the nitty
gritty details of his setup is very unlikely to help a casual reader,
but it could greatly benefit an attacker. there is a lot to be said
for the value of selective omission and the asymmetry of sharing
information." However, I wouldn't want someone to take your initial
but it could greatly benefit an attacker. there is a lot to be said
for the value of selective omission and the asymmetry of sharing
comment the wrong way ("the more information there is out in public,
the easier it is for someone to engineer an attack against you") and
be dissuaded from participating in this community and sharing
important information on this ML which might significantly affect all
Qubes users.
>
>
>
> [1]: http://www.invisiblethingslab.com/resource/2014/
> Software_compartmentalization_vs_physical_separation.pdf
>
-----BEGIN PGP SIGNATURE-----
wSosHaWFoiDQJlrFM+nSvxeDWFDfCvF2Hejhf6jupZ1TTAZN1gTpHHKMBul6t4od
6ZLGftinNNQKSOJ5XIjzIN0+EuSirAnVHxCclujdJRT6H+mt1uR9i3d/pgr7ax0C
SrqD6DXxa5E3fCILI0bwEBQQcBjHfSwBp1YfcA0UdwyqYz0z4odMD+x+WciDL/+Q
EGEVDykT659Sew2A5yNH0xMRjWZw4mv00lSt/9YiTGDMEjpW5lILiiNjxt55ov+w
TOPJQYlw72dFNfMjrOp/kkBjgyj2C9Zny11o3LyrEGgPw7IHHqnvuQC850npzPWP
rU3cB9wU0nXVBjCi1IC6LCt3lHbVCrQ3QDBKqxeDrj2nHIEb4A6cTKd6Q114XrFQ
CXbrB181K69tTyQYAY8pA2Z7d1guXR6vWGk7sJhzPzY65U0UMQl3N8Ng8tr1rnod
567MLlLEnhFjWz6Gcs7OvbeWarj1n+lsN3kqMoFGpbz6TokI0TcZuyUJdGxNvyQP
tu6gCpZMoqRo4GmvwuLHBAROCgWUoNbIEDPQJ6+vYNohr4xuhkH9twX8hAkbql4Q
vQ3DXCQpfV0mjIuZfbXaQHQkX+lvhYrOEKBfEOWgQDY/KJsWI2By98I0AUp0F+ih
1ATnRccKPr34SmrNZx+d
=EDsL
-----END PGP SIGNATURE-----
Anonymous
Oct 31, 2015, 5:38:06 PM10/31/15
to qubes-users
Offline Qubes VMs are "Cold" enough for me.
I am confident enough with my overall security setup, that I don't mind explaining some of the "nitty gritty", if it helps others make THEIR setup more secure. If an attacker can get through the bonded multi-wan, pfSense IDS, VPNs, and Tor, and Qubes, well, they earned their bitcoins. They deserve every one they can pillage.
Not to mention my use of pseudonyms. I certainly wouldn't participate in a mailing list like this using my real name or IP or anything like that. I didn't participate at all for years just because I am so anti-google.
But anywho. I appreciate the security advice. I think I'll be alright though. Even if it costs me all my bitcoins, hopefully the community will learn something from it.
I am confident enough with my overall security setup, that I don't mind explaining some of the "nitty gritty", if it helps others make THEIR setup more secure. If an attacker can get through the bonded multi-wan, pfSense IDS, VPNs, and Tor, and Qubes, well, they earned their bitcoins. They deserve every one they can pillage.
Not to mention my use of pseudonyms. I certainly wouldn't participate in a mailing list like this using my real name or IP or anything like that. I didn't participate at all for years just because I am so anti-google.
But anywho. I appreciate the security advice. I think I'll be alright though. Even if it costs me all my bitcoins, hopefully the community will learn something from it.
Jeremy Rand
Nov 1, 2015, 5:41:22 PM11/1/15
to qubes...@googlegroups.com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On 10/24/2015 10:35 PM, k.c.l....@gmail.com wrote:
> tl;dr - Create air-gapped cold wallet appvm with Bitcoin Armory.
> Create Tor connect Hot wallet from cloned template. Use hardware
> encrypted USB backup to deep freeze your wallet.
>
>
> I have been in the process of building Bitcoin VMs and trying to
> find elegant solutions for hot and cold wallets.
>
> I am using Bitcoin Armory
> (https://github.com/etotheipi/BitcoinArmory) for my wallet
> software, which I am a big fan of.
>
> My current solution has been to build Bitcoin Armory from source in
> a fedora-21-minimal TemplateVM.
(Sorry for sending you a private email accidentally, Thunderbird's UX
fails.)
- From what I can gather by looking at your instructions, the blockchain
is stored in the TemplateVM, but any new blocks created after the hot
wallet AppVMs start will be duplicated in storage in all hot wallet
AppVM's plus the TemplateVM, until those hot wallet AppVM's are
rebooted (meaning that each hot wallet VM sees a completely current
blockchain and the storage overhead is minimal as long as you reboot
the hot wallet VM's every so often). Am I correct, or am I
misunderstanding your instructions?
Also, just a warning that it's unclear whether Armory will continue to
receive the same level of maintenance that it has in the past. Things
aren't looking good at the moment.
https://bitcointalk.org/index.php?topic=1219010.0
Cheers,
- -Jeremy Rand
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJWNpUJAAoJEAHN/EbZ1y06mlQQAJDz+Bq2BVgqasMn6Y+LaWjF
ApR0r6418Z0oPm9HI6HlFgq2Q7x9mrpoAfvgMHiNqVgudRId4qeNdlWXQ+rGKrJ9
h6qO8wzkW+TKMHJY69cmRfqX0sdpKRaOr8BfYTvpdR8sprfA3FENlx8B4FY+65qq
rsnc4+sxHxi+ZUW2WLLDwxYR82k1M1DWd7TBZG2rbc/40JKMHfyidG/JECsOs1K1
zSY/ZcClrxirU2I5g5Idse2a0c6R54hrpjFlMsZzk+CEzEjBDNFH9BZuV9Mgbq5n
XIO41xU77EQf21weJxAAHoV/OLeuyTaKuWhj6lzYwjKhQUYGrecTi95tM953VIbj
c+OljN83NnOQeOXVMxu8r+ovJZtgc+xFyR+lgnVMNl3rHWk8Sbg2T26wlc+kJfOl
6H/V0F2fHOr8CxNGWrvK8QV2Cb1yMoiu3hIt/Kf8N8ySW4Je4fIP0FIB8UzNLA8E
uRFzC5HJpBD/8lDXdvXq9NK213LpBszz/7KxH94yRUx4iYWBEB7aFgHxizCpbF+8
AhmMa2RRL4jIiFSxITRl9kHkbtAytTdeNyqa7oUeMYcpJ0OqNRaTTqZdTtfMy1tM
osLEN6VEoskUpbrmr/97XNVLgttqmiEfTyMGYtxnX2SEYNjnK5j1ezvsOnMP+uyV
5iCkTXmOvGMrRyZzWOcP
=n+OZ
-----END PGP SIGNATURE-----
Hash: SHA256
On 10/24/2015 10:35 PM, k.c.l....@gmail.com wrote:
> tl;dr - Create air-gapped cold wallet appvm with Bitcoin Armory.
> Create Tor connect Hot wallet from cloned template. Use hardware
> encrypted USB backup to deep freeze your wallet.
>
>
> I have been in the process of building Bitcoin VMs and trying to
> find elegant solutions for hot and cold wallets.
>
> I am using Bitcoin Armory
> (https://github.com/etotheipi/BitcoinArmory) for my wallet
> software, which I am a big fan of.
>
> My current solution has been to build Bitcoin Armory from source in
> a fedora-21-minimal TemplateVM.
fails.)
- From what I can gather by looking at your instructions, the blockchain
is stored in the TemplateVM, but any new blocks created after the hot
wallet AppVMs start will be duplicated in storage in all hot wallet
AppVM's plus the TemplateVM, until those hot wallet AppVM's are
rebooted (meaning that each hot wallet VM sees a completely current
blockchain and the storage overhead is minimal as long as you reboot
the hot wallet VM's every so often). Am I correct, or am I
misunderstanding your instructions?
Also, just a warning that it's unclear whether Armory will continue to
receive the same level of maintenance that it has in the past. Things
aren't looking good at the moment.
https://bitcointalk.org/index.php?topic=1219010.0
Cheers,
- -Jeremy Rand
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAEBCAAGBQJWNpUJAAoJEAHN/EbZ1y06mlQQAJDz+Bq2BVgqasMn6Y+LaWjF
ApR0r6418Z0oPm9HI6HlFgq2Q7x9mrpoAfvgMHiNqVgudRId4qeNdlWXQ+rGKrJ9
h6qO8wzkW+TKMHJY69cmRfqX0sdpKRaOr8BfYTvpdR8sprfA3FENlx8B4FY+65qq
rsnc4+sxHxi+ZUW2WLLDwxYR82k1M1DWd7TBZG2rbc/40JKMHfyidG/JECsOs1K1
zSY/ZcClrxirU2I5g5Idse2a0c6R54hrpjFlMsZzk+CEzEjBDNFH9BZuV9Mgbq5n
XIO41xU77EQf21weJxAAHoV/OLeuyTaKuWhj6lzYwjKhQUYGrecTi95tM953VIbj
c+OljN83NnOQeOXVMxu8r+ovJZtgc+xFyR+lgnVMNl3rHWk8Sbg2T26wlc+kJfOl
6H/V0F2fHOr8CxNGWrvK8QV2Cb1yMoiu3hIt/Kf8N8ySW4Je4fIP0FIB8UzNLA8E
uRFzC5HJpBD/8lDXdvXq9NK213LpBszz/7KxH94yRUx4iYWBEB7aFgHxizCpbF+8
AhmMa2RRL4jIiFSxITRl9kHkbtAytTdeNyqa7oUeMYcpJ0OqNRaTTqZdTtfMy1tM
osLEN6VEoskUpbrmr/97XNVLgttqmiEfTyMGYtxnX2SEYNjnK5j1ezvsOnMP+uyV
5iCkTXmOvGMrRyZzWOcP
=n+OZ
-----END PGP SIGNATURE-----
Anonymous
Nov 1, 2015, 6:14:50 PM11/1/15
to qubes-users
(Please note that I made a couple of Typos in the OP. You're going to need to be root/sudo to write to /opt/, and the databases symlink for armory should be to /usr/share/armory/databases)
The AppVMs inherit the blockchain and armory database from the TemplateVM. TemplateVM is in charge of staying current. AppVMs will update the blockchain, and store the updates in /usr/share/bitcoin/blocks. A directory that AppVMs CANNOT make permanent changes to. So each reboot of AppVMs will erase those updates. If you were to store the new blocks somewhere in /rw/, then they would remain between reboots, but every AppVM would then be keeping their own copy. If you have 15-20 wallets, this could get messy. In 3 years when the blockchain is 200GB, it will be worse. So, the only solution I could think of was to simply make all perm. updates using TemplateVM, and the AppVMs get the most recent small updates. Run TemplateVM as frequently as needed to keep AppVMs up to date. I just let my TemplateVM run 24/7. That way, the AppVMs only have to download the blocks that update while the AppVM is running. Each reboot, it gets synchronized with the TemplateVM (assuming you also reboot the templateVM to write the perm changes, just as you would with package updates).
My plan for this is to find out how the UPDATES VM allows such things as yum/apt repos, but blocks everything else. I would like to find a way to also allow it to update the blockchain (and connect to git hub!). I am then going to find a way to setup pfSense with Squid Proxy addon, and selectively cache things like updates and blockchains, so I can save (my neighbors') bandwidth.
Also, regarding my instructions, you probably want to handle the Armory symlinks before you clone your templateVM and install bitcoind. Alternately, you could use a single template and save yourself some space. But for offline "vault" type VMs, I don't like to have any third party software installed, or anything that wants to try to connect to the internet. So I use a "debian-safe" VM for vaults, and they never connect to internet and have no extra software installed. I use debfoster/deborphan/bleachbit/localepurge to strip it down as much as possible, and only install what is required to run vault software (Armory, KeePassX, GPA, TOMB, etc).
Hope this helped.
Kevin Callagy
Nov 1, 2015, 6:19:58 PM11/1/15
to qubes-users
Also, just to make clear. Updating an AppVM, has NO EFFECT on any other AppVMs. The writes to /usr/share/bitcoin and /usr/share/armory are NOT visible from one AppVM to another. It's only visible to THAT AppVM until reboot. So, if you fire up a AppVM and it has 72 hours worth of updates to handle, and then you fire up another AppVM, that AppVM will ALSO need 72 hrs worth of updates. That is until you start the TemplateVM and download those 72 hours, THEN start your AppVMs. Then each one will be up to date. So it is probably best practice to start your TemplateVM and let it finish updates before starting your AppVMs for the day. Otherwise you will be downloading multiple copies. So, I would run TemplateVM as often as possible, and keep AppVMs closed until you need to handle specific transactions. Then, they will be up to date on each startup.
--
You received this message because you are subscribed to a topic in the Google Groups "qubes-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/qubes-users/AkZo8xOxi18/unsubscribe.
To unsubscribe from this group and all its topics, send an email to qubes-users...@googlegroups.com.
To post to this group, send email to qubes...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ed9e79bf-0326-4c30-9348-12ed200b7e2b%40googlegroups.com.
Marek Marczykowski-Górecki
Nov 1, 2015, 6:38:36 PM11/1/15
to Anonymous, qubes-users
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hash: SHA256
On Sun, Nov 01, 2015 at 03:14:49PM -0800, Anonymous wrote:
> My plan for this is to find out how the UPDATES VM allows such things as
> yum/apt repos, but blocks everything else. I would like to find a way to
> also allow it to update the blockchain (and connect to git hub!). I am then
> going to find a way to setup pfSense with Squid Proxy addon, and
> selectively cache things like updates and blockchains, so I can save (my
> neighbors') bandwidth.
In short: it's based on http proxy (tinyproxy) running in netvm.
> My plan for this is to find out how the UPDATES VM allows such things as
> yum/apt repos, but blocks everything else. I would like to find a way to
> also allow it to update the blockchain (and connect to git hub!). I am then
> going to find a way to setup pfSense with Squid Proxy addon, and
> selectively cache things like updates and blockchains, so I can save (my
> neighbors') bandwidth.
Details:
https://www.qubes-os.org/doc/software-update-vm/#tocAnchor-1-1-7
- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBCAAGBQJWNqJ3AAoJENuP0xzK19csai0IAJIAL0blUCLPACrqd8/wVXT/
+HaANQbq8fX0DmLgiQJIyy4Do0fLLKhqkXeg7UrNsbxalv5Mjq3St7QXNUR9XjfF
Lyk9uSAx5zvpwOfwLsg3DB1sG+PViRN5hUocgRU6+az3Howy52iBg0IFzCk4cuC9
IB/8ftgI51plnY80FajAp6hQs7Kf+gOklZkONn1znOYBIdaR4h7UXQYM9+jiUiui
QwYN7AY5+b0DZhBucow7nj4FqpR9r0bOMySS4nDnQGlYnO4mVL5wW/wJ3/GkO97h
wWb/muqITfQUMfOhbPalhCOPoeuLGrZdpQbmzs8G9EZa5MvPJBz/WKrj7rZSK6A=
=XzkE
-----END PGP SIGNATURE-----
Anonymous
Nov 1, 2015, 7:00:00 PM11/1/15
to qubes-users, k.c.l....@gmail.com
Outside of my wheel house, but perhaps someone else can explain how we might make some adjustments to proxyVM to allow some things like GitHub, and Blockchain stuff.
With regards to the Armory stuff, you don't have to worry. I have a copy of the code. We'll fork it if the developers flake. It's all QT stuff right? I remember some C++ from the Trolltech days. Working on it for the Nokia N900 before Nokia bought QT. We'll get it all straightened out. Don't you worry.
Anonymous
Nov 2, 2015, 5:58:28 PM11/2/15
to qubes-users, k.c.l....@gmail.com
A note regarding the OP. You are going to need more like 200GB for your root.img in your hot wallet template. And you are also going to want to symlink ~./bitcoin/chainstate to /usr/share/bitcoin/chainstate. Otherwise you are going to run out of space, and everything starts to fail. You'll be told that you need to rebuild the blockchain and the database. Which you don't want to do. Once you resize the root.img to 200GB, it will finish building.
Reply all
Reply to author
Forward
0 new messages