From: Johnson Lau <jl2012@xbt.hk>
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: <CAO3Pvs9DF6F4gDgrNPoUw5bqwb6ajDwwVP9NpcLzpZMzzgMQjw@mail.gmail.com>
To: Olaoluwa Osuntokun <laolu32@gmail.com>
References: <201704041803.57409.luke@dashjr.org>
	<B15790EC-B298-4F6A-BEBF-AF8C3DA74EED@xbt.hk>
	<CAO3Pvs9DF6F4gDgrNPoUw5bqwb6ajDwwVP9NpcLzpZMzzgMQjw@mail.gmail.com>
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Extension block proposal by Jeffrey et al
Precedence: list


--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 <laolu32@gmail.com> 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

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D""><br class=3D""><div><blockquote type=3D"cite" class=3D""><div =
class=3D"">On 5 Apr 2017, at 22:05, Olaoluwa Osuntokun &lt;<a =
href=3D"mailto:laolu32@gmail.com" class=3D"">laolu32@gmail.com</a>&gt; =
wrote:</div><div class=3D""><div dir=3D"ltr" class=3D""><div =
class=3D""><br class=3D""><div class=3D""><br class=3D""></div><div =
class=3D"">The concrete parameters chosen in the proposal are: each =
channel opening</div><div class=3D"">transaction reserves 700-bytes =
within _each_ block in the chain until the</div><div =
class=3D"">transaction has been closed.&nbsp;</div><div class=3D""><br =
class=3D""></div><div class=3D""></div></div></div><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br =
class=3D"gmail_msg">
</blockquote></div>
</div></blockquote><br class=3D""></div><div>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.</div><div><br class=3D""></div><div>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.</div><div><br class=3D""></div><div>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</div><div><br =
class=3D""></div><div>I think this is an interesting idea to explorer =
and I=E2=80=99d like to include this in my hardfork proposal.</div><br =
class=3D""></body></html>=

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