{"type":"rich","version":"1.0","author_name":"npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kw","author_url":"https://nostr.ae/npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kw","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-05-09\n📝 Original message:RE: fixing sigop counting, and building in UTXO cost: great idea! One of\nthe problems with this debate is it is easy for great ideas get lost in all\nthe noise.\n\nRE: a hard upper limit, with a dynamic limit under it:\n\nI like that idea. Can we drill down on the hard upper limit?\n\nThere are lots of people who want a very high upper limit, right now (all\nthe big Bitcoin companies, and anybody who thinks as-rapid-as-possible\ngrowth now is the best path to long-term success). This is the \"it is OK if\nyou have to run full nodes in a data center\" camp.\n\nThere are also lots of people who want an upper limit low enough that they\ncan continue to run Bitcoin on the hardware and Internet connection that\nthey have (or are concerned about centralization, so want to make sure\nOTHER people can continue to run....).\n\nIs there an upper limit \"we\" can choose to make both sets of people mostly\nhappy? I've proposed \"must be inexpensive enough that a 'hobbyist' can\nafford to run a full node\" ...\n\nIs the limit chosen once, now, via hard-fork, or should we expect multiple\nhard-forks to change it \"when necessary\" ?\n\nThe economics change every time the block reward halves, which make me\nthink that might be a good time to adjust the hard upper limit. If we have\na hard upper limit and a lower dynamic limit, perhaps adjusting the hard\nupper limit (up or down) to account for the block reward halving, based on\nthe dynamic limit....\n\n\n\nRE: the lower dynamic limit algorithm:  I REALLY like that idea.\n\n-- \n--\nGavin Andresen\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150509/e371ad58/attachment.html\u003e"}