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

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

Re: [Bitcoin-development] FYI - Mailing List Move Preparations

[Jeff Garzik]

Thanks for setting this up, Warren!


On Thu, Jun 18, 2015 at 9:57 PM, Warren Togami Jr. 
wrote:

> After discussions in #bitcoin-dev in the past day we decided it would be a
> bad idea to link the old and new lists in some way during a transition
> period.  We decided we are better off announcing the switchover very soon,
> and after that point all posts to the old list will be rejected with a
> message telling them where to find the new list.
>
> The proposed switchover will be on Tuesday, June 23rd, 2015.  We will know
> an exact scheduled time for the move probably tomorrow.  At the time of the
> switchover, the old list will reject all messages, archives will be
> exported and imported into the new list server, then the new list will be
> opened.
>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> Please subscribe now and feel free to make test posts.  We are testing
> configuration options to fix some long standing spam filter-related
> issues.  Any posts to the new list prior to the final switchover will be
> wiped from the archives.
>
> If you have opinions on this, please join us in Freenode #bitcoin-dev and
> talk to warren.
>
> Warren Togami
>
>
> --
>
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>


-- 
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] FYI - Mailing List Move Preparations

[Warren Togami Jr.]

BTW, if you are posting from a less popular mail server your initial post
to the new list may be delayed by 5+ minutes due to greylisting.  If your
sending SMTP server is behaving properly then posts after the first should
go through without delay.

Warren

On Thu, Jun 18, 2015 at 6:57 PM, Warren Togami Jr. 
wrote:

> After discussions in #bitcoin-dev in the past day we decided it would be a
> bad idea to link the old and new lists in some way during a transition
> period.  We decided we are better off announcing the switchover very soon,
> and after that point all posts to the old list will be rejected with a
> message telling them where to find the new list.
>
> The proposed switchover will be on Tuesday, June 23rd, 2015.  We will know
> an exact scheduled time for the move probably tomorrow.  At the time of the
> switchover, the old list will reject all messages, archives will be
> exported and imported into the new list server, then the new list will be
> opened.
>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> Please subscribe now and feel free to make test posts.  We are testing
> configuration options to fix some long standing spam filter-related
> issues.  Any posts to the new list prior to the final switchover will be
> wiped from the archives.
>
> If you have opinions on this, please join us in Freenode #bitcoin-dev and
> talk to warren.
>
> Warren Togami
>
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] FYI - Mailing List Move Preparations

[Warren Togami Jr.]

After discussions in #bitcoin-dev in the past day we decided it would be a
bad idea to link the old and new lists in some way during a transition
period.  We decided we are better off announcing the switchover very soon,
and after that point all posts to the old list will be rejected with a
message telling them where to find the new list.

The proposed switchover will be on Tuesday, June 23rd, 2015.  We will know
an exact scheduled time for the move probably tomorrow.  At the time of the
switchover, the old list will reject all messages, archives will be
exported and imported into the new list server, then the new list will be
opened.

https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Please subscribe now and feel free to make test posts.  We are testing
configuration options to fix some long standing spam filter-related
issues.  Any posts to the new list prior to the final switchover will be
wiped from the archives.

If you have opinions on this, please join us in Freenode #bitcoin-dev and
talk to warren.

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

Re: [Bitcoin-development] Mining centralization pressure from non-uniform propagation speed

[Yifu Guo]

Nice insight Peter,

This further confirms the real problem, which doesn't have much to do with
blocksize but rather the connectivity of nodes in countries with
not-so-friendly internet policies and deceptive connectivity.


On Thu, Jun 18, 2015 at 6:00 PM, Tom Harding  wrote:

> On 06/12/2015 06:51 PM, Pieter Wuille wrote:
> >> However, it does very clearly show the effects of
> >> larger blocks on centralization pressure of the system.
>
> On 6/14/2015 10:45 AM, Jonas Nick wrote:
> > This means that your scenario is not the result of a cartel but the
> result of a long-term network partition.
> >
>
> Pieter, to Jonas' point, in your scenario the big miners are all part of
> the majority partition, so "centralization pressure" (pressure to merge
> with a big miner) cannot be separated from "pressure to be connected to
> the majority partition".
>
> I ran your simulation with a large (20%) miner in a 20% minority
> partition, and 16 small (5%) miners in a majority 80% partition, well
> connected.  The starting point was your recent update, which had a more
> realistic "slow link" speed of 100 Mbit/s (making all of the effects
> smaller).
>
> To summarize the results across both your run and mine:
>
> ** Making small blocks when others are making big ones -> BAD
> ** As above, and fees are enormous -> VERY BAD
>
> ** Being separated by a slow link from majority hash power -> BAD
>
> ** Being a small miner with blocksize=20MB -> *NOT BAD*
>
>
> Configuration:
>* Miner group 0: 20.00% hashrate, blocksize 2000.00
>* Miner group 1: 80.00% hashrate, blocksize 100.00
>* Expected average block size: 480.00
>* Average fee per block: 0.25
>* Fee per byte: 0.000521
> Result:
>* Miner group 0: 20.404704% income (factor 1.020235 with hashrate)
>* Miner group 1: 79.595296% income (factor 0.994941 with hashrate)
>
> Configuration:
>* Miner group 0: 20.00% hashrate, blocksize 2000.00
>* Miner group 1: 80.00% hashrate, blocksize 2000.00
>* Expected average block size: 2000.00
>* Average fee per block: 0.25
>* Fee per byte: 0.000125
> Result:
>* Miner group 0: 19.864232% income (factor 0.993212 with hashrate)
>* Miner group 1: 80.135768% income (factor 1.001697 with hashrate)
>
> Configuration:
>* Miner group 0: 20.00% hashrate, blocksize 2000.00
>* Miner group 1: 80.00% hashrate, blocksize 100.00
>* Expected average block size: 480.00
>* Average fee per block: 25.00
>* Fee per byte: 0.052083
> Result:
>* Miner group 0: 51.316895% income (factor 2.565845 with hashrate)
>* Miner group 1: 48.683105% income (factor 0.608539 with hashrate)
>
> Configuration:
>* Miner group 0: 20.00% hashrate, blocksize 2000.00
>* Miner group 1: 80.00% hashrate, blocksize 2000.00
>* Expected average block size: 2000.00
>* Average fee per block: 25.00
>* Fee per byte: 0.012500
> Result:
>* Miner group 0: 19.865943% income (factor 0.993297 with hashrate)
>* Miner group 1: 80.134057% income (factor 1.001676 with hashrate)
>
>
>
> --
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>



-- 
*Yifu Guo*
*"Life is an everlasting self-improvement."*
--
___
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

[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

[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
> mailto:m...@friedenbach.org>> 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.


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 pro

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

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

[Jeff Garzik]

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

[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
yKlsr

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

[Mark Friedenbach]

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

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

[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] Mining centralization pressure from non-uniform propagation speed

[Tom Harding]

On 06/12/2015 06:51 PM, Pieter Wuille wrote:
>> However, it does very clearly show the effects of
>> larger blocks on centralization pressure of the system.

On 6/14/2015 10:45 AM, Jonas Nick wrote:
> This means that your scenario is not the result of a cartel but the result of 
> a long-term network partition.
>

Pieter, to Jonas' point, in your scenario the big miners are all part of 
the majority partition, so "centralization pressure" (pressure to merge 
with a big miner) cannot be separated from "pressure to be connected to 
the majority partition".

I ran your simulation with a large (20%) miner in a 20% minority 
partition, and 16 small (5%) miners in a majority 80% partition, well 
connected.  The starting point was your recent update, which had a more 
realistic "slow link" speed of 100 Mbit/s (making all of the effects 
smaller).

To summarize the results across both your run and mine:

** Making small blocks when others are making big ones -> BAD
** As above, and fees are enormous -> VERY BAD

** Being separated by a slow link from majority hash power -> BAD

** Being a small miner with blocksize=20MB -> *NOT BAD*


Configuration:
   * Miner group 0: 20.00% hashrate, blocksize 2000.00
   * Miner group 1: 80.00% hashrate, blocksize 100.00
   * Expected average block size: 480.00
   * Average fee per block: 0.25
   * Fee per byte: 0.000521
Result:
   * Miner group 0: 20.404704% income (factor 1.020235 with hashrate)
   * Miner group 1: 79.595296% income (factor 0.994941 with hashrate)

Configuration:
   * Miner group 0: 20.00% hashrate, blocksize 2000.00
   * Miner group 1: 80.00% hashrate, blocksize 2000.00
   * Expected average block size: 2000.00
   * Average fee per block: 0.25
   * Fee per byte: 0.000125
Result:
   * Miner group 0: 19.864232% income (factor 0.993212 with hashrate)
   * Miner group 1: 80.135768% income (factor 1.001697 with hashrate)

Configuration:
   * Miner group 0: 20.00% hashrate, blocksize 2000.00
   * Miner group 1: 80.00% hashrate, blocksize 100.00
   * Expected average block size: 480.00
   * Average fee per block: 25.00
   * Fee per byte: 0.052083
Result:
   * Miner group 0: 51.316895% income (factor 2.565845 with hashrate)
   * Miner group 1: 48.683105% income (factor 0.608539 with hashrate)

Configuration:
   * Miner group 0: 20.00% hashrate, blocksize 2000.00
   * Miner group 1: 80.00% hashrate, blocksize 2000.00
   * Expected average block size: 2000.00
   * Average fee per block: 25.00
   * Fee per byte: 0.012500
Result:
   * Miner group 0: 19.865943% income (factor 0.993297 with hashrate)
   * Miner group 1: 80.134057% income (factor 1.001676 with hashrate)


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

[Jeff Garzik]

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't see a need today" is therefore useless, because when you do reach
X day when need is apparent, the best solution then becomes an immediate
fork for which the network and markets are not prepared.

Failing to resolve the block size issue soon will simply result in most
businesses assuming relevant Bitcoin Core standards process is failing, and
proceed with the Bitcoin-XT fork.

As I've said on IRC, the "do nothing, for now" position is untenable.

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

[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

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

[Matt Whitlock]

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

[Ross Nicoll]

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 occur from 
here on, I hope it's obvious that there will be further accidental forks 
(at least unless and until someone prepares a formal proof of a Bitcoin 
wallet). We need to be more comfortable with that, and plan ahead. 
Education is key here, a lot of people don't understand what a fork is, 
how it will affect them, how to recognise a fork or how to recover. I'll 
dig out what materials I've written already and try making them more 
widely available, as a start.

On whether code forks are a solution to disagreements - I'm not quite 
sure what people expect will happen where a group believes there is an 
existential threat to Bitcoin and they cannot get Bitcoin Core updated. 
I may disagree with Mike & Gavin on timescale, but I do believe there's 
a likelihood inaction will kill Bitcoin, and in that context I see the 
rational choice as taking the perceived smaller risk of a fork killing 
Bitcoin. BIP100 appears to be making progress, however, right now I 
think the best option is pursuing it towards something that can be 
agreed on by all. I would also happily go with an 8MB block size even if 
just to buy us (IMHO a lot) more time.

Lastly, there seems to be a number of people who believe inaction 
through apathy is fine. I respect those who form considered opinions and 
tell me why they believe 1MB is fine, but I do ask that people either 
put the effort in to help make decisions, or delegate to someone else. 
Decentralised does not mean there's no decision making, it means we're 
all decision makers, and frankly I think there's effectively negligence 
in that capacity right now. I'd also point out this ongoing discussion 
is a huge time sink to a number of people who could be making much more 
useful contributions, and that again going in circles endlessly 
discussing in the name of decentralisation isn't positive.

I have failed at being brief, apologies.

Ross


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

[Gregory Maxwell]

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 based on their own personal network. If you're assuming this is a 
> serious motivating factor for anyone, then I'm not sure you've even been 
> reading your email or listening to the conversations you've had with people 
> over the last year or more.

It's probably due to me: When I point to trends and broadband
_distribution_ in the US (much less the less developed parts of the
world), I'm being "hypothetical", and when I point to my _own_
connectivity as a concrete example it's "personal". It's no joke that
communication is _hard_ but it's a shared responsibility however, and
no need to assume anyone isn't reading.,

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

[Matt Corallo]

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

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 
based on their own personal network. If you're assuming this is a serious 
motivating factor for anyone, then I'm not sure you've even been reading your 
email or listening to the conversations you've had with people over the last 
year or more.

On June 18, 2015 11:23:33 AM PDT, 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 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."


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

[Jorge Timón]

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 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.
>
> [...]
>
> 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."

But according to Alex's explanation (which I think is very good
leaving asides some cases like change of the pow hashing function, for
example) there's no individual that can force or veto a change. It is
the decision of each individual user and their own "pretty much
everybody" may vary. But this "pretty much everybody" is what Mark
referred to with the "I know it when I see it."

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

If you recommend users to apply changes when this criterion is met but
you know there's still many users who don't agree with the change,
then you're acting irresponsibly by promoting a chaotic consensus fork
where coins can be spent in both chains at once.
Well...unless you're promoting it as an altcoin that simply happens to
distribute part of the initial monetary based to bitcoin holders at
block X and whose genesis block is equal to bitcoin's genesis block at
block X. I guess in that case you wouldn't necessarily be
irresponsible.
"Miner's vote" is irrelevant here since it cannot tell you anything
about users adoption (besides miner's adoption of course).

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

But this is only relevant for the point 1. Software projects can have
dictators, forks and everything else other free software projects
have. But consensus-based p2p blockchains cannot change their rules in
the same way, otherwise they're centralized.

THERE CANNOT BE A VOTING PROCESS FOR CONSENSUS CHANGES.
If anybody can vote, hod do you prevent the sibyls from outvoting everyone?
If not everybody can vote, how is the voters' list determined without
centralizing the system?
If we had a technical solution to this problem we wouldn't need proof
of work in the first place!!

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

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

[Gavin Andresen]

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

[Melvin Carvalho]

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

[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

[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,  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

[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

[Jeff Garzik]

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

[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

[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

[justusranvier]

-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 way to describe the situation.

The purpose of Bitcoin to let people trade with each other, and trade 
requires mutual agreement.

If some people choose not to trade under certain terms, they aren't 
"forcing" anybody to do anything. They are simply refraining from 
proposed interactions. Not granting them the right to do this would 
actually be forcing them to engage in interactions against their will.

It's an unavoidable reality that Bitcoin's usefulness is related to the 
size (really: economic output) of the group of people who can be 
convinced that it's in their best interest to agree on a common trade 
protocol.

Conversations that feature untrue claims about someone forcing someone 
else to do something is the opposite of a viable strategy for growing 
the size of that group.

Arguments about who violated what Bitcoin Core internal governance 
procedures are not interesting to most Bitcoin users, who generally 
don't know or care who has commit access to the repository.

Getting angry at Gavin and Mike for providing Bitcoin users with an 
alternative which they can freely choose or reject is not helpful in 
persuading users to stay with Bitcoin Core. Making the case why the 
changes in Bitcoin XT are not beneficial to Bitcoin users could be.

For better or for worse, Bitcoin coin users are going to run the 
software they perceive to be in their best interests.  Nobody can stop 
them from making that choice and any effort directed at that end is 
wasted.

It's more productive to expend effort making sure the current and future 
Bitcoin users are as informed as possible about the long term and short 
term consequences of their choices.

Circling back to the original quote:

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. Bitcoin is a negotiation about the best way 
for money to function in the future. The only way we get people to use 
Bitcoin is to convince them that the benefits they gain from agreeing to 
its protocol outweigh the downsides they encounter.

I'm confident that this case can be made successfully but a prerequisite 
to a successful negotiation is recognizing that it is, in fact, a 
negotiation, and that the other parties have full agency and the right 
to walk away if mutual agreement is not reached.

My suggestion is to spend less time talking about procedural violations 
and more time convincing Bitcoin users that Bitcoin Core is the best 
client for them to use, especially if the process of convincing them 
involves making improvements which the users are asking for (or making a 
very compelling case about why the users should reconsider).

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJVguyLAAoJECpf2nDq2eYjTPgP/A16QGWSWkh50OhSjHx7hdY5
v0ZqNvfKSm6a94o22yTQF8VZm7NEJJcNY0Vvu1ro95v27Bm37VodGGOXh4ao9gYQ
ETdzX35OLWUua1e9kfEwgo2Uu2l9AdALOLK5IHyLZdtxJQwUhcdeIhaSMzlZqgEk
n+gbAZXV7JdnK+oejh5s8zgfOY3MqhZC3TQBVWHWx0K0CE75rm0j4ZShYL2eKOua
CmWkcEkfeugrnQQv/BB+oe1TAJoHY4bZAr+amYLZMiC8wRcGGeVBOOFykLNd4rSV
DE+iiGHmgi/wrZjy/xT5kflX55GE8NNVjM2MMNOyD+gWbBn5INahya+DkDWupeQB
iy71NQQVnB/5U5Yhm/oVUax+Cjj/7001cf1q2rXPcjE+4ntw5ad9oCuRW3kSUpzq
C0LqEN2lbagrmk/xHSv/GQl+iWulD1mXJl63y3LdXYWno67eVYqzvRK0UB7ZSVww
3P7p8h2yuvtPtAUDyoOPn7Ghyd1U1lJWGsyffRzd2hWhEYs44cfAv6S2QWIBWbm5
j8C2ao7m6j2mirRZem+bGrN8idR/fOUIjnwqQmNIObsviMrvgXlHvORjsBcdHoKO
9Ir8CvqGWftIG5lLCJvjsnP8E3MRToo6pOsD/Ii9223Pn6DxsMvXF+IkZzUJfWDR
W+t/BYV6XtsAUKI+dAly
=3KeB
-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

[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

[Gregory Maxwell]

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 block size change and then merge it, he
> would revert it. And I fully believe he would do so!

http://www.reddit.com/r/Bitcoin/comments/37pv74/gavin_andresen_moves_ahead_with_push_for_bigger/croxw9o?context=1

This is the only reddit comment I've made using the word revert in
recent memory, so I know you couldn't be referring to another.

>> I was recently in a situation similar to what Gavin is in insofar as a 
>> design dispute that could improperly solved by a git push. I'm pretty 
>> impressed he hasn't given in and done a midnight push. It's cool to see him 
>> back channeling support.
> Such a change would be immediately reverted.

And, I probably should have continued "and resulted with an immediate
revocation of commit rights on the assumption that his account had
been compromised."

There is nothing controversial about that.

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

[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

[Milly Bitcoin]

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




There is always a process.  Right now the process is haphazard, unclear, 
and constantly changing without being written down so people don't 
actually know what it is.  In fact you do not all have a reasonable 
understanding of "technical consensus" because if you did then you could 
write it down ... but you can't.   The current process is being gamed by 
people making tweets, reddit posts, videos, and blog posts.  A more 
formalized process would channel that activity into a a more usable format.


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.


Russ


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

Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork

[Jorge Timón]

On Tue, Jun 16, 2015 at 2:08 AM, Aaron Voisine  wrote:
>
> hell even some major changes to the non-consunsus code to make it
adequately handle the situation when blocks fill up


This will have to eventually be done in addition to any other "alternative"
unless the plan is to keep rising the limit until it is removed or
irrelevant.

Maybe this should be the priority? Maybe this is the "alternative" that
some no-block-size-limit proponents (meaning people who think that
centralization is not a concern when deciding the block size limit) claim
nobody was putting forward?

Anyway, it's sad that we're always mixing 2 different topics: hardfork
deployment and blocksize limit. I wish we talked more about the former, I
wish we would have talked about it it long before the block size debate
became "urgent" (or at least before it was being perceived as urgent).
We've had plenty of time to deploy non-emergency hardforks but apparently
no one was interested (say, for fixing miner but known bugs like the
timetravel attack).
In fact, I plan to eventually propose such a fork, I agree with gavin that
"hardforks aren't possible" is not an answer, though finding opposition to
a concrete hardfork in a concrete point in time doesn't mean that
"hardforks aren't possible". I believe I have proposed many more hardforks
than Gavin, all of them rejected and I still hope some of them will
eventually make it into bitcoin main.
When it was clear that wouldn't be the case I'm afraid the only answer is
creating an altcoin (like Mark and I did with Freicoin and "xtcoin" could
become [hopefully not destroying bitcoin main in the process]).

On Tue, Jun 16, 2015 at 2:08 AM, Aaron Voisine  wrote:

> Wasn't the XT hard fork proposed as a last resort, should the bitcoin-core
> maintainers simply refuse to lift the 1Mb limit? No one wants to go that
> route. An alternate hard-fork proposal like BIP100 that gets consensus, or
> a modified version of gavin's that ups the limit to 8Mb instead of 20Mb, or
> hell even some major changes to the non-consunsus code to make it
> adequately handle the situation when blocks fill up, and allow wallet
> software to continue working with a send-and-forget use pattern, any of
> these would be enough to avoid the need for an XT only hard-fork.
>
> So far BIP100 is the only one that seems to actually be getting any sort
> of momentum toward consensus, and it was proposed... 2 days ago? When the
> XT fork was proposed as a last resort, it was when the opponents were (to
> my understanding) suggesting we just let blocks fill up, and hopefully
> things would just work out on their own.
>
>
>
> Aaron Voisine
> co-founder and CEO
> breadwallet.com
>
> On Mon, Jun 15, 2015 at 3:56 PM, Brian Hoffman 
> wrote:
>
>> Who is actually planning to move to Bitcoin-XT if this happens?
>>
>> Just Gavin and Mike?
>>
>> [image: image1.JPG]
>>
>> On Jun 15, 2015, at 6:17 PM, Faiz Khan  wrote:
>>
>> I'm quite puzzled by the response myself, it doesn't seem to address some
>> of the (more serious) concerns that Adam put out, the most important
>> question that was asked being the one regarding personal ownership of the
>> proposed fork:
>>
>> "How do you plan to deal with security & incident response for the
>> duration you describe where you will have control while you are deploying
>> the unilateral hard-fork and being in sole maintainership control?"
>>
>> I do genuinely hope that whomever (now and future) wishes to fork the
>> protocol reconsider first whether they are truly ready to test/flex their
>> reputation/skills/resources in this way... Intuitively, to me it seems
>> counterproductive, and I don't fully believe it is within a single
>> developer's talents to manage the process start-to-finish (as it is
>> non-trivial to hard-fork successfully, others have rehashed this in other
>> threads)...
>>
>> That being said I think it appropriate if Adam's questions were responded
>> in-line when Mike is feeling up to it. I think that the answers are
>> important for the community to hear when such a drastic change is being
>> espoused.
>>
>> Faiz
>>
>> On Mon, Jun 15, 2015 at 4:56 PM, Bryan Bishop  wrote:
>>
>>> On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn  wrote:
>>>
 Re: anyone who agrees with noted non-programmers Mike&Gavin must be
 non-technical, stupid, uninformed, etc  OK, go ahead and show them the
 error of their ways. Anyone can write blogs.

>>>
>>> I worry that if this is the level of care you take with reading and
>>> (mis)interpreting Adam's messages, that you might not be taking extreme
>>> care with evaluating consensus changes, even while tired or sleeping. I
>>> encourage you to evaluate both messages and source code more carefully,
>>> especially in the world of bitcoin. However, this goes for everyone and not
>>> just you. Specifically, when Adam mentioned your conversations with
>>> non-technical people, he did not mean "Mike has talked with people who have
>>> possibly not made pull re

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

[Milly Bitcoin]

 >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 reply.  Just saying the users 
ultimately decide is not an adequate explanation of the situation. You 
are talking hard fork if someone doesn't like it.  If 10% of the users 
don't like there is nothing they can do unless they want to operate an 
altcoin.  You are not going to resolve anything by repeating these types 
of replies that really have no applicability in the real world.  The 
person who approves the pull request (no matter what the process is 
beforehand) is effectively the decider.

Also, as pointed out, there is no real process in place.   Making 
offhand statements that "multiple ACKs are required" without describing 
a real process just sends people down a rat hole like this block size 
debate.  Providing these (non) answers instead of developing a real 
process is why there is so much contention now.

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

[Mark Friedenbach]

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

[Jeff Garzik]

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

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.

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

[Jeff Garzik]

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://github.com/bitcoin/bitcoin/blob/0.11/doc/release-notes.md#0110-change-log,
>> or follow pull requests for a while, to see how many decisions about
>> changes are made from day to day. No, I'm not sitting on my hands, and so
>> is none of the other contributors that you'd like to get rid of.
>>
>
> The analogy goes further even. Even though I disagree with some of the
> changes you're making, I respect Mike's (and anyone's) right to make a fork
> of Bitcoin Core. That's how open source works: if people disagree with
> changes made or not made, they can maintain their own version. However:
>
>
>> Consensus changes are *much* more difficult, on the other hand. Even
>> relatively straightforward softforks come with a long discussion process
>> (see BIP62, BIP66). A hardfork is hard to do at the best of times (everyone
>> needs to upgrade their software!), and simply not possible if almost the
>> entire technical community disagrees with you.
>>
>
> Consensus changes - in particular hardforks - are not about making a
> change to the software. You are effectively asking users of the system to
> migrate to a new system. Perhaps one which is a philosophical successor to
> the old one, but a different system, with new rules that are incompatible
> with the old one.
>

Indeed.  I think Mike is glossing over this major facet.

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.

Changing bitcoin's rules IS IN NO WAY like Wikipedia or other open source
software.

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

[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] Ninki Wallet view on blocksize debate

[Stephen Morse]

Ben,

How does your wallet calculate the fee that should be paid to miners? Do
they automatically adjust when transactions take a long time to be
confirmed? And how does it respond when transactions are not mined
successfully, such as when blocks are full?

I strongly urge Gavin to withdraw from this standoff and work with the
> bitcoin core devs via the existing and successful bip process.
>

The BIP process has not resulted in any hard forks, so this is a little
different. While I don't like M&G's proposed solution of convincing miners
and services to switch to Bitcoin-XT, I recognize that it is done out of a
sense of urgency. These types of changes take a long time to roll out, and
we should start them before it is too late.

This whole debate comes down to: what is more risky, a consensus hard fork
or letting bitcoin exceed its imposed capacity limits? The former could
result in many services not being compatible and even loss of funds. The
latter could result in software failures, instability, and inability to
transact: essentially, what bitcoin is supposed to be good at. Both are
dangerous and could result in a significant loss of public confidence.

Something needs to be done, that's for sure. In the short term, I think we
need to do one of two things:

   1. All miners and wallet developers need to upgrade to support
   first-safe RBF, to allow for double spending one's own transactions when
   they lack sufficient fees to merit confirmations. Wallets also need to
   randomly request transactions from blocks to see what kind of fees are
   being paid to get confirmations, so that fees can be paid dynamically
   instead of with hard-coded values.
   2. We can implement either Gavin's or Jeff Garzik's proposal to change
   the consensus parameters around the block size limit.

So Ben, if really don't think that going with #2 is the right way to go
(even though everyone agrees that we will need to increase the block size
limit eventually anyway, why not now?), then I hope you start to work hard
on implementing #1 so that your wallet software can handle hitting capacity
limits gracefully.

Best,
Stephen
--
___
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

[Bryan Bishop]

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

[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

[Wladimir J. van der Laan]

-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 open to manipulation.

It looks as if you entirely missed my point. I'm The Decider for *code issues* 
regarding Bitcoin Core. Consensus issues should not be considered part of that, 
they span multiple implementations.

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, and as 
Sipa explained in his.

Speaking of process, let me remind you that there is a BIP processs: 
https://github.com/bitcoin/bips/blob/master/bip-0001.mediawiki 

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.

Wladimir
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCgAGBQJVgtAOAAoJEHSBCwEjRsmmLPUH/1ug5pvLz6ptIhvuROclV7Jh
z0Szk5FOqfg4ejT3nYV5LRV5WNHUGDdFnHZJRFsKYH9B0LFgOlnkc488Qg6hBb+1
rf5zEF/D2X4MhPIx6GqI++gvhDzdBH2t9yxbU7LVZALo7+wtW+ms5eHHFs8WrU0z
m7NgiZRen4cpQUiBWHlt0PojmXBVZQNU0CD6ErcOpQXhN8J0sb0l0DuFswQgUqxk
rrNe3LvKp89xT0kDxyzQts/CeIG/8kQYLwIJ1QQDXvYayj2aHHYMkSEWfDlew3IC
zQkFgHCTGihGHPFeow+dnuW1DI1l92yPYNDLbxivSam3X+qCAGzUTOWTFE+iprk=
=tE4K
-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

[Pieter Wuille]

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% 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.
>
> But let's leave it to one side for a moment.
>
> Let's focus on the other issue:   what happens if the Bitcoin Core
> decision making process goes wrong?
>

Why do you keep talking about Bitcoin Core maintainers? The means for doing
a hard fork is convincing the network to run modified code, whether that is
a new version of Bitcoin Core or a fork of it, or something else entirely.

If I see consensus about a proposed network change, I will be in favor of
implementing it in Bitcoin Core. But we're not at that point. There is no
network change proposed with consensus. There is not even a patch to be
discussed. There are working proposals, and people are talking about them.
This is good.

I think maintainers of particular software should not be, and are not those
who decide the network's rules. People running the code are. Of course
maintainers have a large influence, but so do other people - like you.

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

I believe so too, and I would do the same. Because I believe implementing a
consensus rule change without having very good expectations that the
network will adopt it, is reckless from the point of view of maintainers,
for all reasons I have mentioned before.

-- 
Pieter
--
___
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

[Mike Hearn]

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 Bitcoin *can* be changed, and
have been before (e.g. P2SH), with software upgrades.

When such a fork happens, any user who does not upgrade their node isn't
fully verifying the block chain anymore. Their software might *think* it
is, but it's running NOPs that don't mean NOP to other nodes. So there is a
divergence in the consensus, it's merely been done in such a way that the
node won't stop and print "hard fork detected" to the logs. It'll happily
accept a block that violates the new rules, then wait to be corrected by
miners.

So with any fork, hard or soft, there is risk to those who don't upgrade.
They may accept a block, or even two blocks, that they believe are valid
according to their old rule set, but which other miners would reject. The
effect on double spending is much the same.

Now let's talk philosophy.

* Philosophy: Bitcoin is not a democracy.
>

This appears to be a key point of dispute. Bitcoin is a democracy, though
the analogy is not perfect. You can certainly believe whatever you like
about the true state of the ledger, but rubber hits the road the moment you
go and trade with other people.

If 90% of the people you trade with believe a coin exists, and you don't,
you're gonna discover you keep getting paid with that coin and its
descendents. You may hate it, you may feel your rights are being violated,
you may refuse to trade with those people but it will keep happening.

Money is about trade, and trade inherently involves the decisions of other
people. No man is an island.

With Bitcoin we have a great way to quickly find out what other people
believe about the ledger. If the vast majority of people are on ledger A
and you're on ledger B, then you've got a strong incentive to come into
line with the majority in order to keep trading.


> Changing the rules should be possible if there is wide consensus, but
> nobody should feel forced to change their code against their will.
>

Nobody, not even after a hard fork, is *forced* to change their code
against their will. It may be something that *other people require* as part
of trading with them though. Whether one considers this "forced" or not I
guess can be argued either way. Are you "forced" to buy oranges from the
single orange seller in town if the other goes bankrupt, or could you just
avoid oranges? Where does economic freedom begin and end?


> * Governance: being able to push for a controversial change to the system
> sets an incredibly dangerous precedent about who is in charge of the
> system's rules.
>

I think it's surely the opposite - *not* being able to push for
controversial changes sets an incredibly dangerous precedent. Namely,
whoever gets to decide that a change is controversial gets to veto anything
they like!


> I can promise you that I will say anything in mail to this list if someone
> points a gun at me
>

Indeed, me too! But it's worse than that: what if someone sockpuppets a
discussion to make it look like a change does or does not have consensus?

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 open to manipulation.

Good thing we have a way to resolve this problem:  the block chain. Now it
doesn't matter if someone points a gun at you or me. We can object to
whatever we like and that wouldn't bring Bitcoin to a halt, thus removing
the incentive to try and pressure individuals.

But if we don't have that ability to vote through choice of software and
rulesets, then us poor developers really are in charge and that's not a
place any of us should want to go. There must be a mechanism for people to
disagree with the consensus, even in major, controversial ways, and that
mechanism must have real force to it.
--
___
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

[Milly Bitcoin]

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 reached yet nobody can point to an actual 
process.  If companies are expected to dedicate resources to adopt 
Bitcoin there needs to be some type of process spelled out that can give 
these entities at least minimal assurance that there is some type of 
process in place.  I think the whole process is based on how certain 
personalities handle issues but as those personalities change the system 
changes in unknown ways which equates to risk.

The other thing that is immediately clear is that there is no systems 
engineering process in place to make changes.  A "risk study" was done 
by the Bitcoin Foundation but that is only the first baby step in the 
process.  It works by defining a set of risks, likelihood, mitigations, 
etc.  and a risk matrix and maintaining those as living documents.   
When changes are proposed alternative scenarios are created and they are 
measured against the baseline of what there is now.  Standard test plans 
are created to measure the changes against defined metrics.  It is a lot 
of work to define those risks to the level of detail needed for work 
like this.  However, the amount of time/energy saved in the end is 
tremendous.   Right now the process is haphazard at best with people 
posting random tweets, Reddit posts, blog posts, etc.  All this drama 
makes Bitcoin look somewhat amateurish and rather risky.

http://www.dtic.mil/ndia/2004cmmi/CMMIT1Mon/Track1IntrotoSystemsEngineering/KISE09RiskManagementv2.pdf

https://bitcoinfoundation.org/wp-content/uploads/2014/04/Bitcoin-Risk-Management-Study-Spring-2014.pdf

Some people also seems to conflates the notion of decentralization of 
the state of the ledger by mining/nodes with that of decentralization of 
open source software by forking the software. These are very different 
problems and I don't think it is possible (or even desirable) to achieve 
the same level of decentralization for both things.  In any case 
"decentralization" for the state of the blockchain is only an 
approximation anyway since there are things like 51% attacks and 
checkpoints.

Russ




On 6/18/2015 7:14 AM, Wladimir J. van der Laan wrote:
> -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 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.
> Bitcoin Core is completely different from your average open source project in 
> one aspect: where it concerns consensus.
>
> 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 follow pull requests for a while, to see how many decisions about changes 
> are made from day to day. No, I'm not sitting on my hands, and so is none of 
> the other contributors that you'd like to get rid of.
>
> Consensus changes are *much* more difficult, on the other hand. Even 
> relatively straightforward softforks come with a long discussion process (see 
> BIP62, BIP66). A hardfork is hard to do at the best of times (everyone needs 
> to upgrade their software!), and simply not possible if almost the entire 
> technical community disagrees with you.
>
> Bitcoin is supposed to be a robust, global, decentralized network beyond 
> anyone's control. It makes *no sense* to try to run it as a dictatorship. 
> This would create a handy central position where power can be applied, 
> pushing through changes to the behavior of the system, either by force or 
> other ways of motivation. I refuse to take part in that.
>
> Hence, anything that is controversial needs to be considered really 
> carefully. If I suddenly start making changes to the consensus code without 
> full agreement, by all means take away my commit privileges.
>
> (a major reason for the ongoing libconsensus work is to separate "Bitcoin 
> Core, the node software" and "The Bitcoin Consensus" along clear lines, to 
> avoid this kind of nasty confusion)
>
> Wladimir
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQEcBAEBCgAGBQJVgqfOAAoJEHSBCwEjRsmmFT8H/Rkm29AhLhT8R1Vx8oKUIzID
> +NB7tOps3lIilkDQIC5zHSknx5iugrrAdRf1w7qPj/o8+xhCZw9ruu8eIq+djkRQ
> tvzbHil2pqgT3VHriRlY4lvlmu2NmBcYrAuX9sDhUHBo6cwGajfKMJPfE0haK3K4
> 7EmfdGXJYJmiBnhE6ikOiU687M2WgsmIGrBDIxeA5wYwVK9Ph8hfcbuj7AHvIMI9
> ZNU/V6uhcTjn5wT+6DHGIOxHipYHyAwKb7jKho0XkM6Yi4ORe1mxF5HDtqA0ztta
> mZPNjNrt/ngK20x

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

[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

[Mike Hearn]

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

But let's leave it to one side for a moment.

Let's focus on the other issue:   what happens if the Bitcoin Core decision
making process goes wrong?

For the sake of argument let's pretend we're discussing a different change,
let's imagine there is a proposal to change the block format to include a
Widget, where a Widget is some potentially desirable thing. And this change
means a hard fork. Let's put the block size to one side for a second to
avoid getting distracted.

Imagine that 90% of people in Bitcoin want their Widgets, but one of your
committers refuses to accept it.  I am not saying the block size debate has
such proportions but pretend Widgets do.

What is the process for resolving this problem?

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

What you're saying is - there is no process because a contentious hard fork
must never happen. Such a change is simply impossible.

Now which is a better description of this situation? Is the "it must never
happen end of story" really the cuddly warm democracy that you seem to
suggest? Or is it more like a dictatorship where the opinions of one or two
people can override all the others?

The typical answer I'm seeing to this is that Bitcoin Core's own decision
making process is so fantastic that it never goes wrong, even though
"consensus" is not defined and "technical majority" is not defined and we
have serious long time contributors on this mailing list (such as wallet
developers) disagreeing with this consensus yet our feedback is being
ignored.

You guys *must* accept that your preferred process for resolving disputes
is, itself, in dispute. That leaves the block chain itself as the only
remaining method for bringing this saga to a close.

So this is why we keep disagreeing:

   - If Bitcoin Core has reached a formal decision made by the maintainer
   via whatever mechanism he likes to not accept the block size increase, then
   alright, technical disputes will happen. But 

   - You should agree that the next step is a fork of both the software and
   the block chain. And you should welcome such a thing because it is the ONLY
   check on your own power. It's the one thing that allows the community to
   reject the decision making process you are using in case it goes wrong.

I keep reading that Bitcoin cannot survive a hard fork. Well, we've
survived an accidental fork that happened without anyone being prepared,
and even with a planned soft fork "never upgrade" isn't really an option
for either miners or businesses, so ultimately node operators must know
about upgrades and make them. Both myself and Gavin think this process can
work out OK.

Do you at least understand where we're coming from here, even if you
disagree? And if you disagree, is it because you think a hard fork to
resolve a dispute can't work technically, or is it some other reason?
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Ninki Wallet view on blocksize debate

[Team Ninki]

Hi,

I am the developer for Ninki Wallet which has recently been listed on
bitcoin.org.

FWIW I support the approach of the existing bitcoin core dev team having
observed their work for the last year and their attitude towards consensus,
a clear process for change and discussion of changes.

I think, like everyone else, that the block size limit will have to be
increased in the future, but I don't like to see this done in a gung-ho way
without an established consensus on how bitcoin will scale *with*
decentralization and maintain it's key value property.

I would not support any group that attempts to fork the blockchain in the
manner proposed using XT. I strongly urge Gavin to withdraw from this
standoff and work with the bitcoin core devs via the existing and
successful bip process.

Thanks

Ben
--
___
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

[Benjamin]

"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/overriding the
network. So Mike and Gavin are using the trust and relationship they
have garnered through Bitcoin for their purposes (malicious or not).
There are only 20-30 people with the same kind of recognition who
would be able to do that. M&G already wanted to make a fork in 2014
for entirely different reasons (http://pastebin.com/3kt5Reeh).

On Thu, Jun 18, 2015 at 2:50 PM, Wladimir J. van der Laan
 wrote:
> -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 the changelog for e.g. 0.11
>> > https://github.com/bitcoin/bitcoin/blob/0.11/doc/release-notes.md#0110-change-log,
>> > or follow pull requests for a while, to see how many decisions about
>> > changes are made from day to day. No, I'm not sitting on my hands, and so
>> > is none of the other contributors that you'd like to get rid of.
>> >
>>
>> The analogy goes further even. Even though I disagree with some of the
>> changes you're making, I respect Mike's (and anyone's) right to make a fork
>> of Bitcoin Core. That's how open source works: if people disagree with
>> changes made or not made, they can maintain their own version. However:
>
> Sure. According to github, there exist 4890 forks of the bitcoin/bitcoin 
> repository.
>
> Forking the code is perfectly fine in itself, that doesn't even need to be 
> said, it's how open source works. Make your changes, run your own version, 
> contribute back the changes (or not).
>
> 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.
>
> Wladimir
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1
>
> iQEcBAEBCgAGBQJVgr5LAAoJEHSBCwEjRsmm5mMH/0yLGGQQefRVdmM/nJZ60b/z
> iTCUUzY4eLL67FRC6pqGA18RdUt4Etl4wEqvgXH/B9mWIAM2yQD/jnxutYrEIoBT
> 8Jyd1OhmmKF8MN5/uE7JNPivIuHs0ioF+qTxlbdElpVZ2NodVotznbTvuqJgXUFb
> c9Et5L5n7g55uPzDt+MSV5iBDJaMiBAnZA00aTLGmYmNXxcy7xBwCFX3dDij8krv
> 0+zdpNNAKm85k1rG2jHCM+0onu+TOIur03pPd5OZktgr18P6UvAQ6A59yAkGgFai
> 4l6VVNJ40g3PzItGQ7wsKZ8s/qG5LlcEppxMlG6CX1dIDpxbrwx2aJmeNjwSLKQ=
> =LbA3
> -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

[Wladimir J. van der Laan]

-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 the changelog for e.g. 0.11
> > https://github.com/bitcoin/bitcoin/blob/0.11/doc/release-notes.md#0110-change-log,
> > or follow pull requests for a while, to see how many decisions about
> > changes are made from day to day. No, I'm not sitting on my hands, and so
> > is none of the other contributors that you'd like to get rid of.
> >
> 
> The analogy goes further even. Even though I disagree with some of the
> changes you're making, I respect Mike's (and anyone's) right to make a fork
> of Bitcoin Core. That's how open source works: if people disagree with
> changes made or not made, they can maintain their own version. However:

Sure. According to github, there exist 4890 forks of the bitcoin/bitcoin 
repository.

Forking the code is perfectly fine in itself, that doesn't even need to be 
said, it's how open source works. Make your changes, run your own version, 
contribute back the changes (or not).

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.

Wladimir
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCgAGBQJVgr5LAAoJEHSBCwEjRsmm5mMH/0yLGGQQefRVdmM/nJZ60b/z
iTCUUzY4eLL67FRC6pqGA18RdUt4Etl4wEqvgXH/B9mWIAM2yQD/jnxutYrEIoBT
8Jyd1OhmmKF8MN5/uE7JNPivIuHs0ioF+qTxlbdElpVZ2NodVotznbTvuqJgXUFb
c9Et5L5n7g55uPzDt+MSV5iBDJaMiBAnZA00aTLGmYmNXxcy7xBwCFX3dDij8krv
0+zdpNNAKm85k1rG2jHCM+0onu+TOIur03pPd5OZktgr18P6UvAQ6A59yAkGgFai
4l6VVNJ40g3PzItGQ7wsKZ8s/qG5LlcEppxMlG6CX1dIDpxbrwx2aJmeNjwSLKQ=
=LbA3
-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

[Pieter Wuille]

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 follow pull requests for a while, to see how many decisions about
> changes are made from day to day. No, I'm not sitting on my hands, and so
> is none of the other contributors that you'd like to get rid of.
>

The analogy goes further even. Even though I disagree with some of the
changes you're making, I respect Mike's (and anyone's) right to make a fork
of Bitcoin Core. That's how open source works: if people disagree with
changes made or not made, they can maintain their own version. However:


> Consensus changes are *much* more difficult, on the other hand. Even
> relatively straightforward softforks come with a long discussion process
> (see BIP62, BIP66). A hardfork is hard to do at the best of times (everyone
> needs to upgrade their software!), and simply not possible if almost the
> entire technical community disagrees with you.
>

Consensus changes - in particular hardforks - are not about making a change
to the software. You are effectively asking users of the system to migrate
to a new system. Perhaps one which is a philosophical successor to the old
one, but a different system, with new rules that are incompatible with the
old one.

I believe this is something that can only be done if there is no
controversy about the change, for different reasons:

* Risk: no matter how you determine the switchover date, there is no way of
knowing when (and whether at all) everyone changes their full nodes (and
perhaps other software), and even very high hash power votes cannot prevent
an actual fork from appearing afterwards. At best, people lose the
guarantee that their confirmations are meaningful (because at some point it
becomes clear that the other side will get adopted, and they need to
switch). At worst, a fork persists, and two partitions appear, in each of
which you can spend every pre-existing coin. This defeats the primary
purpose Bitcoin was designed for: double spend protection.

* Philosophy: Bitcoin is not a democracy. The full node security model is
designed to minimize trust in other parties in the system. This works by
validating as much as possible according to the consensus rules. In
particular, there is no "majority vote" that can override things (contrary
to what some people think, it is not "longest chain wins, and a majority of
miners decide"; even a majority of miners cannot steal your coins or
produce more than the allowed subsidy, unless they convince others to
change their software). Changing the rules should be possible if there is
wide consensus, but nobody should feel forced to change their code against
their will.

* Governance: being able to push for a controversial change to the system
sets an incredibly dangerous precedent about who is in charge of the
system's rules. What if next time it is a change demanded by parties with
less good intentions (and yes, I believe people in this discussions all
have good intentions to improve the system in a way they think is most
useful)? I can promise you that I will say anything in mail to this list if
someone points a gun at me, and I think you should make the same assumption
about other people here. By avoiding controversial changes, you avoid
external and potentially invisible manipulation.

Of course, sometimes changes to the consensus rules may be wanted. The
presence of a bug is a good reason, and widespread agreement about one of
the system's limitation is too. As I said before, I think technological
growth in network bandwidth, processing power, and storage, are a good
reason why the system should be able to scale proportionally. I think there
are good technical and economic reasons why we should be cautious about
this, but the primary requirement is consensus, and aligning people's
expectation about what they can expect from network's evolution.

-- 
Pieter
--
___
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

[Wladimir J. van der Laan]

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

And allegations that the project is "run like wikipedia" or "an edit war" are 
verifyably untrue.
Check the commit history.
How many reverts do you see? How many of those do you see that are not simply 
to get rid of unexpected bugs, to be re-merged later?

Not much more than two, in ~5500 commit over six years. I feel sorry for you 
that `getutxos` was rejected in a messy way, still you are so held up about it 
and keep repeating it as if it is a daily occurence. Disingenuous, at the least.

Wladimir
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCgAGBQJVgq/WAAoJEHSBCwEjRsmm8NUIAI/csucOmfF9e+BtSH+uruhl
ox32stQfD3hwcKropLEPFfKvmOcRU1nXBy6lcvhG+axw+WqpC48EvpD73P/BuSv7
RvlLayqP+D6oiNsH+7S7C0/ndy+Pne04D+srSSBhXKfZMqruBqmUSontziJZTeLR
C6CCFwFSAvSXGV873I3i4M4U5QqIrE5PyuK75wjl2SFisd2LjBgfzZh4HDbz85Qr
gApLpdTxu4gDkGx4B9txCkfyb5W2z8nawWYb7+O7y/NbFL1Qlb36MzGuVKL6Zj1z
B8kJrOLVW9ItduVRY/03wLsqBuGC9fjuhWexjKenvMpxfO//VvOxIBA7sCDrxjU=
=lisE
-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

[Lawrence Nahum]

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 risks everyone's bitcoins) - I hope we all 
agree there is no point in a centralized Bitcoin?

In addition and more importantly, it would put Gavin in tremendous dangers, 
both from violent threats/blackmailing prospective as well as regulatory 
prospective - how can you not see that?

I hope all this confrontation will be worth something in the end: to show 
that Bitcoin can't be changed centrally and that it can't be changed without 
consensus


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

[Bitcoin-development] Video summarizations of blocksize issues?

[grarpamp]

On Thu, Jun 18, 2015 at 4:54 AM, odinn  wrote:
> Recently I saw the following video:
> https://www.youtube.com/watch?v=8JmvkyQyD8w&t=47m58s

For those loosely following the technical issues from outside development
circles, but who may be pressed into a voting/adoption type position (miners,
users, investors)... is there a parallel presentation of the concepts and
arguments from the other side (both, or the various, sides) that they
can refer to?
Someplace where they are collated and presented? A wiki perhaps?
Are these even valid or necessary questions?

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

[Wladimir J. van der Laan]

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

Bitcoin Core is completely different from your average open source project in 
one aspect: where it concerns consensus.

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 follow pull requests for a while, to see how many decisions about changes 
are made from day to day. No, I'm not sitting on my hands, and so is none of 
the other contributors that you'd like to get rid of.

Consensus changes are *much* more difficult, on the other hand. Even relatively 
straightforward softforks come with a long discussion process (see BIP62, 
BIP66). A hardfork is hard to do at the best of times (everyone needs to 
upgrade their software!), and simply not possible if almost the entire 
technical community disagrees with you.

Bitcoin is supposed to be a robust, global, decentralized network beyond 
anyone's control. It makes *no sense* to try to run it as a dictatorship. This 
would create a handy central position where power can be applied, pushing 
through changes to the behavior of the system, either by force or other ways of 
motivation. I refuse to take part in that.

Hence, anything that is controversial needs to be considered really carefully. 
If I suddenly start making changes to the consensus code without full 
agreement, by all means take away my commit privileges.

(a major reason for the ongoing libconsensus work is to separate "Bitcoin Core, 
the node software" and "The Bitcoin Consensus" along clear lines, to avoid this 
kind of nasty confusion)

Wladimir
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCgAGBQJVgqfOAAoJEHSBCwEjRsmmFT8H/Rkm29AhLhT8R1Vx8oKUIzID
+NB7tOps3lIilkDQIC5zHSknx5iugrrAdRf1w7qPj/o8+xhCZw9ruu8eIq+djkRQ
tvzbHil2pqgT3VHriRlY4lvlmu2NmBcYrAuX9sDhUHBo6cwGajfKMJPfE0haK3K4
7EmfdGXJYJmiBnhE6ikOiU687M2WgsmIGrBDIxeA5wYwVK9Ph8hfcbuj7AHvIMI9
ZNU/V6uhcTjn5wT+6DHGIOxHipYHyAwKb7jKho0XkM6Yi4ORe1mxF5HDtqA0ztta
mZPNjNrt/ngK20xRbqkb0GtxoyZq38ZF3Bq1gaWl2v9MBBMD5ZxQAvgCNUQFEo0=
=W26K
-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

[Mike Hearn]

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.
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[Bitcoin-development] Bitcoin core 0.11.0 release candidate 2 available

[Wladimir J. van der Laan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello,

I've just uploaded Bitcoin Core 0.11.0rc2 executables to:

https://bitcoin.org/bin/bitcoin-core-0.11.0/test/

The source code can be found in the source tarball or in git under the tag 
'v0.11.0rc2'

Preliminary release notes can be found here:

https://github.com/bitcoin/bitcoin/blob/0.11/doc/release-notes.md

Changes since rc1:
- - #6274 `4d9c7fe` Add option `-alerts` to opt out of alert system
- - #5985 `37b4e42` Fix removing of orphan transactions
- - #6221 `6cb70ca` Prune: Support noncontiguous block files
- - #6256 `fce474c` Use best header chain timestamps to detect partitioning
- - #6244 `0401aa2` configure: Detect (and reject) LibreSSL
- - #6269 `95aca44` gitian: Use the new bitcoin-detached-sigs git repo for OSX 
signatures
- - #6285 `ef1d506` Fix scheduler build with some boost versions.
- - #6280 `25c2216` depends: fix Boost 1.55 build on GCC 5
- - #6276 `c9fd907` Fix getbalance * 0
- - #6264 `94cd705` Remove translation for -help-debug options
- - #6286 `3902c15` Remove berkeley-db4 workaround in MacOSX build docs

Thanks to everyone that participated in development, translation or in the 
gitian build process,

Wladimir
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCgAGBQJVgoeFAAoJEHSBCwEjRsmmkggH/3jyzuPXDpUpCpfzyDZDW4CO
GRqIZwCa8vY9Gv9T0mX5jLXOfXpPAMyzWnCz2Eqh0hRLHK8WzObPqdX+3KLaaoO/
rOroDCG7AUZB4GaodSZURqJm8RmnNtWNckK7GBwXbZ7qNZrkpRNUh1z2JsatZdum
bUTBHX6Z9jW4HCmMZNn5lv5hRwu3XzFSi1uu9VyleVnIvdSbyjMhfjKn1VG0Rcnw
kTrCUgJccMP0htNGpIPni14PTak16ULs7KXMPNtpgB/lo/4LhDLGTivXL5ntjQXX
gQarGdh9eCqazHyIMSHTj4eO3GvLNUCHp3wM6YTiEhABkkWL3wRwn8yqMRf0EWE=
=GCM7
-END PGP SIGNATURE-

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

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

[odinn]

-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 (some) of the views presented in this video.

Let me be blunt, I have serious concerns regarding threats issued by a
developer in this video, and I think that it is entirely possible that
those of you who are core developers have already seen this and have
been discussing it.  But I am interested in seeing this resolved here
on this list openly and having it resolved.  It's sad and unfortunate
to me, but I feel that it's necessary to do this.  Identify what's
happening, address it squarely, have the person who is threatening
others explain his/her behavior, deal with the problem and move on.
This seems to be very important.  Please tell me if I am wrong about
this or totally flawed in my perspective here.  Go right ahead.

In this video, a particular developer makes the following statement,
stating in part:

"My preferred solution is that Gavin revokes commit access from
everyone else in the project, and then... makes the change himself"

Regardless of how you look at this, and even if we believe that Gavin
will not respond to that developer's request for a so-called
"solution," such a statement (by any developer) is indeed both a
threat and an act of sabotage against the larger bitcoin community.
We should certainly be thankful therefore, for the recent policy
change at bitcoin.org which can be seen here:
https://cloud.githubusercontent.com/assets/61096/8173297/578483f8-1399-1
1e5-8f48-96f33d12b996.png

I firmly believe that any developer who made a statement suggesting
that commit access of others in the project be revoked so that they
can proceed with their personal plan, needs to answer for having made
such a suggestion with a formal apology to this list, followed by an
explanation for why they themselves should not have their commit
access removed.

Overall, however, this sort of bombastic, nuclear suggestion makes me
seriously concerned for the future of bitcoin (as well as any
cryptocurrency which has repositories on Github).

So, you know who you are:  Apologize for your statement ("preferred
solution") and explain to the community why you should still have
commit access in light of the threat you have made to all the other
developers (and indeed to all participants of the bitcoin community).
 These "nuclear options" are unacceptable to us all.

Respectfully,

- -O


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

iQEcBAEBAgAGBQJVgoc3AAoJEGxwq/inSG8C6QYH/1Ag+4ESTSUPkP8PCTj1AJds
J4MmBz4cX7IYsSttTAjyiwd6oTHCU+wAcXtgZYpzr8rWF62bG5/+kAFUfjKwNsGM
WqcdNOR6h8fQulx8niuro8kZF/xOsG5eHtRK2FMCorxj0t6qn4pH5WAQL73J3hXQ
xI831Nt/L7VTa0jlKbr2/VGlqh6CtGrZ9mXp6aV1MBNwHbFryNBJW9ubvUv/IRxZ
GyJ+c3+Br2KKAQTMsyNn3VXMlXJL6kt0pwwk2od3j/+dKE4pAetHvZ5OgIO+qUWd
6R0/AaoW5jk343TaQ5BHaSpNW+OM9Yc1ycZyqE/YV8JwWeA6G/QdmRVYeoLMCZQ=
=zJeO
-END PGP SIGNATURE-

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

[Bitcoin-development] Scope narrowing for proposals to address block size limit debate, an inquiry

[odinn]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

The purpose of this post is to present an inquiry related to the
possible narrowing of scope of what sort of proposals are likely to
"bear fruit" at this stage.  The inquiry or question is, "Are there
some proposals that are more likely to succeed, in addressing the
whole block size limit debate meaningfully?"

The flip side of this inquiry, is that if you think that an attempt to
do such "scope narrowing" _at this time_ is foolhardy, inappropriate,
wrong, or otherwise flawed, please say so and explain.  I'm not
religious about this notion.  I throw out proposals below which I
think would be likely to advance further ~ and thus I ask the question
again, and rephrase, "Are there some proposals (some shown below as
examples, not all-inclusive) that are more likely to succeed, in
addressing the whole block size limit debate meaningfully?"

~ 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

And if I'm lucky, this thread may get comments from DumbFruit, who
writes stuff like this:
https://bitcointalk.org/index.php?topic=1085436.msg11643203#msg11643203

So now... your thoughts?


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

iQEcBAEBAgAGBQJVgnLuAAoJEGxwq/inSG8CchMH/0zm+A7Uqp8SpU+CsJr3lF2+
0re+5Ql4qVVmOI560918BtkdFjcq33jsKU9cYUDXqZ4wHfJTAGLGDqNgUZGpGkmJ
bqGgSvdF64P52Vb9PVnz1I9+aClas8Mjvl8XUYoD0yEA14XVBakYDRbVqZ5yPM8n
hBi6EpWLUnkFvvEj2dkgwddvPCvrnhVL/aRfmhet1pfOELfIrXtXI7hs2F1RyaqK
sbR/Qg3SFlyHzbxSzRVcZQ0G81exq/fxHqxc5kSLMiR7TODIJxCl6cJDCjf8LbeS
n6tL/I8vWN2zraYfb0cWu5uIjz5XnXpsitu951109zoS8IYle3uTfCF+6xdG3tY=
=HQ9R
-END PGP SIGNATURE-

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