Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

On 06/19/2015 07:48 AM, Brooks Boyd wrote: > Has there been any talk about reducing the time between blocks? If > blocks were allowed to come twice as fast, they would be able to clear > pending transactions in the mempool the same as if the block size > doubled, but would allow mining to stay more

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

>When is the right time to allow space pressure to rise that ratio? >When the subsidy is at 1.5625, for example, it may be too late to I don¹t believe we have to decide, the miners will do that and are doing that already. >start a non-catastrophic transition from subsidies to fees. >I don't clai

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

On Fri, Jun 19, 2015 at 4:37 AM, Mike Hearn wrote: > Or alternatively, fix the reasons why users would have negative >> experiences with full blocks >> > > It's impossible, Mark. *By definition* if Bitcoin does not have > sufficient capacity for everyone's transactions, some users who were using

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

On Fri, Jun 19, 2015 at 11:37 AM, Mike Hearn wrote: >> Or alternatively, fix the reasons why users would have negative >> experiences with full blocks > > > It's impossible, Mark. By definition if Bitcoin does not have sufficient > capacity for everyone's transactions, some users who were using it

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

> On Jun 19, 2015, at 2:37 AM, Mike Hearn wrote: > > Or alternatively, fix the reasons why users would have negative experiences > with full blocks > > It's impossible, Mark. By definition if Bitcoin does not have sufficient > capacity for everyone's transactions, some users who were using it

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

> > Yeah, but increasing block-size is not a longterm solution. Are you sure? That sort of statement is hard to answer because it doesn't say what you think long term is, or how much you expect Bitcoin to grow. Satoshi thought it was a perfectly fine long term solution because he thought hardwar

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

Benjamin, Timeframe for network congestion and users experiencing service degradation => between now and middle of next year. Timeframe for transaction fees topping block reward fees => many years in the future, based on current ratio of block reward to fees. What is the more pressing requiremen

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

Yeah, but increasing block-size is not a longterm solution. Necessary higher fees are a logical consequence of lower subsidies. Bitcoin was basically free to use at the beginning because miners got paid with new coins at the expense of those who already hold coins. Eventually there needs to be a m

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

> > Or alternatively, fix the reasons why users would have negative > experiences with full blocks > It's impossible, Mark. *By definition* if Bitcoin does not have sufficient capacity for everyone's transactions, some users who were using it will be kicked out to make way for the others. Whether

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

I don’t think the issue is between larger blocks on the one hand and things like lightning on the other - these two ideas are quite orthogonal. Larger blocks aren’t really about addressing basic scalability concerns - for that we’ll clearly need architectural and algorithmic improvements…and wil

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

On 06/18/2015 06:33 PM, Mark Friedenbach wrote: > > * Get safe forms of replace-by-fee and child-pays-for-parent > finished and in 0.12. > * Develop cross-platform libraries for managing micropayment > channels, and get wallet authors to adopt > * Use fidelity bonds, solvency proofs, and othe

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Regarding the bit on "getting out in front of the need, to prevent significant negative impacts to users" I had suggested the following: On 06/18/2015 03:52 PM, Jeff Garzik wrote: > On Thu, Jun 18, 2015 at 3:33 PM, Mark Friedenbach > mailto:m...@fried

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

I'm struggling to illustrate how incredibly low 7 transactions per second is, not just for a payment network, but even just for a clearance network (i.e. to balance transactions between institutions and/or chains). As an example, the Clearing House Interbank Payments System (CHIPS) is a US-only

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

On Thu, Jun 18, 2015 at 3:33 PM, Mark Friedenbach wrote: > On Thu, Jun 18, 2015 at 2:58 PM, Jeff Garzik wrote: > >> >> The whole point is getting out in front of the need, to prevent >> significant negative impact to users when blocks are consistently full. >> >> To do that, you need to (a) plan

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Regarding this proposal from Mike Hearn to remove consensus process from the BIP, which I think is unsound philosophy. I will address this briefly below. On 06/18/2015 09:05 AM, Mike Hearn wrote: > So then: make a proposal for a better process, post

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

On Thu, Jun 18, 2015 at 2:58 PM, Jeff Garzik wrote: > > The whole point is getting out in front of the need, to prevent > significant negative impact to users when blocks are consistently full. > > To do that, you need to (a) plan forward, in order to (b) set a hard fork > date in the future. >

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I maintain that you should apologize to those who traverse this list. What you are saying is digging yourself a deeper hole and is not merely embarrassing but is crossing a threshold in which you have used words, albeit subtly, to attack a community.

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

Is that a forward-looking position? It does not seem so. The whole point is getting out in front of the need, to prevent significant negative impact to users when blocks are consistently full. To do that, you need to (a) plan forward, in order to (b) set a hard fork date in the future. "We don'

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

There's some actually proposing inaction as an outright decision, but I more meant that at times it has felt like we would end up with inaction through momentum, combined with adoption rate making any hard fork more complex if it continues to be delayed. On 18/06/2015 22:42, Matt Whitlock wrote

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

Matt, I for one do not think that the block size limit should be raised at this time. Matt Corallo also started the public conversation over this issue on the mailing list by stating that he was not in favor of acting now to raise the block size limit. I find it a reasonable position to take that e

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

On Thursday, 18 June 2015, at 8:31 pm, Ross Nicoll wrote: > I may disagree with Mike & Gavin on timescale, but I do believe there's > a likelihood inaction will kill Bitcoin An honest question: who is proposing inaction? I haven't seen anyone in this whole, agonizing debate arguing that 1MB bloc

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

I've got a few thoughts on this, but they don't really attach well to a single message, so starting a fresh message in the same thread. I'm going to try being brief. There's a lot of talk about not forking. Sorry, but they're going to happen, planned and unplanned. Even if no intentional forks

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

On Thu, Jun 18, 2015 at 7:24 PM, Matt Corallo wrote: > Ive been trying to stay out of these increasingly useless shit-throwing > contests, but I wanted to take objection to this... I highly, highly doubt > any seriously technical person is making any kind of decision on block size > issues base

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

>For example, I think some of the resistance for bigger blocks is coming >from contributors who are worried they, personally, won't be able to >keep >up with a bigger blockchain. They might not be able to run full nodes >from >their home network connections (or might not be able to run a full node

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

On Thu, Jun 18, 2015 at 8:23 PM, Gavin Andresen wrote: > On Thu, Jun 18, 2015 at 1:42 PM, Alex Morcos wrote: >> >> Let me take a pass at explaining how I see this. >> >> 1) Code changes to Bitcoin Core that don't change consensus: Wladimir is >> the decider but he works under a process that is w

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

Not that I know how to do this, but would you be willing to attempt some other method of measuring just how much of a "super-majority" we have before deploying code? Maybe that information would be helpful for everyone. Obviously such a poll couldn't be perfect, but maybe better than the informat

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

On Thu, Jun 18, 2015 at 1:42 PM, Alex Morcos wrote: > Let me take a pass at explaining how I see this. > > 1) Code changes to Bitcoin Core that don't change consensus: Wladimir is > the decider but he works under a process that is well understood by > developers on the project in which he takes

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

On 18 June 2015 at 12:00, Mike Hearn wrote: > Dude, calm down. I don't have commit access to Bitcoin Core and Gavin > already said long ago he wouldn't just commit something, even though he has > the ability to do so. > > So why did I say it? Because it's consistent with what I've always said: >

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

>2) Changes to the consensus rules: As others have said, this isn't anyone's decision for anyone else. It's up to each individual user as to what code they run and what rules they enforce. So then why is everyone so up in arms about what Mike and Gavin are proposing if everyone is free to de

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

Let me take a pass at explaining how I see this. 1) Code changes to Bitcoin Core that don't change consensus: Wladimir is the decider but he works under a process that is well understood by developers on the project in which he takes under reasonable consideration other technical opinions and pre

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2015-06-18 16:28, Jeff Garzik wrote: > This is an engineering list. The quote precisely describes how the > bitcoin > consensus system functions. > > Users' choice is largely binary: Follow the rules, or bitcoin software > ignores you. Softw

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

On Thu, Jun 18, 2015 at 9:07 AM, wrote: > On 2015-06-18 14:53, Jeff Garzik wrote: > >> Consensus changes - worded another way - change Bitcoin's Constitution - >> The Rules that everyone in the system is -forced- to follow, or be ignored >> by the system. >> > > Bitcoin does not and can not funct

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

On Thu, Jun 18, 2015 at 06:05:58PM +0200, Mike Hearn wrote: > Once a draft BIP has been submitted to bitcoin-development for > consideration, the Bitcoin Core maintainer will deliver a preliminary > yes/no verdict within three weeks. This verdict may be informed by the > debate that has taken part

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

You misunderstand what I am saying. I am not saying I have a specific process that should be followed, I am saying that whatever the process is then it should be formalized or at least written down. That way the stakeholders have something to work with and keeps people on track. Since some p

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2015-06-18 14:53, Jeff Garzik wrote: > Consensus changes - worded another way - change Bitcoin's Constitution > - > The Rules that everyone in the system is -forced- to follow, or be > ignored > by the system. Force is not a helpful or accurate

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

> > So then: make a proposal for a better process, post it to this list. > Alright. Here is a first cut of my proposal. It can be inserted into an amended BIP 1 after "What belongs in a successful BIP?". Let me know what you think. The following section applies to BIPs that affect the block cha

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

On Thu, Jun 18, 2015 at 1:36 PM, Mike Hearn wrote: >> And allegations that the project is "run like wikipedia" or "an edit war" >> are verifyably untrue. >> Check the commit history. > > This was a reference to a post by Gregory on Reddit where he said if Gavin > were to do a pull request for the

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 > This kind of thing always happens as projects become larger and more > diverse. Something that was once a small group turns into a big > group of diverse stakeholders. When it gets too big for the > informal processes then some people get upset

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

On 6/18/2015 11:03 AM, Mark Friedenbach wrote: On Thu, Jun 18, 2015 at 6:31 AM, Mike Hearn > wrote: The first issue is how are decisions made in Bitcoin Core? I struggle to explain this to others because I don't understand it myself. Is it a vote of people wit

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

>Impacts, yes, decider, no. Multiple ACKs are required from developers who will not act if the community will disagree with the change. >The users ultimately choose by deciding which software to download, and that dictates the range of choices available. That is what I mean by a cultish repl

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

On Thu, Jun 18, 2015 at 6:31 AM, Mike Hearn wrote: > The first issue is how are decisions made in Bitcoin Core? I struggle to > explain this to others because I don't understand it myself. Is it a vote > of people with commit access? Is it a 100% agreement of "core developers" > and if so, who ar

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

On Thu, Jun 18, 2015 at 10:53 AM, Milly Bitcoin wrote: > >So I'm *not* the decider for anything that concerns the behavior of > the global consensus, and I cannot be, as I have explained in the > previous post. > > The person who decides if a pull request is accepted is a decider and > significa

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

On Thu, Jun 18, 2015 at 8:29 AM, Pieter Wuille wrote: > On Thu, Jun 18, 2015 at 1:14 PM, Wladimir J. van der Laan < > laa...@gmail.com> wrote: > >> Like in any open source project there is lots of decision making ability >> for code changes. I'd say look at the changelog for e.g. 0.11 >> https://

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

>So I'm *not* the decider for anything that concerns the behavior of the global consensus, and I cannot be, as I have explained in the previous post. The person who decides if a pull request is accepted is a decider and significantly affects the behavior of the global consensus. The only opt

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

On Thu, Jun 18, 2015 at 5:00 AM, Mike Hearn wrote: > Dude, calm down. > Well hold on, his concerns are real and he seems perfectly calm to me and others apparently. > and Gavin already said long ago he wouldn't just commit something, even > though he has the ability to do so. > Nobody is worr

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

> > If you think it's not clear enough, which may explain why you did not even > attempt to follow it for your block size increase, feel free to make > improvements. > As the outcome of a block size BIP would be a code change to Bitcoin Core, I cannot make improvements, only ask for them. Which is

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, Jun 18, 2015 at 03:49:06PM +0200, Mike Hearn wrote: > One reason I keep banging on about *process* and how Wladimir needs to be > The Decider is that the current attempt at "process" is so vague, not only > is it unexplainable, but it's wide

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

On Thu, Jun 18, 2015 at 3:31 PM, Mike Hearn wrote: > OK, let's agree to unpack the two things. > > The first issue is how are decisions made in Bitcoin Core? I struggle to > explain this to others because I don't understand it myself. Is it a vote > of people with commit access? Is it a 100% agre

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

Hi Pieter, I believe Gavin plans to write a blog post about the hard fork process, but I'd like to debate this with you now, if only to give him material to work with :) Your points look to me like the hard/soft fork debate in different clothes. For example, we all agree that the rules of Bitcoi

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

What is immediately clear to anyone who looks at Bitcoin software development is that there is no clear process or method to make changes/updates to the software. When I have questioned this in the past the response is usually some cultish answer about how some kind of technical consensus is r

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

> > And allegations that the project is "run like wikipedia" or "an edit war" > are verifyably untrue. > Check the commit history. > This was a reference to a post by Gregory on Reddit where he said if Gavin were to do a pull request for the block size change and then merge it, he would revert it.

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

OK, let's agree to unpack the two things. The first issue is how are decisions made in Bitcoin Core? I struggle to explain this to others because I don't understand it myself. Is it a vote of people with commit access? Is it a 100% agreement of "core developers" and if so, who are these people? Is

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

"And I never had a problem with Bitcoin-XT while it was just a patch-set with no consensus changes. But a controversial hard fork of the chain is something else completely." How is that different? The only difference is in who makes the fork and if that group has a chance of actually splitting/ove

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, Jun 18, 2015 at 02:29:42PM +0200, Pieter Wuille wrote: > On Thu, Jun 18, 2015 at 1:14 PM, Wladimir J. van der Laan > wrote: > > > Like in any open source project there is lots of decision making ability > > for code changes. I'd say look at

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

On Thu, Jun 18, 2015 at 1:14 PM, Wladimir J. van der Laan wrote: > Like in any open source project there is lots of decision making ability > for code changes. I'd say look at the changelog for e.g. 0.11 > https://github.com/bitcoin/bitcoin/blob/0.11/doc/release-notes.md#0110-change-log, > or fol

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, Jun 18, 2015 at 01:14:09PM +0200, Wladimir J. van der Laan wrote: > On Thu, Jun 18, 2015 at 12:00:17PM +0200, Mike Hearn wrote: > > > Core is in the weird position where there's no decision making ability at > > all, because anyone who show

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

Mike Hearn plan99.net> writes: > It's the only way to keep a project making progress at a reasonable pace. [SNIP] If Bitcoin is managed with a linux kernel style dictator it would be centralized (yet unlike linux, where people can fork without impacting others in Bitcoin a hard fork puts at ri

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Thu, Jun 18, 2015 at 12:00:17PM +0200, Mike Hearn wrote: > Core is in the weird position where there's no decision making ability at > all, because anyone who shows up and shouts enough can generate > 'controversy', then Wladimir sees there is di

Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

Dude, calm down. I don't have commit access to Bitcoin Core and Gavin already said long ago he wouldn't just commit something, even though he has the ability to do so. So why did I say it? Because it's consistent with what I've always said: you cannot run a codebase like Wikipedia. Maintainers ha

[Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Recently I saw the following video: https://www.youtube.com/watch?v=8JmvkyQyD8w&t=47m58s Hadn't seen it until just today, although it was done on June 8, 2015. So this is a bit dated, but to me it was a bit of a stunner to see the extreme nature of (