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

2015-06-19 Thread Eric Lombrozo
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 will 
likely need to move to a model where it isn’t necessary for everyone to 
validate everyone else’s latte purchases. Larger blocks might, at best, keep 
the current system chugging along temporarily - although I’m not sure that’s 
necessarily such a great thing…we need to create a fee market sooner or later, 
and until we do this, block size issues will continue to crop up again and 
again and economic incentives will continue to be misplaced. It would be nice 
to have more time to really develop a good infrastructure for this…but without 
real market pressures, I’m not sure it will happen at all. Necessity is the 
mother of invention, after all. The question is how to introduce a fee market 
smoothly and with the overwhelming consensus of the community - and that's 
where it starts to get tricky.

——

On a separate note, as several others have pointed out in this thread (but I 
wanted to add my voice to this as well), maintenance of source code 
repositories is NOT the real issue here. The bitcoin/bitcoin project on github 
is a reference implementation of the Satoshi protocol…but it is NOT the only 
implementation…and it wasn’t really meant to be. Anyone is free to fork it, 
extend it, improve upon it, or create an entirely new network with its own 
genesis block…a separate cryptoledger.

The real issue regarding XT is NOT the forking of source code nor issues 
surrounding commit access to repositories. The real issue is the *forking of a 
cryptoledger*.

Open source repositories are meant to be forked - in fact, it is often 
encouraged. It is also encouraged that improvements be submitted for review and 
possibly merged back into the parent repository…although this doesn’t always 
happen.

However, we currently have no mechanisms in place to support merging of forked 
cryptoledgers. Software, and most other forms of digital content, generally 
increases in value with more copies made. However, money is scarce…by design. 
The entire value of the assets of a decentralized cryptoledger rests on the 
assumption that nobody can just unilaterally fork it and change the rules. Yes, 
convincing other people to do things a certain way is HARD…yes, it can be 
frustratingly slow…I’ve tried to push for many changes to the Bitcoin 
network…and have only succeeded a very small number of times. And yes, it’s 
often been quite frustrating. But trying to unilaterally impose a change of 
consensus rules for an existing cryptoledger sets a horrendous precedent…this 
isn’t just about things like block size limits, which is a relatively petty 
issue by comparison.

It would be very nice to have a similar workflow with consensus rule evolution 
as we do with most other open source projects. You create a fork, demonstrate 
that your ideas are sound by implementing them and giving others something that 
works so they can review them, and then merge your contributions back in. 
However, the way Bitcoin is currently designed, this is unfortunately 
impossible to do this with consensus rules. Once a fork, always a fork - a.k.a. 
altcoins. Say what you will about how most altcoins are crap - at least most of 
them have the decency of starting with a clean ledger.


- Eric Lombrozo


 On Jun 18, 2015, at 5:57 PM, Chris Pacia ctpa...@gmail.com wrote:
 
 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 other tricks to minimize the 
 risk of already deployed off-chain solutions as an interim measure until:
   * Deploy soft-fork changes for truly scalable solutions like Lightning 
 Network.
 
 One of my biggest concerns is that these solutions (lightning network in 
 particular) could end up being worse, in terms of decentralization, than 
 would be a bitcoin network using larger blocks. We don't exactly know what 
 the economies of scale are for pay hubs and could very well end up with far 
 fewer hubs than nodes at any conceivable block size.
 
 Of course, it could also turn out to be fantastic, but it seems like an 
 enormous gamble to basically force everyone in the ecosystem to collectively 
 spend millions of dollars upgrading to Lightning and then see whether it's 
 actually an improvement in terms of decentralization.
 
 To me, a much more sane approach would be to allow people to voluntarily opt 
 in to those other solutions after we've had an opportunity to experiment with 
 them and see how they actually function in practice, but that can't happen if 
 the network runs out of capacity first.

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

2015-06-19 Thread Mike Hearn

 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 hardware would get cheaper as fast or faster than Bitcoin would
grow. You may disagree with him, but as we're talking about the future are
you 100% certain he was wrong? I did calculations a long time ago that
suggested even with today's hardware (+some software optimisations) it
would be feasible to keep up with Visa.

Hardware improvements can be unintuitive. There's a spreadsheet here that
lets you play with various parameters.

https://docs.google.com/spreadsheets/d/1PJvrAAOVYVszfRRLhKqd1R9lRiOAImzAfdeb6ajATEY/edit#gid=1451669128

(note: the spreadsheet says avg txn size is 250 bytes, but if you check the
formula for the middle column, it does actually use 500 bytes as the
multiplier hard coded).


 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 mechanism which matches supply and demand.


That's not clear either, I'm afraid.

Remember that there's an upper limit on how high Bitcoin fees can go. When
fees become higher than what the banking system charges, many users won't
use Bitcoin for moving money around anymore. Fees cannot really go much
higher than that even if you assume the currency is still attractive for
other reasons, because people would just sell their coins for fiat, move
the fiat, and buy back the coins the other side.

The way mining will be funded in future is an open question. There are
differing proposals. Still, even with a higher hard block size limit,
miners can always refuse to mine transactions that don't include a
particular fee. So if you're worried about this, miners aren't being forced
into any particular policy.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-06-19 Thread GC

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 claim to know that, but it's something that worries me.
No matter how many people say that's too far away in the future to
worry about it, I still worry about it and I'm sure more people do.
What if when it's time to care about it we discover that we should
have started to do things about it long ago to minimize the risks of
this transition?

Hmmm. What should be the price of an email? How much should DARPA have
charged for using TCP/IP?

I see a lot of well-paid, first-world technologists arguing for commercial
returns on a nacent protocol which could could offer benefits to the
unbanked.
Is that really the vision: to (re)build a de-centralized Paypal with
slightly cheaper fees and cool hooks into off-chain commercial systems
providing profits for the already rich?

--

___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development



--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-06-19 Thread Eric Lombrozo

 On Jun 19, 2015, at 2:37 AM, Mike Hearn m...@plan99.net 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 will be 
 kicked out to make way for the others. Whether that happens in some kind of 
 stable organised way or (as with the current code) a fairly chaotic way 
 doesn't change the fundamental truth: some users will find their bitcoin 
 savings have become uneconomic to spend.
 
 Here's a recent user complaint that provides a preview of coming attractions:
 
 https://www.reddit.com/r/Bitcoin/comments/39r3bi/breadwallet_asking_me_to_pay_over_10_network_fee/
  
 https://www.reddit.com/r/Bitcoin/comments/39r3bi/breadwallet_asking_me_to_pay_over_10_network_fee/
 
 Hello, I'm just trying to send my small Sarutobi-tips stash (12,159 bits) 
 onto a paper wallet. When I try to send it, a window pops up stating 
 insufficient funds for bitcoin network fee, reduce payment amount by 1,389 
 bits? This would be a fee of $0.32 to send my $2.82, leaving me with $2.50.
 
 These sorts of complaints will get more frequent and more extreme in the 
 coming months. I realise that nobody at Blockstream is  in the position of 
 running an end user facing service, but many of us are  and we will be 
 the ones that face the full anger of ordinary users as Bitcoin hits the wall.

