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] Bitcoin Days Destroyed as block selection heuristic

[Dave Scotese via bitcoin-dev]

>
> From the Bitcoin wiki page on transaction fees
> :
>
> Transaction priority is calculated as a value-weighted sum of input age,
> divided by transaction size in bytes: priority =
> sum(input_value_in_base_units * input_age)/size_in_bytes
>
If I read that correctly, that is directly proportional to BTCDD, so
whatever effect concerns you has already been built into the code.

On Fri, Sep 11, 2015 at 3:21 PM, Vincent Truong <
vincent.tru...@procabiak.com> wrote:

> Would this alter the way txns will be prioritised in order to try to win?
> You would always pick txns with the best BTCDD to maximize your chances of
> being the block to build on.
>
> I see this as potentially being a bad outcome for bitcoin's fungibility.
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev