sha256 - PKHash RipeMD160 in python - Stack Overflow

Is Crypto Currency truly at risk due to Quantum Computers, and what can you do about it?

Is Crypto Currency truly at risk due to Quantum Computers, and what can you do about it?

There is no denying that the Quantum revolution is coming. Security protocols for the internet, banking, telecommunications, etc... are all at risk, and your Bitcoins (and alt-cryptos) are next!
This article is not really about quantum computers[i], but, rather, how they will affect the future of cryptocurrency, and what steps a smart investor will take. Since this is a complicated subject, my intention is to provide just enough relevant information without being too “techy.”

The Quantum Evolution

In 1982, Nobel winning physicist, Richard Feynman, hypothesized how quantum computers[ii] would be used in modern life.
Just one year later, Apple released the “Apple Lisa”[iii] – a home computer with a 7.89MHz processor and a whopping 5MB hard drive, and, if you enjoy nostalgia, it used 5.25in floppy disks.
Today, we walk around with portable devices that are thousands of times more powerful, and, yet, our modern day computers still work in a simple manner, with simple math, and simple operators[iv]. They now just do it so fast and efficient that we forget what’s happening behind the scenes.
No doubt, the human race is accelerating at a remarkable speed, and we’ve become obsessed with quantifying everything - from the everyday details of life to the entire universe[v]. Not only do we know how to precisely measure elementary particles, we also know how to control their actions!
Yet, even with all this advancement, modern computers cannot “crack” cryptocurrencies without the use of a great deal more computing power, and since it’s more than the planet can currently supply, it could take millions, if not billions, of years.
However, what current computers can’t do, quantum computers can!
So, how can something that was conceptualized in the 1980’s, and, as of yet, has no practical application, compromise cryptocurrencies and take over Bitcoin?
To best answer this question, let’s begin by looking at a bitcoin address.

What exactly is a Bitcoin address?

