|
It sounds like you actually only have two physical cores, and you're including the virtual hyper-threading cores. This has different effects on different architectures.
|
|
|
|
In a worst-case situation, would the whole chain have to be restarted with a new genesis block, or do you think some algorithm from some arbitrary block number, say block 200000, would require the new hashing/cryptographically securing algorithm?
The chain will never be restarted. SHA-256 is very strong. It's not like the incremental step from MD5 to SHA1. It can last several decades unless there's some massive breakthrough attack.
If SHA-256 became completely broken, I think we could come to some agreement about what the honest block chain was before the trouble started, lock that in and continue from there with a new hash function.
If the hash breakdown came gradually, we could transition to a new hash in an orderly way. The software would be programmed to start using a new hash after a certain block number. Everyone would have to upgrade by that time. The software could save the new hash of all the old blocks to make sure a different block with the same old hash can't be used.
|
|
|
|
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.
I did say "almost all cases". That would affect non-Bitcoin things, too. It'd be a case where everyone using SHA-256 is screwed. |
|
|
|
|
"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.
|
|
|
|
This statement from the documentation is simply incorrect. When you sen transactions, you don't know in advance that "they're going to have to pay a transaction fee" or even how much it might be.
When I wrote that there were no custom miners and only one set of rules. I updated it: Whoever sends the transaction is often able to guess what the appropriate fee will be based on their own fee rules. If Bitcoin believes the fee will be non-zero, it will not allow you to send the transaction without the calculated fee. |
|
|
|
|
I've had a long-term interest in distributed systems such as Gnutella and Tor. I also support Austrian economics and anarcho-capitalism. Bitcoin is basically an exact match for my interests.
I know that Bitcoin will work because I understand both its technology and its economics.
|
|
|
|
|
If you find some way of hashing faster, the generating difficulty will just get higher. You might control the network's CPU power for a while, but if you can figure out a SHA-256 shortcut, everyone else will, too.
|
|
|
|
I don't see how the currency would collapse if 50 BTC keep being created "forever". It is a matter of sinks and sources, just like you find in most MMORPGs.
Reality has limited resources. Video games do not. |
|
|
|
What happens to the transactions that don't make it into the current block?
The network forgets about them over time. Queued transactions are forgotten when Bitcoin shuts down (or when it crashes because it's using too much memory...). The attacker probably won't rebroadcast their spam transactions, but real users will. Will this create a de facto situation where TX fee is required for "normal" bitcoin users? Yes. This has always been inevitable. Would it make sense to introduce a consensus blacklist, of abusive bitcoin addresses? ie. miners could -- at their discretion -- simply drop TX's with the blacklisted addresses. This would be easy to bypass unless you also follow a transaction's history, and if you do that the attacker can "infect" people by sending them bitcoins. |
|
|
|
"* The system includes the capability to add a tiny fee to any transaction for super-fast processing. However, almost all users consider the use of that feature unnecessary. And, it would normally be no more than US $0.01 Also, it is completely OPTIONAL, and always will be."
Is that technically accurate? Probably soon every transaction will require at least a 0.01 fee to clear in a reasonable time. |
|
|
|
Very nice explanation, Theymos. Can you comment on "max block size" in the future? Is it likely to stay the same for all time? If not how will it be increased?
It's a backward-incompatible change. Everyone needs to change at once or we'll have network fragmentation. Probably the increase will work like this: after it is determined with great certainty that the network actually can handle bigger blocks, Satoshi will set the larger size limit to take effect at some block number. If an overwhelming number of people accept this change, the generators will also have to change if they want their coins to remain valuable. It might also work in reverse, where almost all generators decide to reduce (or raise) the max block size. If clients want to have any real protection from double-spending, they also need to switch. The limit needs to increase at some point if Bitcoin is to become mainstream. 1MB is not an awful lot of transactions, so not increasing it would raise fees to unreasonable levels. |
|
|
|
|
There is a small cost to adding a new transaction. You have to store the transaction until it is spent, validate the transaction, and recompute part of the Merkle tree for the block. There will also be big network, disk, and electricity costs for generating blocks.
Block size limitations indicate that the network is unanimously willing and able to download, upload, and store blocks of that size every 10 minutes. It will probably stay at the current 1MB until Bitcoin has a solid backbone of generators. Then it can increase rapidly.
Some generators will set fees to the minimum, and some will set fees to the highest profitable level in the hope of raising it further. Most will be set somewhere in the middle. The generators will be saying, "We want to be paid on average this much," and the users will be saying, "We will pay only this much on average." This creates a really nice effect: your transaction will almost always clear eventually, but more fee = more speed.
The "minimum fee" for a generator will usually be the fee that causes the most fee-transactions to be included in the block. Volunteers or people who feel that the generation reward is enough might have a minimum fee of 0. This will happen less and less in the future, though, because costs will rise, inherent rewards will be reduced, and you'll therefore want to create blocks with at least some non-free transactions.
If the network overcharges, competitors will come in that claim the leftover transactions. If the network undercharges (a high-fee transaction exists, but it is not included in a block in favor of a cheaper one), competitors will come in with proper fee-based prioritization.
When the coins generated per block is low, users may not be willing to pay enough for generators to ever be profitable. Transactions will be really slow in this case, and the users will hopefully change their minds. If they don't, the least efficient generators will leave, the difficulty will be reduced, and generation will be profitable again. The users will be saying, "I'm not paying for that much CPU power! Reduce it."
|
|
|
|
In other words, there isn't any way to "claim" a coin without spending it, is there?
Right. An coin/output can be referenced/claimed/spent one time. |
|
|
|
|
I see a few options for learning about your transactions:
- Have the sender give you the transaction hash, and then use getdata
- Download (and then discard) all new blocks
- Use IP transactions (hopefully with some sort of authentication). Maybe using a built-in system like Tor's hidden services.
"Polltx" would be really bad for anonymity. Even people who are not paranoid would probably have a problem with the information divulged there.
|
|
|
|
Functionally, yes. But more than one address cannot "own" the same coins in the blockchain, because the blockchain only records settled transactions. A special transaction that could have multiple claims must remain outside of the blockchain until someone actually claims it, I believe.
No; it's possible to create a transaction with a script that allows claim by any listed transactions. This is valid and would be included in the block chain. There's even a special command in Bitcoin's scripting system that does this: OP_CHECKMULTISIG. |
|
|
|
Sounds like you would be trusting that the peer that sent you the relevant transactions to your new transaction to not be sending you a doctored set.
Not at all. The transactions form a hash tree, and the root of this tree is in the block header. The headers, of course, are verified through the Bitcoin proof-of-work block chain system. The attacker would have to break SHA-256 in order to give you fake transactions. Does the protocol permit a lightweight client to download a specific block from a random peer, or does it have to download them in order? Yes. You can also request specific transactions by hash, which would be useful in this scheme. If two lightweight clients are dealing with each other, they might want to rely on the network to provide the transactions required for the Merkle tree. |
|
|
|
|
I think Pecunix allows you to transfer 0.0001 GAU, so I would add another decimal of allowed precision when 0.01 BTC is worth more than 0.0001 GAU (pretty soon, if prices keep rising).
The decimal should be moved when transfers over 1 BTC are less than 1% of all real transactions. So probably not for a long time.
|
|
|
|
|
Show Posts
