Re: [bitcoin-dev] Segregated Witness App Development
Wouldn't this be entirely on topic for #bitcoin-dev? It's probably better not to fragment the communication channels and associated infrastructure (logs, bots, etc.) On Tue, Jan 19, 2016 at 3:54 AM, Eric Lombrozo via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hello, folks. > > I wanted to let all of you know a new IRC channel has been created called > #segwit-dev where we welcome all discussion pertaining to integrating and > supporting segregated witness transactions in wallets as well as comments > or suggestions for improvement to the spec. Please come join us. :) > > > —— > Eric > ___ > 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] Segregated Witness App Development
On Tue, Jan 19, 2016 at 10:27 AM, Mark Friedenbach via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Wouldn't this be entirely on topic for #bitcoin-dev? It's probably better > not to fragment the communication channels and associated infrastructure > (logs, bots, etc.) Yeah, I agree that this is on topic for #bitcoin-dev. I think that if segwit discussion got to the point of clouding out all other development discussions, then perhaps it would be time for a new channel. I would definitely like to see segwit discussion not fragmented into a separate venue. - Bryan http://heybryan.org/ 1 512 203 0507 ___ 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
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 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 ec
Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process
This seems like a good place to point out that attempts to identify individuals (either by name or simply as an individual human being) are futile as well as destructive. "1%" usually means "one out of every 100 people" but this requires identification of individuals as individuals. One person can look like many in Bitcoin, which is why such an effort is futile. Additionally, one person may be far more affected by a decision than others, which is why it's destructive. I like the idea of measuring consensus, and there are proto-ideas in my head about how that can be done, based not on individual people, but on amounts of bitcoin. Many will argue that we don't want the system to be controlled by those who hold the most bitcoin. I understand that sentiment, but A) I simply disagree, and B) Finding something better seems impossible to me. A simple method is the following: A message can be constructed saying: "As of block X, the holder(s) of Y BTC controlled by [public key] agrees that Z," where X, Y, Z, and the [public key] are the only things that change. This message can be signed by the private key matching the [public key] in the message. Anyone interested in measuring consensus on anything relative to bitcoin holders can advertise for such signed messages to be sent to a repository of their choice which would validate each message (that [public key] (still) holds Y BTC and that the signature is valid) and provide a measure of agreement about Z. Change your mind? Just move your BTC to a different address. On Mon, Jan 18, 2016 at 6:12 PM, Luke Dashjr via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.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 su
[bitcoin-dev] Segregated Witness App Development
Hello, folks. I wanted to let all of you know a new IRC channel has been created called #segwit-dev where we welcome all discussion pertaining to integrating and supporting segregated witness transactions in wallets as well as comments or suggestions for improvement to the spec. Please come join us. :) —— Eric ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev