I'm unable to start bitcoind/bitcoin-qt after the latest upgrade of the Ubuntu PPA.  However, I've got a backed-up wallet.dat, and using the pywallet utility I also have a list of addresses and private keys.  I think the best solution right now is to create a new wallet and to import into it the one address which does have an associated balance (I know there is only one).  However, I don't know which address it is!  Is there a way to find out the balance associated with each address without having to manually check them on the Block Explorer?  (And yes, I could write a small programme to automate this process, but it seems I would be reinventing the wheel and abusing the Block Explorer service).

Yesterday (May 4th, 2013), the Bitcoin-qt/Bitcoind packages were updated on the Ubuntu PPA (I'm using Ubuntu 13.04).  After the upgrade, Bitcoin fails to start due to database errors:

Code:

dbenv.open LogDir=/home/smark/.bitcoin/database ErrorFile=/home/smark/.bitcoin/db.log
ERROR: CDB() : error DB_RUNRECOVERY: Fatal error, run database recovery (-30974) opening database environment
Error: Error initializing database environment /home/smark/.bitcoin! To recover, BACKUP THAT DIRECTORY, then remove everything from it except for wallet.dat.

I have no intention of redownloading the whole blockchain again.  Is there any way to fix this, or should the Ubuntu PPA be deprecated?

I've witnessed something puzzling on the Testnet: three blocks I mined had their number of confirmations suddenly go down.  One of them jumped from 285 to 263, though it has since monotonically increased again, as one would expect.  I thought that the number of confirmations could only increase, unless the block finds itself in an orphaned fork, in which case the number of confirmations becomes meaningless. So, what may explain this sort of situation?

Calling listunspent gives me a list of {txid,vout,spk,amount,conf}.  I also want to determine the account associated with each item in that list.  This can be done in two steps: 1) calling getrawtransaction txid will get me the address associated with a txid+vout combination; 2) calling getaccount addr will finally get me the associated account.

This works, but is awfully convoluted.  Is there a more straightforward way?  I thought about calling gettransaction txid, which does provide account information associated with each "receive" address, but I'm not sure whether I can rely on the array order being exactly the same as the original vout.

If you run bitcoind getrawtransaction abcd1234... 1 you get a fairly complex JSON object with all the information about the given transaction.  My question concerns the "addresses" field deep inside each "vout": if I understand regular Bitcoin transactions correctly, this array should usually contain only one address; on what circumstances would it contain more than one address?  Also, could someone point me towards one transaction (either mainchain or testchain) where more than one address is used?

[getreceivedbyaccount]

I have two questions concerning the official Bitcoin client API:

First, getreceivedbyaccount is listed as taking two optional parameters: account and minconf.  However, the source in bitcoinrpc.cpp implies that the account parameter is actually mandatory.  Oversight in the wiki or error in the code?

Second, what exactly is the difference in semantics between the minconf optional parameter that several calls accept and the target-confirmations optional parameter accepted by listsinceblock?  I understand minconf well enough, but doesn't target-confirmations mean exactly the same thing?

Thank you guys!

[encryptwallet]

