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 your cut-off you will sometimes get no answer and sometimes get a very high fee rate and sometimes get a reasonable fee rate, it just depends because the data is too noisy. I think thats just because there is no good answer to that question. There is no fee you can put on your transaction to guarantee greater than 90% chance of getting confirmed in one block. I think 85% might be safe? RE: tunable as command-line/bitcoin.conf: sounds good! OK, sorry to have all this conversation on the dev list, maybe i'll turn this into an actual PR if we want to comment on the code? I just wanted to see if it even made sense to make a PR for this or this isn't the way we wanted to go about it. On Tue, Oct 28, 2014 at 10:58 AM, Gavin Andresen wrote: > 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 changes and might make it easier for people to build more >> complicated logic on top of it. >> > > RE: 80% versus 90% : I think a default of 80% will get us a lot of "the > fee estimation logic is broken, I want my transactions to confirm quick and > a lot of them aren't confirming for 2 or 3 blocks." > > RE: RPC argument: I'm reluctant to give too many 'knobs' for the RPC > interface. I think the default percentage makes sense as a > command-line/bitcoin.conf option; I can imagine services that want to save > on fees running with -estimatefeethreshold=0.5 (or > -estimatefeethreshold=0.95 if as-fast-as-possible confirmations are > needed). Setting both the number of confirmations and the estimation > threshold on a transaction-by-transaction basis seems like overkill to me. > > -- > -- > Gavin Andresen >