1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
|
Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 60A2E41C
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <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>
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 <bitcoin-dev@lists.linuxfoundation.org>
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 <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 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 <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 <<a =
href=3D"mailto:laolu32@gmail.com" class=3D"">laolu32@gmail.com</a>> =
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. </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--
|
