On Mon, Oct 27, 2014 at 03:33:45PM -0400, Alex Morcos wrote:
I've been playing around with the code for estimating fees and found a few
issues with the existing code. I think this will address several
observations that the estimates returned by the existing code appear to be
too high. For
Could you explain a little further why you think the current approach is
statistically incorrect? There's no doubt that the existing estimates the
system produces are garbage, but that's because it assumes players in the
fee market are rational and they are not.
Fwiw bitcoinj 0.12.1 applies the
I think Alex's approach is better; I don't think we can know how much
better until we have a functioning fee market.
We don't have a functioning fee market now, because fees are hard-coded. So
we get pay the hard-coded fee and you'll get confirmed in one or two or
three blocks, depending on which
Oh in just a couple of blocks, it'll give you a somewhat reasonable
estimate for asking about every confirmation count other than 1, but it
could take several hours for it to have enough data points to give you a
good estimate for getting confirmed in one block (because the prevalent
feerate is
Sorry, perhaps I misinterpreted that question. The estimates will be
dominated by the prevailing transaction rates initially, so the estimates
you get for something like what is the least I can pay and still be 90%
sure I get confirmed in 20 blocks won't be insane, but they will still be
way too
On Tue, Oct 28, 2014 at 10:30 AM, Alex Morcos mor...@gmail.com wrote:
Do you think it would make sense to make that 90% number an argument to
rpc call? For instance there could be a default (I would use 80%) but then
you could specify if you required a different certainty. It wouldn't
RE: 90% : I think it's fine to use 90% for anything other than 1
confirmation, but if you look at the real world data test I did, or the raw
data from this new code, you'll see that even the highest fee rate
transactions only get confirmed at about a 90% rate in 1 block, so that if
you use that as
I've been playing around with the code for estimating fees and found a few
issues with the existing code. I think this will address several
observations that the estimates returned by the existing code appear to be
too high. For instance see @cozz in Issue 4866
8 matches
Mail list logo
