Andy Chase [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-08-25 to 2016-01-19
💬 Posted a total of 14 messages
📚 Participated in the following categories: bitcoin-dev, BIP/Draft
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 17:48:00

- reply

📅 Original date posted:2016-01-19
📝 Original message:Thanks for your comments Luke.
> Are you saying your proposal is intentionally not intended to reflect the
reality?
That's right. I want to be able to include more voices and be able to get a
clearer idea of acceptance then the process currently has available.
This process should work alongside the current one; not replace it.
> conditions under which a proposal is *known to be* accepted by the
community
*known to be* Is what I'm working towards; yes; but I think we need
additional tools/processes to determine that then what we currently have
available.
> As mentioned, IMO a committee shouldn't be indicating acceptance, as much
as
it should be *determining* acceptance.
The committee determine acceptance when taking their opinions in aggregate.
The source of their indication might be similar to what we currently have
(esp for Core Devs, etc.)
> That sounds very time consuming
Ok
> And what happens if these committees don't represent the community?
The committee structures are fluid-- that is users are able to re-organize
at any time.
> What about when only part of the community - let's say 10% - decides to
adopt a BIP that doesn't require consensus
This might happen, but is not a flaw in my process. My process makes it
clear they are going against the acceptance of the rest of the community. I
don't intend to "force" anyone to implement or use an accepted BIP. If that
is desired that's outside the scope of this BIP.
> But the Bitcoin user base is completely unknown, and tracking software
user base is a privacy violation.
I made a suggestion for this here:
https://gist.github.com/andychase/dddb83c294295879308b
If there are other ways for honest but anonymous voting mechanisms (that
aren't proof-of-stake since that's proof-of-most-money) I'd be all ears.
> Bitcoin economic activity is also unknown
> This needs a proper specification. How do miners express their positions?
I agree these are flaws in the proposal. I'm not sure that one way of
indicating should be considered valid forever, but may have to change over
time.
> Chosen how, and by whom?
I think the process could be used to determine this.
> but I don't think we can just let the author set any conditions they like
either
I'm not sure what you mean here but would love more information.
On Mon, Jan 18, 2016 at 6:12 PM, Luke Dashjr <luke at dashjr.org> wrote:
> On Saturday, September 05, 2015 9:19:51 PM Andy Chase wrote:
> > Okay for sure yeah writing another proposal that reflects the current
> state
> > of affairs as people see it might provide some interesting perspective on
> > this proposal. I would welcome that.
>
> Are you saying your proposal is intentionally not intended to reflect the
> reality? I wasn't talking about a "current state of affairs" for BIPs as
> much
> as that that the acceptance of BIPs is *defined by* the state of affairs.
>
> Overall, I think something *similar to* this proposal is a good idea, but I
> disagree with how this proposal currently approaches the problem. Instead,
> what I would recommend is a specification based on BIP 123 that specifies
> the
> conditions under which a proposal is *known to be* accepted by the
> community
> (ie, discerning, not deciding), and establishes a way for a committee to
> review the BIP and *determine* if these conditions have been met. This
> would
> avoid a "disconnect" between the "official status" and reality, making the
> BIP
> process more useful to everyone.
>
> Reviewing your current proposal:
>
> > * It sets up '''committees''' for reviewing comments and indicating
> > acceptance under precise conditions.
>
> As mentioned, IMO a committee shouldn't be indicating acceptance, as much
> as
> it should be *determining* acceptance.
>
> > ** Committees are authorized groups that represent client authors,
> miners,
> > merchants, and users (each as a segment). Each one must represent at
> least
> > 1% stake in the Bitcoin ecosystem.
>
> 1% seems like an awful lot to dedicate to BIP status changes.
>
> > A committee system is used to organize the essential concerns of each
> > segment of the Bitcoin ecosystem. Although each segment may have many
> > different viewpoints on each BIP, in order to seek a decisive yes/no on a
> > BIP, a representational authoritative structure is sought. This structure
> > should be fluid, allowing people to move away from committees that do not
> > reflect their views and should be re-validated on each BIP evaluation.
>
> That sounds very time consuming. And what happens if these committees don't
> represent the community? What about when only part of the community - let's
> say 10% - decides to adopt a BIP that doesn't require consensus? Logically
> that BIP should still proceed...
>
> > ** Proof of claim and minimum 1% stake via:
> > *** Software: proof of ownership and user base (Min 1% of Bitcoin
> userbase)
>
> But the Bitcoin user base is completely unknown, and tracking software user
> base is a privacy violation.
>
> > ** Merchant: proof of economic activity (Min 1% of Bitcoin economic
> > activity)
>
> Bitcoin economic activity is also unknown, and it seems likely that
> merchants
> consider their own activity confidential.
>
> > Mining: proof of work (Min 1% of Hashpower)
>
> This needs a proper specification. How do miners express their positions?
>
> > A BIP Process Manager should be chosen who is in charge of:
>
> Chosen how, and by whom?
>
> > == Conditions for activation ==
> >
> > In order for this process BIP to become active, it must succeed by its
> own
> > rules. At least a 4% sample of the Bitcoin community must be represented,
> > with at least one committee in each segment included. Once at least one
> > committee has submitted a declaration, a request for comments will be
> called
> > and the process should be completed from there.
>
> Until this BIP is active, its rules do not apply, so this would be a form
> of
> circular reasoning. I like the idea of putting conditions for activation in
> the BIP text, but I don't think we can just let the author set any
> conditions
> they like either...
>
> Luke
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160118/7b057fc4/attachment-0001.html>

2023-06-07 17:39:57

- reply

📅 Original date posted:2015-09-11
📝 Original message:What's some more information about the "memorizing and sharing" use
case? In most cases if you wanted someone to send you money you'd send
them a payment request via email (or just send them your address).
There's a bunch of solutions to your problem listed here:
https://github.com/bitcoin/bips/blob/master/bip-0015.mediawiki
But sending a payment request via BIP-70 is the "best practice":
https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki
On Thu, Sep 10, 2015 at 2:32 PM, Mark Friedenbach via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Are you aware of the payment protocol?
>
> On Sep 10, 2015 2:12 PM, "essofluffy . via bitcoin-dev"
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Hi Everyone,
>>
>> An issue I'm sure everyone here is familiar with is the problem concerning
>> the fact that Bitcoin addresses are too complex to memorize and share.
>> Current Bitcoin addresses can be very intimidating to new users. As Bitcoin
>> grows it's necessary to provide a much more user friendly experience to the
>> end user. I think that having the capability to assign a unique name to a
>> Bitcoin address is in the best interest of Bitcoin and it's users.
>> I've recently come up with a method for assigning a unique name to a
>> specific Bitcoin address. I'm looking to get some feedback/criticism on this
>> method that I have detailed below.
>>
>> Let’s run through Bob and Alice transacting with a Named Bitcoin Address.
>> Bob wants to collect a payment from Alice for a service/good he is
>> selling, but Alice wants to pay from her home computer where she securely
>> keeps all her Bitcoin. So now Bob needs to give Alice his Bitcoin address
>> and because Bob is using a Named Bitcoin Address and a supported wallet he
>> can give her an easy to memorize and hard to mess up address. Bob’s address
>> is simply ‘SendBitcoinsToBob’ which can easily be written down or memorized.
>> Now Alice can go home send the Bitcoin from her own supported wallet and be
>> positive that she sent it to Bob.
>>
>> Let’s look at how Bob’s supported wallet made that address.
>>
>> First Bob let’s his wallet know that he wants to create a new address. In
>> response, his wallet simply asks him what he wants that address to be named.
>> Bob then enters ‘SendBitcoinsToBob’ as his preferred address name. The
>> wallet then let’s Bob know if his preferred address name is available. If
>> it’s available the name is broadcasted to the network and ready to use.
>>
>> Now let’s get a little more technical.
>>
>> When Bob inputs his preferred address name the client has to make sure
>> this name hasn’t been taken or else who knows where Alice will be sending
>> her Bitcoins. The client does this by referencing a downloaded “directory”
>> of names chosen by people using this system. This directory of names are
>> transactions sent to an address without a private key (but still viewable on
>> the blockchain) with the name appended to the transactions as an OP_RETURN
>> output. These transactions are downloaded or indexed, depending on whether
>> or not the wallet contains the full Blockchain or is an SPV wallet. Because
>> of such a large amount of possible address names a binary search method is
>> used to search through all this data efficiently. The names could be sorted
>> in two ways, the first being the first character and the second being the
>> total length of the name (I will being exploring additional methods to make
>> this process more efficient). So now that Bob’s client has verified that the
>> name has not been taken and is valid (valid meaning it's under 35 bytes long
>> and only using chars 0-9 and a-z) it sends a transaction of 1 satoshi and a
>> small fee to the address without a private key as talked about earlier. The
>> transaction's OP_RETURN output consists of two parts. The implementation
>> version of this method (up to 8 characters) and the name itself (up to 32
>> characters). Once the transaction is broadcasted to the network and
>> confirmed the name is ready to be used.
>>
>> Let’s look at how Alice’s supported wallet sends her Bitcoin to Bob’s
>> Named Bitcoin Address.
>>
>> When Alice enters in Bob’s address, ‘SendBitcoinsToBob’ Alice’s client
>> references the same “directory” as Bob only on her device and searches for
>> the OP_RETURN output of ‘SendBitcoinsToBob’ using a very similar binary
>> search method as used for the verification of the availability of an address
>> name. If a name isn’t found the client would simply return an error. If the
>> name is found then the client will pull the information of that transaction
>> and use the address it was sent from as the address to send the Bitcoin to.
>>
>> Essentially what this idea describes is a method to assign a name to a
>> Bitcoin address in a way that is completely verifiable and independent of a
>> third party.
>>
>> Please ask your questions and provide feedback.
>>
>> - Devin
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 17:39:47

- reply

📅 Original date posted:2015-09-06
📝 Original message:Mediawiki formatted documented: https://gist.github.com/andychase/dadbfbb145de934d8e1c
——
Title: BIP Realistic Acceptance Process
Author: Andy Chase
Status: Draft
Type: Process
Created: 2015-09-06
Abstract
========
The current process for accepting a BIP is not clearly defined. While
BIP-0001 defines the process for writing and submitting a Bitcoin
improvement proposal to the community it does not specify the precise
method for which BIPs are considered accepted or rejected.
This proposal documents the current method for which BIPs are accepted
or rejected.
Due to the large number of BIPs and the different processes that were
followed, this BIP is specifically based around the acceptance process
of BIP-0064. This was picked because it picks up a lot of the edge cases
that BIPs often have.
Motivation
==========
The primary motivation of this document is to allow for a discussion on
a realistic and acceptable BIP acceptance procedure. There has been a
quite few calls for documenting and using the current "realistic" method
for BIP acceptance:
Luke Jr.
> Any such a BIP like this needs to document the natural forces involved
> in real-world acceptance \[...\] it needs to be reasonably accurate so
> as to not change the outcome from its natural/necessary result.
Btc Drak
> I'm rather perplexed about \[another acceptance\] proposal. What
> exactly is wrong with the existing BIPs process?
Peter Todd
> IMO trying to "set up a system" in that kind of environment is silly,
> and likely to be a bureaucratic waste of time.
Adam Back
> The development process is to improve Bitcoin, not to randomly
> redefine it on a whim of one guy's opinion, nor the devs opinion.
Copyright
=========
This document is placed into the public domain.
Process
=======
This game works best with at least 3 people and a basic familiarity with
the BIP process.
- Story: You are a confident software superstar who has worked at
Hooli and has taken up a passion for Bitcoin. You've realized that
you need a specific protocol in Bitcoin core for an application you
are working on. You've been funded a lot of money for this project
so you don't really have any option but to try to put it into the
core protocol.
- Rules:
- Each turn counts as a day
- You can prevent anyone from taking a drink at any time by
handing them a buck, looking into their eyes and saying "we are
the future of Bitcoin"
- If you can't remember a word replace it with the word
"consensus"
- If try to take a drink but are out, you must try to explain what
a "fork" is to the person on your left in the most complicated
way possible.
- Start:
- Take a turn drawing up your implementation (draw a picture
of something)
- Hand the "implementation" to the person on your left who writes
down words explaining the picture in the abstract using
big words. Hand it back. This is your BIP Draft.
- Roll die, number rolled is the number of required elements
from BIP-0001 that you included in your BIP draft
- take a drink for each element you included
- If you rolled a 6 oops you didn't include a
copyright declaration. Nothing happens.
- Submit for comments on mailing list
- For three turns, receive criticism. Each turn:
- Someone says your proposal is trash! take a drink and
roll a die:
- If 1-2: Smash your hand on the table with your other
hand and take out the pain on the person to your
right who is criticizing your proposal. Take a drink
to ease the pain.
- If 3-4: Make an ad hominem statement about the
person on the right. Look them in the eye and take a
smug sip.
- If 5-6: Ignore it. Do nothing.
- Finish your drink if you get any positive remarks or
constructive feedback about your BIP (in other words don't
finish your drink).
- Submit draft pull request to bitcoin/bip.
- Story: Congrats! This represents an important milestone in
the BIP process. You put in the effort to get the BIP draft
vetted and you are ready to perform the janitorial task of
publicly submitting your BIP into the official BIP repo for
the world to see and refer to. The road ahead won't be easy,
there's rules to obey and guidelines to follow. Think this
will be quick and painless? Think again, a bit of short
sidedness or a forgotten rebase will cost you time, and time
is money.
- Setup (1 turn):
- Take a drink and roll a 6 sided die. Now self-assign a
BIP number based on that. Say: "I'm not sure what the
process is for picking a number, so I just grabbed one
that's free." Take a drink if the number was taken.
- Flip coin. If tails take a drink and argue about
following procedures: Say: "Seems like a timesink
to me".
- Roll 6 sided die. If you get a 7, BIP editor reads your
BIP and makes editorial suggestions.
- Flip a coin: If heads you will be asked to submit a
change to the index readme as well. If so drown your
misery by finishing your drink.
- Maintainence. Each day:
- Roll die. If 6:
- If you were asked to submit a change to the index
readme: flip a coin. If heads, your merge commit has
conflicts and you will be asked to rebase. If tails
continue:
- Did you receive any sort of comment in the last 2
days?
- If so do nothing
- If not, your BIP draft was merged! Celebrate!
Finish your drink.
- Flip coin. If heads take a drink as you received
comments about implementation-level issues in the high
level draft. Person to your right must say to you: "not
a fixed size type? And why does the signed-ness not
match the BIP?"
- You must now stealth fix issues in the background,
squashing history. Do not answer the question with
an explanation but instead remain positive. Say:
"Good catch, thanks!"
- Roll die. Take a stealth sip for each commit you
squashed
- Repeat until merged.
- Submit pull request with implementation
- Story: Amazing! Not only are you a brilliant writer and
communicator, you happen to be a software engineer as well.
Truely a the right combination of ethics and ethos in
your genetics. Now you get to submit your change to see if
it's a good fit for inclusion into Bitcoin core.
- Setup (1 turn)
- Flip a coin. If you get either heads or tails that means
you didn't include any unit tests. Take a drink.
- Maintenance (3 turns):
- (1 turn) Peter found a DDoS vulnerability in your code.
Take a drink of shame and say: "I don't think the attack
you have in mind works."
- (1 turn) Someone says you haven't tested this patch
enough yet. Take a test drink and say: "I attempted to
write unit tests for this, but Core has no
infrastructure for building test chains"
- (1 turn) Roll a dice. You can either take that many sips
or insult the person on your right that many times. The
person on your left may assist with the insults. Insults
must be one of:
- "that would complicate the implementation
considerably"
- "You are welcome to implement such an upgrade in a
future patch, if you like"
- "You're making assumptions about the design without
understanding it."
- "Your second statement is nonsensical."
- "This patch is what it is. If you'd like it to be
better feel free to contribute code to make it so."
- Roll die. If 1-5 your patch was never merged. If 6 your patch
was merged but then reverted. Finish your drink if
this happened.
- Hard fork
- Story: Fantastic! You've gone through the BIP draft process
and now its time to shift from the PR (pull request) process
to the PR (public relations) process. You goal is now to
convince everyone to join a client with your patch in it. If
you get 70% (the economic supermajority) to join your patch
you win the game. To signify they've joined your client,
take their BIP document.
- You have to get 100% if you are playing with 5 or less
people
- Setup (1 turn)
- Pick a reddit username. Flip a coin. If heads the person
on your left makes up a name for you. If tails use your
real name. Your profile picture is a strange picture you
of a much younger age. Everyone must now refer to you by
your reddit name prefixed but "u/" like so: "u slash
sloppy lizard, it's your turn".
- Controversy (each day):
- Roll a die:
- If 1: Make a blog post about how your client is
the best. Make up a headline and say it. Everyone
must thumbs up or thumbs down. Those who thumbs down
must take a drink. Roll a die and that number from
the left looping around joins your client (only if
their thumb was up, you can join your own client).
- If 2: Announce a new community without censorship.
Anyone can finish their drink to censor this action.
If not censored, roll a die to see who joins (same
rules as 1)
- If 3: You make a silly beer joke on twitter. Take
a drink. No one joins.
- If 4: Point to the roof! Last one to point mined one
of your blocks and has to join your client. They
must also take a drink and say (begrudgingly): "to
the moon".
- If 5: Someone incites Fear, Uncertainty, & Doubt
about your client. Everyone is now scared of you.
First one to look you in the eyes has to join your
client and take a drink. Lasts only until your
next turn.
- If 6: Ask someone to join your client. They
must accept. Both take a drink of friendship.

2023-06-07 17:39:41

- reply

📅 Original date posted:2015-09-06
📝 Original message:Dang you are right Thomas! I'm just pretty excited about this proposal and
sparking a discussion on this issue.
Here's some updates and thoughts:
- Luke said: "BIPs wouldn't be recognised as such because nobody cares
to meet the higher requirements"
- Possibly true, but maybe not! I think people like having a say
especially people with a lot of money on the line or those who are really
passionate about Bitcoin
- One counter example, I emailed all the sponsors of the workshop
conference about their stance in regards to scalability going into the
workshop and I got a 47% response rate (with 21% responding with
a concrete
answer). See here:
https://www.reddit.com/r/bitcoinxt/comments/3isqmf/which_of_the_scaling_bitcoin_conference_sponsors/cujg3vc
- One example that agrees with you, I talked to the #bitcoin-assets
community and they seemed very against participating in future
BIPs or even
allowing discussion with people outside their community:
http://pastebin.com/H5WeNwu3
- I'm seeking a historian or political science expert to assist me in
this area. If you guys know any I'd be glad to talk to them about working
with them.
- Many people are complaining about the stake part, and are worried
about the ambiguity. I firmly believe that proof of stake is a poor voting
mechanism because it gives the most power to those that have a lot of
money.
- I think proof of stake might work for merchants to prove they have
a decent economic stake if they sign with a well-known cold
wallet address,
but I agree with someone that said merchants may be hesitant about doing
that.
On Sun, Sep 6, 2015 at 6:36 AM, Thomas Kerin <thomas.kerin at gmail.com> wrote:
> Normally allocation comes after about 2 weeks or so, not 2 days!
> On 5 Sep 2015 10:20 pm, "Andy Chase via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Okay for sure yeah writing another proposal that reflects the current
>> state of affairs as people see it might provide some interesting
>> perspective on this proposal. I would welcome that.
>>
>> Greg: With no other direct comments appearing to be inbound I'd like to
>> move forward with this one and get a number assigned to it. Thanks!
>>
>> Thanks to all for the discussion!
>>
>> On Fri, Sep 4, 2015 at 2:45 PM, Luke Dashjr <luke at dashjr.org> wrote:
>>
>>> On Friday, September 04, 2015 9:36:42 PM Andy Chase wrote:
>>> > I understand your concerns. What kinds of changes do you think should
>>> go
>>> > through a process like this? Just hard forks?
>>>
>>> The process loses meaning if it doesn't reflect reality. So only
>>> hardforks
>>> should go through the hardfork process; only softforks through the
>>> softfork
>>> process; etc. Trying to make one-size-fits-all just means de facto
>>> accepted
>>> BIPs wouldn't be recognised as such because nobody cares to meet the
>>> higher
>>> requirements.
>>>
>>> Luke
>>>
>>
>>
>> _______________________________________________
>> 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/20150906/574ed608/attachment.html>

2023-06-07 17:39:41

- reply

📅 Original date posted:2015-09-12
📝 Original message:Wanted to throw up here some feedback I got off-list. Source:
http://bitco.in/forum/threads/bitcoinxt-dispute-resolution-etc.36/#post-602
==== [1] ====
> Interesting.
>
> I like your idea that people can form representational groups which then collectively votes ("committees"). Basically an individual can delegate his vote to one, but take it away at any time. This allows one person to do the detail work on behalf of others.
>
> I think that your 2 week then 2 week process is too constrained. I would propose that the groups have 2 weeks to respond, then an indetermine time occurs where the BIP author can work to resolve the open questions by corresponding directly with the groups. Then 2 week final arguments and voting.
>
> I think a clear definition of what "accepted" means would be important. I think that "accepted" should mean that the master github branch, and relevant project releases should incorporate the BIP as soon as reasonably possible after a branch is created that passes security and code competence checks. In other words, the "YES" votes may have to implement the BIP or pay to have it implemented.
>
> I think that you need to clearly define how the different groups prove their stake, and perhaps specify maximum ratios. That is, you can't have 100 committees with 99 merchant processors and 1 miner.
==== [2] ====
Timeline
--------
that's an important point. I've gotten that echoed from a few people
now. I was thinking that a re-submit could be called if more time is
needed but I think your method of allowing the author to have control
over the pace makes a lot of sense.
What does accepted mean? "Accepted" is the hardest thing to grasp in
this paper. There's just no way to force client authors, users, and
miners, to integrate and use a change, even if one is accepted by my
process. I.e. I'm trying to define what "accepted" even means, but
maybe I should use different words that don't have baggage. Like my
process could indicate "community greenlight" and client authors who
refuse to follow "community greenlight" can do so, but they are going
against the wishes of the community and that becomes obvious. Other
client others (like btcd) might follow the greenlight recommendation
instead and users are free to switch to that. Then there could also be
"community redlight", and "no decision reached" in which there was
conflicting views.
If I go this route, I could use the word "accepted" to mean something
like "appears in the longest fork", or "is in use by multiple clients,
merchants, & users" (for things like urls that aren't
blockchain-related).
How to prove stake?
--------------------
"How groups prove their stake" is the hard question that has to be
addressed in this proposal or any. I've pushed forward several
recommendations but there's no perfect solution that everyone will
accept. For users, in the comments I suggested a "community sample"
method that requires that only a random few people in a group to give
up their privacy.
Ratios
------
The "accepted" or "greenlit" standard in my proposal is defined as:
least 70% of the represented percentage stake in 3 out of the 4
Bitcoin segments. It's true that it seems weird to have 1 group in a
segment by itself (seems like too much power), you have to recall that
committees can consist of several groups that have agreed to act
together. If the 1 miner group had conflicts they'd separate to make
public both their views.
I'm interested in if you think that definition should be changed or if
you are worried about those risks.
==== [3] ====
> What does accepted mean?
> ------------------------
>
> I like your "community greenlight" idea to cover how BIPs apply to the larger community of wallet providers. However, I also think that there should be stronger language applied to the Bitcoin Core or Bitcoin XT (if a XIP is submitted). That language should make it absolutely clear that committers can't revert or refuse to commit a change that implements the "greenlighted" BIP just because they don't agree with it.
>
> How to prove stake?
> -------------------
>
> I think we need to nail this down (even if imperfectly) to make this BIP real. Personally, I think that there should be at least one way to anonymously vote (say by owning coins). But I don't feel that there's any need to preserve anonymity for the other stakeholders. In fact, for some groups I think it would be bad to allow anonymous voters. If you own a bunch of coins, or prove massive mining capacity, there can be no doubt that you are incentivized to vote for what is best for bitcoin. But some vocal forum writer, speaker or professor might not care about Bitcoin's ultimate success, or be a paid shill or sockpuppet. But requiring identity at least these people are putting a little bit of their personal reputation behind their comments. Of course, companies already disclose their identities so no problem there.
>
> But how do we choose which indirect stakeholders (companies, etc) get a vote? All I can think is that coin owners vote that this company is in fact important... this would be a once every 5 years or something vote not something you can give or take away every time a BIP is proposed.
>
> Ratios
> ------
>
> Somehow I missed that in your doc. Your proposal seems ok, although it may be hard to get consensus at those levels. And honestly I think that miners have too much power already -- I think that Bitcoin should be optimizing itself for users not for infrastructure. At the same time, I hope that miners realize that their business model requires consumer users (vs corporate users like bank 2 bank) so will probably vote what they believe is best for consumers..
On Wed, Sep 9, 2015 at 6:21 PM, Andy Chase <theandychase at gmail.com> wrote:
> Thanks for your response BTC Drak, I will attempt to summarize your
> points and respond to them:
>
> * Some BIPs are not consensus critical -- True, see my response to Luke
> * BIPs do not imply usage -- This I covered in my paper.
> * Acceptance can be defined by actual use -- That's one way of doing it
>
>> Getting back to your specific proposal. It seems to focus more on
>> getting BIPs accepted in the sense of published
>
> Wildly incorrect. My BIP had nothing to do with getting published. The
> first words you can read in my proposal are as follows:
>
>> The current process for accepting a BIP is not clearly defined. While BIP-0001 defines the process for writing and submitting a Bitcoin Improvement Proposal to the community it does not specify the precise method for which BIPs are considered accepted or rejected. This proposal sets up a method for determining BIP acceptance.
>
> * but the proposal is "complete" when the proposer is happy with the final text.
>
> This would be a cool inclusion. That is the intent of my "Submit for
> comments" process.
>
> ---
>
> Overall your post seemed to miss the point of my proposal, but that's
> likely my fault for poor wording. I'm trying to develop a process of
> coming to "consensus" i.e. gathering feedback and reducing opinions
> down to a yes/no should this BIP happen or should we find a better
> solution.
>
> Importantly, it's not client specific. It's just a way of saying "hey
> everyone, here's a problem and solution that a lot of people agree on"
> or "hey everyone, here's a problem and solution that has a few
> problems with it"
>
> It's true that even if a "BIP" is "accepted" by my proposal it still
> may not actually happen (this is mentioned in my proposal), and I
> believe that's healthy. We can't force a change on anyone nor should
> we.
>
> ---
>
> Since so many people are missing the actual problem I'm solving,
> here's another way of wording it: A BIP is proposed and goes through
> the process. A PR is submitted that matches the BIP perfectly, and is
> submitted and vetted. Should wladimir merge it?
>
> My process isn't perfect solution that would make it so we could
> replace wladimir with a wladBot. But it's a tool we can use for
> gathering meaningful information to help guide that decision. Waiting
> on all objections to be handled works okay so far but won't work
> forever.
>
>
> On Mon, Sep 7, 2015 at 12:37 PM, Btc Drak <btcdrak at gmail.com> wrote:
>>
>> Sorry not to reply earlier. I have a rather long post. I've split it
>> into two sections, one explaining the background and secondly talking
>> very specifically about your proposal and possible areas to look at.
>>
>> I think there's a key misunderstanding about BIPs and "who decides
>> what in Bitcoin". A BIP usually defines some problem and a solutions
>> or helps communicate proposals to the technical community. They are
>> sort of mini white papers on specific topics often with reference
>> implementations attached. They may be consensus critical, or not. The
>> process for getting a BIP published is fairly loose in that it really
>> just requires some discussion and relevance to Bitcoin regardless of
>> whether the proposal is something that would be accepted or used by
>> others in the ecosystem. The BIP editor is obviously going to filter
>> out obvious nonesense and that shouldn't be controversial but obvious
>> when you see it.
>>
>> You need to separate out the idea of BIPs as is, and implementations
>> of BIPs in Bitcoin software (like Bitcoin Core).
>>
>> Take BIP64 for example. It's a proposal that adds a service to nodes
>> allowing anyone to query the UTXO set on the p2p network. Bitcoin Core
>> as a project has not implemented it but was instead implemented in XT
>> and is utilised by Lighthouse. So the BIP specification is there in
>> the BIPs repository. As far as the bitcoin ecosystem goes, only
>> Bitcoin XT and lighthouse utilise it so far.
>>
>> BIP101 is another example, but one of a consensus critical proposal
>> that would change the Bitcoin protocol (i.e. requires a hard fork). It
>> was adopted by only the XT project and so far no other software. At
>> the time of writing miners have chosen not to run implementations of
>> BIP101.
>>
>> You can see the BIPs authoring and publishing process is a separate
>> issue entirely to the implementation and acceptance by the Bitcoin
>> ecosystem.
>>
>> For non-consensus critical proposals like BIP64, or maybe one relating
>> to privacy (how to order transaction output for example), you could
>> judge acceptance of the proposal by the number of software projects
>> that implement the proposal, and the number of users it impacts. If a
>> proposal is utilised by many projects, but not the few projects that
>> have the majority of users, one could not claim wide acceptance.
>>
>> For consensus critical proposals like BIP66 (Strict DER encoding) this
>> BIP was implemented in at least two bitcoin software implementations.
>> Over 95% of miners adopted the proposal over a 4.5 month period. The
>> BIP became de facto accepted, and in fact, once 95% lock-in was
>> achieved, the BIP became Final by rights that the consensus rules for
>> the Bitcoin network had changed.
>>
>> In the case of consensus critical proposals like that, you can only
>> write proposals, implement it in software and hope they are adopted.
>>
>> Now where does the confusion arise? Well, Bitcoin Core is the de facto
>> reference implementation by virtue of having the largest technical
>> contributor base and the widest userbase of any Bitcoin full node
>> implementation. This is where I believe, the community get stuck in
>> their assumptions and is so obvious it may have been overlooked.
>>
>> Consensus rule changes to Bitcoin Core are always documented as BIPs
>> so the exact details can be picked up by other software implementers
>> (if they so desire). Take CHECKLOCKTIMEVERIFY a new widely anticipated
>> opcode. The proposal implemented in Bitcoin Core and eventually
>> merged. Peter also authored BIP65 (required because without it, his
>> proposal could not be considered for Bitcoin Core).
>>
>> It is not that BIP65 was somehow "accepted", in fact, as it stands,
>> BIP65 is still just a draft because while there is a BIP and a
>> reference implementation in Bitcoin Core, the consensus changes to the
>> Bitcoin protocol have not been proposed to the community (through a
>> soft fork), and thus acceptance is still only a possibility (although
>> acceptance is extremely likely because service providers are literally
>> chomping at the bit waiting for deployment).
>>
>> Also I would like to note that it's only an internal rule of Bitcoin
>> Core that consensus rule changes require a formal BIP. It is not a
>> requirement laid down from the BIP gods. BIPs simply serve as a way to
>> communicate ideas and proposals. The community at large will decide if
>> a BIP becomes widely adopted or not. Of course, Bitcoin Core has a
>> major influence on this because they have the largest user base. It is
>> relevant to say the large userbase is not just a historical artefact
>> by virtue of being the first Bitcoin implementation. Bitcoin Core is
>> widely trusted by commercial users because of the high developer
>> count, wide technical expertise and relative security given knowing
>> that they will be supported with security and maintenance releases.
>>
>> YOUR PROPOSAL
>>
>> Getting back to your specific proposal. It seems to focus more on
>> getting BIPs accepted in the sense of published and missed the wider
>> picture. As I have detailed, getting published isnt a problem. Anyone
>> can make a proposal, so long as it's not obviously off topic or
>> nonsensical, there is no grounds to refuse to publish it.
>>
>> Any part of your proposal which seems to infer governance of Bitcoin
>> is misplaced because it's not the place of BIPs. The Bitcoin Core
>> project is not the BIPs project and their rules are their own. They
>> are one implementation, and very influential one yes, but, not the one
>> true implementation to rule them all.
>>
>> Where I do think the BIP-1 text falls down is with the workflow of
>> ACCEPTED/REJECTED because it does not really define who is accepting
>> and rejecting what and misses much of the reality of the process in
>> the real world. Given the purpose of BIPs is a formal way to
>> communicate technical proposals to the bitcoin community (i.e.
>> implementers and protocol consumers) the work flow needs to be
>> adjusted.
>>
>> Anyone can submit a proposal and the state of the proposal can be
>> DRAFT or WITHDRAWN but draft here is confusing. Draft would suggest
>> it's a work in progress, but the proposal is "complete" when the
>> proposer is happy with the final text. Downstream implementers should
>> not attempt to write code (in my opinion) until the proposal has been
>> finalised by the authors. Only the author has the right to say when
>> their proposal is finished.
>>
>> The states of Accepted / Rejected are easy for consensus critical
>> changes, especially once versionbits softforking is enacted and
>> proposals will have a timeout associated. Certainly for deployed
>> proposals you could say the proposal is "active" or better still
>> "pending approval". However "accepted" and "rejected" is difficult for
>> say privacy standards because how can you gauge or measure it. As I
>> said earlier, you might have a lot of small projects implementing some
>> privacy standards, but if the major wallets dont, and thus the
>> majority of users, how would you gauge it?
>>
>> Something is a standard only when it becomes a standard by virtue of
>> having become a standard :)
>>
>> "Replaced" is an easy state, when another proposal supercedes and
>> replaces an older one. Again the wording could be better here.
>> "deprecated" would also be appropriate in some circumstances.
>>
>> I'm not making a concrete proposal, I'm just highlighting where BIP-1
>> sort of falls apart because of an incongruence with the workflow
>> states and what actually happens in real life.
>>
>> Local to the BIPs project, I do think the BIPs editor, and guidelines
>> try to filter proposals by raising the bar: i.e. requiring proposal to
>> be polished through peer review before they are formally published as
>> draft BIPs. Though this process an author would a) get most of his
>> details right first time, and b) have some relative confidence his/her
>> idea was useful and withdraw any obvious bad proposals themselves. An
>> author may still decide, despite many objections from their peers they
>> want to proceed with publishing and nothing should stop them providing
>> it's relevant to the Bitcoin space. Peer review pressure is likely to
>> act as the best filtering mechanism in this case anyway (no-one would
>> want to be seen as an ass right?). Personally speaking, I felt quite
>> nervous proposing my own blocksize ideas. I sought opinions in private
>> first and had it been widely decried would probably not have pursued
>> it any further.
>>
>> So in summary, I think some aspects of BIP-1 could do with polishing
>> as I have detailed, specially around the "workflow states" but not to
>> introduce any committees to the process, but where possible to extract
>> state from the real state of the BIP in the real world. In fact, this
>> is my direct argument against any forms of committee, in that the
>> state of a BIP is determined by factors outside of any particular
>> individual's or groups' purview.
>>

