I've considered that-- esp since we know the account was compromised at one point, but if that happened you would have expected gavin to say that Wright knew about that stuff and AFAIK he never did.

One thing people don't know is that the idiots at the bitcoin foundation named 'satoshi' a board member (without his consent, obviously) and as a result copied the satoshi mailbox on all their board communication.  So perhaps there was an opportunity for a hacker to exploit that information without directly showing that they were aware of it----

At least three BCF board members were bamboozled by (or complicit with) wright, now this might be because BCF's composition was unusually rich in idiots and scoundrels but it could also be because after monitoring years of their presumed private communication wright knew exactly which buttons to press for each person and was able to hack their confidence by echoing their own opinions back to them.

Yeah, shame on me for being lazy and not linking it.

https://www.courtlistener.com/recap/gov.uscourts.flsd.521536/gov.uscourts.flsd.521536.647.1.pdf   Items 319, 341.

Hopefully the communication between Wright and Andresen gets made public.

Kinda crazy that Wright is objecting to it on grounds of it being inauthentic, among other things.

In the Bitcoin community people did pretty robustly ignore him, but that actually played into his favor.   The problem is that ignoring him looks like uncertainty, -- the community didn't make it clear that wright's claims were unequivocally and absurdly false.   That left room for people who were stupid or unethical to propagate endorsements, because it wasn't unambiguous that they'd be instantly market as idiots or scammers.

Absolutely-- Gavin and Jon Matonis have a lot to answer for here, similar but to a lesser degree for Roger Ver, Cypherdoc, and other prominent (former) community members that promoted wright.  At least Ver has publicly withdrawn his support, though it took an astonishing amount of time and nagging.

The state of journalism these days is that many outlets will publish extremely sketchy speculation as fact ... so the endorsement by those figureheads has been decisive in the continued treatment of wright's obviously fraudulent claims as credible by the media.  And the media's representations have been critical to wright maintaining a collection of victims and conspirators.

The support of wright's fork(s) by exchanges have also gone a long way: they lend legitimacy, they create an avenue for third party downstream scammers to fund themselves by promoting wright, and they directly finance the scam by creating an avenue for the scammers to pump/dump on the news cycles they create.

Dunno why you'd assume it was hard.

Turns out Andresen had a contract with Wright-- it's one of the pieces of evidence in the florida trial, but Wright is trying to get it suppressed.   It will be interesting to find out what it says.

Unfortunately it's hard to safely implement a RNG in a C-callable and OS agnostic way that is thread safe, fork()ing safe, and being fork/thread safe is pretty important for this sort of thing.   Within Bitcoin Core it's easier because it's all C++ and threading/locking is accomplished in a particular way and the project can guarantee that it's not going to fork() and do something bad.

There are ways to handle fork safely but they're ugly and not particularly portable.

The proc reading stuff is system specific though the code in Bitcoin core already supports handling the normal platforms bitcoin core runs on (linux/windows/osx/openbsd/freebsd/windows/etc.).

The standard practice of automatically characterizing specific actionable criticism as an unsubstantiated emotional response ('hate') is an indication of defective culture that puts users at risk.

I don't hate any of it-- it just has an objective history of both theoretical and actual flaws which have lost users money, and AFAICT little has been done to address the process errors which allowed those flaws to end up in production (and for some of the issues, it's not clear to me that much really can be done).

Not reusing addresses might make some leaks harder to exploit but it's an extremely weak protection,  particularly because the user themselves is not actually in control when it comes to reuse -- someone can send funds with multiple outputs and there isn't much they can do about it.  It's also not realistic because users widely and regularly reuse addresses regardless of what advice they're given, and some services essentially require them to do so (e.g. by only allowing a single static withdraw address.).

To me that seems more like blame shifting rather than an actual protection for users. "We told the drivers of the pinto to drive carefully and not get in any collisions! It isn't our fault the cars exploded on them!"

I would not use any javscript key generator.

1. the underling cryptographic software is almost entirely untested.  For every JS ecc library I've seen the tests consist of a couple static test vectors.  The underlying software has previously had bugs where it would frequently (e.g. one out of a few hundred to few thousand uses) generate an incorrect pubkey and even since the tests have not been improved to the point where they would catch such flaws.  The extremely poor performance of the JS enviroment would make such testing burdensome and the inconsistent execution environment makes testing less useful.

2. Javascript VMs are extremely complex and have a long history of incorrect computation bugs.  As referenced above this means that even if robust testing did exist it would really need to be executed for each user.  Corruption by JS VMs have resulted in incorrect key generation.

3. Access to strong random data in the browser/js environment is limited and extremely fragile.  Widely used libraries for accessing strong randomness have had flaws where they returned extremely weak randomness that went unnoticed resulting in funds loss.  JS dynamic loading and overriding behavior makes it hard to nearly impossible to review a piece of JS code and be confident that what you think is running is actually running.  The extremely difficulty of competent review means it substantially doesn't happen.

4. Web page applications are subject to remote replacement unless your usage is just perfect and there are absolutely no externally loaded pieces of content. Even running with a machine unplugged from the network is not an absolute assurance because there may be cached remotely loaded content that could be replaced while the system is online.  A system which is only secure with perfect use is simply not secure because no human is perfect.

5. the JS loader/linker solution provides no strong guarantee that the various modules implementing a program are atomically updated. You might get a newer version of an application but be using a cached copy of older modules in other files, the two could be silently incompletely.  This has resulted in total funds loss for some users of one web wallet in at least one instance in the past.

6. Uniformly JS implemented cryptographic code has absolutely no protection against timing, cache, power/emi side channels.  It is far from clear if it is even possible to do so.  Even if your threat model does not include physically present attackers,  pratical demonstrations have been made where JS code running in a separate tab are able to steal cryptographic data from unrelated tabs via these sidechannels.  If it's not even possible to implement the basic best practices this may create a bad culture that doesn't even bother being good (as evidence by the lack of testing) since being great isn't on the table.

7. No JS implemented key generation code that I'm aware of performs after the fact validation of its operations, so even if the software is perfect a bitflip can cause an incorrect key (or a private key leaking signature), resulting in a total loss of funds.  (By contrast, Bitcoin core validates key generation and signatures after the fact).

8. The aforementioned issues mean that most competent developers and reviewers won't bother making or reviewing these things, greatly increasing the odds that any such tools you use were not made or reviewed by competent persons.


As far as OS RNG's go, unfortunately /dev/(u)random on a number of systems has multiple instances of insecurity (e.g. see netbsd).  The RNG in Bitcoin core is hardened against weakness of the OS rng by using a hash to combine the OS rng, hardware rngs (if available), and various sources of non-cryptographic entropy (timestamps, network counters, host info, etc.) and passes the result through an computationally expensive hardening function so that even if there is a total failure of cryptographic entropy you still have a fighting chance.

Turn off twitter and other gamified social media and you'll stop getting fed quite a bit of concerning nonsense.

You still holding this position franky1?

"Bitcoin Association" (nchain staff operating under another name) have pretty much announced that they intend to help Wright steal those BSV that he's demanding.  

True, most of them are coins rightfully belonging to MTGox creditors, but give him time...

Pilfering the BSV side of just these 111k coins will yield $21 million dollars -- that will fund plenty of bullshit litigation.

No, you're confused.  The next major version after 0.21 will be 22, but consensus changes are not activated in major releases (as they contain lots of extra features that might make some users unable to upgrade or force them to downgrade).


Development works like this:


0.19.0 --> 0.20.0 --> 0.21.0 --> 22.0 --> ...
     \          \          \
     |->0.19.1  |-> 0.20.1 |-> 0.21.1
     |->0.19.2  |-> 0.20.2 ...
     |->0.19.3  ...
     ...


So the minor releases are all forked off an earlier copy of the software and have fixes back ported to them.

The post you were seeing was discussing dropping the "0." in the master branch.

Not in a meaningful sense.

When new consensus changes are added to bitcoin they are added in advance, completely deactivated and inert.  Later a version will be produced that doesn't change anything except arming the activation.

This avoids the risk that activation will be interrupted by unrelated issues in a new version.  It also gives more time for developers to test the fully integrated version and reduced risk that issues introduced by merging will go undetected.

So 0.21.0 doesn't have taproot support and will continue to not have any taproot support even after taproot activates.

Which has what to do with this thread?

The point of my last reply is that I assume there is no 'message' in these cases,  instead of some material hashed the values were just chosen in order to result in the singularity.

It's not really an ecdsa signature if you're just handed a hash.  Performing the hashing is integral to the process and without it you can generate all sorts of degenerate examples. ... including 'forged' 'signatures' for pubkeys where no one knows the private key.

xmready, why do you keep posting that image?

It's really hard  (impossible?) to make generic software to handle arbitrary scripts.

But this case can be done with existing standard software, just inefficiently:  Make a 3 of 8 multisig where the primary signer controls three of the keys.

As typical the description is overly convoluted. As a result pooya87's script can be simplified.

In the description the signing pubkey can take the coins completely.  That means that there is _absolutely no purpose_  to trying to delay the signing key from changing the "guardians":  The operator of the signing pubkey can just take the coins and move them to a new location (potentially with new guardians.).

In the description the guardians aren't delayed at all, this seems stupid to me, given the purpose is recovery but it's what is described.

As a result,  the script just turns into a 1 or (3 of 5) multisig or a 3 of 6 weighed threshold with the first key having weight 3.

W/ taproot this could be implement so that in the likely case where the guardians aren't required the txn are indistinguishable from a normal single key txn.

It would probably make sense to stick a couple week CSV  in the guardian branch so that if your guardians are compromised you can still prevent them from stealing the coins-- and if it's a recovery mechanism the delay won't matter much.

It has no error protection, swap two words and millions of dollars vanish into a black hole.  Maybe that kind recklessness is acceptable in ethereum but it doesn't fly in Bitcoin.

Bitcoin addresses are also not carrying 160 bits of data, they carry a 5-bit version and up to 40 bytes of payload, although 160 and 256 bits are commonly used now.  160 bits implies only 80-bits of collision security which is not really adequate when multiple parties are involved.

BIP39 really wasn't intended to be decoded, in BIP39 though an encoding mapping is specified to generate uniform mnemonics the inverse isn't used.  It's done this way so the word list is not normative-- different parties can use different wordlists.  Only part of the world speaks english and an english word list is pretty difficult for some to use.  Schemes that depend on decoding can't be compatible with different wordlists.

In informal testing I found that word encoded addresses were much slower and more error prone (e.g. people enter sounds-alike words or just misspell them) to enter than alphanumeric (so long as changes in case are not involved, mixed case alphanum is extremely slow)-- so I'm dubious about there being an actual benefit.

Fixed by harden keys.  Things that don't use harden keys shouldn't allow export of individual keys.

It's fundamentally impossible to 'fix' for non-hardened keys, the best you can do is make it tolerate leaking N keys for some N which the extended pubkey is linear in the size of... and most cases where you could leak one key you will also leak N for any small reasonable value of N.

It's like saying numbers are "flawed" because if I tell you I derived a number by adding a number known to you to some unknown number, you can then derrie the unknown number by subtracting.  In fact, that is _literally_ what is happening in this case:   Public derivation generates more keys by just adding known values to a master key.  You can get the other private keys from any private key just subtracting those numbers from one of the children.

This property was known from day one-- but people have applied public derivation far more widely than I ever expected it-- including in lots of places where its a liability.

It's really just a category error to think of there being multiple keys with public derivation. There is really just a single key.