118 sats \ 0 replies \ @shafemtol 6 May \ on: Bitcoin trader loses almost $70 million after sending crypto to wrong address econ
AIUI, the scam works by scammers sending the victim a small amount "from" an address that has been brute-forced to look like some other address that the victim intends to send their money to.
Reading the explanation, I was surprised how that would work, as normally you shouldn't even see a "from" address on incoming payments in any Bitcoin wallet software, because there really is no "from" address in Bitcoin.
But apparently this was with some kind of "wrapped BTC" on Ethereum, where I'm guessing this scam works better.
An Electrum user having the same problem suggests to me that it could be an issue with the Electrum server.
Is your Sparrow wallet set up to connect to an Electrum server? If so, have you tried connecting to a different server?
Back in February last year I started trying to save testnet from the block storms, modifying my CPU miner to set a timestamp 2 hours into the future on the penultimate block within each difficulty period. Thus the network would be safe from accidental block storms for 2 hours and deliberate block storms for 20 minutes. The hope would be that this would be long enough for an ASIC miner to find a block and thus keep the network safe for the following difficulty period.
I also argued for a soft fork to fix the block storm issue (Lopp had claimed that fixing it required a hard fork).
I didn't run the miner the whole time, so I missed the difficulty adjustment quite a few times, but I do believe I prevented a block storm or two.
Then back in March/April when I was looking to see if it was time to start the miner again, I saw the testnet blocks and mempool were full of crap transactions, so I gave up on the project of trying to save testnet.
Thinking about the timestamp overflow issue a bit further, it could have been implemented as a soft fork by exploiting Bitcoin's time warp bug. By my calculations this could extend the lifespan of the existing chain by some 240 thousand years.
However, after the activation of BIP113 in 2016, a time warp exploit is no longer a viable option as there's no way to do make timelocked transactions with a far-future timestamp spendable at the appropriate time.
But that part could be addressed with a forced soft fork at worst. So my point still stands ("tis but a scratch!"): Bitcoin will "never" need a hard fork.
I had forgotten about the timestamp overflow issue, but that would be the kind of hard fork Bitcoin would need if it would ever need one.
That kind of hard fork doesn't necessarily have the same problem that most other hard forks would have, though. At some point it would be completely impossible to progress on the old chain. If the fork activates at that point, there's no actual chain split, old nodes will simply be stuck on an old block.
In practice such a hard fork would be more similar to a forced soft fork.
Bitcoin will never need a hard fork, but if it will need one, it will be a security related one.
In a hard fork, old nodes will stop following the same chain as forked nodes (if there are miners among the old nodes, there will be a chain split). However, virtually any change can in one way or another be implemented as a soft fork, where old nodes and new nodes still follow the same chain (at least as long as the majority of hash power implements the fork).
Post-quantum signature schemes can be soft-forked in as a new script version, just like what was done for Taproot.
A sudden and complete break of the secp256k1 curve could arguably be a good opportunity for a hard fork, if only to force everyone to upgrade their nodes lest they risk revealing the keys to still-unspent P2PKH/P2WPKH coins through their thence insecure public keys. A fork could then require proof of an OTS-style timestamp (from several hundreds or thousands of blocks prior) of a commitment to spend such coins before allowing them to be spent.
Looking at the transactions, pretty much all of them contain an
OP_RETURN output. From what I've gathered, there's supposedly some new kind of shitcoinery that's been activated since block 840000.I've always thought of "halvening" as a mostly tongue-in-cheek portmanteau of "halving" and "happening".
I modified the search function to search a random, representative subset of the search space, so that the total number of valid 12-word sets can be accurately estimated without an exhaustive search.
In 133 CPU-minutes I searched 1/10,000 of the space. My original goal of an exhaustive search would thus have taken 924 CPU-days, so I'm not going to attempt that.
The search returned got 67,672,354 unique 12-word sets that match the scrambled letters. That means the total number of unique matching 12-word sets is about 677 thousand million. Each one of these sets has 479 million possible permutations. That gives a total of 324 million million million possible word sequences. Of these, 1 in 16 will pass the 4-bit SHA-256 checksum, making a valid mnemonic. Each valid mnemonic must have its master private key derived, which involves 2048 iterations of HMAC-SHA512.
The expected number of SHA-512 operations required to find the correct private key is around 21 thousand million million million, or 2^74. That is comparable to the work currently required to mine a Bitcoin block, about 2^78 SHA-256 operations.
For comparison, given 24 unique words of a 24-word mnemonic in random order, the expected number of SHA-512 operations required to find the correct private key is 2^85, i.e. 2000 times higher.
So my conclusion remains: Finding the seed is probably doable with specialized hardware, but it is nowhere near cost-effective at a 100k sat prize even discounting the hardware cost.
Another hint:
@LaserEyesLeah I assumed no repeated words to make it easier to code. I found 565 sets of words that are scrambles of the given letters. Each of these 565 sets has 479 million possible orders. It is crackable but someone would have to be highly motivated.
@asanoha_gold Replying to @LaserEyesLeah No repeated words! Thank you for checking! What do you think the reward would have to be to make it worth it?
I take this to mean that there are 12 unique words, no duplicates. That seems to reduce the number of unordered combinations by approximately 20 to 40 percent.
Also, someone tell LaserEyesLeah they need to check the truncated forms of longer words as well, blowing the number 565 up by a factor of several million :)
One potentially real case would be one in which a Cryptosteel or equivalent has broken apart and scattered the individual letters, leaving only a few initial letters from each row still intact. That would result in a much smaller search space.
So far I've found ~1000 million matching unordered combinations, still far from complete. Search is returning about 1 million new combinations per minute.
There was a new hint published giving what is presumably the master public key:
zpub6rW2NmPTbNjFkng8Do79zp4zkstGtaCont5drCZCbPfNuQsVU6N8Qguf8PmoYKaDoJtgH8Dehvk6ukGbBzHKyEYrZUeuS1zvn8BNcGEH6tj
Currently I'd estimate an exhaustive search of all permutations of all possible word combinations to take at least 2^67 SHA-512 operations. The expected number of operations needed to find the correct seed would be half that, i.e. at least 2^66 operations.
For comparison, mining a single Bitcoin block currently takes about 2^78 SHA-256 operations. That's up to 4000 times as many operations. That's with specialized hardware, and SHA-256 might take a little less work compared to SHA-512, and the prize is higher, currently at least 6.25 BTC.
So finding the seed is probably doable, but not cost-effective at a 100k sat prize.
Had to record a video of the output during search.
Still going at 64 million unordered combinations so far, no end in sight.
After optimizing the search function to achieve a speedup of several orders of magnitude, I'm currently running it against the full wordlist.
It's even worse than I thought. So far it's found more than 20 million possible unordered combinations, and there's a lot more to go. It's crazy to watch all the results scrolling across the screen.
I miscalculated, it's 12 times worse 🤣
For every combination of 12 unique words, there are 479,001,600 permutations, not 39,916,800.
I've managed to enumerate all possible word combinations (unordered) of the reduced set of the 3- and 4-letter (not truncated) words. There are apparently 1110 of them. Each one of these then needs to be tested for all its permutations (there are 39916800 for each of the combinations with no duplicate words). So from these there are up to ~40 thousand million seeds to test. Of these, 1 in 16 will pass the 4-bit checksum and need a more expensive test to match it against the published address.
I do still believe, however, that the actual seed includes longer words, in which case the possible word combinations (unordered) are possibly hundreds of thousands.
There are 10 four letter words and 2 three letter words
That is ambiguous. I do however believe that what is meant is that those words are four letters long only after truncation, from the sentence that follows:
All of the first four, and three, letters of each word are what I have provided.
(emphasis mine)
From those 602 words, there are some words with too many
ms or ts. These can also be filtered, resulting in 574 possible words:cut -c 1-4 <english.txt | grep -E "^[$SCRAMBLED]+$" | grep -Ev 'm.*m|t.*t' | wc 574 574 2833
FractalEncrypt said he got the list of words down to 547 and I'm not at all sure why he got that number of words.
I didn't see a mention of 547 in the linked post. Could it have been 574?
Looks like you've made an error when filtering the words.
The wordlist first needs to be truncated to the first 4 characters before filtering:
All of the first four, and three, letters of each word are what I have provided.
From that, I get 602 valid words:
SCRAMBLED=pqnieoeuoeheisfppspmecsacaosohegntigujgpeiafss wget https://raw.githubusercontent.com/bitcoin/bips/master/bip-0039/english.txt cut -c 1-4 <english.txt | grep -E "^[$SCRAMBLED]+$" | wc 602 602 2972
And Unicode also has an emoji variation selector U+FE0F, which requests that the preceding character should be rendered as an emoji. Thus, Unicode already has a unique, backwards-compatible encoding for the Bitcoin emoji:
₿ (In the future, with a supporting font, you should see this as a Bitcoin emoji)
U+20BF BITCOIN SIGN
U+FE0F VARIATION SELECTOR-16
It would be considered non-standard until sanctioned by Unicode, but fonts may already be able to implement this. All Unicode needs to do is include this sequence as part of the standardized variation sequences.