In spite of the mistaken claims given earlier in this thread, it is well established that the address contains funds taken from MTGox.  This has been well known to the Bitcoin community for most of a decade, but sadly the post quality here has become so poor that you can't even count on people to respond with well known facts.

A quick google would have quickly answered your questions: https://blog.wizsec.jp/2020/06/mtgox-march-2011-theft.html

As far as the ongoing tiny payments, dust payments to high value addresses is a common form of spam on Bitcoin.  If you look at the payers you'll see that many of them also pay dust to many other high value addresses.

If you're going through all the trouble to generate a key using dice you should be aware that all real dice are biased to some degree.  So you should either roll much more than needed and sha256 the result or you should use a debiasing procedure like the one in the codex32 booklet: https://www.secretcodex32.com/

Most people of the age of 45 (today) or so or older would have been taught to type on a typewriter or using typewriter technique:  You put two spaces after a period.  Word processors made this practice antiquated because their automated typesetting does it for you (technically putting a space and a half after a full stop).  Many people who originally learned to put in two spaces stopped if they've spent a lot of time using MSFT word, which nags you for doing it.  It's also not always clear when people are doing it because because common typesetting (including in browsers) doesn't render it as two spaces.

But for those of us who learned the typewriter ways and haven't been heavy MS word users the practice continues.

