[ShowerThoughts] There will come a day when computing is cheap enough that all the lost bitcoin will be found.
Just like most brainwallets have already been brute forced, I could foresee the day when ECDSA could be brute-forced at some marginal profitability. May be decades away. By then most of the UTXOs will be moved to a new signature algorithm, and the only ones left will be all the "lost coins" of people who forgot their seed or lost their harddrive. In this imaginary future, bitcoin mining will be brute-forcing old / legacy ECDSA UTXOs. Take a look at the RSA Challenge, they have been ticking away at that over the last few decades quite nicely.
And that is just for fame and $50k or so of prizes. The cash "prize" for ECSDA is much higher. I'd be amazed if ECDSA is still unfactorable in 80 years. Especially using made-to-order hardware. Before the maximalists bury me, I'm anticipating innovation in methodologies, not Moore's Law. Though there may be raw tech in the next century as well. Here's a proof-of-concept at defeating RSA 2048 in trivial time Remember... the three bodies problem was considered unsolvable... till it wasn't.
I'm writing a series about blockchain tech and possible future security risks. This is the third part of the series introducing Quantum resistant blockchains.
Part 1 and part 2 will give you usefull basic blockchain knowledge that is not explained in this part. Part 1 here Part 2 here Quantum resistant blockchains explained. - How would quantum computers pose a threat to blockchain? - Expectations in the field of quantum computer development. - Quantum resistant blockchains - Why is it easier to change cryptography for centralized systems such as banks and websites than for blockchain? - Conclusion The fact that whatever is registered on a blockchain can’t be tampered with is one of the great reasons for the success of blockchain. Looking ahead, awareness is growing in the blockchain ecosystem that quantum computers might cause the need for some changes in the cryptography that is used by blockchains to prevent hackers from forging transactions. How would quantum computers pose a threat to blockchain? First, let’s get a misconception out of the way. When talking about the risk quantum computers could pose for blockchain, some people think about the risk of quantum computers out-hashing classical computers. This, however, is not expected to pose a real threat when the time comes. This paper explains why: https://arxiv.org/pdf/1710.10377.pdf "In this section, we investigate the advantage a quantum computer would have in performing the hashcash PoW used by Bitcoin. Our findings can be summarized as follows: Using Grover search, a quantum computer can perform the hashcash PoW by performing quadratically fewer hashes than is needed by a classical computer. However, the extreme speed of current specialized ASIC hardware for performing the hashcash PoW, coupled with much slower projected gate speeds for current quantum architectures, essentially negates this quadratic speedup, at the current difficulty level, giving quantum computers no advantage. Future improvements to quantum technology allowing gate speeds up to 100GHz could allow quantum computers to solve the PoW about 100 times faster than current technology. However, such a development is unlikely in the next decade, at which point classical hardware may be much faster, and quantum technology might be so widespread that no single quantum enabled agent could dominate the PoW problem." The real point of vulnerability is this: attacks on signatures wherein the private key is derived from the public key. That means that if someone has your public key, they can also calculate your private key, which is unthinkable using even today’s most powerful classical computers. So in the days of quantum computers, the public-private keypair will be the weak link. Quantum computers have the potential to perform specific kinds of calculations significantly faster than any normal computer. Besides that, quantum computers can run algorithms that take fewer steps to get to an outcome, taking advantage of quantum phenomena like quantum entanglement and quantum superposition. So quantum computers can run these certain algorithms that could be used to make calculations that can crack cryptography used today. https://en.wikipedia.org/wiki/Elliptic-curve_cryptography#Quantum_computing_attacks and https://eprint.iacr.org/2017/598.pdf Most blockchains use Elliptic Curve Digital Signature Algorithm (ECDSA) cryptography. Using a quantum computer, Shor's algorithm can be used to break ECDSA. (See for reference: https://arxiv.org/abs/quant-ph/0301141 and pdf: https://arxiv.org/pdf/quant-ph/0301141.pdf ) Meaning: they can derive the private key from the public key. So if they got your public key (and a quantum computer), then they got your private key and they can create a transaction and empty your wallet. RSA has the same vulnerability while RSA will need a stronger quantum computer to be broken than ECDSA. At this point in time, it is already possible to run Shor’s algorithm on a quantum computer. However, the amount of qubits available right now makes its application limited. But it has been proven to work, we have exited the era of pure theory and entered the era of practical applications:
2001: First execution of Shor's algorithm at IBM's Almaden Research Center and Stanford University. The paper here: (Experimental realization of Shor's quantum factoring algorithm using nuclear magnetic resonance Lieven M. K. Vandersypen, https://arxiv.org/abs/quant-ph/0112176 )
So far Shor's algorithm has the most potential, but new algorithms might appear which are more efficient. Algorithms are another area of development that makes progress and pushes quantum computer progress forward. A new algorithm called Variational Quantum Factoring is being developed and it looks quite promising. " The advantage of this new approach is that it is much less sensitive to error, does not require massive error correction, and consumes far fewer resources than would be needed with Shor’s algorithm. As such, it may be more amenable for use with the current NISQ (Noisy Intermediate Scale Quantum) computers that will be available in the near and medium term." https://quantumcomputingreport.com/news/zapata-develops-potential-alternative-to-shors-factoring-algorithm-for-nisq-quantum-computers/ It is however still in development, and only works for 18 binary bits at the time of this writing, but it shows new developments that could mean that, rather than a speedup in quantum computing development posing the most imminent threat to RSA and ECDSA, a speedup in the mathematical developments could be even more consequential. More info on VQF here: https://arxiv.org/abs/1808.08927 It all comes down to this: when your public key is visible, which is always necessary to make transactions, you are at some point in the future vulnerable for quantum attacks. (This also goes for BTC, which uses the hash of the public key as an address, but more on that in the following articles.) If you would have keypairs based on post quantum cryptography, you would not have to worry about that since in that case not even a quantum computer could derive your private key from your public key. The conclusion is that future blockchains should be quantum resistant, using post-quantum cryptography. It’s very important to realize that post quantum cryptography is not just adding some extra characters to standard signature schemes. It’s the mathematical concept that makes it quantum resistant. to become quantm resistant, the algorithm needs to be changed. “The problem with currently popular algorithms is that their security relies on one of three hard mathematical problems: the integer factorization problem, the discrete logarithm problem or the elliptic-curve discrete logarithm problem. All of these problems can be easily solved on a sufficiently powerful quantum computer running Shor's algorithm. Even though current, publicly known, experimental quantum computers lack processing power to break any real cryptographic algorithm, many cryptographers are designing new algorithms to prepare for a time when quantum computing becomes a threat.” https://en.wikipedia.org/wiki/Post-quantum_cryptography Expectations in the field of quantum computer development. To give you an idea what the expectations of quantum computer development are in the field (Take note of the fact that the type and error rate of the qubits is not specified in the article. It is not said these will be enough to break ECDSA or RSA, neither is it said these will not be enough. What these articles do show, is that a huge speed up in development is expected.):
When will ECDSA be at risk? Estimates are only estimates, there are several to be found so it's hard to really tell. The National Academy of Sciences (NAS) has made a very thourough report on the development of quantum computing. The report came out in the end of 2018. They brought together a group of scientists of over 70 people from different interconnecting fields in quantum computing who, as a group, have come up with a close to 200 pages report on the development, funding, implications and upcoming challenges for quantum computing development. But, even though this report is one of the most thourough up to date, it doesn't make an estimate on when the risk for ECDSA or RSA would occur. They acknowledge this is quite impossible due to the fact there are a lot of unknowns and due to the fact that they have to base any findings only on publicly available information, obviously excluding any non available advancements from commercial companies and national efforts. So if this group of specialized scientists can’t make an estimate, who can make that assessment? Is there any credible source to make an accurate prediction? The conclusion at this point of time can only be that we do not know the answer to the big question "when". Now if we don't have an answer to the question "when", then why act? The answer is simple. If we’re talking about security, most take certainty over uncertainty. To answer the question when the threat materializes, we need to guess. Whether you guess soon, or you guess not for the next three decades, both are guesses. Going for certain means you'd have to plan for the worst, hope for the best. No matter how sceptical you are, having some sort of a plan ready is a responsible thing to do. Obviously not if you're just running a blog about knitting. But for systems that carry a lot of important, private and valuable information, planning starts today. The NAS describes it quite well. What they lack in guessing, they make up in advice. They have a very clear advice:
"Even if a quantum computer that can decrypt current cryptographic ciphers is more than a decade off, the hazard of such a machine is high enough—and the time frame for transitioning to a new security protocol is sufficiently long and uncertain—that prioritization of the development, standardization, and deployment of post-quantum cryptography is critical for minimizing the chance of a potential security and privacy disaster."
Another organization that looks ahead is the National Security Agency (NSA) They have made a threat assessment in 2015. In August 2015, NSA announced that it is planning to transition "in the not too distant future" (statement of 2015) to a new cipher suite that is resistant to quantum attacks. "Unfortunately, the growth of elliptic curve use has bumped up against the fact of continued progress in the research on quantum computing, necessitating a re-evaluation of our cryptographic strategy." NSA advised: "For those partners and vendors that have not yet made the transition to Suite B algorithms, we recommend not making a significant expenditure to do so at this point but instead to prepare for the upcoming quantum resistant algorithm transition.” https://en.wikipedia.org/wiki/NSA_Suite_B_Cryptography#cite_note-nsa-suite-b-1 What these organizations both advice is to start taking action. They don't say "implement this type of quantum resistant cryptography now". They don't say when at all. As said before, the "when" question is one that is a hard one to specify. It depends on the system you have, the value of the data, the consequences of postponing a security upgrade. Like I said before: you just run a blog, or a bank or a cryptocurrency? It's an individual risk assesment that's different for every organization and system. Assesments do need to be made now though. What time frame should organisationds think about when changing cryptography? How long would it take to go from the current level of security to fully quantum resistant security? What changes does it require to handle bigger signatures and is it possible to use certain types of cryptography that require to keep state? Do your users need to act, or can al work be done behind the user interface? These are important questions that one should start asking. I will elaborate on these challenges in the next articles. Besides the unsnswered question on "when", the question on what type of quantum resistant cryptography to use is unanswered too. This also depends on the type of system you use. The NSA and NAS both point to NIST as the authority on developments and standardization of quantum resistant cryptography. NIST is running a competition right now that should end up in one or more standards for quantum resistant cryptography. The NIST competition handles criteria that should filter out a type of quantum resistant cryptography that is feasable for a wide range of systems. This takes time though. There are some new algorithms submitted and assessing the new and the more well known ones must be done thouroughly. They intend to wrap things up around 2022 - 2024. From a blockchain perspective it is important to notice that a specific type of quantum resistant cryptography is excluded from the NIST competition: Stateful Hash-Based Signatures. (LMS and XMSS) This is not because these are no good. In fact they are excelent and XMSS is accepted to be provable quantum resistant. It's due to the fact that implementations will need to be able to securely deal with the requirement to keep state. And this is not a given for most systems. At this moment NIST intends to approve both LMS and XMSS for a specific group of applications that can deal with the statefull properties. The only loose end at this point is an advice for which applications LMS and XMSS will be adviced and for what applications it is discouraged. These questions will be answered in the beginning of april this year: https://csrc.nist.gov/news/2019/stateful-hbs-request-for-public-comments This means that quite likely LMS and XMSS will be the first type of standardized quantum resistant cryptography ever. To give a small hint: keeping state, is pretty much a naturally added property of blockchain. Quantum resistant blockchains “Quantum resistant” is only used to describe networks and cryptography that are secure against any attack by a quantum computer of any size in the sense that there is no algorithm known that makes it possible for a quantum computer to break the applied cryptography and thus that system. Also, to determine if a project is fully quantum resistant, you would need to take in account not only how a separate element that is implemented in that blockchain is quantum resistant, but also the way it is implemented. As with any type of security check, there should be no backdoors, in which case your blockchain would be just a cardboard box with bulletproof glass windows. Sounds obvious, but since this is kind of new territory, there are still some misconceptions. What is considered safe now, might not be safe in the age of quantum computers. I will address some of these in the following chapters, but first I will elaborate a bit about the special vulnerability of blockchain compared to centralized systems. Why is it easier to change cryptography for centralized systems such as banks and websites than for blockchain? Developers of a centralized system can decide from one day to the other that they make changes and update the system without the need for consensus from the nodes. They are in charge, and they can dictate the future of the system. But a decentralized blockchain will need to reach consensus amongst the nodes to update. Meaning that the majority of the nodes will need to upgrade and thus force the blockchain to only have the new signatures to be valid. We can’t have the old signature scheme to be valid besides the new quantum resistant signature scheme. Because that would mean that the blockchain would still allow the use of vulnerable, old public- and private keys and thus the old vulnerable signatures for transactions. So at least the majority of the nodes need to upgrade to make sure that blocks which are constructed using the old rules and thus the old vulnerable signature scheme, are rejected by the network. This will eventually result in a fully upgraded network which only accepts the new post quantum signature scheme in transactions. So, consensus is needed. The most well-known example of how that can be a slow process is Bitcoin’s need to scale. Even though everybody agrees on the need for a certain result, reaching consensus amongst the community on how to get to that result is a slow and political process. Going quantum resistant will be no different, and since it will cause lesser performance due to bigger signatures and it will need hardware upgrades quite likely it will be postponed rather than be done fast and smooth due to lack of consensus. And because there are several quantum resistant signature schemes to choose from, agreement an automatic given. The discussion will be which one to use, and how and when to implement it. The need for consensus is exclusively a problem decentralized systems like blockchain will face. Another issue for decentralized systems that change their signature scheme, is that users of decentralized blockchains will have to manually transfe migrate their coins/ tokens to a quantum safe address and that way decouple their old private key and activate a new quantum resistant private key that is part of an upgraded quantum resistant network. Users of centralized networks, on the other hand, do not need to do much, since it would be taken care of by their centralized managed system. As you know, for example, if you forget your password of your online bank account, or some website, they can always send you a link, or secret question, or in the worst case they can send you mail by post to your house address and you would be back in business. With the decentralized systems, there is no centralized entity who has your data. It is you who has this data, and only you. So in the centralized system there is a central entity who has access to all the data including all the private accessing data, and therefore this entity can pull all the strings. It can all be done behind your user interface, and you probably wouldn’t notice a thing. And a third issue will be the lost addresses. Since no one but you has access to your funds, your funds will become inaccessible once you lose your private key. From that point, an address is lost, and the funds on that address can never be moved. So after an upgrade, those funds will never be moved to a quantum resistant address, and thus will always be vulnerable to a quantum hack. To summarize: banks and websites are centralized systems, they will face challenges, but decentralized systems like blockchain will face some extra challenges that won't apply for centralized systems.
Updating the signature scheme will need consensus in the sense that all nodes need to update after implementation of a quantum resistant signature scheme.
Users of blockchain will personally need to move their funds from old addresses to new quantum resistant addresses. You won't need to move your bank funds.
Lost addresses where people lost access to their funds will never be moved and stay vulnerable to quantum hacks. Blockchain doesn't know their users, can't communicate with them and won't be able to distinguish coins on lost addresses from coins from users who still have access but somehow have not migrated their coins after a quantum resistant update. So burning lost coins will be legally a big issue.
Bitcoin doesn't require any special hardware, as it can be used on any device which can do computations. To make a Bitcoin transaction you need to create a ECDSA signature, which is just math, something which all computers do well. You can do it both on resource-constrained like smart cards (think SIM cards) and on large servers alike. The idea that you need a special Bitcoin computer to use Bitcoin is outright harmful, as it limits your choices and dupes you into buying overpriced proprietary hardware which gives the vendor more control of what you can and cannot do. This is very much against the spirit of Bitcoin which can thrive only as an open system. So yeah, that thing 21 inc is trying to sell makes no sense, whatsoever. But a lot of people think that "there might be something in it", let me go through the theories of why this device makes sense:
"It is a dev kit!". Let me guess, you aren't a programmer. Or if you're a programmer, you're a shitty programmer and should be ashamed of yourself. You do not need any dev kit for Bitcoin, all you need is open source software (and, maybe, some internet services, optionally). When I wanted to try to do something Bitcoin related back in 2011, all I needed was to download bitcoind and install it on my $10/month VPS. Then I looked through RPC API call list and made a Bitcoin-settled futures exchange. The whole thing took me only a week. I didn't need to pay $400 for a devkit. Learning how to work with bitcoind took less than a day. There are hundreds of Bitcoin companies and thousands of hobbyist working on Bitcoin projects, none of them needed any sort of a dev kit.
"It is useful because it has APIs and pre-installed software!" No, see above. If needed, pre-installed software can be delivered in a form of a virtual machine (e.g. VirtualBox, VMware, etc), no need for a physical device.
"It is useful because it comes with a micropayment service/API". Nope. These things can be done in software, no need for custom hardware. Obviously, a micropayment system can be more widely adopted when it is open. If it is tied to custom hardware (which I doubt) then you have a vendor lock-in which is exactly the thing we're trying to avoid with Bitcoin.
"it comes with pre-installed marketplace". So what, we have marketplaces such as OpenBazaar. If there are useful features in the 21 inc's marketplace we can replicated them in open source software.
"It's convenient for users!" Are you saying that a $400 device which you need to be connected to a laptop is more convenient than a service which can run in a browser?
"It might offer better security". We already have devices such as Trezor which can protect bitcoins from unsecure operating system. Trezor costs much less than $400 and is actually useful. Even though it was done by a small company without much capital.
"It can be used for applications like a reputation system, etc." When telecom companies wanted an ability to differentiate between users, they created smartcard-based SIM cards. This technology is many decades old. Using Bitcoin for a reputation system is a bad idea, as it is not designed for that. If device holds 1000 satoshi to give it an identity weight, a guy who has 1 bitcoin can impersonate 10000 such devices. It just not going to work.
"A constant stream of bitcoins it mines is convenient for users." User has to pay for this device, he might as well just buy bitcoins. If it is necessary for bitcoins to be attached to hardware, this can be done using a tiny dongle which costs less than $1 to manufacture, or a smart card.
"But this device got backed by VCs and large companies, there must be something to it, we are just too stupid to comprehend its greatness". Well...
There is, indeed, a very simple explanation of this device's existnce: Balaji's reality distortion field. He is a prominent VC, so it was relatively easy to convince others that it's a worthy idea. The big vision behind it -- the financial network of devices -- is actually great. And then there is a question of execution. A guy like Balaji is supposed to be an expert in assessing feasibility of execution. So, as we can guess, investors trusted him. As many VCs tell, they invest in people. They cannot examine nitty-gritty technical details, but just look at skills, track record, etc. So the fact that it got large investments and generates a lot of hype doesn't mean much, there was a plenty of such companies during dotcom boom. It's quite like :CueCat. As we now know, an ability to scan a printed code and open a web page which it points to is very useful, a lot of people use QR codes, they are ubiquitous. This was exactly the vision behind CueCat. But it was implemented as a dedicated hardware device, not as a smartphone app, as there were no smartphones at that time. So after a lot of hype and aggressive marketing the company failed, but just few years later their vision became realized in QR reader apps. Hardware becomes increasingly irrelevant. As Mark Andreessen, Balaji's partner, [once said], software is eating the world. Solving problems which can be solved software using custom hardware is just silly. Balaji talks about internet-of-things applications where devices mine bitcoins and use them to buy services they need to function. Well, in the end, user pays for that, as he pays for physical chips and electricity. It would be more efficient for him to pay directly than to use this mining-based scheme. And it's possible to do so using software. E.g. imagine you have a lot of smart devices which use external services in your home. It would be nice if you can just aggregate the bill and pay it off automatically, say $2/month. Why only $2? Well, if there is a device consuming $20/month, it needs some serious mining abilities, so it will cost much more than $20 in electricity bills... Maybe 21 inc will eventually pivot into purely software solutions, they have a lot of money to play with. But the current generation of devices they make just makes no sense, whatsoever, and people who try to find something useful in them just waste their time. EDIT: One plausible case for using custom hardware is a possibility of off-chain microtransactions using trusted hardware. Not unlike MintChip conceptually. But size of the device as well as its price is puzzling in this case, as this can be implemented (and was already implemented) in smart card form factor.
Did you know that LISK uses Schnorr signature-based Ed25519 scheme which is more secure, much faster, more scalable than secp256k1 which is used by Bitcoin, Ethereum, Stratis
Schnorr signatures have been praised by Bitcoin developers for a while Adam Back admitted it was more secure https://bitcointalk.org/index.php?topic=511074.msg5727641#msg5727641 And it is much faster (scalable for verifying hundred thousands of transactions per second) https://bitcointalk.org/index.php?topic=103172.0 DJB and friends claim that with their ed25519 curve (the "ed" is for Edwards) and careful implementation they can do batch verification of 70,000+ signatures per second on a cheap quad-core Intel Westmere chip, which is now several generations old. Given advances in CPUs over time, it seems likely that in the very near future the cited software will be capable of verifying many hundreds of thousands of signatures per second even if you keep the core count constant. But core counts are not constant - it seems likely that in 10 years or so 24-32 core chips will be standard even on consumer desktops. At that point a million signatures per second or more doesn't sound unreasonable. Gavin Andresen, the former Bitcoin Chief Scientist want to support it in Bitcoin https://www.reddit.com/Bitcoin/comments/2jw5pm/im_gavin_andresen_chief_scientist_at_the_bitcoin/clfp3xj/ Bitcoin developers discussed to include it https://github.com/bitcoin-core/secp256k1/pull/212 However, it is still in wishlist https://en.bitcoin.it/wiki/Softfork_wishlist Ed25519 is used in Tahoe-FS, one of most respected crypto project https://moderncrypto.org/mail-archive/curves/2014/000069.html LISK is IoT friendly The good feature of Schnorr signature is that by design it does not require lot of computations on the signer side. Therefore, you can use it even on a computationally weak platform (think of a smart card or RFID), or on a platform with no hardware support for multiple precision arithmetic. Advantages of Schnorr signatures According to David Harding, Schnorr signatures can bring many benefits Smaller multisig transactions Slightly smaller for all transactions Plausible deniability for multisig Plausible deniability of authorized parties using a third-party organizer (which doesn't need to be trusted with private keys), it's possible to prevent signers from knowing whether their private key is part of the set of signing keys. Theoretical better security properties: Also, the ed25519 page linked above describes several ways it is resistant to side-channel attacks, which can allow hardware wallets to operate safely in less secure environments. Faster signature verification: it likely takes fewer CPU cycles to verify an ed25519 Schnorr signature than a secp256k1 ECDSA signature. Multi-crypto multisig: with two (slightly) different cryptosystems to choose from, high-security users can create 2-of-2 multisig pubkey scripts that require both ECDSA and Schnorr signatures, so their bitcoins can't be stolen if only one cryptosystem is broken. https://bitcoin.stackexchange.com/questions/34288/what-are-the-implications-of-schnorr-signatures Scalable multisig transactions The magic of Schnorr signatures is most evident in their ability to aggregate signatures from multiple inputs into a single one to be validated for every individual transactions. The scaling implications of this are obvious: aggregation allows for non-trivial savings in terms of transmission, validation & storage for every peer on the network. The chart below illustrates the historical impact a switch to Schnorr signatures would have had in terms of space savings on the blockchain. (Alex B.) Infamous malleability is non-issue in LISK Provably no inherent signature malleability, while ECDSA has a known malleability, and lacks a proof that no other forms exist. Note that Witness Segregation already makes signature malleability not result in transaction malleability, however. https://www.elementsproject.org/elements/schnorr-signatures/ Bitcoin has malleability bugs
Abstract In this paper, we compute hundreds of Bitcoin private keys and dozens of Ethereum, Ripple, SSH, and HTTPS private keys by carrying out cryptanalytic attacks against digital signatures contained in public blockchains and Internet-wide scans. The ECDSA signature algorithm requires the generation of a per-message secret nonce. This nonce must be generated perfectly uniformly, or else an attacker can exploit the nonce biases to compute the long-term signing key. We use a lattice-based algorithm for solving the hidden number problem to efficiently compute private ECDSA keys that were used with biased signature nonces due to multiple apparent implementation vulnerabilities. References
Benger, N., van de Pol, J., Smart, N.P., Yarom, Y.: “Ooh aah... just a little bit”: A small amount of side channel can go a long way. In: Batina, L., Robshaw, M. (eds.) Cryptographic Hardware and Embedded Systems – CHES 2014. pp. 75–92. Springer Berlin Heidelberg, Berlin, Heidelberg (2014)
Boneh, D., Venkatesan, R.: Hardness of computing the most significant bits of secret keys in diffie-hellman and related schemes. In: Koblitz, N. (ed.) Advances in Cryptology — CRYPTO ’96. pp. 129–142. Springer Berlin Heidelberg, Berlin, Heidelberg (1996)
Bos, J.W., Halderman, J.A., Heninger, N., Moore, J., Naehrig, M., Wustrow, E.: Elliptic curve cryptography in practice. In: Christin, N., Safavi-Naini, R. (eds.) Financial Cryptography and Data Security. pp. 157–175. Springer Berlin Heidelberg, Berlin, Heidelberg (2014)
Brengel, M., Rossow, C.: Identifying key leakage of bitcoin users. In: Bailey, M., Holz, T., Stamatogiannakis, M., Ioannidis, S. (eds.) Research in Attacks, Intrusions, and Defenses. pp. 623–643. Springer International Publishing, Cham (2018)
De Mulder, E., Hutter, M., Marson, M.E., Pearson, P.: Using Bleichenbacher’s solution to the hidden number problem to attack nonce leaks in 384-bit ECDSA. In: Bertoni, G., Coron, J.S. (eds.) Cryptographic Hardware and Embedded Systems - CHES 2013. pp. 435–452. Springer Berlin Heidelberg, Berlin, Heidelberg (2013) Biased Nonce Sense 17
Dierks, T., Rescorla, E.: The Transport Layer Security (TLS) protocol. IETF RFC RFC5246 (2008)
Durumeric, Z., Adrian, D., Mirian, A., Bailey, M., Halderman, J.A.: A search engine backed by Internet-wide scanning. In: 22nd ACM Conference on Computer and Communications Security (Oct 2015)
Heninger, N., Durumeric, Z., Wustrow, E., Halderman, J.A.: Mining your Ps and Qs: Detection of widespread weak keys in network devices. In: Proceedings of the 21st USENIX Security Symposium (Aug 2012)
DJB and friends claim that with their ed25519 curve (the "ed" is for Edwards) and careful implementation they can do batch verification of 70,000+ signatures per second on a cheap quad-core Intel Westmere chip, which is now several generations old. Given advances in CPUs over time, it seems likely that in the very near future the cited software will be capable of verifying many hundreds of thousands of signatures per second even if you keep the core count constant. But core counts are not constant - it seems likely that in 10 years or so 24-32 core chips will be standard even on consumer desktops. At that point a million signatures per second or more doesn't sound unreasonable.
The good feature of Schnorr signature is that by design it does not require lot of computations on the signer side. Therefore, you can use it even on a computationally weak platform (think of a smart card or RFID), or on a platform with no hardware support for multiple precision arithmetic.
Advantages of Schnorr signatures According to David Harding, Schnorr signatures can bring many benefits
Smaller multisig transactions
Slightly smaller for all transactions
Plausible deniability for multisig
Plausible deniability of authorized parties using a third-party organizer (which doesn't need to be trusted with private keys), it's possible to prevent signers from knowing whether their private key is part of the set of signing keys.
Theoretical better security properties: Also, the ed25519 page linked above describes several ways it is resistant to side-channel attacks, which can allow hardware wallets to operate safely in less secure environments.
Faster signature verification: it likely takes fewer CPU cycles to verify an ed25519 Schnorr signature than a secp256k1 ECDSA signature.
Multi-crypto multisig: with two (slightly) different cryptosystems to choose from, high-security users can create 2-of-2 multisig pubkey scripts that require both ECDSA and Schnorr signatures, so their bitcoins can't be stolen if only one cryptosystem is broken.
The magic of Schnorr signatures is most evident in their ability to aggregate signatures from multiple inputs into a single one to be validated for every individual transactions. The scaling implications of this are obvious: aggregation allows for non-trivial savings in terms of transmission, validation & storage for every peer on the network. The chart below illustrates the historical impact a switch to Schnorr signatures would have had in terms of space savings on the blockchain. (Alex B.)
Infamous malleability is non-issue in LISK
Provably no inherent signature malleability, while ECDSA has a known malleability, and lacks a proof that no other forms exist. Note that Witness Segregation already makes signature malleability not result in transaction malleability, however. https://www.elementsproject.org/elements/schnorr-signatures/
Abstract Bitcoin, being the most successful cryptocurrency, has been repeatedly attacked with many users losing their funds. The industry's response to securing the user's assets is to offer tamper-resistant hardware wallets. Although such wallets are considered to be the most secure means for managing an account, no formal attempt has been previously done to identify, model and formally verify their properties. This paper provides the first formal model of the Bitcoin hardware wallet operations. We identify the properties and security parameters of a Bitcoin wallet and formally define them in the Universal Composition (UC) Framework. We present a modular treatment of a hardware wallet ecosystem, by realizing the wallet functionality in a hybrid setting defined by a set of protocols. This approach allows us to capture in detail the wallet's components, their interaction and the potential threats. We deduce the wallet's security by proving that it is secure under common cryptographic assumptions, provided that there is no deviation in the protocol execution. Finally, we define the attacks that are successful under a protocol deviation, and analyze the security of commercially available wallets. References
Alois, J.: Ethereum parity hack may impact eth 500.000 or 146 million (2017)
Atzei, N., Bartoletti, M., Lande, S., Zunino, R.: A formal model of bitcoin transactions. Financial Cryptography and Data Security. LNCS, Springer (2018)
Badertscher, C., Maurer, U., Tschudi, D., Zikas, V.: Bitcoin as a transaction ledger: A composable treatment. pp. 324–356 (2017)
Bamert, T., Decker, C., Wattenhofer, R., Welten, S.: Bluewallet: The secure bitcoin wallet. In: International Workshop on Security and Trust Management. pp. 65–80. Springer (2014)
Bonneau, J., Miller, A., Clark, J., Narayanan, A., Kroll, J.A., Felten, E.W.: Sok: Research perspectives and challenges for bitcoin and cryptocurrencies. In: Security and Privacy (SP), 2015 IEEE Symposium on. pp. 104–121. IEEE (2015)
Canetti, R.: Universally composable security: A new paradigm for cryptographic protocols. pp. 136–145 (2001)
Canetti, R.: Universally composable signatures, certification and authentication. Cryptology ePrint Archive, Report 2003/239 (2003), http://eprint.iacr.org/2003/239
Canetti, R., Krawczyk, H.: Universally composable notions of key exchange and secure channels. Cryptology ePrint Archive, Report 2002/059 (2002), http://eprint.iacr.org/2002/059
Garay, J., Kiayias, A., Leonardos, N.: The bitcoin backbone protocol: Analysis and applications. In: Annual International Conference on the Theory and Applications of Cryptographic Techniques. pp. 281–310. Springer (2015)
Gentilal, M., Martins, P., Sousa, L.: Trustzone-backed bitcoin wallet. In: Proceedings of the Fourth Workshop on Cryptography and Security in Computing Systems. pp. 25–28. ACM (2017)
Gkaniatsou, A., Arapinis, M., Kiayias, A.: Low-level attacks in bitcoin wallets. In: International Conference on Information Security. pp. 233–253. Springer (2017)
Heilman, E., Kendler, A., Zohar, A.: Eclipse attacks on bitcoin’s peer-to-peer network.
Hsiao, H.C., Lin, Y.H., Studer, A., Studer, C., Wang, K.H., Kikuchi, H., Perrig, A., Sun, H.M., Yang, B.Y.: A study of user-friendly hash comparison schemes. In: Computer Security Applications Conference, 2009. ACSAC’09. Annual. pp. 105–114. IEEE (2009)
Johnson, D., Menezes, A., Vanstone, S.: The elliptic curve digital signature algorithm (ecdsa). International journal of information security 1(1), 36–63 (2001)
Lim, I.K., Kim, Y.H., Lee, J.G., Lee, J.P., Nam-Gung, H., Lee, J.K.: The analysis and countermeasures on security breach of bitcoin. In: International Conference on Computational Science and Its Applications. pp. 720–732. Springer (2014)
Nakamoto, S.: Bitcoin: A peer-to-peer electronic cash system (2008)
Pass, R., Seeman, L., Shelat, A.: Analysis of the blockchain protocol in asynchronous networks. In: Annual International Conference on the Theory and Applications of Cryptographic Techniques. pp. 643–673. Springer (2017)
Penard, W., van Werkhoven, T.: On the secure hash algorithm family. Cryptography in Context pp. 1–18 (2008)
Tan, J., Bauer, L., Bonneau, J., Cranor, L.F., Thomas, J., Ur, B.: Can unicorns help users compare crypto key fingerprints? In: Proceedings of the 2017 CHI Conference on Human Factors in Computing Systems. pp. 3787–3798. ACM (2017)
Uzun, E., Karvonen, K., Asokan, N.: Usability analysis of secure pairing methods. In: International Conference on Financial Cryptography and Data Security. pp. 307–324. Springer (2007)
Vasek, M., Bonneau, J., Ryan Castellucci, C.K., Moore, T.: The bitcoin brain drain: a short paper on the use and abuse of bitcoin brain wallets. Financial Cryptography and Data Security, Lecture Notes in Computer Science. Springer (2016)
Volotikin, S.: Software attacks on hardware wallets. Black Hat USA 2018 (2018)
Block reward: 96 MaxCoin per block, halving every ~12 months with min reward of 1
Difficulty: Retargeting using Kimoto Gravity Well algorithm
Block time: 30 seconds
Cryptography Tech Spec MaxCoin uses the Keccak (SHA-3) hashing algorithm for its Proof-of-Work. Keccak was selected as an alternative to the NSA designed SHA256 after a 5-year long competition held by the NIST and will be seen increasingly as the algorithm used in banking and other secure applications. A single round of Keccak is used, resulting in a 256 bit hash. We have also implemented a provably-secure signing algorithm, EC-Schnorr. Every existing cryptocurrency uses the ECDSA algorithm, as chosen by Satoshi; whilst ECDSA is in common use and is secure, EC-Schnorr is provably more secure and is currently being recommended over it (https://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report/at_download/fullReport). Additionally, MaxCoin changes the elliptic curve utilised within the signing algorithms from a Koblitz curve, secp256k1, to a more secure psuedo-random one, secp256r1. The use of the latter curve is recommended almost universally - and the decision by Satoshi to use the former is one that is often queried in the Bitcoin world. One theory is that there are some speed advantages to using the Koblitz curve, but, the implementation used in Bitcoin (OpenSSL) does not make use of this optimisation and, thus, the result is reduced-security. The cryptography choices within MaxCoin have been made to maximise security and, where possible, to minimise NSA influence. We have been advised throughout by the renowed cryptography expert Professor Nigel Smart (https://en.wikipedia.org/wiki/Nigel_Smart_(cryptographer)). These changes also lay the foundation for some key features we're aiming to implement in MaxCoin over the coming months, so while they may currently appear uninteresting changes they pave the way for our future growth. What do you mean by "Starting Algorithm"? This is an issue of hardware miner resistance, such as ASICs. Keccak is the starting algorithm for MaxCoin and at this point in time no hardware miner currently exists. However, creating a Keccak ASIC is not impossible. Therefore, in order to protect against a hardware-miner future we are going to implement an "ASIC protection" feature into MaxCoin. This will work by allowing the blockchain to decide a new hashing algorithm for MaxCoin every x blocks. More specifically, the last authenticated transaction's hash is used to determine an integer and depending on this value an algorithm will be selected. This will mean hardware miners will find it difficult to create hardware in enough time to see profitable return. Purely for example, these could be: x Algorithm 0 Keccak 1 Blake 2 Grostlx2 3 JH 4 Skein 5 Blake2 6 JH(Grostl) 7 Keccak+Blake Difficulty & Distribution MaxCoin will have a zero % premine, proven by the timestamps of the first blocks in a block explorer, and we have attempted to combat low-difficulty instamining with a fast retarget rate up until block 200. At block 200 the Kimoto Gravity Well implementation will take over the retargeting. Mining is done via CPU at release (mining guides about to be released also on this subreddit), but a GPU miner will not be far away. We've seen some versions in the works already after we released CPUminer yesterday, and while we have not yet seen a working version, this is very unlikely to take long. We'll update all official channels with Keccak GPU miner once it is available. It's also worth noting that any GPU miner created will not work after the first algorithm switch takes place.
“Bitcoin enables certain uses that are very unique. I think it offers possibilities that no other currency allows. For example the ability to spend a coin that only occurs when two separate parties agree to spend the coin; with a third party that couldn’t run away with the coin itself.” – Pieter Wui (66 points, 14 comments)
Dear builders, I want to build the best fitting piece of hardware which I will use for things like a Minecraft server, a small webpage server, and, most important and demanding, for verifying ECDSA for a new cryptocurrency and some other IO network stuff which comes along with the currency. It is not in any way related to bitcoin though. The SoC/PC is supposed to run 24/7 and therefore needs low power consumption. So far I had planned an Odroid XU2, the successor of the XU, but I fear that it might not have enough power for my needs. RAM should be >=3Gb being able to use a SSD as hard drive would be great. e: I have a budget of ~300$ (without the SSD) Thank you!
SHA256 and ECDSA which are used in Bitcoin are well-known industry standard algorithms. SHA256 is endorsed and used by the US Government and is standardized (FIPS180-3 Secure Hash Standard). If you believe that these algorithms are untrustworthy then you should not trust Bitcoin, credit card transactions or any type of electronic bank transfer. Bitcoin has a sound basis in well understood ... Bitcoin is a decentralized digital currency that enables instant payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer technology to operate with no central authority: transaction management and money issuance are carried out collectively by the network. The original Bitcoin software by Satoshi Nakamoto was released under the MIT license. . Most client software, derived or "from ... Bitcoind nicht wie ECDSA (r, s) - paar produziert von OpenSSL. Ich Schreibe Transaktionen manuell und haben stolperte über eine Recht bizarre situation. Nur eine in ein paar der Transaktionen ich broadcast auf bitcoind wird akzeptiert, sonst bekomme ich eine REJECT_NONSTANDARD (Nicht-kanonischen DER Signatur). Also ich hab mir die Hände schmutzig zu machen und verfolgt die Ablehnung ... Bitcoin's security, when used properly with a new address on each transaction, depends on more than just ECDSA: Cryptographic hashes are much stronger than ECDSA under QC. Bitcoin's security was designed to be upgraded in a forward compatible way and could be upgraded if this were considered an imminent threat. Exkurs: Elliptische-Kurven-Kryptosystem (ECDSA) Bitcoin verwendet obiges System zur Schlüsselerstellung mit 256 Bit Länge. Die vom Wallet generierte Zufallszahl (private Schlüssel) ist damit 2 256 groß, was knapp 80 Ziffern entspricht. Es gibt elliptische Kurven mit ganz bestimmten, vorher festgelegten Parametern, bei denen man einen festgelegten Punkt G auf der Kurve mit der Zufallszahl ...
'Fake Bitcoin' - How this Woman Scammed the World, then ...
Bitcoin für Anfänger einfach erklärt! [auf Deutsch] Bitcoin-Börse (erhalte 10€ in BTC) https://finanzfluss.de/go/bitcoin-boerse *📱 Sicheres Bitcoin-Wallet... Start mining Bitcoin today: https://pool.bitcoin.com Video: Inside America’s largest Bitcoin mining operation http://bitshare.cm/news/inside-americas-largest... Those secret keys are typically used to create and sign transactions (payments, smart contracts, etc.) using ECDSA. Wallet implementations range from simple open-source software to hardware tokens. Elliptic Curve Digital Signature Algorithm ECDSA Part 10 Cryptography Crashcourse - Duration: 35:32. Dr. Julian Hosp - Blockchain, Krypto, Bitcoin 5,773 views Bitcoin - Wikipedija, prosta enciklopedija - Vsakemu naslovu Bitcoin, ki je analogen računu v bančnem sistemu, pripada par javnega in zasebnega ključa ECDSA iz domene asimetrične kriptografije ...