2023-06-07 17:39:40

- reply

📅 Original date posted:2015-09-09
📝 Original message:Thanks for your response BTC Drak, I will attempt to summarize your
points and respond to them:
* Some BIPs are not consensus critical -- True, see my response to Luke
* BIPs do not imply usage -- This I covered in my paper.
* Acceptance can be defined by actual use -- That's one way of doing it
> Getting back to your specific proposal. It seems to focus more on
> getting BIPs accepted in the sense of published
Wildly incorrect. My BIP had nothing to do with getting published. The
first words you can read in my proposal are as follows:
> The current process for accepting a BIP is not clearly defined. While BIP-0001 defines the process for writing and submitting a Bitcoin Improvement Proposal to the community it does not specify the precise method for which BIPs are considered accepted or rejected. This proposal sets up a method for determining BIP acceptance.
* but the proposal is "complete" when the proposer is happy with the final text.
This would be a cool inclusion. That is the intent of my "Submit for
comments" process.
---
Overall your post seemed to miss the point of my proposal, but that's
likely my fault for poor wording. I'm trying to develop a process of
coming to "consensus" i.e. gathering feedback and reducing opinions
down to a yes/no should this BIP happen or should we find a better
solution.
Importantly, it's not client specific. It's just a way of saying "hey
everyone, here's a problem and solution that a lot of people agree on"
or "hey everyone, here's a problem and solution that has a few
problems with it"
It's true that even if a "BIP" is "accepted" by my proposal it still
may not actually happen (this is mentioned in my proposal), and I
believe that's healthy. We can't force a change on anyone nor should
we.
---
Since so many people are missing the actual problem I'm solving,
here's another way of wording it: A BIP is proposed and goes through
the process. A PR is submitted that matches the BIP perfectly, and is
submitted and vetted. Should wladimir merge it?
My process isn't perfect solution that would make it so we could
replace wladimir with a wladBot. But it's a tool we can use for
gathering meaningful information to help guide that decision. Waiting
on all objections to be handled works okay so far but won't work
forever.
On Mon, Sep 7, 2015 at 12:37 PM, Btc Drak <btcdrak at gmail.com> wrote:
>
> Sorry not to reply earlier. I have a rather long post. I've split it
> into two sections, one explaining the background and secondly talking
> very specifically about your proposal and possible areas to look at.
>
> I think there's a key misunderstanding about BIPs and "who decides
> what in Bitcoin". A BIP usually defines some problem and a solutions
> or helps communicate proposals to the technical community. They are
> sort of mini white papers on specific topics often with reference
> implementations attached. They may be consensus critical, or not. The
> process for getting a BIP published is fairly loose in that it really
> just requires some discussion and relevance to Bitcoin regardless of
> whether the proposal is something that would be accepted or used by
> others in the ecosystem. The BIP editor is obviously going to filter
> out obvious nonesense and that shouldn't be controversial but obvious
> when you see it.
>
> You need to separate out the idea of BIPs as is, and implementations
> of BIPs in Bitcoin software (like Bitcoin Core).
>
> Take BIP64 for example. It's a proposal that adds a service to nodes
> allowing anyone to query the UTXO set on the p2p network. Bitcoin Core
> as a project has not implemented it but was instead implemented in XT
> and is utilised by Lighthouse. So the BIP specification is there in
> the BIPs repository. As far as the bitcoin ecosystem goes, only
> Bitcoin XT and lighthouse utilise it so far.
>
> BIP101 is another example, but one of a consensus critical proposal
> that would change the Bitcoin protocol (i.e. requires a hard fork). It
> was adopted by only the XT project and so far no other software. At
> the time of writing miners have chosen not to run implementations of
> BIP101.
>
> You can see the BIPs authoring and publishing process is a separate
> issue entirely to the implementation and acceptance by the Bitcoin
> ecosystem.
>
> For non-consensus critical proposals like BIP64, or maybe one relating
> to privacy (how to order transaction output for example), you could
> judge acceptance of the proposal by the number of software projects
> that implement the proposal, and the number of users it impacts. If a
> proposal is utilised by many projects, but not the few projects that
> have the majority of users, one could not claim wide acceptance.
>
> For consensus critical proposals like BIP66 (Strict DER encoding) this
> BIP was implemented in at least two bitcoin software implementations.
> Over 95% of miners adopted the proposal over a 4.5 month period. The
> BIP became de facto accepted, and in fact, once 95% lock-in was
> achieved, the BIP became Final by rights that the consensus rules for
> the Bitcoin network had changed.
>
> In the case of consensus critical proposals like that, you can only
> write proposals, implement it in software and hope they are adopted.
>
> Now where does the confusion arise? Well, Bitcoin Core is the de facto
> reference implementation by virtue of having the largest technical
> contributor base and the widest userbase of any Bitcoin full node
> implementation. This is where I believe, the community get stuck in
> their assumptions and is so obvious it may have been overlooked.
>
> Consensus rule changes to Bitcoin Core are always documented as BIPs
> so the exact details can be picked up by other software implementers
> (if they so desire). Take CHECKLOCKTIMEVERIFY a new widely anticipated
> opcode. The proposal implemented in Bitcoin Core and eventually
> merged. Peter also authored BIP65 (required because without it, his
> proposal could not be considered for Bitcoin Core).
>
> It is not that BIP65 was somehow "accepted", in fact, as it stands,
> BIP65 is still just a draft because while there is a BIP and a
> reference implementation in Bitcoin Core, the consensus changes to the
> Bitcoin protocol have not been proposed to the community (through a
> soft fork), and thus acceptance is still only a possibility (although
> acceptance is extremely likely because service providers are literally
> chomping at the bit waiting for deployment).
>
> Also I would like to note that it's only an internal rule of Bitcoin
> Core that consensus rule changes require a formal BIP. It is not a
> requirement laid down from the BIP gods. BIPs simply serve as a way to
> communicate ideas and proposals. The community at large will decide if
> a BIP becomes widely adopted or not. Of course, Bitcoin Core has a
> major influence on this because they have the largest user base. It is
> relevant to say the large userbase is not just a historical artefact
> by virtue of being the first Bitcoin implementation. Bitcoin Core is
> widely trusted by commercial users because of the high developer
> count, wide technical expertise and relative security given knowing
> that they will be supported with security and maintenance releases.
>
> YOUR PROPOSAL
>
> Getting back to your specific proposal. It seems to focus more on
> getting BIPs accepted in the sense of published and missed the wider
> picture. As I have detailed, getting published isnt a problem. Anyone
> can make a proposal, so long as it's not obviously off topic or
> nonsensical, there is no grounds to refuse to publish it.
>
> Any part of your proposal which seems to infer governance of Bitcoin
> is misplaced because it's not the place of BIPs. The Bitcoin Core
> project is not the BIPs project and their rules are their own. They
> are one implementation, and very influential one yes, but, not the one
> true implementation to rule them all.
>
> Where I do think the BIP-1 text falls down is with the workflow of
> ACCEPTED/REJECTED because it does not really define who is accepting
> and rejecting what and misses much of the reality of the process in
> the real world. Given the purpose of BIPs is a formal way to
> communicate technical proposals to the bitcoin community (i.e.
> implementers and protocol consumers) the work flow needs to be
> adjusted.
>
> Anyone can submit a proposal and the state of the proposal can be
> DRAFT or WITHDRAWN but draft here is confusing. Draft would suggest
> it's a work in progress, but the proposal is "complete" when the
> proposer is happy with the final text. Downstream implementers should
> not attempt to write code (in my opinion) until the proposal has been
> finalised by the authors. Only the author has the right to say when
> their proposal is finished.
>
> The states of Accepted / Rejected are easy for consensus critical
> changes, especially once versionbits softforking is enacted and
> proposals will have a timeout associated. Certainly for deployed
> proposals you could say the proposal is "active" or better still
> "pending approval". However "accepted" and "rejected" is difficult for
> say privacy standards because how can you gauge or measure it. As I
> said earlier, you might have a lot of small projects implementing some
> privacy standards, but if the major wallets dont, and thus the
> majority of users, how would you gauge it?
>
> Something is a standard only when it becomes a standard by virtue of
> having become a standard :)
>
> "Replaced" is an easy state, when another proposal supercedes and
> replaces an older one. Again the wording could be better here.
> "deprecated" would also be appropriate in some circumstances.
>
> I'm not making a concrete proposal, I'm just highlighting where BIP-1
> sort of falls apart because of an incongruence with the workflow
> states and what actually happens in real life.
>
> Local to the BIPs project, I do think the BIPs editor, and guidelines
> try to filter proposals by raising the bar: i.e. requiring proposal to
> be polished through peer review before they are formally published as
> draft BIPs. Though this process an author would a) get most of his
> details right first time, and b) have some relative confidence his/her
> idea was useful and withdraw any obvious bad proposals themselves. An
> author may still decide, despite many objections from their peers they
> want to proceed with publishing and nothing should stop them providing
> it's relevant to the Bitcoin space. Peer review pressure is likely to
> act as the best filtering mechanism in this case anyway (no-one would
> want to be seen as an ass right?). Personally speaking, I felt quite
> nervous proposing my own blocksize ideas. I sought opinions in private
> first and had it been widely decried would probably not have pursued
> it any further.
>
> So in summary, I think some aspects of BIP-1 could do with polishing
> as I have detailed, specially around the "workflow states" but not to
> introduce any committees to the process, but where possible to extract
> state from the real state of the BIP in the real world. In fact, this
> is my direct argument against any forms of committee, in that the
> state of a BIP is determined by factors outside of any particular
> individual's or groups' purview.
>

