Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 825C689F for ; 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 ; Wed, 5 Aug 2015 19:05:07 +0000 (UTC) Received: by labow3 with SMTP id ow3so35081172lab.1 for ; 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: References: <1438640036.2828.0.camel@auspira.com> From: Hector Chu Date: Wed, 5 Aug 2015 20:04:35 +0100 Message-ID: To: Adam Back 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 wrote: > On 5 August 2015 at 12:07, Adam Back 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
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.
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.
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.
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.
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.

O= n 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 som= ething extremely
complex to operate and keep secure in a decentralised fashion.
=

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.

We also have no particular reason to suppose other than<= br> 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 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.=

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.=C2=A0

--089e0158cba0a1a44a051c951435--