This is actually true, in the sense that bad money chases good money out of the market. This is one reason you don't see silver dimes anymore, even though they still exist. The difference is that, without some form of outside force compelling the consumer to deal in the bad money, why would they ever buy it in the first place?
Some people ask themselves the same question about bitcoin. Why would anybody buy them in the first place if there's the risk that that market does not develop? Because speculators can look at the system, and in particular the ultimate cap on the monetary base, and speculate that those bitcoins that they can gather and keep would be worth much more in the future. If it were permanently inflationary, those same speculators would be able to assume that even if such a support economy were to develop, those same coins would eventually be worth less in the long term. So again I ask, how would an openly inflationary version of Bitcoin actually bootstrap? Not like Bitcoin has, this is certain. Such a currency would have almost zero chance of overcoming the first value rule. Bitcoin's first value was a potential future value to speculators, but an inflationary bitcoin would never had that first value. |
|
|
|
Some people said in my thread that a demurrage cryptocurrency won't work for the same reason: people would switch to a clone without it. People would prefer to hold bitcoins. That's true. But people would definitely prefer to pay with...let's say...freicoins or timecoins (don't google them, they don't exist).
Bitcoin it's better to store value than timecoin and freicoin. But if they have any value, they will be preferred to pay. The payee can trade them for bitcoins as soon as he receives them or can trade them for other goods and services that accept them.
The payee prefers to be paid in bitcoins, but mostly prefers to be paid. If the payer does not have he can accept freicoins or lose the sell.
This is actually true, in the sense that bad money chases good money out of the market. This is one reason you don't see silver dimes anymore, even though they still exist. The difference is that, without some form of outside force compelling the consumer to deal in the bad money, why would they ever buy it in the first place? |
|
|
|
So, I don't see anything here that would refute my prediction.
Don't need to refute it. It's an opinion. |
|
|
|
Fantastic! Is that in the print edition too? Yup--May 9th. Well, that's it---I'm buying while it's still cheap. With that sort of press we're bound to get a few thousand newcomers buying in next month. yep but since print readers are typically a little slower to jump on something hopefully it will cause a slow gradual rise and not a hard spike and then a corrective drop. Wait, there are still print readers who use the Internet? |
|
|
|
To make it concrete: I believe I know (or at least know of) people who, under the right circumstances, could decide to mobilize relatively easily to get 1000 people with decent hardware to attempt to destroy the Bitcoin network if they thought it was a moral imperative to do that. Note that under the brand of libertarianism popular in these forums, such an "attack" would not be "criminal" or "wrong"; it would be an exercise of "freedom."
Well, yes (I don't know if 1000 people would be enough though). So what? Others were arguing that Bitcoin was a libertarian paradise, not a democracy. Bitcoin is neither. Bitcoin is simply a monetary system. There is no ideology there, and any that people project upon it is their own doing. At the moment, 1000 people with the right (consumer) hardware would be more than enough to compromise the network seriously if not disintegrate it altogether. I think far fewer would pose a serious threat. It's not hard for an individual to become about 1/1000 of the network's hashing power for about $1000 in hardware.
I doubt that, seriously. Just looking at the ongoing hashing power doesn't tell the whole story. I'd wager that there are plenty of people with respectable hashing power that do not presently participate, that would be willing to generate at a loss if an ongoing attack were to become evident. That includes myself. Granted, there is no way to know how much hashing power remains in reserve. But is is easily false to assume that there isn't any. And my my rough calculations, an attacker would need roughly 31K GPU's just to overtake the honest network at this writing. |
|
|
|
A modest inflation of say 1% ? would preserve the award mechanism to promote productivity for individuals/small groups,
I'm not sure if I missed it, but I'm really surprised that no one had pointed out that Bitcoin currently inflates at around 40% APR, and will continue to be inflationary for as long as some of us could hope to live. |
|
|
|
Remember when a Bitcoin used to be worth $0.005 ....?
No, I wasn't around here then. And neither were you. Did you intend to say $0.05? |
|
|
|
Just a weekend is coming. So a trading may slow down until Monday.  People have a lot more time on the weekends, they are not at work/school/etc. I often wonder why trading is down on saturday/sunday for "normal" markets. Because "normal" markets are closed. |
|
|
|
It's irrational to think that will have no effect whatsoever. Yes, it will certainly have some effect. Now, if taxes didn't exist, some ability to fund research would be lost too. I'm not convinced that the increased generosity would make up for that. Just for your puzzlement/horror: http://news.bbc.co.uk/2/hi/europe/8321967.stmI'm not shocked, really. All governments are functionally owned by the wealthy citizens, and a good show of social solidarity would generally encourage the middle classes to not complain later if the wealthy are willing to put up now. Of course, the middle class is who pays for almost everything anyway, and the wealthy will get their taxes cut again later on, but it's always a horse and pony show anyway. |
|
|
|
Give it a little bit of time--not everyone lives online.
Why would anyone want to go out there? |
|
|
|
|
Twilight seems to not have cared for the response, since s/he registered in order to post once, and logged off never to return.
|
|
|
|
This is really cool. I've been between getting an iPad or Xoom for my business, but now I'm definitely leaning Xoom.
Have you seen the Asus Transformer? |
|
|
|
Do you think one hour was too long?
Of a weekly show involving two New Yorkers talking about money? I would have to say yes. |
|
|
|
I think I'm getting confused here. At first you talked about a lightweight client connected to a trusted node back at the office. Now it's untrusted.
A user of an independent, lightweight client can either have one trusted full client he intentionally connects to, such as his full client on his home PC; or can connect to a number of random untrusted peers. The end result is the same, since your full client at home is ultimately connected to numerous untrusted peers itself. The trust comes from polling multiple sources and comparing the results until it becomes statisticly remote that you have been spoofed. The point of forcing the mobile client on your smartphone, lightweight or not, to connect to your single trusted client at home is so that you can move the resource consumption issue to the full home client and off of your wireless data plan. Likewise, the lightweight client that only keeps the block headers locally does so to reduce local storage consumption; but for now, this really isn't an issue on the home PC.
Also, I said it'd be possible to do transactions without internet access for buyers only - I agree there are no situations in which sellers would want to use BitCoin without internet access. And mostly both sides would have it so there's really no issue here.
Perhaps I misunderstood. Client-mode can still be useful even for sellers, consider the case of you paying a restaurant bill and then asking your friends to contribute their share by tapping their phones to yours.
Your freinds presumedly already have your trust, so there isn't really a need for the lightweight client to be able to verify that independently in real time. Likewise for moving funds from your full home client to your mobile client, as you can presumedly trust yourself. The lightweight clients still need to have copies of the blocks that contain your coins, so that they can properly create a spend transaction; so if two light cleints are connected ad-hoc so that one person can send the other funds, a copy of the referancing blocks can move in the same manner, but you had better be able to trust the person giving you the transaction.
On lightweight clients. You could build a system in which only the wallet was hosted locally and it connected to a specially built server. The server would be given the output addresses, a list of every public key in the wallet and create a partially complete transaction which would be sent to the client. The client would sign it and send it back to the server, which would then relay it across the network for you. The client relies on the server to tell it the current balance.
You could do this, but then the light client wouldn't really be independent, and it's practically the same as using a remote control client to tell your full client at home to do the transaction. That model is lower resource usage than even the 'simplified payment verification' model and might be worth investigating if client-mode is still too resource intensive for smartphones. The big downside is you lose all privacy. To build transactions for you the server needs to know all your public keys and thus, your entire balance and naturally gets to correlate them all together as a result. It can't spend your coins but it can track you pretty well.
The privacy issue isn't an issue if you own the full client also, but the point of a lightweight client is to be able to transact sans Internet. |
|
|
|
The regular client doesn't perform a check of the live transaction queue, but it could be done. I'd be willing to bet that it will be a standard check on POS systems long before Wal-Mart starts accepting Bitcoin at their registers. And a slick POS client could also send the transaction to all of it's peers except one, and if that peer offers back that same transaction then it's safe to assume that the transaction is good. Even if there is a double spend attempt underway, if your own POS system has a decent spread of peers and your last peer then sends you the correct transaction, odds are high enough that your transaction was first (and therefore most likely to come away with the actual bitcoins) and therefore acceptable. This would be acceptable risks for sales values under $50, and is similar to how credit card companies handle charges under $50.
Such a check wouldn't take nearly 15 seconds under normal network loading conditions, but a 15 second timeout would be reasonable.
That is an interesting idea. I'm not so sure that gives you that good of certainty. If there was a malicious user, it would be their goal to send out the tx they dont want to see accepted as much as possible through the network. Although it would provide protection, some users would still exploit the system. Whether that is enough for places to take the losses, I don't know. No, not certainty, but high probability. If the POS owner chose his peers well, it would be a quantifiable probability; but it would be pretty certain under random peer selection as well. High enough that I'd be willing to offer vendors insurance against a double spend fraud, and I'd be running the POS super-node. I can forsee an niche industry of Bitcoin processing companies offering such insurance to small vendors, but chains such as Walmart or Sears are going to do such thinkgs for themselves.
In any case I don't see a future where every normal user is using standard bitcoin nodes. The network probably won't handle that and I doubt merchants will want to run their own bitcoin instances all over the place. Much more likely is a set of payment processors using bitcoin as the currency of exchange.
That's it exactly. In the short term, Bitcoin vendors are likely to have normal clients running in the store, but ultimately such functions are likely to be consolidated into datacenters with special POS light clients in the store. This is pretty much how credit card transactions are handled these days. The important part is that an independent vendor always has the realistic option of setting up a local full client if his service company ever gets uppity, and the customer also always has the option of setting up his own full node if he ever has reason to distrust his online wallet bank. Keeps these groups honest. |
|
|
|
After 2012 though it's not so certain. I am not positive that it will remain cost-effective to continue expansion, but it should still be marginally profitable to keep the existing rigs running for another year or so. I am hoping that by then there are better alternatives available which will help me to further reduce operating and expansion costs.
When the block reward drops to 25, and transaction fees begin to matter, these mining profit calculations are going to become much more difficult than they already are. |
|
|
|
Well, you say "trusted full client" like that's an easy thing to conjure up. If I were to host such a server on my personal box, would you trust it? With Ⓑ10 sure. With Ⓑ10,000 .... heck, even I wouldn't trust my server with that, I just haven't put that much effort into securing it. Linux boxes get hacked all the time.
What about MyBitcoin? That's the canonical example of such a cloud wallet. Its contact address is a PO Box in the West Indies - if things go south, what are you going to do?
I'm not talking about remote wallets, just simply a remote full client that you can query whom you already have a relationship with before walking into a transaction. You don't have to trust another machine or user to hold your wallet.dat file, you just have to have a party that you know isn't interested in the outcome of your transaction. An untrusted third party, if you will, but each party to the transaction needs at least one of such a client; and if you set up a full client of your own back at the house, I'd bet that you could trust it. An independent, open source mobile wallet: - is as easy to set up as BitCoin itself is (just install)
- can be verified by reading the code (lots of people know Java and can compile it themselves)
- does not require any trust in third party security procedures
- potentially doesn't even require an internet connection to buy things, as long as the merchant has internet access and can broadcast the transaction for you.
Today, the BitCoin community is made up mostly of people who have never met each other (I've met a few key people in person like justmoon, but not many). So minimizing the trust needed is useful and very much in the spirit of BitCoins design. I don't disagree, but the above list is ideal for a client intended to convieniently spend coins, not accept them. The spender doesn't need to be able to verify anything, at least not in real time. It's the vendor selling things that is taking the risks. Again, I ask the question; in what context would a portable POS system that needs to be disconnected from the Internet be useful? Even hotdog vendors have Internet access. |
|
|
|
On the other hand, smartphones have internet connections nearly all the time. If it became useful for payments then big merchants that somehow didn't have good coverage already would get microcells installed. Your phone does the usual 3G handshake with the cell and gets a trustworthy, disinterested internet connection.
Or simply an open wi-fi connection with common ports blocked, but not Bitcoin ports. It is in the interests of the vendor to make sure that Bitcoin users have ready access to the Bitcoin network, even if they wouldn't want to have warwalkers mulling about the store downloading porn over thier Internet connection. |
|
|
|
Yes, you could eat the losses for small things, however, people would write clients that actively try to double spend on every transaction meaning they pay for their things only maybe 25% of the time, and if such clients gain market share you are looking at eating a lot of losses.
If such things start happening, the methods of double spend checks would become more complicated, and fewer vendors will be willing to accept unconfirmed bitcoin transactions without ID and/or insurance. The fraudulent user is then in a digital arms race that he cannot win, and repeatedly doing these kinds of things is still going to get you caught eventually. |
|
|
|
Clients publish transactions to each other within seconds. If a new transaction is not a copy of the short term list of new transactions and is not a copy of something in the block chain it is probably ok to believe it will be accepted and you can proceed with the transactions.
The risk is that your client hasn’t seen the duplicate and the other transaction gets incorporated in the chain. I believe the chances of that happening for a normal transaction are low. The double spender would have to actively attack your client network connection to accomplish a double spend and for normal transactions a wait of a few seconds is perfectly fine. We would need the window to be large enough that we are very confident most clients have seen the transaction yet short enough that the selling merchant can wait without burdening normal customers. 15 seconds for example.
For high value transactions (like paying for a car) waiting for a few confirmations seems acceptable.
I think the merchant's client could be modified to let the merchant know there are no conflicting transactions in the active list after 15-30 seconds.
NO, unconfirmed transactions with no special attempts to ensure finding double-spend transactions are not acceptable for any automated system. In the standard client, even if your client does hear about a double spend, it doesn't mark the double-spent transaction of notify you in any way. If an attacker created to transactions, sending one to the largest miners (not hard to figure out their IPs) and one to you (depending on the way you structure it, also probably not hard to find your IP) and you would be none the wiser. Even if you purposefully modify your client to mark double-spent transactions, you have to make sure you have a direct connection between you and the miners attacked to ensure the nodes in between don't drop the double-spend you want to know about. The regular client doesn't perform a check of the live transaction queue, but it could be done. I'd be willing to bet that it will be a standard check on POS systems long before Wal-Mart starts accepting Bitcoin at their registers. And a slick POS client could also send the transaction to all of it's peers except one, and if that peer offers back that same transaction then it's safe to assume that the transaction is good. Even if there is a double spend attempt underway, if your own POS system has a decent spread of peers and your last peer then sends you the correct transaction, odds are high enough that your transaction was first (and therefore most likely to come away with the actual bitcoins) and therefore acceptable. This would be acceptable risks for sales values under $50, and is similar to how credit card companies handle charges under $50. Such a check wouldn't take nearly 15 seconds under normal network loading conditions, but a 15 second timeout would be reasonable. |
|
|
|
|
Show Posts
