I reported this on the bitcoin bugtracker since it seems like a bug to me: https://github.com/bitcoin/bitcoin/issues/1643

Can you give details of the "betting fitting inputs" you had?  I mean the inputs it used fit perfectly - the sum of the inputs is exactly equal to the bets plus the change plus the fees.  The problem is that the fee is 40 times bigger than the amount you were trying to send!

What would really make this work well would be if pirate also offered the same feature of being able to request withdrawals in advance.  If he knew in advance what the demand for coins would be then perhaps he could better plan on having the coins available immediately for withdrawal.

I guess ultimately all this is a non-issue though.  Nobody minds waiting 24h for a withdrawal - they're just happy you're providing the service you are.

Right, but let's say it's 7:55pm when someone deposits 500 btc and another person has a 500 btc withdrawal set for 8pm.

You would hold the coins for 5 minutes and process the withdrawal.

If they hadn't been able to request the withdrawal in advance you would send the coins to bs&t and then 5 minutes later get the withdrawal request and have to request the coins back again.

It's always better to have advance warning of withdrawals.  At worst it makes no difference to what you do with the coins, and at best it saves you and pirate 2 transactions each.  As I understand it pirate offers higher interest rates to lenders who make less transactions, but I might be wrong about that.

So long as your lenders realise that giving 24h notice doesn't guarantee their withdrawal won't be delayed by up to 24h after the requested withdrawal time.  I think I'd implement it by having a "withdraw in [...] days and [...] hours" box on the withdraw page, defaulting to 0 in both boxes, and allow users to cancel pending withdrawals too.

Yes, thanks.  I re-confirmed to myself that martingale betting and blackjack don't go together very well.

If you don't want the satoshi coins to be spent, you can change the source code quite easily and rebuild.  There's a single place you can change:

In src/wallet.cpp:


Change the 0 to any number N and it will only spend outputs worth more than N satoshis.

You'll have to change it back (or keep multiple copies of the program around) to consolidate the dust manually.

I see three possibilities:

1) it's a competitor trying to slow down SD payments so their crappy clone site looks better in comparison
2) it's someone trying to cheat by double-spending their losing bets
3) it's an accident - someone has some double-spent inputs in their wallet or buggy client software or some such and doesn't know what's going on

I don't know if 3) is plausible.  The first two would seem to be the more likely.

Notice that the double spends started around the time that SD suffered large losses.

You are paying many times more in transaction fees than those satoshis are worth.  You would be better off just throwing the dust away.

If you want to consolidate the dust, and have some large amounts with lots of confirmations you can try sending (large_amount + 0.00000010) to yourself.  The large amount should be high enough priority that the dust can 'ride for free'.

Or keep on paying the high fees - I'm sure the miners don't mind that at all.

Since adding that line to the code I've had no further crashes.  I'm pretty sure that fixes the bug.  There's probably a more efficient way to get the same result than re-opening all the blockchain files, but at least I've found the problem now.

You're close, but off by one I think.

When the customer bets 1 on "lessthan 1" and wins, they get back 64000.

From SD's point of view, they have lost 63999, not 64000.

So SD is betting 63999 and getting back 64000 when the customer loses.

Re-run your numbers taking that into consideration.  You'll find a significantly different result in the "lessthan 64000" case.

I think you must have pawed the wrong buttons on your spreadsheet.  There's no way Kelly would recommend risking more than your bankroll on any bet, like your suggested max bet on lessthan 1 would be doing.  No matter how favourable the odds (SD wins 65535 in 65536 cases), they're still betting 64000 times max bet on them winning - so max bet should better be less than 1/64000th of their bankroll.

Thanks for lending me the bitcoin.  I've finished with it now and 'given' it back to you.

That's fair enough.  I guess people aren't really going to be manually copying the fields on a regular basis.  They'll either do it a few times and see that it's trustworthy, or they'll use some kind of plugin to do it automatically for them.


Feel free to do what you like with it.  It's basically your javascript code with the unused bits removed and converted into Python.  A lot of the guts of it are unchanged from the javascript.

I think it's more convincing for the users to be able to input just the first 3 fields and have an independent program tell them what the cards were rather than have a flashy javascript 'verify' page say "yep - looks good" without showing anything that's going on behind the scenes.  At least with the Python program they get to see that the first 3 fields lead to the cards they saw dealt.  I suppose a relatively small percentage of users are going to bother to install Python and run the script, but it's nice to have the option, for those who ask "what can I do with this 'probably fair' stuff?"

Shortly after interest payments stop seems to be slightly too late to be panicking.  Either the scheme has just defaulted, in which case your withdrawal won't go through, or it hasn't, and there was no (more than normal) reason to panic.

And smaller at the opposite end - there's too much risk there.

How much do you calculate the max bet should be for 'lessthan 64000'?  I got some huge number, like 10k BTC or something like that.

They are scripted, as in a script exists which can make the payments.

And they're manual, as in payb.tc decides whether to run the script or not.  He didn't run it this week because the payment from BS&T hadn't arrived by the time the bitcoinmax payments usually go out.

The payment from BS&T to payb.tc this week is a little less than the weekly interest should be.  I expect they agreed to do the reinvestment off-blockchain this week.

As for "the show", that won't happen until the bitcoinmax payments go out, and only then if you know what addresses to watch.  Since it appears there has been reinvestment of some of this week's interest, I wouldn't be surprised if the weekly interest covers all pending withdrawals.

How about a little javascript to automatically select the whole field when I click on one of the 'provably fail fair' fields?  Currently it's a pain to copy/paste the 'secret' field since I have to triple-click it.  Double-clicking is enough for the other fields, but the secret contains multiple words, so a triple-click is required.

If you're interested, here's a little Python script I wrote that takes three parameters (the client seed, hash, and secret).  It verifies that the hash matches the secret, and prints out the first 52 cards that will be dealt.

http://pastie.org/4366926

And an example of its use:


As you can see from the bolded cards, using a client seed of 'let me win!' isn't 100% effective.

What's your point?  His only 7 posts are on this thread.  Is that suspicious?

He said he was waiting for the payment, and he's probably sleeping now.  He's in Australia.