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

[Jorge Timón]

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


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

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

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

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

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

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

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

[Peter Todd]

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


signature.asc
Description: Digital signature
--
___
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

[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'  ho...@hozed.org
7 elements  earth::water::air::fire::mind::spirit::soulgrid.coop

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


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

[Peter Todd]

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 

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

[Pindar Wong]

On Tue, Jun 16, 2015 at 9:33 PM, Peter Todd  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  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
> 127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
>
--
___
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

[Peter Todd]

On Tue, Jun 16, 2015 at 08:33:31PM +0800, Pindar Wong wrote:
> On Tue, Jun 16, 2015 at 2:03 AM, Adam Back  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
127ab1d576dc851f374424f1269c4700ccaba2c42d97e778


signature.asc
Description: Digital signature
--
___
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

[Pindar Wong]

On Tue, Jun 16, 2015 at 2:03 AM, Adam Back  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 d

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

[Mike Hearn]

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

[Mike Hearn]

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

On Tue, Jun 16, 2015 at 6:18 AM, Venzen  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.
--
___
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

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

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

[Marcel Jamin]

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

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

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 fo

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

[Aaron Voisine]

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

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

[Eric Lombrozo]

> On Jun 15, 2015, at 3:54 PM, odinn  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


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

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

[Alex Morcos]

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

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

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

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

[Mark Friedenbach]

On Mon, Jun 15, 2015 at 5:08 PM, Aaron Voisine  wrote:

> Wasn't the XT hard fork proposed as a last resort, should the bitcoin-core
> maintainers simply refuse to lift the 1Mb limit? No one wants to go that
> route. An alternate hard-fork proposal like BIP100 that gets consensus, or
> a modified version of gavin's that ups the limit to 8Mb instead of 20Mb, or
> hell even some major changes to the non-consunsus code to make it
> adequately handle the situation when blocks fill up, and allow wallet
> software to continue working with a send-and-forget use pattern, any of
> these would be enough to avoid the need for an XT only hard-fork.
>
> So far BIP100 is the only one that seems to actually be getting any sort
> of momentum toward consensus, and it was proposed... 2 days ago? When the
> XT fork was proposed as a last resort, it was when the opponents were (to
> my understanding) suggesting we just let blocks fill up, and hopefully
> things would just work out on their own.
>

We are not reaching consensus about any proposal, Garzik's or otherwise.
--
___
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

[Aaron Voisine]

Wasn't the XT hard fork proposed as a last resort, should the bitcoin-core
maintainers simply refuse to lift the 1Mb limit? No one wants to go that
route. An alternate hard-fork proposal like BIP100 that gets consensus, or
a modified version of gavin's that ups the limit to 8Mb instead of 20Mb, or
hell even some major changes to the non-consunsus code to make it
adequately handle the situation when blocks fill up, and allow wallet
software to continue working with a send-and-forget use pattern, any of
these would be enough to avoid the need for an XT only hard-fork.

So far BIP100 is the only one that seems to actually be getting any sort of
momentum toward consensus, and it was proposed... 2 days ago? When the XT
fork was proposed as a last resort, it was when the opponents were (to my
understanding) suggesting we just let blocks fill up, and hopefully things
would just work out on their own.



Aaron Voisine
co-founder and CEO
breadwallet.com

On Mon, Jun 15, 2015 at 3:56 PM, Brian Hoffman 
wrote:

> Who is actually planning to move to Bitcoin-XT if this happens?
>
> Just Gavin and Mike?
>
> [image: image1.JPG]
>
> On Jun 15, 2015, at 6:17 PM, Faiz Khan  wrote:
>
> I'm quite puzzled by the response myself, it doesn't seem to address some
> of the (more serious) concerns that Adam put out, the most important
> question that was asked being the one regarding personal ownership of the
> proposed fork:
>
> "How do you plan to deal with security & incident response for the
> duration you describe where you will have control while you are deploying
> the unilateral hard-fork and being in sole maintainership control?"
>
> I do genuinely hope that whomever (now and future) wishes to fork the
> protocol reconsider first whether they are truly ready to test/flex their
> reputation/skills/resources in this way... Intuitively, to me it seems
> counterproductive, and I don't fully believe it is within a single
> developer's talents to manage the process start-to-finish (as it is
> non-trivial to hard-fork successfully, others have rehashed this in other
> threads)...
>
> That being said I think it appropriate if Adam's questions were responded
> in-line when Mike is feeling up to it. I think that the answers are
> important for the community to hear when such a drastic change is being
> espoused.
>
> Faiz
>
> On Mon, Jun 15, 2015 at 4:56 PM, Bryan Bishop  wrote:
>
>> On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn  wrote:
>>
>>> Re: anyone who agrees with noted non-programmers Mike&Gavin must be
>>> non-technical, stupid, uninformed, etc  OK, go ahead and show them the
>>> error of their ways. Anyone can write blogs.
>>>
>>
>> I worry that if this is the level of care you take with reading and
>> (mis)interpreting Adam's messages, that you might not be taking extreme
>> care with evaluating consensus changes, even while tired or sleeping. I
>> encourage you to evaluate both messages and source code more carefully,
>> especially in the world of bitcoin. However, this goes for everyone and not
>> just you. Specifically, when Adam mentioned your conversations with
>> non-technical people, he did not mean "Mike has talked with people who have
>> possibly not made pull 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
>
>
--
___
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

