In theory, you should be able to create scripts that could be satisfied with multiple keys. In practice, you'd usually do this with P2SH, at least now, and the hash of the script becomes the address.
|
|
|
The database is going to be your best bet.
Way too expensive. I reckon my original plan might be the cheapest option yet, even if convoluted. Also, you might want to consider using the cold wallet to protect the hot wallet, not to protect individual accounts.
I may be missing what you intended to say, but the cold wallet is used to protect the hot wallet, which happens to have several accounts. Note that these accounts are not associated with external users; they all belong to me, and are just separate for administrative/accounting purposes. I can't imagine any possible database where a single query is going to be more expensive than a RPC call to bitcoind. Change your administrative plan. What you are trying to do isn't worth it. Set your policies based on the wallets, not the accounts.
|
|
|
Why on earth would you think that a Bitcoin economy would be any different than a conventional economy in terms of wealth disparity?
Show me 1 (just one) modern, free economy in which .001% [1] of the people own 70% [2] of the wealth. Just one. Otherwise you're not thinking this through. [1] assume cabal is 10 people and this number should reflect the percentage of those people against the number of people using btc today, so I may not have this number right, and someone can correct me [2] 10MM btc in circualtion today 7MM is 70% of that Money is not wealth. Money is what you use to buy wealth. (For simplicity, I'm including bitcoin as a subtype of money.)
|
|
|
But I wonder how they managed to determine the exact number of unique address owners:
Read the gist link (above). Their paper includes assumptions about addresses that are obviously wrong: A very important feature of the Bitcoin network is that a transaction involving multiple sending addresses can only be carried out by the common owner of all those addresses, as it is demanded by the Bitcoin system that "Whoever sent this transaction owns all of these addresses". This legal requirement is also technically ensured by the fact that each received amount must have a cryptographic digital signature that unlocks it from the prior transaction.
I would say that he is right for certain values of "all". If you pick a transaction at random from the chain, the odds are overwhelmingly high that a single owner controlled all of the input. Thus, he is "mostly right", and his conclusions are likely to be approximately correct. Fortunately, that will change over time as we develop easier ways to do multi-party inputs, and as web services with shared wallets become more common. I always try to discourage people from multiple wallet schemes because shared wallets obfuscate things in a good way. Consider the Model T, an early car. Conclusions drawn from study of that car are likely to be mostly right when most cars are like that, but they don't have to stay mostly right as cars diversify and grow ever more complex.
|
|
|
The database is going to be your best bet.
Also, you might want to consider using the cold wallet to protect the hot wallet, not to protect individual accounts.
|
|
|
I got my order on Monday. The chocolate is good, and so is the print quality.
They came in a cooler with gel packs to keep them from melting. I suspect that accounts for a big part of the shipping cost.
|
|
|
Doing a little research will tell you lots. Want to know who's finding more blocks than the top 5 pools combined right now?
IP: 82.130.102.160 Decimal: 1384277664 Hostname: nb-10391.ethz.ch ISP: Swiss Federal Institute of Technology Zurich Organization: Swiss Federal Institute of Technology Zurich Services: None detected Type: Corporate Assignment: Static IP
No, they are just relaying them. The hilarious part is that a little "research" would have led this guy to about a dozen threads. In fact, the very first search result for that IP is the thread that ends with this post.
|
|
|
Do we really need this thread every time bitcoincharts loses track of one of the pools? There is a big disclaimer right at the top of the page.
|
|
|
I always thought that my exponential climb for deep replacements was a good middle ground here. The main objection to it was that it might sometimes require human intervention on a node, which never bothered me.
|
|
|
I tried to sell some products for bitcoins and guess what, nobody buys! This may be due to the prices which are a little bit higher than the price in dollars, but it may also show that bitcoin is not preffered for buying goods. So perhaps it will remain only an economical tool for the darkest corners of internet and a speculation area. Therefore, the bitcoin could not have a very bright future.
Maybe the sorts of people that buy your products just haven't heard of bitcoin yet.
|
|
|
800 MHz times 64 cores is 51,200,000,000 instructions per second.
SHA-256 takes about 3000 instructions per round, and has 64 rounds, so 192,000 instructions per hash.
Gives about 266 kilohashes per second, per chip. Not great for mining.
|
|
|
I think never.
It may contain multiple vouts, but each should have only one address. Even with multisig, I think the address shown would be the hash of the multisig script.
|
|
|
Denial of service attack of the pools... Reduce overal network hashrate... Then you would need substantially less hashing power to get >50% right?
I am naive about the network.... But can you trace back large solo miners from the network as well via IP? That way you could knock out a couple of them as well... Just thinking outloud.
I should point out that you are competing with the difficulty, not the network. You would need to take down the big pools, and then hold them down for ~2 weeks before the difficulty adjusted down. Oh, and you wouldn't just need to keep the pools down, you'd have to keep their users from switching to other pools for that whole time too. P.S. subSTRATA, go fuck yourself.
|
|
|
Someone asked in a PM, so I wrote an example. <?php $bits_desired=256; $bytes_desired=ceil($bits_desired/8); echo "Asking for ".$bits_desired." bits of random (".$bytes_desired." bytes)\n"; if(TRUE==($fp_ent=fopen("/proc/sys/kernel/random/entropy_avail","r"))){ $ent=trim(fgets($fp_ent)); echo "Entropy available: ".$ent."\n"; if($ent>$bits_desired){ if(TRUE==($fp_rand=fopen("/dev/random","r"))){ $r=fread($fp_rand,$bytes_desired); echo bin2hex($r)."\n"; }else echo "Failed to open /dev/random.\n"; }else echo "Not enough bits available.\n"; }else echo "Unable to get status of entropy pool.\n"; ?>
|
|
|
Okay, I submit. I trust everyone. The devs will never lie. The devs will be perfect. (!)
We are trying to tell you that it doesn't matter if they lie or not, if they are perfect or not. The system was set up in a way that it doesn't matter, no one has to trust anyone. To do what you are thinking would require a magic wand, not a government. And even if one day all of the devs and pool operators woke up as their own evil twins, someone else would just fork the project and the chain at some point prior to the switch, and your life would go on as before.
|
|
|
Very few people can read code completely after release.
If only there was some tool that would highlight changes and provide annotation and discussion...
|
|
|
Are you absolutely sure the dev team couldn't change the Bitcoin network drastically through an "urgent" protocol update that happens to be immediately accepted by most miners?
What, like in secret? Like all of the congressmen, all of the senators and the President all get together in the middle of the night, pass a law, sign it in blood, and then send out the gestapo to round up all of the devs and pool operators? Sure, I guess that could happen. But if it does, Satoshi will ride up on his unicorn to save the day. The Federal Reserve Act of 1913 was passed in a similar fashion. Ok, so in your fantasy, the gestapo has rounded up all of the devs and pool operators, and tells them that they need to secretly change the protocol or their dogs will be killed. What then? What possible change do you imagine they could actually do? Be specific. You know, if you'd put like 10% of your forum trolling effort into learning how the system really works, you be so paranoid about it.
|
|
|
|