From: Luke Dashjr <luke@dashjr•org>
To: bitcoin-dev@lists•linuxfoundation.org, Jonathan Toomim <j@toom•im>
Subject: Re: [bitcoin-dev] Capacity increases for the Bitcoin system.
Date: Tue, 8 Dec 2015 23:48:53 +0000 [thread overview]
Message-ID: <201512082348.54788.luke@dashjr.org> (raw)
In-Reply-To: <2030FF3C-4F65-44E6-A9D5-9CD144179994@toom.im>
On Tuesday, December 08, 2015 11:40:42 PM Jonathan Toomim via bitcoin-dev
wrote:
> Agree. This data does not belong in the coinbase. That space is for miners
> to use, not devs.
This has never been guaranteed, nor are softforks a "dev action" in the first
place.
> I also think that a hard fork is better for SegWit, as it reduces the size
> of fraud proofs considerably, makes the whole design more elegant and less
> kludgey, and is safer for clients who do not upgrade in a timely fashion.
How about we pursue the SegWit softfork, and at the same time* work on a
hardfork which will simplify the proofs and reduce the kludgeyness of merge-
mining in general? Then, if the hardfork is ready before the softfork, they
can both go together, but if not, we aren't stuck delaying the improvements of
SegWit until the hardfork is completed.
* I have been in fact working on such a proposal for a while now, since before
SegWit.
> I don't like the idea that SegWit would invalidate the security
> assumptions of non-upgraded clients (including SPV wallets). I think that
> for these clients, no data is better than invalid data. Better to force
> them to upgrade by cutting them off the network than to let them think
> they're validating transactions when they're not.
There isn't an option for "no data", as non-upgraded nodes in a hardfork are
left completely vulnerable to attacking miners, even much lower hashrate than
the 51% attack risk. So the alternatives are:
- hardfork: complete loss of all security for the old nodes
- softfork: degraded security for old nodes
Luke
next prev parent reply other threads:[~2015-12-08 23:49 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-07 22:02 Gregory Maxwell
2015-12-07 22:54 ` Bryan Bishop
2015-12-08 2:42 ` Anthony Towns
2015-12-08 4:58 ` Anthony Towns
2015-12-08 5:21 ` Gregory Maxwell
2015-12-08 6:54 ` Anthony Towns
2016-01-18 12:02 ` Anthony Towns
2016-01-22 9:46 ` Anthony Towns
2015-12-08 11:07 ` Wladimir J. van der Laan
2015-12-08 11:14 ` Jorge Timón
2015-12-08 15:12 ` Gavin Andresen
2015-12-08 15:55 ` Justus Ranvier
2015-12-08 17:41 ` Mark Friedenbach
2015-12-08 18:43 ` Justus Ranvier
2015-12-08 19:08 ` Tier Nolan
2015-12-08 19:31 ` Gregory Maxwell
2015-12-08 23:40 ` Jonathan Toomim
2015-12-08 23:48 ` Luke Dashjr [this message]
2015-12-09 0:54 ` Jonathan Toomim
2015-12-08 23:50 ` Jorge Timón
2015-12-09 0:56 ` Jonathan Toomim
2015-12-08 23:59 ` Gregory Maxwell
2015-12-09 0:58 ` Jorge Timón
2015-12-09 1:02 ` Jorge Timón
2015-12-09 1:09 ` Gavin Andresen
2015-12-09 1:31 ` Gregory Maxwell
2015-12-09 4:44 ` Ryan Butler
2015-12-09 6:29 ` Gregory Maxwell
2015-12-09 6:36 ` Ryan Butler
2015-12-09 6:59 ` Mark Friedenbach
2015-12-09 7:17 ` Gregory Maxwell
2015-12-09 7:54 ` Jorge Timón
2015-12-09 8:03 ` Gregory Maxwell
2015-12-09 8:46 ` Mark Friedenbach
2015-12-09 11:08 ` Jorge Timón
2015-12-09 16:40 ` Gavin Andresen
2015-12-11 16:18 ` Jorge Timón
2015-12-11 16:43 ` Gavin Andresen
2015-12-12 5:13 ` digitsu
2015-12-12 15:18 ` Mark Friedenbach
2015-12-14 11:21 ` Jonathan Toomim
2015-12-14 12:44 ` Adam Back
2015-12-09 4:51 ` Anthony Towns
2015-12-09 14:51 ` Chris
[not found] ` <CAPWm=eUomq6SBC0ky0WSs5=_G942vigm4RmgYuq0O-yJ-vqC2A@mail.gmail.com>
[not found] ` <CAPg+sBig9O5+he0PWhTkX5iin14QLz5+eCCu6KfwU=DxntKYtg@mail.gmail.com>
2015-12-21 4:33 ` Pieter Wuille
2015-12-21 4:42 ` Justus Ranvier
2015-12-21 4:44 ` Alex Morcos
2015-12-21 4:50 ` Mark Friedenbach
2015-12-21 5:29 ` Douglas Roark
2015-12-21 5:21 ` Btc Drak
2015-12-21 8:07 ` Anthony Towns
2015-12-21 9:56 ` Jorge Timón
2015-12-08 23:48 ` Jonathan Toomim
2015-12-09 0:23 ` Gregory Maxwell
[not found] ` <CAAS2fgRP8bLWZoKR9-iJS-2RKTGQQ9NG-LpAfa2BOdcR=GuB_A@mail.gmail.com>
2015-12-09 0:40 ` Jonathan Toomim
2015-12-09 12:28 Daniele Pinna
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=201512082348.54788.luke@dashjr.org \
--to=luke@dashjr$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=j@toom$(echo .)im \
/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