[Raystonn .]

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


  I'm quite puzzled by the response myself, it doesn't seem to address some of 
the (more serious) concerns that Adam put out, the most important question that 
was asked being the one regarding personal ownership of the proposed fork: 

  "How do you plan to deal with security & incident response for the duration 
you describe where you will have control while you are deploying the unilateral 
hard-fork and being in sole maintainership control?"

  I do genuinely hope that whomever (now and future) wishes to fork the 
protocol reconsider first whether they are truly ready to test/flex their 
reputation/skills/resources in this way... Intuitively, to me it seems 
counterproductive, and I don't fully believe it is within a single developer's 
talents to manage the process start-to-finish (as it is non-trivial to 
hard-fork successfully, others have rehashed this in other threads)... 

  That being said I think it appropriate if Adam's questions were responded 
in-line when Mike is feeling up to it. I think that the answers are important 
for the community to hear when such a drastic change is being espoused. 

  Faiz

  On Mon, Jun 15, 2015 at 4:56 PM, Bryan Bishop  wrote:

On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn  wrote:

  Re: anyone who agrees with noted non-programmers Mike&Gavin must be 
non-technical, stupid, uninformed, etc  OK, go ahead and show them the 
error of their ways. Anyone can write blogs.

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

[Brian Hoffman]

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  wrote:
> 
> I'm quite puzzled by the response myself, it doesn't seem to address some of 
> the (more serious) concerns that Adam put out, the most important question 
> that was asked being the one regarding personal ownership of the proposed 
> fork:
> 
> "How do you plan to deal with security & incident response for the duration 
> you describe where you will have control while you are deploying the 
> unilateral hard-fork and being in sole maintainership control?"
> 
> I do genuinely hope that whomever (now and future) wishes to fork the 
> protocol reconsider first whether they are truly ready to test/flex their 
> reputation/skills/resources in this way... Intuitively, to me it seems 
> counterproductive, and I don't fully believe it is within a single 
> developer's talents to manage the process start-to-finish (as it is 
> non-trivial to hard-fork successfully, others have rehashed this in other 
> threads)... 
> 
> That being said I think it appropriate if Adam's questions were responded 
> in-line when Mike is feeling up to it. I think that the answers are important 
> for the community to hear when such a drastic change is being espoused. 
> 
> Faiz
> 
>> On Mon, Jun 15, 2015 at 4:56 PM, Bryan Bishop  wrote:
>>> On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn  wrote:
>>> Re: anyone who agrees with noted non-programmers Mike&Gavin must be 
>>> non-technical, stupid, uninformed, etc  OK, go ahead and show them the 
>>> error of their ways. Anyone can write blogs.
>> 
>> I worry that if this is the level of care you take with reading and 
>> (mis)interpreting Adam's messages, that you might not be taking extreme care 
>> with evaluating consensus changes, even while tired or sleeping. I encourage 
>> you to evaluate both messages and source code more carefully, especially in 
>> the world of bitcoin. However, this goes for everyone and not just you. 
>> Specifically, when Adam mentioned your conversations with non-technical 
>> people, he did not mean "Mike has talked with people who have possibly not 
>> made pull 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

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 

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

[Faiz Khan]

I'm quite puzzled by the response myself, it doesn't seem to address some
of the (more serious) concerns that Adam put out, the most important
question that was asked being the one regarding personal ownership of the
proposed fork:

"How do you plan to deal with security & incident response for the duration
you describe where you will have control while you are deploying the
unilateral hard-fork and being in sole maintainership control?"

I do genuinely hope that whomever (now and future) wishes to fork the
protocol reconsider first whether they are truly ready to test/flex their
reputation/skills/resources in this way... Intuitively, to me it seems
counterproductive, and I don't fully believe it is within a single
developer's talents to manage the process start-to-finish (as it is
non-trivial to hard-fork successfully, others have rehashed this in other
threads)...

That being said I think it appropriate if Adam's questions were responded
in-line when Mike is feeling up to it. I think that the answers are
important for the community to hear when such a drastic change is being
espoused.

Faiz

On Mon, Jun 15, 2015 at 4:56 PM, Bryan Bishop  wrote:

> On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn  wrote:
>
>> Re: anyone who agrees with noted non-programmers Mike&Gavin must be
>> non-technical, stupid, uninformed, etc  OK, go ahead and show them the
>> error of their ways. Anyone can write blogs.
>>
>
> I worry that if this is the level of care you take with reading and
> (mis)interpreting Adam's messages, that you might not be taking extreme
> care with evaluating consensus changes, even while tired or sleeping. I
> encourage you to evaluate both messages and source code more carefully,
> especially in the world of bitcoin. However, this goes for everyone and not
> just you. Specifically, when Adam mentioned your conversations with
> non-technical people, he did not mean "Mike has talked with people who have
> possibly not made pull 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

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

[Bryan Bishop]

On Mon, Jun 15, 2015 at 3:55 PM, Mike Hearn  wrote:

> Re: anyone who agrees with noted non-programmers Mike&Gavin must be
> non-technical, stupid, uninformed, etc  OK, go ahead and show them the
> error of their ways. Anyone can write blogs.
>

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

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

[Mike Hearn]

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

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

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

[Mike Hearn]

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 e