Also, why is their only one unique address for the first and second day, and zero for the third through sixth?
Didn't Satoshi use a bunch of different addresses?

Yes, extended Merkle-Lamport signatures (can be made reusable at the cost of increased length), they are based on hash functions, but are too large and unwieldy for practical use.

[citation needed]
Please provide the website url.

If uo keep them on your wallet, and the chain splits, x coins would result in x coins in one chain and x coins in the other.
If you keep them at a "bitcoin bank", the bank may refuse to give you the coins on one of the chains, something like this happened when ethereum split (some "wallets" refused to give users their ETC).
Keep them on a paper wallet, and then, if you think it is wise, trade them after the dust settles.

This happened to me a few times also, I learned my lesson and now know not to reply to spam threads, and not to change the topic in the middle of a thread.
Don't worry about it, and take care to write better posts in the future, no-one cares about a few stupid posts (if 90% of your posts are stupid, on the other hand...).

Using a brain wallet means memorizing a passphrase and using it to derive keys and addresses, with no hard copy. This can be done securely, but it is very easy to choose an insecure passphrase and lose your bitcoin to hackers. Also, a long passphrase is hard to remember, band the coins are lost forever if you forget the passphrase. Finally, if you happen to die while using a bran wallet, the bitcoins die with you (paper wallets and other backups can be found and opened by family).
For those reasons, brain wallets are not recommended for regular storage.
Niche applications include holding on to coins in places they may be stolen or confiscated (prison, oppressive regimes (think 1984), very invasive border patrols, etcetera). If you use a brain wallet for this, be sure never to reveal its existence (better yet, avoid mentioning cryptocurrency at all), as you may be tortured and forced to reveal the pass-phrase.

This post is off topic in this thread, and your explanation is not nearly detailed enough for anyone to help you.
Please create a new thread for your question, and explain in more detail what the problem is.

This is probably just a "souvenir" containing no bitcoin.

Neither of those services are bitcoin wallets, they are equivalent to banks, and thy contro the private keys.
A wallet is a program like Bitcoin Core, Electrum or Mycelium, that generated key-pairs and uses them to keep bitcoins.
To store bitcoins, I would suggest using Electrum or Mycelium in combination with paper wallets in the following manner:
Use the paper wallets to receive coins, until the wallet hits a certain amount (50 or 100 mBTC), than switch to a new paper wallet to receive coins.
To spend coins, use your desktop or mobile wallet, and sweep a paper wallet when funds are insufficient.
This way, you never have most of your coins on the hot wallet.
I have posted instructions for paper wallet generations:
https://bitcointalk.org/index.php?topic=1559277.msg17075677#msg17075677

In your post, you mention linking your wallet to your credit card, I can't tell you much there due to my lack of knowledge, but it sounds like giving up control of the private keys.
If you don't have sole and complete control over the private keys, you don't have any bitcoin!

If you want to buy bitcoins, make and account at an exchange, buy them, and immediately move them to paper wallets.
If you can't make an account at an exchange, you can buy coins from a street seller.

If you want help creating an account at an exchange, I can't help you with that.

This seems to imply you are holding your bounties in bitcoin.
Since this is targeted at the bitcoin community, I assume you are also paying them in bitcoin.
Why, then, do you advertise the bounty amounts in dollars instead of in bitcoins?

It is relatively easy to set up a cluster thousands of times faster than a phone, this would crack the key about as fast as the phone can decrypt it.
I covered this in my previous post.
Most smartphones do not have a secure cryptoprocessor on board, a hacker can take the phone apart, remove the memory storage, and extract the encrypted keys.
After this, the hacker would not have any trouble cracking your key-stretching scheme.
This may require some effort, but it it well worth the stash of bitcoin.

A rough estimate is in the post, highly negotiable.
Sadly, very true.

I feel like there is one particular precaution that could be added, avoid this very common scenario:
A newbie has a paper wallet, with some amount of bitcoin on it.
The newbie wants to spend some of them, downloads and installs a desktop or mobile wallet.
The newbie broadcasts a transaction sending part of the coins, the rest are sent to a new address generated by the desktop or mobile wallet.
Believing the leftover coins are still on the paper wallet, the newbie deletes the wallet.
The leftover coins are gone forever.
This is a sad loss that could be prevented by proper education.

Some people want addresses that say something, like 1BitmixerEiyyp3eTLaCpgBbhYERs48qza for example, instead of random looking addresses like 1JGYXhfhPrkiHcpYkiuCoKpdycPhGCuswa.
Unfortunately, you can't simply type in any 160 bit string and call it your address, because to be able to spend the coins, you need the discrete logarithm of the hash preimage of the address (the address is the hash of the public key, which is the discrete exponential of the private key), and neither of the operation can be inverted (if they could be inverted, it would be trivial to steal coins).
Therefore, the only method to produce a pretty address is by choosing arbitrary private keys, and calculating their addresses, until one is found that has the correct word.
For example, say I want an address starting with "1A" (A for ArcCsch), and start generating private keys and finding their addresses, the results would probably look somewhat like this (Private keys on the right, their addresses on the left):

1,"176HX3TpU6nmVRE5YwapgJKVsQ52CU734N","L29SpQvnXVzcvpwvSaXjSWMoMbSUr53FEpfbaXBDEoUtSFU23asA"
2,"1HtcBMUk4sR3dEbdcNDehSx5KWCmA7P1sP","KzpQ5xAnAomAibgT1b7y1d6E6MrgQvjCxnVSqf3amZWyiWjPASEo"
3,"1MQ77bkGTNbpA8jAGb9zqLcGVw3GjbgJH4","Kwe8aGELMp9U3PN4wgNMh7vze5FDt8YBjxoBREQbsiZEpHqBut7f"
4,"1FzSRKMXCmnbe9pi3GRhxh8yTi49iasYS6","KyymhJTLFRMmnZaERNYU9XsQ2An8kTJNPJvRMe9Vm3SPc42hCw3N"
5,"1Mg3b4am6x7wKvENFNTXgonr8MPn4eLaZo","L3d45874hZDUo1guPcEoCz56iKMZyKQkF3NXE7Kdi8weHQAqt2vD"
6,"1C2EtarJYFRWgXEXxuNWefQRX9JZL944cv","L4zC1LJgSmCFisJ4uakjncTPrhj7XdkM8UgaEcCC6gxuB7BjrD64"
7,"1P2cD6vxK68T5Wn6qLZZ5kK31eSF9fuU3d","L48ZBBxraruWEUsFqVYjFMR7UvdequJ9VsKvP5yc6Q3jqEmNZfxx"
8,"1K3JNRX6ENBxEy4XJmv4rMgoc3k8rE7GwL","L2RtVkX1TZFWuEbUetcoUaim4PQbuSFAeRMxX1NpfuZ8tgerHAEJ"
9,"1EuQmM4Cigych2bHBk493fHahkpbKJfyq","KxTwUAnpBPoq1exCM3GVN6V8bKbpkevTddC76peBUTH6rVh7vdtK"
10,"1HRANKHXPpR4gnmAeTr7tfzh477syR3biv","KznrNnfc6wfYwGkYbLfCMP2ZEV5wzoWTE4CgMRkuboCL2mtuXUKk"
11,"1DukfCTpmGduVhJumeusj2Zxd342jGhA4","L1iNPa1MWSX1FoKfXbv6KcMesVJbMVU9BTkjJqDc7UsZHigBGBsN"
12,"1FpvHnrthF7zDfZoh5YaczrKXyGXzmtpcC","KwDpcAfp16Kf7DdNzYzwh8habpRXc7AX6NQQPQoMmqfzdAEcoZTX"
13,"1Lxm7tXvrGb2nd8oSqAJWvXnCXKhFe2GVr","KzzifnmUMoNFdw9UasKV1bh83m5yAEYuvpwDexxaWb2xWBJC5pz3"
14,"14tpXY96XHze989SPuPDQhz9oU4KDyWUR5","KyDgPQU2eAtn3YiyfGhRnSC4Q7FH2C89exajf1QiRywYXdHJ4CHG"
15,"17bxWpdoYKkrmkF4yhjy96ndJqzRcxwLJr","L1tKsxYPNnL4nwmmufzFFxWXhCKxGchDg8fk126NkTtg9q5gLgjp"
16,"16Gpi5zFKNDiV53n5G7Pd9rkSmKkLjcJJw","L4gXfZrFG4BPb2T9V8nybNHidMbJqxFrvNB1GEDwpQnr6hVvwoV2"
17,"1Jkao7hjHWLSWfLCzeynA8CS3KZLoZH1qC","L2PV2HgziqRJThdrsoztvUnf1NxtuXkB8LFYjCfnynsxyUAPxgR9"
18,"13Amda7V3yAV3MU6ke4zwhoTVTaNMpnm3h","KyPPuuNxKDuxcoXxiaGq1RN3akCyTWjraLdvPwkVbdtDVvTFfKov"
19,"1Kvbnr9ZkuEJWiGnPvUwVY94cAEvHyNnp4","KxmfMBvWH7P32bFGTbqTUYFdNbGbnA5DzzEEaWnzSrpa9NfwtkPN"
20,"1K3KVcThaN6aRsBGxjg9VvM4azHPdqC2uT","L2d2Z2B6AFGEDqaYc9qLiCLscEuhFqYQqp4Zk3WVv3usoPdoRpV9"
21,"17uJFvLNNnx8Uh7BhDkKBtGcniQnBfgT8d","KzdP3x1QiB4UrnSoT7c3mp9d2PQuZqwEDCcXp2QSgFrVCWzcSVDd"
22,"1GhDezoCpV974tHMrDGSnEZZBL23azRBoP","KyCS2Ezs6FQkinrWGWyKNKvGDEamriV7WCUtfvhEdL8L5iqmi88v"
23,"1PmYBits4tM3aBnMgKYva1LaznxEW966jP","L1vMEc3kuKDaDaBbM8KMBTGYciATK1FvSd3DquHeGAXMCigkNSge"
24,"19uYNzpq8exwKuXVrNCPDv5edCZFtP9JbU","L1NNobwtpbsTty3wh4mhY3jwN6hFhe7QgGEt5yBj4yTJinxUEDqy"
25,"1HyM8jFnom5WaMD86gtnTNGRbSxpeyR5LC","L1qR89LAevCQPXjdiJ8V8zcbkQnqx8eNeT4gT9hRjgRaFqfF1gjW"
26,"1HGxM5bBggLNBKiDoGVkmQpU1GsLUUJn9Z","L4csYwhFydcHNhbBsM8eModmBCvC3G7rhZVDoVaN9AexjMe2gYik"
27,"1MQ6SSpes8JDqcVGiN2d1d3RPotHCtCs3i","KyZjDTAYDCXa14NAXxV4GVqJ5ppBXTviqqpUHFaFS5noc1Jt9f1q"
28,"1NqqPT3KY53y9PkC5VReHvfPLBBGw2xPu7","L1ySBTcEEnQxmPRiw2qS74rTUF3FYQtJejju4Uc5nwngZUzpCyoP"
29,"1542DyiaZ9835DRgnEizNLtRgYPXZjQ5oH","L2VHsqccStbMWGsjBKSuHXW7HsgRYAVhVZhJh5UNacvmiaqxtBzz"
30,"1GBSnRHds1CvFQWgr45DG5cVvC6SjjU5EB","L167yAuiRVXEcjTXXq2wpZbGhr61hZvx6oBLAbfTGrWb3iLr9x5G"
31,"1Bf4n1dALB6RCampCPir4gxU4UJubdXh1W","KzMXD1EU3TTDH2AViXj9VeoLXVYto8npbHjkJ6MwMG2RzBt6tRMa"
32,"1FkiKGj7pUyjeG5h8LNY9pfn1DN7W6KW7Y","KytsiftWBYxjMGEDnZC1yEHMp3gSPUVDeiPmeNcgh4h5ewoHbnx9"
33,"1GthMoYqHB3rVi474U4W72Mf7LB76Byvb7","Kxy1KXLjdf7QDYrbgJsiUnUWA5v82syKjvqYKPGjazJyZEFcJGit"
34,"12mvzgNDsewFrpMRPNWkB2S59Hy55SkM2Q","L3ZdDWDLybwMhC33Mys1Px3V61qxmHrcfDmkA6Qz7w2rHPtbJabE"
35,"13vdReZ4TmNg6NBQQxzCdCHmfKZ67eTQqp","L1MKgWEXtS15qqyi3u8WqepT2ZDDHR1SNcQw9T7dgU8S5dJUMgSW"
36,"12bgbnRqbvd1SfJyvYmVoJGNumb5Lne6CJ","L3MaGMTjkghXGBUpi1RM8kyZynK3RoZdNiEHzY5MtVrjnuXq87RR"
37,"1ACdE9iqhGgGy7TvjKue73rTrPPcL1afap","KyxE8mpsASJfooD2YZZJPs1NuYrU3ULfoxpYzJHYTj8t1aBmJWri"

