Topic: Game theory involving Quantum Resistance protocol (Read 897 times)

Hi all guys and girls speaking in this exciting thread (finally someone speaking of QC!?!)

I will not actively step in to say more of what has been said but I would like to point you to https://faqq.info/

There you can find the Frequently Asked Quantum Questions, very informative

And last but not least an XMSS signature based cryptocurrency & blockchain exists and its running smoothly on mainnet for over 1 year now: www.theqrl.org

Cheers and keep this great discussion up, I will enjoy keeping read it. 

If Bitcoin wants to be digital gold, you can't be having arbitrary countdowns in which you are going to lose all of your affected funds unless you move them from A to B. That is what has been my point for a while.

However, what do you really and concisely propose? I have not seen convincing arguments, when it comes to avoiding the need for funds being moved in case of an exploit on the algorithm (QC attack or otherwise).

Perhaps it's something we can't avoid, and every generation or so, you will need to do this, at least once in your lifetime.
With gold, the analogy could be that you may need to reallocate all of your holdings... the place in which they are sitting isn't supposedly safe forever.

It is the true apples and oranges comparison, what you are doing. A digital asset, especially a cryptocurrency deposit is absolutely different artifact. I'm done rehashing the same argument over and over, it is the code, a constitutional right, for users not to be worried about developments and forks, their assets should be kept immune. period.

And it is not all about laziness (which is absolutely a right), people may be away for a long period of time from tech news, maybe they are paranoid about tracking/surveillance systems being watching them and trying to locate them, whales may feel uncomfortable with moving their strategic wallets, some may possibly lose their keys temporarily, others may have deposited their keys in a safe box to be handed to the heirs in a special occasion, ...

Plus, if missing a deadline should have a penalty it is not necessarily losing all funds. In my proposal users that you are calling them lazy have tp pay for it but in a reasonable way.

you are comparing apples and oranges!

your other arguments are like saying our browsers must not have stopped rejecting SHA1 SSL certificates because some people might be lazy in upgrading their certificate to a more secure hash algorithm even though there was a transition period given to everyone to move to new algorithms! instead they should have given the "lazy server" a workaround to push their SHA1 certificates as valid!!!

Firstly, it is a good compromise, not a bad one! Being rough and harsh against people because they have missed some deadline is neither a good practice nor a part of bitcoin culture.

Removing OP_CHECKSIGHASH is too harsh. Unlike what you say, people have no obligation to keep an eye on what pool operators and devs dictate. It is not part of the code, I've bought some coins as an eternally safe asset without signing any contract to be online or keeping an eye on anything. It is basic.

I think even talking about such a hypothetical fork hurts bitcoin and should be immediately stopped! No matter who first put it this way and in what condition such nonsense ideas have been formed in his mind (or probably he has been drunk or high?) but it is not what bitcoin is.
What if pools and wallet companies and devs decided (for the interests of their multi-billion business) to block terrorist wallets, e.g. because of US authorities threatening the whole community?  

if something were broken it must be removed right away. you can't compromise the entire multi billion dollar worth of system just because some people might be lazy!
when people enter bitcoin world the first thing they learn is that they are now responsible and in full control of their own money. that includes keeping an eye on development of bitcoin and changing directions if needed.

The protocol I suggested above, is safe and secure and a very good compromise saving everybody without taking rough measures against people who miss deadlines. You need to take another look at and sleep on it, imo.

I don't believe in antagonistic conflicts of interests between users but we all need to respect the code and destroying coins is not part of the code. I understand for exposed public keys there is no choice and should put the safety of the whole ecosystem first, but for unexposed ones, I see no justification for taking rough actions just because they are easier to implement.

you're missing the point. i've emphasized the relevant sentence in bold. we---the rest of the bitcoin economy---could theoretically pay for their carelessness. i find that unacceptable.

as a bitcoin holder, their interests are directly in conflict with mine. how do you plan to reconcile this? this network operates on the basis of economic rationality. you seem to expect us to embrace irrational behavior that threatens our financial interests. why?


what "deal"? what are you referring to as if some scripture exists re our duty of care obligations? at what point is putting the entire bitcoin economy's well being at stake not acceptable to you?

i don't believe duty of care implies the necessity to protect specifically irresponsible and unsafe behavior that can/will harm other people. it seems like you'd rather see bitcoin burned to the ground before budging on this. is that the case?

not sure, but maybe:

In the real world, trust works fine for many use-cases, it is one of them. It is the penalty a lazy or careless wallet owner or a paranoid one has to pay, her decision, not the community. We have already provided her with a free alternative approach (migrating to the new scheme) and she has refused or missed it and now she should pay costs to secure her funds but the good news is that she has not lost everything.

The way you formulate it is not fair  

The coins are not lost, they are deliberately destroyed by the majority (by a UASF for instance), it is not part of the deal and reminds me of Ethereum and its centralized ecosystem. Bitcoin is not about majorities neither whales nor celebrities, on the contrary, its strength is in the maximum protection of minorities.

there is a dilemma here. firstly, this scheme of yours involves too much trust---in miners to privately mine transactions without stealing and in p2pkh holders to properly secure their coins. they are theoretically a threat to us all.

secondly, bitcoin's economic design implies what satoshi said explicitly---"Lost coins only make everyone else's coins worth slightly more.  Think of it as a donation to everyone."

so it becomes a point of contention. whose interests are more important---
a. people who want to keep their outputs in vulnerable format for eternity (despite safe alternatives) and who will require trusted/centralized solutions to spend them, or
b. the rest of the bitcoin economy?

even if we table the discussion about needless complexity, bitcoin holders will not be interested in your way. they will prefer a predictable outcome that more reliably ensures that bitcoin's value remains intact.

Keeping bitcoin promise as far as it is possible and pushing to the limits, it is the point.
Disabling OP_CHECKSIG means destroying wallets that do not follow our orders, It wasn't part of the code, the contract bitcoin has "signed" with the user. You can't just show up with a new address scheme ordering people to migrate. They have a right not to follow, it is constitutional.

As of 2018 June 4, 19% of p2pkh addresses (4,204,148 of 22,275,753) holding 25% bitcoins (4,319,806 of 17,072,361) were revealing their public keys because of address-reuse.

Such addresses are in the most vulnerable state just like their p2pk counterparts and are indistinguishable from more secure p2pkh addresses with unexposed public keys. They should be blocked too but we want safer p2pkh addresses to be kept valid, burning such addresses by miners through an incentive mechanism is what I've recommended.

It can be a service with a very low fee, centralized and based on trust. The owners of abandoned, expired p2pkh give both their public and private keys to a trusted solo-miner/pool to include it directly in the blocks. lease note that mining is permissionless in bitcoin and there is always a possibility for paranoid minted owners of very fat wallets to lease power and mine their transactions privately.

Forcing people to move their funds and threatening to announce those funds void otherwise? Believe me it is a mess.


Disagree.
Storing state in a single thread of execution of a single script is required and it is nothing more than playing around with one or two booleans and I've explicitly described the rules. This is not dark magic.

What is the point of that? Instead of having two forks, why not just have the one fork have the deadline be farther away so that people have more time to migrate. The point is that during the migration period, ECDLP is still not broken yet.

What is the point of burning the coins? Why would anyone even want to reveal their pubkeys to a miner just to gain nothing? Only the miners benefit from that, it's completely pointless to anyone else. it's the equivalent of just having a fork that completely disallows OP_CHECKSIG.

I disagree. It isn't a mess until QCs actually show up. Migration to PQC is pretty straightforward and non-messy, just needs a lot of time and warning.

The two forks are just so much more complex than a single fork which disallows OP_CHECKSIG and OP_CHECKMULTISIG after a deadline. And I don't think they're any easier than they seem, consensus and the script interpreter and far more complicated than you think, especially with anything that requires storing state or remembering previously executed scripts.

Oh, thank you for being so specific, it is what I always expected from you.  

unlike what it looks like the strategy is not that complicated, it is about two deadlines instead of just one, this is it!

We need two deadlines because we should deal with three radically different cases:

Case #1: P2PK UTXOs (including multisigs); they are exposed to the first wave of commercially available QCs that are able to break ECDSA in feasible time.

Case #2: Compromised P2PKH and P2SH UTXO; they are compromised in the sense that their corresponding raw counterparts are leaked either because of address re-use or other reasons like transaction generation process, wallets being implemented with loose security considerations, ...

Case #3: Abandoned P2PKH and p2SH UTXos; they are wallets that do not follow the recommended practice of migrating to the new PQC scheme and are vulnerable to hijacking by scalable and commercialized QCs capable of breaking secp256k1 keys on the fly.  

In the big picture, each of the above cases is radically different and deserves special treatment. My proposed strategy covers this situation by 2 soft forks or a two-phase fork.

Fork #1: Implement a PQC scheme, set a deadline for P2PK and multisigs to migrate, announce them void thereafter (kick them out of the UTXO set practically)

Fork #2: Up to a deadline, simulate an advanced zero-cost QC attack by letting any miner who has access to the corresponding public key of the address is authorized to spend it into a null address deducting a fixed fee. After the deadline, we are back to the normal situation.


As of implementation considerations:

I understand the second fork is messy but we are dealing with a mess, aren't we? Noways to minimize the damage unless you get hands dirty, no choice. And yet it is not too much, implementing both forks is easier than what they look like in the first glance:

Fork #1: besides the PQC scheme, the script processing engine should fail OP_CHECKSIG after the deadline whenever an OP_HASH160 or OP_HASH256 is not executed freshly and followed by an OP_EQUALVERIFY. Script processing engine can take care of this by maintaining a flag that is set with OP_HASHxxx and reset after the execution of any OP_CODE other than OP_EQUALVERIFY while OP_CHECKSIG checks whether this is flag is set before doing anything, easy.

Fork #2: Before the second deadline OP_CHECKSIG  always pushes 1 (true) if a special flag is set. This flag is set if the transaction follows a defined format which guarantees that after deducting a predefined amount it is burning its (single) input to a specific (void) address. This behavior is reset to default after the deadline.

Interestingly, unlike what happens with your, rough approach, p2pkh legacy wallets that are not been moved for any reason are expendable for eternity as long as they are privately mined (not being relayed in the public network before being confirmed) in the presence of QC equipped thieves.  