Here are some random pre-2008 (to show that I didn't do it because of Satoshi) mailing list posts by me where you can see me using two spaces after periods:

https://lists.cypherpunks.ca/pipermail/otr-users/2007-November/001181.html
https://marc.info/?l=reiserfs-devel&m=110878382927801&w=2

My usage is a little less consistent than Satoshi's and has gone up and down over the years (I think mostly depending on which keyboards I was using, weirdly-- I think I most consistently an extra space when typing on a model M-- most similar to the keyboards I learned on, and do so less consistently on a laptop.)  This is by no means unique to me-- scan around in other messages on those lists, mostly written by tech experts a little older than me and you'll see that many other people use two spaces after periods (even in some of the posts by others that I'm quoting).  It's also possible that this was or wasn't Satoshi's native style, but he might have consistently used it in order to leave less of a stylometry signature.  He was trying to conceal his identity after all (and it's not like stylometry was some unknown thing back then).

I think the fact that people keep talking about it like it's some kind of mystery shows the deep intellectual bankruptcy of the whole speculating-about-satoshi enterprise: the people doing it are too careless or too incompetent to sort out the simplest facts.

But also believe no one could attack ripemd160 AND believe that any break they had of secp256k1 wasn't fast enough for them to just steal your coins at the time you spend them (either by just double spending you with higher fee or doing a short reorg). ... and believe that the value of your bitcoin matters anymore when half of all coins in circulation get stolen.


I think this whole thing is an example of midwit optimization.  Technically adept enough to understand some details, but not enough to put them in a wider context that regards them as insignificant.

You can't use a coin without exposing its pubkey.  So in that sense hashed addresses are strictly less secure (because they can also be attacked through second pre-images and collisions).  One can argue that a race (or reorg) is required there and perhaps the mythical ECC cracker wouldn't quite be fast enough to win the race.  So then you're betting not just on there being an attack on the ECC but not the hash, but you're also betting that it will be slow.

But then you're left with the fact that at any given time half of all coins in circulation are stored in addresses with exposed pubkeys -- which means the system as a whole is already busted if there is even a slow way to crack pubkeys.  "I don't have to outrun the tiger, I only have to outrun you." only applies when its one victim vs another, but no one says "I don't have to outrun the nuclear bomb, I just have to outrun you".  It doesn't matter if *your* coins are secure when the economy is obliterated by half of everything else getting stolen.

And if you're imagining that the attack comes from future quantum computers there I haven't seen any argument as to how it could be slow: coherence time means that it will have to happen fast or not at all.  And that same device would also halve the number of bits of hash function security (e.g. from 160 to 80 bits) just via known generic attacks but it may allow finding better ones.

And at the same time the 160 bits of hashed addresses used in P2WPKH is actually security limiting: Their security against collisions is already only 80-bits which is at the uncomfortable fringe of tractable, this means that in usage models where collisions might apply (e.g. another party or less trusted device co-generates an address with you) the security of the 160-bit hashed addresses isn't just vulnerable to speculative attacks but real (if difficult) ones.

Of course, this design property wasn't chosen arbitrarily, not having to express a hash (which ought to be 256-bits because of the above issues with 160 bit) hashes in addition to the public key is a big space waste.  Even if you don't personally care about wasting resources or funds on fees, other people will-- an extra diversity in key types reduces privacy. (Which then ultimately undermines security since a lack of privacy makes it easier to target you for theft).

There were some cute proposals on ways to construct addresses such that there was a hidden hash inside the address, the knowledge of which could be ZK proven to provide a kind of rescue signature, but I think people haven't done much with that.  Alternatively, one could stick a QC safe public key in a taproot branch and then if this was widely done even if there was currently no consensus support for using those keys today, it could be softforked in if needed later (and the ability to spend via ECDSA softforked out) -- because the taproot commitments are still strongly binding against a quantum computer (well, at the same level a 256-bit hash is).  --- and I think these kind of moves would make a more meaningful difference in security than a blind gamble on an ecc break happening but not being fast enough to steal coins in realtime.

Progress on this though depends on having an environment where people with the ability to build this stuff want to participate.  I don't think that environment exists today.  I debated today if even giving this benefit-of-expirence reply was worth the cost to me, concluded it probably wasn't, but replied anyways for some reason: Mostly because I hate seeing people midwit themselves into bad positions,  that's how you ended up with people losing coins due to libbitcoin seed.  I'll probably regret commenting anyways.  But just making a comment on a thread is a much lower investment than actually designing and deploying something that people will use in production.

For most PRNGs it is not too hard to determine the seed just from seeing the output and often the seed is big enough to avoid finding it by guessing.  For a CSPRNG you cannot find the seed from the output (because the derivation function is cryptographic) or by guessing (because the state space is too big).  This makes all the difference in the world.

There are but they're kinda dangerous.  The issue is that it's often easy for a hardware RNG to fail in a way that makes it still look random but in reality it is somewhat predictable to an attacker.  The best way to use one is to take a lot of output from one, feed it to an expensive cryptographic hash, and use the output as a seed to a CSPRNG.  if its done this way then the result will be secure so long as there was enough randomness anywhere in the data to get the CSPRNG securely seeded.

If you want to be paranoid, after starting up that CSPRNG, get randomness by xoring the CSPRNG and the hardware RNG.  So then the result is secure if either the initial seeding and CSPRNG is good enough or the hardware stream is good enough.

When searching you also must impose the constraint that there is a primitive cube root of unity, as that's required for the endomorphism. This requirement eliminates a lot of curves.

As far as the -2^32 part goes, these numbers are Solinas primes, selected to admit fast modular reduction algorithms.

I doubt the creators of secp256k1 cared that the group order could also be efficiently used to form a curve. They cared that P admitted fast operations (that it was congruent to 3 mod 4 to make sqrt fast, and that it supported a fast modular reduction), that there was an efficiently computable endomorphism (which means that a=0 in the curve equation and that there is a primitive cube root of unity) and that the resulting curve order was prime.  They may have also somewhat cared that the order of the twist has a large factor, or perhaps they got lucky (I never checked if 160k, 192k, and 224k had secure twists)-- I'm not sure when people started caring about twist security due to fault attacks.
 

And why not mention dice or any other alternative?  Will their randomness be decreased if you speak their name? lol.

I doubt there is any rationalizing of this... no more clarity is going to be forthcoming.

I don't use github anymore but someone pinged me there, I loaded it-- only to see voskuil shitting on me: https://github.com/libbitcoin/libbitcoin-explorer/issues/728#issuecomment-1677195708  yet another reason to not use that site!

That kind of toxic deflection from his own errors using maliciously false personal attacks is exactly why development there gets zero review, and is probably the most direct causative reason for the vulnerability in the first place. Regardless of where you might land on how much the flaw was malice vs ignorance, in either case review would have caught it with very high probability had there been any.

As a request, please avoid invoking my name in discussions. I know people mean well but If I make an argument you find persuasive feel free to just restate it in your own words, without attribution.  I've had more credit than anyone needs in a lifetime, and invoking me just inspires asshole responses like the one there and I am really beyond tired of being shit on.

you can recover the MT state from the output even if the seed is big and random.  But it takes a lot of output and bx seed only outputs a single thing then quits.

So MT with secure seeding would probably be okay in bx seed (though fishy smelling), but wouldn't be okay in some other contexts.

Personally I'd never use MT for anything these days. There are alternatives that are much faster and have better properties, even where security isn't an issue.  It's a buzzword PRNG because it came into existence a time when people were using a lot of stuff that sucked a lot worse (and maybe because it has a cool name).

That might create an unhelpful equivalence.

There are CSPRNG  -- cryptographically secure pseudorandom number generators.  Once you feed in enough (say 256 bits) of genuine randomness they run deterministically and spout out as much random numbers as you want, which are generally just as good as new random values-- arguably better in that you're not exposed to a hardware trng flaking out or being slow.  Their main downside is that their state is a secret you have to protect.

Then there are non-CS PRNGs, like mersenne twister.   The output from those shouldn't be used for security relevant purposes because attackers can predict them from seeing some earlier output (or sometimes without seeing any output at all, for really bad ones).

Since bx seed just outputs a random value and quits the fact that it used MT itself wasn't really a problem, if it were seeded with enough cryptographically strong randomness the MT wouldn't have caused a practical harm in the context of bx seed.  It's the use of a 32-bits of seeding and that it came from the time rather than a source which had any chance of being secure.

Not really on modern computers-- they're equipped with a hardware TRNG.  And even without them computers with a user sitting at them have pretty good sources of timing randomness-- from keypress timings and mouse movements which the operating system records--  older hardware with no TRNG and computers with no local user are a more difficult matter.

It's really obvious in the code to anyone who reads it:

https://github.com/libbitcoin/libbitcoin-system/pull/559/commits/6d5a06e283d81260165e0eab95175069bf03b408#diff-e212c578b1951f97c871396a74c4224de9182ed922c8a95db56f995951743d17R42


        return static_cast<uint32_t>(now.time_since_epoch().count());
        ...
        // Seed with high resolution clock.
        twister.reset(new std::mt19937(get_clock_seed()));


It says directly that it's seeded with 32 bits of a high resolution clock.

Your comment conflates two concepts:

A deterministic wallet is one that can be backed up. Without determinism your backup is invalid as soon as you send funds or generate a new address, and that is obviously pretty unsafe and impractical.  A wallet using determinism works the same as one that doesn't except backups actually work.  It's possible to footgun yourself due to backups working, but I think backups not working is a much bigger footgun as it is highly surprising.  And one should be careful to not emphasize protection against theft over protection against loss:  at the end of the day if your coins are gone they're gone and it doesn't matter if they were stolen or if you just lost them another way.  Prior to determinism wallets would contain a small buffer of pre-generated keys, which didn't make backups actually safe but made their failure modes rather weird and inexplicable.

Users handling "seeds" (or private keying material) directly, as they're forced to if they use bx explorer, is obviously dangerous even for experts (as *every* user of bx seed must have been to some extent), and that isn't anything I proposed and I've also generally cautioned against. (In fact, BIP-39 has a warning against its use written by me on its comments page, in fact.).  Sometimes the two concepts get treated as one because if every key is randomly generated then manually handling the individual keys would be very clunky and inconvenient, so any kind of user handled seed scheme will in practice also be a deterministic wallet scheme both because of that practicality and because every wallet today is (because backups exploding is not desirable!).

While I worked on Bitcoin Core it didn't implement any user handled "seed" functionality because of how error prone it is.  (Though arguably if it did some of the people who used bx seed would have been saved: had bitcoin core had this functionality it would have been reviewed and implemented correctly...)

In this case BX's only function for generating keying material was insecure, this meant any keys generated using it (be they bare private keys or BIP39 seeds) were insecure -- so I don't think you can say that determinism OR 'seeds' were particularly relevant to the risk here.

The fact that the author has been resolute in the position that this wasn't an error means that this can't just be understood in terms of how easy it is to screw up.

You're confusing issues.

Libbitcoin explorer was only using 32-bit timestamps to generate keys via its 'bx seed' command.

The downfall thing is an issue on some processors where if you run malicious code on a processor it can steal parts of memory from other processes.  As you note, it's a concern for shared systems like cloud deployments.  But cloud deployments have MANY serious problems and downfall is only the latest in a long series of similar issues.   Certainly a concern but far far far less of a risk than just using 32-bits to generate keys.

It does, it makes the random number generator thread specific. See the code after "// Maintain thread static state space.".  Of course it could have made the RNG thread local with a much smaller commit which changed nothing except the fact that each thread got its own copy of the RNG.

No. libbitcoin is split into 11 different repositories, the flawed rng was in libbitcoin-system, used all over the place the supposed thread safety bug that motivated the change was observed in P2P networking.  But I believe bx-seed is the one and only generate-your-private-key thing in the whole caboodle.

The division of the software into many repositories probably contributes to the lack of review/oversight and wider participation in development there.

I think there are good odds that for any platform where the code can actually be built that function just read randomness from the OS, but you're right that it isn't guaranteed.

Basically it seems they changed from code that had security problems in theory but usually not (and maybe never) in practice to code that was certainly broken all the time for everyone in both theory and practice.

The timer is a high resolution (nanosecond) one and it uses the least significant bits of it, so it loops every 4.2 seconds or so.  But depending on the platform not all the bits will be used, e.g. mac i think only has microsecond resolution.

In any case it shouldn't matter because optimized code will make fast work of all 32-bits.

But there isn't any test it's used for I can find, and its used in all the documentation any place a seed is needed. I also can't find any instructions in their docs on how you *should* generate the seed.  Like if you want to use dice you still need a procedure to de-bias the dice (and to get hex out). I don't buy it, it's just not a credible excuse to me. To be clear, I'm not suggesting that it was intentionally vulnerable, but that it was just mistaken and that a rather non-pragmatic view on what users will or should do caused it to not get as much care as it ought to have.

It's also likely bad for the non-cryptographic usage in libbitcoin. An attacker can observe some of the choices made by the software you can recover the RNG state then use it to predict the random choices that were used and will be used, which likely results in DOS vulnerabilities.

On modern computers there is seldom a reason to use very poor randomness.  The only time these days when I use non-cryptographic randomness is for the inner loops of optimization search code where the RNG is very performance critical.  In those cases I'll use xoshiro256++ periodically seeded with rdrand (the hw RNG on modern cpus). But in any ordinary software it's uncommon for the rng performance to matter so much that you can't use a cryptographic one.

Maybe in some usage or another using a crappy PRNG with weak seeding wouldn't be harmful, but it's usually not worth the cost of figuring out if its safe or not (and making sure it stays safe as people change code), better to use a safe thing unless and until the performance is an issue and then figure out if something faster can be used safely.

This is bad advice and I would strenuously recommend against it. Many non-software licenses do not contain an expansive waver of liability (except sometimes for representations related to the copyright status of the work) e.g. CC0, FDL, LAL. all lack one.  Many other licenses also have problematic terms such as explicit non-waving of patent-rights (e.g. CC0, CC-By-4, CC-By-SA-4).  The FreeBSD-DL is essentially the same as the MIT license but with freebsd and documentation written all over it, perhaps fine but not an improvement unless you happen to be named "FreeBSD".

Even ignoring andytoshi's point about the document itself being a postscript program, the scheme Codex32 is itself software: it's just designed to be run on meat and paper rather than on metal.

They made a similar post on reddit, I responded with some questions but they haven't responded.

If I had to make a bet I would bet they actually used bx to generate their seed and are confused about the history.  I very much would not be surprised if the bitcore software were vulnerable (considering the history) but having the exact same vulnerability seems unlikely.

It seems really credible to me that someone could generate their bip39 seed with one tool and think it was another-- they might have even evaluated both.  I think that's more likely that the bitcore code containing the same vulnerability.

Yes.

Cannot is a little strong, but it would be slightly surprising.  OTOH, it would be less surprising than the original error in libbitcoin explorer itself.

I could imagine some web service wallet thing using it on the backend but it would be an odd choice... or managing to copy the vulnerable code into other software though there was nothing subtle about it.