2023-06-07 17:39:39

- reply

📅 Original date posted:2015-09-05
📝 Original message:Okay for sure yeah writing another proposal that reflects the current state
of affairs as people see it might provide some interesting perspective on
this proposal. I would welcome that.
Greg: With no other direct comments appearing to be inbound I'd like to
move forward with this one and get a number assigned to it. Thanks!
Thanks to all for the discussion!
On Fri, Sep 4, 2015 at 2:45 PM, Luke Dashjr <luke at dashjr.org> wrote:
> On Friday, September 04, 2015 9:36:42 PM Andy Chase wrote:
> > I understand your concerns. What kinds of changes do you think should go
> > through a process like this? Just hard forks?
>
> The process loses meaning if it doesn't reflect reality. So only hardforks
> should go through the hardfork process; only softforks through the softfork
> process; etc. Trying to make one-size-fits-all just means de facto accepted
> BIPs wouldn't be recognised as such because nobody cares to meet the higher
> requirements.
>
> Luke
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150905/9e4999b0/attachment.html>

2023-06-07 17:39:38

- reply

📅 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>

2023-06-07 17:39:36

- reply

📅 Original date posted:2015-09-04
📝 Original message:Thanks for your thoughts.
My proposal isn't perfect for sure. There's likely much better ways to do
it. But to be clear what I'm trying to solve is basically this:
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.
---
My motivation for writing this proposal is stated right at the start:
> "The current process for accepting a BIP is not clearly defined. While
BIP-0001 defines the process for writing and submitting a Bitcoin
Improvement Proposal to the community it does not specify the precise
method for which BIPs are considered accepted or rejected."
BIPs are considered "accepted" right now based on an undefined system,
quite honestly. Btc Drak: What's the system for accepting a BIP? Words like
"consensus" come up but they aren't defined. My goal is to define a system
that makes finding "consensus" (I like the word "acceptance" better) in a
clear and fair way.
I.e. what's broken?
* Being sure that a proposal is widely accepted or rejected
* Preventing deadlock (i.e. one person's weak objections preventing
acceptance)
* Receiving feedback from important segments like user groups,
merchants/exchanges, etc. in a systematic and clear way instead of going
and forth or having "oracles" on technical advisory boards.
> Yes the process is loose, but is it broken?
Yes/No. Work gets done with the current process. Work can get done with
this process. The goal is for this process is to be safer/clearer/better
defined way.
> There have been a flood of
> BIPs added recently with zero bureaucracy or friction.
As we move forward, we want to balance the powers in such a way that we may
want to pause a bit before we accept each proposal. 2 weeks for comments +
2 weeks for opinions will slow things down, but it shouldn't stall
meaningful work. I used 4 weeks for the process with the understanding that
most proposals are clear and easily acceptable. Controversial proposals
will likely need more time and thus will likely have be submitted at least
twice to discover a clear response.
"Accepting" a BIP means just that: It's accepted. What's acceptance mean?
This proposal provides an answer.
Client implementations, users, miners, and merchants can feel safe
implementing and using a feature that has clear acceptance. This process
isn't meant to force anything on client implementors, users, miners, or
merchants.
On Fri, Sep 4, 2015 at 12:20 PM, Btc Drak <btcdrak at gmail.com> wrote:
> I'm rather perplexed about this proposal. What exactly is wrong with
> the existing BIPs process? I mean, it seems to me anyone can publish a
> BIP pretty easily in the BIPs repository. There doesnt seems to be any
> real barrier to entry whatsoever. I know there have been all manner of
> aspersions, but having just written two BIPs there was no friction at
> all.
>
> Whether the ecosystem adopts a BIP is another question of course, but
> that's out of scope of the BIPs project anyhow. Take BIP101
> controversial as it gets, but it's there. Whether Bitcoin implementers
> implement it is another kettle of fish and a matter for each project
> to decide. It's absolutely NOT the realm of the BIPs project itself.
> Bitcoin Core does not make any consensus critical changes with a BIP.
> Where one seeks to establish certain standards, say for privacy, a BIP
> would be appropriate so the ecosystem can harmonise methodology across
> the board.
>
> The status of a BIP is not really determined by anyone, it's by
> adoption - that's where consensus happens. There's a little legroom
> around this but I'm not entirely sure what you are trying to solve.
> Yes the process is loose, but is it broken? There have been a flood of
> BIPs added recently with zero bureaucracy or friction.
>
> BIP0001 is the BIP that defines the BIP process. Interestingly enough
> the only BIP that might be controversial is in fact a BIP to change
> the way BIPs are handled!
>
> So I'd really prefer to start this conversation with a breakdown of
> what you think is broken first before tackling what may or may not
> need fixing. I would be very cautious bringing "administrative"
> burdens to the process or evicting common sense from the proceedings.
> Much of the debates around consensus building seem to negate the
> importance of common sense and the simple fact that "it's obvious when
> you see it".
>
> I'm sure there can be improvements, but for me personally, I need to
> see what is broken before I can make any judgement on a potential way
> forward, and if it's not broken, we should leave it alone.
>
>
> On Fri, Sep 4, 2015 at 5:40 AM, Andy Chase via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > As posted:
> >
> > **Enforcement/Organization** I agree with your comments. I don't believe
> in
> > setting up an organization to manage this process (would be too much
> power
> > and not really needed because the internet is pretty good at information
> > sharing). Therefore, I designed it around the assumption that
> participation
> > is voluntary. This means that it's hard to enforce rules like forcing
> groups
> > to see the other side. Groupthink/Echo chambers is real and is bad but
> it's
> > hard to change human nature.
> >
> > In regards to enforcement, I believe that the best approach would be to
> > motivate committees to produce the best opinion they can (and also proof
> of
> > stake, another weak point in this proposal), as the better they can do
> this
> > the more likely the community will accept their opinion as valid and
> > important.
> >
> > Indeed, I believe that without an organization managing the process,
> it's up
> > to each individual reader of each BIP/Opinions set to make the decision
> on
> > whether or not there is clear and true community acceptance.
> >
> > ----
> >
> > **Committee versus another approach**
> >
> > Pros of using Committees:
> >
> > * Committees are used today in many fields with a range of success. Lots
> of
> > previous work to work off of here, history is established.
> > * Many segments already have committee-like structures (Merchants produce
> > shared signed documents, miners often represent themselves, User groups
> have
> > representatives like voting on subreddit moderators, Core Devs have Core
> > Devs)
> > * Committees can filter a range of opinions down to a yes/no
> > * Committees have real people that can be talked to, contacted, etc.
> > * Much easier to proof stake in a range (People generally accept the
> Bitcoin
> > Core has 70-90% of the market share) vs someone trying to proof they
> make up
> > (.000001% of the Bitcoin user-base)
> > * Committees have some stability, encourages experience and expertise
> > (Committee members can be knowledgeable in their area and adequately
> > understand BIPs)
> >
> > Cons:
> >
> > * Fear of committees working in the dark, censoring opinions (i.e. "Dark
> > smokey room of fat cats") (Possible solution: make committee power fluid
> > i.e. easily abandon-able: miners can change pools, users can change
> client
> > forks, change merchants, users can re-group, encourage transparency)
> > * More centralized, centralization of power (generally bad) (Possible
> > solution: encourage smaller committees)
> > * Centralization pressure (groups may seek to consolidate to gain power)
> > (Possible solution: Segmentation)
> > * Encourages groupthink, political maneuvers, turns good people into
> > politicians, mud-tossing
> >
> > **Another possible approach: micro votes**
> >
> > Pros:
> >
> > * Each user can represent themselves, no censorship
> > * People feel more involved and empowered
> >
> > Cons:
> >
> > * How to prove and prevent manipulation?
> > * Only motivated people will contribute. Motivated people may be
> motivated
> > for bad reasons.
> >
> >
> > On Thu, Sep 3, 2015 at 5:43 PM, Bryan Bishop <kanzure at gmail.com> wrote:
> >>
> >> On Thu, Sep 3, 2015 at 7:30 PM, Andy Chase via bitcoin-dev
> >> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >> > I wrote the BIP mostly to stir the pot on ideas of governance
> >>
> >> Some quick comments:
> >>
> >> I have some objects that I am not ready to put into words, but I do
> >> think there are easily some major objections to committee design. If I
> >> vanish and never respond with my objections, perhaps there's an IETF
> >> RFC about this already....
> >>
> >> Something that may mitigate my possible objections would be some
> >> mandatory requirement about ecosystem echo-chambers making many
> >> attempts and efforts at steelman representations of alternative
> >> viewpoints. Understanding objections at a fundamental level, enough to
> >> make strong steelman statements, is very important to ensure that the
> >> competing opinions are not censored from consideration. Pathological
> >> integration and internalization of these steelman arguments can be
> >> very useful, even if the process looks unusual.
> >>
> >> Your process does not have to replace any particular BIP process
> >> as-is, but rather could be an alternative that proceeds on its own
> >> perhaps indefinitely without replacement. I don't think too many BIP
> >> processes are necessarily incompatible except by namespace collision.
> >>
> >>
> https://gist.github.com/andychase/dddb83c294295879308b#gistcomment-1566432
> >>
> >> - Bryan
> >> http://heybryan.org/
> >> 1 512 203 0507
> >
> >
> >
> > _______________________________________________
> > 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/20150904/1cc7ed2b/attachment-0001.html>

