Bitcoin Forum
October 20, 2017, 09:04:39 AM
 News: Latest stable version of Bitcoin Core: 0.15.0.1  [Torrent]. (New!)
 Home Help Search Donate Login Register
 Pages: 1 2 3 4 5 6 7 8 [9] 10 11 12 13 14 15 16 17 18 19 20 21 22  All
 Author Topic: John Nash created bitcoin  (Read 20177 times)
dinofelis
Hero Member

Offline

Activity: 700

 April 11, 2017, 08:36:00 AM

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.

I already told you that if the public key were exposed for a longer (indefinite!) time, so you would need to increase the security of the public key.  But to what level given quantum computing may be coming?

And 256-bit was about the upper limit of what was available and well accepted in 2008.

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.

Quote
You are not accurately accounting for the savings in portion of UTXO that must be stored in DRAM (for performance) versus what can be put on SSDs. Without that in DRAM, then the propagation time for blocks would be horrendous and the orphan rate would skyrocket (because nodes can't propagate block solutions until they re-validate all transactions due to the anonymity of who produced the PoW).

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.

Quote
Satoshi just nailed you to the cross.

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/

Quote
>Satoshi Nakamoto wrote:
>> I've been working on a new electronic cash system that's fully
>> peer-to-peer, with no trusted third party.
>>
>> The paper is available at:
>> http://www.bitcoin.org/bitcoin.pdf
>
>We very, very much need such a system, but the way I understand your
>proposal, it does not seem to scale to the required size.
>
>For transferable proof of work tokens to have value, they must have
>monetary value.  To have monetary value, they must be transferred within
>a very large network - for example a file trading network akin to
>bittorrent.
>
>To detect and reject a double spending event in a timely manner, one
>must have most past transactions of the coins in the transaction, which,
>  naively implemented, requires each peer to have most past
>transactions, or most past transactions that occurred recently. If
>hundreds of millions of people are doing transactions, that is a lot of
>bandwidth - each must know all, or a substantial part thereof.
>

Long before the network gets anywhere near as large as that, it would be safe
for users to use Simplified Payment Verification (section to check for
double spending, which only requires having the chain of block headers, or
about 12KB per day. Only people trying to create new coins would need to run
network nodes. At first, most users would run network nodes, but as the
network grows beyond a certain point, it would be left more and more to
specialists with server farms of specialized hardware.
A server farm would
only need to have one node on the network and the rest of the LAN connects with
that one node.

The bandwidth might not be as prohibitive as you think. A typical transaction
would be about 400 bytes (ECC is nicely compact). Each transaction has to be
broadcast twice, so lets say 1KB per transaction. Visa processed 37 billion
transactions in FY2008, or an average of 100 million transactions per day.
That many transactions would take 100GB of bandwidth, or the size of 12 DVD or
2 HD quality movies, or about \$18 worth of bandwidth at current prices.

If the network were to get that big, it would take several years, and by then,
sending 2 HD movies over the Internet would probably not seem like a big deal.

Satoshi Nakamoto

---------------------------------------------------------------------

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.

1508490279
Hero Member

Offline

Posts: 1508490279

Ignore
 1508490279

1508490279
 Report to moderator
I HATE TABLES I HATE TABLES I HA(╯°□°）╯︵ ┻━┻ TABLES I HATE TABLES I HATE TABLES
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
dinofelis
Hero Member

Offline

Activity: 700

 April 11, 2017, 09:00:26 AM

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.
Full Member

Offline

Activity: 210

They're tactical

 April 11, 2017, 09:57:07 AM

WOAH...guys....

guys... guys...

you're obviously overlooking the OBVIOUS here:

John Nash was AMERICAN....mkay???

Satoshi Nakamoto was JAPANESE.....

DUHHHHHHH.....

so he's not Satoshi, stupid.

unbelievable.

I asked my girl friend yesterday, she is indonesian and work with chinese ambassy and she know a bit of japonese i think.

What she told me that satoshis is a word related to taoist concept of balance of opposite (male/female, yin/yan) etc, and nakamoto mean 'the central source of'.

http://www.ancestry.com/name-origin?surname=nakamoto

Nakamoto Name Meaning Japanese: ‘central origin’ or ‘(one who lives) in the middle’; found mostly in the Ryukyu islands.

http://www.behindthename.com/name/satoshi/submitted

Given Name SATOSHI
GENDER: Feminine & Masculine
USAGE: Japanese
PRONOUNCED: sa-TOH-shee
OTHER FORMS: 覚 Japanese
CONTRIBUTOR: Spirited Sarah on 3/12/2011
LAST EDITOR: Spirited Sarah on 5/11/2011   [revision history]
Meaning & History
Means "wisdom" or "sense" in Japanese

So litterally satoshis nakamoto would mean ' the central source of balance '. (Cause wisdom with taoism is related to duality of symmetric opposite)

Because with the kanji also name can be translated to a meaning.

And i'm pretty sure it's not hard to find connection between nash theories of equilibrium from opposite agencies and taoist philosophy of harmonious whole from opposite and central balance.

In the idea, it's not because you name a coin 'archimedes' or 'descartes' that your name is necessarily this

It more look like a philosophic concept based on tao and/or nash game theories, involving surely persons from different field.

It's almost sure to me it involve at least two persons from at least mathematics and IT background.

Because to get into implementing a game theory model on a P2P network like this, need necessarily two persons. And it's obvious the code is not involved with game theory math. But in itself it doesn't mean the value and parameters are not computed from a math model issued from game theory.

And i'm being more and more convinced that there might be game theory model directly involved with the code of bitcoin now.

The two more important value for a node on POW is basically block reward and mining difficulty, that's the two things that matter, and it's exactly the same parameters you would find in game theory model (risk = difficulty = 1 / rateof ( good nonce) ).

Or it doesn't look like something that would not be very hard to express in term of nash game theories.

iamnotback
Sr. Member

Offline

Activity: 336

 April 11, 2017, 10:52:04 AM

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.

You're either not comprehending or being disingenuous. Do you not know that Shor's algorithm is known to theoretically break ECC but not hash functions? I had already told you as follows, that the hash has greater security for expectations of quantum computing. It is a prudent precaution.

Another reason (in addition to the compression of UTXO) to hash the values on the block chain is because when the use of a quantum computer is detected, we have some protection against chaos and can map out a strategy for burning the values to a new design securely. Hashes are much more likely to be quantum computing resistant.

If you argue that it doesn't matter if we have the hashes when ECC is broken by quantum computing, because the transactions can be intercepted and cracked by the attacker before they are confirmed in the network, you would not be thinking clearly. Because quantum computing would at its inception (nascent stages) likely be only able to break long-term security but not short-term. So there would be a period to transition as I already stated in the above quote from my prior post.

Please be more thoughtful, because I am losing precious time where I am confident you are smart enough that you could have figured this out if you'd remove your highly irrational confirmation biases.

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.

You are describing future cryptanalysis breakage of the math theoretic security of the intractability of the discrete logarithm over certain fields.

But you're analogy does not apply, because Shor's algorithm (a form of cryptanalysis) is already known! It is not a future unknown.

Also (and this is a minor point which isn't really necessary for my slamdunk) you are conflating the breakage of discrete logarithm math theoretic security with the security of permutation algorithms of hash functions. I repeat the distinction between the two which you have failed to assimilate:

You are uninformed. Crypt-analysis breaks on hash functions typically lower the security in bits, but don't lower it to 0 bits.

As I had originally pointed out you are conflating two entirely different systems of security and each can benefit orthogonally from increased bit lengths when we are not concerned about an intractable brute force enumeration attack and instead concerned with math theoretic cryptanalysis breakage.

Thus...

--> 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.

Not only are you failing to assimilate the fact that Shor's breakage is already known (not a future thing not knowable as you are arguing) which is sufficient slamdunk on why you are incorrect, but you are also claiming that hash functions can typically be entirely broken in one swoop which afaik not the case (and I studied the cryptanalysis history on past SHA submissions from round 1 to final rounds).

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.

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.

You have incorrect conceptualization. The point of long-term security is not the difference in the time it takes to crack with a given level of technology, but rather that over the long-term we can't know when that moment comes that cracking has become sufficiently fast enough. The Bitcoin UTXO from 8 years ago that Satoshi has not spent, could have been under attack for the past 8 years. By having the hash for the long-term security, then we force all attacks to begin only when the UTXO are spent. This enables us to restrict damage to a very few number of transactions and the community will become alarmed and take corrective action.

Yes you are learning from me (and sometimes I learn from you also). I was quite busy the past 4 years learning this stuff.

But I truly hope we can wrap this up, because I have some more important work I want to do today than debating with you, unless you're sure you have an important point to make. But please try hard to think because I have thought deeply about all this stuff already. You are not likely to find a mistake in my past analysis unless it is math based above the level of math I'm knowledgeable.

You are not accurately accounting for the savings in portion of UTXO that must be stored in DRAM (for performance) versus what can be put on SSDs. Without that in DRAM, then the propagation time for blocks would be horrendous and the orphan rate would skyrocket (because nodes can't propagate block solutions until they re-validate all transactions due to the anonymity of who produced the PoW).

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.

Satoshi just nailed you to the cross.

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

Of course I am knowledgeable about Shannon information content (entropy) and also efficiency of various sparse space lookup algorithms (in fact I did considerable research on this in 2015 which is why I am prepared to refute you now), the problem is DDoS resistance. The collision resistance on 48-bits is too low (especially relate that to equations for a sparse space lookup algorithm and the relationship between how full it is and the probability of collisions) so the attack can DDoS the network with invalid address, which force you to go off to SSD storage and bring your system down to a crawl.

And don't give me some BS about using PoW to rate limit, because I already refuted @Gmaxwell when he offered that to me as a solution. Just remember that PoW is a vulnerability to botnets at the nascent stage and then later it is a winner-take-all power vacuum. Satoshi had thought out all of these issues.

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.

I am sorry friend, but the errors continue to be all yours. This is the 3rd time I've replied and obliterated your arguments (pointed out the errors in your thought processes). I went down all the same thought processes you did, but had since realized that indeed Satoshi was a genius.

Maybe you will finally pop out of your pompous confirmation bias delusion and start to realize it too. I hope you aren't going to make a total asshat of yourself as Jorge Stolfi hath done. I know you are smart enough to stop insisting when you've become informed. You are informed now.

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.

I quoted that back in 2013 for making my points about Bitcoin was designed by the global elite.

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.

No you don't understand.

The DRAM issue is for the early decentralized years of Bitcoin's adoption so that the illusion of the idealism could be sustain long enough until Bitcoin becames unstoppable.

Given that Bitcoin will be a settlement layer between power brokers, then UTXO will not be a problem and also centralized mining will mean that DRAM cost is also not a problem.

Bitcoin has already reached the stage of being unstopped, which will be proven when it can't be mutated. Not by anyone. Not even national governments. NWO will be another thing however.
dinofelis
Hero Member

Offline

Activity: 700

 April 11, 2017, 10:53:06 AM

@dinofelis you are so myopic. Give me a moment to compose my rebuttal.

I'm only capable of understanding logical arguments, unfortunately
btvGainer
Hero Member

Offline

Activity: 798

 April 11, 2017, 11:12:29 AM

Instead of we discussing it here let Nash come up with some genuine proofs.We all know Satoshi created bitcoin and Satoshi certainly knows how to proov his identity.

iamnotback
Sr. Member

Offline

Activity: 336

 April 11, 2017, 11:14:25 AM

Instead of we discussing it here let Nash come up with some genuine proofs.We all know Satoshi created bitcoin and Satoshi certainly knows how to proov his identity.

Umm. John Nash is (purportedly) dead.
dinofelis
Hero Member

Offline

Activity: 700

 April 11, 2017, 11:27:05 AM

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

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.

You're either not comprehending or being disingenuous. Do you not know that Shor's algorithm is known to break ECC but not hash functions? I had already told you as follows, that the hash has greater security for expectations of quantum computing. It is a prudent precaution.

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.

Quote
If you argue that it doesn't matter if we have the hashes when ECC is broken by quantum computing, because the transactions can be intercepted and cracked by the attacker before they are confirmed in the network, you would not be thinking clearly. Because quantum computing would at its inception stages likely be only able to break long-term security but not short-term. So there would be a period to transition as I already stated in the above quote from my prior post.

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.

Quote
But you're analogy does not apply, because Shor's algorithm (a form of cryptanalysis) is already known! It is not a future unknown.

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

Quote
Also (and this is a minor point which isn't really necessary for my slamdunk) you are conflating the breakage of discrete logarithm math theoretic security with the security of permutation algorithms of hash functions. I repeat the distinction between the two which you have failed to assimilate:

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.
iamnotback
Sr. Member

Offline

Activity: 336

 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.

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

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

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.

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.

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, so it is very impossible for him to accept it immediately. Give it some time for it to sink in and he will slowly realize or become more obstinate and dig in irrational heels as Jorge Stolfi hath done.

Edit: I decided to throw him a couple more hints:

The 160 bit hash security is USELESS if the 128 bit ECC is not secure.

Incorrect. And I already explained why.

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.

Whether your disbelief of the likelihood is correct or not, Satoshi had a fiduciary and marketing obligation to design as if many people do want such prudence.
OliynyK
Full Member

Offline

Activity: 159

 April 11, 2017, 01:07:59 PM

Instead of we discussing it here let Nash come up with some genuine proofs.We all know Satoshi created bitcoin and Satoshi certainly knows how to proov his identity.
No one is going to come up with any proof and from what i understand he was good at math and not a programmer who is capable of coding this complex puzzle,it is a good try to come up with this name. It is not necessary that even Satoshi could provide any proof that he really did code the bitcoin at this juncture as any proof he comes up with could target against him,so he would keep quite rather than providing any proof.

▬▬▬▬▬  bitJob The Student Marketplace  ▬▬▬▬▬
█ █         [Whitepaper] [Telegram] [slack] [ANN Thread]         █ █
▬▬▬▬▬  STU PRE-SALE ▶ August 2nd, 2017  ▬▬▬▬▬
dinofelis
Hero Member

Offline

Activity: 700

 April 12, 2017, 03:12:49 PM

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):

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.

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.

iamnotback
Sr. Member

Offline

Activity: 336

 April 12, 2017, 03:31:38 PM

Well, my main problem is that I haven't seen any rationally built-up argument that breaks down mine.

Maybe I'm missing them.

You are. And the onus on you is to read my prior text and contemplate/assimilate all the factors. I am not going to enumerate every permutation of the facts I laid out. You are capable of doing that if you put effort into it.
traincarswreck
Sr. Member

Offline

Activity: 308

 April 12, 2017, 03:34:04 PM

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 clumsiness and the monster that you describe as a great reserve currency for unregulated sleazy big business (but not for the normal user....is EXACTLY what Nash describes:
Quote
In a large state like one of the "great democracies" it is reasonable to say that the people should be able, in principle, to decide on the form of a money (like a "public utility") that they should be served by, even though most of the actual volume of the use of the money would be out of the hands of the great majority of the people.

Quote
And then the “integration” or “coordination” of those into a global currency would become just a technical problem. (Here I am thinking of a politically neutral form of a technological utility rather than of a money which might, for example, be used to exert pressures in a conflict situation comparable to “the cold war”.)

Quote
Here I think of the possibility that a good sort of international currency might EVOLVE before the time when an official establishment might occur.

Quote
if it were too easy to set up a form of “global money” that the version achieved might have characteristics of inferiority which would make it, compar-atively, more like a relatively inferior national currency

You simply do not understand the role of money in this world, and are a perfect example of why Satoshi never explained what bitcoin truly was.

iamnotback
Sr. Member

Offline

Activity: 336

 April 12, 2017, 03:36:24 PM

You simply do not understand the role of money in this world, and are a perfect example of why Satoshi never explained what bitcoin truly was.

Agreed. It is actually pointless (and counter-productive) to tell a man something he doesn't want to know.
richmcrich
Hero Member

Offline

Activity: 616

 April 12, 2017, 05:48:22 PM

It will be available on Litecoin. The masses will be transacting on Litecoin or some other off chain derivative of Bitcoin or even fiat system ecurrency such as SEPA. Bitcoin's protocol will not be modified.

What's this SEPA stands for? First time I come upon it.

Anyway, I hope bitcoin will someday be worth enough for me to buy some Mercedes/BMW suv.
SEPA stands for Single Euro Payments Area. For countries that honor SEPA and are included in it, it allows them to easily transfer money including bitcoin. I think the problem it solves is the otherwise difficult time one would have because of country borders and transfer costs.

In regards to John Nash creating Bitcoin I think I could just as well say someone else created it. I don’t think we will ever know for sure.

 bitJob ▄▄▄██████▄▄▄                ▄▄▄▄██████████████████▄▄▄▄        ▄▄▄▄██████████████████████████████████▄▄▄▄  ▄▄▄████████████████████████████████████████████████▄▄▄██████████████████████████████████████████████████████████  ▀▀██████████████████████████████████████████████████▀▀      ▀▀█████████████████████████████████████████████         ████████████████████████████████████████  ██         ████████████████████████████████████████  ██         ████████████████████████████████████████  ██         ████████████████████████████████████████  ██         ████████████████████████████████████████  ██         ████████████████████████████████████████  ██         ▀██████████████████████████████████████▀  ██          ▀▀██████████████████████████████████▀▀  ████                                                 ▄████▄                                                ▀▀████▀▀ . . . . .THE STUDENT MARKETPLACE..▬▬▬▬▬▬▬▬▬▬▬   Powered by Ethereum Blockchain II [Whitepaper] [Telegram][slack] [ANN Thread] II .STU TOKEN SALE.September 12th, 2017
traincarswreck
Sr. Member

Offline

Activity: 308

 April 12, 2017, 05:50:30 PM

In regards to John Nash creating Bitcoin I think I could just as well say someone else created it. I don’t think we will ever know for sure.
Absolutely true and intelligent point!  Although on other hand, how many people do you know spent the last 20 years explaining how an international e-currency with a stable supply and asymptotically stabilizing inflation rate would cause a currency war that would eventually end the monopoly on central banks and government ability to issue money?
iamnotback
Sr. Member

Offline

Activity: 336

 April 12, 2017, 08:00:50 PM

But I consider that as a design error.  Visibly he didn't realize the amount of wasted power that would go into his system.

Everything in Bitcoin was calculated for a reason.

Remember Bitcoin is made by the elite for the elite.

You disingenuously continue to pretend they weren't disproved.

So frankly we are reaching the point where we can't continue to have any dialogue because I don't waste my time with people who are disingenuous.

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 am not the one suffering from cognitive dissonance

You continue to repeat that lie (opinion) about Bitcoin having clunky design. Bitcoin has a perfect design for what the elite want.

You will suffer the most because you are not preparing for the fact that Bitcoin is a 666 tool of the elite. And you are not preparing for the fact that the EU totalitarianism where you are will get horrifically worse. You think the crisis is over in Europe. Lol.

For me it doesn't matter who coded Bitcoin, but rather whose design principles Bitcoin was modeled on. And what is the outcome of Bitcoin going to be and its impact on the world.

You think Bitcoin is a silly toy that will fade away. I think Bitcoin will become a key part of the new financial system after the global monetary reset coming in the horrific sovereign debt totalitarianism collapse underway.

Why are you sorry? I hate Bitcoin too (long-term, its okay for my uses short-term). But I know Bitcoin is unstoppable although I wish it could be stopped.

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

You were disproven. You might be blind or disingenuous and unwilling to figure it out, but that is not my responsibility to fix.

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

So is the entire fiat system. Have you not seen the \$quadrillion in global derivatives holding up the fiat system.

You don't understand what money is. Finance is primary user of money, not the masses.

Bitcoin is the high powered reserve currency money of decentralized finance for \$billionaires. You have no clue as to what is really going on. You are totally lost.

it is a great reserve currency for unregulated sleazy big business (but not for the normal user, only for the big sleazy guys).

Which is 95% of all business.

You don't seem to grasp that Bitcoin is how the banksters-gangsters will carry forward their wealth from the collapsing nation-state monetary system to the new one coming after 2024.

This is why I don't like it.  I think Satoshi created a monster

I don't like it either, but neither of us can stop it. You are highly underestimating the evil rise of Bitcoin.

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.

Consider the genius is evil. Then you realize Bitcoin could have been designed by an evil genius. The reason you think it is not designed by  genius, because you don't understand the real goal of Bitcoin. Thus you misattribute clumsiness where the truth is it was cleverly designed that way to serve an evil purpose.
iamnotback
Sr. Member

Offline

Activity: 336

 April 12, 2017, 08:08:05 PM

For countries that honor SEPA and are included in it, it allows them to easily transfer money including bitcoin.

I didn't know that SEPA can transfer BTC. Is it off chain?

Can you refer me to a document about that?
iamnotback
Sr. Member

Offline

Activity: 336

 April 12, 2017, 08:30:37 PM

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 !

Seriously you need to stop pretending you know anything about blockchain design.

This is beginners' egregious error.

Lol you just flunked the most fundamental issue of decentralized systems, which is there is no total order.
Full Member

Offline

Activity: 210

They're tactical

 April 13, 2017, 07:22:41 AM

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.

I can agree with you on certain point, but I would still be more nuanced about it, it's why I said to me there are contradictory aspect to btc.

Cause on one side there are these clumpsyness ,  can be seen on many points.

But on the other side, still, only the fact it was by far the first working crypto currency, that it's still #1 after 8 years, and it integrate many aspect like distributed database, the sig scripts, and the whole concept still involve good design thinking. Not something pulled out in a sunday afternoon by a student .

But yeah after indexing tx on 256 bits is quite a waste. No data base system would ever do this. The only interest is maybe for separate storing of the tx, where the whole prev tx integrity can be checked by the hash, and another form of index could get wrong tx or block. But in the context of database indexing and transmission  over network, clearly huge waste. Nothing use 256 bit hash of the data as index ! lol

It's why for me there are contradictory aspect making me think either it's a guy who was splinter gift in one area, and just average on others, or the concept and design from a guy, and the whole btc project made by a company to exploit it.

Either it's like work of genius where he doesnt need to put much care into things because he know exactly where he want to get at, and make the choice with a specific life time in mind with enough security for the use case in that time frame.

And sometime, the impression of security is more important than actual security, specially when talking to investors or the masses, since I saw the movie equity im not the same lol

It's why to me most of decision seem to have Been taken more in the context of startup thinking from a company, rather than by some nerds math genius.

But still the overall design is still smart, even if it contain  lots of things that "look secure and good" for average and investor, but clumpsy and not optimal from expert analysis.

But I cant get out of my mind that there is still a brain behind the concept. Either the btc dev copied the base  from something else, or he developped it iteratively, and left some things designed for something else.

But it still contain too much new things and mathematically /  economically sound concept, still #1 after 8 years for me to think it's just a student in his basement.

For me the clumsiness can be explained by :

Complex math theories implemented in cheap code

Targeted more to investor traders and gamblers rather than to developpers or expert

Severe time constraint on the development

But again maybe maybe not, it's hard to be sure of anything, neither about the original intention or if it evolved as planned.
 Pages: 1 2 3 4 5 6 7 8 [9] 10 11 12 13 14 15 16 17 18 19 20 21 22  All
 « previous topic next topic »