Hector Chu [ARCHIVE] on Nostr: š Original date posted:2015-08-05 š Original message:To put some flesh on the ...
š
Original date posted:2015-08-05
š Original message: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 at gmail.com> wrote:
> On 5 August 2015 at 12:07, Adam Back <adam at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150805/e53d1e47/attachment.html>;
š Original message: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 at gmail.com> wrote:
> On 5 August 2015 at 12:07, Adam Back <adam at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150805/e53d1e47/attachment.html>;