📅 Original date posted:2015-07-30
📝 Original message:On Thu, Jul 30, 2015 at 2:29 PM, Gavin via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I would like (and have been asking) those people to take the time to quantify those costs and write up those risks in a careful way.
I agree that having a "minimal hardware requirements" specification
would greatly help with this discussions.
> I believe the costs and risks of 8MB blocks are minimal, and that the benefits of supporting more transaction FAR outweigh those costs and risks, but it is hard to have a rational conversation about that when even simple questions like 'what is s reasonable cost to run a full node' are met with silence.
These tests by Rusty (strong advocate of IBLT and working on it) seem
to indicate otherwise: http://rusty.ozlabs.org/?p=509
On Thu, Jul 30, 2015 at 2:50 PM, Pieter Wuille via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I think the risks of trying to make a controversial change to the network
> FAR outweighs the benefits of a small constant factor that "kicks the can
> down the road".
I think the risks of a controversial deployment in consensus rules
changes, outweigh by far potential benefits of ANY consensus forks, no
matter how amazing the potential benefits may seem. Bitcoin may not
survive a controversial hardfork or go 3 years back in adoption,
nobody knows.
> Let's scale the block size gradually over time, according to technological
> growth.
I agree. Unfortunately, technological and economic growth is very hard
to predict.
On Thu, Jul 30, 2015 at 3:33 PM, Venzen Khaosan <venzen at mail.bihthai.net> wrote:
> 2. Bitcoin is much more than a payment network. A lot of the
> non-payment features are, arguably, what gives Bitcoin most of its
> value. Yet, the payment functionality is a major design feature and
> all agree that it should scale - subject to axiom 1.
I just explained why I disagree with this point. Bitcoin fees depend
on transaction sizes rather than amounts moved. Even ignoring
script-based signatures and all the other advantages in Bitcoin, that
fact alone makes it extremely competitive with "traditional systems"
for many use cases (say, sending 1000 usd from the US to México).
I agree overall with your other points.
Extremely cheap and instant transactions can be provided by lightning,
but cannot be provided by Bitcoin in-chain alone in the long term (it
can't even provide instant irreversible transactions).
> Since I've maintained your interest up to the final sentence, I say:
> as an insurance against a capacity crisis before layer 2 is deployed,
> why not implement bip100's 2MB blocksize proposals in a testnet?
Of all blocksize proposals, bip102 (the one with the single doubling
to 2MB) is the one I dislike less because it doesn't make any
assumptions about future technological or economic growth (I loved
your Bohr cite).
But it still has something that I dislike from all proposals: the
numbers just seem pulled out of a hat.
But I already created that testnet you propose (and
std::numeric_limits<uint64_t>::max() -1 more testnets for other sizes)
in https://github.com/bitcoin/bitcoin/pull/6382
You can run it with the following runtime options: -chain=sizetest
-blocksize=2000000
Unfortunately, nobody seems interested in running some tests for
several sizes before proposing a concrete size.
As far as I know, nobody has used that branch to test different sizes.
Jorge Timón [ARCHIVE] /
npub1fx…cl2d8
2023-06-07 15:44:01
in reply to nevent1q…6cwy
Author Public Key
npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8Published at
2023-06-07 15:44:01Event JSON
{
"id": "71ff25b09e304dab682bf6e36688e248540a05d2c35dc9ae24d61321d9328ec6",
"pubkey": "498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84",
"created_at": 1686152641,
"kind": 1,
"tags": [
[
"e",
"6c35032431244726c153d1a10f0c8b9388f3e47774968a06a7b1ffa60bbaccd9",
"",
"root"
],
[
"e",
"ab8e83c9d8635d920d63962d14bb07bfa480f155f8778ce28984c025f0b32635",
"",
"reply"
],
[
"p",
"e714966547dd91a3f320e4323e88e8ce7c046abe8c7e328d48ae1e68503b04f9"
]
],
"content": "📅 Original date posted:2015-07-30\n📝 Original message:On Thu, Jul 30, 2015 at 2:29 PM, Gavin via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e I would like (and have been asking) those people to take the time to quantify those costs and write up those risks in a careful way.\n\nI agree that having a \"minimal hardware requirements\" specification\nwould greatly help with this discussions.\n\n\u003e I believe the costs and risks of 8MB blocks are minimal, and that the benefits of supporting more transaction FAR outweigh those costs and risks, but it is hard to have a rational conversation about that when even simple questions like 'what is s reasonable cost to run a full node' are met with silence.\n\nThese tests by Rusty (strong advocate of IBLT and working on it) seem\nto indicate otherwise: http://rusty.ozlabs.org/?p=509\n\nOn Thu, Jul 30, 2015 at 2:50 PM, Pieter Wuille via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e I think the risks of trying to make a controversial change to the network\n\u003e FAR outweighs the benefits of a small constant factor that \"kicks the can\n\u003e down the road\".\n\nI think the risks of a controversial deployment in consensus rules\nchanges, outweigh by far potential benefits of ANY consensus forks, no\nmatter how amazing the potential benefits may seem. Bitcoin may not\nsurvive a controversial hardfork or go 3 years back in adoption,\nnobody knows.\n\n\u003e Let's scale the block size gradually over time, according to technological\n\u003e growth.\n\nI agree. Unfortunately, technological and economic growth is very hard\nto predict.\n\n\nOn Thu, Jul 30, 2015 at 3:33 PM, Venzen Khaosan \u003cvenzen at mail.bihthai.net\u003e wrote:\n\u003e 2. Bitcoin is much more than a payment network. A lot of the\n\u003e non-payment features are, arguably, what gives Bitcoin most of its\n\u003e value. Yet, the payment functionality is a major design feature and\n\u003e all agree that it should scale - subject to axiom 1.\n\nI just explained why I disagree with this point. Bitcoin fees depend\non transaction sizes rather than amounts moved. Even ignoring\nscript-based signatures and all the other advantages in Bitcoin, that\nfact alone makes it extremely competitive with \"traditional systems\"\nfor many use cases (say, sending 1000 usd from the US to México).\nI agree overall with your other points.\nExtremely cheap and instant transactions can be provided by lightning,\nbut cannot be provided by Bitcoin in-chain alone in the long term (it\ncan't even provide instant irreversible transactions).\n\n\u003e Since I've maintained your interest up to the final sentence, I say:\n\u003e as an insurance against a capacity crisis before layer 2 is deployed,\n\u003e why not implement bip100's 2MB blocksize proposals in a testnet?\n\nOf all blocksize proposals, bip102 (the one with the single doubling\nto 2MB) is the one I dislike less because it doesn't make any\nassumptions about future technological or economic growth (I loved\nyour Bohr cite).\nBut it still has something that I dislike from all proposals: the\nnumbers just seem pulled out of a hat.\n\nBut I already created that testnet you propose (and\nstd::numeric_limits\u003cuint64_t\u003e::max() -1 more testnets for other sizes)\nin https://github.com/bitcoin/bitcoin/pull/6382\n\nYou can run it with the following runtime options: -chain=sizetest\n-blocksize=2000000\n\nUnfortunately, nobody seems interested in running some tests for\nseveral sizes before proposing a concrete size.\nAs far as I know, nobody has used that branch to test different sizes.",
"sig": "1bd445e6d66b971a3de89b65e3a33e255a91597b1dd5a301688f31393a6ca6464acf6a8841cbc11e4d80ef83052b66c9094282394ec19831a9a5421cc68792df"
}