1 2017-02-25 17:24:12 <tommygunner> evening
 2 2017-02-25 17:24:37 <tommygunner> what happens if i use replace-by-fee but a transaction with the lower fee is confirmed first
 3 2017-02-25 17:25:05 <tommygunner> does the one/the ones with higher fee clear from the mempool automagically or do they hang around
 4 2017-02-25 17:33:21 <arubi> tommygunner, replace by fee also means that you're double spending the low fee transaction, so if it does get confirmed eventually, the higher fee one is no longer valid
 5 2017-02-25 17:34:31 <arubi> they're both valid before one is in a block, but will not appear together in someone's mempool.  only one of them will
 6 2017-02-25 17:34:33 <tommygunner> i think the problem is with the receiving end's implementation
 7 2017-02-25 17:35:18 <arubi> shouldn't be?  they can't live together on the same mempool, and if the "other one" gets in a block, then the one you have will be dropped from your mempool
 8 2017-02-25 17:36:12 <tommygunner> the old ones are still listed on their website as unconfirmed transactions
 9 2017-02-25 17:36:36 <tommygunner> i think i will mail them and ask about replace-by-fee
10 2017-02-25 17:37:15 <arubi> if they are an actual double spend of the one that did get confirmed (one of the inputs is double spent), then yea, not so useful to have the unconfirmed one listed (except for historical use I guess)
11 2017-02-25 17:37:33 <arubi> s/they are/it is
12 2017-02-25 17:38:41 <tommygunner> that would mean the only way to resolve it is wait for a long time until they drop it
13 2017-02-25 17:39:28 <arubi> I don't understand, did the original transaction also pay to them?
14 2017-02-25 17:39:47 <arubi> I guess it did if you used RBF
15 2017-02-25 17:40:37 <arubi> anyway, yea, weird.  if the original one is in a block, then why track this one?  that's what happens when services track txid's instead of supplying the customer with a unique address :)
16 2017-02-25 17:40:39 <tommygunner> its a little bit complicated because it was someone else that did it
17 2017-02-25 17:40:57 <arubi> it doesn't really matter who pays the address
18 2017-02-25 17:41:01 <tommygunner> and the first time it wasnt really a RBF but manually double spending
19 2017-02-25 17:41:05 <tommygunner> with a higher fee
20 2017-02-25 17:41:23 <arubi> oh, so are you sure you paid to their address in both transactions?
21 2017-02-25 17:42:06 <tommygunner> yeah
22 2017-02-25 17:42:47 <arubi> wonder if they used the unconfirmed funds in their own transactions and now have some chain that will never confirm
23 2017-02-25 17:42:48 <tommygunner> that should not have happened, the fee increase should have been done by sending an output to your own address and not to them again
24 2017-02-25 17:43:31 <arubi> the fee increase can be done any way you want
25 2017-02-25 17:43:53 <arubi> the important thing is to actually double spend one of the inputs so that you don't have two independent valid transactions
26 2017-02-25 17:44:55 <tommygunner> the way i did it before RBF was if there was an output in the unconfirmed transaction that i have control over, just send that to myself again with a high enough fee
27 2017-02-25 17:45:06 <arubi> that's CPFP
28 2017-02-25 17:45:58 <tommygunner> yeah the guy i told to do that accidentally sent it to them again
29 2017-02-25 17:46:09 <tommygunner> so its a little bit of a fucked up situation
30 2017-02-25 17:46:36 <arubi> then there are two independent valid transactions, it's neither RBF or CPFP :)
31 2017-02-25 17:46:54 <arubi> unless you mean he used the unconfirmed output to send it to them again?
32 2017-02-25 17:47:16 <arubi> (and not just "send again" which won't use unconfirmed outputs by default)
33 2017-02-25 17:47:45 <tommygunner> yeah the unconfirmed output to them again
34 2017-02-25 17:47:48 <tommygunner> a nice figure 8
35 2017-02-25 17:48:00 <arubi> and you say that one got confirmed?
36 2017-02-25 17:48:23 <arubi> the child has to confirm before the parent (can be on the same block, but physically before it)
37 2017-02-25 17:48:33 <arubi> er, after the parent
38 2017-02-25 17:48:45 <arubi> so, the low fee one has to be confirmed as well
39 2017-02-25 17:48:53 <tommygunner> the CPFP was a RBF
40 2017-02-25 17:49:03 <tommygunner> or something weird
41 2017-02-25 17:49:09 <arubi> makes little sense :)
42 2017-02-25 17:49:48 <tommygunner> obviously the first transaction is confirmed because without that none of the RBF could be
43 2017-02-25 17:50:03 <arubi> nope, in RBF only one transaction confirms
44 2017-02-25 17:50:12 <arubi> with CPFP, both confirm
45 2017-02-25 17:50:30 <arubi> both, or whatever number in the chain.  could also be that the parent is confirmed without the child
46 2017-02-25 17:50:53 <arubi> really I think you just paid twice :)
47 2017-02-25 18:06:40 <tommygunner> yes but i can withdraw again, or rather he
48 2017-02-25 18:06:49 <tommygunner> but only if the transactions are all confirmed
49 2017-02-25 18:10:01 <arubi> sounds like your problem isn't very related to bitcoin development, try emailing that service
50 2017-02-25 18:10:36 <tommygunner> yeah i know, i just wanted some general info about rbf
51 2017-02-25 18:11:07 <tommygunner> thanks for chatting, heh
52 2017-02-25 19:05:07 <arubi> oh np