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
92
93
94
|
Return-Path: <luke@dashjr.org>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 6179DC002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 27 Oct 2022 18:27:04 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 461D9410A4
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 27 Oct 2022 18:27:04 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 461D9410A4
Authentication-Results: smtp4.osuosl.org;
dkim=pass (1024-bit key) header.d=dashjr.org header.i=@dashjr.org
header.a=rsa-sha256 header.s=zinan header.b=E2XJf2TV
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -4.401
X-Spam-Level:
X-Spam-Status: No, score=-4.401 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001,
RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id Ycyj-89AAS52
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 27 Oct 2022 18:27:02 +0000 (UTC)
X-Greylist: delayed 00:07:47 by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org B4A6E40951
Received: from zinan.dashjr.org (zinan.dashjr.org [IPv6:2001:470:88ff:2f::1])
by smtp4.osuosl.org (Postfix) with ESMTP id B4A6E40951
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 27 Oct 2022 18:27:01 +0000 (UTC)
Received: from ishibashi.lan (unknown [12.151.133.18])
(Authenticated sender: luke-jr)
by zinan.dashjr.org (Postfix) with ESMTPSA id 1E72F38AF2EF;
Thu, 27 Oct 2022 18:17:40 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dashjr.org; s=zinan;
t=1666894753; bh=9gdctc9Honnne/qP9P1t6R/Txmad1sd76VgyqTeq+dA=;
h=From:To:Subject:Date:Cc:References:In-Reply-To;
b=E2XJf2TVQcGHW3WrkUlKeXSGAaV0nkWDPJLrnuxrbCMXIci3SfzJ9qK4xtfWfY1UH
1R9S3bDHwyUCAkGqSBBzrWlzYQQWGbmYiV+Vxe8I4vkANLlNgvwPs2cktyB1UmGe11
AdDlyCDRQu2RaivwrUsawRrsMd6TVspq7swvRvBE=
X-Hashcash: 1:25:221027:bitcoin-dev@lists.linuxfoundation.org::knuCrAY=+lT0lrZS:aRyiW
X-Hashcash: 1:25:221027:aj@erisian.com.au::/NLW=bNqMiemBGk2:4nUh
X-Hashcash: 1:25:221027:gloriajzhao@gmail.com::9A9grea120zMTkJM:eGh/c
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org,
Anthony Towns <aj@erisian.com.au>
Date: Thu, 27 Oct 2022 18:17:38 +0000
User-Agent: KMail/1.9.10
References: <Y1nIKjQC3DkiSGyw@erisian.com.au>
<CAFXO6=+Bjr_nuy+24VZR-zE3=Heii_NJxWPdiJTJW6ZgWbZ8rA@mail.gmail.com>
<Y1qlt6uX5Iccuxkc@erisian.com.au>
In-Reply-To: <Y1qlt6uX5Iccuxkc@erisian.com.au>
X-KMail-QuotePrefix: >
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <202210271817.39141.luke@dashjr.org>
Subject: Re: [bitcoin-dev] On mempool policy consistency
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol 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: Thu, 27 Oct 2022 18:27:04 -0000
More generally, some of the arguments against full RBF seem like debatable
reasons (though not fully convincing) to possibly leave it off, and/or
disabled by default, but definitely NOT reasons to remove the option and
prevent users from deciding for themselves.
On Thursday 27 October 2022 15:37:27 Anthony Towns via bitcoin-dev wrote:
> "Can I prevent someone else's transaction from propagating" is almost
> the entirety of the question with -datacarrier, -datacarriersize and
> -permitbaremultisig though:
Not necessarily the entirety, no. Even if others would propagate it, you also
don't want to waste _your_ bandwidth doing so. This also reveals a difference
between the two policies: with RBF, you have _already_ spent resources
propagating the first transaction (what this implies is not immediately
obvious).
Luke
|
