BitCoin delenda est Was: Escalation: time commitment to fix *production* security bugs for BLS RFC v4?

[Phillip Hallam-Baker <[e-mail]>]

OK, if we are escalating to IETF wide discussion...


As a human being living on a planet threatened by environmental damage from
CO2 emissions, I am strongly opposed to any IETF work to support any form
of purported 'cryptocurrency' that relies on any form of 'proof of work' or
'proof of waste'.

The electricity requirements of cryptocurrencies have been larger than that
of entire countries. This is an experiment that it is time to stop.

I am entirely serious in this position.


Besides the environmental issues, there is the fact that the
crypto-currency community has consistently failed to establish any
effective means of preventing the endemic frauds in their systems.
Fraudulent exchanges regularly steal money from their customers.
Applications developed by individuals with minimal expertise are used for
transfers of vast quantities of fictional cash with no effective oversight
and this results in further frauds.

The cryptocurrency community has a long history of misrepresenting the
engagement of parties with established reputations as endorsing their
'product'. And this presents real risk to the IETF when the least
objectionable use of the product in question is to evade currency controls.
Cryptocurrency became popular as a means of paying for illegal drugs and
has since become the enabler for ransomware.

The cryptocurrency world has no shortage of people who will trash anyone
criticizing their activities as 'stupid', 'uninformed', 'need to do some
research'. Fine, let them sort their own messes out.

IETF should take no action that risks a headline 'IETF endorses
cryptocurrency'. If the ransomware, child abuse and Ponzi scheme industries
have a problem as a result of a bad technology decision, we should not lift
a finger to save them.


The only conversations I want to have on cryptocurrencies is with
government regulators looking for ways to regulate these criminal
facilitation enterprises out of existence as they previously did with
eGold, Gold Age and BTC's very long line of predecessors which like BTC
were entirely different but completely the same.


On Mon, Apr 26, 2021 at 9:19 AM Quan Thoi Minh Nguyen <[e-mail]>
wrote:

>
>
> ---------- Forwarded message ---------
> From: Quan Thoi Minh Nguyen <[e-mail]>
> Date: Fri, Apr 23, 2021 at 9:13 AM
> Subject: Escalation: time commitment to fix *production* security bugs for
> BLS RFC v4?
> To: <[e-mail]>
>
>
> Hi,
>
> I'd like to escalate this issue to the CFRG chairs as a last resort. By
> responsibility disclosure mechanism, I reported the bugs *privately far
> before* I posted it publicly at
> https://github.com/cfrg/draft-irtf-cfrg-bls-signature/issues/38. I did
> everything in my capability: reported the bugs, wrote proof-of-concept
> attack, wrote proof-of-concept fix.
>
> I'm curious what is the time commitment of the RFC's authors in resolving
> the following deadlock:
> + Libraries code (ethereum/py ecc, supranational/blst,
> herumi/bls,sigp/milagro bls) are deployed in *production*. They're not
> academic nor experimental code.
> + Libraries' authors can't fix the code because they have to follow the
> standard.
> + BLS RFC v4's authors don't move an inch in fixing it nor have any time
> commitment.
>
> The standard authors are in an extremely powerful position where they
> dictate what every library should do. Does it go with responsibility for
> responding in a timely manner for security bugs deployed in *production*?
> Even if they don't want to fix the message binding bug, should they at
> least fix a very obvious bug? AggregateVerify((PK_1, PK_2), (msg, msg), 0)
> = True, FastAggregateVerify((PK_1, PK_2), msg, 0) = False.
>
> Note that I'm not saying my proposed fix is correct and RFC's authors
> should follow it. What I'm asking is the BLS RFC authors' time commitments
> in resolving the security issues deployed in production?
>
> Thanks,
> - Quan
>
>