 Show Posts
|
|
Pages: [1] 2 3
|
what block am I suppose to be on I'm showing 175038?
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
|
|
|
|
I cannot even determine if it safe and reliable to mine trc... Or even predict my daily coins earned. This has to be the most confusing alt. What does 1 g/h earn right now? The diff also bounces around so much i am unclear if the core prob from a few days ago is resolved.
It seems the core problems from before are resolved and things are more stable now. Coinotron turned their pool back on, at 400Gh+ atm. As far as earnings go, that's hard to say because the difficulty does move around a lot. When it hits the 5255 floor it seems quite profitable at the current price. The surges in difficulty come and go, they don't remain constant. http://www.cryptocoinexplorer.com:3750/chain/Terracoin?count=20miners bumps too (causing this diff movements?) ; check coinotron for example, number of miners and TRC hashrate more than doubles every now and then |
|
|
|
I still find it odd in the sense that it is different from the normal generation, as I would think that a coin base transaction would be uniform with a system that has constant value as a mining reward.
I guess the question is academic as the blocks are being accepted and the transaction does equal the 20 TRC reward.
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 am curious if this would be due to a modified client, or something inherit to the official client itself?
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: "failover-only" : true,
"submit-stale" : false,
"intensity" : "d",
"gpu-threads" : "1",
"gpu-dyninterval" : "7",
"expiry" : "110",
"scan-time" : "60",
"log" : "1",
"queue" : "1",
: downgrading to 2.9.4 fixes that "issue" ; "Q" indicator increases again. |
|
|
|
Anyway, I used strongcoin to open an account and did some freebie stuff now my balance is showing as 5.0e-05 (not quite sure what that means, never mind!). So I decided to mine and installed 50Miner and my hahrate is 82mh/s - not great but it's not a fantastic graphics card.
Does the 5 before the . indicate 5 bitcoins though, do you know?
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 : TRC rbpps coming soon (4-5 Ghashes/s pool hashrate suitable)
( 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 ...) |
|
|
|
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)
There is no reason why a 51% attack needs to affect txns. It can just monopolize mining and have no other impact on end-users. (i.e. unapproved miners get their blocks rejected. other than that everything is normal) 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, Sometimes longpolls can hit every second or so, but it is 30s sometimes too. Avg form last few is always 10s - this way p2pool share chain is regulated (shares are too frequent -> share diff goin up).
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: "gpu-threads" : "1",
"expiry" : "10",
"scan-time" : "9",
"queue" : "0",
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 ) |
|
|
|
|
