pull down to refresh
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.
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 2160 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_CHECKSIGIn 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.
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.
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.
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.
I must have shilled this here before, but Gloria and I wrote a whole series on mempool policy that might be of interest to a voracious reader such as @Scoresby:
I don't think it makes sense, but I've heard Steve Lee make a similar argument about defaults around some of the quadratic hashing type transactions. That there need to be defaults that don't accept such transactions so that miners won't build blocks with them.
You may be thinking of the new policy Bitcoin Core v30 introduced to restrict the number of signature operations permitted in legacy script. The idea here is to discourage at the policy level in advance of BIP54 introducing a consensus rule that elevates the same limit to a consensus rule.
The comparison to the US government didn’t seem relevant at all.
Mempool policy changes are easier than consensus changes because just a small minority adopting a more permissive behavior de facto establishes the policy. Similarly a small minority rejecting or lagging behind in the adoption of a more restrictive policy de facto vetoes it. A state in which there is a sufficient financial incentive for some group to adopt a more permissive policy is inherently unstable in the long-term.
The comparison of policy changes with softforks also strikes me as a false dichotomy, because policy changes by their very nature do not require a change to the consensus rules.
As I remember it, tx sponsors didn’t garner much support because being able to bind any transaction to any other transaction would open up an entire new range of pinning, transaction churn, and denial-of-service concerns, and likely would have made the blockspace market drastically more complex.
:%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.