12017-12-20T00:00:00 *** mrannanay has quit IRC
22017-12-20T00:03:40 *** vicenteH has quit IRC
32017-12-20T00:07:16 *** intcat has quit IRC
42017-12-20T00:11:54 *** Randolf has joined #bitcoin-core-dev
52017-12-20T00:13:08 *** alreadylate has quit IRC
62017-12-20T00:14:28 *** alreadylate has joined #bitcoin-core-dev
72017-12-20T00:14:51 <promag> jonasschnelli: is it possible to know if a rescan is in progress?
82017-12-20T00:16:43 *** BashCo has joined #bitcoin-core-dev
92017-12-20T00:17:41 *** intcat has joined #bitcoin-core-dev
102017-12-20T00:22:41 *** jb55 has joined #bitcoin-core-dev
112017-12-20T00:23:07 *** jb55 has joined #bitcoin-core-dev
122017-12-20T00:23:55 *** alreadylate has quit IRC
132017-12-20T00:24:36 *** zshlyk has joined #bitcoin-core-dev
142017-12-20T00:24:37 *** intcat has quit IRC
152017-12-20T00:24:42 *** alreadylate has joined #bitcoin-core-dev
162017-12-20T00:25:35 <midnightmagic> good heavens, lots of new sigs in the gitian.sigs repo.
172017-12-20T00:26:06 <luke-jr> sipa: jonasschnelli: FWIW, my test had chainstate on a 5400 RPM drive with btrfs+compression (no encryption); i7-4771 CPU
182017-12-20T00:26:53 <phantomcircuit> gmaxwell, expiration is keeping the relay fee from going up?
192017-12-20T00:27:21 <luke-jr> short of the compression, I think that's about the worst-possible disk scenario (although it may be all cached in RAM..)
202017-12-20T00:27:21 <phantomcircuit> iirc we dont remember expired transactions at all, i expected that to mean they just end up back in the mempool after a few hours
212017-12-20T00:27:44 *** Randolf has quit IRC
222017-12-20T00:30:53 *** alreadylate has quit IRC
232017-12-20T00:45:32 *** DrBenway has joined #bitcoin-core-dev
242017-12-20T00:45:55 <DrBenway> hi folks, is the 2018 roadmap published anywhere? i can't seem to find it
252017-12-20T00:46:34 *** cloudrunner has joined #bitcoin-core-dev
262017-12-20T00:46:34 <sipa> there is no roadmap
272017-12-20T00:46:35 <bitcoin-git> [bitcoin] agsstaff opened pull request #11954: update (master...master) https://github.com/bitcoin/bitcoin/pull/11954
282017-12-20T00:46:57 <DrBenway> is there some kind of plan for the future or are you guys just maintaining the current codebase and trying to keep it as is?
292017-12-20T00:47:08 <sipa> many people have many plans for the future
302017-12-20T00:47:19 <sipa> but bitcoin core is just an open source project
312017-12-20T00:47:20 <DrBenway> and none of it is public?
322017-12-20T00:47:28 <bitcoin-git> [bitcoin] fanquake closed pull request #11954: update (master...master) https://github.com/bitcoin/bitcoin/pull/11954
332017-12-20T00:47:39 <sipa> DrBenway: what is your roadmap?
342017-12-20T00:47:53 <DrBenway> sipa: i dont have one. but im also not a project
352017-12-20T00:47:55 *** Randolf has joined #bitcoin-core-dev
362017-12-20T00:47:58 <sipa> neither am i
372017-12-20T00:48:15 <DrBenway> o_O
382017-12-20T00:48:37 <DrBenway> friendly community
392017-12-20T00:48:41 <sipa> i volunteer my time, and i'll gladly tell you what i'm working on or excited about
402017-12-20T00:48:57 <sipa> but i can't tell people what they need to work on, or guarantee what they will prioritize
412017-12-20T00:49:05 <sipa> that's up to them
422017-12-20T00:49:41 <DrBenway> so what are you working on?
432017-12-20T00:49:49 <jonasschnelli> promag: currently not possible...
442017-12-20T00:50:07 <jonasschnelli> though adding a check in getwalletinfo would be trivial
452017-12-20T00:50:27 <jonasschnelli> just test if you can reserve via the WalletRescanReserver
462017-12-20T00:50:32 <sipa> DrBenway: i'm currently working on segwit wallet support in bitcoin core, reviewing many other changes, and longer term i'm working on a signature aggregation proposal and a few further out cryptographic constructions
472017-12-20T00:50:46 <eck> what are you excited about?
482017-12-20T00:51:09 *** ghost43 has quit IRC
492017-12-20T00:51:16 <DrBenway> is bitcoin core going ahead with segwit? there's been so much back and forth that im not sure anymore
502017-12-20T00:51:34 *** ghost43 has joined #bitcoin-core-dev
512017-12-20T00:52:11 <meshcollider> DrBenway: Segwit has been activated for months... you are probably getting confused with S2X which is definitely not going ahead, no
522017-12-20T00:52:56 <DrBenway> so currently signatures are not stored with the block itself? or there's an extended block?
532017-12-20T00:53:12 <sipa> DrBenway: segwit absolutely keeps all signatures in blocks
542017-12-20T00:53:15 <meshcollider> Signatures are stored within the block yes
552017-12-20T00:53:27 <sipa> they're just moved to another place, and hashed slightly differently
562017-12-20T00:53:44 *** BashCo has quit IRC
572017-12-20T00:53:47 <DrBenway> i thought the whole idea of segwit was that the signature would go in an extended block? (im not sure where that extended block ends up in the blcok chain)
582017-12-20T00:53:55 <DrBenway> ok
592017-12-20T00:53:55 <sipa> no
602017-12-20T00:54:25 <sipa> the point is (1) signatures are not committed to by transaction ids (but still included in blocks) and (2) are discounted for the purposes of resource limits
612017-12-20T00:54:28 *** BashCo has joined #bitcoin-core-dev
622017-12-20T00:54:37 <sipa> but if you download a block, it still has all the signatures
632017-12-20T00:54:43 <sipa> it'll be invalid without them
642017-12-20T00:54:54 <DrBenway> sure
652017-12-20T00:55:13 <cfields> NicolasDorier: ping. transaction_tests/test_big_witness_transaction takes 20sec to sign the inputs on x86. I suspect it takes minutes on travis. Suggestions for reducing that without defeating the purpose of the test?
662017-12-20T00:55:18 <DrBenway> and that was done as a mean of reducing memory in case that the signute is used several times within a single block?
672017-12-20T00:55:33 <DrBenway> s/memory/data
682017-12-20T00:55:44 <meshcollider> DrBenway: no, signatures can't be reused for different transactions
692017-12-20T00:55:47 <sipa> DrBenway: https://segwit.org/
702017-12-20T00:57:21 *** dabura667 has joined #bitcoin-core-dev
712017-12-20T00:58:45 *** Victorsueca has quit IRC
722017-12-20T01:00:01 *** Kozuch has quit IRC
732017-12-20T01:00:09 *** Victorsueca has joined #bitcoin-core-dev
742017-12-20T01:06:06 *** Ylbam has quit IRC
752017-12-20T01:09:18 <echeveria> GBT over ZMQ seems to be a win.
762017-12-20T01:10:20 <promag> echeveria: GBT?
772017-12-20T01:10:41 <meshcollider> getblocktemplate?
782017-12-20T01:10:41 <echeveria> `getblocktemplate`
792017-12-20T01:11:00 <meshcollider> those are used for very different things though?
802017-12-20T01:11:38 *** mds404 has joined #bitcoin-core-dev
812017-12-20T01:11:48 *** StopAndDecrypt has quit IRC
822017-12-20T01:11:57 <echeveria> not really. at the moment there's a load of suboptimal ways of getting work updates from Bitcoin Core, adding a GBT endpoint means you don't need to poll or do any roundtrips to RPC.
832017-12-20T01:12:34 <echeveria> the status quo at the moment is using -blocknotify to trigger a RPC call, which involves spawning a shell, making a HTTP connection, and the RPC request time.
842017-12-20T01:14:17 *** DrBenway has quit IRC
852017-12-20T01:14:33 *** mds404 has left #bitcoin-core-dev
862017-12-20T01:14:36 <promag> echeveria: you can use pubrawblock
872017-12-20T01:14:44 <promag> ops, pubhashblock
882017-12-20T01:16:11 <promag> I don't think it's a good idea to have a gbt notification
892017-12-20T01:16:12 <echeveria> promag: that still needs a round trip.
902017-12-20T01:16:58 <promag> echeveria: how would you define template_request of gbt?
912017-12-20T01:17:31 <promag> what is the problem of the round trip?
922017-12-20T01:18:14 <echeveria> template_request?
932017-12-20T01:18:24 <promag> gbt argument
942017-12-20T01:19:33 <sipa> promag: ?
952017-12-20T01:19:50 <echeveria> promag: none of those arguments are necessary.
962017-12-20T01:20:50 *** cloudrunner has quit IRC
972017-12-20T01:24:09 <promag> not sure if a notification is the right thing
982017-12-20T01:25:07 <promag> current notifications are things that "happened" where what you want is to pub a computation (a heavy one?)
992017-12-20T01:25:17 <sipa> echeveria: you're saying to compare with -blocknotify... but you can use GBT over RPC, and use ZMQ notifications too
1002017-12-20T01:25:30 <sipa> i would certainly advise against using -blocknotify
1012017-12-20T01:25:54 <echeveria> by 'seems to be a win' I meant the code is written and running.
1022017-12-20T01:25:55 <promag> right, that's why I said to use pubhashblock
1032017-12-20T01:28:44 *** sploot has joined #bitcoin-core-dev
1042017-12-20T01:29:33 <promag> echeveria: even if that was possible, you should keep the gbt thru rpc. don't rely only in zmq notifications.
1052017-12-20T01:30:09 <promag> for intance, with rpc you get errors
1062017-12-20T01:30:42 <echeveria> not seeing a scheduled ZMQ frame is also an error.
1072017-12-20T01:31:00 <sipa> ZMQ is unreliable
1082017-12-20T01:31:16 *** zshlyk has quit IRC
1092017-12-20T01:31:48 <promag> I'm not talking about that errors, for instance, if the node crash, you will be sitting there waiting for notifications...
1102017-12-20T01:32:41 *** zshlyk has joined #bitcoin-core-dev
1112017-12-20T01:32:58 *** some_ has joined #bitcoin-core-dev
1122017-12-20T01:33:40 <promag> with RPC you can measure the request duration, trigger something if above a certain value, etc it's much more expressive than zmq notifications
1132017-12-20T01:35:01 <promag> zmq notifications are cool to avoid polling or the nasty process spawn, but then use the existing interface
1142017-12-20T01:35:14 <promag> the roundtrip should not be a problem imo
1152017-12-20T01:39:40 *** Chris_Stewart_5 has joined #bitcoin-core-dev
1162017-12-20T01:40:12 *** some_ has quit IRC
1172017-12-20T01:43:46 *** rockhouse has quit IRC
1182017-12-20T01:44:06 *** rockhouse has joined #bitcoin-core-dev
1192017-12-20T01:44:23 <morcos> gmaxwell: what is the issue with expired transactions keeping the relay fee from going up? why do you want the relay fee to go up and how will it go up faster with your idea?
1202017-12-20T01:44:44 *** zshlyk has quit IRC
1212017-12-20T01:45:27 <morcos> at first glance it doesn't make much sense to me. for instance i just today placed some transactions that were 120 sat/byte. i'm assuming they'll get confirmed over christmas weekend. the whole point of longer estimates is people might be able to wait for the weekly cycle so the mempool should be big enough to handle that
1222017-12-20T01:45:57 <echeveria> promag: not receiving a scheduled message, or missing a sequence number clearly indicates that.
1232017-12-20T01:45:57 <morcos> on top of that, i think you want to be able to do CPFP and its nice to have the stuck transactions still in mempools
1242017-12-20T01:46:01 <gmaxwell> morcos: relay fee now appears to be unrealistically low. e.g. we're regularly wasting bandwidth on transactions that are not going to confirm before they expire.
1252017-12-20T01:46:36 <morcos> gmaxwell: ahh.. i think thats ok.
1262017-12-20T01:46:51 <promag> echeveria: not receiving a scheduled message - you mean you timeout when no notification arrives?
1272017-12-20T01:46:53 <gmaxwell> what I'm suggesting is that the only way transactions that aren't making it to the top of your mempool would expire is if they're evicted due to low fee. So they'd be there for CPFPing.
1282017-12-20T01:47:02 *** zshlyk has joined #bitcoin-core-dev
1292017-12-20T01:47:07 <echeveria> promag: yes.
1302017-12-20T01:47:33 <morcos> hopefully we wrote it up in the PR that did mempool limiting, but we were aware of that issue, but the amount of free relay that can be achieved that way is limited (and is not that much)
1312017-12-20T01:48:42 <morcos> gmaxwell: i'm confused. i thought you wanted to expire/evict/remove them if they haven't been in the top 4M weight for 48 hours?
1322017-12-20T01:48:52 <morcos> oh but then you want to make that the mempool min fee?
1332017-12-20T01:49:30 <gmaxwell> no, the other way around. I want to have a counter on each txn that counts roughly how long it's been in the top 4MB weight, and only expires once that goes over 48 hours.
1342017-12-20T01:49:39 <promag> echeveria: not the best approach though, worst case you would be 10min until you do something
1352017-12-20T01:49:46 <gmaxwell> because if it's in the top 4mb and not getting mined, then it's been softforked out.
1362017-12-20T01:49:48 <echeveria> promag: 5 seconds.
1372017-12-20T01:49:51 <morcos> ohhhh
1382017-12-20T01:50:18 <morcos> wow i misunderstood, ok, so you want to get rid of expiration, but need to solve for the unminable txs
1392017-12-20T01:50:22 <morcos> yeah that makes way more sense
1402017-12-20T01:50:26 <promag> you mean you gbt each 5 seconds?
1412017-12-20T01:50:35 <echeveria> yes.
1422017-12-20T01:50:49 <promag> so why do you need zmq?
1432017-12-20T01:50:53 <echeveria> this is not unexpected, ckpool does GBT every 100ms in some modes.
1442017-12-20T01:50:59 <gmaxwell> morcos: yes, I want to get rid of expiration but don't want the risk of your mempool getting filled up with high fee unminable coins.
1452017-12-20T01:51:28 <echeveria> promag: please try and consider what you're arguing. it's clearly ludicrous to poll GBT RPC every 5 seconds, the amount of work wasted would be colossal.
1462017-12-20T01:51:37 <gmaxwell> also for unmineable tx, two weeks is a horrific amount of time to keep them around anyways...
1472017-12-20T01:51:54 <echeveria> promag: pushing GBT on UpdateTip, and every 5 seconds is clearly different.
1482017-12-20T01:52:17 <promag> how is that less work?
1492017-12-20T01:52:41 <echeveria> there's no round trips, and I'm not sequestering cs_main every 100ms.
1502017-12-20T01:53:07 <promag> every 100ms or 5s?
1512017-12-20T01:53:21 <morcos> gmaxwell: it's an intersting idea, but i'm not sure how large the problem is that you're trying to address. at least with mempool expiration there is a cumbersome mechanism to replace a non-RBF tx
1522017-12-20T01:53:23 <echeveria> > ckpool does GBT every 100ms in some modes.
1532017-12-20T01:53:44 <promag> so in those modes with zmq there would be a zmq notification each 100ms?
1542017-12-20T01:54:14 <promag> I mean, even to pub the notification you have to acquire cs_main like gbt
1552017-12-20T01:54:29 <echeveria> ( poll RPC every 100ms | ZMQ on UpdateTip + every 5 seconds) two different things.
1562017-12-20T01:54:39 <morcos> without expiration, then you kind of have to hope it gets evicted, and then you have nodes with larger mempools actually having a worse picture of things b/c they dont' accept the replacement
1572017-12-20T01:54:47 <morcos> would make more sense in a full-rbf world
1582017-12-20T01:55:25 <gmaxwell> morcos: I'm not sure yet if 1s/vb is a feerate that will never confirm... but I do think we don't want minifee to be frequently below the never-confirm rate.
1592017-12-20T01:55:28 <aj> could just continue to expire non-rbf txes after a week?
1602017-12-20T01:56:38 <morcos> gmaxwell: i agree with that, except what we really want is the incremental rate to not be below that.. not just the mempool min fee, where the incremental rate is the floor for minrelay
1612017-12-20T01:56:53 <morcos> and the bump requirement for RBF and mempool min fee after eviction
1622017-12-20T01:56:56 <gmaxwell> Speaking of RBF, I've been thinking some of the the RBF pinning problem, and think we could solve it by having a flag set on a transaction that an unconfirmed spend of its outputs is only allowed in the mempool the resulting package feerate would be near-confirmation.
1632017-12-20T01:57:17 <morcos> so perhaps we want a way to set incremental fee... but i'm just not sure yet how to do that
1642017-12-20T01:58:16 <aj> gmaxwell: noticing you're seeing unmined transactions that you think seem valid might be a useful warning indicator of weird things going on (eg, it might mean your fee estimation is being based on bad data?)
1652017-12-20T01:58:17 <gmaxwell> RBF-pinning for those who don't know what I'm referring to is the issue where you make a moderate fee RBF payment with an intention of bidding up the RBF over the next couple days until it confirms... but then one of your payees manages their input-clutter by immediately creating a very low feerate 100kb transaction that aggregates up all their small inputs.
1662017-12-20T01:58:37 <morcos> i know people hate defaults... but arguably the best thing to do is just change the default incremental relay rate
1672017-12-20T01:59:57 <gmaxwell> The RBF pinning problem is then that the RBFer above can't RBF their transaction unless they also pay the incremental rate for the 100kb child.
1682017-12-20T01:59:59 <morcos> aj: yes, i wrote a MPAM (miner policy alignment meter) for Core, but Peter Todd had some esoteric complaints about it and i forgot it.. i forget a lot of things though
1692017-12-20T02:00:02 <gmaxwell> Which is quite expensive!
1702017-12-20T02:01:13 <promag> echeveria: right, but you can do that now
1712017-12-20T02:02:03 <gmaxwell> a user of ours who hit rbf-pinning hard was trying to suggest that we prohibit all spends of unconfirmed outputs, which is nuts... but perhaps something to opt-in where the outputs could only be spent by txn that would bump the feerate to near confirmation.. everyone could still CPFP... but no more major pinning problem.
1722017-12-20T02:02:53 *** CubicEarth has joined #bitcoin-core-dev
1732017-12-20T02:03:25 <morcos> i think we need segfee for segregating the fee out of txid, so you can increase it without invalidating descendants
1742017-12-20T02:04:16 <aj> morcos: isn't that CPFP?
1752017-12-20T02:04:18 <gmaxwell> yea... I've thought abot that.
1762017-12-20T02:04:31 <gmaxwell> CPFP is inherently not that efficient.
1772017-12-20T02:05:05 <morcos> gmaxwell: one somewhat smart suggestion on those lines would be to have an online mode for Core where if the wallet expects to remain online, it doesn't bother broadcasting lower fee txs until later (but then i guess you'd stil have to resign if the parent changed)
1782017-12-20T02:05:17 <aj> gmaxwell: is this where you point to a wiki page from five years ago explaining how to do it efficiently?
1792017-12-20T02:05:38 <gmaxwell> morcos: yep, made the same observation myself, but it reuires the second party to be helpful at their own very slight expense.
1802017-12-20T02:07:41 <phantomcircuit> wait there's no way to trigger wallet rescan unless the private key is actually new
1812017-12-20T02:07:43 <phantomcircuit> lol
1822017-12-20T02:08:12 <morcos> i probably shouldn't be spitting out my stupid ideas here without thinking on them first, but we could imagine a more efficient CPFP via some softfork mechanism, where a future tx (without needing to spend prior txs outputs could pay for them)
1832017-12-20T02:08:33 <morcos> you could reduce the cost so barely over 32 bytes on the paying tx and could include as many paid for txs as you wanted
1842017-12-20T02:09:21 *** Randolf has quit IRC
1852017-12-20T02:09:44 <morcos> which you broadcast in an extended tx format potentially, but hmmm... how do you know which ones go with it in the block perhaps by required ordering and then just the number of txs
1862017-12-20T02:09:51 <morcos> getting complicated and messy
1872017-12-20T02:10:43 <gmaxwell> Well these sighash no input things wouldn't invalidate the child but they are phenominally dangerous and we really wouldn't want to encourage their use outside of specialized cases.
1882017-12-20T02:10:51 <gmaxwell> (they have no replay protection of any form at all...)
1892017-12-20T02:11:15 *** belcher has quit IRC
1902017-12-20T02:11:43 <aj> having the 100kB RBF-pinning tx use SIGHASH_NOINPUT could be made to work okay afaics
1912017-12-20T02:11:46 <aj> but augh
1922017-12-20T02:12:26 *** zshlyk has quit IRC
1932017-12-20T02:13:13 *** zshlyk has joined #bitcoin-core-dev
1942017-12-20T02:15:17 *** sploot has quit IRC
1952017-12-20T02:17:24 <echeveria> promag: yes I can, because I've written the patch.
1962017-12-20T02:19:00 <promag> echeveria: PR #?
1972017-12-20T02:19:08 <gmaxwell> aj: yes except you really can't safely do that, because the payer needs to know to be sure to NEVER pay to that pubkey again.
1982017-12-20T02:24:57 *** CubicEarth has quit IRC
1992017-12-20T02:43:29 *** sanjeev has quit IRC
2002017-12-20T02:44:15 *** Aaronvan_ has joined #bitcoin-core-dev
2012017-12-20T02:46:50 *** AaronvanW has quit IRC
2022017-12-20T02:48:01 *** Aaronvan_ has quit IRC
2032017-12-20T02:58:46 *** promag has quit IRC
2042017-12-20T03:02:38 *** Giszmo has quit IRC
2052017-12-20T03:04:24 *** zshlyk has quit IRC
2062017-12-20T03:04:29 *** Murch has quit IRC
2072017-12-20T03:06:36 *** zshlyk has joined #bitcoin-core-dev
2082017-12-20T03:08:13 *** bob___ has joined #bitcoin-core-dev
2092017-12-20T03:08:45 <bob___> hello
2102017-12-20T03:08:54 *** ludo has joined #bitcoin-core-dev
2112017-12-20T03:09:17 *** ludo is now known as Guest49262
2122017-12-20T03:09:48 <Guest49262> Bonjour
2132017-12-20T03:09:51 <bob___> having an issue with bitcoin core changing the transaction fee to a lower amount?
2142017-12-20T03:10:06 <bob___> can anyone help?
2152017-12-20T03:11:05 *** Guest49262 has quit IRC
2162017-12-20T03:13:15 *** bob___ has quit IRC
2172017-12-20T03:15:00 *** kikooo has joined #bitcoin-core-dev
2182017-12-20T03:15:14 <kikooo> yop
2192017-12-20T03:15:56 *** kikooo has quit IRC
2202017-12-20T03:16:28 *** ghost43 has quit IRC
2212017-12-20T03:16:41 *** ghost43 has joined #bitcoin-core-dev
2222017-12-20T03:22:48 <meshcollider> bob___: try #bitcoin channel, this one is not for support
2232017-12-20T03:30:28 *** Cory has quit IRC
2242017-12-20T03:42:35 <adiabat> did I hear sighash_noinput? I love that stuff! :) (but yes, I understand that it's a serious foot-cannon)
2252017-12-20T03:57:29 *** atroxes has quit IRC
2262017-12-20T03:58:25 *** atroxes has joined #bitcoin-core-dev
2272017-12-20T03:58:35 *** qrestlove has quit IRC
2282017-12-20T03:58:35 *** Ge0rges has quit IRC
2292017-12-20T04:01:10 *** fanquake has quit IRC
2302017-12-20T04:02:01 *** qrestlove has joined #bitcoin-core-dev
2312017-12-20T04:03:04 *** qrestlove has quit IRC
2322017-12-20T04:03:38 *** qrestlove has joined #bitcoin-core-dev
2332017-12-20T04:03:49 *** fanquake has joined #bitcoin-core-dev
2342017-12-20T04:04:20 *** zshlyk has quit IRC
2352017-12-20T04:05:32 *** zshlyk has joined #bitcoin-core-dev
2362017-12-20T04:09:23 *** larafale has joined #bitcoin-core-dev
2372017-12-20T04:10:45 *** jb55 has quit IRC
2382017-12-20T04:11:16 *** Ge0rges has joined #bitcoin-core-dev
2392017-12-20T04:11:52 *** qrestlove has quit IRC
2402017-12-20T04:12:17 *** Chris_Stewart_5 has quit IRC
2412017-12-20T04:13:27 *** larafale has quit IRC
2422017-12-20T04:15:06 *** qrestlove has joined #bitcoin-core-dev
2432017-12-20T04:18:17 *** zshlyk has quit IRC
2442017-12-20T04:19:13 *** zshlyk has joined #bitcoin-core-dev
2452017-12-20T04:24:43 *** Randolf has joined #bitcoin-core-dev
2462017-12-20T04:33:27 *** jtimon has quit IRC
2472017-12-20T04:33:58 *** lesderid has quit IRC
2482017-12-20T04:35:13 *** lesderid has joined #bitcoin-core-dev
2492017-12-20T04:35:23 *** savin has joined #bitcoin-core-dev
2502017-12-20T04:39:15 *** savin has quit IRC
2512017-12-20T04:42:32 *** jb55 has joined #bitcoin-core-dev
2522017-12-20T05:03:27 *** Ge0rges has quit IRC
2532017-12-20T05:05:27 *** qrestlove has quit IRC
2542017-12-20T05:11:20 *** Ge0rges has joined #bitcoin-core-dev
2552017-12-20T05:11:45 *** BashCo has quit IRC
2562017-12-20T05:16:54 *** qrestlove has joined #bitcoin-core-dev
2572017-12-20T05:19:25 *** zshlyk has quit IRC
2582017-12-20T05:20:17 *** zshlyk has joined #bitcoin-core-dev
2592017-12-20T05:24:15 *** dgenr8 has quit IRC
2602017-12-20T05:26:22 *** basho has joined #bitcoin-core-dev
2612017-12-20T05:26:26 *** zshlyk has quit IRC
2622017-12-20T05:27:14 *** basho has quit IRC
2632017-12-20T05:27:14 *** zshlyk has joined #bitcoin-core-dev
2642017-12-20T05:46:08 *** luke-jr has quit IRC
2652017-12-20T05:46:16 *** luke-jr has joined #bitcoin-core-dev
2662017-12-20T05:49:06 *** Victorsueca has quit IRC
2672017-12-20T05:50:16 *** Victorsueca has joined #bitcoin-core-dev
2682017-12-20T05:52:42 *** Cory has joined #bitcoin-core-dev
2692017-12-20T05:57:38 *** meshcollider has quit IRC
2702017-12-20T06:11:06 *** zshlyk has quit IRC
2712017-12-20T06:11:11 *** yoctopede has joined #bitcoin-core-dev
2722017-12-20T06:12:17 *** yoctopede has quit IRC
2732017-12-20T06:13:35 *** yoctopede has joined #bitcoin-core-dev
2742017-12-20T06:16:31 *** BashCo has joined #bitcoin-core-dev
2752017-12-20T06:23:31 *** anditto has joined #bitcoin-core-dev
2762017-12-20T06:27:10 *** kraeftig has joined #bitcoin-core-dev
2772017-12-20T06:38:10 *** anditto has quit IRC
2782017-12-20T06:38:39 *** anditto has joined #bitcoin-core-dev
2792017-12-20T06:39:11 *** Murch has joined #bitcoin-core-dev
2802017-12-20T06:41:25 *** alfa has joined #bitcoin-core-dev
2812017-12-20T06:43:42 *** anditto has quit IRC
2822017-12-20T06:46:45 *** StopAndDecrypt has joined #bitcoin-core-dev
2832017-12-20T06:50:15 *** anditto has joined #bitcoin-core-dev
2842017-12-20T06:54:31 *** anditto has quit IRC
2852017-12-20T06:58:07 *** anditto has joined #bitcoin-core-dev
2862017-12-20T06:59:04 *** SopaXorzTaker has joined #bitcoin-core-dev
2872017-12-20T07:01:54 <fanquake> If everyone could refrain from being part of a secret society that'd be great.
2882017-12-20T07:02:43 *** mrannanay has joined #bitcoin-core-dev
2892017-12-20T07:09:18 *** yoctopede has quit IRC
2902017-12-20T07:09:40 *** Cogito_Ergo_Sum has joined #bitcoin-core-dev
2912017-12-20T07:10:13 *** yoctopede has joined #bitcoin-core-dev
2922017-12-20T07:10:16 <bitcoin-git> [bitcoin] fockkboy opened pull request #11958: Update README.md to let people know about (((Bilderberg))) and HIGH FEES! (master...master) https://github.com/bitcoin/bitcoin/pull/11958
2932017-12-20T07:10:50 <bitcoin-git> [bitcoin] fanquake closed pull request #11958: Update README.md to let people know about (((Bilderberg))) and HIGH FEES! (master...master) https://github.com/bitcoin/bitcoin/pull/11958
2942017-12-20T07:11:15 <wumpus> sorry MJ12 doesn't take kindly on people trying to quit
2952017-12-20T07:11:58 <phantomcircuit> is there a reason there isn't a wallet rescan rpc separate from the import* functions?
2962017-12-20T07:12:32 <gmaxwell> phantomcircuit: you haven't submitted yet. Bonus points if you make it handle multiwallet sanely (not scanning them one at a fking time!)
2972017-12-20T07:12:50 <fanquake> wumpus :o
2982017-12-20T07:12:53 <gmaxwell> double bonus if it lets you specify a blinking range (code from importmulti, I guess)
2992017-12-20T07:15:16 <wumpus> phantomcircuit: the reasoning behind that was always that it was unnecessary, because import should let you provide the key birthdates and thus it can determine what to scan for itself
3002017-12-20T07:15:38 <wumpus> phantomcircuit: if you need a loose rescan, something is usually wrong
3012017-12-20T07:15:49 <wumpus> phantomcircuit: so it's a diagnostic option for startup only
3022017-12-20T07:17:22 <phantomcircuit> yeah what's wrong is i used importprivkey with rescan false and the only way to fix it is to restart with -rescan but i dont want to restart
3032017-12-20T07:17:45 <sipa> phantomcircuit: you mean the rescanblockchain RPC? https://github.com/bitcoin/bitcoin/blob/master/src/wallet/rpcwallet.cpp#L3362
3042017-12-20T07:18:11 <gmaxwell> oh yea, that reasoning, I forgot about that.
3052017-12-20T07:18:19 <gmaxwell> crazy users rescanning for no reason. :(
3062017-12-20T07:18:54 <sipa> guys. we. have. an. RPC. for. that.
3072017-12-20T07:19:08 <phantomcircuit> oh
3082017-12-20T07:19:09 <phantomcircuit> neat
3092017-12-20T07:19:29 *** yoctopede has quit IRC
3102017-12-20T07:19:41 <gmaxwell> is it hidden?
3112017-12-20T07:19:49 <wumpus> ok. Please don't ask about existing RPCs, apparently I've lost track :-)
3122017-12-20T07:19:50 <gmaxwell> speaking of hidden... we have some things that should get unhidden.
3132017-12-20T07:20:00 <gmaxwell> The logging thing, in particular which is the best damn rpc ever.
3142017-12-20T07:20:13 <echeveria> logging?
3152017-12-20T07:20:17 <wumpus> no, it's not hidden
3162017-12-20T07:20:21 <sipa> what about the increasebalance RPC? i think that one's pretty neat too
3172017-12-20T07:20:30 <wumpus> the only hidden one is 'resendwallettransactions'
3182017-12-20T07:20:33 *** yoctopede has joined #bitcoin-core-dev
3192017-12-20T07:20:43 <wumpus> noooo sipa don't mention that one, it's only for secret society use
3202017-12-20T07:21:02 <eck> gentlemen save this for the bilderberg meeting, please
3212017-12-20T07:21:07 <gmaxwell> echeveria: there is an RPC to set the amount of logging detail.
3222017-12-20T07:21:13 <fanquake> Too late now. Trending on Reddit asap.
3232017-12-20T07:21:37 <gmaxwell> echeveria: which means you can shut off the chatty as heck leveldb stuff when it irritates you without restarting. :P
3242017-12-20T07:22:05 <echeveria> gmaxwell: thatâs handy, my node takes a very long time to restart, and restarting tends to absolve problems Iâd like to debug with -debug=net.
3252017-12-20T07:22:34 <Sentineo> the syntax is pretty easy, just do not forget to escape the " :)
3262017-12-20T07:22:48 <wumpus> logging was unhidden in #11626
3272017-12-20T07:22:49 <gribble> https://github.com/bitcoin/bitcoin/issues/11626 | rpc: Make `logging` RPC public by laanwj · Pull Request #11626 · bitcoin/bitcoin · GitHub
3282017-12-20T07:22:50 <gmaxwell> blocksonly is also hidden. though I think the rational for hiding it has not been addressed. :(
3292017-12-20T07:22:55 <gmaxwell> woot.
3302017-12-20T07:23:15 <Sentineo> yep 15.1 has it in help
3312017-12-20T07:23:19 <echeveria> very, very large mempools take an extraordinary time to load (I understand why).
3322017-12-20T07:23:26 <gmaxwell> I'm sorry I've been on github less lately.
3332017-12-20T07:23:38 <gmaxwell> echeveria: huh? what are you talking about
3342017-12-20T07:23:46 <Sentineo> echeveria: my node when restarted fails to import the mempool saved anyway
3352017-12-20T07:23:48 <gmaxwell> echeveria: mempool restore is entirely non-invasive and in the background.
3362017-12-20T07:24:25 *** qrestlove has quit IRC
3372017-12-20T07:24:45 <echeveria> gmaxwell: yes, itâs very much not a problem, itâs just a reason that changing the debug level is a great feature to have.
3382017-12-20T07:25:16 *** Amuza has joined #bitcoin-core-dev
3392017-12-20T07:25:21 <echeveria> if I want to debug=mempoolrej it needs to have the mempool.dat loaded :)
3402017-12-20T07:26:00 <Sentineo> having other stuff like turning on rpc/rest on the fly would be neat
3412017-12-20T07:27:16 <gmaxwell> Sentineo: gonna use the rpc to turn on RPC?
3422017-12-20T07:27:46 <Sentineo> did not put much thought into it apearantly gmaxwell :P
3432017-12-20T07:27:46 *** qrestlove has joined #bitcoin-core-dev
3442017-12-20T07:27:55 <wumpus> hahahahah yes that would be really neat
3452017-12-20T07:28:11 <Sentineo> but yeh, that would be really neat :D
3462017-12-20T07:28:46 <wumpus> non-causal RPC switching, powered by flux capacitor
3472017-12-20T07:28:52 *** qrestlove has quit IRC
3482017-12-20T07:29:25 *** qrestlove has joined #bitcoin-core-dev
3492017-12-20T07:29:26 <Sentineo> the switch could be called "Delorien" :)
3502017-12-20T07:30:05 <Sentineo> delorean - sorry .. typo
3512017-12-20T07:30:36 <fanquake> gmaxwell if you're going to be on GH again soon, you might be interested in #11359 or 11630
3522017-12-20T07:30:38 <gribble> https://github.com/bitcoin/bitcoin/issues/11359 | Add a pruning high water mark to reduce the frequency of pruning events by esotericnonsense · Pull Request #11359 · bitcoin/bitcoin · GitHub
3532017-12-20T07:31:42 *** timothy has joined #bitcoin-core-dev
3542017-12-20T07:31:47 <gmaxwell> I know, you could send messages via signals and morse code, killall -30 bitcoind ; sleep 1 ; killall -30 bitcoind ....
3552017-12-20T07:32:05 <gmaxwell> fanquake: OK.
3562017-12-20T07:32:15 *** blackbaba has joined #bitcoin-core-dev
3572017-12-20T07:32:37 <wumpus> ah yes the rumored kill -SHORTBEEP -LONGBEEP
3582017-12-20T07:32:44 <gmaxwell> half the reason I haven't been as active is that in the evening I'm using a computer without GH credentials on it, ... which ranks pretty highly for stupid reasons...
3592017-12-20T07:34:45 <wumpus> I understand trying to be careful with your gh credentials, but there's got to be a better way
3602017-12-20T07:36:22 <eck> perhaps called an ssh key
3612017-12-20T07:37:29 <phantomcircuit> eck, cant login to their website with ssh keys sir
3622017-12-20T07:37:39 <eck> i'll concede that point
3632017-12-20T07:37:46 <fanquake> wumpus does everyone inside the bitcoin org have 2FA turned on?
3642017-12-20T07:37:54 <echeveria> phantomcircuit: thatâs what x forwarding is for.
3652017-12-20T07:38:08 <wumpus> fanquake: let's check, it was the case last ime I looked
3662017-12-20T07:38:15 <gmaxwell> this is my only host that I haven't been able to strip intel ME off of, so I'm generally trying to keep security critical things of it.
3672017-12-20T07:39:00 <wumpus> I have no intel devices left
3682017-12-20T07:39:49 <eck> what year is it from
3692017-12-20T07:40:29 <eck> i went through this exercise recently, only to learn that i am pretty much sol if i have any devices made in the last ten years
3702017-12-20T07:40:41 <wumpus> I hope I can get rid of the AMD ones too before a similar backdoor in AMD to show up
3712017-12-20T07:41:17 <Sentineo> what backdoor?
3722017-12-20T07:42:20 <wumpus> but intel's reaction to the whole ME debacle - instead of offering the option to disable it, try to make it even more difficult to disable it - was enough to dump them completely
3732017-12-20T07:42:53 <eck> too bad there are no credible aarch64 systems
3742017-12-20T07:43:25 <Sentineo> so I need to use abacus!
3752017-12-20T07:43:43 <wumpus> yes it's why I'm using AMD for the moment, waiting for ARM and eventually RISCV
3762017-12-20T07:43:51 <gmaxwell> eck: it's pretty easy to lobotomize ME out of most moderately new systems, thanks to MEcleaner
3772017-12-20T07:44:21 <gmaxwell> wumpus: I dunno if you saw, but the next gen of intel cpus will contain efuse based downgrade resistance for the me firmware.
3782017-12-20T07:44:56 <eck> i don't know much about mecleaner, but this doesn't help me use e.g. coreboot, does it?
3792017-12-20T07:45:05 <phantomcircuit> well that's just blatantly admitting it's a backdoor
3802017-12-20T07:45:09 <eck> that's the project i was looking at most recently
3812017-12-20T07:45:20 <gmaxwell> right now you can reflash with a spi programmer to downgrade me firmware (e.g. to undo a possible upgrade that disables the HAP bit) since the cpu has no external truth on what ME firmware is the most recent.
3822017-12-20T07:45:20 <wumpus> gmaxwell: yes I heard, that's what maded me so angry
3832017-12-20T07:45:44 <wumpus> why not give your customers the choice?
3842017-12-20T07:45:51 <gmaxwell> eck: coreboot alone isn't enough, e.g. you can run coreboot on a lenovo x230 but unless you run mecleaner it has the hidden second operating system still.
3852017-12-20T07:46:25 <eck> i have more recent hardware but since that is news to me, i'll take a second look anyway, thanks
3862017-12-20T07:47:16 <gmaxwell> coreboot is nice, but not as important as getting rid of ME. other than some ACPI handling stuff the bios is out of the picture once the OS is running.
3872017-12-20T07:47:42 <gmaxwell> ME = whole seperate quasi-pentium cpu that runs all the time in the background (even with computer suspended) and has access to everything.
3882017-12-20T07:48:09 <gmaxwell> separate meaning still inside the cpu package, however.
3892017-12-20T07:48:22 <eck> the whole point of coreboot from my pov is to know for sure that IME is disabled
3902017-12-20T07:48:41 <eck> otherwise how would you be sure?
3912017-12-20T07:48:50 *** anditto has quit IRC
3922017-12-20T07:49:03 <gmaxwell> eck: because you physically rewrote the flash chip and took most of the me data out of it.
3932017-12-20T07:49:10 <gmaxwell> which is what me cleaner does.
3942017-12-20T07:49:44 <gmaxwell> until me cleaner that wasn't possible for coreboot to disable ME on most hardware that had ME, the issue is on most of those systems the system will shut down after 30 minutes if ME doesn't boot.
3952017-12-20T07:50:00 <eck> i will have to read more about ME and coreboot and mecleaner to comment
3962017-12-20T07:50:12 <eck> what you said makes sense though
3972017-12-20T07:50:18 <gmaxwell> so the coreboot instructions basically have you avoid rewriting the ME partition so the computer will keep working.
3982017-12-20T07:50:20 <Sentineo> so what are the implications of not removing it for a noob? :)
3992017-12-20T07:51:00 <gmaxwell> Sentineo: maybe nothing, or maybe intel and anyone who controls them or compromised them or found bugs in their code has full backdoor access to the computers running it.
4002017-12-20T07:51:00 <wumpus> there's a parallel OS running on your CPU, running a fairly insecure software stack, network connected
4012017-12-20T07:51:17 <wumpus> -> you can work out the rest of the details
4022017-12-20T07:51:34 *** Murch has quit IRC
4032017-12-20T07:51:47 <Sentineo> yeah ...
4042017-12-20T07:51:57 <wumpus> oh yes it happens to have ring -infinite access over anything else your CPU might be doing, so any access controls in your OS mean nothing
4052017-12-20T07:52:00 <eck> the assumption here though is that the me requires external flash memory to run, since it's some bloated c/c++ program, right?
4062017-12-20T07:52:08 <Sentineo> so you were refering to arm ... e.g. running stuff on rasberry pi sounds more secure than? or I got it wrong?
4072017-12-20T07:52:42 <eck> what if the ME was coded directly into the silicon? or is that not likely due to its complexity?
4082017-12-20T07:52:46 <gmaxwell> eck: the flash on current motherboards is ~32 MB in size in total.
4092017-12-20T07:53:21 <fanquake> Good thing there isn't a torrent of bugs found in ME :)
4102017-12-20T07:53:23 <gmaxwell> eck: it's not so much of a mystery now, it runs minix. people how have jtag access to it.
4112017-12-20T07:53:38 <wumpus> Sentineo: RPI is a bad example because it also has a proprietary core glued to the CPU; but something like i.mx6 which can run blobless would be more secure, everything else the same
4122017-12-20T07:53:53 <gmaxwell> you can also run arbritary code on it now and bypass the code signing, at least if you can write to the flash.
4132017-12-20T07:54:14 <eck> wild
4142017-12-20T07:54:25 <eck> and it's all undocumented, right?
4152017-12-20T07:54:25 <gmaxwell> I don't think anyone has targeted it with a compiler yet, its instruction set is non-standard.
4162017-12-20T07:54:46 <gmaxwell> it's a 486 with some pentium features added and some legacy features dropped.
4172017-12-20T07:54:53 <gmaxwell> eck: right.
4182017-12-20T07:55:09 <gmaxwell> but with jtag access people can reverse engineer things.
4192017-12-20T07:55:10 <eck> wait can it access the host os memory
4202017-12-20T07:55:12 <Sentineo> ah insane
4212017-12-20T07:55:13 <eck> what memory mode is it in
4222017-12-20T07:55:50 <Sentineo> so doing dice for privkeys and paper wallet does not sound that a bad idea now :D
4232017-12-20T07:56:30 <eck> i wonder how you would synchronize between the me processor and ring 0/-1
4242017-12-20T07:56:35 <gmaxwell> eck: presumably you use some kind of IO functionality to access the host memory, it's not direct mapped to the host memory.
4252017-12-20T07:56:44 <wumpus> it would have been fairly ok if they just allowed reprogramming it, targetting it with custom software from now on, from now on, but no, they had to clamp down on it more
4262017-12-20T07:56:51 <gmaxwell> which probably also avoids having to make it cache cohearent.
4272017-12-20T07:57:37 <eck> not that i (or anyone else) is running such code, but if there was synchronization between the kernel and some ME processor, surely you could tell from timing
4282017-12-20T07:58:35 <eck> i've written a bunch of ptrace stuff, and from userspace it's pretty obvious when you're being traced due to the clock slowdowns
4292017-12-20T07:58:40 <wumpus> and then, you're going to measure every single memory operation to catch an ME backdoor in the act?
4302017-12-20T07:58:46 <gmaxwell> heh
4312017-12-20T07:58:51 <eck> depends what the overhead is
4322017-12-20T07:59:21 <wumpus> I can't wait for such security theatre in operating systems </s>
4332017-12-20T07:59:25 <gmaxwell> of course the problem is that all it needs to do is snoop your network, which it might do for free, then when triggered push a single write into kernel memory to open up a backdoor.
4342017-12-20T08:00:10 <gmaxwell> and of course mystical power management on recent cpus makes timing kind of a mystery. :)
4352017-12-20T08:00:25 <eck> for sure
4362017-12-20T08:01:16 <wumpus> it's clearly not the solution, certainly not on long term, all those parameters would have to be figured out again for every new chip
4372017-12-20T08:01:25 <eck> on a numa system you can't even depend on time being coherent across threads on the same cpu, much less in the presence of a management engine
4382017-12-20T08:03:16 <wumpus> the ME will just be one of the many DMA streams going on
4392017-12-20T08:03:58 <eck> gmaxwell: curious if you had to deal with this kind of thing at all at xiph
4402017-12-20T08:04:16 <eck> one could easily imagine hardware to block certain content
4412017-12-20T08:04:42 <gmaxwell> intel does use ME in some windows DRM stuff, but that isn't a think that comes up for free codecs.
4422017-12-20T08:05:02 <phantomcircuit> gmaxwell, hdcp stuff?
4432017-12-20T08:05:26 <gmaxwell> no idea. I don't care because DRM and because windows. :P
4442017-12-20T08:06:10 <gmaxwell> apparently the SGX monotone counter stuff uses ME too, some presumably e.g. teechains is class broken now.
4452017-12-20T08:07:07 <wumpus> hdcp is specific to hdmi compression, but I'd assume it's used to create a 'trusted video path' (puke) between the video decoder and graphics/scanout
4462017-12-20T08:07:15 <wumpus> s/compression/encryption
4472017-12-20T08:07:51 <eck> clearly i have 0% of the knowledge in this space as you, but the adversarial attack i was thinking of would be fingerprinting decoding or *encoding* somehow, so you could figure out who decoded/encoded a video
4482017-12-20T08:08:09 <eck> although clearly that would be dependent on the encoder at least using hardware primitives
4492017-12-20T08:13:46 <wumpus> DRM is never about encoding, always about decoding
4502017-12-20T08:16:40 *** Kozuch has joined #bitcoin-core-dev
4512017-12-20T08:18:20 <wumpus> it's rooted in a world where every client is a consumer, and there's a few "premium" producers whose content has to be protected. But ok, this is getting off topic, sorry.
4522017-12-20T08:18:44 <fanquake> wumpus save it for twitter :p
4532017-12-20T08:19:21 <wumpus> :p
4542017-12-20T08:21:20 *** yoctopede has quit IRC
4552017-12-20T08:22:08 *** promag has joined #bitcoin-core-dev
4562017-12-20T08:22:45 *** yoctopede has joined #bitcoin-core-dev
4572017-12-20T08:23:27 *** Kozuch has quit IRC
4582017-12-20T08:28:10 *** promag has quit IRC
4592017-12-20T08:29:25 *** yoctopede has quit IRC
4602017-12-20T08:30:20 *** yoctopede has joined #bitcoin-core-dev
4612017-12-20T08:31:05 *** qrestlove has quit IRC
4622017-12-20T08:38:00 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/18a1bbad98bd...cfd99ddc3c19
4632017-12-20T08:38:00 <bitcoin-git> bitcoin/master be9a13c MeshCollider: Add configuration/argument testing
4642017-12-20T08:38:01 <bitcoin-git> bitcoin/master cfd99dd Wladimir J. van der Laan: Merge #11883: Add configuration file/argument testing...
4652017-12-20T08:38:35 <bitcoin-git> [bitcoin] laanwj closed pull request #11883: Add configuration file/argument testing (master...201712_datadir_tests) https://github.com/bitcoin/bitcoin/pull/11883
4662017-12-20T08:39:00 <bitcoin-git> [bitcoin] laanwj closed pull request #11482: Use CPrivKey typedef for keydata in CKey (master...patch-3) https://github.com/bitcoin/bitcoin/pull/11482
4672017-12-20T08:43:52 *** qrestlove has joined #bitcoin-core-dev
4682017-12-20T08:50:24 *** laurentmt has joined #bitcoin-core-dev
4692017-12-20T08:54:56 *** Ylbam has joined #bitcoin-core-dev
4702017-12-20T09:00:33 *** yoctopede is now known as intcat
4712017-12-20T09:01:53 *** danib31 has quit IRC
4722017-12-20T09:02:05 *** danib31 has joined #bitcoin-core-dev
4732017-12-20T09:09:20 *** intcat has quit IRC
4742017-12-20T09:11:16 *** intcat has joined #bitcoin-core-dev
4752017-12-20T09:26:38 *** Kozuch has joined #bitcoin-core-dev
4762017-12-20T09:26:41 *** Victorsueca has quit IRC
4772017-12-20T09:26:57 *** jb55 has quit IRC
4782017-12-20T09:28:01 *** Victorsueca has joined #bitcoin-core-dev
4792017-12-20T09:31:11 *** alfa has quit IRC
4802017-12-20T09:35:24 *** SopaXorzTaker has quit IRC
4812017-12-20T09:37:22 *** SopaXorzTaker has joined #bitcoin-core-dev
4822017-12-20T09:38:48 *** blackbaba has quit IRC
4832017-12-20T09:42:05 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/cfd99ddc3c19...1fb34e0d1f58
4842017-12-20T09:42:05 <bitcoin-git> bitcoin/master 62e7c04 Matt Corallo: Remove dead feeest-file read code for old versions...
4852017-12-20T09:42:06 <bitcoin-git> bitcoin/master 1fb34e0 Wladimir J. van der Laan: Merge #11951: Remove dead feeest-file read code for old versions...
4862017-12-20T09:42:34 <bitcoin-git> [bitcoin] laanwj closed pull request #11951: Remove dead feeest-file read code for old versions (master...2017-12-dead-feeest-load) https://github.com/bitcoin/bitcoin/pull/11951
4872017-12-20T09:42:55 <sipa> feeest sounds like a really big party in dutch
4882017-12-20T09:43:34 <kallewoof> Haha, same in swedish.
4892017-12-20T09:43:55 <wumpus> yes I also wondered when I first saw that PR title why it was such a big celebration :)
4902017-12-20T09:45:27 <wumpus> although the 'dead' before it makes it a bit of a mixed feeling
4912017-12-20T09:48:21 <kallewoof> Maybe like the Bon festival in Japan (honor the spirits of one's ancestors).
4922017-12-20T09:53:37 <sipa> that even sounds good in French
4932017-12-20T09:55:04 *** dabura667 has quit IRC
4942017-12-20T09:55:13 <wumpus> heh
4952017-12-20T09:59:13 *** promag has joined #bitcoin-core-dev
4962017-12-20T10:09:19 *** jing has joined #bitcoin-core-dev
4972017-12-20T10:14:45 *** go1111111 has quit IRC
4982017-12-20T10:15:30 *** go1111111 has joined #bitcoin-core-dev
4992017-12-20T10:16:39 *** larafale has joined #bitcoin-core-dev
5002017-12-20T10:23:02 *** AaronvanW has joined #bitcoin-core-dev
5012017-12-20T10:24:36 *** intcat has quit IRC
5022017-12-20T10:25:30 *** intcat has joined #bitcoin-core-dev
5032017-12-20T10:26:30 *** Aaronvan_ has joined #bitcoin-core-dev
5042017-12-20T10:29:26 *** intcat has quit IRC
5052017-12-20T10:29:45 *** AaronvanW has quit IRC
5062017-12-20T10:30:47 *** intcat has joined #bitcoin-core-dev
5072017-12-20T10:34:14 *** larafale has quit IRC
5082017-12-20T10:34:55 *** larafale has joined #bitcoin-core-dev
5092017-12-20T10:37:26 *** jing has quit IRC
5102017-12-20T10:38:06 *** Cory has quit IRC
5112017-12-20T10:38:57 *** larafale has quit IRC
5122017-12-20T10:51:14 *** promag has quit IRC
5132017-12-20T11:01:24 *** promag has joined #bitcoin-core-dev
5142017-12-20T11:02:31 *** intcat has quit IRC
5152017-12-20T11:02:59 *** intcat has joined #bitcoin-core-dev
5162017-12-20T11:08:00 *** Cory has joined #bitcoin-core-dev
5172017-12-20T11:15:46 *** intcat has quit IRC
5182017-12-20T11:16:37 *** larafale has joined #bitcoin-core-dev
5192017-12-20T11:17:05 *** intcat has joined #bitcoin-core-dev
5202017-12-20T11:21:06 *** dcousens has quit IRC
5212017-12-20T11:21:30 *** dcousens has joined #bitcoin-core-dev
5222017-12-20T11:23:36 *** promag has quit IRC
5232017-12-20T11:25:28 *** davec has quit IRC
5242017-12-20T11:28:58 *** preet has joined #bitcoin-core-dev
5252017-12-20T11:31:25 *** intcat has quit IRC
5262017-12-20T11:32:29 *** meshcollider has joined #bitcoin-core-dev
5272017-12-20T11:32:54 *** intcat has joined #bitcoin-core-dev
5282017-12-20T11:38:55 *** vicenteH has joined #bitcoin-core-dev
5292017-12-20T11:42:46 *** belcher has joined #bitcoin-core-dev
5302017-12-20T11:46:29 *** larafale has quit IRC
5312017-12-20T11:46:56 *** GoldenBear has quit IRC
5322017-12-20T11:47:08 *** larafale has joined #bitcoin-core-dev
5332017-12-20T11:50:00 *** GoldenBear has joined #bitcoin-core-dev
5342017-12-20T11:51:27 *** larafale has quit IRC
5352017-12-20T11:52:48 *** promag has joined #bitcoin-core-dev
5362017-12-20T11:53:10 *** davec has joined #bitcoin-core-dev
5372017-12-20T11:54:52 *** promag has quit IRC
5382017-12-20T11:58:33 *** promag has joined #bitcoin-core-dev
5392017-12-20T11:59:40 *** contrapumpkin has quit IRC
5402017-12-20T12:03:10 *** larafale has joined #bitcoin-core-dev
5412017-12-20T12:05:21 *** preet has quit IRC
5422017-12-20T12:05:26 *** larafale has quit IRC
5432017-12-20T12:06:05 *** larafale has joined #bitcoin-core-dev
5442017-12-20T12:10:27 *** larafale has quit IRC
5452017-12-20T12:14:17 *** Giszmo has joined #bitcoin-core-dev
5462017-12-20T12:27:22 *** intcat has quit IRC
5472017-12-20T12:28:44 *** intcat has joined #bitcoin-core-dev
5482017-12-20T12:31:54 *** Giszmo has quit IRC
5492017-12-20T12:37:48 *** promag has quit IRC
5502017-12-20T12:40:15 *** promag has joined #bitcoin-core-dev
5512017-12-20T12:42:47 *** promag has quit IRC
5522017-12-20T12:43:55 <bitcoin-git> [bitcoin] laudaa opened pull request #11960: [Doc] Fix link to installation script (master...master) https://github.com/bitcoin/bitcoin/pull/11960
5532017-12-20T12:48:01 <wumpus> can anyone please test #11945 on macosx
5542017-12-20T12:48:03 <gribble> https://github.com/bitcoin/bitcoin/issues/11945 | Improve BSD compatibility of contrib/install_db4.sh by laanwj · Pull Request #11945 · bitcoin/bitcoin · GitHub
5552017-12-20T12:48:36 <wumpus> we replaced the bdb4 patch with a newer one, to accomodate freebsd/openbsd's clang, so need to know if this still works ok for macosx
5562017-12-20T12:55:16 *** Cogito_Ergo_Sum2 has joined #bitcoin-core-dev
5572017-12-20T12:55:47 *** Cogito_Ergo_Sum has quit IRC
5582017-12-20T13:04:46 <provoostenator> wumpus: I'll try it now
5592017-12-20T13:06:26 <provoostenator> Any configure flags you need me to use?
5602017-12-20T13:06:29 *** dcousens has quit IRC
5612017-12-20T13:06:54 *** Victorsueca has quit IRC
5622017-12-20T13:07:30 <wumpus> I'm not sure; just following the osx build guide would be best
5632017-12-20T13:08:10 *** Victorsueca has joined #bitcoin-core-dev
5642017-12-20T13:12:03 *** Cogito_Ergo_Sum2 has quit IRC
5652017-12-20T13:12:25 *** Cogito_Ergo_Sum has joined #bitcoin-core-dev
5662017-12-20T13:12:25 *** Cogito_Ergo_Sum has joined #bitcoin-core-dev
5672017-12-20T13:12:26 *** contrapumpkin has joined #bitcoin-core-dev
5682017-12-20T13:15:27 *** Cogito_Ergo_Sum has quit IRC
5692017-12-20T13:15:43 *** Cogito_Ergo_Sum has joined #bitcoin-core-dev
5702017-12-20T13:16:44 <fanquake> wumpus I'm fairly certain it is ok, because the new patch does the same thing we do patch bd4 in depends.
5712017-12-20T13:17:09 <wumpus> fanquake: I've just tested on linux and gcc and it's ok at least
5722017-12-20T13:17:40 <fanquake> I'm just running though the basics on osx
5732017-12-20T13:17:48 <provoostenator> Related (?) question: does --with-incompatible-bdb still do something?
5742017-12-20T13:17:52 <wumpus> I should probably bite the bullet at some point and get it to work on freebsd
5752017-12-20T13:18:04 <wumpus> it's two lines of script or so...
5762017-12-20T13:18:15 <wumpus> provoostenator: yes, it makes the configure accept bdb 5+
5772017-12-20T13:18:45 <provoostenator> Ok, so I shoulnd't use that in this case I assume, because your changes relates to bdb 4?
5782017-12-20T13:19:02 <wumpus> it would be unnecessary but not do harm
5792017-12-20T13:19:34 <provoostenator> It actually wouldn't even do anything if you don't have berkeley-db5 installed?
5802017-12-20T13:19:37 *** Pavle has joined #bitcoin-core-dev
5812017-12-20T13:20:56 <wumpus> right, it just removes the bdb 4.8 version check, if you want to point it at a different bdb installation you can use LDFLAGS="-L${BDB_PREFIX}/lib/" CPPFLAGS="-I${BDB_PREFIX}/include/"
5822017-12-20T13:21:26 <provoostenator> Ok, TIL...
5832017-12-20T13:22:08 <wumpus> the use of with/enable in our build system is quite inconsistent
5842017-12-20T13:22:52 <provoostenator> Yes, I also found out that it happily continues if QR reader dependencies are missing, which could cause someone to not even know that feature exists.
5852017-12-20T13:23:00 <wumpus> from what I remember officially --with is for specifying dependencies, and enable for features
5862017-12-20T13:23:08 <fanquake> 11960 can go in.
5872017-12-20T13:23:18 <wumpus> fanquake: thanks
5882017-12-20T13:24:21 <wumpus> provoostenator: it's not considered a critical feature that you have to explicitly disable; it should print it in the summary though
5892017-12-20T13:24:26 <fanquake> wumpus are you only using clang on openbsd now?
5902017-12-20T13:25:03 <provoostenator> Yes, it does show in the summary.
5912017-12-20T13:25:07 <wumpus> fanquake: yes; I think from 6.2 on we should be encouraging people to just use the built-in clang CC=cc CXX=c++
5922017-12-20T13:26:22 <wumpus> fanquake: I haven't tried with any other compilers
5932017-12-20T13:29:21 <fanquake> wumpus Ok, that can be an update to the build instructions after 11945
5942017-12-20T13:29:53 <wumpus> fanquake: yes, could do that in the same PR, but I think it's somewhat orthogonal
5952017-12-20T13:29:58 *** Cogito_Ergo_Sum2 has joined #bitcoin-core-dev
5962017-12-20T13:30:21 *** Cogito_Ergo_Sum has quit IRC
5972017-12-20T13:30:24 *** intcat has quit IRC
5982017-12-20T13:30:28 <fanquake> It might also depend on what happens in 11921, so can wait for cory to comment there
5992017-12-20T13:31:45 *** intcat has joined #bitcoin-core-dev
6002017-12-20T13:31:49 *** larafale has joined #bitcoin-core-dev
6012017-12-20T13:36:06 <wumpus> I think 11921 is unncessary with 11945
6022017-12-20T13:37:50 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1fb34e0d1f58...4307062ee2c2
6032017-12-20T13:37:50 <bitcoin-git> bitcoin/master 3d3e58e laudaa: [Doc] Fix link to installation script
6042017-12-20T13:37:51 <bitcoin-git> bitcoin/master 4307062 Wladimir J. van der Laan: Merge #11960: [Doc] Fix link to installation script...
6052017-12-20T13:38:28 <bitcoin-git> [bitcoin] laanwj closed pull request #11960: [Doc] Fix link to installation script (master...master) https://github.com/bitcoin/bitcoin/pull/11960
6062017-12-20T13:39:53 <fanquake> wumpus Did you want to drop the gcc instructions as part of 11945 then? Might as well do the Clang switch in there.
6072017-12-20T13:40:15 <fanquake> clang feels like it's just tacked on the end at the moment heh
6082017-12-20T13:40:18 <wumpus> fanquake: I think we should keep the current doc, just add new instructions for version 6.2+
6092017-12-20T13:40:35 <wumpus> fanquake: people might still want to build for older openbsd, for now
6102017-12-20T13:40:57 <wumpus> not sure
6112017-12-20T13:41:29 <fanquake> I'm not even sure how many people are building on openbsd, given how often the instructions seem to be *broken*
6122017-12-20T13:41:43 <wumpus> great, I have it working on freebsd
6132017-12-20T13:41:59 <fanquake> found a new sha256 tool>
6142017-12-20T13:42:33 <wumpus> well it tends to get detected quite quickly when they're broken
6152017-12-20T13:42:45 <wumpus> bsd users don't tend to be so noisy otherwise
6162017-12-20T13:43:34 *** Cogito_Ergo_Sum2 has quit IRC
6172017-12-20T13:43:46 <fanquake> fair enough, add a 6.2+ section which is clang specific? That document is fairly short anyways.
6182017-12-20T13:43:53 *** Cogito_Ergo_Sum has joined #bitcoin-core-dev
6192017-12-20T13:43:53 *** Cogito_Ergo_Sum has joined #bitcoin-core-dev
6202017-12-20T13:44:13 <wumpus> yep
6212017-12-20T13:44:50 *** larafale has quit IRC
6222017-12-20T13:45:29 *** larafale has joined #bitcoin-core-dev
6232017-12-20T13:49:57 *** larafale has quit IRC
6242017-12-20T13:51:37 *** jtimon has joined #bitcoin-core-dev
6252017-12-20T13:52:39 *** Pavle has quit IRC
6262017-12-20T13:59:55 <Lauda> After running make check, where should the binaries be built?
6272017-12-20T13:59:56 <Lauda> I'm going through the build docs. After make check completed, I'm having trouble finding them
6282017-12-20T14:01:49 <wumpus> make builds the binaries in the build directory, which is where you invoke make. This will be src/bitcoin, src/qt/bitcoin-qt, src/test/test_bitcoin etc
6292017-12-20T14:02:02 *** intcat has quit IRC
6302017-12-20T14:03:16 *** intcat has joined #bitcoin-core-dev
6312017-12-20T14:05:01 *** alfa has joined #bitcoin-core-dev
6322017-12-20T14:05:30 *** promag has joined #bitcoin-core-dev
6332017-12-20T14:08:22 *** intcat has quit IRC
6342017-12-20T14:09:46 *** intcat has joined #bitcoin-core-dev
6352017-12-20T14:10:07 *** Chris_Stewart_5 has joined #bitcoin-core-dev
6362017-12-20T14:12:16 *** meshcollider has quit IRC
6372017-12-20T14:13:21 *** intcat has quit IRC
6382017-12-20T14:13:51 <Lauda> Does that also build bitcoind by default?
6392017-12-20T14:14:31 <wumpus> I'm not sure. 'make check' is to run the unit tests, which don't need bitcoind
6402017-12-20T14:14:42 *** intcat has joined #bitcoin-core-dev
6412017-12-20T14:15:19 <Lauda> Alright, I'll redo make. I also wonder why 'make check' was used in the build example for Arch Linux
6422017-12-20T14:15:21 <Lauda> and not just make?
6432017-12-20T14:15:38 <wumpus> because running the tests is always recommended
6442017-12-20T14:17:14 <wumpus> and maybe they assume 'make check' builds the non-tests too. I really don't know if that's the case or not.
6452017-12-20T14:18:45 <Lauda> Well, for ARM example only 'make' is used and in the Arch one 'make check'. Just got me wondering
6462017-12-20T14:19:07 *** Ylbam has quit IRC
6472017-12-20T14:23:52 <wumpus> ok
6482017-12-20T14:23:59 <provoostenator> Note to self: actually checkout the correct branch before running make...
6492017-12-20T14:31:36 <Lauda> https://i.imgur.com/A4g8Erm.png
6502017-12-20T14:31:36 <Lauda> I take it that this warning is not expected behavior?
6512017-12-20T14:35:17 *** Chris_Stewart_5 has quit IRC
6522017-12-20T14:37:32 <wumpus> I don't remember seeing it
6532017-12-20T14:38:14 <wumpus> it's something in leveldb though, likely part of some inline assembly they added
6542017-12-20T14:40:06 <Lauda> Alright, thanks
6552017-12-20T14:55:22 *** Victorsueca has quit IRC
6562017-12-20T14:56:31 *** Victorsueca has joined #bitcoin-core-dev
6572017-12-20T15:02:53 *** timothy has quit IRC
6582017-12-20T15:04:23 *** intcat has quit IRC
6592017-12-20T15:05:45 *** intcat has joined #bitcoin-core-dev
6602017-12-20T15:05:55 *** larafale has joined #bitcoin-core-dev
6612017-12-20T15:08:19 <jouke> Hmm, fee of a sendmany with a lot of outputs also gets maxed out to some hardcoded 0.1 btc?
6622017-12-20T15:11:11 *** Giszmo has joined #bitcoin-core-dev
6632017-12-20T15:13:11 <instagibbs> jouke, there's a maxtxfee setting
6642017-12-20T15:14:48 <jouke> instagibbs: thanks
6652017-12-20T15:15:33 <wumpus> but yes, all transactions are checked against that
6662017-12-20T15:19:33 *** Chris_Stewart_5 has joined #bitcoin-core-dev
6672017-12-20T15:21:24 *** AaronvanW has joined #bitcoin-core-dev
6682017-12-20T15:21:33 *** intcat has quit IRC
6692017-12-20T15:22:40 *** intcat has joined #bitcoin-core-dev
6702017-12-20T15:23:02 *** Aaronvan_ has quit IRC
6712017-12-20T15:24:11 *** fanquake has quit IRC
6722017-12-20T15:36:15 *** JK^ has joined #bitcoin-core-dev
6732017-12-20T15:36:58 *** BTC^ has quit IRC
6742017-12-20T15:42:19 *** larafale has quit IRC
6752017-12-20T15:42:51 *** pkx2 has joined #bitcoin-core-dev
6762017-12-20T15:45:54 *** goatpig has joined #bitcoin-core-dev
6772017-12-20T15:46:33 *** Guyver2 has joined #bitcoin-core-dev
6782017-12-20T15:47:20 *** goatpig has quit IRC
6792017-12-20T15:47:20 *** cireful has quit IRC
6802017-12-20T15:48:01 *** Guyver2_ has joined #bitcoin-core-dev
6812017-12-20T15:50:03 *** Guyver2_ has quit IRC
6822017-12-20T15:50:15 *** Guyver2_ has joined #bitcoin-core-dev
6832017-12-20T15:51:21 *** Guyver2 has quit IRC
6842017-12-20T15:51:28 *** Guyver2_ is now known as Guyver2
6852017-12-20T15:52:04 <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/4307062ee2c2...9ab9963386ed
6862017-12-20T15:52:05 <bitcoin-git> bitcoin/master 88411e9 MarcoFalke: Squashed 'src/univalue/' changes from fe805ea74f..07947ff2da...
6872017-12-20T15:52:05 <bitcoin-git> bitcoin/master fad349c MarcoFalke: univalue: Bump subtree
6882017-12-20T15:52:06 <bitcoin-git> bitcoin/master 9ab9963 Wladimir J. van der Laan: Merge #11952: [qa] univalue: Bump subtree...
6892017-12-20T15:52:39 <bitcoin-git> [bitcoin] laanwj closed pull request #11952: [qa] univalue: Bump subtree (master...Mf1712-univalueBump) https://github.com/bitcoin/bitcoin/pull/11952
6902017-12-20T15:53:47 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/9ab9963386ed...d4e404a3afa8
6912017-12-20T15:53:47 <bitcoin-git> bitcoin/master 2862b56 John Newbery: [tests] remove redundant univalue_tests.cpp
6922017-12-20T15:53:48 <bitcoin-git> bitcoin/master d4e404a Wladimir J. van der Laan: Merge #11879: [tests] remove redundant univalue_tests.cpp...
6932017-12-20T15:54:00 <bitcoin-git> [bitcoin] laanwj closed pull request #11879: [tests] remove redundant univalue_tests.cpp (master...remove_univalue_test) https://github.com/bitcoin/bitcoin/pull/11879
6942017-12-20T15:55:44 *** Amuza has quit IRC
6952017-12-20T15:56:48 *** Randolf has quit IRC
6962017-12-20T15:57:30 *** Randolf has joined #bitcoin-core-dev
6972017-12-20T15:58:40 *** larafale has joined #bitcoin-core-dev
6982017-12-20T16:02:05 *** goatpig has joined #bitcoin-core-dev
6992017-12-20T16:02:06 *** cireful has joined #bitcoin-core-dev
7002017-12-20T16:04:49 <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d4e404a3afa8...bc6676514429
7012017-12-20T16:04:50 <bitcoin-git> bitcoin/master f455a24 Sjors Provoost: [net] add seed.testnet.bitcoin.sprovoost.nl to testnet DNS seeds
7022017-12-20T16:04:50 <bitcoin-git> bitcoin/master bc66765 Wladimir J. van der Laan: Merge #11917: Add testnet DNS seed: seed.testnet.bitcoin.sprovoost.nl...
7032017-12-20T16:05:22 <bitcoin-git> [bitcoin] laanwj closed pull request #11917: Add testnet DNS seed: seed.testnet.bitcoin.sprovoost.nl (master...testnet-dns-seed-sjors) https://github.com/bitcoin/bitcoin/pull/11917
7042017-12-20T16:08:12 *** jamesob has joined #bitcoin-core-dev
7052017-12-20T16:08:45 *** owowo has quit IRC
7062017-12-20T16:08:59 *** jamesob has quit IRC
7072017-12-20T16:09:23 *** jamesob has joined #bitcoin-core-dev
7082017-12-20T16:12:03 <Lauda> wumpus was this the file that you were talking about? https://i.imgur.com/TP8jc18.png
7092017-12-20T16:14:00 <wumpus> well it's one of the generated executables
7102017-12-20T16:16:50 *** intcat has quit IRC
7112017-12-20T16:17:03 *** owowo has joined #bitcoin-core-dev
7122017-12-20T16:17:23 <Lauda> How does one compile executables for Windows on Unix as well?
7132017-12-20T16:17:55 <wumpus> https://github.com/bitcoin/bitcoin/blob/master/doc/build-windows.md
7142017-12-20T16:17:58 *** intcat has joined #bitcoin-core-dev
7152017-12-20T16:19:07 <Lauda> On it, thanks
7162017-12-20T16:20:02 *** Randolf has quit IRC
7172017-12-20T16:22:19 *** bsm117532 has quit IRC
7182017-12-20T16:23:07 *** intcat has quit IRC
7192017-12-20T16:23:15 *** Randolf has joined #bitcoin-core-dev
7202017-12-20T16:24:13 *** Murch has joined #bitcoin-core-dev
7212017-12-20T16:24:19 *** intcat has joined #bitcoin-core-dev
7222017-12-20T16:25:03 *** larafale has quit IRC
7232017-12-20T16:34:19 *** jamesob has quit IRC
7242017-12-20T16:36:37 *** dgenr8 has joined #bitcoin-core-dev
7252017-12-20T16:39:06 *** j has joined #bitcoin-core-dev
7262017-12-20T16:39:16 *** j has quit IRC
7272017-12-20T16:47:32 *** jb55 has joined #bitcoin-core-dev
7282017-12-20T16:49:15 *** larafale has joined #bitcoin-core-dev
7292017-12-20T16:51:04 *** Murch has quit IRC
7302017-12-20T16:51:04 *** Randolf has quit IRC
7312017-12-20T16:51:56 *** intcat has quit IRC
7322017-12-20T16:53:18 *** mrfrasha has joined #bitcoin-core-dev
7332017-12-20T16:54:48 *** intcat has joined #bitcoin-core-dev
7342017-12-20T16:56:13 *** StopAndDecrypt has quit IRC
7352017-12-20T16:57:55 *** StopAndDecrypt has joined #bitcoin-core-dev
7362017-12-20T17:00:25 *** propumpkin has joined #bitcoin-core-dev
7372017-12-20T17:01:05 *** contrapumpkin has quit IRC
7382017-12-20T17:01:10 <bitcoin-git> [bitcoin] laanwj pushed 8 new commits to master: https://github.com/bitcoin/bitcoin/compare/bc6676514429...79399c8cd0b6
7392017-12-20T17:01:11 <bitcoin-git> bitcoin/master a3603ac Jack Grigg: Fix potential overflows in ECDSA DER parsers
7402017-12-20T17:01:12 <bitcoin-git> bitcoin/master e181dbe Jack Grigg: Add comments
7412017-12-20T17:01:12 <bitcoin-git> bitcoin/master e4a1086 Jack Grigg: Update Debian copyright list
7422017-12-20T17:01:24 <bitcoin-git> [bitcoin] laanwj closed pull request #10657: Utils: Improvements to ECDSA key-handling code (master...libsecp256k1-patches) https://github.com/bitcoin/bitcoin/pull/10657
7432017-12-20T17:05:34 *** `bob has joined #bitcoin-core-dev
7442017-12-20T17:06:34 *** propumpkin is now known as contrapumpkin
7452017-12-20T17:09:57 *** intcat has quit IRC
7462017-12-20T17:11:01 *** intcat has joined #bitcoin-core-dev
7472017-12-20T17:12:03 *** larafale has quit IRC
7482017-12-20T17:12:39 *** larafale has joined #bitcoin-core-dev
7492017-12-20T17:13:24 *** larafale has joined #bitcoin-core-dev
7502017-12-20T17:14:14 *** larafale has joined #bitcoin-core-dev
7512017-12-20T17:14:59 *** larafale has joined #bitcoin-core-dev
7522017-12-20T17:15:27 *** Murch has joined #bitcoin-core-dev
7532017-12-20T17:15:44 *** larafale has joined #bitcoin-core-dev
7542017-12-20T17:16:44 *** larafale has joined #bitcoin-core-dev
7552017-12-20T17:17:25 *** larafale has joined #bitcoin-core-dev
7562017-12-20T17:18:09 *** larafale has joined #bitcoin-core-dev
7572017-12-20T17:18:59 *** larafale has joined #bitcoin-core-dev
7582017-12-20T17:19:12 *** larafale has quit IRC
7592017-12-20T17:19:44 *** larafale has joined #bitcoin-core-dev
7602017-12-20T17:20:34 *** larafale has joined #bitcoin-core-dev
7612017-12-20T17:21:20 *** larafale has joined #bitcoin-core-dev
7622017-12-20T17:21:37 *** larafale has quit IRC
7632017-12-20T17:22:12 *** larafale has joined #bitcoin-core-dev
7642017-12-20T17:23:27 *** StopAndDecrypt_ has joined #bitcoin-core-dev
7652017-12-20T17:23:31 *** StopAndDecrypt has quit IRC
7662017-12-20T17:24:13 *** larafale has joined #bitcoin-core-dev
7672017-12-20T17:25:59 *** Randolf has joined #bitcoin-core-dev
7682017-12-20T17:31:22 *** intcat has quit IRC
7692017-12-20T17:31:31 *** moctos has joined #bitcoin-core-dev
7702017-12-20T17:32:48 *** intcat has joined #bitcoin-core-dev
7712017-12-20T17:33:17 *** larafale has quit IRC
7722017-12-20T17:33:54 *** larafale has joined #bitcoin-core-dev
7732017-12-20T17:34:47 *** larafale has joined #bitcoin-core-dev
7742017-12-20T17:35:35 *** larafale has joined #bitcoin-core-dev
7752017-12-20T17:36:15 *** larafale has joined #bitcoin-core-dev
7762017-12-20T17:39:16 *** moctos has quit IRC
7772017-12-20T17:40:55 *** larafale has joined #bitcoin-core-dev
7782017-12-20T17:46:34 <Lauda> is RBF supposed to be rejected if you specify a custom change output?
7792017-12-20T17:53:06 <Lauda> i.e. from the same wallet
7802017-12-20T17:53:57 *** marcel_ has joined #bitcoin-core-dev
7812017-12-20T18:01:33 *** jb55 has quit IRC
7822017-12-20T18:05:11 *** ExtraCrispy has joined #bitcoin-core-dev
7832017-12-20T18:06:47 *** larafale has quit IRC
7842017-12-20T18:08:12 *** `bob has quit IRC
7852017-12-20T18:13:30 *** alcipir has joined #bitcoin-core-dev
7862017-12-20T18:13:39 *** photonclock_ has quit IRC
7872017-12-20T18:14:23 *** kenois has joined #bitcoin-core-dev
7882017-12-20T18:14:35 *** photonclock_ has joined #bitcoin-core-dev
7892017-12-20T18:22:19 *** jb55 has joined #bitcoin-core-dev
7902017-12-20T18:24:33 *** alfa has quit IRC
7912017-12-20T18:24:36 *** larafale has joined #bitcoin-core-dev
7922017-12-20T18:26:23 *** intcat has quit IRC
7932017-12-20T18:27:22 *** laurentmt has quit IRC
7942017-12-20T18:27:44 *** intcat has joined #bitcoin-core-dev
7952017-12-20T18:32:19 <provoostenator> Regarding production DNS seeds, "// Note that of those with the service bits flag, most only support a subset of possible options": sipa does your tool support all of those out of the box or just a subset?
7962017-12-20T18:35:47 *** Bruce__ has joined #bitcoin-core-dev
7972017-12-20T18:36:45 <sipa> provoostenator: you can configure it
7982017-12-20T18:37:17 <sipa> i think the default is fine
7992017-12-20T18:38:02 <provoostenator> Ok, I'm using the default. Should I clarify anything in the comment in that case?
8002017-12-20T18:38:57 *** ExtraCrispy has quit IRC
8012017-12-20T18:40:22 <provoostenator> Also, is your script able to keep the airdrop coin nodes away? Or is that not really a problem?
8022017-12-20T18:41:55 <wumpus> they tend to have their own DNS seeds
8032017-12-20T18:43:21 <jonasschnelli> provoostenator: default filters: https://github.com/sipa/bitcoin-seeder/blob/master/main.cpp#L150
8042017-12-20T18:43:23 <provoostenator> Right, but how does script prevent Bitcoin Core nodes from bootstrapping with a BCash peer and then getting stuck in August 2017 if none of those peers know of any Bitcoin Core peers? Not sure what the odds of that are.
8052017-12-20T18:43:31 <jonasschnelli> 1, 5, 9, 13...
8062017-12-20T18:43:38 <jonasschnelli> I guess we should add NODE_NETWORK_LIMITED there soon
8072017-12-20T18:43:44 <jonasschnelli> though... not sure
8082017-12-20T18:43:57 <wumpus> jonasschnelli: would there be any reason for nodes to search out NODE_NETWORK_LIMITED peers?
8092017-12-20T18:44:09 <wumpus> (I mean specifically)
8102017-12-20T18:44:50 <jonasschnelli> That is questionable, but maybe to improve network "health"... but yeah. maybe you don't need that
8112017-12-20T18:45:08 <jonasschnelli> Also,... it would have to hide out in non filtering and other filter flags..
8122017-12-20T18:45:19 <jonasschnelli> so,... nm, NODE_NETWORK_LIMITED needs not to be there
8132017-12-20T18:45:28 <wumpus> yes I understand that as argument to also connect to them, but not to seek them specifically
8142017-12-20T18:46:09 <jonasschnelli> indeed. Though you can't mix them with NODE_NETWORK on the seed-db... so peers lern only over getaddr LIMITED nodes
8152017-12-20T18:46:24 <jonasschnelli> (once this has been implemented)
8162017-12-20T18:47:20 <wumpus> right, true
8172017-12-20T18:47:38 *** maaku has joined #bitcoin-core-dev
8182017-12-20T18:47:45 <maaku> I've moved some discussion regarding implementation of BIPs 98, 116, and 117 to #bitcoin-mast
8192017-12-20T18:50:12 <bitcoin-git> [bitcoin] Sjors opened pull request #11962: [net] add seed.bitcoin.sprovoost.nl to DNS seeds (master...dns-seed-sjors) https://github.com/bitcoin/bitcoin/pull/11962
8202017-12-20T18:50:50 <MarcoFalke> jonasschnelli: Think of the tests as a layer around bitcoin-core, not the other way round ;)
8212017-12-20T18:51:07 *** kenois has quit IRC
8222017-12-20T18:51:18 <jonasschnelli> MarcoFalke: yes. that indeed true.
8232017-12-20T18:51:48 *** maaku has left #bitcoin-core-dev
8242017-12-20T18:51:54 *** larafale has quit IRC
8252017-12-20T18:52:04 <jonasschnelli> Though, I think test environments need to be practical, thats why we have almost no difficulty in regtest,.. and without a static fallback fee, regtests gets pretty unusable
8262017-12-20T18:52:28 <jonasschnelli> We could also inject deterministic fee estmation data
8272017-12-20T18:53:00 <jonasschnelli> But disabling on regtest means regtest-wallet is only useful with -fallbackfee... this leads me to think it should be there by default
8282017-12-20T18:53:07 <jonasschnelli> (no on testnet though)
8292017-12-20T18:53:27 <jonasschnelli> Not sure about others, but I use regtest quite often
8302017-12-20T18:53:36 <jonasschnelli> (more then mainnet *duck*)
8312017-12-20T18:55:33 <jonasschnelli> bloody fee spam on github,.. all during the same time of bcash pump and mempool spam.
8322017-12-20T18:57:19 *** arubi has quit IRC
8332017-12-20T18:58:46 <wumpus> at least I banned the neo-nazi with his secret society nonsense from the org today, anything more?
8342017-12-20T18:59:27 <jonasschnelli> No.. the rest is just normal nonblockable spam
8352017-12-20T19:02:27 *** intcat has quit IRC
8362017-12-20T19:03:45 *** intcat has joined #bitcoin-core-dev
8372017-12-20T19:04:45 *** arubi has joined #bitcoin-core-dev
8382017-12-20T19:05:38 *** YellowSphere has joined #bitcoin-core-dev
8392017-12-20T19:06:57 *** jb55 has quit IRC
8402017-12-20T19:07:11 *** Randolf has quit IRC
8412017-12-20T19:09:43 *** laurentmt has joined #bitcoin-core-dev
8422017-12-20T19:14:15 <jonasschnelli> Is there no different way of losing tests into the test_runner.py that would not rais a git conflict all the time? Like autoloading them via readdir()?
8432017-12-20T19:14:20 <jonasschnelli> *loading
8442017-12-20T19:14:49 <wumpus> yes, that could work
8452017-12-20T19:15:05 <wumpus> well except for the order of execution
8462017-12-20T19:15:23 *** jb55 has joined #bitcoin-core-dev
8472017-12-20T19:15:26 <wumpus> you'd have to add metadata for every test as well, in a separate file
8482017-12-20T19:15:38 <wumpus> so that they can be sorted by +/- size
8492017-12-20T19:15:47 <wumpus> eh s/size/execution time/
8502017-12-20T19:16:00 <jonasschnelli> or filename based
8512017-12-20T19:16:08 <jonasschnelli> 1-flag-testname.py
8522017-12-20T19:16:11 <jonasschnelli> (where 1 is the oder)
8532017-12-20T19:16:13 <jonasschnelli> *order
8542017-12-20T19:16:24 <wumpus> nah
8552017-12-20T19:16:33 <wumpus> I'd really prefer not to encode anything into the file name
8562017-12-20T19:17:20 <wumpus> we don't want to be renaming tests all the time, that's awfully inconvenient if you want to execute them seprately to test something
8572017-12-20T19:17:21 <jonasschnelli> Or directly include the meta in the python file?
8582017-12-20T19:17:28 <wumpus> yes, exactly
8592017-12-20T19:17:31 <jonasschnelli> Yeah.. that true
8602017-12-20T19:17:40 <wumpus> just a comment in a certain format at the top
8612017-12-20T19:18:16 <jonasschnelli> Yeah.. ping MarcoFalke ^
8622017-12-20T19:18:26 <jonasschnelli> Let me do an issue
8632017-12-20T19:20:32 <sipa> or what about a test that checks every functional test is listed in test_runner.py?
8642017-12-20T19:21:35 <wumpus> we already have that
8652017-12-20T19:22:28 <sipa> oh.
8662017-12-20T19:22:50 *** Ylbam has joined #bitcoin-core-dev
8672017-12-20T19:23:30 <wumpus> check_script_list() in test_runner.py
8682017-12-20T19:23:38 <sipa> then what's the problem?
8692017-12-20T19:23:44 <wumpus> merge conflicts
8702017-12-20T19:23:55 <sipa> that seems to solve the risk of accidentally lose things in the list
8712017-12-20T19:24:26 <wumpus> yes, that it does, it's just that it doesn't prevent having to rebase, jonasschnelli's comment was more about avoiding the hotspot
8722017-12-20T19:24:27 *** Chris_Stewart_5 has quit IRC
8732017-12-20T19:25:17 <sipa> ah, i see
8742017-12-20T19:25:44 <jonasschnelli> I did at least 5 rebases the last two weeks because of the test_runner hotspot
8752017-12-20T19:26:02 <jonasschnelli> Not problematic,... but maybe it can be solved in a way where things get even more simple
8762017-12-20T19:26:18 <jonasschnelli> (just placing a test script into the right directory seems more elegant)
8772017-12-20T19:27:24 <wumpus> yes, I agree
8782017-12-20T19:28:22 <jonasschnelli> Though it would be another larger change in the test framework. Everytime I write a new test, something is new,... :)
8792017-12-20T19:28:44 <wumpus> lots of changes to the test framework lately
8802017-12-20T19:29:03 *** vh has joined #bitcoin-core-dev
8812017-12-20T19:31:24 *** intcat has quit IRC
8822017-12-20T19:32:45 *** intcat has joined #bitcoin-core-dev
8832017-12-20T19:33:56 * luke-jr grumbles at GitHub changing all our tarballs again
8842017-12-20T19:36:50 <wumpus> what did they change them into this time
8852017-12-20T19:38:45 *** SopaXorzTaker has quit IRC
8862017-12-20T19:40:25 *** vh has quit IRC
8872017-12-20T19:42:42 *** Cory has quit IRC
8882017-12-20T19:44:34 <MarcoFalke> re: jonasschnelli Place them at random locations
8892017-12-20T19:44:47 <MarcoFalke> I don't get why everyone puts them in the last line
8902017-12-20T19:45:09 <MarcoFalke> They are supposed to be sorted by approximate run-time, not date of insertion
8912017-12-20T19:45:35 <MarcoFalke> We should add a comment in the last line to not put any tests there
8922017-12-20T19:45:48 <jonasschnelli> Heh.. yes. Your right,.... but would you not also prefere the auto-loading approach? Or what downsides do you see?
8932017-12-20T19:46:20 *** mrfrasha has quit IRC
8942017-12-20T19:46:43 *** quantbot has joined #bitcoin-core-dev
8952017-12-20T19:46:57 <MarcoFalke> Some of the files that end in ".py" are not test scripts
8962017-12-20T19:47:06 <sipa> jonasschnelli: how do you determine the order of auto loaded tests?
8972017-12-20T19:47:12 <MarcoFalke> and that
8982017-12-20T19:47:56 <sipa> we could move the timing information to the test files themselves, and then use that to determine the order
8992017-12-20T19:48:03 <MarcoFalke> And we'd have to write a test for the auto-loader
9002017-12-20T19:48:04 <jonasschnelli> sipa: with some metadata in the test script (header)
9012017-12-20T19:48:10 <sipa> in that case we could get rid of the hardcoded lists entirely
9022017-12-20T19:48:49 <MarcoFalke> Hmm, I am really scared of not running tests
9032017-12-20T19:48:56 <MarcoFalke> I.e. the autoloader skips tests
9042017-12-20T19:49:00 <jonasschnelli> also, if you change a test, so it will consume more time, you need to shuffle stuff...
9052017-12-20T19:49:31 <jonasschnelli> The script list in test_runner seems redundant info to me
9062017-12-20T19:49:32 <MarcoFalke> jonasschnelli: Not too important. The time is measured in the order of minutes
9072017-12-20T19:49:53 <jonasschnelli> But it's just a though....
9082017-12-20T19:50:08 *** quantbot_ has quit IRC
9092017-12-20T19:50:21 <MarcoFalke> s/minutes/10s-of-seconds/
9102017-12-20T19:51:38 *** quantbot has quit IRC
9112017-12-20T19:52:10 <MarcoFalke> So even if we did the autoloader, I'd only feel comfortable doing it if we hardcoded the test list or at least the number of tests that are supposed to be run.
9122017-12-20T19:57:14 <bitcoin-git> [bitcoin] MarcoFalke opened pull request #11965: qa: Note on test order in test_runner (master...Mf1712-qaTestRunnerOrder) https://github.com/bitcoin/bitcoin/pull/11965
9132017-12-20T20:02:26 *** intcat has quit IRC
9142017-12-20T20:03:58 *** intcat has joined #bitcoin-core-dev
9152017-12-20T20:04:40 *** intcat has quit IRC
9162017-12-20T20:05:22 *** marcel_ has quit IRC
9172017-12-20T20:05:56 *** intcat has joined #bitcoin-core-dev
9182017-12-20T20:08:50 <luke-jr> wumpus: yet another digit added to commit hashes, it appears
9192017-12-20T20:10:13 <luke-jr> maybe we should just use the full hash in the code
9202017-12-20T20:15:27 *** Murch has quit IRC
9212017-12-20T20:19:46 *** Murch has joined #bitcoin-core-dev
9222017-12-20T20:24:38 <bitcoin-git> [bitcoin] MarcoFalke closed pull request #11918: fees: Remove fallbackfee default (master...Mf1712-NoFallBackFee) https://github.com/bitcoin/bitcoin/pull/11918
9232017-12-20T20:24:54 *** meshcollider has joined #bitcoin-core-dev
9242017-12-20T20:28:49 <wumpus> luke-jr: you mean in the embedded version hash? yes, I think that'd make sense
9252017-12-20T20:31:33 *** arubi has quit IRC
9262017-12-20T20:32:02 *** arubi has joined #bitcoin-core-dev
9272017-12-20T20:45:49 *** Randolf has joined #bitcoin-core-dev
9282017-12-20T20:47:52 <MarcoFalke> wumpus: Any thoughts on #11517 ?
9292017-12-20T20:47:54 <gribble> https://github.com/bitcoin/bitcoin/issues/11517 | Tests: Improve benchmark precision by martinus · Pull Request #11517 · bitcoin/bitcoin · GitHub
9302017-12-20T20:48:05 <MarcoFalke> imo, it is ready
9312017-12-20T20:48:30 <MarcoFalke> But I wanted to see if you have any opinion, since it is basically a re-write
9322017-12-20T20:50:09 *** Randolf has quit IRC
9332017-12-20T20:50:19 *** jb55 has quit IRC
9342017-12-20T20:51:51 <wumpus> seems it needs rebase again, but no not really have an opinion on it, if manually specifying the number of iterations works better for precious that's ok with me
9352017-12-20T20:52:01 <wumpus> precision*
9362017-12-20T20:52:52 *** Aaronvan_ has joined #bitcoin-core-dev
9372017-12-20T20:53:30 <wumpus> not sure how the changes to check-doc.py belong in there though
9382017-12-20T20:54:04 *** laurentmt has quit IRC
9392017-12-20T20:54:44 <MarcoFalke> bench is also "test", I assume. Since it is a rewrite of bench, might as well fix that up
9402017-12-20T20:55:23 <bitcoin-git> [bitcoin] luke-jr opened pull request #11966: clientversion: Use full commit hash for commit-based version descriptions (master...ver_full_commit_hash) https://github.com/bitcoin/bitcoin/pull/11966
9412017-12-20T20:56:09 *** AaronvanW has quit IRC
9422017-12-20T20:57:33 <bitcoin-git> [bitcoin] jonasschnelli opened pull request #11967: Add script to test the dns seeds (master...2017/12/seed_test) https://github.com/bitcoin/bitcoin/pull/11967
9432017-12-20T21:00:02 *** JackH_ has joined #bitcoin-core-dev
9442017-12-20T21:02:45 *** laptop__ has quit IRC
9452017-12-20T21:05:38 *** intcat has quit IRC
9462017-12-20T21:06:43 *** intcat has joined #bitcoin-core-dev
9472017-12-20T21:22:22 *** laurentmt has joined #bitcoin-core-dev
9482017-12-20T21:24:44 *** jb55 has joined #bitcoin-core-dev
9492017-12-20T21:35:48 *** kraeftig has quit IRC
9502017-12-20T21:37:29 *** Guyver2 has quit IRC
9512017-12-20T21:38:04 *** promag has quit IRC
9522017-12-20T21:38:39 *** promag has joined #bitcoin-core-dev
9532017-12-20T21:54:23 *** laurentmt has quit IRC
9542017-12-20T21:54:35 *** larafale has joined #bitcoin-core-dev
9552017-12-20T21:55:59 *** laurentmt has joined #bitcoin-core-dev
9562017-12-20T21:56:17 *** jb55 has quit IRC
9572017-12-20T22:05:28 *** intcat has quit IRC
9582017-12-20T22:06:21 *** spinza has quit IRC
9592017-12-20T22:06:46 *** intcat has joined #bitcoin-core-dev
9602017-12-20T22:07:25 *** Giszmo has quit IRC
9612017-12-20T22:15:40 *** spinza has joined #bitcoin-core-dev
9622017-12-20T22:15:58 *** alcipir has quit IRC
9632017-12-20T22:28:38 *** intcat has quit IRC
9642017-12-20T22:29:42 *** Chris_Stewart_5 has joined #bitcoin-core-dev
9652017-12-20T22:29:57 *** intcat has joined #bitcoin-core-dev
9662017-12-20T22:30:40 *** jb55 has joined #bitcoin-core-dev
9672017-12-20T22:34:15 *** Randolf has joined #bitcoin-core-dev
9682017-12-20T22:35:46 *** pkx2 has quit IRC
9692017-12-20T22:39:19 *** YellowSphere has quit IRC
9702017-12-20T22:40:10 <bitcoin-git> [bitcoin] MarcoFalke pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/79399c8cd0b6...604e08c83cf5
9712017-12-20T22:40:11 <bitcoin-git> bitcoin/master b673429 MeshCollider: Cleanups for walletdir PR
9722017-12-20T22:40:11 <bitcoin-git> bitcoin/master aac6b3f MeshCollider: Update files.md for new wallets/ subdirectory
9732017-12-20T22:40:12 <bitcoin-git> bitcoin/master 604e08c MarcoFalke: Merge #11726: Cleanups + nit fixes for walletdir PR...
9742017-12-20T22:40:39 <bitcoin-git> [bitcoin] MarcoFalke closed pull request #11726: Cleanups + nit fixes for walletdir PR (master...201711_walletdir) https://github.com/bitcoin/bitcoin/pull/11726
9752017-12-20T22:41:05 *** Randolf has quit IRC
9762017-12-20T22:52:15 *** Murch has quit IRC
9772017-12-20T22:53:12 *** Murch has joined #bitcoin-core-dev
9782017-12-20T22:59:25 <cfields> gmaxwell: just to clarify, all that's needed upfront for the threshold signing for apple codesigning is a properly signed csr with the (not-yet-existing) new pubkey shoved in, right?
9792017-12-20T23:00:06 <cfields> obviously the pubkey will be shoved in, then the signature generated as a second step
9802017-12-20T23:01:33 <cfields> if so, looks straightforward, just need to figure out how the digest is calculated
9812017-12-20T23:03:43 *** climjark_ has joined #bitcoin-core-dev
9822017-12-20T23:04:25 *** intcat has quit IRC
9832017-12-20T23:05:24 *** Cogito_Ergo_Sum has quit IRC
9842017-12-20T23:05:33 *** intcat has joined #bitcoin-core-dev
9852017-12-20T23:06:35 *** larafale has quit IRC
9862017-12-20T23:07:59 *** bule has joined #bitcoin-core-dev
9872017-12-20T23:13:09 *** harrymm has quit IRC
9882017-12-20T23:18:50 *** Murch has quit IRC
9892017-12-20T23:19:01 *** arubi has quit IRC
9902017-12-20T23:19:01 *** bule has quit IRC
9912017-12-20T23:19:26 *** arubi has joined #bitcoin-core-dev
9922017-12-20T23:19:43 *** bule has joined #bitcoin-core-dev
9932017-12-20T23:19:55 *** Murch has joined #bitcoin-core-dev
9942017-12-20T23:21:55 *** Randolf has joined #bitcoin-core-dev
9952017-12-20T23:24:06 <bitcoin-git> [bitcoin] Raizen opened pull request #11968: Update consensus.h (master...patch-1) https://github.com/bitcoin/bitcoin/pull/11968
9962017-12-20T23:25:54 *** harrymm has joined #bitcoin-core-dev
9972017-12-20T23:26:01 *** d9b4bef9 has quit IRC
9982017-12-20T23:26:44 <bitcoin-git> [bitcoin] MarcoFalke closed pull request #11968: Update consensus.h (master...patch-1) https://github.com/bitcoin/bitcoin/pull/11968
9992017-12-20T23:27:07 *** d9b4bef9 has joined #bitcoin-core-dev
10002017-12-20T23:36:24 *** Kozuch has quit IRC
10012017-12-20T23:36:53 *** Giszmo has joined #bitcoin-core-dev
10022017-12-20T23:42:10 *** vinirunner has joined #bitcoin-core-dev
10032017-12-20T23:49:10 *** Pavle has joined #bitcoin-core-dev
10042017-12-20T23:53:01 *** Murch has quit IRC
10052017-12-20T23:53:35 *** vinirunner has quit IRC
10062017-12-20T23:53:42 *** valentinewallace has joined #bitcoin-core-dev
10072017-12-20T23:57:25 *** laurentmt has quit IRC