|
Just accept 0 confirmations and run Bitcoin with -maxconnections=50. It's not a lot of money, and attacks against this are difficult.
|
|
|
|
Thanks for this, but checkAddress() appears to be broken for some addresses:
Those are all correct. Nothing can tell you whether someone actually owns an address. It simply checks that the address is in the correct form and contains a valid checksum. Try to send bitcoins to any of the addresses you listed. Bitcoin will either prevent you from doing so if checkAddress() is false, or it will show a green checkmark if checkAddress() is true. 1MU97wyf7msCVdaapneW2dW1uXP7oEQsFA bool(false) ** Actually valid ** I just tested this and checkAddress() returned true. Maybe you had some spaces or something: it does no "cleanup" at all. |
|
|
|
ah, theymos, you're here - so what about the key pool? will the 'looking at wallet backup' thing work?
Yes. It's good for 100 generations (and you can use the -keypool switch to increase this). I think an auto-send script would be easier, though. Also, I think there may be some cases where a keypool address would be thrown away without a generation (like if Bitcoin crashes, or maybe even when it shuts down). |
|
|
|
Should any Bitcoin be generated for it, will the address that the Bitcoin is sent to be the address that was initially generated for the client?
No. Each generation has a unique address created for it. This address is not shown in any Bitcoin interface. You could make a script that sends all generated coins to some address, such as this one: http://bitcointalk.org/index.php?topic=1431.0 |
|
|
|
Generators must bear whatever the network demands. If we ever reach a "professional" level of hundreds of transactions per minute, generators will have to bear that.
If no generators are capable of storing the 10TB block chain or whatever, then there will be no generators and Bitcoin will die. Limit adjustments won't make the chain smaller once it has already grown to a gigantic size. You do realize that if this limit is a constant, it will be really hard to change it when needed, right? It will not be hard to change. It will cause a certain amount of disruption, but it's not difficult. A certain group will change, and the change will either catch on with everyone else or the people changing will realize their new coins are becoming worthless and change back. |
|
|
|
|
The main reason for the block size limit is disk space. At 1MB, an attacker can force every generator to permanently store 53GB per year. At 10MB, an attacker can force every generator to permanently store 526GB per year. Even a small change in block size makes a big difference on the load that generators must bear. It must not be changed until the network is ready for it, and this time can not be predicted reliably.
If the block size limit is too high, an attacker can destroy the network by making it impossible for anyone to be a generator. If the block size is too low, fees get higher until the problem is fixed. Automatic adjustments would still carry the risk of adjusting to a limit that is too low.
|
|
|
|
Are you sure? Given any difficulty, you still have to crunch the numbers to solve a block. The more transactions, the more numbers to crunch, thus the longer it takes to compute a given hash.
Block hashes are only hashes of the fixed-size 80 byte block header, which contains a hash of the transactions. Transactions only have a small one-time CPU cost for adding. |
|
|
|
|
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. |
|
|
|
|
Show Posts