Looking at the original Bitcoin client API I noticed one thing: once a wallet is encrypted with encryptwallet, there does not seem to be an API call that unencrypts the wallet.  Sure, you can change the passphrase with walletpassphrasechange, but the encryption remains.  Am I missing something, or is encryptwallet really a one-way street as far as the API is concerned?  (One could of course restore an unencrypted wallet from a backup, but that's not in discussion here).

I'm trying to get a good understanding of how Bitcoin works, and the combination of testnet + raw transactions is a wonderful platform for this!  I do have some questions concerning the basics, so I'll describe how I reckon a simple transaction can be built, and I hope you'll correct me and/or answer some of my doubts.

Suppose that a past transaction with txid=aaaaaaaa gave 100 BTC to address m1111 on output vout=1.  I now want to take these 100 BTC and give 90 BTC to address m2222, 9 BTC to address m3333, and pay the remaining 1 BTC as a transaction fee.  These are the steps I think I need to do (in pseudo-code):

First I would need to create a raw transaction:

   
    hex = createrawtransaction [{txid:aaaaaaaa,vout=1}] {m2222=90,m3333=9}
   

Now I need to sign the transaction.  This is where I have a couple of doubts. First, in this simple example, the second parameter of signrawtransaction can be just an empty list, right? Second, what should the sighash parameter normally be?

   
    priv = dumpprivkey m1111
    hex2 = signrawtransaction hex [] priv ALL
   

Finally I can send the transaction:

   
    txid = sendrawtransaction hex2
   

Is this all or am I missing something?
(Thank you for your input!)

I'm having trouble connecting to testnet.  I've opened up TCP port 18333 and started bitcoind with the following command:

Code:

bitcoind -testnet -debug -printtoconsole

This is the error I get:

Code:

connect() failed after select(): Connection refused
IRC connect failed
IRC waiting 71 seconds to reconnect

Note that connecting to the main network works fine.
Any ideas?

Thanks in advance - Jon.

There's a fair amount of libertarians on this forum, so I guess this question is not completely out of place here: how does libertarianism handle the problem of externalities?  I'm thinking in particular of problems such as acid rain (some of the younger ones may not remember this, but it used to be a serious problem in Europe and the US back in the 70s and 80s, though the situation has largely improved since the introduction of strong regulations on sulfur emissions from power plants), or a more contemporary example like CO₂ emissions and their role in anthropogenic global warming.

Feel free to point me to some external resource that you feel presents a good libertarian solution to this problem.  I'm genuinely curious.

Consider the scenario where Bitcoin fails to get any sort of traction in the real world, its value ultimately implodes, and it ends up failing as either an alternative currency or as a store of value.  Moreover, this scenario occurs purely due to market forces, ie, there is no government crack down or any action against Bitcoin by The Powers That Be™.  Perhaps it simply happens that tomorrow someone starts Inflato-coin, a digital P2P currency based on Bitcoin but with the "tiny" difference that instead of a hard-cap on the total number of coins, Inflato-coin has an inflation rate that asymptotically approaches 1% or 0% or whatever small number without ever actually being 0%.  And it just so happens that Inflato-coin manages to overtake and eclipse Bitcoin.

There's no shortage of people warning on this forum and on the wider blogosphere that Bitcoin's builtin deflation may lead to the above scenario and thus ultimately to its demise. And I know there's a fair amount of Austrian School apologists in this forum who simply dismiss these warnings without further ado.  But would the realisation of this scenario lead Austrians to reconsider their views on Economic theory?

(Obviously the dual scenario also applies.  Should deflation turn out not to be a problem for Bitcoin's success, then inflationistas (me included) may need to revise their assumptions.)

The subject says it all: I'm looking for testimonies of people who've already gone through the experience of declaring Bitcoin-related income for tax purposes.  I'm interested in knowing about the responses you got from accountants and/or the tax-men, regardless of the country you live in.

This question does not come from idle curiosity, either.  I'm in the process of starting a business and I'd very much like to also support payments in Bitcoin.  Therefore, it would be nice to know what sort of things to expect when I bring up the issue at my local IRS-like office.

Hi,

Let's be optimistic and suppose that Bitcoin does take off in a big way and goes mainstream to the point of becoming a significant actor in the world economy.  In this scenario, the early adopters -- those of you who populate this forum today -- will necessarily become a minority.

Since in Bitcoin the policy is dictated by the majority of nodes (weighted against hash/sec), how would you guys react if a future majority were to decide that the current policy needed tweaking?  I am thinking in particular of the policy that the total number of bitcoins is capped at 21 million.  It could very well happen that the majority comes to the conclusion that the builtin cap is having nefarious effects and decides to upgrade the software such that Bitcoin will switch to a controlled inflation system (say 2%/year).  How many of you would "fork" in such a scenario?

On a related note, it seems that many of you see the builtin cap as good thing.  What evidence would be required to change your mind about this?

Jon.

Hi,

Looking at the current valuation of Bitcoin against the dollar, I know I'm not the only one to find Bitcoin to be overpriced given the size of its economy.  Therefore, there are strong indications that the current valuation (even taking into account the recent slump) is largely driven by speculation about the future value of the Bitcoin currency.  However, and though I love Bitcoin as much as the next guy, realistically speaking there are some strong arguments as to why Bitcoin -- at least in its current incarnation -- might fail.  Moreover, I suspect that speculators may not be adequately pricing the risk of a Bitcoin failure into their investment.  If this risk is properly taken into account, then the true valuation of Bitcoin against the dollar should be much lower than the current (almost) parity.

And what arguments for Bitcoin's failure are these?  Well, foremost is the risk of a second genesis or the rise of a competing system based on similar principles (or even the same code base!), particularly if backed by a strong player (think Google).

Hypothetically speaking, suppose Google were to announce gCash: an electronic currency very much like Bitcoin, but with builtin support in the Chrome browser and accepted as payment in all of Google's services.  They could even throw in builtin support for cooperative mining in the standard client to encite people to use Chrome all the time.

Bitcoin's economy is currently so small that it would be dwarfed overnight by gCash.  In a sense, Bitcoin's philosophy and principles would win, but the current block chain would either fade into oblivion or become such a niche player that its valuation would come down drastically, reflecting the true size of its tiny economy.

Now, I used Google only as an example, as I have no indication they actually have such plans.  The point is that the risk of such a scenario is not zero, and I reiterate my initial point that speculators may not be pricing it adequately.

Hi guys,

I would very much like to support Bitcoin in a web site I'm developing.  I've been playing around with the JSON API, and for the most part it fulfills my needs.  There's one glaring omission, however: with the present API I can see no way of obtaining all transactions (either associated with an account or all of them) that have happened since a fixed point in the past (since a given transaction ID, for example).

I realise that 'listtransactions' will give me a list of the last N transactions, but there's no way to know beforehand what is the value N of transactions that have occurred since I last polled the Bitcoin server.  Also, 'listtransactions' requires a mandatory account name; it would be useful if an hypothetical 'listtransactionssince' command could also return all transactions, regardless of the account.

Your thoughts?

Thank you!
Jon