On 06/29/2016 04:37 PM, Franz wrote:
> On Wed, Jun 29, 2016 at 10:46 AM, 7v5w7go9ub0o<7v5w7go9u...@gmail.com>
> wrote:
>
>> On 06/29/2016 07:32 AM, Ben Wika wrote:
>>> When backing up your cold wallet, make sure it's heavily encrypted with a
>>> strong password so no one can access the signing key from the backup.
>> It's
>>> impossible to really know if someone has a copy of your key until they
>> use
>>> it to spend your coins, at which point it would be too late to get them
>>> back.
>>>
>>> Its not really the bitcoins you are storing. What you are storing is the
>>> signing key that authorizes you to reallocate the bitcoins on the public
>>> ledger (to some other bitcoin address).
>>>
>>> I think electrum also has x of y multi-sig. So instead of (or in addition
>>> to) having a cold wallet, you could just have different signing keys
>>> scattered on 'y' different VMs, whereby you have to manually sign the
>>> transaction with at least 'x' signing keys before it is able to broadcast
>>> successfully. Whilst a bit cumbersome, it allows you to develop different
>>> risk profiles for different bitcoin addresses.
>>>
>>> Qubes lends itself very well to handling bitcoin with isolated VMs.
>>>
>>> You might have:
>>> - a hot wallet (networked VM) with a small balance
>>> - a cold wallet (offline VM) with a corresponding watching-only hot
>> wallet
>>> (networked VM)
>>> - a multi-sig cold wallet (offline VM) that also needs 2 other
>> signatures
>>> which may be in hot wallets (3 of 3 multisig).
>>> - a multi-sig cold wallet where you have 2 separate cold wallet VMs
>> that
>>> both have to sign (2 of 2 cold wallets)
>>> - a multi-sig where one of the keys is on your phone running electrum
>>> - a multi-sig where one of the keys is on a piece of paper at a second
>>> location
>>>
>>> Options are limitless and all depends on what risk level you are
>>> comfortable with.
>>
>> Don't know what the threat potential is for the hot wallet, but I'd sure
>> run it in a DispVM so as to not retain any mischief that might be
>> inflicted upon it. Flush and start a fresh copy immediately before any
>> transaction.
>>
>>
>>
> Many thanks to all. It seems more complex than I expected. But Qubes is
> ideally suited to manage all that. This is a very concrete Qubes use, that
> can motivate many people to learn Qubes and to buy an expensive laptop,
> just to safely trade bitcoins. Specially if all this is preinstalled or
> easy to setup.
>
> I mean, pratically now Qubes is mainly an OS for developers, judging from
> the people on this ML. But it could be as well an OS for serious Bitcoin
> users.
>
> Nobody mentioned a tutorial, so I imagine it does not exist. It would be
> nice to try to write something. We may try together.
>
> Regarding the DispVM for the hot wallet, I use the dispVM to print
> everything from more trusted VMs, because printing is not worth much trust.
> But how can I trust a printing dispVM for something as sensitive as a hot
> wallet? We would need two different dispVMs but we are not there yet.
> Best
> Fran
Use a generic DispVM, (e.g. sh -c 'echo uxterm |
/uysr/lib/qubes/qfile-daemon-dvm qubes.VMShell dom0 DEFAULT yellow')
(Heh... I run all of my WAN-exposed applications in DispVMs. Requires a
little initial setup and scripting, but affords great peace of mind.)
In general:
1. Install the software in the template. (This will install both system
executable(s) and a user directory/files).
2. Move the user files to a newly-created folder in the Vault. (delete
the user files in the template).
3. Start a DispVM using the above dom0 utility.
4. Within dom0, copy the user folder from the Vault to the newly-started
DispVM - to the same location and using the same naming convention that
was used by the installer into the template.
5. Start the application (from dom0) in the DispVM.
6. When done with the application, copy any updated files back to the
Vault. (Copy only the minimum amount of non-executable data necessary).
7. Flush the DispVM.
(you'd likely want a backup step in this sequence; say in step 4 before
copying out to the DispVM)
This approach means that you keep all of your "stuff" in a single,
off-line, non-executable-contents Vault; you have one template; you have
virtually no AppVMs - instead, your typical session has 4 or 5 DispVMs.
I haven't set up bitcoins this way - IIUC there are a couple of wallets,
so you'd start up *two* DispVMs: one online hot, and one offline cold.
Two DispVMs so as to not violate the rule that you do not execute
programs in Vault - only move stuff in and out.
(NOT RECOMMENDED: some people actually execute programs within the
Vault - in which case you could get away with only one DispVM for the
hot wallet.)
>>> (As for myself, Armory has been downloading the blockchain for many weeks
>>> at a snail's pace for some reason, ever since I installed qubes, so still
>>> waiting to transfer my coins to electrum for faster access and see what
>>> arrangement I'm most comfortable with - just 15 weeks left to catch up
>> now
>>> - so much for selling any of them at any of the recent peaks)
>>>
>>>
>>> On Wednesday, 29 June 2016 08:37:43 UTC+10, Marek Marczykowski-Górecki
>>> wrote:
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA256
>>>>
>>>> On Tue, Jun 28, 2016 at 02:01:39PM -0700, Todd Lasman wrote:
>>>>> On 2016-06-28 12:01, Franz wrote:
>>>>>> Hello,
>>>>>>
>>>>>> is there some form of tutorial for using Bitcoins with Qubes,
>>>>>> considering that I have no experience of bitcoins?
>>>>>>
>>>>>> It seem I should have a VM for a hot wallet for making transactions
>>>>>> and another for a cold wallet to keep the bitcoins. But have no idea
>>>>>> if it is possible to move bitcoins between the two
>>>>>>
>>>>>> Also imagine a good practice would be to make a backup of the VMs
>>>>>> containing the wallets using Qubes backup.
>>>>>>
>>>>>> It would be also interesting to know which clients you consider safer
>>>>>> for buying and selling bitcoins.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Best
>>>>>> Fran
>>>>> Hi, Fran. I've done exactly this using the Electrum bitcoin wallet. I
>>>> have a
>>>>> dedicated hot ("watching") wallet in its own VM, and a cold (offline)
>>>> wallet
>>>>> in a separate VM that's never network-connected. Although I'm hardly a
>>>>> bitcoin expert, I don't think it's a matter of "transferring bitcoin
>>>> from
>>>>> one wallet to another." Rather, I think the cold wallet just holds the
>>>>> private keys used when authorizing bitcoin transactions. For example,
>> if
>>>> I'm
>>>>> buying something with 1 bc, I generate a pending transaction in the hot
>>>>> wallet, sign that transaction in the cold wallet, transfer the signed
>>>>> transaction back to the hot wallet, and then broadcast it from there.
>>>> That
>>>>> way, only that 1 bc is ever vulnerable in a network-connected VM.
>>>> Yes, this looks like a sensible workflow: one offline VM for holding
>>>> private keys and the other one with only public keys to watch account
>>>> balance, prepare transactions etc. It is critical in such setup to not
>>>> blindly trust what is produced in the online VM - for example carefully
>>>> examine transaction before signing it (in offline VM).
>>>>
>>>>
--
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+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/57740627.422ded0a.7d04e.ffffdfc2%40mx.google.com.
For more options, visit https://groups.google.com/d/optout.
