The only thing that can really harm bitcoin is some heavy mathematics or a bug, which would break the cryptography used.
Or maybe a superior successor to Bitcoin. The field of crypto-currencies is still young and little has been tried. If a new system would appear that combines all the advantages of Bitcoin while fixing some of it's disadvantages (doesn't scale to well, takes a long time to verify transactions) in some smart way, it might replace Bitcoin fairly quickly. Those who switch last to the new system will be left with Bitcoins that nobody wants anymore. However: Maybe the creators of such a successor system might make it recognize current Bitcoin wealth. The genesis block of the new system could include a snapshot of the latest Bitcoin block. That might actually be a good way to jump-start such a system among current Bitcoin users. |
|
|
|
Thx for all your feedback, tips and suggestions! Many of them are on my TODO list. Integrating more markets is probably the next thing I will be focusing on. Mt. Gox was just an easy and sensible first pick. However, before I include more markets, I would like to get in touch with the people running them about the best technique of doing so. Since I'm providing live-data on the website, the whole thing depends on having recent data available. Many markets only provide their trades over a webservice, which I would need to poll. I'm currently polling Mt. Gox at a rate of once every minute (@mtgox: I hope that is ok), but the software engineer in me finds that somewhat inelegant. I noticed that jgarzik has done some work on a streaming real-time market data server already ( http://bitcointalk.org/index.php?topic=2519.msg34154#msg34154). So I will see to what extend I can interface with that. Maybe it's a good opportunity to standardize on some format for trade data and set up streaming servers of this sort at the various markets. I would assume, that they are interested in providing their trade data in the most convenient form and also reduce traffic from polling. Another option I'm thinking about: I can't promise anything yet, but I might set up a gateway for those markets, who don't want to run a streaming server of this form. I can see how some markets might not want to bother with the effort, as it doesn't necessarily integrate easily into web applications. So I might end up polling them, but then provide the data over a streaming server. This way others, interested in the (then-sort-of) real-time data, wouldn't need to poll. Well, those are my thoughts so far on real-time market data. :-) |
|
|
|
I really like this, sent a tip.
Much appreciated, thx. :-) Be nice to be able to see a larger window of time.
Yes, nice suggestion. I might look into implementing something like that at some point. |
|
|
|
Very nice. A good example of a web page that does one thing, and does it well.
I would like the vertical axis to be logarithmic. This would give more interesting detail at the bottom of the chart, without losing the data points at the top of the chart.
Thx for the feedback! I played around with a logarithmic scale for a little while, but wasn't really happy with it. But you are right.. right now once in a while someone moves huge amounts of Bitcoins and blows the chart apart. =) .. I might look into the logarithmic option again at some point. |
|
|
|
I'm happy to announce that http://www.bitcoinmonitor.com is now online! Transactions, blocks and trades on (currently only) Mt. Gox are plotted on a chart there. The website refreshes automatically as soon as new data is available. Enjoy! :-) |
|
|
|
So the problem is not to know about it, but to know which of they two transactions is the "second spend".
Bitcoin's answer is that the "second spend" is the one that doesn't make it into the block chain accepted by the majority. Read Satoshi's paper to see how this works. Yes, I know, I read the paper. But that requires to wait for one or more confirmation blocks. I'm more interested in how to quickly (in a matter of seconds) sort-of-confirm a transaction and manage the risk that is associated with that. That's why I wanted to discuss the possibility of such a penalty, to shift the risk further in favor of a merchant using such a fast-track payment system. So as a merchant, you would then receive a transaction, broadcast it and wait - let's say 5 seconds - whether you see any conflicting transactions. If not, you accept it. If the attacker still manages to pull of a well-timed double spend, you know at least, that when the next few confirmation blocks come around, the fraud will be punished. |
|
|
|
transactions are timestamped, aren't they?
No, they're not. And if they were, the timestamp would be provided by the attacker... Ok, I see. Either way, a node can keep track on how much time passes between receiving the two transactions. |
|
|
|
Splitting the payment 50:50? So if I pay someone some bitcoins, any time I want I can take 50% of them back by spending them again?
Destroying the coins? If someone has already spent the coins twice, the spender is the one laughing and only the recipients lose if the coins are destroyed.
Thx for pointing that out. It should indeed only apply to transactions that a very close to each other in their timestamps (transactions are timestamped, aren't they?). If you attempt a double spend sometime 'later' it should just be rejected as invalid like it would now, without a penalty. In any case I doubt there's a practical way to implement it. If the majority of the network knows about the double-spend attempt, it has rejected the second spend anyway. If the majority of the network doesn't know about the double-spend attempt, it can't do anything in response to it.
A double spend attack is usually a race. So the problem is not to know about it, but to know which of they two transactions is the "second spend". |
|
|
|
I have been doing some thinking about double spending and would like to hear your thoughts regarding the following idea: If I understand this correctly, a double spend attempt of a coin can only be done by the person who is in possession of it. So how about introducing penalties for doing so? Right now when two conflicting transactions appear, the network eventually decides which one is valid and discards the other one. Instead, nodes could react in a special way to these attempts in one of the following ways: 1) Decide that the result of the two conflicting transactions is a 50:50 split of the double spend. So a merchant that has been tricked with a double spend would get a least half of the payment 2) or more radical, but maybe even better: simply destroy the bitcoins involved in the double spend completely Obviously such a penalty would have to be agreed upon among nodes, so the same proof-of-work backing would be necessary to decide whether the network really saw an attempted double spend and destroy the bitcoins as an result. Such a penalty would be most useful in settings where a merchant doesn't want to wait for one or several confirmation blocks, but instead just waits a few seconds for the transaction to spread through the network. This already prevents a number of attacks (see the snack machine thread: http://bitcointalk.org/index.php?topic=423.0 , especially this post by satoshi: http://bitcointalk.org/index.php?topic=423.msg3819#msg3819). This penalty would not make attacks impossible - a merchant could still be cheated (with an elaborated attack) into providing a service without payment. But after the dust settles, the attacker would also be left without his double spent coins, greatly reducing the incentive for such an attack (or at least prevent repeated attacks). Discuss! ;-) |
|
|
|
|
Show Posts
