I suppose you could argue that the bug itself was a hard fork, since it allowed the attacker to do something which everyone agreed should be invalid (create 92 billion bitcoin out of thin air). But the successful patch to fix it was a soft fork, as it was simply tightening the rules (by making such overflow incidents invalid). Even BIP50 wasn't really a hard fork, despite often being called such. I don't believe bitcoin has ever had a successful hard fork.

The presence or absence of a chain split does not give an indication as to whether a change was a soft or a hard fork. Although obviously a hard fork could result in a chain split, we could also code a hard fork (such as to fix the 2106 problem) decades in advance which would result in everybody running a compatible client well in advance and there being no chain split.

As soon as you complete KYC on an exchange, then that exchange is cross referencing the data you provide them with identity data held by your government, so immediately your government can know that you have opened an account with that exchange. Most jurisdictions will require the exchanges to keep complete records of everything you are doing and provide them to various agencies in order to comply with AML laws, and similarly if you trade above a certain amount then you will be automatically reported to various agencies for tax reasons. None of this requires any suspicion of wrongdoing first. And even if they don't provide data to your government directly, we know that centralized exchanges all share or sell data to blockchain analysis companies (or even run their own blockchain analysis subsidiaries), and that governments extensively purchase data and rent the services of such companies.

I mean, just go and read the privacy policy of an exchange like Coinbase, for example: https://www.coinbase.com/legal/privacy. It is so extensive and all encompassing, it essentially gives them carte blanche to do anything they like with your data.

I don't think so. Or at least, not without fundamentally changing what bitcoin is.

At the moment, the split is resolved when one of the two competing blocks has more work built on top of it. That is the basis of proof of work. If you come up with some different mechanism to resolve the split, then it is no longer proof of work, but proof of something else. Further, what if your proposed mechanism resolved in the split in favor of Block A, but some miner running outdated code or different software or whatever accidentally built upon Block B before anyone else built upon Block A? Do we now ignore this chain with more work?

It would not be a case of an attacker still working on 700,001 when the rest of the network has moved on to 700,002, but rather an attacker already mining 700,001 and keeping it secret.

To build on the selfish mining idea in achow101's third paragraph above, imagine a miner finds block 700,001, and it has an exceptionally low hash, which would be enough to overcome two or even three blocks which have an "average" hash. This miner also includes, in every block they mine, a private transaction moving a large amount of bitcoin from one address they own to another address they own, which was never broadcast to the wider network. The miner decides not to broadcast their block 700,001, but instead keep it secret and instead broadcast a transaction which spends the aforementioned large amount of bitcoin with a merchant, exchange, whatever. They let that transaction confirm in block 700,001 on the main chain, get 2 or maybe even 3 confirmations, and then successfully reverse it by broadcasting their replacement block 700,001, which has a sufficiently low hash to reverse three existing blocks.

There is nothing to stop every miner from including such a self transfer in every block they mine, and any time someone is lucky enough to find a very low hash they can keep their block secret and attempt a large double spend.

Yeah, I would also have assumed that Electrum would have no issues RBFing the first transaction even if it invalidated the second one. The first transaction was definitely opted in to RBF?

Not necessarily if the fee on the second transaction was also being used to bump the first. Most wallets and software will base their suggested fee only on the size of the child transaction, and will not include the size of any unconfirmed parent transactions. Depending on the sizes of the two transactions, you might end up needing 10x or more the recommended fee on the child transaction to get the combined fee for both transactions up to a suitable level.

A hard fork does not necessarily imply creation of a new shitcoin, such as in the BCash fork. It is possible to implement a hard fork which the entire network agrees upon, which results in everyone staying on the main chain and no chain split. A hard fork simply means that the rules are being relaxed, and something which was previously invalid is now considered valid.

Not your keys, not your coins. I don't want to swap my coins for some wrapped token which introduces significant risk in that whichever party issued those wrapped tokens can exit scam me or go bankrupt at any time. Not to mention that using a centralized chain which issues wrapped tokens provides zero privacy.

