public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: GC <slashdevnull@hotmail.com>
To: Adam Back <adam@cypherspace.org>, Eric Lombrozo <elombrozo@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Annoucing Not-BitcoinXT
Date: Mon, 17 Aug 2015 22:58:22 +0800	[thread overview]
Message-ID: <BLU437-SMTP6520F38414718F4E15E0DC6790@phx.gbl> (raw)
In-Reply-To: <CALqxMTHfzWr24qELKyYMQ5fy48C1Q-SExCL49w-VMCq2JOdRoQ@mail.gmail.com>

Adam,

While greatly appreciating your prior efforts in crypto-ccy R&D and
current efforts for Blockstream, its not a plus for your reputation to be
using emotive terms like ³attack², ³fork war" and throwing so much FUD
into the developer email channel directly after Eric¹s email.

We would appreciate seeing your well-argued thoughts, not FUD and flaming.
There are multitudes of trolls in all forums already.

On 17/8/15 10:36 pm, "Adam Back via bitcoin-dev"
<bitcoin-dev@lists.linuxfoundation.org> wrote:

>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¹ve never attempted anything even
>>closely resembling a hard fork like what¹s being proposed here.
>>
>> Many of us have wanted to push our own hard-forking changes to the
>>protocolŠand have been frustrated because of the inability to do so.
>>
>> This inability is not due to any malice on anyone¹s partŠit is a
>>feature of Satoshi¹s protocol. For better or worse, it is *very hard* to
>>change the rulesŠand 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¹ve managed to have a few soft forks in the pastŠand for the most
>>part these changes have been pretty uncontroversialŠor at least, they
>>have not had nearly the level of political divisiveness that this block
>>size issue is having. And even then, we¹ve 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¹s being
>>proposed - we¹ve 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Šand we can argue the
>>merits of this or that to deathŠbut the fact remains that we have NEVER
>>attempted any hard forking changeŠnot 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Šit could be any controversial change,
>>really.
>>
>> Would you want to send your test pilots on their first flightŠthe first
>>time an aircraft is ever flownŠdirectly into combat without having
>>tested the plane? This is what attempting a hard fork mechanism that¹s
>>NEVER been done before in such a politically divisive environment
>>basically amounts toŠbut it¹s even worse. We¹re basically risking the
>>entire air force (not just one plane) over an argument regarding how
>>many seats a plane should have that we¹ve never flown before.
>>
>> We¹re talking billlions of dollars¹ worth of other people¹s money that
>>is on the line here. Don¹t 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¹t even
>>care about the merits regarding bigger blocks vs. smaller blocks at this
>>point, to be quite honest - that¹s such a petty thing compared to what
>>I¹m talking about here. If we attempt a novel hard-forking mechanism
>>that¹s 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Šand can easily lead to a war,
>>tanking the value of everyone¹s 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¹t even come close to touching big payment
>>processors like Visa. It¹s hard to imagine a protocol improvement that¹s
>>worth the risk.
>>
>> I urge you to at least try to see the bigger picture hereŠand 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¹s right.
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev@lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev




  reply	other threads:[~2015-08-17 14:58 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-16 22:34 [bitcoin-dev] Annoucing Not-BitcoinXT jyellen
2015-08-17  3:10 ` jl2012
2015-08-17  7:04 ` Peter Todd
2015-08-17 10:09 ` NxtChg
2015-08-17 12:40   ` Vali Zero
2015-08-17 13:34     ` NxtChg
2015-08-17 14:03       ` Eric Lombrozo
2015-08-17 14:09         ` Levin Keller
2015-08-17 14:30           ` Eric Lombrozo
2015-08-17 14:36         ` Adam Back
2015-08-17 14:58           ` GC [this message]
2015-08-17 15:03           ` Levin Keller
2015-08-17 15:07             ` Eric Lombrozo
2015-08-19  3:49           ` odinn
2015-08-17 15:10         ` NxtChg
2015-08-17 16:37       ` Eric Lombrozo
2015-08-17 16:55         ` Eric Lombrozo
2015-08-18  4:37           ` Dave Scotese
2015-08-18  5:13             ` GC
2015-08-18  5:33               ` Dave Scotese
2015-08-18  9:46         ` NxtChg
2015-08-19  9:47           ` Jorge Timón

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=BLU437-SMTP6520F38414718F4E15E0DC6790@phx.gbl \
    --to=slashdevnull@hotmail.com \
    --cc=adam@cypherspace.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=elombrozo@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox