Show Posts
|
Pages: [1]
|
1
|
Bitcoin / Bitcoin Discussion / Real Money(tm), coin versus coin
|
on: January 18, 2012, 12:23:39 PM
|
 A Casascius physical bitcoin and a 5 SEK coin lying next to each other on my desk caught my eye and it struck me how backwards the typical use of the phrase "real money" is. The SEK coin is nothing but a piece of copper alloy. Unlike the bitcoin there is no magic in it. Mold a piece of copper-nickel (worth 0.7 SEK) into that shape and you've got 5 SEK. It's ridiculous. The bitcoin clearly is the Real Money here.
|
|
|
2
|
Bitcoin / Bitcoin Discussion / Printing bitcoins, an implementation
|
on: February 22, 2011, 12:32:02 AM
|
There has been much talk about printing bitcoins. Here is a program to do it. http://bitcoin.modernjob.info/print.htmlIt takes a wallet.dat file and generates PDF and EPS bitcoin cheques looking like this:   Each bitcoin address in the wallet with available coins gets a note containing the amount and the private key that controls it, both human readable and in QR Code. (The notes above are real. The first person to take them gets them.) Edit: PDF / EPS link.
|
|
|
3
|
Bitcoin / Bitcoin Discussion / How much generating power is sufficient?
|
on: November 25, 2010, 11:06:33 PM
|
Taking a step back from the discussions about incentives for generators to ask the question: How much hashing power is actually needed? More is of course better, all else equal, but how much is sufficient?
First, what is it good for? Preventing double spending. If the difficulty is high enough that it costs more to generate a (chain of) block(s) that omits a payment made than the payment itself is worth then double spending fraud is unprofitable. That's it.
There is more to profit from reverting big transactions than small, so the larger the transaction the more blocks the recipient has to wait until considering it confirmed.
For most practical purposes the difficulty won't need to be more than about the worth of a used car per block. Transactions higher in value than that are generally made over longer time, between known participants writing contracts and don't have to rely on the Bitcoin protection anyway.
Currently the difficulty should be worth about 50 BTC/block, considering that the block reward is 50 BTC and most generators do it for profit. That's a bit small if you're selling a 20 000 BTC car and have to wait two days for the transaction to be confirmed.
But the eye watering beauty of the system is that a single 50 BTC/block generator (or whatever the difficulty is) single handedly foils the plots of a million (or however many) 50 BTC scammers who collectively could have gained 50 000 000 BTC on their scams.
The happy conclusion is that not much generating power will ever be needed and that transaction fees can be really tiny forever.
|
|
|
4
|
Bitcoin / Bitcoin Discussion / What will keep transaction fees up?
|
on: November 19, 2010, 04:16:39 PM
|
When coin creation diminishes transaction fees are supposed to encourage people to keep generating blocks. But how does the transaction pricing work? The cost of hashing does not increase from including another transaction in a block. A generator will always benefit from including a transaction no matter how small the fee. So the fees will approach zero (as, indeed, they are now) making block creation very unrewarding which will reduce the computing power providing Bitcoin its security to almost nothing. The wiki only talks about how limited block sizes keeps transactions scarce and prices up. Is that it? I see no market mechanism connecting the demand for transactions to the block size limits. How will everyone agree on maximum block sizes? Am I missing something?
|
|
|
5
|
Bitcoin / Bitcoin Discussion / "BTC" and ISO 4217
|
on: October 12, 2010, 03:48:19 PM
|
"BTC" is not a good or likely ISO 4217 currency code. There are two kinds: country specific and everything else. The country specific codes start with the two letter country code followed by another letter, often the first letter in the name of the currency. "USD" for US Dollar and "SEK" for Swedish Krona. "BT" is the country code for Bhutan. Non country specific codes start with an "X" followed by two letters describing the currency. "XAU" for gold and "XDR" for Special Drawing Rights. The natural ISO 4217 code for Bitcoin would be "XBC". "XBC" is currently taken by the obsolete European Unit of Account 9 so maybe it can be reassigned. Or maybe the ISO 4217 Maintenance Agency can make an exception if "BTC" becomes established enough but it would be kind of ugly.
|
|
|
6
|
Economy / Trading Discussion / Bank tranfers instead of credit cards
|
on: October 12, 2010, 08:37:45 AM
|
Mt. Gox and Bitcoinmarket are pretty much dead right now because of lots of payments with stolen credit cards. As theymos says in the buybitcoins.com closes thread "Such a high rate of chargebacks does not bode well for future CC->BTC trades, no matter what intermediary companies are used." So credit cards are out. What to do? How about markets using bank transfers? Stealing bank accounts are a lot harder than stealing credit cards. Within Europe bank transfers are usually free of charge although a couple of days slow. I guess it's the same within the USA and other places? So at least there could be a functioning european bitcoin market using bank transfers. Maybe even a global one some place where banking and currency exchange laws are not too bad. Is this viable? Problems? Pitfalls?
|
|
|
7
|
Economy / Economics / Deflation
|
on: July 22, 2010, 06:08:09 PM
|
There has been a lot of worry here about the deflationary nature of a currency with a fixed amount of money. Don't worry.
Let's first make it clear what we are talking about. The general price level can decrease in two ways. The first is by a decrease in the supply of money. The second is by an increase in the supply of goods the money is used to trade in, i.e. economic growth.
The first, monetary deflation, is irrelevant. Some bitcoins will always be lost but the effect will be vanishingly small; people are not going to accidentally lose several percent of their money per year.
The real issue is growth deflation. As the economy grows the same amount of money can buy more stuff than before simply because the stuff is cheaper to produce. That is cheaper measured in real resources such as labor, electricity or steel.
This kind of deflation is very beneficial because it is interest on a loan, the return of a real investment. What is it that happens when someone sells something and keeps the money without spending it? The seller gives a real resource, such as a sandwich or a screwdriver, to someone else. In exchange they get money. The money consumes no resources and is entirely useless until it is spent. The seller hopes to regain the value lost in the sale in the future, by spending the money. In effect, the seller has lent out a real resource with hopes of getting paid back in the future. With interest.
The deflationary price drop is the interest. The seller / lender has abstained from consumption now in favor of consumption later. To avoid making a loss the buyer / debtor must find a way to put the resource to such a productive use that it grows in value at least as quick as the deflation. If the buyer can't do that the profit maximizing thing to do is to quickly sell the resource to someone who can. Or simply keep the money to begin with and let the more productive people make use of the resources, to the benefit of all.
In this scenario the deflation rate and the growth rate is the same thing. This base interest rate sends a very useful signal about what investments are worth making.
As so often, it turns out that the best economic result is not achieved by manipulating prices - in this case by creating new money - but instead by just letting the market be and do it's thing.
|
|
|
8
|
Bitcoin / Development & Technical Discussion / Python wrapper for bitcoind
|
on: July 08, 2010, 11:50:43 PM
|
While creating the Bitcoin automation for mullvad.net I made a python wrapper around bitcoind. Should anyone else find such a thing useful it is available here: https://www.mullvad.net/download/bitcoin.pyUsage example: >>> import bitcoin >>> bitcoin.getaddressesbylabel("foo") ['16au2i9ny5pnwCPnoekov2hHMhtS7qcFjR', '19BkB63mo3NQRPNeHkc3bWnKGBU7oL8Dp7'] >>> bitcoin.getreceivedbylabel("Your Address") 6.0 >>> bitcoin.listreceivedbyaddress() {'16au2i9ny5pnwCPnoekov2hHMhtS7qcFjR': {'amount': 2000.0, 'label': 'foo', 'confirmations': 226, 'address': '16au2i9ny5pnwCPnoekov2hHMhtS7qcFjR'}, '1FLD8wCNNBh2wg2mnGjD9ogoLaRxpSz7TW': {'amount': 6.0, 'label': 'Your Address', 'confirmations': 343, 'address': '1FLD8wCNNBh2wg2mnGjD9ogoLaRxpSz7TW'}} >>> bitcoin.sendtoaddress("1Nsq3itZULUZjtZGcjNrtZtwT8aMsHu1R1", 1234.5) >>> bitcoin.sendtoaddress("1Nsq3itZULUZjtZGcjNrtZtwT8aMsHu1R1", 1000000) Traceback (most recent call last): File "<stdin>", line 1, in <module> File "bitcoin.py", line 73, in sendtoaddress _cmd("sendtoaddress %s %d %s %s" % (bitcoinaddress, amount, comment, comment_to)) File "bitcoin.py", line 86, in _cmd return _parse(_cmd_raw(args))[0] File "bitcoin.py", line 92, in _cmd_raw raise BitcoinError(errors) bitcoin.BitcoinError: error: Insufficient funds
>>>
|
|
|
|