Topic: Algorithms used in Bitcoin are expected to be strong until at least 2030 (Read 433 times)

You are forgetting that what you pay as transaction fee is actually the money you pay for the scarce space on the blockchain which means it does not matter at all whether your coins were created 10 seconds ago or 10 years ago if the portion of the block space you want to "purchase" is the same. Not to mention that fees are not enforced at protocol level, it is only policy rules (miners preference).

As for altcoins, they don't cost much anyway so their fees are super cheap which means there is no reason to bother with any changes like that

Miners won't like it. Transactions incur costs, often implicit that falls on the community as a whole, for eg. those who run nodes, those who mines the coin. The former already doesn't receive monetary compensation while the latter has always been receiving it in the form of fees. The cost of moving your coins shouldn't be discounted just because you want to encourage people to move to a new address format. The onus should always be on the user; if you don't want your funds to be lost, move it. We have no obligations whatsoever to encourage you to do so because it serves no benefits for the rest of us.

Also, replay protection is still needed regardless.
That encourages spam. It is unnecessary to implement, adding in the complexity and lowering fees for miners significantly. Having large UTXOs are already discouraged, by having fees proportional to the size. That is not ideal for the network and you'll face significant bottleneck for the rest.

The privacy preserving feature is something to be thought of and worked out when the time comes.

More likely than not, we might have something truly better than Bitcoin when ECDSA finally gets cracked, which is a long time from now.

I'm really doubtful regarding this. Computer and IT progress is slowing down and quantum computers seem to be too far away atm. Honestly, I suspect Bitcoin will be safe also beyond 2030 even with currently used algos. I don't think devs are doing something specifically against this issue. If aint broken, don't try to fix it they say. 

I think I have asked all sort of dumb questions about the difficulty and it’s relationship with the rewards, security of the network, or even complexity getting more or less. I know few questions were out of the line but I think I am trying to learn a subject which is not really my expertise or close field. Though I got good replies from the experts I am still not understanding half of the terminology and could only connect the dots.

Basically I just hope that security of the bitcoin lyes within our hands no matter how advance the technology becomes. That is the only way to keep up with the Bitcoin as is in the long term and until we mine the last bitcoin really.

Long? Maybe. Expensive? It depends, it doesn't have to be.

For example, it is quite easy to implement one-time-fee-discount. I wonder why altcoins that forked from BTC didn't do that in the first place, instead of replay protection. For example, it is possible to create a rule, where you can move some coin for free, if that coin was included before block number X. Then, transition from some old to new address type could be free, but only once, and at the same time, people won't move back from new to old address type, because then their transaction will be included in some later block, and they will pay a regular price for that.

Also, I am not sure if the current fee model will still be present in the future, when ECDSA will be broken. More and more often, there are problems with UTXO set size. That means, some future fee model could be based on how many UTXOs you consume or create. And in that case, a single transaction that will sweep a lot of coins into some single new address, could be cheaper, or even free, if the number of UTXOs will be a bottleneck for pruned nodes.

Another thing is that even if you sweep everything to a single address, it doesn't mean everything would be traced into a single owner. Taproot already can support N-of-N multisig, hidden behind a single key, I won't be surprised if some new address type for "hardened secp256k1" would also contain some privacy-preserving features, and then N people could join forces to move their on-chain coins cheaper (even if developers won't add any discount to encourage true owners to protect their coins). Also, maybe they will land even in LN directly, or some another subnetwork. It is hard to predict, how the whole situation will change, by the time we will get there.

Let inventing such thing to cryptography expert. Adobe (which is big company) tried building their own cryptography, but ended in huge failure[1].


That's probably only true for company and individual with complex wallet setup. Most people just need to wait their wallet software/hardware to support new address format, then they could just send their coin. I would worry more about security risk when people creating new wallet and move their coin.

[1] https://nakedsecurity.sophos.com/2013/11/04/anatomy-of-a-password-disaster-adobes-giant-sized-cryptographic-blunder/

There are millions active addresses. The process of moving coins from them would be very long and very expensive.

As global hashrate goes up, then we find blocks more quickly. As we find blocks more quickly, the difficulty adjusts every 2016 blocks in order to maintain the average block time at 10 minutes. It does this by reducing the target number miners are trying to find. By making the target smaller, we need more hashes in order to find a number which meets that target, hence it is more difficult.

Sometimes the hashrate falls and so the difficulty adjusts downwards (making the target larger), but it's been pretty close to an exponential trend upward for many years. You can see all difficulty adjustments here: https://btc.com/stats/diff

This, however, is all to do with mining blocks, which uses hash functions. This is completely separate to the security of private keys, which uses elliptic curve mathematics. The security of your private keys will be 128 bits regardless of where the network as a whole has 100 hashes per second or 100 trillion hashes per second.

Nope, indirectly associated. I'm assuming a theory whereby circulation remains constant and all the other factors being invariable, which is often not what happens in real life. Bitcoin gets deflationary, fees increases, etc; Satoshi's rationale on reward halving may very well hold true assuming improved efficiency in mining and a compensation in fees. Reward halving doesn't encourage more miners to join, the fee compensation and the other monetary factors (real cost - reward, etc) are what makes it attractive.

Regardless, discussion about this would be diverging from the issues that is being discussed here. Would be more of an economics question rather than technical.

That's actually not good at all, it means we are looking at a significantly flattened (as in the curves are not as extreme) Bell curve for Bitcoin global hashrate between 2009 and 2140. I guess this is why people have been saying that more incentives for Bitcoin miners are required to guarantee that the hashrate stays more or less stable once block rewards in BTC denominations start to become scarce.

Network difficulty is not directly associated with reward halving, in fact the hashrate should decrease in theory. Increasing the difficulty has nothing to do with what we are talking about here, unless you're talking about a pre-image attack. For which, a pre-image attack on SHA256 would go beyond speedups on hashrates which would only concern the first pre-image attack. Collisions and second pre-image attack on SHA256 are by far more potent with regards to the security of Bitcoin.

Damn seriously? I thought network difficulty has got something to do with the complexity over the period of time? I mean as we keep saying that for every halving that occurs, the reward also decreases, while each time network difficulty is rising too. Just for the info, in what relation are we saying that network difficulty is rising.

Has it got no relationship with the maths/equation solving mechanism? I mean if it is getting difficult then it is getting difficult to solve right?

Yeah, the Enigma was something crazy for sure. Turing exactly knew what he was doing, I just hope we do not have another Turing solving the same. Lolz

You can try to explore that, by using some totally broken elliptic curve (for example the one you can find in my avatar), and then try to make some "hardened" version. Or, you can use any curve with more bits, if 7-bit curve is too small to figure it out. You can add more and more bits, until you will reach sufficient space to be unable to use brute force, then you can try some attacks, and then hardening.

I think it is very similar case, as with hash functions, like SHA-1: you could replace it with something bigger, if 160 bits are not enough, or you can try to harden those 160 bits alone, like it was in SHA-1, based on the attack. For 160-bit hash, the attack on SHA-1 requires around 2^64 operations, so to test something similar for elliptic curves, you can try using some 25-bit curve, and assume there is some attack that allows reaching some private key after 2^10 operations. And then, you can try hardening your elliptic curve, and see, what options are available.

Of course. You can only guess and assume. For example, you can split some space containing around 2^25 points into sub-spaces with around 2^10 points each, and then assume, that the attacker can somehow figure it out, which sub-space is taken by a given public key. And then, you can prepare your counter-attack, based on that. In general, your protection will reflect your ability to attack, because it will work only for your scenario, nothing else. If some attacker could make a rainbow table instead, and break any 25-bit key in O(1) time, then your protection will obviously collapse, exactly as if someone could mount some preimage attack on SHA-1, then even hardened version may be vulnerable.

So, to sum up: if you want to know, what is possible, and what is not, then write some code, explore some simplified cases, and then you will learn more about it.

If ECDSA is broken and it is possible to recover the private key from the public key, then even if we depreciate ECDSA signatures then there is nothing stopping an attacker still recovering the private key and also making a transaction on the new algorithm and stealing your coins. As discussed above, the only way around this would be to require a zero knowledge proof of some other piece of information such as the parent chain code or the seed phrase which derived that private key, but that would only be possible for addresses which were part of an HD wallet.

Rather, we would need to have a quantum resistant address type well in advance of ECDSA being broken, everyone would have to generate new quantum resistant addresses from new private keys, and then move their coins to these addresses prior to them becoming vulnerable.

Interesting to see what that would look like though. ECDSA in bitcoin hasn't been exploited yet so it's not possible to pinpoint exactly the weak spots, but I'd assume that we'd have to break ECDSA public key recovery in the process - as in, you could sign the transaction using XYZ quantum-safe signatures, and then sign that with the legacy ECDSA signatures and broadcast that. The transaction can still be verified as correct by everyone, but you can no longer get the public key back, like Schnorr signatures.

I'm pretty sure that's what Satoshi was saying in that quote - the software would automatically send all your money to the new address type we end up with. As ranochigo points out above, I don't think it is possible to leave coins on current addresses but transition to some form of "hardened ECDSA".

That's going to have to involve sending your coins to a completely different set of HDKeys because if the curve is also broken in addition to ECDSA, then just signing all local transactions with the new signature algorithm won't be enough. Most people don't have local unsigned transactions anyway, just old coins.


There's no reason to agree to such a thing anyway - We are not Tether or Bitcoin SV.

A relevant quote:


Obviously it won't quite be as simple as everyone automatically upgrading when they run the new version of Bitcoin Core for the first time, given the number of different wallets in use these days, but the principle still stands.

Absolutely, but I will continue to argue it is preferable for some lost coins to be stolen and we all take a short term hit on the price than it would be to compromise one of the core principles of bitcoin by unilaterally deciding to freeze or seize some coins.

This is conjecture, not proven. But even if the total number of coins at risk does add up to several million, I maintain my stance above.

Most of which are lost, because people couldn't be bothered to have a backup for them. Satoshi is known to have a million Bitcoins at least, and there is probably more than that in terms of non-Satoshi but lost coins. In addition, there are also coins in exposed P2PKH addresses. These could add up to a few millions when the time comes. Of course, these are just vague estimations but that is more than likely to be the case.

There are going to be coins robbed, no doubt. However, I wouldn't take it for granted there will be millions. Sure, there are millions in P2PK, but perhaps they get spent until then; especially after the cryptographic community accepts some quantum safe alternative.

I'm genuinely curious to which math you're referring to. Those I know, which are discrete math and cryptographic-inclusive math, are certainly not pure and simple! 

By 2140? Lol, it has nothing to do with "network complexity" whatever that means.

Simple and pure mathematics is what keeps the coins safe, in order to make it harder for quantum computers we just need more complex math/equations.

Enigma in WW2, was the ultimate crypto/math problem, but the first computer invented managed to break the encryption, now it's the other way around, we need to invent an equation so the new computer generation can't break it.

Satoshi just chose one of the strongest curves at that time, even he knew 20 years later people will have to change the key to their safe.😉

First I thought it was some sort of breakthrough that they are actually planning. Imagine reading this news itself SEC and CBDC would have been so happy since after this they might have thought they would get a chance to spread negativity about the Bitcoin and thus publish the FedNow system more promptly.

Good to know (after reading rest discussion) it’s not really possible to break the code until it really happens. It also made me think that Satoshi did not make it so easy as his plan is for hundreds of years until 2140 by when the last Bitcoin would be mined.

It’s seems it will get more stronger with the time as the complexity of network keeps increasing.

Same as the rest of the community, I believe that there will be more versions of Bitcoin, ones with the old P2PK being burned and the ones that are not. I believe that there are merits to both sides of the camp, but I personally stand on burning them. I can understand the dilemma behind this and what your POV is. It'll be quite interesting to how it pans out, pros and cons for both directions.

By the time ECDSA actually gets broken, there might be more than a few million Bitcoins that are vulnerable still (forgotten or lost used P2PKH, just normal P2PK, etc) . A sufficiently long time for transition would be required, though arguably you're right in a sense that it does rob people of what is rightfully theirs. In the worst case scenario, an adversary gets access to the majority of the Bitcoins and wreck havoc in the markets. While in the best case, they get access to only around 1-2 million, ie. 5% of total possible circulation, not accounting for burned ones.

Regardless, we had this conversation quite a while back: https://bitcointalksearch.org/topic/m.56971465. Recalled it from the top of my head, I guess our position on this issue hasn't changed very much throughout the years.

Even more likely, then, that we will proceed with the "do nothing" option, since that is what we will default to if we cannot reach some sort of consensus on what should happen to these vulnerable coins. And as I've argued previously, this is definitely the preferred option over allowing a small group of users to unilaterally decide that other people's coins should be locked, burned, or redistributed.

I've spoken about this before as well, and while it seems appealing, it is far from perfect. It provides no protection for any keys which are not part of an HD wallet (which likely includes all P2PK addresses as well as many regular P2PKH/P2SH/P2WPKH addresses), and by locking all such addresses pending a proof which cannot be provided, you will undeniably be depriving some users of their coins against their will, which is unforgivable as far as I am concerned.

Or simply just attempt to reorg out any block which claims a sizeable reward for another miner.

But don't forget the competition still exist between miner/pool. There's always possibility miner/pool would do something to increase their chance to claim coin from attacker and other miner/pool, such as create block which only contain two TX, coinbase and TX which send old coin to address by owned miner/pool.

Essentially. That is contingent on the fact with the community as a collective being agreeable with any of the proposed option. More likely than not, we will see people splitting into different camps just with the block size debates. Even more so given how it concerns the economics of the network and a core feature. Hard to tell what it would be without it actually happening.

It depends on the security issue. I would assume something that is especially important as Bitcoin wouldn't be able to be replaced so easily. The algorithm that hardened SHA1 uses doesn't defend against all collisions and any sign of weakness of an algorithm would be a good reason for Bitcoin to move onto another completely. There are no redundancies to the network, especially for something worth more than 500 billion USD.

Attacks are known and they have been proven with the caveat of having a sufficiently powerful computer. None of the asymmetric algorithms that we commonly use right now are safe, nor can they be hardened because they operate on the basis of hardness of factorization. The only fix would be a shift to a quantum resistant algorithm.

It was discussed in other topics, but in general, when it comes to ECDSA, you don't have that many options:
1. You can just introduce new address type, and do nothing with old addresses. This is what would probably happen, because it is also compatible with all other options.
2. You can burn old coins after some time. To make it compatible, you can use "do nothing" option, and make some huge pool for cracking and burning coins, that will be stronger than any single attacker.
3. You can redistribute old coins into miners. In case of any successful attack, miners will probably be powerful enough to take coins from any attackers, it is a similar case as with SHA-1 puzzle, where in practice only miners can safely claim those rewards.

Because it is hard to know in advance, what would happen, I guess people will keep status quo, as long as they can, so there will be option number one, and then if any solution will be needed, it will be just compatible with "do nothing" model.

Also note that speculating about the solutions now, can easily lead to totally wrong results. Would you expect things like "hardened SHA-1", before it was broken? Not really, people thought it will be replaced with a different hash function. But that was not the case, for example Git still uses SHA-1, instead of switching to SHA-2 or anything else. The world is simply unupgradeable, and relies on soft-forks everywhere, if something is "legacy". So, in general, I think no matter what will be broken, the actual "fix" will handle only this particular attack, nothing more, nothing less.

If SHA-1 was turned into "hardened SHA-1", then I expect secp256k1 could be also replaced with "hardened secp256k1". Even if private keys will be reached by the attackers, there are still many options, like "a proof that some key is a part of some HD wallet". The same with signatures: if they will be broken, then you can force using deterministic ones. The fix will be highly dependent on the attack, for that reason we don't know right now, how exactly it will be fixed (because today we don't know how the attack would look like).

