The schnorr patent (not copyright) had expired by the time Bitcoin was created.  But there were no mature or standardized industrial grade implementations of a schnorr ECC signature until a couple years later (I believe the ed25519 work was the first and it was published in late 2011).

Sounds like you might have been fed some disinformation.

Versions 0.14 to 0.16.2 had a bug where a rogue miner could have made a transaction which consumed the same input twice. But this issue was caught and rejected by the startup sanity checks.

The issue was discovered by developers and corrected in 0.16.3 and later versions.  No attack block had been created, and if one had been created before the fix was published it would have been ultimately rejected because it was caught by the startup checks and by earlier versions so ultimately the effect would have been just a very costly DOS attack by the miner.

The issue was introduced because:

The original check against duplicate inputs didn't apply to mempool transactions, so these junk transactions could end up in the mempool. To protect the mempool an additional check was added.  IIRC this would have been in 2011 or 2012.

Then in 2013, 0.8 changed block validation logic significantly and accidentally removed the block validation rule against duplicate inputs. However, this wasn't discovered even with an extraordinary amount of review and testing at the time because the "redundant" check previously added was sufficient.

Then in 0.14 the redundant check was bypassed while validating blocks to speed up block propagation and make Bitcoin able to handle larger blocks without blocks becoming stale.

Unfortunately, unknown to anyone the non-consensus "redundant" check had become critical.  While there were ample tests for double spends, they didn't happen to cover the specific conditions required to bypass the checks.

Transactions don't have any timestamp at all.  They may, however, have an nLocktime.

nLocktime can be time based or height based.

If nLocktime is time based it is not based on the current time, it is based on the blockchain's median time past.

A transaction with a time based lock won't be relayed until it can be included in the next block coming up.

What do you mean by erroneous?

The protocol requires that timestamps be greater than the median of the last 11 blocks and less then 2 hours into the future from your own perspective.  If you get a block more than 2 hours in the future you won't accept it until its within 2 hours.  Any timestamp that passes these criteria is valid, anything else will be ignored.

Time based locktimes aren't based on the time on the current block anymore, but instead are based on the median of the last 11 blocks (the lowest timestamp the block could have).

The allowed 2 hour difference on the blocks timestamp allows a one time 2hr/2week = 0.5% difference in inflation, -- utterly irrelevant and well below the noise.

Bitcoin's requirement for accurate time is *extremely* loose.  A sundial and an almanac is pretty much sufficient.


It's likely that the person you're quoting is confusing multiple different uses of the word 'clock'.

Bitcoin only has a timestamp in it at all to keep the inflation schedule on track and make the infrequently used time-relative locktimes work.  If we didn't care about those features it could just exclude the timestamp entirely-- and it would still be a clock, one that just ticks in the form of blocks.

Anyone who said that was an idiot or just trying to make themselves look greater by alleging a great work was lesser.  It's simply not true.

It is true that Bitcoin today does a lot more than the original software did, and does it with a lot more performance and to get there required many changes.  The fact that the original code wasn't built that way wasn't a deficiency.  In fact, if the original code had been built with the structure suited for the later feature set that would have been a lot of unnecessary and bug-introducing complexity.

And if you ever could compute it, then you have the contributing keys and could just spend the coin.

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.