From: Jeff Garzik <jgarzik@gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Cc: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin
Date: Thu, 17 Dec 2015 13:27:13 -0500 [thread overview]
Message-ID: <CADm_WcbiLCU3yuSfWEJbLDWhfc-9kYFJFCo+fRYyENAsvParng@mail.gmail.com> (raw)
In-Reply-To: <CADm_WcZbbv9zy_5kN264GhYC_kBBr+Leoi0y1PA4pm23CaW3QQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1089 bytes --]
On Wed, Dec 16, 2015 at 5:09 PM, Jeff Garzik <jgarzik@gmail.com> wrote:
> SW presents a blended price and blended basket of two goods. You can
> interact with the Service through the blended price, but that does not
> erase the fact that the basket contains two separate from similar resources.
>
> A different set of economic actors uses one resource, and/or both. There
> are explicit incentives to shift actors from solely using one resource to
> using both.
>
Illustration: If SW is deployed via soft fork, the count of nodes that
validate witness data is significantly lower than the count of nodes that
validate non-witness data. Soft forks are not trustless operation, they
depend on miner trust, slowly eroding the trustless validation of older
nodes over time.
Higher security in one data area versus another produces another economic
value distinction between the two goods in the basket, and creates a "pay
more for higher security in core block, pay less for lower security in
witness" dynamic.
This economic distinction is not present if SW is deployed via hard fork.
[-- Attachment #2: Type: text/html, Size: 1776 bytes --]
next prev parent reply other threads:[~2015-12-17 18:27 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-16 20:38 [bitcoin-dev] Segregated Witness in the context of Scaling Bitcoin Jeff Garzik
2015-12-16 20:50 ` Matt Corallo
2015-12-16 21:51 ` Jameson Lopp
2015-12-16 22:29 ` Matt Corallo
2015-12-16 22:32 ` Matt Corallo
2015-12-17 2:21 ` Jeff Garzik
2015-12-17 2:44 ` Eric Lombrozo
2015-12-17 2:58 ` Jeff Garzik
2015-12-17 3:48 ` Adam Back
2015-12-17 5:32 ` jl2012
2015-12-17 7:54 ` Corey Haddad
2015-12-17 13:09 ` Jorge Timón
2015-12-17 15:51 ` sickpig
2015-12-17 17:55 ` Anthony Towns
2015-12-18 10:01 ` sickpig
2015-12-19 7:50 ` Mark Friedenbach
2015-12-19 23:03 ` Dave Scotese
2015-12-17 9:33 ` Mark Friedenbach
2015-12-17 10:00 ` jl2012
2015-12-17 10:57 ` Anthony Towns
2015-12-17 6:14 ` Marcel Jamin
2015-12-16 20:59 ` Pieter Wuille
2015-12-16 21:27 ` Jeff Garzik
2015-12-16 21:36 ` Pieter Wuille
2015-12-16 22:09 ` Jeff Garzik
2015-12-16 22:10 ` Jeff Garzik
2015-12-17 18:27 ` Jeff Garzik [this message]
2015-12-17 18:46 ` jl2012
2015-12-17 18:52 ` Jeff Garzik
2015-12-17 21:18 ` Eric Lombrozo
2015-12-17 21:31 ` Adam Back
2015-12-17 3:52 ` Anthony Towns
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=CADm_WcbiLCU3yuSfWEJbLDWhfc-9kYFJFCo+fRYyENAsvParng@mail.gmail.com \
--to=jgarzik@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=pieter.wuille@gmail.com \
/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