What do you mean by erroneous?

The protocol requires that timestamps be greater than the median of the last 11 blocks and less then 2 hours into the future from your own perspective.  If you get a block more than 2 hours in the future you won't accept it until its within 2 hours.  Any timestamp that passes these criteria is valid, anything else will be ignored.

Time based locktimes aren't based on the time on the current block anymore, but instead are based on the median of the last 11 blocks (the lowest timestamp the block could have).

The allowed 2 hour difference on the blocks timestamp allows a one time 2hr/2week = 0.5% difference in inflation, -- utterly irrelevant and well below the noise.

Bitcoin's requirement for accurate time is *extremely* loose.  A sundial and an almanac is pretty much sufficient.


It's likely that the person you're quoting is confusing multiple different uses of the word 'clock'.

Bitcoin only has a timestamp in it at all to keep the inflation schedule on track and make the infrequently used time-relative locktimes work.  If we didn't care about those features it could just exclude the timestamp entirely-- and it would still be a clock, one that just ticks in the form of blocks.

The idea of Bitcoin is that anyone who has knowledge of the protocol can log on and determine the correct state of the ledger trustlessly. I ask my peers for the current blockchain and choose the one that is both valid and has the most work.

However, this ideal is not entirely achieved. A block is only valid if its timestamp is close enough to the actual time. This means that malicious miners can confirm blocks with erroneous timestamps, and there would be no way for someone logging on for the first time to detect that this has happened. This is in stark contrast to the case of malicious miners confirming blocks with erroneous transactions, for these erroneous transactions can be detected using only the information internal to the blockchain.

Malicious miners can validate a block with an erroneous timestamp. If they are in the majority, their chain will have the most work. Anyone logging onto the network for the first time will not be able to detect that the time stamps are erroneous. There may be nodes running with no downtime who claim that the time stamps are indeed erroneous, but there is no way to confirm who is telling the truth.

The implication is precisely that the timestamps may have been forged and there is no way to detect this trustlessly. People talk as if blockchains can function as trustless clocks, but this is simply not the case.

My spy filtered node counts 36% of its peers as taproot supporting right now, FWIW.

(earlier I was confused that this was _lower_ than the above figure-- I expected it be higher, but I missed that kano had apparently overcounted by including 0.21.0 and now all is clear! )

Let me put it this way:
We simply have a key derivation function that takes 2 inputs, A and B. If A is created from a 128 (or 132) bits of entropy and B has 0 entropy (no extension word) then your KDF is deriving its keys using that much entropy. If B also has 128 (or 132) bits of entropy then your KDF is deriving its keys using A + B bits of entropy.
Additionally we can say that in order to brute force this to get the BIP32 seed you'll have to generate and check both A and B so the entropy size is A+B.

@xmready, I've used a 12-word seed as an extension in the past.  When I was a younger bitcoiner I thought that would double my entropy, but I've since learned that it does not.  Take a look at hosseinimr93's post above, he is showing you how to generate an honest-to-goodness 24-word seed with double the entropy of a standard 12-word seed.  I also advise against using the same pool of words (i.e. Bip39 word list) for your extension, just to add an extra level of security.

So you mean you want them to split and have two seeds generated for two owners of the wallet?

Is there any specific reason why you want that method? Goin' with electrum's 136 bits is more than fine.

Each electrum seed is already extended with the word “electrum”, if you choose to extend it more with another seed phrase it'd become “electrum<seed_phrase>”.

So it doesn't double the entropy, instead, the entropy remains the same. What it does change is a salt. Once you're done with the seed generation and salt selection, the result is being put through a key derivation function called “PBKDF2”. But, you can of course do it, it'll provide around the same security for a human being.

what do y'all think? Before or after?

Some miners try to save a tiny amount of time by "spying" on other miners. For example they connect a fake miner to the other mining pools and as the other pool finds a new block their fake miner receives that "hash" of that block which is small (32 bytes only) then the "spy" miner builds their next block based on that hash alone without verifying if the block that was found by the other pool was valid or not (which it may not be valid and during a upgrade/fork the chances of it are higher and that would create a longer stale chain with 2 blocks in it, if more miners do the same this stale chain can become longer).

If anyone is ignoring the community, it's luke

In many prior activations at some point after the rules became active some broken miner managed to mine a rule violating block and some other miners who weren't broken but were just not updated yet produced blocks that continued after the invalid one.

Everyone who is updated, including correctly upgraded miners*, will just ignore those blocks like they never happened.  So the invalid block and its descendants will all become stale blocks.

If you aren't upgraded you may see confirmations that go away during such an events, and if you're a miner and not upgraded you will lose money by mining on a doomed fork during such an event.

If *many* people don't upgrade such an instance could be disruptive to the ecosystem, with various services accepting transactions on the invalid fork that will be lost when the valid fork overtakes it.

If for some reason you can't upgrade before activation it would be best to make sure your node(s) connect to the public network exclusively via an upgraded node so the upgraded node will act as a bad block filter.  This works for mining too, since older standard software won't introduce invalidity, only follow it if someone else introduces it.

If you can't even do that but are actively accepting payments, then you should require more confirmations before considering a transaction irreversible.  An extra ten might be a good starting point, depending on how quickly you'd respond do an incident.

If you're not accepting payments it's less critical to upgrade, but its still good to do so that your node can participate in helping the propagation of valid blocks and not propagating invalid blocks.

(*) A number of large miners engage in validationless mining-- they will mine empty blocks after a block without validating it. So confirmation by a string of empty or nearly empty blocks shouldn't treated as confirmation.  The emptyness is actually not a fundamental property but its easiest to implement that way so for now its a reasonable indicator that the miner hasn't actually validated anything.

although if the soft fork is confirmed you will need to upgrade before November when it activates to be safe

This thread is about Taproot implementation

This upgrade is becoming more, and more complex

I think that it was clear in my post as 14 people were fine with either choice 

Very well said, I could not have found a better way to express that, which is what I think too. Only problem I see is the very long wait: August 2022 is too far way, too many things can happen in this huge timeframe.