Bitcoin Forum
December 03, 2024, 07:50:35 PM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2]  All
  Print  
Author Topic: If SHA-2 is so secure then why?  (Read 4372 times)
becoin (OP)
Legendary
*
Offline Offline

Activity: 3431
Merit: 1233



View Profile
July 08, 2011, 11:06:54 AM
 #21

I wasn't sure you were a troll
Now I am
I wasn't sure you were stupid.
Now I am.
JoelKatz
Legendary
*
Offline Offline

Activity: 1596
Merit: 1012


Democracy is vulnerable to a 51% attack.


View Profile WWW
July 08, 2011, 12:09:18 PM
 #22

1) Obtain a community consensus on the change.
I have X amount of bitcoins in my wallet. Am I part of the community?
Actually, that's a very interesting question. From a technical standpoint, you only need the consent of the active miners. From a practical standpoint, you mostly need the consent of those managing the reference client.

Theoretically, a disagreement between a large group of miners and those maintaining the reference client could lead to a fork where the public hash chain splits into two incompatible groups of programs, each rejecting the other's hash chain, where everyone with bitcoins prior to the split has them in both systems (and could spend them differently in each system). However, letting that happen is in nobody's interest. So it's extremely unlikely.
Quote
Where can I read about the procedure to be followed when a community consensus for a change need to be obtained?
In the post you are replying to, which you already read.

I am an employee of Ripple. Follow me on Twitter @JoelKatz
1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
phantomcircuit
Sr. Member
****
Offline Offline

Activity: 463
Merit: 252


View Profile
July 08, 2011, 03:28:36 PM
 #23

1) Obtain a community consensus on the change.
I have X amount of bitcoins in my wallet. Am I part of the community?
Actually, that's a very interesting question. From a technical standpoint, you only need the consent of the active miners. From a practical standpoint, you mostly need the consent of those managing the reference client.

Theoretically, a disagreement between a large group of miners and those maintaining the reference client could lead to a fork where the public hash chain splits into two incompatible groups of programs, each rejecting the other's hash chain, where everyone with bitcoins prior to the split has them in both systems (and could spend them differently in each system). However, letting that happen is in nobody's interest. So it's extremely unlikely.
Quote
Where can I read about the procedure to be followed when a community consensus for a change need to be obtained?
In the post you are replying to, which you already read.

You need all stakeholders to agree to the change.  Although practically it is the client implementors and not the miners who decide which way to go, after all a miner isn't going to use a protocol nobody accepts as being valid.
becoin (OP)
Legendary
*
Offline Offline

Activity: 3431
Merit: 1233



View Profile
July 08, 2011, 03:54:35 PM
 #24

In the post you are replying to, which you already read.
I appreciate your effort to respond to uneasy question, Joel. Let me assure you that I'm an active bitcoin proponent.
elggawf
Sr. Member
****
Offline Offline

Activity: 308
Merit: 250


View Profile
July 08, 2011, 05:52:51 PM
 #25

The guy that was arguing with me basically said NIST announced this competition just in case... What I'm asking is 'If they don't want to wait anymore and are acting now just in case, what are you waiting for and don't act just in case as well?'

How are you prepared for a possible change in SHA?

Because the process of analyzing and certifying a new hashing algorithm is lengthy and fraught with pitfalls - the competitions take like five years because if they didn't, there's a good chance everyone would move to a new algo that is weaker than the one they're moving from. Because it takes a few years lead time for everyone to make sure there's no show-stopping weakness in the algorithm, it's typical to start developing new algorithms before the old one is proven broken.

Bitcoin, on the other hand, has the luxury of taking a mere few months to get everyone ready to go before we pull the trigger. We also have the luxury of we don't really need to do anything until there's a credible threat on the horizon - if we went ahead and began the upgrade to SHA-3 as soon as it's certified, then there's a few major issues:

a) It breaks backwards compatibility of the network;
b) There's still a tiny chance we could be moving to a weaker algorithm, as by that point SHA-2 will have had quite a lot of time of people trying to break it because it would be profitable to do so. SHA-3 on the other hand, if you break it now all you get is bragging rights;
c) It would be a political mess upgrading the hash mechanism for no good reason.

