I don't lie, and I'm only here to acquire rational arguments of which I can learn.  I will try to limit my comments to purely technical and rational comments, because as you really need Satoshi to be an evil genius in order for your work to have sufficient sensible meaning, I know that I have no way to convince you of anything else, nor do I have any incentive to do so (apart from the fact that it is going to perturb, of course, the logic of your arguments).


All this falls apart of course, because there are contradictory elements.  This is what I wanted to outline.  I'm not saying that bitcoin's crypto design is erroneous in the sense of disfunctional.  It is simply incoherently designed.  It is like removing two of the four screws that hold the bicycle bell to win some weight, and adding a wheel made of lead or something.
You are perfectly right that hashing the public key protects the signature scheme in the case that the ECDS scheme becomes broken.  The problem is that at a certain point, you will need to expose that broken system.  Now, the question is: HOW broken will it be, and can the broken system still resist for the functionality that is needed ?

This is why in crypto, you never "protect a broken system", because it implies that 1) you didn't need that broken system in which case, there's no reason to use it or 2) you need it, and as it is broken, this is where your overall design will fail.  And this is exactly what I was pointing out: if ECC is considered broken (partially or totally), then no matter how well we protect it with superior hash protection, when we are going to have to use that broken ECC, our crypto system breaks down.  Now, maybe it is still "surviving long enough ?"  is it ?

This is where we come to the "time scales of resistance" of both systems.  The address, on chain, will need to survive for centuries.  The signature will need to survive AT LEAST 10 minutes, and most probably of the order of days.  The ratio between both is about 12 bits of security.  Not more.  So anything that has *SUFFICIENT* security at the 128 bit level (ECC), will have enough security at the 140 bits level long term.  Or, vice versa, if you NEED 160 bits security in the long term, you NEED at least 148 bits security in the short term, and 128 bits is TOO SMALL.  But given, on top of that, moreover that the chances are higher that ECC will be broken SOMEWHAT before hash functions get broken, you would need somewhat more, vastly more, or infinitely more security for the ECC (so more than 148 bits).

In other words, if you could crack the 160 bit address in a century, then you can crack the signature in less than a second (classically).

You cannot deny this, it is simple math.

==> again, my obvious conclusion is that the address is overprotected, or the signature scheme is very very vulnerable.

But bitcoin's design is even worse.   Bitcoin's design allows you to re-use addresses in several UTXO. This re-use not only makes for a mess in indicating WHICH output you mean when you specify an address, it also renders the above protection scheme totally moot.  Why ?  Because if you spend ONE of the UTXO with a given address A, you have exposed the public key of that address LONG TERM for all the other UTXO that have the same address.  So by allowing the re-use of addresses, bitcoin's design totally destroyed, IN ANY CASE, the "protection by the hash function long term" of the public key.

On top of that, it is true that a single use of a hash protocol in a Merkle-Damgard construction is open to the extension attack, and that a good idea is to do a double hash IF YOU USE THE MERKLE-DAMGARD construction, that is, if you need to hash more than 512 bits.  However, in this particular case, this is ridiculous, because the key doesn't NEED the Merkel Damgard construction, given that SHA-256 takes data blocks of 512 bits, so the whole key fits in a single SHA-256 primitive.  As such, the double hash utilisation is again to protect against a non-existent threat.

Now, the succession of a SHA-256 hash, and a RIPEM160 hash, can be funny, but don't serve any purpose.  You could just take the first 160 bits of the SHA-256 hash ; if you think that SHA-256 is broken, first of all, it doesn't matter much, because with address re-usage, the hash only "protects" the supposedly not broken ECC public key only for the first address that is going to be used, so the importance of this hash is not so large ; but on top of that, one can always reduce a hash length by just taking the first n bits of a hash.  Transforming a 256 bit hash in a 160, 128 or whatever hash is easy: take only the n first bits.

The super-over-protected public key by a double SHA-256 and a RIPEM-160 hash, is given out when the first appearance of an address is signed.


Then, reducing from 256 bits which was possible, to 160 bits, sounds even sillier, doesn't it ?


==> this looks like a smart and correct argument, but it isn't, for several reasons.

The first reason is that the security level is the security level of a single address.  If there are many addresses, of course the probability to break one of them diminishes proportionally to their number, but that doesn't change the individual security level of an address.  In other words, if your probability to die in a car accident is 1/10000, then that is not influenced by how many people run that risk.  If there are 1 million people, then there will be 100 death due to car accidents, but your individual security level to die of a car accident, remains 1/10000.

So the fact that there are trillions of addresses, and that there is hence a trillion times higher probability to find ONE of those addresses than if there were only one, doesn't alter the security of a single address to be found.

Another way of saying this, is to say that the security of using, say, AES-256, isn't diminished because MANY PEOPLE use AES-256, and hence, that the chance to find ONE of the secret keys of ANY ONE of the users of AES-256, is increased, and hence, the security is diminished. 

--> the security level of an individual address is not influenced by the fact that there are many addresses, and hence, that the probability to find one is increased.

But let us assume that Satoshi wanted an OVERALL security level of 128 bits, and not just the single address security. What does it mean, to have a security level of 128 bits ?  It means that it takes 2^128 trials to find it.  Now, suppose that there are N possible addresses on the block chain (trillions = 42 bits, say).  What is the probability to find ONE of them ?  That is, an attacker wants to find AN address, no matter which one, on the block chain.

It is simply one in 2^160 / N = 2^160 / 2^42 = 2^118.  That is still a very small probability !  The "near certainty" is essentially a very rare happening !    In the case of original 2^128 hash bits, it would lead to one out of 2^86.

To what kind of security risk does this correspond ?  It corresponds to an attacker wanting to find JUST AN ADDRESS on the chain.

==> note, however, that the 128 bit level security is not reached with "trillions of addresses" on the chain, with a 160 bit hash.  He would at least need a 170 bit hash if that were the case.

But is that all ?  The confusion is here between collision resistance of a hash (bits / 2) and the probability of finding one of the hashes in a GIVEN SET.    When you have a 160 bit hash, you need on average about 2^80 hashes to have a reasonable probability that two of them are equal (birthday paradox).  However, if you have a 160 bit hash, and you HAVE 2^42 hashes given, then the probability that a next one will be equal to one of them is only 1/2^118.  That said, the probability that ANY two of them in the set are equal, is rather 1/2^76, which is still very small.  In the case of 128 bits, this will bring us down to 1/2^44.

To what kind of security risk does this correspond ?  It corresponds to ALL users being attackers, and trying to find a collision with a previously existing address.  Then ALL of them need to try about 2^76 addresses in the 160 bit hash case, and 2^44 addresses in the 128 bit case, in order for ONE OF THEM to succeed in finding ONE other address.

If we consider this a security risk, then we see that 160 bits is BY FAR not good enough.

==> so in as much as this "overall security level" was required to be 128 bits, the 160 bit hash is WAY WAY TOO SMALL.

In fact, if you want a non-collision probability of 1/2^128 for "trillions of hashes", then you need to add 2^(42 x 2) = 2^(84).

You'd need a hash length of 128 + 84 = 206 bits !

Note that in no way, even with a 128 bit hash, there is "almost certainty" that a collision occurs.  The probability is still of the order of picking the right molecule in a glass of water of this happening without being an "attack".  So the chance that 128 bit address hashes are going to screw up the block chain because of address collision with almost certainty, is wrong.  It remains a very tiny probability.

==> in any case, 160 bits doesn't make sense.  If we look at the security of individual addresses, this is not influenced by the amount of other addresses in the chain (and this is the true "security level" concept).  Then 160 bits is too large.

