Peter R.'s posts seem like he is intentionally *trying* to get himself banned, so he has an excuse to go complain to his followers. Literally every single person posting to bitcoin-dev has their posts delayed until a moderator individually approves them - it's not just you. Yes, it's annoying, but the alternatives have been clearly shown to be worse (the list gets noisy with non-development stuff, and half the intended audience stops reading entirely).
Note I moved our conversation here to the bitcoin-discuss mailing list because we've left the development topic, and this is a completely unmoderated list for discussion of anything Bitcoin-related. I feel this forum is a good fit for our present conversation, and hope you will continue to provide your thoughts on this subject. It sounds to me like your BUIP process is intended to be some kind of binding governance, which is very different from the goals of BIP. The BIP process exists to help coordinate between multiple implementations, but it isn't a binding decision-making process at all, and everyone is free to ignore or implement individual BIPs at their own option. (I almost wonder if it would make more sense for BUIP to be a process on top of BIP, for Bitcoin Unlimited to decide if you will implement particular BIPs?) If Bitcoin Unlimited isn't interested in interoperability with other implementations, obviously you can go ahead and use a centralised/binding BUIP instead - that's your choice you have a right to make - but I would consider this a rather unfortunate decision to make for something like thin blocks. Due to lack of viable alternatives, if there is a rationale for using it for peer selection, I agree a BIP simply allocating a service bit does still make sense, and in this case you could simply add a reference to the BUIP for the protocol itself. Also note that the BIP process does not allow the editor to block submissions (provided they follow the procedure), and BIP 2 does aim to improve the process by addressing how to measure consensus (and clarifying when consensus is and isn't required). If there are further improvements you believe are needed in the BIP process, I encourage you to work on a Process BIP to address those needs. Thanks, Luke On Wednesday, March 09, 2016 9:04:31 PM G. Andrew Stone wrote: > Off the top of my head I can think of the censorship of posts by Gavin and > Peter R on this list. My own posts are "moderated" for hours before being > allowed, yet not one of my posts has been rejected. > > WRT the BIP process, with respect you have no democratic process. The > editor can block submissions, there is no way measure "consensus", there is > no way for a submitter to force a decision on a BIP to be made allowing > BIPs to languish forever, and there is no way for the public to similarly > force a decision (which was important, for example, to expose BIP-100 as a > stalling tactic that diverted miner interest onto a solution that was never > implemented). > > You might look at the Bitcoin Unlimited Articles of Federation ( > http://www.bitcoinunlimited.info/articles) if you are interested in a > template of how such an organization could be structured. > > Things may be very different now that the prior BIP editor has relinquished > his role (BTW, there was no democratic or open process to select a new > editor), and I really hope that you do proceed in a fair and egalitarian > manner. To some degree I suppose it is unfair to blame today's structure > on yesterday's mistakes. However given there there have been no public > statements, apologies, or resignations linked to prior abuses or mistakes > (AFAIK), I am not going to invest in you the power of moderation of > discussion between clients via my participation in this list or BIP process > other than what is needed to communicate with the Bitcoin Core client. > > ... and I'm not really interested in arguing organizational points in this > developer forum so this will be my first and last post on the subject... if > you really are looking to change you can, over the long term, show the > community that via your actions, or send me email directly or communicate > on bitco.in or another uncensored forum. > > Regards, > Andrew > > On Wed, Mar 9, 2016 at 1:45 PM, Luke Dashjr <l...@dashjr.org> wrote: > > On Wednesday, March 09, 2016 6:11:34 PM G. Andrew Stone wrote: > > > Thanks for your offer Luke, but we are happy with our own process and, > > > regardless of historical provenance, see this mailing list and the BIP > > > process as very Core specific for reasons that are too numerous to > > > > describe > > > > > here but should be obvious to anyone who has been aware of the last > > > year > > > > of > > > > > Bitcoin history. > > > > Frankly, I don't see any way this isn't pure FUD. Neither have ever been > > Core- > > specific, and I don't think there's even a single Core dev involved in > > moderating the list. The lead moderator, Jeff Garzik, is even a Classic > > dev. > > Every alt implementation and client (besides yours) has submitted and > > used the > > BIP process. If there is a failure in these venues, it would frankly > > appear to > > be on your end. I'm trying to do what I can here to assume good faith and > > come > > to some commonly agreeable resolution, but you're not giving me anything > > much > > I can go on. > > > > Luke _______________________________________________ bitcoin-discuss mailing list bitcoin-discuss@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-discuss
