< 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
< 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.
< jgarzik>
cool
< gmaxwell>
oh yea you weren't there when I presented on this.
< 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.
< gmaxwell>
Model that R comes up with for that is:
< gmaxwell>
which means a 2.491 second constant delay, plus 732kbit/sec. (1/1.106*10^-5*8)
< 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.
< 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.
< gmaxwell>
so, take with a metric ton of salt, but I thought it was interesting that these figures are in roughly this magnitude.
< jgarzik>
definitely interesting. mostly aligns with my guesstimation of miner+network behavior.
< 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.
< sipa>
to reach half the pools... weighted by hashrate?
< gmaxwell>
yea, not weighed; thats what I was trying to talk about with my "not that simple"
< sipa>
right
< sipa>
hard to do with data that spans several months
< gmaxwell>
because of that the information is a bit more informative about equality/fairness than it is about the economics of fees.
< 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.
< 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. :)
< 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.
< 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.
< zooko>
I really think you are right that it is a user-experience issue, not an economic issue.
< 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,
< zooko>
I think that would be a stinkier.
< zooko>
a stinker.
< zooko>
I mean, nobody would play.
< 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.
< jgarzik>
...maybe this is -wizards material ;p
< 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 ....
< zooko>
WRONG CHAMN
< zooko>
Thanks, jg.
< sipa>
that's a contraction of "wrong chan" and "damn" ?
< 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 :)
< 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
< sipa>
then you could buy a range of hashes from a miner
< GitHub184>
[bitcoin] morcos opened pull request #7020: Implement helper class for CTxMemPoolEntry constructor (master...EntryHelper) https://github.com/bitcoin/bitcoin/pull/7020
< Luke-Jr>
sipa: is there a purpose for such a construct?
< gmaxwell>
::sigh:: libpng security firedrill.
< Luke-Jr>
was there a real risk for us?
< Luke-Jr>
(only PNGs we ever use are our own, right?)
< gmaxwell>
Luke-Jr: I think your request translates to "please don't write software in python" :)
< Luke-Jr>
gmaxwell: well, C++ has most of the same problems in this regard, and the same solutions work in Python
< Luke-Jr>
(eg, renaming the function)
< 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..
< Luke-Jr>
actually, Python has an additional option: it could be made to reject unnamed parameters, so the caller must explicitly specify height=N
< Luke-Jr>
kanzure: in this case, it was breaking a backport
< 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
< kanzure>
was there a test failure that caught this?
< Luke-Jr>
the test failed as a result
< * Luke-Jr>
wonders if he's the only one who tried to run the CLTV tests against 0.11 :x
< 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.
< morcos>
(for 0.11 that is)
< 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.
< 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
< Luke-Jr>
morcos: IIRC I was backporting a newer test
< 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.
< 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.
< 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
< BlueMatt>
gmaxwell: heh, funny, I hadnt even read scrollback and did a similar calculation for the relay network:
< 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