đź“… Original date posted:2015-08-16
đź“ť Original message:On 16 August 2015 at 15:49, Mike Hearn via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Sorry you feel that way. I devoted a big part of the article to trying to
> fairly represent the top 3 arguments made, but ultimately I can't link to a
> clear statement of what Bitcoin Core thinks because there isn't one. Some
> people think the block size should increase, but not now, or not by much.
> Others think it should stay at 1mb forever, others think everyone should
> migrate to Lightning, people who are actually *implementing* Lightning
> think it's not a replacement for an increase ..... I think one or two
> people even suggested shrinking the block size!
>
​That's been really unclear to me. Personally, I'd love to see a vote from
the core and XT developers on:
- what should the block size soft limit be in 12 months (min and max)
- what should the block size hard limit be in 12 months (min and max)
- at what rate should the hard limit grow over the next 10 years​ (min and
max)
- what mechanism should be used to update the soft limit
(manual code change, time based, blockchain history, something else)
​ - what me​chanism should be used to update the hard limit
(hard fork code change, time based, blockchain history, something else)
Bonus:
​ - what should the
​transaction ​
fee level be in 12 months (after the reward halves)?​
- what's a good measure of "(de)centralisation" and what value should
everyone aim for in 12 months?
As an interested newbie, I can't actually tell what most people think the
answers to most of those questions are. FWIW, mine would be:
- soft limit in 12 months: 1MB-4MB
- hard limit in 12 months: 2MB-20MB
- hard limit grows at 17-40% a year (and should be >4x average txn volume)
- update the soft limit by code changes or blockchain history
- update the hardlimit by (1) fee level, (2) miner vote, (3) hard coded
time updates at a conservative (low) rate, (4) hard fork every couple of
years
- transaction fees should in 12months should be lower per kB than today's
defaults, say 20%-50% of today's defaults in USD
- number of bitcoin nodes, should be 20% higher in 12 months than it is now
​Cheers,
aj
--
Anthony Towns <aj at erisian.com.au>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150816/cc92c904/attachment.html>;
Anthony Towns [ARCHIVE] /
npub17r…x9l2h
2023-06-07 15:47:12
in reply to nevent1q…0j97
Author Public Key
npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2hPublished at
2023-06-07 15:47:12Event JSON
{
"id": "95705daa55459e6f7855708931943c69a79e7584af64261b77879f94f229d184",
"pubkey": "f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab",
"created_at": 1686152832,
"kind": 1,
"tags": [
[
"e",
"2f056596a73ada2819a3c6ed27fbcf1ad864d42a414ea6b10e00c7c860550529",
"",
"root"
],
[
"e",
"010af855204a90e79b968e0934e8e7d13910016187a7fdc815ab2ebf72cd475e",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 Original date posted:2015-08-16\n📝 Original message:On 16 August 2015 at 15:49, Mike Hearn via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Sorry you feel that way. I devoted a big part of the article to trying to\n\u003e fairly represent the top 3 arguments made, but ultimately I can't link to a\n\u003e clear statement of what Bitcoin Core thinks because there isn't one. Some\n\u003e people think the block size should increase, but not now, or not by much.\n\u003e Others think it should stay at 1mb forever, others think everyone should\n\u003e migrate to Lightning, people who are actually *implementing* Lightning\n\u003e think it's not a replacement for an increase ..... I think one or two\n\u003e people even suggested shrinking the block size!\n\u003e\n\n​That's been really unclear to me. Personally, I'd love to see a vote from\nthe core and XT developers on:\n\n - what should the block size soft limit be in 12 months (min and max)\n - what should the block size hard limit be in 12 months (min and max)\n\n - at what rate should the hard limit grow over the next 10 years​ (min and\nmax)\n\n - what mechanism should be used to update the soft limit\n (manual code change, time based, blockchain history, something else)\n​ - what me​chanism should be used to update the hard limit\n (hard fork code change, time based, blockchain history, something else)\n\nBonus:\n\n​ - what should the\n​transaction ​\nfee level be in 12 months (after the reward halves)?​\n - what's a good measure of \"(de)centralisation\" and what value should\neveryone aim for in 12 months?\n\nAs an interested newbie, I can't actually tell what most people think the\nanswers to most of those questions are. FWIW, mine would be:\n\n - soft limit in 12 months: 1MB-4MB\n - hard limit in 12 months: 2MB-20MB\n - hard limit grows at 17-40% a year (and should be \u003e4x average txn volume)\n - update the soft limit by code changes or blockchain history\n - update the hardlimit by (1) fee level, (2) miner vote, (3) hard coded\ntime updates at a conservative (low) rate, (4) hard fork every couple of\nyears\n - transaction fees should in 12months should be lower per kB than today's\ndefaults, say 20%-50% of today's defaults in USD\n - number of bitcoin nodes, should be 20% higher in 12 months than it is now\n\n​Cheers,\naj\n\n-- \nAnthony Towns \u003caj at erisian.com.au\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150816/cc92c904/attachment.html\u003e",
"sig": "02a5b43b958edfadc326b26f48c3a35e118e2d33580f8f030b2744a73a3b65ff83e73bf40be8c3c8a4fb69a21aaef4c5bc1e9ff563deee36bfaf85d7e84c6f35"
}