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: Wed, 16 Dec 2015 17:09:58 -0500 [thread overview]
Message-ID: <CADm_WcZbbv9zy_5kN264GhYC_kBBr+Leoi0y1PA4pm23CaW3QQ@mail.gmail.com> (raw)
In-Reply-To: <CAPg+sBiVVcNNHuV9e1SaPoDSMEwjZHL7tQiszxbE2SQYp1Ongw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1368 bytes --]
Maybe a new analogy helps.
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.
The fact that separate sets of economic actors and incentives exist is
sufficient to prove it is indeed a basket of goods, not a single good.
On Wed, Dec 16, 2015 at 4:36 PM, Pieter Wuille <pieter.wuille@gmail•com>
wrote:
> Thus, the miners' best strategy is to accept the witness transactions,
> as it allows 1000000/110=9090 transactions rather than
> 1000000/200=5000.
>
Under your blended algorithm, this seems reasonable as a first pass.
> In fact, the optimal fee maximizing strategy is always to maximize fee
> per virtual size.
>
This is a microscopic, not macroscopic analysis. Externalities and long
term incentives can severely perturb or invalidate that line of thinking.
Typical counter-example: Many miners are perfectly happy with very low
fees to encourage long term growth of their bitcoin income through network
effect growth -- rendering fee micro-optimizations largely in the realm of
DoS prevention rather than miner incentive.
[-- Attachment #2: Type: text/html, Size: 2175 bytes --]
next prev parent reply other threads:[~2015-12-16 22:09 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-16 20:38 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 [this message]
2015-12-16 22:10 ` Jeff Garzik
2015-12-17 18:27 ` Jeff Garzik
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_WcZbbv9zy_5kN264GhYC_kBBr+Leoi0y1PA4pm23CaW3QQ@mail.gmail.com \
--to=jgarzik@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=pieter.wuille@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