Can we get back on topic? Gold is recovering in Asia this morning...
weird. Bitcoin is still going up.
weird so bitcoin, gold and silver all going up?
We need a new measuring stick. This one keeps shrinking.
Topic: Gold collapsing. Bitcoin UP. - page 1264. (Read 2032274 times)
weird. Bitcoin is still going up.
weird so bitcoin, gold and silver all going up?
We need a new measuring stick. This one keeps shrinking.
Can we get back on topic? Gold is recovering in Asia this morning...
weird. Bitcoin is still going up.
weird so bitcoin, gold and silver all going up?
Can we get back on topic? Gold is recovering in Asia this morning...
weird. Bitcoin is still going up.
weird so bitcoin, gold and silver all going up?
Can we get back on topic? Gold is recovering in Asia this morning...
weird. Bitcoin is still going up.
Can we get back on topic? Gold is recovering in Asia this morning...
so am i, or am i not, obscuring a BTC transaction's IP address when running a wallet from a VM?
definitely not. You would use an anonymous VPS, a VPN, tor, i2p or some trustworthy proxy for that.
let me ask your opinion and that of the other tech experts here on something runeks said over in Reddit.
that by putting one's wallet inside a VM, it becomes much more secure, if not impossible for a gubmint entering your pc via the VM to get out of it and access your IP address thru the native OS and connected router. is this accurate? and does it depend on whether one's network adapter uses NAT or bridged?
that by putting one's wallet inside a VM, it becomes much more secure, if not impossible for a gubmint entering your pc via the VM to get out of it and access your IP address thru the native OS and connected router. is this accurate? and does it depend on whether one's network adapter uses NAT or bridged?
secure against what? discovering your IP? certainly not.
The bitcoind (or whatever network-connection-using software) within the VM accesses the network via your router, just like any other device behind the router (except maybe using an additional hop depending on config). You don't need to break into the VM to find the IP address, just look at the traffic.
That wouldn't obscure the IP as the transaction is still being relayed by your connection. If you had a VPN set up on the host and shared the VPN's TAP adapter to the VM, that would obscure your IP.
actually forgot that part. yes, i have a VPN on the host.
what is the TAP adapter?
Assuming you're using NAT on the VM to the host, and your VPN is connected then your IP will already be that of the VPN. Then there's leakage though, if you're using OpenVPN or similar you can specify routing of DNS over the VPN and for a ''kill switch" if the VPN disconnects.
Also, not sure if it still applies, but bitcoin-qt used to use IRC to get a list of peers... not sure if this is still the case but it can be disabled in the config. (of course, this will also be routed over the VPN, but it's something to think about if you decide to connect bitcoin-qt via TOR instead)
Installing TOR on the VM or Host and setting bitcoin-qt to use it as a proxy (and disabling IRC) is still safer, as ranvier says...
yes, i have a VPN on the host.
That's better than not having one, but not as secure as routing through an anonymization network. 
That wouldn't obscure the IP as the transaction is still being relayed by your connection. If you had a VPN set up on the host and shared the VPN's TAP adapter to the VM, that would obscure your IP.
actually forgot that part. yes, i have a VPN on the host.
what is the TAP adapter?
In that case running in a VM isn't doing anything at all in terms of obscuring your "real" IP address.
If you want to submit transactions anonymously, you need to make sure your node can only communicate with the network via Tor or I2P.
A VM can possibly help you there, because you can set the appropriate firewall rules at the host level which restrict the ability of the guest machine to communicate outside a limited set of endpoints.
So you could run a Tor node in one VM and a Bitcoin-Qt node in another, configure Bitcoin-Qt to use Tor, then use firewalling tools on the host to block all packets coming out of the Bitcoin VM except communication to and from the SOCKS listen port on the Tor VM.
Then you're safe as long as your Tor node, or your host OS, isn't compromised.
But again, getting everything right is a bit like getting surgery right. It's difficult to explain the process via a forum post.
If you want to submit transactions anonymously, you need to make sure your node can only communicate with the network via Tor or I2P.
A VM can possibly help you there, because you can set the appropriate firewall rules at the host level which restrict the ability of the guest machine to communicate outside a limited set of endpoints.
So you could run a Tor node in one VM and a Bitcoin-Qt node in another, configure Bitcoin-Qt to use Tor, then use firewalling tools on the host to block all packets coming out of the Bitcoin VM except communication to and from the SOCKS listen port on the Tor VM.
Then you're safe as long as your Tor node, or your host OS, isn't compromised.
But again, getting everything right is a bit like getting surgery right. It's difficult to explain the process via a forum post.
That wouldn't obscure the IP as the transaction is still being relayed by your connection. If you had a VPN set up on the host and shared the VPN's TAP adapter to the VM, that would obscure your IP.
so am i, or am i not, obscuring a BTC transaction's IP address when running a wallet from a VM?
When you spend bitcoins in your setup, via what path do those transactions make it to the rest of the network?i'm sending them thru the VM's network adapter (NAT) to the host, then via wifi to a router, to modem, to net.
so am i, or am i not, obscuring a BTC transaction's IP address when running a wallet from a VM?
When you spend bitcoins in your setup, via what path do those transactions make it to the rest of the network?
so am i, or am i not, obscuring a BTC transaction's IP address when running a wallet from a VM?
This should be a fairly thorough setup, as long as the host remains uncompromised.
I assume that zero day exploits exist for every OS kernel, so that's always a possibility. i know you know what you're talking about so please give us recommendations.
I know enough to doubt my own ability to pull it off, although I do attempt to use virtualization to sandbox all my network-facing applications.I have a workstation which I turned into a VM host system.
Instead of using a dedicated router, I plug my cable modem directly into this system, but the host doesn't talk to the modem directly. I run a Linux system in a VM which serves as the router/firewall.
That VM directs traffic onto a virtual DMZ network, where the other VMs which run services like Tor, I2P, Freenet, Bitcoind, and an OpenVPN client are able to send and receive packets directly over the ISP connection.
Behind the OpenVPN client is another virtual network where the VMs which are public-facing but which I do not want to see my ISP-provided IP address run (like Bitmessage). One of these VMs is also an internal firewall that allows the physical lan to access the internet via the VPN.
I've also got dedicated virtual networks for Tor and I2P communication.
I do ingress and egress packet filtering at the VM level and at the host level using iptables and ebtables.
In spite of all that, I'm not convinced that it's possible for me to fully contain the damage a compromised VM could cause.
This should be a fairly thorough setup, as long as the host remains uncompromised.
A successful attack through the host essentially requires human agent interaction, as opposed to the automated process of searching for a wallet.dat file...
i assume an automated attack coming from the host for a wallet.dat would turn up nothing even with the VM open?
an even simpler question, encryption doesn't help an open VM, correct?
In theory the agent on the host could have code that understands the linux file system and accesses it directly through the VM's disk image file which is on the host. But in practice this isn't going to happen today. Because that ability (accessing Linux file systems in windows) would be pretty valuable as a real product...
It would be trivial to mount a VM disk image and scan it for wallet.dat's. Also, if the VM is running, it is possible for code on the host system to read passwords from the VM's memory.
VM's are never protected from the host.
i know you know what you're talking about so please give us recommendations.
I know enough to doubt my own ability to pull it off, although I do attempt to use virtualization to sandbox all my network-facing applications.I have a workstation which I turned into a VM host system.
Instead of using a dedicated router, I plug my cable modem directly into this system, but the host doesn't talk to the modem directly. I run a Linux system in a VM which serves as the router/firewall.
That VM directs traffic onto a virtual DMZ network, where the other VMs which run services like Tor, I2P, Freenet, Bitcoind, and an OpenVPN client are able to send and receive packets directly over the ISP connection.
Behind the OpenVPN client is another virtual network where the VMs which are public-facing but which I do not want to see my ISP-provided IP address run (like Bitmessage). One of these VMs is also an internal firewall that allows the physical lan to access the internet via the VPN.
I've also got dedicated virtual networks for Tor and I2P communication.
I do ingress and egress packet filtering at the VM level and at the host level using iptables and ebtables.
In spite of all that, I'm not convinced that it's possible for me to fully contain the damage a compromised VM could cause.
Qubes OS may be of interest.
Jump to: