From: Johnson Lau <jl2012@xbt•hk>
To: Olaoluwa Osuntokun <laolu32@gmail•com>
Cc: bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Extension block proposal by Jeffrey et al
Date: Thu, 6 Apr 2017 01:04:10 +0800 [thread overview]
Message-ID: <85BB1F27-0B02-4415-B77B-17B5239E723E@xbt.hk> (raw)
In-Reply-To: <CAO3Pvs9DF6F4gDgrNPoUw5bqwb6ajDwwVP9NpcLzpZMzzgMQjw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1308 bytes --]
> 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 = 256 bytes
I think this is an interesting idea to explorer and I’d like to include this in my hardfork proposal.
[-- Attachment #2: Type: text/html, Size: 2158 bytes --]
next prev parent reply other threads:[~2017-04-05 17:04 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-04 18:03 Luke Dashjr
2017-04-04 18:35 ` Johnson Lau
2017-04-05 14:05 ` Olaoluwa Osuntokun
2017-04-05 15:37 ` Greg Sanders
2017-04-05 16:25 ` Joseph Poon
2017-04-05 17:04 ` Johnson Lau [this message]
2017-04-05 17:43 ` Christopher Jeffrey
2017-04-10 10:14 ` Johnson Lau
2017-05-09 0:56 ` Christopher Jeffrey
2017-05-09 17:56 ` Johnson Lau
2017-05-10 1:19 ` Christopher Jeffrey
2017-04-05 16:54 ` Christopher Jeffrey
2017-04-06 17:18 ` Luke Dashjr
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=85BB1F27-0B02-4415-B77B-17B5239E723E@xbt.hk \
--to=jl2012@xbt$(echo .)hk \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=laolu32@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox