i tried direct connection to a seednode, and that's what i am at too.

It's weird, it looks like p2pool isn't following the same scheme ; i guess p2pool users are not up to date

i guess that attacker - now unable to lower difficulty at will - made it skyrocket to harm the currency

Things will probably stabilize, supposing network gets a constant hashrate, and will progressively return to normal difficulties ; time will tell

multiple rpcallowip= lines are accepted too

miners bumps too (causing this diff movements?) ; check coinotron for example, number of miners and TRC hashrate more than doubles every now and then

removed

I just had a quick look at official bitcoin wiki, and couldn't find an exact limit to the number of output addresses, only the total amount is written there.

Not sure if it must be strictly equal to the current awaited value, or if it could also be smaller (i guess not, that would break the whole economy magic i guess)



I think the poolmining software is probably responsible for the block construction, never heard about that kind of client modification, long ago, when i gave a try to eligius pool (as miners only interact with the pool's software ?).

There are probably mining pools that submit generated blocks to multiple remote nodes to ensure it's correctly spread, quickly. (p2pool maybe? just a wild guess, not sure)

on dirait bien que ce sera plus vers 14h - 14h30 ... (33 blocks restants a cet instant)

EDIT2: je ne sais plus compter, desole je laisse ma betise non modifiee ci-dessus pour la peine

il semblerait que beaucoup aient eu envie d'en finir au plus vite


EDIT : et ... je parierais qu'a peine le 210 000 ieme block trouve, beaucoup vont tout shutdown, laissant "ceux qui restent" dans .. le caca pour qq temps

This is one transaction, with 2 outputs, nothing wrong here i'd say.

(and ... i'd bet i know where those are coming from, that 19.8 number appears frequently at a given trc pool)

some pools even use the "generation" transaction to "pay" miners, if i remember right, eligius did (still do?) that earlier to distribute rewards to miners.

1 hour+ round ... i guess that one will cost some coins to the pool

paste your address, so we can see if you finally made it

i see, thanks for sharing info

With the upcoming hashpower increase, i guess every single pool with use diff>1 shares soon (if not already), or a new protocol

unfortunately, i'm not running it, i was waiting for the pps reward, as i've been mining there from time to time (with a low hashrate though).
[moving from proportional to pps right now, by the way. It wasn't available when i left, thanks to you, it is now ]

With my low hashrate, i also ran into that problem a few times, probably when multiple blocks are found within a few seconds (at least with such a low hashrate as mine).

So if i understand, you'd submit shares against a higher difficulty, to submit less shares, but what about the reward ? let's say you submit shares against a difficulty = 16 ... is one of those shares worth 16 diff=1 shares ? (i guess it would look like that, or something )

I don't know if it's ready yet (there's a big thread discussing it under the miner forum, haven't read it entirely yet), but wouldn't stratum help ?

Not sure this is intended or not : using cgminer 2.9.5 under windows7 (64), downloaded from http://ck.kolivas.org/apps/cgminer/cgminer-2.9.5-win32.7z while connected to a GBT-enabled pool, the "Q" value reported by cgminer stays at "3" and won't change, even after hours of running.

This gives giant efficiency values (which may alter the various load-balance algorithms ?)

Part of my conf file:


EDIT : downgrading to 2.9.4 fixes that "issue" ; "Q" indicator increases again.

5.0e-05 means 5.0 * 10^-5

as winterfrost told you, this is 0.00005 BTC

According to the website, bitcoinreactor pool is about to activate PPS reward for TRC :

( http://pool.bitcoinreactor.com/ )

current hashrate is at 2Ghashes/s atm ... wanna give it a try ?
(i'd like to be able to switch from prop to pps, while still beeing able to choose which pool to use, either in failsafe-only, rotate or balance mode ...)

Yeah, you're right, i guess it's because i won't necessarily first prevent other from mining, if i were attacking...

Anyway ... the "tiny, micro, small" pool i've been mining on from time to time found two blocks in the last 24 hours, but .. currently, that pool hashing power is really low, less than 500 M hashes /s not unusual then...

i'll wait and see if another one is finally found by this one

i'm still able to send 'old' TRC coins, and see them included in later blocks.

Any chance you can extract the full reject reason from your log file ? (the client log, if you were solo-mining) ; could be some time-sync issue, or your local client/daemin just "saw" the new block too late.
(looks like cgminer output)

Thanks for your answer,


Yep, i saw that 20 - 30 sec interval between longpolls too, i finally increased my scan time and expiry to fully rely on longpoll mechanism, i'll wait and see ...

I guess the reason for all those 0 - 1 second intervals between longpolls are somehow due to p2pool popularity increase / many people giving it a try, let's hope it will stabilize somehow, so web have at least a few seconds between longpolls

hi,

have anyone here some miner settings suggestions suitable for p2pool, for a low hashrate miner, with 250 - 270 Mhashes/s ?

i currently see longpoll work restart requests every second or so, so with current p2pool network (400Gh/s ~800 share diff), that means my miner app have 1 or 2 seconds to find a valid share against 800 difficulty ?

using cgminer, i currently use those:

So ... it's heavily based on luck (i saw 0 seconds delay between longpoll requests....)

Any comment anyone ?
I'd really like to be able to use p2pool, although .. it looks like it is not for low-hashrate miners anymore...

cgminer 2.9.4
p2pool 9.0

.. excepting the mechanical parts in mining rig

(ok .. that's .. what .. a few watts per fan, but still :p )