"Breaking" Bitcoin's non-standard use of SHA-256 means finding a way of creating a proof-of-work hash without doing all of the normal hashing work. But in almost all cases, you would still have to do some non-negligible amount of work. All this does is make hashing quicker for you, and this is a problem that can be solved with difficulty adjustments.
"Breaking" SHA-256 is exactly like creating a new computer chip that can do hashing 20x faster per watt than everyone else.
It depends on how the the SHA-256 algorithm is broken. If somebody creates a quantum computer with 400 qubits and is able to create any arbitrary SHA-256 hash with any other prefix or expected "proof of work" with a Big O(1) level of difficulty, Bitcoins as a program would simply be screwed and potentially attacked as if somebody just brought on a million new machines into the network. It actually would be worse, as somebody with this kind of computing power would literally be able to create as many new blocks as fast or as slow as they cared, depending strictly on the speed of the computer to spit out new blocks. This could conceivably happen in this situation about a thousand times per second or more, which would set up a DOS attack on the network like you've never seen before. Difficulty could conceivably go to infinity in this situation and still not stop the flood of new blocks. They would also all be valid new blocks, at least according to the current algorithm, and could not be rejected based upon increased difficulty. Luckily, most current quantum computers are insanely expensive (that are genuine quantum computers) and have right now a dozen qubits as the largest register they are working with. There is reason to believe that Moore's law applies to Quantum computing, so it is something to worry about in terms of future plans for the currency, but I put this on the order of an issue decades away, if even that. It is also something which can be defeated at least temporarily by increasing the number of bits in the hash. Quantum computers and in particular Shor's Algorithm ( http://en.wikipedia.org/wiki/Shor%27s_algorithm) is a known weakness to encryption algorithms that depend on the public/private key method for them to work, of which the SHA-256 algorithm is certainly a member of that class of algorithms vulnerable to this kind of attack. This algorithm isn't O(1), but it is awfully close. What keeps it from being used is mainly a lack of hardware capable of carrying out the methodology, not a lack of ideas for it to work. It is possible that some sort of conventional Von Neumann architecture-type computer (what most people call simply a "computer") would be able to "partially break" the algorithm where hashing would be made considerably easier than is currently the case. In that situation, it would merely be a refinement of the algorithm and speeding up the process, in which case increasing the difficulty would protect the network at least for awhile (in terms of years of protection). Even then, it would be wise to look at replacing the algorithm with something else. That is ultimately the salvation for Bitcoins, and at some point in the future there will have to be a change in the basic algorithm used to creating blocks and used within Bitcoins. We should be planning for that eventuality, even if now it is purely hypothetical. The worst situation is an immediate and mandatory upgrade like happened to 0.3.9. You can change the hash algorithm, the problem would be that the cypto that allows one to 'sign' a coin would also be broken, making bitcoin theft possible. |
|
|
|
|
where is kiba? we need a bitcion comic bounty already! For what it is worth I pledge 50BTC!
|
|
|
|
|
I think that we should put the 3rd decimal place in immediately, however pop up a warning if the transaction is less than the transaction fee(leave the transaction fee as it is). I think that will be a useful tool to educate people about transaction fees.
Much later on (aka a year), we should change the units from BTC to BTCe-3. (and the associated extra 3 decimal places of precision). The client should then have options to have BTC, BTCe-3, or BTCe-6 as it units. (each with 3 decimal places of precision... in th GUI)
At that point, allow people to choose a transaction fee of their choice. The client software should also provide some statistics on how long it takes for a transaction of any given fee to be included in the block chain (based upon the block history), and a warning if the fee is likely to be wasteful.
I think the current system where the transaction fees are invisible gives a false impression on how the network works.
|
|
|
|
I am running out of bitcoins(pledges, bounty donation, etc), so I can't hire you or anybody to make graphics.
I can sympathize with this... They really disappear fast. |
|
|
|
|
Now this is a comic I'll donate serious bitcoin to.
(and then post it to /b/ )
|
|
|
|
|
Just for fun. I'll add some more polls later on... if it is possible.
|
|
|
|
Secondly a phone is more cumbersome than: insert, check amount, pin.
But a smartphone is a gaming device, camera, phone, and a computer at the same time. Yes, and I think that a Java (aka, android) client for bitcoin will be immensely useful and important to the success of bitcoin. That doesn’t change the fact, IMHO, that a smartcard solution is superior when you are shopping for your groceries with bitcoin. |
|
|
|
|
Oh yeah, smart cards are much cheaper to produce than a phone, don't need to keep current with the block chain (the “EFTPOS” machine dose that), and can be stored easily without worrying about theft (pin code).
|
|
|
|
Smartphones are more futureproof than bitcoin smart card?
Yes and no. A bitcoin smart card could be (almost) as reliable as cash. As the TPM could be signed by a 3rd party verifying its integrity, and the “EFTPOS” machine could be directly connected to a core processing network so the transaction is propagated very quickly throughout the generation system. This would allow businesses to do transactions without waiting for the transactions to be verified. On the other hand, mobile phones, must wait for at least the transaction to be propagated to the receivers mobile phone/device, an in general case, it would require one block to be generated before accepting (tentatively) accepting the transaction. Secondly a phone is more cumbersome than: insert, check amount, pin. |
|
|
|
I have done a lot of thinking about the ‘bitcoin cash’ problem, I have finally concluded that there is no natural way of having ‘bitcoin cash’ using bitcoins themselves. For a cash like equiv. see: http://bitcointalk.org/index.php?topic=847.0I was wondering, in the future the bitcoin client is going to (hopefully) become more flexible in handling multiple wallets. This trend will lead to the stage where all the block chain is ‘loaded’ and stored, and the client ‘opens’ a wallet, dose business, and closes it. Enabling many people to uses the same software independently. With this concept in mind, I supposed that the only unique and important thing is indeed one’s bitcoin wallet, (and address book). Suppose there is a store, the equipment to conduct the transaction is fixed at the store, say cash register for issuing change, or an EFTPOS, whatever it may be the store manages the transaction for you. I see no reason that this cannot happen with bitcoin also. What would happen is that a smart card with a TPM or similar that holds all the private keys to the bitcoins, when a customer wants to conduct a transaction they place the card into the EFTPOS machine, enter the pin code (that is sent to the TPM), the chip signs the correct amount of coins over, then sends the result back to the EFTPOS machine. This means that there is no possibility of your coins (private keys) being stolen without the TPM taking a log of the transaction (a malicious machine could always sign all the coins to the hacker, but then there would be a log of the transaction, and the card owner would be able to tell when they use their card in a good machine). The private keys are never made public, only made invalid after they sign over the coins. The owner of the coins requires no expensive hardware, and the card is useless if stolen (while the owner of the coins can still use a backup). |
|
|
|
For use in ASCII text copy.... (when the png logo is not appropriate).... I vote for using ฿ As in...
฿25.50or....
BC฿25.50If you notice on this page, http://www.xe.com/symbols.php ....the $ and the € and the £ and the ¥ ....are all used many times... by many DIFFERENT countries' currencies. If there is any potential for confusion between the US $ and the Canadian $, we simply say, US$ or CA$. It's simple. Why not just reuse: ฿ This has been the most sensible suggestion so far. ฿ is the natural symbol for bitcon... just like $ is used in many places also. |
|
|
|
|
I recommend, instead of the GPL licence, maybe consider using the Apache License, Version 2.0.
|
|
|
|
|
I like the concept of useing bitcoin to donate with. But the whole point of bitcoin isn't to force anyone do do anything...
Btw, maybe we can make some good email templates.
|
|
|
|
|
The correction to the 0.13-0.17 resistance level was an important moment for the bitcoin currency, this notably has been the first time that the RSI has dropped (abet, briefly), blow 30. I think that the bitcoin market has been fundamentally changed, and will be much wiser in the future.
Firstly, now that the market has experienced a more full range of, say ‘emotions,’ the established resistance points will be much stronger, it will now take a much larger volume to move the price to the 0.5 and 1 points.
Secondly, fundamentally, I believe that the many in the bitcoin community are at a better understanding that bitcoin must use to trade real goods and services to be fundamentally sound, this will be reflected in the more cautious speculation we are now seeing.
|
|
|
|
Would a brand new i7 computer, with a gpu, PAY FOR ITSELF in Bitcoin generated (right now)?
maybe, depends on your luck, and the future rise in difficulty. |
|
|
|
BTW, is storing a file on FreeNet reliable ? I mean, as I understand it, FreeNet is P2P. This means that a file is there only if people use it. If I am the only one who need a file, isn't it likely to disappear from the network if I don't consult it regulary ?
It might stay for a week or two (unpredictable). It's certainly not a good destination for backup. They are working on two of the main issues with persistence: First, things aren’t getting routed to the right spot, so they are hard to find; the new load management code should relieve much of the issue as nodes that _should_ have the data will be much less likely to be 'backed-off', an overloaded state, and reject the insert. Secondly, there is an ongoing work to spread the word of freenet, the more people who run nodes, the more places there is to store data  |
|
|
|
|
all sent, I guess now we play the waiting game.
|
|
|
|
The problem with Freenet is that a) it's written in Java b) it's super fucking slow.
Otherwise I'd love the idea in practice
Not to defend what Freenet was/is, (super fucking slow). The project has come a long, long way since even 2 months ago. The new load balancing code is in the process of being merged, this should make a world of difference to the speed of Freenet: read the "Load management and other things" post by Toad at http://amphibian.dyndns.org/flogmirror/ for more info. Secondly I don't hold java to be as bad as it used to be, the main feature of it is the de-facto cross-platform compatibility, and high speed prototyping... On either note, I think that Freenet has a bright future. |
|
|
|
|
amended, thankyou noagendamarket!
|
|
|
|
|
amended, thankyou grondilu
|
|
|
|
|
Show Posts
