12016-07-21T00:02:17 *** jiggalator has joined #bitcoin-core-dev
22016-07-21T00:13:28 *** belcher has quit IRC
32016-07-21T00:23:22 *** alpalp has quit IRC
42016-07-21T00:34:45 *** jiggalator is now known as netsin
52016-07-21T00:35:35 *** fengling has joined #bitcoin-core-dev
62016-07-21T00:35:51 <phantomcircuit> jonasschnelli, can you check 8152 again
72016-07-21T00:40:06 *** fengling has quit IRC
82016-07-21T00:42:55 *** fengling has joined #bitcoin-core-dev
92016-07-21T00:45:56 *** alpalp has joined #bitcoin-core-dev
102016-07-21T00:45:56 *** alpalp has joined #bitcoin-core-dev
112016-07-21T00:59:41 <PRab> Is there a way to have github notify you when there is a new tag?
122016-07-21T01:00:54 <PRab> nm, I should know to google first.
132016-07-21T01:00:59 <PRab> https://github.com/bitcoin/bitcoin/tags.atom works
142016-07-21T01:03:08 *** CubicEarth has joined #bitcoin-core-dev
152016-07-21T01:05:14 *** frankenmint has quit IRC
162016-07-21T01:05:30 *** netsin has quit IRC
172016-07-21T01:08:25 *** alpalp has quit IRC
182016-07-21T01:09:51 *** netsin has joined #bitcoin-core-dev
192016-07-21T01:15:35 <PRab> Testing 0.13.0rc1 from my gitian build. Looks like it upgraded smoothly from 0.12.1 and is working properly for me (Win7 64bit).
202016-07-21T01:15:48 *** Ylbam has quit IRC
212016-07-21T01:16:37 *** netsin has quit IRC
222016-07-21T01:24:08 *** JackH has quit IRC
232016-07-21T01:24:36 *** AaronvanW has quit IRC
242016-07-21T01:31:02 *** Giszmo has joined #bitcoin-core-dev
252016-07-21T01:34:04 *** Giszmo1 has quit IRC
262016-07-21T01:40:34 *** alpalp has joined #bitcoin-core-dev
272016-07-21T01:40:35 *** alpalp has joined #bitcoin-core-dev
282016-07-21T01:54:18 *** jtimon has quit IRC
292016-07-21T01:54:19 *** davec has quit IRC
302016-07-21T01:54:58 *** davec has joined #bitcoin-core-dev
312016-07-21T01:56:46 *** fengling has quit IRC
322016-07-21T01:56:54 *** fengling_ has joined #bitcoin-core-dev
332016-07-21T02:12:29 *** CubicEarth has quit IRC
342016-07-21T02:17:29 *** netsin has joined #bitcoin-core-dev
352016-07-21T02:23:11 *** netsin has quit IRC
362016-07-21T02:33:18 *** TomMc has quit IRC
372016-07-21T02:39:53 *** netsin has joined #bitcoin-core-dev
382016-07-21T02:41:24 *** netsin has quit IRC
392016-07-21T02:43:05 *** netsin has joined #bitcoin-core-dev
402016-07-21T02:44:17 *** netsin has quit IRC
412016-07-21T02:58:10 *** CubicEarth has joined #bitcoin-core-dev
422016-07-21T03:01:05 *** alpalp has quit IRC
432016-07-21T03:10:11 *** Chris_Stewart_5 has quit IRC
442016-07-21T03:13:40 *** netsin has joined #bitcoin-core-dev
452016-07-21T03:16:12 *** supasonic has quit IRC
462016-07-21T03:45:46 *** fengling_ has quit IRC
472016-07-21T03:55:27 *** fengling_ has joined #bitcoin-core-dev
482016-07-21T04:02:46 *** fengling_ has quit IRC
492016-07-21T04:04:40 *** CubicEarth has quit IRC
502016-07-21T04:06:11 *** netsin has quit IRC
512016-07-21T04:09:14 *** netsin has joined #bitcoin-core-dev
522016-07-21T04:14:22 *** netsin has quit IRC
532016-07-21T04:31:59 *** netsin has joined #bitcoin-core-dev
542016-07-21T04:37:44 *** fengling_ has joined #bitcoin-core-dev
552016-07-21T04:47:47 *** netsin has quit IRC
562016-07-21T07:19:08 *** Ylbam has joined #bitcoin-core-dev
572016-07-21T07:20:55 *** paveljanik has quit IRC
582016-07-21T07:39:34 *** AaronvanW has joined #bitcoin-core-dev
592016-07-21T07:39:34 *** AaronvanW has quit IRC
602016-07-21T07:39:34 *** AaronvanW has joined #bitcoin-core-dev
612016-07-21T07:53:47 *** laurentmt has joined #bitcoin-core-dev
622016-07-21T08:20:38 *** blur3d has joined #bitcoin-core-dev
632016-07-21T08:22:05 *** blur3d has quit IRC
642016-07-21T08:41:10 *** spudowiar has joined #bitcoin-core-dev
652016-07-21T08:48:52 *** fengling_ is now known as fengling
662016-07-21T08:53:39 <NicolasDorier> wumpus: can you merge https://github.com/bitcoin/bitcoin/pull/8342 and https://github.com/bitcoin/bitcoin/pull/8341 when you have time (two trivial already acked commits)
672016-07-21T08:55:55 <NicolasDorier> ha and https://github.com/bitcoin/bitcoin/pull/8347
682016-07-21T08:56:28 <NicolasDorier> all trivial stuff so jtimon and me can rebase our independant work on top of it and have smaller future PR
692016-07-21T09:05:03 *** harrymm has quit IRC
702016-07-21T09:21:33 *** harrymm has joined #bitcoin-core-dev
712016-07-21T09:34:58 *** spudowiar has quit IRC
722016-07-21T09:38:19 *** pedrobranco has joined #bitcoin-core-dev
732016-07-21T09:43:52 <wumpus> yes, makes sense
742016-07-21T09:46:21 *** pedrobranco has quit IRC
752016-07-21T09:47:27 *** pedrobranco has joined #bitcoin-core-dev
762016-07-21T09:47:31 *** owowo has quit IRC
772016-07-21T09:54:23 *** owowo has joined #bitcoin-core-dev
782016-07-21T09:57:22 <GitHub64> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/8e048f40cc25...6f4092da80bc
792016-07-21T09:57:22 <GitHub64> bitcoin/master a3e1984 NicolasDorier: Consensus: Trivial transform BOOST_FOREACH into for loop
802016-07-21T09:57:23 <GitHub64> bitcoin/master 6f4092d Wladimir J. van der Laan: Merge #8342: Consensus: Trivial transform BOOST_FOREACH into for loop...
812016-07-21T09:57:34 <GitHub69> [bitcoin] laanwj closed pull request #8342: Consensus: Trivial transform BOOST_FOREACH into for loop (master...removeforeach) https://github.com/bitcoin/bitcoin/pull/8342
822016-07-21T10:01:55 *** JackH has joined #bitcoin-core-dev
832016-07-21T10:16:52 *** jtimon has joined #bitcoin-core-dev
842016-07-21T10:20:32 *** jannes has joined #bitcoin-core-dev
852016-07-21T10:48:20 *** Guyver2 has joined #bitcoin-core-dev
862016-07-21T10:50:06 *** Sosumi has quit IRC
872016-07-21T10:53:16 *** cryptapus has joined #bitcoin-core-dev
882016-07-21T10:56:10 *** btcfan has joined #bitcoin-core-dev
892016-07-21T11:32:09 *** btcfan has quit IRC
902016-07-21T11:33:04 *** laurentmt has quit IRC
912016-07-21T11:36:44 *** pmienk has quit IRC
922016-07-21T11:45:41 *** laurentmt has joined #bitcoin-core-dev
932016-07-21T11:49:17 *** pmienk has joined #bitcoin-core-dev
942016-07-21T12:02:03 <NicolasDorier> wumpus: I just rebased https://github.com/bitcoin/bitcoin/pull/8341 (the second stupid trivial one)
952016-07-21T12:02:17 <wumpus> NicolasDorier: thanks
962016-07-21T12:10:04 <GitHub43> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/6f4092da80bc...04af3cfe8fa9
972016-07-21T12:10:04 <GitHub43> bitcoin/master 7821889 NicolasDorier: Consensus: Remove calls to error() from ContextualCheckBlock
982016-07-21T12:10:04 <GitHub43> bitcoin/master 04af3cf Wladimir J. van der Laan: Merge #8341: Consensus: Remove calls to error() from ContextualCheckBlock...
992016-07-21T12:10:13 <GitHub57> [bitcoin] laanwj closed pull request #8341: Consensus: Remove calls to error() from ContextualCheckBlock (master...error-calls) https://github.com/bitcoin/bitcoin/pull/8341
1002016-07-21T12:12:19 *** TomMc has joined #bitcoin-core-dev
1012016-07-21T12:17:57 *** Chris_Stewart_5 has joined #bitcoin-core-dev
1022016-07-21T12:20:06 *** fengling has quit IRC
1032016-07-21T12:26:57 <NicolasDorier> wumpus: last is https://github.com/bitcoin/bitcoin/pull/8347 of jtimon and I let you sleep in peace
1042016-07-21T12:28:45 <NicolasDorier> wumpus: woops, wait
1052016-07-21T12:28:50 <wumpus> OH I was misreading that, looking at the github page it seemed like jtimon was still adding commits to it, but it says "added a commit to jtimon/bitcoin that referenced this pull request", I think that's new?
1062016-07-21T12:28:57 <sipa> i don't expect wumpus to sleep at 2:30 pm
1072016-07-21T12:28:59 <sipa> :)
1082016-07-21T12:29:20 <wumpus> I have a strange sleep/wake rhythm sometimes, but no, I don't expect so either :-)
1092016-07-21T12:29:22 <NicolasDorier> yeah, I just saw that too sorry, last time I checked was only the const change :p
1102016-07-21T12:29:31 <btcdrak> sipa: I dont expect him to sleep at all. I will buy some match sticks to keep his eyes open 24/7
1112016-07-21T12:30:07 <sipa> btcdrak: quality of review may suffer slightly...
1122016-07-21T12:30:10 <wumpus> it *is* only the const change, github is just making it confusing
1132016-07-21T12:30:34 <NicolasDorier> oh indeed
1142016-07-21T12:30:51 <NicolasDorier> got confused as well
1152016-07-21T12:31:56 <GitHub37> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/04af3cfe8fa9...381917f610e3
1162016-07-21T12:31:56 <GitHub37> bitcoin/master 6f3d616 Jorge Timón: Trivial: Make CBlockIndex param const in ContextualCheckBlockHeader and ContextualCheckBlock
1172016-07-21T12:31:57 <GitHub37> bitcoin/master 381917f Wladimir J. van der Laan: Merge #8347: Trivial: Make CBlockIndex param const in ContextualCheckBlockHeader and ContextualCheckBlock...
1182016-07-21T12:32:08 <GitHub87> [bitcoin] laanwj closed pull request #8347: Trivial: Make CBlockIndex param const in ContextualCheckBlockHeader and ContextualCheckBlock (master...0.12.99-consensus-const-lost) https://github.com/bitcoin/bitcoin/pull/8347
1192016-07-21T12:34:58 <NicolasDorier> thanks
1202016-07-21T12:40:52 <jtimon> awesome, thanks guys
1212016-07-21T12:41:42 <jtimon> NicolasDorier: regarding some of our diffenrces in getflags parameters, they will be resolved by removing issupermajority instead of moving it
1222016-07-21T12:44:29 <NicolasDorier> ooooh that's super cool if we can remove it
1232016-07-21T12:44:41 <NicolasDorier> how? hard coding the activations ?
1242016-07-21T12:44:53 <btcdrak> NicolasDorier: this was the discussion on it https://botbot.me/freenode/bitcoin-core-dev/2016-07-17/?msg=69776851&page=1
1252016-07-21T12:45:36 *** Chris_Stewart_5 has quit IRC
1262016-07-21T12:47:12 <NicolasDorier> oh cool
1272016-07-21T12:49:21 *** Chris_Stewart_5 has joined #bitcoin-core-dev
1282016-07-21T12:52:13 <GitHub111> [bitcoin] NicolasDorier closed pull request #8344: Consensus: Use pindex for ISM check (master...not-using-block) https://github.com/bitcoin/bitcoin/pull/8344
1292016-07-21T12:52:38 *** harrymm has quit IRC
1302016-07-21T12:53:03 *** rubensayshi has joined #bitcoin-core-dev
1312016-07-21T12:54:30 <NicolasDorier> gmaxwell: do you plan to make a PR soon about removing ISM completely ? I can work on redoing it if needed, it simplify the code I'm writing for verifyBlock in consensuslib
1322016-07-21T13:00:21 *** YOU-JI has joined #bitcoin-core-dev
1332016-07-21T13:09:07 *** harrymm has joined #bitcoin-core-dev
1342016-07-21T13:09:24 <jtimon> btw, https://github.com/bitcoin/bitcoin/pull/8348 and https://github.com/bitcoin/bitcoin/pull/8346 are pretty trivial too
1352016-07-21T13:11:38 <jtimon> NicolasDorier: yeah, hardcoding the activations in Consensus::Params like CodeShark did with bip34, the other day gmaxwell said he was working on suh a branch
1362016-07-21T13:12:13 <jtimon> Ideally we would use an array, I wish I had seen the PR for BIP34 when it was open...
1372016-07-21T13:13:32 <jtimon> I'm happy to write that too, the hardest part for me would be too look at the heights and block hashes
1382016-07-21T13:16:50 <jtimon> but yeah, whoever writes it, it simplifies things for libconsensus encapsulation
1392016-07-21T13:50:12 *** Guyver2 has quit IRC
1402016-07-21T13:53:10 *** YOU-JI has quit IRC
1412016-07-21T13:54:08 *** rubensayshi has quit IRC
1422016-07-21T14:18:51 *** fengling has joined #bitcoin-core-dev
1432016-07-21T14:20:26 <GitHub197> [bitcoin] jtimon closed pull request #8345: Introduce Consensus::GetFlags() and hide IsSuperMajority() (master...0.12.99-consensus-flags) https://github.com/bitcoin/bitcoin/pull/8345
1442016-07-21T14:23:46 *** fengling has quit IRC
1452016-07-21T14:38:31 *** Chris_Stewart_5 has quit IRC
1462016-07-21T14:43:12 *** harrymm has quit IRC
1472016-07-21T14:53:30 *** Chris_Stewart_5 has joined #bitcoin-core-dev
1482016-07-21T14:53:34 <jtimon> sipa: I've been thinking more about the consensus vs script flags, I guess it has the advantage of having a much shorter list of consensus flags, basically only one per consensus deployment (well, we can keep bip68 and bip112 as separated flags), while the script flags have many more thant in principle don't need to be exposed in libconsensus
1492016-07-21T14:54:37 <sipa> jtimon: right; if the script code is at some point duplicated to form a consensus-only form, we could combine the flags there
1502016-07-21T14:55:04 <sipa> but as long as the script code is more generically useful, it will have flags that are not necessarily consensus, and it feels cleaner to have the script code independent
1512016-07-21T14:56:09 <jtimon> but I still believe that the refactor is much simpler if we put temporarily the locktime flags and the new ones (bip30 and bip34) in the script flags and then we separate them
1522016-07-21T14:58:08 *** harrymm has joined #bitcoin-core-dev
1532016-07-21T14:58:45 <jtimon> those non consensus script flags are hidden behind the flags in script/bitcoinconsensus.h for libconsensus anyway, that's why I wasn't seeing the point at first
1542016-07-21T15:00:26 <jtimon> probably that's where the consensus flags should be instead of consensus/falgs.h as previously suggested, but then main would need to include script/bitcoinconsensus.h
1552016-07-21T15:01:12 <jtimon> s/falgs/flags
1562016-07-21T15:04:01 <jtimon> mhmm, no converter is necessary if the flags in script/bitcoinconsensus.h and script/interpreter.h just keep matching in their bit numbers...
1572016-07-21T15:04:31 <sipa> that's a terrible idea
1582016-07-21T15:04:46 <sipa> i've argued several times that they should be made independent
1592016-07-21T15:05:02 <sipa> internal constants should not leak into a public API
1602016-07-21T15:05:05 <jtimon> I also prefer the converter function, but that's what we're doing right now
1612016-07-21T15:05:19 <jtimon> makes sense
1622016-07-21T15:05:43 <jtimon> ok, this helps me understand your whole reasoning much better, thanks
1632016-07-21T15:05:57 <sipa> but yes, that is what we're currently doing - but i wouldn't extend that practice further
1642016-07-21T15:07:50 <jtimon> I'll write a converter function and see how disruptive it looks compared with temporarily putting non-script flags in script/interpreter.h
1652016-07-21T15:10:27 <jtimon> erik from libbitcoin also complained about the flags, I believe that was one of the reasons they don't use our API directly and copy the code instead, but IIRC the main one is having to serialize/decerialize the tx to be signed
1662016-07-21T15:12:42 <jtimon> should talk to him again to remind me his thoughts
1672016-07-21T15:15:22 <jtimon> in fact, I should have taken notes
1682016-07-21T15:15:51 <jtimon> I have a very good reason for trusting my memory instead of taking notes most of the time, but I forgot what it was ;)
1692016-07-21T15:16:24 <sipa> hahaha
1702016-07-21T15:20:52 *** fengling has joined #bitcoin-core-dev
1712016-07-21T15:25:26 *** fengling has quit IRC
1722016-07-21T15:26:40 *** pedrobranco has quit IRC
1732016-07-21T15:27:07 *** pedrobranco has joined #bitcoin-core-dev
1742016-07-21T15:30:25 *** pedrobranco has quit IRC
1752016-07-21T15:30:47 *** pedrobranco has joined #bitcoin-core-dev
1762016-07-21T15:32:22 <GitHub188> [bitcoin] laanwj pushed 2 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/66dde4edf733...cbdbc75139a6
1772016-07-21T15:32:22 <GitHub188> bitcoin/0.13 f891e34 Jannes Faber: fix typo: propagation relay -> delay
1782016-07-21T15:32:23 <GitHub188> bitcoin/0.13 cbdbc75 Wladimir J. van der Laan: Merge #8380: fix typo: propagation relay -> delay...
1792016-07-21T15:32:26 <GitHub33> [bitcoin] laanwj closed pull request #8380: fix typo: propagation relay -> delay (0.13...patch-1) https://github.com/bitcoin/bitcoin/pull/8380
1802016-07-21T15:48:31 *** Chris_Stewart_5 has quit IRC
1812016-07-21T15:50:59 *** Guyver2 has joined #bitcoin-core-dev
1822016-07-21T15:54:03 <GitHub75> [bitcoin] laanwj closed pull request #8374: Add release notes for mining changes (0.13...release-notes-mining) https://github.com/bitcoin/bitcoin/pull/8374
1832016-07-21T15:54:05 <GitHub67> [bitcoin] laanwj pushed 2 new commits to 0.13: https://github.com/bitcoin/bitcoin/compare/cbdbc75139a6...76bc30beab86
1842016-07-21T15:54:05 <GitHub67> bitcoin/0.13 52a4158 Suhas Daftuar: Add release notes for mining changes
1852016-07-21T15:54:06 <GitHub67> bitcoin/0.13 76bc30b Wladimir J. van der Laan: Merge #8374: Add release notes for mining changes...
1862016-07-21T15:54:57 <luke-jr> â¦
1872016-07-21T15:58:39 <wumpus> luke-jr: you can do your proposed changes now
1882016-07-21T15:59:51 * luke-jr wonders why his 0.10 won't compile anymore. :x
1892016-07-21T16:02:41 * Lightsword wonders why luke-jr is using 0.10
1902016-07-21T16:02:42 *** frankenmint has joined #bitcoin-core-dev
1912016-07-21T16:03:35 <luke-jr> Lightsword: my hot wallet has too much in it to risk upgrading yet; I should probably deal with that
1922016-07-21T16:03:46 *** spudowiar has joined #bitcoin-core-dev
1932016-07-21T16:04:25 <Lightsword> luke-jr, canât you just backup wallet.dat before doing anything with latest version?
1942016-07-21T16:04:58 <luke-jr> Lightsword: sure, but bdb issues are the least probable kind of loss
1952016-07-21T16:05:35 <luke-jr> I have no particular concerns, just don't like to use new code with lots of funds
1962016-07-21T16:05:55 <Lightsword> what are the other probable kind?
1972016-07-21T16:06:28 <luke-jr> Lightsword: sending the wrong amount somewhere, or to fee
1982016-07-21T16:06:47 * Lightsword wonders why that would be less likely to happen with an older wallet
1992016-07-21T16:07:25 <luke-jr> no changes to the old code
2002016-07-21T16:07:56 <luke-jr> the usual reason stable software is preferred over bleeding edge
2012016-07-21T16:08:27 <luke-jr> anyhow, looks like it was a build system issue, and got it to build
2022016-07-21T16:08:28 <Lightsword> yeahâ¦but 0.10â¦is two releases behind the latest stable
2032016-07-21T16:09:11 <luke-jr> not even a year old
2042016-07-21T16:09:21 <luke-jr> 0.10.4 was released 2015 Nov
2052016-07-21T16:09:55 <Lightsword> I thought 0.11.2 or whatever was earlier since 0.10.4 was a backport
2062016-07-21T16:12:24 <luke-jr> v0.11.0 was 2015 Jul
2072016-07-21T16:12:33 <luke-jr> only a year
2082016-07-21T16:22:02 *** fengling has joined #bitcoin-core-dev
2092016-07-21T16:26:46 *** fengling has quit IRC
2102016-07-21T16:34:10 *** aalex has quit IRC
2112016-07-21T16:34:30 *** netsin has joined #bitcoin-core-dev
2122016-07-21T16:35:27 *** aalex has joined #bitcoin-core-dev
2132016-07-21T16:46:58 *** sipa has quit IRC
2142016-07-21T16:46:58 *** sipa has joined #bitcoin-core-dev
2152016-07-21T16:50:39 *** netsin has quit IRC
2162016-07-21T17:01:33 <GitHub177> [bitcoin] luke-jr opened pull request #8386: mining: Optimise for typical mining use with blockmaxsize (master...blockmaxsize_opti) https://github.com/bitcoin/bitcoin/pull/8386
2172016-07-21T17:01:53 <GitHub184> [bitcoin] luke-jr opened pull request #8387: [0.13] mining: Optimise for typical mining use with blockmaxsize (master...blockmaxsize_opti-0.13) https://github.com/bitcoin/bitcoin/pull/8387
2182016-07-21T17:02:01 <GitHub33> [bitcoin] luke-jr closed pull request #8387: [0.13] mining: Optimise for typical mining use with blockmaxsize (master...blockmaxsize_opti-0.13) https://github.com/bitcoin/bitcoin/pull/8387
2192016-07-21T17:02:38 <GitHub51> [bitcoin] luke-jr opened pull request #8388: [0.13] mining: Optimise for typical mining use with blockmaxsize (0.13...blockmaxsize_opti-0.13) https://github.com/bitcoin/bitcoin/pull/8388
2202016-07-21T17:03:13 *** frankenmint has quit IRC
2212016-07-21T17:06:12 *** spudowiar has quit IRC
2222016-07-21T17:09:22 *** MarcoFalke has joined #bitcoin-core-dev
2232016-07-21T17:21:16 *** netsin has joined #bitcoin-core-dev
2242016-07-21T17:23:57 *** fengling has joined #bitcoin-core-dev
2252016-07-21T17:28:26 *** fengling has quit IRC
2262016-07-21T17:28:34 *** TomMc has quit IRC
2272016-07-21T17:41:00 *** spudowiar has joined #bitcoin-core-dev
2282016-07-21T17:45:03 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2292016-07-21T17:48:44 <gmaxwell> are there NO web block explorers that show transaction version numbers?!
2302016-07-21T17:52:12 <gmaxwell> hmph, when connecting blocks at start RPC can return "Loading banlist" for the duration...
2312016-07-21T17:53:01 <wumpus> gmaxwell: known issue https://github.com/bitcoin/bitcoin/issues/8117
2322016-07-21T17:54:55 <wumpus> it's supposed to release the lock every block, but sometimes it appears it doesn't
2332016-07-21T17:55:33 <roasbeef> gmaxwell: smartbit and http://srv1.yogh.io/ do, a few other do as well but can't recall off the top atm
2342016-07-21T17:55:39 *** murch has joined #bitcoin-core-dev
2352016-07-21T17:56:46 *** wangchun has quit IRC
2362016-07-21T18:00:06 <achow101> gmaxwell: blockcypher does under "advanced details"
2372016-07-21T18:03:02 <jonasschnelli> <phantomcircuit:#bitcoin-core-dev> jonasschnelli, can you check 8152 again
2382016-07-21T18:03:14 <jonasschnelli> Yes. Will do.
2392016-07-21T18:05:39 <sipa> wumpus: i think we should try adding a yield and see if there is a performance degradation
2402016-07-21T18:06:51 <sipa> wumpus: in ActivateBestChain
2412016-07-21T18:07:34 <gmaxwell> roasbeef: achow101: Thanks, I tried like 5 of them before giving up.
2422016-07-21T18:09:54 <wumpus> sipa: Iworth a try I guess
2432016-07-21T18:10:52 <sipa> wumpus: as far as i know there is no guarantee that the scheduler gives a fair distribution of cpu time in case there are multiple waiting threads
2442016-07-21T18:11:26 <sipa> in ActivateBestChain we release cs_main but pretty much instantly grab it agaim
2452016-07-21T18:11:27 <wumpus> there is no guarantee, no, but with multiple cores I think usually a waiting thread should get the lock
2462016-07-21T18:12:18 <wumpus> but indeed if you grab it immediately again, that may be a special case
2472016-07-21T18:12:39 <gmaxwell> we could just add explicit sleeps when connecting more than a few blocks.
2482016-07-21T18:12:40 <wumpus> it may be re-locked before anyone else even sees
2492016-07-21T18:12:49 <wumpus> adding sleeps sounds really ugly
2502016-07-21T18:13:00 <wumpus> there must be a better way
2512016-07-21T18:13:52 <sipa> yes, getting rid of locks that are held for long periods of time :)
2522016-07-21T18:13:54 <wumpus> I'm aware a yield is effectively a sleep for one timeshare, but at least it's as short as possible
2532016-07-21T18:15:13 <sipa> maybe we can release cs_main during signature verification (but after fetching inputs from the cache), and grabbing it back afterwards and compare if the tip is still the same, and apply the changes
2542016-07-21T18:15:46 <wumpus> maybe yield-every-N-ms-or-more instead of, by definition, every block? this avoids the yield slowing things down in the beginning when blocks validate really fast
2552016-07-21T18:15:52 <wumpus> then again maybe it's not a performance issue at all
2562016-07-21T18:16:38 <sipa> well there are two questions: 1) is yield sufficient to fix this problem at all?
2572016-07-21T18:16:55 <sipa> 2) what performance overhead does yield have if there are no orher waiters
2582016-07-21T18:17:07 <wumpus> the issue is only noticable when cs_main is held for, say, more than a second
2592016-07-21T18:17:27 <wumpus> (2) is up to 20ms, depending on the scheduler
2602016-07-21T18:17:35 <wumpus> it just gives away the rest of the timeslot
2612016-07-21T18:18:17 <sipa> it gives away the rest of the timeslot if there is another candidate for taking the timeslot
2622016-07-21T18:18:34 <wumpus> yes, which is very likely on a modern multitasking OS
2632016-07-21T18:19:38 <wumpus> but indeed it depends on factors not under bitcoind's control
2642016-07-21T18:19:50 <sipa> we should benchmark :)
2652016-07-21T18:21:36 *** AaronvanW has quit IRC
2662016-07-21T18:24:58 *** fengling has joined #bitcoin-core-dev
2672016-07-21T18:27:28 *** Amnez777 has quit IRC
2682016-07-21T18:28:19 *** AaronvanW has joined #bitcoin-core-dev
2692016-07-21T18:28:48 <jeremyrubin> I'm using this_thread::yield() in some code right now while I wait on something, seems to work well enough
2702016-07-21T18:28:54 *** pedrobranco has quit IRC
2712016-07-21T18:29:20 *** [b__b] has quit IRC
2722016-07-21T18:29:37 *** gabridome has joined #bitcoin-core-dev
2732016-07-21T18:29:46 *** fengling has quit IRC
2742016-07-21T18:30:37 *** [b__b] has joined #bitcoin-core-dev
2752016-07-21T18:51:05 *** lightningbot has joined #bitcoin-core-dev
2762016-07-21T18:59:29 <wumpus> meeting time
2772016-07-21T18:59:39 <jonasschnelli> megaping required
2782016-07-21T18:59:41 <btcdrak> here
2792016-07-21T18:59:46 <jeremyrubin> here
2802016-07-21T18:59:49 <bsm117532> here
2812016-07-21T18:59:50 <luke-jr> grubles: nicks
2822016-07-21T18:59:51 <wumpus> #startmeeting
2832016-07-21T18:59:51 <lightningbot> Meeting started Thu Jul 21 18:59:51 2016 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
2842016-07-21T18:59:51 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
2852016-07-21T18:59:52 <sipa> here
2862016-07-21T18:59:58 <luke-jr> guess he won't do it XD
2872016-07-21T19:00:02 <gmaxwell> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier
2882016-07-21T19:00:09 *** sanada has quit IRC
2892016-07-21T19:00:16 <kanzure> topics?
2902016-07-21T19:00:16 <sipa> thanks, gmaxwellbot
2912016-07-21T19:00:20 <wumpus> topic: 0.13
2922016-07-21T19:00:24 <gmaxwell> s'not a bot.
2932016-07-21T19:00:30 <jonasschnelli> topic: 0.13 OSX determinism
2942016-07-21T19:00:32 <btcdrak> /msg gmaxwell help topics
2952016-07-21T19:00:32 <cfields> here, but at conference and only 1/2 present
2962016-07-21T19:00:36 <luke-jr> gribble: nicks
2972016-07-21T19:00:44 <grubles> luke-jr: ?
2982016-07-21T19:00:45 <btcdrak> maxwellbot appears to be down
2992016-07-21T19:00:45 <wumpus> jonasschnelli: wasn't that solved already?
3002016-07-21T19:00:50 <luke-jr> grubles: mixed you up with the box :p
3012016-07-21T19:00:55 <wumpus> #topic 0.13
3022016-07-21T19:01:07 <jonasschnelli> wumpus: ah. Was that merged already... sorry, have't noticed.
3032016-07-21T19:01:11 <wumpus> any criticial issues reported with the rc1 yet?
3042016-07-21T19:01:14 <grubles> luke-jr: oh ok :)
3052016-07-21T19:01:24 <luke-jr> wumpus: lack of a way to export the seed has been a complaint on reddit at least
3062016-07-21T19:01:34 <jonasschnelli> I'm working on the critical bug with HD and wallet encrypt (that's the only feedback I got from Rc1)
3072016-07-21T19:01:39 <cfields> jonasschnelli: yes. I need to upstream it though.
3082016-07-21T19:02:00 <wumpus> jonasschnelli: thanks, yes I've added 0.13 milestone to https://github.com/bitcoin/bitcoin/issues/8383
3092016-07-21T19:02:01 *** pedrobranco has joined #bitcoin-core-dev
3102016-07-21T19:02:01 <jonasschnelli> there is a PR to export the seed in dumpwallet
3112016-07-21T19:02:07 <jonasschnelli> we could consider that for 0.13
3122016-07-21T19:02:11 *** netsin has quit IRC
3132016-07-21T19:02:12 <jonasschnelli> its easy to review.
3142016-07-21T19:02:15 <jonasschnelli> Low impacts
3152016-07-21T19:02:15 <wumpus> jonasschnelli: if it's low-impact, why not
3162016-07-21T19:02:21 <luke-jr> wumpus: the default policy not performing as well as inadvisable policies is apparently an issue, which I just PR'd a fix for an hour or so ago
3172016-07-21T19:02:21 <sipa> agree on that
3182016-07-21T19:02:27 <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/8206
3192016-07-21T19:02:28 <CodeShark> wumpus: there are a few issues with the release notes - I'll try to submit comments shortly
3202016-07-21T19:02:33 <luke-jr> jonasschnelli: IMO yes
3212016-07-21T19:02:47 <sipa> jonasschnelli: also in importwallet ?
3222016-07-21T19:02:52 <jonasschnelli> Ino
3232016-07-21T19:02:55 <jonasschnelli> no
3242016-07-21T19:02:57 <wumpus> no, just exporting
3252016-07-21T19:03:03 <jonasschnelli> import wallet imples "import" and no change the see
3262016-07-21T19:03:05 <wumpus> importing is a wholly different issue
3272016-07-21T19:03:05 <jonasschnelli> seed
3282016-07-21T19:03:21 <luke-jr> jonasschnelli: I don't see why import doesn't imply adding the seed
3292016-07-21T19:03:22 <jonasschnelli> Import would just pick the keys.
3302016-07-21T19:03:23 <wumpus> (e.g. in some cases you may want to change the seed, but usually probably not)
3312016-07-21T19:03:34 <luke-jr> does the current format all multiple seeds?
3322016-07-21T19:03:35 <jonasschnelli> luke-jr: adding yes, but not overwriting the current one
3332016-07-21T19:03:35 <wumpus> luke-jr: because you may be importing to *combine* wallets
3342016-07-21T19:03:44 <jonasschnelli> luke-jr: a seed is just a key
3352016-07-21T19:03:45 <luke-jr> err
3362016-07-21T19:03:52 <luke-jr> *does the current format support having multiple seeds?
3372016-07-21T19:03:56 <sipa> nope
3382016-07-21T19:03:59 <gmaxwell> nope
3392016-07-21T19:04:02 <wumpus> in any case that's too much impact
3402016-07-21T19:04:06 <luke-jr> I suppose
3412016-07-21T19:04:10 <wumpus> exporting is easy to do for 0.13 so I think we should
3422016-07-21T19:04:15 <sipa> that would require having multiple lookahead key pools etc
3432016-07-21T19:04:18 <sipa> ack on export
3442016-07-21T19:04:18 <gmaxwell> it's the simplest possible.
3452016-07-21T19:04:33 <wumpus> for 0.14 we could consider things like support multiple seeds
3462016-07-21T19:04:45 <jonasschnelli> Okay. Marked #8206 for 0.13
3472016-07-21T19:04:48 <jonasschnelli> #action review #8206
3482016-07-21T19:04:53 <luke-jr> IMO as long as we're not ruling out multi-seed wallets in 0.14+, ok
3492016-07-21T19:04:54 <wumpus> thanks
3502016-07-21T19:05:06 <sipa> luke-jr: agree
3512016-07-21T19:05:23 <jonasschnelli> Since we have now the most important change done for HD, we can try to add lots of features for 0.14.
3522016-07-21T19:05:25 <jtimon> proposed topic: remove ISM
3532016-07-21T19:05:27 *** GAit has joined #bitcoin-core-dev
3542016-07-21T19:05:41 *** belcher has joined #bitcoin-core-dev
3552016-07-21T19:06:21 *** pedrobranco has quit IRC
3562016-07-21T19:06:21 <wumpus> proposed topic from jeremyrubin: checkqueue.h change
3572016-07-21T19:06:43 <sipa> are we done with 0.13 discussion?
3582016-07-21T19:06:45 <jeremyrubin> wumpus: topic proposal checkqueue performance
3592016-07-21T19:07:03 <jeremyrubin> ah oops sorry network lag
3602016-07-21T19:07:09 <jtimon> jeremyrubin: thanks for being more specific
3612016-07-21T19:07:16 <wumpus> sipa: I think so, unless there are other issues reported I think that's all for 0.13 for this week
3622016-07-21T19:07:38 <jtimon> jeremyrubin: seriously, don't be sorry, it helped me
3632016-07-21T19:07:39 <sipa> ok
3642016-07-21T19:07:55 <wumpus> #topic remove ISM
3652016-07-21T19:08:12 <luke-jr> (https://github.com/bitcoin/bitcoin/pull/8388 needs a 0.13 tag I guess)
3662016-07-21T19:08:47 <sipa> about removing ISM
3672016-07-21T19:08:49 <sipa> how?
3682016-07-21T19:09:04 <wumpus> ISM=IsSuperMajority?
3692016-07-21T19:09:08 <instagibbs> yes
3702016-07-21T19:09:08 <sipa> 1) just a height after which the previous softforks activate
3712016-07-21T19:09:09 *** GAit has quit IRC
3722016-07-21T19:09:09 <btcdrak> wumpus: yes
3732016-07-21T19:09:13 <jtimon> well, my preference would be to introduce a getflags function first
3742016-07-21T19:09:16 <gmaxwell> when are we branching? I've been holding off on patches until after the branch.
3752016-07-21T19:09:27 <sipa> gmaxwell: branch was a few days ago
3762016-07-21T19:09:28 *** GAit has joined #bitcoin-core-dev
3772016-07-21T19:09:29 <btcdrak> gmaxwell: we branched already
3782016-07-21T19:09:29 <wumpus> gmaxwell: we've already branched a few days ago
3792016-07-21T19:09:31 <luke-jr> how many exceptional blocks violate softfork-added rules?
3802016-07-21T19:09:50 <sdaftuar> i'm curious to know what you're thinking about doing for regtest
3812016-07-21T19:10:01 <btcdrak> for some reason github didnt ping the channel on new branch creation
3822016-07-21T19:10:23 <gmaxwell> oh I missed that.
3832016-07-21T19:10:24 <instagibbs> sdaftuar, any issues you can think of?
3842016-07-21T19:10:30 <sipa> sdaftuar: ugh... a command line option to enable the rules individually (from the start, over the entire chain)?
3852016-07-21T19:10:33 <jtimon> but knowing that ISM is going to be reomved, just don't touch any ISM call and leave it all prepared for ISM calls to be simply removed from main and replaced with the new code inside versionbits::getflags()\
3862016-07-21T19:10:57 <wumpus> luke-jr: 8388 is a pretty large change, isn't that a lot to do last-minute? also you don't have a description on the pull at all
3872016-07-21T19:11:04 <gmaxwell> jtimon: ISM things are not versionbits.
3882016-07-21T19:11:08 <gmaxwell> We went over this before.
3892016-07-21T19:11:17 <btcdrak> yes we did
3902016-07-21T19:11:19 *** Amnez777 has joined #bitcoin-core-dev
3912016-07-21T19:11:21 <jtimon> I was previously of the opinion that a height was enough but I changed my mind, yes, block hash too
3922016-07-21T19:11:39 <gmaxwell> sipa: see consensus.BIP34Height = 227931;
3932016-07-21T19:11:46 <gmaxwell> sipa: in chainparams.cpp
3942016-07-21T19:11:47 <btcdrak> jtimon: gmaxwell said he is working on a ISM removal PR
3952016-07-21T19:11:48 <gmaxwell> "like that"
3962016-07-21T19:12:14 <luke-jr> wumpus: well, I didn't expect counting bytes to be used as an excuse to have the release notes pressure miners to use bad policy configs
3972016-07-21T19:12:25 *** sipa has left #bitcoin-core-dev
3982016-07-21T19:12:44 <jtimon> gmaxwell: agreed, I only want a getconsensusflags function, if it's defined in versionbits or consensus/header_verify.cpp or somewhere else I don't care so much
3992016-07-21T19:12:53 <gmaxwell> sdaftuar: what I'd done is just set regtest to 0, but hadn't checked to see what tests doing that would break.
4002016-07-21T19:13:00 *** dstadulis has joined #bitcoin-core-dev
4012016-07-21T19:13:13 <jtimon> but I strongly oppose to define getflags in main.cpp
4022016-07-21T19:13:22 <gmaxwell> jtimon: the things which are ISM should not be flags, becuase they're not optional anymore.
4032016-07-21T19:13:22 <wumpus> luke-jr: ok, fair enough, I do think it requires more discussion
4042016-07-21T19:13:40 <btcdrak> jtimon: but that doesnt mean you can stuff them into an unrelated unit
4052016-07-21T19:13:44 <sdaftuar> gmaxwell: i guess we can just change the tests that test activation of ISM things
4062016-07-21T19:14:00 <sdaftuar> gmaxwell: so maybe that will work fine?
4072016-07-21T19:14:15 <morcos> gmaxwell: they still need flags right? for when they are active and when they aren't?
4082016-07-21T19:14:19 *** sipa has joined #bitcoin-core-dev
4092016-07-21T19:14:34 <gmaxwell> sdaftuar: yea, thats what I was thinking. the obvious alternative is to set it to something not 0, like 5.. and let the tests handle it.
4102016-07-21T19:14:36 <sdaftuar> i wonder if there are cases where we might want to test how a chain behaves when some blocks don't satisfy a rule (like bip34) and then later ones do.
4112016-07-21T19:15:02 <gmaxwell> morcos: some of the things are not accomplished via flags like mechenisms, e.g. the version number checks. They're not a script feature.
4122016-07-21T19:15:27 <jtimon> btcdrak: yep, I just want to coordinate with him, in fact, I believe NicolasDorier and I will benifit more than gmaxwell from this coordination, gmaxwell doesn't really need us and can do it all in main
4132016-07-21T19:15:31 <sipa> sdaftuar: versionbits does not need that anymore, and i don't care strongly about testing that for purely historical features
4142016-07-21T19:15:45 <sipa> jtimon: please
4152016-07-21T19:16:22 <sdaftuar> sipa: yeah i think you're basically right, we can just enumerate each of the ISM soft forks and make a decision, there's only a handful
4162016-07-21T19:16:29 <sipa> sdaftuar: exactly
4172016-07-21T19:16:43 <wumpus> jtimon: where to put it and what solution to use are orthogonal issues
4182016-07-21T19:18:04 * luke-jr observes that P2SH was actually more like BIP 9 than ISM was
4192016-07-21T19:18:08 <gmaxwell> Some future softforks that get virtified might even have no violations anywhere in the chain, in which case, I'd propose just removing all conditional logic for them entirely.
4202016-07-21T19:18:09 <jtimon> wumpus: agreed, but two people trying to complete verifyblock would benefit in sharing the most common refactors as possible
4212016-07-21T19:18:26 *** jeremyrubin has quit IRC
4222016-07-21T19:18:29 <gmaxwell> I believe CSV might be an example of that.
4232016-07-21T19:18:46 <jtimon> gmaxwell: I agree, but I was talking much shorter term here
4242016-07-21T19:18:58 <jtimon> as in, whithin the refactor window
4252016-07-21T19:19:11 <gmaxwell> adding a bunch of additional 'flags' for things like height checks would be undesirable code smell.
4262016-07-21T19:19:32 <gmaxwell> as would moving ISM logic into a file called versionbits.cpp.
4272016-07-21T19:19:40 <sipa> agree
4282016-07-21T19:19:47 <luke-jr> gmaxwell: GBT will likely pose a problem for that, but probably not insurmountable (worst case we can neuter GBT by removing the clients-can-modify-the-template aspect, since nobody much uses it afaik)
4292016-07-21T19:19:54 <CodeShark> I had proposed a softforks unit to solve this a while back ;)
4302016-07-21T19:20:32 <gmaxwell> To be honest, I am really frustrated right now with some of the pointless nitpicky behavior being driven by 'refactoring' all of a sudden. It's making me want to not be involved in the project.
4312016-07-21T19:20:37 <NicolasDorier> btw, I'm almost done with the PR removing ISM
4322016-07-21T19:21:01 <gmaxwell> I don't have the time to endlessly debate minutia with people who are being very tunnel vision about varrious things.
4332016-07-21T19:21:26 <CodeShark> ?
4342016-07-21T19:21:33 <GitHub128> [bitcoin] jonasschnelli opened pull request #8389: [0.13] Create a new HD seed after encrypting the wallet (0.13...2016/07/hd_enc) https://github.com/bitcoin/bitcoin/pull/8389
4352016-07-21T19:21:37 <jtimon> gmaxwell: the movement of ISM to versionbits was only in preparation to more cleanly remove it later and not having to include main.h from consensus files, but yeah no need to move it, just delete it beforehand
4362016-07-21T19:21:44 <wumpus> well code that is going away doesn't need to be moved
4372016-07-21T19:21:55 *** netsin has joined #bitcoin-core-dev
4382016-07-21T19:21:57 <jtimon> of course, agreed
4392016-07-21T19:22:11 *** jeremyrubin has joined #bitcoin-core-dev
4402016-07-21T19:22:30 <wumpus> but refactoring main.cpp is also important - we've held it off for so long now
4412016-07-21T19:22:45 *** netsin has quit IRC
4422016-07-21T19:22:57 <CodeShark> Making sure the code doesn't get cluttered in the long run and establishing good habits for this early on are not tunnel vision, imho
4432016-07-21T19:22:58 <sipa> agree
4442016-07-21T19:23:02 <wumpus> after all that time we still have that huge c++ file with so many different responsibilities
4452016-07-21T19:23:02 <jtimon> all I want to agree is that is "going away" to getflags, and that getflags has some place to exist (it may not be versionbits.o)
4462016-07-21T19:23:16 <jtimon> it won't go away
4472016-07-21T19:23:29 <sipa> jtimon: is getflags the "one set of flags for everything"? if so, nack
4482016-07-21T19:23:36 <kanzure> while we're busy refactoring everything i would like libconsensus and a pony
4492016-07-21T19:24:07 <jtimon> it will be replaced and we can leave it all preapare for where it will be replaced with something like bip34 and that will simplify things, I believe
4502016-07-21T19:24:24 <sipa> ok, can we move on?
4512016-07-21T19:24:28 <wumpus> in any case, this doesn't seem to be a constructive topic in the meeting anymore
4522016-07-21T19:24:35 <CodeShark> yes, let's move ob
4532016-07-21T19:24:39 <sipa> or are there still things about ISM?
4542016-07-21T19:24:40 <CodeShark> on
4552016-07-21T19:24:49 <wumpus> #topic checkqueue.h optimization
4562016-07-21T19:24:58 <btcdrak> ping jeremyrubin
4572016-07-21T19:25:08 *** dstadulis has quit IRC
4582016-07-21T19:25:20 *** dstadulis has joined #bitcoin-core-dev
4592016-07-21T19:25:36 <jtimon> sipa: thank you for being so direct. After our discussions on the subject, I agree the script flags should be separated, but for now it should be libconsensus flags and script flags, yes
4602016-07-21T19:25:40 <jeremyrubin> Hi
4612016-07-21T19:26:07 <jeremyrubin> So all I wanted to say is that I am doing some refactoring of checkqueue, have some nice improvements preliminarily.
4622016-07-21T19:26:25 <jeremyrubin> Will push something to my fork if you're particularly interested in it
4632016-07-21T19:26:27 *** fengling has joined #bitcoin-core-dev
4642016-07-21T19:26:34 <jtimon> sipa: I know you won't like non-script flags in script/interpreter even temporarily, I'm working on changing that, but that's just hwat I have right now
4652016-07-21T19:26:35 *** d_t has joined #bitcoin-core-dev
4662016-07-21T19:26:45 <wumpus> jeremyrubin: looking forward to the pull request :)
4672016-07-21T19:26:51 <jonasschnelli> jeremyrubin: nice!
4682016-07-21T19:26:58 *** netsin has joined #bitcoin-core-dev
4692016-07-21T19:27:09 <sipa> jeremyrubin: looking forward to it, obviously
4702016-07-21T19:27:23 <sipa> (as long as it doesn't rely on MIPS assembly)
4712016-07-21T19:27:25 <jtimon> wumpus: well, it is constructive for me, I'm getting useful feedback
4722016-07-21T19:27:26 <jeremyrubin> just wanted to note it as I've heard some other people looking at it, so don't want to duplicte work
4732016-07-21T19:27:52 <jeremyrubin> that's all!
4742016-07-21T19:28:31 <cfields> jeremyrubin: along those lines, I've been working on optimizing the sigcache, after morcos pointed out some cool speedups. maybe we should work together to come up with a good representative bench for testing improvements?
4752016-07-21T19:28:33 <wumpus> jtimon: ok that's good; it didn't seem to be going the right way. Seems that gmaxwell wants to get rid of ISM as soon as possible, so refactoring the ISM part is just a waste of work
4762016-07-21T19:28:41 *** GAit has quit IRC
4772016-07-21T19:28:57 <cfields> morcos: or are you still hacking on that? ^^
4782016-07-21T19:29:00 <NicolasDorier> I will propose a PR for removing ISM in one or two hours normally
4792016-07-21T19:29:10 <gmaxwell> I wanted to remove it in 0.13 but didn't want to introduct a conflict with the SW merge so I held off.
4802016-07-21T19:29:14 <morcos> cfields: yep, we're working on it together!
4812016-07-21T19:29:29 <gmaxwell> It saves like two whole milliseconds from block connecting times. :P
4822016-07-21T19:29:32 <wumpus> NicolasDorier: great
4832016-07-21T19:29:59 <jeremyrubin> cfields: sounds good -- will msg out of meeting
4842016-07-21T19:30:07 <CodeShark> wumpus: focusing too much on ISM given its impending death is probably not the most urgent thing - my concern is more ovet general habits
4852016-07-21T19:30:18 <CodeShark> *over
4862016-07-21T19:30:23 <cfields> morcos: ah, ok.
4872016-07-21T19:30:23 <wumpus> CodeShark: well the topic was removing ISM
4882016-07-21T19:30:29 <sipa> gmaxwell: that's 12 minites of sync time :o
4892016-07-21T19:30:32 <morcos> gmaxwell: i think with the lock free stuff jeremy is working on, i can get validation times down from 200ms to sub 50ms on my machine
4902016-07-21T19:30:43 <sipa> morcos: impressive
4912016-07-21T19:30:54 <sdaftuar> he has a lot of cores :P
4922016-07-21T19:31:03 <jonasschnelli> heh
4932016-07-21T19:31:17 <BlueMatt> sdaftuar: but across 2 cpus, so numa :/
4942016-07-21T19:31:26 *** fengling has quit IRC
4952016-07-21T19:31:27 *** netsin has quit IRC
4962016-07-21T19:31:36 <wumpus> oh no numa, is that still a thing
4972016-07-21T19:31:38 <jtimon> wumpus: I also want ISM to go away as soon as possible and I'll rebase on top of the PR as soon as it appears, I was just asking for an agreed trivial plan on how to "just don't touch ISM, the replacement will go here" that we could work on in the meantime
4982016-07-21T19:31:50 <gmaxwell> wumpus: any multisocket system is numa.
4992016-07-21T19:32:04 <gmaxwell> (these days)
5002016-07-21T19:32:09 <jtimon> wumpus: in my experience "will go here" can take a lot of time
5012016-07-21T19:33:08 <wumpus> gmaxwell: I didn't know, haven't seen much multisocket systems in recent times, I was hoping it was a crippled thing from the past :)
5022016-07-21T19:33:24 <jtimon> so we should totally not touch ISM in any consensus refactor PR, but where the replacement should go is something we can discuss after the meeting
5032016-07-21T19:33:38 <wumpus> in any case optimizing bitcoind for numa is very much out of scope :p
5042016-07-21T19:33:56 *** GAit has joined #bitcoin-core-dev
5052016-07-21T19:34:11 <btcdrak> we seem to have drifted off topic
5062016-07-21T19:34:13 <wumpus> anything else to discuss?
5072016-07-21T19:34:18 <NicolasDorier> #topic Handling Dust on the wallet
5082016-07-21T19:34:32 <wumpus> hey, I'm supposed to set the topic
5092016-07-21T19:34:37 <NicolasDorier> oh sorry :D
5102016-07-21T19:34:40 <NicolasDorier> noob here
5112016-07-21T19:34:40 <wumpus> (but no problem with this one)
5122016-07-21T19:34:51 <gmaxwell> Has anyone picked up that simulator work and improved it?
5132016-07-21T19:34:57 <sipa> it also does not work (for logs) if someone else than the chair does it
5142016-07-21T19:35:08 <wumpus> #topic Handling Dust on the wallet
5152016-07-21T19:35:23 <NicolasDorier> so the problem is boring: wallet code is preventing to create output below dust using ::txminRelayFee
5162016-07-21T19:35:30 <jtimon> I think the ISM removal topic is mostly finished, TODO adapt any refactor for ISM to be removed before-hand, TODO decide where the replacement need to go during the refactor
5172016-07-21T19:35:50 <NicolasDorier> problem is that when we bumped it long time ago, some transaction could not be relayed anymore
5182016-07-21T19:36:05 <NicolasDorier> causing some stress to users
5192016-07-21T19:36:16 <NicolasDorier> several way to fix the problem
5202016-07-21T19:36:19 <jonasschnelli> You can if you add new/fresh larger coins? right?
5212016-07-21T19:36:25 <jonasschnelli> (econimical painful)
5222016-07-21T19:36:26 <morcos> NicolasDorier: I dont' have a good sense for how to make this work properly and be something the at doesnt involve fiddlign with a bunch of variables
5232016-07-21T19:36:34 *** spudowiar has quit IRC
5242016-07-21T19:36:38 <sipa> NicolasDorier: if all wallets at all times would not create outputs that were uneconomical to spend, there would be no issue, i think
5252016-07-21T19:36:40 <luke-jr> I thought the wallet avoided change below some number much larger than dust?
5262016-07-21T19:36:57 <MarcoFalke> yes
5272016-07-21T19:36:59 <morcos> But I think its clear we should have the MinimumOutput be higher than the dust level, so that when we raise the dust level, we know prev releases are still not generating dust
5282016-07-21T19:37:01 <NicolasDorier> luke-jr: problem is that it is not "much larger"
5292016-07-21T19:37:05 <NicolasDorier> it is "exactly"
5302016-07-21T19:37:08 <MarcoFalke> but this does not affect when you pay someone dust
5312016-07-21T19:37:08 <luke-jr> NicolasDorier: 0.01 BTC last I checked
5322016-07-21T19:37:09 <gmaxwell> This was intentional; not the stress of course, but not relaying transactions with produce outputs which are a loss to consume. But it sounds like you're not talking about the wallet, but relay behavior.
5332016-07-21T19:37:26 <sipa> gmaxwell: no, this is about wallet
5342016-07-21T19:37:32 <luke-jr> MarcoFalke: sure, but that's user error
5352016-07-21T19:37:40 <gmaxwell> The wallet tries to produce change >0.01 btc as luke mentions. (which is its own stupidity, see my earlier simulator question)
5362016-07-21T19:38:09 <NicolasDorier> oh ? I am surprised I did https://github.com/bitcoin/bitcoin/pull/8356 recently and it seemed using the ::minTxRelayFee
5372016-07-21T19:38:14 <NicolasDorier> for calculating the smallest output
5382016-07-21T19:38:15 <MarcoFalke> gmaxwell: I asked murch to present his findings of his masters thesis in one of the meetings
5392016-07-21T19:38:32 <jonasschnelli> I think it should try much higher min change outputs if possible.
5402016-07-21T19:38:38 <jtimon> btw, GetDustThreshold and IsDust are still in primitives/transaction.h (libconsensus), unrelated, but maybe cheap to do both at the same time
5412016-07-21T19:38:39 <morcos> NicolasDorier: i also forgot about that 0.01 btc thing
5422016-07-21T19:38:44 <jonasschnelli> We don't know the fees in â lets say â 2 years.
5432016-07-21T19:38:47 <luke-jr> jonasschnelli: how much higher? this could be a privacy problem
5442016-07-21T19:38:57 <gmaxwell> NicolasDorier: if select coins does not make an exact match, it attempts again with amount + 0.01 btc as the target.
5452016-07-21T19:39:02 <luke-jr> jonasschnelli: we have fee learning logic..
5462016-07-21T19:39:07 <jonasschnelli> luke-jr:If possible 1:1 like the spend itself
5472016-07-21T19:39:09 <jonasschnelli> :-)
5482016-07-21T19:39:14 <luke-jr> jonasschnelli: that harms privacy
5492016-07-21T19:39:26 <jonasschnelli> (and would also not be possible)
5502016-07-21T19:39:39 <gmaxwell> luke-jr: it can be done in ways which don't. Please see my comments on the remove extranious inputs PR.
5512016-07-21T19:39:42 <NicolasDorier> gmaxwell: this is coin selection, but it does not prevent the creation of an output below 0.01 right ?
5522016-07-21T19:39:58 <MarcoFalke> no
5532016-07-21T19:40:18 <jtimon> luke-jr: please tell me "fee learning logic" is in policy/fees.o and not consensus/deeplearning.o
5542016-07-21T19:40:20 <MarcoFalke> Those are different objectives to optimize
5552016-07-21T19:40:24 <gmaxwell> NicolasDorier: it may not be possible to prevent that except by turning small amounts into fees.
5562016-07-21T19:40:35 <luke-jr> jtimon: afaik yes
5572016-07-21T19:40:56 <luke-jr> gmaxwell: if both outputs have the same or near-same value, any observer can see the approximate tx value, no?
5582016-07-21T19:41:06 <jtimon> luke-jr: cool :)
5592016-07-21T19:41:27 <gmaxwell> luke-jr: I'll explain more outside of the meeting.
5602016-07-21T19:41:30 <luke-jr> ok
5612016-07-21T19:41:34 <NicolasDorier> ok I'll need to study more about this 0.01 thing and the implication, will catch up with morcos
5622016-07-21T19:41:58 <gmaxwell> the whole logic with that stuff is braindamaged imo.
5632016-07-21T19:42:32 <NicolasDorier> I heard someone is doing some work in that area (Xekyo)
5642016-07-21T19:42:44 <gmaxwell> manages to fail under every kind of metric I can come up with, except for consistency with the existing code. (which, unsurprisingly, is the property the tests test for... :) )
5652016-07-21T19:42:56 <murch> marcofalke: My thesis is still in the making, sorry.
5662016-07-21T19:43:00 <MarcoFalke> NicolasDorier: it's murch in this channel
5672016-07-21T19:43:05 <NicolasDorier> oh ok
5682016-07-21T19:44:02 <gmaxwell> okay, is there anything else?
5692016-07-21T19:44:16 <wumpus> no proposed topics at lesat
5702016-07-21T19:44:49 <kanzure> well, i am assembling a list of things to talk about in person
5712016-07-21T19:44:55 <kanzure> similar to https://gist.github.com/kanzure/8d193f82aabd85eeba78a61815d3038d
5722016-07-21T19:45:06 <kanzure> so i will be heckling some or most of you regarding proposed subjects
5732016-07-21T19:45:18 <jtimon> well, you could talk more about that to close the meeting, no?
5742016-07-21T19:45:26 <gmaxwell> wumpus: I have a topic.
5752016-07-21T19:45:38 <gmaxwell> wumpus: sigops max size, and the sigops per byte limit.
5762016-07-21T19:45:43 <kanzure> jtimon: what would you like to hear?
5772016-07-21T19:46:02 <wumpus> #topic sigops max size, and the sigops per byte limit
5782016-07-21T19:46:15 <luke-jr> (gmaxwell: btw, I have no strong opinions on the coin selection stuff, if it's one of those minutia you'd rather not spend time on.)
5792016-07-21T19:46:26 <jtimon> kanzure: nothing specifically just things to talk about in person, I didn't folloed your link yet
5802016-07-21T19:46:32 <gmaxwell> We have ongoing complaints that the bytespersigops limit has made some bare multsig outputs difficult to spend (normal software behavior won't work)
5812016-07-21T19:46:54 <wumpus> this is about https://github.com/bitcoin/bitcoin/pull/8365?
5822016-07-21T19:47:00 <gmaxwell> This was an unintended side effect of the limits put in to stop the sigops exhaustion spam attack.
5832016-07-21T19:47:16 <luke-jr> we have a fix for that, which introduces a new concern; and a fix for the new concern, that slightly complicates fee estimation
5842016-07-21T19:47:21 <gmaxwell> https://github.com/bitcoin/bitcoin/pull/8365 and https://github.com/bitcoin/bitcoin/pull/8364
5852016-07-21T19:47:33 <gmaxwell> I don't agree with the position luke is taking.
5862016-07-21T19:47:46 <wumpus> #link https://github.com/bitcoin/bitcoin/pull/8365
5872016-07-21T19:47:49 <wumpus> #link https://github.com/bitcoin/bitcoin/pull/8364
5882016-07-21T19:47:55 <jonasschnelli> Shouldn't this be included in 0.13 then?
5892016-07-21T19:48:15 <luke-jr> jonasschnelli: probably
5902016-07-21T19:48:21 <gmaxwell> It's unambigious why the limit was introduced. There is was a consensus sigops exhaustion attack resulting in small blocks.
5912016-07-21T19:48:24 <sipa> i think 8365 should be in 0.13; i think 8364 is needless complication
5922016-07-21T19:48:34 <sdaftuar> sipa: i agree
5932016-07-21T19:48:38 <gmaxwell> 8365 corrects it in the way I originally proposed (so I like it)
5942016-07-21T19:48:43 <sipa> (but apart from that i'm not strongly against 8364)
5952016-07-21T19:48:52 <luke-jr> gmaxwell: that isn't why the limit was introduced, though.. it was to filter spam
5962016-07-21T19:49:02 <wumpus> for 0.13 we should prefer a simple solution
5972016-07-21T19:49:02 <sipa> luke-jr: in your world view perhaps
5982016-07-21T19:49:20 <jonasschnelli> Im in favor of #8365 (at least for 0.13)
5992016-07-21T19:49:23 <luke-jr> sipa: considering I wrote it..
6002016-07-21T19:49:24 <gmaxwell> Luke proposes 8364 in addition, driven by a concern that allowing high sigops transactions but with high fees is sending an implicit endorsement that it's okay for random transactions to burn up lots of actual signature operations needlessly if they pay for it.
6012016-07-21T19:49:25 <sdaftuar> the PR that introduced the limit lacks explanation
6022016-07-21T19:49:52 <sipa> luke-jr: sure it may have been your intention; that was certainly noy clear to me (or many, i think)
6032016-07-21T19:50:00 <jtimon> is this about #8362 ?
6042016-07-21T19:50:09 <sipa> luke-jr: i disagree that it helps at all with preventing spam, and only encourages further bloating
6052016-07-21T19:50:11 <wumpus> sdaftuar: because it was a DoS fix
6062016-07-21T19:50:23 <luke-jr> jtimon: no, 8364 and 8365
6072016-07-21T19:50:36 <gmaxwell> It was extensively discussed in here. It's revisionist to suggest that it was merged for any reason other than consensus sigops exhaustion.
6082016-07-21T19:50:47 <jtimon> luke-jr: thanks, scrolling back
6092016-07-21T19:51:08 <gmaxwell> I wouldn't have supported it otherwise.
6102016-07-21T19:51:38 <gmaxwell> In any case, 8365 corrects the issue though sdaftuar expressed some concern that it also causes small miscosting of a small amount of transactions.
6112016-07-21T19:51:52 <gmaxwell> (since most of the time no sigops flooding attack is happening)
6122016-07-21T19:52:21 <sdaftuar> gmaxwell: in the current form, #8365 sets the conversion at 20, not 50
6132016-07-21T19:52:31 <sdaftuar> by default
6142016-07-21T19:52:32 <luke-jr> I don't think we can solve that without a much more complicated change..?
6152016-07-21T19:52:34 <CodeShark> luke-jr: I still adhere to the view that "spam" lacks a technical definition here
6162016-07-21T19:52:52 <sdaftuar> so i think it's fine as is. if another sigops attack were to hit the network, miners could bump it up to 50 and avoid being attacked
6172016-07-21T19:53:00 <luke-jr> CodeShark: in this context, it is non-pubkey data fed to sigops as a key
6182016-07-21T19:53:07 <sdaftuar> in its current form, users affected by the old policy have a better alternative to bloating up their transactions
6192016-07-21T19:53:16 <wumpus> CodeShark: storing unnecessary data in the utxo set counts as spam to me
6202016-07-21T19:53:22 <sdaftuar> we can think about better policies in the long run later, imo -- this is good enough for now
6212016-07-21T19:54:05 <wumpus> sdaftuar: for 0.13 that's the most important
6222016-07-21T19:54:08 <luke-jr> 8365 as-is, is a regression of used behaviour
6232016-07-21T19:54:42 <sdaftuar> wumpus: yep agreed
6242016-07-21T19:54:47 <CodeShark> wumpus: if someone is willing to pay for it it's income to someone else
6252016-07-21T19:54:54 <sipa> luke-jr: as-is, i think it will have as sole effect that some people who are now bloating their transactions to bypass the limit, will stop doing so
6262016-07-21T19:54:55 <gmaxwell> luke-jr: I don't agree that it is. since the change manages to except the counterparty data storage transactions, I'm not aware of anything that could be classified as spam that exists now that it usefully blocks.
6272016-07-21T19:55:08 <wumpus> CodeShark: everyone with a full node suffers from it, without being paid for it
6282016-07-21T19:55:27 <CodeShark> wumpus: that's a problem with incentives, not spam
6292016-07-21T19:55:31 <wumpus> CodeShark: that's just like e-mail spam - everyone with an email account has to handle the extra messages
6302016-07-21T19:55:42 <sipa> can we keep philosophical discussions for elsewhere?
6312016-07-21T19:55:43 <luke-jr> gmaxwell: can you rephrase?
6322016-07-21T19:56:41 <wumpus> uhm, okay
6332016-07-21T19:56:50 <gmaxwell> luke-jr: point me to a transaction that 8364 would block that should be blocked? the only thing the sigopsperbyte limit was blocking was the sigops exhaust transactions (blocked by 8365) and counterparty data storage transactions, which 8364 jumps though enormous hoops to not block.
6342016-07-21T19:57:53 <GitHub86> [bitcoin] jonasschnelli opened pull request #8390: [Wallet] Correct hdmasterkeyid/hdmasterkey name confusion (master...2016/07/hd_masterkeyrename) https://github.com/bitcoin/bitcoin/pull/8390
6352016-07-21T19:58:16 <sipa> wumpus, CodeShark: sorry for interrupting, but i don't think you guys disagree at all - only about what certain words meam
6362016-07-21T19:58:23 <luke-jr> gmaxwell: both of those should be blocked, and AFAIK 8365 doesn't block anything at all?
6372016-07-21T19:58:46 <luke-jr> gmaxwell: (to be clear, Counterparty should be using OP_RETURN only for their data)
6382016-07-21T19:58:47 <gmaxwell> luke-jr: 8365 closes the sigops bloat attack vector.
6392016-07-21T19:58:57 <wumpus> only roughly one minute to go
6402016-07-21T19:59:05 *** spudowiar has joined #bitcoin-core-dev
6412016-07-21T19:59:11 <gmaxwell> I think we should close the meeting.
6422016-07-21T19:59:15 <wumpus> #closemeeting
6432016-07-21T19:59:17 <wumpus> #endmeeting
6442016-07-21T19:59:17 <lightningbot> Meeting ended Thu Jul 21 19:59:17 2016 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
6452016-07-21T19:59:17 <lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-07-21-18.59.html
6462016-07-21T19:59:17 <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-07-21-18.59.txt
6472016-07-21T19:59:17 <lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-07-21-18.59.log.html
6482016-07-21T19:59:22 <luke-jr> gmaxwell: it just costs more to perform the attack?
6492016-07-21T19:59:35 <gmaxwell> luke-jr: no, jesus chrsit luke. It _eliminates_ the attack.
6502016-07-21T19:59:36 <sipa> luke-jr: ideally, they are disincntivized to be produced at all. but the current code (which blocks them) has as only result that they bloat their transactions to bypass the restriction
6512016-07-21T20:00:44 <gmaxwell> luke-jr: The attack is that someone make a few small transactions that use up all the block capacity, while paying less than all the other users who were left waiting.
6522016-07-21T20:00:52 *** aaaaa_ has joined #bitcoin-core-dev
6532016-07-21T20:01:13 *** aaaaa_ has quit IRC
6542016-07-21T20:01:20 <gmaxwell> if someone actually wants to outbid the other users and use up the block capacity, they can do that-- and nothign can stop them (except for eventually running out of funds to blow), which is how open markets work. :)
6552016-07-21T20:01:59 <gmaxwell> 8365 fixes things so that users making weirdly shaped transactions can't use up capacity in excess of what they've paid for.
6562016-07-21T20:02:24 *** cryptapus has quit IRC
6572016-07-21T20:02:27 <gmaxwell> Thus no reason to create a weirdly shaped transaction.
6582016-07-21T20:02:43 <sipa> gmaxwell: that would only be the case if the factor were 50, not 20... but it is the best we can do today without potentially impacting transaction relay
6592016-07-21T20:03:02 *** murch has quit IRC
6602016-07-21T20:03:14 <sipa> ok, i'm going to catch some pokemon
6612016-07-21T20:03:16 <sipa> i mean
6622016-07-21T20:03:20 <BlueMatt> .........
6632016-07-21T20:03:20 <sipa> i'm going for a walk
6642016-07-21T20:03:23 <luke-jr> lol
6652016-07-21T20:03:30 <dstadulis> lol
6662016-07-21T20:04:08 <gmaxwell> did sdaftuar measure the impact? or did we just gimp the fix on conjecture?
6672016-07-21T20:05:17 <gmaxwell> I guess at 20 it's no more gimped than the code currently in place.
6682016-07-21T20:05:23 <jonasschnelli> sipa: haha..I tried that once on my speedbike. Almost crashed in a car...
6692016-07-21T20:05:43 <luke-jr> gmaxwell: ok, so how does 8365 close the data storage abuse vector, that bytespersigop used to at least make clear was abuse?
6702016-07-21T20:06:45 *** laurentmt has quit IRC
6712016-07-21T20:08:53 <gmaxwell> luke-jr: none of these things have any impact on data storage abuse.
6722016-07-21T20:09:07 <sipa> luke-jr: clearly people dom't care about whether we consider it abuse or not
6732016-07-21T20:09:09 <gmaxwell> non the bytespersigops, not 8364, not 8365.
6742016-07-21T20:10:00 *** dstadulis has quit IRC
6752016-07-21T20:10:12 <gmaxwell> bytespersigops had a accdential and coincidental negative effect on counterparty data storage transactions, that 8364 introduces a bunch of code to avoid (by counting signature operations instead of consensus sigops)
6762016-07-21T20:10:12 <luke-jr> sipa: the OP_RETURN fiasco suggests otherwise, no?
6772016-07-21T20:10:26 <jtimon> yeah I heard that pockemon thing is awesome and they're going to make a mario kart version soon in collaboration with google and tesla, but I can't find it on gihub, I'm searching on bitbucket next...
6782016-07-21T20:11:00 <jtimon> sorry, #bitcoin
6792016-07-21T20:11:10 <sipa> luke-jr: but OP_RETURN was a deliberately created alternatove for data storage
6802016-07-21T20:11:33 <sipa> luke-jr: not blocking something intended to be a dos fix, that people perceive as accidentally stopping some transactions
6812016-07-21T20:11:45 <luke-jr> no, it was created for commitments to external data, not storage :/
6822016-07-21T20:11:47 <sipa> in the long term, we can't rely on any of these techniques
6832016-07-21T20:12:05 <sipa> we can't expect people to behave nicely
6842016-07-21T20:12:23 <sipa> but we can design systems that make some behaviour expensive, regardless of intent
6852016-07-21T20:12:38 <sipa> and in the long term, that should be enough
6862016-07-21T20:12:43 <gmaxwell> 80 bytes wasn't needed for 'commitments to external data'...
6872016-07-21T20:13:19 <jtimon> luke-jr: IMO "the right way" ie pay2contractOrHash should replace the rpc interface for op_return
6882016-07-21T20:13:30 <gmaxwell> there is no rpc interface to op_return.
6892016-07-21T20:13:32 <sipa> furthermore, OP_RETURN probably actually did help us get rid of stuff that would otherwise permanently have been added to the utxo set (though i thonk at least the increase to 80 bytes was a mistake)
6902016-07-21T20:15:46 <jtimon> gmaxwell: I have probably misunderstood https://github.com/bitcoin/bitcoin/blob/master/src/rpc/rawtransaction.cpp#L426 one time I was around without deeply reading...
6912016-07-21T20:17:06 <luke-jr> sipa: the problem isn't OP_RETURN itself, but people portraying it as us endorsing data storage on-chain
6922016-07-21T20:17:07 <gmaxwell> jtimon: you were right, I had no clue that was there. wtf.
6932016-07-21T20:17:27 *** murch has joined #bitcoin-core-dev
6942016-07-21T20:18:09 <gmaxwell> jtimon: result of PR #6346
6952016-07-21T20:18:57 <gmaxwell> I give up.
6962016-07-21T20:18:59 *** gmaxwell has left #bitcoin-core-dev
6972016-07-21T20:19:26 <jtimon> gmaxwell: oh, awesome, thanks, traceability++, shall you comment in 6346 ?
6982016-07-21T20:19:59 <midnightmagic> he left.
6992016-07-21T20:22:40 <midnightmagic> whoah
7002016-07-21T20:22:59 <midnightmagic> how did commitid d7078533ebd32bb5071f4dba8e3d9c5a3b1f0d4c get merged
7012016-07-21T20:24:38 <sipa> luke-jr: i'm aware
7022016-07-21T20:25:31 <jtimon> I only saw that when doing a one old version of elements thing for assets, I assumed this was known by everyone since I was unfamiliar with rpc in general
7032016-07-21T20:25:48 *** Ylbam has quit IRC
7042016-07-21T20:26:33 <jtimon> I was mostly only familliar to the rawtx prc which I was modifying
7052016-07-21T20:26:44 <jtimon> s/prc/rpc
7062016-07-21T20:27:43 <jtimon> I just looked weird at the op_return and moved on
7072016-07-21T20:28:00 *** fengling has joined #bitcoin-core-dev
7082016-07-21T20:28:15 *** netsin has joined #bitcoin-core-dev
7092016-07-21T20:28:24 <sipa> heh, i don't remember seeing that PR
7102016-07-21T20:29:11 <midnightmagic> me neither. I can't tell people not to use OP_RETURN anymore.
7112016-07-21T20:29:50 <btcdrak> Counterparty are about to stuff Ethereum contracts into them :-p
7122016-07-21T20:30:08 <sipa> counterparty isn't using our rpc interface
7132016-07-21T20:30:13 <midnightmagic> you reviewed it and ACK'd it
7142016-07-21T20:30:29 * btcdrak sniggers at the back of the room
7152016-07-21T20:31:24 *** sipa has left #bitcoin-core-dev
7162016-07-21T20:32:46 *** fengling has quit IRC
7172016-07-21T20:33:09 <jtimon> let's put effort in the fix before tha blame, please, even if git blame is the source of all fixes
7182016-07-21T20:34:03 *** netsin has quit IRC
7192016-07-21T20:34:15 *** murch has quit IRC
7202016-07-21T20:36:23 *** MarcoFalke has left #bitcoin-core-dev
7212016-07-21T20:38:35 *** TomMc has joined #bitcoin-core-dev
7222016-07-21T20:39:02 *** sipa has joined #bitcoin-core-dev
7232016-07-21T20:39:30 *** netsin has joined #bitcoin-core-dev
7242016-07-21T20:43:47 <instagibbs> I'm guessing the amount of op_return data via that interface is really tiny...
7252016-07-21T20:44:03 <instagibbs> I only found out about it last week
7262016-07-21T20:44:12 <sipa> yes, seems nobody even knew about it...
7272016-07-21T20:44:44 <jtimon> I guess so too, that's how I thought it was allowed, but if there's nobody agains, we should really get this out
7282016-07-21T20:45:31 <jtimon> I mean, it's in the "standard" policy, but I consensus first, policy later
7292016-07-21T20:52:11 *** netsin has quit IRC
7302016-07-21T21:05:26 <sipa> wumpus: good news: yield() doesn't seem to affect performance noticable (i didn't do an extensive benchmark, but early in the chain but:
7312016-07-21T21:05:29 <sipa> 2016-07-21 21:03:48 UpdateTip: new best=000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f height=0 version=0x00000001 log2_work=32.000022 tx=1 date='2009-01-03 18:15:05' progr
7322016-07-21T21:05:33 <sipa> ess=0.000000 cache=0.0MiB(0tx)
7332016-07-21T21:05:44 <sipa> 2016-07-21 21:04:34 UpdateTip: new best=000000000003ba27aa200b1cecaad478d2b00432346c3f1f3986da1afd33e506 height=100000 version=0x00000001 log2_work=58.648173 tx=216577 date='2010-12-29 11:57:43' progress=0.000755 cache=23.4MiB(119863tx)
7342016-07-21T21:06:38 <sipa> with 2173 blocks per second, i doubt we're losing much cpu time
7352016-07-21T21:07:19 <sipa> wumpus: the bad news: it doesn't fix the 'Loading block index' message during activation
7362016-07-21T21:07:26 <sipa> oh, wait, that's expected maybe
7372016-07-21T21:07:33 <sipa> instead of showing something about banlist
7382016-07-21T21:14:40 <sipa> bad news is that i can't reproduce the bug, i guess
7392016-07-21T21:19:53 *** GAit has quit IRC
7402016-07-21T21:19:55 *** gabridome has joined #bitcoin-core-dev
7412016-07-21T21:20:23 *** GAit has joined #bitcoin-core-dev
7422016-07-21T21:25:10 *** gabridome has quit IRC
7432016-07-21T21:29:12 *** netsin has joined #bitcoin-core-dev
7442016-07-21T21:29:30 *** fengling has joined #bitcoin-core-dev
7452016-07-21T21:34:26 *** fengling has quit IRC
7462016-07-21T21:52:22 *** netsin has quit IRC
7472016-07-21T21:59:31 <NicolasDorier> I am trying to remove ISM right now... however, I'm hitting problems with tests testing the ISM logic for old soft fork. Especially, normal ISM have two phase, activation (at 75% new rules are enforced for block version X) and version enforcement (at 95% if nVersion < X, reject). However, the difference between both threshold is only relevant during the
7482016-07-21T21:59:31 <NicolasDorier> transition between the two thresholds and a few block afterward. We can safely replace the activations checks by enforcement checks.... Except that if I do that, then tests rightly break...
7492016-07-21T21:59:48 <NicolasDorier> I'm tempted to just remove the old ISM sf tests
7502016-07-21T22:00:08 <NicolasDorier> and make regnet with all the ISM SF activated from block 0
7512016-07-21T22:00:15 <NicolasDorier> I mean block 1
7522016-07-21T22:00:30 <NicolasDorier> thought ?
7532016-07-21T22:01:24 <sipa> for regtest we probably need command line switches to set what is activated (and at what height?)
7542016-07-21T22:01:59 <NicolasDorier> mh it seems rather bothersome for code going away
7552016-07-21T22:03:24 <NicolasDorier> I'd like ideally to remove old ISM SF tests, and default regnet to have everything activated from block 1. Adding those command line switches just so the old tests continue to work seems like a waste
7562016-07-21T22:04:32 <NicolasDorier> or maybe hard coding some number for regtest
7572016-07-21T22:04:35 <NicolasDorier> and testing that
7582016-07-21T22:04:48 <NicolasDorier> hard coding some heights
7592016-07-21T22:06:32 <luke-jr> sipa: I knew about it, but didn't strongly oppose it on the basis that createrawtransaction is a low-level thing that users shouldn't be exposed to anyway. And I was hoping for the author to add more useful tools (contracthash-like), but that didn't get added. â¹
7602016-07-21T22:08:55 <sipa> luke-jr: it would have been nice if it hashed the data first
7612016-07-21T22:09:23 <sipa> luke-jr: but i guess it's hard to change now
7622016-07-21T22:09:44 <sipa> NicolasDorier: i agree... old ISM tests can probably go away
7632016-07-21T22:10:05 <sipa> NicolasDorier: though only those testing activation... not those testing the new behaviour
7642016-07-21T22:10:21 <NicolasDorier> yes
7652016-07-21T22:11:09 <luke-jr> sipa: yes, but then there'd be no marker possible for example
7662016-07-21T22:12:49 <luke-jr> sipa: as soon as libsecp256k1 has contract-sign primitives though, I hope to put it to use to hopefully kill off proof-of-existence spam ;p
7672016-07-21T22:15:36 <btcdrak> luke-jr: how would that work?
7682016-07-21T22:16:37 <sipa> btcdrak: we can make a signature commit to data
7692016-07-21T22:16:42 <sipa> like a hash
7702016-07-21T22:16:53 <sipa> except it independently also remains a valid signature
7712016-07-21T22:17:03 <sipa> and you can't even tell it commits to something
7722016-07-21T22:17:10 <btcdrak> oh
7732016-07-21T22:17:28 <btcdrak> this sounds like black magic...
7742016-07-21T22:17:33 <sipa> the commitment is obvious to anyone who knows the data being committed to
7752016-07-21T22:17:46 <luke-jr> add a merkle tree, and you can do unlimited proof-of-existence in the background when you send txs
7762016-07-21T22:18:06 <luke-jr> even fingerprint your wallet so you can prove its state at any given point in history, if you want to
7772016-07-21T22:18:57 <sipa> luke-jr: unfortunately, very few people seem interested in timestamping, and many seem to be interested in using the blockchain as a broadcast medium
7782016-07-21T22:19:30 <luke-jr> well, maybe we should add a p2p mechanism that relays data along with tx so long as the tx fee pays for the data size too?
7792016-07-21T22:20:40 <sipa> or find a way to actually make the payment protocol take off, so all that stuff can just remain between sender and receiver?
7802016-07-21T22:20:56 <luke-jr> I'm not sure that stuff has a sender/receiver >_<
7812016-07-21T22:22:15 <sipa> if it doesn't, then why does it belong in bitcoin?
7822016-07-21T22:22:47 <sipa> either it's data needef for the world to verify the transaction, or it is private information between sender and receiver of a payment
7832016-07-21T22:23:12 <luke-jr> it doesn't. :<
7842016-07-21T22:24:35 *** frankenmint has joined #bitcoin-core-dev
7852016-07-21T22:24:53 * luke-jr wonders what it would take to get p2sh^2 deployed and in use
7862016-07-21T22:31:21 *** fengling has joined #bitcoin-core-dev
7872016-07-21T22:34:21 <sipa> luke-jr: people would move to storing data in inputs
7882016-07-21T22:35:04 *** frankenmint has quit IRC
7892016-07-21T22:36:06 *** fengling has quit IRC
7902016-07-21T22:36:31 *** frankenmint has joined #bitcoin-core-dev
7912016-07-21T22:40:42 *** netsin has joined #bitcoin-core-dev
7922016-07-21T22:41:22 *** frankenmint has quit IRC
7932016-07-21T22:43:23 *** frankenmint has joined #bitcoin-core-dev
7942016-07-21T22:54:48 *** CubicEarth has joined #bitcoin-core-dev
7952016-07-21T22:55:40 <luke-jr> sipa: where in policy-accepted inputs can data be stored?
7962016-07-21T22:56:05 <luke-jr> wait, forgot we allow any script now
7972016-07-21T22:56:16 <luke-jr> we could potentially lock that down again?
7982016-07-21T22:56:42 *** GAit has quit IRC
7992016-07-21T22:59:34 *** d_t has quit IRC
8002016-07-21T23:12:03 *** Guyver2 has quit IRC
8012016-07-21T23:26:30 *** jtimon has quit IRC
8022016-07-21T23:30:26 *** Giszmo has quit IRC
8032016-07-21T23:32:37 *** fengling has joined #bitcoin-core-dev
8042016-07-21T23:37:26 *** fengling has quit IRC
8052016-07-21T23:40:30 <GitHub100> [bitcoin] NicolasDorier opened pull request #8391: Consensus: Remove ISM (master...remove-ism) https://github.com/bitcoin/bitcoin/pull/8391
8062016-07-21T23:41:14 <NicolasDorier> lightly tested, surely as flaws... specially as I wasted my night on it. :o