"Inflation is always and everywhere a monetary phenomenon." - Friedman, Milton. A Monetary History of the United States 1867-1960 (1963).


Perhaps some econ guru can clear something up for me. In 2008 the supply of dollars M0 most certainly went way up. However at the same time (in some cases before) the price in dollars of hard commodities such as silver, platinum, and crude oil (not gold) dropped significantly. That seems counter intuitive to me and contradicts the seemingly obvious idea that monetary inflation generally effects price inflation.

Wikipedia claims that the gentlemen below state in their glossaries that...

In economics, inflation is a rise in the general level of prices of goods and services in an economy over a period of time.

Abel, Andrew; Bernanke, Ben (2005). Macroeconomics (5th ed.). Pearson

Barro, Robert J. (1997). Macroeconomics. Cambridge, Mass: MIT Press. p. 895. ISBN 0-262-02436-5

Blanchard, Olivier (2000). Macroeconomics (2nd ed.). Englewood Cliffs, N.J: Prentice Hall. ISBN 013013306x

Burda, Michael C.; Wyplosz, Charles (1997). Macroeconomics: a European text. Oxford [Oxfordshire]: Oxford University Press. ISBN 0-19-877468-0

...issuing New Icelandic Króna backed by Bitcoin.

Fair enough, we don't trust consumers, but we can trust Instawallet Inc because they have a physical address.


And the wallet service protects your bitcoins, loans them out, and even pays interest. Fantastic!


Certainly coins and paper money are convenient. I'd much rather a bitcoin-mint printing counterfeit resistant coins with an address that I can confirm online. Your proposed system has only practical value early in the adoption curve. Passive debit cards and accounts would give everything you require except the fear of centralization, fractional reserve, etc, which few people care about, certainly not in comparison to the convenience of a small vending machine purchase.

That's interesting. I wonder why we don't just use the full 256 bit public key as the address (not hashed) -- and then use the 'first bits' rule in the every day.

I would have assumed that's what --rescan would do. Throw away all block references and scan every address for it's balance record in the block chain.

Bitlotto are you talking nonsense, misunderstood the use case, or trolling?

There was a time when keypool=100 was not default and so restoring from backup would loose the change and receipts since backup. But that is no longer the case (and was fixed by Satoshi long ago). If you insist there was EVER a version that presented an address (a hash of a key) before creating and storing the private key, I would like to see the source code in the git repository.

EDIT: Clarification to this point last month: http://forum.bitcoin.org/index.php?topic=17240.msg222709#msg222709

Looks good to me:
http://blockexplorer.com/address/1945qfobZxdnmVJ6qBd4FgcVcWBhDXKiTV (Betting pool)
http://blockexplorer.com/address/16eg1Qs15Vq7mvpi2fPNQuYzBkhp5DhzNq (payout 5.72 btc)
http://blockexplorer.com/address/1NsvfVxNHzoz484aTSeutayTwGi6VQmqYL (payout 3.84 btc)

I assumed you were all taking the money to return it in PM. But you so gleefully fuck each other. I'm ashamed to be a member of this community of geeks, libertarians, and thieves.

From what I understand, the keys are 256 bits (10^77) and there are what? 1 billion keys?

http://en.wikipedia.org/wiki/Birthday_paradox
http://en.wikipedia.org/wiki/Universally_Unique_Identifier#Random_UUID_probability_of_duplicates

1-e^(-(n^2)/2x)

EDIT:

1-e^(-(1000000000^2)/(2^256)) =
1-e^(-(10^18)/(10^77)) =
1-e^(-1/(10^59)) =
10^(-60)

Current Block Probability: ~ 10^(-16)

So, getting the block is 10^45 times more likely than a single collision. An attacker would have to hope for colliding with wallets containing trillions of times more coins than will ever have been created. But if an attacker can change the value of 'n' to 10^39 (duodecillion attempts) then he'll likely be quite profitable... but then again he'll only be colliding with his own keys.

Let us not call Google or Facebook authentication OpenID. They both are OpenID providers, but not consumers. No one wants twenty disparate OpenID's. Users want one (or many that they have 100% control over). In other words, Google and Facebook will let you login to other sites with your Google or Facebook id, but neither will let you login to their own sites with other identities.


