Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YzUJO-0006Ee-Qo for bitcoin-development@lists.sourceforge.net; Mon, 01 Jun 2015 18:19:46 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.220.47 as permitted sender) client-ip=209.85.220.47; envelope-from=wtogami@gmail.com; helo=mail-pa0-f47.google.com; Received: from mail-pa0-f47.google.com ([209.85.220.47]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YzUJN-0000jx-Sk for bitcoin-development@lists.sourceforge.net; Mon, 01 Jun 2015 18:19:46 +0000 Received: by padjw17 with SMTP id jw17so42512891pad.2 for ; Mon, 01 Jun 2015 11:19:40 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.66.118.166 with SMTP id kn6mr42311411pab.93.1433182780235; Mon, 01 Jun 2015 11:19:40 -0700 (PDT) Received: by 10.70.93.72 with HTTP; Mon, 1 Jun 2015 11:19:40 -0700 (PDT) In-Reply-To: References: Date: Mon, 1 Jun 2015 08:19:40 -1000 Message-ID: From: "Warren Togami Jr." Cc: Bitcoin Dev Content-Type: multipart/alternative; boundary=e89a8ffbaba783a6f3051778de12 X-Spam-Score: 3.1 (+++) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (wtogami[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.2 MISSING_HEADERS Missing To: header 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 2.7 MALFORMED_FREEMAIL Bad headers on message from free email service -0.2 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1YzUJN-0000jx-Sk Subject: Re: [Bitcoin-development] Fwd: Block Size Increase Requirements X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 18:19:46 -0000 --e89a8ffbaba783a6f3051778de12 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable By reversing Mike's language to the reality of the situation I had hoped people would realize how abjectly ignorant and insensitive his statement was. I am sorry to those in the community if they misunderstood my post. I thought it was obvious that it was sarcasm where I do not seriously believe particular participants should be excluded. On Mon, Jun 1, 2015 at 3:06 AM, Thy Shizzle wrote: > Doesn't mean you should build something that says "fuck you" to the > companies that have invested in farms of ASICS. To say "Oh yea if they > can't mine it how we want stuff 'em" is naive. I get decentralisation, bu= t > don't dis incentivise mining. If miners are telling you that you're going > to hurt them, esp. Miners that combined hold > 50% hashing power, why wou= ld > you say too bad so sad? Why not just start stripping bitcoin out of > adopters wallets? Same thing. > ------------------------------ > From: Warren Togami Jr. > Sent: =E2=80=8E1/=E2=80=8E06/=E2=80=8E2015 10:30 PM > Cc: Bitcoin Dev > Subject: Re: [Bitcoin-development] Fwd: Block Size Increase Requirements > > Whilst it would be nice if miners in *outside* China can carry on > forever regardless of their internet situation, nobody has any inherent > "right" to mine if they can't do the job - if miners in *outside* China > can't get the trivial amounts of bandwidth required through their firewal= l *TO > THE MAJORITY OF THE HASHRATE* and end up being outcompeted then OK, too > bad, we'll have to carry on without them. > > > On Mon, Jun 1, 2015 at 12:13 AM, Mike Hearn wrote: > > Whilst it would be nice if miners in China can carry on forever > regardless of their internet situation, nobody has any inherent "right" t= o > mine if they can't do the job - if miners in China can't get the trivial > amounts of bandwidth required through their firewall and end up being > outcompeted then OK, too bad, we'll have to carry on without them. > > But I'm not sure why it should be a big deal. They can always run a node > on a server in Taiwan and connect the hardware to it via a VPN or so. > > --e89a8ffbaba783a6f3051778de12 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
By reversing Mike's language to the reality of the sit= uation I had hoped people would realize how abjectly ignorant and insensiti= ve his statement was.=C2=A0 I am sorry to those in the community if they mi= sunderstood my post. I thought it was obvious that it was sarcasm where I d= o not seriously believe particular participants should be excluded.

On Mon, Jun 1, 2015 a= t 3:06 AM, Thy Shizzle <thyshizzle@outlook.com> wrote:<= br>
Doesn't me= an you should build something that says "fuck you" to the compani= es that have invested in farms of ASICS. To say "Oh yea if they can= 9;t mine it how we want stuff 'em" is naive. I get decentralisatio= n, but don't dis incentivise mining. If miners are telling you that you&#= 39;re going to hurt them, esp. Miners that combined hold > 50% hashing p= ower, why would you say too bad so sad? Why not just start stripping bitcoi= n out of adopters wallets? Same thing.
From: Warren Togami Jr.
Sent: =E2=80= =8E1/=E2=80=8E06/=E2=80=8E2015 10:30 PM
Cc: Bi= tcoin Dev
Subject: Re: [B= itcoin-development] Fwd: Block Size Increase Requirements

Whils= t it would be nice if miners in outside China can carry on forever regardless of= their internet situation, nobody has any inherent "right" to min= e if they can't do the job - if miners in=C2=A0outside China can't get the trivial amo= unts of bandwidth required through their firewall TO THE MAJORITY OF THE HASHRATE<= /b> and end up being outcompeted then OK, too bad, we'll have to carry = on without them.

--e89a8ffbaba783a6f3051778de12--