📅 Original date posted:2015-08-04
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 08/04/2015 07:19 PM, Hector Chu via bitcoin-dev wrote:
> On 4 August 2015 at 12:59, Jorge Timón <jtimon at jtimon.cc
> <mailto:jtimon at jtimon.cc>> wrote:
> So if you say 8, I must ask, why not 9? Why 9 MB is not safe for
> mining centralization but 8 MB is?
>
>
> 8MB has simply been the focal point for this debate. 9MB is also
> safe if 8MB is, but I suppose the opponents will be even less
> happy with 9 than with 8, and we don't want to unnecessarily
> increase the conflict.
>
Jorge will answer for himself, but you know that saying "9MB is also
safe if 8MB is" blows your position.
Do you, or me, or XT know that 8MB is "safe"? You say 9MB must then
also be "safe" - there has been no fact for me to grasp and from which
to tell a Bitcoin trading whale group: "here's the bottom line: this
is what it means and these are the implications." They hold
significant amounts of bitcoin and want to see a plan, and a strategy
based on facts. I can assure you, they're not going to XT, it lacks
both a strategy and the seasoned developers present here.
> It seems like the rationale it's always "the bigger the better" and
> the only limitation is what a few people concerned with mining
> centralization (while they still have time to discuss this) are
> willing to accept. If that's the case, then there won't be
> effectively any limit in the long term and Bitcoin will probably
> fail in its decentralization goals.
>
>
> A one-time increase to 8MB is safer than a dynamically growing
> limit over time for exactly this reason. Admittedly whenever the
> next debate to increase the block size over 8MB happens it will be
> even more painful and non-obvious, but that is the safety check to
> prevent unbounded block size increase.
You're articulate and you raise valid issues, but your judgment of
"safer" is not based on anything you or this list can refer to as a
comparator.
It seems you want 8MB for some ideological reason but if you examine
your motive and compare it to the facts, you'll find that many people
in this list are ultimately correct in saying that:
Whatever blocksize is set to, demand will soon fill it.
This is the nature of resource supply inflation - some business plan
will spot the opportunity and exploit it, colonize it and then we deal
with that, with some big-girls'-blouses exclaiming: "if we don't give
them what they want they're all going to leave to XT or ZT!"
Even though XT and ZT perfectly fulfill the needs of certain ambitious
businesses, the creators would rather see it happen on Core's
blockchain. Else why do they still come posit arguments here?
Fortunately, unlike the principle that applies in finance capital,
Bitcoin capacity supply doesn't have be increased on demand (not
without rigorous testing and evaluation) plus there is no maxim here
that "the customer is always right". The maxim is "be your own bank" -
during some periods it might be a slow bank but it _will_ remain
decentralized and it _will_ remain your own - not compromised to some
big business or mining cartel.
We want to compromise to science and reason, not profit motive or
democratic lobbying, right?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVwL80AAoJEGwAhlQc8H1mTVsH/3mdA4XrrRaBx7m/SckufNUu
OWJF/TPuEb0e3/A+OKNvYJgGtkZ9+8pQe2hQK2F1NxFG8QbbIPFXb4PYIiEnU8by
LMMNuDFfZXq0MEyTXXHgNj+XBSR74QKceXD4KM3jVeuieXE2KXGOyeiUD7Tjx0Gv
fyNAM4rhxmipGFu9kmnI6Bm25I4FBzif+ARQSWNmdZQn2bPkFrK0/Q4s/CyXngbb
S/DiPJ7XZrBJ2ogQycVmA4QesOyz30FpQ+QMt5nFUWma3LpLoYEBPtJd8rsG773i
acqSrOXxgfcGtNfbBU0xeTO/FOO4tXtbDVHBTKCBLZ5MgmBOYcm6OTLAwpeHlYY=
=WhnR
-----END PGP SIGNATURE-----
Venzen Khaosan [ARCHIVE] /
npub1uu…r4rpf
2023-06-07 17:32:30
in reply to nevent1q…wk05
Author Public Key
npub1uu2fve28mkg68uequseraz8gee7qg64733lr9r2g4c0xs5pmqnuslr4rpfPublished at
2023-06-07 17:32:30Event JSON
{
"id": "1a234313ac65ef6f1e295d19cdc340d98bd4252cbb4419ef181c0fdbd75cac2b",
"pubkey": "e714966547dd91a3f320e4323e88e8ce7c046abe8c7e328d48ae1e68503b04f9",
"created_at": 1686159150,
"kind": 1,
"tags": [
[
"e",
"4e8415b0ac5f4356e0ce0ebf2c3f4ee3b61a33a2b0c1bc226931c06144bfe5a4",
"",
"root"
],
[
"e",
"e83fd8cba55c1f031d4943caa8c98077caaee61df3709ea8d563517b4d2a3a8b",
"",
"reply"
],
[
"p",
"f3e056e548ecd779cfbea56b1bf9eb9c26afb3780523aa0df2e58f34f4b1faee"
]
],
"content": "📅 Original date posted:2015-08-04\n📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\n\n\nOn 08/04/2015 07:19 PM, Hector Chu via bitcoin-dev wrote:\n\u003e On 4 August 2015 at 12:59, Jorge Timón \u003cjtimon at jtimon.cc \n\u003e \u003cmailto:jtimon at jtimon.cc\u003e\u003e wrote:\n\n\u003e So if you say 8, I must ask, why not 9? Why 9 MB is not safe for \n\u003e mining centralization but 8 MB is?\n\u003e \n\u003e \n\u003e 8MB has simply been the focal point for this debate. 9MB is also \n\u003e safe if 8MB is, but I suppose the opponents will be even less\n\u003e happy with 9 than with 8, and we don't want to unnecessarily\n\u003e increase the conflict.\n\u003e \n\nJorge will answer for himself, but you know that saying \"9MB is also\nsafe if 8MB is\" blows your position.\n\nDo you, or me, or XT know that 8MB is \"safe\"? You say 9MB must then\nalso be \"safe\" - there has been no fact for me to grasp and from which\nto tell a Bitcoin trading whale group: \"here's the bottom line: this\nis what it means and these are the implications.\" They hold\nsignificant amounts of bitcoin and want to see a plan, and a strategy\nbased on facts. I can assure you, they're not going to XT, it lacks\nboth a strategy and the seasoned developers present here.\n\n\u003e It seems like the rationale it's always \"the bigger the better\" and\n\u003e the only limitation is what a few people concerned with mining \n\u003e centralization (while they still have time to discuss this) are \n\u003e willing to accept. If that's the case, then there won't be \n\u003e effectively any limit in the long term and Bitcoin will probably \n\u003e fail in its decentralization goals.\n\u003e \n\u003e \n\u003e A one-time increase to 8MB is safer than a dynamically growing \n\u003e limit over time for exactly this reason. Admittedly whenever the \n\u003e next debate to increase the block size over 8MB happens it will be \n\u003e even more painful and non-obvious, but that is the safety check to \n\u003e prevent unbounded block size increase.\n\nYou're articulate and you raise valid issues, but your judgment of\n\"safer\" is not based on anything you or this list can refer to as a\ncomparator.\n\nIt seems you want 8MB for some ideological reason but if you examine\nyour motive and compare it to the facts, you'll find that many people\nin this list are ultimately correct in saying that:\n\nWhatever blocksize is set to, demand will soon fill it.\n\nThis is the nature of resource supply inflation - some business plan\nwill spot the opportunity and exploit it, colonize it and then we deal\nwith that, with some big-girls'-blouses exclaiming: \"if we don't give\nthem what they want they're all going to leave to XT or ZT!\"\n\nEven though XT and ZT perfectly fulfill the needs of certain ambitious\nbusinesses, the creators would rather see it happen on Core's\nblockchain. Else why do they still come posit arguments here?\n\nFortunately, unlike the principle that applies in finance capital,\nBitcoin capacity supply doesn't have be increased on demand (not\nwithout rigorous testing and evaluation) plus there is no maxim here\nthat \"the customer is always right\". The maxim is \"be your own bank\" -\nduring some periods it might be a slow bank but it _will_ remain\ndecentralized and it _will_ remain your own - not compromised to some\nbig business or mining cartel.\n\nWe want to compromise to science and reason, not profit motive or\ndemocratic lobbying, right?\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1\n\niQEcBAEBAgAGBQJVwL80AAoJEGwAhlQc8H1mTVsH/3mdA4XrrRaBx7m/SckufNUu\nOWJF/TPuEb0e3/A+OKNvYJgGtkZ9+8pQe2hQK2F1NxFG8QbbIPFXb4PYIiEnU8by\nLMMNuDFfZXq0MEyTXXHgNj+XBSR74QKceXD4KM3jVeuieXE2KXGOyeiUD7Tjx0Gv\nfyNAM4rhxmipGFu9kmnI6Bm25I4FBzif+ARQSWNmdZQn2bPkFrK0/Q4s/CyXngbb\nS/DiPJ7XZrBJ2ogQycVmA4QesOyz30FpQ+QMt5nFUWma3LpLoYEBPtJd8rsG773i\nacqSrOXxgfcGtNfbBU0xeTO/FOO4tXtbDVHBTKCBLZ5MgmBOYcm6OTLAwpeHlYY=\n=WhnR\n-----END PGP SIGNATURE-----",
"sig": "11a1508b7512de25d672bbd8f087002e516c5125708f61bb1da3f606e49a27d2648ea0fad5168d553253a5447e0f086f853edeb3b851bea34452d1116d92d4e9"
}