Recently, two known individuals in the crypto community, Bryce Weiner and Andrew Desantis, decided to rehash (no pun intended) a year-old supposed vulnerability involving Bitcoin’s transactions and SegWit (Segregated Witness).
According to the pair’s tweets on Twitter, Segregated Witness, which was an upgrade to the Bitcoin protocol introduced via soft fork in 2017, has allegedly rendered Bitcoin susceptible to an attack vector that could result in user’s having all of their coins drained from their wallet.
The original thread, which was posted by Twitter account (@deosbot), no longer exists because the Twitter account was deleted by its owner.
However, the author (@ProofofResearch) was able to screenshot the contents of the thread before it was deleted.
Contents of the Thread
Below are the contents of the thread posted in their entirety (via screenshots):
Above is the entirety of the thread, which was posted on Twitter January 4th/5th (depending on your time zone).
The two pictures that Andrew Desantis posted are re-posted below as well for convenience:
Dissecting the Claim That Andrew and Bryce are Making Here
Without a ton of information being provided in the thread itself (which Bryce self-admitted in the thread was purposeful for some reason), we as the crypto community are left to surmise what exploit the pair are referring to.
Below, we’ll try our best to make sense of the vague nature of these posts.
Dissecting the Main Claim
Let’s go back to the two photos that Andrew posted:
In a nutshell, Andrew Desantis is claiming that he found a way to steal funds from Bitcoin wallets via address collision. We’re assuming that the concept of address collision has something to do with this alleged discovery because Bryce was careful to mention that several times when asked about this issue.
Specifically, here is a narrated Twitter conversation between Bryce Weiner and the author of this article when Bryce was reached for response:
In a single tweet: it has been proved that two deterministic addresses for which one has the private keys may create a transaction which allows one to spend funds at a “simulated” SegWit address. Should that address collide w/ an existing funded address, funds may be stolen.
In the above tweet, Bryce unequivocally states:
“In a single tweet: it has been proved that two deterministic addresses for which one has the private keys may create a transaction which allows one to spend funds at a ‘simulated’ SegWit address. Should that address collide w/ an existing funded address, funds may be stolen.”
This claim was met with a quote tweeted response from the author (seen below):
Technically, a collision was never impossible even with SHA256 & an ECDSA. It’s just infinitesimally unlikely. https://t.co/MAq7TTgpkA
To which Bryce Weiner responded by stating:
@ProofofResearch SegWit addresses are not on an elliptic curve.
Understanding that the above claim is patently false, the author decided to probe Bryce Weiner to explain his theories a bit further by asking for clarification:
@BryceWeiner How are they created?
After receiving no reply to the above tweet, another tweet response was publicly delivered to Bryce Weiner by the article’s author, explaining the process used to create a SegWit specific address on the Bitcoin protocol:
They are. If we’re talking bech32 addresses, you must use a compressed public key, which is an ECDSA public key. That key is then hashed twice with ripemd160 & SHA256. So there’s no way there could be a collision in the way that you described. https://t.co/YHwAZmE8Wd
This revelation was met with the following response by Bryce Weiner:
@ProofofResearch What? I can’t even stop to explain to you how wrong that is. Moving on.
Without elaborating, Bryce Weiner merely insisted that the author was wrong in his assertion.
How are Segregated Witness Addresses Created?
Fortunately, this is not really a point of debate/contention, because a guide for creating SegWit addresses is clearly posted on Bitcoin’s website:
Most contents of this document could be found in the BIPs related to segregated witness, including BIP141, BIP143, BIP144, and BIP145. Please consider this as the first point of reference to other related documents, and as a checklist for what should and should not be done.
Below is a screenshot of the specific excerpt that addresses the creation of Segregated Witness (bech32) addresses:
As one can see from the highlighted portion of the screenshot posted above, the process for creating a Segregated Witness address (PW2PKH) is the same as what was described to Bryce Weiner in the Twitter response from the article’s author.
What’s the Main Point of Debating the Creation of SegWit Addresses?
This is a good question and one that demands an answer because we don’t want the main point to be lost in the antics.
Bryce Weiner’s claim and central argument relies on the idea that SegWit addresses could potentially collide with existing addresses.
The reason why the notion of ECDSA is important is because ECDSA refers to signatures that adhere to elliptic curve cryptography. Specifically, Bitcoin uses the sepc256k1 standard. This standard is designed specifically so that each unique private key will generate a unique public address. If this were not the case, then the Bitcoin protocol would be at risk for producing “collisions”, which means that there would be a chance that someone’s private key could hash to an already existing public address.
Bryce Weiner’s argument is that this risk is inherent in SegWit. However, this is not true because Segregated Witness addresses must be created from a compressed public key. As we all know, public keys are created through an ECDSA signature. Therefore, each public key should be unique to the private key that created it.
Thus, if one’s public key is obfuscated (or only used once as has been recommended in the community for years), then there is no reason to believe or suggest that the resulting SegWit address (bech32; address prefix bc1) would then correspond to an already existing address.
None of the above even takes into account that the compressed public key is hashed with SHA256, then hashed again using ripemd160 in order to produce a P2WPKH address.
When taking this entire process into account, it makes the idea implausible at best.
Bryce’s Response Should Warrant Scrutiny and Skepticism
Given the denial of the above facts and lack of elaboration by Bryce Weiner, one must call into question how serious he and Andrew Desantis are taking their claims or if this is all just one big publicity stunt.
Nonetheless, we will still attempt to dissect what these two individuals have publicly posted about this alleged exploit.
Breaking Down Andrew Desantis’ Picture
Let’s start by breaking down each element of the picture that Andrew Desantis posted and notated.
The picture has been re-posted below for convenience:
- Andrew shows him sending a small amount of $BTC from his main wallet to two newly created wallets. At that point, the TX is a UTXO (meaning it has not been spent from his wallet, so the $BTC protocol will acknowledge his right to send it).
- The three resulting addresses are the address that he sent it from (that’s the change address), as well as two new (uncompressed) Bitcoin addresses. As Andrew mentioned, these addresses were derived from using the genesis block hash as a private key.
- As Andrew mentioned, the two addresses are new. There’s no problem in accepting that premise. However, I’m not sure if both addresses are derived from compressed or uncompressed public keys, or if one address is derived from a compresed key and the other an uncompressed one. I’m not going to take the time to dig up the Bitcoin genesis block hash, hash that into a private key and then hash a compressed and uncompressed key from it. Perhaps someone else will. The TX size is 290 bytes for that TX, so we can rule out the idea that they’re both uncompressed. My guess is that possibly one is uncompressed and the other is compressed. Andrew didn’t give us that information for some reason.
- For those that do not know, Bitcoin wallet addresses are not the same as public keys. Wallet addresses derive from public keys. This is because of an update in the way Bitcoin wallets are created (done a long time ago), which yielded HD wallets. These wallets provide a public address, and they are hashed from the public keys. The protocol recognizes these wallet addresses and sends your TX to the appropriate corresponding public key. If you download a wallet these days from any reliable source, you’ll more than likely see dozens of private keys for each crypto type.
- According to Andrew, the balance of both of his newly created addresses are then stolen (in the same block). He doesn’t explain how or even provide verifiable proof that the bitcoins were indeed stolen from the two newly created legacy addresses (mixture of compressed and uncompressed).
Problem #1 — Mislabeling the Addresses
The final receiving address (the one that begins with a ‘3’ in a picture above), is not a SegWit specific address.
An address that begins with ‘3’ is a P2SH address. These were created several years ago (2012; Gavin Andresen) via BIP16. (https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki).
Generally, these addresses are multi-sig or imbued with some other script-specific security measure to ensure better custodial protection of the bitcoins sent to the address.
If you look at the Bitcoin rich list, you’ll see a lot of exchanges that store their bitcoins in addresses with this prefix:
These are generally considered substantially more secure than addresses that begin with the prefix of ‘1’.
“Regular”, legacy wallet addresses are P2PKH addresses (Pubkey hash) (https://en.bitcoin.it/wiki/Transaction#Pay-to-PubkeyHash).
SegWit Addresses are Bech32 Addresses
SegWit specific addresses are bech32 addresses. (https://en.bitcoin.it/wiki/Bech32)
As the author mentioned to Bryce, these are created by hashing a compressed public key using SHA256, then hashing that result with ripemd160.
Problem #2 — Failure to Examine the ‘3’-Prefix Address
The ultimate recipient in these transactions is the address with a prefix that begins with ‘3’.
For some reason, Andrew Desantis does not provide any greater information/insight into this address or its owner. If the wallet owner is a malicious actor that has found an exploit in the Bitcoin protocol which they are using to ‘steal’ funds from users, there should be significantly more insight provided by Andrew Desantis. Instead, he and Bryce Weiner decided to be purposefully opaque with their findings. So, we are left with the responsibility of verifying the claims that they have made.
Regardless, we will attempt to do so anyway.
Evaluating the Transaction/Wallet Address Type
While this is not a P2SH-P2WSH transaction, we can still look at this portion of the Bitcoin.org website to glean some useful insight on whether the transaction constituted a SegWit transaction or not.
Please see the following excerpt from the Bitcoin website below:
Fortunately, that UTXO (that the address in #4 of that picture received) was spent, so we can view the raw transaction information, which can be found here:
“Like any other P2SH and P2SH-PSWPKH address, P2SH-P2WSH address has prefix 3. They are indistinguishable until the UTXO is spent.”
It is a bit difficult to determine whether this was a Segregated Witness transaction or not, but it does appear to be so.
What Does This Mean?
Absolutely nothing because an address with a prefix of ‘3’ is not a Segregated Witness address.
It is simply an address that can receive and send SegWit transactions.
However, the two addresses that Andrew Desantis created with his initial transaction (#2 in the picture that he showed), cannot send SegWit transactions. Those are legacy wallet addresses.
Therefore, for us to accept that his conclusion of theft is correct, we must believe that the address that allegedly stole the funds from those two legacy wallets was only able to do so because it was created via a collision on the blockchain (i.e., the private key hashed to a SegWit address that also hashed to an existing or soon-to-exist Bitcoin address). Desantis’ theory also requires that the creator of the address with a ‘3’ prefix would have had to have knowledge of such an “exploit” and then subsequently coded a script of some sort that would automatically transfer the funds from the corresponding legacy wallet to their wallets upon its creation (wallets must receive funds to be created).
Problem #3 — Nothing in Desantis’ Tweets Demonstrates That Collisions Are More or Less Possible on the Bitcoin Protocol
At this point, we have already defined what ‘collision resistance’ means in cryptography, specifically for the Bitcoin protocol. We’ve also debunked Bryce Weiner’s theory that somehow one could create a Segregated Witness address that would collide with an already existing legacy address on the Bitcoin protocol.
However, we have yet to dissect the most important revelation:
The creation of a public key on the Bitcoin protocol is an independent event.
If you’re confused about how public keys are created, we recommend consulting this link, which provides a pretty thorough explanation:
Thanks for contributing an answer to Bitcoin Stack Exchange! Some of your past answers have not been well-received, and you’re in danger of being blocked from answering. Please pay close attention to the following guidance: Please be sure to answer the question. Provide details and share your research!
If you’re wondering about how likely it would be to generate a private key that already exists or that allows you to access funds for an already existing public key, here’s another helpful link that gives the probabilities for such an event:
Here’s a what-if scenario: Person A has a Bitcoin address with 25BTC. Person B opens up their Bitcoin client: which may or may not have the complete blockchain (the latter would mean no copies of
Some may recognize this as the ‘birthday attack’. A research piece that outlines the probability of such an event can be found below:
Thus, the notion that some outside event (i.e., creation of a SegWit address) would heighten the likelihood of a collision being found is nonsensical to the point where the premise itself must be rejected.
Problem #4 — The Private Key Being Generated Was NOT Random
This is perhaps the biggest glaring error in the pictures provided that attest to the alleged ‘hack’ of bitcoins from the two newly created wallets.
In the transaction picture, Andrew states:
“The addresses consist of the address of origin and the un/compressed addresses derived from using the genesis block hash as a private key.”
The issue here is that the public key for the address that was generated was not random.
In order to understand why this is a big deal, we need to travel in time for a little bit.
Remember back in 2013 when there were a lot of Android users that had their bitcoins stolen by the app? If you don’t or you weren’t in crypto at that point, don’t worry — we’ve posted an article covering the event below:
Users of Android Bitcoin apps have woken to the unpleasant news that an old pseudo random number generation bug has been exploited to steal balances from users’ wallets. The Bitcoin Foundation’s announcement, here, merely states that an unspecified component of Android “responsible for generating secure random numbers contains critical weaknesses, that render all Android wallets generated to date vulnerable to theft.”
Essentially, tons of users had their bitcoins stolen from their Android wallets because their private keys were guessed.
How did this happen? And better yet, how could someone have been able to specifically figure out the private keys for these Android users’ wallets without putting the entire Bitcoin protocol at great risk?
The answer lies in ‘random numbers’.
Before one even generates a private key, one must ensure that the root/derivative that their private key is hashed from is truly random.
If it isn’t, then anyone can guess your private key.
Many Bitcoin wallets in the past used the ‘SecureRandom’ java function to produce the ‘r-value’ for Bitcoin public key creation.
Here’s a pretty thorough blog post on it by David Gerard:
Update: The word “Most” in the original title of this post is incorrect – see details at end. Cryptography is profoundly unforgiving of errors. You don’t mess with it. You don’t roll your own – you need battle-hardened algorithms that have been torture-tested by the most technically ruthless cryptographers you can find.
David sums it up best when he stated:
“What that means is that the keys will be predictable enough to crack by sheer brute-force attack of computing power. You might think you have a key long enough that it can’t be cracked before the sun goes out — but it turns out you could do it in a week.
So a lot of browser-based cryptocurrency products that still use SecureRandom() are generating keys that are open to being cracked.”
Extrapolating to Andrew Desantis’ Example
Any and everything that is related to the genesis block of Bitcoin is the stuff of legends at this point.
There is perhaps no other block that has been evaluated and scrutinized more so than the genesis block.
So, to use a known and publicly popular value, like the hash of Bitcoin’s genesis block to create a wallet on the Bitcoin protocol is about as non-random as it gets.
On the basis of this alone, the assertions by Andrew Desantis and Bryce Weiner can be discarded because a compromise of such a wallet only demonstrates poor op-sec, not a flaw in the Bitcoin protocol itself.
There are a significant number of additional issues inherent in Bryce Weiner and Andrew Desantis’ claims, but this article covers the major ones and should serve as a sufficient enough submission to the crypto community to debunk the claims of Bryce Weiner and Andrew Desantis.
If they are able to curate additional research, explanations, and/or evidence that validates their hypothesis, then the author is more than happy to provide another rebuttal on par with the original piece.
However, that’s unanticipated.