1 2016-10-25T00:02:42  *** fengling has joined #bitcoin-core-dev
  2 2016-10-25T00:02:51  *** AaronvanW has quit IRC
  3 2016-10-25T00:07:32  *** DigiByteDev has joined #bitcoin-core-dev
  4 2016-10-25T00:10:09  *** d_t has quit IRC
  5 2016-10-25T00:12:24  *** DigiByteDev has quit IRC
  6 2016-10-25T00:20:03  *** Soligor has quit IRC
  7 2016-10-25T00:20:37  *** Soligor has joined #bitcoin-core-dev
  8 2016-10-25T00:26:17  *** murch has quit IRC
  9 2016-10-25T00:28:09  *** fengling has quit IRC
 10 2016-10-25T00:28:11  *** nickler_ has quit IRC
 11 2016-10-25T00:30:27  *** alpalp has joined #bitcoin-core-dev
 12 2016-10-25T00:30:28  *** alpalp has joined #bitcoin-core-dev
 13 2016-10-25T00:33:02  *** jtimon has quit IRC
 14 2016-10-25T00:43:13  *** alpalp has quit IRC
 15 2016-10-25T00:49:13  *** fengling has joined #bitcoin-core-dev
 16 2016-10-25T00:52:45  *** alpalp has joined #bitcoin-core-dev
 17 2016-10-25T01:03:51  *** a_meteorite has quit IRC
 18 2016-10-25T01:06:21  *** d_t has joined #bitcoin-core-dev
 19 2016-10-25T01:27:57  *** jcorgan has joined #bitcoin-core-dev
 20 2016-10-25T01:36:36  *** fengling has quit IRC
 21 2016-10-25T02:02:18  *** jujumax has joined #bitcoin-core-dev
 22 2016-10-25T02:04:18  *** fengling has joined #bitcoin-core-dev
 23 2016-10-25T02:04:55  *** jcorgan has left #bitcoin-core-dev
 24 2016-10-25T02:29:09  *** alpalp has quit IRC
 25 2016-10-25T02:31:20  *** d_t has quit IRC
 26 2016-10-25T02:35:16  *** brg444 has joined #bitcoin-core-dev
 27 2016-10-25T02:36:37  *** Chris_Stewart_5 has quit IRC
 28 2016-10-25T02:37:05  *** alpalp has joined #bitcoin-core-dev
 29 2016-10-25T02:41:31  *** alpalp has quit IRC
 30 2016-10-25T02:48:13  *** tulip has joined #bitcoin-core-dev
 31 2016-10-25T02:51:15  *** Giszmo has quit IRC
 32 2016-10-25T03:07:23  *** fengling has quit IRC
 33 2016-10-25T03:23:28  *** DigiByteDev has joined #bitcoin-core-dev
 34 2016-10-25T03:32:16  *** fengling has joined #bitcoin-core-dev
 35 2016-10-25T03:55:34  *** jujumax has quit IRC
 36 2016-10-25T03:57:31  *** brg444 has quit IRC
 37 2016-10-25T03:58:56  *** kadoban has quit IRC
 38 2016-10-25T04:01:00  *** a_meteorite has joined #bitcoin-core-dev
 39 2016-10-25T04:56:36  *** sdaftuar has quit IRC
 40 2016-10-25T04:56:51  *** morcos has quit IRC
 41 2016-10-25T04:56:53  *** zxzzt has quit IRC
 42 2016-10-25T04:57:53  *** DigiByteDev has quit IRC
 43 2016-10-25T04:58:05  *** molz has quit IRC
 44 2016-10-25T04:58:21  *** sdaftuar has joined #bitcoin-core-dev
 45 2016-10-25T04:58:26  *** zxzzt has joined #bitcoin-core-dev
 46 2016-10-25T04:58:43  *** morcos has joined #bitcoin-core-dev
 47 2016-10-25T05:00:14  *** moli has joined #bitcoin-core-dev
 48 2016-10-25T05:19:56  *** paveljanik has quit IRC
 49 2016-10-25T05:38:00  <GitHub169> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ced22d035ac0...67728a389ccf
 50 2016-10-25T05:38:01  <GitHub169> bitcoin/master 3421e74 unsystemizer: Clarify `listenonion`...
 51 2016-10-25T05:38:01  <GitHub169> bitcoin/master 67728a3 Wladimir J. van der Laan: Merge #9004: Clarify `listenonion`...
 52 2016-10-25T05:38:18  <GitHub2> [bitcoin] laanwj closed pull request #9004: Clarify `listenonion` (master...patch-3) https://github.com/bitcoin/bitcoin/pull/9004
 53 2016-10-25T05:44:34  *** jacurn has quit IRC
 54 2016-10-25T05:51:02  *** d9b4bef9 has quit IRC
 55 2016-10-25T05:52:08  *** d9b4bef9 has joined #bitcoin-core-dev
 56 2016-10-25T05:54:44  *** a_meteorite has quit IRC
 57 2016-10-25T05:59:19  <luke-jr> can someone reopen https://github.com/bitcoin/bitcoin/pull/8775 ? the other PR had only a tiny part of it.. (ping wumpus)
 58 2016-10-25T06:00:04  <luke-jr> thanks
 59 2016-10-25T06:00:09  <GitHub15> [bitcoin] laanwj reopened pull request #8775: RPC refactoring: Never access wallet directly, only via new CRPCRequestInfo (master...multiwallet_prefactor_rpc) https://github.com/bitcoin/bitcoin/pull/8775
 60 2016-10-25T06:02:52  *** a_meteorite has joined #bitcoin-core-dev
 61 2016-10-25T06:21:59  <jonasschnelli> wumpus: what do you think about 10.8 as min OSX version for core?
 62 2016-10-25T06:22:17  <wumpus> hehe
 63 2016-10-25T06:23:21  <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
 64 2016-10-25T06:23:47  <jonasschnelli> Heh. Yes. Thats somehow true...
 65 2016-10-25T06:23:58  <jonasschnelli> Though, the original 10.7 bug was reported in #bitcoin
 66 2016-10-25T06:24:09  <jonasschnelli> I guess some users are still on 10.7 for some server-based OSX systems
 67 2016-10-25T06:24:11  <wumpus> "things break all the time on 10.x and no one notices" "if a tree falls..."
 68 2016-10-25T06:24:44  <jonasschnelli> We can reduce the tree-falling risks by setting 10.8 as min OSX.
 69 2016-10-25T06:24:51  <jonasschnelli> Also, we could get rid of some warnings
 70 2016-10-25T06:25:29  <jonasschnelli> I mean we only speak about the official binaries... I guess self-compile should still work fine on OSX
 71 2016-10-25T06:25:31  <sipa> when was 10.7 released?
 72 2016-10-25T06:25:31  <wumpus> so that'd be for 0.14.0 I guess
 73 2016-10-25T06:25:45  <jonasschnelli> IF we do a rc3, then we could add it there
 74 2016-10-25T06:25:56  <jonasschnelli> But no 0.13.1 rc just because of that issue
 75 2016-10-25T06:26:03  <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
 76 2016-10-25T06:26:05  <sipa> 10.7 is 5 years old
 77 2016-10-25T06:26:05  <jonasschnelli> sipa: i'm looking... I guess 2-3 years
 78 2016-10-25T06:26:13  <sipa> july 2011
 79 2016-10-25T06:26:18  <wumpus> if not, well, too bad then
 80 2016-10-25T06:26:35  <jonasschnelli> Okay. I'll work on a patch...
 81 2016-10-25T06:27:09  <jonasschnelli> Well... we could still build against 10.7 but set 10.8 as min osx runtime version... but that would be pretty bad
 82 2016-10-25T06:27:12  <wumpus> I didn't mean 'you should fix this now'
 83 2016-10-25T06:27:15  <sipa> windows 7 is already much older than osx 10.7
 84 2016-10-25T06:27:51  <jonasschnelli> "I'm working on a patch" could result in a work-duration of couple of month . :)
 85 2016-10-25T06:28:13  <sipa> haha
 86 2016-10-25T06:28:34  <jonasschnelli> First finishing the SPV hybrid mode
 87 2016-10-25T06:29:01  <sipa> sounds like a 5 year plan
 88 2016-10-25T06:29:06  <jonasschnelli> hah
 89 2016-10-25T06:29:17  <jonasschnelli> It's already working... but that probably 5% of the work.
 90 2016-10-25T06:29:20  <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
 91 2016-10-25T06:30:03  <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).
 92 2016-10-25T06:31:01  <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
 93 2016-10-25T06:31:12  <luke-jr> pretty sure my father is still using hardware incapable of 64-bit <.<
 94 2016-10-25T06:31:28  <sipa> luke-jr: use qemu :p
 95 2016-10-25T06:31:40  <sipa> jonasschnelli: i don't understand
 96 2016-10-25T06:31:42  <luke-jr> sipa: does qemu support XP? :P
 97 2016-10-25T06:32:48  <sipa> wumpus: microsoft has the world's worst customer base. mostly corporate machines whose maintainers don't like change :)
 98 2016-10-25T06:32:59  <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?
 99 2016-10-25T06:33:17  <jonasschnelli> they always re-download the required blocks
100 2016-10-25T06:33:30  <jonasschnelli> s/they/it
101 2016-10-25T06:33:38  <sipa> jonasschnelli: there is no validation in SPV mode
102 2016-10-25T06:33:49  <jonasschnelli> sipa: there is in hybrid...
103 2016-10-25T06:34:03  <sipa> what do you mean by hybrid?
104 2016-10-25T06:34:14  <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...
105 2016-10-25T06:34:29  <jonasschnelli> the full-node part could once reuse those already downloaded blocks
106 2016-10-25T06:34:30  <wumpus> sipa: btw re: 8753, are you sure comparing void* pointers with greater/lesser is defined behavior? I'm fairly sure but...
107 2016-10-25T06:34:44  <wumpus> C has so many scary edge cases there
108 2016-10-25T06:35:07  <jonasschnelli> but how-every,... hard to explain,... i'll show you some code sipa during the next days/weeks
109 2016-10-25T06:35:08  <luke-jr> jonasschnelli: I don't get the purpose?
110 2016-10-25T06:35:35  <sipa> 6.5.8 Relational operators
111 2016-10-25T06:35:35  <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...
112 2016-10-25T06:35:42  <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...
113 2016-10-25T06:35:48  <sipa> behavior is undefined.
114 2016-10-25T06:35:54  <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
115 2016-10-25T06:36:10  <jonasschnelli> these downloaded blocks can later be used for the validation-full-node part
116 2016-10-25T06:36:24  <sipa> jonasschnelli: that's no different from how block fetching works today
117 2016-10-25T06:36:41  <sipa> jonasschnelli: we often have unvalidated blocks ahead of the point we're fully synced to
118 2016-10-25T06:36:55  <wumpus> so this would compare pointers in different arenas, which can be seen as different "arrays"
119 2016-10-25T06:37:06  <sipa> wumpus: ah, i guess...
120 2016-10-25T06:37:10  <luke-jr> sipa: I think he means you'd download blocks from the other end
121 2016-10-25T06:37:57  *** RoyceX has joined #bitcoin-core-dev
122 2016-10-25T06:38:03  <luke-jr> (in order to scan them for unconfirmed transactions)
123 2016-10-25T06:38:23  <sipa> well if you combine it with pruning you wouldn't keep the blocks on disk downloaded for SPV
124 2016-10-25T06:38:29  <luke-jr> indeed
125 2016-10-25T06:38:33  <sipa> which makes things much easier
126 2016-10-25T06:38:35  <jonasschnelli> Yes. With pruning...
127 2016-10-25T06:38:50  <jonasschnelli> I think i'll start with not keeping these blocks for now.
128 2016-10-25T06:39:00  <jonasschnelli> But it would be a nice use case for full-block SPV (if pruning is disabled)
129 2016-10-25T06:39:07  <jonasschnelli> Because you need the blocks anyways.
130 2016-10-25T06:39:23  <luke-jr> IMO the more valuable SPV-hybrid mode is one where cellular data isn't wasted on downloading full blocks ;)
131 2016-10-25T06:41:34  *** niska has joined #bitcoin-core-dev
132 2016-10-25T06:42:42  *** BlueMatt has quit IRC
133 2016-10-25T06:42:42  *** da2ce7 has quit IRC
134 2016-10-25T06:42:42  *** cheese_ has quit IRC
135 2016-10-25T06:42:42  *** niska` has quit IRC
136 2016-10-25T06:42:42  *** bsm117532 has quit IRC
137 2016-10-25T06:42:54  *** bsm117532 has joined #bitcoin-core-dev
138 2016-10-25T06:43:31  *** BlueMatt has joined #bitcoin-core-dev
139 2016-10-25T06:43:40  <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
140 2016-10-25T06:44:18  <sipa> wumpus: well, the last sentence is that anything else is undefined behaviour. So the compiler may delete your wallet.dat in that case.
141 2016-10-25T06:44:45  <wumpus> welcome to adversarial compiler design 101 :)
142 2016-10-25T06:45:23  *** da2ce7 has joined #bitcoin-core-dev
143 2016-10-25T06:45:23  <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
144 2016-10-25T06:45:38  <sipa> so your solution seems perfectly fine
145 2016-10-25T06:46:12  <wumpus> I'll just keep it as it is then, thanks
146 2016-10-25T06:47:28  <sipa> actually, i don't know if the mapping from pointer to integer is required to keep continuous ranges continuous :)
147 2016-10-25T06:48:05  <wumpus> "
148 2016-10-25T06:48:09  <wumpus> "Ok, bad news. I ended up in the bowels of osx"
149 2016-10-25T06:48:16  <wumpus> poor cfields_
150 2016-10-25T06:48:46  <sipa> did he come across a digest function?
151 2016-10-25T06:50:39  <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
152 2016-10-25T06:52:06  <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
153 2016-10-25T06:52:17  <sipa> *uintptrs
154 2016-10-25T06:52:40  <wumpus> but that wouldn't make sense as the arena is allocated at once, so it needs to be a linear area
155 2016-10-25T06:52:53  <sipa> the pointers need to be linear
156 2016-10-25T06:53:00  <sipa> the integers they map to do not
157 2016-10-25T06:53:00  <wumpus> or at least monotonic, linear isn't even necessary
158 2016-10-25T06:53:09  <sipa> of course, in any compiler below adversialness level 7, this will be the case
159 2016-10-25T06:54:25  <wumpus> hehe, phew, so that's still safe for ~5 years then
160 2016-10-25T06:55:57  <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
161 2016-10-25T06:56:15  <sipa> i don't know whether the standard requires that
162 2016-10-25T06:56:32  <sipa> if not, the cast to uintptr could for example bitflip the result or so
163 2016-10-25T06:56:59  <sipa> or switch the bit or byte order
164 2016-10-25T07:00:26  <wumpus> bleh. So usually it's advised to do pointer arithmethic using [u]char*. But this runs into the issue with comparing ranges.
165 2016-10-25T07:00:31  <wumpus> This makes me sick
166 2016-10-25T07:03:17  <sipa> and you get aliasing rules too
167 2016-10-25T07:03:22  <wumpus> C: "between Scylla and Charybdis"
168 2016-10-25T07:03:26  <wumpus> I don't want to do this anymore
169 2016-10-25T07:03:30  <sipa> :)
170 2016-10-25T07:03:39  <sipa> i don't think any of this matters
171 2016-10-25T07:08:10  <sipa> btw: i believe char* pointers are always allowed to alias anything
172 2016-10-25T07:08:28  <sipa> so if that's the reason for wanting to avoid them, no worries
173 2016-10-25T07:12:12  *** paveljanik has joined #bitcoin-core-dev
174 2016-10-25T07:15:10  <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)
175 2016-10-25T07:19:38  <phantomcircuit> cccccceegehfceddehkuieubrvvrejvvbbnlrclrighk
176 2016-10-25T07:20:32  <jonasschnelli> your new private key?
177 2016-10-25T07:21:22  <wumpus> "this is your brain on C"
178 2016-10-25T07:21:38  <tulip> phantomcircuit: try not spilling soda on your keyboard next time.
179 2016-10-25T07:22:18  <sipa> wumpus: where c is the speed of light, so you're saying he's on speed?
180 2016-10-25T07:22:45  <sipa> i'll see myself out
181 2016-10-25T07:23:01  <tulip> I've been trying to work out where the regression that allows bitcoin core to attempt connections on port 0 is.
182 2016-10-25T07:23:12  <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 :)
183 2016-10-25T07:24:25  * wumpus still wonders if cfields_ got caught by macosx' digest function, he's strangely silent
184 2016-10-25T07:24:35  <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.
185 2016-10-25T07:25:32  <tulip> 2016-10-25 03:04:55.029570 connect() to [376f:ff56:100::]:0 failed: Host is down (64) <- like this
186 2016-10-25T07:25:36  <gmaxwell> tulip: the attempts to port 0 may be a side effect of the witness preference.
187 2016-10-25T07:25:52  <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
188 2016-10-25T07:26:19  <tulip> gmaxwell: my thinking was that they were always there, just never chosen before because we never reached the fall back.
189 2016-10-25T07:26:27  <gmaxwell> bingo.
190 2016-10-25T07:26:34  <wumpus> it'd make sense to discard records with port 0 as invalid though
191 2016-10-25T07:27:03  <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.
192 2016-10-25T07:27:05  *** whphhg has quit IRC
193 2016-10-25T07:27:23  <tulip> oh, so choosing not to connect to a node counts as a try?
194 2016-10-25T07:27:32  <gmaxwell> we should probably prevent port 0 from ending up in addrman at all.
195 2016-10-25T07:27:48  <gmaxwell> tulip: yes sir. read the loop in CConman:ThreadOpenConnections()
196 2016-10-25T07:28:52  <wumpus> yes, like invalid addresses, invalid ports probably shouldn't end up in addrman at all
197 2016-10-25T07:29:50  <wumpus> may makesense to add a generic blacklist of ports. 22, 25, etc
198 2016-10-25T07:29:57  <tulip> the only invalid IP address I've seen in my logs is, the IPV6 ones are valid but unroutable
199 2016-10-25T07:30:15  <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.
200 2016-10-25T07:30:36  <gmaxwell> tulip: addrman already filters several broad families of invalid IPs.
201 2016-10-25T07:30:45  <gmaxwell> s/invalid/non-routable/ really
202 2016-10-25T07:30:55  <wumpus> meh, I'd prefer not to hardcode the port even further
203 2016-10-25T07:31:43  *** a_meteorite has quit IRC
204 2016-10-25T07:33:03  <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'
205 2016-10-25T07:33:43  <gmaxwell> ya, but does it? requires there be enough non-8333 hosts to actually find a working one. :P
206 2016-10-25T07:33:54  <wumpus> otherwise it may suddenly become a really attractive measure
207 2016-10-25T07:34:07  <wumpus> there are some non-8333 hosts to connect to
208 2016-10-25T07:34:23  <gmaxwell> fair enough.
209 2016-10-25T07:34:42  <tulip> there's 1990 peers ever to have been crawled by this seed node which have a non standard port.
210 2016-10-25T07:36:03  <tulip> port frequencies http://pastebin.com/raw/wZSSDYW6
211 2016-10-25T07:36:06  <wumpus> may make sense to listen on 8333 as well as arandom non-standard port
212 2016-10-25T07:36:32  <wumpus> 8333 to make sure people connect to you, and the non-standard port to help people behind weird firewalls
213 2016-10-25T07:37:40  <gmaxwell> wumpus: I was just thinking that too.
214 2016-10-25T07:38:22  <wumpus> and for the built-in seed node selection there should probably be some non-standard ports too
215 2016-10-25T07:38:29  <gmaxwell> well also something we could deploy on relatively short notice if there were a widespread reason.
216 2016-10-25T07:38:42  <gmaxwell> seed nodes make sense.
217 2016-10-25T07:39:12  <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
218 2016-10-25T07:39:57  <wumpus> sure, I agree, but it just seems stupid to have so-called robust P2P software be blocked by filtering out one port :)
219 2016-10-25T07:40:57  <wumpus> it also means you can make a selection "no bitcoin here, but we allow dogecoin and litecoin through!"
220 2016-10-25T07:41:32  <sipa> we should make the port depend on the (routable) IP
221 2016-10-25T07:42:30  <sipa> 1024 + H("bitcoin port" || ip) % (32768 - 1024)
222 2016-10-25T07:43:40  <luke-jr> can we not at least not require uint256 math support? :x
223 2016-10-25T07:43:51  <sipa> sure
224 2016-10-25T07:43:59  <gmaxwell> yea, but sadly we don't really know our IP at the relevant time.
225 2016-10-25T07:44:42  <sipa> we need to implement IP over reddit.
226 2016-10-25T07:44:43  <wumpus> "spread spectrum TCP" hehe
227 2016-10-25T07:44:48  <gmaxwell> it's harmless to just save a port to peers.dat and try to use it.
228 2016-10-25T07:45:05  <luke-jr> sipa: can we make an encoding that looks like r/BTC posters? :p
229 2016-10-25T07:45:22  <sipa> luke-jr: working on software for that!
230 2016-10-25T07:45:30  <tulip> https://www.reddit.com/r/blockchainheaders/
231 2016-10-25T07:46:31  <sipa> tulip: last post 1 week ago :(
232 2016-10-25T07:47:27  <rabidus_> maybe blockchain is dead
233 2016-10-25T07:48:28  <luke-jr> :x
234 2016-10-25T07:49:15  <sipa> ok, it's over guys
235 2016-10-25T07:49:28  <sipa> let's go do dollar instead
236 2016-10-25T07:49:38  <wumpus> yep, we've reached the end
237 2016-10-25T07:50:18  <gmaxwell> I am trying to send my dollar over the internet but it will not send.
238 2016-10-25T07:50:50  <sipa> how do we get more people to use dollar?
239 2016-10-25T07:50:52  <gmaxwell> My transaction is stuck in the cup holder and it will not open anymore.
240 2016-10-25T07:53:47  <wumpus> gmaxwell: for some reason no one accepts scanned dollar bills as payment
241 2016-10-25T07:54:24  <wumpus> possibly there is a double-spending problem
242 2016-10-25T07:55:18  *** a_meteorite has joined #bitcoin-core-dev
243 2016-10-25T07:56:13  <gmaxwell> Really? But I heard Microsoft was migrating to dollar.
244 2016-10-25T07:57:52  <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.
245 2016-10-25T08:02:25  <tulip> it should ideally be possible for people to do block data downloads over other transports, but reddit is a particularly ridiculous one.
246 2016-10-25T08:03:11  *** laurentmt has joined #bitcoin-core-dev
247 2016-10-25T08:03:11  *** laurentmt has quit IRC
248 2016-10-25T08:04:13  *** AaronvanW has joined #bitcoin-core-dev
249 2016-10-25T08:05:23  <luke-jr> tulip: but we all know reddit is censorship-proof
250 2016-10-25T08:06:51  *** paveljanik has quit IRC
251 2016-10-25T08:08:17  <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)
252 2016-10-25T08:08:41  <phantomcircuit> tulip: oh nose now someone can login to yubico as me
253 2016-10-25T08:09:21  <luke-jr> gmaxwell: my guess is bitcoind didn't stop before you tried to start it again
254 2016-10-25T08:09:36  <luke-jr> although I would expect a debug.log to be generated in that case
255 2016-10-25T08:09:41  <gmaxwell> then why didn't the startup throw a lockfile error.
256 2016-10-25T08:10:03  <phantomcircuit> gmaxwell: disk space?
257 2016-10-25T08:10:14  <phantomcircuit> nfs or something weird?
258 2016-10-25T08:10:19  <phantomcircuit> debug.log being trimmed?
259 2016-10-25T08:10:20  <gmaxwell> no actually .. damn, its not throwing an error anymore!
260 2016-10-25T08:10:32  <gmaxwell> just always says "Bitcoin server starting" :P
261 2016-10-25T08:10:43  <phantomcircuit> ptrace
262 2016-10-25T08:11:17  <gmaxwell> so I think it's throwing that error after daemonizing so I never see it.
263 2016-10-25T08:11:38  <gmaxwell> yea, with daemon=0, I get the expected cannot obtain a lock.
264 2016-10-25T08:11:49  <gmaxwell> well one mystery solved and a new one created...
265 2016-10-25T08:11:58  <luke-jr> heh, I assumed daemon was 0 because you didn't specify it on the commandline XD
266 2016-10-25T08:12:16  <luke-jr> wait nm
267 2016-10-25T08:12:30  * luke-jr must be getting tired
268 2016-10-25T08:16:02  * gmaxwell opens issue
269 2016-10-25T08:16:20  <btcdrak> making the dollar bill larger will increase adoption
270 2016-10-25T08:17:24  <wumpus> btcdrak: haha I had the same thought
271 2016-10-25T08:17:28  *** thokon00 has joined #bitcoin-core-dev
272 2016-10-25T08:17:39  <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!
273 2016-10-25T08:18:17  <wumpus> btcdrak: but but but you'll need larger wallets to handle the awkward bills, prompting people to store them centrally!
274 2016-10-25T08:19:09  <luke-jr> wumpus: it's okay, I will use visa.info
275 2016-10-25T08:20:23  <luke-jr> man, the analogy there is surprising.
276 2016-10-25T08:21:04  <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
277 2016-10-25T08:21:24  <wumpus> all the messages printed to stdout/stderr also need to go to the log
278 2016-10-25T08:24:06  *** whphhg has joined #bitcoin-core-dev
279 2016-10-25T08:29:05  *** a_meteorite has quit IRC
280 2016-10-25T08:45:27  *** a_meteorite has joined #bitcoin-core-dev
281 2016-10-25T09:22:52  *** laurentmt has joined #bitcoin-core-dev
282 2016-10-25T09:24:41  *** laurentmt has quit IRC
283 2016-10-25T09:34:44  *** face_ has joined #bitcoin-core-dev
284 2016-10-25T09:36:20  *** cryptapus has joined #bitcoin-core-dev
285 2016-10-25T09:38:07  *** face_ is now known as face
286 2016-10-25T09:39:34  *** Samdney has joined #bitcoin-core-dev
287 2016-10-25T09:39:43  *** cryptapus has quit IRC
288 2016-10-25T09:41:30  *** cdecker has joined #bitcoin-core-dev
289 2016-10-25T09:42:47  *** cryptapus has joined #bitcoin-core-dev
290 2016-10-25T09:42:47  *** cryptapus has joined #bitcoin-core-dev
291 2016-10-25T09:43:43  *** murch has joined #bitcoin-core-dev
292 2016-10-25T09:55:42  *** jtimon has joined #bitcoin-core-dev
293 2016-10-25T09:56:08  <luke-jr> rebased multiwallet stuff on latest master including jonasschnelli's suggestions. hopefully unaffected by half-asleepness. :x
294 2016-10-25T09:57:24  *** AaronvanW has quit IRC
295 2016-10-25T10:05:25  *** AaronvanW has joined #bitcoin-core-dev
296 2016-10-25T10:06:18  *** AaronvanW has quit IRC
297 2016-10-25T10:06:25  *** AaronvanW has joined #bitcoin-core-dev
298 2016-10-25T10:06:51  *** AaronvanW has quit IRC
299 2016-10-25T10:06:52  *** AaronvanW has joined #bitcoin-core-dev
300 2016-10-25T10:11:55  *** Samdney has quit IRC
301 2016-10-25T10:12:16  *** Samdney has joined #bitcoin-core-dev
302 2016-10-25T10:18:46  *** a_meteorite has quit IRC
303 2016-10-25T10:21:07  <GitHub194> [bitcoin] laanwj opened pull request #9010: Split up AppInit2 into multiple phases, daemonize after datadir lock errors (master...2016_10_init_split_daemon) https://github.com/bitcoin/bitcoin/pull/9010
304 2016-10-25T10:24:22  *** a_meteorite has joined #bitcoin-core-dev
305 2016-10-25T10:27:48  <GitHub59> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/67728a389ccf...e1d1f57b56b2
306 2016-10-25T10:27:49  <GitHub59> bitcoin/master 515e264 Gregory Maxwell: Make connect=0 disable automatic outbound connections....
307 2016-10-25T10:27:49  <GitHub59> bitcoin/master e1d1f57 Wladimir J. van der Laan: Merge #9002: Make connect=0 disable automatic outbound connections....
308 2016-10-25T10:28:03  <GitHub130> [bitcoin] laanwj closed pull request #9002: Make connect=0 disable automatic outbound connections. (master...connect0) https://github.com/bitcoin/bitcoin/pull/9002
309 2016-10-25T10:31:50  *** Samdney has quit IRC
310 2016-10-25T10:34:17  <btcdrak> luke-jr: #8694? I was meaning to test that out.
311 2016-10-25T10:34:44  <luke-jr> btcdrak: yeah.
312 2016-10-25T10:37:24  <GitHub103> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e1d1f57b56b2...f14f07cb94eb
313 2016-10-25T10:37:25  <GitHub103> bitcoin/master fa1c3c2 MarcoFalke: [net] Remove assert(nMaxInbound > 0)...
314 2016-10-25T10:37:25  <GitHub103> bitcoin/master f14f07c Wladimir J. van der Laan: Merge #9008: [net] Remove assert(nMaxInbound > 0)...
315 2016-10-25T10:37:38  <GitHub161> [bitcoin] laanwj closed pull request #9008: [net] Remove assert(nMaxInbound > 0) (master...Mf1610-netAssert) https://github.com/bitcoin/bitcoin/pull/9008
316 2016-10-25T10:40:52  <GitHub138> [bitcoin] laanwj opened pull request #9011: 0.13.1 backports conditional on rc3 (0.13...2016_10_backports_conditional_rc3) https://github.com/bitcoin/bitcoin/pull/9011
317 2016-10-25T10:45:23  <luke-jr> wumpus: 8784 should be harmless regardless of rc3
318 2016-10-25T10:46:05  <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?
319 2016-10-25T10:55:19  <wumpus> yes that'd be helpful I'll likely not be moerging release notes from anywhere but github pulls
320 2016-10-25T11:25:09  <GitHub186> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f14f07cb94eb...e077e0030384
321 2016-10-25T11:25:10  <GitHub186> bitcoin/master 3f7581d Micha: [TRIVIAL] reorder Windows gitian build order to match Linux...
322 2016-10-25T11:25:10  <GitHub186> bitcoin/master e077e00 Wladimir J. van der Laan: Merge #8948: [TRIVIAL] reorder Windows gitian build order to match Linux...
323 2016-10-25T11:25:17  <GitHub175> [bitcoin] laanwj closed pull request #8948: [TRIVIAL] reorder Windows gitian build order to match Linux (master...master) https://github.com/bitcoin/bitcoin/pull/8948
324 2016-10-25T11:26:36  *** Giszmo has joined #bitcoin-core-dev
325 2016-10-25T11:32:06  <GitHub43> [bitcoin] luke-jr opened pull request #9012: release-notes: Update from blog draft (0.13...0.13.1_relnotes_update) https://github.com/bitcoin/bitcoin/pull/9012
326 2016-10-25T11:37:37  <luke-jr> and with that, I'm heading to bed, night
327 2016-10-25T11:43:21  *** cdecker has quit IRC
328 2016-10-25T11:45:32  *** cjcj has quit IRC
329 2016-10-25T11:50:51  <wumpus> jonasschnelli: re: https://github.com/bitcoin/bitcoin/pull/9010, any idea why not all parameter interaction was moved to InitParameterInteraction?
330 2016-10-25T11:57:50  <wumpus> it's a bit silly after that, with both a InitParameterInteraction and AppInitParameterInteraction :)
331 2016-10-25T11:59:39  *** a_meteorite has quit IRC
332 2016-10-25T12:03:45  *** a_meteorite has joined #bitcoin-core-dev
333 2016-10-25T12:04:47  *** Chris_Stewart_5 has joined #bitcoin-core-dev
334 2016-10-25T12:12:31  <GitHub65> [bitcoin] laanwj closed pull request #9012: release-notes: Update from blog draft (0.13...0.13.1_relnotes_update) https://github.com/bitcoin/bitcoin/pull/9012
335 2016-10-25T12:12:31  <GitHub37> [bitcoin] laanwj pushed 2 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/c9a5baddeef3...cb699885728f
336 2016-10-25T12:12:31  <GitHub37> bitcoin/0.13 99f5cf1 Luke Dashjr: release-notes: Update from blog draft
337 2016-10-25T12:12:32  <GitHub37> bitcoin/0.13 cb69988 Wladimir J. van der Laan: Merge #9012: release-notes: Update from blog draft...
338 2016-10-25T12:16:28  *** murch has quit IRC
339 2016-10-25T12:22:21  <GitHub99> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/e077e0030384...9bdf5269f886
340 2016-10-25T12:22:22  <GitHub99> bitcoin/master f48211b Pieter Wuille: Bypass removeRecursive in removeForReorg
341 2016-10-25T12:22:22  <GitHub99> bitcoin/master 51f2783 Pieter Wuille: Make removed and conflicted arguments optional to remove
342 2016-10-25T12:22:23  <GitHub99> bitcoin/master 4100499 Pieter Wuille: Return shared_ptr<CTransaction> from mempool removes
343 2016-10-25T12:22:24  <GitHub126> [bitcoin] laanwj closed pull request #8515: A few mempool removal optimizations (master...moresharedmem) https://github.com/bitcoin/bitcoin/pull/8515
344 2016-10-25T12:40:20  *** laurentmt has joined #bitcoin-core-dev
345 2016-10-25T12:41:17  <achow101> will there be an rc3?
346 2016-10-25T12:41:43  *** a_meteorite has quit IRC
347 2016-10-25T12:46:03  <wumpus> not at this point, but that's never sure, a critical issue could up any time
348 2016-10-25T12:46:53  *** Chris_Stewart_5 has quit IRC
349 2016-10-25T12:49:06  *** laurentmt has quit IRC
350 2016-10-25T12:54:22  *** laurentmt has joined #bitcoin-core-dev
351 2016-10-25T12:57:09  *** laurentmt has quit IRC
352 2016-10-25T13:03:07  *** a_meteorite has joined #bitcoin-core-dev
353 2016-10-25T13:20:40  *** LeMiner has quit IRC
354 2016-10-25T13:21:21  *** LeMiner has joined #bitcoin-core-dev
355 2016-10-25T13:24:04  *** a_meteorite has quit IRC
356 2016-10-25T13:32:11  *** LeMiner2 has joined #bitcoin-core-dev
357 2016-10-25T13:34:32  *** LeMiner has quit IRC
358 2016-10-25T13:34:32  *** LeMiner2 is now known as LeMiner
359 2016-10-25T13:36:48  *** DigiByteDev has joined #bitcoin-core-dev
360 2016-10-25T13:51:24  *** kadoban has joined #bitcoin-core-dev
361 2016-10-25T14:07:31  *** DigiByteDev has quit IRC
362 2016-10-25T14:12:34  <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?
363 2016-10-25T14:12:43  *** Guyver2 has joined #bitcoin-core-dev
364 2016-10-25T14:12:58  <instagibbs> ie, will getnewaddress return those new address types, will there be a new call for that instead, etc
365 2016-10-25T14:18:52  <sipa> instagibbs: i would think there is a cmdline option that sets the default, which is introduced after activation
366 2016-10-25T14:19:12  <sipa> instagibbs: and maybe at some point the default for that flag is changed
367 2016-10-25T14:19:19  <instagibbs> Ah, ok that might make sense
368 2016-10-25T14:19:30  <instagibbs> fixing tests may only mean a single line per test
369 2016-10-25T14:19:52  <instagibbs> at least in immediate term, even if one flips the default
370 2016-10-25T14:21:19  <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.
371 2016-10-25T14:21:52  *** roconnor has joined #bitcoin-core-dev
372 2016-10-25T14:22:36  *** LeMiner has quit IRC
373 2016-10-25T14:22:48  <wumpus> there should be a flag to getnewaddress what kind of address to return, I suppose
374 2016-10-25T14:23:08  <wumpus> the default of that could depend on a command-line option
375 2016-10-25T14:23:50  <instagibbs> that's what I tried first, but number of flags is quite long :) might be complementary of course
376 2016-10-25T14:24:18  <instagibbs> (also you don't want to have to change every instance of getnewaddress in the test codebase)
377 2016-10-25T14:24:26  <wumpus> have you seen my named-rpc-arguments pull? it would make coping with lots of flags easier
378 2016-10-25T14:24:49  <wumpus> sure, but still want to test old addresses in the test codebase I suppose, so you don't get around some changing there
379 2016-10-25T14:25:03  <instagibbs> yes, and test transition from non-segwit to segwit, etc
380 2016-10-25T14:25:12  *** Cory has quit IRC
381 2016-10-25T14:25:26  <instagibbs> link to pr?
382 2016-10-25T14:25:34  <wumpus> https://github.com/bitcoin/bitcoin/pull/8811
383 2016-10-25T14:26:04  <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.
384 2016-10-25T14:26:14  <sipa> double indirections yay
385 2016-10-25T14:26:31  <wumpus> sipa: well it should be possible to override it through the RPC call at least
386 2016-10-25T14:27:12  <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
387 2016-10-25T14:27:52  *** Cory has joined #bitcoin-core-dev
388 2016-10-25T14:28:10  <wumpus> seems bad both for testing and actual usage
389 2016-10-25T14:28:18  *** owowo has quit IRC
390 2016-10-25T14:29:12  <wumpus> and there may be other types of addresses to return in the future
391 2016-10-25T14:29:21  <wumpus> so an address ttpe argument to getnewaddress would make sense
392 2016-10-25T14:29:27  <instagibbs> I'll think on this while I'm working on it. Stuff like "verifymessage requires you to know the uint160(pubkey)"
393 2016-10-25T14:29:42  *** LeMiner has joined #bitcoin-core-dev
394 2016-10-25T14:30:07  *** tulip has quit IRC
395 2016-10-25T14:45:44  <BlueMatt> hum...are any of the fixes currently proposed as backports for rc3 regressions since 13.0?
396 2016-10-25T14:46:20  *** Chris_Stewart_5 has joined #bitcoin-core-dev
397 2016-10-25T14:47:03  <sipa> BlueMatt: the blocktxn lock is
398 2016-10-25T14:47:34  <GitHub198> [bitcoin] gtsui opened pull request #9013: Trivial: Explicitly pass const CChainParams& to LoadBlockIndexDB() (master...global-params-cleanup) https://github.com/bitcoin/bitcoin/pull/9013
399 2016-10-25T14:47:45  <BlueMatt> sipa: it is?!
400 2016-10-25T14:47:59  <wumpus> the assert too
401 2016-10-25T14:48:11  <BlueMatt> oh, i was mostly asking about the assert
402 2016-10-25T14:48:27  <BlueMatt> damn :(
403 2016-10-25T14:48:31  <sipa> BlueMatt: compact blocks and feelers are in 0.13.0
404 2016-10-25T14:48:35  <wumpus> this ws introduced in the 'feelers' commit which IIRC was introduced after 0.13.0
405 2016-10-25T14:48:52  <BlueMatt> sipa: i said regressions since 13
406 2016-10-25T14:49:06  <wumpus> but I'm not 100% sure
407 2016-10-25T14:49:23  <sipa> oh, you mean regressions introduced strictly after 0.13.0?
408 2016-10-25T14:49:24  <BlueMatt> wumpus: thats what i thought about the asserts, which sucks
409 2016-10-25T14:49:27  <BlueMatt> sipa: yes
410 2016-10-25T14:49:31  <sipa> ah
411 2016-10-25T14:49:48  <sipa> "since" is ambiguous, i guess :)
412 2016-10-25T14:49:48  <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
413 2016-10-25T14:49:58  <wumpus> the license ones and relayrpriority error are just nice to include but low risk and very low priority
414 2016-10-25T14:50:41  <wumpus> I'm not sure the assert one warrants a rc3 yet
415 2016-10-25T14:51:07  <wumpus> it's a problem that is not remote triggerable and easy to work around by increasing maxconnections
416 2016-10-25T14:51:22  <wumpus> note that it asserts the maximum, not the current value
417 2016-10-25T14:51:24  <sipa> i'm surprised it took us so long to find
418 2016-10-25T14:51:32  <sipa> especially since it is 0.13.0
419 2016-10-25T14:51:36  *** Chris_Stewart_5 has quit IRC
420 2016-10-25T14:51:38  <sipa> and nobody reported it
421 2016-10-25T14:52:01  <BlueMatt> sipa: thats the point of rcs
422 2016-10-25T14:52:13  <BlueMatt> wumpus: yea, I'm trying to decide how i feel about rc3, hence the questions
423 2016-10-25T14:52:22  <sipa> BlueMatt: well, yes, but it wasn't found in the 0.13.0 rc
424 2016-10-25T14:52:37  <wumpus> feeler connections was not in 0.13.0
425 2016-10-25T14:52:38  <BlueMatt> sipa: oh, the assert was in 0.13.0?
426 2016-10-25T14:52:44  <BlueMatt> yea, thats what i thought
427 2016-10-25T14:53:09  <wumpus> no, it was added in 2611ad7 (part of #8679), which are post-0.13.0 backports
428 2016-10-25T14:53:21  <wumpus> I don't know anymore why it was flagged for backport in the first place
429 2016-10-25T14:54:12  <BlueMatt> feelers? folks wanted feelers to reinforce the preferential-peering stuff
430 2016-10-25T14:54:17  <BlueMatt> to ensure we find out service bits
431 2016-10-25T14:54:49  <wumpus> ok
432 2016-10-25T14:55:12  <BlueMatt> at least afaiu
433 2016-10-25T14:55:34  <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)
434 2016-10-25T14:55:38  <instagibbs> yes that was the reasoning
435 2016-10-25T14:56:55  <sipa> indeed, i think it was discussed in a meeting
436 2016-10-25T15:05:13  <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
437 2016-10-25T15:06:04  <wumpus> right now it'd set earliest-possible-final date to next week, which'd be oct 1
438 2016-10-25T15:06:28  <wumpus> NOV 1
439 2016-10-25T15:07:46  <sipa> we all know that 31 OCT == 25 DEC.
440 2016-10-25T15:09:44  <BlueMatt> *facepalm*
441 2016-10-25T15:10:00  <BlueMatt> wumpus: I'd vote no
442 2016-10-25T15:10:34  <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
443 2016-10-25T15:13:58  <sipa> maxconnections set to 8 or lower is very common , i think
444 2016-10-25T15:16:04  <sipa> though, given that it took so long to find, perhaps less common than i thought
445 2016-10-25T15:16:28  <BlueMatt> so its maxconnections < 8 and then you get an incoming connectiotn?
446 2016-10-25T15:16:40  <BlueMatt> I mean i think maxconnections < 8 with incoming connections is maybe strange?
447 2016-10-25T15:18:03  <wumpus> I don't think it is *very* common
448 2016-10-25T15:20:41  <BlueMatt> I'm ok with an 0.13.2 for this, delaying 0.13.1 for this seems overkill
449 2016-10-25T15:20:56  <sipa> ok
450 2016-10-25T15:22:01  <btcdrak> ack
451 2016-10-25T15:30:08  <BlueMatt> so pending no other bugs 0.13.0-final would be tagaged on thurs?
452 2016-10-25T15:33:05  <GitHub26> [bitcoin] TheBlueMatt opened pull request #9014: Fix block-connection performance regression (master...2016-10-fix-tx-regression) https://github.com/bitcoin/bitcoin/pull/9014
453 2016-10-25T15:34:25  <BlueMatt> ehh, 13.1-final
454 2016-10-25T15:39:22  *** a_meteorite has joined #bitcoin-core-dev
455 2016-10-25T15:52:30  <wumpus> yes
456 2016-10-25T16:14:03  <gmaxwell> I asked for the backport and the issue is that without feelers addrman learns about witness peers VERY slowly.
457 2016-10-25T16:19:26  <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.
458 2016-10-25T16:21:39  <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.
459 2016-10-25T16:21:54  <gmaxwell> So you'll start the node, think it's all happy, then then boom, it crashes.
460 2016-10-25T16:24:28  <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.
461 2016-10-25T16:34:54  <btcdrak> easily documented in the release notes under known issues
462 2016-10-25T16:35:49  <gmaxwell> yes, well it _will_ cause surprise crashes for some users. As not everyone reads the release notes.
463 2016-10-25T16:36:50  <btcdrak> maybe, but if people dont RTM there isnt much you can do.
464 2016-10-25T16:37:08  <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.
465 2016-10-25T16:47:13  *** a_meteorite has quit IRC
466 2016-10-25T16:47:54  <BlueMatt> gmaxwell: yea, I agree its really not good, but i also dont think its worth delaying 0.13.1 for it
467 2016-10-25T16:48:50  <gmaxwell> Is that really the question?  Are we otherwise going to do the final today?
468 2016-10-25T16:54:25  <gmaxwell> grepping my logs,
469 2016-10-25T16:54:27  <gmaxwell> 05:57 < gijensen> I run my tn node with maxconnections=8
470 2016-10-25T16:54:49  <gmaxwell> 08:54 < KipIngram> I'm running with maxconnections=5 and dbcache=768.
471 2016-10-25T16:55:26  <gmaxwell> 02:06 < epscy> pancake: setting maxconnections to 4 (or 3) helped me
472 2016-10-25T16:56:09  <gmaxwell> 11:01 < geir> Tried bitcoind -dbcache=50 -nolisten -maxconnections=8
473 2016-10-25T16:56:17  <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
474 2016-10-25T16:56:51  <gmaxwell> 10:13 < osmosis> i was able to get what I wanted by using, -maxconnections=0  for testing
475 2016-10-25T16:56:56  <gmaxwell> 08:11 < m0gliE> -maxconnections=6
476 2016-10-25T16:57:22  <gmaxwell> 01:15 < Krellan> As it is now, when I lower maxconnections below 8, my node becomes 100% outbound, no inbound.
477 2016-10-25T16:57:47  *** MarcoFalke has joined #bitcoin-core-dev
478 2016-10-25T16:58:15  <gmaxwell> 13:16 < HM2> maxconnections=8, server=0
479 2016-10-25T16:59:05  <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.
480 2016-10-25T16:59:36  <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
481 2016-10-25T17:00:36  <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.
482 2016-10-25T17:00:58  <gmaxwell> ten we should do an RC for 0.13.2 pretty much immediately.
483 2016-10-25T17:01:10  <BlueMatt> that i agree with
484 2016-10-25T17:02:00  <BlueMatt> though at this point we've fixed enough random stuff in 0.13.1 that we probably also want a for those who wish to not switch to segwit
485 2016-10-25T17:02:04  <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.
486 2016-10-25T17:02:23  <gmaxwell> BlueMatt: sure, but that can be done after the 0.13.1 release.
487 2016-10-25T17:02:29  <BlueMatt> gmaxwell: indeed, and should be
488 2016-10-25T17:03:23  *** neha has quit IRC
489 2016-10-25T17:04:38  <BlueMatt> I'm not a fan of making a code change and tagging final a day later
490 2016-10-25T17:06:48  <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...
491 2016-10-25T17:07:15  <gmaxwell> watcha worrying about? that someone could run with an unusual configuration and find their node crashes on a later connect? :)
492 2016-10-25T17:11:59  <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
493 2016-10-25T17:12:44  <gmaxwell> if so thats only an argument to not release.
494 2016-10-25T17:13:21  <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
495 2016-10-25T17:13:38  <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.
496 2016-10-25T17:14:22  <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.
497 2016-10-25T17:14:35  <BlueMatt> I'm aware
498 2016-10-25T17:17:04  <MarcoFalke> If anything, the assert should be checking >= 0
499 2016-10-25T17:17:07  <MarcoFalke> and not >0
500 2016-10-25T17:17:18  <gmaxwell> it's still pointlss in any case.
501 2016-10-25T17:17:46  <MarcoFalke> I somehow feel uncomfortable shipping code which crashes after some time, unexpectedly.
502 2016-10-25T17:17:48  <gmaxwell> consider, it depends on no dynamic state. It could be in init.cpp.
503 2016-10-25T17:17:52  <BlueMatt> i dont think we disagree on whether the fix (removing it) is probably correct
504 2016-10-25T17:18:19  <MarcoFalke> Hmm, generally I like asserts to verify assumptions about the code.
505 2016-10-25T17:18:31  <gmaxwell> MarcoFalke: yes, thats my concern. If it did immediately on start, I'd say fine! release note it and be done.
506 2016-10-25T17:19:21  <BlueMatt> hum, thats true
507 2016-10-25T17:19:22  <sipa> BlueMatt: i think there may be a larger change optimally, but not for 0.13.x
508 2016-10-25T17:20:07  <MarcoFalke> I think we are missing documentation on how feelers should behave when maxconnections is given
509 2016-10-25T17:20:15  <MarcoFalke> The current behavior makes sense
510 2016-10-25T17:20:24  <MarcoFalke> Even though it was never meant to work this way
511 2016-10-25T17:21:00  <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?
512 2016-10-25T17:21:30  <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." ? :)
513 2016-10-25T17:21:37  <gmaxwell> wumpus: yes, that is my proposal.
514 2016-10-25T17:22:07  <wumpus> so should we then do.. a vote or something? :/
515 2016-10-25T17:22:42  <MarcoFalke> Was there a date when to tag final?
516 2016-10-25T17:22:52  <BlueMatt> gmaxwell: no, the fact that this would be better if it crashed right away
517 2016-10-25T17:22:53  <wumpus> yes, tomorrow
518 2016-10-25T17:23:13  <BlueMatt> alternatively, just throwing this out there, we could make it crash on startup by adding code there instead :p
519 2016-10-25T17:23:15  <MarcoFalke> Ok, so today rc3 with no gitian builds and tomorrow final?
520 2016-10-25T17:23:45  <wumpus> I guess, I'm fine with doing that if there is common agreement to do that
521 2016-10-25T17:23:55  <sipa> sounds good to me
522 2016-10-25T17:24:08  <BlueMatt> I'm really not a fan...
523 2016-10-25T17:24:23  *** Chris_Stewart_5 has joined #bitcoin-core-dev
524 2016-10-25T17:25:02  <GitHub191> [bitcoin] laanwj closed pull request #9011: 0.13.1 backports conditional on rc3 (0.13...2016_10_backports_conditional_rc3) https://github.com/bitcoin/bitcoin/pull/9011
525 2016-10-25T17:25:07  <sipa> the only difference from removing an assert is that some behaviour caused a crash before, now crashes in a different way
526 2016-10-25T17:25:26  <BlueMatt> I mean realistically when are we gonna have binaries out for 0.13.1? not till monday probably anyway
527 2016-10-25T17:25:33  <MarcoFalke> It does not crash in a different way, now.
528 2016-10-25T17:25:37  <wumpus> I think multiple people verified that the code doesn't crash if that value becomes 0 or negative
529 2016-10-25T17:26:04  <MarcoFalke> The value is only used in the local scope of the function once
530 2016-10-25T17:26:09  <wumpus> right
531 2016-10-25T17:26:09  <gmaxwell> I've been running a public node negative number there for ~two days now.
532 2016-10-25T17:26:36  <gmaxwell> (running with maxconnections 8)
533 2016-10-25T17:27:35  <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?
534 2016-10-25T17:28:01  <wumpus> who knows? gitian building goes really fast these days
535 2016-10-25T17:28:01  <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
536 2016-10-25T17:28:28  <wumpus> if we're going to do rc3 with just the assert removed I'm going to tag *now*
537 2016-10-25T17:28:33  <gmaxwell> what does that change?
538 2016-10-25T17:28:40  <gmaxwell> that was a reply to BlueMatt
539 2016-10-25T17:28:55  <wumpus> we know exactly what we want to do so no need to delay one second
540 2016-10-25T17:29:33  <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
541 2016-10-25T17:30:26  <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.
542 2016-10-25T17:30:29  <GitHub136> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/58d4fa7da30cb57e5fc3dca62f49a64e126c76cd
543 2016-10-25T17:30:29  <GitHub136> bitcoin/0.13 58d4fa7 MarcoFalke: [net] Remove assert(nMaxInbound > 0)...
544 2016-10-25T17:30:35  <MarcoFalke> BlueMatt: In which case it does still make sense to tag rc3 sooner than later
545 2016-10-25T17:30:43  <BlueMatt> MarcoFalke: yes
546 2016-10-25T17:31:09  <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
547 2016-10-25T17:31:19  <BlueMatt> gmaxwell: and we still get binaries out before monday morning
548 2016-10-25T17:32:05  <wumpus> I'm not normally a fan of this either, but this is so trivial
549 2016-10-25T17:32:39  <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
550 2016-10-25T17:32:50  <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
551 2016-10-25T17:33:14  <wumpus>  * [new tag]         v0.13.1rc3 -> v0.13.1rc3
552 2016-10-25T17:35:17  *** a_meteorite has joined #bitcoin-core-dev
553 2016-10-25T17:35:39  <BlueMatt> wumpus: wait, why did we not include the cs_main missing lock fix in rc3?
554 2016-10-25T17:36:37  <wumpus> because that is more impact / risk than just removing an assert
555 2016-10-25T17:37:02  *** paveljanik has joined #bitcoin-core-dev
556 2016-10-25T17:37:03  <wumpus> a locking change would need more testing
557 2016-10-25T17:37:39  <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
558 2016-10-25T17:38:03  <achow101> what about the other stuff listed in 9011?
559 2016-10-25T17:38:05  <gmaxwell> I'm of a similar view with wumpus.
560 2016-10-25T17:38:07  <wumpus> morcos: we'll have to, anyway I' m sure there will be plenty of bugs
561 2016-10-25T17:38:45  <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
562 2016-10-25T17:39:18  <wumpus> the other option would be doing a rc3, including more, but delaying -final until next week
563 2016-10-25T17:39:20  <morcos> wumpus: ok.. sufficiently convinced
564 2016-10-25T17:39:30  <achow101> wouldn't doing rc3 knock the release back to nov 1? Or am I missing something?
565 2016-10-25T17:39:36  <BlueMatt> achow101: it did not
566 2016-10-25T17:39:44  <morcos> its rc2.01
567 2016-10-25T17:39:45  <wumpus> achow101: it would have, if we included actual serious changes
568 2016-10-25T17:39:56  <wumpus> removing this assert is so trivial
569 2016-10-25T17:40:18  <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)
570 2016-10-25T17:40:25  <gmaxwell> morcos: at least in my thinking, I'd consider the issue seperately.
571 2016-10-25T17:40:25  <wumpus> and no, I don't feel like discussing that further or backstepping now, that was just a project decision
572 2016-10-25T17:40:44  <gmaxwell> I wouldn't be included to do a short cycle RC for the lock, like I am for the trivial assert.
573 2016-10-25T17:40:46  <achow101> so when is final planned for?
574 2016-10-25T17:40:51  <wumpus> tomorrow
575 2016-10-25T17:40:59  <wumpus> eh, no, thursday
576 2016-10-25T17:41:27  <BlueMatt> oh, it was already thursday
577 2016-10-25T17:41:28  *** ryanofsky has joined #bitcoin-core-dev
578 2016-10-25T17:41:35  <wumpus> yes it was already thursday
579 2016-10-25T17:41:43  <BlueMatt> wumpus: can we do an announce for the rc3 to the ml?
580 2016-10-25T17:41:46  <BlueMatt> even without bins?
581 2016-10-25T17:41:46  <wumpus> the point was not to change that
582 2016-10-25T17:41:55  <wumpus> BlueMatt: sure ,feel free to do so, I"m going to bed
583 2016-10-25T17:41:56  <achow101> do we still need to gitian build it?
584 2016-10-25T17:41:58  <BlueMatt> indeed, I'm aware
585 2016-10-25T17:42:05  <BlueMatt> achow101: we are not doing gitian builds of rc3
586 2016-10-25T17:42:17  <wumpus> achow101: nope
587 2016-10-25T17:42:22  <achow101> ok
588 2016-10-25T17:42:34  <sipa> wumpus: good night!
589 2016-10-25T17:42:34  <wumpus> you can gitian-build it for yourself ofcourse, or if you want to compare against someone else
590 2016-10-25T17:45:00  <cfields_> I'll build either way so we can have something to point to if anyone wants it
591 2016-10-25T17:46:05  <gmaxwell> assuming final is the same would the gitian binaries actually be the same?
592 2016-10-25T17:46:49  <wumpus> unfortunately, no, because the build embeds the tag from git :(
593 2016-10-25T17:47:23  <wumpus> if not for that the binary for -final would be exactly the same as -rc<last>
594 2016-10-25T17:48:33  <wumpus> assuming no commits in between either
595 2016-10-25T17:48:35  <BlueMatt> cfields_: whats the status of the osx change? are we gonna change the plist for final?
596 2016-10-25T17:48:42  *** Chris_Stewart_5 has quit IRC
597 2016-10-25T17:49:13  <wumpus> as the commit id# is also in the executable
598 2016-10-25T17:49:16  <cfields_> BlueMatt: i think we should, yes. There should be ~zero practical impact.
599 2016-10-25T17:49:18  <gmaxwell> wumpus: perhaps we should have the build system mask that out in the future. (e.g. strip rcN from the tag it extracts)
600 2016-10-25T17:49:34  <BlueMatt> cfields_: yes, fine with that being merged w/o rc, just asking if its gonna happen
601 2016-10-25T17:50:28  <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
602 2016-10-25T17:50:35  <wumpus> gmaxwell: that's why that was never removed
603 2016-10-25T17:50:40  <cfields_> wumpus: you ok with https://github.com/bitcoin/bitcoin/issues/8577#issuecomment-255947269 with no additional testing?
604 2016-10-25T17:50:59  <cfields_> sorry that took so long, I chased it all day yesterday
605 2016-10-25T17:51:32  <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.
606 2016-10-25T17:52:20  <wumpus> cfields_: does that affect anything?
607 2016-10-25T17:53:20  <cfields_> wumpus: practically, no. Bitcoin-qt is busted on 10.7. This would just make it refuse to run there, rather than mysteriously crashing.
608 2016-10-25T17:54:09  <wumpus> gmaxwell: indeed, for gitian builds the hash of the executable would be deterministic and possible to look up to a version / commit hash
609 2016-10-25T17:54:20  <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."
610 2016-10-25T17:54:34  <wumpus> cfields_: sounds good to me
611 2016-10-25T17:55:05  <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.
612 2016-10-25T17:55:39  <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
613 2016-10-25T17:55:59  <gmaxwell> wumpus: alernatively, it could embed some hash of the source code that wouldn't be changed by updating tags.
614 2016-10-25T17:56:03  *** Chris_Stewart_5 has joined #bitcoin-core-dev
615 2016-10-25T17:56:21  <cfields_> wumpus: that would require bumping the minversion to 10.8. Which we should do for master, but yes, not here.
616 2016-10-25T17:56:48  <cfields_> -mmacosx-version-min, that is
617 2016-10-25T17:59:48  *** owowo has joined #bitcoin-core-dev
618 2016-10-25T17:59:57  <wumpus> BlueMatt: you sent the rc announcement to bitcoin-dev instead of bitcoin-core-dev :)
619 2016-10-25T18:00:11  <BlueMatt> they're different? oops
620 2016-10-25T18:00:13  <wumpus> BlueMatt: otherwise, thanks!
621 2016-10-25T18:00:20  <BlueMatt> ehh, see, this is why i dont do release process :p
622 2016-10-25T18:00:43  <btcdrak> please send to bitcoin-core-dev also
623 2016-10-25T18:00:44  <wumpus> no problem, just send a copy to bitcoin-core-dev too
624 2016-10-25T18:01:57  <BlueMatt> ok, done
625 2016-10-25T18:06:13  <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?
626 2016-10-25T18:06:42  <jonasschnelli> IIRC, I did only move the SoftSetBoolArg() in https://github.com/bitcoin/bitcoin/pull/6780
627 2016-10-25T18:06:59  <jonasschnelli> But I can't remember the exact reason why not every interaction was moved.
628 2016-10-25T18:07:02  <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
629 2016-10-25T18:08:20  <wumpus> instagibbs: patches welcome
630 2016-10-25T18:09:02  <instagibbs> roger
631 2016-10-25T18:09:27  <cfields_> instagibbs: i have a PR that changes that behavior and creates better error messages. sec.
632 2016-10-25T18:09:42  <instagibbs> I've literally implemented it before, for elements, but then forgot about it
633 2016-10-25T18:09:48  <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 :-)
634 2016-10-25T18:09:50  <instagibbs> and now running into it again working on Core, d'oh
635 2016-10-25T18:10:36  <instagibbs> cfields_, I'd appreciate a patch if you have it. IIRC it's only a few lines so I can do it too
636 2016-10-25T18:10:40  <wumpus> we have tons of pulls open about log messages and comments, but surprisingly few people work on user-facing messages
637 2016-10-25T18:10:53  <cfields_> grr, I need to clean that up and resubmit. Trying to fix up my PRs today.
638 2016-10-25T18:11:03  <instagibbs> wumpus, well right now any error in wallet's transaction gives you a super broad message about money missing
639 2016-10-25T18:11:04  <cfields_> instagibbs: see the comments in https://github.com/bitcoin/bitcoin/pull/8888
640 2016-10-25T18:11:21  <cfields_> instagibbs: specifically: https://github.com/theuni/bitcoin/commit/349edab789557db615b29a5869118b4b08c50dab
641 2016-10-25T18:12:29  <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.
642 2016-10-25T18:14:00  <instagibbs> Yeah that looks better, but it could still stand to pass back why it failed mempool entry
643 2016-10-25T18:16:35  <cfields_> instagibbs: for sure.
644 2016-10-25T18:21:19  *** paveljanik has quit IRC
645 2016-10-25T18:22:42  <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!"
646 2016-10-25T18:25:10  <cfields_> heh
647 2016-10-25T18:25:12  <wumpus> thinking of it, neither amount, complexity or use of recently received funds counts towards the fee
648 2016-10-25T18:25:33  <jl2012> has anyone proposed to have an RPC command like "checkrawtransaction", which does everything of "sendrawtransaction" but not adding it to mempool?
649 2016-10-25T18:25:35  *** paveljanik has joined #bitcoin-core-dev
650 2016-10-25T18:25:37  *** paveljanik has joined #bitcoin-core-dev
651 2016-10-25T18:25:41  <gmaxwell> "because of the required resources"
652 2016-10-25T18:25:44  <wumpus> jl2012: yes, I had a pull for that once
653 2016-10-25T18:25:53  <cfields_> jl2012: decoderawtransaction ?
654 2016-10-25T18:26:17  <jl2012> decode won't test for validity
655 2016-10-25T18:26:25  <jl2012> wumpus: why isn't it merged?
656 2016-10-25T18:27:10  <gmaxwell> jl2012: the way I've recommended doing that before is with a block proposal.
657 2016-10-25T18:27:22  <wumpus> lack of testing
658 2016-10-25T18:27:22  <gmaxwell> jl2012: which lets you also have a chain of unconfirmed transactions.
659 2016-10-25T18:27:31  <wumpus> mine could do that too
660 2016-10-25T18:27:47  <gmaxwell> wumpus: that sounds good.
661 2016-10-25T18:27:55  <wumpus> jl2012: https://github.com/bitcoin/bitcoin/pull/7552
662 2016-10-25T18:28:50  <wumpus> too much arguing and too little actual interest so I eventually gave up, but feel free to resurrect it (in some form)
663 2016-10-25T18:31:21  *** d_t has joined #bitcoin-core-dev
664 2016-10-25T18:32:12  <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
665 2016-10-25T18:32:12  <jl2012> access to one key, you could still get the money back with another key after the locktime
666 2016-10-25T18:32:31  <jl2012> But I need the ability to verify the unconfirmed tx is actually valid
667 2016-10-25T18:33:14  <GitHub115> [bitcoin] theuni opened pull request #9015: release: bump required osx version to 10.8. Credit jonasschnelli. (master...osx-disable107) https://github.com/bitcoin/bitcoin/pull/9015
668 2016-10-25T18:33:39  <GitHub139> [bitcoin] instagibbs opened pull request #9016: Return useful error message on ATMP failure (master...atmperror) https://github.com/bitcoin/bitcoin/pull/9016
669 2016-10-25T18:33:44  <gmaxwell> you can make the spend smaller if the 1 of 2  is just a 1 of 1 with one of the two keys.
670 2016-10-25T18:34:39  <jl2012> yes, the 1/2 for the number of sigs could be pushed with IF/ELSE
671 2016-10-25T18:35:30  *** jtimon has quit IRC
672 2016-10-25T18:37:35  <instagibbs> wumpus, too bad, I think rpc's checking for validity without committing them are useful
673 2016-10-25T18:38:08  <gmaxwell> instagibbs: go pick up his PR.
674 2016-10-25T18:38:18  <gmaxwell> no one was opposed to the idea.
675 2016-10-25T18:39:10  <instagibbs> I remember it being contentious regarding the devilish details, but I'll take another look
676 2016-10-25T18:39:40  <wumpus> indeed, it was just that the way some people wanted to do it involved changing code and refactoring all over the place
677 2016-10-25T18:41:55  <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.
678 2016-10-25T18:42:40  <wumpus> I tend to lose interest in projects after a while, that doesn't mean they're not worth doing
679 2016-10-25T18:43:29  <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
680 2016-10-25T18:44:08  <wumpus> that's easier said than done, especially if you want to be able to handle chains of transactions depending on each other
681 2016-10-25T18:44:32  <wumpus> without actually putting the dependencies in the mempool
682 2016-10-25T18:45:13  <instagibbs> achow101, read the PR thread, it's all debated there I think
683 2016-10-25T18:45:34  <wumpus> yes
684 2016-10-25T18:45:34  <instagibbs> subtle issues mean it's harder to push through
685 2016-10-25T18:46:00  <gmaxwell> well the PR might not make it clear that being able to handle chains is pretty useful.
686 2016-10-25T18:46:16  <wumpus> it's all been debated before, I don't feel like getting involved again, thanksfor the reminder
687 2016-10-25T18:47:17  <achow101> well my idea is to just modify accepttomempool
688 2016-10-25T18:47:29  *** Chris_Stewart_5 has quit IRC
689 2016-10-25T18:48:04  <wumpus> but would you want changes there for an RPC call whose goal is to *not* touch the mempool?
690 2016-10-25T18:48:04  *** JackH has joined #bitcoin-core-dev
691 2016-10-25T18:48:20  *** laurentmt has joined #bitcoin-core-dev
692 2016-10-25T18:49:08  <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.
693 2016-10-25T18:49:44  <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, ...)
694 2016-10-25T18:50:06  <sipa> but if it includes policy it's also much less meaningful to affect the mempool
695 2016-10-25T18:50:17  <achow101> why would adding a flag to acceptomempool be wrong?
696 2016-10-25T18:50:33  <wumpus> because the function is called accepttomempool
697 2016-10-25T18:50:48  <sipa> let's rename it to AcceptableToMempool
698 2016-10-25T18:50:50  <sipa> *ducks*
699 2016-10-25T18:51:19  <wumpus> yes, if you split up functions into a 'acceptable policy' part and 'add to mempool', it makes more sense
700 2016-10-25T18:51:26  <wumpus> I'm repeating myself
701 2016-10-25T18:51:55  <wumpus> agree that checking for consensus is fairly easy
702 2016-10-25T18:52:05  <wumpus> the difficult part was all the different policies
703 2016-10-25T18:52:25  <wumpus> if that's not necessary then indeed it'd just be a 'block proposal'
704 2016-10-25T18:52:42  *** laurentmt has quit IRC
705 2016-10-25T18:52:56  <wumpus> although you probably still want to be able to pass in things such as height, and time, for -final checks
706 2016-10-25T18:53:36  <wumpus> 'is this valid at height X time Y' instead of necessarily now
707 2016-10-25T19:02:57  *** nickler has joined #bitcoin-core-dev
708 2016-10-25T19:04:50  *** Chris_Stewart_5 has joined #bitcoin-core-dev
709 2016-10-25T19:12:39  *** MarcoFalke has left #bitcoin-core-dev
710 2016-10-25T19:19:30  *** bsm117532 has quit IRC
711 2016-10-25T19:21:37  *** bsm117532 has joined #bitcoin-core-dev
712 2016-10-25T19:36:28  *** Chris_Stewart_5 has quit IRC
713 2016-10-25T19:45:01  <GitHub111> [bitcoin] instagibbs opened pull request #9017: Enable various p2sh-p2wpkh functionality (master...p2shp2wpkhstuff) https://github.com/bitcoin/bitcoin/pull/9017
714 2016-10-25T19:46:58  *** jtimon has joined #bitcoin-core-dev
715 2016-10-25T19:52:07  *** Chris_Stewart_5 has joined #bitcoin-core-dev
716 2016-10-25T19:54:20  *** cryptapus has quit IRC
717 2016-10-25T19:54:29  *** droark has joined #bitcoin-core-dev
718 2016-10-25T20:05:08  *** Chris_Stewart_5 has quit IRC
719 2016-10-25T20:07:30  *** Chris_Stewart_5 has joined #bitcoin-core-dev
720 2016-10-25T20:16:37  *** Victorsueca has joined #bitcoin-core-dev
721 2016-10-25T20:18:10  *** Victorsueca has quit IRC
722 2016-10-25T20:19:41  *** echonaut has quit IRC
723 2016-10-25T20:20:42  *** echonaut has joined #bitcoin-core-dev
724 2016-10-25T20:21:20  *** Victorsueca has joined #bitcoin-core-dev
725 2016-10-25T20:22:35  <Victorsueca> wuuuuuut?
726 2016-10-25T20:22:39  <Victorsueca> rc3?
727 2016-10-25T20:22:51  <Victorsueca> I thought rc2 was the choosen one
728 2016-10-25T20:23:20  *** Chris_Stewart_5 has quit IRC
729 2016-10-25T20:24:13  <BlueMatt> Victorsueca: see https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-October/013262.html
730 2016-10-25T20:25:55  *** Chris_Stewart_5 has joined #bitcoin-core-dev
731 2016-10-25T20:26:40  <Victorsueca> BlueMatt: thanks
732 2016-10-25T20:26:51  *** aalex has joined #bitcoin-core-dev
733 2016-10-25T20:29:05  *** a_meteorite has quit IRC
734 2016-10-25T20:41:56  *** a_meteorite has joined #bitcoin-core-dev
735 2016-10-25T20:47:36  *** ill has joined #bitcoin-core-dev
736 2016-10-25T21:02:19  *** a_meteorite has quit IRC
737 2016-10-25T21:05:54  *** a_meteorite has joined #bitcoin-core-dev
738 2016-10-25T21:12:27  *** Chris_Stewart_5 has quit IRC
739 2016-10-25T21:28:24  *** Chris_Stewart_5 has joined #bitcoin-core-dev
740 2016-10-25T21:39:45  *** Guyver2 has quit IRC
741 2016-10-25T21:49:10  <GitHub85> [bitcoin] ryanofsky opened pull request #9018: testing pr (please ignore) (master...loop) https://github.com/bitcoin/bitcoin/pull/9018
742 2016-10-25T22:33:49  *** owowo has quit IRC
743 2016-10-25T22:37:10  <gmaxwell> 40 node_witness peers
744 2016-10-25T22:38:56  <gmaxwell> 5 outbound.
745 2016-10-25T22:50:41  *** owowo has joined #bitcoin-core-dev
746 2016-10-25T22:53:33  <luke-jr> looks like he's abusing that PR to run Travis :/
747 2016-10-25T22:53:46  <luke-jr> guess he doesn't realise it emails everyone
748 2016-10-25T22:54:48  <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.  ...
749 2016-10-25T22:55:00  <gmaxwell> ignore te first part of that line..
750 2016-10-25T22:55:27  <gmaxwell> so thats (If you're..) is all we say about mining & segwit in the release notes right now.
751 2016-10-25T22:55:52  <gmaxwell> which is a little anemic. Like, there should be some mention that all mining software needs to be updated for segwit support.
752 2016-10-25T22:56:00  <gmaxwell> And a list of supporting mining software.
753 2016-10-25T22:56:29  <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..
754 2016-10-25T22:56:42  <gmaxwell> hm.
755 2016-10-25T22:57:20  <luke-jr> or perhaps turning the blog post into a segwit deployment FAQ and linking that
756 2016-10-25T22:57:28  <luke-jr> (so we can update it as needed later)
757 2016-10-25T22:59:22  <GitHub177> [bitcoin] sipa closed pull request #9018: testing pr (please ignore) (master...loop) https://github.com/bitcoin/bitcoin/pull/9018
758 2016-10-25T23:12:14  *** jannes has quit IRC
759 2016-10-25T23:42:48  *** bsm117532 has quit IRC