Can't login to cryptostocks... I can't even override and accept the current certificate for the time being.

Please renew/update your certificate asap.

-- Smoov

Yeah, that's the thing... by that time, I wouldn't need one anymore. I'm trying to find out where a fork occurs in my blk0001.dat file. We're past one of the fork points which Hazard was able to find, since it happened at a specific block, but there is another fork (or a couple) before the merge-mining fork at 160000.

I can currently follow the bad fork (since I didn't update at the time until after I found myself forked off, so still have the orphaned blocks in my chain) but can't backtrack to find where it happened.

I had thought about taking the trimmed blk0001.dat file from the testing build, and re-importing it into the old daemon, to see how far it gets before it rejects my supposed-to-be-orphaned blocks, but it doesn't import well, and have had no success.

(Hazard is handling the code, I'm just doing testing)

-- Smoov

Using -testnet wouldn't let us test against the current blockchain to make sure it is being reloaded properly with all of the past forks and changes to the chain being followed properly.

It wouldn't screw up the real net unless there was more hashpower than the non-testing people have, and we're not hashing at this point, just trying to validate the current chain.

Could really use a block explorer right now tho... anyone still have an i0c block explorer up?

-- Smoov

I thought there was also a claim that Shakespeare was originally written in Klingon too... .. .

-- Smoov

Ahh, that's the piece I was missing. I was assuming a cash table. Tourneys, of course, are different. My mistake.

-- Smoov

edit: but, if all of the other "players" are disconnected ones who's stacks are just being blinded off, I don't count those as active players. In the real tourneys I've played, stacks that have been blinded down up to the cutoff for new entrants to join, got removed from the table. Stacks for players who have joined, but are just gone, won't get removed, but IMHO, if you can't even be bothered to be there and play your stack, you don't really have a right to complain about the other players who are there, choosing among themselves, to check down until your stack is gone. That's probably my #1 gripe about people joining tourneys, never showing up, and their no-play stacks out-last people actually playing to survive into a paying position. Still not relevant to your issue tho, but it came to mind.

If you have 2 people left, and one asks to check it down, openly, I don't see any problem with that. The other person has no obligation to honor that. They could keep checking it down, until the last possible moment for action, and then that player pushes all-in if they want to. Neither is bound to honor 'check it down?'

Since they are the only two left active, and are open about it for all to see, what is the problem?

If they were colluding in private pretending to not be doing so I would agree, that's a problem and needs to be dealt with, but openly agreeing to check it down, I don't think counts as 'colluding'.

This kind of table talk I have seen lots of times at real tables. Most of the time when chopping blinds, where the last two remaining players ask and agree to an action.

If those two were doing so consistently, then maybe it would be worth investigating.

My 2 cents...

-- Smoov

I tried running my jalapeno on a segregated p2pool network (2 nodes only, both nodes on computers I control, no outside connections permitted).

The problem I've been observing using the jalapeno with p2pool is definitely revolving around how the jalapeno returns work. It doesn't look like valid work is returned as soon as it was found, but sending back multiple valids at the same time.

The effect is, the first valid has a good chance of being a valid share, but the rest of the valids sent after it are always rejected.

While they may still be a valid block, I think the same problem arises there too. First valid solves the block, the rest of the valids are rejected as they won't build on the block the first valid solved. Granted, this won't happen often, but it will happen.

The problem when it comes to p2pool is, the miner using the jalapeno, might not get accurate credit for the amount of work they're doing, just because the jalapeno won't abort the work it is doing to start new work, so those miners that are using equipment that will do that, will always have an edge just because they will be more responsive to change.

As the jalapeno keeps mining for more results after it already found a valid result, and not yet sending it along, it is just wasting power at that point.

Just my observations this past week.

Protocol-wise, it seems to behave, it just doesn't appear to handle valid results efficiently.

All that said... after almost 2 years of being stuck at ~160MH/s, now mining at ~5.2GH/s? I don't quite believe I'm watching my own stats yet, thinking I'm being punked by a feed of someone else's screenshots. This is taking some getting used to. XD

-- Smoov

(deleted response, as it was unclear if the fees to what I was replying to, were also going to be paid out PPLNS or Proportional, and if Proportional, then that negated the assumption of PPLNS I was making)

-- Smoov

Ok, maybe it is getting lost in translation (the point, that is)

Try something like this... written as if you expect it to be translated by babelfish...

"How long does the system wait for a withdrawal confirmation, until it expires, and returns the coin back into the account? And, can this be cancelled early?"

-- Smoov

ps: seriously, their english capabilities are atrocious... they desperately need a native englisher on their team.

:facepalm:

and people wonder why we have a backlog of transactions...

it is because of people NOT PROCESSING TRANSACTIONS LIKE THEY'RE SUPPOSED TO BE DOING!!!

they're getting paid to do a job they're not doing...

-- Smoov

Well, OF COURSE that selection of hands would show an abnormal distribution.

Any sampling that is a result of choice, is going to be abnormal.

All those hands that you chose not to run to the river and show would be missing from the sample, so any kind of analysis for finding a normal distribution is impossible.

The fact that you would even offer that as the term of the bet, just tells me you don't have a clue about how random sampling for statistical analysis even works, for determining a normal distribution of a random number generator, and the cards that are being dealt.

You need every card dealt, for every hand, for every table, for a crapload of rounds that were played. Not just the ones that you thought would have been good enough to win, regardless of the other players' choices to hold or fold.

-- Smoov

The green ones are usually 25... 1000 are usually the yellow ones.
Keep the ridged edge on the coin... looks more... coiny...

-- Smoov

Honestly, the orphan thing has more to do with too many connections on bitcoind than it does on p2pool...

p2pool already goes out of its way to help facilitate found blocks getting distributed as fast as possible, but there is no way you're going to be 100% orphan free with the way the bitcoin network itself operates.

Processing transactions is what mining is all about. Too many have forgotten that, believing that mining is about getting coin, and if you can throw in some transactions while you do it, why not.

But... processing the transactions is what our sole purpose as miners, actually is.

Probably be better off to keep the connection counts down to 2-4 on bitcoind, and low connections on p2pool as well, so we're sending data to less people, allowing them to be sent, faster, and let the meganodes with the bandwidth to handle it, focus on the wide redistribution.

It does no good for a node with a residential-quality upstream, to pass along block data to 50 nodes, if it takes 10 seconds to do it.

The torrent community fights about this too, and the best nodes you find that are sending to you fast, are the ones who aren't trying to keep 500 connections open, giving each peer just a few kB/s at a time, making block propagation just drag out forever, much longer than it should, with extra wasted overhead.

Block propagation suffers the same way. Less really is sometimes more.

-- Smoov

Good deal.

-- Smoov

I gotta agree...

It was the main reason I did most of my trading on VCX is because they have the best, most informative, trade notifications, and they were always very responsive.

Something has to be going wrong, this isn't their normal behavior.

-- Smoov

He wants you to paste that requested line, without using any /#+# switches, so the dynamic difficulty values are shown.

Also, +5 is way too high, as shown by the "Difficulty: 0.232827"... that value being used is the upper max p2pool will use based on the current dynamic share diff.

Using +0.0001 would be a better choice than using +5 ... maybe +0.0005 if you have a lot of hashpower behind it.

Your share diff for scrypt is too high too. Even setting it to /1 is probably too high for scrypt.

-- Smoov

Well, unless it has changed, the block solver already gets a bonus, so if the solver is going to get all the TX fees, then the other bonus shouldn't be done anymore.

Pick one or the other, not both.

-- Smoov

The amount the share is worth is based on the target diff you were aiming for, not what diff the share ended up being.

So if you were targetting diff 1,000 shares, and you got 2 shares, at 1,074 and 7,771 then both of those shares would be worth a diff 1,000 share.

If you were targetting diff 2,000 shares, then the 1,074 wouldn't have counted as a share, you would have still got a share for the 7,771 one, which would be worth a diff 2,000 share, which should give you the same share of the payout.

(my example is probably over-simplified, but you get the idea)

-- Smoov

And what's wrong with storing the address?

That's what the Address Book is for.

-- Smoov

Well, they're just gonna have to do better than that.

Their english-speaking customer base is just too big to not have someone who can converse with them effectively when needed.

-- Smoov