And directly from the privacy policy:

I'll be avoiding this one, thanks.

I would say that the best way to learn is simply to try it. You don't need to spend any bitcoin (or any other money) or set up any wallets holding actual bitcoin in order to install Linux on an old device, set up Core, run Electrum or Sparrow, etc., and just get a feel for how they all work and interact. The best way to learn is by doing! Once you've played around with the software for a while, then you can commit a tiny amount of bitcoin to try the actual send/receive functions, or alternatively run everything on testnet and practice for free.

All of the software you have mentioned - Linux, Core, Sparrow, Electrum - have extensive set up guides and documentation, as well as a very helpful online community here which can assist with any troubleshooting.

You keep repeating this like it is a foregone conclusion, but it would be trivial to cap the number of halving events to ensure that the final supply is not changed. And even if this wasn't done, the difference from the rounding errors of 1 sat being the smallest unit compared to 1 millisat being the smallest unit are trivial. As things stand, the final number of bitcoin mined will be 20,999,999.97690000. If we converted to millisats before the first halving which it would matter (the 10th halving, which goes from 0.09765625 BTC to 0.04882812 BTC), then the final number of bitcoin mined will be 20,999,999.99997060. The "new bitcoin" as you put it would amount to around 0.02 BTC, and all your nonsense about 1.3 million new bitcoin is obviously just that - complete nonsense.

But no option to import an individual address or private key. I even tried making a watch only wallet in Electrum containing individual addresses (rather than from an xpub) and importing that Electrum file to Sparrow, but it returned an error about an invalid wallet type.

Ahh, I haven't tried importing individual private keys in to Sparrow yet. Do you run in to the same problem as I did above trying to import individual addresses to a watch only wallet - i.e. you can't do it?

Another excellent strawman. You should try arguing against things that are actually said, instead of just inventing points which weren't made to argue against.

Obviously there is no fraction of raw bytes, and I never claimed that there was. There is however, undeniably, fractions of virtual bytes. BIP 141 is quite clear that transactions are measured in weight units, and that virtual bytes are equal to weight units divided by 4, which leaves us with fractions of virtual bytes, which are then rounded up to the nearest whole byte for the purpose of calculating the fee.

That's the exact opposite of what I said, when I pointed out that a minimum fee of 1000 sats/kvB obviously does not allow you to pay 172.25 sats for a transaction which weighs 689 weight units / 172.25 vbytes since fractions of a satoshi do not exist on the main chain, and so the minimum fee must be 173 sats.

Try actually pausing and reading what people are writing before launching in to another tirade.

Yeah. I've only really tinkered with Sparrow as opposed to using it as a proper wallet yet (mostly because I see no reason to mess with all my various cold storage wallets which have caused me no issue for many years), but I was pretty impressed with just how easy it was to link it to my node. I've not used Sparrow enough nor examined the code enough to start recommending it like I do with Electrum, but it certainly seems like a strong contender on the privacy front since, as you say, it does away with the need to configure and run an Electrum server.

The only thing so far that I didn't like about Sparrow (or maybe I just couldn't figure out how to do it) was to create a watch only wallet involving individual addresses like you can do on Electrum. It seemed the only way to create a watch only wallet on Sparrow was via an xpub or similar, and therefore impossible to have addresses from different wallets in the same watch only wallet.

That's not how it works.

The value you are thinking of is the MIN_RELAY_TX_FEE (https://github.com/bitcoin/bitcoin/blob/e9262ea32a6e1d364fb7974844fadc36f931f8c6/src/policy/policy.h#L57), which is indeed set at 1000 sats/kvB (which is equivalent to 1 sat/vB). However, this only applies to the fee paid for a transaction. Sure, you can change it to 1 sat/kvB if you want, meaning that a 250 vB transaction would only have to pay at least 2.5 sats in fees, which would in reality mean it had to pay a minimum of 3 sats. However, none of that allows you to send fractions of a satoshi as a fee or to create outputs which include fractions of a satoshi. It simply sets a lower limit for what your fee can be.

Because transactions are actually measured in weight units, we already have transactions which are fractions of a vbyte in size. For example, here is one I just pulled from my mempool: https://mempool.space/tx/5cf1d3b06cdb4dcd4513a42d6d3b19691558326af4ca11b961d852e39d9ed402. It has a virtual size of 172.25 vB, meaning the minimum fee required for this transaction would be 172.25 sats. But of course we cannot pay a fee of 172.25 sats, so the minimum fee would be 173 sats.

That's not how wallets work. They do not need to be activated and they do not need to be connected to a live blockchain. Any valid bitcoin address already exists and can have coins sent to it, regardless of whether or not it has actually been generated by a wallet. It is entirely possible to create a wallet which is permanently offline and is never connected to the internet in any way, which will sign transaction offline, and it is only the transaction which is broadcasted to the network.

If you think the process of setting up a hardware wallet is too complicated for newbies, then a paper wallet is a very poor alternative suggestion. It is significantly harder to generate a paper wallet in a secure manner than it is to set up a hardware wallet, and it is significantly easier to mess up when generating or using a paper wallet and end up losing all your coins.

Here's a quote from the comments in the very code that you just linked to:

Which is exactly what I said. If you close a channel which is holding some number of millisats, then the transaction broadcast to the main chain will be rounded down to the nearest whole sat. Or here is another quote from BOLT #3:

So no, what I said is very much not wrong.

I mean, as DooMAD has pointed out, I literally said that a satoshi has always been the base unit in the very post you quoted, but feel free to create more strawmen at which to direct your rage.

Absolutely. Take a meter. It does not matter if you divide that in to 100 centimeters, or 1,000 millimeters, or 1,000,000,000 nanometers. You will never have more than 1 meter.

If it were the case that dividing bitcoin in to millisats was effectively creating more bitcoin, then why is Lightning bitcoin the same value as on-chain bitcoin? It should be that Lightning bitcoin is 1/1000th the price of on-chain bitcoin, since there are 1000 times more units in the form of millisats. This is obviously not the case, because dividing a fixed supply in to smaller units is not the same as increasing the supply.

Satoshi had no issue with further subdivision: https://bitcointalk.org/index.php?topic=44.msg267#msg267

When bitcoin was first launched, the term "satoshi" in reference to the smallest unit did not exist. Most people did not even know what the smallest unit was. The software at the time showed bitcoin as 1.00, and most people thought bitcoin was divisible by 100. At some point, we transitioned to bitcoin being divisible by 100,000,000. No one complained then that suddenly there were a million times more bitcoin, and the cap of 21 million had suddenly become 21 trillion because of 6 more places after the decimal point.

Further subdivision is obviously a far more complex issue given that a satoshi is the base unit as far as the software goes. But it seems Satoshi would not consider millisats to be an inflation in supply:


So if you had 1 sat before, it now shows as 1.000 sats. "Same amount of money", in the words of Satoshi.

getmempoolinfo should do it. As of 24.0.0, this now includes a field entitled "fullrbf" which returns true or false depending on if you have enabled full RBF.

And although I've not tried it, the next time you make a transaction you could ensure it is opted out to RBF and then you should be able to use testmempoolaccept to test whether or not your node would accept a replacement. Or, you know, just actually broadcast a replacement and see that it works.

Alternatively, you could also take a look here: https://fullrbf.mempool.observer/. Find a transaction which as been replaced but neither the original nor the replacement has been mined yet, and then use getmempoolentry to see if the replacement is in your mempool.

That would certainly be possible, although there are probably easier ways of doing it than reprogramming a fax machine.

As I said in my reply which you quoted, the individuals themselves don't necessarily need internet access, but the transaction must reach the internet somehow. If there is a local node with internet access, then any method of getting your signed transaction to that local node to be broadcast would work. Transmitting over telephone lines via a modem, a reprogrammed fax machine, or something else, is certainly a possibility, as is radio, mesh networks, SMS, going there in person with the transaction on a USB drive, and so on.