Topic: The use of Guy Fawkes Signature in case of ECDSA zero-day exploits (Read 6650 times)

I've referred to these as canary coins.

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.


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.

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.

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.


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.

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.

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.


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

You are so right.
But if you have been waiting for your idea to go through since 2011, how much longer do you plan to wait, if you don't mind me asking, before concluding that it's already too long?
You obviously understand the seriousness of a potential problem and all the cons of rushing the solution - that's the approach we need.
Therefore you should be able to judge a good balance between the two things. And where do you see the balance being finally implemented? I hope not in 2020

It technically takes a majority, but a slim majority is unsafe because the length of a reorg that results from it is unbounded. E.g. if it's 50.001%  they split and maybe the reorg is a day long when the forkers decisively overtake.

We actually can make sure a super-majority of whatever level we think is needed exists in a soft-fork.  The way this works miners indicate their intention to support a particular softfork in their coinbase, and then we can have the softfork activate when, say, 90% of the last 1000 blocks have the indication that they're on-board. Then they'll all switch at once and the change is automatically decisive. The downside is that miners can drag their heels and delay the change.

An example of this is described in BIP 34.

The faux-urgency of speculative ideas is not helpful. Rushing in changes "ASAP" is a danger to the network with probabilities much higher that spontaneous EC weakness.  I've proposed having an alternative non-hidden-subgroup-problem signature algorithm at least as far back as early 2011, and written out some more concrete descriptions, though I'm a bit disinclined to post an implementation where some crap altcoin will just rip it off and claim an advantage over Bitcoin. But, regardless, it's not something we can or should rush into.

In terms of deployment, miners who can't update rapidly to softfork enforcing software could start mining no transactions while they update to reduce their exposure. Even if a full implementation is complicated, a simple one that reduces orphaning is likely not so hard.

I have doubts about the viability of non-essential changes in the future, with sadness and regret. The addition of P2SH happened several years ago, and today many popular wallet implementations— including ones that didn't exist when P2SH was created— do not implement it, so people can still not even start using multikey security to secure their wallets because people could not send them coin (Android wallet, Multibit, Blockchain.info, and Armory are the most notable). The non-deployment of P2SH also inhibits the deployment of a new checksig, because even if you start using a wallet secured by an improved signature scheme the whole world needs to be updated before they can send to you... p2sh was intended to resolve this chicken and egg problem with deploying new wallet security measures, by taking the sender out of the loop when they don't need to be in the loop.

OK, thanks for explaining.
But a super-majority is a relative term.
What we are talking about here is in fact any majority, meaning: more than 50%.

If we want to have a super-majority around this, in a close future, you guys better put these new opcodes into the reference client ASAP, and I will follow you adding them to mine, because that would be one of a few changes in the chain protocol that I am supporting today with my all hands.

I am sure the members of the core dev team also own lots of bitcoins and I hope they don't all have the "sudden catastrophic break in ECDSA is pretty much unimaginable" approach.
If not for me, do it for your own interest. Please.

Thats part of the definition of a soft fork. If there is a super-majority of miners enforcing the rule the majority will pull over the old mining nodes, they'll lose some blocks here and there but the consensus will be preserved.

But it will still cause a hard fork, if you try to spend it with a wrong signature, while having some old mining nodes in the network, won't it?

You can. You simply add them.  You write a transaction which looks like an {anyone can spend} to old nodes, but looks like {$XYZ required to spend}. Old nodes are happy, and the transactions are safe to use as soon as a supermajority of miners imposes the new rule.

Can you?
Maybe I miss something, but there is no opcode to do RSA or DSA verify - so how can you add it without a hard fork?

No. You can change pretty much anything in the protocol with soft-fork. Adding new DSAs and Hash algorithms are certainly soft-forks. Imagine to have a script protected by 3 different DSAs and 5 Hash algorithms.....

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 is definitely value in additional protection. 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.

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.

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

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.  What really happens is that they weaken gradually over many years.

Should such a thing happen, the method described in the first post appears, at first look, to allow migration, and the world would implement it or something like it very rapidly.

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.

unless we manage to diversify between different digital signature algos; besides ECDSA, there is at least the old fashion RSA and the DSA.

it is not even that one could diversify his savings between different algos.
giving the scripting language that is already in the protocol, one could protect an unspent output using several different signing algos at the same time, one after another.
and it is very unlikely that all of them would get broken.

but this requires a hard fork and having in mind that the satoshi client has a mining monopoly these days, we won't introduce a new signing method without an active support from the dev team.

First thought:  broken ECDSA would spell the end of BTC despite the very cute hidden public key.  Funds are likely to migrate to a secure DSA. 

Second thought:  did you just find a way to make a secure DSA based only on hash functions and a block chain?

agree on it being better than nothing.

the best countermeasure immediately available is spreading coins across addresses, making sure to never have more than a few 1000 USD worth in any one address.