1 2017-05-01 05:18:55 <CryptAxe> How annoying are PR's for spelling fixes? I notice tiny issues sometimes and I've tried not to keep opening PR's that change a single character or word. Do you guys want pull requests for that or does it waste more of your time than it's worth?
 2 2017-05-01 05:18:55 <CryptAxe> Question for any core dev(s):
 3 2017-05-01 05:30:54 <kallewoof> They're super trivial to review and typos are ugly so I'm all for them personally.
 4 2017-05-01 05:45:49 <CryptAxe> Thank you, I feel the same way but I'm not on the receiving end of the PR so I thought I should at least ask :)
 5 2017-05-01 07:32:16 <wumpus> they're welcome, but try not to overdo it - my suggestion would be to save them up over some period of time
 6 2017-05-01 07:32:23 <wumpus> e.g. keep notes, then fix in one PR
 7 2017-05-01 07:33:20 <wumpus> that's how I do it at least, I feel opening a PR for changing a single letter distracts from more serious work devs are doing, and I feel the same when on the receiving end
 8 2017-05-01 11:07:05 <comboy> what am I misunderstanding? is ANYONECANPAY not allwed without some other sighash type with STRICTENC?
 9 2017-05-01 11:19:52 <comboy> ok, found the relevant part in BIP62, it appears that's the case
10 2017-05-01 11:46:53 <comboy> btw, checked by modifying the source and it doesn't seem to be covered by any test case, if it's welcomed I can try to add some cases to script_tests.json (after collecting some more, I think I had some other things too)
11 2017-05-01 12:16:14 <fnb_theory> hey guys, can the order of input transactions change once the transaction has been submitted to the mempool?
12 2017-05-01 12:43:59 <afk11> fnb_theory, you need to sign a new transaction, and would likely be classed as a double spend. what exactly are you trying to accomplish?
13 2017-05-01 12:50:31 <fnb_theory> afk11: I don't want to change the input order. I want to use it as an identifier for something. So I need to know, if the order will change or not. If I can rely on that order remaining the same, once the transaction has been submitted to a node.
14 2017-05-01 13:03:39 <afk11> if no one else can sign for your inputs, then no one can tamper with that order
15 2017-05-01 13:06:33 <fnb_theory> afk11: thanks. If i understad correctly, ANYONECANPAY allows people to add inputs. Does this apply somehow to transactions already in the mempool?
16 2017-05-01 13:10:09 <afk11> only if your signatures use ANYONECANPAY. if one was ALL then adding an input would invalidate existing sigs
17 2017-05-01 13:10:54 <fnb_theory> afk11: So a transaction can be edited while in the mempool if the sighash is ANYONECANPAY?
18 2017-05-01 13:11:48 <afk11> yea, though it's a double spend, so mightn't propagate very well
19 2017-05-01 13:11:50 <afk11> give it a try ;)
20 2017-05-01 13:12:23 <afk11> edited is a strong word. you're not replacing it, you're competing with it.
21 2017-05-01 13:12:43 <fnb_theory> hmmm... I see, but the old transaction will still exist in the mempool?
22 2017-05-01 13:12:56 <fnb_theory> you'll have two then or what?
23 2017-05-01 13:13:02 <fnb_theory> one with the old data and one with the new?
24 2017-05-01 13:13:03 <afk11> yea
25 2017-05-01 13:13:23 <fnb_theory> with the intention that the new one goes through?
26 2017-05-01 13:13:39 <afk11> I dunno what you're doing, why is replacement/ANYONECANPAY an issue?
27 2017-05-01 13:15:43 <fnb_theory> as I said. I am doing verification of sorts on the transaction inputs based on their order. This, I understand is not normal, but it's part of a bigger process. So let's say for arguments sake that I identify the first transaction as "x" (using sha256) because it has transation inputs in order "12345". If that order changes and I get "54321" then I will end up with and ID of "y".
28 2017-05-01 13:16:07 <fnb_theory> I don't want to change the inputs myself. Nor can I in my application, nor do i care. But I need to understand the input order of the transaction IDs
29 2017-05-01 13:17:17 <goatpig> if you are using sighash_all you won't have any issues
30 2017-05-01 13:17:37 <goatpig> if you are using weird sighash types like ANYONECANPAY, then it gets more complicated
31 2017-05-01 13:17:59 <fnb_theory> goatpig: I won't have control over that. How so?
32 2017-05-01 13:18:13 <goatpig> why would you not have control over it? are you not emitting the transaction?
33 2017-05-01 13:18:25 <fnb_theory> goatpig: no
34 2017-05-01 13:18:46 <goatpig> ok then this is part of some sort of protocol of yours that participants have to follow?
35 2017-05-01 13:19:26 <fnb_theory> goatpig: no :) I just want to understand under what circumstances the input order can change, if it is common and if it does change, how it changes and why.
36 2017-05-01 13:19:45 <fnb_theory> goatpig: if the answer is, it just changes because it feels like it. Then I'm okay with that. I just need to know.
37 2017-05-01 13:19:57 <goatpig> as afk11 was sying ANYONECANPAY can have other users submit inputs
38 2017-05-01 13:20:23 <fnb_theory> goatpig: okay cool
39 2017-05-01 13:20:24 <goatpig> otherwise,  a RBF transaction can be double spent, hence inputs can change/get reorderer
40 2017-05-01 13:20:42 <goatpig> in both cases you can know this
41 2017-05-01 13:20:49 <goatpig> and this only ever applies to mempool tx
42 2017-05-01 13:21:02 <fnb_theory> goatpig: What happens to the old transaction of an RBF transaction occurs?
43 2017-05-01 13:21:03 <goatpig> baring these 2 cases, the order cannot change
44 2017-05-01 13:21:18 <goatpig> depends
45 2017-05-01 13:21:23 <goatpig> at the node level
46 2017-05-01 13:21:38 <goatpig> RBF compliant nodes will outright replace the old one with the new one
47 2017-05-01 13:21:48 <goatpig> non compliant nodes like BU do not relay the second RBF
48 2017-05-01 13:21:50 <goatpig> ie the replacement
49 2017-05-01 13:21:56 <goatpig> at the miner level
50 2017-05-01 13:22:23 <fnb_theory> goatpig: so anyone running core would only ever see that one transaction, even if it gets replaced, they don't see the old one, just the new one right?
51 2017-05-01 13:22:23 <goatpig> you can only speculate their tx selection code will pick up the more rewarding tx, ie the replacement
52 2017-05-01 13:22:43 <goatpig> Core's GUI keeps track of replacements I believe
53 2017-05-01 13:22:51 <goatpig> as for the tx
54 2017-05-01 13:22:57 <goatpig> it won't be in the mempool anymore i believe
55 2017-05-01 13:22:59 <goatpig> the old one that is
56 2017-05-01 13:23:05 <fnb_theory> goatpig: okay, so the re-ordering can occur when mined?
57 2017-05-01 13:23:07 <goatpig> cause it would conflict with the replacement
58 2017-05-01 13:23:29 <goatpig> well assuming you didn't see the replacement/double spend, it is possible for the tx to change
59 2017-05-01 13:23:38 <goatpig> ie there is guarantee what's in your mempool is what is going to get mined
60 2017-05-01 13:23:52 <goatpig> at this point it's only an indication of outputs being signed for
61 2017-05-01 13:23:59 <goatpig> there is no guarantee*
62 2017-05-01 13:24:13 <fnb_theory> goatpig: so if you see the new tx in the mempool, that's the structure it'll have once mined?
63 2017-05-01 13:24:18 <fnb_theory> goatpig: oh right
64 2017-05-01 13:24:28 <goatpig> not unless you have nefarious actors
65 2017-05-01 13:24:39 <goatpig> or people cooperating in private
66 2017-05-01 13:24:44 <goatpig> to double spend what the network sees
67 2017-05-01 13:24:49 <fnb_theory> goatpig: and if the sighash is anyonecanpay it won't invalidate the signatures?
68 2017-05-01 13:25:01 <fnb_theory> goatpig: the re-ordering
69 2017-05-01 13:25:38 <goatpig> adding inputs to a transaction with a signed anyonecanpay input won't invalidate this one input
70 2017-05-01 13:26:12 <fnb_theory> goatpig: and not the other inputs either?
71 2017-05-01 13:26:15 <goatpig> you still have to look at other inputs in that tx
72 2017-05-01 13:26:31 <goatpig> each input has its own sighash
73 2017-05-01 13:26:45 <fnb_theory> right...
74 2017-05-01 13:26:51 <goatpig> so mixing anyonecanpay with sighash_all has no real effect per se
75 2017-05-01 13:27:04 <fnb_theory> so how does re-ordering then occur?
76 2017-05-01 13:27:15 <goatpig> if ALL inputs in that one tx are anyonecanpay
77 2017-05-01 13:27:22 <fnb_theory> ah okay.
78 2017-05-01 13:27:24 <goatpig> you can keep on adding anyonecanpay inputs to it
79 2017-05-01 13:27:26 <fnb_theory> I got it
80 2017-05-01 13:27:30 <fnb_theory> thanks mate
81 2017-05-01 13:27:33 <goatpig> up until the point someone adds a more binding input
82 2017-05-01 13:27:54 <goatpig> consider it's unlikely though
83 2017-05-01 13:28:10 <fnb_theory> okay cool. Shot goatpig and afk11 I get it now :)
84 2017-05-01 13:28:13 <goatpig> those added coins would be burned as fee