If we consider an attacker wanting to find a single collision with just any address, the security level should be higher than 170 bits.  And if we want to require a probability of non-collision less than 1/2^128, the hash length should be 206 bits.

Note that this problem goes away if we publish directly the full 256 bit public key (which, with address re-usage, is in any case published when the first appearance of address is spend).

If we have trillions of 256 bit public keys, the collision probability within a set of trillions of keys, is less than 1/2^172.

Note that all this is when we erroneously consider "overall" security levels, and not individual address security levels.  The overall security of bitcoin is however, way, way smaller than this.  In fact, you can render unspendable an address by simply reversing the transaction that had this address as an output, by redoing the block chain from that point on.

The acctual PoW security of the entire block chain, and hence of every single address, is much, much, much smaller than any of these numbers in any case.  So all this is theory in any case.


Collision attacks are of no importance in bitcoin.  It is pre-image attacks that are of importance.  Being able to generate two well-designed inputs that hash to the same hash doesn't help anything.  You need to find a hash that is in a GIVEN TABLE (the existing addresses).  That's pre-image, not collision. 

Moreover, the "protection" of the public key is silly, if bitcoin addresses can occur in several outputs: once the first one is spend, the public key, so well protected by a hash, is published !

It is also this address re-usage that obliges one to specify the transaction, to know WHICH of the different UTXO with the same address, one is meaning.  If address reusage was prohibited, there could only be one single UTXO with a given address, and that would be unique: no more transaction hashes, positions within a transaction and so further ; including the transaction malleability problem.


this has no influence on the public key itself, or its hash, it only influences the signature.

That's a faulty rebuttal.  A full quantum computer (that is, a general purpose quantum computer with sufficient qubits) cracks an ECC IMMEDIATELY (only a few 1000 clock pulses needed).  My "not thinking clearly" is rebutted with a "not so very clear argument that has no ground".   

Any partial quantum computer is equivalent to a seriously sped up classical machine.  My point was that if you can crack a 160 bit security level in 50 years, you can crack a 128 bit security level in 0.3 seconds with the same machine.  Your rebuttal doesn't address this.  In any case, if you NEED 160 bits of security to be centuries-safe, then a 128 bit security level is cracked in a matter of seconds, classically.  Quantum is even worse, because even though quantum computers still face a 2^80 bits security level for the hash, the ECC is TOTALLY GONE.  In a blink of an eye, a quantum computer solves your ECC problem, no matter its initial security level, if the quantum computer has enough qubits.

But I already said that.  I hope you see that your "rebuttal" is totally empty of arguments.


You are arguing against your own position !  My claim is that if Satoshi feared that ECC was going to be broken, there's no reason to use it and try to protect it, because if that happens, the moment you USE the ECC part of the system, your system breaks down.  And now you argue in the same sense, that the hash protects the broken ECC, because we know already how to break it if ever we can build a quantum computer.  Yes.  I agree, and that's exactly what it was a bad design !  And why you don't protect systems of which you think they are broken.

I'm not going to explain this another time.


You are totally missing my argument, by making your point worse.  Shor's algorithm is known, but the computer on which it can run is not known.  The whole question is whether one day one will be able to make such a machine. The day that we have that computer, an ECC signature doesn't survive 100 milliseconds.  So your hash protected public key is worthless.  That's my point.  You can't do bloody shit with your protected address, because the day that you want to sign a transaction, one can IMMEDIATELY fake another one.

And again, the inconsistency is to allow multiple usage of the same address.  Once THE address key is given out to spend one single UTXO, all other UTXO with the same address are entirely compromised if this hash protection was needed.

This address re-use is also what makes a lot of other things difficult, like having to refer to a transaction as a whole, needing transaction hashes and so on.

I repeat:

1) If the hash was to protect the ECC, have collision resistance etc....
then
1a) this was silly, don't protect a broken system
1b) if you insist, use maximal protection, that is, a 256 bit hash of the key (maximal key entropy preserved).
1c) don't allow, OBVIOUSLY, address re-usage, which makes the protection of the public key entirely moot.

2) if the hash was to reduce block chain bloat, then, there are 2 possibilities:

A: hash the public key to 128 bits, to win room
B: publish the public key directly (and avoid all collision discussions)

but also:

2b) don't allow address re-usage. As such, the signature will reveal the public key, which indicates directly the single UTXO which corresponds --> no need for a silly 256 bit transaction hash, with 32 extra bits of transaction output number: there's only one corresponding UTXO possible.
2c) don't publish a second time the public key, it can be derived from the signature !

These two actions reduce the transaction block chain room by two.

Hashing to 160 bits "to win room on the chain" (and not hashing to 256 bits, and hence loosing out on collision security, if this is an argument), but using transaction hashes of 256 bits, and publishing the public key which is not needed (it can be derived from the signature if some precaution is taken), is totally contradictory.  Claiming that a 160 bit hash is needed to counter whatever attack on the public key, but allowing address re usage and hence exposing all those second and third.... UTXO with the same address, is incoherent.

I agree with you.  The error in most crypto is the reward, which gives rise to strategies that do not necessarily induce the desired properties.  I also think that the only viable kind of crypto currency is where the validation/consensus decision is taken on a voluntary basis, the "reward" being that the system in which you are invested, keeps running correctly.

However, you still need a kind of deterministic decision *that is hard to game* (because you can do "proof of work" like calculations to get the deterministic solution in your advantage).  This is why a kind of PoS signature scheme is necessary in my opinion.


Checkpoints are no solution, because they are just another consensus problem.  If you have two conflicting check points, which one is the "right" one ?  You've just transposed the block consensus to the check point consensus.

Yes, you can *individually* decide that you won't allow any old modification of consensus.  But there is no guarantee that the rest of the network will follow you.

But mainly, yes, PoW is a bad idea, and rewarding (with fees or coin creation) consensus deciders/maintainers is also a bad idea.

Of course, but the consensus in bitcoin is determined by miners.  You'd have to make a fork of bitcoin (make a new coin) to get rid of the miners FROM THAT COIN, but you cannot stop them from continuing bitcoin as it is.  Will your new coin be "bitcoin" or will the coin they continue to handle, be "bitcoin" and you just made a measly altcoin ?

What deterministic solution ?  There isn't any that isn't centralized or permitted.  Proof of Stake was a possibility, but Satoshi was facing the problem that he was the only stake holder in the beginning.  He would have had to sign all blocks by himself, and unless someone actually GOT COINS FROM HIM, there was no way to get a second stake holder.


The problem is, WHEN do you consider that transaction A is the valid one ?  How LATE can transaction B be propagated and WIN from transaction A ?

Suppose I pay you 100 BTC.  You observe transaction A on the network paying you.  How long do you wait before you consider that this payment is secure ?  Suppose I buy a car with that.  How long do you wait until you let me have the car ?

Suppose that the next day, I make a new double spend payment to myself.  I can modify my receiver addresses until I find a payment that has a smaller hash than transaction A.  I call that transaction: B.  I now transmit B on the network.  As B has a smaller hash than A, the consensus tells us one should take B over A, and finally, your transaction is eliminated.

Ok, but one day later, we don't accept this any more.  Ok, but how long do we have to wait ?  At what point do you consider that A is definitively the accepted transaction ?  After 30 minutes ?  But what if B comes in after 29 minutes for Joe and after 31 minutes for Jack ?  Joe and Jack will now disagree FOREVER over what was the right transaction ?  If you connect to Joe, you see your transaction reversed, while if you connect to Jack, you see your transaction not reversed ?

--> this is the consensus problem.  It is already difficult if most players want to play honestly.  It becomes very hard if you get a sybil possibility of 90% of the nodes conspiring to game the system (90% of nodes in the hands of one entity).

Suppose that I transmit transaction B almost immediately after transaction A, but I fire up 90% of nodes that "ignore" transaction B.  You will probably not see transaction B, and you think that after half an hour, you are safe.  Then I switch off my sybil nodes.  The rest of the network has preferred transaction B.  When you try to spend your coins a few months later, your right to spend doesn't exist on most nodes, because they had rejected A, and chosen B, and forgot about A.  You are the only one remembering A, thinking it was right.

Satoshi found a kind of solution with PoW.  It is a clunky solution, but he needed one.

If the idea is to "store value for the long term", or "play greater fool" I don't see the use of crypto.  If it is to use as a currency, it doesn't matter much, does it, from the moment you can acquire it, and spend it.  But "currency usage" is not something that became a success in crypto 'currencies', is it ?

The only reason to use crypto is when you can't do it with fiat, for one or another reason.  I can only think of things like monero, or zcash or so, to be suitable for that.  I wouldn't touch DASH with a stick.  I guess LTC could be used for those things that have some fiat obstacle that isn't a legal obstacle, and where you don't have to hide (but in most cases, then you CAN use fiat).  And if you want to gamble, most probably eth or one of its ICO tokens for gamblers, is suitable.

But it all depends on why you need crypto (why can't you do it with fiat ?) ; different needs may/should induce different coins.

If it is to trade and to play greater-fool games, the coin doesn't really matter, does it ?  It is penny stock then.

Miners care about the absolute fee, not about a percentage.  If for one reason or another, a miner can take transaction A OR transaction B, but not both (for instance, limited block size, or other technical aspects that make that him taking on another transaction generates a cost: cost of missing a block, cost of infrastructure, cost of I don't know what), then that miner will pick the transaction with the highest ABSOLUTE fee. 

The fee market is about "transaction room" ; it doesn't care about what amount is transacted.  This is like driving a truck: the cost, and the fee of hiring a truck, depends on the load to be transported, not upon the value of the load.

So in an on-chain fee market, scenario B seems plausible.

However, in a lightning network banking, I guess it will be more like scenario A.  Because the "cost" of transacting on a LN (namely, the cost of having to settle on chain) depends on the amount transacted.  If that amount is small, it will easily go over many channels that have still provisions to do so.  If that amount is big, chances are bigger that it stresses the reserves in the channels used.

On the other hand, the bigger are the LN hubs, the more they can put into their channels, and the lower the fees they can ask for the same amount of transmitted value.  So a LN with limited block size will converge to very expensive block transactions between major LN hubs to settle their things, and a limited oligarchy of big LN hubs, being your bank, to which everybody is attached with a single expensive settlement on-chain (making it essentially impossible to "change bank") of your unique channel, which is entirely controlled by your bank, and which charges you proportionally to the transactions you want to make.
Like fiat banking, but without legal protection, and being bound to sleazy obscure bankers on the internet, without any recourse and to whose mercy you are delivered.  Unless you are wealthy enough to permit settling your channel on chain yourself, and go see one of their competitors (if they don't collude).

I entirely agree.  PoW is a total disaster.  Thanks to a lot of discussions with @iamnotback I realized HOW MUCH it is a disaster.


Indeed.  Moreover, as I recently saw, Satoshi even foresaw that this mining would become totally centralized, defeating the purpose !  It is totally ridiculous to introduce PoW to avoid a sybil attack, and then come to the conclusion that only a few big players will decide on the consensus as a consequence of his "solution".

This is why I think that Satoshi, after he finished the outline of his invention, accepted to modify the design criteria he put forward himself, because his design didn't fit it, but now that he made it, he didn't want to discard it.

That is like wanting to make an airplane, finding out it will not fly, but it will float very well, and declare in the end that your were actually designing a boat !

In the same way, Satoshi wanted "money for everyone to use" and then put in a 1 MB block limit, making it impossible for this to be used as money for more than a few geeks on a few obscure trading places.

Of course, all this can be the work of an evil genius.  But Occam's razor makes me believe that this is just a guy in his basement, doing the best he could, and the best he could, he realized, wasn't good enough for what he set out to do, but that wouldn't stop him.  Don't put on the shoulders of conspiracy, what can be explained by ignorance.

Why hashing a public key could have been brilliant, and how bitcoin's design totally missed it.
=========================================================

I outlined before that hashing the public key as a bitcoin address was a faux good idea, but now I realize that it could have been a good idea.

The reasons I stated that it was a faux good idea were:
1) if you need the hash to protect a broken crypto system (elliptic curve crypto), you are making a fundamental mistake.  In as much as hashes can protect better against quantum computers and elliptic crypto is essentially TOTALLY DEAD, you can't use your private key any more because one can change your transaction on the fly if one has a quantum computer.  So instead of "protecting a broken system", one should have used one that isn't broken ; and in as much as one thinks that elliptic curve crypto isn't broken, there's no need to protect it.

2) I indicated that introducing the hash was wasting room on the chain, because if you hash the public key in the output (the address), you have to provide the key in spending input (as is the case today) ; while if you provided directly the public key in the output, you didn't need to copy it again in the spending input.

--> now it turns out that this argument is wrong.  So YES, introducing the hashed key IS winning room on the block chain.  However, this feature IS NOT USED.
 
In ECDS, with a key of N bits (and a security of N/2 bits classically), the signature contains 2N bits.  Essentially, the first N bits are related to a chosen random number, and the second N bits are the actual signature.  However, it is possible to derive the public key (actually a small set of public keys) most of the time from the signed message and the signature.

As such, the publication of the public key is not necessary !

The verifier can derive it (up to a few candidates) from the signature and the message.  In fact, for the curve that Satoshi chose, with cofactor 1, there are only two candidate public keys.

It is explained here.
https://crypto.stackexchange.com/questions/18105/how-does-recovering-the-public-key-from-an-ecdsa-signature-work

In this very case, there is no need, EVER, to publish the public key on the block chain: the signature gives you two candidates, and if one of them hashes to the public key hash, that's a proof that the signature came from that address owner.
And then you WIN by hashing the public key, because the hash can be half as short as the public key (given that the hash security is the length of the hash output - we are after pre-image security ; and the public key security is half of the key length classically).

So, yes, it is a good idea to hash the public key after all, if you don't publish the public key in the spending input !  But in bitcoin, one does, so one has totally wasted this advantage.  Moreover, there's no point in making the hash bigger than 128 bits.

--> this indicates that the bitcoin designer wasn't aware of this economy of bits and hence, cannot have designed the crypto for that reason, given that he didn't use its potential.

So, the most economical design in bitcoin would:

1) have used a 128 bit hash of the public key in the output (instead of 160 bits), saving 32 bits
2) have imposed a single address usage in the protocol (eliminating the need for transaction references, saving  288 bits)
3) having used only the signature in the spending input, not the public key (saving 256 bits)

A transaction would hence have saved 576 bits, or 72 bytes, would have had consistent 128 bit security level, wouldn't have had the hassle of transaction hashes and malleability, and would not have exposed same address UTXO to different levels of security (once the first signature is out, the 160 bit long term hash security drops in any case to 128 bit key security).

Now, a full transaction in bitcoin (one output and one corresponding input) consist of the order of 24 + 8 = 32 bytes (output) and 32 + 4 + 36 + 36 + 4 =  112 bytes (input), so in total 144 bytes.

If we can save 72 bytes, we can reduce the volume of the block chain BY HALF, if we were using crypto correctly and consistently in the idea of optimizing consistent security (128 bit level) and maximum economy of room.

In fact, the original design even published the (x,y) coordinates in full of the public key, doubling the room used, but that was a total waste: you can recover y from x (and a single extra bit).  This is done now.

