📅 Original date posted:2022-07-10
📝 Original message:> We want mining to be is a boring, predictable, business that anyone can do, with as little reward as possible to larger scale miners.
To reach that, miners should earn their block rewards inside Lightning Network. Then, if you want to send some transaction, and you have one satoshi fee, you can produce a Bitcoin block on your CPU, and get a discount on your fee for doing that. Imagine mining a block with difficulty one, and getting some millisatoshis, or even microsatoshis as a reward. Then, to bootstrap that system, it could at first accept any blocks, so existing miners could redirect their shares to such network, then a pool will be able to claim those rewards. And then, when miners will see that the system works as intended, they could switch to solo mining, to get their rewards directly to their addresses.
On 2022-07-10 19:27:28 user Peter Todd via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Sat, Jul 09, 2022 at 09:59:06PM +0000, ZmnSCPxj wrote:
> Good morning e, and list,
>
> > Yet you posted several links which made that specific correlation, to which I was responding.
> >
> > Math cannot prove how much coin is “lost”, and even if it was provable that the amount of coin lost converges to the amount produced, it is of no consequence - for the reasons I’ve already pointed out. The amount of market production has no impact on market price, just as it does not with any other good.
> >
> > The reason to object to perpetual issuance is the impact on censorship resistance, not on price.
>
> To clarify about censorship resistance and perpetual issuance ("tail emission"):
>
> * Suppose I have two blockchains, one with a constant block subsidy, and one which *had* a block subsidy but the block subsidy has become negligible or zero.
> * Now consider a censoring miner.
> * If the miner rejects particular transactions (i.e. "censors") the miner loses out on the fees of those transactions.
> * Presumably, the miner does this because it gains other benefits from the censorship, economically equal or better to the earnings lost.
> * If the blockchain had a block subsidy, then the loss the miner incurs is small relative to the total earnings of each block.
> * If the blockchain had 0 block subsidy, then the loss the miner incurs is large relative to the total earnings of each block.
> * Thus, in the latter situation, the external benefit the miner gains from the censorship has to be proportionately larger than in the first situation.
Now let's look at an actual, real-world, attempt to censor Bitcoin via mining:
https://petertodd.org/2016/mit-chainanchor-bribing-miners-to-regulate-bitcoin
The Chain Anchor model was to simply straight up bribe and coerce miners into
only accepting compliant transactions. That's only effective when a large % of
miners actually do that - if a small % do the effect on confirmation time is
miniscule. Obviously, censoring transactions is a significant threat to the
value of Bitcoin - and thus all your Bitcoin-only hashing equipment.
So how do you make a Chain Anchor attack cheaper? By reducing total mining
reward, and making it tied to transaction volume rather than the value of
Bitcoin as a whole.
> Basically, the block subsidy is a market distortion: the block subsidy erodes the value of held coins to pay for the security of coins being moved.
The block subsidy directly ties miner revenue to the total value of Bitcoin:
that's exactly how you want to incentivise a service that keeps Bitcoin secure.
> But the block subsidy is still issued whether or not coins being moved are censored or not censored.
> Thus, there is no incentive, considering *only* the block subsidy, to not censor coin movements.
> Only per-transaction fees have an incentive to not censor coin movements.
The strongest incentive not to censor is because it'll keep Bitcoin valuable.
Not some piddling transaction fees.
> Thus, we should instead prepare for a future where the block subsidy *must* be removed, possibly before the existing schedule removes it, in case a majority coalition of miner ever decides to censor particular transactions without community consensus.
> Fortunately forcing the block subsidy to 0 is a softfork and thus easier to deploy.
Absolutely not.
The historical reality of transaction fees is they've had huge swings, about
10x more volatile than total miner revenue. In the past three years they've
ranged from $8.4 million USD/30-day-average to as little as $140k/30-day-avg,
with the current amount being $370k/30-day-avg. That's a 60x difference.
Meanwhile miner revenue has ranged from $60 million/30-day-avg to $9
million/30-day-avg, a 7x difference.
https://www.blockchain.com/charts/fees-usd-per-transaction
We want mining to be is a boring, predictable, business that anyone can do,
with as little reward as possible to larger scale miners. That's what you need
for maximal decentralization. Making mining a sophisticated business reduces
the pool of entities that can profitably compete in it, and increases their
visibility to government regulation.
Additionally, we want mining to be predictable to avoid having large gluts of
unprofitable mining equipment laying around: mining equipment that could be
used to attack Bitcoin. Fee revenue is obviously doing a much worse job of
achieving that goal than subsidy revenue.
If transaction-fee-only mining was such a good idea, why hasn't any other coin
done it?
--
https://petertodd.org 'peter'[:-1]@petertodd.org
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
vjudeu at gazeta.pl [ARCHIVE] /
npub135…nssga
2023-06-07 23:11:28
in reply to nevent1q…wdk3
Author Public Key
npub1357006afyypkgz03lmq8fnuvlkyjt0rukx8rt56ck8xv396jaceqmnssgaPublished at
2023-06-07 23:11:28Event JSON
{
"id": "2e2e540fda73e9ddde78a730e2ed9a0e393e533c309a66f1d92c3c90132b20f0",
"pubkey": "8d3cf7eba921036409f1fec074cf8cfd8925bc7cb18e35d358b1ccc89752ee32",
"created_at": 1686179488,
"kind": 1,
"tags": [
[
"e",
"58ba5412c6c2b5602710ac2f4e1819c2f92facaa3c9fa557b2ad25c78b5dd662",
"",
"root"
],
[
"e",
"2ced2325a53478e311ccff748794909de0dc334cbfc170c0b0956619f26bcdc3",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2022-07-10\n📝 Original message:\u003e We want mining to be is a boring, predictable, business that anyone can do, with as little reward as possible to larger scale miners.\n\nTo reach that, miners should earn their block rewards inside Lightning Network. Then, if you want to send some transaction, and you have one satoshi fee, you can produce a Bitcoin block on your CPU, and get a discount on your fee for doing that. Imagine mining a block with difficulty one, and getting some millisatoshis, or even microsatoshis as a reward. Then, to bootstrap that system, it could at first accept any blocks, so existing miners could redirect their shares to such network, then a pool will be able to claim those rewards. And then, when miners will see that the system works as intended, they could switch to solo mining, to get their rewards directly to their addresses.\n\nOn 2022-07-10 19:27:28 user Peter Todd via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e On Sat, Jul 09, 2022 at 09:59:06PM +0000, ZmnSCPxj wrote:\n\u003e Good morning e, and list,\n\u003e \n\u003e \u003e Yet you posted several links which made that specific correlation, to which I was responding.\n\u003e \u003e\n\u003e \u003e Math cannot prove how much coin is “lost”, and even if it was provable that the amount of coin lost converges to the amount produced, it is of no consequence - for the reasons I’ve already pointed out. The amount of market production has no impact on market price, just as it does not with any other good.\n\u003e \u003e\n\u003e \u003e The reason to object to perpetual issuance is the impact on censorship resistance, not on price.\n\u003e \n\u003e To clarify about censorship resistance and perpetual issuance (\"tail emission\"):\n\u003e \n\u003e * Suppose I have two blockchains, one with a constant block subsidy, and one which *had* a block subsidy but the block subsidy has become negligible or zero.\n\u003e * Now consider a censoring miner.\n\u003e * If the miner rejects particular transactions (i.e. \"censors\") the miner loses out on the fees of those transactions.\n\u003e * Presumably, the miner does this because it gains other benefits from the censorship, economically equal or better to the earnings lost.\n\u003e * If the blockchain had a block subsidy, then the loss the miner incurs is small relative to the total earnings of each block.\n\u003e * If the blockchain had 0 block subsidy, then the loss the miner incurs is large relative to the total earnings of each block.\n\u003e * Thus, in the latter situation, the external benefit the miner gains from the censorship has to be proportionately larger than in the first situation.\n\nNow let's look at an actual, real-world, attempt to censor Bitcoin via mining:\n\nhttps://petertodd.org/2016/mit-chainanchor-bribing-miners-to-regulate-bitcoin\n\nThe Chain Anchor model was to simply straight up bribe and coerce miners into\nonly accepting compliant transactions. That's only effective when a large % of\nminers actually do that - if a small % do the effect on confirmation time is\nminiscule. Obviously, censoring transactions is a significant threat to the\nvalue of Bitcoin - and thus all your Bitcoin-only hashing equipment.\n\nSo how do you make a Chain Anchor attack cheaper? By reducing total mining\nreward, and making it tied to transaction volume rather than the value of\nBitcoin as a whole.\n\n\u003e Basically, the block subsidy is a market distortion: the block subsidy erodes the value of held coins to pay for the security of coins being moved.\n\nThe block subsidy directly ties miner revenue to the total value of Bitcoin:\nthat's exactly how you want to incentivise a service that keeps Bitcoin secure.\n\n\u003e But the block subsidy is still issued whether or not coins being moved are censored or not censored.\n\u003e Thus, there is no incentive, considering *only* the block subsidy, to not censor coin movements.\n\u003e Only per-transaction fees have an incentive to not censor coin movements.\n\nThe strongest incentive not to censor is because it'll keep Bitcoin valuable.\nNot some piddling transaction fees.\n\n\u003e Thus, we should instead prepare for a future where the block subsidy *must* be removed, possibly before the existing schedule removes it, in case a majority coalition of miner ever decides to censor particular transactions without community consensus.\n\u003e Fortunately forcing the block subsidy to 0 is a softfork and thus easier to deploy.\n\nAbsolutely not.\n\nThe historical reality of transaction fees is they've had huge swings, about\n10x more volatile than total miner revenue. In the past three years they've\nranged from $8.4 million USD/30-day-average to as little as $140k/30-day-avg,\nwith the current amount being $370k/30-day-avg. That's a 60x difference.\n\nMeanwhile miner revenue has ranged from $60 million/30-day-avg to $9\nmillion/30-day-avg, a 7x difference.\n\nhttps://www.blockchain.com/charts/fees-usd-per-transaction\n\nWe want mining to be is a boring, predictable, business that anyone can do,\nwith as little reward as possible to larger scale miners. That's what you need\nfor maximal decentralization. Making mining a sophisticated business reduces\nthe pool of entities that can profitably compete in it, and increases their\nvisibility to government regulation.\n\nAdditionally, we want mining to be predictable to avoid having large gluts of\nunprofitable mining equipment laying around: mining equipment that could be\nused to attack Bitcoin. Fee revenue is obviously doing a much worse job of\nachieving that goal than subsidy revenue.\n\n\nIf transaction-fee-only mining was such a good idea, why hasn't any other coin\ndone it?\n\n-- \nhttps://petertodd.org 'peter'[:-1]@petertodd.org\n_______________________________________________\nbitcoin-dev mailing list\nbitcoin-dev at lists.linuxfoundation.org\nhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev",
"sig": "2c95b2a751b7c691ca59ea0110f45e07415b0295b9e028f8467bc766102acee4d5ffee87268d394fcaf1f7c4dd7f5083dae52b0310fe7a7b2d9ba7abedf6c611"
}