rich1.0npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2njumphttps://nostr.ae📅 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>