📅 Original date posted:2015-05-06
📝 Original message:On Wed, May 06, 2015 at 11:41:37PM +0000, Matt Corallo wrote:
> Yes, but this does NOT make an actual policy. Note that the vast
> majority of miners already apply their own patches to Bitcoin Core, so
> applying one more is not all that hard. When blocks start to become
> limited (ie there is any fee left on the table by transactions not
> included in a block) there becomes incentive for miners to change that
> behavior pretty quick. Not just that, the vast majority of the hashpower
> is behind very large miners, who have little to no decentralization
> pressure. This results in very incompatible incentives, mainly that the
> incentive would be for the large miners to interconnect in a private
> network and generate only maximum-size blocks, creating a strong
> centralization pressure in the network.
I'll also point out that miners with the goal of finding more blocks
than their competition - a viable long-term strategy to increase market
share and/or a short-term strategy to get more transaction fees -
actually have a perverse incentive(1) to ensure their blocks do *not*
get to more than ~30% of the hashing power. The main thing holding them
back from doing that is that the inflation subsidy is still quite high -
better to get the reward now than try to push your competition out of
business.
It's plausible that with a limited blocksize there won't be an
opportunity to delay propagation by broadcasting larger blocks - if
blocks propagate in a matter of seconds worst case there's no
opportunity for gaming the system. But it does strongly show that we
must build systems where that worst case propagation time in all
circumstances is very short relative to the block interval.
1) http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03200.html
--
'peter'[:-1]@petertodd.org
000000000000000004dc867e4541315090329f45ed4dd30e2fd7423a38a72c0e
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150506/1e8954f8/attachment.sig>;
Peter Todd [ARCHIVE] /
npub1m2…a2np2
2023-06-07 15:33:02
in reply to nevent1q…pxwu
Author Public Key
npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2Published at
2023-06-07 15:33:02Event JSON
{
"id": "6d65f5bc2a0027f58ea7471dd71e191da1f512bee66f61eb5e175ee217425333",
"pubkey": "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa",
"created_at": 1686151982,
"kind": 1,
"tags": [
[
"e",
"0def597b074aa190bf159e12f9433ea74d157ee52321b38d195ba644ad5c177f",
"",
"root"
],
[
"e",
"9b837473a54f7db32d64a977e85d1d0c07983daa818fef57ae990235087682ec",
"",
"reply"
],
[
"p",
"cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba"
]
],
"content": "📅 Original date posted:2015-05-06\n📝 Original message:On Wed, May 06, 2015 at 11:41:37PM +0000, Matt Corallo wrote:\n\u003e Yes, but this does NOT make an actual policy. Note that the vast\n\u003e majority of miners already apply their own patches to Bitcoin Core, so\n\u003e applying one more is not all that hard. When blocks start to become\n\u003e limited (ie there is any fee left on the table by transactions not\n\u003e included in a block) there becomes incentive for miners to change that\n\u003e behavior pretty quick. Not just that, the vast majority of the hashpower\n\u003e is behind very large miners, who have little to no decentralization\n\u003e pressure. This results in very incompatible incentives, mainly that the\n\u003e incentive would be for the large miners to interconnect in a private\n\u003e network and generate only maximum-size blocks, creating a strong\n\u003e centralization pressure in the network.\n\nI'll also point out that miners with the goal of finding more blocks\nthan their competition - a viable long-term strategy to increase market\nshare and/or a short-term strategy to get more transaction fees -\nactually have a perverse incentive(1) to ensure their blocks do *not*\nget to more than ~30% of the hashing power. The main thing holding them\nback from doing that is that the inflation subsidy is still quite high -\nbetter to get the reward now than try to push your competition out of\nbusiness.\n\nIt's plausible that with a limited blocksize there won't be an\nopportunity to delay propagation by broadcasting larger blocks - if\nblocks propagate in a matter of seconds worst case there's no\nopportunity for gaming the system. But it does strongly show that we\nmust build systems where that worst case propagation time in all\ncircumstances is very short relative to the block interval.\n\n1) http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03200.html\n\n-- \n'peter'[:-1]@petertodd.org\n000000000000000004dc867e4541315090329f45ed4dd30e2fd7423a38a72c0e\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 650 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150506/1e8954f8/attachment.sig\u003e",
"sig": "c8d90ecd12bcb9afb0f2e03a5a89d5a7c75132439fd4f8e696c0ad02388f6775e8c48ea69aa50c2b07c513759cb914fcb2a08d4202b0dcf6946763589783ba4d"
}