1 2016-11-04 00:32:21	0|murch|Does signaling start with the epoch time listed in the Deployment on BIP141 or with the first difficulty retarget after the epoch time listed in deployment?
  2 2016-11-04 00:37:05	0|murch|Nevermind, reading BIP0009 now. :p
  3 2016-11-04 00:49:45	0|murch|Answer is only with the next retarget, if anyone is interested. ;)
  4 2016-11-04 01:07:13	0|sipa|murch: indeed :)
  5 2016-11-04 01:08:05	0|murch|sipa: So, did you have a chance to take a glimpse at my thesis? :)
  6 2016-11-04 01:08:10	0|sipa|murch: i haven't
  7 2016-11-04 01:08:29	0|murch|Ah, I'm really curious what you'll think.
  8 2016-11-04 01:09:14	0|murch|(if you have time)
  9 2016-11-04 01:16:59	0|phantomcircuit|wumpus: can you take another look at #8831 ?
 10 2016-11-04 01:17:00	0|gribble|https://github.com/bitcoin/bitcoin/issues/8831 | Replace CWalletDB::ReadKeyValue with CWallet::LoadKeyValue by pstratem · Pull Request #8831 · bitcoin/bitcoin · GitHub
 11 2016-11-04 01:17:03	0|phantomcircuit|(i'm going to rebase now)
 12 2016-11-04 03:50:19	0|GitHub47|[13bitcoin] 15rebroad opened pull request #9082: Fix peer selection so that non-Witness peers are still connected to (06master...06FixPeerSelection) 02https://github.com/bitcoin/bitcoin/pull/9082
 13 2016-11-04 04:55:08	0|rebroad|gmaxwell, in response to your comment to #9061 - it's already ignoring getheaders - this pull make it ignore less of them
 14 2016-11-04 04:55:10	0|gribble|https://github.com/bitcoin/bitcoin/issues/9061 | Ignore getheaders prior to passing all checkpoints. by rebroad · Pull Request #9061 · bitcoin/bitcoin · GitHub
 15 2016-11-04 07:31:52	0|GitHub133|13bitcoin/06master 142b175d4 15John Newbery: Clean up bctest.py and bitcoin-util-test.py...
 16 2016-11-04 07:31:52	0|GitHub133|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/82077ef6e49a...ed64bcec2dde
 17 2016-11-04 07:31:53	0|GitHub133|13bitcoin/06master 14ed64bce 15Wladimir J. van der Laan: Merge #9069: Clean up bctest.py and bitcoin-util-test.py...
 18 2016-11-04 07:32:00	0|GitHub61|[13bitcoin] 15laanwj closed pull request #9069: Clean up bctest.py and bitcoin-util-test.py (06master...06btutiltestcleanup) 02https://github.com/bitcoin/bitcoin/pull/9069
 19 2016-11-04 08:57:17	0|rebroad|wumpus, gmaxwell, just want to say thank you for all the hard work you do on bitcoin-core and apologies that I sometimes facilitate a perception of distraction from the more important duties... certainly not my intention. and apologies for the paranoia I sometimes exhibit.. I just find it so hard to understand some of your decisions but I realise you feel you have too little time to explain them fully, so it's ok
 20 2016-11-04 08:59:12	0|rebroad|I do sometimes wonder how much egos come into the weird dynamics I perceive on github, with various maintainers accusing people of trolling, when they are just trying to be constructive...  I think the term "trolling" is used a little too much in general and is, IMHO, a rather unnecessary "bad faith assumption", and I would quite like to see some better standards of ettiquette if possible for github, etc
 21 2016-11-04 09:00:06	0|rebroad|but i realise we're all only human so maybe I'm setting my standards too high given the design limitation of the human race :)
 22 2016-11-04 09:01:05	0|rebroad|I just want to see bitcoin do well. I certainly don't want to see anyone burn out.. i'd rather see more collaboration rather than empire building
 23 2016-11-04 09:01:41	0|Victorsueca|rebroad: never seen "empire building" on core
 24 2016-11-04 09:01:48	0|rebroad|i think some of the recent exchanges between lead deveopers between classic and core for example are all rather silly with egos getting in the way of potential collaboration which could be awesome
 25 2016-11-04 09:02:03	0|rebroad|Victorsueca, wasn't referring specifically to core regarding that statement
 26 2016-11-04 09:02:17	0|Victorsueca|ahh, makes more sense then
 27 2016-11-04 09:02:42	0|rebroad|i just see too much competition.. e.g. core, classic, zcash... I think if forces were combined better (and outsiders accepted more readily) that something better could exist.
 28 2016-11-04 09:02:54	0|rebroad|anyway, I'll get off my soapbox now
 29 2016-11-04 09:04:28	0|rebroad|It does seem that some people are stressed... I'm not quite sure why or what's behind this. I do sometimes wonder if there are things going on in a covert attempt to sabotage the project. I'm a little concerned about the current stress levels I perceive... then again, I could also get a little less stressed when my contributions are dismissed so rapidly..!
 30 2016-11-04 09:04:42	0|Victorsueca|actually nobody cares about classic or zcash, there's no competition at all because reasonable people just ignores them, they will eventually die like all other attempts to compete with bitcoin did so nothing to worry about and nothing we can do about
 31 2016-11-04 09:05:01	0|rebroad|I guess it's hard to be enthused without being attached (in the buddhist sense)
 32 2016-11-04 09:06:16	0|rebroad|Victorsueca, I hope you are right... although I do get the impression that zcash has some quite clever technology in it... but why ddn't they help put this into bitcoin instead of an alt-coin... well.. I think I already know the answer to this...  greed
 33 2016-11-04 09:07:31	0|rebroad|anyway.. all a little OT for this channel perhaps
 34 2016-11-04 09:08:13	0|gmaxwell|Speculating about that kind of stuff does no one any good. All you'll  do is make yourself a target of the currency speculators that are invested in that system. Not worth your time.
 35 2016-11-04 09:14:13	0|jouke|In wallet.cpp on line 2565 I see a transaction is added to wallet, but only fails at 2582, but since it's in the wallet it get's rebroadcasted right? (which I see happening in debug log).
 36 2016-11-04 09:15:45	0|gmaxwell|jouke: if its acceptable to the memory pool ater, then I believe so...
 37 2016-11-04 09:16:24	0|gmaxwell|I think thats a little obnoxious, looks like it could cause the rpc to return an error but still have the txn go out. (though at least it whould show in listtransactions in the meantime)
 38 2016-11-04 09:16:42	0|jouke|That's excactly what's happening now
 39 2016-11-04 09:17:03	0|gmaxwell|would*
 40 2016-11-04 09:17:37	0|gmaxwell|How did you manage to construct a txn that wasn't acceptable to the mempool at the time of construction? that in and of itself is a bug.
 41 2016-11-04 09:17:56	0|sipa|indeed
 42 2016-11-04 09:18:05	0|jouke|gmaxwell: just using bitcoin core 12.0
 43 2016-11-04 09:18:08	0|sipa|i believe the source code has a "this should never happen" comment in that place
 44 2016-11-04 09:18:13	0|jouke|sipa: indeed
 45 2016-11-04 09:18:30	0|jouke|It's a big wallet
 46 2016-11-04 09:18:32	0|gmaxwell|hm. we have had bugs in the past where it could happen.
 47 2016-11-04 09:18:49	0|sipa|ah, 0.12 may have had some issue there - it had just introduced the mempool limiting, and not adapted some of the wallet code to deal with that
 48 2016-11-04 09:18:53	0|gmaxwell|and a lot of wallet things were fixed since 0.12.0
 49 2016-11-04 09:19:16	0|gmaxwell|not a very satisifying answer.
 50 2016-11-04 09:19:16	0|jouke|sipa: ah, right
 51 2016-11-04 09:20:30	0|jouke|Hmm, mempool bytes is at 10% of maxmempool
 52 2016-11-04 09:20:55	0|jouke|These was also a commit ten days ago that would provide more information about this happening.
 53 2016-11-04 09:21:05	0|sipa|how large is the created txn?
 54 2016-11-04 09:21:08	0|sipa|in bytes
 55 2016-11-04 09:22:18	0|jouke|one input, three outputs, 260 bytes
 56 2016-11-04 09:22:29	0|jouke|no dust output
 57 2016-11-04 09:30:56	0|jouke|probably this: https://github.com/bitcoin/bitcoin/pull/7084
 58 2016-11-04 09:44:37	0|jouke|wallet with 250+ keys and working like a charm otherwise :)
 59 2016-11-04 09:55:44	0|NielsvG|for the record, jouke means 250k+ 😉
 60 2016-11-04 09:56:11	0|jouke|euh, that.
 61 2016-11-04 09:56:31	0|jouke|250k+ unlocking takes ages
 62 2016-11-04 09:57:38	0|jouke|anyway, great job @ core devs :)
 63 2016-11-04 10:39:45	0|wumpus|tnx jouke :)
 64 2016-11-04 11:43:02	0|jonasschnelli|250k+ keys.. holy cow!
 65 2016-11-04 12:02:34	0|GitHub142|[13bitcoin] 15s-matthew-english opened pull request #9083: Enforcing consistency, 'gitian' to 'Gitian' (06master...06patch-9) 02https://github.com/bitcoin/bitcoin/pull/9083
 66 2016-11-04 12:53:25	0|jonasschnelli|Any ideas why my gitian builder (night builds) is failing?
 67 2016-11-04 12:53:25	0|jonasschnelli|test/coins_tests.cpp:6:25: fatal error: test_random.h: No such file or directory
 68 2016-11-04 12:53:43	0|jonasschnelli|https://bitcoin.jonasschnelli.ch/nightlybuilds/2016-11-04/build-linux.log
 69 2016-11-04 12:53:43	0|jonasschnelli|I have in mind we did already mentioned this issue somewhere
 70 2016-11-04 13:25:31	0|wumpus|jonasschnelli: I have no clue, haven't seen that error anywhere else, looks like a header file wasn't committed or not added to the makefile (so it doesn't get packaged0
 71 2016-11-04 13:25:52	0|jonasschnelli|It's not in the Makefile.test.include
 72 2016-11-04 13:25:59	0|jonasschnelli|But so are the other headers IMO
 73 2016-11-04 13:26:54	0|wumpus|that could be the reason, though travis would crash on that too
 74 2016-11-04 13:27:15	0|jonasschnelli|hmm...
 75 2016-11-04 13:46:17	0|timothy|hi, which is the "reference" platform for bitcoin-core on linux? aka which distro and version is used with gitian to build it?
 76 2016-11-04 13:47:45	0|jonasschnelli|timothy: Expect of libc/c++, everything is linkes statically. You should be capable of using those binaries on (almost) all linux platforms.
 77 2016-11-04 13:47:55	0|jonasschnelli|timothy: It's built on Ubuntu trusty
 78 2016-11-04 13:48:00	0|jonasschnelli|but portable
 79 2016-11-04 13:49:41	0|timothy|not so portable since it can't work under alpine linux (mostly used for docker) :P I'll use ubuntu:trusty
 80 2016-11-04 13:57:22	0|jonasschnelli|timothy: what error you get when running on alpine?
 81 2016-11-04 13:57:28	0|timothy|alpine uses musl
 82 2016-11-04 13:57:34	0|timothy|so no glibc
 83 2016-11-04 13:58:07	0|jonasschnelli|Yes. That won't work.
 84 2016-11-04 13:58:22	0|jonasschnelli|Compile it on alpine?!
 85 2016-11-04 14:15:23	0|wumpus|libraries need to be compatible with libgcc 4.4.0 and glibc 2.11
 86 2016-11-04 14:15:53	0|wumpus|musl or bionic, not so much
 87 2016-11-04 14:16:23	0|otium|……………………………….. in the year 2016 before Segwit ……………………………..
 88 2016-11-04 14:16:23	0|otium|Thank you core dev for my new Bitcoin core node
 89 2016-11-04 14:16:24	0|otium|it’s fast as lightning
 90 2016-11-04 14:16:24	0|otium|it welcomes  every node thats speaks Segwit fluently
 91 2016-11-04 14:16:26	0|otium|;-)
 92 2016-11-04 14:16:26	0|otium|awesome !
 93 2016-11-04 14:16:28	0|otium|………………………………………………… 2016 BS ………………………………………
 94 2016-11-04 14:17:11	0|wumpus|libstdc++ is also statically linked (-static-libstdc++)
 95 2016-11-04 14:18:14	0|wumpus|woohoo :)
 96 2016-11-04 14:51:45	0|GitHub114|[13bitcoin] 15TheBlueMatt opened pull request #9085: Remove unused CTxOut::GetHash() (06master...062016-11-remove-outpoint-hash) 02https://github.com/bitcoin/bitcoin/pull/9085
 97 2016-11-04 14:54:54	0|BlueMatt|sipa: now you lost the commit message text for "Make nType and nVersion private and sometimes const"
 98 2016-11-04 14:55:00	0|instagibbs|does a block ever set CorruptionPossible?
 99 2016-11-04 14:55:02	0|BlueMatt|its similar text to the next commit, but not the same
100 2016-11-04 14:55:09	0|BlueMatt|instagibbs: it should?!
101 2016-11-04 14:55:19	0|instagibbs|BlueMatt, ok, rephrase, what situation :)
102 2016-11-04 14:56:01	0|BlueMatt|instagibbs: it refers to someone having changed the block such that it is no longer the data which the miner committed to - eg my merkle tree malleability or removing witnesses
103 2016-11-04 14:56:26	0|instagibbs|oh, like handing simply a bad merkle tree
104 2016-11-04 14:56:27	0|instagibbs|ok
105 2016-11-04 14:56:47	0|BlueMatt|please rename and add comments
106 2016-11-04 14:56:58	0|BlueMatt|it was originally names obscurely to hide a bug, but this was years ago
107 2016-11-04 14:57:52	0|BlueMatt|sipa: previously the corresponding commit text was "Make the various stream implementations' nType and nVersion private and const (except in CDataStream where we really need a setter)."
108 2016-11-04 15:01:43	0|sipa|BlueMatt: gah
109 2016-11-04 15:44:10	0|instagibbs|On master running rpc tests im getting a smattering of: Unexpected exception caught during testing: Exception('bitcoind exited with status 1 during initialization',)
110 2016-11-04 15:44:31	0|instagibbs|basically a couple each time, some tests more prone than others, and it gets better if i run with only one thread
111 2016-11-04 15:46:44	0|instagibbs|I'll open an issue :)
112 2016-11-04 15:52:15	0|morcos|cfields_: did you ever look at maxuploadtarget.py failing?  i had guessed a couple months ago that it was due to your refactor and i never really dived into it.  i'm surprised no one else has had issues with it.  i can look into if if you haven't?
113 2016-11-04 16:21:28	0|jm22|just wanted to let you know that when importing private keys or addresses you need to add rescan after the address or the private key. for releases before 13.1 there was no need for that.
114 2016-11-04 16:22:43	0|sipa|jm22: what? please file an issue
115 2016-11-04 16:23:59	0|jm22|iam talking about importing keys or addresses with the console of bitcoin-qt.
116 2016-11-04 16:25:57	0|sipa|yes, i know what you are saying
117 2016-11-04 16:26:06	0|sipa|you should file an issue, so we don't forget
118 2016-11-04 16:26:24	0|jm22|I am not familiar with filing issues. there is nothing wrong just that before there was no need to specify rescan.. just wanted to help in cse someone else have the same problem
119 2016-11-04 16:27:20	0|sipa|https://github.com/bitcoin/bitcoin/issues
120 2016-11-04 16:27:34	0|jm22|ok thanks
121 2016-11-04 16:27:47	0|sipa|click new issue, and describe what you're typing, what you expect to happen, what really happens
122 2016-11-04 16:28:00	0|sipa|if the behaviour changed in 0.13.1, that is a bug
123 2016-11-04 16:30:06	0|jm22|the funny thing is that after you have have try to import thekey  without specifying rescan, if you try again with former release is does not work any more either
124 2016-11-04 16:30:33	0|sipa|?
125 2016-11-04 16:32:55	0|jm22|when I run 13.1 and try imporiting a key without rescan the app freezes. now it I reboot and use a former release the same thing happen even though beforeusing 13.1 it was working.
126 2016-11-04 16:34:12	0|sipa|it freezes??
127 2016-11-04 16:35:30	0|jm22|now if I take a blockchain I updated with a former release importing the key works without rescan
128 2016-11-04 16:37:13	0|jm22|well I need to reboot to stop the app.
129 2016-11-04 16:42:08	0|sipa|how long did you wait?
130 2016-11-04 16:45:05	0|jm22|I have done it many times I must have waited for 1/2 or 1 hour. I cna run it again and leave it on as long as you want.
131 2016-11-04 16:45:56	0|jm22|the dis would work but with long pauses while when you import the disk works nonstop
132 2016-11-04 16:51:36	0|sipa|and how do you fix it?
133 2016-11-04 16:51:58	0|sipa|"by specifying rescan"... what does that mean?
134 2016-11-04 16:52:09	0|sipa|do you put a 'true' after the command
135 2016-11-04 16:52:22	0|sipa|or do you restart with -rescan
136 2016-11-04 16:54:22	0|jm22|importaddress "address"    for releases before 13.1  importaddress "address" rescan    for 13.1
137 2016-11-04 16:55:45	0|jm22|importaddress "address" rescan works fine with former releases just that I never  put rescan
138 2016-11-04 16:59:21	0|sipa|just literally 'rescan' ?
139 2016-11-04 16:59:28	0|jm22|yes
140 2016-11-04 16:59:31	0|sipa|not 'true' or '1'?
141 2016-11-04 16:59:40	0|jm22|no nothing else
142 2016-11-04 17:00:58	0|sipa|the argument after address is the label to assign to ot
143 2016-11-04 17:01:10	0|sipa|and rescan is on by default
144 2016-11-04 17:02:34	0|sipa|putting rescan as a literal directly after the address has no effect but giving the imported address a label
145 2016-11-04 17:02:45	0|sipa|and certainly does not affect rescanning or not
146 2016-11-04 17:03:03	0|sipa|maybe there was some other unrelated issue that caused it to hang
147 2016-11-04 17:03:24	0|jm22|yes but with 13.1 it did not work for me I had to add it.
148 2016-11-04 17:03:47	0|sipa|i'm sorry but that makes no sensr
149 2016-11-04 17:04:13	0|sipa|the way you'd pass a rescan argument would be:
150 2016-11-04 17:04:27	0|sipa|importaddress "1abcbdaddress" "" true
151 2016-11-04 17:04:34	0|jm22|maybe I did something wrong however I did exactly the same with former releases and 13.1 and to make it work on 13.1 I need to write rescan.
152 2016-11-04 17:05:04	0|sipa|that makes no sense at all
153 2016-11-04 17:05:44	0|sipa|i believe you have some unrelated issue that triggers randomly, and you mistakenly believe it has anything to do with putting 'rescan' in the command
154 2016-11-04 17:06:04	0|sipa|anyway, if it persists, please file an issue
155 2016-11-04 17:06:15	0|sipa|so that more people can look into iy
156 2016-11-04 17:06:34	0|jm22|all I can tell you is        importaddress 1QARJNqw4QNZwiNDEu1XVqZQreRSGzvLHB rescan works on 13.1 and
157 2016-11-04 17:06:46	0|sipa|i urge you to try more combinations
158 2016-11-04 17:06:52	0|jm22|importaddress 1QARJNqw4QNZwiNDEu1XVqZQreRSGzvLHB  does not.
159 2016-11-04 17:07:09	0|sipa|ok, please file an issue
160 2016-11-04 17:07:16	0|jm22|the address is not the one I used.
161 2016-11-04 17:09:43	0|jm22|ok I did not mean to make a fuss I just wanted to help and sipa  I really appreciate your dedication and work
162 2016-11-04 17:10:26	0|sipa|i appreciate it, but saying "nothing but X" works when it's obvious it is unrelated, is not helpful
163 2016-11-04 17:10:58	0|sipa|i don't mean to tell you there is no problem
164 2016-11-04 17:11:18	0|sipa|but it has nothing to do with putting 'rescan' in the command
165 2016-11-04 17:11:40	0|sipa|and if you want to further resolve the problem, file an issue
166 2016-11-04 17:11:48	0|sipa|with the actual commands
167 2016-11-04 17:13:50	0|jm22|the command I gave you were exactly what I specified except I change the address.
168 2016-11-04 17:14:10	0|jm22|ok thanks.
169 2016-11-04 17:18:32	0|sipa|jm22: i believe you, but it still has nothing to do with the rescan being there. can you try a few morw times without? my expectation is that sometimes it will work and sometimes it won't
170 2016-11-04 17:18:47	0|sipa|jm22: if that is the case, there is a really issue we need to solve
171 2016-11-04 17:19:14	0|sipa|if you want to help with that, please file an issue so people can look into it in more detail than i can right now
172 2016-11-04 17:20:20	0|jm22|ok I will.
173 2016-11-04 17:21:59	0|sipa|thanks!
174 2016-11-04 17:29:44	0|gmaxwell|jm22: what release do you believe what you're describing worked in? 0.13.0 ?
175 2016-11-04 17:59:35	0|jm22|gmaxwell wel    /  importaddress "address" has always worked since I have been using it, however when I troed to do it with 13.1 it would just freeze and had to reboot manually to stop it. It could be something else ofc. I will try again.
176 2016-11-04 18:00:09	0|sipa|jm22: but what was the last version you know of that does not have this problem?
177 2016-11-04 18:01:11	0|jm22|13.0
178 2016-11-04 18:02:45	0|jm22|maybe it comes from the way I work since I work exclusively off line, so matbe I screwed up something I will go over that again with the different releases.
179 2016-11-04 18:03:15	0|gmaxwell|if you are exclusively offline what are using importaddress for?
180 2016-11-04 18:03:36	0|jm22|just to create watchonly wallets
181 2016-11-04 18:04:01	0|sipa|if you're offline, what are you watching?
182 2016-11-04 18:04:03	0|jm22|I actually really use it to import keys
183 2016-11-04 18:04:27	0|sipa|oh, the importaddress is on the online machine, while the private keys are on the offline one?
184 2016-11-04 18:05:13	0|jm22|I do both on offline, actually I almost do everything offline except for broadcasting
185 2016-11-04 18:06:41	0|jm22|that is why I thing bitcoin-qt is amazing and safe.
186 2016-11-04 18:08:40	0|sipa|then how do you learn about incoming payments?
187 2016-11-04 18:09:21	0|jm22|watchonly wallets
188 2016-11-04 18:37:40	0|sipa|BlueMatt: fixed the commit messages... i hope
189 2016-11-04 18:38:00	0|BlueMatt|sipa: damn, now I lost my partial-review....fuck github
190 2016-11-04 18:46:49	0|GitHub138|13bitcoin/06master 14190fd32 15Matt Corallo: Remove unused CTxOut::GetHash()
191 2016-11-04 18:46:49	0|GitHub138|[13bitcoin] 15sipa pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/ed64bcec2dde...05009935f9ac
192 2016-11-04 18:46:50	0|GitHub138|13bitcoin/06master 140500993 15Pieter Wuille: Merge #9085: Remove unused CTxOut::GetHash()...
193 2016-11-04 18:47:00	0|GitHub147|[13bitcoin] 15sipa closed pull request #9085: Remove unused CTxOut::GetHash() (06master...062016-11-remove-outpoint-hash) 02https://github.com/bitcoin/bitcoin/pull/9085
194 2016-11-04 19:13:59	0|BlueMatt|/query sipa
195 2016-11-04 19:14:02	0|BlueMatt|lol
196 2016-11-04 20:37:57	0|jm22|sipa I probably screwed up something because after rebuilding a new blockchain from stored blockchain that I keep, I do not seem to have any problem with importkey that I encountered yesterday. mea culpa.
197 2016-11-04 20:44:56	0|sipa|jm22: ok, good to hear!