From: Tier Nolan <tier.nolan@gmail•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Increasing the blocksize as a (generalized) softfork.
Date: Sun, 20 Dec 2015 15:50:57 +0000 [thread overview]
Message-ID: <CAE-z3OXxX9Xki=oco4veasE796z__x17C-KLc0jsMW8GxSrZ_Q@mail.gmail.com> (raw)
In-Reply-To: <1bf64a5b514d57ca37744ae5f5238149@openmailbox.org>
[-- Attachment #1: Type: text/plain, Size: 1762 bytes --]
This is essentially the "nuclear option". You are destroying the current
chain (converting it to a chain of coinbases) and using the same POW to
start the new chain. You are also giving everyone credit in the new chain
equal to their credit in the old chain.
It would be better if the current chain wasn't destroyed.
This could be achieved by adding the hash of an extended block into the
coinbase but not requiring the coinbase to be the only transaction.
The new block is the legacy block plus the associated extended block.
Users would be allowed to move money to the extended block by spending it
to a specific output template.
<public key hash> OP_1 OP_TO_EXTENDED OP_TRUE
OP_1 is the extended block index and initially, only one level is available.
This would work like P2SH. Users could spend the money on the extended
block chain exactly as they could on the main chain.
Money can be brought back the same way.
<public key hash> <txid1> <txid2> ... <txid-n> <N> OP_0 OP_UNLOCK OP_TRUE
The txids are for transactions that have been locked in root chain. The
transaction is only valid if they are all fully funded. The fee for the
transaction would be fee - (cost to fund unlocked txids). A negative fee
tx would be invalid.
This has the advantage that it keeps the main chain operating. People can
still send money with their un-upgraded clients. There is also an
incentive to move funds to the extended block(s). The new extended blocks
are more complex, but potentially have lower fees. Nobody is forced to
change. If the large blocks aren't needed, nobody will both to use them.
The rule could be
Now:
0) 1 MB
After change over
0) 1 MB
1) 2 MB
After 2 years
0) 1 MB
1) 2 MB
2) 4MB
After 4 years
0) 1 MB
1) 2 MB
2) 4MB
3) 8MB
[-- Attachment #2: Type: text/html, Size: 2307 bytes --]
next prev parent reply other threads:[~2015-12-20 15:50 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-20 10:56 joe2015
2015-12-20 15:22 ` joe2015
2015-12-20 15:50 ` Tier Nolan [this message]
2015-12-20 18:17 ` Bryan Bishop
2015-12-21 3:04 ` joe2015
2015-12-21 4:23 ` jl2012
2015-12-21 4:41 ` joe2015
2015-12-30 19:00 ` Bob McElrath
2015-12-30 23:49 ` Jonathan Toomim
2015-12-30 23:56 ` Jonathan Toomim
2015-12-31 0:04 ` Bob McElrath
2015-12-31 4:39 ` joe2015
2015-12-31 10:39 ` David Chan
2015-12-31 11:32 ` joe2015
2016-01-04 21:53 ` Luke Dashjr
2015-12-20 17:21 joe2015
2015-12-21 3:39 ` Jeff Garzik
2015-12-21 3:58 ` joe2015
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='CAE-z3OXxX9Xki=oco4veasE796z__x17C-KLc0jsMW8GxSrZ_Q@mail.gmail.com' \
--to=tier.nolan@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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