1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
|
Return-Path: <gmaxwell@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 63133B09
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 8 Dec 2015 05:21:19 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com
[209.85.213.175])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D621FE4
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 8 Dec 2015 05:21:18 +0000 (UTC)
Received: by igvg19 with SMTP id g19so94592982igv.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 07 Dec 2015 21:21:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:sender:in-reply-to:references:date:message-id:subject
:from:to:cc:content-type;
bh=G9jM3BpktRtZITZmHYpM3IKxeczCLIg/byC7SAkZU2s=;
b=ccXe0HKjWcOHoScGhlA3u2AcDUxEWvNxmSjI3eyOAX+yGi+otYAJvSedKWdsFW63N6
VYjG/wJkAicQTPh5vYwOUKIufD31UcuB0evMWDVcXcD+yFno2H8gdcGRIDORUFx8rPdC
yU5MPZv0bZb2CbORyhj/x6uvCh91U2s+Mfe0jLeR3MVE0ZjPGN+glidQ6kRC1HLLLgwx
OvzHF/LIXXJBqta7wHci0r8RKTi8FKCRPKdAPBhFkx70DF+77YnYvX0Ht4CcOhw4ea8Y
bZDvjlgWGSMehcGgsmRU4SqBZJGYLt9bsB6BwToRygEbkkc36MWdUNpM2SuSDlhIMz52
CZDQ==
MIME-Version: 1.0
X-Received: by 10.50.87.100 with SMTP id w4mr20035414igz.62.1449552078361;
Mon, 07 Dec 2015 21:21:18 -0800 (PST)
Sender: gmaxwell@gmail.com
Received: by 10.107.192.70 with HTTP; Mon, 7 Dec 2015 21:21:18 -0800 (PST)
In-Reply-To: <20151208045803.GA1042@sapphire.erisian.com.au>
References: <CAAS2fgQyVs1fAEj+vqp8E2=FRnqsgs7VUKqALNBHNxRMDsHdVg@mail.gmail.com>
<20151208024224.GA32631@sapphire.erisian.com.au>
<20151208045803.GA1042@sapphire.erisian.com.au>
Date: Tue, 8 Dec 2015 05:21:18 +0000
X-Google-Sender-Auth: DtN4eLMJ_m8j2R_aM-KW0RPClh0
Message-ID: <CAAS2fgQUJBZqj7Y_k9cUv+dmqnL-aZG6ySKAr=WFWcO4iGUL_w@mail.gmail.com>
From: Gregory Maxwell <greg@xiph.org>
To: Anthony Towns <aj@erisian.com.au>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Capacity increases for the Bitcoin system.
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Dec 2015 05:21:19 -0000
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.
|
