They didn't, but but now they do again, because new members unrestricted tend to do unsocial things like post signature ads to bump four-year old threads.

Not as a GUI feature, but the building blocks are there:

Or take a clue from Edward Snowden - either paranoid enough or informed enough to only enter his decryption passwords when covered with a blanket.

Keep even your use of Bitcoin secret from anyone who you do not completely trust. They tell their friends, their friends tell their methhead cousin...

Isn't it great that the monetary amount you transfer doesn't affect the data or processing cost to network members, or cost of disk space that nodes must allocate to store your transaction forever?

Well, anyway, the commentary should be that if it was important to have processed quickly, then paying a larger-than-default fee would have been a much smaller percentage of this non-trivial amount.


My amendments below to the first post's points still stand valid - don't experiment with paying the lowest fees possible for important transactions:


The Bitcoin white paper doesn't say anything about free or cheap transactions, this came from Bitcoin promoters while it was still true. In fact, reasonable and balanced fees are necessary to discourage trivial transactions and to replace the shrinking block rewards paid to miners. The economics of this are competitive and self-correcting - as more transactions pile up, more fees are needed for timely confirmation. What hasn't happened in the last five years is exponentially cheaper hard drives or processors that could have kept Bitcoin data growth less expensive.

Coinbase appears to be available as a data source from bitcoincharts in several different local currencies. You can view the history files directory here to look at the available ticker names (SYMBOLS) that you would use as a command line option -sSYMBOLS when starting scfeed.

Example usage: scfeed.exe -scoinbaseUSD,coinbaseEUR,btcexUSD

Disable signatures and activity numbers on posts, to reduce the incentive for mindless garbage filling up neverending threads and driving long-term members away from the once-useful forum.

My signature site has what I feel is just the right amount of information to get started in understanding Bitcoin.

There are Bitcoin topics that can go far beyond most people's understanding or desire to learn, such as when we start talking about Merkle trees, digital signature algorithms, hexadecimal math, or subjects that require college-level statistics.

If you have a particular topic you would like to investigate further, you can start at https://en.bitcoin.it/wiki/Category:Technical

BIP0038 is made very computationally difficult to encrypt/decrypt. It was specifically designed to be resistant to hardware-accelerated brute force attacks. That will not be a fruitful attack method unless you simply need to figure out which of 20 passwords was used.

Were you able to decrypt the wallets previously? Were the specific passwords trialed before use?

You might try time-traveling - get a old version of the github bitaddress code from the date of creation to replicate any code flaws and load it back up on the original distro and platform used to make the addresses.

That's BS. It has only ruined this forum by encouraging junk posting and keeping year-long pointless threads alive with banal content.

The solution is just to turn off forum signatures completely. They add nothing.

I created a thread with discussion of why disabling signatures is the only solution, and of course after a few pages and months even that thread was just signature spammers rehashing junk posts at each other.

By inaction, Theymos has made this forum not worth the time.

Well, you answered the OP's first question as "yes" (as long as that user is Satoshi). Not news to me, but informative to others:

OP hasn't really revealed a topic of curiosity though, unless you want to send someone unsolicited op_checksig payments.

It sounds like the private key may need more massaging to recover, whether programmatically, or by analysis of what was written down. I would start by analyzing how you transcribed the private key to paper, and think for yourself where you were and how it might have been written in error. Did you lose your place when writing it down, are there any letters close to each other that repeat? Did you make a mistake in lower/upper case when transcribing. Picture yourself with pen and paper in one hand and screen, you will be your own best resource for figuring out how it might have gone wrong.

Programming a solution to "brute force" what was written down now needs to be informed about further possible ways that mistakes were made.

When I see a thread like this, the first question - what is the OP hoping to achieve? Sometimes the question asked is not the real question.

A "Bitcoin User" doesn't have a public key, a Bitcoin address has a public key. The public key is only published when a transaction spends funds previously sent to that exact address.

Only after an address has spent money can the public key be recovered from a transaction stored in the blockchain. By recommendation, addresses are often never reused. Nothing about the address or its public key informs you about other addresses the user may have or use.

Start here: http://we.lovebitco.in/how-bitcoin-works/bitcoin-addresses/ and read the following page also.

Bitcoin addresses traditionally are randomly generated, but they can also be generated by a random seed fed into a pseudorandom algorithm. This makes a deterministic wallet, so that all addresses that will ever be in a wallet can be recreated by a backup of just the seed.

The only way someone will know a Bitcoin address of yours is if you give it to them. Many orgs use a single donation address, with the benefit/detriment being that others can see how much has been donated.

The safest way to offer a new address for each contribution is to pre-generate them offline, and have web site software simply give a new one to each donator from a list of addresses. Putting full wallet software online for a web backend requires incredible security precautions.

Bitcoin address balances are in the form of previous unspent transaction output (UXTO) payments they have received. A standard Bitcoin UXTO that would be in a wallet is a "pay to pubkey-hash", where money is sent to the RIPEMD160(SHA256()) hash of the public key (this pubKeyHash is the same thing as a Bitcoin address, without the Base58 encoding making it pretty). The output script in this UXTO defines the procedures that must be met to spend the money.

A pay to pubkey-hash output script has instructions that basically say: if you can provide a pubkey, and the hash of that pubkey is the Bitcoin address included in the script, then you can spend the bitcoins with a message signed by the keypair.

The output script doesn't care that you use a particular pubkey out of the many that might exist that create the same pubkey-hash, only that the hash (address) matches. The spender is the one that is sending the pubkey to the network, saying in effect with their transaction "this is bitcoins I am allowed to spend - here I'm signing a message with the instructions to spend it, and since you don't have the pubkey yet to cryptographically verify my signature, I'm providing the one I used to sign the message".

Of course the signature has to be valid and the pubkey has to match the bitcoin address, but that is assumed.

The original generation of 50 BTCs from mining was a pay-to-pubkey script. To spend those, you had to have the correct key.

If a URL contains brackets, then the webmaster is a dummy.

When I send you money, I am only sending it to a Bitcoin address; I don't know your public key. Any public key that hashes to that Bitcoin address can spend the money.

Of course, even if there were 21 trillion addresses each having one satoshi in them (more than the maximum number of bitcoins that will ever exist), the odds are impossible-1 that you will ever be able to spend money for a Bitcoin address and key you didn't generate yourself.

Base58 conversion always preserves leading 0 bytes by directly encoding them as a "1" at the start of an address. This is the reason all standard Bitcoin addresses start with 1, because of the hard-coded network ID byte of 00 for Bitcoin.

A byte can store a value 0-255; the chance that the next byte (the first digit of the hash) is also 0x00h is 1 in 256, and so on.

The Bitcoin address in it's native binary form (that you never see) is 25 bytes, it's parts are:
byte 0: Network ID Byte (0x00 for main bitcoin network)
byte 1-20: ripemd160 hash (20 bytes) of sha256 hash (32 bytes) of 0x04+public key (65 bytes)
byte 21-24: checksum: first four bytes of sha256 hash of sha256 hash of bytes 0-20 above

Only after the leading byte preservation is the address then put through Base58-encoding.

The other non-related "answers" seen in this thread are also wrong: because the largest Bitcoin address (all FFFFs for the hash plus checksum) is 1QLbz7JHiBTspS962RLKV8GndWFwi5j6Qr, there are strange address probabilities. The chance of an address starting with characters 12 - 1P is about 1-in-23; an address starting 1R-1z must be a 33 character or less address, and chances are 1-in-1353. As we now know, starting in 11 is 1-in-256.

A valid private key is not 2**256, it is between 1 and FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141, which is the order n of G on the Koblitz curve secp256k1 used in Bitcoin.
The chance of a random 2**256 number not being on the curve is 1 in 267776665566007192515705986938822075895 or so, so pretty much the same thing as 2²⁵⁶ for casual discussion.

As you surmised, any given Bitcoin address is expected to have about 2⁹⁶ possible public/private keys.

There are probably 2¹⁶⁰ Bitcoin addresses, but there is no proof that they all exist, and statistics about the chances they all exist aren't informed about how oracle-like ripemd160 might be when it is streamed 160+96 bits.

The last page and a half is just signature spammers saying the same shit over and over again. Seriously, fuck you.

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