He has a complicated web of half a dozen companies, going back several years, whose main sources of revenue seem to be private investment and subsidies given by the Australian government to R&D companies.  To justify the latter, he used deals between his own companies and his family trust fund.  At one point he claimed that one of his entities bought private software from another of his entities, for tens of millions of dollars -- allegedly paid with bitcoin.  And he tried to use that deal to get more R&D subsidy money.

So, for several years he has had two possible motives to pretend to be Satoshi: to dupe investors, and to explain to the Australian government how he could have so much bitcoin.

This would not be the first time that a con artist managed to get the endorsement of specialists.  Hardly.

https://en.wikipedia.org/wiki/Piltdown_Man

https://en.wikipedia.org/wiki/Cottingley_Fairies

https://en.wikipedia.org/wiki/Uri_Geller#Scientific_testing

https://en.wikipedia.org/wiki/N_ray

https://en.wikipedia.org/wiki/Water_memory#Benveniste.27s_study

to quote just a few...

Indeed.  If Craig had a chance to tamper with the software that checks the signature, the validation is worthless.


Gavin says that he was not allowed to take the signed message because Craig did not want Gavn to leak the news before Craig himself did so.

Well, Craig has come public.  But the signed message has not shown up.  Instead, Craig's post has some signatures aken from the blockchain, and lots of words and tech stuff, so that a reader who is not quite following it may think that he has provided the signed message.  But he hasn't.

Why is he doing it? Perhaps not to fool the ATO, but to fool someone else who would give Satoshi money and/or protection.

I still think that he is the most competent of the bitcoin Core developers. 

Gavin has now posted a bit more information on reddit

Apparently he verified the signature on a laptop provided by Craig, using software downloaded by Craig.  And was not allowed to keep the laptop or the signed message.

Who can see what is wrong with that?

Or even before.  How do we know that the "I am not" message came from the real Satoshi?

AFAIK, that Kleinman guy was originally a policeman in Florida who had to leave the job on disability, and then tried to make a living as a computer security consultant.  For all I know, his knowledge of computing was nowhere near what would be needed to invent and implement bitcoin.

He seems to be a convenient excuse that Craig found for obvious questions, such as: why doesn't Craig move Satoshi's coins.

Thanks!  It is the best explanation I have seen of Craig's claim to be Satoshi.  And for the determination (desperation?) that he has shown in sustaining it.

Gavin has not posted anything to reddit in the past 10 days.  Are there any recent posts by him anywhere else?  Any OTHER posts where he confirms Craig's claim?

Maybe he is away and his ninja account has been hacked.  (To me, that post reads more like Craig's style than Gavin's style.)

Or maybe this is Gavin's way to kick the bucket and give the finger to the community...  

"Jon Matonis" also claims to have seen proof firsthand. But I do not trust Jon's expertise or anything else...

I don't know.  How do you explain it?  Why did the price double in Oct-Nov after one year in the 220's, and why has it been parked in the 420's for the last  5 months?

But actually I can make up two excuses for the price not collapsing after the scam was closed. 

One: The MMM ponzi organizers and/or their victims are still holding the bitcoins that the victims bought in order to play the game.  The price will not drop back until those coins are put back in the market.

Two: It is a fact that other copycat ponzis appeared after MMM; and those copycats may have been more successful than  MMM itself, especially in China.  If that is the case, the price will not drop again until those ponzis collapse too.

Any change to the protocol, soft or hard or otherwise, will require users to upgrade their wallet software eventually.  The question is WHEN they would have to upgrade, and what will happen if they don't. 

With a hard fork change, users must upgrade before the change is activated by a majority of the miners.  Users who fail to do that may find that their wallet software stops working (if almost all miners convert), or that it becomes much more sluggish, and will be using a forked altcoin (if a significant minority of miners refuses to convert).

With a soft fork, the old client software will work to some extent after the change is activated, but will not be totally functional.  The consequences of continuing to run old software will depend on the change. 

For soft-fork changes that do not introduce "extension records", the old client software gets all the information, but fails to chec (and notice) that there are new restrictions about transactions and blocks. 

For one thing, he may therefore accept blocks that new clients consider invalid; but that is not much of a problem, unless those blocks are backed by the majority of the hashpower -- which is to say, the miners reversed the change. 

A more serious problem is that the old clients may issue invalid transactions, and will not understand why those transactions are never confirmed, or even propagated.  For example, a wallet that did not incorporate the BIP66 soft fork may issue transactions with invalid signature variants. (IIRC, Master Spoiler @AlisterMaclin exploited this fact in one of his pranks, a couple of months ago.)

Another example is the idea of introducing demurrage, or negative interest: a rule by which old bitcoins lose their value at a fixed rate -- say, 5% per year, compounded daily.  With that proposal, if you received 100 BTC two years ago, you can only send a little more than 90 BTC to someone else: the other 10 BTC will have to go to the miners, somehow. 

Demurrage is trivial to implement as a soft fork: the majority mining cartel needs only decide that a transaction is invalid if the transaction fee does not include the negative interest amount.  Miners individually can already do that, but those transactions can be picked up by more generous miners.  Making that rule part of the protocol means forcing all miners to respect it: because the cartel will orphan any block by other miners that violates the demurrage rule.

After this soft fork, old client software will still seem to work, and see the same blockchain as everybody else.  Users would be able to spend any small amounts of bitcoin that they received recently, since the standard tx fee would cover the demurrage tax.  But transactions spending larger and/or older inputs would be mysteriously rejected.  Users would have to learn about the new rule, and either add the demurrage tax by hand, or get a new wallet that implements it automatically.

(5% per year may be enough  to convince most holders, traders, and bitcoin services to move to an altcoin, forked from bitcoin or not. But it would not bother people who use bitcoin as a currency.  A more modest tax, say 1% per year, may be acceptable even to holders, since they implicitly believe that the price will rise a lot more than that.  Anyway, the point here is not whether a demurrage tax could pass, but to explain that, even in a soft fork, the old client software will not FULLY work, and clients will be forced to upgrade eventually.)

In the case of soft-fork changes that create "extension records", like SegWit and my "extra block reward" scenario, users and relay nodes who are running the old software would not even receive that extra information.  In the case of SegWit, for example, old users and nodes would be unable to check whether confirmed transactions were properly signed by the coin owners.  Those old player will not see the signatures, and will not even know that they are required.  I cannot see any serious harm that can result from that; but I could not see the Fork of July coming either.  Who knows what Maclin will be able to do after SegWit is deployed for real... 

Finally, in my "extra block reward" scenario, the old clients would be unable to see the new block reward coins created in the extension records, or any transaction outputs that get tainted by them.  But both old and new clients would continue to work together, as long as they exchanged only old untainted coins.  It may take months for the new reward coins to spread and contaminate a significant fraction of the coins in circulation.   Exchanges that adopt the change would want to keep separate hot and cold wallets for old clean coins and for new or tainted ones, to keep old clients happy for as long as possible.  But, perhaps many months after the switch, the old clients would be forced to upgrade -- because someone sent them tainted coins that cannot be ignored or returned, or because their exchange ran out of old clean coins, so clients who withdraw will receive only tainted coins.

You could call those extra reward coins "just an altcoin that is merged mined with bitcoin", but it is more than that.  For the users of the new software, there will be no difference between that two coins.  A new client can send coins that he received from anyone to any address, without knowing (or having to know) whether those coins are clean or tainted.



Maybe, if the modified wallet software comes from a new source.  But if its comes from Core, or from an established wallet software provider -- probably no one will check (or care).  How many have checked the previous releases that introduced soft forks?

A year or two ago, Blockchain.Info (BCI) deployed a new version of their wallet software with a totally broken random number generator, that made all new private keys trivial to guess.  The bug was discovered a few hours later; but not by one of their million (?) users, instead by a white-hat hacker who was monitoring the blockchain for certain key-exposing signatures.  Yet BCI's wallet is deployed as source (javascript) not binaries.


Why would anyone care about the inflation rate, if one is not a greedy speculative trader/holder? 

The people who use bitcoin as currency certainly could not care less about its inflation rate, or even it price.  They would use bolivares, if bolivares could be used the same way as bitcoins...

And the 21 million is not "intrinsic", it is an arbitrary number that was put in partly for economic naivete, partly for rather quaint technical reasons. 

And there is no "contract", just as the rules of chess are not in any contract.  The protocol is out there; anyone can issue transactions and mine.  And everyone is free to make up his own rules, and take whatever that will bring.

Curious that you say that, since the Brazilian bankers are among the biggest corrupters here, and they have been spear-heading the move to get Dilma impeached -- because she dared to try lowering the prime interest rate, that defines how much of taxpayers money will go to them banks. (It was ~60% last time I checked.)

Sigh, I have had this discussion before, won't get into it again.  "The staircase did not collapse because it was badly designed, but because two fat people walked on it at once."


I could point out again that soft forks put the decision in the hands of FEWER people (as few as three miners in China).  But it does not matter: whether they are safe or not, the community cannot prevent soft forks from hppening.


If and when the Core plans fail, it will be much more satisfying if they fail for the reasons that I and others have pointed out. 


Bitcoin cannot have a "governance".  If you do not understand that, then you don't understand the only thing that justifies its existence.


I have no illusions of stopping SegWit.  It is quite obvious already that no amount of technical argument from us idiots will change Greg Maxwell's mind once he made it up.   


Er, I must have slept through that too.  What is the "C" in "FUCD"?



Sorry, I was half asleep when I typed that. It should have been 1500 PH/s of course.

There is no known obvious flaw in SegWit, even implemented as soft fork with Luke's script hack (as Blockstream is doing).  It does fix those malleability problems.  The other alleged benefits are small: it saves a little bandwidth for simple clients (only for them; not for full nodes) and may give a little more block space (depending on how many clients adopt the new format). 

SegWit is just a disgusting hack.  The same benefits could (should) have been implemented in a cleaner way, with a hard fork, without having to change the format of blocks. 

I have seen complaints from wallet developers about the extent of changes that it will require to their code.  Others have complained about the huge risk of having such a pervasive change (more than 500 lines of code, last I read) made to the core of the protocol, with relatively little critical review, and under such pressure. (Testing can reveal accidental flaws; but one will not know about security flaws until it is implemented, and malicious hackers try to break it.)

Others are unhappy that Blockstream is putting so much effort into deploying SegWit, instead of other things like fast block propagation.  The reason for the hurry is that SegWit is needed for the LN (or some other thing that Blockstream is planning and did not tell).

Hard forks are not more dangerous than soft-forks.  One can argue that they in fact safer, because they must be executed openly and be accepted in advance by a large segment of the users. 

Last July there was a 6-block reorganization of the blockchain, the third largest in bitcoin's history.  It was caused by a blocthed soft fork.

Besides, there will be some hard fork in the future, for other reasons (such as increasing the min block size).  The alternative malleability fix (that does not require the split-block format) could be deployed in the same hard fork.

SegWit makes bitcoin more complicated: the split blocks and transactions, Luke's script hack, the fee formulas, etc.
Increasing the complexity of the protocol makes it harder to explain and master (many docs will have to be edited) and harder to maintain.   Increased complexity means that fewer people will qualify to maintain the code, and to write applications that depend on the format.





[/quote]

That is the point: users who do nothing automatically accept any soft-fork type of change, even if they are unaware of it.


That would be the position of a fanatic receiver: "As a matter of principle, I do not accept as valid those extra reward coins, nor any coins that were tainted by being mixed with them, no matter when or by whom."   But of course the newbie who sent him those coins will not have to agree.  If he did not receive the corresponding goods yet, he will want his coins back, "or I will call the cops".  If he received the goods already, he may say "I have no other coins, I got them from my exchange and are good for other merchants; if you don't like them, it is your problem".

It would be like if a merchant rejected any dollar bills printed after 2008, "because they are fake"; and also any pre-2008 dollar bills that the customer may have got as return change when he bought a coffee and paid with a post-2008 bill.  If there are many who take that stance, it may make some sense.  If only a few do that, it would be just stupid...


They could do that, but the users would have to download that software to get back the old rules.  More crucially, it will violate the most basic priciple of bitcoin.  Namely, there cannot be any authority that decides which miners are good or bad.  Anyone can mine, and the blockchain that you should use is the one that your client software accepts as valid and has the most proof of work.


Indeed, there is no technical difference between a soft-fork and a 51% attack.  Both are changes to the rules that are deployed without users's explicit consent or cooperation, exploiting the "majority of work" rule. 

The difference is only whether the change is considered "good" or "bad" by the community; but that may depend on people's relation to bitcoin, the context of the change, how it is presented, etc.

Take my favorite example: postpone the next halving by 2 years, but then shorten the halving time to be every 2 years instead of every 4.  This change would not increase the 21 million limit; it would keep the current rate of inflation until 2018, but the inflation would drop much faster after 2020, so that issuance would be complete in half the original time.

Would this change be "good" or "bad"?  All the miners should love the idea, since it postpones the 50% drop of revenue next July.  Holders who were hoping to cash out in 2019 may hate it, but those with a longer outlook may love it.   And the miners could point out that, without that change, many of them would have to shut down, which would cause the hashrate to drop, which would be bad for bitcoin's security and very bad for its image...

That is the point: with a soft-fork type of change, old clients would not even be aware that the change was
deployed and activated, unless they read about it somewhere.  How many bitcoin users follow the forums
(and know about the reward schedule)?


And would use the garlic spray and silver bullets in case of a vampire attack...

Switching the PoW algorithm will not jam the miners' equipment.  They would
continue mining as always, and every user or business will continue to
use their blockchain by default, "secured by a network with 1.5 PH/s
of mining power". 

What "switch the algo" actually means means  is that the Faithful will create
a new altcoin, say "TruCoin", that starts off with the current state of the bitcoin
blockchain, but has only a modest amount of CPU/GPU mining; and will ask
everybody to ditch their bitcoins and use only TruCoin. 

But, to  do that, users would have to download a new version of the software. 
How many do you think will bother?  My guess is fewer than 5000 bitcoiners...

[/quote]

Someone would have to implement that change; but it does not have to be the Core devs.
The changes would not be too big (compared to the whole of the code); the miners could
easily find programmers able to implement them.

Again, a soft-fork type of change to the protocol becomes effective as soon as a majority
of the miners starts mining by the new rule.  The other players need not download
a new version, and would not even notice the change.

In practice, the cartel will probably want to warn at least the other non-cartel miners, and
provide them the modified code, so that they don't waste effort mining blocks that the cartel
will orphan.

For the change to have an economic impact, it would still be necessary for some part of the user
base to download software that incorporates it.  However. that does not have to occur before
the change is activated (as would be the case with a hard fork).  Old clients would still operate
normally for a while, and would interoperate with new clients to some extent.

It is hard to be more specific about the process without specifying the change, and its
context.  There have been several soft forks already, that users for the most part were not
aware of: they eventually adopted the changes, mostly without knowing, when they downloaded
newer releases of Core.

Specifically, for a change that creates additional coins (beyond the normal block reward schedule),
the miners would start accumulating those rewards immediately; but anyone running the old
software would not see those extra coins, because they would be in the new extension part of the blocks.

In order to sell the "extra" reward coins, the miners would need to convince an exchange to run
the new software.  At the moment, any majority cartel would have to include the top Chinese miners,
so the big Chinese exchanges (that are very closely connected to them)  will probably accept those
coins too.  Those exchanges would then  provide the new wallet software to their clients, and
urge them to upgrade. 

A user or merchant running the old software will only notice that something is amiss
when he fails to receive coins that someone else claims to have sent him.  That will
happen if the sender is using the new software, and the coins that he sent were tainted
by mixing with the new "extra" reward coins at some point.  When that happens,
the receiver would have to download the new wallet software to get access to those coins
(even if only to return them to the sender).

