641
|
Bitcoin / Bitcoin Discussion / Re: 90 BTC stolen!
|
on: January 26, 2014, 05:48:54 PM
|
for anyone else concerned about losing their money I highly recommend the following free way to secure your wallet.
1) Install True Crypt on your PC/laptop and create an encrypted volume that is only mounted manually. 2) Install Virtual Box. 3) Create A Linux virtual machine inside the encrypted volume ... 4) Install Armoury, Bitcoin Client, Litecoin etc into the linux virtual machine ... 5) Create your encrypted/password protected armory, litecoin and other wallets inside the virtual machine. 6) do not use the virtual machine for anything other than Sending and receiving crypto transactions, do not install anything other than the bare essential tools you need and do not surf the internet with it.
from inside the virtual machine you should also be able to create a paper wallet for cold storage.
This only works if you never use the host (hypervisor) for anything but launching virtual machines. If the host is compromised: so is the virtual machine. Keeping it encrypted is about the same security as keeping your wallet encrypted. If you never spend funds, an attacker can't either (assuming the passphrase is secure). How can two wallets be made to transact at the same time with a single transaction?
If all else fails, this can be done manually. Coinjoin transactions take advantage of this.
|
|
|
643
|
Bitcoin / Project Development / Re: Proposing Nanocompensated Servers and a New Paradigm of Social Networking
|
on: January 20, 2014, 03:01:39 PM
|
I think I found a major design flaw in the proposal: If the sever wants to get paid, the owner of the server must have a private key only they know. However, if the user is expected to sign all transactions with the the same key: they must also know it. The implication is that if the user was to withdraw funds, they don't actually need to ask the server permission. Because you are micro-billing by the table entry, it would cost extra money to delete all of their posts as well. Doing so automatically may upset users who did not do this on purpose. For example, Bitcoind automatically spends from all coins the user has access to. However, to sign messages, the user must have the corresponding private key in their wallet. There is also the issue where the user much unlock their wallet for mundane status updates: mostly defeating encryption. One conceptual problem with the design is that bitcoin addresses are not intended to be account numbers. Apparently Bitcoind supports "accounts" that do not actually correspond to specific coins at all (it is possible to have a negative Bitcoin account balance). When sending coins to the server, there may be more than one coin sent. Each coin will have its own input and corresponding private key. With the use of coinjoin transactions, these may not even all be controlled by the same entity. Stealth addresses may mitigate some of these concerns. Using Elliptic curve Diffie-Hellman (ECDH) we can generate a shared secret that the payee can use to recover their funds. Let the payee have keypair Q=dG. The payor generates nonce keypair P=eG and uses ECDH to arrive at shared secret c=H(eQ)=H(dP). This secret could be used to derive a ECC secret key, and from that a scriptPubKey, however that would allow both payor and payee the ability to spend the funds. So instead we use BIP32-style derivation to create Q’=(Q+c)G and associated scriptPubKey. - [Bitcoin-development] Stealth AddressesBTW, that reddit link appears to be circular: linking back to the same post for the "the technical writeup". I also don't understand how the rock paper scissors example can properly work if all of the database entries are public and verifiable. The code does not require both submissions be submitted at the same time. I am not even sure that would be technically possible since relational databases need to serialize updates. I also feel that "wallet seeds" (essentially a brain wallet) should not be supported. You say yourself that "to handle money, a deep understanding of... the intricacies of using Bitcoin is required." You go on to say the the goal of netvend is to "(provide) every internet user (with) easy and cheap access to a neutral server that solves many of these problems." Brain wallets are very insecure unless you know what you are doing. People tend to overestimate the entropy of their passphrases. "Wallet seeds" should not be used: even for examples. If people insist on using a "wallet seed", they can go to brainwallet.org and copy the resulting private key from there.
|
|
|
645
|
Bitcoin / Bitcoin Discussion / Re: Say bitcoin eventually reached 100k per. How much do you think transaction fees
|
on: January 16, 2014, 06:39:11 AM
|
Currently the minimum suggested fees are kind of hard-coded. You currently can't sent transactions of less than about 5000 satoshies.
I think I the price really does go up, it will cost about 10µBTC (1000 satoshies) for the average transaction. At $100,000 per coin, that works out to about $1 per transaction. The fees would help pay for expensive network access full nodes need to maintain. Edit: miners get the fees, not normal nodes though.
|
|
|
646
|
Bitcoin / Bitcoin Discussion / Re: Bitcoin safety deposit box/wallet...Insure your coins
|
on: January 16, 2014, 06:29:50 AM
|
What kind of rich asshole has millions of dollars worth of bitcoin but can't be bothered to take ONE DAY to learn how to secure them safely and save at least $20,000/year (per million) on fees? This jerk would also have to trust a third and a fourth party (insurer and government) when neither is necessary if you can simply manage to secure or hide A STRING OF CHARACTERS. It would take at least a day to set up the insurance policy anyway!!
The proposition is not as easy as it sounds. In the article excerpt (no source is given) Bitcoin vault offering insurance is 'world's first' BBC Link. The article does not say anything about storage in multiple locations. You want to guard against two competing things: I think the current best way to do this is spit the keys with m of n transactions and Pay to Script hash, and store them in 3 geographically separate locations. The actual vaults should be sealed such that tampering can be detected and the keys regenerated if needed (which opens up social engineering attacks). I am not sure a rich a Bitcoiner can't do better, based on information from the sparse article. Hopefully their insurance company was able to vet their security procedures while keeping the unique properties of Bitcoin in mind.
|
|
|
647
|
Bitcoin / Bitcoin Technical Support / Re: Hypothetical: So, your cleaning out closet, boot up old PC from 2010 and find...
|
on: January 16, 2014, 06:06:00 AM
|
I locked myself out of my own wallet. I think I recall choosing the length such that I can likely brute-force in the next 40 years (about 72 bits96 bits of entropy). I have it written down, so actual typos should be testable within a day.
I am thinking eventually wallets should start to integrate a "crack the password" feature. Though that would not work for extremely long/high-quality passphrases.
OP: I recommend backing up your wallet. Would suck if you crack the password, only to learn the drive crapped out.
|
|
|
650
|
Bitcoin / Hardware wallets / Re: Let There Be Dark! Bitcoin Dark Wallet
|
on: January 14, 2014, 09:15:17 PM
|
It seems a pretty safe method, except the needing to be careful part. Sort of a manual form of trezor.
trezor also does key calculations off-machine. I reasoned that while a separate machine is ideal, malware can still piggy-back on USB keys.
|
|
|
651
|
Bitcoin / Hardware wallets / Re: Let There Be Dark! Bitcoin Dark Wallet
|
on: January 14, 2014, 09:06:51 PM
|
Do you mean the private keys are on your machine only at the time of a transaction?
Yes. I have been using Addresses generated off-line with Vanitygen. I only copy the private key immediately before sending the funds. Using this as an outline, but moving the private key step downI installed multibit for "normal" transactions, but have not been able to actually spend any funds with it yet. I think technically, all the coins are actually stored in the Block-chain PS: I am not necessarily advocating other people adopt my practice. Manual transactions are error-prone and may involve unusually large mining fees if you are not careful. I hope to upgrade to N-of-M +P2SH transactions for savings, but that is likely off-topic.
|
|
|
652
|
Bitcoin / Bitcoin Discussion / Re: Bitcoins Y2k moment to remove the Decimal places fast approaching.
|
on: January 14, 2014, 07:24:48 PM
|
Ok, I didn't put OP on my ignore list because I thought the quantum kitten was cute.
This is a bad topic title. Shifting the decimal place is a solved problem; assuming Satoshi sub-division is not needed: just use mBTC and 5 decimal places.
I agree Doge may be popular because they chose "better" parameters. However, Bitcoin has not yet proven it is scalable enough to actually need any extra precision. It may become a reserve currency: only used for large transactions. The fees may become comparable to wire transfers today.
|
|
|
653
|
Bitcoin / Hardware wallets / Re: Let There Be Dark! Bitcoin Dark Wallet
|
on: January 14, 2014, 03:57:25 PM
|
well, I have been using the sx tools to manually build transactions: without having the coins actually stored on my machine until I move them.
The project seems to be a effort to tie together a bunch of separate tools that together can replace Bitcoind that tries to do everything.
|
|
|
654
|
Alternate cryptocurrencies / Altcoin Discussion / Re: Openex hacked but coins recovered
|
on: January 14, 2014, 03:50:08 PM
|
What I was really getting at is why not use a framework, it gives a fair amount of security if used correctly.
I honeslty feel like it would dimish the accomplishment. when you write your own stuff, you have a more intimate knowledge of it than you would with a framework. I face-palmed here. It is "not invented here" syndrome. The problem is that computers are too complex for any one person to know. That is why abstraction is used. The difficulty I have with abstraction is that the abstraction layer (there is more than one) is rarely proven correct. This can lead to abstraction leakage. However, to start proving a whole system is correct will take many man-centuries. It is not something you can do on your own. Myself, I have been delayed months setting up a simple Bitcoin node intended for merged-mining. I may be overly cautious compared to you.
|
|
|
655
|
Bitcoin / Hardware wallets / Re: Let There Be Dark! Bitcoin Dark Wallet
|
on: January 11, 2014, 04:45:51 PM
|
Will this implement coinjoin by default for transactions or enable one to participate continuously in the background when running?
Doing Coinjoin transactions in the background sounds like a bad idea to me. First, it would require a network-connected machine to have access to your private wallet keys. Second, even if randomized, the "spam" transactions may be distinguishable from real transactions. The way coinjoin integration should work is: if you don't need to send immediately, the client should look for other coinjoin participants.
|
|
|
657
|
Bitcoin / Mining / Re: Miners: Time to deprioritise/filter address reuse!
|
on: December 16, 2013, 11:58:36 PM
|
The structure of HD Wallets is presented here. If your are storing leafs, they have 512 bits of data. This is about twice as much data as traditional keys. In the "serialization format" section, it says that the keys are up to 112 Characters in base-58 format, which is longer than traditional addresses, IIRC. However, in theory, you only have to back these up once. I think a more interesting question is if this can be made to work with Pay to Script Hash and M-of-N Multisignature Transactions.
|
|
|
659
|
Bitcoin / Development & Technical Discussion / Re: CoinJoin: Bitcoin privacy for the real world
|
on: December 16, 2013, 05:58:29 PM
|
Are you kidding me? This is not any new technology - personally I would not even call it an invention... IMHO, it is rather a legal advise to use a plausible deniability in a possible cases against you.
...
CoinJoin does not create any additional privacy - it is actually less private than regular translations, since the process involves letting other people to know which coins are yours. At best, it only gives you a reason to claim in court that not all the inputs were yours. The core of the "solution" here is a legal advise based on a technical properties of the bitcoin protocol.
Privacy is not only for plausible deniability in a legal case against you: as waxwing alluded to, it is also designed to give plausible deniability if local thugs figure out you frequent a Bitcoin accepting shop and likely have a fat wallet. I am not convinced doing coinjoin transactions with yourself gives the same deniability. You would first have to split your funds (a good idea anyway with the relentless climb in value), then mix them. However, without other parties, the spitting and mixing with no external links will look obvious on a graph of transactions.
|
|
|
|