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. |
|
|
|
You know, I'm a little bitter today, and I'm coming around to this point of view. Here you go BCX here's a list: https://bitcointalk.org/index.php?topic=264016.0Just start at the top and diff lock them all. The 5 or 6 that are fixed and running again within a week might be worth trying to work with. |
|
|
|
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: <?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. |
|
|
|
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. |
|
|
|
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. |
|
|
|
Thought you would like to knowrealsolid: i honestly wish the stupid people in the world all died, so i cant treat them how a business which aim is to make money should  realsolid: and that some bad engrish there wolf: RealHitler. thespiral: Then the bar for "stupid" is raised and the circle continues. Stupidception. logicalogic: yeah I feel ya, I'm trying to remove as much Customer service from my life as I can, I expiramented with outsourcing it but didn't get good results achastar: stupid within stupid? realsolid: so you detach the eccentric people like me from the customers ego12: well i get pissed for you; im thinking to myself "cant these fucks go read a page on the forums for 5 minutes" screamingeagle: LOl quopte saved for future referennce RS achastar: how does one achieve such a level of stupity?? prospector: damn brick hashy: night all 3 am bedtime logicalogic: you 100% need to hold peoples hand and never tell them they are wrong even when they are 100% wrong, its the only way to make any progress else they flame you back forever necom: never let your engineers interact with customers. lol! ego12: i killed a man with a trident prospector: yes! realsolid: never send a brick to do a pillows job screamingeagle: I dont think anything can stop the flaming of RS he ruined that long ago thespiral: Lol. realsolid: https://i.imgur.com/wyqcXUr.jpgprospector: you better hide out for a while thespiral: I love lamp. orphanhammer: screamingeagle, kinda sounds like a patriotic nsa name? hashy: might play with some aud tomorow lol logicalogic: Love the "I'm gonna complain to BBB" or "I will persue legal action and will be in touch with my lawyer" to myself I alway say "go ahead you fuck" those are always empty threats, but in reality I have to answer objectively, nicely, and with a sollution thespiral: Lol, RS xP logicalogic: without telling them they are wrong achastar: when i was doing field services at ASU my boss told me that I was too "nonchalant" about what i was talking about when I was out fixing the profs' pc's/staffs pcs prospector: i can't believe you banned usahero rs, we had recently gone from enemies to friends realsolid: maybe ill unban him after she calms down thespiral: Snap Snap. achastar: I never understood why achastar: could someone fill me in?? achastar: lol. screamingeagle: LOl and another quote of RS real nice dude realsolid: he usually is ok, but recently since he failed to pay for the shares hes been untolerable realsolid: intollerable! prospector: he didn't pay? but he makes out he is a major baller realsolid: im dieting so its ok my spelling is fuzzy prospector: from some eastern euro country realsolid: prospector: he didnt want to risk $150, so you do the math achastar: well prospector: hahaha thats probably 25 goats and 10 pigs where he lives orphanhammer: slovenia thespiral: It is a small gamble. Why I only got 6 shares, but it's a fun little gamble. achastar: i'm in between a rock and a hard place on the .2 btc i'm wanting to give to you rs... I want to, but .2 btc is a lot of my wdc currently realsolid: i dont care if he didnt want to risk it, its irrelevant, but to ask for it then not even say he didnt want it. thats an asshole prospector: and wef did that too right? another "baller" wolf: I'm a baller, I've got 3 BTC lol realsolid: then he comes around acting like its the smartest decision he ever made and warning people of the "Risks" that they already know hartar: Hey RS - how about an FAQ button? That's sure to save ya a lot of time. That and appoint your faithful trolls a special colour to handle the easy customer service crap in exchange for...I dunno...whatever token you like. realsolid: this is why he got banned, stupidity juggernaut: dude I dumped my IFC and paid right up, and my ass is poor So, you're saying you hang out at mcxNOW? |
|
|
|
The update won't even cause a fork.
I don't think that word means what you think it does. This update is exactly the definition of a hard fork. A change to the protocol, which many (most) of the existing clients will reject, causing the creation of two incompatible block chains with the same name and other identifiers.  |
|
|
|
How deep could this thread go before someone points out that there's no use for the coin?
That's not true! Litecoin, and other scrypt coins are absolutely useless. Primecoin finds prime numbers, which can be useful for science. It also verifies blocks faster than SHA. Yes but that's not a use for the COINS. Mathematicians may run primecoin for the fun of it, or for scientific value. Miner, traders, and normal people are going to stop running it at some time if there's never any use for the coins it generates. |
|
|
|
If someone is selling a item to be used for a money making enterprise i.e. mining there is a understanding that is implied to the client that this service will make you money NOT COST you money your excuses are all bullshit.
Nobody with a dollar is going to sell it to you for 80 cents. If someone is selling a service to be used for money making, there is a clear understanding that is implied to the client: They're going to make more money selling the product to you than they expect to make using it. yes I understand that to a certain extent, but when they SCAM THE CRAP OUT OF YOU GETTING A RETURN OF 4% THAT IS BULLSHIT AND THEY ARE FULL BLOWN SCAMMERS! THEY KNEW THAT IT WOULD ONLY RETURN 4% AND STILL WENT OUT OF THEY WAY TAKE OUT MORE ADVERTISING AND A GET NEW VICTIMS! THEY COULD HAVE REFUND THE MONEY AT THE START jeeebus, take a valium. |
|
|
|
What makes it better than, say, feathercoin?
It's marginally less wasteful, as some people are interested in it's output. Nothing else. In fact, feathercoin has some services and infrastructure, and as part of UNOCS it "may" have a better future than prime coin IMO. Not that I'm a huge feathercoin fan but, since you picked that as your example... |
|
|
|
 HoooWhoooo ! |
|
|
|
It's not a "No" but it's definitely not a "Yes" - Lets just say I'm keeping our options open for a day or two.
As one of the only alts to try and develop a unique infrastructure before announcing yourselves, I think there are plenty of people happy to give you the time you need. Rapid adjustment can, on the one hand, simply allow any attackers or hopping pools to push the diff even higher before abandoning the coin again. I wish I had better input to give but I'm stumped by this one - as long as it's coins vs miners it seems most other types of development and innovation are going to have to stop (or at least slow way down) until someone figures out a long term fix for this. In the meantime a sudden attempt to hard-fork someone else's coin while the dev is still actually working with it is a pretty lame-ass maneuver. |
|
|
|
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! |
|
|
|
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? 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. |
|
|
|
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... 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. |
|
|
|
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. |
|
|
|
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
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. |
|
|
|
just done around 10 1k transactions
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 |
|
|
|
soooo, with this update, you hope to make your current holdings, more valuable, before dumping them? Still no word on making GLD useful, eh?
It is useful, it is the Gold Standard of Digital Currency! Thank you for your support. It's very much appreciated! I'm also working now on producing a series of TV commercials that will depict average/ordinary consumers using GoldCoin as money in their day-to-day lives. My goal is to have these ads produced and aired sometime late in the fall. Ultimately it will be mass consumer adoption that will take GoldCoin™ to the next level. IMO Why not put some of that effort into making something to use it for? Until you do all of this PUMP PUMP PUMP basically reeks of a huge fleecing. EDIT: At this time is there one single thing for a non-miner/non-crypto-trader to do with GoldCoin™ ? |
|
|
|
just done around 10 1k transactions
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. |
|
|
|
|
Show Posts
