Bitcoin Forum

Hey I'm trying to get a final round of heavy beta testing on this script.

It's a gambling script - a simple coin flip.

IT's running at 0 confirmations, and binding your input to any required output for security.  But the wallet can't handle this on it's own, and balances get borked really bad once you send any inputs as manually created transactions, so I've had to create an external ledger.

Every once in a while it still rejects a TX.  I was able to reproduce a few times and I'm not getting any useful info out of the logs so I've build a bit more thorough logging into it and now it's not rejecting any (of course).

I need to get some traffic on it and see if I can sort this out.  So....

I'm looking for 8 - 10 testers.  I will send you 100k IFC, I ask you to make at least 50k worth of bets on the site. At max bet this is 50 0 confirmation transactions it won't take a ton of your time and you can walk away with at least 50k IFC.

Volunteers?

i can help you, tell me what do you need i do

i'ld be happy to give it a try, you can add me to the list & send me a PM for future details :)

id be willing to help

Can help. No need to send the IFC.

PM when ready.

haha, i'm in

Thanks!

First ten posted addresses will receive the 100k each.

You'll then be asked to visit http://flip.coinworld.us/IFC/ and make at least 50k in wagers.

Anyone who wants to play on their own dime is welcome to hit it right away.

I would not advise trying with any of the other linked coins at this time.

iBP9RLKqcr7LYxuaJHTgxpsqDnkoc7SefM

iK197ZbtVXgqb8ttk22yavmcAD1KhskG6J

i64jPwSkdiqELHp53tcefR71wbvWYKgwu6

iM98H7zHxT3HgMSXADxmpsQxr9nhTCpvit

sent 100k each!

LMAO wait, that's 200k to barwizi ;)

sent

TX ID: bd802a6820fb7a13053644841085561e6e5c2bee4f2019cded37d205c8aa611a
Hash: 239b03c68b34ee7a944b4268f609d6013d46448e722e2f1e4c079b52702cdf12
Time: 1375385552 (07:32:32 UTC) Number: 9115

Looks like I won that one but was sent back .0001

iAJK4UWhE24qqL6jsCzw9dMw3rnf1Lcx4d :)

ok I'll have a look, .0001 usually indicates a loss.


100k sent

I have this as a reject - the .0001 had to be related to another tx as this never sent.  First reject of the test, too.

post your IFC addy please so I can get you the 100k and thanks for jumping in!

ty, gonna split it between 2 wallets, wanna give my friends something to do if they are interested

No need to send. Will test for a bit longer before lunch.

You are a gentleman, thank you very much and sorry for the loss of your .000000000001 cents (or whatever) :)

sent have fun!

http://flip.coinworld.us/IFC/

(2 rejects so far)

You going to raise the max or keep it at 1000?

Second thought, maybe not with the block split coming soon?

how do you like that 10 IFC minimum fee that's on the way?

Catering to miners at the expense of any potential users - and guarantees a lasting impression of low value.

Think it's fine the way it is.

2 trans in a row sent, nothing returned.

Transaction ID: 36cdb41883602e44077193151d0786a3d840d7492da0db720400a5b47dff92df

Transaction ID: 4554a310a39bfa31ff4bd1e6e061397e57d6aad29922c7bf8d8bbe79ee21065a

lol @ whoever sent the 10k and got 100 penalty.

Sometimes there is a small delay in processing transactions :)

The large amounts are me, im trying to see what happens if i send over limit, also i have learned that by sending too large of amounts you will not have them returned lol

Noticed that earlier, been 10 minutes, still nothing on both.

just done around 10 1k transactions

hmm i have the 45554 as rejected but 36cd i have no record of - this thing might be weaker than I thought.

It has a 5 second rate limit on running the script and I'm not sure how many this server/db can process per cycle.

cycle is approximately 30 seconds when idle, the page does a background ajax to accelerate that to every 8 seconds when someone has it loaded. if too many people are on the page it will be tripping the rate limit.

