Comments:
* Cloud-based virtual machines are easier to wiretap or hack than dedicated servers.
* Most CPUs are likely to have a backdoor in them, even in hardware purchased outside the US or Europe.
* Your servers can be seized no matter where you locate them.
|
|
|
Bump, due to renewed interest.
|
|
|
Fixed the date in thread title. The thread date should be the date of the article, not when the article is discovered by the poster.
|
|
|
Hey all,
I am looking to check the balance of an address I don't own (e.g. 1HtUGfbDcMzTeHWx2Dbgnhc6kYnj1Hp24i) from the daemon, is this possible using an existing command? I have tried getreceivedbyaddress and listreceivedbyaddress but they do not seem to work.
The easiest way currently is to visit http://blockchain.info/ or http://blockexplorer.com/There are a couple features under development which will enable this facility in a decentralized fashion, for anyone using Bitcoin-Qt or bitcoind: 1) An optional address index is being added, for searches such as these 2) A pull request exists for "watch only address" support. A watch-only address is an address in your bitcoin wallet for which you do not have the private key. With this feature, bitcoind will dutifully watch for any transactions on the watched addresses, just like a normal bitcoin address you control.
|
|
|
It can be done with the Raw Transactions API but not easily. You'ld use listunspent to get a list of transactions and filter that for the address you are checking on. - http://en.bitcoin.it/wiki/Raw_TransactionsThat will not work for "an address I don't own" -- listunspent looks in the wallet.
|
|
|
I used to pretty much assume that every time I run "yum update" or "yum upgrade" a CIA officer could be in some RedHat (or Mirror site) office telling some techie "Yes, that's the guy. He gets the worm/trojan".
Basically that they could target, everyone else getting a perfectly normal copy of whatever thing they wanted me to have a backdoored copy of while I get the backdoor.
Sure, they have the signing key after all. There is a highly secured (note I did not say "secure") signing robot that signs packages after they are built on a build farm. As long as you are "inside the moat" and appear to be a build machine passing along properly built RPMs, your packages will be robo-signed. Same goes for most, if not all, other distros. The signing takes place somewhere in the automated build system apparatus.
|
|
|
I think it is unlikely that people working for NSA would have discovered an exploitable bug, before people who don't work for NSA. Personally I don't find the kind of people that work for intelligence agencies as particularly intelligent - if they were intelligent, they would have had an honest job. So IMO, NSA employees have much lower chance to find security holes in open source code than the rest of the world.
I disagree completely with this assessment. So much so that it makes me wonder about bitcointalk PsyOps
|
|
|
Multisig addresses are fully visible in blocks, just like regular addresses. I was talking about using the bitcoind client. Are you suggesting that bitcoin users should manually parse the blockchain to determine if their funds arrived? This is a fair criticism, and no, average users cannot be expected to parse the block chain. Average users can, however, watch a specific address on blockchain/block explorer.
|
|
|
The tools for multisig are admittedly poor, at the moment. Multi-sig introduces an interesting concept: bitcoins that you might be able to spend. Therefore, your balance only shows bitcoins when you control 100% of the private keys. Right now, you need to take a few extra steps. Some tools outside bitcoind exist to help with multisig, but in general, additional work is needed in this area.
|
|
|
My fault, I admit. I should have specified simple manual more clearly. Simple configuration instructions for various hardwares: * Avalon * BFL * ASICMINER * ... And configuration information for each major mining software (bfgminer, cgminer, guiminer?). The reader of the document is probably someone who may or may not know much about bitcoin, so it should be basic, "Push Here Dummy" instructions. Ideally, another Chinese reader will agree that these instructions are error-free, for verification. ETA: Payable when the site administrators update http://eligius.st/ or eligius wiki with your document.
|
|
|
Wanting to promote Chinese use, I offer a 1.0 BTC bounty for a complete Chinese translation of Eligius, or 0.5 BTC for a simple document in Chinese that describes how to mine using Eligius.
Ditto for Russian, though at lower bounty prices: 0.25 BTC for simple "Eligius User Manual" in Russian.
|
|
|
I am unable to compile 0.8.4 in Debian 7. I checked out 0.8.3 and was able to compile with no issues. When I switch back to 0.8.4 I get the following:
Your paste indicates you are building the development version (master, aka pre-0.9), not 0.8.4 release. Your 0.9 build fails due to lack of the protobufs compiler, "protoc" You want to check out the v0.8.4 branch.
|
|
|
OSX: use 'FD_FULLSYNC' with LevelDB, which will (hopefully!) prevent the database corruption issues many people have experienced on OSX.
Thanks very much for addressing this one! +1 Well... please help us confirm that the OSX issue is fixed. Note the "hopefully!" tag...
|
|
|
My standard, per-version refrain: If downloading a new block chain, then download the torrent: [ANN] Bitcoin blockchain data torrent https://bitcointalk.org/index.php?topic=145386.0Torrent handles bursty behavior such as new releases nicely, without loading the bitcoin P2P network so much. (if you are upgrading and already have some block chain, this message does not apply to you)
|
|
|
Merged an important bug fix, ensuring bug-for-bug compatibility with reference implementation's SignatureHash() https://github.com/jgarzik/python-bitcoinrpc/ was also merged into this library, so that RPC support does not require a separate library. Thanks to Peter Todd for both updates.
|
|
|
Merged "addnodes" support, so that additional nodes may be added via configuration file.
|
|
|
Here's another 10 BTC. With the recent USD price of bitcoins, I wouldn't even say "it's not much".
Retracting my offer, as GPUs are now useless for sha256 mining. Yes, the OP was long ago updated to reflect current bounty status (15 BTC from me).
|
|
|
Forgot to mention... the following python util, linearize.py, was checked into the bitcoin repo today: https://github.com/bitcoin/bitcoin/tree/master/contrib/linearizeThis tool may be used to recreate bootstrap.dat byte-for-byte identical with the bootstrap.dat in this torrent. If you are running bitcoind locally, create bootstrap.dat locally, then start seeding the torrent immediately at 100%!
|
|
|
|