BTW: Pocket WiFi = cellular network standalone WiFi hotspot.

It is very possible that the device or the ISP is doing a man-in-the-middle proxy, decrypting and then resigning https traffic. Don't do it.

You should be able to use the browser to investigate the https certificate you are getting - what domains it is valid for, and who the issuer is.

Here is the current valid certificate for bitcointalk.org:

Issuer:
CN = COMODO RSA Domain Validation Secure Server CA
O = COMODO CA Limited
L = Salford
ST = Greater Manchester
C = GB

Signature:
Size: 256 Bytes / 2048 Bits
34 47 69 a3 ab 30 85 82 91 9c ba 59 f6 cd 9a 99
7a 98 b1 29 10 61 a1 7b 69 5a f6 a2 df d2 a3 b7
13 77 44 f4 b4 1d 9c 9c ba ea 38 1d 05 2a cd 51
96 66 25 cc cd 8a c9 bd cc f4 1c 1a 88 02 db 2a
1d f3 91 54 21 43 66 f9 c8 34 2d 73 0b d5 c5 c5
87 3e 56 50 47 b2 62 b7 f3 d7 63 f4 6a b5 1e fc
31 e9 6e b7 cb b7 85 03 c1 cb ef d1 60 d1 ab 6e
55 64 3b 29 87 93 89 4f 5e 7e c1 9f 4b d1 8f 4f
69 71 03 2f 60 51 34 89 8a 0e 31 ea 55 5f 29 72
af 3d c7 1f 84 82 3c fa d7 74 0d 9f b9 37 d3 81
fe de 18 b8 f4 c7 9a f3 03 b3 62 2a 39 42 3b 82
09 e9 25 89 7a 51 ad 6d 59 d3 41 c3 6d c7 80 70
73 4c c3 88 d6 01 b6 cb 33 3e c9 e8 01 95 92 b6
23 28 39 da 42 40 52 67 0d 15 9f 4f ba 03 c1 f1
30 5a ee 16 bd 3c 18 ee a1 81 42 18 22 2a 2d 6a
7f 8d ca 11 da a6 6a 0f d2 90 b0 a8 a6 ae f1 61

The Bitcoin network did what it was supposed to do, no action from anyone here made the transaction confirm.

The problem with PayPal is that they can suck the money back out of the recipient's account many months later, for credit card chargebacks, fraud, stolen accounts, etc. Unless you want an Escrow agent that hangs on to your payment for the year it takes to really be "clear" of these risks, it is not practical.

No fee, likely because you didn't add any optional fee in the settings of your non-upgraded Bitcoin client. Bitcoin up until 0.12 had a priority system that allowed large transactions of coins to move for free with relatively little aging, and there was block space reserved in each block for the processing of free transactions, since they are not spam-like.

Since there was no monetary incentive for including these, some miners reduced the free transaction space, or opted to include transactions for only paying customers. Bitcoin 0.12 has largely disabled the priority system for both sending and for miners, so a fee will always be included that should get you fast confirmations. Since the free block window is minimized, there may be increasingly fewer miners actively including these legacy transactions.

It is still a valid pending transaction that will be in most client memory pools, and I would wager would be picked up within six blocks by somebody.

You could hedge your bets by removing the broadcast transaction from your wallet and sending another with fee, but:

1. You can't guarantee that the same coins will be used for the second transaction unless you are a coin-control expert; you could end up sending the recipient two completely different and valid transactions funded with different coins, and they receive both,
2. The original transaction will still exist in relay and miner mempools, the second will be seen as a double-spend attempt if it sends the same coins, and will be dropped.

The address can be posted anywhere and be known throughout the world safely. There are many public addresses of organizations that have large amounts of bitcoin in them. There is no crypto vulnerability that will let you be "hacked" by merely publishing your address.

When you publish your ownership of an address, along with that comes a loss of privacy, though. Without special steps being taken, it is possible to discover people who sent money to the address, and we can see the address's balance and where you sent the money after you got it. You may put yourself in personal jeopardy or may invite more hackers to try to crack into your system if you are identified as being "bit-rich"

More importantly, though, wallets do not take special care to separate your public address funds from funds you wish to remain private. You may unwittingly reveal that you are the owner of other addresses. When you spend money, the transaction may be funded using both coins sent to the public address and coins sent to other addresses, indisputably disclosing your ownership of other addresses also.

