That's a good attempt but I'd say if we are to design a symbol for the smallest unit of bitcoin called satoshi we should utilize the letter "s" in it not "b" similar to ¢ which is the symbol for cent and uses the letter "c".

Lower case "b" symbol could be used for other units of bitcoin like bits which is 100 satoshi.

Technically they shouldn't show you anything because public key is not a P2PK (nor is it P2PKH or any other address type). When we say P2PK we are talking about a specific script that contains the public key (pushdata + OP_CheckSig).

That's how you get weak hands into bitcoin and increase the already high volatility in the market where they panic buy and panic sell because they have no understanding of what bitcoin is!

I wouldn't say they don't care, instead they probably see the risk as being small enough to neglect, which is not wrong either the risk is not the biggest. But if that chances and they feel the threat as being big enough that can damage their "investment" they do care and specially the big ones because they have more at stake. If you think about it, a successful attack on bitcoin will harm those who have more money invested in bitcoin and bitcoin mining.

In fact we saw how much miners care when they feel the risk rising about 7 years ago when ghash.io grew too big that they controlled more than 50% of the hashrate. Miners did make the effort and started switching pool and left their service to reduce the risk.

You could technically create a customized word list containing an arbitrary number of words and then use the Electrum mnemonic algorithm to create your seed phrase using that particular word list. It should have the same security level since Electrum still creates a random entropy and encodes that using the custom word list.
Keep in mind that if your list is small (like 10 words), your mnemonic length would be massive since each word encodes a much smaller number of bits.
Also remember that you should also store the list alongside the mnemonic otherwise you won't be able to recover your keys.

FWIW mnemonic algorithm, despite what the name may sound like, is not created for memorization. Its main purpose is for you to be able to write it down (with pen and paper) with a very low chance of mistakes.

Keep this educational and don't create any serious addresses using this. Most importantly is that you won't find bugs by just testing it a couple of times with random cases, there are a lot of edge cases that you may not know of and may not face in your "random tests" but can encounter in a real scenario.
Off the top of my head since you mentioned Java and are probably using the BigInteger class,is that you may forget the necessary padding for the public key and use a smaller than 32 byte x/y coordinate in the pubkey for your hash and end up with coins that can never be spent.

The best real life example I can think of that is similar to what I explained here is the bitcore-lib by Bitpay written in Javascript that had a similar bug with lack of padding. https://github.com/bitpay/bitcore-lib/issues/47

I would also say that generating a serious key (to send actual funds to) using your own code is not a good idea even if you verify the correctness of the key->address using a secondary tool. Because there can be other vulnerabilities in your code like your RNG being weak.

That's right but also "automatic payment" may mean fixed and predefined payments for example a fixed amount of bitcoin sent to a fixed address(es). In that case the transactions could be created by utilizing the transaction locktime and setting it to the date and time of the payment while each tx is in a chain meaning they each spend the output of the previous one.
This way each tx can not be broadcasted or mined before its time and the online system does not need to hold the key anymore.

No offense but if you have to ask something this basic, you can't call yourself a "developer" and you definitely should not attempt at creating something security critical unless you are just playing around in which case just visit github and search for a library written in PHP that supports BIP32.
Something like this search: https://github.com/search?q=bip32+language%3APHP&type=repositories&l=PHP
Then either use one of the ready to use tools or get the code from there to write a tool around that. But as I said if you don't know what you are doing, the result will not be secure.

To be clear the option to pay to address (ie. P2PKH scripts and addresses) was not something to be added later. They were available from the first release that is version 0.1.0. The only reason why P2PK is seen in all early blocks is that the P2PK outputs were the default output type that the bitcoin core miner chose.

Start by looking at the existing projects on github that are already doing this (recovering WIF with missing characters). You'll get a good idea.

As for what I meant, I'll give you an example.
Instead of using the line I mentioned above (key = Key(wif=test_wif)) you'd use these 4 lines and under the if branch instead of throwing an exception you'd just skip when the checksum is invalid. And in the else branch (you add) you perform the conversion to address and the rest of the checks.

When you want to write a recovery code (ie. a computation heavy code needing to be heavily optimized) you shouldn't go through the simple route writing a "normal" code like what you'd write for a normal function that encodes/decodes Base58 keys. Instead you should find the bottlenecks in your code and try to go around them by finding alternative computation route that perform faster.

I'm not a python expert but for example in your code when you are replacing * with random chars and then convert it to a key in this line:
you are adding a big bottleneck that slows your code specially since you are throwing and catching an exception which adds additional computational cost.
Changing that code and doing the conversion from base58 in your own code would significantly improve your speed. Of course when optimizing you must always perform benchmarks on your code and the changes you make so that you don't make it slower. And you should add tests so that you don't introduce bugs.

