1 2015-11-08 02:19:20 <Webchat> Joim
  2 2015-11-08 02:19:32 <Webchat> Join
  3 2015-11-08 02:36:35 <jtoomim> https://www.reddit.com/r/btc/comments/3ryoa5/miner_unions_for_fee_control/
  4 2015-11-08 16:38:03 <akrmn1> Hi can any help me with reading blocks from blkxxxxx.dat?
  5 2015-11-08 16:39:27 <akrmn1> I am looking at block 136948. I calculated the hash of the blockheader fine as confirmed with blockchain.info
  6 2015-11-08 16:39:37 <akrmn1> but I do I find the next block in the file?
  7 2015-11-08 16:40:52 <akrmn1> I used the block size integer to count how many more bytes to skip in the file, but it doesn't seem to work as I don't see the magic number right after that
  8 2015-11-08 19:43:47 <kenrestivo> sorry for being lazy, but what's the current best-practices (or link to them) for using BTC for micropayments (USD$1 or so)? use an altcoin instead?
  9 2015-11-08 19:44:18 <kenrestivo> i don't want to pollute the blockchain with a bunch of crap
 10 2015-11-08 19:51:06 <Lightsword> kenrestivo, probably just offchain for now is easiest, kind of depends on what type of microtransactins you are doing
 11 2015-11-08 19:52:14 <Lightsword> right now there is still plenty of space for legidimate transactions in the block chain, fees may be a little higher though because of spam attacks
 12 2015-11-08 20:04:28 <brand0> kenrestivo, lots of people are spamming the blockchain with OP_RETURN and ppl don't seem to mind too much
 13 2015-11-08 20:05:15 <brand0> I doubt many would complain if you were actually using BTC as value
 14 2015-11-08 20:18:49 <kenrestivo> thanks
 15 2015-11-08 20:19:26 <jasjdahsd63hfof> sipa: in 2013 you said you preferred an immediate increase to 10MB or even 100MB block size limit
 16 2015-11-08 20:19:29 <jasjdahsd63hfof> what happened?
 17 2015-11-08 20:20:44 <sipa> jasjdahsd63hfof: i can't remember that, but it's certainly possible i changed my mind... we know a lot more now
 18 2015-11-08 20:20:53 <jasjdahsd63hfof> see: https://bitcointalk.org/index.php?topic=144895.msg1537737#msg1537737
 19 2015-11-08 20:21:01 <jasjdahsd63hfof> that's a big change
 20 2015-11-08 20:21:16 <jasjdahsd63hfof> what new info would have swayed you?
 21 2015-11-08 20:22:04 <sipa> i've since realized that centralization pressure is both in theory and practice a lot worse
 22 2015-11-08 20:22:36 <sipa> the point i was making in that post is mostly that we can't remove the limit
 23 2015-11-08 20:23:17 <sipa> what the actual constraints should be is something to be debated, but i don't think 10 MB is feasible right now, for purely technical reasons
 24 2015-11-08 20:24:41 <jasjdahsd63hfof> what is the bottleneck for 10mb?
 25 2015-11-08 20:25:19 <sipa> relay times, full node memory usage, ever-faster growing UTXO set, ...
 26 2015-11-08 20:25:23 <sipa> these are all solvable problems
 27 2015-11-08 20:27:21 <jasjdahsd63hfof> are you saying 10MB isn't a feasible block size or a feasible limit?
 28 2015-11-08 20:28:14 <btcdrak> sips: does this solve your nits over #6312? https://github.com/bitcoin/bitcoin/pull/6312#issuecomment-154652895
 29 2015-11-08 20:28:14 <sipa> with the current technology, i think 10MB is infeasible without massively increasing centralization pressure for full nodes and miners
 30 2015-11-08 20:29:12 <jasjdahsd63hfof> miners would have to regularly create 10MB blocks
 31 2015-11-08 20:29:22 <Lightsword> one nice way to see how it is in practice is looking at how long blocks take o get out of china which is currently about 5-10 seconds from my benchmarking under current conditions
 32 2015-11-08 20:30:10 <jasjdahsd63hfof> why do we care how long it takes blocks to leave china
 33 2015-11-08 20:30:18 <jasjdahsd63hfof> isn't that where mining is centralizing
 34 2015-11-08 20:30:23 <Lightsword> because it affects orphan rates
 35 2015-11-08 20:30:37 <Lightsword> and higher orphan rates encourage centralization
 36 2015-11-08 20:31:18 <Lightsword> the chinese pools also use SPV mining to increase their block change times for blocks origionating from pools outside of china
 37 2015-11-08 20:31:21 <jasjdahsd63hfof> wouldnt it mostly affect their ow orphan rates
 38 2015-11-08 20:31:27 <jasjdahsd63hfof> own*
 39 2015-11-08 20:31:32 <gmaxwell> jasjdahsd63hfof: you misunderstand how that impact applies. If the moon has a large amount of hashpower and takes a long time to send blocks, it's everyone _else_ that suffers more.
 40 2015-11-08 20:31:50 <Lightsword> yeah, china is not the one getting hurt here….it is everyone else
 41 2015-11-08 20:33:16 <gmaxwell> Increases in block propagation times make mining more progressful, and thus confer benefits to centeralization.  You need to adopt a "relativistic perspective" to understand it, there is no privleged frame of reference:  When communication between alice-bob and alice-charlie is slow, you cannot say that "alice" is slow, -- from alice's perspective bob and charlie are slow.
 42 2015-11-08 20:35:01 <jasjdahsd63hfof> so you would be worried about a pact among chinese miners to only mine ontop of each other's blocks?
 43 2015-11-08 20:35:05 <gmaxwell> Worse, these impacts on miners can be most easly and incrementally "optimized" by centeralizing control and adopting things like "spv mining" that break the system's security assumptions.
 44 2015-11-08 20:35:27 <gmaxwell> jasjdahsd63hfof: no pact is required. Higher transmission delays make that behavio[D[D[D[D[D[D[Dr implicit, unintentionally.
 45 2015-11-08 20:35:35 <Lightsword> I even made a simple tool to monitor propagation in real time http://poolbench.antminer.link/ block 0 is the latest block, you can see how chinese pools like f2pool and btcchina have an advantage
 46 2015-11-08 20:37:24 <Lightsword> you can also see that they are picking up blocks going the opposite direction using SPV mining since the delay is basically one way, bw.com however does not SPV mine so you can get an idea of the propagaion going the opposite direction from looking at their times
 47 2015-11-08 20:38:41 <jasjdahsd63hfof> this seems like a narrow window to practically exploit with high confidence
 48 2015-11-08 20:38:43 <Lightsword> although I suspect bw.com may have issues with GBT latency from mempool bloating so that may not be all that good of a measurement
 49 2015-11-08 20:39:12 <Lightsword> how is it narrow when every second counts?
 50 2015-11-08 20:39:21 <gmaxwell> jasjdahsd63hfof: there is no "exploit", there is just a "bigger miners are more profitable" and "bigger pools are more profitable" effect.
 51 2015-11-08 20:39:59 <jasjdahsd63hfof> it would be nice to see a formal summary of this effect
 52 2015-11-08 20:40:10 <gmaxwell> And so the more profitable miners buy more hashpower, and the people migrate to the bigger choices, incrementally. And we've observed this in practice, since the soft blocksize limit was increased.
 53 2015-11-08 20:40:31 <gmaxwell> jasjdahsd63hfof: it's covered in many places, most recent paper showing it is the bitcoin-ng paper, for example.
 54 2015-11-08 20:42:39 <jasjdahsd63hfof> i thought the relay network provided near constant time propagation anyway
 55 2015-11-08 20:43:00 <Lightsword> that’s not what i’ve seen in my testing
 56 2015-11-08 20:43:16 <Lightsword> it’s pretty good for blocks origionating outside of china
 57 2015-11-08 20:43:26 <Lightsword> but china still has 5-10second delays
 58 2015-11-08 20:45:37 <Lightsword> it varies a lot by block size though, smaller blocks coming from china can be much faster than that
 59 2015-11-08 20:46:34 <Lightsword> I’ve seen smaller chinese blocks closer to 2 seconds
 60 2015-11-08 20:48:23 <jasjdahsd63hfof> im still failing to see why slow egress of their blocks gives them an advantage unless they constantly ignore everyone else and maintain a hashrate majority
 61 2015-11-08 20:48:26 <gmaxwell> jasjdahsd63hfof: no, realy network helps indeed, but it's only constant time in the best case. Also doesn't impact other volume dependant handling delays, which can be quite considerable right now. Though some are improvable with better software.
 62 2015-11-08 20:49:09 <gmaxwell> jasjdahsd63hfof: because they have their own blocks with no delay. Leaving everyone else at a disadvantage.
 63 2015-11-08 20:49:34 <jasjdahsd63hfof> but that needs to happen consistently in sequence
 64 2015-11-08 20:49:48 <Lightsword> it does happen consistantly
 65 2015-11-08 20:50:15 <jasjdahsd63hfof> so it should also be hurting them
 66 2015-11-08 20:50:25 <jasjdahsd63hfof> is my point
 67 2015-11-08 20:50:35 <gmaxwell> jasjdahsd63hfof: for a toy example, imagine 75% hashrate on mars, 25% on earth. Everyone is completely honest. Mars will get almost all the blocks. Because when mars finds a block it will take earth a half hour to learn about it, and all that time earth would have been wasting its time mining on a non-longest chain.
 68 2015-11-08 20:51:24 <Lightsword> now add in that the delay is one way and it is even worse
 69 2015-11-08 20:51:37 <gmaxwell> This applies in-the-small too, it's just easier to imagine with really exagerated figures.
 70 2015-11-08 20:51:55 <jasjdahsd63hfof> does it though when the difference is seconds
 71 2015-11-08 20:52:25 <jasjdahsd63hfof> the ratio of propagation to difficulty seems significant
 72 2015-11-08 20:52:38 <Lightsword> yes, seconds are absolutely critical
 73 2015-11-08 20:52:44 <jasjdahsd63hfof> if its much less than the 10min window its an entirely different thought exercise
 74 2015-11-08 20:52:51 <jasjdahsd63hfof> than to mars
 75 2015-11-08 20:53:23 <Lightsword> in fact the larger the delay is the larger the advantage china has
 76 2015-11-08 20:53:42 <gmaxwell> jasjdahsd63hfof: mining is a posson process, so even when the mean is 10 minutes, a great many blocks are found only seconds apart. And those seconds when you're on a shorter chain are still seconds you're not mining.
 77 2015-11-08 20:53:55 <jasjdahsd63hfof> and the flipside is sometimes it takes an hour
 78 2015-11-08 20:54:00 <gmaxwell> but yes, it gets considerably worse with shorter interblock intervals.
 79 2015-11-08 20:55:19 <jasjdahsd63hfof> it seems as though china is just as likely to orphan their own blocks due to the poisson variance
 80 2015-11-08 20:55:43 <jasjdahsd63hfof> here on earth
 81 2015-11-08 20:55:46 <gmaxwell> what?!
 82 2015-11-08 20:56:18 <Lightsword> miners don’t orphan their own blocks…
 83 2015-11-08 20:57:27 <jasjdahsd63hfof> to have an advantage they'd have to be guarenteed to always win
 84 2015-11-08 20:57:40 <Lightsword> no, they only have to win more often than not
 85 2015-11-08 20:58:53 <jasjdahsd63hfof> and i dont see how you can claim they can if the poisson process is at play adding +/- 0s-3600s jitter with an avg of 600s
 86 2015-11-08 20:59:33 <jasjdahsd63hfof> they would have to form a formal pact
 87 2015-11-08 20:59:49 <jasjdahsd63hfof> it dwarfs the few seconds of delay you're observing
 88 2015-11-08 21:00:26 <jasjdahsd63hfof> and if 50%+ decides to form a pact what does it matter
 89 2015-11-08 21:01:10 <jasjdahsd63hfof> i also don't see how this is clearly described by the ng paper
 90 2015-11-08 21:02:34 <jasjdahsd63hfof> i understand what youre driving at but it seems like a very tenuous argument
 91 2015-11-08 21:02:59 <Lightsword> jasjdahsd63hfof, I don’t think you are looking a this the right way, for every second you are mining on top of the older block you are essentially losing money
 92 2015-11-08 21:03:23 <hdbuck> do not surrender to reddit/corporation pressure and change the blocksize devs!
 93 2015-11-08 21:03:52 <Lightsword> but the amount you are losing depends somewhat on regional propagation
 94 2015-11-08 21:04:32 <Lightsword> for instance in a race between a block in china and one out of china that get found at the same time, china has an advantage due to more hashing power
 95 2015-11-08 21:04:54 <Lightsword> there are of course many other factors in play but that is a large part of it
 96 2015-11-08 21:05:33 <Lightsword> hdbuck, huh? I thought it was corporations like coinbase that were pushing for crazy increases like BIP101
 97 2015-11-08 21:09:21 <hdbuck> lightsword yea, wasnt that what i was implying? MIT, coinbase, reddit mob, whatever, dont let them turn bitcoin into a social media pseudo democracy
 98 2015-11-08 21:10:01 <jasjdahsd63hfof> Lightsword: what are the relative orphan rates atm?
 99 2015-11-08 21:11:55 <Lightsword> jasjdahsd63hfof, I don’t have exact data but it can be extrapolated from my pool bench marking tool, f2pool and btcchina would appear to have a non-insignfican advantage, antpool is somewhat inconsistant but can be fast and bw pool is slower
100 2015-11-08 21:12:24 <jasjdahsd63hfof> it seems like that would be the most relevant thing to track
101 2015-11-08 21:12:52 <Lightsword> it’s really hard to measure directly due to the way pool software differs
102 2015-11-08 21:13:11 <Lightsword> measuring stratum updates is the easiest way to get decent numbers
103 2015-11-08 21:14:03 <jasjdahsd63hfof> people would be more receptive to seeing relative orphan rates. it makes it concrete and a demonstrably real problem.
104 2015-11-08 21:15:38 <Lightsword> jasjdahsd63hfof, you can extrapolate that from stratum update times, orphan rates have high variance and poor reporting which makes them too hard to directly measure
105 2015-11-08 21:17:32 <jasjdahsd63hfof> hmm can you really extrapolate it though? how do u know an update is the result of an abandoned fork
106 2015-11-08 21:18:11 <jasjdahsd63hfof> what about the more coarse measurement of blocks we actually see sent out to propagate
107 2015-11-08 21:18:36 <Lightsword> jasjdahsd63hfof, you can just measure the average time between first pool to see the block and a particular pool and use that number to estimate orphan rates
108 2015-11-08 21:18:52 <Lightsword> stratum updates are the direct result of a pool switching to a new block
109 2015-11-08 21:20:52 <jasjdahsd63hfof> if this argument is so compelling it's interesting to me that no one tracks relative orphan rates
110 2015-11-08 21:21:04 <jasjdahsd63hfof> surely it'd be plastered everywhere
111 2015-11-08 21:21:07 <Lightsword> jasjdahsd63hfof because there is no reliable data
112 2015-11-08 21:21:23 <jasjdahsd63hfof> i thought u told me we could extrapolate it
113 2015-11-08 21:21:55 <Lightsword> jasjdahsd63hfof, indirectly you can estimate it
114 2015-11-08 21:22:32 <jasjdahsd63hfof> well why does no one estimate it and display this damning data which allegedly shows a clear an obvious threat to  decentralization
115 2015-11-08 21:22:40 <jasjdahsd63hfof> and
116 2015-11-08 21:23:03 <Lightsword> jasjdahsd63hfof, for a simplistic estimation just use changetime/600
117 2015-11-08 21:23:13 <Lightsword> that gives you your orphan rate percentage
118 2015-11-08 21:23:22 <jasjdahsd63hfof> my point is no one has done it yet
119 2015-11-08 21:23:31 <jasjdahsd63hfof> but this is a critical lynch pin of many arguments
120 2015-11-08 21:23:39 <jasjdahsd63hfof> can u understand my confusion?
121 2015-11-08 21:23:54 <Lightsword> maybe nobody has made it pretty but people have done he calculations
122 2015-11-08 21:24:28 <jasjdahsd63hfof> where are the results
123 2015-11-08 21:26:13 <Lightsword> well lets use 10 seconds for large block coming out of china as an example, that would be 10/600 or an orphan rate of about 1.7%
124 2015-11-08 21:27:04 <Lightsword> for smaller block coming out of china I’ve seen closer to 2 seconds so that is an orphan rate of about .3%
125 2015-11-08 21:28:06 <Lightsword> there are more factors that come into play but that gives you an idea of what a few seconds can do
126 2015-11-08 21:28:42 <jasjdahsd63hfof> im implying the other factors are material
127 2015-11-08 21:29:14 <jasjdahsd63hfof> theres much more at play than "time spent hashing the wrong block for this cycle"
128 2015-11-08 21:29:51 <Lightsword> jasjdahsd63hfof, yes there is propagation of the competing block that comes into play as well, which further benefits china
129 2015-11-08 21:30:55 <Lightsword> how much it does is tricky to measure due to how many factors are in play such as SPV mining
130 2015-11-08 21:34:50 <jasjdahsd63hfof> what's stopping china from selfish-mining then intentionally. why not exaggerate the effect of the gfw then if it's such a clear advantage
131 2015-11-08 21:35:06 <Lightsword> jasjdahsd63hfof, nothing
132 2015-11-08 21:35:32 <jasjdahsd63hfof> so if blocks were 1mb or 10mb they could do the same thing if they control more hashing power
133 2015-11-08 21:35:38 <jasjdahsd63hfof> the size of the blocks doesnt seem to matter
134 2015-11-08 21:35:49 <Lightsword> larger blocks make the firewall worse
135 2015-11-08 21:36:01 <jasjdahsd63hfof> well we've established nothing stops them from simulating that anyway
136 2015-11-08 21:36:54 <jasjdahsd63hfof> (by the way i really appreciate you engaging me)
137 2015-11-08 21:37:13 <Lightsword> yes, but that would assume they are acting maliciously which they are not, if they chose to make bigger blocks to get more transaction fees they could cause the same problem without the collusion
138 2015-11-08 21:37:31 <Lightsword> and without the malicous intention
139 2015-11-08 21:39:46 <jasjdahsd63hfof> im not sure intention is completely relevant
140 2015-11-08 21:40:17 <jasjdahsd63hfof> if it is a sure way to make more money i think we have to assume it will be adopted
141 2015-11-08 21:40:36 <jasjdahsd63hfof> and if its not so sure then why do we care again
142 2015-11-08 21:41:01 <Lightsword> it already is an issue to some degree, f2pool for instance makes a lot of large block which propagate slowly to non-chinese pools, this gives f2pool an advantage
143 2015-11-08 21:41:48 <jasjdahsd63hfof> they could just delay propagation
144 2015-11-08 21:42:37 <Lightsword> larger blocks do that already without intentionally causing delays
145 2015-11-08 21:43:04 <Lightsword> but they aren’t acting malicously, they are going for more fees
146 2015-11-08 21:43:43 <jasjdahsd63hfof> the real threat to decentralization seems like their aggregate hashrate and not the size of their blocks
147 2015-11-08 21:44:17 <jasjdahsd63hfof> we're latching onto one second order effect
148 2015-11-08 21:44:25 <Lightsword> the thing is larger block incentivise centralization
149 2015-11-08 21:45:11 <jasjdahsd63hfof> wanting to mine with the biggest hashrate is probably a much larger incentive
150 2015-11-08 21:45:50 <Lightsword> I’m talking about incentives for miners when they are choosing a pool, they would be incentivised to go to a larger more profitable pool
151 2015-11-08 21:46:17 <jasjdahsd63hfof> the real incentive there is the hashrate of the pool
152 2015-11-08 21:46:21 <jasjdahsd63hfof> not how big their blocks are
153 2015-11-08 21:46:36 <jasjdahsd63hfof> or some slight orphanrate advantage that cant be reliably quantified
154 2015-11-08 21:47:00 <Lightsword> it’s not really slight, it is measureable and is significantly influenced by block size
155 2015-11-08 21:47:48 <jasjdahsd63hfof> it's a secodn order incentive comparedto hashrate
156 2015-11-08 21:47:53 <jasjdahsd63hfof> if at all
157 2015-11-08 21:48:01 <jasjdahsd63hfof> is my argument anyway
158 2015-11-08 21:48:14 <Lightsword> hashrate can move between pools though
159 2015-11-08 21:48:23 <Lightsword> you attract hashrate by paying out more
160 2015-11-08 21:48:54 <Lightsword> the more hashrate you get the more the pool can pay out, this is what can cause centralization
161 2015-11-08 21:49:07 <Lightsword> larger block increase the impact of centralization
162 2015-11-08 21:50:06 <jasjdahsd63hfof> in some unmeasurable way
163 2015-11-08 21:50:36 <Lightsword> it is measureable, I have been watching it using stratum updates
164 2015-11-08 21:51:07 <jasjdahsd63hfof> what you're measuring isn't an end to end conclusive effect of block size on centralization pressure
165 2015-11-08 21:52:56 <Lightsword> it certainly shows there is an effect, although I don’t have detailed statistics on exactly how significant the effect is over long periods of time
166 2015-11-08 21:53:00 <jasjdahsd63hfof> is there a better channel to discuss this including others?
167 2015-11-08 21:53:06 <jasjdahsd63hfof> this seems pretty off topic at the moment
168 2015-11-08 21:53:24 <Lightsword> well I have to go soon anyways
169 2015-11-08 21:53:37 <jasjdahsd63hfof> ok well good talking with you
170 2015-11-08 21:53:43 <jasjdahsd63hfof> it's helped me understand some more nuances
171 2015-11-08 21:54:31 <Lightsword> if a 1MB block takes 5 seconds to propagate my guess would be an 8MB one could take 40
172 2015-11-08 21:54:35 <Lightsword> or worse
173 2015-11-08 21:54:51 <Lightsword> that would be very very bad
174 2015-11-08 21:57:05 <jasjdahsd63hfof> i better get back to work
175 2015-11-08 21:57:06 <jasjdahsd63hfof> thanks again
176 2015-11-08 22:44:18 <BlueMatt> /query phantomcircuit
177 2015-11-08 22:44:23 <BlueMatt> lol
178 2015-11-08 22:51:11 <Diablo-D3> fail
179 2015-11-08 23:35:25 <essof> Could someone point me to some documentation for building outputs?
180 2015-11-08 23:36:05 <phantomcircuit> jtoomim, really you went to all the trouble of forking testnet and you're not even really running xt?
181 2015-11-08 23:36:05 <phantomcircuit> lol
182 2015-11-08 23:37:21 <jtoomim> yes i am
183 2015-11-08 23:37:32 <jtoomim> i just wasn't connected to any other xt nodes
184 2015-11-08 23:38:35 <jtoomim> hey, does anyone know a way to get a VPS in the mainland?
185 2015-11-08 23:38:45 <jtoomim> amazon aws seems to only allow it if you're a chinese company
186 2015-11-08 23:38:52 <phantomcircuit> ah right that stupid grace period
187 2015-11-08 23:40:28 <jtoomim> our testnet is configured so crappily right now
188 2015-11-08 23:40:36 <jtoomim> performance is going to be epically awful
189 2015-11-08 23:40:37 <jtoomim> should be fun
190 2015-11-08 23:40:42 <phantomcircuit> you realize there's like 3 forks now right?
191 2015-11-08 23:41:00 <jtoomim> uh, i just woke up about an hour ago
192 2015-11-08 23:41:16 <jtoomim> 3 testnets?
193 2015-11-08 23:41:29 <jtoomim> what are you referring to?
194 2015-11-08 23:42:00 <jtoomim> do you mean the v4 fork?
195 2015-11-08 23:42:10 <jtoomim> v4, bip101, and what else?
196 2015-11-08 23:42:23 <phantomcircuit> you'll find out
197 2015-11-08 23:44:54 <wangchun> Lightsword: I suggest you point some hashrate to our stratum server to benchmark. We send stratum job updates to big miners sooner than smaller ones.
198 2015-11-08 23:45:19 <phantomcircuit> wangchun, er... why?
199 2015-11-08 23:45:23 <wangchun> And if you listen to stratum, you'll see slush also sends 25 BTC empty blocks
200 2015-11-08 23:45:36 <phantomcircuit> bandwidth really that limited?
201 2015-11-08 23:45:46 <wangchun> phantomcircuit: to reduce orphan rate, big miners are more valuable to pools
202 2015-11-08 23:45:49 <Lightsword> wangchun, yeah, eligius does sometime similar, with my current setup it’s not really possible
203 2015-11-08 23:46:14 <Lightsword> the benchmarking server is just running cgminer in load balance mode but it is a VPS without any actual hardware behind it
204 2015-11-08 23:46:29 <Lightsword> interestingly enough f2pool is still often the fastest
205 2015-11-08 23:46:39 <phantomcircuit> wangchun, so when you send out new work you would be using 100% of your bandwidth if you weren't doing that?
206 2015-11-08 23:47:21 <wangchun> phantomcircuit: but at 100% bandwidth it still takes a second or two
207 2015-11-08 23:47:35 <wangchun> phantomcircuit: so you have to prioritize big miners
208 2015-11-08 23:47:38 <phantomcircuit> wangchun, ah so you really are using 100% of bandwidth at that point
209 2015-11-08 23:47:52 <phantomcircuit> wangchun, proxies?
210 2015-11-08 23:48:14 <Lightsword> wangchun, the main issue I’m seeing is your blocks are taking a long time to get out of china, you are on relay network right?
211 2015-11-08 23:48:30 <wangchun> Lightsword: yes, i am using relay network
212 2015-11-08 23:48:59 <wangchun> Lightsword: You mean the full block data, not only block header right?
213 2015-11-08 23:49:01 <Lightsword> wangchun, is it bandwidth overall that is causing the slowdown or something else?
214 2015-11-08 23:49:17 <Lightsword> yeah, full block data, my pool fully validates and builds only off of GBT
215 2015-11-08 23:49:39 <wangchun> Lightsword: I don't know, our bitcoind only connect to a limited number of other bitcoinds,
216 2015-11-08 23:50:04 <Lightsword> wangchun, do you use multiple bitcoind instances or just one?
217 2015-11-08 23:50:38 <phantomcircuit> wangchun, are you running the relay network client itself?
218 2015-11-08 23:51:04 <wangchun> Lightsword: what user agent are you using? If it's not Satoshi:0.9.5/0.10.2/0.11.*, you are guaranteed not connected to us directly
219 2015-11-08 23:51:45 <Lightsword> wangchun, I’m running unmodified 0.11.1, but I think I get most blocks off of relay network
220 2015-11-08 23:51:47 <wangchun> Lightsword: I have 6 bitcoinds, which only accept connections from synced Satoshi:0.9.5/0.10.2/0.11.* nodes
221 2015-11-08 23:52:41 <wangchun> Nodes like bitcoinj bitcoinxt and etc have no value to mining operations, only wastes resource
222 2015-11-08 23:52:53 <wangchun> Because no pools using them
223 2015-11-08 23:53:30 <Lightsword> wangchun, I think relay makes the biggest difference, do you see the client when you run “bitcoin-cli getpeerinfo | grep "RelayNetworkClient””
224 2015-11-08 23:53:45 <Lightsword> on all your nodes
225 2015-11-08 23:53:58 <Lightsword> I’m wondering if you accidentially blocked relayclient
226 2015-11-08 23:54:26 <Lightsword> since it’s subver comes up as "subver" : "/RelayNetworkClient:42/",
227 2015-11-08 23:56:40 <Lightsword> if you are blocking any clients without “satoshi:0.9.5/0.10.2/0.11.*” then you are probably blocking relay client
228 2015-11-08 23:57:12 <Lightsword> also make sure you do a git pull to update relay client and compile it from the c++ folder
229 2015-11-08 23:57:53 <wangchun> Lightsword: I think I've got a problem...
230 2015-11-08 23:58:04 <Lightsword> wangchun, you should be running relay client like this “/opt/RelayNode/c++/relaynetworkclient 127.0.0.1 8333 public.us-east.relay.mattcorallo.com”
231 2015-11-08 23:58:21 <Lightsword> wangchun, what sort of problem?
232 2015-11-08 23:59:01 <wangchun> Lightsword: I forgot to whitelist the relayclient ip address in iptables
233 2015-11-08 23:59:13 <Lightsword> wangchun, are you running it locally?
234 2015-11-08 23:59:29 <Lightsword> do you mean the outgoing connection from relayclient?