It is discouraged to reuse an address, because to spend the money, the transaction (included in the blockchain) includes the full public key. This removes one security layer from the address. Other procedural faults, such as a bad random number generator used in the transaction signature generation, are then exposed to exploitation.

I've tried to replicate Python project py2exe binaries on other computers to make a reliable verification procedure and not had luck. For a start, you need the same setup.py file, and one character different (in the version string that shows up when you right click, for example) makes it not hash right.

Here's the setup.py I likely used to create the exe:

Of course using different version of py2exe script byte-compiled on a different day with different windows libraries and modules graphed by the py2exe script with the moon in a different phase makes it different.

You did discover that the base py2exe options creates a small file reliant on the system's installed python modules. I had the same dependency problem with attempts using cython. The py2exe binary is partly ZIP file, you can extract the files to see the python interpreter and many other byte-compiled files included.

Signature shitposters would have to figure out some other way to turn their contentless annoyance into micropennies.

The network and nodes are relatively stable, we aren't tiebreaking between orphan or attack chains dozens of blocks long. The current rule where the majority decides "the chain I heard about first is the one I trust" is a good way of deciding blocks. It is not uncommon for miners to publish block solutions within seconds of each other due to network latency; orphans happen all the time. "First to get the block published, wins" is thus logically fair and creates the least reorgs.

I updated the first post with a more verbose description. It should now be an answer you can provide to most "paper wallet...what?" questions.

No reason to change the two-year-old code. I anticipate changing hosting providers in the next month if anybody keeps track; this free and open-source code could also go up on a git/svn site, but taking contributions & trust is problematic, as well as hosting somewhere more vulnerable to hacking.

The blog post is also incoherent nonsense about procedures to verify a signature meant to spoof non-tech journalists.

Compare to the clear communication of Satoshi emails and white paper, which I have HTMLized here: http://we.lovebitco.in/how-bitcoin-works/bitcoin-paper/ - or any of Satoshi's year of posting on the forum https://bitcointalk.org/index.php?action=profile;u=3;sa=showPosts;start=340 - biggest bullshit artist that now deserves NOT to get left alone.

Gavin's blog site is also serving up a bad cert, so it's a decent conclusion that the message confirming Wright's identity is a hack:

The displayed private key is probably raw hex. What you are looking for is wallet import format, which uses Bitcoin's base58 encoding plus a checksum:

https://en.bitcoin.it/wiki/Wallet_import_format

You can view a key in different formats after downloading the bitaddress html w scripts that run on your computer: https://github.com/pointbiz/bitaddress.org

The wallet import format has a checksum in it just like Bitcoin addresses. It is possible to quickly determine if a candidate "recovered" key is valid:

WIF checksum checking

1 - Take the Wallet Import Format string

2 - Convert it to a byte string using Base58Check encoding

3 - is the beginning byte string 0x80? If not, invalid.

4 - Drop the last 4 checksum bytes from the byte string

5 - Perform SHA-256 hash on the shortened string

6 - Perform SHA-256 hash on result of SHA-256 hash

7 - Take the first 4 bytes of the second SHA-256 hash, this is the checksum

8 - Is #7 the same as the last 4 bytes of #2? If not, invalid.

If we have such a checking routine that can try hundreds of WIF key checksums per second, then all we need to do is feed different text possibilities into the validator logically. It may be possible to programmatically find the private key with several characters mistranscribed or missing:

- Starts with "5"? No? Add "5" if missing characters; substitute "5" if right length; add "5" and drop other characters if right length;
- Correct Length: substitute alternate upper/lower case for one character, check all positions for one character wrong, then iterate for increasing numbers of multiple incorrect cases, incorrect letters, etc;
- Missing one character? Try adding all Base58 characters at all positions.

Missing two characters? It becomes a slightly harder problem. Adding two characters in all possible positions = 3,956,064 possibilities (if the 5 at the start is correct). Single-threaded python does about 300,000 SHA256 hashes a second on my PC, so probably less than a minute to try all.

This might be an interesting programming project, but I wouldn't bother until it's actually going to recover some Bitcoins.