That's not sarcasm, that's the effects of being severely brainwashed. One of the side effects of it is seeing the world in complete black or white with nothing in between.
This is why over a year ago when Russia was cut from SWIFT these people claimed it is the "end of Russia", they even set a deadline of a couple of weeks and stuff like that. And whenever other people disagreed with their extreme views they could only interpret them as meaning the other end of the spectrum (as in "everything is fine without a single problem") because as I said they have lost the ability to think or see anything between totally black and totally white.

I wouldn't say the country that sells the weapons but instead the company that sells them. Take a look at US for example. As the biggest weapons seller in this war the arms manufacturers and the arms dealers are making tons of money but US itself is experiencing inflation and recession at the same time with the national debt growing by the trillions every couple of months as the government can not keep up with its massive expenses while the banks keep shutting down one at a time and people who can no longer pay their debt due to high interest rates and the inflation that eats through their income.

Your definition of speed is wrong because you probably don't really understand what confirmation means and what its relationship with reversibility is.

A confirmation is when a transaction is included in a block. From that point as newer blocks are found, the confirmed transaction goes deeper into the chain or gets more confirmation.
What matters here is to find a number of confirmation where the chances of the confirmed transaction being reversed by performing an attack on the chain (eg. 51% attack on PoW chains and other forms on PoS) is nearly zero.
Depending on the algorithm, the hashrate, level of decentralization, security of the protocol itself (in simple terms being bug free), and the network state this number can be different.

For example for a centralized shitcoin with a weak protocol where mining is performed by centralized powers this number can be in the thousands. In fact if you look at the deposit page of most exchanges, they require very high number of confirmation for a lot of altcoins for this reason, although not all of their values are accurate or safe but it is a good practical example.
But for a decentralized cryptocurrency like bitcoin with a solid protocol and a well spread miners and a very big hashrate this number is the lowest.

In other words, as others also pointed out, for a centralized shitcoin like ETH having only one confirmation (even with the new flawed PoS algorithm) doesn't provide nearly enough security as one bitcoin confirmation provides.

The global economy is still not stable enough to predict things and this month (August) we are going to have a major event with the BRICS currency possibly being revealed which could be another huge step in the dollar dumping process.

For bitcoin this is both good news and bad news in my opinion.
It is a bad news because in short term it could cause more recession ergo put additional sell pressure on the market that prevents the further rises for the time being.
But it is also good news since it continues pushing the dollar value down and as US prints more dollars to cover the enormous budget deficit  and the additional costs in the trillions, that dump helps shoot up the bitcoin price.

Generally speaking ETF is in my opinion an over-hyped thing which doesn't have nearly as much an impact as some people have been saying it should have over the past 5-6 years. Specially since there have been a bunch of different ETFs in different countries around the globe without much impact.

Besides I'd go as far as saying ETF by definition is the exact opposite of what Bitcoin is made for. When you want to buy bitcoin, you should buy bitcoin directly instead of buying the garbage some investment company sells to you in the name of bitcoin as a middle man. After all Bitcoin was created to eliminate the middle man not add more of them.

That does not matter for address generation because your x value does not change when negating a public key meaning P(x,y) = -P(x,y) = P(x,-y) and we only use the x coordinate in the address.
Even y coordinate is something you should check and take some extra steps when signing and verifying ECSDSA signatures.

Two questions come to mind here. First is whether companies hiring "blockchain experts" require such certificates or care if you have one or not. Second is whether these hiring companies even recognize the issuer of such certificates!

I haven't really looked for the jobs in this industry but from what I've seen from startups and other small businesses in this field, the experts themselves create these small companies and then they hire regular programmers, etc. to help build the business.
Not to mention that when anybody hires employees, they look for experience not certificates. For example when they hire a programmer, they don't ask them who taught them c++. Instead they ask them how many lines of c++ they have written and what programs they've created, and stuff like that.

The same problems apply here.
We can't decide what people should do in a hundred years from now when we aren't even around.
You also significantly decreased the incentive and also re-introduced a decreasing reward since the amount of coins "lost" or amount that hasn't moved in a long time is decreasing per year as price goes up and more people get in. That means after a couple of "periods" we could theoretically end up with a fraction of bitcoin as the total amount "lost", which is like halving all over again.

At some point as you keep increasing the complexity of this idea, it raises the question of why not just increase the supply in the year 2140?

Hash is computed from the data (not exactly assigned to it) and one of the usage of computing a hash is ensuring integrity of the data which means not a single bit inside the data can change without the resulting hash also changing. In other words even if the bit length remains the same but the bits change, the hash changes too.

A block header hash must be smaller than or equal to a globally enforced target (hash <= target).


Mining is similar to a competition where each miner tries to find the hash faster than others, so they need the most efficient hardware to perform the most number of computations in the shortest time possible.
Otherwise the hash itself (and the whole process of mining) can be performed on any device, even the least efficient or ancient computer you can find that performs something like 1 hash per hour using one of those computers that were as big as a room!