1 2016-10-25 05:38:01	0|GitHub169|13bitcoin/06master 143421e74 15unsystemizer: Clarify `listenonion`...
  2 2016-10-25 05:38:01	0|GitHub169|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/ced22d035ac0...67728a389ccf
  3 2016-10-25 05:38:02	0|GitHub169|13bitcoin/06master 1467728a3 15Wladimir J. van der Laan: Merge #9004: Clarify `listenonion`...
  4 2016-10-25 05:38:18	0|GitHub2|[13bitcoin] 15laanwj closed pull request #9004: Clarify `listenonion` (06master...06patch-3) 02https://github.com/bitcoin/bitcoin/pull/9004
  5 2016-10-25 05:59:19	0|luke-jr|can someone reopen https://github.com/bitcoin/bitcoin/pull/8775 ? the other PR had only a tiny part of it.. (ping wumpus)
  6 2016-10-25 06:00:05	0|luke-jr|thanks
  7 2016-10-25 06:00:09	0|GitHub15|[13bitcoin] 15laanwj reopened pull request #8775: RPC refactoring: Never access wallet directly, only via new CRPCRequestInfo (06master...06multiwallet_prefactor_rpc) 02https://github.com/bitcoin/bitcoin/pull/8775
  8 2016-10-25 06:22:00	0|jonasschnelli|wumpus: what do you think about 10.8 as min OSX version for core?
  9 2016-10-25 06:22:17	0|wumpus|hehe
 10 2016-10-25 06:23:21	0|wumpus|sorry, have to laugh after how difficult it has turned out to deprecate 32-bit windows version, or windows XP for that matter. OSX is so different in that regard, no one cares about old versions support
 11 2016-10-25 06:23:48	0|jonasschnelli|Heh. Yes. Thats somehow true...
 12 2016-10-25 06:23:58	0|jonasschnelli|Though, the original 10.7 bug was reported in #bitcoin
 13 2016-10-25 06:24:09	0|jonasschnelli|I guess some users are still on 10.7 for some server-based OSX systems
 14 2016-10-25 06:24:11	0|wumpus|"things break all the time on 10.x and no one notices" "if a tree falls..."
 15 2016-10-25 06:24:44	0|jonasschnelli|We can reduce the tree-falling risks by setting 10.8 as min OSX.
 16 2016-10-25 06:24:51	0|jonasschnelli|Also, we could get rid of some warnings
 17 2016-10-25 06:25:29	0|jonasschnelli|I mean we only speak about the official binaries... I guess self-compile should still work fine on OSX
 18 2016-10-25 06:25:31	0|sipa|when was 10.7 released?
 19 2016-10-25 06:25:32	0|wumpus|so that'd be for 0.14.0 I guess
 20 2016-10-25 06:25:45	0|jonasschnelli|IF we do a rc3, then we could add it there
 21 2016-10-25 06:25:56	0|jonasschnelli|But no 0.13.1 rc just because of that issue
 22 2016-10-25 06:26:03	0|wumpus|in any case I don't really want to have an opionion about this: if there's anyone willing to fix problems that come up with 10.7, I'll merge them and keep supporting
 23 2016-10-25 06:26:05	0|jonasschnelli|sipa: i'm looking... I guess 2-3 years
 24 2016-10-25 06:26:05	0|sipa|10.7 is 5 years old
 25 2016-10-25 06:26:13	0|sipa|july 2011
 26 2016-10-25 06:26:18	0|wumpus|if not, well, too bad then
 27 2016-10-25 06:26:36	0|jonasschnelli|Okay. I'll work on a patch...
 28 2016-10-25 06:27:09	0|jonasschnelli|Well... we could still build against 10.7 but set 10.8 as min osx runtime version... but that would be pretty bad
 29 2016-10-25 06:27:12	0|wumpus|I didn't mean 'you should fix this now'
 30 2016-10-25 06:27:15	0|sipa|windows 7 is already much older than osx 10.7
 31 2016-10-25 06:27:51	0|jonasschnelli|"I'm working on a patch" could result in a work-duration of couple of month . :)
 32 2016-10-25 06:28:13	0|sipa|haha
 33 2016-10-25 06:28:34	0|jonasschnelli|First finishing the SPV hybrid mode
 34 2016-10-25 06:29:01	0|sipa|sounds like a 5 year plan
 35 2016-10-25 06:29:06	0|jonasschnelli|hah
 36 2016-10-25 06:29:17	0|jonasschnelli|It's already working... but that probably 5% of the work.
 37 2016-10-25 06:29:20	0|wumpus|sipa: yes, it's weird, you can't really compare windows and OSX users in that regard, windows users love their old versions, macosx users upgrade both hardware and software when they can
 38 2016-10-25 06:30:03	0|jonasschnelli|sipa: I'm not sure how we could reuse blocks (lets say around the tip) to be reused once they where downloaded (without connecting the tip).
 39 2016-10-25 06:31:01	0|wumpus|I've yet to see any exceptions to this, well there are a few that truly like windows 10 better than the previous versions, but there's always a reluctance to upgrading
 40 2016-10-25 06:31:13	0|luke-jr|pretty sure my father is still using hardware incapable of 64-bit <.<
 41 2016-10-25 06:31:29	0|sipa|luke-jr: use qemu :p
 42 2016-10-25 06:31:40	0|sipa|jonasschnelli: i don't understand
 43 2016-10-25 06:31:42	0|luke-jr|sipa: does qemu support XP? :P
 44 2016-10-25 06:32:48	0|sipa|wumpus: microsoft has the world's worst customer base. mostly corporate machines whose maintainers don't like change :)
 45 2016-10-25 06:32:59	0|jonasschnelli|sipa: I'm downloading blocks - required for SPV, have a modified AcceptBlock() (no tip update), that stores the block with WriteBlockToDisk(),... but I guess the validation-part does not check if blocks are stored on disk?
 46 2016-10-25 06:33:17	0|jonasschnelli|they always re-download the required blocks
 47 2016-10-25 06:33:30	0|jonasschnelli|s/they/it
 48 2016-10-25 06:33:38	0|sipa|jonasschnelli: there is no validation in SPV mode
 49 2016-10-25 06:33:49	0|jonasschnelli|sipa: there is in hybrid...
 50 2016-10-25 06:34:03	0|sipa|what do you mean by hybrid?
 51 2016-10-25 06:34:14	0|jonasschnelli|I have now a state where i have some random non-validated blocks (around the tip) used for SPV that are stored on my disk...
 52 2016-10-25 06:34:29	0|jonasschnelli|the full-node part could once reuse those already downloaded blocks
 53 2016-10-25 06:34:31	0|wumpus|sipa: btw re: 8753, are you sure comparing void* pointers with greater/lesser is defined behavior? I'm fairly sure but...
 54 2016-10-25 06:34:44	0|wumpus|C has so many scary edge cases there
 55 2016-10-25 06:35:07	0|jonasschnelli|but how-every,... hard to explain,... i'll show you some code sipa during the next days/weeks
 56 2016-10-25 06:35:08	0|luke-jr|jonasschnelli: I don't get the purpose?
 57 2016-10-25 06:35:35	0|sipa|6.5.8 Relational operators
 58 2016-10-25 06:35:36	0|sipa|5 When two pointers are compared, the result depends on the relative locations in the address space of the objects pointed to. If two pointers to object types both point to the same object, or both point one past the last element of the same array object, they compare equal. If the objects pointed to are members of the same aggregate object, pointers to structure members declared later compare greater than pointers to members declared earlier...
 59 2016-10-25 06:35:42	0|sipa|in the structure, and pointers to array elements with larger subscript values compare greater than pointers to elements of the same array with lower subscript values. All pointers to members of the same union object compare equal. If the expression P points to an element of an array object and the expression Q points to the last element of the same array object, the pointer expression Q+1 compares greater than P. In all other cases, the...
 60 2016-10-25 06:35:48	0|sipa|behavior is undefined.
 61 2016-10-25 06:35:54	0|jonasschnelli|The idea is, you start your IBD, but in parallel, you download blocks down to your wallet-birthday and do SPV-ismine check with these
 62 2016-10-25 06:36:11	0|jonasschnelli|these downloaded blocks can later be used for the validation-full-node part
 63 2016-10-25 06:36:24	0|sipa|jonasschnelli: that's no different from how block fetching works today
 64 2016-10-25 06:36:41	0|sipa|jonasschnelli: we often have unvalidated blocks ahead of the point we're fully synced to
 65 2016-10-25 06:36:55	0|wumpus|so this would compare pointers in different arenas, which can be seen as different "arrays"
 66 2016-10-25 06:37:06	0|sipa|wumpus: ah, i guess...
 67 2016-10-25 06:37:10	0|luke-jr|sipa: I think he means you'd download blocks from the other end
 68 2016-10-25 06:38:04	0|luke-jr|(in order to scan them for unconfirmed transactions)
 69 2016-10-25 06:38:24	0|sipa|well if you combine it with pruning you wouldn't keep the blocks on disk downloaded for SPV
 70 2016-10-25 06:38:29	0|luke-jr|indeed
 71 2016-10-25 06:38:34	0|sipa|which makes things much easier
 72 2016-10-25 06:38:35	0|jonasschnelli|Yes. With pruning...
 73 2016-10-25 06:38:50	0|jonasschnelli|I think i'll start with not keeping these blocks for now.
 74 2016-10-25 06:39:00	0|jonasschnelli|But it would be a nice use case for full-block SPV (if pruning is disabled)
 75 2016-10-25 06:39:08	0|jonasschnelli|Because you need the blocks anyways.
 76 2016-10-25 06:39:23	0|luke-jr|IMO the more valuable SPV-hybrid mode is one where cellular data isn't wasted on downloading full blocks ;)
 77 2016-10-25 06:43:40	0|wumpus|sipa: but one'd hope that "the result depends on the relative locations in the address space of the objects pointed to" is stil true in every case
 78 2016-10-25 06:44:18	0|sipa|wumpus: well, the last sentence is that anything else is undefined behaviour. So the compiler may delete your wallet.dat in that case.
 79 2016-10-25 06:44:45	0|wumpus|welcome to adversarial compiler design 101 :)
 80 2016-10-25 06:45:23	0|sipa|and conversion of pointer to int is implementation defined, but must be convertable back to a valid pointer if the integer is large enough
 81 2016-10-25 06:45:39	0|sipa|so your solution seems perfectly fine
 82 2016-10-25 06:46:12	0|wumpus|I'll just keep it as it is then, thanks
 83 2016-10-25 06:47:28	0|sipa|actually, i don't know if the mapping from pointer to integer is required to keep continuous ranges continuous :)
 84 2016-10-25 06:48:05	0|wumpus|"
 85 2016-10-25 06:48:09	0|wumpus|"Ok, bad news. I ended up in the bowels of osx"
 86 2016-10-25 06:48:16	0|wumpus|poor cfields_
 87 2016-10-25 06:48:46	0|sipa|did he come across a digest function?
 88 2016-10-25 06:50:39	0|wumpus|sipa: I'm not sure that is required either, outside arrays. But think I wrote the code in a way in which that doesn't matters, as long as the different ranges are disjunct, it's just a membership test after all
 89 2016-10-25 06:52:06	0|sipa|wumpus: if the pointers inside the arena's memory range are not mapped to a continuous set of uintotrs, your membership test won't work
 90 2016-10-25 06:52:17	0|sipa|*uintptrs
 91 2016-10-25 06:52:41	0|wumpus|but that wouldn't make sense as the arena is allocated at once, so it needs to be a linear area
 92 2016-10-25 06:52:54	0|sipa|the pointers need to be linear
 93 2016-10-25 06:53:00	0|sipa|the integers they map to do not
 94 2016-10-25 06:53:01	0|wumpus|or at least monotonic, linear isn't even necessary
 95 2016-10-25 06:53:09	0|sipa|of course, in any compiler below adversialness level 7, this will be the case
 96 2016-10-25 06:54:26	0|wumpus|hehe, phew, so that's still safe for ~5 years then
 97 2016-10-25 06:55:57	0|sipa|the question is really whether you can do pointer arithmetic by converting to uintptr, doing the arithmetic (multiplied the the pointer type's size), and converting back
 98 2016-10-25 06:56:15	0|sipa|i don't know whether the standard requires that
 99 2016-10-25 06:56:32	0|sipa|if not, the cast to uintptr could for example bitflip the result or so
100 2016-10-25 06:56:59	0|sipa|or switch the bit or byte order
101 2016-10-25 07:00:26	0|wumpus|bleh. So usually it's advised to do pointer arithmethic using [u]char*. But this runs into the issue with comparing ranges.
102 2016-10-25 07:00:31	0|wumpus|This makes me sick
103 2016-10-25 07:03:18	0|sipa|and you get aliasing rules too
104 2016-10-25 07:03:22	0|wumpus|C: "between Scylla and Charybdis"
105 2016-10-25 07:03:26	0|wumpus|I don't want to do this anymore
106 2016-10-25 07:03:31	0|sipa|:)
107 2016-10-25 07:03:39	0|sipa|i don't think any of this matters
108 2016-10-25 07:08:10	0|sipa|btw: i believe char* pointers are always allowed to alias anything
109 2016-10-25 07:08:29	0|sipa|so if that's the reason for wanting to avoid them, no worries
110 2016-10-25 07:15:10	0|wumpus|will try to change uses of uintptr_t to char* and see if it still makes sense. I'd like to keep the interface as void* though so will need static_casts there (but maybe that's better than reinterpret_cast)
111 2016-10-25 07:19:38	0|phantomcircuit|cccccceegehfceddehkuieubrvvrejvvbbnlrclrighk
112 2016-10-25 07:20:32	0|jonasschnelli|your new private key?
113 2016-10-25 07:21:22	0|wumpus|"this is your brain on C"
114 2016-10-25 07:21:39	0|tulip|phantomcircuit: try not spilling soda on your keyboard next time.
115 2016-10-25 07:22:19	0|sipa|wumpus: where c is the speed of light, so you're saying he's on speed?
116 2016-10-25 07:22:45	0|sipa|i'll see myself out
117 2016-10-25 07:23:01	0|tulip|I've been trying to work out where the regression that allows bitcoin core to attempt connections on port 0 is.
118 2016-10-25 07:23:12	0|wumpus|I had imagined it more like some kind of hallucogenic substance, twisting time and space in arbitrary and disjointed ways, but sure, speed will do too :)
119 2016-10-25 07:24:35	0|tulip|also sort of interested why my addrman has lots of invalid IPv6 addresses. feels like a fingerprinting attack of some description, as they're unique.
120 2016-10-25 07:25:32	0|tulip|2016-10-25 03:04:55.029570 connect() to [376f:ff56:100::]:0 failed: Host is down (64) <- like this
121 2016-10-25 07:25:36	0|gmaxwell|tulip: the attempts to port 0 may be a side effect of the witness preference.
122 2016-10-25 07:25:52	0|wumpus|tulip: did it ever had an explicit check to not try port 0? I think it has a prefernce for its own port, but there it stops
123 2016-10-25 07:26:19	0|tulip|gmaxwell: my thinking was that they were always there, just never chosen before because we never reached the fall back.
124 2016-10-25 07:26:27	0|gmaxwell|bingo.
125 2016-10-25 07:26:34	0|wumpus|it'd make sense to discard records with port 0 as invalid though
126 2016-10-25 07:27:03	0|gmaxwell|It doesn't try non-default ports until after 50 tries... but now it's much more likely to make 50 tries due to the witness stuff.
127 2016-10-25 07:27:23	0|tulip|oh, so choosing not to connect to a node counts as a try?
128 2016-10-25 07:27:32	0|gmaxwell|we should probably prevent port 0 from ending up in addrman at all.
129 2016-10-25 07:27:49	0|gmaxwell|tulip: yes sir. read the loop in CConman:ThreadOpenConnections()
130 2016-10-25 07:28:52	0|wumpus|yes, like invalid addresses, invalid ports probably shouldn't end up in addrman at all
131 2016-10-25 07:29:50	0|wumpus|may makesense to add a generic blacklist of ports. 22, 25, etc
132 2016-10-25 07:29:58	0|tulip|the only invalid IP address I've seen in my logs is 255.255.0.0, the IPV6 ones are valid but unroutable
133 2016-10-25 07:30:15	0|gmaxwell|I do wonder if there is much purpose to automatic connections to non-standard ports at all.  In the far past it arguably could have helped the network heal across firewalling, but w/ things like tor there is much less reason for it, and I would expect there are few to no hosts to connect to.
134 2016-10-25 07:30:36	0|gmaxwell|tulip: addrman already filters several broad families of invalid IPs.
135 2016-10-25 07:30:46	0|gmaxwell|s/invalid/non-routable/ really
136 2016-10-25 07:30:56	0|wumpus|meh, I'd prefer not to hardcode the port even further
137 2016-10-25 07:33:03	0|wumpus|I agree that tor or vpns are a better way to avoid more persistent firewalling, but ideally bitcoin core would get around the simple case of 'port 8333 firewalled'
138 2016-10-25 07:33:43	0|gmaxwell|ya, but does it? requires there be enough non-8333 hosts to actually find a working one. :P
139 2016-10-25 07:33:55	0|wumpus|otherwise it may suddenly become a really attractive measure
140 2016-10-25 07:34:07	0|wumpus|there are some non-8333 hosts to connect to
141 2016-10-25 07:34:24	0|gmaxwell|fair enough.
142 2016-10-25 07:34:43	0|tulip|there's 1990 peers ever to have been crawled by this seed node which have a non standard port.
143 2016-10-25 07:36:03	0|tulip|port frequencies http://pastebin.com/raw/wZSSDYW6
144 2016-10-25 07:36:07	0|wumpus|may make sense to listen on 8333 as well as arandom non-standard port
145 2016-10-25 07:36:32	0|wumpus|8333 to make sure people connect to you, and the non-standard port to help people behind weird firewalls
146 2016-10-25 07:37:40	0|gmaxwell|wumpus: I was just thinking that too.
147 2016-10-25 07:38:22	0|wumpus|and for the built-in seed node selection there should probably be some non-standard ports too
148 2016-10-25 07:38:29	0|gmaxwell|well also something we could deploy on relatively short notice if there were a widespread reason.
149 2016-10-25 07:38:42	0|gmaxwell|seed nodes make sense.
150 2016-10-25 07:39:12	0|gmaxwell|my general expirence with firewalls that block random ports is that they block all of them, so really the only way to get through them is to use :443 or :80
151 2016-10-25 07:39:57	0|wumpus|sure, I agree, but it just seems stupid to have so-called robust P2P software be blocked by filtering out one port :)
152 2016-10-25 07:40:57	0|wumpus|it also means you can make a selection "no bitcoin here, but we allow dogecoin and litecoin through!"
153 2016-10-25 07:41:32	0|sipa|we should make the port depend on the (routable) IP
154 2016-10-25 07:42:30	0|sipa|1024 + H("bitcoin port" || ip) % (32768 - 1024)
155 2016-10-25 07:43:40	0|luke-jr|can we not at least not require uint256 math support? :x
156 2016-10-25 07:43:51	0|sipa|sure
157 2016-10-25 07:43:59	0|gmaxwell|yea, but sadly we don't really know our IP at the relevant time.
158 2016-10-25 07:44:43	0|sipa|we need to implement IP over reddit.
159 2016-10-25 07:44:44	0|wumpus|"spread spectrum TCP" hehe
160 2016-10-25 07:44:48	0|gmaxwell|it's harmless to just save a port to peers.dat and try to use it.
161 2016-10-25 07:45:06	0|luke-jr|sipa: can we make an encoding that looks like r/BTC posters? :p
162 2016-10-25 07:45:22	0|sipa|luke-jr: working on software for that!
163 2016-10-25 07:45:30	0|tulip|https://www.reddit.com/r/blockchainheaders/
164 2016-10-25 07:46:32	0|sipa|tulip: last post 1 week ago :(
165 2016-10-25 07:47:27	0|rabidus_|maybe blockchain is dead
166 2016-10-25 07:48:28	0|luke-jr|:x
167 2016-10-25 07:49:15	0|sipa|ok, it's over guys
168 2016-10-25 07:49:28	0|sipa|let's go do dollar instead
169 2016-10-25 07:49:38	0|wumpus|yep, we've reached the end
170 2016-10-25 07:50:18	0|gmaxwell|I am trying to send my dollar over the internet but it will not send.
171 2016-10-25 07:50:50	0|sipa|how do we get more people to use dollar?
172 2016-10-25 07:50:52	0|gmaxwell|My transaction is stuck in the cup holder and it will not open anymore.
173 2016-10-25 07:53:48	0|wumpus|gmaxwell: for some reason no one accepts scanned dollar bills as payment
174 2016-10-25 07:54:24	0|wumpus|possibly there is a double-spending problem
175 2016-10-25 07:56:13	0|gmaxwell|Really? But I heard Microsoft was migrating to dollar.
176 2016-10-25 07:57:52	0|tulip|sipa: the reddit api implementation decided to do an incompatible re-write and drop it as a replacement under the same name in pypi. I can't really be bothered fixing what amounts to a joke.
177 2016-10-25 08:02:25	0|tulip|it should ideally be possible for people to do block data downloads over other transports, but reddit is a particularly ridiculous one.
178 2016-10-25 08:05:23	0|luke-jr|tulip: but we all know reddit is censorship-proof
179 2016-10-25 08:08:18	0|gmaxwell|any guesses what happened here? this is the second or maybe third time I've seen this: http://0bin.net/paste/TlJ+g8dEsUb7JJpa#4B0Izyd57LaA9MxAvgB7A0pa+HwtwXY8i90So-WYat9  (others not with the noconnect stuff, I believe, doubt thats related)
180 2016-10-25 08:08:42	0|phantomcircuit|tulip: oh nose now someone can login to yubico as me
181 2016-10-25 08:09:22	0|luke-jr|gmaxwell: my guess is bitcoind didn't stop before you tried to start it again
182 2016-10-25 08:09:36	0|luke-jr|although I would expect a debug.log to be generated in that case
183 2016-10-25 08:09:41	0|gmaxwell|then why didn't the startup throw a lockfile error.
184 2016-10-25 08:10:04	0|phantomcircuit|gmaxwell: disk space?
185 2016-10-25 08:10:15	0|phantomcircuit|nfs or something weird?
186 2016-10-25 08:10:20	0|gmaxwell|no actually .. damn, its not throwing an error anymore!
187 2016-10-25 08:10:20	0|phantomcircuit|debug.log being trimmed?
188 2016-10-25 08:10:33	0|gmaxwell|just always says "Bitcoin server starting" :P
189 2016-10-25 08:10:44	0|phantomcircuit|ptrace
190 2016-10-25 08:11:17	0|gmaxwell|so I think it's throwing that error after daemonizing so I never see it.
191 2016-10-25 08:11:38	0|gmaxwell|yea, with daemon=0, I get the expected cannot obtain a lock.
192 2016-10-25 08:11:49	0|gmaxwell|well one mystery solved and a new one created...
193 2016-10-25 08:11:58	0|luke-jr|heh, I assumed daemon was 0 because you didn't specify it on the commandline XD
194 2016-10-25 08:12:16	0|luke-jr|wait nm
195 2016-10-25 08:16:20	0|btcdrak|making the dollar bill larger will increase adoption
196 2016-10-25 08:17:24	0|wumpus|btcdrak: haha I had the same thought
197 2016-10-25 08:17:39	0|gmaxwell|well I heard that all it took was changing a 1 to a 2, but I also heard someone who tried that and got harassed by the secret service!
198 2016-10-25 08:18:17	0|wumpus|btcdrak: but but but you'll need larger wallets to handle the awkward bills, prompting people to store them centrally!
199 2016-10-25 08:19:10	0|luke-jr|wumpus: it's okay, I will use visa.info
200 2016-10-25 08:20:23	0|luke-jr|man, the analogy there is surprising.
201 2016-10-25 08:21:04	0|wumpus|gmaxwell: yeah it's sort of a known issue https://github.com/bitcoin/bitcoin/pull/8278#issuecomment-242706794  , though opening an issue to track it wouldn't hurt
202 2016-10-25 08:21:24	0|wumpus|all the messages printed to stdout/stderr also need to go to the log
203 2016-10-25 09:56:08	0|luke-jr|rebased multiwallet stuff on latest master including jonasschnelli's suggestions. hopefully unaffected by half-asleepness. :x
204 2016-10-25 10:21:08	0|GitHub194|[13bitcoin] 15laanwj opened pull request #9010: Split up AppInit2 into multiple phases, daemonize after datadir lock errors (06master...062016_10_init_split_daemon) 02https://github.com/bitcoin/bitcoin/pull/9010
205 2016-10-25 10:27:49	0|GitHub59|13bitcoin/06master 14515e264 15Gregory Maxwell: Make connect=0 disable automatic outbound connections....
206 2016-10-25 10:27:49	0|GitHub59|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/67728a389ccf...e1d1f57b56b2
207 2016-10-25 10:27:50	0|GitHub59|13bitcoin/06master 14e1d1f57 15Wladimir J. van der Laan: Merge #9002: Make connect=0 disable automatic outbound connections....
208 2016-10-25 10:28:04	0|GitHub130|[13bitcoin] 15laanwj closed pull request #9002: Make connect=0 disable automatic outbound connections. (06master...06connect0) 02https://github.com/bitcoin/bitcoin/pull/9002
209 2016-10-25 10:34:18	0|btcdrak|luke-jr: #8694? I was meaning to test that out.
210 2016-10-25 10:34:44	0|luke-jr|btcdrak: yeah.
211 2016-10-25 10:37:25	0|GitHub103|13bitcoin/06master 14fa1c3c2 15MarcoFalke: [net] Remove assert(nMaxInbound > 0)...
212 2016-10-25 10:37:25	0|GitHub103|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/e1d1f57b56b2...f14f07cb94eb
213 2016-10-25 10:37:26	0|GitHub103|13bitcoin/06master 14f14f07c 15Wladimir J. van der Laan: Merge #9008: [net] Remove assert(nMaxInbound > 0)...
214 2016-10-25 10:37:38	0|GitHub161|[13bitcoin] 15laanwj closed pull request #9008: [net] Remove assert(nMaxInbound > 0) (06master...06Mf1610-netAssert) 02https://github.com/bitcoin/bitcoin/pull/9008
215 2016-10-25 10:40:52	0|GitHub138|[13bitcoin] 15laanwj opened pull request #9011: 0.13.1 backports conditional on rc3 (060.13...062016_10_backports_conditional_rc3) 02https://github.com/bitcoin/bitcoin/pull/9011
216 2016-10-25 10:45:24	0|luke-jr|wumpus: 8784 should be harmless regardless of rc3
217 2016-10-25 10:46:06	0|luke-jr|wumpus: will you be merging release notes in from the blog post, or would it help if I make a PR to do that?
218 2016-10-25 10:55:19	0|wumpus|yes that'd be helpful I'll likely not be moerging release notes from anywhere but github pulls
219 2016-10-25 11:25:10	0|GitHub186|13bitcoin/06master 143f7581d 15Micha: [TRIVIAL] reorder Windows gitian build order to match Linux...
220 2016-10-25 11:25:10	0|GitHub186|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/f14f07cb94eb...e077e0030384
221 2016-10-25 11:25:11	0|GitHub186|13bitcoin/06master 14e077e00 15Wladimir J. van der Laan: Merge #8948: [TRIVIAL] reorder Windows gitian build order to match Linux...
222 2016-10-25 11:25:18	0|GitHub175|[13bitcoin] 15laanwj closed pull request #8948: [TRIVIAL] reorder Windows gitian build order to match Linux (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/8948
223 2016-10-25 11:32:06	0|GitHub43|[13bitcoin] 15luke-jr opened pull request #9012: release-notes: Update from blog draft (060.13...060.13.1_relnotes_update) 02https://github.com/bitcoin/bitcoin/pull/9012
224 2016-10-25 11:37:37	0|luke-jr|and with that, I'm heading to bed, night
225 2016-10-25 11:50:51	0|wumpus|jonasschnelli: re: https://github.com/bitcoin/bitcoin/pull/9010, any idea why not all parameter interaction was moved to InitParameterInteraction?
226 2016-10-25 11:57:50	0|wumpus|it's a bit silly after that, with both a InitParameterInteraction and AppInitParameterInteraction :)
227 2016-10-25 12:12:32	0|GitHub37|13bitcoin/060.13 1499f5cf1 15Luke Dashjr: release-notes: Update from blog draft
228 2016-10-25 12:12:32	0|GitHub37|[13bitcoin] 15laanwj pushed 2 new commits to 060.13: 02https://github.com/bitcoin/bitcoin/compare/c9a5baddeef3...cb699885728f
229 2016-10-25 12:12:32	0|GitHub65|[13bitcoin] 15laanwj closed pull request #9012: release-notes: Update from blog draft (060.13...060.13.1_relnotes_update) 02https://github.com/bitcoin/bitcoin/pull/9012
230 2016-10-25 12:12:33	0|GitHub37|13bitcoin/060.13 14cb69988 15Wladimir J. van der Laan: Merge #9012: release-notes: Update from blog draft...
231 2016-10-25 12:22:22	0|GitHub99|[13bitcoin] 15laanwj pushed 5 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/e077e0030384...9bdf5269f886
232 2016-10-25 12:22:23	0|GitHub99|13bitcoin/06master 1451f2783 15Pieter Wuille: Make removed and conflicted arguments optional to remove
233 2016-10-25 12:22:23	0|GitHub99|13bitcoin/06master 14f48211b 15Pieter Wuille: Bypass removeRecursive in removeForReorg
234 2016-10-25 12:22:24	0|GitHub126|[13bitcoin] 15laanwj closed pull request #8515: A few mempool removal optimizations (06master...06moresharedmem) 02https://github.com/bitcoin/bitcoin/pull/8515
235 2016-10-25 12:22:24	0|GitHub99|13bitcoin/06master 144100499 15Pieter Wuille: Return shared_ptr<CTransaction> from mempool removes
236 2016-10-25 12:41:18	0|achow101|will there be an rc3?
237 2016-10-25 12:46:04	0|wumpus|not at this point, but that's never sure, a critical issue could up any time
238 2016-10-25 14:12:35	0|instagibbs|I've been doing some work on preparation for switching to p2sh-p2wpkh for default addresses in Core, and was wondering what the actual roll out might look like as far as rpc calls go. Has anyone thought about this much?
239 2016-10-25 14:12:58	0|instagibbs|ie, will getnewaddress return those new address types, will there be a new call for that instead, etc
240 2016-10-25 14:18:52	0|sipa|instagibbs: i would think there is a cmdline option that sets the default, which is introduced after activation
241 2016-10-25 14:19:12	0|sipa|instagibbs: and maybe at some point the default for that flag is changed
242 2016-10-25 14:19:19	0|instagibbs|Ah, ok that might make sense
243 2016-10-25 14:19:30	0|instagibbs|fixing tests may only mean a single line per test
244 2016-10-25 14:19:52	0|instagibbs|at least in immediate term, even if one flips the default
245 2016-10-25 14:21:19	0|instagibbs|I'm switching to segwit addresses by default, seeing what breaks. Some are just how tests are written, and would be a huge pain to change manually.
246 2016-10-25 14:22:49	0|wumpus|there should be a flag to getnewaddress what kind of address to return, I suppose
247 2016-10-25 14:23:09	0|wumpus|the default of that could depend on a command-line option
248 2016-10-25 14:23:51	0|instagibbs|that's what I tried first, but number of flags is quite long :) might be complementary of course
249 2016-10-25 14:24:18	0|instagibbs|(also you don't want to have to change every instance of getnewaddress in the test codebase)
250 2016-10-25 14:24:26	0|wumpus|have you seen my named-rpc-arguments pull? it would make coping with lots of flags easier
251 2016-10-25 14:24:49	0|wumpus|sure, but still want to test old addresses in the test codebase I suppose, so you don't get around some changing there
252 2016-10-25 14:25:03	0|instagibbs|yes, and test transition from non-segwit to segwit, etc
253 2016-10-25 14:25:27	0|instagibbs|link to pr?
254 2016-10-25 14:25:34	0|wumpus|https://github.com/bitcoin/bitcoin/pull/8811
255 2016-10-25 14:26:04	0|sipa|wumpus: oh, so a named argument to getnewaddress, which defaults to the cmdline value, whose value defaults to a constant, and we'll change that constant sometime later.
256 2016-10-25 14:26:14	0|sipa|double indirections yay
257 2016-10-25 14:26:32	0|wumpus|sipa: well it should be possible to override it through the RPC call at least
258 2016-10-25 14:27:12	0|wumpus|I don't think the behavior should only depend on an ambient setting that can only be changed with a command-line argument at starting time
259 2016-10-25 14:28:10	0|wumpus|seems bad both for testing and actual usage
260 2016-10-25 14:29:12	0|wumpus|and there may be other types of addresses to return in the future
261 2016-10-25 14:29:21	0|wumpus|so an address ttpe argument to getnewaddress would make sense
262 2016-10-25 14:29:27	0|instagibbs|I'll think on this while I'm working on it. Stuff like "verifymessage requires you to know the uint160(pubkey)"
263 2016-10-25 14:45:44	0|BlueMatt|hum...are any of the fixes currently proposed as backports for rc3 regressions since 13.0?
264 2016-10-25 14:47:04	0|sipa|BlueMatt: the blocktxn lock is
265 2016-10-25 14:47:34	0|GitHub198|[13bitcoin] 15gtsui opened pull request #9013: Trivial: Explicitly pass const CChainParams& to LoadBlockIndexDB() (06master...06global-params-cleanup) 02https://github.com/bitcoin/bitcoin/pull/9013
266 2016-10-25 14:47:45	0|BlueMatt|sipa: it is?!
267 2016-10-25 14:47:59	0|wumpus|the assert too
268 2016-10-25 14:48:11	0|BlueMatt|oh, i was mostly asking about the assert
269 2016-10-25 14:48:28	0|BlueMatt|damn :(
270 2016-10-25 14:48:31	0|sipa|BlueMatt: compact blocks and feelers are in 0.13.0
271 2016-10-25 14:48:35	0|wumpus|this ws introduced in the 'feelers' commit which IIRC was introduced after 0.13.0
272 2016-10-25 14:48:52	0|BlueMatt|sipa: i said regressions since 13
273 2016-10-25 14:49:06	0|wumpus|but I'm not 100% sure
274 2016-10-25 14:49:23	0|sipa|oh, you mean regressions introduced strictly after 0.13.0?
275 2016-10-25 14:49:24	0|BlueMatt|wumpus: thats what i thought about the asserts, which sucks
276 2016-10-25 14:49:28	0|BlueMatt|sipa: yes
277 2016-10-25 14:49:31	0|sipa|ah
278 2016-10-25 14:49:48	0|sipa|"since" is ambiguous, i guess :)
279 2016-10-25 14:49:49	0|BlueMatt|sipa: ie if they are regressions /since/ 0.13.0 then we should do rc3, otherwise i was gonna propose 0.13.2 with them
280 2016-10-25 14:49:58	0|wumpus|the license ones and relayrpriority error are just nice to include but low risk and very low priority
281 2016-10-25 14:50:41	0|wumpus|I'm not sure the assert one warrants a rc3 yet
282 2016-10-25 14:51:08	0|wumpus|it's a problem that is not remote triggerable and easy to work around by increasing maxconnections
283 2016-10-25 14:51:22	0|wumpus|note that it asserts the maximum, not the current value
284 2016-10-25 14:51:25	0|sipa|i'm surprised it took us so long to find
285 2016-10-25 14:51:33	0|sipa|especially since it is 0.13.0
286 2016-10-25 14:51:38	0|sipa|and nobody reported it
287 2016-10-25 14:52:02	0|BlueMatt|sipa: thats the point of rcs
288 2016-10-25 14:52:13	0|BlueMatt|wumpus: yea, I'm trying to decide how i feel about rc3, hence the questions
289 2016-10-25 14:52:22	0|sipa|BlueMatt: well, yes, but it wasn't found in the 0.13.0 rc
290 2016-10-25 14:52:38	0|BlueMatt|sipa: oh, the assert was in 0.13.0?
291 2016-10-25 14:52:38	0|wumpus|feeler connections was not in 0.13.0
292 2016-10-25 14:52:44	0|BlueMatt|yea, thats what i thought
293 2016-10-25 14:53:09	0|wumpus|no, it was added in 2611ad7 (part of #8679), which are post-0.13.0 backports
294 2016-10-25 14:53:21	0|wumpus|I don't know anymore why it was flagged for backport in the first place
295 2016-10-25 14:54:13	0|BlueMatt|feelers? folks wanted feelers to reinforce the preferential-peering stuff
296 2016-10-25 14:54:17	0|BlueMatt|to ensure we find out service bits
297 2016-10-25 14:54:50	0|wumpus|ok
298 2016-10-25 14:55:12	0|BlueMatt|at least afaiu
299 2016-10-25 14:55:34	0|wumpus|(apparantly I added the backport label to #8282, but didn't add any rationale, and there's no discussion there. But your reasoning makes sense)
300 2016-10-25 14:55:38	0|instagibbs|yes that was the reasoning
301 2016-10-25 14:56:55	0|sipa|indeed, i think it was discussed in a meeting
302 2016-10-25 15:05:13	0|wumpus|in any case if people agree that the assert issue warrants an rc we should roll it immediately, to delay the release as little as possible
303 2016-10-25 15:06:04	0|wumpus|right now it'd set earliest-possible-final date to next week, which'd be oct 1
304 2016-10-25 15:06:29	0|wumpus|NOV 1
305 2016-10-25 15:07:46	0|sipa|we all know that 31 OCT == 25 DEC.
306 2016-10-25 15:09:44	0|BlueMatt|*facepalm*
307 2016-10-25 15:10:01	0|BlueMatt|wumpus: I'd vote no
308 2016-10-25 15:10:34	0|BlueMatt|its a local assert against a very strange configuration and a missing lock that seems nearly impossible to cause problems with, including a requirement that you be doing something stragely locally
309 2016-10-25 15:13:59	0|sipa|maxconnections set to 8 or lower is very common , i think
310 2016-10-25 15:16:04	0|sipa|though, given that it took so long to find, perhaps less common than i thought
311 2016-10-25 15:16:29	0|BlueMatt|so its maxconnections < 8 and then you get an incoming connectiotn?
312 2016-10-25 15:16:41	0|BlueMatt|I mean i think maxconnections < 8 with incoming connections is maybe strange?
313 2016-10-25 15:18:03	0|wumpus|I don't think it is *very* common
314 2016-10-25 15:20:42	0|BlueMatt|I'm ok with an 0.13.2 for this, delaying 0.13.1 for this seems overkill
315 2016-10-25 15:20:57	0|sipa|ok
316 2016-10-25 15:22:02	0|btcdrak|ack
317 2016-10-25 15:30:09	0|BlueMatt|so pending no other bugs 0.13.0-final would be tagaged on thurs?
318 2016-10-25 15:33:05	0|GitHub26|[13bitcoin] 15TheBlueMatt opened pull request #9014: Fix block-connection performance regression (06master...062016-10-fix-tx-regression) 02https://github.com/bitcoin/bitcoin/pull/9014
319 2016-10-25 15:34:25	0|BlueMatt|ehh, 13.1-final
320 2016-10-25 15:52:30	0|wumpus|yes
321 2016-10-25 16:14:03	0|gmaxwell|I asked for the backport and the issue is that without feelers addrman learns about witness peers VERY slowly.
322 2016-10-25 16:19:26	0|gmaxwell|Sorry that it caused problems, though I still feel it was a good decision. I'm happier about a 0.13.1 that can't run with maxconnections<10 than one that doesn't learn update its addrman for peer info.
323 2016-10-25 16:21:40	0|gmaxwell|wumpus: the downside of that maxconnections assert is this: there are people running max connections cut down to smaller numbers (we've recommended it in the past, I've encountered users with it, etc).  I don't know how many but they exist.  And the assert only happens when an inbound connection happens.
324 2016-10-25 16:21:55	0|gmaxwell|So you'll start the node, think it's all happy, then then boom, it crashes.
325 2016-10-25 16:24:28	0|gmaxwell|I don't think that there is a ~need~ to delay, but I do think it would more or less immediately require a 0.13.2.
326 2016-10-25 16:34:55	0|btcdrak|easily documented in the release notes under known issues
327 2016-10-25 16:35:49	0|gmaxwell|yes, well it _will_ cause surprise crashes for some users. As not everyone reads the release notes.
328 2016-10-25 16:36:50	0|btcdrak|maybe, but if people dont RTM there isnt much you can do.
329 2016-10-25 16:37:08	0|gmaxwell|'crashes'-- not really a crash in the kind of uncontrolled failure that could be truly bad that a crash usually is, but the user can't see te difference.
330 2016-10-25 16:47:54	0|BlueMatt|gmaxwell: yea, I agree its really not good, but i also dont think its worth delaying 0.13.1 for it
331 2016-10-25 16:48:50	0|gmaxwell|Is that really the question?  Are we otherwise going to do the final today?
332 2016-10-25 16:54:25	0|gmaxwell|grepping my logs,
333 2016-10-25 16:54:27	0|gmaxwell|05:57 < gijensen> I run my tn node with maxconnections=8
334 2016-10-25 16:54:49	0|gmaxwell|08:54 < KipIngram> I'm running with maxconnections=5 and dbcache=768.
335 2016-10-25 16:55:27	0|gmaxwell|02:06 < epscy> pancake: setting maxconnections to 4 (or 3) helped me
336 2016-10-25 16:56:09	0|gmaxwell|11:01 < geir> Tried bitcoind -dbcache=50 -nolisten -maxconnections=8
337 2016-10-25 16:56:18	0|BlueMatt|so which is worse: shipping segwit with only 13/14 days (incl weekends) before first possible lock-in or shipping with a known assert and following up with a 0.13.2 very quickly
338 2016-10-25 16:56:51	0|gmaxwell|10:13 < osmosis> i was able to get what I wanted by using, -maxconnections=0  for testing
339 2016-10-25 16:56:56	0|gmaxwell|08:11 < m0gliE> -maxconnections=6
340 2016-10-25 16:57:22	0|gmaxwell|01:15 < Krellan> As it is now, when I lower maxconnections below 8, my node becomes 100% outbound, no inbound.
341 2016-10-25 16:58:15	0|gmaxwell|13:16 < HM2> maxconnections=8, server=0
342 2016-10-25 16:59:05	0|gmaxwell|there are a lot more with the figure being >=10.  And it was more common further in the past to see people mention it.
343 2016-10-25 16:59:36	0|BlueMatt|<BlueMatt> so which is worse: shipping segwit with only 13/14 days (incl weekends) before first possible lock-in or shipping with a known assert and following up with a 0.13.2 very quickly
344 2016-10-25 17:00:36	0|gmaxwell|I think that if it's going to ship with an exposed assert we're not likely to fix anyting else except something truely network breaking, and we should ship now.
345 2016-10-25 17:00:58	0|gmaxwell|ten we should do an RC for 0.13.2 pretty much immediately.
346 2016-10-25 17:01:11	0|BlueMatt|that i agree with
347 2016-10-25 17:02:01	0|BlueMatt|though at this point we've fixed enough random stuff in 0.13.1 that we probably also want a 0.13.0.1 for those who wish to not switch to segwit
348 2016-10-25 17:02:04	0|gmaxwell|I think sticking to a rigid schedule is harmful to users. I also don't see why we couldn't merge the assert fix now, and have a developer only RC (tag but no binaries) and final a day later.
349 2016-10-25 17:02:23	0|gmaxwell|BlueMatt: sure, but that can be done after the 0.13.1 release.
350 2016-10-25 17:02:30	0|BlueMatt|gmaxwell: indeed, and should be
351 2016-10-25 17:04:38	0|BlueMatt|I'm not a fan of making a code change and tagging final a day later
352 2016-10-25 17:06:48	0|gmaxwell|that seems like formulaic thinking, -- it's the removal of an assert which was just recently added, that does a >0 test on a variable where the only other use is a <= test...
353 2016-10-25 17:07:16	0|gmaxwell|watcha worrying about? that someone could run with an unusual configuration and find their node crashes on a later connect? :)
354 2016-10-25 17:11:59	0|BlueMatt|i mean i assume the assert was added by someone who used the assumption in their thinking about the code logic, as well as reviewers of the original pr
355 2016-10-25 17:12:45	0|gmaxwell|if so thats only an argument to not release.
356 2016-10-25 17:13:21	0|BlueMatt|well the reviewers/original author wrote code under those assumptions, and while they can be violated, they are rarely violated, which was the argument for not backporting
357 2016-10-25 17:13:38	0|gmaxwell|there is no local effect of removing it, but if you were reasoning about far away code by "this case can't happen because there is an assert over there" -- well you were wrong.
358 2016-10-25 17:14:23	0|gmaxwell|BlueMatt: to e clear anytime you run with maxconnections below ten that assert is violated the whole time... it only gets around to actually shutting down when an inbound comes in, but the condition was still violated.
359 2016-10-25 17:14:35	0|BlueMatt|I'm aware
360 2016-10-25 17:17:04	0|MarcoFalke|If anything, the assert should be checking >= 0
361 2016-10-25 17:17:07	0|MarcoFalke|and not >0
362 2016-10-25 17:17:18	0|gmaxwell|it's still pointlss in any case.
363 2016-10-25 17:17:46	0|MarcoFalke|I somehow feel uncomfortable shipping code which crashes after some time, unexpectedly.
364 2016-10-25 17:17:48	0|gmaxwell|consider, it depends on no dynamic state. It could be in init.cpp.
365 2016-10-25 17:17:53	0|BlueMatt|i dont think we disagree on whether the fix (removing it) is probably correct
366 2016-10-25 17:18:19	0|MarcoFalke|Hmm, generally I like asserts to verify assumptions about the code.
367 2016-10-25 17:18:31	0|gmaxwell|MarcoFalke: yes, thats my concern. If it did immediately on start, I'd say fine! release note it and be done.
368 2016-10-25 17:19:21	0|BlueMatt|hum, thats true
369 2016-10-25 17:19:22	0|sipa|BlueMatt: i think there may be a larger change optimally, but not for 0.13.x
370 2016-10-25 17:20:08	0|MarcoFalke|I think we are missing documentation on how feelers should behave when maxconnections is given
371 2016-10-25 17:20:15	0|MarcoFalke|The current behavior makes sense
372 2016-10-25 17:20:24	0|MarcoFalke|Even though it was never meant to work this way
373 2016-10-25 17:21:01	0|wumpus|gmaxwell: so your proposal would be to do an rc3 with only the assert removed, release no binaries, and don't move final for it?
374 2016-10-25 17:21:30	0|gmaxwell|BlueMatt: how come you weren't swayed when I said that above, "So you'll start the node, think it's all happy, then then boom, it crashes." ? :)
375 2016-10-25 17:21:37	0|gmaxwell|wumpus: yes, that is my proposal.
376 2016-10-25 17:22:08	0|wumpus|so should we then do.. a vote or something? :/
377 2016-10-25 17:22:42	0|MarcoFalke|Was there a date when to tag final?
378 2016-10-25 17:22:52	0|BlueMatt|gmaxwell: no, the fact that this would be better if it crashed right away
379 2016-10-25 17:22:53	0|wumpus|yes, tomorrow
380 2016-10-25 17:23:13	0|BlueMatt|alternatively, just throwing this out there, we could make it crash on startup by adding code there instead :p
381 2016-10-25 17:23:15	0|MarcoFalke|Ok, so today rc3 with no gitian builds and tomorrow final?
382 2016-10-25 17:23:45	0|wumpus|I guess, I'm fine with doing that if there is common agreement to do that
383 2016-10-25 17:23:56	0|sipa|sounds good to me
384 2016-10-25 17:24:09	0|BlueMatt|I'm really not a fan...
385 2016-10-25 17:25:03	0|GitHub191|[13bitcoin] 15laanwj closed pull request #9011: 0.13.1 backports conditional on rc3 (060.13...062016_10_backports_conditional_rc3) 02https://github.com/bitcoin/bitcoin/pull/9011
386 2016-10-25 17:25:08	0|sipa|the only difference from removing an assert is that some behaviour caused a crash before, now crashes in a different way
387 2016-10-25 17:25:27	0|BlueMatt|I mean realistically when are we gonna have binaries out for 0.13.1? not till monday probably anyway
388 2016-10-25 17:25:33	0|MarcoFalke|It does not crash in a different way, now.
389 2016-10-25 17:25:37	0|wumpus|I think multiple people verified that the code doesn't crash if that value becomes 0 or negative
390 2016-10-25 17:26:04	0|MarcoFalke|The value is only used in the local scope of the function once
391 2016-10-25 17:26:09	0|gmaxwell|I've been running a public node negative number there for ~two days now.
392 2016-10-25 17:26:09	0|wumpus|right
393 2016-10-25 17:26:36	0|gmaxwell|(running with maxconnections 8)
394 2016-10-25 17:27:36	0|BlueMatt|well if we're not gonna get binaries out for 0.13.1 till sunday/weekend anyway, why not push tag by a day?
395 2016-10-25 17:28:01	0|wumpus|who knows? gitian building goes really fast these days
396 2016-10-25 17:28:02	0|BlueMatt|we can tag thurs instead of tomorrow with a no-binary rc (but announcements for it) and then tag on thurs and give fri/sat to do gitian builds
397 2016-10-25 17:28:29	0|wumpus|if we're going to do rc3 with just the assert removed I'm going to tag *now*
398 2016-10-25 17:28:34	0|gmaxwell|what does that change?
399 2016-10-25 17:28:40	0|gmaxwell|that was a reply to BlueMatt
400 2016-10-25 17:28:55	0|wumpus|we know exactly what we want to do so no need to delay one second
401 2016-10-25 17:29:33	0|BlueMatt|gmaxwell: a) doing an announce so that we feel marginally more comfortable doing a fast turnaround without getting more testing, and b) give a day to actually do that testing
402 2016-10-25 17:30:26	0|gmaxwell|BlueMatt: if, in the astronomically unlikely event that removing the assert introduces a serious bug, in the next couple days before the announce and binaries are out, then we pull it.
403 2016-10-25 17:30:29	0|GitHub136|13bitcoin/060.13 1458d4fa7 15MarcoFalke: [net] Remove assert(nMaxInbound > 0)...
404 2016-10-25 17:30:29	0|GitHub136|[13bitcoin] 15laanwj pushed 1 new commit to 060.13: 02https://github.com/bitcoin/bitcoin/commit/58d4fa7da30cb57e5fc3dca62f49a64e126c76cd
405 2016-10-25 17:30:36	0|MarcoFalke|BlueMatt: In which case it does still make sense to tag rc3 sooner than later
406 2016-10-25 17:30:43	0|BlueMatt|MarcoFalke: yes
407 2016-10-25 17:31:09	0|BlueMatt|gmaxwell: yes, I'm suggesting a) we get testing on that by doing an announce for rc3, and b) we push release bins to sunday so that we have time before needing to pull it
408 2016-10-25 17:31:20	0|BlueMatt|gmaxwell: and we still get binaries out before monday morning
409 2016-10-25 17:32:05	0|wumpus|I'm not normally a fan of this either, but this is so trivial
410 2016-10-25 17:32:40	0|BlueMatt|wumpus: agreed, hence why I'm suggesting we be willing to amend the process, but going all the way to tagging quicker in the hope that we give people one more weekday of release seems overkill to me
411 2016-10-25 17:32:51	0|wumpus|I mean the only reason that this is any issue at all is that we force building with asserts, if not, people building with NDEBUG wouldn't even notice
412 2016-10-25 17:33:14	0|wumpus|* [new tag]         v0.13.1rc3 -> v0.13.1rc3
413 2016-10-25 17:35:40	0|BlueMatt|wumpus: wait, why did we not include the cs_main missing lock fix in rc3?
414 2016-10-25 17:36:38	0|wumpus|because that is more impact / risk than just removing an assert
415 2016-10-25 17:37:03	0|wumpus|a locking change would need more testing
416 2016-10-25 17:37:40	0|morcos|wumpus: ok i don't have a strong opinion, but i think that if we were going to bother doing another rc, then it might have been worth including that so we didn't need to issue another bug fix release for 0.13.1 later
417 2016-10-25 17:38:03	0|achow101|what about the other stuff listed in 9011?
418 2016-10-25 17:38:05	0|gmaxwell|I'm of a similar view with wumpus.
419 2016-10-25 17:38:07	0|wumpus|morcos: we'll have to, anyway I' m sure there will be plenty of bugs
420 2016-10-25 17:38:46	0|wumpus|the idea would be to do a rc3 with only the assert removed, which is atrivial change, o we don't have to delay the release by another week for testing
421 2016-10-25 17:39:18	0|wumpus|the other option would be doing a rc3, including more, but delaying -final until next week
422 2016-10-25 17:39:20	0|morcos|wumpus: ok.. sufficiently convinced
423 2016-10-25 17:39:30	0|achow101|wouldn't doing rc3 knock the release back to nov 1? Or am I missing something?
424 2016-10-25 17:39:37	0|BlueMatt|achow101: it did not
425 2016-10-25 17:39:44	0|morcos|its rc2.01
426 2016-10-25 17:39:46	0|wumpus|achow101: it would have, if we included actual serious changes
427 2016-10-25 17:39:57	0|wumpus|removing this assert is so trivial
428 2016-10-25 17:40:19	0|BlueMatt|however, I'd still like to push tagging to thursday and release on sunday instead of tagging tomorrow and release either friday or saturday (or sunday)
429 2016-10-25 17:40:25	0|wumpus|and no, I don't feel like discussing that further or backstepping now, that was just a project decision
430 2016-10-25 17:40:26	0|gmaxwell|morcos: at least in my thinking, I'd consider the issue seperately.
431 2016-10-25 17:40:44	0|gmaxwell|I wouldn't be included to do a short cycle RC for the lock, like I am for the trivial assert.
432 2016-10-25 17:40:47	0|achow101|so when is final planned for?
433 2016-10-25 17:40:51	0|wumpus|tomorrow
434 2016-10-25 17:40:59	0|wumpus|eh, no, thursday
435 2016-10-25 17:41:27	0|BlueMatt|oh, it was already thursday
436 2016-10-25 17:41:35	0|wumpus|yes it was already thursday
437 2016-10-25 17:41:44	0|BlueMatt|wumpus: can we do an announce for the rc3 to the ml?
438 2016-10-25 17:41:46	0|BlueMatt|even without bins?
439 2016-10-25 17:41:47	0|wumpus|the point was not to change that
440 2016-10-25 17:41:56	0|achow101|do we still need to gitian build it?
441 2016-10-25 17:41:56	0|wumpus|BlueMatt: sure ,feel free to do so, I"m going to bed
442 2016-10-25 17:41:59	0|BlueMatt|indeed, I'm aware
443 2016-10-25 17:42:06	0|BlueMatt|achow101: we are not doing gitian builds of rc3
444 2016-10-25 17:42:17	0|wumpus|achow101: nope
445 2016-10-25 17:42:23	0|achow101|ok
446 2016-10-25 17:42:34	0|sipa|wumpus: good night!
447 2016-10-25 17:42:34	0|wumpus|you can gitian-build it for yourself ofcourse, or if you want to compare against someone else
448 2016-10-25 17:45:00	0|cfields_|I'll build either way so we can have something to point to if anyone wants it
449 2016-10-25 17:46:06	0|gmaxwell|assuming final is the same would the gitian binaries actually be the same?
450 2016-10-25 17:46:49	0|wumpus|unfortunately, no, because the build embeds the tag from git :(
451 2016-10-25 17:47:24	0|wumpus|if not for that the binary for -final would be exactly the same as -rc<last>
452 2016-10-25 17:48:34	0|wumpus|assuming no commits in between either
453 2016-10-25 17:48:36	0|BlueMatt|cfields_: whats the status of the osx change? are we gonna change the plist for final?
454 2016-10-25 17:49:13	0|wumpus|as the commit id# is also in the executable
455 2016-10-25 17:49:16	0|cfields_|BlueMatt: i think we should, yes. There should be ~zero practical impact.
456 2016-10-25 17:49:18	0|gmaxwell|wumpus: perhaps we should have the build system mask that out in the future. (e.g. strip rcN from the tag it extracts)
457 2016-10-25 17:49:34	0|BlueMatt|cfields_: yes, fine with that being merged w/o rc, just asking if its gonna happen
458 2016-10-25 17:50:28	0|wumpus|gmaxwell: strictly it doesn't need to extract a tag at all, the version should be in configure.ac/clientversion.h. But some poeple (I think mostly gavin) regarded it as a feature that a build could tell it is -rc sometnhing
459 2016-10-25 17:50:35	0|wumpus|gmaxwell: that's why that was never removed
460 2016-10-25 17:50:41	0|cfields_|wumpus: you ok with https://github.com/bitcoin/bitcoin/issues/8577#issuecomment-255947269 with no additional testing?
461 2016-10-25 17:51:00	0|cfields_|sorry that took so long, I chased it all day yesterday
462 2016-10-25 17:51:32	0|gmaxwell|an alternative to achieve I think the same end would be for the places we display that tag to also display a hash of the actual binary that you're running.
463 2016-10-25 17:52:21	0|wumpus|cfields_: does that affect anything?
464 2016-10-25 17:53:20	0|cfields_|wumpus: practically, no. Bitcoin-qt is busted on 10.7. This would just make it refuse to run there, rather than mysteriously crashing.
465 2016-10-25 17:54:09	0|wumpus|gmaxwell: indeed, for gitian builds the hash of the executable would be deterministic and possible to look up to a version / commit hash
466 2016-10-25 17:54:20	0|MarcoFalke|"The OS will then present the user with an error message if they try to run the application on an older version of the system."
467 2016-10-25 17:54:34	0|wumpus|cfields_: sounds good to me
468 2016-10-25 17:55:05	0|cfields_|wumpus: ok, doing now. I have a 10.7 vm, so i can verify that it works as intended on 10.7 and >10.7.
469 2016-10-25 17:55:40	0|wumpus|cfields_: I was wondering if it also changed e.g. APIs that are exposed to the executable, but if it's just a silly check that doesn't affect anything else then there is no risk changing it
470 2016-10-25 17:55:59	0|gmaxwell|wumpus: alernatively, it could embed some hash of the source code that wouldn't be changed by updating tags.
471 2016-10-25 17:56:21	0|cfields_|wumpus: that would require bumping the minversion to 10.8. Which we should do for master, but yes, not here.
472 2016-10-25 17:56:49	0|cfields_|-mmacosx-version-min, that is
473 2016-10-25 17:59:57	0|wumpus|BlueMatt: you sent the rc announcement to bitcoin-dev instead of bitcoin-core-dev :)
474 2016-10-25 18:00:12	0|BlueMatt|they're different? oops
475 2016-10-25 18:00:13	0|wumpus|BlueMatt: otherwise, thanks!
476 2016-10-25 18:00:21	0|BlueMatt|ehh, see, this is why i dont do release process :p
477 2016-10-25 18:00:43	0|btcdrak|please send to bitcoin-core-dev also
478 2016-10-25 18:00:45	0|wumpus|no problem, just send a copy to bitcoin-core-dev too
479 2016-10-25 18:01:57	0|BlueMatt|ok, done
480 2016-10-25 18:06:14	0|jonasschnelli|<*highlight>	[13:50:51] <wumpus:#bitcoin-core-dev> jonasschnelli: re: https://github.com/bitcoin/bitcoin/pull/9010, any idea why not all parameter interaction was moved to InitParameterInteraction?
481 2016-10-25 18:06:43	0|jonasschnelli|IIRC, I did only move the SoftSetBoolArg() in https://github.com/bitcoin/bitcoin/pull/6780
482 2016-10-25 18:06:59	0|jonasschnelli|But I can't remember the exact reason why not every interaction was moved.
483 2016-10-25 18:07:03	0|instagibbs|is there any reason why the wallet's CommitTransaction reject message is so bland? Should be trivial to pass the failure state up from AcceptToMemoryPool
484 2016-10-25 18:08:20	0|wumpus|instagibbs: patches welcome
485 2016-10-25 18:09:02	0|instagibbs|roger
486 2016-10-25 18:09:27	0|cfields_|instagibbs: i have a PR that changes that behavior and creates better error messages. sec.
487 2016-10-25 18:09:42	0|instagibbs|I've literally implemented it before, for elements, but then forgot about it
488 2016-10-25 18:09:48	0|wumpus|I'm sure that the reason is that no one ever bothered to make that message better, and also the detailed state return message is something relatively new. I think we have an ancient issue from ~2010 open about some weird message in the wallet that never was fixed :-)
489 2016-10-25 18:09:50	0|instagibbs|and now running into it again working on Core, d'oh
490 2016-10-25 18:10:37	0|instagibbs|cfields_, I'd appreciate a patch if you have it. IIRC it's only a few lines so I can do it too
491 2016-10-25 18:10:40	0|wumpus|we have tons of pulls open about log messages and comments, but surprisingly few people work on user-facing messages
492 2016-10-25 18:10:53	0|cfields_|grr, I need to clean that up and resubmit. Trying to fix up my PRs today.
493 2016-10-25 18:11:03	0|instagibbs|wumpus, well right now any error in wallet's transaction gives you a super broad message about money missing
494 2016-10-25 18:11:05	0|cfields_|instagibbs: see the comments in https://github.com/bitcoin/bitcoin/pull/8888
495 2016-10-25 18:11:21	0|cfields_|instagibbs: specifically: https://github.com/theuni/bitcoin/commit/349edab789557db615b29a5869118b4b08c50dab
496 2016-10-25 18:12:29	0|cfields_|instagibbs: with the caller responsible for ATMP and broadcasting, the errors can be much more specific. IIRC I basically just copied them as-is there though.
497 2016-10-25 18:14:00	0|instagibbs|Yeah that looks better, but it could still stand to pass back why it failed mempool entry
498 2016-10-25 18:16:35	0|cfields_|instagibbs: for sure.
499 2016-10-25 18:22:43	0|wumpus|the ancient wallet message I was talking about still exists, but apparently I closed the issue: https://github.com/bitcoin/bitcoin/issues/211 "Error: This transaction requires a transaction fee of at least %s because of its amount, complexity, or use of recently received funds!"
500 2016-10-25 18:25:11	0|cfields_|heh
501 2016-10-25 18:25:12	0|wumpus|thinking of it, neither amount, complexity or use of recently received funds counts towards the fee
502 2016-10-25 18:25:33	0|jl2012|has anyone proposed to have an RPC command like "checkrawtransaction", which does everything of "sendrawtransaction" but not adding it to mempool?
503 2016-10-25 18:25:41	0|gmaxwell|"because of the required resources"
504 2016-10-25 18:25:44	0|wumpus|jl2012: yes, I had a pull for that once
505 2016-10-25 18:25:53	0|cfields_|jl2012: decoderawtransaction ?
506 2016-10-25 18:26:17	0|jl2012|decode won't test for validity
507 2016-10-25 18:26:26	0|jl2012|wumpus: why isn't it merged?
508 2016-10-25 18:27:10	0|gmaxwell|jl2012: the way I've recommended doing that before is with a block proposal.
509 2016-10-25 18:27:22	0|gmaxwell|jl2012: which lets you also have a chain of unconfirmed transactions.
510 2016-10-25 18:27:22	0|wumpus|lack of testing
511 2016-10-25 18:27:31	0|wumpus|mine could do that too
512 2016-10-25 18:27:48	0|gmaxwell|wumpus: that sounds good.
513 2016-10-25 18:27:55	0|wumpus|jl2012: https://github.com/bitcoin/bitcoin/pull/7552
514 2016-10-25 18:28:50	0|wumpus|too much arguing and too little actual interest so I eventually gave up, but feel free to resurrect it (in some form)
515 2016-10-25 18:32:12	0|jl2012|access to one key, you could still get the money back with another key after the locktime
516 2016-10-25 18:32:12	0|jl2012|i'm thinking of a CSV timelocked vault. You send money to a 2-of-2 which you have both key. Then you create a tx, sending this 2-of-2 to this : IF 1-of-2 , locktime CSV ELSE 2-of-2 ENDIF. Then you store the 2 keys separately, with this unconfirmed tx. If one of the keys was stolen, you could still recover the fund before the thief got it. If you lost one
517 2016-10-25 18:32:31	0|jl2012|But I need the ability to verify the unconfirmed tx is actually valid
518 2016-10-25 18:33:14	0|GitHub115|[13bitcoin] 15theuni opened pull request #9015: release: bump required osx version to 10.8. Credit jonasschnelli. (06master...06osx-disable107) 02https://github.com/bitcoin/bitcoin/pull/9015
519 2016-10-25 18:33:39	0|GitHub139|[13bitcoin] 15instagibbs opened pull request #9016: Return useful error message on ATMP failure (06master...06atmperror) 02https://github.com/bitcoin/bitcoin/pull/9016
520 2016-10-25 18:33:44	0|gmaxwell|you can make the spend smaller if the 1 of 2  is just a 1 of 1 with one of the two keys.
521 2016-10-25 18:34:39	0|jl2012|yes, the 1/2 for the number of sigs could be pushed with IF/ELSE
522 2016-10-25 18:37:36	0|instagibbs|wumpus, too bad, I think rpc's checking for validity without committing them are useful
523 2016-10-25 18:38:08	0|gmaxwell|instagibbs: go pick up his PR.
524 2016-10-25 18:38:19	0|gmaxwell|no one was opposed to the idea.
525 2016-10-25 18:39:11	0|instagibbs|I remember it being contentious regarding the devilish details, but I'll take another look
526 2016-10-25 18:39:40	0|wumpus|indeed, it was just that the way some people wanted to do it involved changing code and refactoring all over the place
527 2016-10-25 18:41:55	0|wumpus|and as this localized change was already hard enough to get review and testing for, I feared for anything that would touch main more. BUt maybe changes since have made it easier, I don't know.
528 2016-10-25 18:42:41	0|wumpus|I tend to lose interest in projects after a while, that doesn't mean they're not worth doing
529 2016-10-25 18:43:30	0|achow101|i'm thinking of doing a verifyrawtx with it doing exactly the same thing as sendrawtx except the actual send and placing in mempool parts
530 2016-10-25 18:44:08	0|wumpus|that's easier said than done, especially if you want to be able to handle chains of transactions depending on each other
531 2016-10-25 18:44:32	0|wumpus|without actually putting the dependencies in the mempool
532 2016-10-25 18:45:13	0|instagibbs|achow101, read the PR thread, it's all debated there I think
533 2016-10-25 18:45:34	0|instagibbs|subtle issues mean it's harder to push through
534 2016-10-25 18:45:34	0|wumpus|yes
535 2016-10-25 18:46:00	0|gmaxwell|well the PR might not make it clear that being able to handle chains is pretty useful.
536 2016-10-25 18:46:16	0|wumpus|it's all been debated before, I don't feel like getting involved again, thanksfor the reminder
537 2016-10-25 18:47:17	0|achow101|well my idea is to just modify accepttomempool
538 2016-10-25 18:48:04	0|wumpus|but would you want changes there for an RPC call whose goal is to *not* touch the mempool?
539 2016-10-25 18:49:08	0|wumpus|accepttomempool(bla,bla,dontAcceptToMempoolFlag) would be wrong. So you'd end up splitting up functions and refactoring. Maybe that needs to happen anyway, I don't know.
540 2016-10-25 18:49:44	0|sipa|at risk of bringing up older discussions again: just checking for consensus is easy if we don't want to touch the mempool for chains of transactions, but testing all policy is much harder (especially if it includes replacement, rbf, eviction, timelocking, fee rates, ...)
541 2016-10-25 18:50:06	0|sipa|but if it includes policy it's also much less meaningful to affect the mempool
542 2016-10-25 18:50:17	0|achow101|why would adding a flag to acceptomempool be wrong?
543 2016-10-25 18:50:33	0|wumpus|because the function is called accepttomempool
544 2016-10-25 18:50:48	0|sipa|let's rename it to AcceptableToMempool
545 2016-10-25 18:50:50	0|sipa|*ducks*
546 2016-10-25 18:51:19	0|wumpus|yes, if you split up functions into a 'acceptable policy' part and 'add to mempool', it makes more sense
547 2016-10-25 18:51:26	0|wumpus|I'm repeating myself
548 2016-10-25 18:51:55	0|wumpus|agree that checking for consensus is fairly easy
549 2016-10-25 18:52:06	0|wumpus|the difficult part was all the different policies
550 2016-10-25 18:52:26	0|wumpus|if that's not necessary then indeed it'd just be a 'block proposal'
551 2016-10-25 18:52:56	0|wumpus|although you probably still want to be able to pass in things such as height, and time, for -final checks
552 2016-10-25 18:53:36	0|wumpus|'is this valid at height X time Y' instead of necessarily now
553 2016-10-25 19:45:01	0|GitHub111|[13bitcoin] 15instagibbs opened pull request #9017: Enable various p2sh-p2wpkh functionality (06master...06p2shp2wpkhstuff) 02https://github.com/bitcoin/bitcoin/pull/9017
554 2016-10-25 20:22:35	0|Victorsueca|wuuuuuut?
555 2016-10-25 20:22:39	0|Victorsueca|rc3?
556 2016-10-25 20:22:52	0|Victorsueca|I thought rc2 was the choosen one
557 2016-10-25 20:24:14	0|BlueMatt|Victorsueca: see https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-October/013262.html
558 2016-10-25 20:26:41	0|Victorsueca|BlueMatt: thanks
559 2016-10-25 21:49:10	0|GitHub85|[13bitcoin] 15ryanofsky opened pull request #9018: testing pr (please ignore) (06master...06loop) 02https://github.com/bitcoin/bitcoin/pull/9018
560 2016-10-25 22:37:10	0|gmaxwell|40 node_witness peers
561 2016-10-25 22:38:57	0|gmaxwell|5 outbound.
562 2016-10-25 22:53:33	0|luke-jr|looks like he's abusing that PR to run Travis :/
563 2016-10-25 22:53:47	0|luke-jr|guess he doesn't realise it emails everyone
564 2016-10-25 22:54:49	0|gmaxwell|40 node_witness peers If you're a miner or mining pool operator, please see the versionbits FAQ for information about signaling support for a soft fork.  ...
565 2016-10-25 22:55:01	0|gmaxwell|ignore te first part of that line..
566 2016-10-25 22:55:27	0|gmaxwell|so thats (If you're..) is all we say about mining & segwit in the release notes right now.
567 2016-10-25 22:55:52	0|gmaxwell|which is a little anemic. Like, there should be some mention that all mining software needs to be updated for segwit support.
568 2016-10-25 22:56:00	0|gmaxwell|And a list of supporting mining software.
569 2016-10-25 22:56:29	0|luke-jr|gmaxwell: that's slated for the blog post, I think. although I do get a sense that the blog post really should just be the same as release notes..
570 2016-10-25 22:56:42	0|gmaxwell|hm.
571 2016-10-25 22:57:20	0|luke-jr|or perhaps turning the blog post into a segwit deployment FAQ and linking that
572 2016-10-25 22:57:28	0|luke-jr|(so we can update it as needed later)
573 2016-10-25 22:59:23	0|GitHub177|[13bitcoin] 15sipa closed pull request #9018: testing pr (please ignore) (06master...06loop) 02https://github.com/bitcoin/bitcoin/pull/9018