From: Gregory Maxwell <greg@xiph•org>
To: Anthony Towns <aj@erisian•com.au>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Capacity increases for the Bitcoin system.
Date: Tue, 8 Dec 2015 05:21:18 +0000 [thread overview]
Message-ID: <CAAS2fgQUJBZqj7Y_k9cUv+dmqnL-aZG6ySKAr=WFWcO4iGUL_w@mail.gmail.com> (raw)
In-Reply-To: <20151208045803.GA1042@sapphire.erisian.com.au>
On Tue, Dec 8, 2015 at 4:58 AM, Anthony Towns via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> Having a cost function rather than separate limits does make it easier to
> build blocks (approximately) optimally, though (ie, just divide the fee by
> (base_bytes+witness_bytes/4) and sort). Are there any other benefits?
Actually being able to compute fees for your transaction: If there are
multiple limits that are "at play" then how you need to pay would
depend on the entire set of other candidate transactions, which is
unknown to you. Avoiding the need for a fancy solver in the miner is
also virtuous, because requiring software complexity there can make
for centralization advantages or divert development/maintenance cycles
in open source software off to other ends... The multidimensional
optimization is harder to accommodate for improved relay schemes, this
is the same as the "build blocks" but much more critical both because
of the need for consistency and the frequency in which you do it.
These don't, however, apply all that strongly if only one limit is
likely to be the limiting limit... though I am unsure about counting
on that; after all if the other limits wouldn't be limiting, why have
them?
> That seems kinda backwards.
It can seem that way, but all limiting schemes have pathological cases
where someone runs up against the limit in the most costly way. Keep
in mind that casual pathological behavior can be suppressed via
IsStandard like rules without baking them into consensus; so long as
the candidate attacker isn't miners themselves. Doing so where
possible can help avoid cases like the current sigops limiting which
is just ... pretty broken.
next prev parent reply other threads:[~2015-12-08 5:21 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 [this message]
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
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='CAAS2fgQUJBZqj7Y_k9cUv+dmqnL-aZG6ySKAr=WFWcO4iGUL_w@mail.gmail.com' \
--to=greg@xiph$(echo .)org \
--cc=aj@erisian$(echo .)com.au \
--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