Why would you consider this a bug?  Yes, it could have been implemented differently, but the definition of CMS is that signature validation passes N of M times.

Obvious ways of implementing it-- including the way it was originally implemented-- wouldn't provide for any way to determine exactly why a signature failed to validate only that it did.

In fact Wright has shown extremely profound technical ignorance about Bitcoin, but he says that what he is saying is brilliant. Because you, yourself, are incapable of directly evaluating his claims you make the mistake of believing him and other similarly uninformed persons.

Of course, not absolutely everything he says is untrue or gibberish-- some things he just copies out of the bitcoin wiki or old posts and chatlogs.

This is a great point and it's something to keep in mind.  I do think that many of the people wright fooled could have and should have done better, but none of us should feel confident that we couldn't have been fooled. We could have. Maybe the trick that would have fooled us would have been different or the situation that succeeded would have been different. But humans make mistakes.


To be fair, the only thing that ever appointed him as Chief Scientist of anything was an organization that he, alongside Jon Matonis (Former Nchain Vice President of Strategy), Roger Ver (another prior Wright sucker, massive shitcoin promoter), Peter Vessenes (stole millions from MTGox customers and is holding up the distribution of the remaining mtgox assets with frivolous litigation),  Charlie Shrem (went to jail for money laundering), and Mark Karpeles  (lost customer funds at MTGox and went to jail for smaller scale embezzling) created.

There are plenty of defences that can be offered for the Bitcoin Foundation and the people involved with creating it but I don't think anyone can argue that it was some dream team of people went on to demonstrate good and careful judgement.  

Validation of Wright's evidence is a question for a technical expert. Gavin had sufficient expertise to demand the right things-- he had even previously published a more or less reasonable laundry list-- and he didn't. He also knew enough to know the basic limits of his expertise, such as being unable to determine if a random windows PC had been tampered with. Most importantly, he should have known that he was being asked to participate because his enforcement would be taken as a high degree of assurance, nearly proof, by the media and the public -- and as a result deserved either an appropriately diligent vetting on his part or a refusal to participate if he was unable or uninterested in providing one.

From my perspective it was just another example of a long history of poor judgement.
 
The fact that anyone can be tricked is why it's so much more important for people who will be perceived to be an authority to make an extra effort to not get tricked or just not play along.  So I think here the issue isn't so much that wright tricked him, it's that he shouldn't have been exposed in the first place, and that to this day he still has do little to nothing to walk back the damage.  Wright suckers still continue to cite his equivocation as evidence to support wright. I  think Ver is one of the less ethical people around cryptocurrency, and yet even Ver did better and eventually provided an unequivocated statement against wright's claims.

I'm really sad to hear this. It seems like bitcoin faces such tremendous headwinds.

Indeed, I don't know that he'll run it again in May.  But when 6 months from the last run comes up I'm going to nag him to do it.  I got seriously gimped in the last update because I'd been inactive for a while.

BIP37 has zero privacy.  https://en.bitcoin.it/wiki/BIP37_privacy_problems   Electrum also has extremely poor privacy but at least its upfront about that and actually works well, the BIP37 approach is pretty much the worst of all worlds-- it takes forever to scan the chain plus it identifies and links your addresses and it makes nodes DOS attack vulnerable in the process.

That sounds like a DOS attack, to be honest.  I usually see weeks pass without a single connection from an actual SPV client,  though there are bunch of shitty spy things that pretend to be them.  It absolutely shouldn't be making remotely that kind of difference.


uh, also, 125 is the maximum connections.

The only issue it exposes you to are DOS attacks and any bugs in that functionality... though bugs seem fairly unlikely at that point.  The DOS attack issues have been exploited in the wild, so for a rarely used and not very useful functionality.

Wrong question.  Difficulty is floating, it'll adapt to whatever is there.  A single asicminer using a hundred watts is enough to keep blocks being produced.

The question you should instead ask is "how much of an increase is needed to keep security acceptable?". Because if a single asicminer is all thats keeping the network going then two asicminers would be all that were needed to reorg blocks and replace recent transactions (and twenty could replace ones that weren't particularly recent!).

A couple years ago during congestion before segwit was rolled out, there were sustained total fees in amounts similar to the block subsidy!  So I think that's pretty strong evidence that fees can be high enough to provide for reasonable amounts of security.

At the moment Bitcoin arguably has too much capacity now between changing usage patterns (e.g. batching, and sweeping during low fee times) and segwit and as a result fees are floating at about 2% of subsidy and often running right at the default minimum relay fee. After the halving they'll end up about 4% (though, likely they'll go much higher in a brief period after the halving due to congestion, due to the rate of block production going down for a little while).

The little tombstone icon seems rather playful-- I'm reminded of old shareware rpgs-- for something that should be at least somewhat sombre. Maybe a unicode block instead of an image at all:  █

One thing to keep in mind for these TMTO approaches is that the pre-computation size can be amortized across multiple problems. So, for example, on a 2TB ram (plus a few TB of disk) host you can build up a 2^38 ish-sized table and reuse it against multiple problems... and solve each additional 64-bit search with 2^25 operations each.

The optimizations to get low memory don't work quite as well for amortizing multiple problems, or at least are much harder to implement.

Andytoshi wrote a static analysis tool that was sound but incomplete... it would find scripts that could never be satisified, e.g. because of types/length mismatched.

IIRC other than those large MTGOX outputs there wasn't a whole lot more.  There is a large number of low value ones created by a p2pool bug and a smattering of other things.

While standardness might have helped, the big reason you don't find any is because people don't like throwing their coins away!