There's no reason to take so many steps and add even more special cases to the scripting system. To allow P2PKH but not P2PK requires adding special cases to OP_CHECKSIG which then needs to inspect the script to check whether it was P2PKH. And then you aren't covering things like multisigs or any complex script that uses OP_CHECKSIG. What about if the P2PK was nested inside of P2SH (because that's allowed)? Or people using bare multisig? So now we need to have tons more logic to handle all the weird things people can do with scripts? That's completely unnecessary.

The simpler and easier, and just as safe solution is to soft fork in a hard deadline (that can be several years in the future) where OP_CHECKSIG and OP_CHECKMULTISIG both become immediate script failures thus outlawing ECDSA. People can move their coins to whatever PQC signature scheme is introduced up until that deadline, regardless of script type, and then after the deadline, any usage of OP_CHECKSIG and OP_CHECKMULTISIG is disallowed.

I don't see why it is necessary at all to roll out such a migration so slowly with different script types getting different treatment. And it really doesn't generalize at all.

there is zero evidence of that



and there is also zero evidence of that



and there is also zero evidence of any of that

in particular, all of the above would be crazy (assuming that satoshi is/was not crazy) if the intention was for Bitcoin to ever succeed. The uncertainty could potentially cause alot of chaos in the Bitcoin economy, it makes little sense to store up such a problem just so Bitcoin might one day catch on fire, for what reason? To enjoy watching it burn? (<--- rhetorical question, although I have this funny feeling some joker in the pack is going to try answering it anyway )

He can but he will not. We think that the early mined coins of Satoshi are created as a prize competition (Re: Maybe Satoshi created the greatest prize competition https://bitcointalksearch.org/topic/maybe-satoshi-created-the-greatest-prize-competition-5150688) and that Satoshi is waiting this coins to be moved. We also think that he will not respond when somebody moves the first coins but it will be a message to the Bitcoin community that the private keys are somehow on the blockchain. Satoshi could move the coins (2009/2010) to P2PKH addresses but did not.

assuming satoshi can still move their/his coins, this is a likely reason why it's not happening. Although we shouldn't discount the most conservative thing that all 2009 era mined BTC key holders could do; start by moving their BTC with the highest block number, and do it very very slowly. Satoshi could potentially do so too (we have zero clue what's going on with satoshi in so many ways), so assuming that chaos was not the intention, I expect that if those coins ever did move, that's what would happen; starting at block ~50,000, then working backwards from there.

In such a sequence of events, it could be interpreted as a signal that those early miners are losing confidence in the safety of ECDLP protected coins. Of course, those people may have other reasons to not publicly announce why they're moving to different keys (which are not necessarily anything to do with the safety of the public key cryptography), so you are indeed correct; the lack of information will cause uncertainty, and the uncertainty will rock the Bitcoin ecosystem.

I hope such people (whether satoshi or not, there are others) are reading some of these discussions (it would surely be prudent to do so). If so, I also hope they will consider a slow and orderly move to new key types, and act sooner rather than later.

Yes, it is. It is how we do our job in technology fields: We study trends and speculate developments then decide. We don't take fiction about a monster that suddenly shows up with super-power, as being serious.

It will be long enough: When a technology is in its infancy, i.e. it is not scalable, doubling the speed needs quadratic or higher costs, QC is in such a phase, it is definitively not scalable right now.
If a breakthrough happens in the future and scalable QC technology becomes available, it won't be commercialized for a long time because of governments and military and corporates who need it for their devious plans. It would be very unlikely to be used against the day to day bitcoin transactions. It is also worth mentioning that scalable technology needs time to mature. We are talking about a few years for the least, to be very paranoid.

You need a non-Interactive zero-knowledge proof protocol which is not a piece of cake, it is complicated and both time and space consuming. I don't think it will be ever used in a performance-hungry system like bitcoin. Forget about it.

Why should you show your trolling face once a week to me?  

For my line of research, the main challenge, regarding this issue, is a time&space efficient QC resistant signature algorithm which is an open problem for the whole cryptography community. Although I don't think it would be a wise decision for me to focus on such an algorithm, I wouldn't hesitate to take part and implement it in my proposal, at any point that we might have become close enough to a consensus about a superior algorithm.

@achow101,
Above thread, I've suggested a strategy for different stages of the QC evolution it includes measures and actions to be taken:

1- Implement a new QC resistant signature and install/promote it in bitcoin.

2- starting from the p2pk group of the UTXOs, because they are the most vulnerable segment. It is mandatory for this group to migrate, If they wouldn't, their coins will be announced void after a deadline. More propaganda for convincing p2pkh owners to take actions, no obligations tho.

3- When we are closer to the doomsday, we give anybody with access to the public key behind a hashed address, a right to claim a very tiny and fixed portion of the UTXO just like a txn fee, destroying the remainder. Practically it may be just miners who take advantage of this feature, we don't care.

4- After the QC apocalyptus, we will have a percentage of untouched p2pkh addresses that their public keys are not exposed to the public. For the owners of such UTXOs, there will be still a chance to privately mine their transactions or buying such a service from a trusted pool or mining farm.

The only argument against this strategy, from your side, would be the chaos thing:
While I agree there will be some turbulence but I think it is too much to consider it as chaos. Prices will fluctuate but game theory will work eventually and there will be no catastrophe.

Back to taproot proposal, how do you put it in the context of such a strategy? I'm assuring you right here, right now: this is a must-go strategy.