Transcript for #bitcoin-dev 2017/05/01

05:18 CryptAxe Question for any core dev(s):
05:18 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?
05:30 kallewoof They're super trivial to review and typos are ugly so I'm all for them personally.
05:45 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 :)
07:32 wumpus they're welcome, but try not to overdo it - my suggestion would be to save them up over some period of time
07:32 wumpus e.g. keep notes, then fix in one PR
07:33 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
11:07 comboy what am I misunderstanding? is ANYONECANPAY not allwed without some other sighash type with STRICTENC?
11:19 comboy ok, found the relevant part in BIP62, it appears that's the case
11:46 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)
12:16 fnb_theory hey guys, can the order of input transactions change once the transaction has been submitted to the mempool?
12:43 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?
12:50 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.
13:03 afk11 if no one else can sign for your inputs, then no one can tamper with that order
13:06 fnb_theory afk11: thanks. If i understad correctly, ANYONECANPAY allows people to add inputs. Does this apply somehow to transactions already in the mempool?
13:10 afk11 only if your signatures use ANYONECANPAY. if one was ALL then adding an input would invalidate existing sigs
13:10 fnb_theory afk11: So a transaction can be edited while in the mempool if the sighash is ANYONECANPAY?
13:11 afk11 yea, though it's a double spend, so mightn't propagate very well
13:11 afk11 give it a try ;)
13:12 afk11 edited is a strong word. you're not replacing it, you're competing with it.
13:12 fnb_theory hmmm... I see, but the old transaction will still exist in the mempool?
13:12 fnb_theory you'll have two then or what?
13:13 fnb_theory one with the old data and one with the new?
13:13 afk11 yea
13:13 fnb_theory with the intention that the new one goes through?
13:13 afk11 I dunno what you're doing, why is replacement/ANYONECANPAY an issue?
13:15 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".
13:16 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
13:17 goatpig if you are using sighash_all you won't have any issues
13:17 goatpig if you are using weird sighash types like ANYONECANPAY, then it gets more complicated
13:17 fnb_theory goatpig: I won't have control over that. How so?
13:18 goatpig why would you not have control over it? are you not emitting the transaction?
13:18 fnb_theory goatpig: no
13:18 goatpig ok then this is part of some sort of protocol of yours that participants have to follow?
13:19 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.
13:19 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.
13:19 goatpig as afk11 was sying ANYONECANPAY can have other users submit inputs
13:20 fnb_theory goatpig: okay cool
13:20 goatpig otherwise, a RBF transaction can be double spent, hence inputs can change/get reorderer
13:20 goatpig in both cases you can know this
13:20 goatpig and this only ever applies to mempool tx
13:21 fnb_theory goatpig: What happens to the old transaction of an RBF transaction occurs?
13:21 goatpig baring these 2 cases, the order cannot change
13:21 goatpig depends
13:21 goatpig at the node level
13:21 goatpig RBF compliant nodes will outright replace the old one with the new one
13:21 goatpig non compliant nodes like BU do not relay the second RBF
13:21 goatpig ie the replacement
13:21 goatpig at the miner level
13:22 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?
13:22 goatpig you can only speculate their tx selection code will pick up the more rewarding tx, ie the replacement
13:22 goatpig Core's GUI keeps track of replacements I believe
13:22 goatpig as for the tx
13:22 goatpig it won't be in the mempool anymore i believe
13:22 goatpig the old one that is
13:23 fnb_theory goatpig: okay, so the re-ordering can occur when mined?
13:23 goatpig cause it would conflict with the replacement
13:23 goatpig well assuming you didn't see the replacement/double spend, it is possible for the tx to change
13:23 goatpig ie there is guarantee what's in your mempool is what is going to get mined
13:23 goatpig at this point it's only an indication of outputs being signed for
13:23 goatpig there is no guarantee*
13:24 fnb_theory goatpig: so if you see the new tx in the mempool, that's the structure it'll have once mined?
13:24 fnb_theory goatpig: oh right
13:24 goatpig not unless you have nefarious actors
13:24 goatpig or people cooperating in private
13:24 goatpig to double spend what the network sees
13:24 fnb_theory goatpig: and if the sighash is anyonecanpay it won't invalidate the signatures?
13:25 fnb_theory goatpig: the re-ordering
13:25 goatpig adding inputs to a transaction with a signed anyonecanpay input won't invalidate this one input
13:26 fnb_theory goatpig: and not the other inputs either?
13:26 goatpig you still have to look at other inputs in that tx
13:26 goatpig each input has its own sighash
13:26 fnb_theory right...
13:26 goatpig so mixing anyonecanpay with sighash_all has no real effect per se
13:27 fnb_theory so how does re-ordering then occur?
13:27 goatpig if ALL inputs in that one tx are anyonecanpay
13:27 fnb_theory ah okay.
13:27 goatpig you can keep on adding anyonecanpay inputs to it
13:27 fnb_theory I got it
13:27 fnb_theory thanks mate
13:27 goatpig up until the point someone adds a more binding input
13:27 goatpig consider it's unlikely though
13:28 fnb_theory okay cool. Shot goatpig and afk11 I get it now :)
13:28 goatpig those added coins would be burned as fee