Of course not.  People are maybe buying bitcoin at $1000 because they think it may go up to, say, $10 000,-.  But who is going to buy a bitcoin at $500 000,- ?  You're not expecting it to reach $5 000 000,- do you ?  So if you buy at $500 000,- you must be buying near the all-time high for ever.  Who's going to do so ?  So bitcoin will still grow a while, until buyers realize that there's more downside than upside, not only in the short term, but also in the long term.  And then, the greater-fool game stops.  And we get the supernova, or the slow deflation of the bubble.  I have no idea if it will be in 5 years, 15 years, or 30 years.  


So those billionaires are going to put their fortunes in some funny crypto thing running by a few Chinese maffioso instead of owning companies, real estate, intellectual property and much more ?  Wake up.  Yes, sleazy business will.  Porn, hookers, drugs, gambling, arms deals, espionage, hackers, tax evaders and so on will.  But not really big billionaires.  They buy state power, not bitcoins.


Stating that I don't understand something is not an argument, I already told you.


The value of money, ultimately comes from what you can buy with it, or rather the belief of what you can buy with it.


No, you didn't.  You gave some arguments that I debunked, and then you only repeated that I was wrong, or that I didn't understand, or that I was suffering from cognitive dissonance, but these are not arguments that demonstrate anything.

The points I made about the technical clunkiness not only stand, you haven't even been able to find a single argument against it.  Bitcoin's crypto is working, but clunky, inconsistently designed with wasteful applications of inappropriate cryptographic primitives.  That doesn't stop it from working, but it illustrates the ineptness of the designer of the system.  And no, I don't buy the arguments that:
1) it is truly genial, so genial that we don't understand it but it must be genial because it was designed by a genius, and if we think it is clunky, that's because we aren't smart enough (circular proof of genius)
2) it is indeed clunky, but on purpose, only to mislead you to make you not see the design was done by a real genius (unfalsifiable argument: if it was brilliant, it was a genius, and if it was clunky, a genius wanted to make you think he wasn't a genius)

These two logical errors won't convince me.


Nope.  I argued why.  Your argument contains a contradiction, namely the impossibility to keep at the same time a pre-announced numerical debasement scheme, and a constant market value.  I indicated that you misunderstood the notion of non-manipulable debasement, not as meaning a pre-announced *numerical* emission scheme, but a pre-announced emission scheme with a value target (for instance, constant small inflation, or constant value), the only way to avoid the contradiction.


I already told you that I think it is you who are suffering from that, simply because you are too much invested in that view, without which most of what you do would run the risk to be reduced to something of lesser importance than you are willing to conceive.

I'm not designing something that has to stop the evil future masters of the world (bitcoin), and I'm not the one wanting to change the world.  You need bitcoin to be designed by an evil genius, in the hands of the world elite, with a mega evil master plan that you can outplay in order for your work to be of the importance you want it to be.  So you need bitcoin to be the evil future domination after fiat finance has collapsed, at the right time scale so that your design has had the time to have overcome that devil's plan.  I don't.  I couldn't care less.  I simply don't care about the world, and yes, one day I will be "slaughtered" and I couldn't care less, either.  That's part of life.

As such, the probability that you are suffering from cognitive dissonance is quite higher than the probability that it is me.  I am not invested into this.  I'm just putting elements on the table.  Yes, it might very well be that Nash was an evil genius working for the Rothschilds when he was 80 years old, has denied all his theories about money to build them a currency with which they would rule the world, has made a cryptographic design that violates about every rule of good design (because he wanted to convince knowledgeable people that he was clumsy and was at the same time far ahead of most cryptographers of his time, so that they don't even realize it), announced future visions of his decentralized oligarchic money that would take over VISA, and then killed it by introducing a 1 MB block limit, is going to use 10% of the world's electricity to use a stupid security mechanism PoW, and...
has enabled you to be the hero that will save the world by outsmarting that mathematical and economical genius, John Forbes Nash, and building a system that will kill his devil's machine.

Maybe.  I just bring in elements that make me believe that such is not the case, but if it is the case, I don't care: you will save us and bitcoin is done anyway.  I'll pay you a beer if you were right (and I won't pay it in bitcoin) in 2025 and if both of us are still alive.

But you see that your stake in this is way way higher than mine.  This is why I think that I can be more open-minded about these things that you are.  I'm not saying that I know better.  But the fact that you reply with judgements of my sayings, person and intelligence, rather than with rational arguments, which is the only reason I'm here, makes me think that if one of us is emotionally attached to a position, it is you rather than me.


That is exactly the same analysis.  The only reason people hodl, is because they wait for greater fools.  Hodling stuff doesn't give it economic value, because no value is created by doing so.  This is also exactly the reason why bitcoin's market cap is fake if you see it as an illustration of the total amount of value stored in it.  The day the bubble bursts, this deflates to almost zero.


--> this is not a rational argument.

I think one is reading too much in what isn't there.  This is how people invent religions, by seeing purpose when there wasn't any.  In my idea, the whole concept was rather simple: Satoshi wanted a non-centralized token transmission system, and needed to solve a few technical, and a few economical problems.  There were already several elements lying on the table and he put them together (which is the merit he really has).

1) He needed to get rid of the "central bank".  The block chain concept, where instead of tokens to be materialized, TRANSACTIONS were the fundamental element, was a great insight.  In as much as it is impossible to prove that transmitted digital tokens aren't double-spent, if everyone has a list of past transactions, that solves the double spending problem.  So the idea was to get all participants to get the full list of all transactions at a point.

2) he then realized that he needed to solve a consensus problem, because of the finite propagation delays on the network: what if some participants received valid transaction A, and other participants received valid transaction B, and A and B are spending the same tokens ?  How to come to a consensus ?

=> he needed a kind of decision game so that at any moment, only one decider was going to decide upon the consensus, that is, the full list of accepted past valid transactions.  As he didn't want (at first) a central authority, he needed a LOTTERY BETWEEN PARTICIPANTS.  However, in order to avoid a sybil attack, he proposed to do the lottery with Proof Of CPU work.  --> a lottery every 10 minutes.

3) he needed also to create coins, and he realized that creating coins was going to give seigniorage which was going to undermine the belief system in the money.  So he (though he had) a brilliant insight:

"the CPU work spent in winning the lottery to determine consensus, is going to be rewarded with new coins ; that looks fair, because 1) a priori everyone gets the belief that they could have won the coins and 2) people doing something useful get rewarded".

That's more or less it.  I don't think Satoshi's insight went beyond that, but that was already quite something.

The rest consisted in:

1) working out the details
2) thinking about the consequences of choices made when working out the details.

One of the things Satoshi was religious about, visibly, was the fact that there should only be a finite amount of coins in circulation.  He must have been influenced by the Austrian school and gold bugs.  In fact, if he could have put them into circulation right away, most probably he would have preferred that, but as he now needed to emit them by people finding consensus, he HAD A SERIOUS PROBLEM: how to reward people in the future when all coins are emitted ?

In order to obtain a finite amount of coins at the end of the universe, he needed to diminish rewards ---> simple solution of block reward halvings.  In order to reward them in the long term, he needed transaction fees. 

In order to limit the coin emission, he needed the lottery to take place only once every 10 minutes, and because he didn't want to rely on real time (in the end, he did!) he invented the scheme of increasing difficulty.

The logical consequence of this was that the economic cost of the PoW at the 10 minute reward was going to rise to be about equal to the market value of the emitted coins.  This would lead to totally crazy amounts of PoW, the rise of specialized hardware, and the killing of the original idea of just "a lottery between participants to decide who was going to decide upon consensus next with Sybil mitigation".

