Quote from: iamnotback on April 11, 2017, 11:35:55 AM

Unfortunately it is a true statement that it is impossible for someone to argue with a person who is incapable of comprehending.

@dinofelis, you should be smart enough to understand what I already wrote. You have repeated your argument, which I already refuted. It doesn't matter how many times you repeat an incorrect logic.

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.

Quote

I see no benefit of repeating my argument. You are capable of re-reading and thinking until you get it.

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.

Quote

I will quote what Satoshi wrote to @bytemaster (Daniel Larimer):

Quote from: satoshi on July 29, 2010, 02:00:38 AM

The current system where every user is a network node is not the intended configuration for large scale. That would be like every Usenet user runs their own NNTP server. The design supports letting users just be users. The more burden it is to run a node, the fewer nodes there will be. Those few nodes will be big server farms. The rest will be client nodes that only do transactions and don't generate.

Quote from: bytemaster on July 28, 2010, 08:59:42 PM

Besides, 10 minutes is too long to verify that payment is good. It needs to be as fast as swiping a credit card is today.

See the snack machine thread, I outline how a payment processor could verify payments well enough, actually really well (much lower fraud rate than credit cards), in something like 10 seconds or less. If you don't believe me or don't get it, I don't have time to try to convince you, sorry.

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.

Quote

Folks, I can see @dinofelis undergoing cognitive dissonance due to the shock of not wanting to admit that Satoshi was really a genius. It changes his whole interpretation of everything

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.