š
Original date posted:2014-10-28
š Original message: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 <gavinandresen at gmail.com>
wrote:
> 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/2ebb0ad7/attachment.html>;
Alex Morcos [ARCHIVE] /
npub10zā¦3xfzw
2023-06-07 15:26:57
in reply to nevent1qā¦9vn4
Author Public Key
npub10z4xjfgftd3fm9dfu7dw6mkemgyhxgumcmhd7yd0ggjq7rsaw4wqa3xfzwPublished at
2023-06-07 15:26:57Event JSON
{
"id": "4e00737035375701d421e3345e0d6ea7be648de437cc034f7dec0a9bad649a7d",
"pubkey": "78aa6925095b629d95a9e79aed6ed9da0973239bc6eedf11af42240f0e1d755c",
"created_at": 1686151617,
"kind": 1,
"tags": [
[
"e",
"22b496210e2e75fac8ac4c7f5586e67f707d43b5b6cd72cb909b95110d85c775",
"",
"root"
],
[
"e",
"73a4d08942196420687d900392fa86ca3052fbcdce0e0ea9559b44848e86afe4",
"",
"reply"
],
[
"p",
"857f2f78dc1639e711f5ea703a9fc978e22ebd279abdea1861b7daa833512ee4"
]
],
"content": "š
Original date posted:2014-10-28\nš Original message:RE: 90% : I think it's fine to use 90% for anything other than 1\nconfirmation, but if you look at the real world data test I did, or the raw\ndata from this new code, you'll see that even the highest fee rate\ntransactions only get confirmed at about a 90% rate in 1 block, so that if\nyou use that as your cut-off you will sometimes get no answer and sometimes\nget a very high fee rate and sometimes get a reasonable fee rate, it just\ndepends because the data is too noisy. I think thats just because there is\nno good answer to that question. There is no fee you can put on your\ntransaction to guarantee greater than 90% chance of getting confirmed in\none block. I think 85% might be safe?\n\nRE: tunable as command-line/bitcoin.conf: sounds good!\n\nOK, sorry to have all this conversation on the dev list, maybe i'll turn\nthis into an actual PR if we want to comment on the code?\nI just wanted to see if it even made sense to make a PR for this or this\nisn't the way we wanted to go about it.\n\n\n\n\nOn Tue, Oct 28, 2014 at 10:58 AM, Gavin Andresen \u003cgavinandresen at gmail.com\u003e\nwrote:\n\n\u003e On Tue, Oct 28, 2014 at 10:30 AM, Alex Morcos \u003cmorcos at gmail.com\u003e wrote:\n\u003e\u003e\n\u003e\u003e Do you think it would make sense to make that 90% number an argument to\n\u003e\u003e rpc call? For instance there could be a default (I would use 80%) but then\n\u003e\u003e you could specify if you required a different certainty. It wouldn't\n\u003e\u003e require any code changes and might make it easier for people to build more\n\u003e\u003e complicated logic on top of it.\n\u003e\u003e\n\u003e\n\u003e RE: 80% versus 90% : I think a default of 80% will get us a lot of \"the\n\u003e fee estimation logic is broken, I want my transactions to confirm quick and\n\u003e a lot of them aren't confirming for 2 or 3 blocks.\"\n\u003e\n\u003e RE: RPC argument: I'm reluctant to give too many 'knobs' for the RPC\n\u003e interface. I think the default percentage makes sense as a\n\u003e command-line/bitcoin.conf option; I can imagine services that want to save\n\u003e on fees running with -estimatefeethreshold=0.5 (or\n\u003e -estimatefeethreshold=0.95 if as-fast-as-possible confirmations are\n\u003e needed). Setting both the number of confirmations and the estimation\n\u003e threshold on a transaction-by-transaction basis seems like overkill to me.\n\u003e\n\u003e --\n\u003e --\n\u003e Gavin Andresen\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141028/2ebb0ad7/attachment.html\u003e",
"sig": "5594d53a945cbd891b667206b2978b45e04463c685ba3b57f0947589d1c3e66c6e831b909bcdea91f9fd680621a4db09cca396223ef3fbf4b294ad0c3c651334"
}