Thanks. One of the reasons I have not been active here recently is, besides that I've said most of what needs to be said (x3200 posts), there is no participation here from intelligent people any more, just spam scams and get rich alt coin schemes. Any legitimate service would be wise to steer clear of rewarding those who would destroy their own currency's forum for profit, and the ultimate solution was given nine months ago in post #1.

As long as it is clear that what you are purchasing is in no way a legitimate license to operate a Microsoft product or operating system, and may be an ill-gotten good, gained by leveraging hacked accounts and stolen credentials and funds from innocent victims...then maybe you're safe. Deceptively representing what is being sold is worthy of report.

A software audit from Microsoft or the BSA requires invoices and receipts from legitimate resellers for every seat or workstation, and is hard to comply with even if you normally buy shrink-wrapped software. Purchases of grey market goods like "internet keys" in no way provide the proof of purchase required to pass such an audit. A COA hologram sticker alone doesn't provide the proof needed by an actual software audit, and certainly some random key bought on eBay or a dark web site does not either. At most what is being sold is a (temporary) copy-protection bypass mechanism. Representing such keys as an actual license to run software is fraudulent and a negative trust warning is warranted.

Pretty much anything being sold on this site that could be a means to launder and profit from stolen passwords, accounts and credentials, or credit card numbers should be considered as such, without strong evidence to the contrary. The purchaser will likely be the person criminally investigated for the fraudulent use and gain from the purchase. If it walks like a duck...

If a seller says "for sale: stolen Netflix account username/passwords, working until the legitimate owner contacts Netflix or cancels the accounts, or until Netflix contacts the FBI to see who is currently logging in with the hacked account" or "Xbox account purchased with stolen credit card number from data breach, will likely work until credit card theft victim completes chargeback; by purchasing you are contributing to further for-profit criminal enterprise and hacking attempts from our lawless nation-state", then the seller at least is being an honest criminal.

The mouse cursor entropy-gathering was only added after it was pointed out the problems that the site/script had in simply using the javascript random method presented to the browser and lack of entropy gathering. https://bitcointalk.org/index.php?topic=399058.msg4315842#msg4315842

Now it is an annoyance you must pass through when you want to do anything else written into the do-everything page, such as decoding a private key you already know.

There's a link in my sig for an offline paper wallet/cold storage address generator. It only generates compressed addresses, saving you some bitcoin transaction fees in addition to reducing the blockchain size. It gets key-pounding entropy input from the user in addition to OS-based entropy sources. The private key generated is a completely random number that has no known biases.

https://bitcointalk.org/index.php?topic=361092.0

I sense that the computer failure caused an unexpected close/crash of the Bitcoin client. This would leave the blockchain index files in a corrupted or unsyncronized state. When restarting, Bitcoin re-checks the consistency of the last few day's blocks, and the first repair effort is to initiate a reindex if problems are found.

One solution is to use a journaled filesystem such as EXT4 on Linux that can tolerate some unexpected shutdowns and replay or back out incomplete data saves.

Bitcoin addresses beginning with 3 are a multisignature address. This type of addresses is used by the service in a 2-of-3 configuration. It takes two signatures to transfer bitcoins. This illustration sort of illustrates their use by the service:



A blurb from bitgo "the aforementioned multi-signature wallet that leverages both BIP16 and BIP32 standards found with hierarchical deterministic wallets; and a “2-of-3-key” configuration, whereby three keys are issued and any two can be used to sign a transaction. It ensures against loss or theft while allowing for relatively easy access."

The WAP2 links should be blocked from indexing by search engines. Hasn't been done. Even the Google result to find my post below returned the wap2 page.

I DMCA-noticed one of those sites and got them to remove my post ripped from bitcointalk. I was hoping they wouldn't respond so then I could send the takedown to their ISP.

Everything I write and submit here is copyright ME and I have provided bitcointalk exclusive license to its contents.

My apologies for naming trolls, but you seem so convinced of conspiracy that you are willing to make allegations without understanding. Dozens if not hundreds of coders have made contributions to Bitcoin and understand how it works, nothing that you postulate here could have gone unnoticed.

The link https://blockchain.info/nl/charts/difficulty?showDataPoints=false&timespan=all&show_header=true&daysAverageString=1&scale=0&format=csv&address=  - it shows wrong information. It fails to calcuate the "average daily difficulty" on days when there are no blocks mined. A correct answer would be "not applicable".

The difficulty is set at 1 in the genesis block, and is recalculated every 2016 blocks to maintain an average block finding rate of 2016 blocks in two weeks (six per hour). Difficulty 1 is the minimum allowed in code. A block hash must start with 0x00000000h or smaller at difficulty 1.

Here you can see the difficulty setting at every re-evaluation block:
http://blockexplorer.com/q/nethash/2016

Block 32256 is the first where the difficulty increased, to 1.18 - it is the first evaluation period where 2016 blocks took less than two weeks.


Here's one of the screenshots from early bitcoin that Satoshi used in documentation. It has addresses and transactions that are not seen in the release blockchain, but notably the dates are the same as the genesis block. The blockchain height is 213 blocks at that time though, so this may even be a chain using a genesis block before the Times headline. It is certainly expected that Bitcoin was tested privately in many iterations before it was released, with much discarded private mining.


Don't put more money into any investment than you can lose. Bitcoin will keep working, but there's no guarantees of what others will pay you for one.

What happens if I write my password down on two pieces of paper and then set both papers on fire, will I lose my password? Please don't ask such silly questions in a Theymos thread for the sake of spamming your signature.


There is an interesting aspect of RAID arrays when using SSDs in a mirrored configuration that can only tolerate the failure of one drive - you are writing identical data to identical drives, and should expect them to fail in identical ways, killing two drives at once.

Physical hard drives are more subject to mechanical tolerances that vary between samples. The disk coatings are not deposited equally, the bearings are not made molecularly identical, the windings in the heads and the motors aren't perfect matches. We would expect given a high intensity and identical load to two drives that it would be virtually impossible for them to suffer failure at the same time.

SSDs are different. Some drives have firmware that specifically bricks the drive or turns it into a read-only drive after a certain number of writes. While the actual memory cells may fail differently between the drives, they wear at a predictable statistical rate and there is a reserve of usually 2-5% of drive space of extra sectors that will finally be exhausted at nearly identical times given identical write patterns.

SSDs push the limit of what can be stored on silicon, so they have many layers of error correction to go along with the wear leveling. It is quite hard to get bad data back out of a well-designed Tier 1 drive.

However, failure of SSDs can be random and capricious, especially the OCZ/Patriot/Crucial bottom-tier drives that just shit themselves for no reason. As it is unlikely the forum completely used up the drive wear life on it's drives, it is more likely random crap-drive failure or RAID controller failure.

For reference, look at the tests here: http://techreport.com/review/27436/the-ssd-endurance-experiment-two-freaking-petabytes - they designed a test specifically to kill SSDs with writes and left it running 24/7 for over a year on six drives. You can see that the SMART wear indicators on most drives indicate the amount of drive life left, some lock up after the reserve is used, and some keep going into write error territory. Only one drive unexpectedly died. SMART analysis of forum's drives will likely indicate the status of the reallocated sector count and wear leveling count to see if failure was unexpected.

Outside of the SSDs themselves failing, most hardware RAID controllers are pretty dumb (and if you are spending less than ~$400 you are not even getting hardware RAID). They just write the same data to two drives. There is no error correcting or checksumming, so they are useless to fix corruption, and actually are less tolerant than just a single drive would be. If you want to see scary, look up "RAID 5 write hole", basically there is no way for these RAIDs to tolerate power loss, making on-controller battery backup super important.

Also, consumer hardware just plan HAS errors, and hardware RAID is not written to deal with them: http://www.zdnet.com/article/has-raid5-stopped-working/

Also majorly important is that the system must be running ECC RAM, and the RAID controller must also have ECC RAM if it has cache slots.

I am getting much more behind ZFS RAID. It is very impressive. It is software RAID run by the OS. This is no longer a bad thing. The CPU and OS has hundreds of times more processing and RAM than RAID cards. There is a journal written that can be replayed upon power loss and commits are made to the disk in a way that data will never be corrupted. Everything on the disks is self-healing with error-correction checksummed. The OS can talk directly to the drives and their SMART status to understand drive state. You can run RAID on standard SATA controllers, and when your motherboard burns up, mount the drives in any other motherboard and on any other controller. You don't need to have hot-spares and lengthy rebuilds, you can have RAIDZ3 - three extra drives of parity - so it would take three drive failures to take out your disk array.

Then mirror the whole machine automatically with High-Availibility storage (HAST) and CARP in BSD. Backups are now just for when the whole place burns to the ground.

I shouldn't respond to a troll OP, in fact I've managed to avoid responding to anyone for a while.

There are no concerns.

OP is a fucking idiot if he thinks that Satoshi Nakamoto somehow had advance knowledge or could have planted the exact headline in the London Times. It is about a newsworthy event that didn't happen before that date. Bitcoin really doesn't need a timestamping event in the genesis block to work, but if you read the whitepaper the blockchain is referred to as a timestamping mechanism, so this crypto metaphor is likely why we even have the effort made.

The genesis block is special and must be created ahead of time, and incorporated into the code. The six days between the known headline date and the release of Bitcoin onto the Metzdown mailing list was certainly to run some testing chains that were then discarded. There is screenshot evidence of unpublished testing chains made before release that were on bitcoin.org.

The chain was not premined. We can see Hal Finney's release day correspondence and even debug.log posts from Jan 10 where the chain was on the same blocks we still have now.

The lowest difficulty is not 0, but 1. This minimum difficulty level is set so that it takes about 4 billion double-SHA256 hashes of the block on average to find a solution. This is not a low difficulty, in fact it took over nine months before it increased even with many different miners running.

What we have in Bitcoin is better than the coin release schedule of every get rich scamcoin since then. At least a good portion were released to interested and contributing cryptographers rather than big money that could already harness mining farms. There is no pump-and-dump publicity effort by Satoshi, just academic discussion about the software. There appears to be a distinct number of coins mined by a differently-coded "bare minimum" heartbeat miner run by Satoshi during early days that have never been spend and I feel never will be spent as he only seems to have spent coins made by the normal Bitcoin client.

You can, the only element missing is the community karma you think you earn for tipping someone publicly. I just reconfigured my sig so you can click on the link when you have a desktop Bitcoin client installed.

More info about how that works: https://electrum.org/bitcoin_URIs.html

There's a thread where I helped someone who couldn't ignore a German user, so I tested that I could. I don't read German forums to have encountered his actual posts. I'll remove it from the post in case anyone actually wants to use my info.

My list is not an authoritative or maintained list, or supposed to be useful to you in any way, it's just what my current ignore list is on bitcointalk as requested by OP.

Are you actually going to use the graphic user interface version of the program, or just the daemon? Qt is only needed for GUIs written in it, and centos "servers" typically aren't installed with an xwindow system.

You do not need to do any chown commands on Bitcoin, especially giving it root. That would be a bad idea. You can simply uncompress it in a user home directory and run bin/bitcoind.

Additionally, 0.9.3+ is compiled with QT5.2, you should be using that version or higher on your system, the instructions are old.

To install Qt, this is going to be too difficult for you if you don't know how to run a program:
http://www.qtcentre.org/threads/57624-How-to-Install-Qt-5-and-Qwt-on-CentOS-6?highlight=centos

Instead include this repo using instructions from this message:
https://lists.fedoraproject.org/pipermail/fedora-kde/2013-March/012437.html

It has qt5-qtbase-* in the testing repo, which should get the job done http://download.kdeforge.net/kde-redhat/redhat/6/x86_64/RPMS.testing/

That's my list from bitcointalk. Once you go on, you don't come off. The few instances I have read an ignored person's post to see what they wrote, it was never something worthy to care about them again.

It uses OpenSSL.

https://bitcointalk.org/index.php?topic=179464.msg1877732#msg1877732

Here ya go

kokjo
bulanula
hdclover
The_Duke
bitpop
punin
Micon
becoin
misterbigg
smoothie
Blinken
buttcoin1
Hippie Tech
giantdragon
martychubbs
Gerken
Surawit
ClownCoins
astana
Daily Anarchist
ALPHA.
MPOE-PR
gweedo
posormo
Hyena
notig
Sonica
crashoveride54902
The Fool
aantonop
sublime5447
hennessyhemp
BitHits
jubalix
mai77
wingding
Pangia
St.Bit
ISAWHIM
MobMin
scottii
cryptocoinsnews
marcotheminer
BADecker
U1TRA_L0RD
hartvercoint
CryptoCurrencyInc.com
YouAreABetaProvider

Mostly shameless spammers or those that need a personal permanent reminder to me that they are trolls.

Cold storage, a "savings account" for putting away Bitcoins in the most unhackable place, shouldn't include regular wallet software. That's not what it's designed to do.

You should generate a single address/privkey offline, booting into a LiveCD/secure environment, and store the generated paper wallet in a secure location(s). Use the same method to make several keys, and test (and then discard) one with small BTC amounts to be sure you understand the creation, securing, and spending procedures.

See the last line in my sig.

If you have some text-edit finesse, you can turn a list of keys into a list of import commands. From another thread:

Just make the final line "true" to reindex.

Any software doing signing should do the smart thing and call multiple security libraries for random, and/or mix those with native calls to /dev/random. Every individual random lib should not only be considered potentially backdoored when used exclusively (only safe when XORed with another source), but also equally likely to be broken on any given platform from library or hardware/system access failure.

Additionally, there should be checks to disqualify the whole process if any individual element or the random function code as a whole fails robustness tests. What if the getRandom function in your code is returning all 0s or 1s or the same value every call? Probably not random. More creative thinking could detect and abort on other flawed random scenarios that have previously been seen in libraries or have been introduced in code.

A random function should be compartmentalized in code, with methods/APIs to check each entropy element, and we should have a standard-practices algorithm to prequalify and detect the worst kinds of broken that could lead to lost coin. Publish and community-review this meta-code function and demand its use from anyone operating any Bitcoin service.


I echo the sentiment that it is not worth developing any kind of "brain" based wallet, and that people who trust people to make their own passphrases are not people to be trusted with people's passphrases.

I had contemplated making a brainphrase-to-deterministic-wallet creator, but even if it used ten minutes of GPU time hashing through various combined key derivation functions per passphrase, it still could not be secure, being limited by the unbounded inventiveness of dummies using easily guessable passwords.