Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id F24C23EE for ; Mon, 17 Aug 2015 15:07:44 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f41.google.com (mail-pa0-f41.google.com [209.85.220.41]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 521401F2 for ; Mon, 17 Aug 2015 15:07:43 +0000 (UTC) Received: by pawq9 with SMTP id q9so12754192paw.3 for ; Mon, 17 Aug 2015 08:07:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=yDLWY2PdT8sMDXAUY+s8SDyjeTk2Fv7TMgguc1oV/wk=; b=ppDYLeMYD1ocKFkDSMuMN9F67ATVsxta0DuyAaen1jmCgIsg+Rmr57SgHgBHyVfgfO SY/5rZmJwS1UHZdp+QOuQUmAp/nG44nPk2qHS9UnTpO4cAN1+rgmp7DyFIe9Xx88F0Ux zGQQooTEgFyRVcqfB5En8PBCtI8tEYiJtwMLsn8wv0+hniHYgD9s8B6cMB9kvJiXqP1p I2+wg2H4HohkaZmpBGhv50xvdwiD5MoVzXgShir/ZyMWmsj16Iqt4JVkEQZi0JWh0QFQ SuUXkoV+Q2KbPfpvYjl2HZCx8G7536l+5bvRwLHUE94QXexqKIRF5nMZjh26bPb/FXee IbXw== X-Received: by 10.69.26.38 with SMTP id iv6mr3497791pbd.151.1439824062937; Mon, 17 Aug 2015 08:07:42 -0700 (PDT) Received: from [192.168.1.107] (cpe-76-167-237-202.san.res.rr.com. [76.167.237.202]) by smtp.gmail.com with ESMTPSA id y2sm15032547pdp.0.2015.08.17.08.07.41 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 17 Aug 2015 08:07:42 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_32B82850-82F1-44D6-BCE1-71B23C6CC02D"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5 From: Eric Lombrozo In-Reply-To: Date: Mon, 17 Aug 2015 08:07:39 -0700 Message-Id: <1FE73D1F-E984-4662-AB2D-9799CAF1A3CD@gmail.com> References: <20150817100918.BD1F343128@smtp.hushmail.com> <1439815244.89850.YahooMailBasic@web173102.mail.ir2.yahoo.com> <20150817133438.DDD4243128@smtp.hushmail.com> <64C86292-6671-4729-8A77-63C081797F62@gmail.com> To: Levin Keller X-Mailer: Apple Mail (2.2098) X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, MIME_QP_LONG_LINE, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Annoucing Not-BitcoinXT X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2015 15:07:45 -0000 --Apple-Mail=_32B82850-82F1-44D6-BCE1-71B23C6CC02D Content-Type: multipart/alternative; boundary="Apple-Mail=_F433E8DB-8A0B-4FF8-9B5A-A8A6A4A9FC3E" --Apple-Mail=_F433E8DB-8A0B-4FF8-9B5A-A8A6A4A9FC3E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Aug 17, 2015, at 8:03 AM, Levin Keller wrote: >=20 > Dear Eric, >=20 > thank you for sharing your thoughts. >=20 > It obviously boils down to political beliefs, not so much technical = arguments. I understand that you are in favor of a "guided = decentralization" and you are most happily invited to follow this path. = I don't want to be on it. I want total decentralisation of bitcoin and = many other parts of the current system. I specifically asked you to stop misrepresenting - I=E2=80=99m NOT in = favor of guided decentralization, I never said anything like that. = *THIS* is the problem=E2=80=A6you=E2=80=99re reading intentions into = others that simply are NOT there. If you don=E2=80=99t really understand = something, ask. I want complete decentralization - but for practical reasons, which = should be obvious, we cannot start at this point. Bitcoin came into = existence because Satoshi wrote a whitepaper and implemented the idea - = and it was his rules. There was no voting, no committee, no = proof-of-work, no nothing=E2=80=A6it was a complete dictatorship in the = beginning. >=20 > So in the end the hard fork might be perfect, because people like you = will not waste so much more energy and time fighting people like me (and = others) who are following different dogmata because we are using = different coins and talking about different code. Interestingly enough = in the end we will probably have a winner - determined by the price - so = I am looking forward to the outcome. It is just the time so make some = bets, which I embrace. >=20 > Another interesting thing is, that you actually fear problems arising = from this. What do you have to loose? Just stick with the old bitcoin = version and weather this storm. Bitcoin is not going to vanish or break = from this. It is just forking. One fork will come stronger out of this. = You just have to choose a side and live with it, if you loose it all. = But that is the story of bitcoin since the beginning. If you ask me, you = fear the choice, not the change. >=20 Again, misrepresentation - =E2=80=9Cyou fear the choice, not the = change=E2=80=9D - why should anyone ask *you* what I fear? Why don=E2=80=99= t you ask *me*? > Cheers >=20 > Levin >=20 > Adam Back via bitcoin-dev > schrieb am Mo., 17. Aug. = 2015 um 16:37 Uhr: > Thank you Eric for saying what needs to be said. >=20 > Starting a fork war is just not constructive and there are multiple > proposals being evaluated here. >=20 > I think that one thing that is not being so much focussed on is > Bitcoin-XT is both a hard-fork and a soft-fork. It's a hard-fork on > Bitcoin full-nodes, but it is also a soft-fork attack on Bitcoin core > SPV nodes that did not opt-in. It exposes those SPV nodes to loss in > the likely event that Bitcoin-XT results in a network-split. >=20 > The recent proposal here to run noXT (patch to falsely claim to mine > on XT while actually rejecting it's blocks) could add enough > uncertainty about the activation that Bitcoin-XT would probably have > to be aborted. >=20 > Adam >=20 > On 17 August 2015 at 15:03, Eric Lombrozo via bitcoin-dev > > wrote: > > NxtChg, > > > > In the entire history of Bitcoin we=E2=80=99ve never attempted = anything even closely resembling a hard fork like what=E2=80=99s being = proposed here. > > > > Many of us have wanted to push our own hard-forking changes to the = protocol=E2=80=A6and have been frustrated because of the inability to do = so. > > > > This inability is not due to any malice on anyone=E2=80=99s = part=E2=80=A6it is a feature of Satoshi=E2=80=99s protocol. For better = or worse, it is *very hard* to change the rules=E2=80=A6and this is = exactly what imbues Bitcoin with one of its most powerful attributes: = very well-defined settlement guarantees that cannot be suddenly altered = nor reversed by anyone. > > > > We=E2=80=99ve managed to have a few soft forks in the past=E2=80=A6and= for the most part these changes have been pretty uncontroversial=E2=80=A6= or at least, they have not had nearly the level of political = divisiveness that this block size issue is having. And even then, = we=E2=80=99ve encountered a number of problems with these deployments = that have at times required goodwill cooperation between developers and = mining pool operators to fix. > > > > Again, we have NEVER attempted anything even remotely like what=E2=80=99= s being proposed - we=E2=80=99ve never done any sort of hard fork before = like this. If even fairly uncontroversial soft forks have caused = problems, can you imagine the kinds of potential problems that a hard = fork over some highly polarizing issue might raise? Do you really think = people are going to want to cooperate?!? > > > > I can understand that some people would like bigger blocks. Other = people might want feature X, others feature Y=E2=80=A6and we can argue = the merits of this or that to death=E2=80=A6but the fact remains that we = have NEVER attempted any hard forking change=E2=80=A6not even with a = simple, totally uncontroversial no-brainer improvement that would not = risk any sort of ill-will that could hamper remedies were it not to go = as smoothly as we like. *THIS* is the fundamental problem - the whole = bigger block thing is a minor issue by comparison=E2=80=A6it could be = any controversial change, really. > > > > Would you want to send your test pilots on their first flight=E2=80=A6= the first time an aircraft is ever flown=E2=80=A6directly into combat = without having tested the plane? This is what attempting a hard fork = mechanism that=E2=80=99s NEVER been done before in such a politically = divisive environment basically amounts to=E2=80=A6but it=E2=80=99s even = worse. We=E2=80=99re basically risking the entire air force (not just = one plane) over an argument regarding how many seats a plane should have = that we=E2=80=99ve never flown before. > > > > We=E2=80=99re talking billlions of dollars=E2=80=99 worth of other = people=E2=80=99s money that is on the line here. Don=E2=80=99t we owe it = to them to at least test out the system on a far less controversial, far = less divisive change first to make sure we can even deploy it without = things breaking? I don=E2=80=99t even care about the merits regarding = bigger blocks vs. smaller blocks at this point, to be quite honest - = that=E2=80=99s such a petty thing compared to what I=E2=80=99m talking = about here. If we attempt a novel hard-forking mechanism that=E2=80=99s = NEVER been attempted before (and which as many have pointed out is = potentially fraught with serious problems) on such a politically = divisive, polarizing issue, the result is each side will refuse to = cooperate with the other out of spite=E2=80=A6and can easily lead to a = war, tanking the value of everyone=E2=80=99s assets on both chains. All = so we can process 8 times the number of transactions we currently do? = Even if it were 100 times, we wouldn=E2=80=99t even come close to = touching big payment processors like Visa. It=E2=80=99s hard to imagine = a protocol improvement that=E2=80=99s worth the risk. > > > > I urge you to at least try to see the bigger picture here=E2=80=A6and = to understand that nobody is trying to stop anyone from doing anything = out of some desire for maintaining control - NONE of us are able to = deploy hard forks right now without facing these problems. And different = people obviously have different priorities and preferences as to which = of these changes would be best to do first. This whole XT thing is = essentially giving *one* proposal special treatment above those that = others have proposed. Many of us have only held back from doing this out = of our belief that goodwill amongst network participants is more = important than trying to push some pet feature some of us want. > > > > Please stop this negativity - we ALL want the best for Bitcoin and = are doing our best, given what we understand and know, to do what=E2=80=99= s right. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org = > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev = --Apple-Mail=_F433E8DB-8A0B-4FF8-9B5A-A8A6A4A9FC3E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Aug 17, 2015, at 8:03 AM, Levin Keller <post@levinkeller.de>= wrote:

Dear Eric,

thank you for sharing your thoughts.

It obviously boils down to political = beliefs, not so much technical arguments. I understand that you are in = favor of a "guided decentralization" and you are most happily invited to = follow this path. I don't want to be on it. I want total = decentralisation of bitcoin and many other parts of the current = system.

I = specifically asked you to stop misrepresenting - I=E2=80=99m NOT in = favor of guided decentralization, I never said anything like that. = *THIS* is the problem=E2=80=A6you=E2=80=99re reading intentions into = others that simply are NOT there. If you don=E2=80=99t really understand = something, ask.

I want complete = decentralization - but for practical reasons, which should be obvious, = we cannot start at this point. Bitcoin came into existence because = Satoshi wrote a whitepaper and implemented the idea - and it was his = rules. There was no voting, no committee, no proof-of-work, no = nothing=E2=80=A6it was a complete dictatorship in the = beginning.


So in the end the hard fork might be = perfect, because people like you will not waste so much more energy and = time fighting people like me (and others) who are following different = dogmata because we are using different coins and talking about different = code. Interestingly enough in the end we will probably have a winner - = determined by the price - so I am looking forward to the outcome. It is = just the time so make some bets, which I embrace.
Another interesting thing is, that you = actually fear problems arising from this. What do you have to loose? = Just stick with the old bitcoin version and weather this storm. Bitcoin = is not going to vanish or break from this. It is just forking. One fork = will come stronger out of this. You just have to choose a side and live = with it, if you loose it all. But that is the story of bitcoin since the = beginning. If you ask me, you fear the choice, not the change.


Again, misrepresentation - =E2=80=9Cyou fear the = choice, not the change=E2=80=9D - why should anyone ask *you* what I = fear? Why don=E2=80=99t you ask *me*?


Cheers

Levin

Adam = Back via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> schrieb am Mo., = 17. Aug. 2015 um 16:37 Uhr:
Thank you Eric for saying what needs to be = said.

Starting a fork war is just not constructive and there are multiple
proposals being evaluated here.

I think that one thing that is not being so much focussed on is
Bitcoin-XT is both a hard-fork and a soft-fork.  It's a hard-fork = on
Bitcoin full-nodes, but it is also a soft-fork attack on Bitcoin core
SPV nodes that did not opt-in.  It exposes those SPV nodes to loss = in
the likely event that Bitcoin-XT results in a network-split.

The recent proposal here to run noXT (patch to falsely claim to mine
on XT while actually rejecting it's blocks) could add enough
uncertainty about the activation that Bitcoin-XT would probably have
to be aborted.

Adam

On 17 August 2015 at 15:03, Eric Lombrozo via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org>= wrote:
> NxtChg,
>
> In the entire history of Bitcoin we=E2=80=99ve never attempted = anything even closely resembling a hard fork like what=E2=80=99s being = proposed here.
>
> Many of us have wanted to push our own hard-forking changes to the = protocol=E2=80=A6and have been frustrated because of the inability to do = so.
>
> This inability is not due to any malice on anyone=E2=80=99s = part=E2=80=A6it is a feature of Satoshi=E2=80=99s protocol. For better = or worse, it is *very hard* to change the rules=E2=80=A6and this is = exactly what imbues Bitcoin with one of its most powerful attributes: = very well-defined settlement guarantees that cannot be suddenly altered = nor reversed by anyone.
>
> We=E2=80=99ve managed to have a few soft forks in the past=E2=80=A6an= d for the most part these changes have been pretty uncontroversial=E2=80=A6= or at least, they have not had nearly the level of political = divisiveness that this block size issue is having. And even then, = we=E2=80=99ve encountered a number of problems with these deployments = that have at times required goodwill cooperation between developers and = mining pool operators to fix.
>
> Again, we have NEVER attempted anything even remotely like what=E2=80= =99s being proposed - we=E2=80=99ve never done any sort of hard fork = before like this. If even fairly uncontroversial soft forks have caused = problems, can you imagine the kinds of potential problems that a hard = fork over some highly polarizing issue might raise? Do you really think = people are going to want to cooperate?!?
>
> I can understand that some people would like bigger blocks. Other = people might want feature X, others feature Y=E2=80=A6and we can argue = the merits of this or that to death=E2=80=A6but the fact remains that we = have NEVER attempted any hard forking change=E2=80=A6not even with a = simple, totally uncontroversial no-brainer improvement that would not = risk any sort of ill-will that could hamper remedies were it not to go = as smoothly as we like. *THIS* is the fundamental problem - the whole = bigger block thing is a minor issue by comparison=E2=80=A6it could be = any controversial change, really.
>
> Would you want to send your test pilots on their first flight=E2=80=A6= the first time an aircraft is ever flown=E2=80=A6directly into combat = without having tested the plane? This is what attempting a hard fork = mechanism that=E2=80=99s NEVER been done before in such a politically = divisive environment basically amounts to=E2=80=A6but it=E2=80=99s even = worse. We=E2=80=99re basically risking the entire air force (not just = one plane) over an argument regarding how many seats a plane should have = that we=E2=80=99ve never flown before.
>
> We=E2=80=99re talking billlions of dollars=E2=80=99 worth of other = people=E2=80=99s money that is on the line here. Don=E2=80=99t we owe it = to them to at least test out the system on a far less controversial, far = less divisive change first to make sure we can even deploy it without = things breaking? I don=E2=80=99t even care about the merits regarding = bigger blocks vs. smaller blocks at this point, to be quite honest - = that=E2=80=99s such a petty thing compared to what I=E2=80=99m talking = about here. If we attempt a novel hard-forking mechanism that=E2=80=99s = NEVER been attempted before (and which as many have pointed out is = potentially fraught with serious problems) on such a politically = divisive, polarizing issue, the result is each side will refuse to = cooperate with the other out of spite=E2=80=A6and can easily lead to a = war, tanking the value of everyone=E2=80=99s assets on both chains. All = so we can process 8 times the number of transactions we currently do? = Even if it were 100 times, we wouldn=E2=80=99t even come close to = touching big payment processors like Visa. It=E2=80=99s hard to imagine = a protocol improvement that=E2=80=99s worth the risk.
>
> I urge you to at least try to see the bigger picture here=E2=80=A6and= to understand that nobody is trying to stop anyone from doing anything = out of some desire for maintaining control - NONE of us are able to = deploy hard forks right now without facing these problems. And different = people obviously have different priorities and preferences as to which = of these changes would be best to do first. This whole XT thing is = essentially giving *one* proposal special treatment above those that = others have proposed. Many of us have only held back from doing this out = of our belief that goodwill amongst network participants is more = important than trying to push some pet feature some of us want.
>
> Please stop this negativity - we ALL want the best for Bitcoin and = are doing our best, given what we understand and know, to do what=E2=80=99= s right.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= /a>

= --Apple-Mail=_F433E8DB-8A0B-4FF8-9B5A-A8A6A4A9FC3E-- --Apple-Mail=_32B82850-82F1-44D6-BCE1-71B23C6CC02D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJV0fi7AAoJEJNAI64YFENU2tUQALBCHjVRRsdlGhURC6d4XG5f 7wuwhSzPNB+CCaJshjakz/UjTWHahpiw6JaL6bDcbq+WCmYxOktMJG7+v3UUxo/U zbTgNEmzvZF0gDdEZNk4Ne535YbsWKnLmPhlIEd+OmaF+lkKsapYJgf9JKKG/+iM 2LWhAzPudF4nXmAShPEWBIbjSpt2txxf7k77g+jpS4xjCvdv+TCNwe73bzkqtgtU En7iK6qDRlCWwJsgEEQw3r3g2H97QV8XPUZhAHoWJ34pwq60JJLrvQ/YyyBJrbM5 iBdmIkufL9vc4DjjhnGllJFh+7D2jr8G4c6WObFy6bpVc0cJ857GamSJBt2HfdY6 C4lS/silCKi7MuorLf8+L7b+D6+hi2edEePEi4A3yKeT6ElKgvPS1plcfL3t7egL /KezGQzqy5VQxtZZvaxgcGO5HyvzURyg1p2f0gKCrSITvFuDPs6dx98uAB4NXbEC 5Lq2uGxPLaw8Gwa0LhvlNOpWjA45Uw3F+PbS9vwtHjbFGqOE9SK6Uun9ka0YrqqE XpjGXvwrtJtGjRoHWJIkBR2a/USmWeLpuYwKIYo7KyLBt2y/jPUvxgVG5EyD76Cn 7jIHvby6m8btMtqnk1xBYtY3qz3La3MPCCuitFniMwNS5oqPkUlQLsfqqeJ/Gbbe HNhg1tfc3R8TPs1Tk0Zr =jveH -----END PGP SIGNATURE----- --Apple-Mail=_32B82850-82F1-44D6-BCE1-71B23C6CC02D--