12016-02-25T00:00:13  *** raedah has joined #bitcoin-core-dev
  22016-02-25T00:20:12  *** AaronvanW_ has joined #bitcoin-core-dev
  32016-02-25T00:30:46  *** wumpus has quit IRC
  42016-02-25T00:35:05  *** wumpus has joined #bitcoin-core-dev
  52016-02-25T00:40:17  *** danielsocials has joined #bitcoin-core-dev
  62016-02-25T00:44:14  *** danielsocials has quit IRC
  72016-02-25T00:44:23  *** danielsocials has joined #bitcoin-core-dev
  82016-02-25T00:47:25  *** randy-waterhouse has joined #bitcoin-core-dev
  92016-02-25T00:48:39  *** Thireus has joined #bitcoin-core-dev
 102016-02-25T00:48:52  *** danielsocials has quit IRC
 112016-02-25T01:04:10  *** Chris_Stewart_5 has quit IRC
 122016-02-25T01:09:38  <GitHub107> [bitcoin] promag closed pull request #6570: Add option to specify rescan starting timestamp to RPC import calls (master...feature/import-rescan-from-block-index) https://github.com/bitcoin/bitcoin/pull/6570
 132016-02-25T01:10:02  *** ghtdak has quit IRC
 142016-02-25T01:13:28  <GitHub184> [bitcoin] promag closed pull request #7498: Add createtransaction (master...feature/rpc-createtransaction) https://github.com/bitcoin/bitcoin/pull/7498
 152016-02-25T01:17:23  *** d9b4bef9 has quit IRC
 162016-02-25T01:18:27  *** justanotheruser has quit IRC
 172016-02-25T01:19:09  *** d9b4bef9 has joined #bitcoin-core-dev
 182016-02-25T01:24:17  *** justanotheruser has joined #bitcoin-core-dev
 192016-02-25T01:33:51  *** gevs has quit IRC
 202016-02-25T01:42:28  *** zooko has joined #bitcoin-core-dev
 212016-02-25T01:45:37  *** gevs has joined #bitcoin-core-dev
 222016-02-25T01:45:57  *** danielsocials has joined #bitcoin-core-dev
 232016-02-25T01:48:27  *** Ylbam has quit IRC
 242016-02-25T01:48:36  *** PaulCapestany has quit IRC
 252016-02-25T01:50:08  *** PaulCapestany has joined #bitcoin-core-dev
 262016-02-25T01:52:27  *** danielsocials has quit IRC
 272016-02-25T01:54:49  *** wallet42 has quit IRC
 282016-02-25T02:00:26  *** dermoth has quit IRC
 292016-02-25T02:00:56  *** dermoth has joined #bitcoin-core-dev
 302016-02-25T02:01:25  *** go1111111 has quit IRC
 312016-02-25T02:16:43  *** AaronvanW_ has quit IRC
 322016-02-25T02:17:13  *** go1111111 has joined #bitcoin-core-dev
 332016-02-25T02:32:45  *** justanotheruser has quit IRC
 342016-02-25T02:33:25  *** justanotheruser has joined #bitcoin-core-dev
 352016-02-25T02:34:59  *** gamersg has joined #bitcoin-core-dev
 362016-02-25T02:46:01  *** p15 has joined #bitcoin-core-dev
 372016-02-25T02:50:27  *** belcher has quit IRC
 382016-02-25T02:53:54  *** laurentmt has joined #bitcoin-core-dev
 392016-02-25T02:54:10  *** laurentmt has quit IRC
 402016-02-25T02:59:29  *** gevs has quit IRC
 412016-02-25T03:23:31  *** ghtdak has joined #bitcoin-core-dev
 422016-02-25T03:28:16  *** PaulCapestany has quit IRC
 432016-02-25T03:34:26  *** achow101 has joined #bitcoin-core-dev
 442016-02-25T03:49:18  *** achow101 has quit IRC
 452016-02-25T03:49:39  *** danielsocials has joined #bitcoin-core-dev
 462016-02-25T03:53:35  <GitHub23> [bitcoin] AliceWonderMiscreations closed pull request #7588: Sample RPM spec file for Bitcoin 0.12.0 (master...master) https://github.com/bitcoin/bitcoin/pull/7588
 472016-02-25T03:54:34  *** danielsocials has quit IRC
 482016-02-25T04:20:35  *** p15x has joined #bitcoin-core-dev
 492016-02-25T04:20:40  *** helo has quit IRC
 502016-02-25T04:21:09  *** helo has joined #bitcoin-core-dev
 512016-02-25T04:30:57  *** baldur has quit IRC
 522016-02-25T04:31:16  *** baldur has joined #bitcoin-core-dev
 532016-02-25T04:52:31  *** wallet42 has joined #bitcoin-core-dev
 542016-02-25T04:58:55  *** Don_John has quit IRC
 552016-02-25T05:38:29  *** p15x has quit IRC
 562016-02-25T05:52:32  *** danielsocials has joined #bitcoin-core-dev
 572016-02-25T05:57:18  *** xiangfu has quit IRC
 582016-02-25T05:59:07  *** xiangfu has joined #bitcoin-core-dev
 592016-02-25T05:59:31  *** danielsocials has quit IRC
 602016-02-25T06:02:02  *** midnightmagic has quit IRC
 612016-02-25T06:20:53  *** midnightmagic has joined #bitcoin-core-dev
 622016-02-25T06:54:08  *** goregrind has quit IRC
 632016-02-25T07:32:24  *** gamersg has quit IRC
 642016-02-25T07:33:01  *** Ylbam has joined #bitcoin-core-dev
 652016-02-25T07:56:29  *** danielsocials has joined #bitcoin-core-dev
 662016-02-25T07:59:26  *** BashCo has quit IRC
 672016-02-25T08:03:45  *** danielsocials has quit IRC
 682016-02-25T08:25:53  *** BashCo has joined #bitcoin-core-dev
 692016-02-25T08:32:10  *** chris2000 has joined #bitcoin-core-dev
 702016-02-25T08:32:52  *** xiangfu has quit IRC
 712016-02-25T08:34:50  *** xiangfu has joined #bitcoin-core-dev
 722016-02-25T08:40:59  *** fkhan has quit IRC
 732016-02-25T08:54:24  *** fkhan has joined #bitcoin-core-dev
 742016-02-25T09:01:11  *** danielsocials has joined #bitcoin-core-dev
 752016-02-25T09:07:01  *** danielsocials has quit IRC
 762016-02-25T09:16:51  *** MarcoFalke has joined #bitcoin-core-dev
 772016-02-25T09:27:15  *** AaronvanW_ has joined #bitcoin-core-dev
 782016-02-25T09:48:22  *** go1111111 has quit IRC
 792016-02-25T10:00:32  *** go1111111 has joined #bitcoin-core-dev
 802016-02-25T10:01:02  *** MarcoFalke has quit IRC
 812016-02-25T10:07:53  *** wallet42 has quit IRC
 822016-02-25T10:14:39  *** zooko has quit IRC
 832016-02-25T10:29:43  *** randy-waterhouse has quit IRC
 842016-02-25T10:47:51  *** MarcoFalke has joined #bitcoin-core-dev
 852016-02-25T10:49:29  *** xiangfu has quit IRC
 862016-02-25T10:51:33  *** xiangfu has joined #bitcoin-core-dev
 872016-02-25T11:04:20  *** danielsocials has joined #bitcoin-core-dev
 882016-02-25T11:16:56  *** MarcoFalke has quit IRC
 892016-02-25T11:20:48  *** danielsocials has quit IRC
 902016-02-25T11:36:03  <GitHub199> [bitcoin] luke-jr closed pull request #7529: Bugfix: Rename descendantfees to descendantmodfees (master...bugfix_descendantfees) https://github.com/bitcoin/bitcoin/pull/7529
 912016-02-25T11:48:34  *** xiangfu has quit IRC
 922016-02-25T12:36:51  *** dermoth_ has joined #bitcoin-core-dev
 932016-02-25T12:37:17  *** dermoth has quit IRC
 942016-02-25T12:37:19  *** dermoth_ is now known as dermoth
 952016-02-25T12:40:22  *** MarcoFalke has joined #bitcoin-core-dev
 962016-02-25T12:41:38  *** p15x has joined #bitcoin-core-dev
 972016-02-25T12:47:04  *** Thireus has quit IRC
 982016-02-25T12:47:10  *** Thireus1 has joined #bitcoin-core-dev
 992016-02-25T12:48:06  *** Thireus has joined #bitcoin-core-dev
1002016-02-25T12:51:43  *** Thireus1 has quit IRC
1012016-02-25T12:55:12  *** MarcoFalke has quit IRC
1022016-02-25T12:56:02  *** wallet42 has joined #bitcoin-core-dev
1032016-02-25T13:01:53  *** dermoth_ has joined #bitcoin-core-dev
1042016-02-25T13:02:00  *** dermoth has quit IRC
1052016-02-25T13:02:21  *** dermoth_ is now known as dermoth
1062016-02-25T13:02:30  *** laurentmt has joined #bitcoin-core-dev
1072016-02-25T13:15:52  *** Kexkey has joined #bitcoin-core-dev
1082016-02-25T13:16:58  *** gevs has joined #bitcoin-core-dev
1092016-02-25T13:17:23  *** danielsocials has joined #bitcoin-core-dev
1102016-02-25T13:20:37  *** zooko has joined #bitcoin-core-dev
1112016-02-25T13:22:09  *** danielsocials has quit IRC
1122016-02-25T13:32:24  *** xiangfu has joined #bitcoin-core-dev
1132016-02-25T13:35:08  *** Kexkey has quit IRC
1142016-02-25T13:58:56  *** MarcoFalke has joined #bitcoin-core-dev
1152016-02-25T14:00:29  *** p15 has quit IRC
1162016-02-25T14:01:22  *** p15x has quit IRC
1172016-02-25T14:02:54  *** p15x has joined #bitcoin-core-dev
1182016-02-25T14:03:19  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1192016-02-25T14:10:46  *** Chris_Stewart_5 has quit IRC
1202016-02-25T14:13:42  *** wallet42 has quit IRC
1212016-02-25T14:19:13  *** danielsocials has joined #bitcoin-core-dev
1222016-02-25T14:25:15  *** MarcoFalke has quit IRC
1232016-02-25T14:25:39  *** danielsocials has quit IRC
1242016-02-25T14:44:09  *** zooko has quit IRC
1252016-02-25T15:12:15  *** p15x has quit IRC
1262016-02-25T15:22:29  *** danielsocials has joined #bitcoin-core-dev
1272016-02-25T15:31:11  *** zooko has joined #bitcoin-core-dev
1282016-02-25T15:32:51  *** MarcoFalke has joined #bitcoin-core-dev
1292016-02-25T15:33:30  *** murch has joined #bitcoin-core-dev
1302016-02-25T15:34:57  *** danielsocials has quit IRC
1312016-02-25T15:53:01  *** zooko has quit IRC
1322016-02-25T15:53:51  * Luke-Jr prods cfields to fix the OSX SDK from Travis..
1332016-02-25T16:12:25  *** xiangfu has quit IRC
1342016-02-25T16:16:39  *** zooko has joined #bitcoin-core-dev
1352016-02-25T16:18:49  <btcdrak> Luje-Jr: what's wrong with it?
1362016-02-25T16:19:41  *** treehug88 has joined #bitcoin-core-dev
1372016-02-25T16:21:37  <Luke-Jr> btcdrak: it's Forbidden as usual
1382016-02-25T16:23:24  *** cheese_ has joined #bitcoin-core-dev
1392016-02-25T16:23:56  <btcdrak> link?
1402016-02-25T16:24:15  <btcdrak> oh the SDK, yeah.
1412016-02-25T16:25:57  *** Cheeseo has quit IRC
1422016-02-25T16:26:58  *** BashCo has quit IRC
1432016-02-25T16:32:16  *** danielsocials has joined #bitcoin-core-dev
1442016-02-25T16:34:10  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1452016-02-25T16:35:57  *** Thireus has quit IRC
1462016-02-25T16:38:04  *** danielsocials has quit IRC
1472016-02-25T16:41:10  *** Thireus has joined #bitcoin-core-dev
1482016-02-25T16:42:25  *** dermoth has quit IRC
1492016-02-25T16:47:08  *** BashCo has joined #bitcoin-core-dev
1502016-02-25T16:47:17  *** Don_John has joined #bitcoin-core-dev
1512016-02-25T16:48:06  *** Thireus1 has joined #bitcoin-core-dev
1522016-02-25T16:48:06  *** Thireus has quit IRC
1532016-02-25T16:55:37  *** Thireus has joined #bitcoin-core-dev
1542016-02-25T16:55:43  *** gevs has quit IRC
1552016-02-25T16:56:34  *** Thireus1 has quit IRC
1562016-02-25T17:08:29  *** Thireus1 has joined #bitcoin-core-dev
1572016-02-25T17:09:23  *** Thireus has quit IRC
1582016-02-25T17:10:10  *** Thireus has joined #bitcoin-core-dev
1592016-02-25T17:13:07  *** Thireus1 has quit IRC
1602016-02-25T17:19:35  <GitHub178> [bitcoin] morcos opened pull request #7598: Refactor CreateNewBlock to be a method of the BlockAssembler class (master...BlockAssembler) https://github.com/bitcoin/bitcoin/pull/7598
1612016-02-25T17:25:28  *** laurentmt has quit IRC
1622016-02-25T17:29:52  *** gevs has joined #bitcoin-core-dev
1632016-02-25T17:29:52  *** gevs has joined #bitcoin-core-dev
1642016-02-25T17:34:46  *** cj has quit IRC
1652016-02-25T17:37:16  *** lightningbot has joined #bitcoin-core-dev
1662016-02-25T17:41:00  *** jon3ss has joined #bitcoin-core-dev
1672016-02-25T17:43:26  *** jon3ss has quit IRC
1682016-02-25T17:44:09  *** Chris_Stewart_5 has quit IRC
1692016-02-25T17:44:25  *** danielsocials has quit IRC
1702016-02-25T17:50:46  *** skyraider_ has joined #bitcoin-core-dev
1712016-02-25T17:52:45  *** cj has joined #bitcoin-core-dev
1722016-02-25T17:53:39  *** zooko has quit IRC
1732016-02-25T18:04:43  *** raedah has quit IRC
1742016-02-25T18:05:10  *** raedah has joined #bitcoin-core-dev
1752016-02-25T18:06:14  *** wallet42 has joined #bitcoin-core-dev
1762016-02-25T18:08:38  *** murch has quit IRC
1772016-02-25T18:13:38  *** Thireus1 has joined #bitcoin-core-dev
1782016-02-25T18:14:39  *** Thireus has quit IRC
1792016-02-25T18:14:58  *** Thireus has joined #bitcoin-core-dev
1802016-02-25T18:18:13  *** Thireus1 has quit IRC
1812016-02-25T18:26:28  *** cj has quit IRC
1822016-02-25T18:28:24  *** cj has joined #bitcoin-core-dev
1832016-02-25T18:30:26  *** AtashiCon has quit IRC
1842016-02-25T18:30:45  *** AtashiCon has joined #bitcoin-core-dev
1852016-02-25T18:40:35  *** raedah has quit IRC
1862016-02-25T18:43:49  <cfields> Luke-Jr: just grepped the logs and guessed on a range based on what was failing. fingers crossed, should work now.
1872016-02-25T18:50:31  *** zooko has joined #bitcoin-core-dev
1882016-02-25T18:54:12  *** raedah has joined #bitcoin-core-dev
1892016-02-25T18:58:38  *** achow101 has joined #bitcoin-core-dev
1902016-02-25T19:01:14  <gmaxwell> #startmeeting
1912016-02-25T19:01:14  <lightningbot> Meeting started Thu Feb 25 19:01:14 2016 UTC.  The chair is gmaxwell. Information about MeetBot at http://wiki.debian.org/MeetBot.
1922016-02-25T19:01:14  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
1932016-02-25T19:01:35  <gmaxwell> Hello. Welcome to today's meeting (bot is broken in #bitcoin-dev. Topics?
1942016-02-25T19:02:08  <morcos> Did anyone review 7187 as per last weeks action item?
1952016-02-25T19:02:14  <morcos> We need punishments
1962016-02-25T19:02:29  <petertodd> morcos: heh, you're making me glad I was on a plane :)
1972016-02-25T19:02:30  <btcdrak> I got stuck in traffic, honest
1982016-02-25T19:02:41  *** zooko has quit IRC
1992016-02-25T19:03:02  *** proslogion has joined #bitcoin-core-dev
2002016-02-25T19:03:05  <morcos> Actually to make a topic out of it, lets gameplan a 68/112/113 rollout
2012016-02-25T19:03:10  <gmaxwell> morcos: we'll end up with people showing up every other meeting it seems. I also wasn't in last week.
2022016-02-25T19:03:18  <gmaxwell> #topic  68/112/113 rollout
2032016-02-25T19:03:18  <btcdrak> +1 morcos
2042016-02-25T19:03:37  <petertodd> so, rollout is made more complex by a non-trivial amount of hashing power nVersion voting for classic
2052016-02-25T19:03:54  <jonasschnelli> could a bip 68/112/113 softfork be a timestopper for SW?
2062016-02-25T19:04:09  <gmaxwell> This... again. :(
2072016-02-25T19:04:11  <morcos> sorry btcdrak i haven't checked recently, but it seemed to me that the soft fork logic was relatively easy to review (except for gmaxwells concern), but that we still needed more extensive testing
2082016-02-25T19:04:14  <petertodd> jonasschnelli: what do you mean by 'timestopper'?
2092016-02-25T19:04:17  <btcdrak> Yes. I have written an ISM rollout in https://github.com/bitcoin/bitcoin/pull/7561 but we may need to consider BIP9 now
2102016-02-25T19:04:21  <sdaftuar> has anyone reviewed either of the new versionbits proposals? (i haven't)
2112016-02-25T19:04:33  <jonasschnelli> timestopper: I guess we can't run two SF at the same time.
2122016-02-25T19:04:38  <morcos> yes, that should be action item for next week.
2132016-02-25T19:05:01  <btcdrak> sipa started a BIP9 implementation in https://github.com/bitcoin/bitcoin/pull/7575
2142016-02-25T19:05:02  <gmaxwell> jonasschnelli: I don't think so; at least we can roll multiple ISM sofforks at once so long as they are strictly additive. No one that I'm aware of is clamoring againsst 68/112/113.
2152016-02-25T19:05:12  <petertodd> gmaxwell: fwiw I asked f2pool and bitmain to use coinbase to allow hashers to show support rather than nVersion
2162016-02-25T19:05:37  <petertodd> gmaxwell: 68/112/113 were briefly discussed in HK, with no objections, fwiw
2172016-02-25T19:05:40  <gmaxwell> I am pretty fond of sipa's BIP9 implementation.
2182016-02-25T19:05:46  <btcdrak> I've been working on converting the tests in #7561 to work with versionbits so we have both options. But I have a couple of technical nits I'd like to discuss
2192016-02-25T19:06:52  <morcos> I think it would be the wiser move technically and politically to do BIP9 first if we don't think the delay is too long.  It's kind of the whole point of the thign.
2202016-02-25T19:06:52  <btcdrak> BIP68 obviously requires v2 transactions, which currently dont relay. So we need to bump the relay policy. the question is do we go for sf enforcement first, and then bump the policy or do we change the relay policy with the sf deployment?
2212016-02-25T19:07:08  <gmaxwell> petertodd: it's hard to be sure, it may be that it only becomes a constructed political hot potato once merged as we've seen for at least one other thing. But we can't plan based on my cyncicism. Maybe a last call to the mailing list would be useful.  "We're thinking about moving this into deployment, what if any complaints remain?"
2222016-02-25T19:07:29  <petertodd> btcdrak: I think changing the relay policy in the release that supports it is fine - that's basically what we did with CLTV after all
2232016-02-25T19:07:36  <morcos> gmaxwell: yes thats my point exactly, i think much less likely to have complaints if we are doing it via bip9
2242016-02-25T19:07:48  <petertodd> btcdrak: just don't bump the default tx version number yet!
2252016-02-25T19:07:55  <btcdrak> We also have a sort of chicken and egg situation for changing the default tx version, so I proposed this https://github.com/btcdrak/bitcoin/commit/957d59043b1eb3a2525eae6cae6a2a15b2eab401 so it can be done in two steps
2262016-02-25T19:08:18  <petertodd> btcdrak: looks good
2272016-02-25T19:08:37  *** zooko has joined #bitcoin-core-dev
2282016-02-25T19:08:50  <morcos> two steps seems logical, and bumping the default isn't particularly important while we don't have wallet code for sending BIP68 locked txs anyway right?
2292016-02-25T19:08:52  <btcdrak> Unless miners were change their signalling, I think we should go for BIP9 this time. It shouldnt take too long to convert the RPC tests over to sipa's PR.
2302016-02-25T19:09:01  <gmaxwell> I haven't spoken to the BTCD folks in a bit, they've provided useful feedback on protocol changes in the past. I'll take an action to go talk to them about 9/68/112/113.
2312016-02-25T19:09:14  <btcdrak> I'm building a patch based on #7575
2322016-02-25T19:09:36  <CodeShark> I personally dislike adding these constants to the CTransaction class
2332016-02-25T19:09:37  <jonasschnelli> #action talk to BTCD folk about bips 9/68/112/113
2342016-02-25T19:10:02  <btcdrak> maybe also action review 7575?
2352016-02-25T19:10:15  <gmaxwell> Should we send a last call-ish like message about 68/112/113 ?
2362016-02-25T19:10:27  <CodeShark> CTransaction should be relay policy independent as well as consensus independent
2372016-02-25T19:10:28  <petertodd> gmaxwell: ack
2382016-02-25T19:10:30  <btcdrak> gmaxwell: in what way?
2392016-02-25T19:10:53  <gmaxwell> btcdrak: "We're thinkin about moving these to deployment. Speak now or be mocked when you complain later."
2402016-02-25T19:10:53  <morcos> CodeShark: are you referring to BIP68 stuff.  (I mostly agree, but we merged that already)
2412016-02-25T19:10:54  <petertodd> CodeShark: I think that's a reasonable concern
2422016-02-25T19:10:59  <sdaftuar> gmaxwell: ack
2432016-02-25T19:11:10  <btcdrak> gmaxwell: yes that would be great. I had been contemplating this.
2442016-02-25T19:11:26  <gmaxwell> #action Send email re-68/112/113 deployment.
2452016-02-25T19:11:27  *** Thireus1 has joined #bitcoin-core-dev
2462016-02-25T19:11:30  <petertodd> gmaxwell: probably worth mentioning that we're considering version bits due to classic conflicts
2472016-02-25T19:11:40  <morcos> Who is taking that action item
2482016-02-25T19:11:46  <sipa> hi, i'm on bad internet in barbados
2492016-02-25T19:12:08  <gmaxwell> I could do it but I'm not ideal; not super up to date on the history there.
2502016-02-25T19:12:10  <morcos> petertodd: i think we should not mention that, lets just see if we can get bip 9 ready quickly and then say we're doing it
2512016-02-25T19:12:16  <CodeShark> sipa: what's the status on bip 9?
2522016-02-25T19:12:46  <petertodd> morcos: eh, that's reasonable if we think we're close
2532016-02-25T19:13:02  <sipa> CodeShark: i started working on some other changes to the bip (disambiguate some things, add a state transition diagram, and add start time)
2542016-02-25T19:13:03  <jonasschnelli> morcos: do you want to take the action-item for email re-68/112/113 deployment?
2552016-02-25T19:13:17  <morcos> sure unless btcdrak wants it
2562016-02-25T19:13:31  <btcdrak> morcos: I'll pass :)
2572016-02-25T19:13:34  <sipa> CodeShark: but not submitted yet
2582016-02-25T19:13:48  <jonasschnelli> morocs has "a white vest".
2592016-02-25T19:14:02  <btcdrak> sipa: is #7575 not up to date?
2602016-02-25T19:14:12  <jonasschnelli> 7575 was updated today
2612016-02-25T19:14:16  <sipa> btcdrak: is that my pr?
2622016-02-25T19:14:19  <gmaxwell> jonasschnelli: all the better to show the gunshot wounds.
2632016-02-25T19:14:26  <jonasschnelli> gmaxwell... haha
2642016-02-25T19:14:28  <sipa> btcdrak: it impkements a start time, which is not in bip9
2652016-02-25T19:14:52  *** Thireus has quit IRC
2662016-02-25T19:14:56  <btcdrak> sipa: oh, _that_ is why my RPC tests did not work....
2672016-02-25T19:14:58  <morcos> uhh
2682016-02-25T19:14:58  <sipa> btcdrak: and i had to make some interoretation as bip9 is ambiguous about what hapoens when both transitiin to failed and lockedin happen simultaneously
2692016-02-25T19:15:04  <gmaxwell> We had previously discussed a start time esp with the debacle that happened with CLTV being used by 1/4 to 1/3 of the hashpower before any released software supported it.
2702016-02-25T19:15:09  <btcdrak> sipa: I was going bananas
2712016-02-25T19:15:27  <sipa> sorry for typing, in a bumpy car
2722016-02-25T19:15:42  <CodeShark> argh...I added and removed a start time several times to the bip :p
2732016-02-25T19:15:52  <sipa> CodeShark: i know, sorry
2742016-02-25T19:16:06  <sipa> i believe we need one, but i want some other explanations on the bip too
2752016-02-25T19:16:07  <btcdrak> sipa: I agree with starttime, prefer it.
2762016-02-25T19:16:22  <sipa> there are different ways to do it
2772016-02-25T19:16:46  <morcos> sipa: so to be clear, is your bip 9 pr (7575) where you want it to be?  if so i think that should be primary action item for everyone else to review and feedback
2782016-02-25T19:16:58  <gmaxwell> I can't imagine doin BIP9 without a start time. Rusty was opposed on principle, I think, but expirence trumps.
2792016-02-25T19:17:00  <btcdrak> sipa: so I'll have to mock time for the RPC test
2802016-02-25T19:17:11  <petertodd> gmaxwell: by start time, you mean minimum possible activation data right?
2812016-02-25T19:17:13  <morcos> btcdrak can simultaneously work on getting the 68/112/113 ready to use it
2822016-02-25T19:17:19  <petertodd> gmaxwell: or grace period post-activation?
2832016-02-25T19:17:20  <sdaftuar> fyi 7575 is still failing travis, haven't dived in to see what is wrong
2842016-02-25T19:17:24  <gmaxwell> morcos: people reviewing should keep in mind that intentional discrepency with the BIP at the moment.
2852016-02-25T19:17:28  <morcos> we need both of those and 7187 merged for backport
2862016-02-25T19:17:36  <morcos> gmaxwell: noted.  :)
2872016-02-25T19:17:49  <CodeShark> https://github.com/bitcoin/bips/pull/219 didn't even get merged over this whole starttime crap :(
2882016-02-25T19:18:03  <gmaxwell> petertodd: former, in what the PR implements there is a time where the bit in the header becomes defined as counting for the soft-fork.
2892016-02-25T19:18:07  <CodeShark> Which wasn't even the main point of that PR
2902016-02-25T19:18:13  <btcdrak> morcos: yeah it's basically done, modulo converting the RPC tests from my ISM PR.
2912016-02-25T19:18:34  <petertodd> gmaxwell: right, any idea on how many months after final release that should be?
2922016-02-25T19:18:46  <sipa> btcdrak: starttime is blocktime based, not real time; you don't need mocktime
2932016-02-25T19:19:10  <sipa> morcos: 7575 is where i want it to be, but the logic should also go in bip9
2942016-02-25T19:19:31  <gmaxwell> petertodd: I think it's OKAY for it to be relatively near the release. considering that we've survived with an effectively negative start time.
2952016-02-25T19:19:43  <sipa> CodeSharki'll have a look at your pr to the bip again
2962016-02-25T19:19:55  <petertodd> gmaxwell: ok, so maybe 1-2 months?
2972016-02-25T19:20:11  <btcdrak> our roadmap FAQ tentatively pencilled BIP68,112,113 for March.
2982016-02-25T19:20:14  <sipa> sdaftuar: if tests still fails, the pr is certainly not where it should be regarding tests
2992016-02-25T19:20:31  <morcos> petertodd: i'm not following, you think you shouldn't be able to start soft fork activation for 1-2 months after code release?
3002016-02-25T19:20:53  <morcos> why not? at 95% miner threshold and with innocous soft forks, it should be ok to do it sooner.
3012016-02-25T19:20:56  <CodeShark> We need to start getting into the habit of publishing less optimistic schedules ;)
3022016-02-25T19:21:14  <morcos> maybe something a bit more invasive (like segwit) then you could put a couple 1000 block delay
3032016-02-25T19:21:15  <gmaxwell> morcos: ideally nodes are updated first, though it's not strictly needed.
3042016-02-25T19:21:15  <petertodd> morcos: yes, that's gmaxwell's argument, to give non-miners some time to upgrade their nodes (even in a soft-fork that's a good thing)
3052016-02-25T19:21:26  <btcdrak> morcos: we want to avoid the situation we had with CLTV where f2pool were mining v4 blocks before we'd actually released the code.
3062016-02-25T19:21:26  <gmaxwell> morcos: because you want them rejecting any blocks from that 5% that are not valid.
3072016-02-25T19:21:35  <CodeShark> However long you think anything could reasonably take, double it for public expectations
3082016-02-25T19:21:45  <petertodd> morcos: one argument for it, is it can be done in about one line of code - cheap protection
3092016-02-25T19:22:13  <petertodd> CodeShark: yeah, so a practical problem, is you'd be changing unit tests right up until the last minute pre-release
3102016-02-25T19:22:35  <petertodd> CodeShark: a grace period - if it could be implemented easily enough - is better in that regard as it's defined from after the point at which the fork activates
3112016-02-25T19:22:50  <morcos> petertodd: i'm mostly just thinking about making changes take even longer..  and also perhaps losing attention focused on what's happening...   oh maybe i'm misunderstanding.  you could signal for it immediately, but it couldn't activate until start time
3122016-02-25T19:22:53  <petertodd> CodeShark: less important if the minimum start time is far into the future, but 1-2 months isn't
3132016-02-25T19:22:54  <morcos> that might be good
3142016-02-25T19:23:04  <petertodd> morcos: yeah, 100% ok to signal immediately
3152016-02-25T19:23:05  <btcdrak> petertodd: I think we get the PR into a mergable state, once agreed (and decided on deployment of code), we can set the start date for a reasonable amount of time into the future.
3162016-02-25T19:23:38  <petertodd> btcdrak: well, so long as we can co-ordinate that with the bitcoin core release schedule - which admittedly is much easier if we continue to do that in minor version releases
3172016-02-25T19:23:51  <btcdrak> petertodd: exactly.
3182016-02-25T19:24:15  <petertodd> alright, ack 1-2 month min start time
3192016-02-25T19:25:30  <btcdrak> wumpus: I would caution any merging consensus refactoring PRs until we get the sf code emerged. It will make backporting to 0.12 easier and easier to verify (basically an easy cherrypick).
3202016-02-25T19:26:28  <petertodd> btcdrak: I suggest we buy jtimom a time machine so he can do his refactors in the past :)
3212016-02-25T19:26:40  <petertodd> *jtimon
3222016-02-25T19:28:52  <gmaxwell> Any other topics? (we can discuss BIP9 more out of meeting and maybe when sipa has better connectivity?
3232016-02-25T19:29:04  <sipa> i'm going afk now; i'll look at bip9 and 7575 and tests next week
3242016-02-25T19:30:02  <petertodd> I'm working on a tech writeup re: HK
3252016-02-25T19:30:46  <warren> FYI: probably need to be ready to analyze and act on https://mta.openssl.org/pipermail/openssl-announce/2016-February/000063.html if necessary
3262016-02-25T19:31:35  <petertodd> warren: interesting!
3272016-02-25T19:31:38  <gmaxwell> #topic openssl drama again
3282016-02-25T19:31:54  <gmaxwell> our response needs to get openssl out of the software to the greatest extent possible. It's already out of consensus, it's close to out of bitcoind.
3292016-02-25T19:32:37  <gmaxwell> The only thing we don't have an answer for is payment protocol, and the feedback I'm getting is that PP is virtually unused esp in core. We could consider making PP off by default and have a setting in the UI to enable it.
3302016-02-25T19:32:54  <petertodd> gmaxwell: and fortunately, PP isn't consensus critical, which helps a bit
3312016-02-25T19:33:04  <morcos> oh so i don't need to ever bother figuring out what PP is?
3322016-02-25T19:33:10  <petertodd> morcos: payment protocol
3332016-02-25T19:33:16  <gmaxwell> petertodd: still means we need to roll emergency updates for serious openssl vulnerabilties.
3342016-02-25T19:33:27  <morcos> i just mean i haven't looked at the code
3352016-02-25T19:33:43  <warren> Does anyone use rpcssl?
3362016-02-25T19:33:44  *** jtimon has joined #bitcoin-core-dev
3372016-02-25T19:33:46  <petertodd> gmaxwell: interesting question re: PP - does the average install of Bitcoin Core's qt wallet actually let people click on a PP link and have their wallet pop up? if not, strongly suggests it isn't being used much
3382016-02-25T19:33:49  <gmaxwell> It's written in QT, uses QT for HTTP.
3392016-02-25T19:33:52  <gmaxwell> warren: thats gone.
3402016-02-25T19:33:56  <warren> oh good
3412016-02-25T19:34:22  <gmaxwell> petertodd: I know nothing about windows packaging. I did believe we installed a URL handler.
3422016-02-25T19:35:24  <gmaxwell> If PP continues in the long run it should be process seperated at least, I tried to do this before (and also to make it useful from cli/rpc) but the implementation was such that it didn't lend itself to that.
3432016-02-25T19:35:24  <petertodd> gmaxwell: we can always do a release where you need a command line flag to enable it and see if anyone notices :)
3442016-02-25T19:35:56  <gmaxwell> petertodd: thats kind of what I was thinking with the GUI option too "If you've turned this on, please report to..."
3452016-02-25T19:36:32  <petertodd> also, PP w/o multisig has somewhat dubious advantages right now, and even with multisig I'm not sure there are any wallets that really do it well
3462016-02-25T19:37:16  <petertodd> more likely that PP will have worse CA verification than your browser, which benefits from the massive amount of work done to make SSL secure in the face of bad cert authorities
3472016-02-25T19:38:15  <CodeShark> PP is dumb
3482016-02-25T19:38:50  <petertodd> CodeShark: eh, it goes in the right direction, it's just not so useful in the current environment
3492016-02-25T19:39:36  <CodeShark> silly to try to specify it when so many more fundamental things still aren't solved ;)
3502016-02-25T19:39:56  <petertodd> CodeShark: in the far future I'd be surprised if we aren't using something like PP for all txs, probably on a mandatory basis (but I assume treechains will eventually happen!)
3512016-02-25T19:40:02  <gmaxwell> Okay any other topics?
3522016-02-25T19:41:02  <gmaxwell> Otherwise, I'm going to call the end.
3532016-02-25T19:41:15  <petertodd> ack
3542016-02-25T19:41:18  <gmaxwell> #endmeeting
3552016-02-25T19:41:18  <lightningbot> Meeting ended Thu Feb 25 19:41:18 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
3562016-02-25T19:41:18  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-02-25-19.01.html
3572016-02-25T19:41:18  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-02-25-19.01.txt
3582016-02-25T19:41:18  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-02-25-19.01.log.html
3592016-02-25T19:41:21  <gmaxwell> thanks everyone.
3602016-02-25T19:41:25  <btcdrak> thank you!
3612016-02-25T19:41:28  <paveljanik> Let's celebrate #400000 :-)
3622016-02-25T19:41:37  <jonasschnelli> \o/
3632016-02-25T19:41:44  <morcos> and hope we make it to 500000
3642016-02-25T19:41:57  <sdaftuar> if we're lucky we'll get lots of 500000's
3652016-02-25T19:42:02  <petertodd> paveljanik: why? why not celibrate an important number like 524288?
3662016-02-25T19:42:05  <btcdrak> LOL
3672016-02-25T19:42:18  <paveljanik> sdaftuar, ;-)
3682016-02-25T19:42:36  <paveljanik> sdaftuar, so many to choose from :-)
3692016-02-25T19:43:30  <petertodd> paveljanik: I'm also partial to 0x6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000
3702016-02-25T19:44:13  <paveljanik> sdaftuar, maybe we can patch UI to help user to select from all #500000s ;-)
3712016-02-25T19:45:59  *** achow101 has quit IRC
3722016-02-25T19:48:35  <sdaftuar> paveljanik: :)
3732016-02-25T19:51:05  *** belcher has joined #bitcoin-core-dev
3742016-02-25T19:52:09  <CodeShark> petertodd: my comment regarding PP is not to be understood to mean such layers aren't necessary...but that I think such specification is premature
3752016-02-25T19:53:23  <CodeShark> It's sorta like trying to specify ssl before we've even specified tcp
3762016-02-25T20:07:27  <zooko> Does the payment protocol use Bitcoin private (signing) keys?
3772016-02-25T20:07:56  <jtimon> petertodd: lol, actually you guys need the time machine to review my code in the past, most of what's in https://github.com/jtimon/bitcoin/tree/libconsensus-p3 / https://github.com/jtimon/bitcoin/tree/jt I had coded in some way or another for long (although I constantly rewrite history to try to have the "most mergeable things" as the first commits)
3782016-02-25T20:09:52  <jtimon> btcdrak: fwiw all my consensus PRs merged since 0.12 's fork are already backported (with anything that would make the rebase less clean) in https://github.com/jtimon/bitcoin/tree/backports-0.12 in case they were necessary for backporting SF functionality
3792016-02-25T20:10:17  <btcdrak> jtimon: great.
3802016-02-25T20:11:29  <sipa> zooko: no
3812016-02-25T20:11:36  <sipa> it uses ssl :(
3822016-02-25T20:12:37  <zooko> Great, so no matter how badly screwed up this new openssl announcement is, openssl isn't being given the opportunity to touch Bitcoin signing keys.
3832016-02-25T20:12:41  <zooko> In current Bitcoin core.
3842016-02-25T20:13:06  <zooko> Although I fully agree that "No openssl anywhere near our codebase" is a desirable goal.
3852016-02-25T20:14:17  <paveljanik> zooko, who created them then? ;-)
3862016-02-25T20:17:08  <jtimon> CodeShark: when I first reviewed your BIP9 implementation I first complained aboutthe start time but then reading the code more was convinced that it could actually simplify the implementation, after implementing it myself, I realized it does not simplify things, but it's just a couple of extra lines for a very reaonable feature (specially needed if we are ever going to use versionbits for hardfork deployment as recommended by
3872016-02-25T20:17:08  <jtimon> bip99 anyway)
3882016-02-25T20:17:42  <jtimon> I feel sorry for you that it wasn't incorporated to spec at the time
3892016-02-25T20:19:40  <jtimon> sipa starttime is block.nTime based? we're using median time for the timeout
3902016-02-25T20:20:39  *** treehug88 has quit IRC
3912016-02-25T20:22:26  <sipa> jtimon: yes, mediantimepast
3922016-02-25T20:22:45  <sipa> jtimon: i mean it is not based on the real clock time, it deoends on the block chain only
3932016-02-25T20:23:57  <btcdrak> I can't believe I missed the start time detail
3942016-02-25T20:25:34  *** zooko has quit IRC
3952016-02-25T20:26:31  <jtimon> btw, my wip bip9 implementation is #7566 I started before sipa but got distracted maximizing its libconsensus friendly-ness and...sipa codes faster than me
3962016-02-25T20:27:18  <jtimon> in any case, it seems we're both copying a little bit of code from one another since we found out we were both working on it
3972016-02-25T20:48:13  <GitHub136> [bitcoin] sdaftuar opened pull request #7600: [WIP] Mining: Select transactions using feerate-with-ancestors (master...ancestor-mining) https://github.com/bitcoin/bitcoin/pull/7600
3982016-02-25T20:50:25  *** Guyver2 has joined #bitcoin-core-dev
3992016-02-25T20:52:10  <instagibbs> what's the correct way to flush the wallet db? I'm "zapping" individual transactions and internal accounting doesn't realize this until I shut down and start back up.
4002016-02-25T20:53:23  <jonasschnelli> instagibbs: hmm... could be a bud. Can you explain how you do a "zapping"?
4012016-02-25T20:53:27  <jonasschnelli> bug
4022016-02-25T20:53:36  <sipa> instagibbs: what do you mean by flush?
4032016-02-25T20:54:40  <GitHub141> [bitcoin] ebfull opened pull request #7601: [WIP] HTLC implementation in the wallet (master...zkcp) https://github.com/bitcoin/bitcoin/pull/7601
4042016-02-25T20:55:22  <instagibbs> jonasschnelli, I'm rolling my own, which is probably why it's my fault. I'm calling EraseTx.
4052016-02-25T20:55:58  <instagibbs> i run my code, check listunspent/listreceivedbyX, transactions are still there. If I shut down, start back up, they're gone.
4062016-02-25T20:56:23  <jonasschnelli> call `void CWallet::MarkDirty()`=
4072016-02-25T20:56:29  <jonasschnelli> s/=/?
4082016-02-25T20:56:31  <instagibbs> ah the whole wallet?
4092016-02-25T20:56:33  <instagibbs> makes sense
4102016-02-25T20:57:02  <jonasschnelli> hmm... but you can't marke the erased wtx as dirty. :)... not sure if it works.
4112016-02-25T20:57:20  <instagibbs> heh, ill test
4122016-02-25T20:57:34  <sipa> if you erase a tx, you need to dirty all the transactions that it's spending coins from
4132016-02-25T20:57:46  <jonasschnelli> Wait... you only call EraseTx?!
4142016-02-25T20:57:53  <jonasschnelli> You also need to remove it from the in memory map
4152016-02-25T20:58:12  <instagibbs> that could definitely explain it yes
4162016-02-25T20:58:16  <sipa> the mempool?
4172016-02-25T20:58:20  <jonasschnelli> no... :)
4182016-02-25T20:58:30  <jonasschnelli> mapWallet
4192016-02-25T20:58:39  <jonasschnelli> <const uint256, CWalletTx>
4202016-02-25T20:58:47  <sipa> i was assuming that that's exactly what EraseTx does
4212016-02-25T20:58:54  <instagibbs> nope from the wallet itself
4222016-02-25T20:59:03  <instagibbs> ZapWalletTxns calls it on aLL THE THINGS
4232016-02-25T20:59:05  <sipa> oh, from the database?
4242016-02-25T20:59:12  <sipa> the database has no effect on runtime
4252016-02-25T20:59:15  <jonasschnelli> probably you should do: 1. remove from mapWallet, 2. remove from DB (eraseTx), mark whole wallet as dirty
4262016-02-25T20:59:20  <sipa> we only read from it at startup
4272016-02-25T20:59:25  <instagibbs> i see ok cool
4282016-02-25T20:59:27  <instagibbs> so yeah
4292016-02-25T20:59:29  <instagibbs> map
4302016-02-25T20:59:34  <instagibbs> thanks jonasschnelli i think that'll do it
4312016-02-25T20:59:46  <jonasschnelli> And PR your work. We need a runtime zap wallet tx functionality!
4322016-02-25T20:59:51  <instagibbs> I know!
4332016-02-25T21:00:00  <instagibbs> belcher was bitching about it in pruned mode :)
4342016-02-25T21:00:13  <instagibbs> and i coded the reverse(importprunedfunds), so figured i should do it
4352016-02-25T21:00:25  <belcher> to clarify, i was not bitching
4362016-02-25T21:00:35  <jonasschnelli> yes. You probably can't zap in prune because of missing rescan functionality
4372016-02-25T21:00:44  <jonasschnelli> belcher: lol
4382016-02-25T21:00:46  <instagibbs> ;)
4392016-02-25T21:01:32  <instagibbs> jonasschnelli, right, you can't do that zap, so im making no-rescan equiv
4402016-02-25T21:02:30  <jonasschnelli> instagibbs: also keep an eye on the "abandontransaction" RPC function
4412016-02-25T21:02:57  <jonasschnelli> Could be saver for most usecases then just zapping.
4422016-02-25T21:22:09  *** drnet has joined #bitcoin-core-dev
4432016-02-25T21:32:57  *** Guyver2 has quit IRC
4442016-02-25T21:34:15  *** drnet has quit IRC
4452016-02-25T21:41:59  <GitHub22> [bitcoin] instagibbs opened pull request #7602: [WIP] [RPC] Add call zaptransaction to delete transaction from wallet (master...zaponetx) https://github.com/bitcoin/bitcoin/pull/7602
4462016-02-25T21:43:09  *** danielsocials has joined #bitcoin-core-dev
4472016-02-25T21:48:03  *** danielsocials has quit IRC
4482016-02-25T21:49:40  <jtimon> sipa btcdrak I was going to comment on https://github.com/sipa/bitcoin/commit/99f66325e83f8da3b5dfe38cad4f5fdc60bca05a#commitcomment-16313065 but I thought IRC could be more appropriate:
4492016-02-25T21:49:40  <jtimon> See my other comment bike-shedding the enumerator.
4502016-02-25T21:49:40  <jtimon> I think it makes a lot of sense that BIP68 and BIP112 are deployed together (in fact, I would have been happy if they had been a single BIP), but I'm not so sure about BIP113.
4512016-02-25T21:49:40  <jtimon> @petertodd mentioned that BIP68 required more testing and that's why I went with BIP113 in my implementation (although I'm happy to change it to something else and that will probably mean less code in my PR).
4522016-02-25T21:49:40  <jtimon> Assuming BIP9 was reviewed, tested and ready for merge, what would be the BIPs from this 3 that are ready to be deployed right now (modulo backports)?
4532016-02-25T21:49:42  <jtimon> 
4542016-02-25T21:53:13  <jtimon> BIP113 is ready, right? or do we plan to wait some more time of it being deployed as relay policy ?
4552016-02-25T21:55:12  <midnightmagic> I really like this, from the OpenSSL team: "You can not pay us to get security patches in advance."
4562016-02-25T21:55:17  <midnightmagic> good for them.
4572016-02-25T21:56:40  *** zooko has joined #bitcoin-core-dev
4582016-02-25T22:01:26  *** jujumax has joined #bitcoin-core-dev
4592016-02-25T22:04:33  *** AaronvanW_ has quit IRC
4602016-02-25T22:12:18  *** Expanse has joined #bitcoin-core-dev
4612016-02-25T22:30:16  *** MarcoFalke has quit IRC
4622016-02-25T22:51:34  *** Thireus1 has quit IRC
4632016-02-25T22:52:33  *** Thireus has joined #bitcoin-core-dev
4642016-02-25T23:03:41  *** laurentmt has joined #bitcoin-core-dev
4652016-02-25T23:17:07  *** Chris_Stewart_5 has joined #bitcoin-core-dev
4662016-02-25T23:28:31  *** AaronvanW has joined #bitcoin-core-dev
4672016-02-25T23:28:32  *** AaronvanW has quit IRC
4682016-02-25T23:28:32  *** AaronvanW has joined #bitcoin-core-dev
4692016-02-25T23:29:37  *** randy-waterhouse has joined #bitcoin-core-dev
4702016-02-25T23:40:23  <jtimon> sipa sorry for the bunch of comments in #7575, I edited some of them to make clear they are not very important
4712016-02-25T23:40:24  <jtimon> the difference between my implementation and yours that worries me the most is https://github.com/bitcoin/bitcoin/pull/7575/files#r54179238
4722016-02-25T23:41:34  <gmaxwell> midnightmagic: the last time they did one of these timed code dumps they also had run the code through a reformat so it was impossible to easily tell what they changed.
4732016-02-25T23:44:33  *** danielsocials has joined #bitcoin-core-dev
4742016-02-25T23:47:33  <jtimon> one test case comes to mind that my explain my point better: my implementation should be fine if you have if you schedule 3 different deployments for the same bit on the same date (or in three consecutive days), even if each of them takes 3 months to be deployed (the other ones will just wait)
4752016-02-25T23:48:20  <jtimon> sipa I believe your implementation would currently fail that test (assuming the test is properly implemented)
4762016-02-25T23:49:33  <jtimon> I'm not sure I'm explaining myself...
4772016-02-25T23:54:12  <jtimon> but sipa is probably busy, so, never mind, I will maintain the "can queue new deployments on utilized bits without knowing when the previous started deployments on that bit will be activated" feature in mind for now, even if I still don't see a clean wait of making that feature with nicely separating the warning code (while still reusing a lot of code) like you've done
4782016-02-25T23:57:29  *** danielsocials has quit IRC
4792016-02-25T23:57:33  <jtimon> in the meantime, I think I will decouple my PR from BIP113 (I don't know why #7565 is currently failing in travis anyway, but doesn't inspire confidence) and use BIP112 as example as well
4802016-02-25T23:59:41  <jtimon> I guess I should also decouple it from the two first commits in #7563 as well to make it easier to review and compare with #7575