📅 Original date posted:2015-09-04
📝 Original message:I understand your concerns. What kinds of changes do you think should go
through a process like this? Just hard forks?
I was thinking that an advantage of making all BIPs use this process is
that it makes it familiar and well used. Kinda like a muscle grows stronger
with use. If only hard forks go through the process then there's the risk
that the process has to be spun up whenever they happen which might cause
confusion.
Another reason I was thinking is that even small, local changes, it doesn't
hurt to have a few more people take a look at it and approve it.
The bureaucracy only applies to BIPs, not PRs. There's only been 18
approved/final/accepted BIPs in 4 years since BIP-0001. That's only about
~5 per year. I get that bureaucracy is often a waste of time, but I just
don't think every second counts for these things.
On Fri, Sep 4, 2015 at 2:01 PM, Luke Dashjr <luke at dashjr.org> wrote:
> On Friday, September 04, 2015 8:13:18 PM Andy Chase via bitcoin-dev wrote:
> > Who makes high-level Bitcoin decisions? Miners, client devs, merchants,
> or
> > users? Let's set up a system where everyone has a say and clear
> acceptance
> > can be reached.
>
> For hardforks (removing consensus rules), economic consensus: people who
> accept payment in bitcoins weighted by their actual volume of such
> payments.
> A supermajority subset may arguably be sufficient for some hardforks (which
> don't violate Bitcoin's social contract) since they can effectively compel
> the remaining economy to comply.
>
> For softforks (adding consensus rules), a majority of miners: they can "51%
> attack" miners who don't go along with it.
>
> Anything else does not necessarily need universal agreement, so are
> completely up to the whim of individual software projects. If someone
> doesn't
> like a decision in Core (for example), they can safely fork the code. If
> any
> significant amount of people use their fork, then the BIP is accepted
> whether
> or not Core later adopts it.
>
> Note this "system" is really describing a lack of a system - that is, what
> naturally must happen for changes to occur. Softforks have a relatively
> mature technical method for measuring support and deploying (which I
> believe
> someone else is already working on a BIP describing), but the same thing is
> impractical for hardforks. Some formal way to measure actual economic
> acceptance seems like a good idea to study, but it needs to be reasonably
> accurate so as to not change the outcome from its natural/necessary result.
>
> Luke
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150904/31c3d750/attachment-0001.html>;
Andy Chase [ARCHIVE] /
npub1hg…2pv20
2023-06-07 17:39:38
in reply to nevent1q…qn93
Author Public Key
npub1hgz0f5ghpavn49u2h2za7464v9w02fd534nx5w268plwr06zal3s32pv20Published at
2023-06-07 17:39:38Event JSON
{
"id": "ed5ef42f4b15491e30e8e456fedb09253e1cc283860805ebe7582d2027606d73",
"pubkey": "ba04f4d1170f593a978aba85df5755615cf525b48d666a395a387ee1bf42efe3",
"created_at": 1686159578,
"kind": 1,
"tags": [
[
"e",
"9c96b271d28066e4cb9eb50131a2ba9c23f5c1ad1af3e01fa5e76e13c28699d2",
"",
"root"
],
[
"e",
"88237408aa4902dd4d416347db7467fa0f11e688aabf99f517161cfe8ff8411a",
"",
"reply"
],
[
"p",
"5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803"
]
],
"content": "📅 Original date posted:2015-09-04\n📝 Original message:I understand your concerns. What kinds of changes do you think should go\nthrough a process like this? Just hard forks?\n\nI was thinking that an advantage of making all BIPs use this process is\nthat it makes it familiar and well used. Kinda like a muscle grows stronger\nwith use. If only hard forks go through the process then there's the risk\nthat the process has to be spun up whenever they happen which might cause\nconfusion.\n\nAnother reason I was thinking is that even small, local changes, it doesn't\nhurt to have a few more people take a look at it and approve it.\n\nThe bureaucracy only applies to BIPs, not PRs. There's only been 18\napproved/final/accepted BIPs in 4 years since BIP-0001. That's only about\n~5 per year. I get that bureaucracy is often a waste of time, but I just\ndon't think every second counts for these things.\n\nOn Fri, Sep 4, 2015 at 2:01 PM, Luke Dashjr \u003cluke at dashjr.org\u003e wrote:\n\n\u003e On Friday, September 04, 2015 8:13:18 PM Andy Chase via bitcoin-dev wrote:\n\u003e \u003e Who makes high-level Bitcoin decisions? Miners, client devs, merchants,\n\u003e or\n\u003e \u003e users? Let's set up a system where everyone has a say and clear\n\u003e acceptance\n\u003e \u003e can be reached.\n\u003e\n\u003e For hardforks (removing consensus rules), economic consensus: people who\n\u003e accept payment in bitcoins weighted by their actual volume of such\n\u003e payments.\n\u003e A supermajority subset may arguably be sufficient for some hardforks (which\n\u003e don't violate Bitcoin's social contract) since they can effectively compel\n\u003e the remaining economy to comply.\n\u003e\n\u003e For softforks (adding consensus rules), a majority of miners: they can \"51%\n\u003e attack\" miners who don't go along with it.\n\u003e\n\u003e Anything else does not necessarily need universal agreement, so are\n\u003e completely up to the whim of individual software projects. If someone\n\u003e doesn't\n\u003e like a decision in Core (for example), they can safely fork the code. If\n\u003e any\n\u003e significant amount of people use their fork, then the BIP is accepted\n\u003e whether\n\u003e or not Core later adopts it.\n\u003e\n\u003e Note this \"system\" is really describing a lack of a system - that is, what\n\u003e naturally must happen for changes to occur. Softforks have a relatively\n\u003e mature technical method for measuring support and deploying (which I\n\u003e believe\n\u003e someone else is already working on a BIP describing), but the same thing is\n\u003e impractical for hardforks. Some formal way to measure actual economic\n\u003e acceptance seems like a good idea to study, but it needs to be reasonably\n\u003e accurate so as to not change the outcome from its natural/necessary result.\n\u003e\n\u003e Luke\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150904/31c3d750/attachment-0001.html\u003e",
"sig": "f000c120f5969ffab2d65f29318e6d1ccd98181d0688a16ec33b07384342917e262277b417050beb989f21bcac5d7b3de4aeadc47b35fee210b3daecca427db0"
}