path: root/3a/772ce5df37e0ce182bd627f95e7753f20421f3

Return-Path: <hectorchu@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 825C689F
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  5 Aug 2015 19:05:08 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-la0-f54.google.com (mail-la0-f54.google.com
	[209.85.215.54])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1F6FE220
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed,  5 Aug 2015 19:05:07 +0000 (UTC)
Received: by labow3 with SMTP id ow3so35081172lab.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 05 Aug 2015 12:05:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc:content-type;
	bh=WNu4ZSXP1x7y/cSGoBlkJi5mIyJPn1Jlm6XtZGoNarE=;
	b=otVgPu9q38K69e3iLbADkkW9fT583VdwkEqYZX4+RNYrscTiMU62SJv6z+lEPb+4BJ
	glM9uvu9YcpDkbIyQFTw9oUDpL1tUS4w8KQTUERXNidfBLCmoonFvl0Din4v2vWbHvwF
	8x1CLkaFSUHUnBtFirp2tFeEA+Su0r8xZaow7uKVaA802wqFktEn//Wz3CO0oxbMCikW
	XPyT7cepd1cZvAPZlZKB7pwkNcDh2vY6ZQNuriBB43sk88nYd4FhOi7d5YS25ANlyEqC
	5k0gEPRAEdoEAjipcbF/fmKxdocbIbv4ZmFxqgT5+a0KAmS6P5EhisaToO7H/TKs7c91
	uVTg==
X-Received: by 10.152.30.100 with SMTP id r4mr10635031lah.92.1438801505393;
	Wed, 05 Aug 2015 12:05:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.25.22.25 with HTTP; Wed, 5 Aug 2015 12:04:35 -0700 (PDT)
In-Reply-To: <CAAO2FKGwf0yNFT1VaSVQ7B88YRnSaGONrCrTxuVoe4d0ryw5mA@mail.gmail.com>
References: <CABsx9T1E1s=4h-SxLTOAXK4GniZrUekcEb6zDdTDFG+h7X98MA@mail.gmail.com>
	<1438640036.2828.0.camel@auspira.com>
	<CABsx9T2A-Mz9z=TTifbL2_sKCDvy8coRpNse+0vff6EbXbp8cg@mail.gmail.com>
	<BF420F3B-044C-46F6-8880-FEEB9A3DC748@gmx.com>
	<CAOoPuRb=wDKOoRXuqktDypyJ_gs1w5WORx4+LH84AOEv_PY1ZQ@mail.gmail.com>
	<CAAO2FKGPeBnpB0X3fvqkX+Wy6wOO+m1ZPhEup0Hvv4_nhcRUKA@mail.gmail.com>
	<CALqxMTGiSdh64G9LVLoCCio3fLNaXUY9v0BeMZV+ZiN6ShY0Ew@mail.gmail.com>
	<CAAO2FKGjarDHVyF0kJ39iS=QPQ_XrB97=dgHVVwSyih05EjJsQ@mail.gmail.com>
	<CALqxMTH9K1WrZo9RUBmK93y_42ffe_Ni7yJFrghJy_7EZMM8Eg@mail.gmail.com>
	<CAAO2FKGwf0yNFT1VaSVQ7B88YRnSaGONrCrTxuVoe4d0ryw5mA@mail.gmail.com>
From: Hector Chu <hectorchu@gmail.com>
Date: Wed, 5 Aug 2015 20:04:35 +0100
Message-ID: <CAAO2FKH7YO0WVf17_tH8dhZJ7Rt2-sHO40hx9afVjobY1i4i+A@mail.gmail.com>
To: Adam Back <adam@cypherspace.org>
Content-Type: multipart/alternative; boundary=089e0158cba0a1a44a051c951435
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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 <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] "A Transaction Fee Market Exists Without a Block
 Size Limit"--new research paper suggests
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Aug 2015 19:05:08 -0000

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

