12015-11-15T00:07:06  *** MarcoFalke has quit IRC
  22015-11-15T00:08:10  *** MarcoFalke has joined #bitcoin-core-dev
  32015-11-15T00:08:39  <gmaxwell> so at devcore one of the things I talked about was some analysis taken from monitoring miners and mining pools. Someone collected data from all accessible stratum endpoints over several months
  42015-11-15T00:10:25  <gmaxwell> and from it I can extract data like how much time from the first pool working on extending block X was it until the 2nd, 3rd, ... nth pool.  Taking the time after the first pool to reach half the pools, fit a linear model reasonably well.
  52015-11-15T00:10:58  <jgarzik> cool
  62015-11-15T00:11:10  <gmaxwell> oh yea you weren't there when I presented on this.
  72015-11-15T00:12:24  <gmaxwell> I tried all sorts of different analysis approaches, including including factors for in china or not, pool origin, etc. but there really aren't enough blocks (esp from smaller miners) to say much of statistical significance.  But size, did.
  82015-11-15T00:12:30  <gmaxwell> Model that R comes up with for that is:
  92015-11-15T00:12:31  <gmaxwell> 20:40 <gmaxwell> (Intercept) 2.491e+00  2.674e-01   9.318   <2e-16 ***
 102015-11-15T00:12:31  <gmaxwell> 20:40 <gmaxwell> size        1.106e-05  4.025e-07  27.474   <2e-16 ***
 112015-11-15T00:13:14  <gmaxwell> which means a 2.491 second constant delay, plus 732kbit/sec. (1/1.106*10^-5*8)
 122015-11-15T00:15:27  <gmaxwell> interestingly, plugging this into an orphaning calculation vs the subsidy---- suggests that the final byte of the block should have a feerate of ((((e^(-1/600*(2.491+((1000000)/90415.91)))))*25)-(((e^(-1/600*(2.491+((1000001)/90415.91)))))*25))*1000 = .00045054 BTC per 1000 bytes, or otherwise you're losing money just considering the subsidy.
 132015-11-15T00:15:58  <gmaxwell> Though reality is not that simple, because of hashpower distribution dynamics, large miners don't really care if it takes small miners a long time to get their blocks.
 142015-11-15T00:17:53  <gmaxwell> so, take with a metric ton of salt, but I thought it was interesting that these figures are in roughly this magnitude.
 152015-11-15T00:18:56  *** alpalp has joined #bitcoin-core-dev
 162015-11-15T00:23:08  <jgarzik> definitely interesting. mostly aligns with my guesstimation of miner+network behavior.
 172015-11-15T00:26:40  <gmaxwell> This way of looking it has some surprising results, but I think correct-- e.g. if you decrease the fixed delay then you actually want a _higher_ feerate for the last byte of the block for it to break even.  because of the exponentially decreasing slope of the orphaning rate as you move away from 0 latency.  1 byte of extra delay makes more of a difference if your base delay is lower.
 182015-11-15T00:27:46  *** pmienk_ has quit IRC
 192015-11-15T00:29:00  <sipa> to reach half the pools... weighted by hashrate?
 202015-11-15T00:29:21  <gmaxwell> yea, not weighed; thats what I was trying to talk about with my "not that simple"
 212015-11-15T00:29:29  <sipa> right
 222015-11-15T00:29:48  <sipa> hard to do with data that spans several months
 232015-11-15T00:30:29  <gmaxwell> because of that the information is a bit more informative about equality/fairness than it is about the economics of fees.
 242015-11-15T00:30:58  <gmaxwell> Though it's an interesting question if the network should be relaying transactions with fees so low that only very large hashpower consolidations could mine them except at a loss.
 252015-11-15T00:31:51  <gmaxwell> also it suggests a framework for setting minimum feerates which are independant of bitcoin's price-- though dependant on communications efficiency, which is perhaps no better. :)
 262015-11-15T00:38:41  <gmaxwell> The reason I went to go crunch the numbers into a feerate is that I was thinking about what the minimum really should be.
 272015-11-15T00:39:59  *** pmienk_ has joined #bitcoin-core-dev
 282015-11-15T00:42:59  <zooko> gmaxwell: I really like what you wrote on -wizards after I parted last time about why people don't treat solo mining as gambling.
 292015-11-15T00:43:14  <zooko> I really think you are right that it is a user-experience issue, not an economic issue.
 302015-11-15T00:43:33  <zooko> If some state lottery offered a scheme where you subscribed and then it would run in the background and eventually someday maybe it would pop up and give you money,
 312015-11-15T00:43:36  <zooko> I think that would be a stinkier.
 322015-11-15T00:43:39  <zooko> a stinker.
 332015-11-15T00:43:42  <zooko>  I mean, nobody would play.
 342015-11-15T00:44:07  <zooko> Instead, you get the build-up-and-anticipation-and-reveal cycle, like scratching off the silver coating to reveal the numbers beneath and find out if you won.
 352015-11-15T00:44:26  <jgarzik> ...maybe this is -wizards material ;p
 362015-11-15T00:44:29  <zooko> If that's right, you could add lottery UX on top of mining, by giving people a button that they can push and then it let ....
 372015-11-15T00:44:31  <zooko> WRONG CHAMN
 382015-11-15T00:44:47  <zooko> Thanks, jg.
 392015-11-15T00:45:04  <sipa> that's a contraction of "wrong chan" and "damn" ?
 402015-11-15T00:45:20  <gmaxwell> Well it's also a bit #bitcoin-core-dev too, in that I think it would be useful if work were done in the GUI to make mining fun, ... but probably more than that is just speculation :)
 412015-11-15T00:46:42  *** ParadoxSpiral has quit IRC
 422015-11-15T00:46:58  <sipa> hmm, if only we had some sort of hash-within-range unlockable scripts, where a block's coinbase is assigned to, so you can postfacto determine who gets it
 432015-11-15T00:47:26  <sipa> then you could buy a range of hashes from a miner
 442015-11-15T01:16:47  *** MarcoFalke has quit IRC
 452015-11-15T01:23:45  *** d_t has joined #bitcoin-core-dev
 462015-11-15T01:35:38  *** Thireus has quit IRC
 472015-11-15T01:44:37  *** d_t has quit IRC
 482015-11-15T01:52:33  *** d_t has joined #bitcoin-core-dev
 492015-11-15T02:24:26  *** Ylbam has quit IRC
 502015-11-15T02:26:37  <GitHub184> [bitcoin] morcos opened pull request #7020: Implement helper class for CTxMemPoolEntry constructor (master...EntryHelper) https://github.com/bitcoin/bitcoin/pull/7020
 512015-11-15T02:35:47  *** jtimon has quit IRC
 522015-11-15T02:50:58  *** moli has joined #bitcoin-core-dev
 532015-11-15T02:53:11  *** molly has quit IRC
 542015-11-15T03:01:43  *** jl2012_ has joined #bitcoin-core-dev
 552015-11-15T03:02:17  *** jl2012 has quit IRC
 562015-11-15T03:10:13  <Luke-Jr> sipa: is there a purpose for such a construct?
 572015-11-15T03:23:56  *** d_t has quit IRC
 582015-11-15T04:07:32  <gmaxwell> ::sigh:: libpng security firedrill.
 592015-11-15T04:09:07  <Luke-Jr> was there a real risk for us?
 602015-11-15T04:10:23  <Luke-Jr> (only PNGs we ever use are our own, right?)
 612015-11-15T04:11:14  <CodeShark_> are you referring to https://www.cvedetails.com/cve/CVE-2015-8126/ ?
 622015-11-15T04:11:45  <gmaxwell> yes, not a risk for us but we'll probably get asked to update when people notice bitcoin-qt links it.
 632015-11-15T04:12:19  <CodeShark_> we don't use libpng with any user or network supplied data directly, do we?
 642015-11-15T04:13:32  <gmaxwell> FWIW, I've unsubscribed from bitcoin-dev mailing list.
 652015-11-15T04:14:46  <Luke-Jr> sigh
 662015-11-15T04:15:36  <gmaxwell> Luke-Jr: no biggie, it's just still very low SNR.
 672015-11-15T04:18:28  <CodeShark_> oh well...I guess the value of the list tanks even further
 682015-11-15T04:28:17  *** PRab has joined #bitcoin-core-dev
 692015-11-15T04:42:30  *** d_t has joined #bitcoin-core-dev
 702015-11-15T04:45:12  *** lecusemble has quit IRC
 712015-11-15T04:45:12  *** guruvan has quit IRC
 722015-11-15T04:45:49  *** baldur has quit IRC
 732015-11-15T04:45:51  *** gavinandresen has quit IRC
 742015-11-15T04:46:37  *** gavinandresen has joined #bitcoin-core-dev
 752015-11-15T04:46:55  *** lecusemble has joined #bitcoin-core-dev
 762015-11-15T04:48:00  *** PaulCape_ has joined #bitcoin-core-dev
 772015-11-15T04:50:29  *** PaulCapestany has quit IRC
 782015-11-15T04:52:04  *** guruvan has joined #bitcoin-core-dev
 792015-11-15T04:59:10  *** baldur has joined #bitcoin-core-dev
 802015-11-15T05:13:45  <Luke-Jr> FWIW, I figured out why the CLTV tests failed on 0.11.2: https://github.com/bitcoin/bitcoin/pull/6523#issuecomment-156782660
 812015-11-15T05:14:24  <Luke-Jr> (Nothing to worry about)
 822015-11-15T05:26:37  <gmaxwell> Luke-Jr: I think your request translates to "please don't write software in python" :)
 832015-11-15T05:27:08  <Luke-Jr> gmaxwell: well, C++ has most of the same problems in this regard, and the same solutions work in Python
 842015-11-15T05:27:23  <Luke-Jr> (eg, renaming the function)
 852015-11-15T05:27:39  <kanzure> not sure python is the cause of the problem here. taking same value type but treating differently seems like sort of thing you would catch while grepping for the callers, or checking whether your function previously had different meaning..
 862015-11-15T05:27:49  <Luke-Jr> actually, Python has an additional option: it could be made to reject unnamed parameters, so the caller must explicitly specify height=N
 872015-11-15T05:28:09  <Luke-Jr> kanzure: in this case, it was breaking a backport
 882015-11-15T05:28:52  <Luke-Jr> kanzure: CLTV tests were written *after* this change, and when I went to use them with 0.11.2, it silently behaved differently
 892015-11-15T05:29:19  <kanzure> was there a test failure that caught this?
 902015-11-15T05:30:18  <Luke-Jr> the test failed as a result
 912015-11-15T05:32:02  * Luke-Jr wonders if he's the only one who tried to run the CLTV tests against 0.11  :x
 922015-11-15T06:06:35  *** Guest25458 has quit IRC
 932015-11-15T06:07:40  *** pigeons has joined #bitcoin-core-dev
 942015-11-15T06:08:03  *** pigeons is now known as Guest95455
 952015-11-15T06:10:15  *** zooko has quit IRC
 962015-11-15T07:41:38  *** Thireus has joined #bitcoin-core-dev
 972015-11-15T07:48:07  *** Thireus has quit IRC
 982015-11-15T07:48:28  *** Thireus has joined #bitcoin-core-dev
 992015-11-15T08:03:38  *** Thireus has quit IRC
