12017-02-13T00:09:16  <bitcoin-git> [bitcoin] luke-jr opened pull request #9749: If -spkreuse=0, ensure transactions in mempool always have unique scriptPubKeys (master...unique_spk_mempool) https://github.com/bitcoin/bitcoin/pull/9749
  22017-02-13T00:09:44  *** jtimon has quit IRC
  32017-02-13T00:28:44  *** AaronvanW has joined #bitcoin-core-dev
  42017-02-13T00:33:05  *** AaronvanW has quit IRC
  52017-02-13T00:35:46  *** str4d has quit IRC
  62017-02-13T00:37:02  *** AaronvanW has joined #bitcoin-core-dev
  72017-02-13T00:37:03  *** AaronvanW has joined #bitcoin-core-dev
  82017-02-13T00:46:14  <gmaxwell> luke-jr: it would be interesting if there were a 1 bit flag in scriptpubkeys that indicated if you wanted to allow reuse or not.
  92017-02-13T00:50:10  *** Giszmo has quit IRC
 102017-02-13T00:50:26  *** Giszmo has joined #bitcoin-core-dev
 112017-02-13T01:29:18  <luke-jr> gmaxwell: enforcing it consistently would require an ever-growing set, so this is more useful to simply discourage it in general
 122017-02-13T01:29:48  <gmaxwell> it would just be "best effort"
 132017-02-13T01:30:12  <gmaxwell> e.g. I promise no two in the last N blocks, beyond that, "probablistic"
 142017-02-13T01:30:22  <luke-jr> I can't think of any reason to ever intentionally accomidate reuse.
 152017-02-13T01:30:39  <gmaxwell> widespread practice.
 162017-02-13T01:31:02  <gmaxwell> an improvement no one uses is not an improvement.
 172017-02-13T01:31:24  <luke-jr> widespread practice needs to change; people enabling this puts pressure on others to stop doing it
 182017-02-13T01:31:45  <luke-jr> especially people doing more transaction volume
 192017-02-13T01:31:52  <BlueMatt> how? only realistically if its off-by-default, which we cant do, or if miners use it, which they wont
 202017-02-13T01:32:07  <sdaftuar> i haven't read this patch carefully, but is there anything to prevent an attacker from interfering with relay by sending a low-fee, low-value transaction to an output that he sees, and relaying that ahead of the original tx?
 212017-02-13T01:32:12  <gmaxwell> and what if the net effect is just someone standarziding that wallets should notice their scriptpubkey with a dummy push also strapped to it?
 222017-02-13T01:32:23  <gmaxwell> oh slick point.
 232017-02-13T01:32:32  <luke-jr> sdaftuar: there isn't. perhaps it should use RBF semantics in that case
 242017-02-13T01:33:02  <sdaftuar> this seems like a solution looking for a problem imo
 252017-02-13T01:33:19  <gmaxwell> well there are problems it would help with.
 262017-02-13T01:34:10  <gmaxwell> for example,, if you take some old addresses and spend all the connected coins, people have frequently then sent near dust amounts to them, seemingly with the hope that you'll spend the dust in another transaction and link the outputs.
 272017-02-13T01:34:57  <morcos> luke-jr: also to clarify (sorry for not just reading the code), if there are already multiple outputs encumbered by the same scriptpubkey, does this patch prevent spending more than one of them at a time?
 282017-02-13T01:35:17  <gmaxwell> no, it's just a creation restriction AFAICT.
 292017-02-13T01:35:18  <luke-jr> morcos: it doesn't prevent that.
 302017-02-13T01:35:33  <luke-jr> it restricts spending as well, but allows multiple of them in the same tx
 312017-02-13T01:35:34  <morcos> ok, the exception in your PR text confused me..   that's good at least!
 322017-02-13T01:35:40  <luke-jr> brb
 332017-02-13T01:35:52  <morcos> wait... so it does prevent that unless you put them in the same TX????
 342017-02-13T01:37:08  <jcorgan> is there a particular reason bitcoin.conf only allows IP parameters by address and not hostname/dns name, other than "it hasn't been written yet"?
 352017-02-13T01:37:24  *** goksinen has quit IRC
 362017-02-13T01:37:48  <morcos> for the record, i agree with the basic gist of discouraging address reuse, but i think its crazy to make it an absolute.  i've reused (And continue to reuse) addresess many times... its a choice of convenience over.. eh.. maybe some loss of privacy
 372017-02-13T01:38:30  <morcos> for instance if your change output is readily discernible already..
 382017-02-13T01:38:33  <gmaxwell> luke-jr: probably more important is that more outputs shouldn't be made to an address once it's been spent from (and ideally wallets would spend from that address all at once)
 392017-02-13T01:40:20  <midnightmagic> morcos: Also, loss of privacy for other people who deal with you.
 402017-02-13T01:40:34  *** Giszmo has quit IRC
 412017-02-13T01:40:54  *** Giszmo has joined #bitcoin-core-dev
 422017-02-13T01:43:59  *** Ylbam has quit IRC
 432017-02-13T01:50:40  *** Giszmo has quit IRC
 442017-02-13T02:05:34  *** AaronvanW has quit IRC
 452017-02-13T02:26:15  <luke-jr> morcos: it's not absolute; you can wait until the transaction is mined
 462017-02-13T02:27:30  <luke-jr> it occurs to me the current PR already breaks RBF, so I need to fix that :/
 472017-02-13T02:31:16  <luke-jr> I suppose it should just treat SPK overlaps as if they shared a conflicting input
 482017-02-13T02:31:44  <luke-jr> solve both issues at once
 492017-02-13T02:32:34  <morcos> i think it makes no sense at all to have an option that makes it difficult for people to spend previously created outputs
 502017-02-13T02:32:45  <morcos> i'd be opposed to that
 512017-02-13T02:33:16  <morcos> i mean i'm basically opposed to the option in general..  but if its just an option and it defaults off..  well you have to pick your battles
 522017-02-13T02:33:26  <morcos> but if it prevents spending existing outputs.. that seems crazy
 532017-02-13T02:33:53  <luke-jr> you can spend them in separate blocks or in the same tx
 542017-02-13T02:34:03  <luke-jr> there is no reason anyone should ever have multiple tx in the same block anyway
 552017-02-13T02:35:24  <sipa> right, but why would miners enable that setting?
 562017-02-13T02:35:36  <sipa> and if miners don't, why would anyone else?
 572017-02-13T02:36:02  <sipa> i like the reasons... but it's noneconomical
 582017-02-13T02:36:07  <luke-jr> because some miners actually care about Bitcoin
 592017-02-13T02:36:25  <morcos> honestly i think this is the kind of change that should go into something like Knots
 602017-02-13T02:38:17  <luke-jr> I don't like the direction Core is changing to where everything must be exclusively economic incentives. Bitcoin can't work with mere economic incentives as things are today. The way things are heading, Core is no longer a reference implementation, but a specific political agenda to the exclusion of others.
 612017-02-13T02:39:15  <sipa> luke-jr: the only criteria for non-miner mempools is the expectancy of what will confirm
 622017-02-13T02:39:39  <sipa> for miners, i would argue that any non-economical property is a push for a certain policy
 632017-02-13T02:39:50  <sipa> the economical one is that i expect everyone to take eventually
 642017-02-13T02:40:10  <luke-jr> sipa: I see it more of that non-miner mempools constrain miners, by creating slower propagation of blocks that don't match the wider network policies.
 652017-02-13T02:40:21  <luke-jr> sipa: economical is also a certain policy. options are options.
 662017-02-13T02:40:51  <sipa> luke-jr: divergence between non-miners and miners just encourages people to submit directly to miners, and miners to be reachable (and thus non-anonymous)
 672017-02-13T02:41:21  <sipa> i think that's a far worse outcome than just rational policies
 682017-02-13T02:41:26  <luke-jr> lack of divergence creates centralisation pressures forcing miners to all run the same policy dictated by developers
 692017-02-13T02:41:37  <morcos> i would argue that a minimum bar for an option is that at least the majority of Core developers think its a good idea OR a good fraction of the user community think its a good idea
 702017-02-13T02:41:42  <morcos> we can't support every fringe option
 712017-02-13T02:42:45  <sipa> luke-jr: my assumption is that if we'd introduce non-economical policies, and they're configurable they'd be turned off, and if they're not configurable someone will create a patch to change them
 722017-02-13T02:43:06  <sipa> by the vast majority of miners
 732017-02-13T02:43:39  <morcos> i also dislike the use of policy as something that tries to constrain users to use bitcoin in a certain way..  if its not necessary for DoS prevention or resource allocation, then good usage policies/options should be at the wallet level
 742017-02-13T02:44:08  <morcos> relay and mining should be essentially blind to any attribute of txs other than resource usage (which is unfortunately a multi-dimensional beast)
 752017-02-13T02:44:09  <luke-jr> I don't see many miners turning on acceptnonstdtxn. Or enabling full RBF (although some do exist). Miners do care to an extent, and that will hopefully improve as difficulty kills profits.
 762017-02-13T02:45:44  <luke-jr> morcos: that is not a sustainable view, at least as things are today. but more importantly, I concede your right to take that position, but you need to understand not everyone agrees with it.
 772017-02-13T02:46:13  <sipa> luke-jr: ok, i'll reformulate: my expectation is that over time we'll converge to more rational relay policies... not because developers force it, but because it's the most economical thing to do
 782017-02-13T02:46:37  <luke-jr> economical != rational
 792017-02-13T02:46:50  <sipa> short-term vs long-term?
 802017-02-13T02:46:59  <luke-jr> perhaps
 812017-02-13T02:47:08  <luke-jr> it's rational to filter SPK reuse in hopes of improving Bitcoin privacy, for example
 822017-02-13T02:47:52  <sipa> the only thing that actually improves privacy IMHO is consensus rules that incentivize it
 832017-02-13T02:48:16  <morcos> luke-jr: i'd be much more amenable to that argument if the Core wallet stopped SPK reuse..  having relay be difficult in the even of SPK reuse seems like it risks causing more harm than good
 842017-02-13T02:48:27  <luke-jr> neither developers nor miners control consensus rules. but miners do control policy.
 852017-02-13T02:49:01  <morcos> luke-jr: right!  that's why we need to work towards a bitcoin where there is no policy!!  all txs look the same
 862017-02-13T02:49:15  <luke-jr> no, policy is important.
 872017-02-13T02:49:16  <sipa> yes, let's switch to MimbleWimble. all txs look the same!
 882017-02-13T02:49:55  <sipa> luke-jr: in my ideal world, there can't be any policy beyond fees/size, because there is nothing else that distinguishes two transactions
 892017-02-13T02:50:15  <luke-jr> sipa: that's not everyone's ideal world.
 902017-02-13T02:50:29  <sipa> the fact that you can even say whether two outputs use the same address is a fungibility flaw on itself
 912017-02-13T02:50:45  <sipa> the fact that miners have censorship rights at all is a weakness
 922017-02-13T02:50:46  <luke-jr> I suppose
 932017-02-13T02:50:53  <luke-jr> no, miners are supposed to "censor" spam
 942017-02-13T02:50:56  <luke-jr> that's part of how the system works
 952017-02-13T02:51:20  <sipa> i agree with you, but only in its "development phase"... which may last a long time
 962017-02-13T02:51:34  <luke-jr> ?
 972017-02-13T02:51:36  *** ChatSharp has joined #bitcoin-core-dev
 982017-02-13T02:51:39  <sipa> everyone should cooperate to make the system as usable as possible while it is not perfect
 992017-02-13T02:52:07  <luke-jr> morcos: btw, Core wallet never reuses SPKs
1002017-02-13T02:52:17  <sipa> but eventually, it will need to work in a very-close-to-perfectly-rational environment
1012017-02-13T02:52:36  <luke-jr> sipa: okay, I think I agree on that.
1022017-02-13T02:52:40  <sipa> that doesn't mean that has to happen today
1032017-02-13T02:53:56  <luke-jr> IMO Lightning will help take a big step toward that
1042017-02-13T02:54:05  <sipa> maybe
1052017-02-13T02:54:22  <luke-jr> well, in theory since legit txs will probably drop in blockchain data usage vs spam
1062017-02-13T02:54:38  *** ChatSharp has left #bitcoin-core-dev
1072017-02-13T02:54:49  <luke-jr> hopefully that will increase the feerate of legit use beyond the point where spam is more economic
1082017-02-13T03:06:03  *** AaronvanW has joined #bitcoin-core-dev
1092017-02-13T03:06:32  * luke-jr ponders if a town will ever be named std::<something> XD
1102017-02-13T03:11:09  *** AaronvanW has quit IRC
1112017-02-13T03:46:48  *** wdfwefewvfgew has joined #bitcoin-core-dev
1122017-02-13T03:46:50  *** wdfwefewvfgew has left #bitcoin-core-dev
1132017-02-13T04:07:34  *** AaronvanW has joined #bitcoin-core-dev
1142017-02-13T04:12:34  *** AaronvanW has quit IRC
1152017-02-13T05:09:11  *** AaronvanW has joined #bitcoin-core-dev
1162017-02-13T05:13:40  *** AaronvanW has quit IRC
1172017-02-13T05:42:31  <bitcoin-git> [bitcoin] rohundhar opened pull request #9750: Bloomfilter: parameter variables made constant (master...bloomVar) https://github.com/bitcoin/bitcoin/pull/9750
1182017-02-13T06:50:36  *** lclc has joined #bitcoin-core-dev
1192017-02-13T06:51:03  *** AaronvanW has joined #bitcoin-core-dev
1202017-02-13T07:12:01  *** Ylbam has joined #bitcoin-core-dev
1212017-02-13T07:29:19  *** harrymm has quit IRC
1222017-02-13T07:37:09  *** udiWertheimer has quit IRC
1232017-02-13T07:39:02  *** BashCo has quit IRC
1242017-02-13T07:43:53  *** wasi has quit IRC
1252017-02-13T07:44:32  *** wasi has joined #bitcoin-core-dev
1262017-02-13T07:52:41  *** harrymm has joined #bitcoin-core-dev
1272017-02-13T07:55:36  *** AaronvanW has quit IRC
1282017-02-13T08:02:21  *** BashCo has joined #bitcoin-core-dev
1292017-02-13T08:06:57  *** harrymm has quit IRC
1302017-02-13T08:06:57  *** udiWertheimer has joined #bitcoin-core-dev
1312017-02-13T08:09:56  *** BashCo_ has joined #bitcoin-core-dev
1322017-02-13T08:10:03  *** AaronvanW has joined #bitcoin-core-dev
1332017-02-13T08:13:20  *** BashCo has quit IRC
1342017-02-13T08:15:04  *** goksinen has joined #bitcoin-core-dev
1352017-02-13T08:19:35  *** goksinen has quit IRC
1362017-02-13T08:52:21  *** juscamarena has joined #bitcoin-core-dev
1372017-02-13T09:09:19  *** goksinen has joined #bitcoin-core-dev
1382017-02-13T09:14:01  *** goksinen has quit IRC
1392017-02-13T09:20:24  *** instagibbs has quit IRC
1402017-02-13T10:03:31  *** goksinen has joined #bitcoin-core-dev
1412017-02-13T10:08:01  *** goksinen has quit IRC
1422017-02-13T10:13:22  *** BashCo has joined #bitcoin-core-dev
1432017-02-13T10:16:17  *** BashCo_ has quit IRC
1442017-02-13T10:30:10  *** Guyver2 has joined #bitcoin-core-dev
1452017-02-13T10:57:48  *** goksinen has joined #bitcoin-core-dev
1462017-02-13T11:02:28  *** goksinen has quit IRC
1472017-02-13T11:27:51  *** lclc has quit IRC
1482017-02-13T12:10:28  *** lclc has joined #bitcoin-core-dev
1492017-02-13T12:17:33  *** ChatSharp has joined #bitcoin-core-dev
1502017-02-13T12:19:41  *** Guyver2 has quit IRC
1512017-02-13T12:20:09  *** Cory has quit IRC
1522017-02-13T12:20:37  *** ChatSharp has left #bitcoin-core-dev
1532017-02-13T12:22:00  *** Pasha has joined #bitcoin-core-dev
1542017-02-13T12:28:55  *** Pasha is now known as Cory
1552017-02-13T12:51:06  *** jannes has joined #bitcoin-core-dev
1562017-02-13T12:57:05  *** udiWertheimer has quit IRC
1572017-02-13T12:57:23  *** BashCo_ has joined #bitcoin-core-dev
1582017-02-13T12:58:52  *** BashCo__ has joined #bitcoin-core-dev
1592017-02-13T13:00:09  *** udiWertheimer has joined #bitcoin-core-dev
1602017-02-13T13:01:17  *** BashCo has quit IRC
1612017-02-13T13:02:05  *** BashCo_ has quit IRC
1622017-02-13T13:03:55  <bitcoin-git> [bitcoin] DATSEC opened pull request #9751: Mini fix (master...patch-1) https://github.com/bitcoin/bitcoin/pull/9751
1632017-02-13T13:12:42  <jonasschnelli> ^^ Hmm.. chaning changelogs seems wired
1642017-02-13T13:20:44  *** laurentmt has joined #bitcoin-core-dev
1652017-02-13T13:22:09  *** laurentmt has quit IRC
1662017-02-13T13:27:05  *** molz_ has joined #bitcoin-core-dev
1672017-02-13T13:30:46  *** helo_ has joined #bitcoin-core-dev
1682017-02-13T13:30:47  *** crescend1 has joined #bitcoin-core-dev
1692017-02-13T13:30:51  *** Bootvis_ has joined #bitcoin-core-dev
1702017-02-13T13:31:01  *** thestrin1puller has joined #bitcoin-core-dev
1712017-02-13T13:31:02  *** xiangfu_ has joined #bitcoin-core-dev
1722017-02-13T13:31:16  *** wolfspra1l has joined #bitcoin-core-dev
1732017-02-13T13:31:18  *** roasbeef_ has joined #bitcoin-core-dev
1742017-02-13T13:31:25  *** eenoch_ has joined #bitcoin-core-dev
1752017-02-13T13:32:14  *** Bootvis has quit IRC
1762017-02-13T13:32:14  *** roasbeef has quit IRC
1772017-02-13T13:32:14  *** wolfspraul has quit IRC
1782017-02-13T13:32:14  *** Victorsueca has quit IRC
1792017-02-13T13:32:18  *** jonasschnelli has quit IRC
1802017-02-13T13:32:18  *** mol has quit IRC
1812017-02-13T13:32:18  *** crescendo has quit IRC
1822017-02-13T13:32:19  *** xiangfu has quit IRC
1832017-02-13T13:32:19  *** eenoch has quit IRC
1842017-02-13T13:32:19  *** helo has quit IRC
1852017-02-13T13:32:34  *** jonasschnelli_ has joined #bitcoin-core-dev
1862017-02-13T13:33:18  *** Victorsueca has joined #bitcoin-core-dev
1872017-02-13T13:34:39  *** jonasschnelli_ has quit IRC
1882017-02-13T13:34:51  *** jonasschnelli has joined #bitcoin-core-dev
1892017-02-13T13:36:26  *** thestringpuller has quit IRC
1902017-02-13T13:38:05  *** jonasschnelli has quit IRC
1912017-02-13T13:38:34  *** jonasschnelli has joined #bitcoin-core-dev
1922017-02-13T13:38:46  *** goksinen has joined #bitcoin-core-dev
1932017-02-13T13:41:54  *** Giszmo has joined #bitcoin-core-dev
1942017-02-13T13:43:42  *** goksinen has quit IRC
1952017-02-13T13:55:02  *** MarcoFalke has joined #bitcoin-core-dev
1962017-02-13T14:28:07  <jcorgan> is there a particular reason bitcoin.conf only allows IP parameters by address and not hostname/dns name, other than "it hasn't been written yet"?
1972017-02-13T14:28:30  *** paveljanik has joined #bitcoin-core-dev
1982017-02-13T14:28:30  *** paveljanik has joined #bitcoin-core-dev
1992017-02-13T14:29:07  <jonasschnelli> jcorgan: Yes. Probably. But I think we don't want addr-man to send around hostnames... in the config, yeah, fine.
2002017-02-13T14:30:22  <jcorgan> right, i'm only think of the conf file or cmd line, like proxy=, etc.
2012017-02-13T14:30:27  <jcorgan> *thinking
2022017-02-13T14:33:24  *** jtimon has joined #bitcoin-core-dev
2032017-02-13T14:39:41  *** MarcoFalke has quit IRC
2042017-02-13T15:14:33  *** chjj has quit IRC
2052017-02-13T15:19:14  *** goksinen has joined #bitcoin-core-dev
2062017-02-13T15:23:49  *** goksinen has quit IRC
2072017-02-13T15:25:54  *** goksinen has joined #bitcoin-core-dev
2082017-02-13T15:41:51  *** jnewbery has joined #bitcoin-core-dev
2092017-02-13T15:59:30  *** chjj has joined #bitcoin-core-dev
2102017-02-13T16:18:14  *** Greybits has joined #bitcoin-core-dev
2112017-02-13T16:45:46  <Greybits> Hi!  im not very smart and trying to learn more about segwit.  to me it looks like lightning network is just a "man in the middle" proxy that can block transactions if they want to.   why is lightning network good for crypto?  who is bitfury?  why do they have an office in washington dc?  what do they do in north carolina by the military base?
2122017-02-13T16:46:16  *** lclc has quit IRC
2132017-02-13T16:47:44  <Chris_Stewart_5> Is there a BIP that talks about block time stamp requirements?
2142017-02-13T16:50:53  <Chris_Stewart_5> Looking at BIP113, it states we take the median time stamp for the last 11 blocks, but what stops the miner from egregiously lieing about that timestamp?
2152017-02-13T16:50:55  *** abpa has joined #bitcoin-core-dev
2162017-02-13T16:54:22  *** Guyver2 has joined #bitcoin-core-dev
2172017-02-13T16:59:14  *** BashCo has joined #bitcoin-core-dev
2182017-02-13T17:02:46  *** BashCo__ has quit IRC
2192017-02-13T17:12:16  <BlueMatt> Chris_Stewart_5: there is a consensus rule that the MTP (median time past) of each block must progress
2202017-02-13T17:12:32  <BlueMatt> ie you acan never have a block which is older than the median-of-last-11 as per its timestamp
2212017-02-13T17:15:55  <Chris_Stewart_5> BlueMatt: Thanks
2222017-02-13T17:31:22  *** Greybits has quit IRC
2232017-02-13T17:35:27  *** udiWertheimer has quit IRC
2242017-02-13T18:03:19  *** lclc has joined #bitcoin-core-dev
2252017-02-13T18:14:05  *** udiWertheimer has joined #bitcoin-core-dev
2262017-02-13T18:22:56  *** whphhg has joined #bitcoin-core-dev
2272017-02-13T18:31:44  *** goksinen has quit IRC
2282017-02-13T18:41:12  *** lclc has quit IRC
2292017-02-13T18:42:04  *** BashCo has quit IRC
2302017-02-13T18:47:10  *** goksinen has joined #bitcoin-core-dev
2312017-02-13T18:52:34  *** goksinen has quit IRC
2322017-02-13T18:56:10  *** lclc has joined #bitcoin-core-dev
2332017-02-13T19:04:35  *** BashCo has joined #bitcoin-core-dev
2342017-02-13T19:12:55  <bitcoin-git> [bitcoin] ryanofsky opened pull request #9753: Add static_assert to prevent VARINT(<signed value>) (master...pr/varint-assert) https://github.com/bitcoin/bitcoin/pull/9753
2352017-02-13T19:14:40  *** droark has quit IRC
2362017-02-13T19:15:34  *** droark has joined #bitcoin-core-dev
2372017-02-13T19:18:28  *** goksinen has joined #bitcoin-core-dev
2382017-02-13T19:22:55  *** goksinen has quit IRC
2392017-02-13T19:43:04  *** goksinen has joined #bitcoin-core-dev
2402017-02-13T19:43:15  *** goksinen has joined #bitcoin-core-dev
2412017-02-13T19:48:51  *** thestrin1puller is now known as thestringpuller
2422017-02-13T19:49:21  *** thestringpuller is now known as Guest52978
2432017-02-13T19:50:40  *** Guest52978 is now known as thestringpuller
2442017-02-13T19:51:04  *** thestringpuller has joined #bitcoin-core-dev
2452017-02-13T19:57:09  *** laurentmt has joined #bitcoin-core-dev
2462017-02-13T20:02:04  *** goksinen has quit IRC
2472017-02-13T20:07:41  *** goksinen has joined #bitcoin-core-dev
2482017-02-13T20:07:53  *** gk-1wm-su has joined #bitcoin-core-dev
2492017-02-13T20:10:10  *** gk-1wm-su has quit IRC
2502017-02-13T20:34:26  *** whphhg has quit IRC
2512017-02-13T21:06:39  *** goksinen has quit IRC
2522017-02-13T21:09:16  *** goksinen has joined #bitcoin-core-dev
2532017-02-13T21:10:20  *** lclc has quit IRC
2542017-02-13T21:16:14  *** whphhg has joined #bitcoin-core-dev
2552017-02-13T21:51:13  *** laurentmt has quit IRC
2562017-02-13T21:53:15  *** goksinen has quit IRC
2572017-02-13T22:16:45  *** goksinen has joined #bitcoin-core-dev
2582017-02-13T22:19:43  *** norotartagen has quit IRC
2592017-02-13T22:26:15  *** norotartagen has joined #bitcoin-core-dev
2602017-02-13T22:41:00  *** isle2983 has quit IRC
2612017-02-13T22:42:06  *** isle2983 has joined #bitcoin-core-dev
2622017-02-13T22:42:25  <bitcoin-git> [bitcoin] richardkiss opened pull request #9754: Change NULLFAIL => SIG_NULLFAIL. (master...feature/unify_sig_nullfail) https://github.com/bitcoin/bitcoin/pull/9754
2632017-02-13T22:48:04  *** norotartagen has left #bitcoin-core-dev
2642017-02-13T22:48:09  *** norotartagen has joined #bitcoin-core-dev
2652017-02-13T22:51:50  <bitcoin-git> [bitcoin] luke-jr opened pull request #9755: Bugfix: Qt/Options: Restore persistent "restart required" notice (master...bugfix_gui_opts_restartreq) https://github.com/bitcoin/bitcoin/pull/9755
2662017-02-13T22:59:58  <bitcoin-git> [bitcoin] ryanofsky opened pull request #9756: Return error when importmulti called with invalid address. (master...pr/multiaddr) https://github.com/bitcoin/bitcoin/pull/9756
2672017-02-13T23:14:16  *** goatee has joined #bitcoin-core-dev
2682017-02-13T23:38:10  *** `_^gk-1wm has joined #bitcoin-core-dev
2692017-02-13T23:40:12  *** `_^gk-1wm has quit IRC
2702017-02-13T23:44:45  *** `_^gk-1wm has joined #bitcoin-core-dev
2712017-02-13T23:50:25  *** `_^gk-1wm has quit IRC