1 2015-11-07 03:37:35 <Lightsword> I’ve been noticing the more uptime my pools node has the slower GBT is getting in relation to other pools, I’ve been using this tool to monitor block change times http://poolbench.antminer.link/ any idea what the cause of that would be?
  2 2015-11-07 03:41:34 <jtoomim> lightsword yes, i've seen that before too
  3 2015-11-07 03:41:49 <Lightsword> any idea what causes it?
  4 2015-11-07 03:41:55 <jtoomim> i know that mempool size affects GBT time strongly
  5 2015-11-07 03:42:13 <Lightsword> doesn’t seem to be that, I’m already running .0001 as relay fee
  6 2015-11-07 03:42:14 <jtoomim> i haven't seen any cases in which GBT latency was clearly related to operating time and not to mempool
  7 2015-11-07 03:42:28 <jtoomim> run bitcoin-cli getmempoolinfo
  8 2015-11-07 03:42:36 <jtoomim> don't assume, measure
  9 2015-11-07 03:43:03 <Lightsword> "size" : 846,
 10 2015-11-07 03:43:11 <jtoomim> how many bytes?
 11 2015-11-07 03:43:16 <Lightsword> "currentblocksize" : 164910,
 12 2015-11-07 03:43:23 <Lightsword> "bytes" : 6451433
 13 2015-11-07 03:43:41 <jtoomim> so your mempool has 6.4 MB of transactions in it
 14 2015-11-07 03:43:59 <jtoomim> and that's the serialized size
 15 2015-11-07 03:44:06 <jtoomim> so enough for 6.4 full blocks
 16 2015-11-07 03:44:16 <jtoomim> in-memory size is probably about 16 MB
 17 2015-11-07 03:44:31 <Lightsword> now I’m a bit confused, why is that different from getmininginfo
 18 2015-11-07 03:44:34 <jtoomim> that's fairly large
 19 2015-11-07 03:45:29 <jtoomim> why is getmempoolinfo different from getmininginfo?
 20 2015-11-07 03:45:37 <jtoomim> ... because it's a different RPC with a different purpose?
 21 2015-11-07 03:46:12 <jtoomim> CNB has a nested loop in the beginning that iterates over each input of each transaction in the mempool
 22 2015-11-07 03:46:22 <Lightsword> I mean, why wouldn’t those transactions be in "currentblocksize" : 225246,
 23 2015-11-07 03:46:29 <jtoomim> that loop is used to sort transactions according to priority and to find chains
 24 2015-11-07 03:46:36 <jtoomim> that loop is slow if your mempool is large
 25 2015-11-07 03:47:01 <jtoomim> maybe a bug?
 26 2015-11-07 03:47:17 <jtoomim> maybe your mintxfee is higher than your minrelaytxfee?
 27 2015-11-07 03:47:18 <Lightsword> that’s my guess
 28 2015-11-07 03:47:58 <Lightsword> my mintxfee is default
 29 2015-11-07 03:48:02 <jtoomim> you could run getrawmempoolinfo and try to figure out what transactions there are that would not be allowed into a block
 30 2015-11-07 03:48:15 <jtoomim> oops
 31 2015-11-07 03:48:20 <jtoomim> i think it's getrawmempool
 32 2015-11-07 03:48:26 <jtoomim> or getmempoolraw
 33 2015-11-07 03:48:46 <jtoomim> it's getrawmempool
 34 2015-11-07 03:49:32 <Lightsword> yeah, any idea how I would analyze it?
 35 2015-11-07 03:49:37 <jtoomim> i don't know of any tools that would help you sort through it, no
 36 2015-11-07 03:50:30 <jtoomim> it gives you a list of transaction hashes, iirc
 37 2015-11-07 03:50:50 <jtoomim> so you can take those transactions and enter them into blockexplorer.com
 38 2015-11-07 03:51:08 <jtoomim> (don't use blockchain.info, they don't keep unconfirmed txs for very long)
 39 2015-11-07 03:51:27 <jtoomim> as for doing it programmatically, i don't know of a good method
 40 2015-11-07 03:51:28 <Lightsword> so the weird thing is that "size" : 1696, from getmempool info is close to "pooledtx" : 1706, in getmininginfo
 41 2015-11-07 03:52:02 <Lightsword> but the size is way different "currentblocksize" : 473630,  "bytes" : 6934459
 42 2015-11-07 03:52:52 <jtoomim> right
 43 2015-11-07 03:53:00 <Lightsword> which makes no sense
 44 2015-11-07 03:53:12 <jtoomim> so i'm guessing somehow you've gotten txns into your mempool that createnewblock is excluding for some reason
 45 2015-11-07 03:53:16 <Lightsword> it’s well below 1MB
 46 2015-11-07 03:54:49 <jtoomim> by the way, p2pool generates nice GBT latency graphs
 47 2015-11-07 03:55:07 <jtoomim> e.g. http://74.82.233.205:9332/static/graphs.html?week at the bottom
 48 2015-11-07 03:55:34 <Lightsword> what do you see under getmininginfo?
 49 2015-11-07 03:55:37 <jtoomim> it doesn't have getmempoolinfo graphs, unfortunately
 50 2015-11-07 03:55:38 <Lightsword> does it match for you?
 51 2015-11-07 03:56:35 <jtoomim> jtoomim@feather:~$ echo `dev/bitcoin/bitcoinxt/src/bitcoin-cli getmempoolinfo`
 52 2015-11-07 03:56:35 <jtoomim> { "size" : 46329, "bytes" : 621343752 }
 53 2015-11-07 03:56:36 <jtoomim> jtoomim@feather:~$ dev/bitcoin/bitcoinxt/src/bitcoin-cli getmininginfo
 54 2015-11-07 03:56:38 <jtoomim> {
 55 2015-11-07 03:56:40 <jtoomim> "blocks" : 382401,
 56 2015-11-07 03:56:42 <jtoomim> "currentblocksize" : 989879,
 57 2015-11-07 03:56:44 <jtoomim> "currentblocktx" : 1622,
 58 2015-11-07 03:56:46 <jtoomim> "difficulty" : 62253982449.76081848,
 59 2015-11-07 03:56:48 <jtoomim> "errors" : "",
 60 2015-11-07 03:56:50 <jtoomim> "genproclimit" : -1,
 61 2015-11-07 03:56:52 <jtoomim> "networkhashps" : 460138931505464320,
 62 2015-11-07 03:56:54 <jtoomim> "pooledtx" : 46356,
 63 2015-11-07 03:56:56 <jtoomim> "testnet" : false,
 64 2015-11-07 03:56:58 <jtoomim> "chain" : "main",
 65 2015-11-07 03:57:00 <jtoomim> "generate" : false
 66 2015-11-07 03:57:02 <jtoomim> }
 67 2015-11-07 03:57:04 <jtoomim> that's on one of my test nodes, not a mining node
 68 2015-11-07 03:57:06 <jtoomim> obviously, i don't mine with a 600 MB mempool intentionally
 69 2015-11-07 03:57:35 <Lightsword> hmm, would be more interesting to see from a node with minrelay at 0.0001 if you have one
 70 2015-11-07 03:57:40 <jtoomim> no, i don't
 71 2015-11-07 03:58:09 <jtoomim> i try not to mine small blocks when there are transactions in mempool that i consider to not be intentional spam
 72 2015-11-07 03:58:12 <Lightsword> since getmininginfo current blocksize maxes at 1MB it is hard to do a comparison with it
 73 2015-11-07 03:58:16 <jtoomim> i consider doing so to be antisocial behavior
 74 2015-11-07 03:58:54 <Lightsword> I was restricting it because of the high GBT latency
 75 2015-11-07 03:59:17 <jtoomim> ./bitcoin-cli stop; sleep 3; ./bitcoind -daemon
 76 2015-11-07 04:00:20 <Lightsword> you can add daemon=1 to bitcoin.conf so you don’t have to do -daemon when starting bitcoind
 77 2015-11-07 04:00:37 <jtoomim> i suppose you can
 78 2015-11-07 04:00:58 <jtoomim> i guess i used to test it as a non-daemon a lot, so i forgot
 79 2015-11-07 04:02:08 <jtoomim> before you do that, though, you should log your getrawmempool
 80 2015-11-07 04:04:03 <jtoomim> my guess is that you have free relay enabled
 81 2015-11-07 04:04:13 <jtoomim> and you're probably getting a slow trickle of transactions through free relay
 82 2015-11-07 04:04:27 <jtoomim> but which aren't getting evicted, because you don't have an eviction policy set up
 83 2015-11-07 04:04:41 <jtoomim> and which aren't getting mined by you or by other pools
 84 2015-11-07 04:05:31 <jtoomim> probably because there are other transactions that other pools are putting at a higher priority (based on bitcoin days destroyed, or dPriority) that you're not seeing
 85 2015-11-07 04:05:43 <Lightsword> how do you disable free relay?
 86 2015-11-07 04:08:08 <jtoomim> limitfreerelay=0, i think
 87 2015-11-07 04:08:15 <jtoomim> but i'm not seeing that in the command line help
 88 2015-11-07 04:08:44 <jtoomim> it's in main.cpp around line 1146
 89 2015-11-07 04:08:46 <jtoomim> static int64_t nFreeLimit = GetArg("-limitfreerelay", 15);
 90 2015-11-07 04:09:04 <jtoomim> // At default rate it would take over a month to fill 1GB
 91 2015-11-07 04:09:04 <jtoomim> if (RateLimitExceeded(dFreeCount, nLastFreeTime, nFreeLimit, nSize))
 92 2015-11-07 04:09:04 <jtoomim> return state.DoS(0, error("AcceptToMemoryPool : free transaction rejected by rate limiter"),
 93 2015-11-07 04:09:06 <jtoomim> REJECT_INSUFFICIENTFEE, "rate limited free transaction");
 94 2015-11-07 04:09:08 <jtoomim> LogPrint("mempool", "Rate limit dFreeCount: %g => %g\n", dFreeCount, dFreeCount+nSize);
 95 2015-11-07 04:09:10 <jtoomim> ]
 96 2015-11-07 04:10:42 <jtoomim> {
 97 2015-11-07 04:10:42 <jtoomim> bool RateLimitExceeded(double& dCount, int64_t& nLastTime, int64_t nLimit, unsigned int nSize)
 98 2015-11-07 04:10:42 <jtoomim> // Exponentially limit the rate of nSize flow to nLimit.  nLimit unit is thousands-per-minute.
 99 2015-11-07 04:10:44 <jtoomim> static CCriticalSection csLimiter;
100 2015-11-07 04:10:46 <jtoomim> int64_t nNow = GetTime();
101 2015-11-07 04:10:48 <jtoomim> LOCK(csLimiter);
102 2015-11-07 04:10:50 <jtoomim> dCount *= pow(1.0 - 1.0/600.0, (double)(nNow - nLastTime));
103 2015-11-07 04:10:52 <jtoomim> nLastTime = nNow;
104 2015-11-07 04:10:54 <jtoomim> if (dCount >= nLimit*10*1000)
105 2015-11-07 04:10:56 <jtoomim> return true;
106 2015-11-07 04:10:58 <jtoomim> dCount += nSize;
107 2015-11-07 04:11:00 <jtoomim> return fals
108 2015-11-07 04:12:14 <Lightsword> wondering why those wouldn’t get mined….the fee filter happens before the trasaction even gets to the mempool right?
109 2015-11-07 04:13:25 <Lightsword> restarted my node
110 2015-11-07 04:14:15 <jtoomim> const uint256& hash = tx.GetHash();
111 2015-11-07 04:14:15 <jtoomim> double dPriorityDelta = 0;
112 2015-11-07 04:14:15 <jtoomim> // Skip free transactions if we're past the minimum block size:
113 2015-11-07 04:14:17 <jtoomim> CAmount nFeeDelta = 0;
114 2015-11-07 04:14:19 <jtoomim> mempool.ApplyDeltas(hash, dPriorityDelta, nFeeDelta);
115 2015-11-07 04:14:21 <jtoomim> if (fSortedByFee && (dPriorityDelta <= 0) && (nFeeDelta <= 0) && (feeRate < ::minRelayTxFee) && (nBlockSize + nTxSize >= nBlockMinSize))
116 2015-11-07 04:14:23 <jtoomim> continue;
117 2015-11-07 04:14:25 <jtoomim> that's in CreateNewBlock
118 2015-11-07 04:14:27 <Lightsword> on restart getmempoolinfo is consistant with getmininginfo
119 2015-11-07 04:14:35 <jtoomim> so it checks to see if the fee is less than ::minRelayTxFee
120 2015-11-07 04:14:37 <Lightsword> my guess is there is a memory leak
121 2015-11-07 04:14:39 <jtoomim> which is weird
122 2015-11-07 04:14:57 <jtoomim> because it should check against mintxfee, not minrelaytxfee, i think
123 2015-11-07 04:16:05 <jtoomim> oh, never mind
124 2015-11-07 04:16:10 <jtoomim> i misunderstood mintxfee
125 2015-11-07 04:16:12 <jtoomim> strUsage += HelpMessageOpt("-mintxfee=<amt>", strprintf("Fees (in BTC/Kb) smaller than this are considered zero fee for transaction creation (default: %s)",
126 2015-11-07 04:16:36 <jtoomim> it's just a wallet setting
127 2015-11-07 04:16:40 <Lightsword> I’m going to try running with limitfreerelay=0
128 2015-11-07 04:17:51 <jtoomim> the issue is that this check in CreateNewBlock for (feeRate < ::minRelayTxFee) happens after some of the performance bottlenecks of CreateNewBlock
129 2015-11-07 04:18:25 <jtoomim> so you had a few large low-fee tx in your mempool that were getting processed by CNB and ultimately rejected
130 2015-11-07 04:19:17 <Lightsword> so could that be the memory leak?
131 2015-11-07 04:19:24 <jtoomim> it's not a memory leak
132 2015-11-07 04:19:34 <jtoomim> as far as i can tell, the software is running as designed
133 2015-11-07 04:19:45 <jtoomim> it's just not designed the way you thought it was
134 2015-11-07 04:19:47 <Lightsword> are they removed from the mempool at that time?
135 2015-11-07 04:19:53 <jtoomim> and also not designed as well as it could have been
136 2015-11-07 04:20:23 <jtoomim> unless you're running a version with mempool eviction, the transactions will never be removed from the mempool unless they are mined or otherwise invalidated
137 2015-11-07 04:20:45 <jtoomim> we have about 600 MB of transactions floating around right now that were first broadcast on october 7th
138 2015-11-07 04:20:51 <jtoomim> these transactions are 14790 bytes long
139 2015-11-07 04:20:55 <jtoomim> and annoying as hell
140 2015-11-07 04:21:20 <jtoomim> sorry, i should have said "at least 600 MB" not "about"
141 2015-11-07 04:21:20 <Lightsword> so could they be getting invalidated in a way that causes a memory leak?
142 2015-11-07 04:21:40 <jtoomim> i did a lot of testing earlier to see if there were any memory leaks
143 2015-11-07 04:21:46 <jtoomim> and there are no memory leaks that i could find
144 2015-11-07 04:22:00 <jtoomim> if getmempoolinfo is showing the transactions, they're not getting leaked
145 2015-11-07 04:22:25 <jtoomim> also, a memory leak would not cause GBT times to get slow like this
146 2015-11-07 04:22:58 <jtoomim> since for it to slow down GBT, the transactions must be processed by GBT/CNB, which means they are still accessible
147 2015-11-07 04:23:05 <Lightsword> the transaction count does not seem to match the memory usage though
148 2015-11-07 04:23:16 <jtoomim> and a memory leak is, by definition, an allocation of memory that no longer is accessible (pointer lost)
149 2015-11-07 04:23:26 <jtoomim> what do you mean?
150 2015-11-07 04:23:37 <jtoomim> transaction count seems to match memory usage as far as i can tell
151 2015-11-07 04:23:38 <Lightsword> under getmempoolinfo
152 2015-11-07 04:24:14 <Lightsword> since getmininginfo was showing nearly the same number but with a much smaller size
153 2015-11-07 04:24:20 <jtoomim> 846 transactions, 6451433 bytes?
154 2015-11-07 04:24:55 <jtoomim> 6451433 / 846 = 7625 bytes average
155 2015-11-07 04:25:11 <jtoomim> so you probably have about 400 transactions that are nearly 15kb in size
156 2015-11-07 04:25:23 <jtoomim> plus 400 others that are about 400 bytes each
157 2015-11-07 04:25:32 <Lightsword> but what doesn’t make sense is the mismatch between  "currentblocksize" : 473630 and "bytes" : 6934459
158 2015-11-07 04:25:46 <jtoomim> why not?
159 2015-11-07 04:25:53 <jtoomim> you can't make a block that's 6.9 MB in size
160 2015-11-07 04:26:11 <jtoomim> and most of the bytes in your mempool belong to transactions with fees below your minrelaytxfee limit
161 2015-11-07 04:26:12 <Lightsword> "currentblocksize" : 473630  is less than .5MB so I don’t think thats the issue
162 2015-11-07 04:26:30 <jtoomim> block size doesn't matter
163 2015-11-07 04:26:33 <jtoomim> mempool size matters
164 2015-11-07 04:26:47 <jtoomim> about half of the time in createnewblock is just scanning through the mempool
165 2015-11-07 04:26:53 <jtoomim> i have a 600 MB mempool on my test node
166 2015-11-07 04:26:55 <Lightsword> "currentblocksize" : 473630 should come from CNB
167 2015-11-07 04:27:07 <jtoomim> that means that createnewblock has to scan through 600 MB of transactions in order to make a 1 MB block
168 2015-11-07 04:27:22 <jtoomim> the speed of CNB is determined by the 600 MB, not the 1 MB
169 2015-11-07 04:27:23 <jtoomim> mostly
170 2015-11-07 04:27:25 <Lightsword> right, bu if the mempool was 6.9MB why isn’t CNB creating a 1MB block?
171 2015-11-07 04:27:45 <jtoomim> because you have a minrelaytxfee setting which excludes 6.5 MB of those transactions
172 2015-11-07 04:28:52 <jtoomim> those 6.5 MB of transactions trickled in due to the default limitfreerelay=15 setting
173 2015-11-07 04:29:09 <Lightsword> yeah, that’s my guess, but why is CNB using minrelaytxfee?
174 2015-11-07 04:29:20 <jtoomim> because that's what the code says
175 2015-11-07 04:29:22 <phantomcircuit> Lightsword, "because"
176 2015-11-07 04:29:37 <jtoomim> that's the inviolate will of satoshi nakamoto, of course
177 2015-11-07 04:29:45 <jtoomim> or maybe gavin
178 2015-11-07 04:29:52 <phantomcircuit> more likely Luke-Jr
179 2015-11-07 04:29:59 <Luke-Jr> ?
180 2015-11-07 04:30:27 <Luke-Jr> no, that was a "fix" Hearn snuck in IIRC
181 2015-11-07 04:30:34 <Lightsword> so CNB and what gets allowed into the mempool are inconsistant?
182 2015-11-07 04:30:38 <Luke-Jr> which reduced the real default fee
183 2015-11-07 04:30:46 <Luke-Jr> without discussion
184 2015-11-07 04:30:51 <jtoomim> Lightsword: yes.
185 2015-11-07 04:30:58 <Luke-Jr> Lightsword: they're supposed to be
186 2015-11-07 04:31:13 <jtoomim> there is a trickle of free/dust transactions allowed in
187 2015-11-07 04:31:36 <jtoomim> there's also a trickle of dust/free transactions that are put into blocks
188 2015-11-07 04:31:41 <jtoomim> most pools have this disabled, though
189 2015-11-07 04:31:42 <Lightsword> so the mempool just keeps getting bloated until CNB gets bogged down?
190 2015-11-07 04:31:48 <jtoomim> i think only eligius still puts them in
191 2015-11-07 04:31:56 <Luke-Jr> phantomcircuit: it was supposed to be removed in like 0.8 or 0.9 :P
192 2015-11-07 04:32:20 <jtoomim> lightsword: yes, except that until now, we've always been able to clear out all the transactions in the network and get mempool size to 0 every now and then
193 2015-11-07 04:32:20 <Luke-Jr> Lightsword: 0.12 will have some kind of expiry on the mempool stuff
194 2015-11-07 04:32:33 <Luke-Jr> unless we revert it
195 2015-11-07 04:32:44 <jtoomim> But the Oct 7 spam changed that. Now it's chronically full.
196 2015-11-07 04:32:44 <Luke-Jr> jtoomim: what? that was never a goal..
197 2015-11-07 04:33:20 <Lightsword> so why haven’t people been recommending pools to run with limitfreerelay=0 if it is a source of GBT latency?
198 2015-11-07 04:33:36 <Luke-Jr> because GBT latency should not be a problem
199 2015-11-07 04:33:38 <jtoomim> luke-jr: what was never a goal? eligius and free tx, or putting a trickle of dust into blocks?
200 2015-11-07 04:33:38 <Luke-Jr> for the 10000th time
201 2015-11-07 04:33:51 <Luke-Jr> jtoomim: the latter
202 2015-11-07 04:34:12 <Lightsword> what’s the point of allowing free transactions if they aren’t getting put into block by CNB?
203 2015-11-07 04:34:13 <jtoomim> well, one person's dust is another person's dPriority transactions
204 2015-11-07 04:34:21 <jtoomim> i'm referring to the 5% default reserved blockspace
205 2015-11-07 04:34:28 <Luke-Jr> Lightsword: CNB is different for every node.
206 2015-11-07 04:34:41 <Luke-Jr> jtoomim: no, dust is never priority
207 2015-11-07 04:34:50 <jtoomim> fine, free != dust
208 2015-11-07 04:34:56 <jtoomim> i apologize for conflating the terms
209 2015-11-07 04:35:15 <jtoomim> there's also a trickle of free transactions that are put into blocks
210 2015-11-07 04:35:45 <jtoomim> but all of our dust currently gets swept under the carpet, where it belongs
211 2015-11-07 04:35:45 <Luke-Jr> Lightsword: the mempool/relay policy defaults are intended to be explicitly broader than the mining defaults, so that miners can configure their mining policy without being tied back by relay
212 2015-11-07 04:35:53 <jtoomim> and where it remains for ever and ever.
213 2015-11-07 04:36:41 <Lightsword> Luke-Jr, aside from patching bitcoin core itself how would a miner configure their policy separately?
214 2015-11-07 04:37:10 <Luke-Jr> Lightsword: every release has gradually made policy more and more configurable in bitcoin.conf, and miners /should/ be patching Core
215 2015-11-07 04:38:05 <jtoomim> limitfreerelay=x and blockprioritysize=x
216 2015-11-07 04:38:38 <Lightsword> well, I don’t like running patched code like that in production
217 2015-11-07 04:38:56 <Luke-Jr> Lightsword: well too bad. you want to be a lazy miner, and we want you to NOT be a lazy miner. -.-
218 2015-11-07 04:39:06 <Lightsword> although that’s probably more because I’m not able to do code review core code myself
219 2015-11-07 04:39:16 <Lightsword> for core*
220 2015-11-07 04:39:40 <jtoomim> luke-jr: many miners are pathologically afraid of patching core. https://forum.bitcoin.com/post6041.html#p6040
221 2015-11-07 04:39:55 <Luke-Jr> Lightsword: if you can't write the code yourself, hire someone else to do it :P (or to submit improvements upstream to make less patching needed)
222 2015-11-07 04:40:08 <Lightsword> Luke-Jr, I often do hire people :P
223 2015-11-07 04:40:23 <Luke-Jr> jtoomim: I have no idea why you linked that.
224 2015-11-07 04:40:37 <Lightsword> but I don’t really have any policy other than best fees that I would want for my node
225 2015-11-07 04:40:38 <Luke-Jr> Lightsword: good; this is one of those things.. :P
226 2015-11-07 04:40:55 <Luke-Jr> well, best fees can be configured now except for RBF and CPFP
227 2015-11-07 04:41:10 <Lightsword> best fees is default behavior right?
228 2015-11-07 04:41:13 <Luke-Jr> no
229 2015-11-07 04:41:20 <jtoomim> luke-jr: i'm just saying that a lot of miners (like Marshall Long) don't even want to upgrade bitcoind, much less patch it, because they're afraid of breaking something and losing a block
230 2015-11-07 04:41:31 <Luke-Jr> (also, I'd encourage miners to be more altruistic than greedy..)
231 2015-11-07 04:41:51 <Luke-Jr> jtoomim: that link appears to be talking about malware forks, not upgrades.
232 2015-11-07 04:42:14 <jtoomim> In fact we dont upgrade if we don't have to."
233 2015-11-07 04:42:26 <Lightsword> Luke-Jr, I think mining needs to align with economic encentives, if you have to rely on altruism you have a design issue IMO
234 2015-11-07 04:42:31 <Lightsword> incentives*
235 2015-11-07 04:42:42 <Luke-Jr> jtoomim: anyhow, admittedly many lazy miners exist, and that is a problem.
236 2015-11-07 04:42:55 <Luke-Jr> jtoomim: but it's not a problem necessarily solved by enabling laziness ;)
237 2015-11-07 04:43:10 <Luke-Jr> Lightsword: yes, we have a design issue. sadly, knowing that does not fix it.
238 2015-11-07 04:45:04 <Lightsword> well after restarting my node with limitfreerelay=0 I’m at the top of the poolbench
239 2015-11-07 04:45:10 <Lightsword> going to see if it stays that way
240 2015-11-07 04:47:07 <Lightsword> two block in a row
241 2015-11-07 04:50:18 <Lightsword> jtoomim, do you have any mining nodes that have getmininginfo showing below 1MB?
242 2015-11-07 04:54:17 <jtoomim> lightsword: no, because doing so violates my ethics
243 2015-11-07 04:55:32 <jtoomim> there's enough non-spam for 1 MB blocks, so i make 990 kB blocks.
244 2015-11-07 04:56:07 <Lightsword> jtoomim, I allow 1MB block on mine but have to restrict mempool size due to spam using minrelaytxfee, not much in the way of other opions right now that don’t involve patching
245 2015-11-07 04:56:20 <Lightsword> orphans cost a lot….
246 2015-11-07 04:57:03 <jtoomim> lightsword, i use a patched malware fork that has mempool eviction to limit the mempool size to a certain number of bytes on my main node
247 2015-11-07 04:57:20 <jtoomim> where "patched malware fork" is what luke-jr calls XT
248 2015-11-07 04:57:24 <Lightsword> jtoomim, I can’t risk breaking relay network
249 2015-11-07 04:57:39 <jtoomim> that's a valid concern. i use p2pool, so i don't care.
250 2015-11-07 04:57:53 <jtoomim> also, the node that i run this on is not the node that's connected to the relay network anyway
251 2015-11-07 04:58:00 <jtoomim> only one IP address
252 2015-11-07 04:58:06 <jtoomim> RN only allows one connection per IP, apparently
253 2015-11-07 04:58:08 <Lightsword> anyways, IMO the random eviction is stupid because it does not make sense economically
254 2015-11-07 04:58:27 <jtoomim> we've had this conversation before
255 2015-11-07 04:58:53 <jtoomim> i agree that random eviction to keep the mempool very close to the blocksize is not a good idea
256 2015-11-07 04:59:02 <Lightsword> jtoomim, I never heard of any restrictions on relay network per IP
257 2015-11-07 04:59:08 <Lightsword> there are multiple relay network servers even
258 2015-11-07 04:59:20 <jtoomim> hmm, i suppose i should try a different server
259 2015-11-07 04:59:23 <Lightsword> you should be using relay network even with p2pool
260 2015-11-07 04:59:48 <jtoomim> i am using relay network on my :9334 p2pool node, but when i tried it on my :9336 p2pool node, it wouldn't connect
261 2015-11-07 05:00:08 <Lightsword> I’m using “/opt/RelayNode/c++/relaynetworkclient 127.0.0.1 8333 public.us-west.relay.mattcorallo.com”
262 2015-11-07 05:00:13 <jtoomim> my guess is that this was because both servers are NATted on the same IP
263 2015-11-07 05:00:17 <jtoomim> but i am not sure
264 2015-11-07 05:00:21 <jtoomim> i should investigate further
265 2015-11-07 05:00:31 <Lightsword> you are connecting it to bitcoind right?
266 2015-11-07 05:00:34 <jtoomim> yes
267 2015-11-07 05:01:25 <jtoomim> #screen -dmS relaynode /home/p2pool/RelayNode/client/relaynetworkclient public.us-west.relay.mattcorallo.com 127.0.0.1 8333
268 2015-11-07 05:01:30 <jtoomim> strange, the argument order is different
269 2015-11-07 05:01:37 <jtoomim> maybe that was my mistake?
270 2015-11-07 05:01:42 <Lightsword> could be
271 2015-11-07 05:02:19 <Lightsword> bitcoin-cli getpeerinfo | grep "subver"
272 2015-11-07 05:02:33 <Lightsword> and you should see it as a peer "subver" : "/RelayNetworkClient:42/",
273 2015-11-07 05:03:05 <jtoomim> p2pool@feather:~$ /home/p2pool/RelayNode/client/relaynetworkclient 127.0.0.1 8333 public.us-west.relay.mattcorallo.com
274 2015-11-07 05:03:05 <jtoomim> terminate called after throwing an instance of 'std::invalid_argument'
275 2015-11-07 05:03:05 <jtoomim> what():  stoul
276 2015-11-07 05:03:07 <jtoomim> Aborted
277 2015-11-07 05:03:28 <Lightsword> you git pull recently?
278 2015-11-07 05:03:54 <jtoomim> Connected to bitcoind with version 70010
279 2015-11-07 05:03:54 <jtoomim> Finished connect handshake with bitcoind
280 2015-11-07 05:03:54 <jtoomim> p2pool@feather:~$ /home/p2pool/RelayNode/client/relaynetworkclient public.us-west.relay.mattcorallo.com 127.0.0.1 8333
281 2015-11-07 05:03:56 <jtoomim> Closing relay socket, failed to read message header (104: Connection reset by peer)
282 2015-11-07 05:03:58 <jtoomim> Closing relay socket, failed to read message header (104: Connection reset by peer)
283 2015-11-07 05:04:00 <jtoomim> Closing relay socket, failed to read message header (104: Connection reset by peer)
284 2015-11-07 05:04:02 <jtoomim> Closing relay socket, failed to read message header (104: Connection reset by peer)
285 2015-11-07 05:04:04 <jtoomim> Closing relay socket, failed to read message header (104: Connection reset by peer)
286 2015-11-07 05:04:06 <jtoomim> Closing relay socket, failed to read message header (104: Connection reset by peer)
287 2015-11-07 05:04:07 <Lightsword> there shouldn’t be a relaynetworkclient binary in the client folder
288 2015-11-07 05:04:08 <jtoomim> ^C
289 2015-11-07 05:04:20 <jtoomim> so it looks like my version's argument order is different, and my version isn't connecting to the server successfully on this machine
290 2015-11-07 05:04:22 <Lightsword> you need to go into the c++ and use make
291 2015-11-07 05:04:36 <Lightsword> it was updated 10 days ago
292 2015-11-07 05:04:41 <jtoomim> but it connects on the other machine from which i got my binary
293 2015-11-07 05:05:07 <Lightsword> do you see it in bitcoin-cli getpeerinfo | grep "subver"?
294 2015-11-07 05:05:41 <jtoomim> "subver" : "/RelayNetworkClient:42/",
295 2015-11-07 05:05:43 <jtoomim> yes
296 2015-11-07 05:05:58 <jtoomim> it's connecting to bitcoind fine, just not connecting to the remote server
297 2015-11-07 05:06:10 <jtoomim> i suppose i could make the relay node on my other server connect to this one
298 2015-11-07 05:06:22 <Lightsword> well have you tried updating relaynetworkclient?