I may have cut off the id, https://podcasts.apple.com/zw/podcast/honigdachs/id1099608079 works.

oh oops, I just have broken the link when I formatted it

Sorry, I didn’t mean that you missed it, it seemed pretty obvious that you were only looking at English podcasts. I just thought it was an interesting tidbit to share.

One of my favorites, a German Bitcoin Podcast called Honigdachs (German for honey badger) has been running since November 2015 (and is still running). From what you describe, they might have claim on being the longest running podcast, although they certainly haven’t made the most episodes, they have made 116 so far in a bit over ten years.

:%s/Ponsoit/Poinsot/g ;)

P2TRv2 would be the easiest for wallet developers to start supporting and would support all of the wallet features that we have been building for the last ten years. The big downside is of course that it sets us up for the difficult decision when to disable the keypath for it at a later time when it might be really costly to get it wrong either by being too early or too late, and likely it would be hard to agree as a community.

They do also infect humans and pets.

He found a list of addresses, turned it in, so it should be only fair that the police return the list of addresses to him when it befalls to him as the finder.

The three are:

• LNHANCE
• BIP-110
• CTV

See, e.g.: #1461045

@optimism: Didn’t realize that you stopped those until now! How are we going to keep up with that without your posts telling us?

The baby boomers are the generation born between 1946 and 1964. Somehow my mental image of you is much younger. ;)

There are actually three soft forks signaling right now, and Sztorc’s ecash is a hard fork/forkcoin, not a soft fork.

It’s not impossible, it’s just that the number space is so enormous that it’s exceedingly unlikely that it will ever be found: every random private key you generate will map to one of 2¹⁶⁰ possible P2PKH addresses.

Also see, Bitcoin Stack Exchange Is each Bitcoin address unique?

These funds will remain burnt even if CRQC make an appearance. The 000…000 was inserted in the position of the pubkey hash. The public key that hashes to 000…000 remains unknown.

You can see this by inspecting the details of an output that paid 111…14oLvT2`, e.g., on mempool.space:

Usually when you generate a key pair, you would first randomly produce the private key and then calculate the public key from the private key.

To make a Pay to Public Key Hash (P2PKH) output script from the public key, you would hash the public key and insert it into the following script:

OP_DUP OP_HASH160 OP_PUSHBYTES_20 <pubkeyhash> OP_EQUALVERIFY OP_CHECKSIG

In this case, instead of generating a private key, calculating the public key, and producing its hash, someone just put 000…000 for <pubkeyhash>. Because it is extremely unlikely that someone would find the private key whose public key hashes to 000…000, funds sent to the resulting address are likely lost forever.

This holds true even if CRQC make an appearance, because CRQC can only calculate the private key from a public key, but they cannot reverse hashes. The public key corresponding to this P2PKH is still unknown, the 000…000 took the place of the public key hash, not the public key.

Thanks for covering our announcement!

I’m wondering how the work relationship of people could be discovered. Some people reply to each other because they are collaborating. Some people serially reply to each other, because they cannot ever agree. If the latter could be discovered in some manner, and push people apart rather than pulling them together, the clusters may actually be more representative of what’s going on.

I think you forgot to share a link to the site:
https://sorukumar.github.io/orange-dev-network

The 'Email para newsletters' circle strikes me as strange:

Cool data, but the Influence Map is a bit hard to read. Especially among the more active contributors basically everyone reviews everyone.

You might also like BIP451 that just dropped recently.

I thought Greg Tonoski wanted to be a BIP Editor, but I haven’t seen him review a PR since he said that again.

I need to provide an update on that on the mailing list. Meanwhile, several people have approached me to indicate interest in the role, and a few of those took me up on my suggestion to review some open BIPs. We should start talking about the composition of the new team.

Regarding the candidates for the role, I have lately been thinking that Bitdevs organizers should potentially consider whether they are interested: they tend to have a decent overview of what’s going on in the mailing list and in protocol development, and may be looking for ways to contribute more.

That’s part of why it works at all! (^_^)/

Exactly what @optimism says here: policy is capable of discouraging new behavior from taking a first foothold, or as long as almost the entire hashrate does not accept the new behavior. Low-feerate transactions had been propagating on the network for years before the sub-sat-summer, but when one miner started including the low-feerate transactions the behavior was adopted quickly by a larger part of the network.

I don’t have the exact numbers on hand, but I agree with Optimism that a surprisingly low adoption among the node population is sufficient for transactions to propagate somewhat reliably, even more so if they are preferentially peering. Laurent had some interesting simulation results regarding transaction propagation here: https://x.com/LaurentMT/status/1973416866212180089.