📅 Original date posted:2015-08-03
📝 Original message:I proposed something along these lines in the lightning-dev mailing list:
http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/000088.html
It's probably a little off-topic there...but I'm very interested in
discussing such ideas.
On Aug 3, 2015 10:06 AM, "Luv Khemani via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> The current block size debate has brought up an important, albeit often
> neglected observation. Full nodes suffer from a tragedy of the commons
> problem and therefore are likely to continue decreasing as a percentage of
> total Bitcoin nodes. This also results in a vicious circle as more and more
> people use SPVs, the burden on existing full nodes will increase even
> without a block size increase, which will further reduce the number of full
> nodes . A few people have mentioned it in blogs or reddit, but the topic is
> generally quickly overshadowed by posts along the lines of "RAISE the
> blocksize already!".
>
> Full nodes bear the full cost of validating/relaying/storing the
> blockchain and servicing SPV clients but gain nothing financially from it,
> yet they serve an important role in validating transactions and keeping
> miner dishonesty in check. If there were few independent full nodes, it
> would be possible for 3-4 of the biggest mining pools to collude and do
> literally whatever they wanted with the protocol, including inflating the
> money supply, freezing funds or even confiscating funds, because who would
> know? And even if someone running a full node did voice out, the majority
> of users on SPV/Coinbase/etc.. would be powerless to do anything about it
> and would likely bear with the changes to protect status quo, just as is
> the case with current fiat regimes where people bear with QE/Inflation/bail
> outs because they are so dependent on the current system that they would
> rather tolerate any injustice than to have the system go down and bring
> them with it.
> This is the primary reason why many in the technical community are against
> drastic blocksize increases, as this will only worsen the problem of
> decentralization as this cost increases. And as long as full nodes are
> running on charity, i'm fully in agreement with the conservative block size
> camp.
>
> However, it is important to note that this seems to be an economic problem
> instead of a technical one. I cannot deny the argument from the big block
> side that technically, the hardware/bandwidth required to run full nodes
> supporting considerably larger blocks (4MB-8MB) is not out of reach of many
> individuals around the globe. The core issue in my opinion is that of
> incentive, because at the end of the day, running a full node is not free
> and at larger blocks costs will not be trivial. In my opinion, its perhaps
> our insistence that full nodes cant be incentivised that contributes to
> centralization pressures and discourages increasing of blocksize even
> though the technology exists to support it.
>
> Technically, existing hardware is capable of validating/processing blocks
> in the region of an order of magnitude larger than the current limit.
> Bandwidth requirements for running a validating full node are also not very
> high if you are not mining, as you can afford to wait a couple of minutes
> to download your block. This is obviously not the case for miners who need
> to download new blocks asap to avoid idle hash power or as has been seen in
> the recent fork, SPV mining (which is extremely undesirable for the
> network). IBLT should help greatly in reducing the propagation time of new
> blocks and ease peak bandwidth requirements. But im not worried about the
> miners, they are after all being financially compensated for what they are
> doing and investing in more bandwidth(either locally or running a full node
> remotely) can be seen as a cost of the business as long as the cost of
> running a full node is insignificant to the cost of hashing equipment to
> keep barriers to mining low.
>
> Before the concept lightning, there did not seem to be any trustless way
> of feasibly paying small micropayments to full nodes for their services.
> However, with payment channels and lightning, this may no longer be an
> issue. A node could advertise it's rates to a SPV nodes upon connection and
> the SPV could either agree or look for another node with lower fees. If
> implemented, fees are likely to be trivial(few satoshis per request) as
> competition will drive down fees close to the cost of running a full node.
> This should spur an increase in the number of full nodes and increase
> decentralization of the network.
>
> I just wanted to float the idea and hear comments/feedback/critiques of
> this idea.
>
> _______________________________________________
> 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/20150803/7f98eccb/attachment-0001.html>;
Eric Lombrozo [ARCHIVE] /
npub1az…t2krq
2023-06-07 17:32:44
in reply to nevent1q…zr85
Author Public Key
npub1azvhdrf9fu6n0tm7yez4j6zcxcedp2ct6nrcq3z74naqs7kgpk8s5t2krqPublished at
2023-06-07 17:32:44Event JSON
{
"id": "910aff16f7c31dba533495e7bea072c7767f86d08fd216649b08a31bbf9aacb8",
"pubkey": "e899768d254f3537af7e26455968583632d0ab0bd4c780445eacfa087ac80d8f",
"created_at": 1686159164,
"kind": 1,
"tags": [
[
"e",
"27ce21e0dc2dbb9dfa0524f21e7a2eb12a30a6c6c90993a9e000cca03e908ab9",
"",
"root"
],
[
"e",
"03fc2b81697a18c1ac520539b081ae4e336408c8050d39054b4f8a8f5053a58c",
"",
"reply"
],
[
"p",
"e941dfa3762ee3ab50a8f21443d78c29cec53ffce703c0d2bd623c892d7085e4"
]
],
"content": "📅 Original date posted:2015-08-03\n📝 Original message:I proposed something along these lines in the lightning-dev mailing list:\nhttp://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/000088.html\n\nIt's probably a little off-topic there...but I'm very interested in\ndiscussing such ideas.\nOn Aug 3, 2015 10:06 AM, \"Luv Khemani via bitcoin-dev\" \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e The current block size debate has brought up an important, albeit often\n\u003e neglected observation. Full nodes suffer from a tragedy of the commons\n\u003e problem and therefore are likely to continue decreasing as a percentage of\n\u003e total Bitcoin nodes. This also results in a vicious circle as more and more\n\u003e people use SPVs, the burden on existing full nodes will increase even\n\u003e without a block size increase, which will further reduce the number of full\n\u003e nodes . A few people have mentioned it in blogs or reddit, but the topic is\n\u003e generally quickly overshadowed by posts along the lines of \"RAISE the\n\u003e blocksize already!\".\n\u003e\n\u003e Full nodes bear the full cost of validating/relaying/storing the\n\u003e blockchain and servicing SPV clients but gain nothing financially from it,\n\u003e yet they serve an important role in validating transactions and keeping\n\u003e miner dishonesty in check. If there were few independent full nodes, it\n\u003e would be possible for 3-4 of the biggest mining pools to collude and do\n\u003e literally whatever they wanted with the protocol, including inflating the\n\u003e money supply, freezing funds or even confiscating funds, because who would\n\u003e know? And even if someone running a full node did voice out, the majority\n\u003e of users on SPV/Coinbase/etc.. would be powerless to do anything about it\n\u003e and would likely bear with the changes to protect status quo, just as is\n\u003e the case with current fiat regimes where people bear with QE/Inflation/bail\n\u003e outs because they are so dependent on the current system that they would\n\u003e rather tolerate any injustice than to have the system go down and bring\n\u003e them with it.\n\u003e This is the primary reason why many in the technical community are against\n\u003e drastic blocksize increases, as this will only worsen the problem of\n\u003e decentralization as this cost increases. And as long as full nodes are\n\u003e running on charity, i'm fully in agreement with the conservative block size\n\u003e camp.\n\u003e\n\u003e However, it is important to note that this seems to be an economic problem\n\u003e instead of a technical one. I cannot deny the argument from the big block\n\u003e side that technically, the hardware/bandwidth required to run full nodes\n\u003e supporting considerably larger blocks (4MB-8MB) is not out of reach of many\n\u003e individuals around the globe. The core issue in my opinion is that of\n\u003e incentive, because at the end of the day, running a full node is not free\n\u003e and at larger blocks costs will not be trivial. In my opinion, its perhaps\n\u003e our insistence that full nodes cant be incentivised that contributes to\n\u003e centralization pressures and discourages increasing of blocksize even\n\u003e though the technology exists to support it.\n\u003e\n\u003e Technically, existing hardware is capable of validating/processing blocks\n\u003e in the region of an order of magnitude larger than the current limit.\n\u003e Bandwidth requirements for running a validating full node are also not very\n\u003e high if you are not mining, as you can afford to wait a couple of minutes\n\u003e to download your block. This is obviously not the case for miners who need\n\u003e to download new blocks asap to avoid idle hash power or as has been seen in\n\u003e the recent fork, SPV mining (which is extremely undesirable for the\n\u003e network). IBLT should help greatly in reducing the propagation time of new\n\u003e blocks and ease peak bandwidth requirements. But im not worried about the\n\u003e miners, they are after all being financially compensated for what they are\n\u003e doing and investing in more bandwidth(either locally or running a full node\n\u003e remotely) can be seen as a cost of the business as long as the cost of\n\u003e running a full node is insignificant to the cost of hashing equipment to\n\u003e keep barriers to mining low.\n\u003e\n\u003e Before the concept lightning, there did not seem to be any trustless way\n\u003e of feasibly paying small micropayments to full nodes for their services.\n\u003e However, with payment channels and lightning, this may no longer be an\n\u003e issue. A node could advertise it's rates to a SPV nodes upon connection and\n\u003e the SPV could either agree or look for another node with lower fees. If\n\u003e implemented, fees are likely to be trivial(few satoshis per request) as\n\u003e competition will drive down fees close to the cost of running a full node.\n\u003e This should spur an increase in the number of full nodes and increase\n\u003e decentralization of the network.\n\u003e\n\u003e I just wanted to float the idea and hear comments/feedback/critiques of\n\u003e this idea.\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\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150803/7f98eccb/attachment-0001.html\u003e",
"sig": "7d2696f5f2ddb8c47adfcab67f6481a214d9b99f503b89e7b6da94d09661cb689776875bffa701ea3b32b56ede461d2a05affe555751d62fb138411b74a47f1d"
}