Good question.

So the transactions involving millisats aren't broadcast to the main chain. They remain entirely within the Lightning network. Whenever a Lightning channel which has a balance involving millisats is closed, then the transaction which is broadcast to the main chain is rounded down to the nearest whole satoshi.

Think of it like this. You and I each put ten $1 bills in a jar. There are now twenty $1 bills in that jar. You sell me some goods for $5, and so we agree that when we open the jar again, you'll get fifteen of those bills, and I'll get five. All good so far. Then I sell you some goods for $2.50. So now the balance is $12.50 for you, and $7.50 for me. If we open the jar now, then we can't get the exact amounts we are owed, because there are only $1 bills in the jar and no quarters, dimes, etc., so we can't receive 50 cents each. But no matter, we aren't opening the jar yet, so it doesn't matter for now. We can agree that this is what we are each owed, without actually opening the jar. So we do another trade for $2.80, and now the split is $15.30 and $4.70. And another trade, and another, and another. All the time we agree to split the original $20 in different ways, some of which won't actually be possible because we don't have the coins needed to split up a dollar in to smaller parts. When we finally come to open the jar, let's say (for example) the split is $15.30 and $4.70, as above. You would get $15, and I would get $4, with $1 left over in the jar.

The same thing happens with Lightning channels. You open the channel using a whole number of sats, but then can trade in millisats. As long as your channel stays open (i.e. we don't open the jar), you can trade back and forth in millisats as long as you like. When you want to close the channel (i.e. open the jar), then the transaction broadcast to the main chain will only use sats, and so the balance of both parties will be rounded down to the nearest whole satoshi, with the extra satoshi (the $1 left over in the example above) added to the fee of the closing transaction.

In its current form it would only be part of the solution. There are still other stumbling blocks which would need addressed first.

For example, let's say that a satoshi is worth $1 or more. Are people going to be happy spending hundreds of dollars worth of bitcoin just to open a channel? Or do we need something like channel factories to make it possible to open a channel for a fraction of that cost? More importantly, what about if you have an amount on your channel which is currently considered on-chain dust, but which could be worth hundreds of dollars? Most people won't be happy chalking that up as a loss.

Although it is worth repeating that for a satoshi to be worth $1, then the marketcap of bitcoin would be $2.1 quadrillion, which is more than an order of magnitude more than the global monetary supply. It is a crazy hypothetical.

This is simply not correct.

At the protocol level, everything is measured in satoshis. There are no decimal points; only satoshis. You cannot move a decimal point in the protocol because there is not one to move. Coins are defined as 100,000,000 sats. Amounts, outputs, block rewards, fees, everything, is denominated in sats.

If you want to introduce a unit smaller than the satoshi, then it requires a hard fork. A hard fork is a fork which makes things which are currently invalid, valid. If I tried to broadcast a transaction right now spending some fraction of a satoshi, it would be invalid and would be rejected. To makes this invalid transaction valid, we would need a hard fork to introduce smaller units and re-denominate everything in to these smaller units.

I'm not sure if I am correctly interpreting your question, but I think what you are saying is correct.

If your HD wallet software is connecting to a third party server in order to function (i.e. any wallet which is not running exclusively from your own node), then that software will query that third party server for the balance and transaction history of every address in your wallet. The third party server will then see a bunch of requests for different addresses all showing up at once from the same IP address, and can therefore be almost certain that all those addresses belong to the same wallet and are owned by the same person. If you are using Tor, the third party will see your Tor exit node's IP address; if you are not using Tor (or some other service such as a VPN) the third party will see your IP address.

If you then open a different wallet using the same software and query the same third party server, then that server will again see a bunch of requests for different addresses all showing up at once from the same IP address as before (whether that is a Tor IP address or your own IP address). It is possible then for the third party to link this second wallet to the first wallet by nature of the same IP address.

You can improve on this second problem somewhat by using a different Tor circuit and different third party server for each of your wallets. However, to completely mitigate both problems, then you must have your wallet software collect data exclusively from your own node.

If you are running your mining equipment as part of a pool, then generally speaking the pool will run multiple nodes each with their own mempool, use that information to build candidate blocks, and then send those candidate blocks to the miners to be worked on. Each individual miner doesn't need to run their own node, although many will. If you are mining solo, then you must run a node in order to receive broadcasted transactions to your node's mempool and then attempt to include them in a block you are attempting to mine.

Mining hardware does not have a mempool. It is nodes which have a mempool, and then use that information to create blocks for the mining equipment to work on.

Yes. Bitcoin Core is a full node, and as with any full node, will have a mempool.

Not necessarily.

I'm not a fan of any back up system for seed phrases where the compromise of a single back up results in you losing your coins. Because of this, I exclusively use either wallets generated from both a seed phrase and an additional passphrase, or multi-sig wallets. And as I have said before, I would always recommend having at least two back ups of any important information. So in such a case where I am storing a back up in a safe deposit box, then if the bank makes a mistake and drills out my box, I have not lost my wallet since I have additional back ups elsewhere, and my funds cannot be stolen since one back up on its own is insufficient to compromise my wallets.

If you only have one back up, and someone discovering that one back up gives them all the information required to steal your coins, then you are already in a highly risky situation.

It's a complete waste of time and all you are doing is giving exchanges even more profit since the majority grossly overcharge for withdrawal fees.

Only a minority of users will ever take part, meaning centralized exchanges which are either already insolvent or running fractional reserve (i.e. all of them) can easily cover the small number of coins which will be withdrawn. Further, since it is advertised and the date well known, all these exchanges can easily pull back in some risky investments or loans, or take out a loan themselves, to cover the withdrawals for a day or two if they need, before going right back to their usual scammy ways the very next day. Despite this day existing for several years, the number of exchanges going bankrupt or insolvent or turning out to be scams and their users losing everything is going up, not down. This day proves nothing and prevents nothing.

Most users who take part will withdraw their coins, pay the ridiculous withdrawal fees, and then just send their coins straight back the very next day. All they achieve is lining the pockets of the centralized exchanges even more, while gaining zero additional security.

If your coins are on a centralized exchange, then you do not own them and you are at constant risk of losing everything. This pointless day changes absolutely nothing. The only real proof of keys is having your coins in your own wallet 24/7/365.

This is much less of an issue. Although a satoshi is the base unit in the protocol (meaning introducing smaller units would require a hard fork), this is not the case for fees. Although we all think in terms of sats/vbyte for fees, in the protocol fees are actually define in terms of sats per virtual kilobyte, or kvb. The default setting is 1000 sats/kvb, which is obviously the same as 1 sat/vbyte. Because of this, if is easy to change that to 100 sats/kvb (for example), which would be the same as 0.1 sats/vbyte (which would obviously then be rounded up to the nearest sat). Indeed, not only do we not need to fork for this, but we don't even need an update to Core at all. Any node is free to change their minimum fee rate at any time, and miners are free to include any transaction paying any fee they like at any time.

You can already do this with Lightning. You can open a channel and make transactions involving millisats for as long as your channel remains open. If you close a channel which is holding some fraction of a satoshi, then the balance you receive will be floored to the nearest satoshi.

So for example I open a channel with 100,000,000 msats (100,000 sats). I transact back and forth over several months. At the end of those months my channel has a balance of 100,045,724 msats. If I close the channel, I'll receive 100,045 sats.

There is an important distinction to make here.

If an address has only received coins, then the public key is unknown (unless the owner has revealed it in some other way). Whenever coins are sent from an address, then the public key is revealed. This is the case for all recent P2PKH (pay to public key hash) outputs.

However, the transaction being discussed in this thread is not paying a P2PKH output. It is paying a P2PK output. Rather than paying to a hash of the public key (which we encode as an address), it is paying to the public key directly. As soon as a raw public key has received coins, then that public key is revealed on the blockchain.

100% this. If CSW ever did provide a valid signature (he won't), then given his long history of technical incompetence, plagiarism, poor knowledge regarding how bitcoin works, and multiple blatant and child-like forgeries, the balance of probabilities makes it exponentially more likely he has simply found the private key belonging to an early block as opposed to him being Satoshi.

Here's a post from Ray Dillinger on this topic which you might find interesting: https://bitcointalk.org/index.php?topic=819656.msg9170781#msg9170781

Even in such a case where bitcoin becomes a globally adopted currency, a satoshi is probably still going to be just fine as the smallest on-chain unit. The bigger issue would be dealing with fees and the dust limit for transactions which are only moving a few sats. No point paying 100 sats to move 1.

That's where second layer solutions come in to play. No one is going to pay 100 sats to move 1, but would likely have no problems spending 100 sats to open a channel which could move 1 sat over and over again, thousands or even tens of thousands of times.

You can code your own wallet software to display any units you like. I could code my wallet so instead of displaying 8 decimal places it displays 20. Instead of sats being the base unit, now my base unit is picosats. None of that makes any difference to the protocol though, and the smallest amount I could work in would be 1,000,000,000,000 picosats, which is equivalent to 1 sat. Trying to change any of the 12 zeroes in that number would simply result in an invalid transaction which would be rejected by the network.

The locking script for early P2PK outputs is simply as follows:

So simply look at the locking script, remove the 0x41 from the start and the 0xac from the end, and you have the public key.

This is a pretty misleading statement. Even with a known public key, the best known attack would require 2¹²⁸ operations, which is so far outside of the the realms of possibility it is not even worth considering. Any additional security which comes from having an unknown public key is the difference between deducing your private key being "impossible" and "no really, it's impossible". There are millions of bitcoin held on P2PK outputs which have known public keys, on reused P2PKH addresses with known public keys, and P2TR outputs now use public keys directly rather than pubkey hashes, so also have known public keys. The whole point of public keys is that it is perfectly safe for them to be public.

Yes you shouldn't reuse addresses, but this is a privacy issue, not a security one.

Here is a story from FTX which proves what I've been saying all along: https://news.yahoo.com/ftx-execs-hid-8-billion-173336895.html. FTX created a single account on their system, not belonging to any person, and put $8 billion of unaccounted for liabilities in to it in order to balance their books.

And so what stops any other centralized exchange doing the same thing? Absolutely nothing. They create a Merkle tree which includes a sham account or two with a balance of negative $8 billion. Oh look! Everything balances up perfectly. How convenient. Or maybe they have some third parties "audit" their books and bottom lines. Bearing in mind that none of these audits were actual audits and were just "agreed upon procedures" where the third parties were only given access to what the exchange wanted them to have access to, and so hidden in those books are a few sham accounts holding billions in made up liabilities. And surprise again! Everything balances up just fine. And all the time the exchange is actually massively insolvent and your coins are already lost.

That's not accurate. Two entirely different non-coinbase transaction can theoretically have the same TXID. It's just that it would be incredibly unlikely - the same as the chance of finding a SHA256 collision.

Correct. As per BIP34, the first entry in the coinbase's scriptsig must be the block height. At present, it is the first four bytes. The first byte is 0x03 to signal three more bytes, and then the next three bytes are the block height in little endian. So if we take the scriptsig from the coinbase transaction of the most recent block (768977), we see the following:

The block height is encoded by the following:

0x03 tells use to look at the next three bytes. The next three bytes are d1bb0b. Convert to big endian (0bbbd1) and then to decimal, and we get 768977.

That's correct. These two historic collisions are still viewable in the Bitcoin Core code here: https://github.com/bitcoin/bitcoin/blob/e9262ea32a6e1d364fb7974844fadc36f931f8c6/src/validation.cpp#L5311-L5321

Along those lines, the first thing to do would be to identify what is wrong with the existing solution which is impeding newbies.

Let's use the Electrum example we have been using above. What is wrong with it in its current format that makes it too hard for newbies to use?

Is it the process of verifying the download before installing it? I can appreciate that point, but it is an important step to ensure security. Do newbie guides on how to do this need to be more prominently advertised, or do they need to be made simpler?
Is it the process of creating a new wallet? The wallet creation wizard is pretty straightforward. You can't really make it any simpler without removing options and railroading every newbie in to a standard hot wallet, which I don't think is the right thing to do.
Is it the GUI of the wallet itself? Should we hide every tab except history/send/receive by default? Should we hide expiry on the receive tab? Should we hide description on the send tab? These are optional features which are not required to send or receive coins.
Is all of the above actually fine, and we just need better and jargon-free documentation and guides?
Is Electrum the wrong wallet to be recommending to newbies at all, and we should be recommending something else which is even simpler to use?

The problem with this approach is that once you have entangled yourself in centralized exchanges, it is significantly harder to untangle yourself than if you never used them in the first place. You have a bunch of coins which are connected to your real identity which you then have to thoroughly mix or coinjoin to break that link, you've already given away your personal information and KYC documents and they remain at risk of being stolen/sold/leaked forever, and it is impossible to delete all the information that exchange has gathered on you and shared with third parties. If you use a proper DEX from the outset, you avoid all of this.

I have no problem with people using bitcoin as a store of value. Such is the beauty of bitcoin - you can use it in any way you like and no one can stop you from doing so. What I have a problem with is centralized exchanges turning themselves in to banks and losing billions of dollars of money belonging to average people as they gamble deposits for their own profit, all while selling user data to governments and third parties.

Then you are entering the wrong string in to FinderOuter. If it is showing up immediately, then it means FinderOuter is simply checking the string you have entered and telling you it has an incorrect checksum. It is not actually attempting to brute force any other possibilities.

Here's what you should be doing:

Open FinderOuter
Click on "Missing Base58"
Paste in your private key to the first box
Swap the invalid characters I and l for the missing char symbol (which is * by default)
Ensure the input type is "PrivateKey"
Click "Find" at the top

If it doesn't find your key, if you could then copy and paste here exactly what appears in the box at the bottom, that would be useful.

Certainly. Any wallet which is not itself a full node (such as Bitcoin Core or other full node software such as Bitcoin Knots) will connect to public nodes (usually via an intermediary server) to collect the data it needs to display your transaction history and balance and be able to broadcast transactions. The node(s) or server(s) which you connect to in order to gather this information are able to see that you are querying this information, and are therefore able to link all the addresses in your wallet together and link all of them to your IP address and other information you might leak, such as the wallet software or device identifiers.

If you want to protect your privacy from the issue I have just described above, then you must run your own node and either use it as your wallet or point any other wallet software you might use (such as Electrum) exclusively at your own node (via an Electrum server which you also run).

It means that the checksum (the last 5-6 characters of the private key) are not valid and do not match up with the rest of the private key. In other words, you still have one or more errors somewhere and have not yet found a valid key.

Is this error showing up on btcrecover? Can you share exactly the command you are running? Does it give you that error immediately or does it perform a search first?

Or if you are using software which doesn't allow you to do either of these things, then the simplest thing to do is simply change your fee by 1 satoshi.

Yes, miners need to know about unconfirmed transactions, but they do so via nodes. Usually what happens is that mining pools run several nodes, and then create candidate blocks which are sent to individual miners. The individual miners themselves don't need to keep their own mempool or run their own node, because the mining pool gathers the necessary data for them via its nodes.

To an extent. It is entirely possible to use Electrum without knowing anything about elliptic curve multiplication or how transaction signing works or even how bitcoin transactions are constructed or how they are mined. You click receive, you copy the address. You click send, you paste an address. You could change the GUI to make it even simpler and remove any mention of advanced options, but the underlying process I think is as simple as can be. Even a third party custodial wallet or centralized exchange account can't get much simpler than simply "send" and "receive". Although if you also want it to educate people in the process, then you need to leave in some mention of more advanced concepts so people can learn about them as they go.

Then it seems we have all misunderstood you, as your original post very much reads like you want Core developers and the Core software to be responsible for implementing this proposal.

Some of the things you talk about already exist, such as elaborate yet simple to understand documentation which can then be expanded as people want to learn more. I would point to https://learnmeabitcoin.com/ as a great example of this. A lot of your proposal might be simply bringing together existing solutions in to one place or integrating them together. Maybe there is a market for an incredibly bare bones beginner friendly wallet, but I'm not sure how much simpler you can really get.