As much as I like Google, using their authentication method for money gives me the willies. Depends on what your plans are. Maybe it's just a proof of concept and you can take it from there.

It could, and maybe should, be a controversy. But it is not. Few know or care.

con·tro·ver·sy [kon-truh-vur-see; kuhn-trov-er-see] a prolonged public dispute, debate, or contention; disputation concerning a matter of opinion. contention, strife, or argument.

BTC must go beyond $35 so I can buy silver for the ladies.

The great experiment will bring a negative result if the markets go below 0

Sipa just pointed me to this thread after I posted http://forum.bitcoin.org/index.php?topic=26269.0

The transaction in question is now over a month old. I have two versions of the same send in my client (neither send happened). The first send has 7000 confirmations sent to no (blank) address. Another send (with the same timestamp and btc amount) has 0/confirmations to an unknown address in the block chain (presumably an address of mine somewhere).

I believe the one or two transactions are invalid due to double spending from a copied wallet but it's difficult to confirm because I can not be sure which are the sending nor receiving addresses. In any case, I would hope that before 7000 blocks the 0.3.23 client would be convinced that the transaction is never going to happen.

This is great news. I wish you luck with the project. May I suggest you accept firstbits.com minimal/unambiguous/case-insensitive addresses?

No version proposed is practical nor instant. The recipient would have the same burden of confirmation/trust as today. There is nothing preventing the 'sender' from racing the recipient to cash out the instawallets. And with dozens of transactions required, I'd just as soon trust a 0/confirmed transaction or just wait ten minutes.

Expecting the use of the same service is not bad. If I could easily transfer from your instawallet/mybitcoin to my own account immediately, then that's great. If we don't both have instawallet/mybitcoin accounts, fine, I just have to wait for confirmation or trust you.

A different approach would use a system similar to instawallet whereby passwords could be easily changed. The sender gives the password to the recipient who changes it. Now we move the burden of trust from the sender to the service.


The only use case I can come up with for this is my trek across the arctic or sahara sans computer, batteries, whereby I might need to use bitcoins in some village, where of course they exclusively use bitcoins.

YES with a capital FANTASTIC!

I'm not even trying to be anonymous, but I still have a dozen wallets to keep track of 'accounts'. These patches bring us a long way toward personal financial control. I'd like to similarly be able to right click on a group of linked addresses and export them into a separate wallet... (as well as import wallets). I'm very happy to see all addresses, whether used in a transaction or not! Perhaps the ability to generate 'x' for the keypool buffer (and maybe delete unused addresses) would be handy.

I look forward to seeing your patch in the mainline along with encrypted keys!

Muchas gracias!

I would like to see more federated authentication (OpenID). Then, whether we authenticate with PGP or mailed TAN, we can use the same authentication token for many services in the bitcoin community. Services like OpenID haven't taken off due to the chicken-egg problem. Well, we're a huge clutch of chickens! let's lay some eggs.

Early last month, while trying to understand keys, wallets, security, and backup, I believe I inadvertently attempted to double spend. The client is not handling it gracefully (the UI displays two semi-duplicate transactions neither of which occurred and a zero balance even after thousands of blocks). While I am not entirely sure about the order of events, I believe the following steps might be correct:

I created a wallet (A), received coins, sent coins, closed client.

I copied wallet, rescanned with new copy (B), and sent the same coins to different addresses.

Now, when I open wallet A, I see a transaction sent to <blank> address with almost 7000 confirmations. In the new client I ALSO have a similar transaction sent to an address not known to the blockexplorer with the exact same June timestamp but with 0/unconfirmed.

While I would like to think the coins are still available to me, I believe they were actually sent (from the copied B wallet). I'll be happy to disclose the addresses in question to client developers (PM me) in order to improve the client transactional log.

--

But aside from this odd behavior, it highlights the need for more address transparency. I can not see to what address the transaction is sending (abnormal), nor can I see from which address the coins are coming (normal). In this case, I can guess at the sending addresses because I've received with a limited number of addresses. I do not know what addresses are 'hidden' in my wallet, and therefore do not know whether wallet A is a pure subset of B and can thus be deleted.

My personal feeling on the UX matter is to think of and display addresses as accounts and a wallet as a portfolio. I think the wallet metaphor creates confusion.