Gavin Andresen [ARCHIVE] on Nostr: š Original date posted:2014-10-28 š Original message:On Tue, Oct 28, 2014 at ...
š
Original date posted:2014-10-28
š Original message:On Tue, Oct 28, 2014 at 10:30 AM, Alex Morcos <morcos at 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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141028/a346b252/attachment.html>
š Original message:On Tue, Oct 28, 2014 at 10:30 AM, Alex Morcos <morcos at 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
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141028/a346b252/attachment.html>