Eric Lombrozo [ARCHIVE] on Nostr: 📅 Original date posted:2015-09-20 📝 Original message:------ Original Message ...
📅 Original date posted:2015-09-20
📝 Original message:------ Original Message ------
From: "Milly Bitcoin via bitcoin-dev"
<bitcoin-dev at lists.linuxfoundation.org>
To: bitcoin-dev at lists.linuxfoundation.org
Sent: 9/20/2015 3:51:36 PM
Subject: Re: [bitcoin-dev] Scaling Bitcoin conference micro-report
>>Some of us have also been actively working towards developing
>>a more modular, layered architecture and better implementations that
>>will afford greater decentralization in software development with less
>>need for critical code reviews, less pushback from downstream
>>developers
>>who must continuously rebase, a better process for building consensus
>>in
>>the community, and simpler app migration.
>
>It sounds more efficient but it is not clear to me that it would change
>the level of centralization of how the final decisions are made.
>
>One threat to Bintcoin involves incentive for companies to hire
>developers. The only reason is to change (or not change) Bitcoin Core
>so it is beneficial to their interests. I am not sure anything can be
>done about that risk but it needs to be understood and considered and
>not just ignored.
Core development process and decentralized dev/community consensus
building (in particular for consensus-critical changes) is at the top of
my priorities as issues right now...and one that I'd love to discuss
more in depth...but it probably deserves its own thread. The political
angle seems very difficult right now while the systems architecture
stuff seems a bit more tractable...and it seems that without
architectural changes it will be extremely hard to decentralize
development and easily bring large numbers of new developers in.
>
>>We need to increase the basic infrastructure nodes by a factor much
>>larger than 2 or 3...more like 100 or 1000...and it's entirely doable
>>with properly aligned incentives.
>
>I assume that would mean fees that hike transaction fees and make
>Bitcoin more expensive?
>
Not necessarily. Right now we already pay around 3,600 bitcoins a day in
inflationary subsidies, very little of which goes to the majority of
critical infrastructure nodes and their operators. This is a problem
with the current protocol design, one we'll hopefully be able to fix.
Having more core infrastructure nodes doesn't need to raise costs per
transaction - but it will most likely require abandoning the current
approach of having three basic node classes: miners (which tend towards
centralized pools), full nodes (which must validate each of everyone's
transaction and in return get paid nothing), and thin clients (which
essentially amount to parasitic nodes that do not contribute any
resources back to the network and must be subsidized).
Published at
2023-06-07 17:40:36Event JSON
{
"id": "b1e61ef90ff0496b460eb0cb22c80570a5bd856d6b353ce8c9b6b7f14a3889b1",
"pubkey": "e899768d254f3537af7e26455968583632d0ab0bd4c780445eacfa087ac80d8f",
"created_at": 1686159636,
"kind": 1,
"tags": [
[
"e",
"4dc88d58511033587919733d4dc9dc5f297805e31bd935cb9f1c91f45ed8346b",
"",
"root"
],
[
"e",
"37f9ffe9871f77edc7297f5bbabbbc1c6e6f9cda3ff5ce40a00fde6e065a2486",
"",
"reply"
],
[
"p",
"1b29d94ee81e1ee0479f1db4bc4ac887407bd470a0d7060e76f8ab27fdd57e50"
]
],
"content": "📅 Original date posted:2015-09-20\n📝 Original message:------ Original Message ------\nFrom: \"Milly Bitcoin via bitcoin-dev\" \n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e\nTo: bitcoin-dev at lists.linuxfoundation.org\nSent: 9/20/2015 3:51:36 PM\nSubject: Re: [bitcoin-dev] Scaling Bitcoin conference micro-report\n\n\u003e\u003eSome of us have also been actively working towards developing\n\u003e\u003ea more modular, layered architecture and better implementations that\n\u003e\u003ewill afford greater decentralization in software development with less\n\u003e\u003eneed for critical code reviews, less pushback from downstream \n\u003e\u003edevelopers\n\u003e\u003ewho must continuously rebase, a better process for building consensus \n\u003e\u003ein\n\u003e\u003ethe community, and simpler app migration.\n\u003e\n\u003eIt sounds more efficient but it is not clear to me that it would change \n\u003ethe level of centralization of how the final decisions are made.\n\u003e\n\u003eOne threat to Bintcoin involves incentive for companies to hire \n\u003edevelopers. The only reason is to change (or not change) Bitcoin Core \n\u003eso it is beneficial to their interests. I am not sure anything can be \n\u003edone about that risk but it needs to be understood and considered and \n\u003enot just ignored.\nCore development process and decentralized dev/community consensus \nbuilding (in particular for consensus-critical changes) is at the top of \nmy priorities as issues right now...and one that I'd love to discuss \nmore in depth...but it probably deserves its own thread. The political \nangle seems very difficult right now while the systems architecture \nstuff seems a bit more tractable...and it seems that without \narchitectural changes it will be extremely hard to decentralize \ndevelopment and easily bring large numbers of new developers in.\n\n\u003e\n\u003e\u003eWe need to increase the basic infrastructure nodes by a factor much\n\u003e\u003elarger than 2 or 3...more like 100 or 1000...and it's entirely doable\n\u003e\u003ewith properly aligned incentives.\n\u003e\n\u003eI assume that would mean fees that hike transaction fees and make \n\u003eBitcoin more expensive?\n\u003e\nNot necessarily. Right now we already pay around 3,600 bitcoins a day in \ninflationary subsidies, very little of which goes to the majority of \ncritical infrastructure nodes and their operators. This is a problem \nwith the current protocol design, one we'll hopefully be able to fix.\n\nHaving more core infrastructure nodes doesn't need to raise costs per \ntransaction - but it will most likely require abandoning the current \napproach of having three basic node classes: miners (which tend towards \ncentralized pools), full nodes (which must validate each of everyone's \ntransaction and in return get paid nothing), and thin clients (which \nessentially amount to parasitic nodes that do not contribute any \nresources back to the network and must be subsidized).",
"sig": "301729ad1f6c3b09e06294b0c61197ce0345dd6c287bf9cb864c74dafbc81e56c5f2f9faa920ac82b359bbc653b1a3a0fd9a5fcbc15ad8d8e453da1b6408e603"
}