Ryan Butler [ARCHIVE] on Nostr: 📅 Original date posted:2015-07-30 📝 Original message:I shouldn't have said ...
📅 Original date posted:2015-07-30
📝 Original message:I shouldn't have said unlimited, i should have said a greater blocksize
limit such as 8mb.
Anyways, why is that the assumption? If a miner can do so, and do so
profitably, isn't that just competition? Isn't that what we want? If a
miner can mine low transaction fees at a profit then don't they deserve to
have their spot? Surely if they do so unprofitably they quickly find
themselves out of business? Besides, if a miner mines low fee transactions
by breaking rank, how does this affect another miner EXCEPT for the
additional blocksize load. I would maintain this is just competition
amongst miners gentlemen. And it's a good thing.
Right now things are distorted because most income comes from the coinbase,
but as transaction fees start to constitute the majority of income this
idea seems to have more importance.
On Jul 29, 2015 11:00 PM, "Adam Back" <adam at cypherspace.org> wrote:
> On 29 July 2015 at 20:41, Ryan Butler via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Does an unlimited blocksize imply the lack of a fee market? Isn't every
> > miner able to set their minimum accepted fee or transaction acceptance
> > algorithm?
>
> The assumption is that wont work because any miner can break ranks and
> do so profitably, so to expect otherwise is to expect oligopoly
> behaviour which is the sort of antithesis of a decentralised mining
> system. It's in fact a similar argument as to why decentralisation of
> mining provides policy neutrality: some miner somewhere with some
> hashrate will process your transaction even if some other miners are
> by policy deciding not to mine it. It is also similar reason why free
> transactions are processed today - policies vary and this is good for
> ensuring many types of transaction get processed.
>
> Adam
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150729/f665c813/attachment-0001.html>;
📝 Original message:I shouldn't have said unlimited, i should have said a greater blocksize
limit such as 8mb.
Anyways, why is that the assumption? If a miner can do so, and do so
profitably, isn't that just competition? Isn't that what we want? If a
miner can mine low transaction fees at a profit then don't they deserve to
have their spot? Surely if they do so unprofitably they quickly find
themselves out of business? Besides, if a miner mines low fee transactions
by breaking rank, how does this affect another miner EXCEPT for the
additional blocksize load. I would maintain this is just competition
amongst miners gentlemen. And it's a good thing.
Right now things are distorted because most income comes from the coinbase,
but as transaction fees start to constitute the majority of income this
idea seems to have more importance.
On Jul 29, 2015 11:00 PM, "Adam Back" <adam at cypherspace.org> wrote:
> On 29 July 2015 at 20:41, Ryan Butler via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Does an unlimited blocksize imply the lack of a fee market? Isn't every
> > miner able to set their minimum accepted fee or transaction acceptance
> > algorithm?
>
> The assumption is that wont work because any miner can break ranks and
> do so profitably, so to expect otherwise is to expect oligopoly
> behaviour which is the sort of antithesis of a decentralised mining
> system. It's in fact a similar argument as to why decentralisation of
> mining provides policy neutrality: some miner somewhere with some
> hashrate will process your transaction even if some other miners are
> by policy deciding not to mine it. It is also similar reason why free
> transactions are processed today - policies vary and this is good for
> ensuring many types of transaction get processed.
>
> Adam
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150729/f665c813/attachment-0001.html>;