Anthony Towns [ARCHIVE] on Nostr: đź“… Original date posted:2015-08-07 đź“ť Original message:On 8 August 2015 at 00:57, ...
đź“… Original date posted:2015-08-07
đź“ť Original message:On 8 August 2015 at 00:57, Gavin Andresen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I answered:
>
>> > 1. If you are willing to wait an infinite amount of time, I think the
>> > minimum fee will always be zero or very close to zero, so I think it's a
>> > silly question.
>
> That's not what I'm thinking. It is just an observation based on the fact
> that blocks are found at random intervals.
>
Every once in a while the network will get lucky and we'll find six blocks
> in ten minutes. If you are deciding what transaction fee to put on your
> transaction, and you're willing to wait until that
> six-blocks-in-ten-minutes once-a-week event, submit your transaction with a
> low fee.
>
All the higher-fee transactions waiting to be confirmed will get confirmed
> in the first five blocks and, if miners don't have any floor on the fee
> they'll accept (they will, but lets pretend they won't) then your
> very-low-fee transaction will get confirmed.
>
​That depends a bit on how ra​tional miners are, doesn't it? Once the block
subsidy is retired, hashpower is only paid for by fees -- and if there's no
fee paying transactions in the queue, then there's no reward for applying
hashpower, so mining a block won't even pay for your costs. In that case,
better to switch to hatching something else (an altcoin with less fees than
bitcoin has on average but more than nothing, eg), or put your hashing
hardward into a low power mode so you at least cut costs.
That will only be needed for a short while though -- presumably enough
transactions will come in in the next five or ten minutes for a block to be
worth mining again, so maybe implementing that decision process is more
costly than the money you'd save.
​(C​
onversely, when the queue is over-full because there's been no blocks found
for a while, that should mean you can fill a block with higher-than-average
fee transactions, so I'd expect some miners to switch hashpower from
altcoins and sidechains to catch the temporary chance of higher revenue
blocks.
​Both tendencies would help reduce the variance in block time, compared to
a steady hashrate, which would probably be a good thing for the network as
a whole)​
I think the same incentives apply with mining being paid for by assurance
contracts rather than directly by transaction fees -- if you get a bunch of
blocks done quickly, the existing assurance contracts are dealt with just
as well as if it had taken longer; so you want to wait until new ones come
in rather than spend your hashpower for no return.
​All of this only applies once fees make up a significant portion of the
payment for mining a block, though.​
Cheers,
aj
--
Anthony Towns <aj at erisian.com.au>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150808/44edd617/attachment.html>;
đź“ť Original message:On 8 August 2015 at 00:57, Gavin Andresen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I answered:
>
>> > 1. If you are willing to wait an infinite amount of time, I think the
>> > minimum fee will always be zero or very close to zero, so I think it's a
>> > silly question.
>
> That's not what I'm thinking. It is just an observation based on the fact
> that blocks are found at random intervals.
>
Every once in a while the network will get lucky and we'll find six blocks
> in ten minutes. If you are deciding what transaction fee to put on your
> transaction, and you're willing to wait until that
> six-blocks-in-ten-minutes once-a-week event, submit your transaction with a
> low fee.
>
All the higher-fee transactions waiting to be confirmed will get confirmed
> in the first five blocks and, if miners don't have any floor on the fee
> they'll accept (they will, but lets pretend they won't) then your
> very-low-fee transaction will get confirmed.
>
​That depends a bit on how ra​tional miners are, doesn't it? Once the block
subsidy is retired, hashpower is only paid for by fees -- and if there's no
fee paying transactions in the queue, then there's no reward for applying
hashpower, so mining a block won't even pay for your costs. In that case,
better to switch to hatching something else (an altcoin with less fees than
bitcoin has on average but more than nothing, eg), or put your hashing
hardward into a low power mode so you at least cut costs.
That will only be needed for a short while though -- presumably enough
transactions will come in in the next five or ten minutes for a block to be
worth mining again, so maybe implementing that decision process is more
costly than the money you'd save.
​(C​
onversely, when the queue is over-full because there's been no blocks found
for a while, that should mean you can fill a block with higher-than-average
fee transactions, so I'd expect some miners to switch hashpower from
altcoins and sidechains to catch the temporary chance of higher revenue
blocks.
​Both tendencies would help reduce the variance in block time, compared to
a steady hashrate, which would probably be a good thing for the network as
a whole)​
I think the same incentives apply with mining being paid for by assurance
contracts rather than directly by transaction fees -- if you get a bunch of
blocks done quickly, the existing assurance contracts are dealt with just
as well as if it had taken longer; so you want to wait until new ones come
in rather than spend your hashpower for no return.
​All of this only applies once fees make up a significant portion of the
payment for mining a block, though.​
Cheers,
aj
--
Anthony Towns <aj at erisian.com.au>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150808/44edd617/attachment.html>;