Because the hashes are much shorter than the input data there an infinite number of second preimages for almost any hash. If that weren't true it would result in statistical discrepancies in the hash function that would distinguish it from random.

If you can compute a second preimage of a arbitrary hash you can already steal any coin, e.g. by replacing the transaction someone signed by another transaction, or even by replacing transactions in the ledger. Bitcoin has an absolute and total dependency of the second preimage security of SHA256.  Nor would it be particularly feasible to construct an alternative system which didn't have similar security requirements.

Fortunately the security history of well studied hash functions against second preimage attacks is extremely good.  Even old and busted hash functions like MD5 and SHA1 still stand up pretty well to second preimage attacks.

Bitcoin Core with its current feature set without having another implementation that they could gawk at.

If you drop features or assume the other programmer could read Bitcoin Core's codebase than it would take a lot less time -- which is part of how there are a number of other implementations.

These figures don't include time for research and design, however.  And if you didn't have access to Bitcoin Core (or similar) there would be a substantial amount of that required.

For example, Bech32(m) has a really solid man year of R&D time in it alone, even though its implementation is short (0.15kloc. 0.25 person-months per COCOMO).  There are a number of small parts of Bitcoin Core that were novel tech which had much higher R&D costs than typical for industrial programming problems.

So the COCOMO estimates assume that you've received the high level design and feature requirements as inputs and are not doing a large amount of novel invention and research (though it does assume you're doing some), but it also doesn't assume that you've got access to the source code of another complete implementation.

It really depends on what you're asking, exactly.

Attacks against ECDLP allows you to solve multiple ECDLPs for only very slightly more work.

The security increase from bitcoin multisig comes because some of the participants may be untrustworthy or because they're unable to keep control of their private keys (hacks, etc.).  This same benefit is also provided by true multisignatures.

Multisig is an pre-existing term in cryptography that predates bitcoin, E.g.:


The bitcoin checkmultisig fakes a traditional mutisignature with a collection of single signatures because defects in ECDSA (which exist because ECDSA was created to avoid schnorr's patent) make it extraordinarily complicated to implement a true multisignature with it.  With Schnorr, you don't have to fake it.

However, in taproot you still can use a collection of single signatures if you want. Why would you? Not for security but because a schnorr multisignature requires two passes while a fake multisignature can be done in a single pass, or simply because you have software for one and not the other.

If you were using multisig with all the private keys just on a single device-- that's snake oil. It isn't practically increasing your security.

Some people? You mean ... all people, right?  There isn't a way to shortcut it: You can't sign without getting access to the requisite private keys. (assuming the hardness of the hash functions and discrete log problem, of course).

That is extremely vague. Do you expect a useful reply?  Your non-question post seems like a fake question.

In reality the old checkmultisig is the fake multisignature:  It's not a true multisignature but one faked by just having a bunch of regular signatures and applying some logic after the fact.

You can still use that kind of explicit fake multisig if you want to, but but it's inefficient.  M*32 bytes + N*64 bytes ... instead of just 32+64 bytes. You can also do other variants with different tradeoffs.  Like a tree of N choose M leaves (size 32*ceil(log2(n choose m))) plus a M of M signature (size 32+64).


Any M of N multisig is only as secure as the N-Mth most secure key in it.  Same is true for a fake-multisig as it is for a true threshold signature.

sloccount run against current git-master, with leveldb removed (since that was developed independently of Bitcoin):


Total Physical Source Lines of Code (SLOC)                = 208,911
Development Effort Estimate, Person-Years (Person-Months) = 54.57 (654.89)
 (Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months)                         = 2.45 (29.38)
 (Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule)  = 22.29
Total Estimated Cost to Develop                           = $ 7,372,266
 (average salary = $56,286/year, overhead = 2.40).


So-- it says 55 person years.  Of course, this kind of estimation is a bit bullshitty, but it's about the best you could do.  Bitcoin is a lot trickier than many of the industrial tasks used to calibrate those estimates, otoh the industrial developers those estimates are based on are a lot less productive than some that exist.

There has been more than 55 person years put into the codebase for sure.

In this thread: https://www.youtube.com/watch?v=YtLEWVu815o

FWIW, lightning already lets you use smaller amounts.

CHECKMULTISIG has a stupid design where it has to use trial and error.

Say your stack looks like 0 [sig3] [sig2] 2 [pub3] [pub2] [pub1] 3  with sig3 and sig2 being signatures with pubkeys 3 and 2 respectively.

The validation will first attempt to verify with pub1 and sig2, which will fail. Then it will try pub2 and sig2 which will be successful.

This is pointlessly inefficient and in a batch validation *no* signature can fail or otherwise the whole batch fails. In something like a 1 of 20 signature every node could be forced to process 20 failing signatures just to find the one passing one.

Perhaps Satoshi had intended to use the dummy value to indicate which signatures were in use, but that was never implemented.

The checksigadd construction avoids the inefficiency and makes batch validation possible-- because no checksig(add) input is allowed to fail except for an empty signature regardless of what the surrounding script does.  It also works equally well for weighed thresholds without losing any efficiency.

The best tool we have is mockery.

Among well informed people they look at Wright and see an obvious fraud-- so they turn away: nothing to see here.  But people who don't know better are fooled. Reliably.  They might believe a "lite" version of his scam-- like that he was involved and was exaggerating his involvement, or that he wasn't satoshi but really had 111k BTC that was stolen from him---- and a big part of that is because Wright's paid press activities are substantial, while the opposition is mostly silent and uncoordinated.

We need to all go out and make sure that the whole world knows that wright and his congames are jokes.

Satoshi continue to communicate with developers in private for some time after.

In April 2011 Satoshi emailed Gavin (and in part criticizing him for failing to credit other contributors work on Bitcoin). Gavin replied that he would be visiting the CIA. Satoshi never emailed anyone else again. (unless you want to believe the messages from years later after the accounts were known to be compromised were satoshi)

They don't actually care about this judgement, they want Cobra's identity so they can harass/threaten him and/or fabricate false evidence in an attempt to steal the domain.  Last year they offered him $10 million dollars for it, unsolicited, as an opening offer and they seem to have been making it clear that no isn't an option.

So it's not too surprising that they are willing to endanger their ability to collect on this 'small' default judgement. Whats 35k UKP compared to what they're willing to pay to get that domain?  It's a rounding error.

The challenge here is that the UK system seems to have no avenue for cobra to defend in these actions without doxing himself, which would expose him to worse attack.  Fortunately, the UK's power of bitcoin.org is appears to be minimal.

You remember incorrectly, Satoshi abruptly cut off communication when Gavin emailed him to say he would be meeting with the CIA. Gavin himself has speculated before that this is why Satoshi went away. As doomad notes, this should totally have not been a shock.

Back on topic... Cobra is still trying to pay as demanded by the court, but ontier is evading every effort (cobra is copying me on the emails).  Ironically, they've stopped attaching their own name to their communications with Cobra.  "Anonymity for me but not for thee".

This code does what you're asking for:

https://github.com/bitcoin/bitcoin/blob/master/src/wallet/coinselection.cpp#L21

(Actually, somewhat more-- not only does it bound the fee over-payment, but it finds solutions that pay at least a given feerate-- though it could be run with a feerate of 0 to give more of what you're asking for)

Bitcoin core will produce changeless outputs when it can... and it can pretty often for wallets with many inputs.


That would work but has factorial complexity, which is actually a problem on practical wallet sizes. More efficient is possible.

Demanding to know Satoshi's "real" identity, totally out of the blue.

Particularly with Gavin-- no surprise if you knew what Gavin's first message to Satoshi was...

And "could have been leaked"-- is that how he rationalized handing it over to Wright?

He already managed to get a copy of all Gavin's private communications with Satoshi from Gavin...

He vaguely alleges it was stolen from him. Of course, he's absurdly vague because he knows nothing about Cobra or the history of the domain (beyond whats been posted) he's currently unable to usefully construct any forgeries to support his lies.  It's a safe bet that a big part of why he's obsessed with doxing cobra is to facilitate taking the domain by force.

The primary site to download the software is https://bitcoincore.org/en/download/  and has been for years.

I only glanced at the multisig section.

The scheme there is grievously insecure, and you should put a more explicit warning on your tutorial because people will follow stuff like it even with notices that it hasn't been reviewed.

Imagine Alice has pubkey P_a, then Bob sets his pubkey P_b =  P_c - P_a.

If you make a combined pubkey P = P_a + P_b then P = P_a + P_c - P_a = P_c.  Bob can sign without Alice's help.

The same also applies to the nonces:  If Bob sees R_a first he can set R_b based on it and cause alice to make a signature with a known nonce, and then he can extract the private key.

Secure multisignatures are possible but what you've described isn't one.

https://eprint.iacr.org/2018/068

https://eprint.iacr.org/2020/1057

Give secure and peer reviewed schemes.

Well not no point, it provides at least some indication that they probably haven't accidentally downgraded their configuration.

(but not much, since essentially all signaling is not driven by the node itself)

The discussion here just seems to be looping and getting increasingly heated. I think people have said what they want to say on the subject.

Further threads about non-pow will get punted to the altcoin subforum for the immediate future.