The closest thing that would be feasibly broken would be ECDSA, which is pretty impactful since it results in any ECDSA private key to be feasibly obtained from it's corresponding public key by the use of Shor's algorithm. SHA256, or other symmetric crypto are not vulnerable to this and are not affected by Shor's algorithm, and Grover's algorithm doesn't provide for a sufficiently high speedup.

Collision and pre-image resistance for SHA256 will be weakened gradually, but I have my doubts that they would happen overnight or within a decade.

Transition for ECDSA is actually quite difficult. You face the conundrum of securing the older Bitcoin addresses, where they are vulnerable with P2PK or even those with the public key exposed. Quantum resistant algorithms are in the works now, but even if it broken the economics of it wouldn't make Bitcoin any more attractive than government secrets.

If ECDSA will be broken (and only that), then we can just create a new address type, and move all coins there. In case of Taproot, all that is needed, is probably just disabling spend-by-key.

For SHA-256, the situation is more difficult, but in that case, we will be alerted in advance. If you ever see block headers with 128 leading zero bits for SHA-256, that would mean reaching the collision level, and transitioning to something else. I wonder if that process will start even faster, when chainwork will reach 2^128, just to be 100% sure.

Protecting SHA-256 is harder, but still possible. It requires rehashing everything with some new algorithm, maybe even in some backward-compatible way, where you could have some 512-bit hash, with the first 256-bits being always identical to SHA-256, and the next 256-bits being generated by some other hash function. I also expect the same kind of stuff that happened with SHA-1: you have the real SHA-1, and some hardened version, that can protect you just from some discovered attacks, and nothing else.

