Need some testers - I'm willing to fund

[jdebunt]

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

[Giodark]

service is down

[coinerd]

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.

[barwizi]

tz dwn? 

[coinerd]

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.

[Petr1fied]

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:

Code:

<?php

require_once("jsonRPCClient.php");

$rpc_host="127.0.0.1";
$rpc_user="some_user";
$rpc_pass="some_pass";
$rpc_port="some_port";

$client = new jsonRPCClient("http://".$rpc_user.":".$rpc_pass."@".$rpc_host.":".$rpc_port."/");
$test_worked=false;

try
{
    $client->settxfee(0.1);
    $test_worked=true;
}
catch (Exception $e)
{
    $error="[".date("d/m/Y H:i:s")."] ERROR: ".$e."\r\n";
    $filename=dirname(__FILE__)."/errors.txt";
    $fd=fopen($filename, "a");
    fwrite($fd, $error, strlen($error));
    fclose($fd);
}

if($test_worked)
{
    echo "Yay, the test worked";
}
else
{
    echo "Oh no, the test failed. Please refer to <b>".$filename."</b> for further information.";
}

?>

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.

In the near term I think accounts are a more reasonable goal, and also more beneficial to any other future plans.

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.

[coinerd]

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:

Code:

<?php

require_once("jsonRPCClient.php");

$rpc_host="127.0.0.1";
$rpc_user="some_user";
$rpc_pass="some_pass";
$rpc_port="some_port";

$client = new jsonRPCClient("http://".$rpc_user.":".$rpc_pass."@".$rpc_host.":".$rpc_port."/");
$test_worked=false;

try
{
    $client->settxfee(0.1);
    $test_worked=true;
}
catch (Exception $e)
{
    $error="[".date("d/m/Y H:i:s")."] ERROR: ".$e."\r\n";
    $filename=dirname(__FILE__)."/errors.txt";
    $fd=fopen($filename, "a");
    fwrite($fd, $error, strlen($error));
    fclose($fd);
}

if($test_worked)
{
    echo "Yay, the test worked";
}
else
{
    echo "Oh no, the test failed. Please refer to <b>".$filename."</b> for further information.";
}

?>

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.

[Petr1fied]

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.  

[coinerd]

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.