Did you get 10 payouts?

edit: Just had an awful run 5 of the last 12 were rejects.  I had to update the logging as implode wasn't working in a multidimensional array.

So far this test has brought about 150 tx and maybe 20 rejects thanks a lot for helping with this.  I hope I can nail it down.

Good luck getting it all fixed. Back later if you need more testing.

ok, thanks for your help kimosan

Refunds should be processing without issue.  They are always made from the original input - 10% for fees and change.

If you had one not process it's a big clue for me that fees on fresh coins are probably part of this issue.  I'll have an eye out for any rejected refunds especially that's a good catch.

Again thanks for everyone that is taking time to help with this.

Status: 5/onbevestigd, broadcast through 16 node(s)
Date: 1/08/2013 22:38
To: iEBoRWFz6GyT1ESYWEkVtjy5pgkesFj7v7
Debit: -1000.00 IFC
Net amount: -1000.00 IFC
Transaction ID: 90f6ffd3005938eaf9c920e7a3574ef632c8f201f6b1f218ed8be81777a3e6e6

no response from the game :<

That's two that are not logged at all.

I'm glad I decided to call for testers before "Releasing" this version.

glad you did aswell :)

It didn't ask for any TX fee on that transactions, perhaps that could be part of the reason? I'm not sure...

Edit :

Status: 4/onbevestigd, broadcast through 17 node(s)
Date: 1/08/2013 22:47
To: iEBoRWFz6GyT1ESYWEkVtjy5pgkesFj7v7
Debit: -150.00 IFC
Net amount: -150.00 IFC
Transaction ID: 227f2657b5bc433ed242a6ad3d4904b747b92bb5986c4c22aa8e59293288c636

didn't make it through either i guess? :)

No I mean fees from my end.  This is the second one that the script has apparently "missed".

The issue I was looking for is (more and more presumably) a fee issue - the script automatically includes a .1 fee with every outgoing tx - I'm sure it's not trying to re-use inputs so I'm guessing those times when the protocol wants more than .1 for a fee is the likely cause of these rejects.

Logging from the daemon is pretty poor in this area it's not helpful.  But I do know I've seen fees of up to 9.8 IFC for a transaction consisting of a ton of p2pool payouts.

I'm guessing that since the payout always includes the bet tx as an input, it's a fee issue for coins that are "too new" impacting the payouts.

As to why it's skipped two transactions from the queue, I have no farking idea.  the TX have slowed down, probably another 15 minutes or so and I'll shut'er down for some further analysis.

3rd that's not logged, I was hoping that was a reject.


Hold your coins guys this test is over.  The script will be completely unresponsive in 2-3 minutes.

well i'm off to bed now, will look in this topic tomorrow morning & if it's safe to run again, i'll make sure i get to atleast 50k in wagers :)

ok I have several things going on and I doubt I'll get to the bottom of this today.

Thanks again for your time, don't worry about the extra transactions, and enjoy the free IFC!

Well if you want me to test again, i still have the coins sitting in my wallet, just send a PM if needed :)

service is down

As announced in post #41 this service is down for now.

In order to even try and sort out the two issues it's having I need to determine how the client calculates fees and possibly start calculating them manually.

Then I can try to address the queuing issue - when it got busy it missed at least three transactions.

If it can't get through a half hour of high activity, it's not ready for release.  The other option is to move to actual accounts on my end, and play games with the balance instead of trying for 0 confirmation transaction security.

I'm considering my options. Now that I've got the flow straightened out it may depend on just how difficult it is for me to understand the fee calculations. 

There are other plans that will have me maintaining accounts and balances soon anyways so unless I find out that the fee calculations are relatively simple to implement in PHP I'll probably just move on towards that.

Giodark if you have sent coins send me a PM please.

