đź“… Original date posted:2015-11-15
đź“ť Original message:This topic is straying from Bitcoin development into general Bitcoin
governance, policy, or other meta-issues.
We have now the new bitcoin-discuss mailing list now, specifically for
these more free-flowing topics:
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-discuss
Please take further discussion of this thread to that forum.
Thank you,
The bitcoin-dev moderation team
On Sat, Nov 14, 2015 at 1:45 PM, Peter R via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> > It looks like some specific meta-level criteria would help more at this
> point than new proposals all exploring a different variants of block size
> increase schedules.
>
> I agree. In fact, I’ll go meta on your meta and suggest that we should
> first discuss how Bitcoin should be governed in the first place. Should
> Bitcoin evolve from the “bottom up,” or from the “top down”?
>
> If one’s answer is from the “top-down,” then the meta-level criteria can
> be endlessly debated, for they all involve some sort of tradeoff, they all
> require some sort of compromise. The “top down” perspective holds that
> people might make poor choices if given the freedom to easily do so--it
> holds that the trade-offs must be balanced instead by experts.
>
> However, if one's answer is from the “bottom up,” then the meta-level
> criteria is very easy: we do what the people wants. We allow the people to
> weigh the tradeoffs and then we watch as consensus emerges through a
> decentralized process, objectively represented by the longest proof-of-work
> chain.
>
> Regarding the block size limit debate, at the end of the day it comes down
> to two things:
>
> 1. How big of a block will my node accept today?
>
> 2. What do I want my node to do if the longest chain includes a block
> larger than the limit I set?
>
> If one concedes that Bitcoin should be governed from the “bottom up,” then
> it is already possible to empower each node operator to more easily express
> his free choice regarding the size of blocks he is willing to accept, while
> simultaneously ensuring that his node tracks consensus.
>
> Best regards,
> Peter
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151114/ee289deb/attachment-0001.html>;
Johnathan Corgan [ARCHIVE] /
npub1j6…jm42m
2023-06-07 17:44:48
in reply to nevent1q…jkeu
Author Public Key
npub1j66aek8wm7jq8vaffs2l8w43evyywd4q7tcnqyge6xqezz0vcpks7jm42mPublished at
2023-06-07 17:44:48Event JSON
{
"id": "0eac05ed290e1191601b527e81f6aaa4e0adb8c2c33093c1f4dbd1166e9887aa",
"pubkey": "96b5dcd8eedfa403b3a94c15f3bab1cb084736a0f2f1301119d1819109ecc06d",
"created_at": 1686159888,
"kind": 1,
"tags": [
[
"e",
"3a0a71e06daf4df40d34d7d4df38f6afd927082ae4667eeee9d89bbe73cc655b",
"",
"root"
],
[
"e",
"672ac3827ca02e2d0cd284b215c1969501b9d28ddce538d5817e14fc7f8a216d",
"",
"reply"
],
[
"p",
"6185f02289f12c01c6f7c80cdc0331a01eae9c6356f228be12efdb7fb395bc19"
]
],
"content": "📅 Original date posted:2015-11-15\n📝 Original message:This topic is straying from Bitcoin development into general Bitcoin\ngovernance, policy, or other meta-issues.\n\nWe have now the new bitcoin-discuss mailing list now, specifically for\nthese more free-flowing topics:\n\nhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-discuss\n\nPlease take further discussion of this thread to that forum.\n\nThank you,\n\nThe bitcoin-dev moderation team\n\n\nOn Sat, Nov 14, 2015 at 1:45 PM, Peter R via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e \u003e It looks like some specific meta-level criteria would help more at this\n\u003e point than new proposals all exploring a different variants of block size\n\u003e increase schedules.\n\u003e\n\u003e I agree. In fact, I’ll go meta on your meta and suggest that we should\n\u003e first discuss how Bitcoin should be governed in the first place. Should\n\u003e Bitcoin evolve from the “bottom up,” or from the “top down”?\n\u003e\n\u003e If one’s answer is from the “top-down,” then the meta-level criteria can\n\u003e be endlessly debated, for they all involve some sort of tradeoff, they all\n\u003e require some sort of compromise. The “top down” perspective holds that\n\u003e people might make poor choices if given the freedom to easily do so--it\n\u003e holds that the trade-offs must be balanced instead by experts.\n\u003e\n\u003e However, if one's answer is from the “bottom up,” then the meta-level\n\u003e criteria is very easy: we do what the people wants. We allow the people to\n\u003e weigh the tradeoffs and then we watch as consensus emerges through a\n\u003e decentralized process, objectively represented by the longest proof-of-work\n\u003e chain.\n\u003e\n\u003e Regarding the block size limit debate, at the end of the day it comes down\n\u003e to two things:\n\u003e\n\u003e 1. How big of a block will my node accept today?\n\u003e\n\u003e 2. What do I want my node to do if the longest chain includes a block\n\u003e larger than the limit I set?\n\u003e\n\u003e If one concedes that Bitcoin should be governed from the “bottom up,” then\n\u003e it is already possible to empower each node operator to more easily express\n\u003e his free choice regarding the size of blocks he is willing to accept, while\n\u003e simultaneously ensuring that his node tracks consensus.\n\u003e\n\u003e Best regards,\n\u003e Peter\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151114/ee289deb/attachment-0001.html\u003e",
"sig": "2b2aeeed307f5fe0f662220afa6bf0de3de84ce776a058a1aa94cb7402be5a82c294f51f3c1ed11be8692b1c3737c393ac1a41033c153fb4a3d373694a171c7b"
}