Well I was informed on IRC that I need to add txindex=1 to my bitcoin.conf and then reindex.  I think that should fix it but I won't know for sure until this thing reindexes (which at 20GB+ may take a while  )

Hello I'm in the early stages of developing a local blockchain browser.  I would like the final form to be basically what you would see on https://blockchain.info but done through a local program interfacing with the bitcoind/bitcoin-qt JSON-RPC interface for both faster speed and independence from a third-party hosting the viewer.

Anyway I ran into a problem where seemingly random transactions refuse to show giving the following error


Yet I can see on blockchain.info that this is indeed a valid transaction:

https://blockchain.info/tx/4b262acf8c947ecbe5024106cc5b89b8f9ff849ce2cbc6108475a8f4b0f204e7?show_adv=true

And even stranger, getrawtransaction does work on 344052678313f83f81b5ac8c1ae5af374f37cc831b6adf6ee0c7695ac9facc80 which uses 4b262acf8c947ecbe5024106cc5b89b8f9ff849ce2cbc6108475a8f4b0f204e7 as one of its inputs.  I asked someone on IRC to test that same transaction and he got the same error so it's not just my client either.  I'm just really puzzled as to why this is and why it's only certain transactions that have this problem (most transactions that I've tried have worked just fine.)  This pretty much puts a halt to my project until I can find an answer...

All the changes are to Python files so, again, no need to compile anything.  Python is interpreted so you simply save your changes and run.  It's also really easy to debug by adding print statements in the code so it'll output to the console exactly what it's doing.  For example, if you wanted to see the URL it's using, add a print statement in the getDecoratedURL function right above the return statement like:


That way it prints to the console exactly what the function returns to the caller.

Well on the bright side Armory is open source so I forked it on GitHub to remove this behavior.  It looks to be done entirely in a single Python file so you don't even need to rebuild anything to make the change.  Just merge these changes into your announcefetch.py and you should be good to go.

https://github.com/weirddan455/BitcoinArmory/commit/09207dc089facfcea279e485077ed0848491995b

What's a good recipe for Tilapia?  I'm a big fan of Catfish personally but I've been wanting to try something new.

Wow, very nice.  I can confirm that I got my payout from this transaction.  That alleviates all my concerns from my post last week about the growing payout queue.  I was considering hopping to another pool but now I'm glad I didn't.  Appreciate the fine work.  Will be sticking on Eligius for the forseeable future   

One flaw in your test:  I'm pretty sure when you give the Bitcoin client a bootstrap.dat file it doesn't just "update" but instead rescans the entire blockchain database on your hard drive.  That's why the bootstrap.dat is meant to be used on a fresh install because if you already have a good chunk of the blockchain downloaded you're usually better off just letting the client update from the network.

Also not everyone has the bandwidth of an extra large AWS instance.  With my slow 3mbps/384kbps DSL line, I may be the exception in that I could possibly rebuild my local database faster than I could download the latest blocks.

They have indeed evaluated this.  Eligius used to use SMPPS which is very similar to the current system but with oldest backpay.  If I understand it right, the only difference with SMPPS was instead of the logic with "shelving shares" it paid out every share but upon bad luck reduced the amount paid per share proportionally.  Upon good luck, these underpaid shares got paid back "extra credit" (in the order of oldest first) until every share gets paid the full PPS amount.

This system sounds OK in theory but the problem is that luck does not even out to 100%.  According to Eligius's stats, the luck for the entire duration of the pool evens out to about 98%.  This is due in a big part to orphaned blocks (and maybe a small part due to some miners withholding blocks.)  In any case, this means if you backpay the oldest shares first over time the backlog will grow faster than the pool can pay it off.  Eventually the pool will end up in a situation where the backlog reaches a very undesirable length for new miners.  Say it gets to the point where it takes 3 months to pay back everything in the backlog.  If you're a new miner this means you won't see any benefit from lucky blocks for 3 whole months until your first shelved shares reach the front of the queue.  Also the people mining 3 months ago may no longer be contributing to the pool (and if it's been that long who knows if they even still control the payout address.)  A lot of people thought it unfair that current miners were using their hashpower to pay people no longer contributing.  The current miners are also depending on the pool still mining 3 months down the road in order to receive any of their backpay. (if the backlog gets that bad it's likely the miners will abandon or the pool with switch payment methods like Eligius did.)

Another way to think about it is that oldest backpay is unfair because it benefits the people who mine on the pool when it first opens (and eventually punishes new miners as the backlog grows.)  This is because there is no backlog initially so chances are good that all your shares will be paid out 100% making it effectively a 0% fee straight PPS pool (with your backpays being only slightly delayed.)  This low/no backlog state can also occur later if the pool gets some very good luck (likely while the pool is still relatively new since, given time, the backlog will inevitably grow faster than it can be paid off) and this encourages pool hopping.  If someone sees the pool has a low/no backlog they can benefit themselves by hopping on it while the chances are good that they'll get all their shares paid 100% in a timely matter.

In any case, when a pool with oldest backpay shuts down or changes payment systems (which will likely happen to any such pool when the backlog inevitably reaches unacceptable levels) the end result will be the same:  the original miners and the pool hoppers who mined when the backlog was low and then bailed when the backlog grew will get all their shares paid 100% while the new miners may never get any of their backpay.

Just talk to your bank ahead of time before you send the deposit.  Make sure to ask them about their policy on any holds for large wire transfers.  Any deposit over $10k requires the bank to send a report to the IRS but that won't get you into trouble as long as you declare that money as income and pay taxes on it at the end of the year.

Honestly you're more likely to run into problems with the bitcoin exchange than you are with your bank.  I don't know if it's been sorted out now but I remember reading a few months ago about how Bitstamp was trying to make sells "prove" the source of their BTC before they would allow them to withdrawal USD.  IIRC they let them exchange the BTC into USD (and took their fee for doing so) and only notified them of the "prove your source" requirement after they had initiated the USD wire transfer.

Once you get the money out of the exchange I doubt you will run into many problems (check with your bank first anyway just in case.)  Once the bank recieves the wire transfer in your name they're legally obligated to give you that money (as long as its rightfully yours.)

That's more or less the way they already do commissary (only with USD instead of BTC.)  They give you an inmate number when you get booked in, your family puts money on your account, and money gets deducted whenever you buy something.  They're not going to want to use bitcoin because it's an internal system.  No need to fool with wallets, encryption, and broadcasting transactions when all you need is a ledger of how much money is on each account especially when there's only one place for inmates to spend the money (commissary.)  Plus there's no reason to give inmates an actual curreny when it's cheaper to just give them "JailBux" or credit for overpriced food.

Now the other way they could utilize bitcoin is to accept it as a way for families to send money to the inmates.  For the reasons I stated above, they would likely just credit the inmate for the equivilent amount in USD and put that in their commissary account.  However, even if they do this, it's not likely to reduce the cost of sending money or make it any quicker.  You need to understand just how many people profit off throwing others in jail.  In order to send money to an inmate you're probably going to have to go through a company like JPay.  I just pulled up a random prison to get their rates:

http://www.jpay.com/Facility-Details/California-State-Prison-System/California-City-Correctional-Center.aspx

The very least you're going to pay is 5% and that's only if you send $200.  If you only have $20 to send you're going to pay 20%.  These companies have deals with the state (or private prison) to be the sole provider of the money services.  They have a monopoly and there's no way they're going to let up on those prices.  In fact, if they do start accepting bitcoin, I can see them using an exchange rate that heavily favors them making it cost even more.  Just because the technology has improved, a company with a monopoly isn't going to drop prices.  Same with inmate phone calls... when everyone else got Sprint's 10 cents a minute long distance, inmates are paying up to $1 a minute.

The one place I can actually see bitcoin being used effectively is on the black market.  Basically the way it works now if someone wants to buy, say drugs, in a larger amount than is feasible to trade in food or stamps they'll tell the buyer's family to send money to the seller's family via Western Union or MoneyGram.  Obviously that's going to leave a paper trail and likely require the money recipient to show ID.  If they instead sent a bitcoin transaction, it would cut most of the paper and speed up the transit time so Smacky McInmate can have his heroin in half the time.

Unless I'm missing something, I don't see what the luck in finding blocks has to do with the size of the payout queue.  Worse luck means fewer payouts but it also means less BTC credited so that should balance out.

What's the deal with the payout queue recently?  It's usually at most 3-4 days to get to the top (which conviently is about how long it takes my 2 S1s to mine my 40 TBC minimum.)  Now I've hit my minimum and it's been over 4 days since my last payout and I'm still 14 blocks down on the queue 

It worries me a little bit because it seems the pool is increasing its "debt" when logically that shouldn't be.  The BTC in the payout queue should have all been earned and are now owed to the miners.  We're not taking about shelved shares here, these are BTC that have already been mined.

Say the pool shuts down tomorrow (not saying it will but bear with me.)  What happens to all the miners who have a balance on their account?  Obviously new blocks won't be mined so we can't be paid out the traditional way.  Do you have enough BTC in cold storage to pay everyone off?  Right now there's a staggering 571.77 BTC in the payout queue and that's not even counting the miners who haven't hit their minimum.  Furthermore, how does the cold storage wallet get paid?  Do you send off a percentage of each new block to it?  Or is it only credited when the payout system goes into "fallback" mode?

This just confuses me because the point of the CPPSRB system is that there will never be more BTC in shares credited than what the pool actually mines.  Yet it seems the "debt" in the payout queue continues to grow and we're at the mercy of the miners tomorrow to pay off what we mined yesterday.

Actually I may have to eat my words about Ubuntu.  I just found this minimal install ISO.

https://help.ubuntu.com/community/Installation/MinimalCD

It's a netinstall so the computer will have to be online to grab the packages but I don't see that as a huge issue.  IIRC Ubuntu by default verifies all the packages it installs via GPG signatures.  The plan is to grab all the packages that Armory needs while online then disconnect, blacklist the wifi module, and never connect to the internet again.  Then only after I'm offline for good will I install Armory and generate my private keys.  Updates don't really matter unless it's something that directly effects Armory so I won't even both with those (if it is something that affects Armory I'll just grab the .deb from my online computer, verify it, then copy it over via USB driver... same with updates to Armory itself.)

The downside is they state it doesn't work for UEFI boot.  My UEFI-based desktop supports BIOS emulation (which is actually the default mode) so this isn't an issue there but that's my main online machine.  I have a laptop that shipped with Windows 8 I would like to use as my offline machine so I don't know if I can BIOS boot with that or not.  We'll see in a little bit I guess.  For now, I'm just testing it out in a VM.  Here's a screenshot of the most bare-bones Ubuntu install possible:

http://i.imgur.com/1rRyIPV.png

Really above all else, the point is to do a fresh OS installation on the computer.  If it's been previously online who knows what kind of malware lurks on it (especially if it's running Windows.)  Ubuntu was chosen because it has the largest userbase among desktop distros and the install is probably one of the simplest.

Honestly I've found Linux installs to be easier than Windows installs.  The main pitfalls people run into are in getting certain wifi cards and certain graphics cards to work.  Neither are needed for an offline Armory wallet.  In fact it's even better if your wifi card won't work because then it's impossible for any app to connect to anything.  In the case of the graphics card, likely all you'll be lacking is OpenGL acceleration because if all else fails Linux will fall back to the VESA framebuffer driver which will work on damn near anything.  This will still bring up the Xorg GUI and worst case you'll have to live without some of the transparency desktop effects.  Who cares!  The offline wallet is for signing transactions securely, not for looking pretty!

For older computers, look into Xubuntu and Lubuntu instead of the main Ubuntu.  They use the exact same package base (even pull from the same repos.)  The only difference is in the GUI.  They use Xfce and LXDE, respectively.  Lubuntu is going to be the lightest of the two.  Xubuntu, IMO, looks much better but may use a little more RAM.  Both are much more lightweight than Ubuntu with its default Unity interface.  Perhaps the biggest difference is that Unity has no way to turn compositioning off (the thing that enables the fancy desktop effects.)  This means that if you run into problems with your graphics driver like I noted above, Unity will fall back to llvmpipe which attempts to render all those fancy effects on your CPU.  This works but will be much, much slower (and probably unusable if you have an older CPU.)  On Xubuntu you can simply turn off compositioning (if its enabled by default) to have a fast GUI without desktop effects and with Lubuntu I don't think compositioning is even an option in the first place.

You joke but when you have lots of BTC it pays to be a little paranoid 

One of the basics of computer security is to disable unnecessary services.  For an offline Armory wallet, this means most of a traditional desktop install can go.  I would like to see Armory more easily ported to other distros for this reason.  X11 doesn't bother me so much (Armory is GUI only at the moment so you need it anyway) but stuff like the Ubuntu Amazon shopping lens, web browsers, and bluetooth software could be potential attack vectors.  Sure you can remove all those from Ubuntu but I would prefer to start with a minimalistic Arch or Debian install with only X11, a bare Openbox for the WM, and the dependencies of Armory.  Bonus points for blacklisting the kernel modules for the NIC and bluetooth cards so apps can't connect to anything even if they wanted to.

Looks like you also forgot to merge 0.91.2 into the Master tree on GitHub.  I run Arch Linux so I used the AUR package that pulls from git and I got 0.91.1.

Not many people have enough hashpower to effectively solo mine but for those that do running bitcoin-qt is not much of a problem as they've likely got everything set up in a datacenter.  Also they don't have to trust that a third-party "solo pool" is fairly awarding blocks because they're running everything themselves.

He's just talking about setting up the node on AWS, not actually mining with it.  On topic, I would try just adding a swap partition (AWS doesn't give you one by default.)  It'll run slower but it may be good enough.  I'm showing 660MB RAM usage on my Linux box with bitcoin-qt.  I imagine bitcoind would use less.  The micro instance only comes with 616MB RAM so you will see some swapping but I'd say give yourself 1 - 2 GB of swap and see how it runs.  If it performs poorly you can always upgrade.  The m1.small instance comes with 1.7GB RAM which should be enough depending on how lightweight your OS is.

Has anyone noticed improved hash rate by updating cgminer on the Antminer S1?  It looks like the latest firmware from Bitmain is running cgminer 3.12.  I just got mine recently so that's the version it shipped with and it's been running without issue right around 180GH/s each (I didn't overclock... my 750W power supply probably couldn't handle any extra load since I'm running 2 S1's off of it.)

I read your instructions and it seems pretty straight forward to update since I'm very familiar with Linux and ssh.  I'd just like to know what practical benefits I would get from updating.  I'm kind of leaning towards "if it ain't broke don't fix it" unless it would help me out in some way.

Mine looks the same way.  "As of last block" is 0 but "Estimated Change" looks about right for the total I should have mined since my last payout... it's far more than I stand to get from 1 block anyway like "Estimated Change" usually displays.

What is failsafe mode exactly?  I wish they'd update us when they do something like this.