From: Lucas Clemente Vella <lvella@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: [bitcoin-dev] Freeze Bitcoin protocol and call it Bitcoin 1
Date: Wed, 21 Jun 2017 01:46:15 -0300 [thread overview]
Message-ID: <CAGCathyHbNpepDZU-EHzmvGW_yM=+B3K6hHDDJ-LbDQ4T3vCyg@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 3438 bytes --]
Is it too late to propose to freeze Bitcoin protocol as it is today (no
SegWit, no bigger block)?
Hear me out: assume Bitcoin is frozen as it is now: no more forks, no more
change in consensus rules. Call it Bitcoin 1 (BC1). So, how to evolve and
scale Bitcoin?
Use a very conservative sidechain, call it Bitcoin 2 (BC2), tightly
coupled, block per block, with Bitcoin 1 chain. No fancy experimental
changes there: fix the bare minimum to support more general two-way
sidechains, linear scalability transaction verification time and
transaction malleability. Can be one way only if that makes it simple
enough: coins sent to BC2 can never come back to BC1.
Miners choose to mine a BC2 block alongside a BC1 block, and it can be done
for free once a BC1 block is found. There may be BC1 blocks in the chain
whose corresponding BC2 blocks are missing (and that is not a big deal),
but there will be an economic incentive to mine a BC2 block, since
transaction fees on that chain will be collected.
The economic adoption is completely voluntary and independent of anyone
else, doesn't require the strong consensus of SegWit. If it is feasible to
create a simple enough two way sidechain over BC1, good. If not, economic
value of BC1 will always be at least that of BC2, but never lower. BC2 may
have a lower price than BC1 at first, but since it will have every feature
of BC1, plus the possibility of massive scalability and instantaneous
transactions with a lightning network built over BC2 (a practical
economical advantage), it will most likely value over what BC1 could ever
be alone, raising BC1 price with it.
If these predictions are correct, fewer and fewer people will transact BC1,
eventually with blocks mined empty except for the coinbase, which the miner
may choose to send directly to BC2. If I turn out to be wrong, and people
prefer to stick to the old BC1 for some reason, BC2 becomes just another
speculative altcoin. Thus, everyone migrating should be fully conscious
about the risk of immediate devaluation.
The 2 major risks I see that could hamper the adoption are:
- Just plain fear: I find the whole economical incentive scenario of BC2
sound and plausible, just as I found Bitcoin sound and plausible when I
heard about it for the first time. I also fear to put my money in BC2, just
as I did when I heard about Bitcoin. BC2 case is even worse, because I can
safely hold my coins in BC1 until I am sure BC2 is solid, so at first we
may experience only enthusiast adoption;
- Technological inertia: everyone wishing to accept BC2 will have to
implement this payment system as for any other altcoin. Every exchange
supporting both will have to create separated markets for BC1 and BC2.
Remember: both chains must be obviously distinguishable. It is even
desirable that the address format in BC2 to be incompatible with BC1 (maybe
staring with "2" ?).
Finally, due to the present state of affairs, with impending activation of
segwit with a promise to hardfork in 3 months, I believe this proposal is
too late, not to mention the stress, emotions and hard feelings of the
situation will make it go largely ill received or ignored. But since I
genuinely believe this to be the best and most conservative way to go with
Bitcoin, I wrote this anyway.
Please forgive me if something like this was discussed a thousand times
before and you wasted your time reading this.
--
Lucas Clemente Vella
lvella@gmail.com
[-- Attachment #2: Type: text/html, Size: 3941 bytes --]
reply other threads:[~2017-06-21 4:46 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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='CAGCathyHbNpepDZU-EHzmvGW_yM=+B3K6hHDDJ-LbDQ4T3vCyg@mail.gmail.com' \
--to=lvella@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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