1002015-11-15T08:03:59  *** Thireus has joined #bitcoin-core-dev
1012015-11-15T08:06:20  *** Thireus has quit IRC
1022015-11-15T08:06:41  *** Thireus has joined #bitcoin-core-dev
1032015-11-15T08:08:09  *** Thireus has joined #bitcoin-core-dev
1042015-11-15T08:13:29  *** Thireus has quit IRC
1052015-11-15T08:13:49  *** Thireus has joined #bitcoin-core-dev
1062015-11-15T08:37:10  *** Ylbam has joined #bitcoin-core-dev
1072015-11-15T08:44:53  *** Thireus has quit IRC
1082015-11-15T08:45:12  *** Thireus has joined #bitcoin-core-dev
1092015-11-15T08:53:23  *** Guyver2 has joined #bitcoin-core-dev
1102015-11-15T09:07:13  *** ParadoxSpiral has joined #bitcoin-core-dev
1112015-11-15T09:23:44  *** Guyver2 has quit IRC
1122015-11-15T09:54:15  *** d_t has quit IRC
1132015-11-15T10:36:43  *** ParadoxSpiral has quit IRC
1142015-11-15T11:04:28  *** jtimon has joined #bitcoin-core-dev
1152015-11-15T11:06:11  *** jtimon has quit IRC
1162015-11-15T12:27:24  *** CodeShark_ has quit IRC
1172015-11-15T12:50:29  *** Squidicc has joined #bitcoin-core-dev
1182015-11-15T12:52:56  *** Squidicuz has quit IRC
1192015-11-15T13:44:08  *** jtimon has joined #bitcoin-core-dev
1202015-11-15T14:04:33  <morcos> Luke-Jr: oh interesting. i thought i'd run all the RPC tests, but hadn't noticed that the CLTV tests were not added to the extended tests list.  we should probably add them.
1212015-11-15T14:04:45  <morcos> (for 0.11 that is)
1222015-11-15T14:42:20  *** bsm117532 has joined #bitcoin-core-dev
1232015-11-15T14:51:32  *** jl2012_ has quit IRC
1242015-11-15T14:52:04  *** jl2012 has joined #bitcoin-core-dev
1252015-11-15T14:56:51  *** zooko has joined #bitcoin-core-dev
1262015-11-15T15:01:07  *** Thireus has quit IRC
1272015-11-15T15:01:28  *** Thireus has joined #bitcoin-core-dev
1282015-11-15T15:57:50  *** MarcoFalke has joined #bitcoin-core-dev
1292015-11-15T16:24:50  *** zooko has quit IRC
1302015-11-15T16:35:54  *** JackH has joined #bitcoin-core-dev
1312015-11-15T18:21:16  *** d_t has joined #bitcoin-core-dev
1322015-11-15T18:22:00  *** d_t has joined #bitcoin-core-dev
1332015-11-15T18:36:25  *** arubi has joined #bitcoin-core-dev
1342015-11-15T18:53:17  *** ParadoxSpiral has joined #bitcoin-core-dev
1352015-11-15T19:31:47  *** MarcoFalke has quit IRC
1362015-11-15T19:34:59  *** Thireus1 has joined #bitcoin-core-dev
1372015-11-15T19:35:02  *** Thireus has quit IRC
1382015-11-15T19:44:46  *** evoskuil has quit IRC
1392015-11-15T20:08:15  *** Guyver2 has joined #bitcoin-core-dev
1402015-11-15T20:09:13  <morcos> oh heh, that really is annoying.  turns out this was already broken once in the opposite direction, and sdaftuar fixed it in master 3 weeks ago.
1412015-11-15T20:10:07  <morcos> but Luke-Jr the version of the cltv rpc test in 0.11 should work with 0.11?  did you manually run the new one against it instead of the one in the branch/tag
1422015-11-15T20:11:35  <Luke-Jr> morcos: IIRC I was backporting a newer test
1432015-11-15T20:12:25  *** d_t has quit IRC
1442015-11-15T20:12:58  <morcos> well either way, at least as of now, the version in 0.11 has the old meaning of the arguments and works, and the version in master has the new meaning and works.
1452015-11-15T20:22:28  <morcos> Oh so I think I was confused.  sendFreeTransactions is defaulted off for both QT and bitcoind?  those damn QT config settings always confuse me.
1462015-11-15T20:31:35  *** jgarzik has quit IRC
1472015-11-15T20:33:19  *** jgarzik has joined #bitcoin-core-dev
1482015-11-15T20:33:34  *** jgarzik has joined #bitcoin-core-dev
1492015-11-15T20:53:28  *** d_t has joined #bitcoin-core-dev
1502015-11-15T21:03:56  <GitHub64> [bitcoin] morcos opened pull request #7021: add bip65 tests to rpc-tests.sh -extended (in 0.11 branch) (0.11...11rpcfixups) https://github.com/bitcoin/bitcoin/pull/7021
1512015-11-15T21:10:27  <GitHub84> [bitcoin] morcos opened pull request #7022: Change default block priority size to 0 (master...defaultPrioritySize) https://github.com/bitcoin/bitcoin/pull/7022
1522015-11-15T21:14:28  *** evoskuil has joined #bitcoin-core-dev
1532015-11-15T21:17:11  <BlueMatt> gmaxwell: heh, funny, I hadnt even read scrollback and did a similar calculation for the relay network:
1542015-11-15T21:17:18  <BlueMatt> if you model the relay network as a pipe from the first node to receive any given block to the last node which will receive that block, it has an effective throughput of ~512kbps in the best case
1552015-11-15T21:17:21  <BlueMatt> so thats about right
1562015-11-15T22:22:29  *** ParadoxSpiral has quit IRC
1572015-11-15T22:38:03  *** jtimon has quit IRC
1582015-11-15T22:50:09  *** paveljanik has quit IRC
1592015-11-15T22:54:57  *** Guyver2 has quit IRC
1602015-11-15T23:09:49  *** CodeShark_ has joined #bitcoin-core-dev
1612015-11-15T23:17:40  *** d_t has quit IRC
1622015-11-15T23:34:37  *** d4de has quit IRC
1632015-11-15T23:40:08  *** PaulCape_ has quit IRC
1642015-11-15T23:41:59  *** PaulCapestany has joined #bitcoin-core-dev
1652015-11-15T23:55:25  *** randy-waterhouse has joined #bitcoin-core-dev