Alright, I am clear on the security aspect. It is sort of how products have a best before date when they should be consumed, but taking it after then is not immediately hazardous, but we cannot imagine that FUD about bitcoin being unsafe will not becomes very popular very quickly if there is any suggestion that it is not as safe as it used to be.

Can anyone explain the final bit about transitioning to a new algorithm not being too difficult?

True, some of the factoids^[1] contain witty and educative messages.

[1] https://bitcointalk.org/adrotate.php?adinfo

- Jay -

SEC estimated these years based on a simple extrapolation and haven't updated the document ever since
This is why the table 3 in Standard for Efficient Cryptography v2 states that ECC with 128-bit security level (256-bit key size) protects until year 2040 (2030 is for ECC-224).
https://www.secg.org/sec1-v2.pdf

I believe the number is also based on MIPS years, that is the estimated amount of work performed in one year by a computer operating at the rate of one million operations per second. The values in SEC.1 v2 are from 2009.

I believe the threat they are referring to is about Quantum computers, it will surely not be a threat to BTC's security in 2030, which is just 7 years away, it will take a very long time from now before quantum computers become a problem or a threat that can solve ECDSA. BTC developers don't have to do anything now because there is no existing threat, but as quantum computers develop, the network will also develop and work on moving to an algorithm that is resistant to the threat of quantum computers.

The answer to your question lies in the text you quoted. The algorithms are good enough 'at least' until 2030. That does not mean that they will instantly be insecure from 2030.

'Definitely secure before 2030' ⇏ 'Definitely insecure after 2030'
But: 'Definitely secure before 2030' ⇒ 'No definitive judgement starting from 2030'

Basically, the authors don't yet want to definitively state whether they think Bitcoin's crypto algorithms will still be secure enough in the year 2030. Nothing more.

I am not an expert but i have read many times that when the quantum computer will be available like current computing power sources then people with bad mindset will try to break BTC encryption algorithms and which are easily breakable by such huge powering computers.

Maybe you might heard such topics here before. Because i came to know about Quantum computing's side effects on BTC here in this forum. I think developers will come up with something unquie and more secure then current encryption algorithms.

Few days ago when I was on this forum, I saw this:


You know that there is no forum ad again, but sometimes you can see meaningful information there to read and I saw it.

Is it true that cryptographic algorithm that bitcoin is using will likely no more be safe by 2030? What are bitcoin developers doing to make bitcoin safer?