2023-06-07 17:39:35

- reply

📅 Original date posted:2015-09-04
📝 Original message:As posted:
**Enforcement/Organization** I agree with your comments. I don't believe in
setting up an organization to manage this process (would be too much power
and not really needed because the internet is pretty good at information
sharing). Therefore, I designed it around the assumption that participation
is voluntary. This means that it's hard to enforce rules like forcing
groups to see the other side. Groupthink/Echo chambers is real and is bad
but it's hard to change human nature.
In regards to enforcement, I believe that the best approach would be to
motivate committees to produce the best opinion they can (and also proof of
stake, another weak point in this proposal), as the better they can do this
the more likely the community will accept their opinion as valid and
important.
Indeed, I believe that without an organization managing the process, it's
up to each individual reader of each BIP/Opinions set to make the decision
on whether or not there is clear and true community acceptance.
----
**Committee versus another approach**
Pros of using Committees:
* Committees are used today in many fields with a range of success. Lots of
previous work to work off of here, history is established.
* Many segments already have committee-like structures (Merchants produce
shared signed documents, miners often represent themselves, User groups
have representatives like voting on subreddit moderators, Core Devs have
Core Devs)
* Committees can filter a range of opinions down to a yes/no
* Committees have real people that can be talked to, contacted, etc.
* Much easier to proof stake in a range (People generally accept the
Bitcoin Core has 70-90% of the market share) vs someone trying to proof
they make up (.000001% of the Bitcoin user-base)
* Committees have some stability, encourages experience and expertise
(Committee members can be knowledgeable in their area and adequately
understand BIPs)
Cons:
* Fear of committees working in the dark, censoring opinions (i.e. "Dark
smokey room of fat cats") (Possible solution: make committee power fluid
i.e. easily abandon-able: miners can change pools, users can change client
forks, change merchants, users can re-group, encourage transparency)
* More centralized, centralization of power (generally bad) (Possible
solution: encourage smaller committees)
* Centralization pressure (groups may seek to consolidate to gain power)
(Possible solution: Segmentation)
* Encourages groupthink, political maneuvers, turns good people into
politicians, mud-tossing
**Another possible approach: micro votes**
Pros:
* Each user can represent themselves, no censorship
* People feel more involved and empowered
Cons:
* How to prove and prevent manipulation?
* Only motivated people will contribute. Motivated people may be motivated
for bad reasons.
On Thu, Sep 3, 2015 at 5:43 PM, Bryan Bishop <kanzure at gmail.com> wrote:
> On Thu, Sep 3, 2015 at 7:30 PM, Andy Chase via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > I wrote the BIP mostly to stir the pot on ideas of governance
>
> Some quick comments:
>
> I have some objects that I am not ready to put into words, but I do
> think there are easily some major objections to committee design. If I
> vanish and never respond with my objections, perhaps there's an IETF
> RFC about this already....
>
> Something that may mitigate my possible objections would be some
> mandatory requirement about ecosystem echo-chambers making many
> attempts and efforts at steelman representations of alternative
> viewpoints. Understanding objections at a fundamental level, enough to
> make strong steelman statements, is very important to ensure that the
> competing opinions are not censored from consideration. Pathological
> integration and internalization of these steelman arguments can be
> very useful, even if the process looks unusual.
>
> Your process does not have to replace any particular BIP process
> as-is, but rather could be an alternative that proceeds on its own
> perhaps indefinitely without replacement. I don't think too many BIP
> processes are necessarily incompatible except by namespace collision.
>
> https://gist.github.com/andychase/dddb83c294295879308b#gistcomment-1566432
>
> - Bryan
> http://heybryan.org/
> 1 512 203 0507
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150903/77939aff/attachment-0001.html>