Perhaps, but quite a few times people have shown up with "cracking" tools that turned out to be a scam. It's a pretty standard MO. In particular several of the more recent ones have setup making these seemingly pointless "advertising posts" then nailing people who PM them, e.g. by sending them the software privately where other people can't call it out for being malware.  I guess they feel better about robbing people because they imagine they're robbing other thieves.

If your program could actually do what you claimed-- evaluate 2.2 petakeys per second, then it could find keys whos pubkeys have 60-bit leading zeros quite quickly.


But instead you demand a starting point _and_ a public key (rather than, e.g. a key hash). Which means you cannot actually do what you claim, because you need to compute a point difference in order to use a precomputed table.  One we consider that, instead what you claim is not impressive-- it is outright slow.

Assuming that the pubkey isn't available for that challenge payment-- go solve it.  It's worth several thousand dollars, so if you could actually operate at the speed you could you wouldn't be wasting my time, you'd be collecting the bounty.

Or go start at key 1, within 2^64 operations you will find a pubkey that begins with 60 zero bits with very high likelihood.

No I am talking about finding the private key for ANY pubkey which matches a particular criteria: one where the first 60 bits are zero, so that it will take on average 2^60 operations to find it.

Your first post said a speed of 2.2 PH/s.

And I suggested two days.

You should be able to find a key matching the property I described in about 2 days at 2.2PH/s.

Man, why you gotta tell me this at 5am when I'm too tired to go actually attempt collect it. I'm going to guess the pubkey isn't available, or otherwise this would have already been solved.

Clearly you're looking to fool people who don't, sadly for you I'm not one of them. Though the fact that you don't recognize that I do is odd...

This is exactly the same as what you offered above-- you just offset the starting position of the interior step.

In what you describe, I choose x and y so that their difference is 60-ish bits. Then I give you y and xG.    You would compute yG - xG and begin adding steps of the 2 x table_size * G to it and looking up the result in the table.  Once you find a hit, you add the table position, the loop offset, and the y value to yield x.

What I described to you -- finding a private key whos pubkey begins with a long fixed string is an actual test of performance. To make it a better test, instead of zeros (which you could have precomputed over weeks or months) it would be better to use the hash of a recent block hash to bound the starting time. But zeros would be good enough for the discussion here.

I'm sure if you got anywhere near a 68 bit chosen prefix in two days you'd be setting a world record in "purebasic" computation for sure.

That isn't impressive at all and wouldn't prove your claim.  Because you fix a range, you could simply have a table of 2^31 entries (1G, 2G, 3G) based on X-only, you step by twice the size of your table, checking only the X to get a positive and negative offset, and find the match in one hour at a terribly slow rate of 1.2 million keys a second.

At that speed you are missing even the most basic optimizations.

Go away scammer.

Or come back with a private key who's pubkey x coordinate begins with >=68 zero bits within two days... (other than the one with pubkey 00000000000000000000003b78ce563f89a0ed9414f5aa28ad0d96d6795f9c63).

That CPU cannot do *any* operation at that speed, not even a single 32-bit multiply. Your post is an outright untruth.

My guess is that you intend to trick people into running malware or just rip them off selling them cracking software that lies about its performance.

The best practice is don't.

You can't discuss Bitcoin if you are sick or dead.

I get the impression that the anti-authority streak of many contributors here results in the forum having more than its share of participants who are covid19 deniers.

Just like it's important for the health of a geographic community to be well informed, it's important for the health of an online community to be well informed.  Due to conference and events its even possible for BCT members to transmit the virus to each other! ---- though, I agree that is much less of a concern.


That is a phenomenal piece of misinformation.  Because it's unethical to conduct a randomized-controlled test for live infections, all the studying in actual humans is extremely underpowered-- it's stuck with very few participants, poor compliance, testing too late when they're probably not very contagious, etc.  When you have an underpowed test the most common outcome is that the finding is not statistically significant.

It's like saying that "there is no evidence that parachutes improve survival when jumping out of planes" -- because virtually no one is jumping out of planes without them and some of the few that do survive.

So, instead we get stuff like natural experiments where an aircraft flies from NY to China with a person with swine flu on it, and zero people on board with masks get sick while 47% of the unmasked "control group" people got sick. Was it due to the masks, or was it simply that people with masks were more careful in general? We can't be completely sure.  The purpose of having a randomized control trial is to eliminate issues like that, but we can't go around intentionally infecting people with swine flu.

The particular study you're linking too was frustrated by detecting extremely low levels of viruses in *all* samples. For example for coronavirus (OC43) they  only detected the virus in droplets in the breath of 3 of 10 parties with the virus and no mask, while they detected it in 0 of 11 with the virus and a mask. Yet we *know* these viruses spread via dropplets. Their problem was that they either weren't testing people while they were contagious-- e.g. because the most contagious period was before symptoms showed, as is believed to be the case for sars-cov-2-- or their measurement approach was just busted. But regardless, in every case the mask reduced the levels they detected.

The problem was that their test was so underpowered that even an infinity fold reduction in rate was not statistically significant.

If the same approach study had also tested a six foot thick lead lined concrete wall, it would have also concluded that there was no evidence that it prevented the spread of OC43!  No virus particles would have been detected on the other side of the wall, just like the mask.  It would have been nice if they did include that, because then we could go around saying that there is no evidence that a mask works less well than a six foot thick lead lined concrete wall, and we'd be just as technically correct. And while it would also be a stupid and misleading claim, it would probably be less misleading than the claim that masks are completely ineffective which you've extracted from that paper.

Here is the image you couldn't link: