OK, he requested a withdrawal.  That's different.

It seems that bitcoinmax is the only outstanding interest payment from yesterday.

The maximum deposit for new accounts at Starfish BCB appears to be 100 BTC now if that helps your decision process any.

I don't understand what that means.  Are you simply saying that customers who currently have more than 100 BTC on deposit can keep it on deposit but not increase the amount?

Source?

120k I think.  And that's the whole BS&T account, which is probably bigger than just bitcoinmax.

But bitcoinmax always reinvests something, and a lot of the smaller BS&T lenders don't.  So it would still make sense to pay out bitcoinmax first.


I personally don't know what it is.  It looks a lot like a ponzi, but maybe there's some magic money-making business going on at BS&T that I don't understand.

Whether BS&T is a ponzi or whether it's putting the borrowed bitcoins to work, it's plausible that it wouldn't have lots of spare coins sitting around waiting to be paid out on Mondays, so the delays in interest payment are explicable whether or not it's a ponzi.

If I had to bet on whether it's a ponzi or not, I'd bet that it is.  But I wouldn't be sure of winning.

I think it's safe to say that pirate wouldn't have taken the bet if it wasn't in his interest to do so.

It's quite possible that both sides end up profiting from the bet.

Last week bitcoinmax was one of the first to be paid by BS&T.  59% of the interest paid to bitcoinmax was immediately reinvested in BS&T, and that reinvestment was then used to pay the interest on other BS&T accounts.

I wonder why the same scheme wasn't used this week since it worked so well last week.

So each time you win (97.4% of the time) you win 7, and each time you lose (2.6%) you lose 290.

Expected winnings per round: 0.974 * 7 - 0.026 * 290 = -0.722 BTC.

Except that Vandroiy didn't shut up after the bet...

payb.tc paid interest on paper, but not on the blockchain.

pirate paid all his lenders except payb.tc.

payb.tc can't and won't pay his lenders until pirate pays payb.tc.

payb.tc has a lot of coins with pirate, and so gets a lot of interest each week.

Pirate probably needs new investment before he can pay the interest.  10K BTC should cover it.

That large closure is MtGox.  My MtGox deposit address is in the same closure.

It's a single file too - all the graphics, css, scripting are part of the main HTML file.  So just save the page to a USB stick and take it to an offline machine to generate your offline keys & brain wallets.

Well, SD pays out unconfirmed bets.  When your bet loses, you get 0.5% of it back, and the other 99.5% goes into their wallet as change, and is used to pay out the winning bets.  If the wallet has lots of old confirmed change from losing bets, that's fine, but what if the only coins available in the wallet are unconfirmed change from losing bets?

When you win, and they pay you out with unconfirmed change from other people's losing bets, it's possible that at least one of those losing bets was double-spent and never confirms.  That means the 0.5% returned payment never confirms, and so neither does the change you were paid with.  That in turns means your winning payment won't confirm.

I don't know how you fix that, but I'm guessing it requires manual intervention.

The client needs to know the passphrase in order to encrypt the private keys - that's why you can't add a private key if the wallet is locked.


I just comment out these two lines in src/rpcdump.cpp:


Then you can import keys really quickly.  Since you've probably just generated the private keys anyway using bitaddress.org it's a real waste of time to scan the blockchain for transactions to and from the keys.  I need to restart bitcoin-qt after importing a batch of keys for the keys to show up in the 'receive coins' tab, but that's much better than having to wait for a full rescan after each importprivkey.

Thanks for that!

I wasn't sure whether to report that one or not since it took such special timing to provoke.

I guess I'll keep reporting everything that bugs me...

Edit: is there some way I can get rid of the odd .62 uBTC in my account?  I don't seem to be able to bet it or withdraw it.  It looks like I deposited it, so I guess I can deposit the matching .38 uBTC to make it go away.

How about letting people set 'satoshi' as their base unit, along with BTC, cBTC, mBTC and uBTC, with the understanding that they'll lose due to rounding if they get a blackjack after betting an odd amount?

(Or maybe just I shouldn't deposit such silly amounts)

Another thing: I was running low at the table, and wanted to re-buy, using the button I hadn't noticed before and which you pointed out in your previous post.  I clicked the 'Buy In' button, and nothing happened for a few seconds.  The button hadn't changed ('buying in...') and the dialog hadn't gone away, so there was no way I could know whether the click had registered or not.  It had, and it appears after trying it again that the button's border flashes when I click it, but I missed that the first time.  It would be better if something permanently changed to let me know that it was waiting for the network, not for me.

Great.

The first time I ran the taint script you just published, it ran for half an hour before I realised what was up.

I modified the 'cluster' routine so it would cluster the blockchain then prompt in a loop for the address to cluster, making it much faster if you want to cluster multiple addresses.  So it was just sat there prompting, but with the prompt redirected to the output file so I didn't see it.

Doh!

I remember this argument he had with hashcoin on the subject of quantum computing.  I thought that D&T was wrong throughout the argument, but I'm no expert.  It just kind of ended with neither side coming around to the other's point of view.  Can you imagine??

It seems like github doesn't have your newest version.  I don't think it has the ability to load keys from a file for the 'taint' command in the version you published...