It was a 'there one day gone the next' issue with getmemorypool - that I brought up in the 0.7.0 release thread back when it came out - but that got swept under the carpet also.
Anyway I guess I should go re-post a lot of this in the GBT thread and
Topic: [1050 TH] BitMinter.com [1% PPLNS,Pays TxFees +MergedMining,Stratum,GBT,vardiff] - page 271. (Read 837101 times)
October 31, 2012, 07:05:05 AM
Well, if it wasn't obvious (it wasn't for me until my last post), my post should be in the GBT thread - it's not really about pools (though it has taken my carry-on about this to realise where the problem is - but also annoying that the problem has been ignored by GBT proponents), it's about GBT itself, however, people choosing to use it and not even realising it may not be the holy grail of decentralisation that it's proponents are saying in their attempt to force everyone to use it. Yes force is correct - they even got rid of the previous option getmemorypool and made it necessary to call getblocktemplate for anything but getwork, through there are clearly issues with getblocktemplate ...
It was a 'there one day gone the next' issue with getmemorypool - that I brought up in the 0.7.0 release thread back when it came out - but that got swept under the carpet also.
Anyway I guess I should go re-post a lot of this in the GBT thread andstir up some trouble see if I can get a reasonable response there ...
It was a 'there one day gone the next' issue with getmemorypool - that I brought up in the 0.7.0 release thread back when it came out - but that got swept under the carpet also.
Anyway I guess I should go re-post a lot of this in the GBT thread and
October 31, 2012, 05:14:15 AM
Bitcoin now has many outstanding transactions.
You can blame it on BitMinter, or SatoshiDice or GBT or whatever.. it won't make any sense though. People are now starting to actually send a few transactions and it's not going as smoothly as we would like. That's a problem we have to solve (together).
I don't think this is any one person's fault. I am certainly not going to accept the full responsibility for transactions processing more slowly now than last year.
I would also not recommend pools to stop using bitcoind to filter out transactions. If you include one bitcoind doesn't like then your block will be rejected and you'll be losing a lot of coins.
Noone said that, that I know of anyway.
You can blame it on BitMinter, or SatoshiDice or GBT or whatever.. it won't make any sense though. People are now starting to actually send a few transactions and it's not going as smoothly as we would like. That's a problem we have to solve (together).
I don't think this is any one person's fault. I am certainly not going to accept the full responsibility for transactions processing more slowly now than last year.
I would also not recommend pools to stop using bitcoind to filter out transactions. If you include one bitcoind doesn't like then your block will be rejected and you'll be losing a lot of coins.
And pools OP are gonna say that it's got nothing to do with them coz they don't control their pools?
Noone said that, that I know of anyway.
October 31, 2012, 03:02:37 AM
Not sure why you come here demanding an explanation from me when BitMinter has the biggest block currently on the frontpage of blockchain.info. Height 205802 with 634 transactions. Maybe you are trolling again?
Pretty sure its trolling/FUD trying to make GBT look bad for some reason... I thought it was kinda funny myself.
Not a couple - 2/3rds of BitMinter's blocks:
Code:
Block size txns
205771 209,454 311
205767 188,756 499
205766 9,468 32
205729 30,740 55
205724 37,399 58
205706 11,169 27
205699 9,720 28
205689 8,609 28
205683 102,113 245
205671 27,961 20
205670 59,118 69
205668 46,083 114
205667 4,791 15
205656 105,743 194
205654 71,232 188
205643 10,739 23
205631 4,551 13
205627 16,381 38
205771 209,454 311
205767 188,756 499
205766 9,468 32
205729 30,740 55
205724 37,399 58
205706 11,169 27
205699 9,720 28
205689 8,609 28
205683 102,113 245
205671 27,961 20
205670 59,118 69
205668 46,083 114
205667 4,791 15
205656 105,743 194
205654 71,232 188
205643 10,739 23
205631 4,551 13
205627 16,381 38
6 blocks (1/3) in there you could consider large (>100 txn),
6 blocks (1/3) are very small (~10k or less and few txns)
Is this basically saying that GBT doesn't adhere to the fee structure in bitcoind?
Is GBT's aim to have every bitcoind on the BTC network constantly running large (>4000) txn memorypools?
And pools OP are gonna say that it's got nothing to do with them coz they don't control their pools?
Hmm ........
October 31, 2012, 02:17:44 AM
We don't have any limit on the number of free transactions as I understand some other pools have. Although the pool was losing all donations for a while due to the frequency of orphans, I never put in any limits despite the possibility that it would have sped up block propagation and reduced the orphan rate.
Glad to hear that, thanks. I wish all pools would do the same. October 31, 2012, 01:28:40 AM
Not sure why you come here demanding an explanation from me when BitMinter has the biggest block currently on the frontpage of blockchain.info. Height 205802 with 634 transactions. Maybe you are trolling again?
Pretty sure its trolling/FUD trying to make GBT look bad for some reason... I thought it was kinda funny myself.
October 31, 2012, 01:14:04 AM
Namecoind locked up against last night. Sorry for slow payments again. 
I will set up an automated system to kill and restart it when it stops working, later today.
Some pools are considering removing namecoins. It starts to look tempting the way namecoind crashes every day and the namecoin developers not really doing anything anymore.
I will set up an automated system to kill and restart it when it stops working, later today.
Some pools are considering removing namecoins. It starts to look tempting the way namecoind crashes every day and the namecoin developers not really doing anything anymore.
October 31, 2012, 01:08:58 AM
Not sure why you come here demanding an explanation from me when BitMinter has the biggest block currently on the frontpage of blockchain.info. Height 205802 with 634 transactions. Maybe you are trolling again?
BitMinter is still including all transactions suggested for the block by bitcoind. We don't have any limit on the number of free transactions as I understand some other pools have. Although the pool was losing all donations for a while due to the frequency of orphans, I never put in any limits despite the possibility that it would have sped up block propagation and reduced the orphan rate.
50BTC just had a block with 34 transactions. Why 34 and not 4000-5000? For an explanation of that you can read the bitcoin sourcode.
BitMinter is still including all transactions suggested for the block by bitcoind. We don't have any limit on the number of free transactions as I understand some other pools have. Although the pool was losing all donations for a while due to the frequency of orphans, I never put in any limits despite the possibility that it would have sped up block propagation and reduced the orphan rate.
50BTC just had a block with 34 transactions. Why 34 and not 4000-5000? For an explanation of that you can read the bitcoin sourcode.
October 31, 2012, 12:33:40 AM
Can I get an explanation of block 205766 ?
Why does it only contain 32 transactions and is only 9.25kb?
The memory pool of bitcoind has been in the 4000 to 5000 range constantly.
In the last 16 hours, the lowest it has been is 4376 outstanding transactions.
If you look at the block that was orphaned by your block, it had 619 transactions in it and was 304.27kb
Edit: N.B. block 205765 before it was almost 30 minutes before it.
Why does it only contain 32 transactions and is only 9.25kb?
The memory pool of bitcoind has been in the 4000 to 5000 range constantly.
In the last 16 hours, the lowest it has been is 4376 outstanding transactions.
If you look at the block that was orphaned by your block, it had 619 transactions in it and was 304.27kb
Edit: N.B. block 205765 before it was almost 30 minutes before it.
Low transaction blocks could be the result of a bitcoind crash/restart.
Since midnight rollover:
Code:
Block Pool txn kb
205802 BitMinter 634 228.62
205800 BitMinter 15 5.15
205796 BitMinter 126 61.31152344
205794 BitMinter 89 25.74804688
205771 BitMinter 311 204.54296875
1 very small in there again. 205802 BitMinter 634 228.62
205800 BitMinter 15 5.15
205796 BitMinter 126 61.31152344
205794 BitMinter 89 25.74804688
205771 BitMinter 311 204.54296875
October 30, 2012, 09:45:34 PM
Can I get an explanation of block 205766 ?
Why does it only contain 32 transactions and is only 9.25kb?
The memory pool of bitcoind has been in the 4000 to 5000 range constantly.
In the last 16 hours, the lowest it has been is 4376 outstanding transactions.
If you look at the block that was orphaned by your block, it had 619 transactions in it and was 304.27kb
Edit: N.B. block 205765 before it was almost 30 minutes before it.
Why does it only contain 32 transactions and is only 9.25kb?
The memory pool of bitcoind has been in the 4000 to 5000 range constantly.
In the last 16 hours, the lowest it has been is 4376 outstanding transactions.
If you look at the block that was orphaned by your block, it had 619 transactions in it and was 304.27kb
Edit: N.B. block 205765 before it was almost 30 minutes before it.
Low transaction blocks could be the result of a bitcoind crash/restart.
October 30, 2012, 07:21:02 PM
Can I get an explanation of block 205766 ?
Why does it only contain 32 transactions and is only 9.25kb?
The memory pool of bitcoind has been in the 4000 to 5000 range constantly.
In the last 16 hours, the lowest it has been is 4376 outstanding transactions.
If you look at the block that was orphaned by your block, it had 619 transactions in it and was 304.27kb
Edit: N.B. block 205765 before it was almost 30 minutes before it.
Now I don't know, but if this is the result of the GBT implementation, it's a worrying sign... considering GBT was meant to improve bitcoin, the potential for pools using it in a way that makes transaction propagation even less likely than before is precisely what I've been complaining about with pooled mining GBT implementations. Why does it only contain 32 transactions and is only 9.25kb?
The memory pool of bitcoind has been in the 4000 to 5000 range constantly.
In the last 16 hours, the lowest it has been is 4376 outstanding transactions.
If you look at the block that was orphaned by your block, it had 619 transactions in it and was 304.27kb
Edit: N.B. block 205765 before it was almost 30 minutes before it.
October 30, 2012, 06:00:03 PM
Can I get an explanation of block 205766 ?
Why does it only contain 32 transactions and is only 9.25kb?
The memory pool of bitcoind has been in the 4000 to 5000 range constantly.
In the last 16 hours, the lowest it has been is 4376 outstanding transactions.
If you look at the block that was orphaned by your block, it had 619 transactions in it and was 304.27kb
Edit: N.B. block 205765 before it was almost 30 minutes before it.
Why does it only contain 32 transactions and is only 9.25kb?
The memory pool of bitcoind has been in the 4000 to 5000 range constantly.
In the last 16 hours, the lowest it has been is 4376 outstanding transactions.
If you look at the block that was orphaned by your block, it had 619 transactions in it and was 304.27kb
Edit: N.B. block 205765 before it was almost 30 minutes before it.
October 30, 2012, 02:08:46 PM
I havent read the last 5 pages, so sorry if this is a repost....I came upon this video.....around the 2:50 mark....http://www.youtube.com/watch?v=K7hVMHVf4p0
Ive also restart some miners....24 blocks, nice....house is getting cold...
Ive also restart some miners....24 blocks, nice....house is getting cold...
October 30, 2012, 10:22:43 AM
Stratum work is entirely push based. There is no requesting of work. BTC Guild pushes new work every 30 seconds. I believe Slush is using the same interval. It's slightly more frequent because new blocks bring a new work push. I'm not sure if slush's implementation resets his 30 second timer after a new block. In the case of BTC Guild, the timer does not reset after a new block.
Thanks, useful info. I'll probably just copy that behavior.
October 30, 2012, 02:30:55 AM
The idea of ignoring txn's sorta seemed a big point in there to me ...
So when using Stratum how often do you request new work to make sure new transactions get included quickly? Or is it the server's responsibility to push out work with a new merkletree when it has new transactions?
Stratum work is entirely push based. There is no requesting of work. BTC Guild pushes new work every 30 seconds. I believe Slush is using the same interval. It's slightly more frequent because new blocks bring a new work push. I'm not sure if slush's implementation resets his 30 second timer after a new block. In the case of BTC Guild, the timer does not reset after a new block.
October 30, 2012, 02:09:53 AM
Last night namecoind locked up again. This caused us to lose a few namecoin blocks and the payment processor got stuck trying to run namecoin payments so it also didn't do bitcoin payments for a while. Bitcoins went out again as soon as I got namecoind restarted. Looks like we had this issue for about 3 hours. Sorry for the delay.
So when using Stratum how often do you request new work to make sure new transactions get included quickly? Or is it the server's responsibility to push out work with a new merkletree when it has new transactions?
I moved over 77Gh/s to port 9000. Hope this helps test things out.
sweet!
been running nice for 7+ hours
Thanks, much appreciated, guys.
So far everything seems to be running smoothly. Difficulty seems to be selected appropriately and mining credited correctly, hashrate reported in completed shifts including both main and test port. Many will have a hashrate between two difficulties and it will jump up and down a bit, but that's not really a problem.
One thought to prevent a huge difficulty for a big mining operation on a single worker account: if the max difficulty the server will give out is the one that is appropriate for a 1.5 TH/s rig then adding multiple such rigs will not affect the difficulty. That should solve it for the 1.5+ TH/s miners at least.
The idea of ignoring txn's sorta seemed a big point in there to me ...
So when using Stratum how often do you request new work to make sure new transactions get included quickly? Or is it the server's responsibility to push out work with a new merkletree when it has new transactions?
just switched over the minirigs about 20 mins ago.. looks ok so far.
I moved over 77Gh/s to port 9000. Hope this helps test things out.
sweet!
been running nice for 7+ hours
Thanks, much appreciated, guys.
So far everything seems to be running smoothly. Difficulty seems to be selected appropriately and mining credited correctly, hashrate reported in completed shifts including both main and test port. Many will have a hashrate between two difficulties and it will jump up and down a bit, but that's not really a problem.
One thought to prevent a huge difficulty for a big mining operation on a single worker account: if the max difficulty the server will give out is the one that is appropriate for a 1.5 TH/s rig then adding multiple such rigs will not affect the difficulty. That should solve it for the 1.5+ TH/s miners at least.
October 29, 2012, 09:52:38 PM
just switched over the minirigs about 20 mins ago.. looks ok so far.
I moved over 77Gh/s to port 9000. Hope this helps test things out.
sweet!
been running nice for 7+ hours
cgminer version 2.8.7 - Started: [2012-10-29 14:01:24]
--------------------------------------------------------------------------------
(5s):51.03G (avg):52.46Gh/s | Q:6267 A:7606 R:32 HW:2 E:121% U:16.4/m
TQ: 0 ST: 37 SS: 0 DW: 2314 NB: 49 LW: 461321 GF: 1 RF: 0 WU: 732.7
Connected to mint.bitminter.com with LP as user
Block: 034c9ead4f41b79ee7651d12... Started: [21:41:47] Best share: 171K
--------------------------------------------------------------------------------
[2012-10-29 21:46:10] Accepted 0155905d Diff 191/64 BFL 26 pool 0
[2012-10-29 21:46:10] Accepted 00e3e98b Diff 287/64 BFL 33 pool 0
[2012-10-29 21:46:11] Accepted 010295c9 Diff 253/64 BFL 23 pool 0
[2012-10-29 21:46:11] Accepted 02cf9b36 Diff 91/64 BFL 24 pool 0
[2012-10-29 21:46:16] Accepted 000d22eb Diff 4.99K/64 BFL 18 pool 0
[2012-10-29 21:46:21] Accepted 032b1fe9 Diff 80/64 BFL 10 pool 0
[2012-10-29 21:46:22] Accepted 014c3075 Diff 197/64 BFL 21 pool 0
[2012-10-29 21:46:41] Accepted 039077da Diff 71/64 BFL 35 pool 0
[2012-10-29 21:46:44] Accepted 034ff34d Diff 77/64 BFL 15 pool 0
[2012-10-29 21:46:54] Accepted 03061153 Diff 84/64 BFL 35 pool 0
[2012-10-29 21:47:04] Accepted 02b0635f Diff 95/64 BFL 13 pool 0
[2012-10-29 21:47:16] Accepted 00b21b65 Diff 367/64 BFL 24 pool 0
[2012-10-29 21:47:16] Accepted 00d5b1db Diff 306/64 BFL 14 pool 0
[2012-10-29 21:47:22] Accepted 00c287d9 Diff 336/64 BFL 31 pool 0
[2012-10-29 21:47:33] Accepted 0036c334 Diff 1.2K/64 BFL 34 pool 0
October 29, 2012, 08:04:21 PM
just switched over the minirigs about 20 mins ago.. looks ok so far.
I moved over 77Gh/s to port 9000. Hope this helps test things out.
October 29, 2012, 07:59:15 PM
... fail ...
I sincerely hope you are not ignoring network transactions as you just suggested you do ...
I sincerely hope you are not ignoring network transactions as you just suggested you do ...
Read what I wrote again, please. This is an idea for how I would implement work generation with GBT and Stratum. It's not something I am already doing. I also said that I won't do it if you can tell me why reusing work with ntime rolled in sync with the clock is harmful.
So grab work every minute and get a 60 times speedup instead of 600. That's still pretty good. Or how often you feel is necessary to not avoid transactions.
If the block used at the beginning of the difficulty calculation has ntime out by 1hr forward (and the block used at the end of the difficulty calculation has ntime correct) - it will mean the result will be 0.66% too high.
Please go back and read what I actually wrote. I don't know how you get from "update ntime in sync with the clock" to "ntime is 1 hour out of sync with the clock".
I tell you how you can save CPU time by producing fewer merkletrees. You reply trying to teach me how merkletrees are calculated. I tell you that you can roll ntime in sync with the clock. You reply that this is bad because ntime will be out of sync with the clock.
You're just trolling, right?
I thought you were still arguing for roll-n-time ... I didn't spot the switch from the post before that ... in the middle of the discussion ...
Glossed over your post too lightly.
The idea of ignoring txn's sorta seemed a big point in there to me ...
No I don't ... usually ... troll serious discussions I'm a part of ...
October 29, 2012, 07:53:28 PM
I tell you how you can save CPU time by producing fewer merkletrees. You reply trying to teach me how merkletrees are calculated. I tell you that you can roll ntime in sync with the clock. You reply that this is bad because ntime will be out of sync with the clock.
October 29, 2012, 07:30:20 PM
You're just trolling, right?
Psst, check his sig. Jump to: