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
95
96
|
Return-Path: <dp@simplexum.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 7FC18C016F
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 8 Jun 2020 07:12:17 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 7C7718669E
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 8 Jun 2020 07:12:17 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id sVWPnqChFVrY
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 8 Jun 2020 07:12:16 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.ruggedbytes.com (mail.ruggedbytes.com [88.99.30.248])
by whitealder.osuosl.org (Postfix) with ESMTPS id BBE1186505
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 8 Jun 2020 07:12:16 +0000 (UTC)
Received: from mail.ruggedbytes.com (localhost [127.0.0.1])
by mail.ruggedbytes.com (Postfix) with ESMTPS id 311D82600237;
Mon, 8 Jun 2020 07:12:14 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simplexum.com;
s=mail; t=1591600334;
bh=PzsM04c0c2R/ggzlq0FuK5K2pu3ztPH5jiQCdkUDX7w=;
h=Date:From:To:Cc:Subject:In-Reply-To:References;
b=HQU3AHGnnfcSF+KpbIv2fiQ2d60cCmkz5HCzhDz4hgCUDdWpMGSLYdBDZyUB8Nc2T
Sb9SHFIUbCt4qvKJfKUmfgKw2DlExigddUrSbAWTvd/nY1ZW13xtSet8Y8ufUZBOhO
m9plc3BIalpNrKTdDfv4vacx33Ej1aon67KfZGk8=
Date: Mon, 8 Jun 2020 12:15:11 +0500
From: Dmitry Petukhov <dp@simplexum.com>
To: bitcoin-dev@lists.linuxfoundation.org
Message-ID: <20200608121511.4dbadea8@simplexum.com>
In-Reply-To: <CAD5xwhjhcSDX_e8RFHveOdEEwC6YTe8kPaUw_egKkrdE0fVe1w@mail.gmail.com>
References: <CAD5xwhjXidpeLLUr4TO30t7U3z_zUxTpU9GBpLxu3MWX3ZFeTA@mail.gmail.com>
<1cQUGt1pX0_lWPJm-tFDr9fQCvrPd5vqmCorgN89jy7gUF0m9wsouUosrFm1eal3jO9oB1BvMtORGE2htLdFjyDD5lno_QkXCFn971LQNZY=@protonmail.com>
<CAD5xwhhZyAkQE3DpLku_xrOnixL344AqkWB=+a=fOBbekobY6g@mail.gmail.com>
<20200608110545.078f8e81@simplexum.com>
<CAD5xwhjhcSDX_e8RFHveOdEEwC6YTe8kPaUw_egKkrdE0fVe1w@mail.gmail.com>
Organization: simplexum.com
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Mon, 08 Jun 2020 07:33:57 +0000
Subject: Re: [bitcoin-dev] [was BIP OP_CHECKTEMPLATEVERIFY] Fee Bumping
Operation
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: Mon, 08 Jun 2020 07:12:17 -0000
=D0=92 Sun, 7 Jun 2020 23:43:39 -0700
Jeremy via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > PFN transaction would still be valid if some of 'ghost parents' are
> > =20
> already confirmed, so the miners could have more fees than strictly
> necessary. But this is the same as with CPFP.
>=20
> This is problematic and can't be done as it requires a new index of
> all past txns for consensus.
If the logic would match CPFP, then PFN would be valid if some of the
'ghost parents' are confirmed, but would be invalid if some of them are
spent. I believe in this case txindex won't be required.
> My thinking is that a Fee Bump transaction can name a list of TXIDs
> (Or one TXID which implies all ancestors of) that it wishes to be
> included in a block with. It must be included in that block. A Fee
> Bump transaction may have no unconfirmed ancestors nor any children.
> Potentially, it also may not be RBF'd. You treat the Fee Bump
> Transactions as the lowest descendant of whatever it targets and then
> set it's feerate/total fee based on the package that would have to
> co-confirm for it to be worth mining. This makes it sort like normal
> transactions for inclusion. You can require some minimums for mempool
> inclusion at all.
>=20
> If it's target is confirmed or replaced, it should drop from the
> mempool.
Re "may not be RBF'd": What if the sender of PFN tx wants to increase
the fee it offers for the 'ghost parents'? RBF-ing PFN tx itself seems
like less wasteful way than RBF-ing some of the parents/'ghost parents'
just for this purpose. Sometimes I think the sender of PFN will not be
even able to replace any other transactions beside their own PFN tx
(like when they offer 'fee bumping' service for others)
|