2023-06-07 17:39:35

- reply

📅 Original date posted:2015-09-03
📝 Original message:> Any such a BIP like this needs to
> document the natural forces involved in real-world acceptance, not try to
lay
> down "rules" that people are expected to follow.
That's my goal: to take the hodgepodge of we already use for acceptance,
and apply rules that allow true acceptance to be identified in a clearer
way.
If people don't follow the "rules" then the system simply won't work, this
is mentioned in the last section.
On Thu, Sep 3, 2015 at 5:41 PM, Luke Dashjr <luke at dashjr.org> wrote:
> On Friday, September 04, 2015 12:30:50 AM Andy Chase via bitcoin-dev wrote:
> > Here's a BIP. I wrote the BIP mostly to stir the pot on ideas of
> > governance, but I’m moderately serious about it.
>
> Sigh. There is *no governance at all*. Any such a BIP like this needs to
> document the natural forces involved in real-world acceptance, not try to
> lay
> down "rules" that people are expected to follow.
>
> For hardforks, that means economic consensus. For softforks, miner
> majority.
> For basically anything else, real-world implementation and use (by any
> significant quantity of people).
>
> Luke
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150903/1f4e33fd/attachment.html>

2023-06-07 17:39:33

- reply

📅 Original date posted:2015-09-03
📝 Original message:Here’s a BIP. I wrote the BIP mostly to stir the pot on ideas of governance, but I’m moderately serious about it. This is set in Markdown for readability, but here’s the BIP-0001 Medawiki version: https://gist.github.com/andychase/dddb83c294295879308b <https://gist.github.com/andychase/dddb83c294295879308b>
Title: BIP Acceptance Process
Author: Andy Chase
Status: Draft
Type: Process
Created: 2015-08-31
Abstract
========
The current process for accepting a BIP is not clearly defined. While
BIP-0001 defines the process for writing and submitting a Bitcoin
improvement proposal to the community it does not specify the precise
method for which BIPs are considered accepted or rejected.
This proposal sets up a method for determining BIP acceptance.
This BIP has two parts:
- It sets up a process which a BIP goes through for comments
and acceptance.
- The Process is:
- BIP Draft
- Submitted for comments (2 weeks)
- Waiting on opinion (two weeks)
- Accepted or Deferred
- It sets up committees for reviewing comments and indicating
acceptance under precise conditions.
- Committees are authorized groups that represent client authors,
miners, merchants, and users (each as a segment). Each one must
represent at least 1% stake in the Bitcoin ecosystem.
BIP acceptance is defined as at least 70% of the represented percentage
stake in 3 out of the 4 Bitcoin segments.
Copyright
=========
This document is placed into the public domain.
Motivation
==========
BIPs represent important improvements to Bitcoin infrastructure, and in
order to foster continued innovation, the BIP process must have clearly
defined stages and acceptance acknowledgement.
Rationale
=========
A committee system is used to organize the essential concerns of each
segment of the Bitcoin ecosystem. Although each segment may have many
different viewpoints on each BIP, in order to seek a decisive yes/no on
a BIP, a representational authoritative structure is sought. This
structure should be fluid, allowing people to move away from committees
that do not reflect their views and should be re-validated on each BIP
evaluation.
Weaknesses
==========
Each committee submits a declaration including their claim to represent
a certain percentage of the Bitcoin ecosystem in some way. Though
guidelines are given, it's up to each committee to prove their stake,
and it's up to the reader of the opinions to decide if a BIP was truly
accepted or rejected.
The author doesn't believe this is a problem because a BIP cannot be
forced on client authors, miners, merchants, or users. Ultimately this
BIP is a tool for determining whether a BIP is overwhelmingly accepted.
If one committee's validity claim becomes the factor that decides
whether the BIP will succeed or fail, this process simply didn't return
a clear answer and the BIP should be considered deferred.
Process
=======
- **Submit for Comments.** The first BIP champion named in the
proposal can call a "submit for comments" at any time by posting to
the [Dev Mailing
List](https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>)
mailling with the BIP number and a statement that the champion
intends to immediately submit the BIP for comments.
- The BIP must have been assigned BIP-number (i.e. been approved
by the BIP editor) to be submitted for comments.
- **Comments.**
- After a BIP has been submitted for comments, a two-week waiting
period begins in which the community should transition from
making suggestions about a proposal to publishing their opinions
or concerns on the proposal.
- **Reported Opinions.**
- After the waiting period has past, committees must submit a
summary of the comments which they have received from their
represented communities.
- The deadline for this opinion is four weeks after the BIP was
submitted for comments.
- Committees cannot reverse their decision after the deadline, but
at their request may flag their decision as "likely to change if
another submit for comments is called". Committees can change
their decision if a resubmit is called.
- Opinions must include:
- One of the following statements: "Intend to accept", "Intent
to implement", "Decline to accept", "Intend to accept, but
decline to implement".
- If rejected, the opinion must cite clear and specific
reasons for rejecting including a checklist for what must
happen or be change for their committee to accept
the proposal.
- If accepted, the committee must list why they accepted the
proposal and also include concerns they have or what about
the BIP that, if things changed, would cause the committee
to likely reverse their decision if another submit for
comments was called.
- **Accepted.**
- If at least 70% of the represented percentage stake in 3 out of
4 segments accept a proposal, a BIP is considered accepted.
- If a committee fails to submit an opinion, consider the
opinion "Decline to accept".
- The BIP cannot be substantially changed at this point, but can
be replaced. Minor changes or clarifications are allowed but
must be recorded in the document.
- **Deferred.**
- The acceptance test above is not met, a BIP is sent back
into suggestions.
- BIP can be modified and re-submitted for a comments no sooner
than two months after the date of the previous submit for
comments is called.
- A BIP is marked rejected after two failed submission attempts. A
rejected BIP can still be modified and re-submitted.
Committees
==========
**BIP Committees.**
- BIP Committees are representational structures that represent
critical segments of the Bitcoin ecosystem.
- Each committee must prove and maintain a clear claim that they
represent at least 1% of the Bitcoin ecosystem in some form.
- If an organization or community does not meet that requirement,
it should conglomerate itself with other communities and
organizations so that it does.
- The segments that committees can be based around are:
- Bitcoin software
- Merchants/services/payment processors
- Mining operators
- User communities
- A person may be represented by any number of segments, but a
committee cannot re-use the same resource as another committee in
the same segment.
- **Committee Declarations.** At any point, a Committee Declaration
can be posted.
- This Declaration contain details about:
- The segment the Committee is representing
- Who the committee claim to represent and it's compositional
makeup (if made up of multiple miner orgs, user orgs, companies,
clients, etc).
- Proof of claim and minimum 1% stake via:
- Software: proof of ownership and user base (Min 1% of
Bitcoin userbase)
- Merchant: proof of economic activity (Min 1% of Bitcoin
economic activity)
- Mining: proof of work (Min 1% of Hashpower)
- For a user organization, auditable signatures qualifies for
a valid committee (Min 1% of Bitcoin userbase)
- Who is running the committee, their names and roles
- How represented members can submit comments to the committee
- A code of conduct and code of ethics which the committee
promises to abide by
- A committee declaration is accepted if:
- The declaration includes all of the required elements
- The stake is considered valid
- Committee validation is considered when considering the results of
opinions submitted by committee on a BIP. A committee must have met
the required stake percentage before a BIP is submitted for
comments, and have maintained that stake until a valid opinion
is submitted.
- Committees can dissolve at any time or submit a declaration at
any time
- Declaration must have been submitted no later than the third day
following a BIP's request for comments to be eligible for
inclusion in a BIP
BIP Process Management Role
===========================
BIPs, Opinions, and Committee Declaration must be public at all times.
A BIP Process Manager should be chosen who is in charge of:
- Declaring where and how BIPs, Opinions, and Committee Declaration
should be posted and updated officially.
- Maintaining the security and authenticity of BIPs, Opinions, and
Committee Declarations
- Publishing advisory documents about what kinds of proof of stakes
are valid and what kinds should be rejected.
- Naming a series of successors for the roles of the BIP Process
Manager and BIP Editor (BIP-001) as needed.
Conditions for activation
=========================
In order for this process BIP to become active, it must succeed by its
own rules. At least a 4% sample of the Bitcoin community must be
represented, with at least one committee in each segment included. Once
at least one committee has submitted a declaration, a request for
comments will be called and the process should be completed from there.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150903/79dda43f/attachment-0001.html>