There are many script instructions that are simply math or stack manipulation that were written for versatility or future use. To eliminate potential bugs and undefined states, some non-money transfer instructions as originally implemented by Satoshi have been disabled. Transactions including them would be invalid, and modified or non-Satoshi clients including them in a block would result in an invalid "fork" block, ignored by the rest of the network.

You can see which instructions are disabled: https://en.bitcoin.it/wiki/Script#Splice

It is very probable that there are nearly 2 ** 160 bitcoin addresses, but it cannot be proved if all exist.

For a bit of background, lets examine a hash function. An ideal crypto hash algorithm would act as a random oracle, where every possible input generates an output that while discrete, is completely random. Random numbers, as in not necessarily unique.

For this example, we'll make it a (meaningless) 1 bit hash function. A coin toss. One random oracle hash function might have heads=1, tails=0. Another random oracle might result in heads=1, tails=1. Since the output values of the hash function are completely random, a case where two inputs have the same output value is a valid hash function.

In this simplest case, the chance that for any hash function the second output is a duplicate of a first one is 50% - a 50% chance that although the number of inputs is 2, the number of possible outputs is one.

This idea can be scaled up. For Bitcoin's RIPEMD-160, if we look at every possible 160-bit input (from 0 to 2^160-1), there will be many duplicate hash outputs if the algorithm is truly "random". A mapping of 1:1 input to output would be a non-oracle hash and breaks many crypto assumptions. Such expected hash collisions have been proven on other crypto hashes. For every duplicate, there must be by necessity one non-existing output value. There are not 160 bits of output for 160 bits of input.

The funny thing is that we aren't putting just 160 bits into RipeMD-160, the message we are hashing is the 256-bit output of SHA256.

For this case where the message is larger than the output, lets go back to our 1-bit hash. Lets say that our input message two bits; possible inputs are 00,01,10,11. All we have to do is look at all possible inputs, and then see if all possible outputs, both 0 and 1, were generated. A "1" output never being generated is still a possibility.

For our 2-bit message, it is easy to check whether we get all possible outputs. However when the number of possible outputs is way higher than the number of atoms in the universe, it is a bit harder.

It is very probable that even with a 256-bit input message that there are many ungeneratable Bitcoin addresses, from sheer probability, or further, from underlying hash algorithm biases or the mandatory non-oracle behavior in RIPEMD forced by using real-word algorithms.

Bitcoin without the internet, while still somewhat functional even via sneakernet, becomes dangerous to use.

If mining nodes are isolated, they each can start developing an independent blockchain. In this scenario, the fastest miner wins and has 100% control of the blockchain with less than 50% of the hashrate. When the network is reunited, and the fastest miner communicates their longest chain, it immediately wipes any blocks that anyone else had created.

The OP's question is wrong. It should be "how to I securely erase a text file that I put on my computer's hard drive, a file holding plaintext information that should have only been stored encrypted?"

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.

There is nothing to infer about the sender by examining a normal bitcoin address - they are randomly generated, and the hashing algorithm used in creating the human-readable address further obscures any meaning.

Vanity addresses are one exception - while still randomly generated, we pick one we like after generating billions. An address that starts with 1dceleron might be mine.

If you wish to learn more about wallets and senders and receivers, you can however "follow the money", by seeing how an address was funded, and to where it spent its money. This can be done on block explorer sites, but you quickly see coins mixing with other coins from other senders rendering the exercise pointless. This is why it is good to only use addresses once, so there is even less for someone to learn about the sender.

Inferring your experience level, unless you want hackers to empty out your wallet, it would be much better for you to employ a third-party checkout/shopping cart vendor.

A hash is a computer science term, more specifically you'd be employing a cryptographically strong hashing algorithm like SHA256.

Hashing algorithms such as SHA256 create a digital fingerprint of data that cannot be easily falsified, as their output is unpredictable and irreversible by design. It is almost impossible using state of the art hashing algorithms to make two different sets of data ("messages") that have the same signature (or "hash"). You also cannot "reverse" a hash back to the message unless the message is extremely simple, like a too-short password.

Therefore if I give you the sha256 hash today 2e4710beb876bc87d8c471e263f396e3431ff6f193b45bd788a006d7bfab42f8 and say "guess my number", tomorrow when I tell you that the message I signed is Guess my number game: the number for March 22 is 42. then you can go to a site like http://www.xorbin.com/tools/sha256-hash-calculator and see that I was playing fair.