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

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

[Adam Back]

Mike Hearn <mike@plan99.net> wrote:
> Which is why there will soon be a fork that does it.

I understand why you would be keen to scale bitcoin, everyone here is.

But as you seem to be saying that you will do a unilateral hard-fork,
and fork the code-base simultaneously, probably a number of people
have questions, so I'll start with some:

( I noticed some of your initial thoughts are online here
https://www.youtube.com/watch?v=DB9goUDBAR0 or the full podcast
https://epicenterbitcoin.com/podcast/082/ )

- Are you releasing a BIP for that proposal for review?

- If the reviewers all say NACK will you take on board their suggestions?

- On the idea of a non-consensus hard-fork at all, I think we can
assume you will get a row of NACKs.  Can you explain your rationale
for going ahead anyway?  The risks are well understood and enormous.

- How do you propose to deal with the extra risks that come from
non-consensus hard-forks?  Hard-forks themselves are quite risky, but
non-consensus ones are extremely dangerous for consensus.

- If you're going it alone as it were, are you proposing that you will
personally maintain bitcoin-XT?  Or do you have a plan to later hand
over maintenance to the bitcoin developers?

- Do you have contingency plans for what to do if the non-consensus
hard-fork goes wrong and $3B is lost as a result?


As you can probably tell I think a unilateral fork without wide-scale
consensus from the technical and business communities is a deeply
inadvisable.  While apparently some companies have expressed interest
in increased scale, I can only assume they do no yet understand the
risks.  I suggest before they would actually go ahead that they seek
independent advice.

Of the overall process, I think you can agree we should not be making
technical decisions with this level of complexity and consensus risk
with financial implications of this magnitude under duress of haste?
This seems otherwise a little like the moral hazard of the 2008
financial collapse that Satoshi put the quote in the genesis block
about.

I think its best that we progress as Jeff Garzik has done to have
engineering discussions centre around BIPs, running code for review,
simulation and careful analysis.

I understand this has been going on for a long time, and some people
are frustrated with the rate of progress, but making hasty,
contentious or unilateral actions in this space is courting disaster.

Please use your considerable skills to, along with the rest of the
community, work on this problem collaboratively.

I can sincerely assure you everyone does want to scale bitcoin and
shares your long term objective on that.

Adam

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

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 5913 bytes --]

Hi Adam,

Provisional answers below!

- Are you releasing a BIP for that proposal for review?
>

The work splits like this:

   - Gavin is writing the code and I think a BIP as well

   - I will review both and mostly delegate to Gavin's good taste around
   the details, unless there is some very strong disagreement. But that seems
   unlikely.

   - I have been handling gitian and the patch rebases, the code signing
   and so on, so far. I've also been doing some work to setup the basic
   infrastructure of the project (website etc).


- If the reviewers all say NACK will you take on board their suggestions?
>

Feedback will be read. There are no NACKS in Bitcoin XT. Patch requests
aren't scored in any way. The final decision rests with the maintainer as
in ~all open source projects.



> - On the idea of a non-consensus hard-fork at all, I think we can
> assume you will get a row of NACKs.  Can you explain your rationale
> for going ahead anyway?  The risks are well understood and enormous.
>

Yes, I have been working on an article that explains how we got to this
point from my perspective. It is quite long, but only because I want it to
be readable for people who weren't following the debate.

Anyway, I think I've laid out the gist of it over and over again, but to
summarise:

If Bitcoin runs out of capacity *it will break and many of our users will
leave*. That is not an acceptable outcome for myself or the many other
wallet, service and merchant developers who have worked for years to build
an ecosystem around this protocol.



> - How do you propose to deal with the extra risks that come from
> non-consensus hard-forks?  Hard-forks themselves are quite risky, but
> non-consensus ones are extremely dangerous for consensus.
>

The approach is the same for other forks. Voting via block versions and
then when there's been >X% for Y time units the 1mb limit is
lifted/replaced.




> - If you're going it alone as it were, are you proposing that you will
> personally maintain bitcoin-XT?  Or do you have a plan to later hand
> over maintenance to the bitcoin developers?
>

Good question!  I have various thoughts on this, but let's wait and see
what happens first. Perhaps the new chain won't get the majority on it.

In the event that the >1mb chain does eventually win, I would expect Core
to apply the patch and rejoin the consensus rather than lose all its users.
That would take XT back to being a fairly small patchset to improve the
network protocol.



- Do you have contingency plans for what to do if the non-consensus
> hard-fork goes wrong and $3B is lost as a result?
>

Where did you get the $3B figure from? The fork either doesn't happen, or
it happens after quite a long period of people knowing it's going to happen
- for example because their full node is printing "You need to upgrade"
messages due to seeing the larger block version, or because they read the
news, or because they heard about it via some other mechanisms.

Let me flip the question around. Do you have a contingency plan if Bitcoin
runs out of capacity and significant user disruption occurs that results in
exodus, followed by fall in BTC price? The only one I've seen is "we can
perform an emergency hard fork in a few weeks"!



> As you can probably tell I think a unilateral fork without wide-scale
> consensus from the technical and business communities is a deeply
> inadvisable.


Gavin and I have been polling many key players in the ecosystem. The
consensus you seek does exist. All wallet developers (except Lawrence), all
the major exchanges, all the major payment processors and many of the major
mining pools want to see the limit lifted (I haven't been talking to pools,
Gavin has).

This notion that the change has no consensus is based on you polling the
people directly around you and people who like to spend all day on this
mailing list. It's not an accurate reflection of the wider Bitcoin
community and that is one of the leading reasons there is going to be a
fork. A small number of people have been flatly ignoring LOTS of highly
technical and passionate developers who have written vast amounts of code,
built up the Bitcoin user base, designed hardware and software, and yes
built companies.

How do you think that makes Bitcoin Core look to the rest of the Bitcoin
world? How much confidence does that give people?



Of the overall process, I think you can agree we should not be making
> technical decisions with this level of complexity and consensus risk
> with financial implications of this magnitude under duress of haste?
>

This debate will never end until a fork makes it irrelevant. There is no
process for ending it, despite me begging Wladimir to make one.

And there is no haste. We have been debating the block size limit for
*years*. We have known it must be lifted for *years*. I kicked off this
current round of debates after realising that Wladimir's release timeline
wouldn't allow a block size limit to be released before the end of the
year. The reason we're talking about it now and not next year is exactly to
ensure there is plenty of time.




> I can sincerely assure you everyone does want to scale bitcoin and
> shares your long term objective on that


I really wish you were right, and I definitely feel you are one of the more
reasonable ones Adam. But the overwhelming impression I get from a few
others here is that no, they don't want to scale Bitcoin. They already
decided it's a technological dead end. They want to kick end users out in
order to "incentivise" (force) the creation of some other alternative,
claiming that it's still Bitcoin whilst ignoring basic details ... like the
fact that no existing wallets or services would work.

Scaling Bitcoin can only be achieved by letting it grow, and letting people
tackle each bottleneck as it arises at the right times. Not by convincing
ourselves that success is failure.

[-- Attachment #2: Type: text/html, Size: 8718 bytes --]

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

[Adam Back]

Hi Mike

Well thank you for replying openly on this topic, its helpful.

I apologise in advance if this gets quite to the point and at times
blunt, but transparency is important, and we owe it to the users who
see Bitcoin as the start of a new future and the$3b of invested funds
and $600m of VC funds invested in companies, we owe it to them that we
be open and transparent here.

I would really prefer on a personal nor professional basis to be
having this conversation period, never mind in public, but Mike - your
and Gavin's decision to promote a unilateral hard-fork and code fork
are extremely high risk for bitcoin and so there remains little
choice.  So I apologise again that we have to have this kind of
conversation on a technical discussion list.  This whole thing is
hugely stressful and worrying for developers, companies and investors.

I strongly urge that we return to the existing collaborative
constructive review process that has been used for the last 4 years
which is a consensus by design to prevent one rogue person from
inserting a backdoor, or lobbying for a favoured change on behalf of a
special interest group, or working for bad actor (without accusing you
of any of those - I understand you personally just want to scale
bitcoin, but are inclined to knock heads and try to force an issue you
see, rather than work collaboratively).

For you (and everyone)

- Should there be a summit of some kind, that is open attendance, and
video recorded so that people who are unable to attend can participate
too, so that people can present the technical proposals and risks in
an unbiased way?

(It is not theoretical question, I may have a sponsor and host - not
Blockstream, an independent, its a question for everyone, developers,
users, CTOs, CEOs.)



So here I come back to more frank questions:

Governance

The rest of the developers are wise to realise that they do not want
exclusive control, to avoid governance centralising into the hands of
one person, and this is why they have shared it with a consensus
process over the last 4 years.  No offence but I dont think you
personally are thinking far enough ahead to think you want personal
control of this industry.  Maybe some factions dont trust your
motives, or they dont mind, but feel more assured if a dozen other
people are closely reviewing and have collective review authority.

- Do you understand that attempting to break this process by
unilateral hard-fork is extremely weakening of Bitcoin's change
governance model?

- Do you understand that change governance is important, and that it
is important that there be multiple reviewers and sign-off to avoid
someone being blackmailed or influenced by an external party - which
could potentially result in massive theft of funds if something were
missed?

- Secondarily do you understand that even if you succeed in a
unilateral fork (and the level of lost coins and market cap and damage
to confidence is recoverable), that it sets a precedent that others
may try to follow in the future to introduce coercive features that
break the assurances of bitcoin, like fungibility reducing features
say (topically I hear you once proposed on a private forum the concept
of red-lists, other such proposals have been made and quickly
abandoned), or ultimately if there is a political process to obtain
unpopular changes by unilateral threat, the sky is the limit - rewrite
the social contract at that point without consensus, but by
calculation that people will value Bitcoin enough that they will
follow a lead to avoid risk to the system?


Security

As you probably know some extremely subtle bugs in Bitcoin have at
times slipped past even the most rigorous testings, often with
innocuous but unexpected behaviours, but some security issues  Some
extremely intricate and time-sensitive security defect and incident
response happens from time to time which is not necessarily publicly
disclosed until after the issue has been rolled out and fixed, which
can take some time due to the nature of protocol upgrades,
work-arounds, software upgrade via contacting key miners etc.  We
could take an example of the openSSL bug.

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

- Are you a member of the bitcoin security reporting list?

On 15 June 2015 at 11:56, Mike Hearn <mike@plan99.net> wrote:
> I will review both and mostly delegate to Gavin's good taste around the
> details, unless there is some very strong disagreement. But that seems
> unlikely.
> ...
> Feedback will be read. There are no NACKS in Bitcoin XT. Patch requests
> aren't scored in any way. The final decision rests with the maintainer as in
> ~all open source projects.

As you know the people who have written 95% of the code (and reviewed,
and tested, and formally proved segments etc) are strenuously advising
not to push any consensus code into public use without listening to
and addressing review questions which span beyond rigorous code &
automated guided fuzz testers, simulation and sometimes formal proofs,
but also economics, game-theory and critically very subtle
determinism/consensus safety that they have collectively 4-5 years
experience of each.

- Will you pause your release plans if all of the other developers
insist that the code or algorithm is defective?

- Please don't take this the wrong way, and I know your bitcoinj work
was a significant engineering project which required porting bitcoin
logic.  But If the answer to the above question is no, as you seemed
to indicate in your response, as you not have not written much bitcoin
core code yourself (I think 3 PRs in total), do you find yourself more
qualified than the combination of peer review of the group of people
who have written 95% of it, and maintained it and refactored most of
it over the last 4-5 years?

I presume from your security background you are quite familiar with
the need for review of crypto protocol changes & rigorous code review.
That is even more the case with Bitcoin given the consensus
criticality.

>> - On the idea of a non-consensus hard-fork at all, I think we can
>> assume you will get a row of NACKs.  Can you explain your rationale
>> for going ahead anyway?  The risks are well understood and enormous.
>
> If Bitcoin runs out of capacity it will break and many of our users will
> leave. That is not an acceptable outcome for myself or the many other
> wallet, service and merchant developers who have worked for years to build
> an ecosystem around this protocol.

That you are frustrated, is not a sufficient answer as to why you are
proposing to go ahead with a universally acknowledged extreme network
divergence danger unilateral hard-fork, lacking wide-spread consensus.
People are quite concerned about this.  Patience, caution and prudence
is necessary in a software system with such high assurance
requirements.

So I ask again:

- On the idea of a non-consensus hard-fork at all, I think we can
assume you will get a row of NACKs.  Can you explain your rationale
for going ahead anyway?  The risks are well understood and enormous.

Note the key point is that you are working on a unilateral hard-fork,
where there is a clear 4 year established process for proposing
improvements and an extremely well thought out and important change
management governance process.  While there has been much discussion,
you nor Gavin, have not actually posted a BIP for review.  Nor
actually was much of the discussion even conducted in the open: it was
only when Matt felt the need to clear the air and steer this
conversation into the open that discussion arose here.  During that
period of private discussion you and Gavin were largely unknown to
most of us lobbying companies with your representation of a method
that concerns everyone of the Bitcoin users.  Now that the technical
community aware aware they are strenuously discouraging you on the
basis of risks.


Openness

- Do you agree that bitcoin technical discussions should happen in the open?

- As this is a FOSS project, do you agree that companies should also
be open, about their requirements and trade-offs they would prefer?

- Can you disclose the list of companies you have lobbied in private
whether they have spoken publicly or not, and whether they have
indicated approval or not?

- Did you share a specific plan, like a BIP or white paper with these
companies, and if so can we see it?

- If you didnt submit a plan, could you summarise what you asked them
and what you proposed, and if you discussed also the risks?  (If you
asked them if they would like Bitcoin to scale, I expect almost
everyone does, including every member of the technical community, so
that for example would not fairly indicate approval for a unilateral
hard-fork)

I and others will be happy to talk with the CTO and CEOs of companies
you have lobbied in private, for balance to assure ourselves and the
rest of the community that their support was given - and with full
understanding of the risks of doing it unilaterally, without peer
review, benefit of maintenance and security inidence management, and
what exactly they are being quoting as having signed up for.

(This maybe more efficiently and openly achieved by the open process,
on a mailing list, maybe a different one even special purpose to this
topic, with additional option of the open public meeting I proposed at
the top).

- Do you agree that it would be appropriate, that companies be aware
of both the scaling opportunities (of course, great everyone wants
scalability) as well as the technical limits and risks with various
approaches?  And that these be presented by parties from a range of
views to ensure balance?

- Do you consider your expression of issues to hold true to the ideal
of representing balanced nuanced view of all sides of a technical
debate, even when under pressure or feeling impatient about the
process?

You may want to review the opening few minutes of your epicenter 82
bitcoin for example where you claimed and I quote "[the rest of the
technical community] dont want capacity to ever increase and want it
to stay where it is and when it fills up people move to other
systems".

- Do you think that is an accurate depiction of the complex trade-offs
we have been discussing on this list?

(For the record I am not aware of a single person who has said they do
not agree with scaling Bitcoin.  Changing a constant is not the
hard-part.  The hard part is validating a plan and the other factors
that go into it.  It's not a free choice it is a security/scalability
tradeoff.  No one will thank us if we "scale" bitcoin but break it in
hard to recover ways at the same time.)

