MIME-Version: 1.0
Sender: dscotese@gmail.com
In-Reply-To: <55BDF31D.1010803@mail.bihthai.net>
References: <20150731083943.Horde.68uT9J78H_PdIgIwQP5frA1@server47.web-hosting.com>
	<CAPg+sBhFYJudy+m8+FqxTczj6W8Uc1pH1BsOqP0kgxmv-FMW0w@mail.gmail.com>
	<bbdbc08925ca3416f0f9982466b98413@xbt.hk>
	<CAPg+sBhQV7ymm3sDW44DWr1FEfgoGoTfMva1iTbZXHcf==mYbw@mail.gmail.com>
	<55BDF31D.1010803@mail.bihthai.net>
Date: Sun, 2 Aug 2015 15:07:22 -0700
Message-ID: <CAGLBAheCCuz+co3ZVqrVQyxiaPm399k+mvznrgGM4yghrgQ9zw@mail.gmail.com>
From: Dave Scotese <dscotese@litmocracy.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=f46d04374917fcdd9f051c5b46f0
Subject: Re: [bitcoin-dev] A compromise between BIP101 and Pieter's proposal
Precedence: list

--f46d04374917fcdd9f051c5b46f0
Content-Type: text/plain; charset=UTF-8

It will help to assume that there is at least one group of evil people who
are investing in Bitcon's demise.  Not because there are, but because there
might be.  So let's assume they are making a set of a billion transactions,
or a trillion, and maintaining currently-being-legitimately-used hashing
power.  When block size is large enough to frustrate other miners, this
hash power (or some piece of it) will be experimentally shifted to solving
a block containing an internally consistent subset of the prepared
trasnsactions to fill it - experimentally at first, but on the active
Bitcoin network.  One seemingly random, bloated, useless (except for the
universal timestamp) block will be created and the evil group will measure
the effect on the mining community - client takedowns, market exits, and
whatever else interests them.  Then they lie in wait, perhaps let out one
more to do another experiment, but with the goal of eventually catching us
unawares and doing as much damage to morale as possible.

Good concrete descriptions of the threats against which we want to guard
will be very helpful.  Maybe there are already unit tests for such things
or requests for miners' reactions to them (as opposed to just the
software's behavior).  My description might be a bit too long and perhaps
not a very good example, but do we have a place where such examples can be
constructed?

While we will do our best to guard against such nightmares, it's also
helpful to imagine what we will do if and when one of them ever actually
occurs.  Yes, I'm paranoid; because those who like to control everything
are losing it.

Dave

On Sun, Aug 2, 2015 at 3:38 AM, Venzen Khaosan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> +1 on every point, sipa
>

--f46d04374917fcdd9f051c5b46f0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div>It will help to assume that there is a=
t least one group of evil people who are investing in Bitcon&#39;s demise.=
=C2=A0 Not because there are, but because there might be.=C2=A0 So let&#39;=
s assume they are making a set of a billion transactions, or a trillion, an=
d maintaining currently-being-legitimately-used hashing power.=C2=A0 When b=
lock size is large enough to frustrate other miners, this hash power (or so=
me piece of it) will be experimentally shifted to solving a block containin=
g an internally consistent subset of the prepared trasnsactions to fill it =
- experimentally at first, but on the active Bitcoin network.=C2=A0 One see=
mingly random, bloated, useless (except for the universal timestamp) block =
will be created and the evil group will measure the effect on the mining co=
mmunity - client takedowns, market exits, and whatever else interests them.=
=C2=A0 Then they lie in wait, perhaps let out one more to do another experi=
ment, but with the goal of eventually catching us unawares and doing as muc=
h damage to morale as possible.<br></div><br></div>Good concrete descriptio=
ns of the threats against which we want to guard will be very helpful.=C2=
=A0 Maybe there are already unit tests for such things or requests for mine=
rs&#39; reactions to them (as opposed to just the software&#39;s behavior).=
=C2=A0 My description might be a bit too long and perhaps not a very good e=
xample, but do we have a place where such examples can be constructed?<br><=
br></div>While we will do our best to guard against such nightmares, it&#39=
;s also helpful to imagine what we will do if and when one of them ever act=
ually occurs.=C2=A0 Yes, I&#39;m paranoid; because those who like to contro=
l everything are losing it.<br><br></div>Dave<br><div class=3D"gmail_extra"=
><br><div class=3D"gmail_quote">On Sun, Aug 2, 2015 at 3:38 AM, Venzen Khao=
san via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lis=
ts.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation=
.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D=
"">-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
</span>+1 on every point, sipa<br>
<div><div class=3D"h5"></div></div></blockquote></div><br></div></div>

--f46d04374917fcdd9f051c5b46f0--