It gets even more mindboggling, when you turn it around: the expected time since the previous block is also 10 minutes. So at any point in time, the expected time between the previous block and the next block is 20 minutes.

Yay. :)

what means SBR?

He apparently thinks that they should be added to the U.S. Strategic Bitcoin Reserve.

Ah right, sure. The likelihood of C-A-A being found before C-B should then just be $x$.

That sounds like a big mistake, not a small mistake! :grin:

I agree, and retract my guess. I’m gonna have to wait for someone else to correct me, though.

a. If Alice hides the block, hash power is now directed separately at two chains. Alice is mining on C-A while Bob is mining on C. What is the expected time until Alice finds C-A-A, and what is the expected time until Bob finds C-B?

The expected time for Alice to find C-A-A is $\frac{10min}{x}$.
The expected time for Bob to find C-B is $\frac{10min}{1-x}$.

b. What is the probability that Alice finds C-A-A before Bob finds C-B? Hint: Look up Poisson processes and competing risks.

The approximate probability that Alice finds C-A-A before Bob finds C-B is $\frac{x}{1-x}$.

b. What is the expected time to the next block?

Answer: 10 minutes - how long since the last block

Bitcoin mining is a progress-free process, therefore the expected time to the next block is always ten minutes, regardless of how much time has passed (assuming that the difficulty matches the deployed hashrate).

I also think that you are either interpreting the question 1.c. very differently from me.

The way 1.c. is posed sounds a bit odd. Are you asking what the expected reward for either party is or do you mean to convey an additional constraint by mentioning the time?

I was gonna write my own answer, but @Undisciplined’s answer matches my thinking.

Yeah, that struck me as completely divorced from what was going on in the Bitcoin Core repository as well.

Nit: BIP 360 does not disable the P2TR Keypath, it proposes a new output type that only has a script path and otherwise is like P2TR. This would not at all affect existing P2TR usage and would require any adopters to implement handling for the new output type.

You got me good with the link at the bottom. I thought version 31.0 was out, but we are on v31.0rc4. ;)

Heh, it seemed like the obvious place to publish a little bit of text without involuntarily revealing it to other people stumbling on this exercise.

She’s in Finance. She solved it visually: I added her explanation to my gist above.

There is nothing new under the sun. ;)

Your site recreates LightningK0ala’s https://satoshis.place that was very popular in 2018.
He published the source code here in 2019: https://github.com/LightningK0ala/satoshis.place

His site sold each pixel for 1 sat, though.

Heh, my wife looked at it for fifteen seconds and also had it. And her explanation was much simpler. Guess we can both go to middleschool now.

I have the solution. It took me a few minutes to figure out how to express the shaded area in terms of the semicircles and circles. We don’t have spoiler syntax here, do we?

Solution: https://gist.github.com/murchandamus/d1accb1188eb18b29e9496d2f27b5eab

Yay, I can graduate primary school! Thanks for the fun. (^_^)/

They could be forbidden at the protocol level, but they cannot be prevented at a per-output level by the user.

If this is correct, as I assume it is (maybe somebody more familiar with tapscript can correct me if not), it's trivial to use taproot too in a "quantum safe" 😂😂 way.

Giacomo is mistaken here. You can use P2TR with the keypath rendered unusable (to the output owner) by using a NUMS point as the basis for the script tree tweak. However, even if you use a NUMS point, it must be a valid point for the script path to work. While the output script owner can prove that no human could have known the private key corresponding to the NUMS point, a CRQC could still calculate and use the private key to spend via the keypath.

Huh? No, by default nodes are configured to be listening.

Yes. Whether by oversight or done on purpose, Satoshi’s original release did not process the coinbase transaction in the Genesis block like other transactions nor was its output added to the spendable outputs manually. Therefore, the Genesis block’s reward is not part of the UTXO set.