As you can see, on my 37th attempt, I generated an address that starts with "1A", now I have a pretty address (I can't use this particular one, of course, because I just published its private key).
In the same way, addresses like 1Bitmixer... can be generated by this procedure, requiring far more attempts (the expected number of attempts grows exponentially with the length of the desired pattern).
For this reason, longer patterns require considerable computational effort.
This is what LoyceV is giving away, customized addresses.
The whole key-part thing is a procedure to allow LoyceV to generate addresses, and others to use them, without exposing the full private key.
This exploits the commutativity properties of discrete exponentials, and allows the key-parts to be published on this thread without risk, because the other part of the key is retained by the user requesting the address.

This procedure is described under "instructions" in the first post, if you are interested, I can explain the technical details of this procedure.

This is what I meant with "k-collisions" in my previous post.

To sign a transaction or message, besides the message M and private key Pr, you also need a 256 bit parameter K, usually chosen at random.
If you sign two different messages M with the same key Pr and the same parameter K, a hacker can recover your private key.
Some bitcoin wallets were designed by incompetent amateurs who used a poor randomness source for K, and hackers quickly stole the coins.
If you have a reputable wallet, you don't have to worry about it.

Please send me the questions you are talking about, your description is not very descriptive.
By "stepwise", do you mean to include explanation on how to solve them (kind of like textbook example problems)?
This is unofficial and of questionable legality.
The "further your learning" part was simply to make it clear that having someone else do your homework would probably not help you in the long term, kind of the way gambling sites often make it clear that gambling is addicting and a waste of money. I don't want anyone blaming me for not learning anything and flunking the test.
True, I just wanted a disclaimer so people don't blame me for their laziness.

And as for the tutoring bit, I have considered it and...I don't think I would be able to organize that.

If you are receiving payments or donations on a regular basis, there is a simple way to deal with them.
Use one address at a time for receiving coins, and keep using it repeatedly until you need to spend the coins on it.
Once you do that, switch to a new address, and keep using it until you need the coins on it, etcetera.

This is not particularly good from the privacy perspective, but, unless you use a mix, your coins can probably be traced even if you use a new address for each transaction received.
In this case, using a new address for each payment would only result in more transaction fees, and not yield any advantages.
Also, this does not expose the public keys any longer than absolutely necessary, which gives less time for theoretical (currently implausible) attacks on ECDSA, and since each address is used only once, you don't need to worry about the k-collision problem.

First, how long is this PIN?
If it is four digits, and the phone is hacked (encrypted key leaked), that would be broken pretty quickly, even with key stretching.
For example, if decrypting takes one minute on your phone, cracking would on average take a bit over eight hours on an identical phone, a powerful GPU could probably crack it in a few minutes.
You could fix that by replacing the PIN with a pass-phrase, until it becomes essentially a salted brain-wallet.
Also, if this is a bitcoin wallet, why does the article say "send 2 dollars to joe", instead of "send two millies to Joe"?

I see where the confusion stems from, size as in number of bits (think document or check with long paragraphs of text vs. just a few sentences) vs. size as in value (think check for $500 vs. check for $100, same amount of text but different value).
To avoid confusion, I will use "size" only for the amount of data in the transaction, and "value" for the amount of bitcoin.

The miners prioritize transactions based on the "fee rate", which is the value of the fee (the tip given to miners) divided by the size of the transaction. Fee rate is usually expressed in satoshis (10^-8 bitcoin) per byte (8 binary digits), this is kind of like paying for a telegram in cents (value) per word (size).
How fast your transaction gets confirmed depends on the fee you give and on the size, not on the value.
Size is determined by number of inputs and outputs (if you see more text on blockchain.info, that transaction has a larger size), and your transaction had a smaller size than the others.

In the second quote, by "small transaction" I meant size, not value.

I hope this clears up the confusion.

Note that those two transactions are bigger than yours (each has two outputs), and both have a smaller fee.
Miners fit transactions into blocks, and each block can only hold a limited amount of data.
To get as much total fees as possible, miners prioritize transactions by fee per bite (98.401 sat/B for yours, 62.016 sat/B and 57.16 sat/B for the other two), so your transaction is naturally confirmed much quicker.