Mike,

With all due respect, many of us DO run end user facing services…and would 
rather see a fundamental problem *fixed* rather than merely covered up 
temporarily…hoping nobody notices.

The user experience of Bitcoin is already horrendous…unless you use a 
centralized validator web wallet. Even SPV is fundamentally broken (and I would 
have pegged you for being one of the people most directly aware of this fact). 
If we’re going for centralized validation, why even use a blockchain in the 
first place? We already have much faster, more efficient technology that can do 
that kind of stuff at a fraction of the cost. If you have well-established 
entities running banking services, we have other mechanisms in place that can 
help keep them honest…other far more efficient protocols. We’re basically 
defeating the very purpose of this invention.

Then there are a bunch of other “inconveniences” about the way Bitcoin 
currently works. For instance, have you ever received a bunch of small payments 
(i.e. a crowdsale) and then found yourself in the position of having to 
suddenly move a big chunk of that on the blockchain…only to discover all the 
txouts you were spending added up to hundreds of kB or more? Or have you ever 
had to send a small payment but only had one large output in your wallet…which 
meant that the entirety of those funds were tied up until the first transaction 
got signed and propagated? Yes, the protocol has MANY serious issues…of which 
the “send and forget” fee model as opposed to the “send and bid model” is just 
one.

Bitcoin was designed from the beginning with the idea that sooner or later fees 
would be a significant component of the network. The problem was never really 
fully addressed and solved - I’m glad to see that finally some good people in 
this space are starting to seriously think about solutions.

Mike, are you telling us you’d rather avoid user complaints at all costs even 
if that means building something shitty for them that doesn’t really serve its 
stated purpose? If those are your standards then no thanks, I don’t want to be 
part of your fork. And I don’t think I’m alone in this sentiment.


- Eric Lombrozo


 --
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




signature.asc
Description: Message signed with OpenPGP using GPGMail
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-06-19 Thread Benjamin
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 mechanism which matches supply and demand.

On Fri, Jun 19, 2015 at 11:37 AM, Mike Hearn m...@plan99.net 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 will be
 kicked out to make way for the others. Whether that happens in some kind of
 stable organised way or (as with the current code) a fairly chaotic way
 doesn't change the fundamental truth: some users will find their bitcoin
 savings have become uneconomic to spend.

 Here's a recent user complaint that provides a preview of coming
 attractions:

 https://www.reddit.com/r/Bitcoin/comments/39r3bi/breadwallet_asking_me_to_pay_over_10_network_fee/

 Hello, I'm just trying to send my small Sarutobi-tips stash (12,159 bits)
 onto a paper wallet. When I try to send it, a window pops up stating
 insufficient funds for bitcoin network fee, reduce payment amount by 1,389
 bits? This would be a fee of $0.32 to send my $2.82, leaving me with $2.50.


 These sorts of complaints will get more frequent and more extreme in the
 coming months. I realise that nobody at Blockstream is  in the position of
 running an end user facing service, but many of us are  and we will be
 the ones that face the full anger of ordinary users as Bitcoin hits the
 wall.

 --

 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-06-19 Thread GC
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 requirement now? A working ³fee market² or a
reliable, useful payment network that scales without falling over in the
next 2-3 years.

On 19/6/15 4:53 pm, Benjamin benjamin.l.cor...@gmail.com wrote:

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 mechanism which matches supply and demand.

On Fri, Jun 19, 2015 at 11:37 AM, Mike Hearn m...@plan99.net 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 will
be
 kicked out to make way for the others. Whether that happens in some
kind of
 stable organised way or (as with the current code) a fairly chaotic way
 doesn't change the fundamental truth: some users will find their bitcoin
 savings have become uneconomic to spend.

 Here's a recent user complaint that provides a preview of coming
 attractions:

 
https://www.reddit.com/r/Bitcoin/comments/39r3bi/breadwallet_asking_me_to
_pay_over_10_network_fee/

 Hello, I'm just trying to send my small Sarutobi-tips stash (12,159
bits)
 onto a paper wallet. When I try to send it, a window pops up stating
 insufficient funds for bitcoin network fee, reduce payment amount by
1,389
 bits? This would be a fee of $0.32 to send my $2.82, leaving me with
$2.50.


 These sorts of complaints will get more frequent and more extreme in the
 coming months. I realise that nobody at Blockstream is  in the position
of
 running an end user facing service, but many of us are  and we will
be
 the ones that face the full anger of ordinary users as Bitcoin hits the
 wall.

 
-
-

 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--

___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development



--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-06-19 Thread Jorge Timón
On Fri, Jun 19, 2015 at 11:37 AM, Mike Hearn m...@plan99.net 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 will be
 kicked out to make way for the others. Whether that happens in some kind of
 stable organised way or (as with the current code) a fairly chaotic way
 doesn't change the fundamental truth: some users will find their bitcoin
 savings have become uneconomic to spend.

He doesn't mean that: he means solving the mempool and crashes and
hitting the limit would have.
If the chain has limited size it is a scarce resource and people have
to bid for it: nothing unexpected or wrong about that.
Of course, people that believe the limit should be completely removed
eventually because they don't care about mining being decentralized
(or fail to see the relation between the two) may have a very
different view about this.

On Fri, Jun 19, 2015 at 12:08 PM, GC slashdevn...@hotmail.com wrote:
 Timeframe for transaction fees topping block reward fees = many years in
 the future, based on current ratio of block reward to fees.

Do you think that this ratio is unrelated to an abundant (non-scarce)
block size?
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
start a non-catastrophic transition from subsidies to fees.
I don't claim to know that, but it's something that worries me.
No matter how many people say that's too far away in the future to
worry about it, I still worry about it and I'm sure more people do.
What if when it's time to care about it we discover that we should
have started to do things about it long ago to minimize the risks of
this transition?

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-06-19 Thread Brooks Boyd
On Fri, Jun 19, 2015 at 4:37 AM, Mike Hearn m...@plan99.net 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 will be kicked out to make way for the others. Whether that happens in
 some kind of stable organised way or (as with the current code) a fairly
 chaotic way doesn't change the fundamental truth: *some users will find
 their bitcoin savings have become uneconomic to spend*.

 Here's a recent user complaint that provides a preview of coming
 attractions:


 https://www.reddit.com/r/Bitcoin/comments/39r3bi/breadwallet_asking_me_to_pay_over_10_network_fee/

 Hello, I'm just trying to send my small Sarutobi-tips stash (12,159 bits)
 onto a paper wallet. When I try to send it, a window pops up stating
 insufficient funds for bitcoin network fee, reduce payment amount by 1,389
 bits? This would be a fee of $0.32 to send my $2.82, leaving me with $2.50.



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 decentralized since miners wouldn't be
working on such large-scale blocks? It would still take more storage space
to store the blockchain, though.

Brooks
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-06-19 Thread Mike Hearn

 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 that happens in some kind of
stable organised way or (as with the current code) a fairly chaotic way
doesn't change the fundamental truth: *some users will find their bitcoin
savings have become uneconomic to spend*.

Here's a recent user complaint that provides a preview of coming
attractions:

https://www.reddit.com/r/Bitcoin/comments/39r3bi/breadwallet_asking_me_to_pay_over_10_network_fee/

Hello, I'm just trying to send my small Sarutobi-tips stash (12,159 bits)
 onto a paper wallet. When I try to send it, a window pops up stating
 insufficient funds for bitcoin network fee, reduce payment amount by 1,389
 bits? This would be a fee of $0.32 to send my $2.82, leaving me with $2.50.


These sorts of complaints will get more frequent and more extreme in the
coming months. I realise that nobody at Blockstream is  in the position of
running an end user facing service, but many of us are  and we will be
the ones that face the full anger of ordinary users as Bitcoin hits the
wall.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-06-18 Thread Mike Hearn

 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. And I fully believe he would do so!
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-06-18 Thread Mike Hearn

 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 what I'm doing.

I agree that BIP 1 is not clear enough. Gavin is writing a BIP to accompany
his patch, because BIPs are best when they describe working code, and BIP 1
*is* at least clear about that. Otherwise it can turn out during
implementation that something was different to what was anticipated. I'm
sure you agree with this.

So a BIP is coming. However, BIP 1 also says this:

Vetting an idea publicly before going as far as writing a BIP is meant to
 save the potential author time


and

BIP authors are responsible for collecting community feedback on a BIP
 before submitting it for review


OK. Gavin has been vetting the idea publicly and collecting community
feedback. Note that the entire Bitcoin community is not on this list, so he
published a series of blog posts to get wider feedback, and then was
criticised for not doing it all here instead.

But anyway - so far, so good.  The procedure is being followed.

What happens once a BIP is written? The process says:

For a BIP to be accepted it must meet certain minimum criteria. It must be
 a clear and complete description of the proposed enhancement. The
 enhancement must represent a net improvement. The proposed implementation,
 if applicable, must be solid and must not complicate the protocol unduly.



  Once a BIP has been accepted, the reference implementation must be
 completed.


This is where the problem starts.

The BIP process you refer to *does not state how acceptance will happen*.
It merely sets out a few minimum requirements like making some sort of
sense, having code. It's also full of extremely vague descriptions like
must represent a net improvement. Improvement according to who? That's
left unexplained.

And then it says what happens once a BIP is accepted.

The middle bit is missing. When there is disagreement over a consensus BIP,
how are decisions made?
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-06-18 Thread Bryan Bishop
On Thu, Jun 18, 2015 at 5:00 AM, Mike Hearn m...@plan99.net 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 worried about Gavin or anyone else making commits to git
repositories. You'll notice that this wasn't even mentioned in the original
email you were replying to. Instead, the email was talking about commit
access, which is a property of GitHub's repositories.

So why did I say it? Because it's consistent with what I've always said:


(That's not a good reason.)

you cannot run a codebase like Wikipedia


Wikipedia is a top-down centralized authority-based hierarchy. That's
pretty close to what you're proposing. That's what everyone else is
disagreeing with. You seem to have switched your position mid-flight...?

This is not a radical position. That's how nearly all coding projects work.
 I have been involved with open source for 15 years and the 'single
 maintainer who makes decisions' model is normal, even if in some large
 codebases  subsystems have delegated submaintainers.


There are a number of reasons why that perspective is broken; throughout
our conversations others have repeatedly reminded you (such as in -wizards)
that forking an open-source repository is not at all like a hard-fork of
the blockchain. Anyone can be glorious leader of any repository they want,
that's how open-source works. However, it's critical that bitcoin users are
never convinced to trust BDFLs or anything else that can be compromised.
Should all bitcoin users suddenly start using software with BDFLs, even
multiple implementations with separate BDFLs, then those users can be
trivially compromised through their trust in those individuals and projects.

The alternative is that every developer and every user is personally
responsible for self-validation of the rules, checking for correctness and
validity. Happy coincidence that this seems to match the strategy of
operating the bitcoin network itself, which is to run a node that sees
everything and validates all the transactions. Anyone is able to find an
error in logic or flaw in the system rules, and they should make it known
as widely as possible so that others may evaluate the evidence and consider
which solutions preserve the important properties of the system. This is
not a matter of majorities or minorities; these arguments should be true
for anyone independent of who or what they are, or what level of
unpopularity they may have.

Anything other than this is somewhat radical, and I am confused as to why
others have been talking about developer consensus. I suspect that the
reason why they have been saying developer consensus is because they are
talking about the Bitcoin Core project on GitHub at the moment. But the
topic switched to contentious hard-forks already, which is not a topic of
repositories but a topic of the blockchain and network; and in the context
of contentious hard-forks it is clear why everyone individually must
evaluate the rules and decide whether they the software is correct, or
whether changes can trivially cause catastrophic broken hard-forks. These
lines of reasoning should be true for everyone, and not merely true for one
person but not another. Users, companies and developers must be aware of
this, even though it's different from their usual expectations of how
systems operate and are maintained. And it is important to be careful to
not misconstrue this to others because it is entirely possible to
unintentionally convince others that traditional and centralized models are
safely applicable here.

I realise some people think this anti-process leads to better decision
 making. I disagree. It leads to no decision making, which is not the same
 thing at all.


Well, if you're talking about the recent disputes regarding a certain patch
to hard-fork the blockchain, a decision to not include such a patch seems
like the very definition of a decision.

Gavin and I say - there is a process, and that process is a hard fork of
 the block chain.


I doubt that other bitcoin software maintainers would agree with that sort
of toxic reasoning; contentious hard-forks are basically a weapon of war
that you can use against any other collaborator on any bitcoin project. Why
would anyone want to collaborate on such a hostile project? How would they
even trust each other?

- Bryan
http://heybryan.org/
1 512 203 0507
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-06-18 Thread Milly Bitcoin
 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 
option for someone who doesn't agree is to hard fork.  There is no way 
around that and you should just accept that fact and move on.

Russ


--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-06-18 Thread Mark Friedenbach
On Thu, Jun 18, 2015 at 6:31 AM, Mike Hearn m...@plan99.net 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 are these people? Is it whoever reverts the change last?
 Could I write down in a document a precise description of how decisions are
 made? No, and that's been a fairly frustrating problem for a long time.


There is a quote from United States Supreme Court Justice Potter Stewart to
describe his threshold test for obscenity which is relevant here: I know
it when I see it.

It is hard certainly, and perhaps even impossible to write down a system of
rules that is used to resolve every dispute among core developers. But that
doesn't mean it isn't obvious to all the participants what is going on. If
a contentious change is proposed, and if after sufficient debate there are
still members of the technical community with reasoned, comprehensible
objections who are not merely being obstinate in the views -- a neutral
observer would agree that their concerns have not been met -- then there is
a lack of consensus.

If there was some sort of formal process however, the system wouldn't work.
Rules can be gamed, and if you add rules to a process then that process can
be gamed. Instead we all have a reasonable understanding of what technical
consensus is, and we all know it when we see it. Where we do not see it,
we do not proceed.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-06-18 Thread Wladimir J. van der Laan
-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 and defensive. Happens
 all the time but it is not really a good excuse to keep doing things
 in an inefficient manner.  The old ways just don't scale and if you
 ever worked on massive projects then you know these formal processes
 work better.

So then: make a proposal for a better process, post it to this list.

In practice there has been zero interest in improving the BIP process.

E.g. the BIP process was adapted from the Python Enhancement Proposals by Amir 
Taaki (in 2009 or so?). It hasn't really changed since then, apart from some 
spelling and grammar corrections. It is not specifically adapted to Bitcoin, 
and doesn't make a distinction between for example, consensus changes and 
non-consensus changes.

So that's up to someone to do. You seem to be enthousiastic about it, so go 
ahead.

Wladimir
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCgAGBQJVgufFAAoJEHSBCwEjRsmmAmYIAI9ndrMoqEuoaP5t+7W42UuH
sh5qR7hojCCoZZl1N+rQ63UXcPBO/V4NUkUG97S3qpEFDzuoYSbOX2Eh+TRfK+s+
U+BpLhWteSexJ3N9aiFuR0q5jgesAzLZ9wtq1gCPI/Zu5/fgYBP4AVTiQGdXCZtv
m6ZDKCf+aB/fW/59/AiY44NkMDjVQieEVRiT1IPFJULWesOOdtv7UoqIpz0vDa/5
Jplm41j8IpTPioJKSwUi5qzSDrF7O39PC9LMXNRx/0FIuYfwqJpvF0Frc+vtPpjQ
llKE7945uMXz3FLSV0Orx26XPal/MuF5AYOPNk6pJfwYw7q91AUvQxVFepBa9vw=
=dMO9
-END PGP SIGNATURE-

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-06-18 Thread Mike Hearn

 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 chain consensus
rules or the peer to peer protocol and thus require changes to Bitcoin
Core.

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 in the previous three weeks. If more time is
required, the maintainer is required to request an extension from the BIP
author, who may then elect to force an immediate decision (risking a no),
or choosing to allow more time.

The verdict will meet the following criteria:

   - It will address the latest version of the BIP at the time the verdict
   is rendered.

   - In case of a rejection, it will spell out and describe the technical
   rationale for this decision. Opinions held by other people are not
   considered technical rationales: if the maintainer agrees with a technical
   point made during discussion, he must own that opinion for himself.
   Therefore no BIP will be rejected on grounds of controversy, disagreement,
   lack of consensus or otherwise.

   - In case of rejection, the maintainer will provide a clear, specific
   list of actionable steps the BIP author can take next. For example, a list
   of what changes would address the technical objections raised. In case the
   maintainer believes no change could ever make the BIP acceptable, the list
   must consist of instructions for how to create a patch set and, in the case
   of changes to the consensus rules, how to initiate a hard fork.

A BIP, even once rejected, may live on in the BIPS repository, though its
entry in the index may be sorted below others. The BIP author may update
the BIP with a summary of any resulting discussion. As such a summary may
be inherently contentious in case of a dispute, the authors wording of that
summary is final and may not be subject to meta-debate.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-06-18 Thread Milly Bitcoin
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 people are saying they don't really know what the process is 
the first step would be to describe the current process.  I don't fully 
understand the current process but I can see it is not formalized and 
nobody can even give me a clear description of what it is.  Once you 
have it written down then changes/improvements can be proposed.

The first baby step was already done by the Foundation in developing 
that risk study.   A NIST guide for developing such a document is at 
http://csrc.nist.gov/publications/nistpubs/800-30-rev1/sp800_30_r1.pdf. 
No one person can come up with this and it would take buy in from 
several different people who have expertise in specific technical areas 
as well as experts in coming up with test plans.  I recently suggested 
to the people running the MIT lab that they look into developing a 
program along those lines.  Gavin also recently suggested that list of 
Bitcoin metrics be developed to help resolve the current disputes.  I 
can help develop this process if there is interest.

Russ




On 6/18/2015 11:46 AM, Wladimir J. van der Laan wrote:
 -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 and defensive. Happens
 all the time but it is not really a good excuse to keep doing things
 in an inefficient manner.  The old ways just don't scale and if you
 ever worked on massive projects then you know these formal processes
 work better.
 So then: make a proposal for a better process, post it to this list.

 In practice there has been zero interest in improving the BIP process.

 E.g. the BIP process was adapted from the Python Enhancement Proposals by 
 Amir Taaki (in 2009 or so?). It hasn't really changed since then, apart from 
 some spelling and grammar corrections. It is not specifically adapted to 
 Bitcoin, and doesn't make a distinction between for example, consensus 
 changes and non-consensus changes.

 So that's up to someone to do. You seem to be enthousiastic about it, so go 
 ahead.

 Wladimir
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iQEcBAEBCgAGBQJVgufFAAoJEHSBCwEjRsmmAmYIAI9ndrMoqEuoaP5t+7W42UuH
 sh5qR7hojCCoZZl1N+rQ63UXcPBO/V4NUkUG97S3qpEFDzuoYSbOX2Eh+TRfK+s+
 U+BpLhWteSexJ3N9aiFuR0q5jgesAzLZ9wtq1gCPI/Zu5/fgYBP4AVTiQGdXCZtv
 m6ZDKCf+aB/fW/59/AiY44NkMDjVQieEVRiT1IPFJULWesOOdtv7UoqIpz0vDa/5
 Jplm41j8IpTPioJKSwUi5qzSDrF7O39PC9LMXNRx/0FIuYfwqJpvF0Frc+vtPpjQ
 llKE7945uMXz3FLSV0Orx26XPal/MuF5AYOPNk6pJfwYw7q91AUvQxVFepBa9vw=
 =dMO9
 -END PGP SIGNATURE-




--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-06-18 Thread Jeff Garzik
On Thu, Jun 18, 2015 at 9:07 AM, justusranv...@riseup.net 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 function as a set of rules imposed by some
 people onto other people.


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.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-06-18 Thread Wladimir J. van der Laan
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 in the previous three weeks. If more time is
 required, the maintainer is required to request an extension from the BIP
 author, who may then elect to force an immediate decision (risking a no),
 or choosing to allow more time.

Again, for the last time: Bitcoin Core maintainer does not decide about 
protocol or consensus level changes.

This is not a role for me. Find someone else, if you think you need an arbiter. 
There was an idea about a Bitcoin Standards Body once, but as far as I know 
that's not actively being worked on.

BTW: for more exposure a proposal is better posted as a new thread, not as a 
deep reply to an existing topic.

Wladimir


--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-06-18 Thread justusranvier
-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.


Software engineers should understand that they have a binary choice: 
produce the software that your customers want, or the world will ignore 
your software.

There is *no inherent value* to Bitcoin's software rules. The only value 
that is exists is that produced by the individuals who voluntarily 
choose to run the software.

Failing to account for all design requirements is bad engineering. 
Nobody cares about the design features of a bridge to nowhere.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJVgvoDAAoJECpf2nDq2eYj0h4P/0YaTsS963qpb63zvB6WlIPS
2lhCJ9FtAd3II5Et+5c/cisfJ9YI2OnM0y8nQpyB9NEOeueN1L1sLFcayE5aHASd
EgF7F81AhQD2iSIVwQNs2qAzrZNC2/Nx+nBzBDcrgZ6gRiPpQdsNLy2p0OuZdOgX
yG4xl6tKADB2kNi6tVPtZqUC300uQHvggtm+pexYilT0ojEbeVHCoDV40MNDZC2h
1kcdTnGU2SHJJqeZN2vChJCOMfhmK4JwKgoz7JRXe/GHkUUJKriE6Kb7SVczii9e
9qfcosbnR3gjATMoHFYuJX/nsUx52Q1LM9eQgvE8Ml+6Mim5bj2KCJFh7YISxSq9
FhDujfZFCRRQLPJCSkEUePxU/LS7lmoTZXYl3Zz1j9zbq4ncpRHpIFy9QX6iIqK6
Dursnge9ELQwB+H6HoosWRzxOZyo+oiGj17OngJvZYcvzrc2wjHbpZfVqSkmZepU
SfJZ64O7yjjXjITwhOc4XF2drzvhsjTsHH5BIwdbCn82SoCkJIwXraj7sxIundli
LUJBPiAE0csdmsvW/2kkxLsd9JwTw9lJ9Pf8fiqH3itgrkPkO5mf10DPPnay1SNk
Wnm1bAJ05WnKXSo0m0SzaFgZkdfFuhWR4fieSzhLpa+s/HHj18NZvJCmCBR6ic9G
0A+51wwSZnAdMIw7lwIb
=r4Co
-END PGP SIGNATURE-


--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-06-18 Thread Chris Pacia
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 other tricks to minimize
 the risk of already deployed off-chain solutions as an interim measure
 until:
   * Deploy soft-fork changes for truly scalable solutions like
 Lightning Network.

One of my biggest concerns is that these solutions (lightning network in
particular) could end up being worse, in terms of decentralization, than
would be a bitcoin network using larger blocks. We don't exactly know
what the economies of scale are for pay hubs and could very well end up
with far fewer hubs than nodes at any conceivable block size.

Of course, it could also turn out to be fantastic, but it seems like an
enormous gamble to basically force everyone in the ecosystem to
collectively spend millions of dollars upgrading to Lightning /and then/
see whether it's actually an improvement in terms of decentralization.

To me, a much more sane approach would be to allow people to voluntarily
opt in to those other solutions after we've had an opportunity to
experiment with them and see how they actually function in practice, but
that can't happen if the network runs out of capacity first.

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-06-18 Thread Melvin Carvalho
On 18 June 2015 at 12:00, Mike Hearn m...@plan99.net 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:
  you cannot run a codebase like Wikipedia. Maintainers have to take part in
 debates, and then make a decision, and anyone else who was delegated commit
 access for robustness or convenience must then respect that decision. It's
 the only way to keep a project making progress at a reasonable pace.

 This is not a radical position. That's how nearly all coding projects
 work. I have been involved with open source for 15 years and the 'single
 maintainer who makes decisions' model is normal, even if in some large
 codebases  subsystems have delegated submaintainers.

 This is also how all my own projects are run. Bitcoinj has multiple people
 with commit access. Regardless, if there were to be some design dispute or
 whatever, I wouldn't tolerate the others with commit access starting some
 kind of Wiki-style edit war in the code if they disagreed. Nor would I ever
 expect to get my own way in other people's projects by threatening to
 revert the maintainers changes.

 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 disagreement and won't touch the
 issue in question. So it just runs and runs and *anyone* with commit
 access can then block any change.

 I realise some people think this anti-process leads to better decision
 making. I disagree. It leads to no decision making, which is not the same
 thing at all.


Bicoin is not like other projects.  There are large financial stakes
involved.  I was at a standards convention once and the head of standards
at a large company joked to me:

We know there are 6 people in the standards world that we can never buy.
So we just buy everyone else.

You have to luck out in a huge way to get a person like that running your
project.  Linux has done.  Id say bitcoin has been lucky there too.  But
have a look at other projects, have a look at the alts, the *last* thing
you want is a dictator in may cases.

Ultimately bitcoin is a ledger based on consensus.  There are 3 branches,
the miners, the protocol and the market.  They all play a role in
regulating bitcoin and generally on the conservative side (which I think is
a good thing).  Whatever your view on the 20MB change, it's not a
*conservative* approach, which is the approach that has served bitcoin very
well so far.

So bitcoin is not like other open source projects, and that's probably
quite a good thing.




 --

 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-06-18 Thread Alex Morcos
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 information we have now.

A) I don't believe we should consider changing the 1 MB limit now
B) I conceptually believe in increasing block size, but would like to
follow a more conservative process and wait to see if a stronger technical
consensus on a plan to do so can develop.
C) I'd like to go along with Gavin and Mike's 8MB proposal (maybe we wait
til this is fully specified, but again not deployed)

Perhaps there can even be 4 polls:
Miners can vote in coinbases
Known corporate entities can announce their vote
Does the Bitcoin Foundation infrastructure still exist to represent some
authenticated (I think) set of individuals
A reddit poll

I don't even know if I think this is a good idea, but just trying to find a
way to move forward where more of us are on the same page.






On Thu, Jun 18, 2015 at 2:23 PM, Gavin Andresen gavinandre...@gmail.com
wrote:

 On Thu, Jun 18, 2015 at 1:42 PM, Alex Morcos mor...@gmail.com 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 under reasonable consideration
 other technical opinions and prefers to have clear agreement among them.


 Yes.

 2) Changes to the consensus rules: As others have said, this isn't
 anyone's decision for anyone else.


 Yes.


 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 decide for themselves?  I
 believe that each individual user should adhere to the principle that there
 should be no changes to the consensus rules unless there is near complete
 agreement among the entire community, users, developers, businesses miners
 etc. It is not necessary to define complete agreement exactly because every
 individual person decides for themselves.  I believe that this is what
 gives Bitcoin, or really any money, its value and what makes it work, that
 we all agree on exactly what it is.  So I believe that it is misleading and
 bad for Bitcoin to tell users and business that you can just choose without
 concern for everyone else which code you'll run and we'll see which one
 wins out.  No.  You should run the old consensus rules (on any codebase you
 want) until you believe that pretty much everyone has consented to a change
 in the rules.  It is your choice, but I think a lot of people that have
 spent time thinking about the philosophy of consensus systems believe that
 when the users of the system have this principle in mind, it's what will
 make the system work best.


 I don't think I agree with pretty much everybody, because status-quo
 bias is a very powerful thing. Any change that disrupts the way they've
 been doing things will generate significant resistance -- there will be 10
 or 20% of any population that will take a position of too busy to think
 about this, everything seems to be working great, I don't like change, NO
 to any change.

 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 AND
 stream Game of Thrones), on their old raspberry pi machines.

 The criteria for me is clear super-majority of the people and businesses
 who are using Bitcoin the most, and I think that criteria is met.



 3) Code changes to Core that do change consensus: I think that Wladimir,
 all the other committers besides Gavin, and almost all of the other
 developers on Core would defer to #2 above and wait for its outcome to be
 clear before considering such a code change.


 Yes, that's the way it has mostly been working. But even before stepping
 down as Lead I was starting to wonder if there are ANY successful open
 source projects that didn't have either a Benevolent Dictator or some clear
 voting process to resolve disputes that cannot be settled with rough
 consensus.


 --
 --
 Gavin Andresen

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-06-18 Thread Milly Bitcoin
 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 decide for themselves?

Because the notion that people are free to decide for themselves is just 
a rough approximation of the real world situation.  If your software 
does not agree with merchants and exchanges you can't pay your bills and 
if Bitcoin splits the exchange rate could plummet and damage the 
ecosystem.   People are free to decide within the constraints of the 
Bitcoin system.

Russ


--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-06-18 Thread Alex Morcos
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 prefers to have clear agreement among them.

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 decide
for themselves?  I believe that each individual user should adhere to the
principle that there should be no changes to the consensus rules unless
there is near complete agreement among the entire community, users,
developers, businesses miners etc.  It is not necessary to define complete
agreement exactly because every individual person decides for themselves.
I believe that this is what gives Bitcoin, or really any money, its value
and what makes it work, that we all agree on exactly what it is.  So I
believe that it is misleading and bad for Bitcoin to tell users and
business that you can just choose without concern for everyone else which
code you'll run and we'll see which one wins out.  No.  You should run the
old consensus rules (on any codebase you want) until you believe that
pretty much everyone has consented to a change in the rules.  It is your
choice, but I think a lot of people that have spent time thinking about the
philosophy of consensus systems believe that when the users of the system
have this principle in mind, it's what will make the system work best.

3) Code changes to Core that do change consensus: I think that Wladimir,
all the other committers besides Gavin, and almost all of the other
developers on Core would defer to #2 above and wait for its outcome to be
clear before considering such a code change.

I'm sure my description of point 2 is not the most eloquent or clear, but
maybe someone else can try to elucidate this principle if they've grasped
what I'm trying to say.





On Thu, Jun 18, 2015 at 1:04 PM, justusranv...@riseup.net wrote:

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


 Software engineers should understand that they have a binary choice:
 produce the software that your customers want, or the world will ignore
 your software.

 There is *no inherent value* to Bitcoin's software rules. The only value
 that is exists is that produced by the individuals who voluntarily
 choose to run the software.

 Failing to account for all design requirements is bad engineering.
 Nobody cares about the design features of a bridge to nowhere.

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2

 iQIcBAEBCgAGBQJVgvoDAAoJECpf2nDq2eYj0h4P/0YaTsS963qpb63zvB6WlIPS
 2lhCJ9FtAd3II5Et+5c/cisfJ9YI2OnM0y8nQpyB9NEOeueN1L1sLFcayE5aHASd
 EgF7F81AhQD2iSIVwQNs2qAzrZNC2/Nx+nBzBDcrgZ6gRiPpQdsNLy2p0OuZdOgX
 yG4xl6tKADB2kNi6tVPtZqUC300uQHvggtm+pexYilT0ojEbeVHCoDV40MNDZC2h
 1kcdTnGU2SHJJqeZN2vChJCOMfhmK4JwKgoz7JRXe/GHkUUJKriE6Kb7SVczii9e
 9qfcosbnR3gjATMoHFYuJX/nsUx52Q1LM9eQgvE8Ml+6Mim5bj2KCJFh7YISxSq9
 FhDujfZFCRRQLPJCSkEUePxU/LS7lmoTZXYl3Zz1j9zbq4ncpRHpIFy9QX6iIqK6
 Dursnge9ELQwB+H6HoosWRzxOZyo+oiGj17OngJvZYcvzrc2wjHbpZfVqSkmZepU
 SfJZ64O7yjjXjITwhOc4XF2drzvhsjTsHH5BIwdbCn82SoCkJIwXraj7sxIundli
 LUJBPiAE0csdmsvW/2kkxLsd9JwTw9lJ9Pf8fiqH3itgrkPkO5mf10DPPnay1SNk
 Wnm1bAJ05WnKXSo0m0SzaFgZkdfFuhWR4fieSzhLpa+s/HHj18NZvJCmCBR6ic9G
 0A+51wwSZnAdMIw7lwIb
 =r4Co
 -END PGP SIGNATURE-



 --
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-06-18 Thread Gavin Andresen
On Thu, Jun 18, 2015 at 1:42 PM, Alex Morcos mor...@gmail.com 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 under reasonable consideration
 other technical opinions and prefers to have clear agreement among them.


Yes.

2) Changes to the consensus rules: As others have said, this isn't anyone's
 decision for anyone else.


Yes.


 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 decide for themselves?  I
 believe that each individual user should adhere to the principle that there
 should be no changes to the consensus rules unless there is near complete
 agreement among the entire community, users, developers, businesses miners
 etc. It is not necessary to define complete agreement exactly because every
 individual person decides for themselves.  I believe that this is what
 gives Bitcoin, or really any money, its value and what makes it work, that
 we all agree on exactly what it is.  So I believe that it is misleading and
 bad for Bitcoin to tell users and business that you can just choose without
 concern for everyone else which code you'll run and we'll see which one
 wins out.  No.  You should run the old consensus rules (on any codebase you
 want) until you believe that pretty much everyone has consented to a change
 in the rules.  It is your choice, but I think a lot of people that have
 spent time thinking about the philosophy of consensus systems believe that
 when the users of the system have this principle in mind, it's what will
 make the system work best.


I don't think I agree with pretty much everybody, because status-quo bias
is a very powerful thing. Any change that disrupts the way they've been
doing things will generate significant resistance -- there will be 10 or
20% of any population that will take a position of too busy to think about
this, everything seems to be working great, I don't like change, NO to any
change.

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 AND
stream Game of Thrones), on their old raspberry pi machines.

The criteria for me is clear super-majority of the people and businesses
who are using Bitcoin the most, and I think that criteria is met.



 3) Code changes to Core that do change consensus: I think that Wladimir,
 all the other committers besides Gavin, and almost all of the other
 developers on Core would defer to #2 above and wait for its outcome to be
 clear before considering such a code change.


Yes, that's the way it has mostly been working. But even before stepping
down as Lead I was starting to wonder if there are ANY successful open
source projects that didn't have either a Benevolent Dictator or some clear
voting process to resolve disputes that cannot be settled with rough
consensus.


-- 
--
Gavin Andresen
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-06-18 Thread Mark Friedenbach
On Thu, Jun 18, 2015 at 2:58 PM, Jeff Garzik jgar...@bitpay.com 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.


Or alternatively, fix the reasons why users would have negative experiences
with full blocks, chiefly:

  * 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 other tricks to minimize the
risk of already deployed off-chain solutions as an interim measure until:
  * Deploy soft-fork changes for truly scalable solutions like Lightning
Network.

Not raising the block size limit does not mean doing nothing to solve the
problem.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-06-18 Thread odinn
-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 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 chain 
 consensus rules or the peer to peer protocol and thus require
 changes to Bitcoin Core.
 
 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.

For many things, that will simply be too fast. It is better to allow
the primary maintainer to collaborate with other people who normally
work on the code and determine what the schedule will be based on
life, volume of work, and so on.


 This verdict may be informed by the debate that has taken part in
 the previous three weeks. If more time is required, the maintainer
 is required to request an extension from the BIP author, who may
 then elect to force an immediate decision (risking a no), or
 choosing to allow more time.

Again, this three week thing doesn't work.  But assume for a moment
that there is a certain amount of time that is such and so and it is
set by the maintainer.  The notion that the maintainer would be
required to request an extension from the BIP author is sheer
lunacy.  There is no need to codify the actions of the project
maintainer such that he/she would be needing to be subject to the
whims of whatever BIP author.  In like manner, a BIP author should not
have to be subject to forever delay of a BIP due to inaction of a
maintainer, but should have an answer regarding whether it can be
assigned a number, published as draft and so forth after a reasonable
time.  To me, a reasonable time is something that should be
discussed amongst the maintainer, those who work regularly on code,
and the BIP author.

 
 The verdict will meet the following criteria:
 
 * It will address the latest version of the BIP at the time the 
 verdict is rendered.
 
 * In case of a rejection, it will spell out and describe the
 technical rationale for this decision. Opinions held by other
 people are not considered technical rationales: if the maintainer
 agrees with a technical point made during discussion, he must own
 that opinion for himself. Therefore no BIP will be rejected on
 grounds of controversy, disagreement, lack of consensus or
 otherwise.

No, this is ridiculous, because the notion that no BIP will be
rejected on grounds of controversy, disagreement, lack of consensus,
or otherwise, is clearly an attempt to do away with consensus models
of business, and it is also not a very logical statement because
controversy and disagreement are a natural part of... coming to what
eventually is an agreement.

 
 * In case of rejection, the maintainer will provide a clear,
 specific list of actionable steps the BIP author can take next. For
 example, a list of what changes would address the technical
 objections raised.

This above section I agree with.


 In case the maintainer believes no change could ever make
 the BIP acceptable, the list must consist of instructions for how
 to create a patch set and, in the case of changes to the consensus 
 rules, how to initiate a hard fork.

This above section I do not agree with because of the obvious bias in
favor of the hard fork.  Everything here seems to be aligned to push
for hard fork, hard fork, hard fork.  It's like the author can't tear
his mind off it.

 
 A BIP, even once rejected, may live on in the BIPS repository,
 though its entry in the index may be sorted below others. The BIP
 author may update the BIP with a summary of any resulting
 discussion. As such a summary may be inherently contentious in case
 of a dispute, the authors wording of that summary is final and may
 not be subject to meta-debate.
 
 
This doesn't seem right at all.

 
 
 --
- 

 
 
 
 ___ Bitcoin-development
 mailing list Bitcoin-development@lists.sourceforge.net 
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 

- -- 
http://abis.io ~
a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVg0sHAAoJEGxwq/inSG8CuFcH/0tzRWWyy3wmDegNx463xoaq
EhG/dNqoIvavMlyJrKfKWPK6Mndgo9BtxkYbvOlO40Y51SW4SaisWGzHRg4HyIbJ
0Orp+C0jXhvnrJ7hRwKhrdZQUIRAI19NLVthSb9W6mHnXWJC8ilhlK9Ei9ILRjGl
tM5pZ28SkyJ/b+CnltnYW8t6AvE4zlggC4QsCuUwA2cFoFWjQeESpqjy4kJNv464
yKlsrqoIzs2vNnoLIx1B0aLX9mNTQUwB1yMXtu8IVcAQe/G1LEEnNO56LGf8O0yJ

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

2015-06-18 Thread Jeff Garzik
On Thu, Jun 18, 2015 at 3:33 PM, Mark Friedenbach m...@friedenbach.org
wrote:

 On Thu, Jun 18, 2015 at 2:58 PM, Jeff Garzik jgar...@bitpay.com 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.


 Or alternatively, fix the reasons why users would have negative
 experiences with full blocks, chiefly:

   * 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 other tricks to minimize the
 risk of already deployed off-chain solutions as an interim measure until:
   * Deploy soft-fork changes for truly scalable solutions like Lightning
 Network.

 Not raising the block size limit does not mean doing nothing to solve the
 problem.


This is a long, unreasonable list of work.  None of this exists and it
equates to upgrade all wallets and websites everywhere  It requires all
exchanges, payment processors, merchants, etc. to  - basically everybody
but miners - to update.

It is a far, far larger amount of work to write, test and deploy than
simply increasing the block size limit.

Think through roll-out of these ambitious suggestions, before suggesting as
an alternative!

Not a realistic alternative except in an alternate universe where (a)
developer work at all companies is cost free, plus (b) we can pause the
business universe while we wait for The Perfect Solution.










-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.  https://bitpay.com/
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-06-18 Thread Mark Friedenbach
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
even if you feel the block size limit should be raised at some time in the
future, there are reasons why now is not the best time to do it.

On Thu, Jun 18, 2015 at 2:42 PM, Matt Whitlock b...@mattwhitlock.name
wrote:

 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 blocks are adequate. The
 debate has been about *how* to increase the block-size limit and whether to
 take action ASAP (at the risk of fracturing Bitcoin) or to delay action for
 further debate (at the risk of overloading Bitcoin). Even those who are
 arguing for further debate are not arguing for *inaction*.


 --
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-06-18 Thread Ross Nicoll
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:
 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 blocks are adequate. The debate has 
 been about *how* to increase the block-size limit and whether to take action 
 ASAP (at the risk of fracturing Bitcoin) or to delay action for further 
 debate (at the risk of overloading Bitcoin). Even those who are arguing for 
 further debate are not arguing for *inaction*.


--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-06-18 Thread odinn
-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.

If you refuse to apologize, I get it.  You have not apologized thus
far, and pressing for an apology is unlikely to get an (authentic)
one.  But then, you should voluntarily step back and let others do the
hard work of coming to the consensus that you seem to think is
impossible to accomplish based on how bitcoin is run.

I believe this matter will be resolved, but not with the help of
those who make threatening statements (and who are unable to apologize
for having made them).

- -O

On 06/18/2015 03:00 AM, 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: you cannot run a codebase like Wikipedia. Maintainers have to
 take part in debates, and then make a decision, and anyone else who
 was delegated commit access for robustness or convenience must then
 respect that decision. It's the only way to keep a project making
 progress at a reasonable pace.
 
 This is not a radical position. That's how nearly all coding
 projects work. I have been involved with open source for 15 years
 and the 'single maintainer who makes decisions' model is normal,
 even if in some large codebases  subsystems have delegated
 submaintainers.
 
 This is also how all my own projects are run. Bitcoinj has
 multiple people with commit access. Regardless, if there were to be
 some design dispute or whatever, I wouldn't tolerate the others
 with commit access starting some kind of Wiki-style edit war in the
 code if they disagreed. Nor would I ever expect to get my own way
 in other people's projects by threatening to revert the maintainers
 changes.
 
 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 disagreement
 and won't touch the issue in question. So it just runs and runs and
 /anyone/ with commit access can then block any change.
 
 I realise some people think this anti-process leads to better
 decision making. I disagree. It leads to no decision making, which
 is not the same thing at all.

- -- 
http://abis.io ~
a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good
https://keybase.io/odinn
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJVg0HiAAoJEGxwq/inSG8CXOwIAKSGRJPtSx+untgMERwE7lW7
9p0gWz4jvKhyO+RrGPXlofckvp4Fp/7Yxa+TDLcXbzGi6OesX9yIyN7e06LJW4DP
h7V2PwzS49ZyB/krd03HjvWMFnhoGy7zB7M1okq5myIvx+h1htX9TirNbDl7PU9Z
SWyNNw+GXPsIV/xuPu81LP5GrR3gIxwwhhopOq2qcm08AUiuIJ8EA31mT2ZgwMWB
RxrnktFRzMbW2fD7Z7njTz1gjw1duPyGApJ+xpqtcjjS2idPNuw1nESZTCE3+TwG
Dk1AKmYt8TvZzFWyo/0ly7vYFFW27Yh7SC3oeDJBoWkvySuIFrevux7ekfKxPOc=
=wc2m
-END PGP SIGNATURE-

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-06-18 Thread Ross Nicoll
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, inter-bank only clearance network, which handled 
about 3.5 transactions per second (average) in 2014 
(https://www.theclearinghouse.org/~/media/tch/pay%20co/chips/reports%20and%20guides/chips%20volume%20through%20may%202015.pdf?la=en).


While it seems likely the US population of 300 million makes more 
transactions individually than many other countries, and therefore we 
can't simply multiply that by 20 to estimate what a global clearance 
network might require, hopefully it's clear that if Bitcoin is to scale 
globally, it needs substantially more transaction throughput even if 
main chain transactions become something for banks and the super rich. I 
don't know how much more, but I can't look at the 8MB reportedly backed 
by a number of mining pools and say it's clearly insufficient, at least.


I should emphasise that I don't think we need to jump straight to 8MB 
(or otherwise), if a scaling protocol can be decided upon that would be 
ideal, but we should be planning ahead while it's still relatively easy 
to make these changes.


Ross

On 18/06/2015 23:33, Mark Friedenbach wrote:
On Thu, Jun 18, 2015 at 2:58 PM, Jeff Garzik jgar...@bitpay.com 
mailto:jgar...@bitpay.com 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.


Or alternatively, fix the reasons why users would have negative 
experiences with full blocks, chiefly:


  * 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 other tricks to minimize 
the risk of already deployed off-chain solutions as an interim measure 
until:
  * Deploy soft-fork changes for truly scalable solutions like 
Lightning Network.


Not raising the block size limit does not mean doing nothing to solve 
the problem.




--


___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2015-06-18 Thread odinn
-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
 m...@friedenbach.org mailto:m...@friedenbach.org wrote:
 
 On Thu, Jun 18, 2015 at 2:58 PM, Jeff Garzik jgar...@bitpay.com 
 mailto:jgar...@bitpay.com wrote:
 
 
 The whole point is getting out in front of the need, to prevent 
 significant negative impact to users when blocks are consistently
 full.


My thoughts on that:

Possible scope narrowing to one of the following concepts (but please,
someone tell me if this scope narrowing is unwise, not timely, or if
there is some other factors that would make it just stupid right now
because other things are in the works or whatever:

~ Jeff Garzik, with respect to his BIP 100 (note Evan Mo, CEO of
Huobi's mining project Digcoin, clarified that the big Chinese mining
pools consider further adjustments to the protocol beyond the
suggested 8 MB block size limit adjustment — such as the Bitcoin core
developer Jeff Garzik's BIP-100 draft — to be feasible)
   ~ Adam Back, with a simplified soft-fork one-way peg
   ~ Gavin Andresen, developing an 8 MB block size limit adjustment in
the context of Core (as an example) with one or more of the above
authors rather than focusing on XT. (This is a big assumption but,
roll with it)

All of this assumes that developer(s) are willing to abandon
intentionally contentious proposals such as the hard fork to XT w/ 20
MB, remain within the context of Core and be reasonable.

Here I am being aware of the fact that Pushing a hard fork in the
face of such controversy is a folly, a danger to the network, and that
deserves to be said. - Wladimir J. van der Laan
https://github.com/bitcoin/bitcoin.org/pull/894#issuecomment-112113917


 
 To do that, you need to (a) plan forward, in order to (b) set a 
 hard fork date in the future.
 
 
 Or alternatively, fix the reasons why users would have negative 
 experiences with full blocks, chiefly:
 
 * 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 other tricks to minimize
 the risk of already deployed off-chain solutions as an interim
 measure until: * Deploy soft-fork changes for truly scalable
 solutions like Lightning Network.
 
 Not raising the block size limit does not mean doing nothing to 
 solve the problem.
 
 
 This is a long, unreasonable list of work.  None of this exists and
 it equates to upgrade all wallets and websites everywhere  It
 requires all exchanges, payment processors, merchants, etc. to  -
 basically everybody but miners - to update.
 
 It is a far, far larger amount of work to write, test and deploy
 than simply increasing the block size limit.
 
 Think through roll-out of these ambitious suggestions, before
 suggesting as an alternative!
 
 Not a realistic alternative except in an alternate universe where
 (a) developer work at all companies is cost free, plus (b) we can
 pause the business universe while we wait for The Perfect
 Solution.
 
 
 


Something else I wanted to point out here in this thread is the
subject of the problem of developers going off the deep end which is
what started this thread:

Suppose you have a developer with full commit access who happens to
start threatening to revoking the other developers' commit access on
the repository, or that person doesn't even threaten, one day it just
happens.

What do you have then?  Peter Todd has stated that all one would
achieve by that sabotage is setting a key-value pair in a centralised
registry.  But is that what we want?

The answer, obviously, is no.

This leads to other questions. What technical mechanisms exist to keep
developers from (in some dubious emotional or psycho state) to just
going off the deep and doing exactly what has been described above, if
they have full commit access?  Is there a process whereby that can't
actually happen unless another developer provides a signature (e.g. a
multisignature type of process)?  What keeps bitcoin safe from The
Hearn Threat?

If nothing does, then how would you change that?

And go ahead and tell me if these are dumb questions and I should just
be quiet, but if they are, please do explain why they are such dumb
questions.

 
 
 
 
 
 
 
 -- Jeff Garzik Bitcoin core developer and open source evangelist 
 BitPay, Inc.  https://bitpay.com/
 
 
 --
- 

 
 
 
 ___ Bitcoin-development
 mailing list Bitcoin-development@lists.sourceforge.net 
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 

- -- 
http://abis.io ~
a protocol concept to enable decentralization
and