Satoshi's idea of having most payments done with bitcoin led him to understand that the block chain as he designed it, would have to grow at 100 GB a day.

However, as is often the case with inventions, when one sees the consequences that were orthogonal to the original design ideas, the right way is to discard the invention because it fails in implementing what one had in mind ; but most often, one perseveres in modifying the initial design goals so that the invention in which one has a lot of emotional and intellectual investment, ends up suiting the goals.  I think bitcoin has been created exactly that way: when Satoshi realized (partially) that his invention wasn't exactly what he set out to do, but not being able to think of anything better at the moment, he considered that it should go ahead and modified his initial ideas so that they suited the thing he invented.

This is why bitcoin is the clunky thing we see it is, and not the thing Satoshi set out to design, but failed to do so: a digital peer-to-peer trustless, decentralized money and payment system for all to use.

One can of course always think that this clunky thing is what he intended to make, but this is like explaining why God, in his perfection, allows man to make war and allows him to suffer unfairness.  Simply because there wasn't any god, there wasn't any masterplan, but things just happened, and they weren't designed this way or another way.

I don't believe in that "monetary reset".  There will be financial crises, as there always have been.  No big deal.  Crypto won't help.


I use deflation simply in terms of "monetary unit acquires value".  

From wiki:

When a monetary unit acquires value, there is deflation of that monetary unit.


You can't have it both ways.  You can't require the ideal money unit to keep a stable value (with respect to a large basket) and have its debasement *numerically* specified in advance.  What you can do, is to have strict target rules for debasement to act to reach an inflation target.  In as much as these rules are immutable, they are non-manipulable.

This is why Nash thought of the Euro as close to an asymptotic ideal money:

(from the wiki on ideal money).

So, the "schedule of debasement" as a non-manipulable rule to reach the inflation target, yes.  A pre-programmed, blind, debasement scheme: obviously not, because otherwise, the introduced inelasticity cannot guarantee price stability or price inflation stability, which is the defining characteristic of ideal money.  

It is why gold is not a possible ideal money:

exactly because one cannot apply a debasement (or destruction) to keep its value constant.

This is the other reason why I don't think it was Nash that created bitcoin: the economic model of ideal money of his hand, would never go for a collectible with DIMINISHING emission.  At best, Nash would have built in an emission curve that would follow predicted adoption (which is essentially impossible in advance): few emission in the beginning, and issuing MORE AND MORE bitcoins as time advances, so as to keep the price of bitcoin constant with growing adoption.

In fact, there would have been a way to do so: instead of increasing difficulty to have constant (and 4-year stepwise decreasing) emission rate, have constant difficulty, compensated by Moore's law.  As such, the price of a bitcoin would more or less remain constant, and equal the cost of the work spent on making them.  You would accept bitcoins against value if it would cost you more to make them, and you would make bitcoins if it would cost you less making them than buying them.

PoW at constant work cost, was a way to implement something much closer to ideal money, than bitcoin's sound money doctrine.

Satoshi designed it that way BY ERROR (or by cheating and lying).  I simply don't think that bitcoin is going to fly so high.  It will find its niche, namely an unregulated reserve currency for big sleazy business, and as a highly speculative toy for gamblers/traders, and that's it.  Bitcoin, nor any other block chain type crypto, will be "the future of money" for most people, simply because it is too clunky, authorities won't let it happen, and in the end, people are material beings.

So, yes, I agree with you that the design of bitcoin is such that it will remain immutable, and that most of the current characteristics of bitcoin are understandable by game-theoretical arguments.

Where I don't agree with you is to think that bitcoin will become world-important - it will remain in a niche.  Like all crypto.  People will never pay their groceries with crypto.  Forget that.  Fiat systems will remain in place as long as humanity is still in command and states exist.

Where I sort of don't agree with you, but I don't care much, is that I have good reasons to think that bitcoin's design has too many clunky crypto design features to be the product of a mind like Nash.  But it could be ; but as, moreover, Bitcoin's monetary philosophy is ALSO not in agreement with Nash ideal money, I tend to reject the hypothesis that Satoshi was Nash.  I tend to think it was a guy with some bright ideas, and some limited crypto and math understanding, and some limited economic understanding, that made bitcoin in his basement.  But I could be wrong.   The "design features" that I find clunky in bitcoin, don't break it, but they are simply clunky.  There's nothing "brilliant" about them.

Where I don't agree with you is that bitcoin is designed by the "global elite" because apart from a gambler's token, it is not going to go anywhere that can interest the "global elite".  The sleazy business it is profiting is not the global elite, but second-hand maffioso.  And if it were, against all odds, designed by the global elite, it is a failure in any case.  Don't stare yourself blind on the "market cap" of bitcoin: that's nothing else but one big huge speculative bubble, driven by greater-fool games.  The economic value of bitcoin (the value creation it allows over its competition: fiat, in economic activity) is most probably 100 times smaller, and dominated by dark web markets, its main economic utility for the moment.  Bitcoin's economic value must at most be a few hundreds of millions of $$ worth ; that is, the value creation it helped create which wouldn't have been possible with fiat because of legal or other obstacles.  The 20 billions are nothing else but greater fool speculators waiting for still greater fools.  If they don't find greater fools after 10 years or 15 years, that bubble will collapse.  But there are still a lot of greater fools to be taken, so as long as the black tulips rise in price, you will find speculators flowing in.  But that is not economic value.  

This is another reason why bitcoin is not corresponding to Nash's ideal money.  Bitcoin has a diminishing DEBASEMENT, and a huge DEFLATION (that is, value appreciation). 

For Nash, it was extremely important that this international currency had zero or low and fixed, inflation, that is VALUE DEPRECIATION.  He accused gold of not being ideal, exactly because it was too much of a collectible, and couldn't adapt supply to keep its value constant.  Bitcoin is based upon sound money doctrine, which is not what Nash considers ideal money, because it doesn't have a stable value, and can't because you cannot have inelastic supply, variable demand, and constant price.  Bitcoin has perfectly inelastic supply (it is programmed in advance), even a diminishing growth rate of his supply.  So this must be a value-appreciating asset, which cannot serve as ideal money with constant value AT ALL.

If it was meant to be a reserve ASSET (not money), then Satoshi has been lying through his teeth, and it doesn't correspond to what Nash called ideal money.

We are mixing different things here.  Satoshi clearly stated that he intended to have VISA-like transaction volumes on-chain with bitcoin, but that bitcoin would become a semi-centralized served thing.

I already cited that:

http://satoshi.nakamotoinstitute.org/emails/cryptography/2/


From this, I clearly read that the original aim, as announced by Satoshi, was to have VISA like transaction amounts on chain.  100 GB of extra block chain a day didn't seem to scare him in 2008.

The way I understand what Nash is saying in what you put in bold, is not so much that most people should use another KIND of money, but rather that they would use *the same money* but not determine most VOLUME.

In other words, people pay in dollars - the same dollars - as a few rich entities, but the dollar flow between the few rich entities is much, much bigger than the dollar flow between most people.  He's talking about VOLUME, not about KIND.

I read from Satoshi also that he realized that his system would only be viable in the long term in the hands of an oligarchy of miners.

(from the same e-mail):


So much for the P2P nature of bitcoin, which was only intended as a bootstrap with useful idiots.  He clearly didn't care about a long-term P2P network, and the importance of decentralized nodes: he wanted a few big miner nodes, to which people would connect directly, without them even having the ability to download the block chain.  The block chain was just the ledger that a few oligarchs would share amongst them, hopefully keeping one another in check, to serve as the new centralized VISA backbone to which all users would connect.

