|
Stuff is valuable because it is either useful (like hammers) or we think it is pretty (like Picasso paintings); the more rare, useful, and/or desirable something is, the more valuable it tends to be.
We know how rare bitcoins are. It remains to be seen how useful they are. I think they're pretty useful as both a convenient way of paying for things and as a long-term store of value, but it will take time to convince most people that they're useful for those things.
|
|
|
|
https://github.com/bitcoin/bitcoin/pull/138I think this is ready: This patch adds immature generated blocks to listtransactions. They are reported just like mature blocks, except the category is 'immature' instead of 'generate'.
This functionality is needed by people creating alternative, JSON-RPC-based GUIs, and is useful for impatient miners who currently grep through debug.log or use unofficial patches to see not-yet-mature blocks they've generated. I found one edge case during testing, and after discussion on #bitcoin-dev changed the information reported. The edge case was reporting the coinbase transactions from orphaned blocks. Here's the scenario: + As soon as you generate a block, the coinbase transaction goes into your wallet as a 1-confirmation transaction. Before this patch, that transaction was not listed in the listtransactions output. With this patch, it is (as "category" : "immature", "confirmations" : 1). + If that block is orphaned, the coinbase transaction is no longer valid. With this patch, it will be reported at "category" : "orphan", "confirmations" : 0 + When a coinbase transaction has 120 confirmations, it will be reported as "category" : "generate" (as before).
|
|
|
|
|
I added a comment to the PULL request-- I ran into an issue when sanity testing this (a testnet wallet that reports an impossibly high balance after conversion).
|
|
|
|
OK that's pretty much what I was talking about then. So my stupidly small transaction at the moment won't be accepted by most miners, which means it wont get recorded in the block chain which means it wont happen, right?
Yes, and right now it will sit in your wallet at 0 confirmations and get rebroadcast once in a blue moon (ok, not that long, but I'm too lazy right now to dig out the rules for when transactions are rebroadcast) until it DOES make it into a block. And you'll have to hack your copy of bitcoin to be able to send a less-than-.01 transaction without a fee; the RPC send* methods automatically add the fee, and the GUI will tell you a fee is necessary (and won't let you send unless you agree to it). |
|
|
|
|
Be nice, y'all. Todd emailed me directly and I steered him here because I don't have time to talk about economic theory with everybody who emails me these days.
Todd: if you were designing a new currency, what would it look like? Are you imagining a LETS-like system of credit?
Bitcoin is designed to be like a scarce natural resource, which is pretty conservative, really-- scarce natural resources have a long history of being used as currency. I don't know enough about the alternatives to know whether or not they could work as an Internet currency-- the LETS systems I've heard about all rely on local interactions and trust to keep people from cheating.
PS: I'm going to move this thread to the Economics forum.
|
|
|
|
Would it work if you used only two copies, one that always only mined, not spending the money, and keeping the same address, and another that has that address, that you use to spend and receive money as usual? Besides the lag 'til mining earnings show up on your spending wallet, is there gonna be any issue?
Better would be a new feature that tells the mining bitcoin "please credit generated bitcoins to THIS address (instead of a new one)." If you are just mining, you don't need the private key at all, the bitcoin address (or public key) is enough to create the coin generation transaction. |
|
|
|
|
Do these types of 'make money without doing anything productive' schemes bother anybody else, or am I just a financial prude who doesn't recognize harmless fun when I see it?
I feel like we might soon need a Frequently Seen Schemes to go along with our FAQ, just to let people know that using a different currency doesn't suspend the laws of economics.
|
|
|
|
The only question is how we reach them and expand our job market?
That's not the ONLY question. A question I've been thinking a lot about is what are an employer's potential liabilities if they are caught paying employees in bitcoins "under the table." I honestly don't know the answer if the employer is in Finland and the employee is in Ecuador, and suspect the answer might depend on whether or not the person doing the work is considered an independent contractor or an employee. |
|
|
|
|
I just bought two Boston Red Sox tickets from my friend Baer using bitcoins. They really do work nicely for grassroots, person-to-person transactions, and the beautiful thing is you don't need a lot of people accepting them in one place to get started.
|
|
|
|
|
Cloning your wallet to do anything besides backing it up is a bad idea.
It might work perfectly for a while... but you are very likely to get weird behavior from bitcoin sooner or later, because doing that is not tested or supported.
Where 'weird behavior' is one clone of the wallet shows one balance, the other clone shows another, and you might end up with bitcoins that you can spend from one wallet but not the other (or, worst case, end up with bitcoins that neither wallet is able to spend).
If you REALLY REALLY REALLY want to do this... then get the latest code from git, pull sipa's 'Spent per txout' patch, and then spend a bunch of time testing to find out what happens when your cloned wallets eventually start using different keys from the keypool.
|
|
|
|
From wikipedia: Recent scholarship confirms that merchants made far more money than miners during the Gold Rush. So, who are the merchants in the bitcoin rush? |
|
|
|
I am really paranoid about leakage, and for me to even touch a float when dealing with people's money is unacceptable. On Britcoin, there's a whole system of balances and checks at every stage of the various transactions to ensure consistency to all decimal places, and I would not want to throw a spanner in the works because of a tiny rounding error (which would throw up flags and warnings everywhere). Even hearing the words round(...) is like heresy.
Am I the only person here who looks at our documentation for how to use bitcoin from PHP and thinks "people are going to run away screaming" ? See: https://en.bitcoin.it/wiki/API_reference_(JSON-RPC)I strongly believe you are making the common cases (simple shopping carts or "hold a bitcoin balance for a customer and let them spend it") much, much more complicated than necessary. What do other people think? I'd especially like to hear from people who have prior experience using PHP to implement shopping carts and other simple applications that deal with money. Did you use BCMATH/GMP? |
|
|
|
Ok.... so Gavin asked me (many times before and now) for the proof that the banking/financial industry avoids floats.
HOW MANY TIMES DO I HAVE TO YELL THIS?  ?? Of COURSE you shouldn't use floats internally (unless you are doing something trivial like adding up items in a shopping cart). We are talking about the JSON-RPC api. Which is an api for communicating between bitcoin and other applications, in which all values are turned into strings. So: what are the best practices in the banking world for representing monetary values in strings? As far as I can tell, the answer is "write them out as decimal values and convert them to Decimal() or integer as you read in or write out." Which is exactly what Bitcoin does, and which is what I think we should recommend to people. |
|
|
|
The main problem is that floating point is not sufficient to accurately store a Bitcoin balance
An IEEE double-precision floating point number has 53 bits of precision, which IS sufficiently accurate to store a bitcoin balance. Every single possible bitcoin value can be converted to and from an IEEE 64-bit float with no loss of precision. I agree that if you're going to be performing lots of calculations on bitcoin values you need a Decimal type (and ClearCoin stores and uses python's decimal.Decimal(precision=8) for all bitcoin values)-- if you don't, floating point errors can accumulate and eventually cause you to gain or lose .00000001 of a coin. But really the main problem with storing monetary values as any floating point type is you're likely to be embarrassed by mistakes like error's cash register receipt if you truncate values instead of rounding before printing. |
|
|
|
|
All righty, I hereby state:
All money values in the bitcoin JSON-RPC interface Are and Shall Be treated as Decimal, with 8 digits of precision after the decimal point.
If you're writing a banking application in a language that doesn't support Decimal types from JSON, then you should pack up your bags and go home.
|
|
|
|
If we want to be taken remotely seriously by the banking and merchant communities, floats need to go.
People keep claiming that, and yet I just did YET ANOTHER google search for "banking apis", clicked through to the Open Financial Exchange standard (from Microsoft and Quicken), and what do you know! Money amounts look like floats: <STMTTRN>
<TRNTYPE>CREDIT
<DTPOSTED>20070315
<DTUSER>20070315
<TRNAMT>200.00
<FITID>980315001
<NAME>DEPOSIT
<MEMO>automatic deposit
</STMTTRN>
|
|
|
|
|
Apologies to Nefario, I was reacting to the wiki pages written by genjix on how to use PHP with bitcoind that started with:
+ First, compile my fork.
+ Next, install the GMP and BCMath libraries...
And why do I defend floats: because simple things should be simple. Using GMP/BCMATH is overkill for 98% of what bitcoin JSON-RPC users will be doing.
And because certain people keep beating this dead horse. I have said that I am PERFECTLY WILLING to support strings in the JSON-RPC interface if somebody can demonstrate to me someplace where it is actually a real problem (that isn't trivially solved using something like round(value*1e8+0.5) or printf("%.08", value)).
|
|
|
|
|
Can you'all educate me about these mythical rounding errors that require using GMP?
I can see, maybe, if you're computing interest down to the penny on a 30-year mortgage you might conceivably be off by a penny if you use 64-bit floats instead of 64-bit integers, although even there you're going to have to think hard about rounding as you get integer remainders.
And I can see being really careful if you're writing a bitcoin exchange site or bitcoin bank that deals in thousands of internal transactions that must all balance exactly.
But for the typical PHP website that is just going to add up 10 items in a shopping cart using plain-old PHP Numbers will be just fine. I don't see PayPal recommending that PHP users of it's APIs install GMP. Recommending that any website dealing with bitcoins compile genjix' fork and use GMP is a really good way to ensure that nobody accepts bitcoins.
|
|
|
|
I did however find something else very interesting while I was there... the 'vanity' param  That's not part of the official API, that's just a fun hack I made one day on a whim. The technical information in the wiki needs more attention and polish; if you have time and are a decent writer, please jump in and help out. |
|
|
|
|
Show Posts
