BTW, this could be turned into a potential (but difficult to pull off) attack: get a large mining capacity, make the difficulty go up, then, all of a sudden, stop mining.
Actually, that happened once on the testnet, when ArtForz redirected his rigs to it just for fun, producing blocks with ~4 times the usual hashrate. It took some months for the difficulty to recover, during which transaction confirmation was very slow. This would probably be a major problem for Bitcoin but I doubt someone has the required ExaFLOP/s idling around somewhere on this planet  I'm of the opinion that enough hashing power to disrupt the network does not currently exist in purchasable form. I think it would require a door to door search and confiscation operation in several countries. |
|
|
|
In other words, Bitcoin is INFINITELY divisible, therefore the loss of even 99.9% of all bitcoins is not a problem?
Yes. Should the need ever arise, we can switch to arbitrary precision representation. Coins that are permanently lost are essentially a gift of value to the rest of the bitcoin using world. |
|
|
|
|
Feel free to create a network that implements this idea. I suspect that a couple dozen people worldwide will join you.
The rest of us have absolutely no desire to change from a system that is incapable of forcibly removing our coins to one that is.
|
|
|
|
|
The correct chain is the longest one (the one with the greatest embedded difficulty, but it is usually the same thing). In the case of a tie, the provisionally correct chain is the fork you saw first.
Eventually, one or the other will win. Even if exactly half of the network considers each branch to be provisionally correct, it is very unlikely for both halves to find a valid continuation at the same time, so one fork will be longer. A single block fork is unusual, but happens every few hundred blocks. A two block fork is rare. I don't think we've seen a three block fork yet.
When that happens, all transactions from the blocks that became invalid are reversed, and added to the pending transaction pool. If a transaction is no longer valid because it attempts to re-spend previous transactions that were already redeemed in the winning chain, that transaction will not be accepted.
That is why people wait for several blocks to pass before they consider a transaction to be really confirmed. The deeper it is into the block, the harder it will be to reverse.
|
|
|
|
The stock client is the one you can download from here. |
|
|
|
|
Well, linpack benchmarks all measure in FLOPS, and the bitcoin network is still at zero FLOPS, so by the accepted benchmark, we lose.
However, we pwn the entire Top 500 list if you measure MIPS.
Then again, we have no spare capacity, so in a race to do any sort of computation, we will lose.
|
|
|
|
|
No, it works just fine with the stock client. You may need to create or edit a bitcoin.conf file to tell the software to listen for API requests.
|
|
|
|
And what you do with the psychological effect?
I mean, someone people will look back and say:
"Oh the good times, back in 2010, when I got 10.000 BTC for selling Pizza. Now I am getting this crap paltry 0,000001 BTC"
Even if 10.000 BTC was valued 15 USD and now 0,000001 is 30 USD
The psychological effect is overblown, particularly when the change is gradual. Observe inflation over the last 5/10/30/100 years. Wasn't the end of the world. Won't be the end of the world going in the other direction either. |
|
|
|
If the seller uses a single address for all receipts, how they know that they got your payment?
Doesn't the block chain keeps track of where the bitcoins you received came from? Yup, sure does. Your published payment address just got a payment that was last seen being sent to address 1NnZFpNK8aeL8PfDr4hMKDHQjoUkEPintE. Which of your customers sent that to you? |
|
|
|
|
The listtransactions command will do it, or listreceivedbyaddress. Most sites use JSON RPC to communicate with a bitcoind daemon, either running on the webserver or elsewhere.
You can play with it a bit on the command line to see how it all works. Normally, you use getnewaddress to create a new address, then setaccount to associate the address with an account (just a name), then "listtransactions" to see if it has arrived yet.
|
|
|
|
The Austrian school of economics says that deflation seems to have a positive effect on everyone and I would tend to agree. Inflationary economics seems to really be bad all around except for the government and central banks. In a In Keynesian/inflationary economics Goods and services tend to go up in price while the wages employees are earning go down in value every year, thus the need for employers to give out standard for living increases. In a Austrian/deflationary economy there would be no need for a standard of living increase as the amount of money they were making on a yearly or hourly basis would increase in its purchasing power each year.
I think this is wrong. Prosperity causes deflation. Deflation does not cause prosperity. A gain in productivity means that society gets more benefit for the effort expended, which is another way of saying that things cost less. |
|
|
|
|
Also, if you send, it will create a new address to receive the change.
|
|
|
|
|
If the seller uses a single address for all receipts, how they know that they got your payment?
|
|
|
|
I dont know that everyone agrees with that. However, I feel like thats the first response that makes a little sense to me. IF one feels it is truly in the greater good for the rollback to happen, then I can see why it would be supported. I supposed I am just confused about whether this is the Wild West or Wall Street.
Both. Bitcoin is the Wild West. Mtgox is Wall Street. Or rather, mtgox is part of a group that hopes to grow up to be Wall Street some day. |
|
|
|
|
The exchange part is easy.
Call me when you figure out how to do a decentralized clearing house.
|
|
|
|
It has many advantages, and only one gotcha, that being that a legitimate network partition could get into a state where it is not possible to reconcile the two halves manually.
Er. More than one. You end up with a byzantine generals problem in determining that a situation exists which requires the higher difficulty. Normally we solve the byzantine generals problem by using the blockchain, but in this case we'd need to secure the blockchain a blockchain and we'd have infinite recursion. Nah. It is just counting, and the decision happens on each node. For what it's worth, I think that a permanent fork would be close enough to impossible not to worry about. I can't think of any way to divide a large fraction of the world's hashing power from the remainder for more than a couple of hours. Well, I can think of a one way, but if alien spaceships shoot down all of our satellites, jam all radio and microwave transmissions, and cut the earth in half, we'll have bigger things to worry about that day. |
|
|
|
It rejected what I would consider a very strong password ... I hope they understand that making passwords harder just encourages people to write them down, which is actually less secure in the long run. You figure since they took so long to fix it; they would at least do it right instead of going nuts. FAIL.
Someone can't look at a written password over the internet. I actually encourage people to use strong passwords and write them down. I just make sure that they understand that the proper place to store the paper with the password is with their other small, valuable pieces of paper, in their wallet. They can with a keylogger. This doesn't change the relative security of written vs. unwritten passwords. |
|
|
|
It rejected what I would consider a very strong password ... I hope they understand that making passwords harder just encourages people to write them down, which is actually less secure in the long run. You figure since they took so long to fix it; they would at least do it right instead of going nuts. FAIL.
Someone can't look at a written password over the internet. I actually encourage people to use strong passwords and write them down. I just make sure that they understand that the proper place to store the paper with the password is with their other small, valuable pieces of paper, in their wallet. |
|
|
|
I guess there is some interest in the inner workings of exchange markets, so I'm going to publicly post a PM exchange. Note that I'm not affiliated with mtgox in any way. I have an account there, but I've never funded it or done any trades. But, I have designed and written software for exchange markets before. This is conjecture on my part, but experienced conjecture. I'm only posting it here to show that there are possible technical reasons why an exchange system might exhibit strange behavior during unusual events. I'm not claiming to disprove any of the many conspiracy theories running around these forums, but I am showing that one is not necessary to explain what happened the other day. Also, my mention of MySQL is not a claim that they are using it. I have no idea what they are using. It started with a PM about a comment I made on why the exchange didn't lock the order books while processing matches. "This is a bad idea, but it isn't obvious to people that haven't written or worked with large exchange markets."
A quick explanation, or a reference to where I can find out more? This is interesting.
The short version is that you take a huge hit to performance to prevent something that can't really be prevented and almost no one cares about. Unnecessary locking means that you need several times as much capacity to handle the same throughput. There are schemes that can queue up orders before dumping them into the main databases between locked transactions, but this means that either orders get delayed, or the clearing code has to check two sets of tables (which means new delays). Exchanges that get a lot of traffic are always coded with an order matcher that finds one match at a time before moving on. They are simple and fast, or efficient, really. And you could still simulate the same behavior by having the order matcher take extra steps for orders that matched, but didn't close out. It just has to keep attention on that order until it fails to match once, and only look at opposed orders that are older than the time when the matching attempt started. But no exchange does that, because people placing large orders benefit when other orders jump in front of the sale. Serious participants would just write their trading bots to nibble instead of chomp, to give people (and other bots) time to reposition themselves to their mutual benefit. So, it would have reduced confusion in this situation, which is very rare and unusual, but it would hindered operations the other 99.99999% of the time. After sending my PM, I realized the beneficial implications for both the buyer and the seller as well as the likelihood of partitioning (nibbling) a sell off. Thanks for your response though! Nonetheless, I still surmise that mtgox is likely small enough such that the infrastructure is managed quite similar to what I proposed, especially given the length of time for the sell off to complete. Based on reports of the site's sluggishness during the rundown, I would suspect that their order matcher runs at full speed (and possibly high priority) until it is unable to find a match, and then it sleeps, allowing other processes use of the CPU and IO capacity. I've had big orders clobber stout boxes before, and until it happens to you, the value of only matching a fixed number of transactions before yielding for a second isn't always obvious. Keep in mind that while it isn't necessary to do much locking when adding an order, any time there is a match, both order tables must be locked, along with tables for balances, ledgers and logs. Multiply that out by a couple thousand, and add flushes to disk after each transaction, and you can easily end up with 30-60 minutes of churn. Their choice of database may also have been a factor in that. Looks like they are using PHP, which usually goes hand in hand with MySQL which is awesome for a lot of stuff, but not necessarily for this. If there had been a big single lock, either of the table or the whole database, it would have been much quicker, maybe only a few minutes, but anything involving the locked portion would have stalled for the entire duration. |
|
|
|
Make it easier within the client to dump your bitcoins onto a flash/thumbdrive, making them inaccessible until re-imported into the client.
For example, say you have 50 bitcoins. You want to take half of them and put them on your thumbdrive. Insert the removable drive, and choose "export bitcoins to drive" in the amount of 25 bitcoins. After doing this, the client would report that you have 25 bitcoins available.
When you want to pull those coins off that thumbdrive, you could just "import bitcoins from drive".
Except that you don't "have" bitcoins. You have keys that you can use to control bitcoins in the blockchain by giving control to a different key. The metaphor you are using doesn't really work. You could sorta simulate the behavior that you are talking about by making a new key, sending half of your coins to it, then copying it to the flash drive and erasing from the main computer. But that doesn't do what you want either, because a stolen key remains useful to the thief for as long as there are coins in the chain that can be controlled by it. An attacker with your key can steal your coins at any time, even when you think you are safe because your flash drive is unplugged. Wallet security is very hard to do, not because no one bothered to make a simple way to secure them, but because security is very hard to do right. |
|
|
|
|
Show Posts