To put some flesh on the bones of this idea, imagine a hypothetical
security named BLK. Demand for bigger blocks should buy up BLK and demand
for smaller blocks should short BLK. The price of BLK in BTC is the ideal
block size.
Now imagine that there are futures contracts for the security BLK. On the
settlement date of those futures the current BLK/BTC price of those futures
is taken to be the new Bitcoin block size for the next 3 months.
For instance, if I predict or want the block size to be higher on September
than it currently is, I would buy up September BLK futures. My actions
would nudge the price up, and if come September I am right I get what I
want and have a floating profit on the futures market.
The nice thing about a futures market is that it allows capacity planning
for the months ahead. Also there is no need for an underlying BLK security
for a futures market in BLKs to exist.
If the market is efficient and correctly sets the block size, BTC/USD will
rise and the BTC profits of the market participants will go up in USD terms
as a result.

On 5 August 2015 at 12:35, Hector Chu <hectorchu@gmail.com> wrote:

> On 5 August 2015 at 12:07, Adam Back <adam@cypherspace.org> wrote:
>
>> This prediction market in block-size seems like something extremely
>> complex to operate and keep secure in a decentralised fashion.
>
>
> Why would it need to be decentralised? Bitcoin.org could run the exchange,
> and the profits from the exchange could be used to fund Core development.
>
> We also have no particular reason to suppose other than
>> meta-incentive, that it should result in a secure parameter set.
>>
>
> Security is a continuous variable, trading off against others. If security
> gradually begins to be threatened as a result of block size gradually
> increasing, the concerns of users will be enough that the bears will gain
> control over the bulls on the block size market.
>
> I suspect that, while it is interesting in the abstract, it risks
>> converting a complex security problem into an even more complex one,
>> rather than constituting an incremental security improvement which is
>> more the context of day to day discussions here.
>
>
> Hard problems call for complex solutions.
>

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

<div dir=3D"ltr">To put some flesh on the bones of this idea, imagine a hyp=
othetical security named BLK. Demand for bigger blocks should buy up BLK an=
d demand for smaller blocks should short BLK. The price of BLK in BTC is th=
e ideal block size.<div>Now imagine that there are futures contracts for th=
e security BLK. On the settlement date of those futures the current=C2=A0BL=
K/BTC=C2=A0price of those futures is taken to be the new Bitcoin block size=
 for the next 3 months.</div><div>For instance, if I predict or want the bl=
ock size to be higher on September than it currently is, I would buy up Sep=
tember BLK futures. My actions would nudge the price up, and if come Septem=
ber I am right I get what I want and have a floating profit on the futures =
market.</div><div>The nice thing about a futures market is that it allows c=
apacity planning for the months ahead. Also there is no need for an underly=
ing BLK security for a futures market in BLKs to exist.</div><div>If the ma=
rket is efficient and correctly sets the block size, BTC/USD will rise and =
the BTC profits of the market participants will go up in USD terms as a res=
ult.</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">O=
n 5 August 2015 at 12:35, Hector Chu <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:hectorchu@gmail.com" target=3D"_blank">hectorchu@gmail.com</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gm=
ail_extra"><div class=3D"gmail_quote"><span class=3D"">On 5 August 2015 at =
12:07, Adam Back <span dir=3D"ltr">&lt;<a href=3D"mailto:adam@cypherspace.o=
rg" target=3D"_blank">adam@cypherspace.org</a>&gt;</span> wrote:<br><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">This prediction market in block-size seems like som=
ething extremely<br>
complex to operate and keep secure in a decentralised fashion.</blockquote>=
<div><br></div></span><div>Why would it need to be decentralised? Bitcoin.o=
rg could run the exchange, and the profits from the exchange could be used =
to fund Core development.</div><span class=3D""><div><br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">We also have no particular reason to suppose other than<=
br>
meta-incentive, that it should result in a secure parameter set.<br></block=
quote><div><br></div></span><div>Security is a continuous variable, trading=
 off against others. If security gradually begins to be threatened as a res=
ult of block size gradually increasing, the concerns of users will be enoug=
h that the bears will gain control over the bulls on the block size market.=
</div><span class=3D""><div><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I suspect that, while it is interesting in the abstract, it risks<br>
converting a complex security problem into an even more complex one,<br>
rather than constituting an incremental security improvement which is<br>
more the context of day to day discussions here.</blockquote><div><br></div=
></span><div>Hard problems call for complex solutions.=C2=A0</div></div></d=
iv></div>
</blockquote></div><br></div>

--089e0158cba0a1a44a051c951435--