Topic: █▓▒░-< [ZPOOL.CA][BTC Multipool] The miners multipool >-░▒▓█ Paid 925+ BTC (Read 217698 times)

Actually, in the folder below yaamp, there is a config.sample.php file. You copy that to config.php and add your settings there before the defaultconfig.php file is run.

More made up BS. There is no way you would know that.

I've said all I've needed to say now. Since many people feel the effective pool rate is higher the advertised pool rate, if they feel this support issue is not being addressed and they feel they have enough evidence, I suppose they could always discuss it here:

https://bitcointalk.org/index.php?board=83.0

Guys, last time ill personally say it:

All of this chatter needs to be in a separate discussion thread about the issue.  you can let crackfoo know about the thread and I am sure he will check it if asked.

You were asked several times to do this.

YAAMP_ALLOW_EXCHANGE will be set in another config file before the defaults are run, so the !defined check will not pass.
It makes sense that user earnings are converted to a BTC value and then converted back to the payout coin of choice when the system is set up this way.
However, the algo fee seems to be applied at earnings time, so if the code snippet implies another hard coded 2% fee at payout time, it might be the case that there is a double fee application error. That might be worth looking into and raising an issue against yiimp if it is the case.
When the system seemed to have an 80% share cap when being the only miner on an algo solving blocks, from a code trace this appeared to be the result of a query against the share table. I was unable to query that table to check if it was the case that his table was getting corrupted, but such an issue would propagate up to earnings. But the code has changed since then.
We aren't going to get to the bottom of the problem by just looking at code, if we cannot confirm what the data holds is what we would expect.
So I've come to my own speculative conclusions, but the bottom line is what is the most profitable pool for your equipment? I suppose with so many algos going ASIC/FPGA, I'm benefiting less and less from the profit switching component of the pool, and only really benefiting from the pooled exchanging. I've retired my ASIC's because my hash percent was so low most coins weren't building up a sat before exchange time.

https://github.com/tpruvot/yiimp/blob/next/web/yaamp/defaultconfig.php


DEFAULT CONFIG.. you will change this to what you want..

but what do i know

 


PS the OP said to start a new thread.. maybe you can find answers you like from someone else.

BS, you just made that up.  If false, which it is, it converts to the refcoin value, which can be BTC.
That's what the code says.

The only effect of it being true in this piece of code is to set the refcoin to BTC if is currently not defined.

the pool admin, crackfoo, would have set allow_echange to true in the config..

its obviously enabled cause if it wasnt we wouldnt be paid in bitcoin at all..

YAAMP_ALLOW_EXCHANGE is set to false here...


... and never set true. So the first branch of the if is always skipped.

However there is a bug, or just bad coding. The "same coin" test (3rd branch) should be done before the "other altcoin" test (2nd branch).
The way it is written the altcoin test is done before the same coin test and will catch the same coin case unless the price is
strategically set to 0.

This means the same coin case will do a price conversion but it should be 1/1 because the price is being divided by itself.
Something else to confirm.

yeah but allow exchange is turned on, that means the symbol is forced btc.

if allow exchange is disabled, then you would only get paid in the coin that you mine..

this is what its saying.

I found an interesting function. It ckearly shows that no conversion is done if the ernings coin ($coin->id) is the same
as the user's payout coin ($user->coinid) it does no conversion. It simply returns the amount unchanged. It further shows
that BTC payouts are the only ones that can use a market exchange.

The returned value is then added to the balance.

What's my point? This is called by BackendClearEarnings which is where the block's status is changed to "Cleared".
This is a key place to collect data to verify the credit from a block and there is a debug log already.
This also answers the question about doing needless exchanges.

Can we progress forward now and get some real data to stop the speculation?

I appreciate the explanation but I have some concerns about it. Could you point me to the code you are looking at?

I think your math is off. ask+bid/2 * 0.9 is actually 90% of the mean, so it's minus 10%, not 20%.
Regardless of the math it looks like you're saying it will not dump the coins if the price drops more than a specified percentage.
This looks like good downside protection that should limit the losses, not exacerbate them.

looking at the code i see this happening..

even if it says you "earned" 10 BERN or whatever, its really .000002342 BTC and its just showing the BERN amount based on exchange rate at that time.


this is why when you actually get a payout its less.

it actually looks like it comes up with this value by

ask+bid/2 * 0.9 - tx fee..
it also looks like its set to dump the coins on the exchange at up to a 20% loss if it cant meet this price.. during actual exchange..

the only way i see fixing this, is to get the author to tighten up the guesstimation, and lower the loss to say 5% or so..
but the problem this would cause is the people mining BERN or whatever and want to get paid in BTC would see a lot longer pending times..


to the guys that want to mine a certain coins to get paid out in those coins, they should really find a different pool. this one is setup to pay out in bitcoin.

Answers and question highlighted from the same post that asked where... and that posting quoted was the one right before it.

Please.  Stop.

Where? To what end?

Say you do an internal trade in the worst case, you pay the ask and receive the bid. It's an internal trade and you end
up with less than you started with. Where are those coins you lost? Are they in the pool's BTC wallet? If so that's wrong.

However, your example does not line up with the available data. I have not seen anyone post losing more than 30-35% nor
less than 15% and diffferent coins have different spreads so there should be some higher volume, and better known, coins
with smaller spreads and correspondingly smaller losses. But they are all centered around 20%. It's a pattern that is not
dependent on the coind being mined, the coin being paid out or whether an exchange, internal or external, is required.

The simplest case is when the payout coin is the same as the mined coin. No exchange nor estimating is required.

Internal exchnage is the next more complex case because an internal exchange is required. However, the internal exchange
does not incur trading fees and should not be subject to price spread or market flooding.

External exchange, only required for BTC payout, is the most complex case as there are exchange fees and all other market risks.

If the software is executing unnecessary internal trades for same coin payout it complicates debugging. But it seems a simple
to bypass it if it is happening. If the problem goes away for same coin payout you've found where the problem is.

But it's still premature to think about fixes because the problem is still not fully understood. It still needs to be determined where
the loss occurs. It's after the block is cleared but before it appears in the user's balance. That includes retrieving the data from
the DB, possible exchange to payout coin, deducting the estimated block value from the pending and adding the actual value
to the balance. At one of those points an error is being made causing a loss of ~20%.

You say you noted the problem, what is your next step?

It's been noted.

Sounds like a valid ongoing support issue to me. Where else would you like it discussed?

bid 0.00000038 ask 0.00000078

Whats the math there?

Anyways, this discussion is for another thread. Move it please.