1 2016-07-22 09:46:12	0|GitHub78|13bitcoin/06master 14b50e1ac 15Jonas Schnelli: [Wallet] Correct hdmasterkeyid/masterkeyid name confusion
  2 2016-07-22 09:46:12	0|GitHub78|[13bitcoin] 15jonasschnelli pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/381917f610e3...0df9ea42b888
  3 2016-07-22 09:46:13	0|GitHub78|13bitcoin/06master 140df9ea4 15Jonas Schnelli: Merge #8390: [Wallet] Correct hdmasterkeyid/masterkeyid name confusion...
  4 2016-07-22 09:46:22	0|GitHub185|[13bitcoin] 15jonasschnelli closed pull request #8390: [Wallet] Correct hdmasterkeyid/masterkeyid name confusion (06master...062016/07/hd_masterkeyrename) 02https://github.com/bitcoin/bitcoin/pull/8390
  5 2016-07-22 09:46:49	0|jonasschnelli|wumpus: should I open a PR for the 0.13 backport of https://github.com/bitcoin/bitcoin/pull/8390? Or how do you do this normally?
  6 2016-07-22 10:53:08	0|btcdrak|jonasschnelli: if it cherry-picks cleanly he can just cherry-pick.
  7 2016-07-22 13:46:26	0|sipa|wumpus: there is much more wrong with the best chain activation...
  8 2016-07-22 13:46:48	0|sipa|wumpus: it's apparently doing the activation from within the 'check the blockchain at startup' phase
  9 2016-07-22 13:46:59	0|sipa|if you reindex
 10 2016-07-22 14:09:04	0|GitHub135|[13bitcoin] 15sipa opened pull request #8392: Fix several node initialization issues (06master...06fixactivatewait) 02https://github.com/bitcoin/bitcoin/pull/8392
 11 2016-07-22 14:22:06	0|instagibbs|jl2012, longer term we should probably just check up to what version of witness has been softforked, and then make those witness programs standard. Otherwise each version SF will require a similar PR
 12 2016-07-22 14:23:44	0|jl2012|instagibbs: that should be part of the next softfork
 13 2016-07-22 15:22:33	0|GitHub93|[13bitcoin] 15sipa opened pull request #8393: Support for compact blocks together with segwit (06master...06segwitcb) 02https://github.com/bitcoin/bitcoin/pull/8393
 14 2016-07-22 15:23:44	0|instagibbs|so, did no one scream for a SW backport?
 15 2016-07-22 15:24:26	0|sipa|i started writing one; i don't think the actual backport will be hard
 16 2016-07-22 15:24:39	0|sipa|getting review for it will be
 17 2016-07-22 15:25:24	0|instagibbs|indeed
 18 2016-07-22 15:25:54	0|sipa|i'll continue working on it, but it's not my highest priority
 19 2016-07-22 15:26:13	0|btcdrak|sipa: is #8393 unchanged from when we were testing segwitcb a while ago?
 20 2016-07-22 15:26:27	0|sipa|btcdrak: yup, only trivial rebase + squash
 21 2016-07-22 15:56:42	0|btcdrak|sipa: Travis needs a gentle tap on #8393 - the last job barfed for no good reason
 22 2016-07-22 16:13:00	0|instagibbs|while we're improving CB, lets get https://github.com/bitcoin/bitcoin/pull/8235 if for nothing else me not having to scan the source to figure out how to log debug messages :P
 23 2016-07-22 16:52:49	0|sipa|instagibbs: good idea
 24 2016-07-22 17:08:35	0|pedrobranco|\cl
 25 2016-07-22 17:26:49	0|achow101|I'm doing some stuff for segwit with Armory, and one part of it is sending a getdata message to bitcoin core about a transaction that it just sent. The transaction was clearly accepted by core (I see it in the transaction list) but it keeps returning a notfound message. Any reason why?
 26 2016-07-22 17:28:32	0|sipa|achow101: is this only for segwit, or generally true?
 27 2016-07-22 17:29:12	0|sipa|achow101: is this from the same node that sent the transaction?
 28 2016-07-22 17:29:22	0|achow101|I think it is only for segwit, I haven't seen this behavior anywhere else, but I'm not sure
 29 2016-07-22 17:29:39	0|sipa|there have been significant changes to tx relay in 0.13
 30 2016-07-22 17:29:51	0|sipa|you can only query for transactions now after they've been inved to you for privacy reasons
 31 2016-07-22 17:30:02	0|sipa|but if you're the sender yourself that doesn't make much sense
 32 2016-07-22 17:30:41	0|achow101|no, Armory is the sender. It connects as another node. It sends the transaction then asks for it back to check that it was accepted
 33 2016-07-22 17:33:27	0|sipa|let me check
 34 2016-07-22 17:37:32	0|sipa|achow101: if you wait a few seconds, that should work
 35 2016-07-22 17:37:48	0|achow101|how so?
 36 2016-07-22 17:37:56	0|sipa|can you test whether that's the case?
 37 2016-07-22 17:38:07	0|achow101|I can try
 38 2016-07-22 17:38:20	0|sipa|we delay inserting the transaction into the relay pool until we actually relay it somewhere
 39 2016-07-22 17:38:30	0|sipa|but there is a randomized delay before that happens
 40 2016-07-22 17:39:26	0|sipa|it's probably easier to check for a reject message instead...
 41 2016-07-22 17:40:17	0|achow101|what is the longest the randomized delay can be?
 42 2016-07-22 17:40:33	0|sipa|infinity
 43 2016-07-22 17:40:37	0|sipa|it's poisson distributed
 44 2016-07-22 17:40:41	0|achow101|great...
 45 2016-07-22 17:40:45	0|sipa|but on average it's 5 to 10 seconds
 46 2016-07-22 17:42:28	0|sipa|as an alternative, you can send a ping after the getdata, and if the pong returns before you get a reject message, the transaction is accepted
 47 2016-07-22 17:43:17	0|sipa|or even better, check whether _other_ peers inv the transaction back to you
 48 2016-07-22 17:43:39	0|sipa|that way you can actually see whether it propagated across the network
 49 2016-07-22 17:43:49	0|goatpig|hi
 50 2016-07-22 17:44:16	0|goatpig|@anchow i fixed that in the upcoming version, don't bother with it
 51 2016-07-22 17:44:25	0|achow101|ok
 52 2016-07-22 17:50:47	0|jtimon|NicolasDorier: is your comment https://github.com/bitcoin/bitcoin/pull/8391#issuecomment-234586998 regarding my comment in https://github.com/bitcoin/bitcoin/pull/8391#discussion_r71896343 ?
 53 2016-07-22 17:51:33	0|jtimon|bip34Hash can still be deleted, right?
 54 2016-07-22 18:23:33	0|gmaxwell|petertodd: CodeShark: http://www.coindesk.com/bitcoin-core-ethereum-hard-fork-unsettling-precedent/ why are you making untrue statements to the media about hardforks in Bitcoin in the past?
 55 2016-07-22 18:26:00	0|instagibbs|lack of quotation makes me think of a noisy channel output
 56 2016-07-22 18:32:52	0|CodeShark|gmaxwell: I got misquoted
 57 2016-07-22 18:33:00	0|CodeShark|talking to the author now
 58 2016-07-22 18:34:46	0|gmaxwell|stab stab stab
 59 2016-07-22 18:35:22	0|gmaxwell|cfields: I am currently compiling old versions and it is reminding me to thank you for all the wonderful things you did to the build process.
 60 2016-07-22 18:35:48	0|cfields|heh
 61 2016-07-22 18:35:57	0|cfields|building pre-0.7?
 62 2016-07-22 18:37:17	0|sipa|i tried building 0.3.x a while ago
 63 2016-07-22 18:37:21	0|sipa|that was painful.
 64 2016-07-22 18:39:29	0|sipa|it's probably fair to say that ever since the concept of backward compatible consensus changes was invented (now called soft forks), bitcoin has not had any hard forks (apart from potentially the march 2013 one, but that's dubious)
 65 2016-07-22 18:40:06	0|sipa|and bitcoin 0.2.10 should be able to sync the full chain (due to a p2p change in 0.2.10)
 66 2016-07-22 18:40:24	0|gmaxwell|Trying to compile 0.2.10 right now... in wxhell
 67 2016-07-22 18:41:03	0|gmaxwell|doing earlier is possible, I synced the _original_ release up to the current chain last sometime in 2013 I believe, but its a PITA due to the p2p proto change.
 68 2016-07-22 18:45:39	0|gmaxwell|sweet. C++ languauge drift...
 69 2016-07-22 18:52:59	0|kanzure|gmaxwell: plz make an archive of the dependencies if you find them
 70 2016-07-22 19:03:52	0|gmaxwell|got 0.2.10 compile but darn thing can't change its listening port. :)
 71 2016-07-22 19:04:29	0|btcdrak|that was fast.
 72 2016-07-22 19:04:50	0|gmaxwell|I was working on it two hours ago actually, before seeing that fool article.
 73 2016-07-22 19:05:04	0|gmaxwell|because of some other person repeating the same claim elsewhere.
 74 2016-07-22 19:06:08	0|gmaxwell|(and I have 0.7 synced to mid 2013... though it's slow and going to take forever to finish)
 75 2016-07-22 19:25:11	0|sipa|gmaxwell: i did get 0.3.x to compile at some point and needed to change the listening ports too
 76 2016-07-22 19:25:14	0|sipa|when was that
 77 2016-07-22 19:26:15	0|sipa|maybe for 0.8 or 0.10
 78 2016-07-22 20:58:36	0|gmaxwell|interesting failure mode, user manages to manually create a zero fee txn for something where they don't care if takes forever...
 79 2016-07-22 20:58:42	0|gmaxwell|then we spend the unconfirmed change.
 80 2016-07-22 20:58:54	0|gmaxwell|and then they're unhappy wth all their txn stuck.
 81 2016-07-22 21:02:25	0|sipa|gmaxwell: cpfp!
 82 2016-07-22 21:02:43	0|luke-jr|^
 83 2016-07-22 21:02:44	0|sdaftuar|if it was literally zero fee, cpfp probably won't help
 84 2016-07-22 21:02:51	0|luke-jr|sdaftuar: why not?
 85 2016-07-22 21:02:57	0|sdaftuar|limited mempools
 86 2016-07-22 21:03:00	0|luke-jr|oh, no relay cpfp yet?
 87 2016-07-22 21:03:18	0|sdaftuar|this is really made for RBF
 88 2016-07-22 21:03:37	0|luke-jr|yes, it's better to respend with an additional output than to create a child
 89 2016-07-22 21:04:04	0|gmaxwell|I'm helping this guy compute a replacement.
 90 2016-07-22 21:04:18	0|gmaxwell|none of this stuff is relaying, so easy to get mined.
 91 2016-07-22 21:04:21	0|luke-jr|somehow I suspect the wallet logic doesn't calculate fees with unconfirmed inputs taken into consideration :x
 92 2016-07-22 21:04:27	0|luke-jr|probably not a show-stopper
 93 2016-07-22 21:04:45	0|gmaxwell|well we should probably have a thing like not spending unconfirmed unputs where it won't spend change with fees to low to relay now.
 94 2016-07-22 21:06:11	0|luke-jr|we already don't spend unconfirmed change when it's possible to avoid it
 95 2016-07-22 21:37:02	0|gmaxwell|luke-jr: kinda! so say you have two unconfirmed outputs, one has no low fee ancestor in its unconfirmed history.
 96 2016-07-22 21:37:05	0|gmaxwell|The other does.
 97 2016-07-22 21:37:09	0|gmaxwell|We'll spend both of those equally.
 98 2016-07-22 21:37:34	0|gmaxwell|similarly for long chains of unconfirmed transactions.. we'll spend a unconfirmed coin at depth 25 even when there is one at depth 1 available.
 99 2016-07-22 23:51:49	0|gmaxwell|do we have any tests of bitcoin-tx at all?
100 2016-07-22 23:54:02	0|sipa|yes.
101 2016-07-22 23:54:26	0|sipa|in the form of a python script that feeds it certain input, and verifies its output