- Were you similarly balanced in your explanations when talking to
companies in private discussions?

- Do you understand that if we do not work from balanced technical
discussion, that we may end up with some biased criteria?

Authority

Neither you nor Gavin have any particular authority here to speak on
behalf of Bitcoin (eg you acknowledge in your podcast that Wladimir is
dev lead, and you and Gavin are both well aware of the 4 year
established change management consensus decision making model where
all of the technical reviewers have to come to agreement before
changes go in for security reasons explained above).  I know Gavin has
a "Chief Scientist" title from the Bitcoin Foundation, but sadly that
organisation is not held in as much regard as it once was, due to
various irregularities and controversies, and as I understand it no
longer employs any developers, due to lack of funds.  Gavin is now
employed by MIT's DCI project as a researcher in some capacity.  As
you know Wladimir is doing the development lead role now, and it seems
part of your personal frustration you said was because he did not
agree with your views.  Neither you nor Gavin have been particularly
involved in bitcoin lately, even Gavin, for 1.5 years or so.

- Do you agree that if you presume to speak where you do not have
authority you may confuse companies?

> If Bitcoin runs out of capacity it will break and many of our users will
> leave. That is not an acceptable outcome for myself or the many other
> wallet, service and merchant developers who have worked for years to build
> an ecosystem around this protocol.

But I think this is a false dichotomy.  As I said in previous mail I
understand people are frustrated that it has taken so long, but it is
not the case that no progress has been made on scalability.

I itemised a long list of scalability work which you acknowledged as
impressive work (CPU, memory, network bandwidth/latency) and RBF, CPFP
fee work, fee-estimation, and so on, which you acknowledged and are
aware of.

There are multiple proposals and BIPs under consideration on the list right now.

- what is the reason that you (or Gavin) would not post your BIP along
side the others to see if it would win based on technical merit?

- why would you feel uniquely qualified to override the expert opinion
of the rest of the technical community if your proposal were not
considered to have most technical merit? (Given that this is not a
simple market competition thing where multiple hard-forks can be
considered - it is a one only decision, and if it is done in a
divisive unilateral way there are extreme risks of the ledger
diverging.)

Network Divergence Risk

>> - How do you propose to deal with the extra risks that come from
>> non-consensus hard-forks?  Hard-forks themselves are quite risky, but
>> non-consensus ones are extremely dangerous for consensus.
>
> The approach is the same for other forks. Voting via block versions and then
> when there's been >X% for Y time units the 1mb limit is lifted/replaced.

But this is not a soft-fork, it is a hard-fork.  Miner voting is only
peripherally related.  Even if in the extremis 75% of miners tried a
unilateral hard-fork but 100% of the users stayed on the maintained
original code, no change would occur other than those miners losing
reward (mining fork-coins with no resale value) and the difficulty
would adjust.  The miners who made an error in choice would lose money
and go out of business or rejoin the chain.

However if something in that direction happens with actual users and
companies on both sides of it users will lose money, the ledger will
diverge as soon as a single double-spend happens, and never share a
block again, companies will go instantly insolvent, and chaos will
break out.  This is the dangerous scenario we are concerned about.

So the same question again:

- How do you propose to deal with the extra risks that come from
non-consensus hard-forks?  Hard-forks themselves are quite risky, but
non-consensus ones are extremely dangerous for consensus.


Being sensitive to alarming the market

It is something akin to Greece or Portugal or Italy exiting the euro
currency in a disorderly way.  Economists and central bank policy
makers are extremely worried about such an eventuality and talk about
related factors in careful, measured terms, watch Mario Draghi when he
speaks.

Imagine that bitcoin is 10x or 100x bigger.  Bitcoin cant have people
taking unilateral actions such as you have been proposing.  It is not
following the consensus governance process, and not good policy and it
is probably affecting bitcoin confidence and price at this moment.

>> - Do you have contingency plans for what to do if the non-consensus
>> hard-fork goes wrong and $3B is lost as a result?
>
> Where did you get the $3B figure from? The fork either doesn't happen, or it
> happens after quite a long period of people knowing it's going to happen -
> for example because their full node is printing "You need to upgrade"
> messages due to seeing the larger block version, or because they read the
> news, or because they heard about it via some other mechanisms.

This is not a soft-fork, and the community will not want to take the
risks once they understand them, and they have months in which to
understand them and at this point you've motivated and wasted 100s of
developer man hours such that we will feel impelled to make sure that
no one opts into a unilateral hard-fork without understanding the
risks.  It would be negligent to allow people to do that.  Before this
gets very far FAQs will be on bitcoin.org etc explaining this risk I
would imagine.  Its just starting not finished.

What makes you think the rest of the community may not instead prefer
Jeff Garzik's BIP after revisions that he is making now with review
comments from others?

Or another proposal.  Taken together with a deployment plan that sees
work on decentralisation tying into that plan.

- If you persisted anyway, what makes you think bitcoin could not make
code changes defensively relating to your unilateral fork?
(I am sure creative minds can find some ways to harden bitcoin against
a unilateral fork, with a soft-fork or non-consensus update can be
deployed much faster than a hard-fork).

I tried to warn Gavin privately that I thought he was under-estimating
the risk of failure to his fork proposal due to it being unilateral.
Ie as you both seem sincere in your wish to have your proposal
succeed, then obviously the best way to do that is to release a BIP in
the open collaborative process and submit it to review like everyone
else.  Doing it unilaterally only increases its chance of failure.

The only sensible thing to do here is submit a BIP and stop the
unilateral fork threat.

Scalability Plans

> Let me flip the question around. Do you have a contingency plan if Bitcoin
> runs out of capacity and significant user disruption occurs that results in
> exodus, followed by fall in BTC price? The only one I've seen is "we can
> perform an emergency hard fork in a few weeks"!

Yes people have proposed other plans.  Bryan Bishop posted a list of them.

Jeff Garzik has a proposal, BIP-100 which seems already better than
Gavin's having benefit of peer review which he has been incorporating.

I proposed several soft-fork models which can be deployed safely and
immediately, which do not have ledger risk.

I have another proposal relating to simplified soft-fork one-way pegs
which I'll write up in a bit.

I think there are still issues in Jeff's proposal but he is very open
and collaborating and there maybe related but different proposals
presently.

>> As you can probably tell I think a unilateral fork without wide-scale
>> consensus from the technical and business communities is a deeply
>> inadvisable.
>
> Gavin and I have been polling many key players in the ecosystem. The
> consensus you seek does exist. All wallet developers (except Lawrence), all
> the major exchanges, all the major payment processors and many of the major
> mining pools want to see the limit lifted (I haven't been talking to pools,
> Gavin has).

It does not seem to me that you understand the issue.  Of course they
want to increase the scalability of bitcoin.  So does everyone else on
this mailing list.

That they would support that is obvious.  If you presented your
unilateral action plan without explaining the risks too.

I think I covered this further above.  If you would like to share the
company list, or we can invite them to the proposed public physical
meeting, I think it would be useful for them to have a balanced view
of the ledger divergence risks, and alternative in-consensus proposals
underway, as well as the governance risks, maintenance risks, security
incident risks.

Note that other people talk to companies too, as part of their day to
day jobs, or from contacts from being in the industry.  You have no
special authority or unique ability to talk with business people.  Its
just that the technical community did not know you were busy doing
that.

I can not believe that any company that would listen to their CTO, CSO
or failing that board would be ok with the risks implied by what you
are proposing on full examination.

> This notion that the change has no consensus is based on you polling the
> people directly around you and people who like to spend all day on this
> mailing list. It's not an accurate reflection of the wider Bitcoin community
> and that is one of the leading reasons there is going to be a fork. A small
> number of people have been flatly ignoring LOTS of highly technical and
> passionate developers who have written vast amounts of code, built up the
> Bitcoin user base, designed hardware and software, and yes built companies.

I know you want scale bitcoin, as I said everyone here does. I think
what you're experiencing is that you've had more luck explaining your
pragmatic unilateral plan to non-technical people without peer review,
and so not experienced the kind of huge pushback you are getting from
the technical community.  The whole of bitcoin is immensely
complicated such that it takes an uber-geek CS genius years to
catchup, this is not a slight of any of the business people who are
working hard to deploy Bitcoin into the world, its just complicated
and therefore not easy to understand the game-theory, security,
governance and distributed system thinking.  I have a comp sci PhD in
distributed systems, implemented p2p network systems and have 2
decades of applied crypto experience with a major interest in
electronic cash crypto protocols, and it took me a several years to
catchup and even I have a few hazy spots on low-level details, and I
addictively into read everything I could find.  Realistically all of
us are still learning, as bitcoin combines so many fields that it
opens new possibilities.

What I am expecting that yourself and Gavin are thinking is that
you'll knock heads and force the issue and get to consensus.

However I think you have seriously misjudged the risks and have not
adequately explained them to companies you are talking with.  Indeed
you do not fully seem to acknowledge the risks, nor to have a well
thought out plan here of how you would actually manage it, nor the
moral hazards of having a lone developer in hugely divisive
circumstances in sole control of bitcoins running code.  Those are
exactly the reasons for the code change governance process!

Even though you are trying to help, the full result is you are not
helping achieve anything by changing a constant and starting a
unilateral hard-fork (not to trivialise the work of making a patch to
do that).

The work to even make the constant change be feasible was a result of
1000s of hours of work by others in the development community, that is
emphatically and unilaterally telling you that hard-forks are hugely
inadvisable.

You are trying to break the code change governance security procedure
that were put in place for good reason for the security of $3b of
other peoples money, even if you have a pragmatic intent to help, this
is flat out unacceptable.

There are also security implications to what you are proposing, which
I have heard you attempting to trivialise, that are core to Bitcoins
security and core functionality.

>  the overwhelming impression I get from a few
> others here is that no, they don't want to scale Bitcoin. They already
> decided it's a technological dead end.

I think this is a significant mischaracterisation, and I think almost
everybody is on board with a combination plan:

1. work to improve decentralisation (specific technical work already
underway, and education)
2. create a plan to increase block-size in a slow fashion to not cause
system shocks (eg like Jeff is proposing or some better variant)
3. work on actual algorithmic scaling

In this way we can have throughput needed for scalability and security
work to continue.

As I said you can not scale a O(n^2) broadcast network by changing
constants, you need algorithmic improvements.

People are working on them already.  All of those 3 things are being
actively worked on RIGHT NOW, and in the case of algorithmic scaling
and improve decentralisation have been worked on for months.

You may have done one useful thing which is to remind people that
blocks are only 3x-4x below capacity such that we should look at it.

But we can not work under duress of haste, nor unilateral ultimatums,
this is the realm of human action that leads to moral hazard, and
ironically reminds us of why Satoshi put the quote in the genesis
block.

Bitcoin is too complex a system with too much at stake to be making
political hasty decisions, it would be negligent to act in such a way.

Again please consider that you did your job, caused people to pay
attention, but return to the process, submit a BIP, retract the
unilateral hard-fork which is so dangerous and lets have things be
calm, civil and collaborative in the technical zone of Bitcoin and not
further alarm companies and investors.

Adam

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

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1413 bytes --]

Hi Adam,

I replied publicly because your questions were sent to the mailing list.
I'd have been happy to reply in private if so asked.

I started to write up a much longer reply, but I'm tired - we've long since
been going in circles. I feel like I've written down answers to almost all
your questions before, including some in the email above.

Still, there are a few new ones. Let me work through them now.


Yes, I am on the bitcoin-security list. I have always been on it. I have
taken part in many threads there and started one or two myself. I guess
you're not though, otherwise you'd know that. You can ask, I'm sure Gavin
will add you if you like.


Re: BIP. Gavin is working on a BIP to go along with his patch. I hope that
will satisfy. I do not expect the resulting discussion to differ much from
the discussion so far, though.


Re: summit. No, I would not attend. I have been to several Bitcoin
conferences over the years where the block size issue was discussed. No
progress was ever made at these events.



Re: if some flaw or bug was found in the patch. Yes, of course if there was
some specific problem with the code then we would fix it. There will be
time to review Gavin's patches for these reasons.



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.

[-- Attachment #2: Type: text/html, Size: 1867 bytes --]

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

[Bryan Bishop]

[-- Attachment #1: Type: text/plain, Size: 1234 bytes --]

On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn <mike@plan99.net> 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 requests to Bitcoin Core, so therefore Mike is a
non-programmer". Communication is difficult and I can understand that, but
we really have to be more careful when evaluating each other's messages;
technical miscommunication can be catastrophic in this context. On the
topic of whether you are a programmer, I suspect that ever since you built
CIA.vc we have all known you're a programmer, Mike.

- Bryan
http://heybryan.org/
1 512 203 0507

[-- Attachment #2: Type: text/html, Size: 1794 bytes --]

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

[Faiz Khan]

[-- Attachment #1: Type: text/plain, Size: 2852 bytes --]

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 <kanzure@gmail.com> wrote:

> On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn <mike@plan99.net> 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 requests to Bitcoin Core, so therefore Mike is a
> non-programmer". Communication is difficult and I can understand that, but
> we really have to be more careful when evaluating each other's messages;
> technical miscommunication can be catastrophic in this context. On the
> topic of whether you are a programmer, I suspect that ever since you built
> CIA.vc we have all known you're a programmer, Mike.
>
> - 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
>
> --
>
> My regards,
>
> Faiz Khan
>
>  <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>

[-- Attachment #2: Type: text/html, Size: 4285 bytes --]

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

[odinn]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mike,

To sum it up, you are saying "bitcoin will break and many of our users
will leave therefore OMG WTF so we have to do what GAVIN AND ME want
to do to hardfork to XT which is the ONLY WAY, so GTFO!"

And so, no.  We don't have to accept that attitude.

There are other proposals that actually would work here.

Cameron Garnham's dynamic block size adjustment (needing soft fork
only) mentioned here http://www.twitlonger.com/show/n_1smkanp

Jeff Garzik's proposals (rewritten and published as a BIP)
http://bitcoin-development.narkive.com/f5FMeA4D/comments-on-bip-100

and more.

I also disagree with the notion that everybody's just ok with what
Mike and Gavin are doing.... specifically, this statement by Mike

> The consensus you seek does exist. All wallet developers (except 
> Lawrence), all the major exchanges, all the major payment
> processors and many of the major mining pools want to see the limit
> lifted

was kind of twisting things, because it made it sound like everybody
supports Gavin's proposal to hard fork to XT, which these folks don't.

Example:

1)
http://cointelegraph.com/news/114481/chinese-exchanges-reject-gavin-andr
esens-20-mb-block-size-increase

2) https://twitter.com/GreenAddress/status/605037073725313024

This isn't to say they don't want to see a limit adjusted but not in
the way that Gavin (and you, Mike) are proposing - not through this
hard fork to XT.

So go roll out your code for whatever it is you are going to put into
XT and make a BIP, but stop saying that everyone supports it when
obviously they don't and you don't even have something yet and there
are already superior alternatives that don't involve Gavin's hard fork
and your blessed XT.


On 06/15/2015 02:56 AM, Mike Hearn wrote:
> Hi Adam,
> 
> Provisional answers below!
> 
> - Are you releasing a BIP for that proposal for review?
> 
> 
> The work splits like this:
> 
> * Gavin is writing the code and I think a BIP as well
> 
> * I will review both and mostly delegate to Gavin's good taste
> around the details, unless there is some very strong disagreement.
> But that seems unlikely.
> 
> * I have been handling gitian and the patch rebases, the code
> signing and so on, so far. I've also been doing some work to setup
> the basic infrastructure of the project (website etc).
> 
> 
> - If the reviewers all say NACK will you take on board their 
> suggestions?
> 
> 
> Feedback will be read. There are no NACKS in Bitcoin XT. Patch
> requests aren't scored in any way. The final decision rests with
> the maintainer as in ~all open source projects.
> 
> 
> 
> - On the idea of a non-consensus hard-fork at all, I think we can 
> assume you will get a row of NACKs.  Can you explain your
> rationale for going ahead anyway?  The risks are well understood
> and enormous.
> 
> 
> Yes, I have been working on an article that explains how we got to
> this point from my perspective. It is quite long, but only because
> I want it to be readable for people who weren't following the
> debate.
> 
> Anyway, I think I've laid out the gist of it over and over again,
> but to summarise:
> 
> If Bitcoin runs out of capacity *it will break and many of our
> users will leave*. That is not an acceptable outcome for myself or
> the many other wallet, service and merchant developers who have
> worked for years to build an ecosystem around this protocol.
> 
> 
> 
> - How do you propose to deal with the extra risks that come from 
> non-consensus hard-forks?  Hard-forks themselves are quite risky,
> but non-consensus ones are extremely dangerous for consensus.
> 
> 
> The approach is the same for other forks. Voting via block versions
> and then when there's been >X% for Y time units the 1mb limit is 
> lifted/replaced.
> 
> 
> 
> 
> - If you're going it alone as it were, are you proposing that you
> will personally maintain bitcoin-XT?  Or do you have a plan to
> later hand over maintenance to the bitcoin developers?
> 
> 
> Good question!  I have various thoughts on this, but let's wait and
> see what happens first. Perhaps the new chain won't get the
> majority on it.
> 
> In the event that the >1mb chain does eventually win, I would
> expect Core to apply the patch and rejoin the consensus rather than
> lose all its users. That would take XT back to being a fairly small
> patchset to improve the network protocol.
> 
> 
> 
> - Do you have contingency plans for what to do if the
> non-consensus hard-fork goes wrong and $3B is lost as a result?
> 
> 
> Where did you get the $3B figure from? The fork either doesn't
> happen, or it happens after quite a long period of people knowing
> it's going to happen - for example because their full node is
> printing "You need to upgrade" messages due to seeing the larger
> block version, or because they read the news, or because they heard
> about it via some other mechanisms.
> 
> Let me flip the question around. Do you have a contingency plan if 
> Bitcoin runs out of capacity and significant user disruption occurs
> that results in exodus, followed by fall in BTC price? The only one
> I've seen is "we can perform an emergency hard fork in a few
> weeks"!
> 
> 
> 
> As you can probably tell I think a unilateral fork without
> wide-scale consensus from the technical and business communities is
> a deeply inadvisable.
> 
> 
> Gavin and I have been polling many key players in the ecosystem.
> The consensus you seek does exist. All wallet developers (except
> Lawrence), all the major exchanges, all the major payment
> processors and many of the major mining pools want to see the limit
> lifted (I haven't been talking to pools, Gavin has).
> 
> This notion that the change has no consensus is based on you
> polling the people directly around you and people who like to spend
> all day on this mailing list. It's not an accurate reflection of
> the wider Bitcoin community and that is one of the leading reasons
> there is going to be a fork. A small number of people have been
> flatly ignoring LOTS of highly technical and passionate developers
> who have written vast amounts of code, built up the Bitcoin user
> base, designed hardware and software, and yes built companies.
> 
> How do you think that makes Bitcoin Core look to the rest of the
> Bitcoin world? How much confidence does that give people?
> 
> 
> 
> Of the overall process, I think you can agree we should not be
> making technical decisions with this level of complexity and
> consensus risk with financial implications of this magnitude under
> duress of haste?
> 
> 
> This debate will never end until a fork makes it irrelevant. There
> is no process for ending it, despite me begging Wladimir to make
> one.
> 
> And there is no haste. We have been debating the block size limit
> for _years_. We have known it must be lifted for _years_. I kicked
> off this current round of debates after realising that Wladimir's
> release timeline wouldn't allow a block size limit to be released
> before the end of the year. The reason we're talking about it now
> and not next year is exactly to ensure there is plenty of time.
> 
> 
> 
> 
> I can sincerely assure you everyone does want to scale bitcoin and 
> shares your long term objective on that
> 
> 
> I really wish you were right, and I definitely feel you are one of
> the more reasonable ones Adam. But the overwhelming impression I
> get from a few others here is that no, they don't want to scale
> Bitcoin. They already decided it's a technological dead end. They
> want to kick end users out in order to "incentivise" (force) the
> creation of some other alternative, claiming that it's still
> Bitcoin whilst ignoring basic details ... like the fact that no
> existing wallets or services would work.
> 
> Scaling Bitcoin can only be achieved by letting it grow, and
> letting people tackle each bottleneck as it arises at the right
> times. Not by convincing ourselves that success is failure.
> 
> 
> 
> ----------------------------------------------------------------------
- --------
>
> 
> 
> 
> _______________________________________________ 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

iQEcBAEBAgAGBQJVf1e3AAoJEGxwq/inSG8C7NwIAIah+HzWKB+aydCgarJB1Tuv
4wK6ffaWP3pzT/D1jNPMoMwL6bp+hi/ixyrV2y9a841Oc/9vgf75ws1l8QH2YtEE
TM5cLnRtScXnbaHKAAQZyewURbmGKTUxhNLMIRlVMMq2uHwbUEqRrDaaBGhwC1HO
+v3u5zK13H1UMKBuUY7yANWvOamjs17FmwZ6MURYdX8qBFVqMoTorhPHTebDGusS
NxDm4uqphW7ylXISOm53v7i3/CPjW63YGB2fyk9J+BqxhOM7yAJSH0Ln/xtu/COa
uXudO+SbMco+x+cKrFLf/5ItxR65aOnWvWPKw0o55f96uSabngs/QozDhaU2BJk=
=gof9
-----END PGP SIGNATURE-----

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

[Brian Hoffman]

[-- Attachment #1: Type: text/plain, Size: 3291 bytes --]

Who is actually planning to move to Bitcoin-XT if this happens? 

Just Gavin and Mike?



> On Jun 15, 2015, at 6:17 PM, Faiz Khan <faizkhan00@gmail.com> 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 <kanzure@gmail.com> wrote:
>>> On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn <mike@plan99.net> 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 requests to Bitcoin Core, so therefore Mike is a non-programmer". Communication is difficult and I can understand that, but we really have to be more careful when evaluating each other's messages; technical miscommunication can be catastrophic in this context. On the topic of whether you are a programmer, I suspect that ever since you built CIA.vc we have all known you're a programmer, Mike.
>> 
>> - 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
>> 
>> -- 
>> 
>> My regards,
>> 
>> Faiz Khan
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

[-- Attachment #2.1: Type: text/html, Size: 5400 bytes --]

[-- Attachment #2.2: image1.JPG --]
[-- Type: image/jpeg, Size: 22107 bytes --]

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

[Raystonn .]

[-- Attachment #1.1: Type: text/plain, Size: 3944 bytes --]

http://xtnodes.com/
From: Brian Hoffman 
Sent: Monday, June 15, 2015 3:56 PM
To: Faiz Khan 
Cc: Bitcoin Dev 
Subject: Re: [Bitcoin-development] questions about bitcoin-XT code fork &non-consensus hard-fork

Who is actually planning to move to Bitcoin-XT if this happens? 

Just Gavin and Mike?




On Jun 15, 2015, at 6:17 PM, Faiz Khan <faizkhan00@gmail.com> 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 <kanzure@gmail.com> wrote:

    On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn <mike@plan99.net> 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 requests to Bitcoin Core, so therefore Mike is a non-programmer". Communication is difficult and I can understand that, but we really have to be more careful when evaluating each other's messages; technical miscommunication can be catastrophic in this context. On the topic of whether you are a programmer, I suspect that ever since you built CIA.vc we have all known you're a programmer, Mike.


    - 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


    -- 


    My regards,

    Faiz Khan


  ------------------------------------------------------------------------------

  _______________________________________________
  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

[-- Attachment #1.2: Type: text/html, Size: 7344 bytes --]

[-- Attachment #2: image1.JPG --]
[-- Type: image/jpeg, Size: 22107 bytes --]

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

[Aaron Voisine]

[-- Attachment #1.1: Type: text/plain, Size: 4743 bytes --]

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 <brianchoffman@gmail.com>
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 <faizkhan00@gmail.com> 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 <kanzure@gmail.com> wrote:
>
>> On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn <mike@plan99.net> 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 requests to Bitcoin Core, so therefore Mike is a
>> non-programmer". Communication is difficult and I can understand that, but
>> we really have to be more careful when evaluating each other's messages;
>> technical miscommunication can be catastrophic in this context. On the
>> topic of whether you are a programmer, I suspect that ever since you built
>> CIA.vc we have all known you're a programmer, Mike.
>>
>> - 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
>>
>> --
>>
>> My regards,
>>
>> Faiz Khan
>>
>>  <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #1.2: Type: text/html, Size: 7432 bytes --]

[-- Attachment #2: image1.JPG --]
[-- Type: image/jpeg, Size: 22107 bytes --]

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

[Mark Friedenbach]

[-- Attachment #1: Type: text/plain, Size: 1085 bytes --]

On Mon, Jun 15, 2015 at 5:08 PM, Aaron Voisine <voisine@gmail.com> 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.
>

We are not reaching consensus about any proposal, Garzik's or otherwise.

[-- Attachment #2: Type: text/html, Size: 1417 bytes --]

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

[Alex Morcos]

[-- Attachment #1.1: Type: text/plain, Size: 6888 bytes --]

Aaron,

My understanding is that Gavin and Mike are proceeding with the XT fork, I
hope that understanding is wrong.

As for improving the non-consensus code to handle full blocks more
gracefully.  This is something I'm very interested in, block size increase
or not. Perhaps I shouldn't hijack this thread, but maybe there are others
who also believe this would ameliorate some of the time pressure for
deciding on a block size increase.

What is it that you would like to see improved?
The fee estimation code that is included for 0.11 will give much more
accurate fee estimates, which should allow adding the correct fee to a
transaction to see it likely to be confirmed in a reasonable time.  For
further improvements:
- There has recently been attention to overhauling the block creation and
mempool limiting code in such a way that actual outstanding queues to be
included in a block could also be incorporated in fee estimation.  See
https://github.com/bitcoin/bitcoin/pull/6281.
- CPFP and RBF are candidates for inclusion in core soon, both of which
could be integrated into transaction processing to handle the edge cases
where a priori fee estimation fails. See
https://github.com/bitcoin/bitcoin/pull/1647 and
https://github.com/bitcoin/bitcoin/pull/6176

I know there has been much discussion of fee estimation not working for SPV
clients, but I believe several independent servers which were serving the
estimates from full nodes would go a long way towards allowing that
information to be used by SPV clients even if its not a completely
decentralized solution.  See for example
http://core2.bitcoincore.org/smartfee/latest.json



On Mon, Jun 15, 2015 at 8:08 PM, Aaron Voisine <voisine@gmail.com> 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 <brianchoffman@gmail.com>
> 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 <faizkhan00@gmail.com> 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 <kanzure@gmail.com> wrote:
>>
>>> On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn <mike@plan99.net> 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 requests to Bitcoin Core, so therefore Mike is a
>>> non-programmer". Communication is difficult and I can understand that, but
>>> we really have to be more careful when evaluating each other's messages;
>>> technical miscommunication can be catastrophic in this context. On the
>>> topic of whether you are a programmer, I suspect that ever since you built
>>> CIA.vc we have all known you're a programmer, Mike.
>>>
>>> - 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
>>>
>>> --
>>>
>>> My regards,
>>>
>>> Faiz Khan
>>>
>>>  <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #1.2: Type: text/html, Size: 10469 bytes --]

[-- Attachment #2: image1.JPG --]
[-- Type: image/jpeg, Size: 22107 bytes --]

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

[Eric Lombrozo]

[-- Attachment #1.1: Type: text/plain, Size: 814 bytes --]


> On Jun 15, 2015, at 3:54 PM, odinn <odinn.cyberguerrilla@riseup.net> wrote:
> 
> I also disagree with the notion that everybody's just ok with what
> Mike and Gavin are doing.... specifically, this statement by Mike
> 
> > The consensus you seek does exist. All wallet developers (except
> > Lawrence), all the major exchanges, all the major payment
> > processors and many of the major mining pools want to see the limit
> > lifted


This is certainly twisting words!

We all agree that the limit needs to eventually be lifted - but some of us certainly disagree with the means being used to do so by Mike and Gavin.

Most news publications keep the discussion rather shallow and like to keep the controversy pretty black and white - some of us have far more nuanced views!

- Eric Lombrozo

[-- Attachment #1.2: Type: text/html, Size: 5684 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

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

[Aaron Voisine]

[-- Attachment #1.1: Type: text/plain, Size: 9655 bytes --]

Thanks Alex, the work you've pointed out is helpful. Limiting mempool size
should at least prevent nodes from crashing. When I looked a few days ago I
only found a few old PRs that seemed to have fallen by the wayside, so this
new one is encouraging.

I can respond in the PR comments if it's more appropriate there, but I
believe ejecting tx from mempools rather than preemptively refusing them
according to standard network wide propagation rules will result in spotty,
inconsistent tx propagation, and possibly a large increase in tx
re-broadcasts, so if those haven't been addressed they will need to be. It
would also be prudent to run some simulations to see what other issues are
going to pop-up.

We're currently using CPFP already in breadwallet when spending unconfirmed
non-change inputs. A small percentage of hashing power is using it, but
enough to get a transaction unstuck assuming breadwallet's fee calculation
is better than the sender's.

The problem with RBF is that there's currently no way to tell if your tx
has been picked up by miners or not in order to know if you need to replace
it. Miners broadcasting partial block solutions would be helpful in this
regard, but only for tx in the currently-being-worked-on block, not for tx
that won't be picked up until the block after. If miners were to eject tx
that were previously being worked on in favor of higher fee tx, then that
causes another set of problems for wallets that thought their tx was going
to get in but then it doesn't. The other problem with RBF is that users
don't know up front what fee they're actually going to pay which is a big
blow to real world usability. Also mobile wallets will have to sign lots of
tx up front and rely on a service to replace as necessary. And this is all
just on the send side. On the receive side it's much worse since you can't
rely on the sender to do the replacing. The real problem seems to be the
fact that RBF is an interactive iterative process rather than a
send-and-forget one.

What you really need is some way to tell up-front, is a transaction going
to get mined with a high probability? That problem seems really difficult
to solve with fixed-size blocks that are full. If the goal is simply to
reduce or limit the growth of the blockchain, then there are much simpler
solutions, which is why I've advocated for the blocksize increase, followed
by tx selection and propagation rule changes to create fee pressure.

Aaron Voisine
co-founder and CEO
breadwallet.com

On Mon, Jun 15, 2015 at 6:17 PM, Alex Morcos <morcos@gmail.com> wrote:

> Aaron,
>
> My understanding is that Gavin and Mike are proceeding with the XT fork, I
> hope that understanding is wrong.
>
> As for improving the non-consensus code to handle full blocks more
> gracefully.  This is something I'm very interested in, block size increase
> or not. Perhaps I shouldn't hijack this thread, but maybe there are others
> who also believe this would ameliorate some of the time pressure for
> deciding on a block size increase.
>
> What is it that you would like to see improved?
> The fee estimation code that is included for 0.11 will give much more
> accurate fee estimates, which should allow adding the correct fee to a
> transaction to see it likely to be confirmed in a reasonable time.  For
> further improvements:
> - There has recently been attention to overhauling the block creation and
> mempool limiting code in such a way that actual outstanding queues to be
> included in a block could also be incorporated in fee estimation.  See
> https://github.com/bitcoin/bitcoin/pull/6281.
> - CPFP and RBF are candidates for inclusion in core soon, both of which
> could be integrated into transaction processing to handle the edge cases
> where a priori fee estimation fails. See
> https://github.com/bitcoin/bitcoin/pull/1647 and
> https://github.com/bitcoin/bitcoin/pull/6176
>
> I know there has been much discussion of fee estimation not working for
> SPV clients, but I believe several independent servers which were serving
> the estimates from full nodes would go a long way towards allowing that
> information to be used by SPV clients even if its not a completely
> decentralized solution.  See for example
> http://core2.bitcoincore.org/smartfee/latest.json
>
>
>
> On Mon, Jun 15, 2015 at 8:08 PM, Aaron Voisine <voisine@gmail.com> 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 <brianchoffman@gmail.com>
>> 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 <faizkhan00@gmail.com> 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 <kanzure@gmail.com> wrote:
>>>
>>>> On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn <mike@plan99.net> 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 requests to Bitcoin Core, so therefore Mike is a
>>>> non-programmer". Communication is difficult and I can understand that, but
>>>> we really have to be more careful when evaluating each other's messages;
>>>> technical miscommunication can be catastrophic in this context. On the
>>>> topic of whether you are a programmer, I suspect that ever since you built
>>>> CIA.vc we have all known you're a programmer, Mike.
>>>>
>>>> - 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
>>>>
>>>> --
>>>>
>>>> My regards,
>>>>
>>>> Faiz Khan
>>>>
>>>>  <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>

[-- Attachment #1.2: Type: text/html, Size: 13757 bytes --]

[-- Attachment #2: image1.JPG --]
[-- Type: image/jpeg, Size: 22107 bytes --]

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

[Venzen]

Mike Hearn,

In the light of your responses to Adam Back's questions, below, I feel
it is time to speak up because what I now understand, and is implied,
is that Mike Hearn and Gavin Andresen have planned and deployed the
infrastructure for a Bitcoin hard-fork and intend to action it despite
majority opposition.  http://xtnodes.com/

I'll try to keep it brief:

Mike Hearn, you should cease your activity of a unilateral hard-fork
immediately. You are doing untold damage by breaking FOSS governance
protocol requiring methodical collaborative work and due process of
change implementation by consensus. Your actions are bad for the
Bitcoin project and its ideals, disrespectful of your peers and years
of their passionate hard work, and dangerous for Bitcoin in the
marketplace and bitcoin in peoples' wallets.

Mike Hearn and Gavin Andresen do not own Bitcoin and, emphatically,
you cannot have it. Your hard-fork is tantamount to theft and you and
your collaborators will effectively ex-communicate yourselves from
this project and community. It appears that you are consciously trying
to usurp ownership and maintenance of Bitcoin. As if it is that easy!
You clearly do not comprehend the array of risks - especially the
unanticipated ones. As the market saying goes: "If you think
speculation is easy, it is because you are ignorant about the risks".
If you take the risks with Mike&GavCoin, that would be fine, but you
are about to take them with community-owned Bitcoin and Other People's
Money!

You are causing a lot of stress, unnecessarily, and grave concern
surrounds your proposed renegade action. You can dissolve the threat:
those players to whom you have made promises can be appeased and
eventually get most of what they need from this FOSS project. The
developers whom you are railroading to get your way, and the way in
which you are doing it, is about to cause a schism that will expand
outward from this community.

You may accuse the community for being antagonistic to you, and
therefore uncooperative, but it is plain to see that your bullheaded
manner eventually generates antagonism wherever you go. Taking Bitcoin
away from this community, in anger, won't solve the problem and will
be like killing the goose that lays the golden eggs.

If an individual in an objectively agreed-to FOSS-modelled
collaborative project has the audacity to threaten his peers and the
world with a unilateral hard-fork despite majority objection and a
probability distribution that includes terminal risks and unintended
consequences, then what would an impartial outsider think? Some of
their thoughts would include that the antagonist could be acting in
self-interest, or may be a paid actor, or worse, a saboteur. What
would they advise? Stop that individual, at once!

Bitcoin is a Free and Open Source Software project that serves as
flagship for the blockchain. It has a payment network but the key
benefits are censorship resistance and trustless decentralization.
There is protocol for how change is effected in a FOSS project. For
the sake of everything that is good and useful in Bitcoin, reconsider
your dangerous plan and its intended and unintended consequences. Put
your feet back on the ground, return to the fold and let the
collaborative FOSS model, and the skills available here, gradually
scale Bitcoin to your (and all our) grand vision.

Venzen Khaosan


On 06/15/2015 04:56 PM, Mike Hearn wrote:
> Hi Adam,
> 
> Provisional answers below!
> 
> - Are you releasing a BIP for that proposal for review?
> 
> 
> The work splits like this:
> 
> * Gavin is writing the code and I think a BIP as well
> 
> * I will review both and mostly delegate to Gavin's good taste
> around the details, unless there is some very strong disagreement.
> But that seems unlikely.
> 
> * I have been handling gitian and the patch rebases, the code
> signing and so on, so far. I've also been doing some work to setup
> the basic infrastructure of the project (website etc).
> 
> 
> - If the reviewers all say NACK will you take on board their 
> suggestions?
> 
> 
> Feedback will be read. There are no NACKS in Bitcoin XT. Patch
> requests aren't scored in any way. The final decision rests with
> the maintainer as in ~all open source projects.
> 
> 
> 
> - On the idea of a non-consensus hard-fork at all, I think we can 
> assume you will get a row of NACKs.  Can you explain your
> rationale for going ahead anyway?  The risks are well understood
> and enormous.
> 
> 
> Yes, I have been working on an article that explains how we got to
> this point from my perspective. It is quite long, but only because
> I want it to be readable for people who weren't following the
> debate.
> 
> Anyway, I think I've laid out the gist of it over and over again,
> but to summarise:
> 
> If Bitcoin runs out of capacity *it will break and many of our
> users will leave*. That is not an acceptable outcome for myself or
> the many other wallet, service and merchant developers who have
> worked for years to build an ecosystem around this protocol.
> 
> 
> 
> - How do you propose to deal with the extra risks that come from 
> non-consensus hard-forks?  Hard-forks themselves are quite risky,
> but non-consensus ones are extremely dangerous for consensus.
> 
> 
> The approach is the same for other forks. Voting via block versions
> and then when there's been >X% for Y time units the 1mb limit is 
> lifted/replaced.
> 
> 
> 
> 
> - If you're going it alone as it were, are you proposing that you
> will personally maintain bitcoin-XT?  Or do you have a plan to
> later hand over maintenance to the bitcoin developers?
> 
> 
> Good question!  I have various thoughts on this, but let's wait and
> see what happens first. Perhaps the new chain won't get the
> majority on it.
> 
> In the event that the >1mb chain does eventually win, I would
> expect Core to apply the patch and rejoin the consensus rather than
> lose all its users. That would take XT back to being a fairly small
> patchset to improve the network protocol.
> 
> 
> 
> - Do you have contingency plans for what to do if the
> non-consensus hard-fork goes wrong and $3B is lost as a result?
> 
> 
> Where did you get the $3B figure from? The fork either doesn't
> happen, or it happens after quite a long period of people knowing
> it's going to happen - for example because their full node is
> printing "You need to upgrade" messages due to seeing the larger
> block version, or because they read the news, or because they heard
> about it via some other mechanisms.
> 
> Let me flip the question around. Do you have a contingency plan if 
> Bitcoin runs out of capacity and significant user disruption occurs
> that results in exodus, followed by fall in BTC price? The only one
> I've seen is "we can perform an emergency hard fork in a few
> weeks"!
> 
> 
> 
> As you can probably tell I think a unilateral fork without
> wide-scale consensus from the technical and business communities is
> a deeply inadvisable.
> 
> 
> Gavin and I have been polling many key players in the ecosystem.
> The consensus you seek does exist. All wallet developers (except
> Lawrence), all the major exchanges, all the major payment
> processors and many of the major mining pools want to see the limit
> lifted (I haven't been talking to pools, Gavin has).
> 
> This notion that the change has no consensus is based on you
> polling the people directly around you and people who like to spend
> all day on this mailing list. It's not an accurate reflection of
> the wider Bitcoin community and that is one of the leading reasons
> there is going to be a fork. A small number of people have been
> flatly ignoring LOTS of highly technical and passionate developers
> who have written vast amounts of code, built up the Bitcoin user
> base, designed hardware and software, and yes built companies.
> 
> How do you think that makes Bitcoin Core look to the rest of the
> Bitcoin world? How much confidence does that give people?
> 
> 
> 
> Of the overall process, I think you can agree we should not be
> making technical decisions with this level of complexity and
> consensus risk with financial implications of this magnitude under
> duress of haste?
> 
> 
> This debate will never end until a fork makes it irrelevant. There
> is no process for ending it, despite me begging Wladimir to make
> one.
> 
> And there is no haste. We have been debating the block size limit
> for _years_. We have known it must be lifted for _years_. I kicked
> off this current round of debates after realising that Wladimir's
> release timeline wouldn't allow a block size limit to be released
> before the end of the year. The reason we're talking about it now
> and not next year is exactly to ensure there is plenty of time.
> 
> 
> 
> 
> I can sincerely assure you everyone does want to scale bitcoin and 
> shares your long term objective on that
> 
> 
> I really wish you were right, and I definitely feel you are one of
> the more reasonable ones Adam. But the overwhelming impression I
> get from a few others here is that no, they don't want to scale
> Bitcoin. They already decided it's a technological dead end. They
> want to kick end users out in order to "incentivise" (force) the
> creation of some other alternative, claiming that it's still
> Bitcoin whilst ignoring basic details ... like the fact that no
> existing wallets or services would work.
> 
> Scaling Bitcoin can only be achieved by letting it grow, and
> letting people tackle each bottleneck as it arises at the right
> times. Not by convincing ourselves that success is failure.
> 
> 
> 
> ------------------------------------------------------------------------------
>
> 
> 
> 
> _______________________________________________ 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

[Marcel Jamin]

[-- Attachment #1: Type: text/plain, Size: 11746 bytes --]

> Mike Hearn and Gavin Andresen do not own Bitcoin and, emphatically,
you cannot have it.

Neither do you or anyone else.

> There is protocol for how change is effected in a FOSS project.

And it allows the minority to hold the majority hostage.

> If you take the risks with Mike&GavCoin, that would be fine, but you are
about to take them with community-owned Bitcoin and Other People's Money!

The same can be said about the other camp.

BitcoinXT is not going to fork the chain on a specific date no matter what.
People will be able to vote via block versions and once a sufficient
majority supports the extensions, everyone else will have a grace period to
upgrade. Only after that is a very small minority at risk of losing money.

That being said, I'd rather see a solution that everyone agrees on. My
personal opinion/hope is that Mike and Gavin are just applying pressure
where it's needed. But in the end, they can do whatever they want if they
have the necessary support. Permissionless innovation is one of bitcoins
virtues. In the end, only adoption will decide what bitcoin is and isn't.

2015-06-16 7:18 GMT+02:00 Venzen <venzen@mail.bihthai.net>:

> Mike Hearn,
>
> In the light of your responses to Adam Back's questions, below, I feel
> it is time to speak up because what I now understand, and is implied,
> is that Mike Hearn and Gavin Andresen have planned and deployed the
> infrastructure for a Bitcoin hard-fork and intend to action it despite
> majority opposition.  http://xtnodes.com/
>
> I'll try to keep it brief:
>
> Mike Hearn, you should cease your activity of a unilateral hard-fork
> immediately. You are doing untold damage by breaking FOSS governance
> protocol requiring methodical collaborative work and due process of
> change implementation by consensus. Your actions are bad for the
> Bitcoin project and its ideals, disrespectful of your peers and years
> of their passionate hard work, and dangerous for Bitcoin in the
> marketplace and bitcoin in peoples' wallets.
>
> Mike Hearn and Gavin Andresen do not own Bitcoin and, emphatically,
> you cannot have it. Your hard-fork is tantamount to theft and you and
> your collaborators will effectively ex-communicate yourselves from
> this project and community. It appears that you are consciously trying
> to usurp ownership and maintenance of Bitcoin. As if it is that easy!
> You clearly do not comprehend the array of risks - especially the
> unanticipated ones. As the market saying goes: "If you think
> speculation is easy, it is because you are ignorant about the risks".
> If you take the risks with Mike&GavCoin, that would be fine, but you
> are about to take them with community-owned Bitcoin and Other People's
> Money!
>
> You are causing a lot of stress, unnecessarily, and grave concern
> surrounds your proposed renegade action. You can dissolve the threat:
> those players to whom you have made promises can be appeased and
> eventually get most of what they need from this FOSS project. The
> developers whom you are railroading to get your way, and the way in
> which you are doing it, is about to cause a schism that will expand
> outward from this community.
>
> You may accuse the community for being antagonistic to you, and
> therefore uncooperative, but it is plain to see that your bullheaded
> manner eventually generates antagonism wherever you go. Taking Bitcoin
> away from this community, in anger, won't solve the problem and will
> be like killing the goose that lays the golden eggs.
>
> If an individual in an objectively agreed-to FOSS-modelled
> collaborative project has the audacity to threaten his peers and the
> world with a unilateral hard-fork despite majority objection and a
> probability distribution that includes terminal risks and unintended
> consequences, then what would an impartial outsider think? Some of
> their thoughts would include that the antagonist could be acting in
> self-interest, or may be a paid actor, or worse, a saboteur. What
> would they advise? Stop that individual, at once!
>
> Bitcoin is a Free and Open Source Software project that serves as
> flagship for the blockchain. It has a payment network but the key
> benefits are censorship resistance and trustless decentralization.
> There is protocol for how change is effected in a FOSS project. For
> the sake of everything that is good and useful in Bitcoin, reconsider
> your dangerous plan and its intended and unintended consequences. Put
> your feet back on the ground, return to the fold and let the
> collaborative FOSS model, and the skills available here, gradually
> scale Bitcoin to your (and all our) grand vision.
>
> Venzen Khaosan
>
>
> On 06/15/2015 04:56 PM, Mike Hearn wrote:
> > Hi Adam,
> >
> > Provisional answers below!
> >
> > - Are you releasing a BIP for that proposal for review?
> >
> >
> > The work splits like this:
> >
> > * Gavin is writing the code and I think a BIP as well
> >
> > * I will review both and mostly delegate to Gavin's good taste
> > around the details, unless there is some very strong disagreement.
> > But that seems unlikely.
> >
> > * I have been handling gitian and the patch rebases, the code
> > signing and so on, so far. I've also been doing some work to setup
> > the basic infrastructure of the project (website etc).
> >
> >
> > - If the reviewers all say NACK will you take on board their
> > suggestions?
> >
> >
> > Feedback will be read. There are no NACKS in Bitcoin XT. Patch
> > requests aren't scored in any way. The final decision rests with
> > the maintainer as in ~all open source projects.
> >
> >
> >
> > - On the idea of a non-consensus hard-fork at all, I think we can
> > assume you will get a row of NACKs.  Can you explain your
> > rationale for going ahead anyway?  The risks are well understood
> > and enormous.
> >
> >
> > Yes, I have been working on an article that explains how we got to
> > this point from my perspective. It is quite long, but only because
> > I want it to be readable for people who weren't following the
> > debate.
> >
> > Anyway, I think I've laid out the gist of it over and over again,
> > but to summarise:
> >
> > If Bitcoin runs out of capacity *it will break and many of our
> > users will leave*. That is not an acceptable outcome for myself or
> > the many other wallet, service and merchant developers who have
> > worked for years to build an ecosystem around this protocol.
> >
> >
> >
> > - How do you propose to deal with the extra risks that come from
> > non-consensus hard-forks?  Hard-forks themselves are quite risky,
> > but non-consensus ones are extremely dangerous for consensus.
> >
> >
> > The approach is the same for other forks. Voting via block versions
> > and then when there's been >X% for Y time units the 1mb limit is
> > lifted/replaced.
> >
> >
> >
> >
> > - If you're going it alone as it were, are you proposing that you
> > will personally maintain bitcoin-XT?  Or do you have a plan to
> > later hand over maintenance to the bitcoin developers?
> >
> >
> > Good question!  I have various thoughts on this, but let's wait and
> > see what happens first. Perhaps the new chain won't get the
> > majority on it.
> >
> > In the event that the >1mb chain does eventually win, I would
> > expect Core to apply the patch and rejoin the consensus rather than
> > lose all its users. That would take XT back to being a fairly small
> > patchset to improve the network protocol.
> >
> >
> >
> > - Do you have contingency plans for what to do if the
> > non-consensus hard-fork goes wrong and $3B is lost as a result?
> >
> >
> > Where did you get the $3B figure from? The fork either doesn't
> > happen, or it happens after quite a long period of people knowing
> > it's going to happen - for example because their full node is
> > printing "You need to upgrade" messages due to seeing the larger
> > block version, or because they read the news, or because they heard
> > about it via some other mechanisms.
> >
> > Let me flip the question around. Do you have a contingency plan if
> > Bitcoin runs out of capacity and significant user disruption occurs
> > that results in exodus, followed by fall in BTC price? The only one
> > I've seen is "we can perform an emergency hard fork in a few
> > weeks"!
> >
> >
> >
> > As you can probably tell I think a unilateral fork without
> > wide-scale consensus from the technical and business communities is
> > a deeply inadvisable.
> >
> >
> > Gavin and I have been polling many key players in the ecosystem.
> > The consensus you seek does exist. All wallet developers (except
> > Lawrence), all the major exchanges, all the major payment
> > processors and many of the major mining pools want to see the limit
> > lifted (I haven't been talking to pools, Gavin has).
> >
> > This notion that the change has no consensus is based on you
> > polling the people directly around you and people who like to spend
> > all day on this mailing list. It's not an accurate reflection of
> > the wider Bitcoin community and that is one of the leading reasons
> > there is going to be a fork. A small number of people have been
> > flatly ignoring LOTS of highly technical and passionate developers
> > who have written vast amounts of code, built up the Bitcoin user
> > base, designed hardware and software, and yes built companies.
> >
> > How do you think that makes Bitcoin Core look to the rest of the
> > Bitcoin world? How much confidence does that give people?
> >
> >
> >
> > Of the overall process, I think you can agree we should not be
> > making technical decisions with this level of complexity and
> > consensus risk with financial implications of this magnitude under
> > duress of haste?
> >
> >
> > This debate will never end until a fork makes it irrelevant. There
> > is no process for ending it, despite me begging Wladimir to make
> > one.
> >
> > And there is no haste. We have been debating the block size limit
> > for _years_. We have known it must be lifted for _years_. I kicked
> > off this current round of debates after realising that Wladimir's
> > release timeline wouldn't allow a block size limit to be released
> > before the end of the year. The reason we're talking about it now
> > and not next year is exactly to ensure there is plenty of time.
> >
> >
> >
> >
> > I can sincerely assure you everyone does want to scale bitcoin and
> > shares your long term objective on that
> >
> >
> > I really wish you were right, and I definitely feel you are one of
> > the more reasonable ones Adam. But the overwhelming impression I
> > get from a few others here is that no, they don't want to scale
> > Bitcoin. They already decided it's a technological dead end. They
> > want to kick end users out in order to "incentivise" (force) the
> > creation of some other alternative, claiming that it's still
> > Bitcoin whilst ignoring basic details ... like the fact that no
> > existing wallets or services would work.
> >
> > Scaling Bitcoin can only be achieved by letting it grow, and
> > letting people tackle each bottleneck as it arises at the right
> > times. Not by convincing ourselves that success is failure.
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> >
> >
> >
> >
> > _______________________________________________ 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
>

[-- Attachment #2: Type: text/html, Size: 15179 bytes --]

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

[Benjamin]

"And it allows the minority to hold the majority hostage"

The Bitcoin protocol has no definitions about developer consensus .
The reference to FOSS is quite arbitrary. The alternative of lobbying
companies is equally indeterminate and arbitrary. One of the core
problem is that you can't poll users about features, and even if one
could users are unlikely to be able to make design decisions about the
system. Voting is a quite imperfect mechanism. IF there would be a
hardfork vote of this kind, at least each party should lay out a
longterm plan and proposal. Mike and Gavin don't have any plans to
implement new scaling facilities and Lightening is not a coherent
proposal. In effect this fork battle would not be part of a BIP
process, but a vote on a longterm plan/architecture.

On Tue, Jun 16, 2015 at 8:09 AM, Marcel Jamin <marcel@jamin.net> wrote:
>> Mike Hearn and Gavin Andresen do not own Bitcoin and, emphatically,
> you cannot have it.
>
> Neither do you or anyone else.
>
>> There is protocol for how change is effected in a FOSS project.
>
> And it allows the minority to hold the majority hostage.
>
>> If you take the risks with Mike&GavCoin, that would be fine, but you are
>> about to take them with community-owned Bitcoin and Other People's Money!
>
> The same can be said about the other camp.
>
> BitcoinXT is not going to fork the chain on a specific date no matter what.
> People will be able to vote via block versions and once a sufficient
> majority supports the extensions, everyone else will have a grace period to
> upgrade. Only after that is a very small minority at risk of losing money.
>
> That being said, I'd rather see a solution that everyone agrees on. My
> personal opinion/hope is that Mike and Gavin are just applying pressure
> where it's needed. But in the end, they can do whatever they want if they
> have the necessary support. Permissionless innovation is one of bitcoins
> virtues. In the end, only adoption will decide what bitcoin is and isn't.
>
> 2015-06-16 7:18 GMT+02:00 Venzen <venzen@mail.bihthai.net>:
>>
>> Mike Hearn,
>>
>> In the light of your responses to Adam Back's questions, below, I feel
>> it is time to speak up because what I now understand, and is implied,
>> is that Mike Hearn and Gavin Andresen have planned and deployed the
>> infrastructure for a Bitcoin hard-fork and intend to action it despite
>> majority opposition.  http://xtnodes.com/
>>
>> I'll try to keep it brief:
>>
>> Mike Hearn, you should cease your activity of a unilateral hard-fork
>> immediately. You are doing untold damage by breaking FOSS governance
>> protocol requiring methodical collaborative work and due process of
>> change implementation by consensus. Your actions are bad for the
>> Bitcoin project and its ideals, disrespectful of your peers and years
>> of their passionate hard work, and dangerous for Bitcoin in the
>> marketplace and bitcoin in peoples' wallets.
>>
>> Mike Hearn and Gavin Andresen do not own Bitcoin and, emphatically,
>> you cannot have it. Your hard-fork is tantamount to theft and you and
>> your collaborators will effectively ex-communicate yourselves from
>> this project and community. It appears that you are consciously trying
>> to usurp ownership and maintenance of Bitcoin. As if it is that easy!
>> You clearly do not comprehend the array of risks - especially the
>> unanticipated ones. As the market saying goes: "If you think
>> speculation is easy, it is because you are ignorant about the risks".
>> If you take the risks with Mike&GavCoin, that would be fine, but you
>> are about to take them with community-owned Bitcoin and Other People's
>> Money!
>>
>> You are causing a lot of stress, unnecessarily, and grave concern
>> surrounds your proposed renegade action. You can dissolve the threat:
>> those players to whom you have made promises can be appeased and
>> eventually get most of what they need from this FOSS project. The
>> developers whom you are railroading to get your way, and the way in
>> which you are doing it, is about to cause a schism that will expand
>> outward from this community.
>>
>> You may accuse the community for being antagonistic to you, and
>> therefore uncooperative, but it is plain to see that your bullheaded
>> manner eventually generates antagonism wherever you go. Taking Bitcoin
>> away from this community, in anger, won't solve the problem and will
>> be like killing the goose that lays the golden eggs.
>>
>> If an individual in an objectively agreed-to FOSS-modelled
>> collaborative project has the audacity to threaten his peers and the
>> world with a unilateral hard-fork despite majority objection and a
>> probability distribution that includes terminal risks and unintended
>> consequences, then what would an impartial outsider think? Some of
>> their thoughts would include that the antagonist could be acting in
>> self-interest, or may be a paid actor, or worse, a saboteur. What
>> would they advise? Stop that individual, at once!
>>
>> Bitcoin is a Free and Open Source Software project that serves as
>> flagship for the blockchain. It has a payment network but the key
>> benefits are censorship resistance and trustless decentralization.
>> There is protocol for how change is effected in a FOSS project. For
>> the sake of everything that is good and useful in Bitcoin, reconsider
>> your dangerous plan and its intended and unintended consequences. Put
>> your feet back on the ground, return to the fold and let the
>> collaborative FOSS model, and the skills available here, gradually
>> scale Bitcoin to your (and all our) grand vision.
>>
>> Venzen Khaosan
>>
>>
>> On 06/15/2015 04:56 PM, Mike Hearn wrote:
>> > Hi Adam,
>> >
>> > Provisional answers below!
>> >
>> > - Are you releasing a BIP for that proposal for review?
>> >
>> >
>> > The work splits like this:
>> >
>> > * Gavin is writing the code and I think a BIP as well
>> >
>> > * I will review both and mostly delegate to Gavin's good taste
>> > around the details, unless there is some very strong disagreement.
>> > But that seems unlikely.
>> >
>> > * I have been handling gitian and the patch rebases, the code
>> > signing and so on, so far. I've also been doing some work to setup
>> > the basic infrastructure of the project (website etc).
>> >
>> >
>> > - If the reviewers all say NACK will you take on board their
>> > suggestions?
>> >
>> >
>> > Feedback will be read. There are no NACKS in Bitcoin XT. Patch
>> > requests aren't scored in any way. The final decision rests with
>> > the maintainer as in ~all open source projects.
>> >
>> >
>> >
>> > - On the idea of a non-consensus hard-fork at all, I think we can
>> > assume you will get a row of NACKs.  Can you explain your
>> > rationale for going ahead anyway?  The risks are well understood
>> > and enormous.
>> >
>> >
>> > Yes, I have been working on an article that explains how we got to
>> > this point from my perspective. It is quite long, but only because
>> > I want it to be readable for people who weren't following the
>> > debate.
>> >
>> > Anyway, I think I've laid out the gist of it over and over again,
>> > but to summarise:
>> >
>> > If Bitcoin runs out of capacity *it will break and many of our
>> > users will leave*. That is not an acceptable outcome for myself or
>> > the many other wallet, service and merchant developers who have
>> > worked for years to build an ecosystem around this protocol.
>> >
>> >
>> >
>> > - How do you propose to deal with the extra risks that come from
>> > non-consensus hard-forks?  Hard-forks themselves are quite risky,
>> > but non-consensus ones are extremely dangerous for consensus.
>> >
>> >
>> > The approach is the same for other forks. Voting via block versions
>> > and then when there's been >X% for Y time units the 1mb limit is
>> > lifted/replaced.
>> >
>> >
>> >
>> >
>> > - If you're going it alone as it were, are you proposing that you
>> > will personally maintain bitcoin-XT?  Or do you have a plan to
>> > later hand over maintenance to the bitcoin developers?
>> >
>> >
>> > Good question!  I have various thoughts on this, but let's wait and
>> > see what happens first. Perhaps the new chain won't get the
>> > majority on it.
>> >
>> > In the event that the >1mb chain does eventually win, I would
>> > expect Core to apply the patch and rejoin the consensus rather than
>> > lose all its users. That would take XT back to being a fairly small
>> > patchset to improve the network protocol.
>> >
>> >
>> >
>> > - Do you have contingency plans for what to do if the
>> > non-consensus hard-fork goes wrong and $3B is lost as a result?
>> >
>> >
>> > Where did you get the $3B figure from? The fork either doesn't
>> > happen, or it happens after quite a long period of people knowing
>> > it's going to happen - for example because their full node is
>> > printing "You need to upgrade" messages due to seeing the larger
>> > block version, or because they read the news, or because they heard
>> > about it via some other mechanisms.
>> >
>> > Let me flip the question around. Do you have a contingency plan if
>> > Bitcoin runs out of capacity and significant user disruption occurs
>> > that results in exodus, followed by fall in BTC price? The only one
>> > I've seen is "we can perform an emergency hard fork in a few
>> > weeks"!
>> >
>> >
>> >
>> > As you can probably tell I think a unilateral fork without
>> > wide-scale consensus from the technical and business communities is
>> > a deeply inadvisable.
>> >
>> >
>> > Gavin and I have been polling many key players in the ecosystem.
>> > The consensus you seek does exist. All wallet developers (except
>> > Lawrence), all the major exchanges, all the major payment
>> > processors and many of the major mining pools want to see the limit
>> > lifted (I haven't been talking to pools, Gavin has).
>> >
>> > This notion that the change has no consensus is based on you
>> > polling the people directly around you and people who like to spend
>> > all day on this mailing list. It's not an accurate reflection of
>> > the wider Bitcoin community and that is one of the leading reasons
>> > there is going to be a fork. A small number of people have been
>> > flatly ignoring LOTS of highly technical and passionate developers
>> > who have written vast amounts of code, built up the Bitcoin user
>> > base, designed hardware and software, and yes built companies.
>> >
>> > How do you think that makes Bitcoin Core look to the rest of the
>> > Bitcoin world? How much confidence does that give people?
>> >
>> >
>> >
>> > Of the overall process, I think you can agree we should not be
>> > making technical decisions with this level of complexity and
>> > consensus risk with financial implications of this magnitude under
>> > duress of haste?
>> >
>> >
>> > This debate will never end until a fork makes it irrelevant. There
>> > is no process for ending it, despite me begging Wladimir to make
>> > one.
>> >
>> > And there is no haste. We have been debating the block size limit
>> > for _years_. We have known it must be lifted for _years_. I kicked
>> > off this current round of debates after realising that Wladimir's
>> > release timeline wouldn't allow a block size limit to be released
>> > before the end of the year. The reason we're talking about it now
>> > and not next year is exactly to ensure there is plenty of time.
>> >
>> >
>> >
>> >
>> > I can sincerely assure you everyone does want to scale bitcoin and
>> > shares your long term objective on that
>> >
>> >
>> > I really wish you were right, and I definitely feel you are one of
>> > the more reasonable ones Adam. But the overwhelming impression I
>> > get from a few others here is that no, they don't want to scale
>> > Bitcoin. They already decided it's a technological dead end. They
>> > want to kick end users out in order to "incentivise" (force) the
>> > creation of some other alternative, claiming that it's still
>> > Bitcoin whilst ignoring basic details ... like the fact that no
>> > existing wallets or services would work.
>> >
>> > Scaling Bitcoin can only be achieved by letting it grow, and
>> > letting people tackle each bottleneck as it arises at the right
>> > times. Not by convincing ourselves that success is failure.
>> >
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> >
>> >
>> >
>> >
>> > _______________________________________________ Bitcoin-development
>> > mailing list Bitcoin-development@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>> >
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

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

[Tier Nolan]

[-- Attachment #1: Type: text/plain, Size: 3798 bytes --]

On Tue, Jun 16, 2015 at 6:18 AM, Venzen <venzen@mail.bihthai.net> wrote:

> Mike Hearn, you should cease your activity of a unilateral hard-fork
> immediately. You are doing untold damage by breaking FOSS governance
> protocol requiring methodical collaborative work and due process of
> change implementation by consensus.


The main principle of open source software is that anyone can fork the code
if they wish.  They don't do it very often, but they can.

This means that if a project dies, someone can take it over.  If some of
the devs want to take things in a different direction, they can.  Users can
decide which version they prefer.

The software itself is what is valuable.

In the case of bitcoin, the blockchain is also (very) valuable.  Simply
splitting into two projects is not possible for bitcoin.

Otherwise, the discussion would have ended already, those who want a larger
block would simply create a fork of the software and create an alt chain.

The fundamental problem is that there is no clear way to make this decision
once and for all.

An agreed set of rules for a hard fork would be a nice thing to have, but
it is hard to have rules about how to change fundamental rules.

I think using the soft fork rules (maybe with a higher threshold than 95%)
plus a delay is a reasonable compromise on hard fork rules.

Even then, it would be nice to include users of the software too.  Peter
Todd's suggestion of encoding a vote in transactions is a step in that
direction (YES transactions in YES blocks and NO transactions in NO blocks).


> Mike Hearn and Gavin Andresen do not own Bitcoin and, emphatically,
> you cannot have it.


Nobody owns it, so there is no court of final appeal.

If miners vote >95% for the fork, users could still refuse to accept the
change.

Maybe the sequence could be

version 3 blocks means no opinion
version 4 blocks means NO to fork
version 5 blocks means YES to fork & YES transactions
version 6 blocks means YES to fork & NO transactions

Transaction matching rule:

version 1, 2, 3 transactions means no opinion (can be in any block)
version 4 transactions means YES to fork (cannot be in version 6 blocks)
version 5 transactions means NO to fork (cannot be in version 5 blocks)

Rules
0) if 750 of the last 1000 blocks are version 5 or 6 blocks, tx matching
rule activates for version 5 & 6 blocks
1) if 950 of the last 1000 blocks are version 5 or 6 blocks, then version 4
blocks are rejected
2) if 750 of the last 1000 blocks are version 4 blocks, then version 5 & 6
blocks are rejected
3) if 750 of the last 1000 blocks are version 5 transactions and 950 of the
last 1000 are version 5 or 6, then the fork is accepted
4) 25,000 blocks after 3 is accepted, hard fork actually takes effect

Once miner acceptance is achieved, then only version 5 and 6 blocks are
allowed.  The split between version 5 and 6 blocks should be roughly in
proportion to the number of transactions of each kind produced.

75% of miners can kill the fork by producing version 4 blocks, but 95% is
needed for acceptance.  Even then, transaction volume needs to support the
fork.  I think 75% is reasonable here.  (95% of miners and 75% of
merchants/users is a pretty strong majority).


> You may accuse the community for being antagonistic to you, and
> therefore uncooperative, but it is plain to see that your bullheaded
> manner eventually generates antagonism wherever you go. Taking Bitcoin
> away from this community, in anger, won't solve the problem and will
> be like killing the goose that lays the golden eggs.
>

They are still suggesting some kind of fork threshold process (or at least
that is what is being suggested)

If their system requires 95% miner approval, they aren't taking unilateral
action.  Miners are though if they vote in favour.

[-- Attachment #2: Type: text/html, Size: 5034 bytes --]

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

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 1486 bytes --]

Hi Bryan,

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 requests to Bitcoin Core, so therefore Mike is a non-programmer".
>

Yes, my comment was prickly and grumpy. No surprises, I did not sleep well
last night.

I am upset about this constant insistence from Adam, Gregory and others
that the "technical community" or "technical majority" agree with them and
anyone who doesn't is "non technical" or "not a contributor" or not an
expert or not had things properly explained to them.

This is not true and needs to stop. Gavin and I have both been working on
Bitcoin in substantial ways for longer than Gregory and Adam have been in
the community at all. We are extremely technical, as are many of the people
who want us to release XT+larger blocks. We cannot make progress in any
kind of negotiation if one side constantly blows off the other and refuses
to take anything they say seriously, which has been a feature of this
"debate" from the start.

In contrast Gavin and I have written vast amounts of analysis on the
concerns raised by larger blocks. So many hours were spent, we could
probably fill a small book by now. We have carefully read and addressed
*dozens* of points raised by the 1mb camp. We have also done our best to
open this debate to the whole community.

So it would be nice if the people who are so keen on 1mb blocks show the
same respect to us.

[-- Attachment #2: Type: text/html, Size: 1959 bytes --]

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

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 2188 bytes --]

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

How do we plan to deal with security & incident response - exactly the same
way as before. Remember that XT is basically Core plus a few patches.

Gavin and myself are both on the bitcoin-security mailing list and have
been for years. Both of us have experience of responding to very serious
and tight-deadline security incidents, for example, the accidental bdb hard
fork and (in my case) when we discovered that Android phones had so little
entropy in them that different devices were actually generating the same
keys!

That one required co-ordinated crash rollouts of multiple wallets across
the Bitcoin ecosystem because there was a parallel investigation into key
collisions taking place in an open forum and they were not far from
discovering the truth about how badly the Android RNG was broken   (I knew
because at the time I had access to the Google internal Android bug
tracker). I organised the whole thing.

So I think we'll manage. But I don't expect things to exist in a state of
disjointness for very long. XT will rebase on top of Core and follow it's
releases for as long as there seems to be interest in bigger blocks and as
long as I have the time/energy/interest. If the >1mb chain wins then Core
will have to adopt the new ruleset or simply stop being relevant, as it
will have no users. That wouldn't make much sense.

Now, there have been concerns raised that a hard fork is unbelievably
risky, the sky will fall, the value of Bitcoin will drop to zero, etc. I
don't believe it's anywhere near that risky. The patch Gavin is working on
requires both a miner majority *and* also has a date trigger in it. Much
like previous forks, in fact. So nobody should be taken by surprise if/when
bigger blocks appear, because it will have been known for a long time
beforehand that there was sufficiently strong consensus, there will have
been messages printed to the node logs, announcements in various places and
so on.

Does that help clear things up?

[-- Attachment #2: Type: text/html, Size: 2631 bytes --]

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

[Pindar Wong]

[-- Attachment #1: Type: text/plain, Size: 26818 bytes --]

On Tue, Jun 16, 2015 at 2:03 AM, Adam Back <adam@cypherspace.org> wrote:

> Hi Mike
>
> Well thank you for replying openly on this topic, its helpful.
>
> I apologise in advance if this gets quite to the point and at times
> blunt, but transparency is important, and we owe it to the users who
> see Bitcoin as the start of a new future and the$3b of invested funds
> and $600m of VC funds invested in companies, we owe it to them that we
> be open and transparent here.
>
> I would really prefer on a personal nor professional basis to be
> having this conversation period, never mind in public, but Mike - your
> and Gavin's decision to promote a unilateral hard-fork and code fork
> are extremely high risk for bitcoin and so there remains little
> choice.  So I apologise again that we have to have this kind of
> conversation on a technical discussion list.  This whole thing is
> hugely stressful and worrying for developers, companies and investors.
>
> I strongly urge that we return to the existing collaborative
> constructive review process that has been used for the last 4 years
> which is a consensus by design to prevent one rogue person from
> inserting a backdoor, or lobbying for a favoured change on behalf of a
> special interest group, or working for bad actor (without accusing you
> of any of those - I understand you personally just want to scale
> bitcoin, but are inclined to knock heads and try to force an issue you
> see, rather than work collaboratively).
>
> For you (and everyone)
>
> - Should there be a summit of some kind, that is open attendance, and
> video recorded so that people who are unable to attend can participate
> too, so that people can present the technical proposals and risks in
> an unbiased way?
>
>
Dear Adam, All:

At the community's convenience, it would be an honour to arrange an initial
open summit to meet with representatives of the Chinese miners in Hong Kong
(UTC+8) to facilitate a better understand between the different
stakeholders of the Bitcoin ecosystem on this important issue.   This could
be arranged for this October, or earlier, if deemed necessary.

Remote online participation would be welcome from those who might not be
able to attend in person.

However,  it is hoped that such a meeting would be primarily document
driven to facilitate orderly translation, discussion and decision.

p.



> (It is not theoretical question, I may have a sponsor and host - not
> Blockstream, an independent, its a question for everyone, developers,
> users, CTOs, CEOs.)
>
>
>
> So here I come back to more frank questions:
>
> Governance
>
> The rest of the developers are wise to realise that they do not want
> exclusive control, to avoid governance centralising into the hands of
> one person, and this is why they have shared it with a consensus
> process over the last 4 years.  No offence but I dont think you
> personally are thinking far enough ahead to think you want personal
> control of this industry.  Maybe some factions dont trust your
> motives, or they dont mind, but feel more assured if a dozen other
> people are closely reviewing and have collective review authority.
>
> - Do you understand that attempting to break this process by
> unilateral hard-fork is extremely weakening of Bitcoin's change
> governance model?
>
> - Do you understand that change governance is important, and that it
> is important that there be multiple reviewers and sign-off to avoid
> someone being blackmailed or influenced by an external party - which
> could potentially result in massive theft of funds if something were
> missed?
>
> - Secondarily do you understand that even if you succeed in a
> unilateral fork (and the level of lost coins and market cap and damage
> to confidence is recoverable), that it sets a precedent that others
> may try to follow in the future to introduce coercive features that
> break the assurances of bitcoin, like fungibility reducing features
> say (topically I hear you once proposed on a private forum the concept
> of red-lists, other such proposals have been made and quickly
> abandoned), or ultimately if there is a political process to obtain
> unpopular changes by unilateral threat, the sky is the limit - rewrite
> the social contract at that point without consensus, but by
> calculation that people will value Bitcoin enough that they will
> follow a lead to avoid risk to the system?
>
>
> Security
>
> As you probably know some extremely subtle bugs in Bitcoin have at
> times slipped past even the most rigorous testings, often with
> innocuous but unexpected behaviours, but some security issues  Some
> extremely intricate and time-sensitive security defect and incident
> response happens from time to time which is not necessarily publicly
> disclosed until after the issue has been rolled out and fixed, which
> can take some time due to the nature of protocol upgrades,
> work-arounds, software upgrade via contacting key miners etc.  We
> could take an example of the openSSL bug.
>
> - 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?
>
> - Are you a member of the bitcoin security reporting list?
>
> On 15 June 2015 at 11:56, Mike Hearn <mike@plan99.net> wrote:
> > I will review both and mostly delegate to Gavin's good taste around the
> > details, unless there is some very strong disagreement. But that seems
> > unlikely.
> > ...
> > Feedback will be read. There are no NACKS in Bitcoin XT. Patch requests
> > aren't scored in any way. The final decision rests with the maintainer
> as in
> > ~all open source projects.
>
> As you know the people who have written 95% of the code (and reviewed,
> and tested, and formally proved segments etc) are strenuously advising
> not to push any consensus code into public use without listening to
> and addressing review questions which span beyond rigorous code &
> automated guided fuzz testers, simulation and sometimes formal proofs,
> but also economics, game-theory and critically very subtle
> determinism/consensus safety that they have collectively 4-5 years
> experience of each.
>
> - Will you pause your release plans if all of the other developers
> insist that the code or algorithm is defective?
>
> - Please don't take this the wrong way, and I know your bitcoinj work
> was a significant engineering project which required porting bitcoin
> logic.  But If the answer to the above question is no, as you seemed
> to indicate in your response, as you not have not written much bitcoin
> core code yourself (I think 3 PRs in total), do you find yourself more
> qualified than the combination of peer review of the group of people
> who have written 95% of it, and maintained it and refactored most of
> it over the last 4-5 years?
>
> I presume from your security background you are quite familiar with
> the need for review of crypto protocol changes & rigorous code review.
> That is even more the case with Bitcoin given the consensus
> criticality.
>
> >> - On the idea of a non-consensus hard-fork at all, I think we can
> >> assume you will get a row of NACKs.  Can you explain your rationale
> >> for going ahead anyway?  The risks are well understood and enormous.
> >
> > If Bitcoin runs out of capacity it will break and many of our users will
> > leave. That is not an acceptable outcome for myself or the many other
> > wallet, service and merchant developers who have worked for years to
> build
> > an ecosystem around this protocol.
>
> That you are frustrated, is not a sufficient answer as to why you are
> proposing to go ahead with a universally acknowledged extreme network
> divergence danger unilateral hard-fork, lacking wide-spread consensus.
> People are quite concerned about this.  Patience, caution and prudence
> is necessary in a software system with such high assurance
> requirements.
>
> So I ask again:
>
> - On the idea of a non-consensus hard-fork at all, I think we can
> assume you will get a row of NACKs.  Can you explain your rationale
> for going ahead anyway?  The risks are well understood and enormous.
>
> Note the key point is that you are working on a unilateral hard-fork,
> where there is a clear 4 year established process for proposing
> improvements and an extremely well thought out and important change
> management governance process.  While there has been much discussion,
> you nor Gavin, have not actually posted a BIP for review.  Nor
> actually was much of the discussion even conducted in the open: it was
> only when Matt felt the need to clear the air and steer this
> conversation into the open that discussion arose here.  During that
> period of private discussion you and Gavin were largely unknown to
> most of us lobbying companies with your representation of a method
> that concerns everyone of the Bitcoin users.  Now that the technical
> community aware aware they are strenuously discouraging you on the
> basis of risks.
>
>
> Openness
>
> - Do you agree that bitcoin technical discussions should happen in the
> open?
>
> - As this is a FOSS project, do you agree that companies should also
> be open, about their requirements and trade-offs they would prefer?
>
> - Can you disclose the list of companies you have lobbied in private
> whether they have spoken publicly or not, and whether they have
> indicated approval or not?
>
> - Did you share a specific plan, like a BIP or white paper with these
> companies, and if so can we see it?
>
> - If you didnt submit a plan, could you summarise what you asked them
> and what you proposed, and if you discussed also the risks?  (If you
> asked them if they would like Bitcoin to scale, I expect almost
> everyone does, including every member of the technical community, so
> that for example would not fairly indicate approval for a unilateral
> hard-fork)
>
> I and others will be happy to talk with the CTO and CEOs of companies
> you have lobbied in private, for balance to assure ourselves and the
> rest of the community that their support was given - and with full
> understanding of the risks of doing it unilaterally, without peer
> review, benefit of maintenance and security inidence management, and
> what exactly they are being quoting as having signed up for.
>
> (This maybe more efficiently and openly achieved by the open process,
> on a mailing list, maybe a different one even special purpose to this
> topic, with additional option of the open public meeting I proposed at
> the top).
>
> - Do you agree that it would be appropriate, that companies be aware
> of both the scaling opportunities (of course, great everyone wants
> scalability) as well as the technical limits and risks with various
> approaches?  And that these be presented by parties from a range of
> views to ensure balance?
>
> - Do you consider your expression of issues to hold true to the ideal
> of representing balanced nuanced view of all sides of a technical
> debate, even when under pressure or feeling impatient about the
> process?
>
> You may want to review the opening few minutes of your epicenter 82
> bitcoin for example where you claimed and I quote "[the rest of the
> technical community] dont want capacity to ever increase and want it
> to stay where it is and when it fills up people move to other
> systems".
>
> - Do you think that is an accurate depiction of the complex trade-offs
> we have been discussing on this list?
>
> (For the record I am not aware of a single person who has said they do
> not agree with scaling Bitcoin.  Changing a constant is not the
> hard-part.  The hard part is validating a plan and the other factors
> that go into it.  It's not a free choice it is a security/scalability
> tradeoff.  No one will thank us if we "scale" bitcoin but break it in
> hard to recover ways at the same time.)
>
> - Were you similarly balanced in your explanations when talking to
> companies in private discussions?
>
> - Do you understand that if we do not work from balanced technical
> discussion, that we may end up with some biased criteria?
>
> Authority
>
> Neither you nor Gavin have any particular authority here to speak on
> behalf of Bitcoin (eg you acknowledge in your podcast that Wladimir is
> dev lead, and you and Gavin are both well aware of the 4 year
> established change management consensus decision making model where
> all of the technical reviewers have to come to agreement before
> changes go in for security reasons explained above).  I know Gavin has
> a "Chief Scientist" title from the Bitcoin Foundation, but sadly that
> organisation is not held in as much regard as it once was, due to
> various irregularities and controversies, and as I understand it no
> longer employs any developers, due to lack of funds.  Gavin is now
> employed by MIT's DCI project as a researcher in some capacity.  As
> you know Wladimir is doing the development lead role now, and it seems
> part of your personal frustration you said was because he did not
> agree with your views.  Neither you nor Gavin have been particularly
> involved in bitcoin lately, even Gavin, for 1.5 years or so.
>
> - Do you agree that if you presume to speak where you do not have
> authority you may confuse companies?
>
> > If Bitcoin runs out of capacity it will break and many of our users will
> > leave. That is not an acceptable outcome for myself or the many other
> > wallet, service and merchant developers who have worked for years to
> build
> > an ecosystem around this protocol.
>
> But I think this is a false dichotomy.  As I said in previous mail I
> understand people are frustrated that it has taken so long, but it is
> not the case that no progress has been made on scalability.
>
> I itemised a long list of scalability work which you acknowledged as
> impressive work (CPU, memory, network bandwidth/latency) and RBF, CPFP
> fee work, fee-estimation, and so on, which you acknowledged and are
> aware of.
>
> There are multiple proposals and BIPs under consideration on the list
> right now.
>
> - what is the reason that you (or Gavin) would not post your BIP along
> side the others to see if it would win based on technical merit?
>
> - why would you feel uniquely qualified to override the expert opinion
> of the rest of the technical community if your proposal were not
> considered to have most technical merit? (Given that this is not a
> simple market competition thing where multiple hard-forks can be
> considered - it is a one only decision, and if it is done in a
> divisive unilateral way there are extreme risks of the ledger
> diverging.)
>
> Network Divergence Risk
>
> >> - How do you propose to deal with the extra risks that come from
> >> non-consensus hard-forks?  Hard-forks themselves are quite risky, but
> >> non-consensus ones are extremely dangerous for consensus.
> >
> > The approach is the same for other forks. Voting via block versions and
> then
> > when there's been >X% for Y time units the 1mb limit is lifted/replaced.
>
> But this is not a soft-fork, it is a hard-fork.  Miner voting is only
> peripherally related.  Even if in the extremis 75% of miners tried a
> unilateral hard-fork but 100% of the users stayed on the maintained
> original code, no change would occur other than those miners losing
> reward (mining fork-coins with no resale value) and the difficulty
> would adjust.  The miners who made an error in choice would lose money
> and go out of business or rejoin the chain.
>
> However if something in that direction happens with actual users and
> companies on both sides of it users will lose money, the ledger will
> diverge as soon as a single double-spend happens, and never share a
> block again, companies will go instantly insolvent, and chaos will
> break out.  This is the dangerous scenario we are concerned about.
>
> So the same question again:
>
> - How do you propose to deal with the extra risks that come from
> non-consensus hard-forks?  Hard-forks themselves are quite risky, but
> non-consensus ones are extremely dangerous for consensus.
>
>
> Being sensitive to alarming the market
>
> It is something akin to Greece or Portugal or Italy exiting the euro
> currency in a disorderly way.  Economists and central bank policy
> makers are extremely worried about such an eventuality and talk about
> related factors in careful, measured terms, watch Mario Draghi when he
> speaks.
>
> Imagine that bitcoin is 10x or 100x bigger.  Bitcoin cant have people
> taking unilateral actions such as you have been proposing.  It is not
> following the consensus governance process, and not good policy and it
> is probably affecting bitcoin confidence and price at this moment.
>
> >> - Do you have contingency plans for what to do if the non-consensus
> >> hard-fork goes wrong and $3B is lost as a result?
> >
> > Where did you get the $3B figure from? The fork either doesn't happen,
> or it
> > happens after quite a long period of people knowing it's going to happen
> -
> > for example because their full node is printing "You need to upgrade"
> > messages due to seeing the larger block version, or because they read the
> > news, or because they heard about it via some other mechanisms.
>
> This is not a soft-fork, and the community will not want to take the
> risks once they understand them, and they have months in which to
> understand them and at this point you've motivated and wasted 100s of
> developer man hours such that we will feel impelled to make sure that
> no one opts into a unilateral hard-fork without understanding the
> risks.  It would be negligent to allow people to do that.  Before this
> gets very far FAQs will be on bitcoin.org etc explaining this risk I
> would imagine.  Its just starting not finished.
>
> What makes you think the rest of the community may not instead prefer
> Jeff Garzik's BIP after revisions that he is making now with review
> comments from others?
>
> Or another proposal.  Taken together with a deployment plan that sees
> work on decentralisation tying into that plan.
>
> - If you persisted anyway, what makes you think bitcoin could not make
> code changes defensively relating to your unilateral fork?
> (I am sure creative minds can find some ways to harden bitcoin against
> a unilateral fork, with a soft-fork or non-consensus update can be
> deployed much faster than a hard-fork).
>
> I tried to warn Gavin privately that I thought he was under-estimating
> the risk of failure to his fork proposal due to it being unilateral.
> Ie as you both seem sincere in your wish to have your proposal
> succeed, then obviously the best way to do that is to release a BIP in
> the open collaborative process and submit it to review like everyone
> else.  Doing it unilaterally only increases its chance of failure.
>
> The only sensible thing to do here is submit a BIP and stop the
> unilateral fork threat.
>
> Scalability Plans
>
> > Let me flip the question around. Do you have a contingency plan if
> Bitcoin
> > runs out of capacity and significant user disruption occurs that results
> in
> > exodus, followed by fall in BTC price? The only one I've seen is "we can
> > perform an emergency hard fork in a few weeks"!
>
> Yes people have proposed other plans.  Bryan Bishop posted a list of them.
>
> Jeff Garzik has a proposal, BIP-100 which seems already better than
> Gavin's having benefit of peer review which he has been incorporating.
>
> I proposed several soft-fork models which can be deployed safely and
> immediately, which do not have ledger risk.
>
> I have another proposal relating to simplified soft-fork one-way pegs
> which I'll write up in a bit.
>
> I think there are still issues in Jeff's proposal but he is very open
> and collaborating and there maybe related but different proposals
> presently.
>
> >> As you can probably tell I think a unilateral fork without wide-scale
> >> consensus from the technical and business communities is a deeply
> >> inadvisable.
> >
> > Gavin and I have been polling many key players in the ecosystem. The
> > consensus you seek does exist. All wallet developers (except Lawrence),
> all
> > the major exchanges, all the major payment processors and many of the
> major
> > mining pools want to see the limit lifted (I haven't been talking to
> pools,
> > Gavin has).
>
> It does not seem to me that you understand the issue.  Of course they
> want to increase the scalability of bitcoin.  So does everyone else on
> this mailing list.
>
> That they would support that is obvious.  If you presented your
> unilateral action plan without explaining the risks too.
>
> I think I covered this further above.  If you would like to share the
> company list, or we can invite them to the proposed public physical
> meeting, I think it would be useful for them to have a balanced view
> of the ledger divergence risks, and alternative in-consensus proposals
> underway, as well as the governance risks, maintenance risks, security
> incident risks.
>
> Note that other people talk to companies too, as part of their day to
> day jobs, or from contacts from being in the industry.  You have no
> special authority or unique ability to talk with business people.  Its
> just that the technical community did not know you were busy doing
> that.
>
> I can not believe that any company that would listen to their CTO, CSO
> or failing that board would be ok with the risks implied by what you
> are proposing on full examination.
>
> > This notion that the change has no consensus is based on you polling the
> > people directly around you and people who like to spend all day on this
> > mailing list. It's not an accurate reflection of the wider Bitcoin
> community
> > and that is one of the leading reasons there is going to be a fork. A
> small
> > number of people have been flatly ignoring LOTS of highly technical and
> > passionate developers who have written vast amounts of code, built up the
> > Bitcoin user base, designed hardware and software, and yes built
> companies.
>
> I know you want scale bitcoin, as I said everyone here does. I think
> what you're experiencing is that you've had more luck explaining your
> pragmatic unilateral plan to non-technical people without peer review,
> and so not experienced the kind of huge pushback you are getting from
> the technical community.  The whole of bitcoin is immensely
> complicated such that it takes an uber-geek CS genius years to
> catchup, this is not a slight of any of the business people who are
> working hard to deploy Bitcoin into the world, its just complicated
> and therefore not easy to understand the game-theory, security,
> governance and distributed system thinking.  I have a comp sci PhD in
> distributed systems, implemented p2p network systems and have 2
> decades of applied crypto experience with a major interest in
> electronic cash crypto protocols, and it took me a several years to
> catchup and even I have a few hazy spots on low-level details, and I
> addictively into read everything I could find.  Realistically all of
> us are still learning, as bitcoin combines so many fields that it
> opens new possibilities.
>
> What I am expecting that yourself and Gavin are thinking is that
> you'll knock heads and force the issue and get to consensus.
>
> However I think you have seriously misjudged the risks and have not
> adequately explained them to companies you are talking with.  Indeed
> you do not fully seem to acknowledge the risks, nor to have a well
> thought out plan here of how you would actually manage it, nor the
> moral hazards of having a lone developer in hugely divisive
> circumstances in sole control of bitcoins running code.  Those are
> exactly the reasons for the code change governance process!
>
> Even though you are trying to help, the full result is you are not
> helping achieve anything by changing a constant and starting a
> unilateral hard-fork (not to trivialise the work of making a patch to
> do that).
>
> The work to even make the constant change be feasible was a result of
> 1000s of hours of work by others in the development community, that is
> emphatically and unilaterally telling you that hard-forks are hugely
> inadvisable.
>
> You are trying to break the code change governance security procedure
> that were put in place for good reason for the security of $3b of
> other peoples money, even if you have a pragmatic intent to help, this
> is flat out unacceptable.
>
> There are also security implications to what you are proposing, which
> I have heard you attempting to trivialise, that are core to Bitcoins
> security and core functionality.
>
> >  the overwhelming impression I get from a few
> > others here is that no, they don't want to scale Bitcoin. They already
> > decided it's a technological dead end.
>
> I think this is a significant mischaracterisation, and I think almost
> everybody is on board with a combination plan:
>
> 1. work to improve decentralisation (specific technical work already
> underway, and education)
> 2. create a plan to increase block-size in a slow fashion to not cause
> system shocks (eg like Jeff is proposing or some better variant)
> 3. work on actual algorithmic scaling
>
> In this way we can have throughput needed for scalability and security
> work to continue.
>
> As I said you can not scale a O(n^2) broadcast network by changing
> constants, you need algorithmic improvements.
>
> People are working on them already.  All of those 3 things are being
> actively worked on RIGHT NOW, and in the case of algorithmic scaling
> and improve decentralisation have been worked on for months.
>
> You may have done one useful thing which is to remind people that
> blocks are only 3x-4x below capacity such that we should look at it.
>
> But we can not work under duress of haste, nor unilateral ultimatums,
> this is the realm of human action that leads to moral hazard, and
> ironically reminds us of why Satoshi put the quote in the genesis
> block.
>
> Bitcoin is too complex a system with too much at stake to be making
> political hasty decisions, it would be negligent to act in such a way.
>
> Again please consider that you did your job, caused people to pay
> attention, but return to the process, submit a BIP, retract the
> unilateral hard-fork which is so dangerous and lets have things be
> calm, civil and collaborative in the technical zone of Bitcoin and not
> further alarm companies and investors.
>
> Adam
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 30069 bytes --]

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

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 2275 bytes --]

On Tue, Jun 16, 2015 at 08:33:31PM +0800, Pindar Wong wrote:
> On Tue, Jun 16, 2015 at 2:03 AM, Adam Back <adam@cypherspace.org> wrote:
> Dear Adam, All:
> 
> At the community's convenience, it would be an honour to arrange an initial
> open summit to meet with representatives of the Chinese miners in Hong Kong
> (UTC+8) to facilitate a better understand between the different
> stakeholders of the Bitcoin ecosystem on this important issue.   This could
> be arranged for this October, or earlier, if deemed necessary.

Great!

FWIW there Constance Choi and Primavera De Filippi (CC'd) are holding a
blockchain-tech conference October 14th-15th in Hong Kong as well;
coordinating your summit with that conference could be useful.

http://blockchainworkshops.org/

This workshop series has been attracting audiences of people looking to
use blockchain tech in general; many of these use-cases will likely
involve the Bitcoin blockchain in unpredictable ways. Importantly, these
ways can drive demand significantly beyond our current assumptions based
on most demand being consumer-merchant transactions.

In addition, many of the attendees have significant experience with
regulatory issues and interacting with governments on regulation of
blockchain tech. Bitcoin faces existential risks to its existence by
these regulation efforts, which include things like efforts to setup
industry wide Anti-Money-Laundering/Know-Your-Customer programs,
including programs that would tie on-chain transactions to identity
information. Any blocksize discussion needs to be informed by these
potential threats to usage of the technology, as well as challenges to
using scaling solutions.

> Remote online participation would be welcome from those who might not be
> able to attend in person.
> 
> However,  it is hoped that such a meeting would be primarily document
> driven to facilitate orderly translation, discussion and decision.

Agreed. Pieter Wuille's recent work is a great example of the kind of
science-driven investigations that need to be done - and haven't been
done very much - to get us some hard data to make decisions on.

-- 
'peter'[:-1]@petertodd.org
0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

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

[Pindar Wong]

[-- Attachment #1: Type: text/plain, Size: 2720 bytes --]

On Tue, Jun 16, 2015 at 9:33 PM, Peter Todd <pete@petertodd.org> wrote:

> On Tue, Jun 16, 2015 at 08:33:31PM +0800, Pindar Wong wrote:
> > On Tue, Jun 16, 2015 at 2:03 AM, Adam Back <adam@cypherspace.org> wrote:
> > Dear Adam, All:
> >
> > At the community's convenience, it would be an honour to arrange an
> initial
> > open summit to meet with representatives of the Chinese miners in Hong
> Kong
> > (UTC+8) to facilitate a better understand between the different
> > stakeholders of the Bitcoin ecosystem on this important issue.   This
> could
> > be arranged for this October, or earlier, if deemed necessary.
>
> Great!
>
> FWIW there Constance Choi and Primavera De Filippi (CC'd) are holding a
> blockchain-tech conference October 14th-15th in Hong Kong as well;
> coordinating your summit with that conference could be useful.
>
> http://blockchainworkshops.org/
>
> This workshop series has been attracting audiences of people looking to
> use blockchain tech in general; many of these use-cases will likely
> involve the Bitcoin blockchain in unpredictable ways. Importantly, these
> ways can drive demand significantly beyond our current assumptions based
> on most demand being consumer-merchant transactions.
>
> In addition, many of the attendees have significant experience with
> regulatory issues and interacting with governments on regulation of
> blockchain tech. Bitcoin faces existential risks to its existence by
> these regulation efforts, which include things like efforts to setup
> industry wide Anti-Money-Laundering/Know-Your-Customer programs,
> including programs that would tie on-chain transactions to identity
> information. Any blocksize discussion needs to be informed by these
> potential threats to usage of the technology, as well as challenges to
> using scaling solutions.
>
> > Remote online participation would be welcome from those who might not be
> > able to attend in person.
> >
> > However,  it is hoped that such a meeting would be primarily document
> > driven to facilitate orderly translation, discussion and decision.
>
> Agreed. Pieter Wuille's recent work is a great example of the kind of
> science-driven investigations that need to be done - and haven't been
> done very much - to get us some hard data to make decisions on.
>

Thank you very much Peter for pointing this out! That is very kind of you.

It would be great to work with Constance Choi, Primavera De Filippi, your
goodself and others to make this happen.

As you may know, the Hong Kong Monetary Authority considers bitcoin a
virtual 'commodity' and not a currency per se.

Regards,

p.


>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
>

[-- Attachment #2: Type: text/html, Size: 3759 bytes --]

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

[Troy Benjegerdes]

> - How do you propose to deal with the extra risks that come from
> non-consensus hard-forks?  Hard-forks themselves are quite risky, but
> non-consensus ones are extremely dangerous for consensus.

This is a non-issue.

If the hard-fork is not a consensus, then those of us that don't consent
ignore the fool that tried to hard-fork.

If a fool attempting a non-consensus hard-fork actually breaks something,
then you have a fragile system that needs some serious re-thinking.

I think a non-consensus hard-fork would be the best thing that could 
happen to the bitcoin ecosystem long-term, because it would force some
re-examination of some very bad assumptions.

-- 
----------------------------------------------------------------------------
Troy Benjegerdes                 'da hozer'                  hozer@hozed.org
7 elements      earth::water::air::fire::mind::spirit::soul        grid.coop

      Never pick a fight with someone who buys ink by the barrel,
         nor try buy a hacker who makes money by the megahash

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

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 5630 bytes --]

On Mon, Jun 15, 2015 at 09:00:19PM -0700, Aaron Voisine wrote:
> Thanks Alex, the work you've pointed out is helpful. Limiting mempool size
> should at least prevent nodes from crashing. When I looked a few days ago I
> only found a few old PRs that seemed to have fallen by the wayside, so this
> new one is encouraging.

BTW it's worth working out how many $ in fees you need for a given
amount of MB worth of mempool.

At the current 10uBTC/KB minimim relay fee 1MB of txs requires just $2.5
worth of fees - kinda ridiculous when a block earns a miner $6250 in
revenue. Pretty much all txs pay significantly higher rates - more like
100uBTC/KB, or $25/MB. At that rate the 288MB max mempool size proposed
by Patrick Strateman's pull-req requires at least $7.2k worth of BTC to
fill to pay the fees, and in practice will probably quickly get higher.

https://github.com/bitcoin/bitcoin/pull/6281

> I can respond in the PR comments if it's more appropriate there, but I
> believe ejecting tx from mempools rather than preemptively refusing them
> according to standard network wide propagation rules will result in spotty,
> inconsistent tx propagation, and possibly a large increase in tx
> re-broadcasts, so if those haven't been addressed they will need to be. It
> would also be prudent to run some simulations to see what other issues are
> going to pop-up.

See above - filling the mempool like that will be both a slow process,
and require lots of funds. Equally, once full, the sensible thing to do
is raise the minimum relay fee appropriately, so those transactions that
pay too low a fee will simply be rejected.

It'd be reasonable to tell peers that, and what the minimum fee needed
for acceptance would be for that particular node.

> We're currently using CPFP already in breadwallet when spending unconfirmed
> non-change inputs. A small percentage of hashing power is using it, but
> enough to get a transaction unstuck assuming breadwallet's fee calculation
> is better than the sender's.

> The problem with RBF is that there's currently no way to tell if your tx
> has been picked up by miners or not in order to know if you need to replace
> it. Miners broadcasting partial block solutions would be helpful in this
> regard, but only for tx in the currently-being-worked-on block, not for tx
> that won't be picked up until the block after. If miners were to eject tx
> that were previously being worked on in favor of higher fee tx, then that
> causes another set of problems for wallets that thought their tx was going
> to get in but then it doesn't. The other problem with RBF is that users
> don't know up front what fee they're actually going to pay which is a big
> blow to real world usability. Also mobile wallets will have to sign lots of
> tx up front and rely on a service to replace as necessary. And this is all
> just on the send side.

For an interactive, mobile wallet, the best thing to do is estimate the
fee correctly the first time, using RBF as a follow up mechanism only if
needed. For other users - e.g. exchanges handling customer withdrawals -
using RBF more agressively to get the minimum possible fee may make
sense.

> On the receive side it's much worse since you can't
> rely on the sender to do the replacing. The real problem seems to be the
> fact that RBF is an interactive iterative process rather than a
> send-and-forget one.

In any case, the *existance* of RBF makes no difference to any of these
problems; RBF does make solving the easier. You can always choose to not
use it after all, resulting in the same "send-and-forget" process.
Having it available allows mistakes to be fixed after the fact, always
an improved user experience over not being able to re-bid for block
space.


Incidentally, if my FSS-RBF bug bounty isn't collected in the next week
or two, we'll likely have a major double-digits % of hashing power
mining FSS-RBF soon after.

http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08122.html

> What you really need is some way to tell up-front, is a transaction going
> to get mined with a high probability? That problem seems really difficult
> to solve with fixed-size blocks that are full.

Have you looked at the fee estimation code in Bitcoin Core? I have no
reason to think it doesn't basically speaking work. Of course, SPV
wallets will need a semi-trusted third party to securely get that data,
but this seems to be a fundemental problem in a decentralized network -
the purpose of the blockchain itself is to prove that some data was
published to some audience, an analogous problem to proving to the SPV
wallet that their transaction actually reached miners and they actually
are considering it for inclusion.

Guaranteed reliable transaction processing is only possible in
centralized environments that can make service guarantees.

> If the goal is simply to
> reduce or limit the growth of the blockchain, then there are much simpler
> solutions, which is why I've advocated for the blocksize increase, followed
> by tx selection and propagation rule changes to create fee pressure.

Few if any of those mechanisms can be deployed in a consensus-critical
way that is resistant to attack; the blocksize limit is needed to -
among other things - resist attacks by one miner on another to reduce
the competitors profitability. Without an explicit limit tx selection
and propagation rule changes can be gamed.

-- 
'peter'[:-1]@petertodd.org
0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

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

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1323 bytes --]

On Tue, Jun 16, 2015 at 09:55:13PM +0800, Pindar Wong wrote:
> > Agreed. Pieter Wuille's recent work is a great example of the kind of
> > science-driven investigations that need to be done - and haven't been
> > done very much - to get us some hard data to make decisions on.
> >
> 
> Thank you very much Peter for pointing this out! That is very kind of you.
> 
> It would be great to work with Constance Choi, Primavera De Filippi, your
> goodself and others to make this happen.

Great! They're excited to see this happen. I'm in London right now
actually for the conference they were holding this week; the blocksize
issue was being discussed a fair bit there among attendees. (notably,
with rather different views than seen on reddit!)

> As you may know, the Hong Kong Monetary Authority considers bitcoin a
> virtual 'commodity' and not a currency per se.

Yup, though keep in mind the regulatory question is more than just how
your local jurisdiction views Bitcoin, but rather how your customers'
jurisdictions view Bitcoin.

Of course, when I say "customers" above, I mean the entire Bitcoin
community that is ultimately buying the new coins produced by miners and
paying fees to them!

-- 
'peter'[:-1]@petertodd.org
0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

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

[Jorge Timón]

[-- Attachment #1.1: Type: text/plain, Size: 6898 bytes --]

On Tue, Jun 16, 2015 at 2:08 AM, Aaron Voisine <voisine@gmail.com> 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 <voisine@gmail.com> 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 <brianchoffman@gmail.com>
> 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 <faizkhan00@gmail.com> 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 <kanzure@gmail.com> wrote:
>>
>>> On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn <mike@plan99.net> 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 requests to Bitcoin Core, so therefore Mike is a
>>> non-programmer". Communication is difficult and I can understand that, but
>>> we really have to be more careful when evaluating each other's messages;
>>> technical miscommunication can be catastrophic in this context. On the
>>> topic of whether you are a programmer, I suspect that ever since you built
>>> CIA.vc we have all known you're a programmer, Mike.
>>>
>>> - 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
>>>
>>> --
>>>
>>> My regards,
>>>
>>> Faiz Khan
>>>
>>>  <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #1.2: Type: text/html, Size: 10246 bytes --]

[-- Attachment #2: image1.JPG --]
[-- Type: image/jpeg, Size: 22107 bytes --]

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

[Pindar Wong]

[-- Attachment #1: Type: text/plain, Size: 2209 bytes --]

On Wed, Jun 17, 2015 at 11:59 AM, Peter Todd <pete@petertodd.org> wrote:

> On Tue, Jun 16, 2015 at 09:55:13PM +0800, Pindar Wong wrote:
> > > Agreed. Pieter Wuille's recent work is a great example of the kind of
> > > science-driven investigations that need to be done - and haven't been
> > > done very much - to get us some hard data to make decisions on.
> > >
> >
> > Thank you very much Peter for pointing this out! That is very kind of
> you.
> >
> > It would be great to work with Constance Choi, Primavera De Filippi, your
> > goodself and others to make this happen.
>
> Great! They're excited to see this happen. I'm in London right now
> actually for the conference they were holding this week; the blocksize
> issue was being discussed a fair bit there among attendees. (notably,
> with rather different views than seen on reddit!)
>
> > As you may know, the Hong Kong Monetary Authority considers bitcoin a
> > virtual 'commodity' and not a currency per se.
>
> Yup, though keep in mind the regulatory question is more than just how
> your local jurisdiction views Bitcoin, but rather how your customers'
> jurisdictions view Bitcoin.
>
> Of course, when I say "customers" above, I mean the entire Bitcoin
> community that is ultimately buying the new coins produced by miners and
> paying fees to them!
>

I'm sorry for the distraction with the mailing list problems.

Taking an ecosystem view, the miners are important, so are all the other
participants who rely on it and  invest time, effort and energy to make
Bitcoin work and work well.

I am in contact with Primavera and it would appear that the Cyberport is
available for use on October 14 and 15 (Wed/Thursday).

Last November, this was where the Global Bitcoin Summit (Hong Kong)
<http://www.cyberport.hk/en/about_cyberport/our_5_centres/collaboration_centre/collaboration_news/2146>
was hosted with the participation of many of China's leading
Bitcoin-related companies. There is a meeting now in Shanghai.

It would be an honour to host a more technical meeting to discuss BIP100,
101 et al. should be interest to do so.

p.


>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
>

[-- Attachment #2: Type: text/html, Size: 3136 bytes --]

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

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1689 bytes --]

On Thu, Jun 25, 2015 at 02:43:19PM +0800, Pindar Wong wrote:
> > Yup, though keep in mind the regulatory question is more than just how
> > your local jurisdiction views Bitcoin, but rather how your customers'
> > jurisdictions view Bitcoin.
> >
> > Of course, when I say "customers" above, I mean the entire Bitcoin
> > community that is ultimately buying the new coins produced by miners and
> > paying fees to them!
> >
> 
> I'm sorry for the distraction with the mailing list problems.
> 
> Taking an ecosystem view, the miners are important, so are all the other
> participants who rely on it and  invest time, effort and energy to make
> Bitcoin work and work well.

Agreed.

IMO any change to the blocksize needs explicit mechanisms to let all
Bitcoin holders have a say in it.

> I am in contact with Primavera and it would appear that the Cyberport is
> available for use on October 14 and 15 (Wed/Thursday).

Great! Glad to hear.

> Last November, this was where the Global Bitcoin Summit (Hong Kong)
> <http://www.cyberport.hk/en/about_cyberport/our_5_centres/collaboration_centre/collaboration_news/2146>
> was hosted with the participation of many of China's leading
> Bitcoin-related companies. There is a meeting now in Shanghai.
> 
> It would be an honour to host a more technical meeting to discuss BIP100,
> 101 et al. should be interest to do so.

Are you thinking this more technical meeting should be before or after
the October event? Perhaps a better question, is what exactly do you see
being discussed at a technical meeting?

-- 
'peter'[:-1]@petertodd.org
0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]