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
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
|
Return-Path: <dkbryant@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 9F439BA2
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 6 Jul 2015 04:14:15 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f53.google.com (mail-oi0-f53.google.com
[209.85.218.53])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BD88B1FD
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 6 Jul 2015 04:14:14 +0000 (UTC)
Received: by oiaf66 with SMTP id f66so77886417oia.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 05 Jul 2015 21:14:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:reply-to:in-reply-to:references:date:message-id
:subject:from:to:content-type;
bh=h+Q82bsShOgOq1FNW1tRoUPX5G3hQfyfmXq57AFyf+U=;
b=Sz4/F+HggEqrdI/V8/6qj/CowAxDpSNhl9Zz5mZcWTH7P+gqqjqIWvFYkU+Z3+cmF5
AXUyRf2CCPOh92AESzz6xccQ5k3ora8WSxm5q+3ZnHW5XOXZpUDVQsdGOvsLpx0U6bBP
b1KKVQndZ0cvmG6Sc20iT356JNAzRJ5ycJzskLX6oYvQ6rHYpR+wbhmV9c0djDEzJOP+
Pxvx4JVdZ7TlF5KdqcUPwNj6Y68sddzWvndSD27XynsEQXrW7L9ZMwNbIBSKxhls/WMq
IhRSU8sIWu88RV1YbXDnpQ6cFDdYTOyX6BbGPvBcFi0gtrGirOMDLS4Qxt4wubN+JjNJ
G86g==
MIME-Version: 1.0
X-Received: by 10.182.134.130 with SMTP id pk2mr47572365obb.4.1436156054123;
Sun, 05 Jul 2015 21:14:14 -0700 (PDT)
Received: by 10.76.69.229 with HTTP; Sun, 5 Jul 2015 21:14:14 -0700 (PDT)
In-Reply-To: <20150703215658.GC5916@muck>
References: <CAAUFj10D37A1kfqFNPWz6bOMYSFXQbecJ+RxxOnw6HtwUg70mg@mail.gmail.com>
<CAOG=w-swH-_cD00Xy5yCN7LebeQSh-oG0gXFM6LxNSDwQZ64Tw@mail.gmail.com>
<20150703215658.GC5916@muck>
Date: Sun, 5 Jul 2015 23:14:14 -0500
Message-ID: <CAAUFj11AM3eCX=GDn6384qCi8yKX1jMDF-Jaw2SGemm_HSis9A@mail.gmail.com>
From: Dan Bryant <dkbryant@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, 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
Subject: Re: [bitcoin-dev] REQ BIP # / Discuss - Sweep incoming unconfirmed
transactions with a bounty.
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: DKBryant@gmail.com
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: Mon, 06 Jul 2015 04:14:15 -0000
On Wed, Jul 01, 2015 at 09:52:57PM -0700, Mark Friedenbach wrote:
> This is called child pays for parent and there is a three year old pull
> request implementing it:
>
> https://github.com/bitcoin/bitcoin/pull/1647
Understood... When I wrote the BIP proposal I was assuming
(incorrectly) that CPFP TX selection was already being done by miners,
but I see now that certain trees could bloom the TX selection latency
as miners would need to be more dependency aware. Perhaps the BIP66
orphan block chain shows that some miners may not always be counted on
to ensure that all TX stuffed in a block have dependencies met.
Certainly not until the PR1647 is fully merged and deployed.
On Wed, Jul 1, 2015 at 11:57 PM, Matt Whitlock <bip@mattwhitlock.name> wrote:
> PR#1647 only addresses miner policy, though, right? I believe the BIP is
> addressing the user-facing side of this functionality. CPFP mining policy
> does very little good if wallets don't offer any way for users to goose up
> incoming transactions.
On Wed, Jul 01, 2015 at 09:52:57PM -0700, Mark Friedenbach wrote:
> The points regarding sweep transaction UI is out of scope for a BIP I'm
> afraid. I suggest talking with wallet authors, and if agreement can be
> found writing a pull request.
Yes... although I certainly admit, I didn't know about CPFP or I would
have called it out as a requirement for this UI enhancement request.
I'll see if I can't get some wallet authors interested in this as a
feature enhancement when PR1647 commits.
Perhaps there are risks raised if CPFP is not enabled but these sweep
tx enter the mempool. If miners take the high fee "children" but
ignore the low fee "parents" then the child might enter the blockchain
without the parent. If miners were light on block validation,
wouldn't it be possible that the child may go forward with many
confirmations, while the parent patiently waits in the mempool? This
could be bad since spending the child may look good, as it might have
many confirmations, while its parent has few.
On Fri, Jul 3, 2015 at 4:56 PM, Peter Todd <pete@petertodd.org> wrote:
> "Replace-by-fee scorched-earth without child-pays-for-parent",
> Peter Todd, Bitcoin-development mailing list, Apr 28th 2014
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-April/005620.html
Very good! So if I follow, RPF can work one of two ways:
In the "countermeasure" form, spender gives receiver a partially
signed "countermeasure" transactions with juiced up fees.
In the "anyonecanpay" form, spender signs the transaction with
ANYONECANPAY bit allowing the reviver to add fees at will.
One question I did have about RBF is this.. Is it correct to presume
that the spender doesn't send the incomplete "countermeasure"
transaction to the network? If they did, wouldn't they get flagged on
DoS code banning them from peers?
Corollary question. If the "countermeasure" transaction is not
broadcast, is it sent to the receiver via back channel (email, etc)
I'll try to clean up the draft BIP to include CPFP dependencies and
RBF capabilities. Whether it belongs in a BIP or a PR, its just a doc
to outline my thoughts at this point. Not burning a whole in my head,
so may take some time.
Thx.
|