Now if there was a credible threat on the horizon, you'd probably be hard pressed to find anyone (save possibly a company that just dumped a few million bucks into SHA-2 ASICs) who'd disagree with making the gradual change. If someone released a "holy shit, it's broken now now now" attack on SHA-2, the community would gladly respond in a quicker, more violent and bloody manner.

I get the feeling that the conclusion you're leaping to is that they're working on SHA-3 because SHA-2 is broken. That's almost certainly false, the NIST competitions don't work that way - if the algorithm is broken, it's too late to still be working on the next one.

^_^
jackjack
Legendary
*
Offline Offline

Activity: 1176
Merit: 1280


May Bitcoin be touched by his Noodly Appendage


View Profile
July 08, 2011, 06:05:11 PM
 #26

I wasn't sure you were a troll
Now I am
I wasn't sure you were stupid.
Now I am.

Own address: 19QkqAza7BHFTuoz9N8UQkryP4E9jHo4N3 - Pywallet support: 1AQDfx22pKGgXnUZFL1e4UKos3QqvRzNh5 - Bitcointalk++ script support: 1Pxeccscj1ygseTdSV1qUqQCanp2B2NMM2
Pywallet: instructions. Encrypted wallet support, export/import keys/addresses, backup wallets, export/import CSV data from/into wallet, merge wallets, delete/import addresses and transactions, recover altcoins sent to bitcoin addresses, sign/verify messages and files with Bitcoin addresses, recover deleted wallets, etc.
ampkZjWDQcqT
Member
**
Offline Offline

Activity: 70
Merit: 10


GNU is not UNIX


View Profile
July 08, 2011, 08:51:14 PM
 #27

I'm surprised an option for changing bitcoin hashing algorithm was not envisaged in the original concept. Everything that is man-made can be destroyed or counterfeited by another man. This is why everything valuable for the society should have built-in mechanisms for defence and protection improvements in case it is needed.

False. Knowledge based on formal logic can't be destroyed. Theorems for instance. However, it would be more appropriate to describe them as being man-discovered rather than man-made.

If you found my comment useful please express your gratitude by doing an action of similar magnitude towards a better society. Thanks you!.
wareen
Millionaire
Legendary
*
Offline Offline

Activity: 910
Merit: 1001

Revolutionizing Brokerage of Personal Data


View Profile
July 08, 2011, 09:02:42 PM
 #28

Theorems for instance.
Too bad we still don't have proof for the existence of one-way functions - would surely boost the value of Bitcoins Wink

        ▄▄▀▀▄▄
    ▄▄▀▀▄▄██▄▄▀▀▄▄
▄▄▀▀▄▄█████▄████▄▄▀▀▄▄
█▀▀█▄█████████████
█▄▄████▀   ▀██████
███████     █▄████
█████▀█▄   ▄██████
█▄█████▌   ▐█████
█████▀█     ██████
██▄███████████████
▀▀▄▄▀▀█████▀████▀▀▄▄▀▀
    ▀▀▄▄▀▀██▀▀▄▄▀▀
        ▀▀▄▄▀▀
.PDATA..
.
TOKEN..
██
██
██   ██
██   ██
██   ██
██   ██
██   ██
██   ██

██   ██
██   ██

██   ██
██
██
██
██
██  ██
██  ██
██  ██
██  ██
██  ██
██  ██

██  ██
██  ██

██  ██
██
██
██
██
██   ██
██   ██
██   ██
██   ██
██   ██
██   ██

██   ██
██   ██

██   ██
██
██
TELEGRAM     BITCOINTALK     FACEBOOK
MEDIUM    SLACK    TWITTER    YOUTUBE
▬▬▬▬▬▬▬   E M A I L   ▬▬▬▬▬▬▬
██
██
██  ██
██  ██
██  ██
██  ██
██  ██
██  ██

██  ██
██  ██

██  ██
██
██
Pages: « 1 [2]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!