There are many reasons why a mining cartel would not want to do such a change, of course.
However, those obstacles would also stand in the way of the same change being deployed by
a hard fork.  The soft-fork option just removes one big obstacle: the need to inform
all users beforehand, and to convince them to accept the change and upgrade, before the
change is activated.

A hard-fork change that is adopted by a majority of the miners also creates a permanent split
of the coin.  Normally one expects the minority to adopt the change too, so the minority branch
will immediately die.  However, if a significant minority of the miners insists in rejecting the change,
each client will have the option to refuse it too, and continue using the "old" coin.  Or use both
coins, independently, by running both versions of the software. 

With a soft-fork, users do not have this choice.  Even if 45% of the miners hate the change to the
rules, they cannot force a split of the chain, and must adopt it. The users will have to accept it too,
whether they are aware of it or not.

I have avoided watching or reading news about it, and did not watch the vote.  One bit of news or two is enough to spoil my day.  Would you watch a gang rape that you have no way of stopping?


Raising the 21 million BTC limit with a soft fork

SegWit was presented by Blockstream's Pieter Wuille to the world at the end of the second Bitcoin Stalling conference in Hong Kong.  The video of his talk should be on YouTube. Apparently it was a surprise to most people there, except Blockstream folks of course.  Indeed I would say that Blockstream planned the conferences to be just a stage for the SegWit announcement.  

According to Pieter himself, he thought of SegWit some time ago, but put it aside because he believed that it would require a hard fork.  But then Luke Dash Jr. found a way to make SegWit into a soft-fork type of change, by using a script hack and redefining one of the NOP opcodes. That made it possible to deploy it in Blockstream's favorite "stealth mode".  (That is, the change is effective as soon as a miner majority adopts it, whether full nodes, users, and businesses like it or not.)

AFAIK, the only significant improvement that SegWit brings is to fix various malleability problems in one go.  Even that benefit could be obtained much more cleanly by other means, without changing the block and transaction format; but this cleaner solution would require a hard fork, and also the discarding of Pieter and Luke's ingenious hack -- so obviously it could not happen.

I haven't heard of the "fraud proofs" in a while.  In the initial description, they seemed to be more "hints" than "proofs"; and it was never clear how they would be used, and for what.

One interesting "benefit" of SegWit was to make people aware that soft forks are actually more dangerous than hard forks.  With SegWit's "extension record" trick, a soft fork can achieve many of the taboo changes that were thought to require a hard fork; such as increasing the block reward (and therefore the 21 million issuance cap) or confiscating coins. As soft forks, those changes would require only the agreement of a mining majority, without the consent of the rest of the community.  However, for that same reason, there is nothing that the community or the developers can do to prevent non-consensual soft forks.

Floating point is quite adequate for financial computations -- if the programmer understands how it works.  

According to the IEEE floating-point standard, that is used by all major makers since the 1980s, a double-precision float can represent all integers up to 2^53 exactly, with no rounding.  It turns out that 21 million BTC is just below 2^51 satoshis.   That means it is safe to store BTC amounts as doubles, and even do simple math on them, if one stores them internally as satoshi amounts, rather than fractional BTC amounts.  

(The only theory I know for why Satoshi limited the max issuance to 21 million BTC is that he knew this fact, and was aware that Excel, Awk, Python, Matlab, and many other languages and formats used IEEE doubles for all numbers, integer or real. Een though he did not use floating point in the bitcoin protocol, he must have felt necessary to accommodate those languages.)

In the 1990s, smart programmers used floating-point to do integer computations, because the FPU multiplication and division units in typical CPU chips were much faster than the corresponding integer units.  (I don't know whether this is still true today.) The infamous Pentium Divide Bug was discovered by a mathematician who used that trick in his investigation of some number theory conjecture.


Yes in theory, but the full IEEE floating-point representation is quite complicated.  Simulating it in software is no easy task.  Fortunately, one does not need to understand any of that complexity when storing integers up to 2^53 or so.