mix coins because why?
To protect yourself from cybercriminals. |
|
|
|
Let us not forget that even inside a VM any virus/exploit is already BEHIND your main defense and can easily access the ip addresses of any computers on your internal network(not to mention default passwords/access on your router!!)
Including the machine the VM is being hosted on…(not much point in having a DMZ, if you are going to put shit inside it…)
and that is before we even consider the capability to crash 'out' of a VM. You're assuming the most simplistic possible implementation of virtualized networking. Also, using off the shelf routers is a really bad idea. All that shit's rooted. |
|
|
|
If you want to use them, you must seek out a miner who will agree to mine these transactions for you, and it will take a very long time for it to get into the blockchain. i.e. if you make an agreement with a miner that represents 0.5% of the total network mining power, it will take an average of 200 blocks (1.3 days) for it to be mined. It may take a few hours, or a week, depending on that miner's short-term luck.
Or you send them to Eligius with 17% of the hashing power and it will take an average of 6 blocks to be mined. |
|
|
|
|
This is exactly what Second Market is planning to do.
It remains to be seen whether or not they'll get away with it.
|
|
|
|
|
Bitcoin wealth disparity is a problem invented problem by people who aren't nearly as good at analyzing the blockchain as they think they are.
|
|
|
|
Although I wouldn't normally recommend this, I think it's no so bad to do that as long as it's your online computer with watching-only wallets. Anything stupid that the online computer does will be caught by the offline computer (as long as you actually check all the transaction details before continuing).
Of course, I may be neglecting some corner case situation, so I still wouldn't put an official endorsement behind it. But having a stable version that does the reviewing and signing certainly reduces the risk considerably. (but definitely don't use it for your offline computer yet, unless it's tiny amounts of money) Yeah, I think I still use 0.88 on the offline computer because the risk/reward of updating the offline machine isn't favorable. I thought maybe I should add a "don't try this at home" disclaimer to my other post, but on the other hand I think anyone capable of using git can make their own risk analysis. |
|
|
|
Thanks for the positive feedback! Understandably, most people post and communicate with us when things don't work, and it's not a high priority to contact us when it does work. It makes me feel like it doesn't work for anyone, even though it obviously does -- we had more than 20k downloads last month...and less than 20,000 nasty emails  So, it feels good to hear a success story occasionally. The 0.91-dev branch on GitHub works for me well enough that I use it as my primary wallet. |
|
|
|
Armory M of N backup of an offline created wallet stored in multiple different physical locations.
Why do people still talk about secure storage as if Armory hasn't solved that problem for years? Armory works. Just use it. |
|
|
|
d00d, it is just a money grab scheme. Relax, chill out. Someone will have several free lunch for a good period of time.
No. Its not. Its far more likely its an "I want to meet Satoshi" scheme. Andreas doesn't steal Bitcoins from people. He has a long history of donating. -B- Andreas is pissed at the news media right now, and part of the reason for this campaign is illuminating and correcting the damage they do. |
|
|
|
Why do you think I do not know how Bitcoin works and at what level of understanding I should be to code the app? For one thing, you're talking about the balance of an address. That means it's virtually certain that you're tracking the wrong things. D&T appears to have more time/patience than I so you should ask him about it. |
|
|
|
Data integrity: Lets say I do not use bitcoind accounts. I have N addresses in Wallet and my own SQL database with addr-user (n:1) mapping. I really need user to have many addresses. So, when I display addr A to some user, I have to check for transactions to the addr A in some point in time and update my SQL - cron could be my friend in this case.
But, I have to scan all the addresses in my SQL with current balance to find out user balance! I have to use "deep" scan - I can not assume each address has static balance - the wallet sends btc from addresses it decides are optimal. So, I have to use for example blockchain.info API where I can pass many addresses with minconf and it returns balance from corresponding TXs which have minconf confirmations. I am sure bitcoind's rpc functions do not support many addresses as input and not sure if it could retrieve balance at minconf from one addr either.
It is pointless to cache user balances in SQL, because it may be changed at every user withdrawal. No way to say "send ONLY from THIS address".
And many more problems...
Atomic or synchronization problems: User wants withdrawal:
0. I need to set set semaphore/lock or make this withdrawal function serialized.
1. I deep-rescan his balance B1.
2. From this moment, the actual balance A1 >= B1 (he could send funds to his addr in the meantime).
3. The second withdrawal (attack attempt) comes at this time. Because of point zero 0, it waits blocked.
4a. If point 0. does not exists, each of two or more server instances/threads retrieved balance B1 (in fact, B1 and B2, B1==B2 or B1!=B2) and I command my wallet "send B1 amount to some user address" - two times!
4b. If point 0. exists, I commant my wallet "send B1 amount to some user address" - only once.
5. Withdrawal function ends and unlocks second attempt to withdrawal, which continues from point 1. Before you try to build whatever you're building, you really should learn how Bitcoin works so that you don't base your application's design on incorrect assumptions. |
|
|
|
let's challenge him. Just wish him luck with the new altcoin he'll be creating and move on. |
|
|
|
|
Show Posts
