From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 60A2E41C for ; Wed, 5 Apr 2017 17:04:17 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BE5BCAD for ; Wed, 5 Apr 2017 17:04:16 +0000 (UTC) Received: from [10.8.8.2] (119246245241.ctinets.com [119.246.245.241]) by mx.zohomail.com with SMTPS id 1491411854306299.8263050853823; Wed, 5 Apr 2017 10:04:14 -0700 (PDT) From: Johnson Lau Message-Id: <85BB1F27-0B02-4415-B77B-17B5239E723E@xbt.hk> Content-Type: multipart/alternative; boundary="Apple-Mail=_BF334922-2F67-4703-A813-65E68CC31DC0" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Thu, 6 Apr 2017 01:04:10 +0800 In-Reply-To: To: Olaoluwa Osuntokun References: <201704041803.57409.luke@dashjr.org> X-Mailer: Apple Mail (2.3259) X-ZohoMailClient: External X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_NONE 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] Extension block proposal by Jeffrey et al X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Apr 2017 17:04:17 -0000 --Apple-Mail=_BF334922-2F67-4703-A813-65E68CC31DC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 5 Apr 2017, at 22:05, Olaoluwa Osuntokun wrote: >=20 >=20 > The concrete parameters chosen in the proposal are: each channel = opening > transaction reserves 700-bytes within _each_ block in the chain until = the > transaction has been closed.=20 >=20 >=20 Why so? It seems you are describing it as a softfork. With hardfork or = extension block, a new rule could simply grant extra space when the = tagged UTXO is spent. So if the usual block size limit is 1MB, when the = special UTXO is made, the block size limit decreases to 1MB-700 byte, = and the user has to pay for that 700 byte. When it is spent, the block = size will become 1MB+700 byte. But miners or even users may abuse this system: they may try to claim = all the unused space when the blocks are not congested, or when they are = mining empty block, and sell those tagged UTXO later. So I think we need = to limit the reservable space in each block, and deduct more space than = it is reserved. For example, if 700 bytes are reserved, the deduction = has to be 1400 byte. With BIP68, there are 8 unused bits in nSequence. We may use a few bits = to let users to fine tune the space they want to reserve. Maybe 1 =3D = 256 bytes I think this is an interesting idea to explorer and I=E2=80=99d like to = include this in my hardfork proposal. --Apple-Mail=_BF334922-2F67-4703-A813-65E68CC31DC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 5 Apr 2017, at 22:05, Olaoluwa Osuntokun <laolu32@gmail.com> = wrote:

The concrete parameters chosen in the proposal are: each = channel opening
transaction reserves 700-bytes = within _each_ block in the chain until the
transaction has been closed.

Why so? It seems you are = describing it as a softfork. With hardfork or extension block, a new = rule could simply grant extra space when the tagged UTXO is spent. So if = the usual block size limit is 1MB, when the special UTXO is made, the = block size limit decreases to 1MB-700 byte, and the user has to pay for = that 700 byte. When it is spent, the block size will become 1MB+700 = byte.

But miners or even users may = abuse this system: they may try to claim all the unused space when the = blocks are not congested, or when they are mining empty block, and sell = those tagged UTXO later. So I think we need to limit the reservable = space in each block, and deduct more space than it is reserved. For = example, if 700 bytes are reserved, the deduction has to be 1400 = byte.

With BIP68, there are 8 unused = bits in nSequence. We may use a few bits to let users to fine tune the = space they want to reserve. Maybe 1 =3D 256 bytes

I think this is an interesting idea to explorer = and I=E2=80=99d like to include this in my hardfork proposal.

= --Apple-Mail=_BF334922-2F67-4703-A813-65E68CC31DC0--