2023-06-07 17:39:22

- reply

📅 Original date posted:2015-09-04
📝 Original message:The 32Mb limit is here:
https://github.com/bitcoin/bitcoin/blob/master/src/serialize.h#L25
It's to keep the message size small enough that messages can be serialized
in memory.
Jeff if you decide to lift the 32MB limit (you really should, unless your
plan is to potentially hard force another Blocksize discussion again which
might be okay). I suggest having the 32MB ceiling auto-raise according to a
exponential factor (1.5?) starting 1 year from now.
Basically hard limit ceiling 2016-2017: 32 MB
Hard limit ceiling 2018+: 32*((currentYear-2018)*1.5) MB
The factor could be 2 like BIP-101 but I imagine you will want to be more
conservative. The delay time could also be longer if you think it will take
longer to fix the message size issue across all implementations.
On Thu, Sep 3, 2015 at 4:59 AM, Tier Nolan via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>>
>> 1.
>>
>> hardLimit floats within the range 1-32M, inclusive.
>>
>>
>>
> Does the 32MB limit actually still exist anywhere in the code? In effect,
> it is re-instating a legacy limitation.
>
> The message size limit is to minimize the storage required per peer. If a
> 32MB block size is required, then each network input buffer must be at
> least 32MB. This makes it harder for a node to support a large number of
> peers.
>
> There is no reason why a single message is used for each block. Using the
> merkleblock message (or a different dedicated message), it would be
> possible to send messages which only contain part of a block and have a
> limited maximum size.
>
> This would allow receiving parts of a block from multiple sources.
>
> This is a separate issue but should be considered if moving past 32MB
> block sizes (or maybe as a later protocol change).
>
>
>>
>> 1. Changing hardLimit is accomplished by encoding a proposed value
>> within a block's coinbase scriptSig.
>> 1. Votes refer to a byte value, encoded within the pattern
>> "/BV\d+/" Example: /BV8000000/ votes for 8,000,000 byte hardLimit. If
>> there is more than one match with with pattern, the first match is counted.
>>
>> Is there a need for byte resolution? Using MB resolution would use up
> much fewer bytes in the coinbase.
>
> Even with the +/- 20% rule, miners could vote for the nearest MB. Once
> the block size exceeds 5MB, then there is enough resolution anyway.
>
>
>> 1. Absent/invalid votes and votes below minimum cap (1M) are counted
>> as 1M votes. Votes above the maximum cap (32M) are counted as 32M votes.
>>
>>
> I think abstains should count for the status quo. Votes which are out of
> range should be clamped.
>
> Having said that, if core supports the change, then most miners will
> probably vote one way or another.
>
> > New hardLimit is the median of the followings:
> > min(current hardLimit * 1.2, 20-percentile)
> > max(current hardLimit / 1.2, 80-percentile)
> > current hardLimit
>
> I think this is unclear, though mathematically exact.
>
> Sort the votes for the last 12,000 blocks from lowest to highest.
>
> Blocks which don't have a vote are considered a vote for the status quo.
>
> Votes are limited to +/- 20% of the current value. Votes that are out of
> range are considered to vote for the nearest in range value.
>
> The raise value is defined as the vote for the 2400th highest block (20th
> percentile).
> The lower value is defined as the vote for the 9600th highest block (80th
> percentile).
>
> If the raise value is higher than the status quo, then the new limit is
> set to the raise value.
> If the lower value is lower than the status quo, then the new limit is set
> to the lower value.
> Otherwise, the size limit is unchanged.
>
> _______________________________________________
> 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/20150904/7a2ee899/attachment.html>

2023-06-07 17:38:11

- reply

📅 Original date posted:2015-08-25
📝 Original message:As I understand Github is not to be used for the high-level discussion
of a draft BIP so I will post my thoughts here (is this specified
somewhere? Can we specify this in BIP-0001?).
- I have some concerns about the structure and the wording of this
proposal. I think both the structure and the internal wording can be
slimmed down and simplified
- I also believe the "history lessons" should be trimmed out,
mentioned at best
- There's separate BIP for at least one of the code forks
- BIP-001 specifies that BIP proposals should not be given a BIP
number until after they have been spelled checked and approved by an
editor. Greg Maxwell: was this followed?
- What kind of proposal is this? Informational, Process or Standards
track?
- I believe it should be Standards Track. Include the proposed
upgrade path as a patch into core as a module that hard forks
can use in the future. This will also give us some space to work
through some of the complexities of forks in a definite way.
- Alternatively maybe we can split up this BIP into a Standards
track and a separate Informational BIP?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150825/e42a53b9/attachment.html>