Well, in layman terms, a Bitcoin address is used to send and receive Bitcoins, and looking a bit closer (excuse the pun), it has two parts:[vi]
A public key that is openly shared with the world to accept payments. A public key that is derived from the private key. The private key is made up of 256 bits of information in a (hopefully) random order. This 256 bit code is 64 characters long (in the range of 0-9/a-f) and further compressed into a 52 character code (using RIPEMD-160).
NOTE: Although many people talk about Bitcoin encryption, Bitcoin does not use Encryption. Instead, Bitcoin uses a hashing algorithm (for more info, please see endnote below[vii]).
Now, back to understanding the private key:
The Bitcoin address “1EHNa6Q4Jz2uvNExL497mE43ikXhwF6kZm” translates to a private key of “5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreAnchuDf” which further translates to a 256 bit private key of “0000000000000000000000000000000000000000000000000000000000000001” (this should go without saying, but do not use this address/private key because it was compromised long ago.) Although there are a few more calculations that go behind the scenes, these are the most relevant details.
Now, to access a Bitcoin address, you first need the private key, and from this private key, the public key is derived. With current computers, it’s classically impractical to attempt to find a private key based on a public key. Simply put, you need the private key to know the public key.
However, it has already been theorized (and technically proven) that due to private key compression, multiple private keys can be used to access the same public key (aka address). This means that your Bitcoin address has multiple private keys associated with it, and, if someone accidentally discovers or “cracks” any one of those private keys, they have access to all the funds in that specific address.
There is even a pool of a few dedicated people hunting for these potential overlaps[viii], and they are, in fact, getting very efficient at it. The creator of the pool also has a website listing every possible Bitcoin private key/address in existence[ix], and, as of this writing, the pool averages 204 trillion keys per day!
But wait! Before you get scared and start panic selling, the probability of finding a Bitcoin address containing funds (or even being used) is highly unlikely – nevertheless, still possible!
However, the more Bitcoin users, the more likely a “collision” (finding overlapping private/public key pairs)! You see, the security of a Bitcoin address is simply based on large numbers! How large? Well, according to my math, 1.157920892373x1077 potential private keys exist (that number represents over 9,500 digits in length! For some perspective, this entire article contains just over 14,000 characters. Therefore, the total number of Bitcoin addresses is so great that the probability of finding an active address with funds is infinitesimal.

So, how do Quantum Computers present a threat?

At this point, you might be thinking, “How can a quantum computer defeat this overwhelming number of possibilities?” Well, to put it simple; Superposition and Entanglement[x].
Superposition allows a quantum bit (qbit) to be in multiple states at the same time. Entanglement allows an observer to know the measurement of a particle in any location in the universe. If you have ever heard Einstein’s quote, “Spooky Action at a Distance,” he was talking about Entanglement!
To give you an idea of how this works, imagine how efficient you would be if you could make your coffee, drive your car, and walk your dog all at the same time, while also knowing the temperature of your coffee before drinking, the current maintenance requirements for your car, and even what your dog is thinking! In a nutshell, quantum computers have the ability to process and analyze countless bits of information simultaneously – and so fast, and in such a different way, that no human mind can comprehend!
At this stage, it is estimated that the Bitcoin address hash algorithm will be defeated by quantum computers before 2028 (and quite possibly much sooner)! The NSA has even stated that the SHA256 hash algorithm (the same hash algorithm that Bitcoin uses) is no longer considered secure, and, as a result, the NSA has now moved to new hashing techniques, and that was in 2016! Prior to that, in 2014, the NSA also invested a large amount of money in a research program called “Penetrating Hard Targets project”[xi] which was used for further Quantum Computer study and how to break “strong encryption and hashing algorithms.” Does NSA know something they’re not saying or are they just preemptively preparing?
Nonetheless, before long, we will be in a post-quantum cryptography world where quantum computers can crack crypto addresses and take all the funds in any wallet.

What are Bitcoin core developers doing about this threat?

Well, as of now, absolutely nothing. Quantum computers are not considered a threat by Bitcoin developers nor by most of the crypto-community. I’m sure when the time comes, Bitcoin core developers will implement a new cryptographic algorithm that all future addresses/transactions will utilize. However, will this happen before post-quantum cryptography[xii]?
Moreover, even after new cryptographic implementation, what about all the old addresses? Well, if your address has been actively used on the network (sending funds), it will be in imminent danger of a quantum attack. Therefore, everyone who is holding funds in an old address will need to send their funds to a new address (using a quantum safe crypto-format). If you think network congestion is a problem now, just wait…
Additionally, there is the potential that the transition to a new hashing algorithm will require a hard fork (a soft fork may also suffice), and this could result in a serious problem because there should not be multiple copies of the same blockchain/ledger. If one fork gets attacked, the address on the other fork is also compromised. As a side-note, the blockchain Nebulas[xiii] will have the ability to modify the base blockchain software without any forks. This includes adding new and more secure hashing algorithms over time! Nebulas is due to be released in 2018.

Who would want to attack Bitcoin?

Bitcoin and cryptocurrency represent a threat to the controlling financial system of our modern economy. Entire countries have outright banned cryptocurrency[xiv] and even arrested people[xv], and while discrediting it, some countries are copying cryptocurrency to use (and control) in their economy[xvi]!
Furthermore, Visa[xvii], Mastercard[xviii], Discover[xix], and most banks act like they want nothing to do with cryptocurrency, all the while seeing the potential of blockchain technology and developing their own[xx]. Just like any disruptive technology, Bitcoin and cryptocurrencies have their fair share of enemies!
As of now, quantum computers are being developed by some of the largest companies in the world, as well as private government agencies.
No doubt, we will see a post-quantum cryptography world sooner than most realize. By that point, who knows how long “3 letter agencies” will have been using quantum technology - and what they’ll be capable of!

What can we do to protect ourselves today?

Of course, the best option is to start looking at how Bitcoin can implement new cryptographic features immediately, but it will take time, and we have seen how slow the process can be just for scaling[xxi].
The other thing we can do is use a Bitcoin address only once for outgoing transactions. When quantum computers attack Bitcoin (and other crypto currencies), their first target will be addresses that have outgoing transactions on the blockchain that contain funds.
This is due to the fact that when computers first attempt to crack a Bitcoin address, the starting point is when a transaction becomes public. In other words, when the transaction is first signed – a signed transaction is a digital signature derived from the private key, and it validates the transaction on the network. Compared to classical computers, quantum computers can exponentially extrapolate this information.
Initially, Bitcoin Core Software might provide some level of protection because it only uses an address once, and then sends the remaining balance (if any) to another address in your keypool. However, third party Bitcoin wallets can and do use an address multiple times for outgoing transactions. For instance, this could be a big problem for users that accept donations (if they don’t update their donation address every time they remove funds). The biggest downside to Bitcoin Core Software is the amount of hard-drive space required, as well as diligently retaining an up-to-date copy of the entire blockchain ledger.
Nonetheless, as quantum computers evolve, they will inevitably render SHA256 vulnerable, and although this will be one of the first hash algorithms cracked by quantum computers, it won’t be the last!

Are any cryptocurrencies planning for the post-quantum cryptography world?

Yes, indeed, there are! Here is a short list of ones you may want to know more about:

Full disclosure:

Although I am in no way associated with any project listed above, I do hold coins in all as well as Bitcoin, Litecoin and many others.
The thoughts above are based on my personal research, but I make no claims to being a quantum scientist or cryptographer. So, don’t take my word for anything. Instead, do your own research and draw your own conclusions. I’ve included many references below, but there are many more to explore.
In conclusion, the intention of this article is not to create fear or panic, nor any other negative effects. It is simply to educate. If you see an error in any of my statements, please, politely, let me know, and I will do my best to update the error.
Thanks for reading!

References

[i] https://www.youtube.com/watch?v=JhHMJCUmq28 – A great video explaining quantum computers.
[ii] https://www.doc.ic.ac.uk/~nd/surprise_97/journal/vol4/spb3/ - A brief history of quantum computing.
[iii] https://en.wikipedia.org/wiki/Apple_Lisa - More than you would ever want to know about the Apple Lisa.
[iv] https://www.youtube.com/watch?v=tpIctyqH29Q&list=PL8dPuuaLjXtNlUrzyH5r6jN9ulIgZBpdo - Want to learn more about computer science? Here is a great crash course for it!
[v] https://www.collinsdictionary.com/dictionary/english/quantify - What does quantify mean?
[vi] https://en.bitcoin.it/wiki/Private_key - More info about Bitcoin private keys.
[vii] https://www.securityinnovationeurope.com/blog/page/whats-the-difference-between-hashing-and-encrypting - A good example of the deference between Hash and Encryption
[viii] https://lbc.cryptoguru.org/stats - The Large Bitcoin Collider.
[ix] http://directory.io/ - A list of every possible Bitcoin private key. This website is a clever way of converting the 64 character uncompressed key to the private key 128 at a time. Since it is impossible to save all this data in a database and search, it is not considered a threat! It’s equated with looking for a single needle on the entire planet.
[x] https://uwaterloo.ca/institute-for-quantum-computing/quantum-computing-101#Superposition-and-entanglement – Brief overview of Superposition and Entanglement.
[xi] https://www.washingtonpost.com/world/national-security/nsa-seeks-to-build-quantum-computer-that-could-crack-most-types-of-encryption/2014/01/02/8fff297e-7195-11e3-8def-a33011492df2_story.html?utm_term=.e05a9dfb6333 – A review of the Penetrating Hard Targets project.
[xii] https://en.wikipedia.org/wiki/Post-quantum_cryptography - Explains post-quantum cryptography.
[xiii] https://www.nebulas.io/ - The nebulas project has some amazing technology planned in their roadmap. They are currently in testnet stage with initial launch expected taking place in a few weeks. If you don’t know about Nebulas, you should check them out. [xiv] https://en.wikipedia.org/wiki/Legality_of_bitcoin_by_country_or_territory - Country’s stance on crypto currencies.
[xv] https://www.cnbc.com/2017/08/30/venezuela-is-one-of-the-worlds-most-dangerous-places-to-mine-bitcoin.html - Don’t be a miner in Venezuela!
[xvi] http://www.newsweek.com/russia-bitcoin-avoid-us-sanctions-cryptocurrency-768742 - Russia’s plan for their own crypto currency.
[xvii] http://www.telegraph.co.uk/technology/2018/01/05/visa-locks-bitcoin-payment-cards-crackdown-card-issue - Recent attack from visa against crypto currency.
[xviii] https://www.ccn.com/non-government-digital-currency-junk-says-mastercard-ceo-rejecting-bitcoin/ - Mastercards position about Bitcoin.
[xix] http://www.livebitcoinnews.com/discover-joins-visa-mastercard-barring-bitcoin-support/ - Discovers position about Bitcoin.
[xx] http://fortune.com/2017/10/20/mastercard-blockchain-bitcoin/ - Mastercard is making their own blockchain.
[xxi] https://bitcoincore.org/en/2015/12/21/capacity-increase/ - News about Bitcoin capacity. Not a lot of news…
[xxii] https://learn.iota.org/faq/what-makes-iota-quantum-secure - IOTA and quantum encryption.
[xxiii] https://eprint.iacr.org/2011/191.pdf - The whitepaper of Winternitz One-Time Signature Scheme
[xxiv] https://cardanoroadmap.com/ - The Cardano project roadmap.
[xxv] https://eprint.iacr.org/2017/490 - More about the BLISS hash system.
[xxvi] https://www.ethereum.org/ - Home of the Ethereum project.
[xxvii] https://en.wikipedia.org/wiki/SHA-3#Security_against_quantum_attacks – SHA3 hash algorithm vs quantum computers.
[xxviii] https://en.wikipedia.org/wiki/Lamport_signature - Lamport signature information.
[xxix] https://theqrl.org/ - Home of the Quantum Resistant Ledger project.
submitted by satoshibytes to CryptoCurrency [link] [comments]

Ren will present on Bitcoin Wednesday’s 6-Year Anniversary on 3 July 2019

Bitcoin Wednesday’s 6-Year Anniversary on 3 July 2019 presents cryptographer Ren Zhang, who will compare Proof of Work (PoW) to Proof of Stake (PoS). Proof of Work is a mathematical algorithm that produces results that are difficult to calculate but easy to verify, the governing principle that secures Bitcoin. Although the PoW concept was first proposed in the early 90s, Satoshi Nakamoto’s novel use of it, described in the Bitcoin white paper, sparked the cryptocurrency revolution.

In his talk for Bitcoin Wednesday Ren will explain what Proof of Work brings us that was previously impossible and how it compares to alternatives like Proof of Stake. He writes:

More than $146 billion in crypto-assets (75% of them worldwide) are secured by Proof of Work. As of June 2019, $1 million worth of Bitcoin is created every day to compensate miners who use physical resources to secure the system. These numers are not small, and it is likely that they will grow even larger if cryptocurrencies continue to thrive. In order to avoid PoW’s high level of energy consumption, many new cryptocurrencies turn to other consensus mechanisms. How do they match up to Proof of Work? Have they achieved their goals? What do they sacrifice, if anything?

Ren is a cryptography researcher at COSIC Research Group at KU Leuven in Belgium, where he focuses on blockchain consensus protocols and privacy- and security-related problems in peer-to-peer networks. He is currently working on a variant of Nakamoto Consensus with higher throughput known as NC-Max. He is a cryptographer for Nervos, a new Proof-of-Work blockchain, and a research assistant to Bart Preneel, the designer of RIPEMD 160, the hash function used to compute from your Bitcoin public key to your Bitcoin address. Ren’s research group at KU Leuven happens to be the birthplace of AES, the advanced encryption standard used in almost all electronic devices.

In 2017, after Ren discovered design flaws in the Bitcoin Unlimited scaling proposal, he was invited to work with Pieter Wuillie and Gregory Maxwell at Blockstream. His paper, “Lay Down the Common Metrics: Evaluating Proof-of-Work Consensus Protocol’s Security” which he co-authored with Bart Preneel, was presented at the 2019 IEEE SP symposium in Oakland.

https://www.bitcoinwednesday.com/speakers/ren-zhang-cryptographer-ku-leuven-nervos/
submitted by Aimeedeer to NervosNetwork [link] [comments]

BIP Number Request: Open Asset | Nicolas Dorier | May 26 2016

Nicolas Dorier on May 26 2016:
Open Asset is a simple and well known colored coin protocol made by Flavien
Charlon, which has been around for more than two years ago.
Open Asset is OP_RETURN to store coin's color. Since then, the only
modification to the protocol has been for allowing OA data to be into any
push into an OP_RETURN.
The protocol is here:
https://github.com/OpenAssets/open-assets-protocol/blob/mastespecification.mediawiki
I asked to Flavien Charlon if he was OK if I submit the protocol to the
mailing list before posting.
Additional BIP number might be required to cover for example the "colored
address" format:
https://github.com/OpenAssets/open-assets-protocol/blob/masteaddress-format.mediawiki
But I will do it in a separate request.
Here is the core of the Open Asset specification:
Title: Open Assets Protocol (OAP/1.0)
Author: Flavien Charlon
Created: 2013-12-12
==Abstract==
This document describes a protocol used for storing and transferring
custom, non-native assets on the Blockchain. Assets are represented by
tokens called colored coins.
An issuer would first issue colored coins and associate them with a
formal or informal promise that he will redeem the coins according to
terms he has defined. Colored coins can then be transferred using
transactions that preserve the quantity of every asset.
==Motivation==
In the current Bitcoin implementation, outputs represent a quantity of
Bitcoin, secured by an output script. With the Open Assets Protocol,
outputs can encapsulate a quantity of a user-defined asset on top of
that Bitcoin amount.
There are many applications:
could then be traded frictionlessly through the Bitcoin
infrastructure.
could withdraw and deposit money in colored coins, and trade those, or
use them to pay for goods and services. The Blockchain becomes a
system allowing to transact not only in Bitcoin, but in any currency.
of colored coins. The door would only open when presented with a
wallet containing that specific coin.
==Protocol Overview==
Outputs using the Open Assets Protocol to store an asset have two new
characteristics:
asset stored on the output.
many units of that asset are stored on the output.
This document describes how the asset ID and asset quantity of an
output are calculated.
Each output in the Blockchain can be either colored or uncolored:
both undefined).
non-null asset ID.
The ID of an asset is the RIPEMD-160 hash of the SHA-256 hash of the
output script referenced by the first input of the transaction that
initially issued that asset (script_hash =
RIPEMD160(SHA256(script))). An issuer can reissue more of an
already existing asset as long as they retain the private key for that
asset ID. Assets on two different outputs can only be mixed together
if they have the same asset ID.
Like addresses, asset IDs can be represented in base 58. They must use
version byte 23 (115 in TestNet3) when represented in base 58. The
base 58 representation of an asset ID therefore starts with the
character 'A' in MainNet.
The process to generate an asset ID and the matching private key is
described in the following example:

