The use of Guy Fawkes Signature in case of ECDSA zero-day exploits

[kjj]

Protection against a potential weakness in ECDSA has been included since day 1.  Don't reuse keys.

It doesn't help, if someone can crack the key before your tx gets confirmed and has a better access to miners.

Use your imagination, mr bitcoin elite.

Also, in reality, a sudden catastrophic break in ECDSA is pretty much unimaginable.  There have been zero sudden breaks of that magnitude in modern cryptosystems.

How is it unimaginable when the trapdoor is based on math we think is hard? "It hasn't happened before, ergo..." is a logical fallacy. "Modern" cryptography has been primarily based around symmetric crypto which is much simpler and does not rely on trapdoors.

There may be some value to adding this to the system in advance of the need to use it.  It may even enable some other useful things.  But it would be a fork.

There is definitely value in additional protection.

Old systems were broken suddenly because they sucked.  No one knew they sucked, because no one was looking at them.  Anyone can design a system that they can't break.  Our systems don't suck any more.  They aren't built in the dark.  Everyone looks at them.  In fact, a decent fraction of the intellectual power of the human race is devoted to examining cryptosystems.  The really bad ideas are gone now.

I understand full well that the history of modern cryptography doesn't absolutely preclude the chance of a sudden break, but it certainly relegates it to the domain of extreme long shots.

If you feel strongly enough that the threat is so great that we need to take action now, feel free to do so.  All of the source code is publicly available.  Design and implement something.  Test it out, prove to the world that it works and is safe.  Convince everyone that the risk of changing the system is small enough that it outweighs their estimate of the risk of a catastrophic break.  No one will stop you.  Plenty of us will even help you with design and implementation.

Just don't expect to make any friends by telling people that they must do your work for you.

However, I have to agree with hashman that it is essentially the end of any trust in bitcoin as there will be many unprotected addresses, especially a lot of the early coinbase tx that will never be protected by anything added to the protocol later.

Dormant keys are protected by dormancy.  Unless in this hypothetical world SHA-256 is broken at the same time as ECDSA.

[1714141721]

1714141721

[1714141721]

1714141721

[1714141721]

1714141721

[1714141721]

1714141721

[piotr_n]

If you feel strongly enough that the threat is so great that we need to take action now, feel free to do so.  

I think you miss the point, that I don't consider you as my ally in this war.

I can take the action in changing the protocol, but nobody is going to use my code, so it won't work.
The only reasonable action I could take facing this threat is converting all my bitcoin savings to another asset.
Which I partially did, but I would still like to help bitcoin in resisting a potential NSA backdoor, or whoever else could have put such a thing in there.
There was this topic on the forum where we were trying to figure out how they chose the G point for the Kobus curve.
And exactly as I had predicted: they did not tell us - it's just a one big mastery how they picked the "random" point.
And that is why I trust more in RSA/DSA - because there is no a mysterious "random" point.

[kjj]

If you feel strongly enough that the threat is so great that we need to take action now, feel free to do so.  

I think you miss the point, that I don't consider you as my ally in this war.

I can take the action in changing the protocol, but nobody is going to use my code, so it won't work.

Ally or not, I told you exactly what you need to do.

This change has some risk associated with it.  Not doing the change also has a risk associated with it.  Everyone judges these risks on their own.  If you want to change minds, you'll need to use a combination of reducing the perception of risk on one side and increasing the perception of risk on the other.

The view of cryptography that I've outlined is, more or less, the view held by most people that actually work on and with cryptography.  You are unlikely to increase the perception of risk by repeating the well known statement that a sudden break is technically possible.

Your best bet is to develop a working implementation of the change, test the hell out of it, and convince people that the risk of accepting the change is very low.  These are things that you can do yourself, hire out, or attempt to crowdsource along with others that share your view.

The only reasonable action I could take facing this threat is converting all my bitcoin savings to another asset.
Which I partially did, but I would still like to help bitcoin in resisting a potential NSA backdoor, or whoever else could have put such a thing in there.
There was this topic on the forum where we were trying to figure out how they chose the G point for the Kobus curve.
And exactly as I had predicted: they did not tell us - it's just a one big mastery how they picked the "random" point.
And that is why I trust more in RSA/DSA - because there is no a mysterious "random" point.

Any G is as good as any other.  Outside of curiosity and historic interest, no one cares much why we use the G we use.  If you are looking for a project to hone your c++ and/or bitcoin skills in preparation for the other patch, changing to a different G is relatively easy.  I think you only need to add a new address type, a new flag for WIF, and a new SIGHASH flag value.

[gmaxwell]

Any G is as good as any other.  Outside of curiosity and historic interest, no one cares much why we use the G we use.  If you are looking for a project to hone your c++ and/or bitcoin skills in preparation for the other patch, changing to a different G is relatively easy.  I think you only need to add a new address type, a new flag for WIF, and a new SIGHASH flag value.

We do really believe that any G is equally good.  Sort of the sillyness I argued with nothing up my sleeve points in stupid protocols which really aren't nothing up my sleeve, there is nothing evil you can do with G selection.  In particular, the reason for this is because the group has the additive homomorphism, so if there were some magic G that let you solve the DLP you could reproject any pubkey onto a new G and then solve the DLP on that pubkey relative to the new G and thereby solve the original problem as well.

It's nice to have nothing to say at all, even in bad protocols though, so I tried to get DJB to change his definition of fully rigid to also encourage better G selection procedures, but I failed to convince him.  Our curve meets the definition of full-rigid as held by the currently strongest standards for EC by respected cryptographers today.

I gave an argument in SAGE:

F = FiniteField (0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F)
C = EllipticCurve ([F (0), F (7)])
F2 = FiniteField(C.order())

#We anticipate someone to use 1/sqrt(2) to make a nothing up their sleeve point in this system:
Point_1 = C.lift_x(0x6A09E667F3BCC908B)
#(122254265231296204939 : 10348448370814257613525050294440956391133934006892469524333988955631776211309 : 1)

#Now we pick a random value to be the discrete log of our point.
DLP1 = 31337
#and set the generator of our new public cryptosystem:
G = Point_1 * int( 1 / F2(DLP1))
# (3289106939212447273101810288144217892737559734143795594097718377788892356978 : 93681368535132531056006250228841417954446824336668031982795047251196201715915 : 1)

#Now, observe:

G * DLP1 == Point_1
#True

# DLP1 is now the discrete log wrt G of our "nothing up our sleeve point".


To which he replied "Protocols such as signatures are designed to be secure no matter what the generator is.", which is absolutely true.

[Etlase2]

Old systems were broken suddenly because they sucked.  No one knew they sucked, because no one was looking at them.  Anyone can design a system that they can't break.  Our systems don't suck any more.  They aren't built in the dark.  Everyone looks at them.  In fact, a decent fraction of the intellectual power of the human race is devoted to examining cryptosystems.  The really bad ideas are gone now.

Granted, but this does not address the fact that most public key cryptography, and certainly that used in bitcoin, is based on an unproven premise of seemingly difficult problems far, far below the class of P=NP.

Dormant keys are protected by dormancy.  Unless in this hypothetical world SHA-256 is broken at the same time as ECDSA.

Well, RIPEMD-160 anyway. And I'm not an expert on the bitcoin scripting system, but if it is possible to preimage attack RIPEMD-160, the scripting system could make it fairly easy to avoid any need to break ECDSA. Of course, preimage attacks are much more difficult than hash collisions. However, early versions of bitcoin did not pay to a script hash, only a pubkey: http://blockexplorer.com/address/12c6DSiU4Rq3P4ZxziKxzrL5LmMBrzjrJX, so dormancy is no protection for those early coins in the face of an attack on ECDSA as mentioned in the OP.

[gmaxwell]

so dormancy is no protection for those early coins in the face of an attack on ECDSA as mentioned in the OP.

I've referred to these as canary coins.