However, the way bitcoin is evolving, and was actually designed with the 1 MB limit (and other practical limits), is that on chain transactions will be limited to a few big actors and will not reach large scale, but on the other hand, that most people will be able to download a chain with which they cannot do anything apart from contemplating how big guys are filling it with their expensive transactions.

Bitcoin is "rich sleasy business" OWN private money, NOT to be used by normal people, contrary to what Satoshi initially announced.   Bitcoin IS downloadable by anybody, but not usable ; Satoshi announced bitcoin to be usable by anybody, but not downloadable except for a few miner oligarchs.

And why did it become a rich sleazy business money and not a VISA administered by a few miners ?  Because Satoshi put himself a 1MB limit on the block chain.  If he understood the game structure of bitcoin, he would have known that this limit would become immutable because it was needed to generate fees (which he needed for reasons of his diminishing coin creation scheme in the longer term) but then it couldn't turn into a VISA kind of money and he would deny what he had been proposing from the start  - and if he didn't understand the consequences of him introducing a "temporary" 1 MB limit, then he couldn't foresee that it was going to become a rich-business-only crypto either.

Well, my main problem is that I haven't seen any rationally built-up argument that breaks down mine.  A statement "you are wrong" is not a rational argument, BTW.


Well, it would be nice to line it out at least once

I repeat my arguments that bitcoin is built on inconsistent cryptographical bases.   I have outlined several arguments for that, and they still stand, as no logical argument is countering them (statements that I'm wrong, yes, but no arguments as far as I see).  Maybe I'm missing them.

Here is a summary of my arguments.

A) the 160 bit hash of the P key vs the 256 bit key in ECDS
B) the transaction hash of 256 bit

A is flawed because:
1) In the light of classical security levels as of now, A is contradictory.  256 bit ECDS is 128-bit secure (exposed in the short term), and 160 bit hash is 160 bits secure.  The 32 bits security gap between both is too large to bridge "short term" (10 minutes - days/weeks) and "long term" (centuries).  If long term = centuries, then 32 bits less is "seconds".  So or the long term is overprotected, or the short term is underprotected.   In fact, for about the same room and LESS computation hassle, you get FULL 160 bit security with 320 bit ECDS.

--> if long term needs 160 bits security, then 128 bit security is TOO LOW in the short term.

2) If you fear quantum computers, and you need to "protect" ECDS long term then first you are making a fatal crypto design error by designing with a primitive you expect not to be secure BUT on top of that, the situation becomes worse.

While classically, in the current scheme you get 160 bits security long term, and 128 bits security short term which is already too short, with quantum computing, the latter becomes essentially 0 bits security.  A full quantum computer FULLY BREAKS ECDS if it has enough qubits.  To crack a 256 bit ECDS scheme, you only need a few thousand clock iterations on a quantum computer, that is to say, essentially instantaneously.

But moreover, Grover's algorithm most probably can reduce the hash function to 80 bits security, which is not secure enough.

==> the 160 bit choice of the hash, leading to only 80 bits of quantum security, and the total failure of ECDS with a quantum computer, make the bitcoin scheme TOTALLY INSECURE.  

So the argument that Satoshi put in the hash to protect against quantum attacks:
1) fails totally when the key is exposed, but moreover
2) the 160 bit hash is simply too short, while he had a 256 bit hash available that would have been good enough.

In other words, A is classically flawed because for the same room and less computational hassle, one could have better short term security (160 bits security overall) ; it is quantum-mechanically totally flawed because the short term security is *totally* gone, and the long term security has been brought down too much with the 160 bit hash.

I haven't seen any argument countering this.  Hashing the public key was a faux good idea, because it used the space that could have improved the ECDS security if it held up, and if it didn't hold up it was "trying to protect broken crypto" which is a no-go.

B is also quite silly, because a 256 bit hash to recognize an earlier transaction is quite a silly idea, if bits are expensive on the chain.  In fact, the very idea of having to refer to a previous transaction is a silly idea, and the transaction malleability bug that comes with it even worse.  Addresses should have been single-use only from the start, and be their own lookup.  That would have been way, way simpler to implement, to look up and everything.  

There is a serious inconsistency in how UTXO are referred.
On one hand, there is all the work of having a totally ordered consensus of transactions: the block chain.  It would have been extremely simple to refer to a transaction output in a block chain: the block number, the transaction number in the block, and the output number in the transaction uniquely specify the UTXO.  No need for a hash, no need for 256 bit !

But Satoshi wanted to be able to indicate transactions that AREN'T in the block chain, in order to allow for micro-payments.  That, however, defeats the whole idea, because transactions are accepted or not based upon the *unspend nature* of a transaction in the block chain, so he didn't want to use the ordering that is naturally offered to us for normal payments, but replaced this by a hash (that could be modified before inclusion in the block chain, transaction malleability).  As I lined out, there's no need for such a big hash.  There's no need for 256 bits of hash, but on top of that, the uniqueness of that hash wasn't even guaranteed.  So that simply didn't make sense.

If it had been specified in the protocol that not only inputs can only be used once, but also addresses can occur only in one single output, then there wasn't any need to refer to the transaction (with a hash), nor to a specific output of that transaction: the address itself would be unique, and easily found, in the consensus chain, or in "floating" transactions.  In the current scheme, as the public key is part of the spending input, the address corresponding to it would be computed from it, so the whole 256 bits + 32 bits of order number could be left out ; in the scheme with the public key in the UTXO, you can in fact, derive the public key from the signature and the message signed.

http://crypto.stackexchange.com/questions/18105/how-does-recovering-the-public-key-from-an-ecdsa-signature-work

So you do not even have to publish any hash of the public key.

==> in both cases, you don't need to refer to the transaction, you win 288 bits for every input.

As Satoshi always insisted to only use addresses once, he could have imposed it in the protocol, and reduced the input size significantly.

==> the referencing of UTXO with 256 crypto hashes is clunky and wasteful.

A and B together make no coherent sense.  It works, but is clunky, and security compromises on one hand were made to "win a few bits" while almost 300 bits were wasted elsewhere, and on top of that, made the lookup of UTXO harder than needed.


I am not the one suffering from cognitive dissonance, because I have nothing at stake.  I just point out glaring problems in bitcoin as it was designed, which make me suspect that it wasn't done by a guy called Nash - or that that guy called Nash made more mistakes than one would have expected from him.   You, on the other hand, have a whole world view based on the belief that Satoshi had to be an (evil) genius.  I don't.  I would have liked bitcoin to be better designed than the clunky thing it really is.  It is quite a failure, wasteful, speculative and erroneous monetary theory behind it, transparent, slow and limited.  That said, it is nevertheless a feat to have put together this thing and it is always easy to throw stones with hindsight.  But that hindsight tells us it is clunky and contains severe design errors.


I already quoted Satoshi saying about the same from one of the first e-mails.  So he foresaw the current situation of an oligarchy of a few miners, and all the arguments of decentralization of nodes and so on, which is clear bullshit anyways, is something I've myself tried to hammer into the head of bitcoin maximalists.  But I consider that as a design error.  Visibly he didn't realize the amount of wasted power that would go into his system.


Nope, I'm quite indifferent to whether Satoshi was Nash, another genius, or just a relatively smart guy but designing a prototype that contained quite a lot of "features" which, with hindsight, turned out to be design errors.  

Ask yourself whose world view is hurt most:
- mine if ever it turned out that Nash was Satoshi (making me conclude that Nash's genius was probably having a bad day - can happen, given bitcoin's clunky design)
- yours if ever it turned out that Satoshi was just a guy in his basement

I'm not invested in this stuff at all.  I find it interesting because it teaches us how a non-governed trustless system behaves.  If anything, it shows us how easily it is to fuck it up with innocently-looking features.

Yes, I consider bitcoin, unfortunately, totally fucked up - which doesn't mean I think it won't rise in price for the next few years or even decades - but as "money that makes free" it failed utterly as of now, 95% or more of its market cap sustained by greater fool theory, and probably less than 5% used as money in one way or another.  And the last few months, I realized that this is mostly due to its design.  

I'm sorry about that.  I used to like bitcoin, and I used to believe that it could have been good money.  It turns out it isn't.  But it is a great gambler's token, and it is a great reserve currency for unregulated sleazy big business (but not for the normal user, only for the big sleazy guys).  This is why I don't like it.  I think Satoshi created a monster, and that, together with a lot of technical clumsiness of the design, makes my have some doubts about him being Nash. But I'm not emotionally invested into this.  In other words, when I see the work, I think it cannot be the work of a genius, or at most of a genius in a bad day. Simply because the result doesn't look very well constructed, not because it has something to do with my "world view".  Bitcoin turned out to be clunky and quite ugly.  If you think that a genius created something clunky and quite ugly, be my guest.  I'm just pointing out that for a math genius, things don't add up, and I haven't seen any explanation of why it doesn't add up.  Your "you are wrong" are not arguments, but just expressions of your un-argumented opinion.

I can write a letter to Pythagoras, saying "you are wrong, but you are suffering from cognitive dissonance".  That doesn't disprove Pythagoras' theorem.

If the elements I bring up WERE truly well-thought over, I'm sure that one could explain them clearly to me, or refer to Satoshi explaining them which would even be better.  I haven't looked through all of the documentation, but I have never seen (so maybe I missed it) a convincing analysis countering the indications of clumsy design I mention here *especially on the math and crypto side* which is where we could expect a guy like Nash to be top-level.

The design looks rather like someone having some notions of cryptography, having read some elements of security (like double hashing, which is also used when useful and when not useful), being selectively paranoid (using RIPEM-160 and SHA-256 because of different designs so that back doors in them would not be simultaneously open), adhering to erroneous concepts like "the more the merrier" ("if one thing breaks, another will save it") and not able to count bits or coherently defining security, sometimes doing things to protect against quantum computers, not realizing that the rest of his design is broken under the same assumption.

==> something got wrong when I tried to post, so here it is, hopefully, again...



I answered that already.  If you think that your system has to work when a component is totally broken, you don't use that component.   My answer to your rebuttal was already written out above, as I expected this rebuttal, but you're missing the point I'm making:

if 160 bit ECC is not secure in the long term, then 128 bit ECC is not secure in the REALLY REALLY short term. So this argument backfires.
Note that I'm totally aware that any public key cryptographic system is *potentially* easier to attack crypt analytically than the symmetric-key mixers that are used in things like hash functions.  But that doesn't solve the issue on the contrary.

Again: if you need a symmetric-key hash algorithm to keep your public key of 320 bits (160 bit security) safe from a quantum computer (I don't believe in them, but that's another matter), then using a 128 bit public key is going to be cracked before it got included in the block chain.

If a 160 bit secure public key cannot survive 50 years of attack, a 128 bit secure public key cannot stand a second of attacks.

This is what I tried to explain to you: if you think that ECC is going to be fundamentally broken, by quantum computers, DON'T USE IT AT ALL.  And if you use it, assume that a certain security level is going to be secure, and apply it.  But don't "protect" the broken system with another system ; because you are going to use the broken system at a certain point, and then you're done and that's what happening here.

Again, if 160 bits security ECC won't do where bitcoin is hiding it with a hash, 128 bits security won't do openly in the very short term where bitcoin needs it.


No, you don't seem to understand that if you can crack an ECC of 160 bits security in the long term (say, 50 years of computing), you can crack an ECC of 128 bits security in a single second *with the same equipment*.  There's a factor of 2^32 = 4 billion between them.  I was only taking 16 bits, this is why I arrived at an afternoon but between 160 bits and 128 bits there are 32 bits.

Look: 50 years = 50 * 365 * 24 * 3600 = 1.57 billion seconds.  If your quantum computer can crack a 160 bit security ECC in 50 years, it can do that 4 billion times faster for a 128 bit ECC, because the search space is 4 billion times smaller.  ==> 0.4 seconds.

This is why I tell you that it doesn't make any sense to have (strong hash) 160 bit security in the long term, and (weak ECC) 128 bit security in the short term.  


My point is that if you assume this to work one day, then you shouldn't use ECC.  And I just showed you why.


I'm perfectly aware of that.  But that's not the point I am making.  The 160 bit hash security is USELESS if the 128 bit ECC is not secure.  I'm perfectly aware that ECC has a higher chance of being broken than a hash function.  I'm not believing in quantum computers, though.  I have my own reasons to think so on which I will not digress.  But that's not even the point.  If you THINK that they will exist, simply don't use ECC (nor any known form of discrete log public key crypto) because it is TOTALLY BROKEN in that case.

There's no point in having 300 years of a secure hashed public key on the chain, which is then broken the second after you propagate your transaction and the node you send it to modifies it.  

You seem to be focussed on the long term security, but what fails utterly in the consistency of the system is the *short term security* under the assumptions made.  (and yes, I also made that error in the beginning of this discussion)

It is not the 160 bits that is insecure: it is the 128 bits after propagating one's signature and public key IF ever one makes the assumption that 160 bits ECC is not long-term secure.

There's no point discussing the rest as long as you didn't see my point here, so I state it once more:

If ever you have a doubt about the security of ECC in the long term with 160 bits, then 128 bits ECC security is gone essentially IMMEDIATELY upon broadcasting your public key and signature, making the entire concept broken.  This is why one should never use a crypto primitive of which one has a doubt over its security.

I'm only capable of understanding logical arguments, unfortunately

Yet another "strange aspect" of the bitcoin protocol is the following: the fact that we use bloody 256 bit transaction hashes.   Transaction hashes have limited cryptographic validity.  They are essentially "lookup" hashes.  Maybe I'm missing one or other security point, but I don't think so.  Being able to "fake a transaction hash" doesn't seem to win any advantage, because in the end, what counts is the signature as cryptographic "unlocking".  So in as much as the transaction hash is just a lookup hash, 256 bits is totally absurd.  There cannot be 2^256 transactions on the block chain ever.  64 bits would even be overkill.  At VISA rate with say, 10^11 (that is, 2^36 or so) we'd have thousands of years of spending with 48 bits, and with 64 bits, till the end of the universe or close.
If 64 bits is more than enough, we are wasting about 200 bits per spending for nothing.  If there was much ado to "compress" (erroneously) a 256 bit key into 160 bits to win 100 bits, then wasting 200 bits sounds cavalier.

But even if there is a cryptographic security to transaction hashes (which escapes me entirely), there's absolutely no reason to require much higher security levels for the transaction hash than for the key security !  The 200 bits extra room could be better spend on ECC security, or on key hash security, rather than on this silly transaction hash "security" which doesn't serve much of a purpose.

If bits are expensive, transaction hashes of 256 bits are ridiculous.

The 32 bit word indicating the "entry" in the transaction is also somewhat crazy.  Transactions won't contain 4 billion outputs.

So there's a lot of "spilled bits" which are totally useless in the specification of a transaction input.

===> EDIT: I should multiply my lookup hashes with two to avoid the birthday paradox of course.  But that doesn't change the principle.

Well, this is the kind of cryptographic "common sense" that doesn't make sense.  As I said before, one has to assume, in a cryptographic design, that the cryptographic primitives are about at the security level that is known - for the simple reason that one cannot predict the deterioration of its security level by future cryptanalysis.  As far as one goes, it can be total.

Let us take a very simplistic example to illustrate what I mean (it is simplistic, for illustrative purposes, don't think I'm cretin like that ).  Suppose that we take as a group, the addition group modulo a prime number, and that we don't know that multiplication forms a field with it.  We could have the "discrete log" problem in this group, where "adding together n times" the generator g, a random number between 1 and  p-1, is the "hard problem to solve", exactly as we do in an elliptic group.  Suppose that we take p a 2048 bit number.  Now THAT's a big group, isn't it ?  Alas, the Euclidean division algorithm solves my "discrete logarithm" problem as fast as I can compute the signature !

2048, 4096, 10^9 bit key, it doesn't matter: the difficulty of cracking goes polynomially with the difficulty of using it ! (Here, even linearly!).

So the day that one finds the "Euclidean division" in an ECC, it is COMPLETELY BROKEN.  The time it takes a user to calculate his signature, is the time it takes about, for an attacker to calculate the secret key from the public key.  As such, the ECC has become a simple MAC, and it doesn't even last 3 seconds once the key is broadcast.

--> if we assume that ECC will be broken one day, bitcoin's crypto scheme is IN ANY CASE not usable.  This is why the "common sense" in cryptography, of "protecting primitive crypto building blocks because we cannot assume they are secure" is just as much a no-go as the other common sense of security by obscurity.  It sounds logical, but it is a fallacy.  You think ECC will be broken, don't use it.  And if you use it, accept its security level as of today.  Because you cannot foresee HOW HARD it will be broken, and if it is totally broken, you are using, well, broken crypto.

Now, what is the reason we can allow LOWER security for the exposed public key, than for the long-term address in an output ?  The reason is a priori (and I also fell into that trap - as I told you before, my reason for these discussions is only to improve my proper understanding and here it helped) that the public key needs only to secure the thing between broadcasting and inclusion in the chain.  But as you point out, that can take longer if blocks are full than 10 minutes.  This can be a matter of hours.  Also, in micro channel spending, you have to expose your public key to the counter party for the time the channel is open.

Now, if we are on a security requirement of days or weeks, then there's essentially not much difference between days or weeks, and centuries.  The factor between them is 10000 or so.  That's 16 bits.  A scheme that is secure for days or weeks, only needs 16 bits of extra security, to be secure for centuries ====>  there is no reason to nitpick on 16 bits if we are talking about 128 bits or so.
There is no reason to introduce "short term security" if this is only 16 bits less than the long term security level.

In other words, if you are afraid that 160 bits isn't good enough in ECC for the long term, well, then 128 bits (as it is now) is not good enough either in the short term.  If you think a "quantum computer" can crack a 320 bit ECC key in 50 years, then that quantum computer will be able to crack a 256 bit ECC key in less than a day.

So you may very well protect an address with an unbreakable hash of 160 bits for 50 years your quantum computer breaks its teeth on, the day that you use that address in a micro-payment channel, by the evening the key is cracked.


Of course not.  You don't have to keep all UTXO in DRAM of course.  You can do much smarter database lookup tables.  If the idea is that a node has to keep all UTXO in RAM, then bitcoin will be dead soon.


Nope, Gavin Andresen is talking bullshit and confuses cryptographic hashes and lookup table hashes.

http://qntra.net/2015/05/gavin-backs-off-blocksize-scapegoats-memory-utxo-set/

If you need to keep a LOOKUP HASH of UTXO, then that doesn't need cryptographic security.  There's no point in having 160 bit hashes if you can only keep a few GB of them in memory !  160 bit lookup hashes means you expect of the order of 2^160 UTXO to be ordered.  Now try to fit 2^160 things in a few GB of RAM

You only need about a 48 bit hash of the UTXO to keep a database in RAM.  That doesn't need to be cryptographically secure.  Completely crazy to keep 160 bit hashes as LOOKUP HASHES in a database hash table !   And there are smarter ways to design lookup tables in databases than keeping a long hash table in RAM, ask Google

I'm not even putting this on the back of Satoshi.  I claim he made sufficient errors for him not to be a math genius but he is a smart guy nevertheless.  I can criticise him because of hindsight, I'm absolutely not claiming to be at his level.  But I claim that he's not of the type of math genius as a guy like Nash.  This is the kind of argument I'm trying to build.  

But SUCH stupid errors, I don't even think Satoshi is capable of.  It is Gavin Andreesen who is talking bullshit to politically limit block size.  If ever it is true that RAM limits the amount of UTXO in a hard way, then bitcoin is dead from the start.  But it isn't.

This is a very interesting read BTW:

http://satoshi.nakamotoinstitute.org/emails/cryptography/2/


The first piece in bold is the network configuration we talked about earlier: the backbone of miner nodes, and all others directly connecting to it, no more P2P network. (has nothing to do with the current subject, but I thought it was interesting to note that Satoshi already conceived the miner centralization from the start).

The second part is indeed considering bitcoin scaling on chain to VISA-like transaction rates, with the chain growing at 100 GB per day.  He's absolutely not considering a P2P network here, but a "central backbone and clients" system.

The point however, is the fact that most certainly, he doesn't think of any RAM limits on cryptographic hashes and hence on the maximum amount of existing UTXO permissible.

A priori, by hashing the public key, you don't win, but you LOSE space on the chain.  The reason is that you should consider an input and an output together.  A UTXO by itself is worthless if it is not spend one day.  So you have to consider both together.

Now, if in the output, you HASH the public key, you will have to publish that key openly in the corresponding future input, because otherwise, nobody will be able to check the signature.  If, on the other hand, you publish the public key at the output directly, without a hash, you don't have to repeat that at the corresponding input, you only have to specify the signature as everyone can go and get the public key to check it.  

--> hashing the public key adds a bit load equal to the hash length.

There are seemingly only two valid reasons to hash the public key:

1) you think that the public key scheme is vulnerable in the long term
2) you want to separate long term and short term security.

It is true that hashing the public key of 256 bits (which has a security of 128 bits) INCREASES its security to the level of the number of hashed bits if that number is between 128 and 256.  So it is true that a hashed key to 160 bits, is 160 bits secure, while the key itself is only 128 bits secure.  This 160 bit security is maintained until the key is published in a transaction.

However, let us make a small calculation.  Consider H the hash length, and K the key length.

Let us call long term security L, and short term security S.

Let us call B the total bit cost of an input and an output.

If there is no hashing, that is, if you directly publish the public key from its outset, then:

L = S = K/2

B_nohash = 3 K = 6 L = 6 S

(because there is the public key of length K, and the signature size is twice the key length, hence 3K)

If there is hashing, and we assume H between K and 2 K, then:

L = H

S = K / 2

B_hash = H + 3 K = L + 6 S

I will now show you why there's some craziness in this scheme:
Take Satoshi's system: L = 160 bits, S = 128 bits, which makes his B_hash(160,128) = 928.

Suppose that I would have taken L = 160 bits overall: B_nohash(160) = 960.

So I would only have used 32 bits on about 1 K more to have OVERALL SECURITY of 160 bits.

The hashing wins me 3% of room, to decrease the ECC security from 160 to 128 bits.

If I would have a direct address with a 320 bit ECC key, I would use about as much room on the block chain, as Satoshi's scheme, which LOWERS the security of ECC to 128 bit in the short term.

If I consider 128 bits enough, I would  have B_nohash(128) = 768 bits, which is about 20% less room.

In other words, apart from a suspicion on the fragility of ECC, there was no point in doing what he did.  And if there is a suspicion on that fragility, it is very wasteful to take a useless 256 bit key which would in any case easily be cracked by assumption.