12016-10-25T00:02:42  *** fengling has joined #bitcoin-core-dev
  22016-10-25T00:02:51  *** AaronvanW has quit IRC
  32016-10-25T00:07:32  *** DigiByteDev has joined #bitcoin-core-dev
  42016-10-25T00:10:09  *** d_t has quit IRC
  52016-10-25T00:12:24  *** DigiByteDev has quit IRC
  62016-10-25T00:20:03  *** Soligor has quit IRC
  72016-10-25T00:20:37  *** Soligor has joined #bitcoin-core-dev
  82016-10-25T00:26:17  *** murch has quit IRC
  92016-10-25T00:28:09  *** fengling has quit IRC
 102016-10-25T00:28:11  *** nickler_ has quit IRC
 112016-10-25T00:30:27  *** alpalp has joined #bitcoin-core-dev
 122016-10-25T00:30:28  *** alpalp has joined #bitcoin-core-dev
 132016-10-25T00:33:02  *** jtimon has quit IRC
 142016-10-25T00:43:13  *** alpalp has quit IRC
 152016-10-25T00:49:13  *** fengling has joined #bitcoin-core-dev
 162016-10-25T00:52:45  *** alpalp has joined #bitcoin-core-dev
 172016-10-25T01:03:51  *** a_meteorite has quit IRC
 182016-10-25T01:06:21  *** d_t has joined #bitcoin-core-dev
 192016-10-25T01:27:57  *** jcorgan has joined #bitcoin-core-dev
 202016-10-25T01:36:36  *** fengling has quit IRC
 212016-10-25T02:02:18  *** jujumax has joined #bitcoin-core-dev
 222016-10-25T02:04:18  *** fengling has joined #bitcoin-core-dev
 232016-10-25T02:04:55  *** jcorgan has left #bitcoin-core-dev
 242016-10-25T02:29:09  *** alpalp has quit IRC
 252016-10-25T02:31:20  *** d_t has quit IRC
 262016-10-25T02:35:16  *** brg444 has joined #bitcoin-core-dev
 272016-10-25T02:36:37  *** Chris_Stewart_5 has quit IRC
 282016-10-25T02:37:05  *** alpalp has joined #bitcoin-core-dev
 292016-10-25T02:41:31  *** alpalp has quit IRC
 302016-10-25T02:48:13  *** tulip has joined #bitcoin-core-dev
 312016-10-25T02:51:15  *** Giszmo has quit IRC
 322016-10-25T03:07:23  *** fengling has quit IRC
 332016-10-25T03:23:28  *** DigiByteDev has joined #bitcoin-core-dev
 342016-10-25T03:32:16  *** fengling has joined #bitcoin-core-dev
 352016-10-25T03:55:34  *** jujumax has quit IRC
 362016-10-25T03:57:31  *** brg444 has quit IRC
 372016-10-25T03:58:56  *** kadoban has quit IRC
 382016-10-25T04:01:00  *** a_meteorite has joined #bitcoin-core-dev
 392016-10-25T04:56:36  *** sdaftuar has quit IRC
 402016-10-25T04:56:51  *** morcos has quit IRC
 412016-10-25T04:56:53  *** zxzzt has quit IRC
 422016-10-25T04:57:53  *** DigiByteDev has quit IRC
 432016-10-25T04:58:05  *** molz has quit IRC
 442016-10-25T04:58:21  *** sdaftuar has joined #bitcoin-core-dev
 452016-10-25T04:58:26  *** zxzzt has joined #bitcoin-core-dev
 462016-10-25T04:58:43  *** morcos has joined #bitcoin-core-dev
 472016-10-25T05:00:14  *** moli has joined #bitcoin-core-dev
 482016-10-25T05:19:56  *** paveljanik has quit IRC
 492016-10-25T05:38:00  <GitHub169> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ced22d035ac0...67728a389ccf
 502016-10-25T05:38:01  <GitHub169> bitcoin/master 3421e74 unsystemizer: Clarify `listenonion`...
 512016-10-25T05:38:01  <GitHub169> bitcoin/master 67728a3 Wladimir J. van der Laan: Merge #9004: Clarify `listenonion`...
 522016-10-25T05:38:18  <GitHub2> [bitcoin] laanwj closed pull request #9004: Clarify `listenonion` (master...patch-3) https://github.com/bitcoin/bitcoin/pull/9004
 532016-10-25T05:44:34  *** jacurn has quit IRC
 542016-10-25T05:51:02  *** d9b4bef9 has quit IRC
 552016-10-25T05:52:08  *** d9b4bef9 has joined #bitcoin-core-dev
 562016-10-25T05:54:44  *** a_meteorite has quit IRC
 572016-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)
 582016-10-25T06:00:04  <luke-jr> thanks
 592016-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
 602016-10-25T06:02:52  *** a_meteorite has joined #bitcoin-core-dev
 612016-10-25T06:21:59  <jonasschnelli> wumpus: what do you think about 10.8 as min OSX version for core?
 622016-10-25T06:22:17  <wumpus> hehe
 632016-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
 642016-10-25T06:23:47  <jonasschnelli> Heh. Yes. Thats somehow true...
 652016-10-25T06:23:58  <jonasschnelli> Though, the original 10.7 bug was reported in #bitcoin
 662016-10-25T06:24:09  <jonasschnelli> I guess some users are still on 10.7 for some server-based OSX systems
 672016-10-25T06:24:11  <wumpus> "things break all the time on 10.x and no one notices" "if a tree falls..."
 682016-10-25T06:24:44  <jonasschnelli> We can reduce the tree-falling risks by setting 10.8 as min OSX.
 692016-10-25T06:24:51  <jonasschnelli> Also, we could get rid of some warnings
 702016-10-25T06:25:29  <jonasschnelli> I mean we only speak about the official binaries... I guess self-compile should still work fine on OSX
 712016-10-25T06:25:31  <sipa> when was 10.7 released?
 722016-10-25T06:25:31  <wumpus> so that'd be for 0.14.0 I guess
 732016-10-25T06:25:45  <jonasschnelli> IF we do a rc3, then we could add it there
 742016-10-25T06:25:56  <jonasschnelli> But no 0.13.1 rc just because of that issue
 752016-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
 762016-10-25T06:26:05  <sipa> 10.7 is 5 years old
 772016-10-25T06:26:05  <jonasschnelli> sipa: i'm looking... I guess 2-3 years
 782016-10-25T06:26:13  <sipa> july 2011
 792016-10-25T06:26:18  <wumpus> if not, well, too bad then
 802016-10-25T06:26:35  <jonasschnelli> Okay. I'll work on a patch...
 812016-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
 822016-10-25T06:27:12  <wumpus> I didn't mean 'you should fix this now'
 832016-10-25T06:27:15  <sipa> windows 7 is already much older than osx 10.7
 842016-10-25T06:27:51  <jonasschnelli> "I'm working on a patch" could result in a work-duration of couple of month . :)
 852016-10-25T06:28:13  <sipa> haha
 862016-10-25T06:28:34  <jonasschnelli> First finishing the SPV hybrid mode
 872016-10-25T06:29:01  <sipa> sounds like a 5 year plan
 882016-10-25T06:29:06  <jonasschnelli> hah
 892016-10-25T06:29:17  <jonasschnelli> It's already working... but that probably 5% of the work.
 902016-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
 912016-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).
 922016-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
 932016-10-25T06:31:12  <luke-jr> pretty sure my father is still using hardware incapable of 64-bit <.<
 942016-10-25T06:31:28  <sipa> luke-jr: use qemu :p
 952016-10-25T06:31:40  <sipa> jonasschnelli: i don't understand
 962016-10-25T06:31:42  <luke-jr> sipa: does qemu support XP? :P
 972016-10-25T06:32:48  <sipa> wumpus: microsoft has the world's worst customer base. mostly corporate machines whose maintainers don't like change :)
 982016-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?
 992016-10-25T06:33:17  <jonasschnelli> they always re-download the required blocks
1002016-10-25T06:33:30  <jonasschnelli> s/they/it
1012016-10-25T06:33:38  <sipa> jonasschnelli: there is no validation in SPV mode
1022016-10-25T06:33:49  <jonasschnelli> sipa: there is in hybrid...
1032016-10-25T06:34:03  <sipa> what do you mean by hybrid?
1042016-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...
1052016-10-25T06:34:29  <jonasschnelli> the full-node part could once reuse those already downloaded blocks
1062016-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...
1072016-10-25T06:34:44  <wumpus> C has so many scary edge cases there
1082016-10-25T06:35:07  <jonasschnelli> but how-every,... hard to explain,... i'll show you some code sipa during the next days/weeks
1092016-10-25T06:35:08  <luke-jr> jonasschnelli: I don't get the purpose?
1102016-10-25T06:35:35  <sipa> 6.5.8 Relational operators
1112016-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...
1122016-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...
1132016-10-25T06:35:48  <sipa> behavior is undefined.
1142016-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
1152016-10-25T06:36:10  <jonasschnelli> these downloaded blocks can later be used for the validation-full-node part
1162016-10-25T06:36:24  <sipa> jonasschnelli: that's no different from how block fetching works today
1172016-10-25T06:36:41  <sipa> jonasschnelli: we often have unvalidated blocks ahead of the point we're fully synced to
1182016-10-25T06:36:55  <wumpus> so this would compare pointers in different arenas, which can be seen as different "arrays"
1192016-10-25T06:37:06  <sipa> wumpus: ah, i guess...
1202016-10-25T06:37:10  <luke-jr> sipa: I think he means you'd download blocks from the other end
1212016-10-25T06:37:57  *** RoyceX has joined #bitcoin-core-dev
1222016-10-25T06:38:03  <luke-jr> (in order to scan them for unconfirmed transactions)
1232016-10-25T06:38:23  <sipa> well if you combine it with pruning you wouldn't keep the blocks on disk downloaded for SPV
1242016-10-25T06:38:29  <luke-jr> indeed
1252016-10-25T06:38:33  <sipa> which makes things much easier
1262016-10-25T06:38:35  <jonasschnelli> Yes. With pruning...
1272016-10-25T06:38:50  <jonasschnelli> I think i'll start with not keeping these blocks for now.
1282016-10-25T06:39:00  <jonasschnelli> But it would be a nice use case for full-block SPV (if pruning is disabled)
1292016-10-25T06:39:07  <jonasschnelli> Because you need the blocks anyways.
1302016-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 ;)
1312016-10-25T06:41:34  *** niska has joined #bitcoin-core-dev
1322016-10-25T06:42:42  *** BlueMatt has quit IRC
1332016-10-25T06:42:42  *** da2ce7 has quit IRC
1342016-10-25T06:42:42  *** cheese_ has quit IRC
1352016-10-25T06:42:42  *** niska` has quit IRC
1362016-10-25T06:42:42  *** bsm117532 has quit IRC
1372016-10-25T06:42:54  *** bsm117532 has joined #bitcoin-core-dev
1382016-10-25T06:43:31  *** BlueMatt has joined #bitcoin-core-dev
1392016-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
1402016-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.
1412016-10-25T06:44:45  <wumpus> welcome to adversarial compiler design 101 :)
1422016-10-25T06:45:23  *** da2ce7 has joined #bitcoin-core-dev
1432016-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
1442016-10-25T06:45:38  <sipa> so your solution seems perfectly fine
1452016-10-25T06:46:12  <wumpus> I'll just keep it as it is then, thanks
1462016-10-25T06:47:28  <sipa> actually, i don't know if the mapping from pointer to integer is required to keep continuous ranges continuous :)
1472016-10-25T06:48:05  <wumpus> "
1482016-10-25T06:48:09  <wumpus> "Ok, bad news. I ended up in the bowels of osx"
1492016-10-25T06:48:16  <wumpus> poor cfields_
1502016-10-25T06:48:46  <sipa> did he come across a digest function?
1512016-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
1522016-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
1532016-10-25T06:52:17  <sipa> *uintptrs
1542016-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
1552016-10-25T06:52:53  <sipa> the pointers need to be linear
1562016-10-25T06:53:00  <sipa> the integers they map to do not
1572016-10-25T06:53:00  <wumpus> or at least monotonic, linear isn't even necessary
1582016-10-25T06:53:09  <sipa> of course, in any compiler below adversialness level 7, this will be the case
1592016-10-25T06:54:25  <wumpus> hehe, phew, so that's still safe for ~5 years then
1602016-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
1612016-10-25T06:56:15  <sipa> i don't know whether the standard requires that
1622016-10-25T06:56:32  <sipa> if not, the cast to uintptr could for example bitflip the result or so
1632016-10-25T06:56:59  <sipa> or switch the bit or byte order
1642016-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.
1652016-10-25T07:00:31  <wumpus> This makes me sick
1662016-10-25T07:03:17  <sipa> and you get aliasing rules too
1672016-10-25T07:03:22  <wumpus> C: "between Scylla and Charybdis"
1682016-10-25T07:03:26  <wumpus> I don't want to do this anymore
1692016-10-25T07:03:30  <sipa> :)
1702016-10-25T07:03:39  <sipa> i don't think any of this matters
1712016-10-25T07:08:10  <sipa> btw: i believe char* pointers are always allowed to alias anything
1722016-10-25T07:08:28  <sipa> so if that's the reason for wanting to avoid them, no worries
1732016-10-25T07:12:12  *** paveljanik has joined #bitcoin-core-dev
1742016-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)
1752016-10-25T07:19:38  <phantomcircuit> cccccceegehfceddehkuieubrvvrejvvbbnlrclrighk
1762016-10-25T07:20:32  <jonasschnelli> your new private key?
1772016-10-25T07:21:22  <wumpus> "this is your brain on C"
1782016-10-25T07:21:38  <tulip> phantomcircuit: try not spilling soda on your keyboard next time.
1792016-10-25T07:22:18  <sipa> wumpus: where c is the speed of light, so you're saying he's on speed?
1802016-10-25T07:22:45  <sipa> i'll see myself out
1812016-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.
1822016-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 :)
1832016-10-25T07:24:25  * wumpus still wonders if cfields_ got caught by macosx' digest function, he's strangely silent
1842016-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.
1852016-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
1862016-10-25T07:25:36  <gmaxwell> tulip: the attempts to port 0 may be a side effect of the witness preference.
1872016-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
1882016-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.
1892016-10-25T07:26:27  <gmaxwell> bingo.
1902016-10-25T07:26:34  <wumpus> it'd make sense to discard records with port 0 as invalid though
1912016-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.
1922016-10-25T07:27:05  *** whphhg has quit IRC
1932016-10-25T07:27:23  <tulip> oh, so choosing not to connect to a node counts as a try?
1942016-10-25T07:27:32  <gmaxwell> we should probably prevent port 0 from ending up in addrman at all.
1952016-10-25T07:27:48  <gmaxwell> tulip: yes sir. read the loop in CConman:ThreadOpenConnections()
1962016-10-25T07:28:52  <wumpus> yes, like invalid addresses, invalid ports probably shouldn't end up in addrman at all
1972016-10-25T07:29:50  <wumpus> may makesense to add a generic blacklist of ports. 22, 25, etc
1982016-10-25T07:29:57  <tulip> the only invalid IP address I've seen in my logs is 255.255.0.0, the IPV6 ones are valid but unroutable
1992016-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.
2002016-10-25T07:30:36  <gmaxwell> tulip: addrman already filters several broad families of invalid IPs.
2012016-10-25T07:30:45  <gmaxwell> s/invalid/non-routable/ really
2022016-10-25T07:30:55  <wumpus> meh, I'd prefer not to hardcode the port even further
2032016-10-25T07:31:43  *** a_meteorite has quit IRC
2042016-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'
2052016-10-25T07:33:43  <gmaxwell> ya, but does it? requires there be enough non-8333 hosts to actually find a working one. :P
2062016-10-25T07:33:54  <wumpus> otherwise it may suddenly become a really attractive measure
2072016-10-25T07:34:07  <wumpus> there are some non-8333 hosts to connect to
2082016-10-25T07:34:23  <gmaxwell> fair enough.
2092016-10-25T07:34:42  <tulip> there's 1990 peers ever to have been crawled by this seed node which have a non standard port.
2102016-10-25T07:36:03  <tulip> port frequencies http://pastebin.com/raw/wZSSDYW6
2112016-10-25T07:36:06  <wumpus> may make sense to listen on 8333 as well as arandom non-standard port
2122016-10-25T07:36:32  <wumpus> 8333 to make sure people connect to you, and the non-standard port to help people behind weird firewalls
2132016-10-25T07:37:40  <gmaxwell> wumpus: I was just thinking that too.
2142016-10-25T07:38:22  <wumpus> and for the built-in seed node selection there should probably be some non-standard ports too
2152016-10-25T07:38:29  <gmaxwell> well also something we could deploy on relatively short notice if there were a widespread reason.
2162016-10-25T07:38:42  <gmaxwell> seed nodes make sense.
2172016-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
2182016-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 :)
2192016-10-25T07:40:57  <wumpus> it also means you can make a selection "no bitcoin here, but we allow dogecoin and litecoin through!"
2202016-10-25T07:41:32  <sipa> we should make the port depend on the (routable) IP
2212016-10-25T07:42:30  <sipa> 1024 + H("bitcoin port" || ip) % (32768 - 1024)
2222016-10-25T07:43:40  <luke-jr> can we not at least not require uint256 math support? :x
2232016-10-25T07:43:51  <sipa> sure
2242016-10-25T07:43:59  <gmaxwell> yea, but sadly we don't really know our IP at the relevant time.
2252016-10-25T07:44:42  <sipa> we need to implement IP over reddit.
2262016-10-25T07:44:43  <wumpus> "spread spectrum TCP" hehe
2272016-10-25T07:44:48  <gmaxwell> it's harmless to just save a port to peers.dat and try to use it.
2282016-10-25T07:45:05  <luke-jr> sipa: can we make an encoding that looks like r/BTC posters? :p
2292016-10-25T07:45:22  <sipa> luke-jr: working on software for that!
2302016-10-25T07:45:30  <tulip> https://www.reddit.com/r/blockchainheaders/
2312016-10-25T07:46:31  <sipa> tulip: last post 1 week ago :(
2322016-10-25T07:47:27  <rabidus_> maybe blockchain is dead
2332016-10-25T07:48:28  <luke-jr> :x
2342016-10-25T07:49:15  <sipa> ok, it's over guys
2352016-10-25T07:49:28  <sipa> let's go do dollar instead
2362016-10-25T07:49:38  <wumpus> yep, we've reached the end
2372016-10-25T07:50:18  <gmaxwell> I am trying to send my dollar over the internet but it will not send.
2382016-10-25T07:50:50  <sipa> how do we get more people to use dollar?
2392016-10-25T07:50:52  <gmaxwell> My transaction is stuck in the cup holder and it will not open anymore.
2402016-10-25T07:53:47  <wumpus> gmaxwell: for some reason no one accepts scanned dollar bills as payment
2412016-10-25T07:54:24  <wumpus> possibly there is a double-spending problem
2422016-10-25T07:55:18  *** a_meteorite has joined #bitcoin-core-dev
2432016-10-25T07:56:13  <gmaxwell> Really? But I heard Microsoft was migrating to dollar.
2442016-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.
2452016-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.
2462016-10-25T08:03:11  *** laurentmt has joined #bitcoin-core-dev
2472016-10-25T08:03:11  *** laurentmt has quit IRC
2482016-10-25T08:04:13  *** AaronvanW has joined #bitcoin-core-dev
2492016-10-25T08:05:23  <luke-jr> tulip: but we all know reddit is censorship-proof
2502016-10-25T08:06:51  *** paveljanik has quit IRC
2512016-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)
2522016-10-25T08:08:41  <phantomcircuit> tulip: oh nose now someone can login to yubico as me
2532016-10-25T08:09:21  <luke-jr> gmaxwell: my guess is bitcoind didn't stop before you tried to start it again
2542016-10-25T08:09:36  <luke-jr> although I would expect a debug.log to be generated in that case
2552016-10-25T08:09:41  <gmaxwell> then why didn't the startup throw a lockfile error.
2562016-10-25T08:10:03  <phantomcircuit> gmaxwell: disk space?
2572016-10-25T08:10:14  <phantomcircuit> nfs or something weird?
2582016-10-25T08:10:19  <phantomcircuit> debug.log being trimmed?
2592016-10-25T08:10:20  <gmaxwell> no actually .. damn, its not throwing an error anymore!
2602016-10-25T08:10:32  <gmaxwell> just always says "Bitcoin server starting" :P
2612016-10-25T08:10:43  <phantomcircuit> ptrace
2622016-10-25T08:11:17  <gmaxwell> so I think it's throwing that error after daemonizing so I never see it.
2632016-10-25T08:11:38  <gmaxwell> yea, with daemon=0, I get the expected cannot obtain a lock.
2642016-10-25T08:11:49  <gmaxwell> well one mystery solved and a new one created...
2652016-10-25T08:11:58  <luke-jr> heh, I assumed daemon was 0 because you didn't specify it on the commandline XD
2662016-10-25T08:12:16  <luke-jr> wait nm
2672016-10-25T08:12:30  * luke-jr must be getting tired
2682016-10-25T08:16:02  * gmaxwell opens issue
2692016-10-25T08:16:20  <btcdrak> making the dollar bill larger will increase adoption
2702016-10-25T08:17:24  <wumpus> btcdrak: haha I had the same thought
2712016-10-25T08:17:28  *** thokon00 has joined #bitcoin-core-dev
2722016-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!
2732016-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!
2742016-10-25T08:19:09  <luke-jr> wumpus: it's okay, I will use visa.info
2752016-10-25T08:20:23  <luke-jr> man, the analogy there is surprising.
2762016-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
2772016-10-25T08:21:24  <wumpus> all the messages printed to stdout/stderr also need to go to the log
2782016-10-25T08:24:06  *** whphhg has joined #bitcoin-core-dev
2792016-10-25T08:29:05  *** a_meteorite has quit IRC
2802016-10-25T08:45:27  *** a_meteorite has joined #bitcoin-core-dev
2812016-10-25T09:22:52  *** laurentmt has joined #bitcoin-core-dev
2822016-10-25T09:24:41  *** laurentmt has quit IRC
2832016-10-25T09:34:44  *** face_ has joined #bitcoin-core-dev
2842016-10-25T09:36:20  *** cryptapus has joined #bitcoin-core-dev
2852016-10-25T09:38:07  *** face_ is now known as face
2862016-10-25T09:39:34  *** Samdney has joined #bitcoin-core-dev
2872016-10-25T09:39:43  *** cryptapus has quit IRC
2882016-10-25T09:41:30  *** cdecker has joined #bitcoin-core-dev
2892016-10-25T09:42:47  *** cryptapus has joined #bitcoin-core-dev
2902016-10-25T09:42:47  *** cryptapus has joined #bitcoin-core-dev
2912016-10-25T09:43:43  *** murch has joined #bitcoin-core-dev
2922016-10-25T09:55:42  *** jtimon has joined #bitcoin-core-dev
2932016-10-25T09:56:08  <luke-jr> rebased multiwallet stuff on latest master including jonasschnelli's suggestions. hopefully unaffected by half-asleepness. :x
2942016-10-25T09:57:24  *** AaronvanW has quit IRC
2952016-10-25T10:05:25  *** AaronvanW has joined #bitcoin-core-dev
2962016-10-25T10:06:18  *** AaronvanW has quit IRC
2972016-10-25T10:06:25  *** AaronvanW has joined #bitcoin-core-dev
2982016-10-25T10:06:51  *** AaronvanW has quit IRC
2992016-10-25T10:06:52  *** AaronvanW has joined #bitcoin-core-dev
3002016-10-25T10:11:55  *** Samdney has quit IRC
3012016-10-25T10:12:16  *** Samdney has joined #bitcoin-core-dev
3022016-10-25T10:18:46  *** a_meteorite has quit IRC
3032016-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
3042016-10-25T10:24:22  *** a_meteorite has joined #bitcoin-core-dev
3052016-10-25T10:27:48  <GitHub59> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/67728a389ccf...e1d1f57b56b2
3062016-10-25T10:27:49  <GitHub59> bitcoin/master 515e264 Gregory Maxwell: Make connect=0 disable automatic outbound connections....
3072016-10-25T10:27:49  <GitHub59> bitcoin/master e1d1f57 Wladimir J. van der Laan: Merge #9002: Make connect=0 disable automatic outbound connections....
3082016-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
3092016-10-25T10:31:50  *** Samdney has quit IRC
3102016-10-25T10:34:17  <btcdrak> luke-jr: #8694? I was meaning to test that out.
3112016-10-25T10:34:44  <luke-jr> btcdrak: yeah.
3122016-10-25T10:37:24  <GitHub103> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e1d1f57b56b2...f14f07cb94eb
3132016-10-25T10:37:25  <GitHub103> bitcoin/master fa1c3c2 MarcoFalke: [net] Remove assert(nMaxInbound > 0)...
3142016-10-25T10:37:25  <GitHub103> bitcoin/master f14f07c Wladimir J. van der Laan: Merge #9008: [net] Remove assert(nMaxInbound > 0)...
3152016-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
3162016-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
3172016-10-25T10:45:23  <luke-jr> wumpus: 8784 should be harmless regardless of rc3
3182016-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?
3192016-10-25T10:55:19  <wumpus> yes that'd be helpful I'll likely not be moerging release notes from anywhere but github pulls
3202016-10-25T11:25:09  <GitHub186> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f14f07cb94eb...e077e0030384
3212016-10-25T11:25:10  <GitHub186> bitcoin/master 3f7581d Micha: [TRIVIAL] reorder Windows gitian build order to match Linux...
3222016-10-25T11:25:10  <GitHub186> bitcoin/master e077e00 Wladimir J. van der Laan: Merge #8948: [TRIVIAL] reorder Windows gitian build order to match Linux...
3232016-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
3242016-10-25T11:26:36  *** Giszmo has joined #bitcoin-core-dev
3252016-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
3262016-10-25T11:37:37  <luke-jr> and with that, I'm heading to bed, night
3272016-10-25T11:43:21  *** cdecker has quit IRC
3282016-10-25T11:45:32  *** cjcj has quit IRC
3292016-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?
3302016-10-25T11:57:50  <wumpus> it's a bit silly after that, with both a InitParameterInteraction and AppInitParameterInteraction :)
3312016-10-25T11:59:39  *** a_meteorite has quit IRC
3322016-10-25T12:03:45  *** a_meteorite has joined #bitcoin-core-dev
3332016-10-25T12:04:47  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3342016-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
3352016-10-25T12:12:31  <GitHub37> [bitcoin] laanwj pushed 2 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/c9a5baddeef3...cb699885728f
3362016-10-25T12:12:31  <GitHub37> bitcoin/0.13 99f5cf1 Luke Dashjr: release-notes: Update from blog draft
3372016-10-25T12:12:32  <GitHub37> bitcoin/0.13 cb69988 Wladimir J. van der Laan: Merge #9012: release-notes: Update from blog draft...
3382016-10-25T12:16:28  *** murch has quit IRC
3392016-10-25T12:22:21  <GitHub99> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/e077e0030384...9bdf5269f886
3402016-10-25T12:22:22  <GitHub99> bitcoin/master f48211b Pieter Wuille: Bypass removeRecursive in removeForReorg
3412016-10-25T12:22:22  <GitHub99> bitcoin/master 51f2783 Pieter Wuille: Make removed and conflicted arguments optional to remove
3422016-10-25T12:22:23  <GitHub99> bitcoin/master 4100499 Pieter Wuille: Return shared_ptr<CTransaction> from mempool removes
3432016-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
3442016-10-25T12:40:20  *** laurentmt has joined #bitcoin-core-dev
3452016-10-25T12:41:17  <achow101> will there be an rc3?
3462016-10-25T12:41:43  *** a_meteorite has quit IRC
3472016-10-25T12:46:03  <wumpus> not at this point, but that's never sure, a critical issue could up any time
3482016-10-25T12:46:53  *** Chris_Stewart_5 has quit IRC
3492016-10-25T12:49:06  *** laurentmt has quit IRC
3502016-10-25T12:54:22  *** laurentmt has joined #bitcoin-core-dev
3512016-10-25T12:57:09  *** laurentmt has quit IRC
3522016-10-25T13:03:07  *** a_meteorite has joined #bitcoin-core-dev
3532016-10-25T13:20:40  *** LeMiner has quit IRC
3542016-10-25T13:21:21  *** LeMiner has joined #bitcoin-core-dev
3552016-10-25T13:24:04  *** a_meteorite has quit IRC
3562016-10-25T13:32:11  *** LeMiner2 has joined #bitcoin-core-dev
3572016-10-25T13:34:32  *** LeMiner has quit IRC
3582016-10-25T13:34:32  *** LeMiner2 is now known as LeMiner
3592016-10-25T13:36:48  *** DigiByteDev has joined #bitcoin-core-dev
3602016-10-25T13:51:24  *** kadoban has joined #bitcoin-core-dev
3612016-10-25T14:07:31  *** DigiByteDev has quit IRC
3622016-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?
3632016-10-25T14:12:43  *** Guyver2 has joined #bitcoin-core-dev
3642016-10-25T14:12:58  <instagibbs> ie, will getnewaddress return those new address types, will there be a new call for that instead, etc
3652016-10-25T14:18:52  <sipa> instagibbs: i would think there is a cmdline option that sets the default, which is introduced after activation
3662016-10-25T14:19:12  <sipa> instagibbs: and maybe at some point the default for that flag is changed
3672016-10-25T14:19:19  <instagibbs> Ah, ok that might make sense
3682016-10-25T14:19:30  <instagibbs> fixing tests may only mean a single line per test
3692016-10-25T14:19:52  <instagibbs> at least in immediate term, even if one flips the default
3702016-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.
3712016-10-25T14:21:52  *** roconnor has joined #bitcoin-core-dev
3722016-10-25T14:22:36  *** LeMiner has quit IRC
3732016-10-25T14:22:48  <wumpus> there should be a flag to getnewaddress what kind of address to return, I suppose
3742016-10-25T14:23:08  <wumpus> the default of that could depend on a command-line option
3752016-10-25T14:23:50  <instagibbs> that's what I tried first, but number of flags is quite long :) might be complementary of course
3762016-10-25T14:24:18  <instagibbs> (also you don't want to have to change every instance of getnewaddress in the test codebase)
3772016-10-25T14:24:26  <wumpus> have you seen my named-rpc-arguments pull? it would make coping with lots of flags easier
3782016-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
3792016-10-25T14:25:03  <instagibbs> yes, and test transition from non-segwit to segwit, etc
3802016-10-25T14:25:12  *** Cory has quit IRC
3812016-10-25T14:25:26  <instagibbs> link to pr?
3822016-10-25T14:25:34  <wumpus> https://github.com/bitcoin/bitcoin/pull/8811
3832016-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.
3842016-10-25T14:26:14  <sipa> double indirections yay
3852016-10-25T14:26:31  <wumpus> sipa: well it should be possible to override it through the RPC call at least
3862016-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
3872016-10-25T14:27:52  *** Cory has joined #bitcoin-core-dev
3882016-10-25T14:28:10  <wumpus> seems bad both for testing and actual usage
3892016-10-25T14:28:18  *** owowo has quit IRC
3902016-10-25T14:29:12  <wumpus> and there may be other types of addresses to return in the future
3912016-10-25T14:29:21  <wumpus> so an address ttpe argument to getnewaddress would make sense
3922016-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)"
3932016-10-25T14:29:42  *** LeMiner has joined #bitcoin-core-dev
3942016-10-25T14:30:07  *** tulip has quit IRC
3952016-10-25T14:45:44  <BlueMatt> hum...are any of the fixes currently proposed as backports for rc3 regressions since 13.0?
3962016-10-25T14:46:20  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3972016-10-25T14:47:03  <sipa> BlueMatt: the blocktxn lock is
3982016-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
3992016-10-25T14:47:45  <BlueMatt> sipa: it is?!
4002016-10-25T14:47:59  <wumpus> the assert too
4012016-10-25T14:48:11  <BlueMatt> oh, i was mostly asking about the assert
4022016-10-25T14:48:27  <BlueMatt> damn :(
4032016-10-25T14:48:31  <sipa> BlueMatt: compact blocks and feelers are in 0.13.0
4042016-10-25T14:48:35  <wumpus> this ws introduced in the 'feelers' commit which IIRC was introduced after 0.13.0
4052016-10-25T14:48:52  <BlueMatt> sipa: i said regressions since 13
4062016-10-25T14:49:06  <wumpus> but I'm not 100% sure
4072016-10-25T14:49:23  <sipa> oh, you mean regressions introduced strictly after 0.13.0?
4082016-10-25T14:49:24  <BlueMatt> wumpus: thats what i thought about the asserts, which sucks
4092016-10-25T14:49:27  <BlueMatt> sipa: yes
4102016-10-25T14:49:31  <sipa> ah
4112016-10-25T14:49:48  <sipa> "since" is ambiguous, i guess :)
4122016-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
4132016-10-25T14:49:58  <wumpus> the license ones and relayrpriority error are just nice to include but low risk and very low priority
4142016-10-25T14:50:41  <wumpus> I'm not sure the assert one warrants a rc3 yet
4152016-10-25T14:51:07  <wumpus> it's a problem that is not remote triggerable and easy to work around by increasing maxconnections
4162016-10-25T14:51:22  <wumpus> note that it asserts the maximum, not the current value
4172016-10-25T14:51:24  <sipa> i'm surprised it took us so long to find
4182016-10-25T14:51:32  <sipa> especially since it is 0.13.0
4192016-10-25T14:51:36  *** Chris_Stewart_5 has quit IRC
4202016-10-25T14:51:38  <sipa> and nobody reported it
4212016-10-25T14:52:01  <BlueMatt> sipa: thats the point of rcs
4222016-10-25T14:52:13  <BlueMatt> wumpus: yea, I'm trying to decide how i feel about rc3, hence the questions
4232016-10-25T14:52:22  <sipa> BlueMatt: well, yes, but it wasn't found in the 0.13.0 rc
4242016-10-25T14:52:37  <wumpus> feeler connections was not in 0.13.0
4252016-10-25T14:52:38  <BlueMatt> sipa: oh, the assert was in 0.13.0?
4262016-10-25T14:52:44  <BlueMatt> yea, thats what i thought
4272016-10-25T14:53:09  <wumpus> no, it was added in 2611ad7 (part of #8679), which are post-0.13.0 backports
4282016-10-25T14:53:21  <wumpus> I don't know anymore why it was flagged for backport in the first place
4292016-10-25T14:54:12  <BlueMatt> feelers? folks wanted feelers to reinforce the preferential-peering stuff
4302016-10-25T14:54:17  <BlueMatt> to ensure we find out service bits
4312016-10-25T14:54:49  <wumpus> ok
4322016-10-25T14:55:12  <BlueMatt> at least afaiu
4332016-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)
4342016-10-25T14:55:38  <instagibbs> yes that was the reasoning
4352016-10-25T14:56:55  <sipa> indeed, i think it was discussed in a meeting
4362016-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
4372016-10-25T15:06:04  <wumpus> right now it'd set earliest-possible-final date to next week, which'd be oct 1
4382016-10-25T15:06:28  <wumpus> NOV 1
4392016-10-25T15:07:46  <sipa> we all know that 31 OCT == 25 DEC.
4402016-10-25T15:09:44  <BlueMatt> *facepalm*
4412016-10-25T15:10:00  <BlueMatt> wumpus: I'd vote no
4422016-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
4432016-10-25T15:13:58  <sipa> maxconnections set to 8 or lower is very common , i think
4442016-10-25T15:16:04  <sipa> though, given that it took so long to find, perhaps less common than i thought
4452016-10-25T15:16:28  <BlueMatt> so its maxconnections < 8 and then you get an incoming connectiotn?
4462016-10-25T15:16:40  <BlueMatt> I mean i think maxconnections < 8 with incoming connections is maybe strange?
4472016-10-25T15:18:03  <wumpus> I don't think it is *very* common
4482016-10-25T15:20:41  <BlueMatt> I'm ok with an 0.13.2 for this, delaying 0.13.1 for this seems overkill
4492016-10-25T15:20:56  <sipa> ok
4502016-10-25T15:22:01  <btcdrak> ack
4512016-10-25T15:30:08  <BlueMatt> so pending no other bugs 0.13.0-final would be tagaged on thurs?
4522016-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
4532016-10-25T15:34:25  <BlueMatt> ehh, 13.1-final
4542016-10-25T15:39:22  *** a_meteorite has joined #bitcoin-core-dev
4552016-10-25T15:52:30  <wumpus> yes
4562016-10-25T16:14:03  <gmaxwell> I asked for the backport and the issue is that without feelers addrman learns about witness peers VERY slowly.
4572016-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.
4582016-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.
4592016-10-25T16:21:54  <gmaxwell> So you'll start the node, think it's all happy, then then boom, it crashes.
4602016-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.
4612016-10-25T16:34:54  <btcdrak> easily documented in the release notes under known issues
4622016-10-25T16:35:49  <gmaxwell> yes, well it _will_ cause surprise crashes for some users. As not everyone reads the release notes.
4632016-10-25T16:36:50  <btcdrak> maybe, but if people dont RTM there isnt much you can do.
4642016-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.
4652016-10-25T16:47:13  *** a_meteorite has quit IRC
4662016-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
4672016-10-25T16:48:50  <gmaxwell> Is that really the question?  Are we otherwise going to do the final today?
4682016-10-25T16:54:25  <gmaxwell> grepping my logs,
4692016-10-25T16:54:27  <gmaxwell> 05:57 < gijensen> I run my tn node with maxconnections=8
4702016-10-25T16:54:49  <gmaxwell> 08:54 < KipIngram> I'm running with maxconnections=5 and dbcache=768.
4712016-10-25T16:55:26  <gmaxwell> 02:06 < epscy> pancake: setting maxconnections to 4 (or 3) helped me
4722016-10-25T16:56:09  <gmaxwell> 11:01 < geir> Tried bitcoind -dbcache=50 -nolisten -maxconnections=8
4732016-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
4742016-10-25T16:56:51  <gmaxwell> 10:13 < osmosis> i was able to get what I wanted by using, -maxconnections=0  for testing
4752016-10-25T16:56:56  <gmaxwell> 08:11 < m0gliE> -maxconnections=6
4762016-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.
4772016-10-25T16:57:47  *** MarcoFalke has joined #bitcoin-core-dev
4782016-10-25T16:58:15  <gmaxwell> 13:16 < HM2> maxconnections=8, server=0
4792016-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.
4802016-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
4812016-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.
4822016-10-25T17:00:58  <gmaxwell> ten we should do an RC for 0.13.2 pretty much immediately.
4832016-10-25T17:01:10  <BlueMatt> that i agree with
4842016-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 0.13.0.1 for those who wish to not switch to segwit
4852016-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.
4862016-10-25T17:02:23  <gmaxwell> BlueMatt: sure, but that can be done after the 0.13.1 release.
4872016-10-25T17:02:29  <BlueMatt> gmaxwell: indeed, and should be
4882016-10-25T17:03:23  *** neha has quit IRC
4892016-10-25T17:04:38  <BlueMatt> I'm not a fan of making a code change and tagging final a day later
4902016-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...
4912016-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? :)
4922016-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
4932016-10-25T17:12:44  <gmaxwell> if so thats only an argument to not release.
4942016-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
4952016-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.
4962016-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.
4972016-10-25T17:14:35  <BlueMatt> I'm aware
4982016-10-25T17:17:04  <MarcoFalke> If anything, the assert should be checking >= 0
4992016-10-25T17:17:07  <MarcoFalke> and not >0
5002016-10-25T17:17:18  <gmaxwell> it's still pointlss in any case.
5012016-10-25T17:17:46  <MarcoFalke> I somehow feel uncomfortable shipping code which crashes after some time, unexpectedly.
5022016-10-25T17:17:48  <gmaxwell> consider, it depends on no dynamic state. It could be in init.cpp.
5032016-10-25T17:17:52  <BlueMatt> i dont think we disagree on whether the fix (removing it) is probably correct
5042016-10-25T17:18:19  <MarcoFalke> Hmm, generally I like asserts to verify assumptions about the code.
5052016-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.
5062016-10-25T17:19:21  <BlueMatt> hum, thats true
5072016-10-25T17:19:22  <sipa> BlueMatt: i think there may be a larger change optimally, but not for 0.13.x
5082016-10-25T17:20:07  <MarcoFalke> I think we are missing documentation on how feelers should behave when maxconnections is given
5092016-10-25T17:20:15  <MarcoFalke> The current behavior makes sense
5102016-10-25T17:20:24  <MarcoFalke> Even though it was never meant to work this way
5112016-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?
5122016-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." ? :)
5132016-10-25T17:21:37  <gmaxwell> wumpus: yes, that is my proposal.
5142016-10-25T17:22:07  <wumpus> so should we then do.. a vote or something? :/
5152016-10-25T17:22:42  <MarcoFalke> Was there a date when to tag final?
5162016-10-25T17:22:52  <BlueMatt> gmaxwell: no, the fact that this would be better if it crashed right away
5172016-10-25T17:22:53  <wumpus> yes, tomorrow
5182016-10-25T17:23:13  <BlueMatt> alternatively, just throwing this out there, we could make it crash on startup by adding code there instead :p
5192016-10-25T17:23:15  <MarcoFalke> Ok, so today rc3 with no gitian builds and tomorrow final?
5202016-10-25T17:23:45  <wumpus> I guess, I'm fine with doing that if there is common agreement to do that
5212016-10-25T17:23:55  <sipa> sounds good to me
5222016-10-25T17:24:08  <BlueMatt> I'm really not a fan...
5232016-10-25T17:24:23  *** Chris_Stewart_5 has joined #bitcoin-core-dev
5242016-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
5252016-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
5262016-10-25T17:25:26  <BlueMatt> I mean realistically when are we gonna have binaries out for 0.13.1? not till monday probably anyway
5272016-10-25T17:25:33  <MarcoFalke> It does not crash in a different way, now.
5282016-10-25T17:25:37  <wumpus> I think multiple people verified that the code doesn't crash if that value becomes 0 or negative
5292016-10-25T17:26:04  <MarcoFalke> The value is only used in the local scope of the function once
5302016-10-25T17:26:09  <wumpus> right
5312016-10-25T17:26:09  <gmaxwell> I've been running a public node negative number there for ~two days now.
5322016-10-25T17:26:36  <gmaxwell> (running with maxconnections 8)
5332016-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?
5342016-10-25T17:28:01  <wumpus> who knows? gitian building goes really fast these days
5352016-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
5362016-10-25T17:28:28  <wumpus> if we're going to do rc3 with just the assert removed I'm going to tag *now*
5372016-10-25T17:28:33  <gmaxwell> what does that change?
5382016-10-25T17:28:40  <gmaxwell> that was a reply to BlueMatt
5392016-10-25T17:28:55  <wumpus> we know exactly what we want to do so no need to delay one second
5402016-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
5412016-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.
5422016-10-25T17:30:29  <GitHub136> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/58d4fa7da30cb57e5fc3dca62f49a64e126c76cd
5432016-10-25T17:30:29  <GitHub136> bitcoin/0.13 58d4fa7 MarcoFalke: [net] Remove assert(nMaxInbound > 0)...
5442016-10-25T17:30:35  <MarcoFalke> BlueMatt: In which case it does still make sense to tag rc3 sooner than later
5452016-10-25T17:30:43  <BlueMatt> MarcoFalke: yes
5462016-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
5472016-10-25T17:31:19  <BlueMatt> gmaxwell: and we still get binaries out before monday morning
5482016-10-25T17:32:05  <wumpus> I'm not normally a fan of this either, but this is so trivial
5492016-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
5502016-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
5512016-10-25T17:33:14  <wumpus>  * [new tag]         v0.13.1rc3 -> v0.13.1rc3
5522016-10-25T17:35:17  *** a_meteorite has joined #bitcoin-core-dev
5532016-10-25T17:35:39  <BlueMatt> wumpus: wait, why did we not include the cs_main missing lock fix in rc3?
5542016-10-25T17:36:37  <wumpus> because that is more impact / risk than just removing an assert
5552016-10-25T17:37:02  *** paveljanik has joined #bitcoin-core-dev
5562016-10-25T17:37:03  <wumpus> a locking change would need more testing
5572016-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
5582016-10-25T17:38:03  <achow101> what about the other stuff listed in 9011?
5592016-10-25T17:38:05  <gmaxwell> I'm of a similar view with wumpus.
5602016-10-25T17:38:07  <wumpus> morcos: we'll have to, anyway I' m sure there will be plenty of bugs
5612016-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
5622016-10-25T17:39:18  <wumpus> the other option would be doing a rc3, including more, but delaying -final until next week
5632016-10-25T17:39:20  <morcos> wumpus: ok.. sufficiently convinced
5642016-10-25T17:39:30  <achow101> wouldn't doing rc3 knock the release back to nov 1? Or am I missing something?
5652016-10-25T17:39:36  <BlueMatt> achow101: it did not
5662016-10-25T17:39:44  <morcos> its rc2.01
5672016-10-25T17:39:45  <wumpus> achow101: it would have, if we included actual serious changes
5682016-10-25T17:39:56  <wumpus> removing this assert is so trivial
5692016-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)
5702016-10-25T17:40:25  <gmaxwell> morcos: at least in my thinking, I'd consider the issue seperately.
5712016-10-25T17:40:25  <wumpus> and no, I don't feel like discussing that further or backstepping now, that was just a project decision
5722016-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.
5732016-10-25T17:40:46  <achow101> so when is final planned for?
5742016-10-25T17:40:51  <wumpus> tomorrow
5752016-10-25T17:40:59  <wumpus> eh, no, thursday
5762016-10-25T17:41:27  <BlueMatt> oh, it was already thursday
5772016-10-25T17:41:28  *** ryanofsky has joined #bitcoin-core-dev
5782016-10-25T17:41:35  <wumpus> yes it was already thursday
5792016-10-25T17:41:43  <BlueMatt> wumpus: can we do an announce for the rc3 to the ml?
5802016-10-25T17:41:46  <BlueMatt> even without bins?
5812016-10-25T17:41:46  <wumpus> the point was not to change that
5822016-10-25T17:41:55  <wumpus> BlueMatt: sure ,feel free to do so, I"m going to bed
5832016-10-25T17:41:56  <achow101> do we still need to gitian build it?
5842016-10-25T17:41:58  <BlueMatt> indeed, I'm aware
5852016-10-25T17:42:05  <BlueMatt> achow101: we are not doing gitian builds of rc3
5862016-10-25T17:42:17  <wumpus> achow101: nope
5872016-10-25T17:42:22  <achow101> ok
5882016-10-25T17:42:34  <sipa> wumpus: good night!
5892016-10-25T17:42:34  <wumpus> you can gitian-build it for yourself ofcourse, or if you want to compare against someone else
5902016-10-25T17:45:00  <cfields_> I'll build either way so we can have something to point to if anyone wants it
5912016-10-25T17:46:05  <gmaxwell> assuming final is the same would the gitian binaries actually be the same?
5922016-10-25T17:46:49  <wumpus> unfortunately, no, because the build embeds the tag from git :(
5932016-10-25T17:47:23  <wumpus> if not for that the binary for -final would be exactly the same as -rc<last>
5942016-10-25T17:48:33  <wumpus> assuming no commits in between either
5952016-10-25T17:48:35  <BlueMatt> cfields_: whats the status of the osx change? are we gonna change the plist for final?
5962016-10-25T17:48:42  *** Chris_Stewart_5 has quit IRC
5972016-10-25T17:49:13  <wumpus> as the commit id# is also in the executable
5982016-10-25T17:49:16  <cfields_> BlueMatt: i think we should, yes. There should be ~zero practical impact.
5992016-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)
6002016-10-25T17:49:34  <BlueMatt> cfields_: yes, fine with that being merged w/o rc, just asking if its gonna happen
6012016-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
6022016-10-25T17:50:35  <wumpus> gmaxwell: that's why that was never removed
6032016-10-25T17:50:40  <cfields_> wumpus: you ok with https://github.com/bitcoin/bitcoin/issues/8577#issuecomment-255947269 with no additional testing?
6042016-10-25T17:50:59  <cfields_> sorry that took so long, I chased it all day yesterday
6052016-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.
6062016-10-25T17:52:20  <wumpus> cfields_: does that affect anything?
6072016-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.
6082016-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
6092016-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."
6102016-10-25T17:54:34  <wumpus> cfields_: sounds good to me
6112016-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.
6122016-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
6132016-10-25T17:55:59  <gmaxwell> wumpus: alernatively, it could embed some hash of the source code that wouldn't be changed by updating tags.
6142016-10-25T17:56:03  *** Chris_Stewart_5 has joined #bitcoin-core-dev
6152016-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.
6162016-10-25T17:56:48  <cfields_> -mmacosx-version-min, that is
6172016-10-25T17:59:48  *** owowo has joined #bitcoin-core-dev
6182016-10-25T17:59:57  <wumpus> BlueMatt: you sent the rc announcement to bitcoin-dev instead of bitcoin-core-dev :)
6192016-10-25T18:00:11  <BlueMatt> they're different? oops
6202016-10-25T18:00:13  <wumpus> BlueMatt: otherwise, thanks!
6212016-10-25T18:00:20  <BlueMatt> ehh, see, this is why i dont do release process :p
6222016-10-25T18:00:43  <btcdrak> please send to bitcoin-core-dev also
6232016-10-25T18:00:44  <wumpus> no problem, just send a copy to bitcoin-core-dev too
6242016-10-25T18:01:57  <BlueMatt> ok, done
6252016-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?
6262016-10-25T18:06:42  <jonasschnelli> IIRC, I did only move the SoftSetBoolArg() in https://github.com/bitcoin/bitcoin/pull/6780
6272016-10-25T18:06:59  <jonasschnelli> But I can't remember the exact reason why not every interaction was moved.
6282016-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
6292016-10-25T18:08:20  <wumpus> instagibbs: patches welcome
6302016-10-25T18:09:02  <instagibbs> roger
6312016-10-25T18:09:27  <cfields_> instagibbs: i have a PR that changes that behavior and creates better error messages. sec.
6322016-10-25T18:09:42  <instagibbs> I've literally implemented it before, for elements, but then forgot about it
6332016-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 :-)
6342016-10-25T18:09:50  <instagibbs> and now running into it again working on Core, d'oh
6352016-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
6362016-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
6372016-10-25T18:10:53  <cfields_> grr, I need to clean that up and resubmit. Trying to fix up my PRs today.
6382016-10-25T18:11:03  <instagibbs> wumpus, well right now any error in wallet's transaction gives you a super broad message about money missing
6392016-10-25T18:11:04  <cfields_> instagibbs: see the comments in https://github.com/bitcoin/bitcoin/pull/8888
6402016-10-25T18:11:21  <cfields_> instagibbs: specifically: https://github.com/theuni/bitcoin/commit/349edab789557db615b29a5869118b4b08c50dab
6412016-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.
6422016-10-25T18:14:00  <instagibbs> Yeah that looks better, but it could still stand to pass back why it failed mempool entry
6432016-10-25T18:16:35  <cfields_> instagibbs: for sure.
6442016-10-25T18:21:19  *** paveljanik has quit IRC
6452016-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!"
6462016-10-25T18:25:10  <cfields_> heh
6472016-10-25T18:25:12  <wumpus> thinking of it, neither amount, complexity or use of recently received funds counts towards the fee
6482016-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?
6492016-10-25T18:25:35  *** paveljanik has joined #bitcoin-core-dev
6502016-10-25T18:25:37  *** paveljanik has joined #bitcoin-core-dev
6512016-10-25T18:25:41  <gmaxwell> "because of the required resources"
6522016-10-25T18:25:44  <wumpus> jl2012: yes, I had a pull for that once
6532016-10-25T18:25:53  <cfields_> jl2012: decoderawtransaction ?
6542016-10-25T18:26:17  <jl2012> decode won't test for validity
6552016-10-25T18:26:25  <jl2012> wumpus: why isn't it merged?
6562016-10-25T18:27:10  <gmaxwell> jl2012: the way I've recommended doing that before is with a block proposal.
6572016-10-25T18:27:22  <wumpus> lack of testing
6582016-10-25T18:27:22  <gmaxwell> jl2012: which lets you also have a chain of unconfirmed transactions.
6592016-10-25T18:27:31  <wumpus> mine could do that too
6602016-10-25T18:27:47  <gmaxwell> wumpus: that sounds good.
6612016-10-25T18:27:55  <wumpus> jl2012: https://github.com/bitcoin/bitcoin/pull/7552
6622016-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)
6632016-10-25T18:31:21  *** d_t has joined #bitcoin-core-dev
6642016-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
6652016-10-25T18:32:12  <jl2012> access to one key, you could still get the money back with another key after the locktime
6662016-10-25T18:32:31  <jl2012> But I need the ability to verify the unconfirmed tx is actually valid
6672016-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
6682016-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
6692016-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.
6702016-10-25T18:34:39  <jl2012> yes, the 1/2 for the number of sigs could be pushed with IF/ELSE
6712016-10-25T18:35:30  *** jtimon has quit IRC
6722016-10-25T18:37:35  <instagibbs> wumpus, too bad, I think rpc's checking for validity without committing them are useful
6732016-10-25T18:38:08  <gmaxwell> instagibbs: go pick up his PR.
6742016-10-25T18:38:18  <gmaxwell> no one was opposed to the idea.
6752016-10-25T18:39:10  <instagibbs> I remember it being contentious regarding the devilish details, but I'll take another look
6762016-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
6772016-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.
6782016-10-25T18:42:40  <wumpus> I tend to lose interest in projects after a while, that doesn't mean they're not worth doing
6792016-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
6802016-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
6812016-10-25T18:44:32  <wumpus> without actually putting the dependencies in the mempool
6822016-10-25T18:45:13  <instagibbs> achow101, read the PR thread, it's all debated there I think
6832016-10-25T18:45:34  <wumpus> yes
6842016-10-25T18:45:34  <instagibbs> subtle issues mean it's harder to push through
6852016-10-25T18:46:00  <gmaxwell> well the PR might not make it clear that being able to handle chains is pretty useful.
6862016-10-25T18:46:16  <wumpus> it's all been debated before, I don't feel like getting involved again, thanksfor the reminder
6872016-10-25T18:47:17  <achow101> well my idea is to just modify accepttomempool
6882016-10-25T18:47:29  *** Chris_Stewart_5 has quit IRC
6892016-10-25T18:48:04  <wumpus> but would you want changes there for an RPC call whose goal is to *not* touch the mempool?
6902016-10-25T18:48:04  *** JackH has joined #bitcoin-core-dev
6912016-10-25T18:48:20  *** laurentmt has joined #bitcoin-core-dev
6922016-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.
6932016-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, ...)
6942016-10-25T18:50:06  <sipa> but if it includes policy it's also much less meaningful to affect the mempool
6952016-10-25T18:50:17  <achow101> why would adding a flag to acceptomempool be wrong?
6962016-10-25T18:50:33  <wumpus> because the function is called accepttomempool
6972016-10-25T18:50:48  <sipa> let's rename it to AcceptableToMempool
6982016-10-25T18:50:50  <sipa> *ducks*
6992016-10-25T18:51:19  <wumpus> yes, if you split up functions into a 'acceptable policy' part and 'add to mempool', it makes more sense
7002016-10-25T18:51:26  <wumpus> I'm repeating myself
7012016-10-25T18:51:55  <wumpus> agree that checking for consensus is fairly easy
7022016-10-25T18:52:05  <wumpus> the difficult part was all the different policies
7032016-10-25T18:52:25  <wumpus> if that's not necessary then indeed it'd just be a 'block proposal'
7042016-10-25T18:52:42  *** laurentmt has quit IRC
7052016-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
7062016-10-25T18:53:36  <wumpus> 'is this valid at height X time Y' instead of necessarily now
7072016-10-25T19:02:57  *** nickler has joined #bitcoin-core-dev
7082016-10-25T19:04:50  *** Chris_Stewart_5 has joined #bitcoin-core-dev
7092016-10-25T19:12:39  *** MarcoFalke has left #bitcoin-core-dev
7102016-10-25T19:19:30  *** bsm117532 has quit IRC
7112016-10-25T19:21:37  *** bsm117532 has joined #bitcoin-core-dev
7122016-10-25T19:36:28  *** Chris_Stewart_5 has quit IRC
7132016-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
7142016-10-25T19:46:58  *** jtimon has joined #bitcoin-core-dev
7152016-10-25T19:52:07  *** Chris_Stewart_5 has joined #bitcoin-core-dev
7162016-10-25T19:54:20  *** cryptapus has quit IRC
7172016-10-25T19:54:29  *** droark has joined #bitcoin-core-dev
7182016-10-25T20:05:08  *** Chris_Stewart_5 has quit IRC
7192016-10-25T20:07:30  *** Chris_Stewart_5 has joined #bitcoin-core-dev
7202016-10-25T20:16:37  *** Victorsueca has joined #bitcoin-core-dev
7212016-10-25T20:18:10  *** Victorsueca has quit IRC
7222016-10-25T20:19:41  *** echonaut has quit IRC
7232016-10-25T20:20:42  *** echonaut has joined #bitcoin-core-dev
7242016-10-25T20:21:20  *** Victorsueca has joined #bitcoin-core-dev
7252016-10-25T20:22:35  <Victorsueca> wuuuuuut?
7262016-10-25T20:22:39  <Victorsueca> rc3?
7272016-10-25T20:22:51  <Victorsueca> I thought rc2 was the choosen one
7282016-10-25T20:23:20  *** Chris_Stewart_5 has quit IRC
7292016-10-25T20:24:13  <BlueMatt> Victorsueca: see https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-October/013262.html
7302016-10-25T20:25:55  *** Chris_Stewart_5 has joined #bitcoin-core-dev
7312016-10-25T20:26:40  <Victorsueca> BlueMatt: thanks
7322016-10-25T20:26:51  *** aalex has joined #bitcoin-core-dev
7332016-10-25T20:29:05  *** a_meteorite has quit IRC
7342016-10-25T20:41:56  *** a_meteorite has joined #bitcoin-core-dev
7352016-10-25T20:47:36  *** ill has joined #bitcoin-core-dev
7362016-10-25T21:02:19  *** a_meteorite has quit IRC
7372016-10-25T21:05:54  *** a_meteorite has joined #bitcoin-core-dev
7382016-10-25T21:12:27  *** Chris_Stewart_5 has quit IRC
7392016-10-25T21:28:24  *** Chris_Stewart_5 has joined #bitcoin-core-dev
7402016-10-25T21:39:45  *** Guyver2 has quit IRC
7412016-10-25T21:49:10  <GitHub85> [bitcoin] ryanofsky opened pull request #9018: testing pr (please ignore) (master...loop) https://github.com/bitcoin/bitcoin/pull/9018
7422016-10-25T22:33:49  *** owowo has quit IRC
7432016-10-25T22:37:10  <gmaxwell> 40 node_witness peers
7442016-10-25T22:38:56  <gmaxwell> 5 outbound.
7452016-10-25T22:50:41  *** owowo has joined #bitcoin-core-dev
7462016-10-25T22:53:33  <luke-jr> looks like he's abusing that PR to run Travis :/
7472016-10-25T22:53:46  <luke-jr> guess he doesn't realise it emails everyone
7482016-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.  ...
7492016-10-25T22:55:00  <gmaxwell> ignore te first part of that line..
7502016-10-25T22:55:27  <gmaxwell> so thats (If you're..) is all we say about mining & segwit in the release notes right now.
7512016-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.
7522016-10-25T22:56:00  <gmaxwell> And a list of supporting mining software.
7532016-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..
7542016-10-25T22:56:42  <gmaxwell> hm.
7552016-10-25T22:57:20  <luke-jr> or perhaps turning the blog post into a segwit deployment FAQ and linking that
7562016-10-25T22:57:28  <luke-jr> (so we can update it as needed later)
7572016-10-25T22:59:22  <GitHub177> [bitcoin] sipa closed pull request #9018: testing pr (please ignore) (master...loop) https://github.com/bitcoin/bitcoin/pull/9018
7582016-10-25T23:12:14  *** jannes has quit IRC
7592016-10-25T23:42:48  *** bsm117532 has quit IRC