Re: [Bitcoin-development] Reworking the policy estimation code (fee estimates)

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. Fo

Re: [Bitcoin-development] Reworking the policy estimation code (fee estimates)

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

Re: [Bitcoin-development] Reworking the policy estimation code (fee estimates)

On Tue, Oct 28, 2014 at 10:30 AM, Alex Morcos 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 > require any code

Re: [Bitcoin-development] Reworking the policy estimation code (fee estimates)

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 to

Re: [Bitcoin-development] Reworking the policy estimation code (fee estimates)

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 not

Re: [Bitcoin-development] Reworking the policy estimation code (fee estimates)

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

Re: [Bitcoin-development] Reworking the policy estimation code (fee estimates)

Yeah, so to explain points 1 and 2 a bit more 1) It's about what question you are trying to answer. The existing code tries to answer the question of what is the median fee of a transaction that gets confirmed in Y blocks. It turns out that is not a very good proxy for the question we really wa

Re: [Bitcoin-development] Reworking the policy estimation code (fee estimates)

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 Ja

[Bitcoin-development] Reworking the policy estimation code (fee estimates)

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