Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process

[Andy Chase via bitcoin-dev]

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 

Re: [bitcoin-dev] Named Bitcoin Addresses

[Andy Chase via bitcoin-dev]

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
 wrote:
> Are you aware of the payment protocol?
>
> On Sep 10, 2015 2:12 PM, "essofluffy . via bitcoin-dev"
>  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
>>
>>
>> 

Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process

[Andy Chase via bitcoin-dev]

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

[bitcoin-dev] [BIP/Draft] BIP Realistic Acceptance Process

[Andy Chase via bitcoin-dev]

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
   

Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process

[Andy Chase via bitcoin-dev]

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.ke...@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@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 <l...@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@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process

[Andy Chase via bitcoin-dev]

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  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@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process

[Andy Chase via bitcoin-dev]

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 <btcd...@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@lists.linuxfoundation.org> wrote:
>

Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process

[Andy Chase via bitcoin-dev]

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 <l...@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
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP 100 specification

[Andy Chase via bitcoin-dev]

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@lists.linuxfoundation.org> wrote:

>
>
> On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev <
> bitcoin-dev@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: /BV800/ 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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process

[Andy Chase via bitcoin-dev]

> 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 <l...@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
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] BIP/Motivation and deployment of consensus rule changes ([soft/hard]forks)

[Andy Chase via bitcoin-dev]

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?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev