dcousens

I think it depends on where you draw the line for the word "natural". If you include human behaviour, it is natural, but yes, otherwise it is typically known as "artificial selection" in this context.

Opposite experience here. Near 4-5x slower than actual HN for me.

Therefore, you could consider the "need" for this to happen in the first place, a "late-stage" flaw of capitalism.

I think you agree with the OP?

Maybe the data usage would have alerted the infected.

This mirrored my confusion when `AES_cbc_encrypt` modified my IV data when _decrypting_.

Easy. Vim doesn't get in my way.

52 attempts first here, then 25 then 20... exactly the same thought process.

How does a code base become so cumbersome, without someone signalling that there will be a price to pay?

If you moved your scripts to 1st party, uMatrix wouldn't block it

Honestly, just being able to "tick" each commit would be great. On https://github.com/bitcoin/bitcoin/ it is common practice to include the commit hash in your approval comment so you can easily review where you were up to if a rebase occurs.

I just use `notify-send` every 30 minutes... https://github.com/dcousens/dotfiles/blob/master/.xinitstatu....

The graph displayed of ECDSA duplicate r-value exploits shows 2 prominent "columns" of addresses, the latter of which was in April/May 2014. That latter column was directly related to a commit that I made to the bitcoinjs-lib master branch (which was undergoing major refactoring at the time).

The commit that fixed the issue: https://github.com/bitcoinjs/bitcoinjs-lib/commit/bc37e65014...

The issue itself was that a `Buffer` was being interpreted as `0` by crypto-js's cryptographic hash functions in our implementation of RFC6979, thus creating a case of duplicate `k` values.

The second most interesting point was the majority of the funds (>20k USD) stolen from Counterparty (the only known users of our master branch at that time) was returned by a grey hat.

That point when you realise you're responsible for the data in someones presentation.

You're not wrong.

Thanks for pointing this out, thankfully the implementation already failed on a negative s value, but you're correct in that it wasn't definitive.

I also whole-heartedly agree with your comment about the unnecessary inclusion of a bignum that allows for negative values. The lack of typing in this (and other cases) has lead to several problematic scenarios for users to the point we have littered the code with assertions to enforce whatever we can.

Its not really a bug, the operations after it would still be valid (it is almost immediately reduced to the field order), its just that those parameters would not be akin to the SEC paper specification. I agree that the honus isn't on the users to check that though, so I'm probably going to make a pull request to change this.[1]

[1] https://github.com/bitcoinjs/bitcoinjs-lib/pull/250