tz dwn?  :(

Yeap.

I do try to be transparent about these things so, the reasons are listed above.

In the near term I think accounts are a more reasonable goal, and also more beneficial to any other future plans.  The more I think about it, the less and less likely it is that I will try and revive this in it's current form. It was an interesting exercise and I learned a TON about both the functions and the problems of the wallets regarding balances, transactions, etc...

The wallets can't support anything like this directly, and I'm not sure I want to continue investing so much time to re-work the wallet internals into PHP.

I assume you're using the settxfee method to try and set the fee to 0.1? If this fails due to the required fee being more than the value you're trying to set it to then it can result in an unhandled exception. It may be wise to try something like this to catch the errors:


NOTE: It probably won't provide you with any useful information. It usually just tells you it can't connect in the event you set a tx fee that's less than the minimum you're able to but at least if you're going through try/catch you don't get a fatal error. you actually get the opportunity to do something else like perhaps increasing the tx fee if it fails.


I think it's definitely beneficial to use accounts, users can deposit to their own unique account and you can just use the move method to move the funds between a house account and their own. That's exactly what i do on cryptoblackjack, when they bet the funds get moved to the house account, if they win/draw the relevant amount is moved back to their account.

Not at all.  settxfee is meaningless when you have created a transaction manually.  You would have to calculate the expected fee according to the rules of the network you're transacting on.

I think that code there is just going to tell you if the wallet has allowed you to set your tx fee for future transactions, and setting the wallet to a fee less than what the network demands is accepted by the wallet.  It means you will tie up funds on the block chain that no one will mine into a block.

Fees are applied to manually created TX by simply creating a TX that fails to spend some of it's input, which the network then consumes as a TX fee.  So to ensure you've applied a correct fee you've got to duplicate most or all of the fee calculation for each network including factors such as input age and the final size of the tx data.  Which you don't have until you've created the TX so if you aren't literally encoding the TX data manually you've got to loop it through the wallet to determine that and readjust per iteration until you've found your final fee.

Also the error messages are not informative, I've found multiple different errors where the client simply returns (Error -22 TX Rejected) or whatever.  There's nothing more explanatory in debug.log or anywhere that I can find.

You will see this message for a transaction that includes spent inputs.  You will see this message for a transaction that includes invalid/unsigned inputs.  You will log this message for any of an unknown number of other problems, as well. 

And in many cases even with bitcoin you will log this as your error message while the real info is in debug.log with no timestamp or clue to which tx it's related to.

 And the amount of this stuff depends heavily on which branch of the family tree a coin was cloned off of, and also very much on when it was branched.

In fact I'm not sure that fees are the problem, and there is no logging to tell me what the problem is in most of these clients (tx rejected nothing more).  Reproducing a similar problem with bitcoin testnet is sometimes helpful (better logging) but there's no guarantee that you've tripped the same error in another network.

Here's a peek at my IFC wallet:
----------------------------------------------------------------------------
  getbalance 
----------------------------------------------------------------------------
-23574097.8865

There are nice, elegant fixes for many of the problems I've encountered but real world issues like stack latency come up and kick you in the ass once you start applying them.

You just can't have 12 - 15 hits to the wallet for each transaction once the transactions start coming at at any decent pace, and there are things that the wallets just don't do, like tracking any inputs that have been handled manually.

The account/balance system is shit.  Even in the latest bitcoin with testnet it's no good. And once I found out I had to manually track all inputs and outputs and balances manually, I've run into two new "mystery issues" and the fact that in my current stack seeing 90 - 100 TX in 30 minutes actually caused the queuing system to start dropping transactions, which is probably entirely my fault my queuing system is probably losing them but it's a kludge as well because of how the wallet handles/presents transactions which is, bluntly, asinine.

The fact is that having nearly 100 hours into this and having come this far, all I can see is another hundred coming and no light at the end of the tunnel.  It's proving to be not worth it.  Add in additional factors like community response to these sort of things and some other issues regarding my current resources, hardly feasible in any reasonable sort of way (projected time/earnings).

Then, as you well know, every time something minor glitches out you've got someone running to the forum screaming about how you're a horrible fucking scammer and everyone should never ever use your site - bleh this project is over for now.

Sorry if that doesn't make a lot of sense but I'm pretty frustrated with it, at this point.

If the volume of users is a problem then using a MySQL database is probably the best course of action although that is not without problems of it's own. Transactions could potentially be reversed after the fact so you'd need to ensure you're checking for confirms dropping to zero after the fact.

I used to see the negative balance issue in accounts quite often as it seems that the wallet just picks a random account to send out of sometimes so I've started using the sendfrom method on my daemon based sites as you can directly specify the account the funds come out of.

I know exactly what you mean about scam accusations. They don't even bother raising it with you privately or even giving you the opportunity to resolve it before essentially labelling you a scammer and usually over something that amounts to a few cents worth of coins.  ::)

:)

The mysql database for this site has every input to the account tracked.

There are no random accounts or addresses at any time it is 100% restricted.

Transactions as they are incoming to either of two specific addresses sharing an account, each of which has a separate purpose.

Receive transactions to the betting address are read from the mem pool once they're recognized by the wallet. The transaction is analyzed for one of three conditions.

    Under limit transactions are ignored. Thank you for your donation. (edit: I double checked and I posted too fast. These are stored as unspent inputs not ignored. Still, the thanks ;))

    Over limit transactions are refunded. The transaction it was send in is used as the sole input for a return transaction which sends the user back 99% of their funds, a tx fee, and if anything is left, some change to the script, which is logged to the database as an input for recycling at the funding/change address.

    Transactions which might result in a payout of more than the sum of the script's stored inputs are refunded to the customer. If the system is literally 100% depleted of funds, I would end up having to do this manually as it wouldn't generate an outgoing tx at 0 fee.

So once those conditions are met, the script calculates the bet according to the published rules. If the bet is a loss, the customer is notified with a .0001 payout (and a .1 fee).  If the bet is a win...

The script adds .1 to the payout amount for the win.  It then requests a list of inputs from the db and adds them (oldest to newest) to the amount of the original tx until it has sufficient inputs to send the tx.

Each input is removed from the unspent inputs as it is added to the tx for sending.

Once the necessary total is achieved a tx is constructed using the gathered inputs. Any overage once the payout and fees are covered is returned to the specific change address for the script.

It's then processed in three phases by the wallet; encode, sign, send.

So, when send returns that friendly generic error message, the fun begins.

Step by step troubleshooting it I have gotten to here. If it slips it should be slipping in favor of caution - I suspect it's more likely to lose inputs than to double spend them for instance as they're deleted before there's any actual confirmation of being spent. If in doubt about the ability to pay out it attempts to refund the money.

This is so that it can move along smoothly without a lot of double and triple checking and still be unlikely to screw a customer. While still covering my butt in the end of course.  I won't mind taking my payment in fragmented coins that I eventually have to sort out of a confused wallet - as long as I get paid. Based on what I have read it seems as if the "bind the original input into the output" is a relatively sound method of covering against being double-spent, etc..

So for me it was a goal of the project to have it run as securely as it can in 0 confirmations and be fast. Even with the limitation to private wallets (not being able to play from an exchange account) - a trade off for a multiple alt-coin game right now when a lot of people hold coins they don't have wallets for.

Once I realized that I would have to track the inputs independent of the wallet to get this performance into the game, it seems a next reasonable step to keep things moving is to touch the wallet as little as possible. It still has to be scanned fairly frequently to keep the script moving if no one is camped at the web page.

But for now I need to use the encode, sign, send procedure.  To be entirely honest I'm not up to doing the encoding or the signing myself right now I need these.

Anyways I'm not saying that I'll never fix this but right now I think I'll let it lie with some frustration, and maybe look at a refactor in a couple of days. Obviously i've missed a large hole in the queuing process that's causing me some slippage.

And after all of that, a move to an account based system with balances does sound refreshingly simple indeed.