The issuer first generates a private key:

18E14A7B6A307F426A94F8114701E7C8E774E7F9A47E2C2035DB29A206321725.

He calculates the corresponding address:

16UwLL9Risc3QfPqBUvKofHmBQ7wMtjvM.

Next, he builds the Pay-to-PubKey-Hash script associated to that

address: OP_DUP OP_HASH160
010966776006953D5567439E5E39F86A0D273BEE OP_EQUALVERIFY
OP_CHECKSIG.

The script is hashed: 36e0ea8e93eaa0285d641305f4c81e563aa570a2

Finally, the hash is converted to a base 58 string with checksum

using version byte 23:
ALn3aK1fSuG27N96UGYB1kUYUpGKRhBuBC.
The private key from the first step is required to issue assets
identified by the asset ID
ALn3aK1fSuG27N96UGYB1kUYUpGKRhBuBC. This acts as a
digital signature, and gives the guarantee that nobody else but the
original issuer is able to issue assets identified by this specific
asset ID.
==Open Assets Transactions==
Transactions relevant to the Open Assets Protocol must have a special
output called the marker output. This allows clients to recognize such
transactions. Open Assets transactions can be used to issue new
assets, or transfer ownership of assets.
Transactions that are not recognized as an Open Assets transaction are
considered as having all their outputs uncolored.
===Marker output===
The marker output can have a zero or non-zero value. The marker output
starts with the OP_RETURN opcode, and can be followed by any sequence
of opcodes, but it must contain a PUSHDATA opcode containing a
parsable Open Assets marker payload. If multiple parsable PUSHDATA
opcodes exist in the same output, the first one is used, and the other
ones are ignored.
If multiple valid marker outputs exist in the same transaction, the
first one is used and the other ones are considered as regular
outputs. If no valid marker output exists in the transaction, all
outputs are considered uncolored.
The payload as defined by the Open Assets protocol has the following format:
{|
! Field !! Description !! Size
|-
! OAP Marker || A tag indicating that this transaction is an
Open Assets transaction. It is always 0x4f41. || 2 bytes
|-
! Version number || The major revision number of the Open Assets
Protocol. For this version, it is 1 (0x0100). || 2 bytes
|-
! Asset quantity count || A
[https://en.bitcoin.it/wiki/Protocol_specification#Variable_length_integer
var-integer] representing the number of items in the asset
quantity list field. || 1-9 bytes
|-
! Asset quantity list || A list of zero or more
[http://en.wikipedia.org/wiki/LEB128 LEB128-encoded] unsigned integers
representing the asset quantity of every output in order (excluding
the marker output). || Variable
|-
! Metadata length || The
[https://en.bitcoin.it/wiki/Protocol_specification#Variable_length_integer
var-integer] encoded length of the metadata field. || 1-9
bytes
|-
! Metadata || Arbitrary metadata to be associated with
this transaction. This can be empty. || Variable
|}
Possible formats for the metadata field are outside of
scope of this protocol, and may be described in separate protocol
specifications building on top of this one.
The asset quantity list field is used to determine the
asset quantity of each output. Each integer is encoded using variable
length [http://en.wikipedia.org/wiki/LEB128 LEB128] encoding (also
used in [https://developers.google.com/protocol-buffers/docs/encoding#varints
Google Protocol Buffers]). If the LEB128-encoded asset quantity of any
output exceeds 9 bytes, the marker output is deemed invalid. The
maximum valid asset quantity for an output is 263 - 1
units.
If the marker output is malformed, it is considered non-parsable.
Coinbase transactions and transactions with zero inputs cannot have a
valid marker output, even if it would be otherwise considered valid.
If there are less items in the asset quantity list than
the number of colorable outputs (all the outputs except the marker
output), the outputs in excess receive an asset quantity of zero. If
there are more items in the asset quantity list than the
number of colorable outputs, the marker output is deemed invalid. The
marker output is always uncolored.
After the asset quantity list has been used to assign an
asset quantity to every output, asset IDs are assigned to outputs.
Outputs before the marker output are used for asset issuance, and
outputs after the marker output are used for asset transfer.
====Example====
This example illustrates how a marker output is decoded. Assuming the
marker output is output 1:
Data in the marker output Description ----------------------------- 
0x6a The OP_RETURN opcode. 0x10 The PUSHDATA opcode for a 16 bytes payload. 0x4f 0x41 The Open Assets Protocol tag. 0x01 0x00 Version 1 of the protocol. 0x03 There are 3 items in the asset quantity list. 0xac 0x02 0x00 0xe5 0x8e 0x26 The asset quantity list: - '0xac 0x02' means output 0 has an 
asset quantity of 300.
 - Output 1 is skipped and has an 
asset quantity of 0
 because it is the marker output. - '0x00' means output 2 has an 
asset quantity of 0.
 - '0xe5 0x8e 0x26' means output 3 
has an asset quantity of 624,485.
 - Outputs after output 3 (if any) 
have an asset quantity of 0.
0x04 The metadata is 4 bytes long. 0x12 0x34 0x56 0x78 Some arbitrary metadata. 
===Asset issuance outputs===
All the outputs before the marker output are used for asset issuance.
All outputs preceding the marker output and with a non-zero asset ...[message truncated here by reddit bot]...
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012741.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

[uncensored-r/CryptoCurrency] Is Crypto Currency truly at risk due to Quantum Computers, and what can you do about it?

The following post by satoshibytes is being replicated because some comments within the post(but not the post itself) have been openly removed.
The original post can be found(in censored form) at this link:
np.reddit.com/ CryptoCurrency/comments/7uvomu
The original post's content was as follows:

Is Crypto Currency truly at risk due to Quantum Computers, and what can you do about it?

There is no denying that the Quantum revolution is coming. Security protocols for the internet, banking, telecommunications, etc... are all at risk, and your Bitcoins (and alt-cryptos) are next!
This article is not really about quantum computers[i], but, rather, how they will affect the future of cryptocurrency, and what steps a smart investor will take. Since this is a complicated subject, my intention is to provide just enough relevant information without being too “techy.”

The Quantum Evolution

In 1982, Nobel winning physicist, Richard Feynman, hypothesized how quantum computers[ii] would be used in modern life.
Just one year later, Apple released the “Apple Lisa”[iii] – a home computer with a 7.89MHz processor and a whopping 5MB hard drive, and, if you enjoy nostalgia, it used 5.25in floppy disks.
Today, we walk around with portable devices that are thousands of times more powerful, and, yet, our modern day computers still work in a simple manner, with simple math, and simple operators[iv]. They now just do it so fast and efficient that we forget what’s happening behind the scenes.
No doubt, the human race is accelerating at a remarkable speed, and we’ve become obsessed with quantifying everything - from the everyday details of life to the entire universe[v]. Not only do we know how to precisely measure elementary particles, we also know how to control their actions!
Yet, even with all this advancement, modern computers cannot “crack” cryptocurrencies without the use of a great deal more computing power, and since it’s more than the planet can currently supply, it could take millions, if not billions, of years.
However, what current computers can’t do, quantum computers can!
So, how can something that was conceptualized in the 1980’s, and, as of yet, has no practical application, compromise cryptocurrencies and take over Bitcoin?
To best answer this question, let’s begin by looking at a bitcoin address.

What exactly is a Bitcoin address?

Well, in layman terms, a Bitcoin address is used to send and receive Bitcoins, and looking a bit closer (excuse the pun), it has two parts:[vi]
A public key that is openly shared with the world to accept payments. A private key that is derived from the public key. The private key is made up of 256 bits of information in a (hopefully) random order. This 256 bit code is 64 characters long (in the range of 0-9/a-f) and further compressed into a 52 character code (using RIPEMD-160).
NOTE: Although many people talk about Bitcoin encryption, Bitcoin does not use Encryption. Instead, Bitcoin uses a hashing algorithm (for more info, please see endnote below[vii]).
Now, back to understanding the private key:
The Bitcoin address “1EHNa6Q4Jz2uvNExL497mE43ikXhwF6kZm” translates to a private key of “5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreAnchuDf” which further translates to a 256 bit private key of “0000000000000000000000000000000000000000000000000000000000000001” (this should go without saying, but do not use this address/private key because it was compromised long ago.) Although there are a few more calculations that go behind the scenes, these are the most relevant details.
Now, to access a Bitcoin address, you first need the private key, and from this private key, the public key is derived. With current computers, it’s classically impractical to attempt to find a private key based on a public key. Simply put, you need the private key to know the public key.
However, it has already been theorized (and technically proven) that due to private key compression, multiple private keys can be used to access the same public key (aka address). This means that your Bitcoin address has multiple private keys associated with it, and, if someone accidentally discovers or “cracks” any one of those private keys, they have access to all the funds in that specific address.
There is even a pool of a few dedicated people hunting for these potential overlaps[viii], and they are, in fact, getting very efficient at it. The creator of the pool also has a website listing every possible Bitcoin private key/address in existence[ix], and, as of this writing, the pool averages 204 trillion keys per day!
But wait! Before you get scared and start panic selling, the probability of finding a Bitcoin address containing funds (or even being used) is highly unlikely – nevertheless, still possible!
However, the more Bitcoin users, the more likely a “collision” (finding overlapping private/public key pairs)! You see, the security of a Bitcoin address is simply based on large numbers! How large? Well, according to my math, 1.157920892373x1077 potential private keys exist (that number represents over 9,500 digits in length! For some perspective, this entire article contains just over 14,000 characters. Therefore, the total number of Bitcoin addresses is so great that the probability of finding an active address with funds is infinitesimal.

So, how do Quantum Computers present a threat?

At this point, you might be thinking, “How can a quantum computer defeat this overwhelming number of possibilities?” Well, to put it simple; Superposition and Entanglement[x].
Superposition allows a quantum bit (qbit) to be in multiple states at the same time. Entanglement allows an observer to know the measurement of a particle in any location in the universe. If you have ever heard Einstein’s quote, “Spooky Action at a Distance,” he was talking about Entanglement!
To give you an idea of how this works, imagine how efficient you would be if you could make your coffee, drive your car, and walk your dog all at the same time, while also knowing the temperature of your coffee before drinking, the current maintenance requirements for your car, and even what your dog is thinking! In a nutshell, quantum computers have the ability to process and analyze countless bits of information simultaneously – and so fast, and in such a different way, that no human mind can comprehend!
At this stage, it is estimated that the Bitcoin address hash algorithm will be defeated by quantum computers before 2028 (and quite possibly much sooner)! The NSA has even stated that the SHA256 hash algorithm (the same hash algorithm that Bitcoin uses) is no longer considered secure, and, as a result, the NSA has now moved to new hashing techniques, and that was in 2016! Prior to that, in 2014, the NSA also invested a large amount of money in a research program called “Penetrating Hard Targets project”[xi] which was used for further Quantum Computer study and how to break “strong encryption and hashing algorithms.” Does NSA know something they’re not saying or are they just preemptively preparing?
Nonetheless, before long, we will be in a post-quantum cryptography world where quantum computers can crack crypto addresses and take all the funds in any wallet.

What are Bitcoin core developers doing about this threat?

Well, as of now, absolutely nothing. Quantum computers are not considered a threat by Bitcoin developers nor by most of the crypto-community. I’m sure when the time comes, Bitcoin core developers will implement a new cryptographic algorithm that all future addresses/transactions will utilize. However, will this happen before post-quantum cryptography[xii]?
Moreover, even after new cryptographic implementation, what about all the old addresses? Well, if your address has been actively used on the network (sending funds), it will be in imminent danger of a quantum attack. Therefore, everyone who is holding funds in an old address will need to send their funds to a new address (using a quantum safe crypto-format). If you think network congestion is a problem now, just wait…
Additionally, there is the potential that the transition to a new hashing algorithm will require a hard fork (a soft fork may also suffice), and this could result in a serious problem because there should not be multiple copies of the same blockchain/ledger. If one fork gets attacked, the address on the other fork is also compromised. As a side-note, the blockchain Nebulas[xiii] will have the ability to modify the base blockchain software without any forks. This includes adding new and more secure hashing algorithms over time! Nebulas is due to be released in 2018.

Who would want to attack Bitcoin?

Bitcoin and cryptocurrency represent a threat to the controlling financial system of our modern economy. Entire countries have outright banned cryptocurrency[xiv] and even arrested people[xv], and while discrediting it, some countries are copying cryptocurrency to use (and control) in their economy[xvi]!
Furthermore, Visa[xvii], Mastercard[xviii], Discover[xix], and most banks act like they want nothing to do with cryptocurrency, all the while seeing the potential of blockchain technology and developing their own[xx]. Just like any disruptive technology, Bitcoin and cryptocurrencies have their fair share of enemies!
As of now, quantum computers are being developed by some of the largest companies in the world, as well as private government agencies.
No doubt, we will see a post-quantum cryptography world sooner than most realize. By that point, who knows how long “3 letter agencies” will have been using quantum technology - and what they’ll be capable of!

What can we do to protect ourselves today?

...
submitted by censorship_notifier to noncensored_bitcoin [link] [comments]

Bitcoin Core 0.13.1 released | Wladimir J. van der Laan | Oct 27 2016

Wladimir J. van der Laan on Oct 27 2016:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Bitcoin Core version 0.13.1 is now available from:
https://bitcoin.org/bin/bitcoin-core-0.13.1/
Or through bittorrent:
magnet:?xt=urn:btih:dbe48c446b1113890644bbef03e361269f69c49a&dn;=bitcoin-core-0.13.1&tr;=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.publicbt.com%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.ccc.de%3A80%2Fannounce&tr;=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr;=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969&ws;=https%3A%2F%2Fbitcoin.org%2Fbin%2F
This is a new minor version release, including activation parameters for the
segwit softfork, various bugfixes and performance improvements, as well as
updated translations.
Please report bugs using the issue tracker at github:
https://github.com/bitcoin/bitcoin/issues
To receive security and update notifications, please subscribe to:
https://bitcoincore.org/en/list/announcements/join/
Compatibility

Microsoft ended support for Windows XP on April 8th, 2014,
an OS initially released in 2001. This means that not even critical security
updates will be released anymore. Without security updates, using a bitcoin
wallet on a XP machine is irresponsible at least.
In addition to that, with 0.12.x there have been varied reports of Bitcoin Core
randomly crashing on Windows XP. It is not clear
what the source of these crashes is, but it is likely that upstream
libraries such as Qt are no longer being tested on XP.
We do not have time nor resources to provide support for an OS that is
end-of-life. From 0.13.0 on, Windows XP is no longer supported. Users are
suggested to upgrade to a newer version of Windows, or install an alternative OS
that is supported.
No attempt is made to prevent installing or running the software on Windows XP,
you can still do so at your own risk, but do not expect it to work: do not
report issues about Windows XP to the issue tracker.
but severe issues with the libc++ version on 10.7.x keep it from running reliably.
0.13.1 now requires 10.8+, and will communicate that to 10.7 users, rather than crashing unexpectedly.
Notable changes

Segregated witness soft fork
Segregated witness (segwit) is a soft fork that, if activated, will
allow transaction-producing software to separate (segregate) transaction
signatures (witnesses) from the part of the data in a transaction that is
covered by the txid. This provides several immediate benefits:
Activation for the segwit soft fork is being managed using BIP9
versionbits. Segwit's version bit is bit 1, and nodes will begin
tracking which blocks signal support for segwit at the beginning of the
first retarget period after segwit's start date of 15 November 2016. If
95% of blocks within a 2,016-block retarget period (about two weeks)
signal support for segwit, the soft fork will be locked in. After
another 2,016 blocks, segwit will activate.
For more information about segwit, please see...[message truncated here by reddit bot]...
original: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-Octobe013265.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Does Multi-Sig have weaker crypto than a standard transaction ?

Hello,
I am not versed in cryptography at all but from what I understand, storing funds in a multi-signature "wallet" for the long term, seems less safe than storing them in a standard single-address wallet.
Assuming we have built quantum super-computers and we have broken ECDSA aka we can calculate the private key of any given public key.
TL;DR I understand that multi-sig is essentially pay-to-more-than-one-public-key and not pay-to-more-than-one-public-key-hash.
According to a bitcoin magazine article this was a crypto pitfall that was avoided early on.
Have we taken a step back from that direction ?
submitted by starsRunderground to Bitcoin [link] [comments]

Idea for safely implementing "Opt-In Full-RBF": Make it receiver opt-in rather than sender opt-in.

There are currently a lot of arguments against opt-in RBF about how it could become a usability nightmare and can enable double spends against unwitting people. This stems from the fact that it's opt-in by the sender and this requires a certain amount of knowledge by the receiver to avoid being scammed. But what if it was opt-in by the receiver instead? Then the sender has no way of issuing a RBF transaction against someone who is unwilling to accept a RBF transaction.
Currently there is no way to do this. The Bitcoin network is unaware of anything to do with the receiver of a transaction other than the public key hash or script hash. It can however tell the difference between the two types of keys. Standard public key hashes are prefixed with "1" and script hash keys are prefixed with "3". https://en.bitcoin.it/wiki/List_of_address_prefixes
I'm suggesting a hard fork that adds 2 new prefixes to public addresses. The new prefixes could be anything, but for the sake of this example let's say the the new prefixes are "R" and "r". "R" would become the prefix for public key hash addresses that are willing to accept RBF transactions and "r" for opt-in RBF script hash addresses. Now there is no need for transactions to be declared by the sender as RBF. Nodes and miners will simply reject any double spend attempts unless all outputs of the transaction are prefixed with either "R" or "r". The sender could even choose to opt-out of RBF by using a non-RBF prefixed address as one of the change outputs.
This does create an issue where you can spoof the intent of the receiver by changing the prefix on the address, so the function used to calculate the public address would need to be slightly different. The sender can't be allowed to reverse engineer an "R" address from a "1" address. There are two possible solutions here.
Option 1: Make a small change to the public key hashing algorithm. This could be something as simple as performing the RIPEMD-160 hash twice instead of once when creating a RBF address. This method has the benefit of not adding any cryptographic complexity to the system but the cons are that once you spend from an address and reveal the true public key, anyone can generate both public addresses. You only have the security of receiving non-RBF transactions exclusively as long as you don't reuse the address once you spend from it, or if you generate a new address for each incoming transaction. Also, wallet and block explorer software would need to be updated so that the possibility of two different addresses pointing to the same public key won't break it.
Option 2: Use a different ECDSA curve. This is the cleanest option when it comes to usability and writing code, but at the expense of adding more cryptographic complexity to the system. More points of failure to worry about.
Personally I think option 1 might be better. Address reuse is already discouraged and thanks to the popularity of HD wallets, following that rule is not that big a deal.
submitted by testing1567 to btc [link] [comments]

[BIP] OP_CHECKPRIVPUBPAIR | Mats Jerratsch | Nov 27 2015

Mats Jerratsch on Nov 27 2015:
Prior discussion:
http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-Novembe000309.html
Goal:
Greatly improve security for payment networks like the 'Lightning
Network' (LN) [1]
Introduction:
To improve privacy while using a payment network, it is possible to
use onion-routing to make a payment to someone. In this context,
onion-routing means encrypting the data about subsequent hops in a way
that each node only knows where it received a payment from and the
direct next node it should send the payment to. This way we can route
a payment over N nodes, and none of these will know
(1) at which position it is within the route (first, middle, last?)
(2) which node initially issued the payment (payer)
(3) which node consumes the payment (payee).
However, given the way payments in LN work, each payment is uniquely
identifiable by a preimage-hash pair R-H. H is included in the output
script of the commit transaction, such that the payment is enforceable
if you ever get to know the preimage R.
In a payment network each node makes a promise to pay the next node,
if they can produce R. They can pass on the payment, as they know that
they can enforce the payment from a previous node using the same
preimage R. This severely damages privacy, as it lowers the amount of
nodes an attacker has to control to gain information about payer and
payee.
Problem:
The problem was inherited by using RIPEMD-160 for preimage-hash
construction. For any cryptographic hash-function it is fundamentally
unfeasible to correlate preimage and hash in such a way, that
F1(R1) = R2 and
F2(H1) = H2, while
SHA(R1) = H1 and SHA(R2) = H2.
In other words, I cannot give a node H1 and H2 and ask it to receive
my payment using H1, but pass it on using H2, as the node has no way
of verifying it can produce R1 out of the R2 it will receive. If it
cannot produce R1, it is unable to enforce my part of the contract.
Solution:
While above functions are merely impossible to construct for a
cryptographic hash functions, they are trivial when R and H is a EC
private/public key pair. The original sender can make a payment using
H1 and pass on a random number M1, such that the node can calculate a
new public key
H2 = H1 + M1.
When he later receives the private key R2, he can construct
R1 = R2 - M1
to be able to enforce the other payment. M1 can be passed on in the
onion object, such that each node can only see M for that hop.
Furthermore, it is unfeasible to brute-force, given a sufficiently
large number M.
Example:
Given that E wants to receive a payment from A, payable to H. (if A
can produce R, it can be used as a prove he made the payment and E
received it)
A decides to route the payment over the nodes B, C and D. A uses four
numbers M1...M4 to calculate H1...H4. The following payments then take
place
A->B using H4
B->C using H3
C->D using H2
D->E using H1.
When E receives H1, he can use attached M1 to calculate R1 from it.
The chain will resolve itself, and A is able to calculate R using
M1...M4. It also means that all privacy is at the sole discretion of
the sender, and that not even the original pair H is known to any of
the nodes.
To improve privacy, E could also be a rendezvous point chosen by the
real receiver of the payment, similar constructions are similar in
that direction as well.
Caveats:
Currently it is difficult to enforce a payment to a private-public key
pair on the blockchain. While there exists OP_HASH160 OP_EQUAL to
enforce a payment to a hash, the same does not hold true for EC keys.
To make above possible we would therefore need some easy way to force
a private key, given a public key. This could be done by using one of
the unused OP_NOP codes, which will verify
OP_CHECKPRIVPUBPAIR
and fails if these are not correlated or NOP otherwise. Would need
OP_2DROP afterwards. This would allow deployment using a softfork.
As there are requests for all sort of general crypto operations in
script, we can also introduce a new general OP_CRYPTO and prepend one
byte for the operation, so
0x01 OP_CRYPTO = OP_CHECKPRIVPUBPAIR
0x02-0xff OP_CRYPTO = OP_NOP
to allow for extension at some later point.
Alternatives:
In the attached discussion there are some constructions that would
allow breaking the signature scheme, but they are either very large in
script language or expensive to calculate. Given that the blocksize is
a difficult topic already, it would not be beneficial to have a 400B+
for each open payment in case one party breaches the contract. (or
just disappears for a couple of days)
It is also possible to use a NIZKP - more specifically SNARK - to
prove to one node that it is able to recover a preimage R1 = R2 XOR
M1, given only H1, H2 and M1. However, these are expensive to
calculate and experimental in it's current state.
Acknowledgements:
Gregory Maxwell for pointing out addition of M1 for EC points is much
less expensive
Pieter Wuille for helping with general understanding of EC math.
Anthony Towns for bringing up the issue and explaining SNARKs
[1]
http://lightning.network/
original: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-Novembe011827.html
submitted by dev_list_bot to bitcoin_devlist [link] [comments]

Инструкция по настройки программы чтоб взломать Биткоин-кошелек вариант и способ FSE 2018 - Cryptanalysis of 48-step RIPEMD-160 ripemd 160 - YouTube Bitcoin Hacking! Overview of the program For searching for private keys How to get Bitcoins How to hack bitcoin addresses! This is a new working program 2020 for selecting private keys BTC!

I am trying to understand how the crypto algorithms RIPEMD and SHA256 work. The bitcoin method for computing PKHash is RIPEMD160(SHA256(PublicKey)). I am trying to first implement the RIPEMD of SH... Is RIPEMD-160 a requirement for European countries? Any additional information, that would be helpful in deciding. sha ripemd. share improve this question follow asked Sep 10 '09 at 10:59. Priyank Bolia Priyank Bolia. 12.3k 13 13 gold badges 55 55 silver badges 81 81 bronze badges. add a comment 3 Answers Active Oldest Votes. 1. As for SHA-256 there are no known collisions. I believe ... Complete a RIPEMD output on the Input data. This cryptographic hash function is a message digest algorithm. Short for RACE Integrity Primitives Evaluation Message Digest, it was published first in the mid 1990’s. Unlike the more popular SHA-1 and SHA-2 which were created by the NSA, RIPEMD is a child of an open academic collaboration, created as an European Union project. It was designed to ... RIPEMD-160 is a cryptographic hash function based upon the Merkle–Damgård construction. It is used in the Bitcoin standard. It is a a strengthened version of the RIPEMD algorithm which produces a 128 bit hash digest while the RIPEMD-160 algorithm produces a 160-bit output. The compression function is made up of 80 stages made up of 5 blocks that run 16 times each. This pattern runs twice ... Online RIPEMD160 Hash Calculator. Algorithm. String to encode. Encode. Other algorithms calculators MD2 MD4 MD5 SHA1 SHA224 SHA256 SHA384 SHA512/224 SHA512/256 SHA512 SHA3-224 SHA3-256 SHA3-384 SHA3-512 RIPEMD128 RIPEMD160 RIPEMD256 RIPEMD320 WHIRLPOOL TIGER128,3 TIGER160,3 TIGER192,3 TIGER128,4 TIGER160,4 TIGER192,4 SNEFRU SNEFRU256 GOST GOST-CRYPTO ADLER32 CRC32 CRC32B FNV132 FNV1A32 FNV164 ...

[index] [49659] [25539] [23850] [43504] [18744] [48575] [51113] [38115] [5510] [42603]

Инструкция по настройки программы чтоб взломать Биткоин-кошелек вариант и способ

RIPEMD 160 hash algorithm https://hash.onlinetoolsland.com/ripemd/ The whole name of RIPEMD is RACE Integrity Primitives Evaluation Message Digest. RIPEMD a ... Bitcoin makes use of two hashing functions, SHA-256 and RIPEMD-160, but it also uses Elliptic Curve DSA on the curve secp256k1 to perform signatures. The C++ implementation uses a local copy of ... The program does not require an Internet connection, since the generation of bitcoin addresses with private keys occurs, SHA 256, RIPEMD-160 , base58 are already built into the program Loading... Session VIII - Hash Functions 25th International Conference on Fast Software Encryption (Bruges, Belgium, 2018) The program does not require an Internet connection, since the generation of bitcoin addresses with private keys occurs, SHA 256, RIPEMD-160 , base58 are already built into the program Loading...

#