12017-08-24T00:00:49  *** abpa has quit IRC
  22017-08-24T00:07:50  *** Dyaheon has quit IRC
  32017-08-24T00:08:09  *** Dyaheon has joined #bitcoin-core-dev
  42017-08-24T00:09:28  *** Murch has joined #bitcoin-core-dev
  52017-08-24T00:19:28  *** Zimbo has joined #bitcoin-core-dev
  62017-08-24T00:27:50  *** Aaronvan_ is now known as AaronvanW
  72017-08-24T00:30:20  *** Zimbo has quit IRC
  82017-08-24T00:41:53  *** Murch has quit IRC
  92017-08-24T00:42:22  *** Murch has joined #bitcoin-core-dev
 102017-08-24T00:44:00  *** Chris_St1 has joined #bitcoin-core-dev
 112017-08-24T00:48:32  *** jimpo has quit IRC
 122017-08-24T00:51:56  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 132017-08-24T00:52:16  *** Chris_St1 has quit IRC
 142017-08-24T01:07:07  *** Aaronvan_ has joined #bitcoin-core-dev
 152017-08-24T01:08:20  *** AaronvanW has quit IRC
 162017-08-24T01:08:58  *** Murch has quit IRC
 172017-08-24T01:10:59  *** Aaronvan_ is now known as AaronvanW
 182017-08-24T01:13:44  *** dabura667 has joined #bitcoin-core-dev
 192017-08-24T01:14:08  *** treebeardd has joined #bitcoin-core-dev
 202017-08-24T01:29:04  *** Chris_Stewart_5 has quit IRC
 212017-08-24T01:38:16  *** Murch has joined #bitcoin-core-dev
 222017-08-24T01:47:12  <meshcollider> is there any style preference for atomic_bool vs atomic<bool> and similar for other atomic types?
 232017-08-24T01:47:24  <meshcollider> Its not mentioned in the style guidelines
 242017-08-24T01:50:02  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 252017-08-24T01:59:30  *** cluelessperson has quit IRC
 262017-08-24T01:59:33  *** gmaxwell has quit IRC
 272017-08-24T02:09:13  *** Aaronvan_ has joined #bitcoin-core-dev
 282017-08-24T02:09:14  *** gmaxwell has joined #bitcoin-core-dev
 292017-08-24T02:09:42  *** lrvick has joined #bitcoin-core-dev
 302017-08-24T02:10:15  *** Aaronva__ has joined #bitcoin-core-dev
 312017-08-24T02:10:42  *** AaronvanW has quit IRC
 322017-08-24T02:12:51  <BlueMatt> meshcollider: not atm, I dont believe
 332017-08-24T02:13:26  <meshcollider> ok sweet as
 342017-08-24T02:13:52  *** Aaronvan_ has quit IRC
 352017-08-24T02:18:15  <cfields> i have a slight preference for std::atomic<foo>, because that allows everything to be the same. atomic_bool is fine, but obviously doesn't work for atomic_myfoo
 362017-08-24T02:18:30  <cfields> (i'm pretty sure i haven't even been consistent with my own preference though)
 372017-08-24T02:18:55  *** mryandao has joined #bitcoin-core-dev
 382017-08-24T02:22:22  *** ula has quit IRC
 392017-08-24T02:22:25  *** Chris_Stewart_5 has quit IRC
 402017-08-24T02:23:32  <meshcollider> might as well change the couple of atomic_ to atomic<> and add it to the developer notes then aye? Or not worth it
 412017-08-24T02:31:16  <cfields> i don't really mind either way
 422017-08-24T02:57:54  *** Guest71977 has joined #bitcoin-core-dev
 432017-08-24T03:01:06  <achow101> happy segwit activation
 442017-08-24T03:02:44  *** cluelessperson has joined #bitcoin-core-dev
 452017-08-24T03:02:44  *** cluelessperson has joined #bitcoin-core-dev
 462017-08-24T03:05:03  <BlueMatt> indeed it is
 472017-08-24T03:30:27  *** goatpig has quit IRC
 482017-08-24T03:30:44  *** Bluewolf33 has quit IRC
 492017-08-24T03:32:27  *** Dyaheon has quit IRC
 502017-08-24T03:32:53  *** Dyaheon has joined #bitcoin-core-dev
 512017-08-24T03:34:51  *** Aaronva__ has quit IRC
 522017-08-24T03:37:26  *** Guest71977 has quit IRC
 532017-08-24T03:42:29  *** treebeardd has quit IRC
 542017-08-24T04:06:20  *** fanquake has joined #bitcoin-core-dev
 552017-08-24T04:08:34  <fanquake> Has anyone had trouble gitian building the signed windows build? I'm getting a message digest mismatch. Never seen that before.
 562017-08-24T04:09:57  *** Murch has quit IRC
 572017-08-24T04:17:29  *** Murch has joined #bitcoin-core-dev
 582017-08-24T04:22:00  <gmaxwell> w
 592017-08-24T04:42:58  *** treebeardd has joined #bitcoin-core-dev
 602017-08-24T05:17:45  *** Bluewolf33 has joined #bitcoin-core-dev
 612017-08-24T05:28:08  <wumpus> fanquake: for rc2? no, haven't heard issues reported
 622017-08-24T05:29:49  <gmaxwell> wumpus: someone on reddit was saying it was segfaulting for them, I prodded them to open an issue.
 632017-08-24T05:29:53  <fanquake> wumpus yes rc2. Had no issues with rc1.
 642017-08-24T05:31:18  <fanquake> Details here if anyone is interested. https://pastebin.com/WCPjd1gE Will submit built sigs and play around with it later.
 652017-08-24T05:33:20  <wumpus> meshcollider: both are used, I don't think the project needs an opinion of which one to use. Usually a CPU supports a limited set of atomic types, which is a subet of the typedef-ed ones.
 662017-08-24T05:34:16  <meshcollider> ah in that case should i drop the commit to change them from my PR?
 672017-08-24T05:34:17  <meshcollider> https://github.com/bitcoin/bitcoin/pull/11107/commits/f334f44bad5a78978f714148b799cea6e12a525f
 682017-08-24T05:34:52  <wumpus> it's allowed by the standard to define your own atomic<mystruct> but I don't know what it will do, fail or emulate with mutexes somehow
 692017-08-24T05:35:22  <wumpus> yes, no need to make a rule about it, it doesn't affect safety
 702017-08-24T05:35:33  *** arowser has quit IRC
 712017-08-24T05:35:59  <meshcollider> nah it was just for the sake of consistency since most cases used atomic<bool>, only like 10 in the whole project used atomic_bool
 722017-08-24T05:36:24  *** Dyaheon has quit IRC
 732017-08-24T05:36:58  *** arowser has joined #bitcoin-core-dev
 742017-08-24T05:37:03  *** Dyaheon has joined #bitcoin-core-dev
 752017-08-24T05:37:20  <meshcollider> removed
 762017-08-24T05:39:01  <wumpus> we should avoid creating too many little rules, that people have to slog through before contributing, my original idea with the guidelines in developer-notes was to add useful review criteria with rationale how they make the code safer
 772017-08-24T05:40:16  <wumpus> then some things like consistent variable naming which are reasonably important to be able to distinguish various scopes
 782017-08-24T05:42:16  <wumpus> btw has anyone tried cross-compiling bitcoin core for windows from ubuntu zesty/17.04 or pre-.10
 792017-08-24T05:43:04  <wumpus> I'd like to know if they solved some of the issues that made 16.04 so terrible e.g. the lack of sane support for std::threads by default, I'll try but I wonder if someone else did already
 802017-08-24T05:48:09  <wumpus> fanquake: whoa, I never saw that one before. Maybe cfields can comment what it means.  Did your unsigned assert match?
 812017-08-24T05:51:48  <sipa> wumpus: agree, for many things it really doesn't matter what approach is used
 822017-08-24T05:52:18  <fanquake> wumpus my win-unsigned sigs match yours. Will PR them in a sec.
 832017-08-24T05:52:39  *** laurentmt has joined #bitcoin-core-dev
 842017-08-24T05:53:13  *** laurentmt has quit IRC
 852017-08-24T05:55:48  <wumpus> fanquake: rah! I expected an error like this if the thing-to-be-signed mismatches, so the signature, which is added without heed to what it is added to, mismatches. But if the  unsigned matches I can't think of any reason for that error.
 862017-08-24T05:57:35  <luke-jr> ‎[05:29:49] ‎<‎gmaxwell‎>‎ wumpus: someone on reddit was saying it was segfaulting for them, I prodded them to open an issue. <-- this "someone" I have labelled as a troll FYI, maybe a bogus report
 872017-08-24T05:58:40  <wumpus> gmaxwell: luke-jr: well if he has steps to reproduce it, and can open an issue, I don't care if it's a troll :)
 882017-08-24T05:58:54  <luke-jr> wumpus: sure, just saying, if he doesn't answer, it's probably made-up
 892017-08-24T06:00:37  <wumpus> agree, making up segfaults just to sabotage the rc process would be a new low, but yeah you never know here
 902017-08-24T06:02:18  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/8858b6ddd3bc...00ada17230f7
 912017-08-24T06:02:18  <bitcoin-git> bitcoin/master fa14b67 MarcoFalke: [doc] build-windows: Mention that only trusty works
 922017-08-24T06:02:19  <bitcoin-git> bitcoin/master 00ada17 Wladimir J. van der Laan: Merge #11119: [doc] build-windows: Mention that only trusty works...
 932017-08-24T06:02:28  <fanquake> wumpus opened a PR at the gitian sigs repo if you want to compare sigs.
 942017-08-24T06:02:58  <bitcoin-git> [bitcoin] laanwj closed pull request #11119: [doc] build-windows: Mention that only trusty works (master...Mf1708-docBuildWinTrusty) https://github.com/bitcoin/bitcoin/pull/11119
 952017-08-24T06:03:02  *** marcoagner has quit IRC
 962017-08-24T06:05:25  <wumpus> fanquake: all ok
 972017-08-24T06:09:58  *** marcoagner has joined #bitcoin-core-dev
 982017-08-24T06:14:01  <wumpus> fanquake: I retried that part of gitian process here, got this output: https://0bin.net/paste/63Ek6D3S2Skvx3j7#2hu2HQVGq49WrG1g0a3-HRT/77bV80g7lpMDgES7KUs
 992017-08-24T06:15:02  <wumpus> PE checksum is the same, Calculated message digest : 73AAB82BB3761BE13A9DC0ACAC0BD35AC51C48DC matches in my case though
1002017-08-24T06:18:17  *** JackH has joined #bitcoin-core-dev
1012017-08-24T06:18:18  *** JackH has quit IRC
1022017-08-24T06:18:44  *** JackH has joined #bitcoin-core-dev
1032017-08-24T06:20:20  <wumpus> however your input file's sha256sum af3da01beda391e06f2fb4d2dced316b580f989b71ee886582aaddac5c00374f for bitcoin-0.15.0-win64-setup-unsigned.exe matches
1042017-08-24T06:21:06  <wumpus> some faulty case of caching maybe?
1052017-08-24T06:21:43  <fanquake> wumpus not sure. I'm re-running the windows build now.
1062017-08-24T06:25:58  <wumpus> you did copy the right bitcoin-0.15.0-win64-setup-unsigned.exe file to inputs/? (e.g. not a stale one from rc1, for example?)
1072017-08-24T06:33:21  *** Murch has quit IRC
1082017-08-24T06:33:34  *** jl2012 has joined #bitcoin-core-dev
1092017-08-24T06:36:12  <fanquake> wumpus it should have been the right one. Will check shortly as it will still be in /inputs
1102017-08-24T06:37:18  <wumpus> maybe we should add a sha256sum of the input file to that descriptor's build output, to diagnose cases like this
1112017-08-24T06:46:24  *** treebeardd has quit IRC
1122017-08-24T06:48:10  *** Deacyded has quit IRC
1132017-08-24T06:54:25  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/00ada17230f7...affe9271aa49
1142017-08-24T06:54:25  <bitcoin-git> bitcoin/master 79191f5 Joe Harvell: Add option -stdinrpcpass to allow RPC password to be read from standard input
1152017-08-24T06:54:26  <bitcoin-git> bitcoin/master affe927 Wladimir J. van der Laan: Merge #10997: RPC: Add option -stdinrpcpass to bitcoin-cli to allow RPC password to be read from standard input...
1162017-08-24T06:54:58  <bitcoin-git> [bitcoin] laanwj closed pull request #10997: RPC: Add option -stdinrpcpass to bitcoin-cli to allow RPC password to be read from standard input (master...stdinrpcpass) https://github.com/bitcoin/bitcoin/pull/10997
1172017-08-24T06:55:23  *** SopaXorzTaker has joined #bitcoin-core-dev
1182017-08-24T06:56:11  *** jannes has joined #bitcoin-core-dev
1192017-08-24T06:56:34  *** eck has quit IRC
1202017-08-24T06:57:42  *** alreadylate has joined #bitcoin-core-dev
1212017-08-24T06:58:42  *** BashCo has quit IRC
1222017-08-24T06:59:03  *** eck has joined #bitcoin-core-dev
1232017-08-24T07:02:11  *** eck has quit IRC
1242017-08-24T07:02:11  *** eck has joined #bitcoin-core-dev
1252017-08-24T07:02:22  *** ghost43 has quit IRC
1262017-08-24T07:02:36  *** ghost43 has joined #bitcoin-core-dev
1272017-08-24T07:08:23  *** alreadylate has quit IRC
1282017-08-24T07:18:37  <bitcoin-git> [bitcoin] practicalswift closed pull request #10961: Improve readability of DecodeBase58Check(...) (master...DecodeBase58Check-cleanup) https://github.com/bitcoin/bitcoin/pull/10961
1292017-08-24T07:19:20  *** BashCo has joined #bitcoin-core-dev
1302017-08-24T07:19:35  <bitcoin-git> [bitcoin] practicalswift reopened pull request #10961: Improve readability of DecodeBase58Check(...) (master...DecodeBase58Check-cleanup) https://github.com/bitcoin/bitcoin/pull/10961
1312017-08-24T07:22:04  *** jtimon has quit IRC
1322017-08-24T07:52:05  *** Alina-malina has quit IRC
1332017-08-24T07:52:45  *** alreadylate has joined #bitcoin-core-dev
1342017-08-24T07:55:04  *** Alina-malina has joined #bitcoin-core-dev
1352017-08-24T08:13:29  *** ghost43 has quit IRC
1362017-08-24T08:13:45  *** ghost43 has joined #bitcoin-core-dev
1372017-08-24T08:15:01  *** jonasa has quit IRC
1382017-08-24T08:35:01  *** d9b4bef9 has quit IRC
1392017-08-24T08:35:20  *** Deacyde has joined #bitcoin-core-dev
1402017-08-24T08:36:08  *** d9b4bef9 has joined #bitcoin-core-dev
1412017-08-24T08:49:20  *** Deacydal has joined #bitcoin-core-dev
1422017-08-24T08:51:07  *** Deacyde has quit IRC
1432017-08-24T08:54:28  *** Deacydal has quit IRC
1442017-08-24T08:54:29  *** Deacyde has joined #bitcoin-core-dev
1452017-08-24T08:57:42  *** Dyaheon has quit IRC
1462017-08-24T08:58:51  *** Dyaheon has joined #bitcoin-core-dev
1472017-08-24T09:10:41  *** justan0theruser has quit IRC
1482017-08-24T09:20:01  *** fanquake has quit IRC
1492017-08-24T09:23:05  *** fanquake has joined #bitcoin-core-dev
1502017-08-24T10:02:58  *** fanquake1 has joined #bitcoin-core-dev
1512017-08-24T10:03:45  *** fanquake has quit IRC
1522017-08-24T10:06:54  *** dabura667 has quit IRC
1532017-08-24T10:14:46  *** JackH has quit IRC
1542017-08-24T10:22:33  *** laurentmt has joined #bitcoin-core-dev
1552017-08-24T10:22:54  *** laurentmt has quit IRC
1562017-08-24T10:49:42  <meshcollider> hmm https://github.com/bitcoin/bitcoin/blob/master/doc/gitian-building.md uses br0 but https://github.com/bitcoin/bitcoin/blob/master/contrib/gitian-build.sh uses lxcbr0, are they supposed to be different?
1572017-08-24T10:51:26  <meshcollider> (unrelated to the issue fanquake was having btw)
1582017-08-24T11:14:45  *** tiagotrs has joined #bitcoin-core-dev
1592017-08-24T11:15:03  *** tonikt has joined #bitcoin-core-dev
1602017-08-24T11:15:16  *** tonikt has left #bitcoin-core-dev
1612017-08-24T11:41:20  *** Dyaheon has quit IRC
1622017-08-24T11:42:28  *** Dyaheon has joined #bitcoin-core-dev
1632017-08-24T11:49:21  *** AaronvanW has joined #bitcoin-core-dev
1642017-08-24T11:50:49  *** jtimon has joined #bitcoin-core-dev
1652017-08-24T11:56:33  *** laurentmt has joined #bitcoin-core-dev
1662017-08-24T12:01:22  *** laurentmt has quit IRC
1672017-08-24T12:09:56  *** goatpig has joined #bitcoin-core-dev
1682017-08-24T12:16:03  *** Alina-malina has quit IRC
1692017-08-24T12:16:03  *** Alina-malina has joined #bitcoin-core-dev
1702017-08-24T12:26:57  *** Evel-Knievel has quit IRC
1712017-08-24T12:28:30  *** Evel-Knievel has joined #bitcoin-core-dev
1722017-08-24T12:40:06  <michagogo> meshcollider: looks like the former script exports an env variable to use that device
1732017-08-24T12:40:19  <michagogo> The latter*
1742017-08-24T12:40:42  <michagogo> br0 is the default that gitian uses (and if I'm not mistaken, that's what's set up on my system)
1752017-08-24T12:44:42  <GAit> I'm a bit confused by a failure, https://travis-ci.org/bitcoin/bitcoin/jobs/267945919 - two out of seven failed, seems a race but not sure what is causing it. Is stop_nodes() synchronous?
1762017-08-24T12:46:00  <instagibbs> GAit, looks like a "normal" failure: assert wait_until(lambda: len(self.nodes[1].getrawmempool()) == 5)
1772017-08-24T12:48:05  <GAit> What do you mean normal? it shouldn't fail and indeed it doesn't fail on the other runners nor locally.
1782017-08-24T12:49:30  <GAit> the test does this: have a node with 5 tx in mempool, dump that to file, copy file to second node, start second node, make sure it has those 5 tx - without synchronizing manually.
1792017-08-24T12:56:06  <fanquake1> GAit I restarted the tests
1802017-08-24T13:00:16  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1812017-08-24T13:00:42  <jnewbery> fanquake1 - I was just looking at the Travis output and it disappeared under my feet :(
1822017-08-24T13:01:14  <jnewbery> in any case, if it's a new test and it failed first time on Travis it's probably reproducible
1832017-08-24T13:02:41  *** Deacydal has joined #bitcoin-core-dev
1842017-08-24T13:04:46  *** ghost43 has quit IRC
1852017-08-24T13:06:22  *** Deacyde has quit IRC
1862017-08-24T13:06:30  *** ghost43 has joined #bitcoin-core-dev
1872017-08-24T13:07:19  <instagibbs> GAit, it means that it appears to be related to your changes, or maybe you got unlucky
1882017-08-24T13:09:16  <fanquake1> jnewbery sorry. Looks like the same two have failed anyways.
1892017-08-24T13:10:18  <GAit> jnewbery: I merged mempool_dump into mempool_persist. instagibbs: def related to my changes, what i don't get is which is causing it to be racy. Maybe os.rename but i'd be very surprised.
1902017-08-24T13:10:43  *** Giszmo has joined #bitcoin-core-dev
1912017-08-24T13:11:43  <GAit> jnewbery: seems we get the same failure, but only on some builders
1922017-08-24T13:13:22  <jnewbery> ok, I'll try to reproduce locally
1932017-08-24T13:17:05  <jnewbery> oh, it might be a merge conflict with master. You no longer need to assert on the return value of `wait_until()` (after #11068)
1942017-08-24T13:17:26  <jnewbery> Try rebasing on master and changing the `assert wait_until()`s to `wait_until()`s
1952017-08-24T13:19:23  *** Guyver2 has joined #bitcoin-core-dev
1962017-08-24T13:19:56  <GAit> thanks, but i didn't rebase so i don't see how master can hurt it? - but very happy to rebase. Do you think I can also squash things while at it?
1972017-08-24T13:22:35  *** Chris_Stewart_5 has quit IRC
1982017-08-24T13:25:04  <jnewbery> GAit: Github automatically creates a merge into master, which is what Travis takes for its build: https://github.com/bitcoin/bitcoin/commit/30dfb2ceda2e8aae954a25b6a3cef63d24cf6512
1992017-08-24T13:25:28  <jnewbery> There's no merge conflict, but the semantics of that function have changed in a different file, which I believe is what caused your build failure
2002017-08-24T13:25:42  <jnewbery> if you merge or rebase locally and then test I expect it'll fail in the same way
2012017-08-24T13:25:49  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2022017-08-24T13:25:58  *** Bluewolf33 has quit IRC
2032017-08-24T13:26:16  *** Bluewolf33 has joined #bitcoin-core-dev
2042017-08-24T13:26:39  <jnewbery> And yes, probably a good idea to squash at this point
2052017-08-24T13:28:53  <GAit> thanks! i thought i was crazy :) indeed fails locally now, will fix and squash
2062017-08-24T13:31:15  <jnewbery> GAit: no problem. I'll re-review once you've pushed
2072017-08-24T13:34:07  *** Cheeseo has joined #bitcoin-core-dev
2082017-08-24T13:35:10  <GAit> jnewbery: done but i'd wait for travis before reviewing
2092017-08-24T13:35:33  *** alreadylate has quit IRC
2102017-08-24T13:39:42  *** justanotheruser has joined #bitcoin-core-dev
2112017-08-24T13:39:45  *** promag has joined #bitcoin-core-dev
2122017-08-24T13:40:19  <promag> jnewbery: do you think travis should merge with master and then run the tests?
2132017-08-24T13:43:32  <GAit> promag: that is what it does now and what made it fail, wait_until changed in master after i branched so I had to rebase
2142017-08-24T13:44:33  *** Dyaheon has quit IRC
2152017-08-24T13:45:29  <GAit> i guess is better to fail earlier rather merge day but it was confusing for me
2162017-08-24T13:46:56  <promag> right, the problem is when master forwards but you don't push to your branch, and at that moment your branch can have problems.
2172017-08-24T13:47:36  *** Dyaheon has joined #bitcoin-core-dev
2182017-08-24T13:47:40  <GAit> yes and if the code is still mergable it may suffer only too late. But rebasing often (which I like) breaks reviews doesn't it?
2192017-08-24T13:49:53  <promag> usually unless you point the diff between the old and new commit.
2202017-08-24T13:59:41  *** Giszmo has quit IRC
2212017-08-24T14:01:19  <instagibbs> wish github had gitlab feature of "diff since last push"
2222017-08-24T14:07:01  *** promag has quit IRC
2232017-08-24T14:07:57  *** Evel-Knievel has quit IRC
2242017-08-24T14:09:13  *** Evel-Knievel has joined #bitcoin-core-dev
2252017-08-24T14:10:48  *** promag has joined #bitcoin-core-dev
2262017-08-24T14:15:17  *** promag has joined #bitcoin-core-dev
2272017-08-24T14:20:25  *** promag has quit IRC
2282017-08-24T14:20:36  *** jonasa has joined #bitcoin-core-dev
2292017-08-24T14:28:31  *** promag has joined #bitcoin-core-dev
2302017-08-24T14:30:47  *** fanquake1 has quit IRC
2312017-08-24T14:32:08  <GAit> jnewbery: i like what you are doing in #11121
2322017-08-24T14:33:33  <jnewbery> GAit thanks. Just working on some nits from kallewoof and MarcoFalke. I'll push an updated branch soon. Reviews always appreciated :)
2332017-08-24T14:36:49  <GAit> jnewbery: :) - do you know why there are sleeps in the tests all over the place? if they are flacky without perhaps we need a better way to wait for the node to be ready?
2342017-08-24T14:37:05  *** tiagotrs has quit IRC
2352017-08-24T14:44:25  <GAit> mempool_persist seems to work fine locally without the sleeps (and 3 whole seconds faster!)
2362017-08-24T14:45:28  *** promag has quit IRC
2372017-08-24T14:50:40  *** Aaronvan_ has joined #bitcoin-core-dev
2382017-08-24T14:50:48  *** AaronvanW has quit IRC
2392017-08-24T15:09:27  <jnewbery> GAit - yes there are probably sleeps that can be removed
2402017-08-24T15:13:18  *** promag has joined #bitcoin-core-dev
2412017-08-24T15:13:47  *** tiagotrs has joined #bitcoin-core-dev
2422017-08-24T15:14:38  *** promag has quit IRC
2432017-08-24T15:15:38  *** tiagotrs has quit IRC
2442017-08-24T15:15:38  *** tiagotrs has joined #bitcoin-core-dev
2452017-08-24T15:34:56  *** SopaXorzTaker has quit IRC
2462017-08-24T15:38:45  *** Murch has joined #bitcoin-core-dev
2472017-08-24T15:39:08  <MarcoFalke> Indeed, we should remove all sleeps other than for explicit polling
2482017-08-24T15:40:09  *** promag has joined #bitcoin-core-dev
2492017-08-24T15:50:50  *** SopaXorzTaker has joined #bitcoin-core-dev
2502017-08-24T15:51:11  *** promag has joined #bitcoin-core-dev
2512017-08-24T15:51:37  *** Dyaheon has quit IRC
2522017-08-24T15:52:46  *** promag has quit IRC
2532017-08-24T15:53:22  *** btcdrak has joined #bitcoin-core-dev
2542017-08-24T15:55:17  *** Dyaheon has joined #bitcoin-core-dev
2552017-08-24T16:03:44  *** Dizzle has joined #bitcoin-core-dev
2562017-08-24T16:07:07  *** chjj has quit IRC
2572017-08-24T16:07:14  *** promag has joined #bitcoin-core-dev
2582017-08-24T16:13:07  *** Dizzle has quit IRC
2592017-08-24T16:16:57  *** tiagotrs has quit IRC
2602017-08-24T16:18:51  *** Giszmo has joined #bitcoin-core-dev
2612017-08-24T16:20:29  *** chjj has joined #bitcoin-core-dev
2622017-08-24T16:21:31  *** Dizzle has joined #bitcoin-core-dev
2632017-08-24T16:23:42  *** abpa has joined #bitcoin-core-dev
2642017-08-24T16:36:27  *** adrh has joined #bitcoin-core-dev
2652017-08-24T16:39:40  <adrh> hey guys. i need some help if you can help me. I've been busting my head off...i want to build a script that uses sendtoaddress and i really can't get it to work
2662017-08-24T16:39:46  <adrh> here is my script: https://pastebin.com/fESuZDvz
2672017-08-24T16:41:10  <adrh> it works to list my address, but i can't make sendtoaddress work
2682017-08-24T16:45:07  *** BashCo has quit IRC
2692017-08-24T16:48:15  *** tiagotrs has joined #bitcoin-core-dev
2702017-08-24T16:48:24  *** gwillen has joined #bitcoin-core-dev
2712017-08-24T16:50:44  <adrh> anyone ?
2722017-08-24T16:54:02  <instagibbs> adrh, try #bitcoin
2732017-08-24T16:54:50  <adrh> i tried . nobody can help me there at the moment
2742017-08-24T17:02:31  *** BashCo has joined #bitcoin-core-dev
2752017-08-24T17:03:06  <instagibbs> sorry, off topic here
2762017-08-24T17:03:15  *** alreadylate has joined #bitcoin-core-dev
2772017-08-24T17:04:31  <adrh> i dont know where to ask to be honest. i'm trying for 8 hours to make it work...
2782017-08-24T17:04:56  *** jimpo has joined #bitcoin-core-dev
2792017-08-24T17:05:05  *** alreadylate has quit IRC
2802017-08-24T17:21:21  *** adrh has quit IRC
2812017-08-24T17:22:44  <luke-jr> I seem to have a reproducable crash at startup with rc2 on testnet
2822017-08-24T17:23:34  <gmaxwell> luke-jr: whats the backtrace
2832017-08-24T17:23:42  <luke-jr> getting it
2842017-08-24T17:25:27  <luke-jr> http://codepad.org/aiVTgE08
2852017-08-24T17:25:58  <luke-jr> lock order issue, so probably wouldn't affect prod bins
2862017-08-24T17:28:24  <gmaxwell> what did the lockorder debugging print
2872017-08-24T17:29:51  <luke-jr> it's in the pastebin
2882017-08-24T17:30:55  <luke-jr> I don't understand how the walletdb.cpp lock is still in the lock order here
2892017-08-24T17:44:00  <ryanofsky> probably the easiest way to fix this is to just change LoadWallet LOCK(wallet) to a LOCK2(main, wallet)
2902017-08-24T17:44:19  <BlueMatt> ryanofsky: that feels strange...maybe cs_main in CreateWalletFromFile in wallet.cpp instead?
2912017-08-24T17:44:24  <luke-jr> ryanofsky: do you understand the problem? why is walletdb's lock relevant here?
2922017-08-24T17:44:26  <BlueMatt> taking cs_main inside of walletdb is...yuck
2932017-08-24T17:44:33  <BlueMatt> luke-jr: cause its a lock inversion
2942017-08-24T17:44:45  <BlueMatt> walletdb takes the wallet lock, so...lock inversion?
2952017-08-24T17:44:47  <luke-jr> BlueMatt: but walletdb's lock is released before we get to the wallet lock?
2962017-08-24T17:44:53  <BlueMatt> no it isnt
2972017-08-24T17:44:59  <BlueMatt> ReadKeyValue calls back into wallet
2982017-08-24T17:45:44  *** chjj has quit IRC
2992017-08-24T17:46:16  <luke-jr> BlueMatt: to ReacceptWalletTransactions?
3002017-08-24T17:46:18  <luke-jr> how?
3012017-08-24T17:46:35  <MarcoFalke> wumpus: Mind to create a gitian.docs under bitcoin-core?
3022017-08-24T17:46:45  <BlueMatt> luke-jr: yes
3032017-08-24T17:46:47  <BlueMatt> LoadToWallet
3042017-08-24T17:46:54  <MarcoFalke> You wanted me to write a fedora guide for it
3052017-08-24T17:47:48  <luke-jr> BlueMatt: that doesn't call Reaccept
3062017-08-24T17:48:06  <bitcoin-git> [bitcoin] promag opened pull request #11125: Add bitcoin-cli -stdinrpcpass functional test (master...2017-08-stdinrpcpass-functional-test) https://github.com/bitcoin/bitcoin/pull/11125
3072017-08-24T17:48:39  <promag> jnewbery: ^ as soon as you can? ty!
3082017-08-24T17:49:11  <wumpus> MarcoFalke: you want a repo specifically for gitian docs?
3092017-08-24T17:49:28  <BlueMatt> luke-jr: the conflict is MarkConflicted, not Reaccept
3102017-08-24T17:49:46  * luke-jr peers at his editor
3112017-08-24T17:50:35  <luke-jr> oh, the backtrace was in Reaccept
3122017-08-24T17:50:37  <MarcoFalke> jup, they don't really belong in the main repo
3132017-08-24T17:50:49  <MarcoFalke> Also, a GitHub wiki is not suitable
3142017-08-24T17:51:22  <MarcoFalke> It is either open to be edited by anyone (with a GitHub account) or effectively none
3152017-08-24T17:52:21  *** harding has joined #bitcoin-core-dev
3162017-08-24T17:54:57  *** Aaronvan_ is now known as AaronvanW
3172017-08-24T17:57:45  <wumpus> but I can't see a gitian.docs repo ever containing more than one or two files - what about a more general 'docs' repo, which could potentially include other things as well?
3182017-08-24T17:58:04  *** jimpo has quit IRC
3192017-08-24T17:58:26  <luke-jr> wumpus: +1
3202017-08-24T17:58:37  *** chjj has joined #bitcoin-core-dev
3212017-08-24T17:58:38  * luke-jr wonders how to make a test that would pick up on this wallet lock issue
3222017-08-24T17:58:55  <luke-jr> if (prevtx.nIndex == -1 && !prevtx.hashUnset()) { <-- this line needs a comment :/
3232017-08-24T17:58:55  <MarcoFalke> wumpus: Fine with me
3242017-08-24T17:59:09  <wumpus> MarcoFalke: ok
3252017-08-24T17:59:21  <luke-jr> otoh, gitian docs may be unversioned, whereas other docs might be versioned?
3262017-08-24T18:00:42  <wumpus> nah, all documentation tends to be about the newest versions
3272017-08-24T18:01:01  <wumpus> could add sections for building older versions
3282017-08-24T18:01:06  *** oooo has joined #bitcoin-core-dev
3292017-08-24T18:01:08  <luke-jr> wumpus: I just mean, it makes sense to tag docs per release, but not gitian docs necessarily
3302017-08-24T18:01:23  *** ghost43 has quit IRC
3312017-08-24T18:01:24  <wumpus> I'd prefer not to do any tagging/brancing in the docs repo
3322017-08-24T18:01:50  <wumpus> document change control tends to be very diffrent from source code
3332017-08-24T18:01:54  <luke-jr> wumpus: so we keep release-specific docs with the main repo?
3342017-08-24T18:02:15  *** jimpo has joined #bitcoin-core-dev
3352017-08-24T18:02:17  <wumpus> yes, there are no plans to move anythingbesides the gitian building doc at this point
3362017-08-24T18:02:52  <luke-jr> i c
3372017-08-24T18:06:21  *** ghost43 has joined #bitcoin-core-dev
3382017-08-24T18:08:30  *** oooo has quit IRC
3392017-08-24T18:09:04  <wumpus> MarcoFalke: https://github.com/bitcoin-core/docs.git
3402017-08-24T18:09:14  <MarcoFalke> ty
3412017-08-24T18:09:48  <wumpus> you should have push access, we can add other maintainers later
3422017-08-24T18:14:52  *** jimpo has quit IRC
3432017-08-24T18:15:58  *** abpa has quit IRC
3442017-08-24T18:19:35  <cfields> sipa: do you have local work on top of #11117? Anything I can help with there?
3452017-08-24T18:22:00  *** Veseli_Zagorec has joined #bitcoin-core-dev
3462017-08-24T18:22:28  *** ghost43 has quit IRC
3472017-08-24T18:23:09  <sipa> cfields: nope
3482017-08-24T18:23:12  *** ghost43 has joined #bitcoin-core-dev
3492017-08-24T18:23:18  <sipa> but i don't expect it to be much
3502017-08-24T18:24:22  *** jimpo has joined #bitcoin-core-dev
3512017-08-24T18:27:27  <cfields> ok. let me know if there's anything i can help with without stepping on your toes
3522017-08-24T18:29:46  <bitcoin-git> [bitcoin] ryanofsky opened pull request #11126: Acquire cs_main lock before cs_wallet during wallet initialization (master...pr/loadlock2) https://github.com/bitcoin/bitcoin/pull/11126
3532017-08-24T18:45:05  *** tiagotrs has quit IRC
3542017-08-24T18:48:40  *** Veseli_Zagorec has quit IRC
3552017-08-24T18:58:16  *** clarkmoody has quit IRC
3562017-08-24T18:59:58  *** clarkmoody has joined #bitcoin-core-dev
3572017-08-24T19:00:00  <sipa> WOOSH
3582017-08-24T19:00:26  *** praxeology1 has joined #bitcoin-core-dev
3592017-08-24T19:00:37  <sipa> meetingh?
3602017-08-24T19:00:46  <jonasschnelli> \o/
3612017-08-24T19:01:20  *** Guest79199 has joined #bitcoin-core-dev
3622017-08-24T19:01:28  *** chjj has quit IRC
3632017-08-24T19:01:45  <wumpus> #startmeeting
3642017-08-24T19:01:45  <lightningbot> Meeting started Thu Aug 24 19:01:45 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
3652017-08-24T19:01:45  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
3662017-08-24T19:01:53  <gmaxwell> wumpus: you have the best nameping.
3672017-08-24T19:02:12  <wumpus> #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 jl2012 achow101
3682017-08-24T19:02:17  <kanzure> hi.
3692017-08-24T19:02:18  <achow101> hi
3702017-08-24T19:02:32  <BlueMatt> happy segwit everyone
3712017-08-24T19:02:51  <sipa> short topic: thanks and congrats everyone with SegWit... it seems it activated on the network without a glitch
3722017-08-24T19:02:57  <wumpus> yes, congratulations everyone!
3732017-08-24T19:03:03  <jonasschnelli> wohoo!
3742017-08-24T19:03:06  <achow101> yay!
3752017-08-24T19:03:10  <cfields> hi
3762017-08-24T19:03:14  <wumpus> it took lots of time, and lots of sweat, but we did it
3772017-08-24T19:03:36  <kanzure> whole bitcoin community did it
3782017-08-24T19:03:44  <gmaxwell> sipa: well except the glitch of miners universally having maxblocksize=1000000 in their configs, resulting in overly small blocks even though there have been several oppturnityies to make bigger ones.
3792017-08-24T19:03:59  <sipa> gmaxwell: everything on its time
3802017-08-24T19:04:00  <luke-jr> s/glitch/good thing/
3812017-08-24T19:04:06  <sipa> misconceptions are hard to fix
3822017-08-24T19:04:07  <gmaxwell> You may well have jinxed us, since things blowing up might only happen with a >1MB block. :)
3832017-08-24T19:04:10  <BlueMatt> yes, some miner appear to be confused by maxblocksize/maxblockweight options, we need #11100
3842017-08-24T19:04:11  <wumpus> we should probably publicize some segwit miner's faq thing
3852017-08-24T19:04:14  <wumpus> on bitcoincore.org
3862017-08-24T19:04:26  <achow101> wumpus: isn't there already one?
3872017-08-24T19:04:28  <luke-jr> wumpus: not if they don't encourage big blocks. :/
3882017-08-24T19:04:32  <luke-jr> err, not if they do*
3892017-08-24T19:04:33  <kanzure> luke-jr: it would have been better if the expectations around that would have been communicated, then i would agree with you about good thing. expectation mismatch is not ideal.
3902017-08-24T19:04:48  <wumpus> achow101: there is a segwit faq but it doesn't include this
3912017-08-24T19:04:49  *** Dyaheon has quit IRC
3922017-08-24T19:04:51  <achow101> https://bitcoincore.org/en/2016/10/27/segwit-upgrade-guide/#miners
3932017-08-24T19:05:02  <achow101> not really an faq I guess
3942017-08-24T19:05:36  <gmaxwell> achow101: says nothing about needing to remove the maxblocksize setting and setting maxblockweight=4000000
3952017-08-24T19:05:48  <luke-jr> there is no such need, nor is it good for them to do so
3962017-08-24T19:06:19  <kanzure> luke-jr: it's about being honest about expectations. if miners expected the software to do something different, then we need to better document the configuration.
3972017-08-24T19:06:30  <wumpus> kanzure: +1
3982017-08-24T19:06:55  <harding> Is there anything else that should go into a current segwit faq for miners?
3992017-08-24T19:06:55  <wumpus> there is apparently a lack of documentation for these optons and what they do, that's clear, no matter what your opinion on what their value should be is
4002017-08-24T19:07:12  <kanzure> sounds like there's some requests for a post-activation faq
4012017-08-24T19:07:18  <wumpus> #topic segwit faq for miners
4022017-08-24T19:07:23  <luke-jr> hm, I thought we had documented it before, but I can't find it
4032017-08-24T19:07:31  *** Dyaheon has joined #bitcoin-core-dev
4042017-08-24T19:07:57  <BlueMatt> blockmaxsize really just needs to be removed, it has caused significant confusion with several mining pool operators...if you want to limit the block's size-in-bytes you can do that yourself as a gbt client (isnt that what gbt is for?)
4052017-08-24T19:08:04  <gmaxwell> wumpus: it's super confusing for people.  esp the fact that the maxblocksize setting (which doesn't make any sense anymore) says it defaults to 750k so then I tell people to remove it and set maxblockweight=4000000 and they don't believe it'll make a >750k block.
4062017-08-24T19:08:05  *** Dizzle has quit IRC
4072017-08-24T19:08:06  <wumpus> not sure if there's any other ones, have there been any other frequent questions about segwit by miners?
4082017-08-24T19:08:22  <luke-jr> BlueMatt: size is often the bottleneck today, so it makes sense to limit by size
4092017-08-24T19:08:36  <gmaxwell> so then I say, "it will but fine, just set blockmaxsize=4000000" and then they think if they set if over 1M they'll make invalid blocks. :(
4102017-08-24T19:08:37  <BlueMatt> luke-jr: ok, then gbt clients can do so
4112017-08-24T19:08:56  <gmaxwell> luke-jr: size is a bottleneck in _what_?
4122017-08-24T19:09:17  <BlueMatt> wumpus: I've literally heard confusion to the tone of what gmaxwell described from every mining pool operator I spoke to
4132017-08-24T19:09:19  <luke-jr> gmaxwell: IBD mainly at this point I guess
4142017-08-24T19:09:22  <BlueMatt> that option needs to die
4152017-08-24T19:09:26  <sipa> luke-jr: with BIP152, the size hardly matters, except if you're ridiculously bandwidth constraint to the point you'd be unable to keep a node synced in the first place
4162017-08-24T19:09:38  <sipa> *constrained
4172017-08-24T19:09:39  <achow101> luke-jr: IBD is too late to save already
4182017-08-24T19:09:42  <luke-jr> sipa: blocksonly?
4192017-08-24T19:09:43  <gmaxwell> luke-jr: not for anyone with an internet connection beyond a few megabits in speed.
4202017-08-24T19:10:24  <gmaxwell> luke-jr: IBD time is limited by chainstate database operations for parties that aren't totally network starved.
4212017-08-24T19:10:24  <luke-jr> achow101: it's nothing like as bad as it could be
4222017-08-24T19:10:41  <cfields> i've seen a ton of questions about segwit and "the addresses that start with a 3"...
4232017-08-24T19:10:50  <kanzure> ya i have seen mostly non-miner questions
4242017-08-24T19:10:51  <BlueMatt> anyway, so aside from luke is there anyone who objects generally to removing -maxblocksize? (ala #11100)
4252017-08-24T19:10:55  <wumpus> BlueMatt: IMO the solution to lack of documentation  should be documentation, changing around things more so there's differences between versions to explain too
4262017-08-24T19:11:05  <cfields> a quick update and faq about segwit addresses, how they look, and how they'll look soon would be helpful imo. even if it's just re-hashed info
4272017-08-24T19:11:10  <luke-jr> not long ago, the blockchain was 100 GB. now it's 150 GB. and every month 10 GB more with 2 MB blocks :/
4282017-08-24T19:11:14  <kanzure> we can also copy-paste old segwit faq details anyway
4292017-08-24T19:11:17  <kanzure> (or link to them)
4302017-08-24T19:11:20  <sipa> luke-jr: prune
4312017-08-24T19:11:27  <luke-jr> sipa: that doesn't eliminate IBD
4322017-08-24T19:11:29  <wumpus> 'take the option away and the problem goes away' is a bit too simplistic at this point
4332017-08-24T19:11:33  <BlueMatt> wumpus: 11100 now removes it but keeps it somewhat compaible in spirit with what most miners appear to still have in their config files...
4342017-08-24T19:11:43  <BlueMatt> ehh, deprecates it
4352017-08-24T19:11:51  <BlueMatt> and clearly states blockmaxsize is deprecated
4362017-08-24T19:12:00  <BlueMatt> which roughly aligns with the expectation of everyone i spoke to
4372017-08-24T19:12:06  <luke-jr> 11100 is stupid.
4382017-08-24T19:12:13  <BlueMatt> there was confusion as to why blockmaxsize still existed in the context of segwit
4392017-08-24T19:12:16  <meshcollider> deprecating makes sense to me
4402017-08-24T19:12:30  <morcos> even i have trouble keeping up with what the interaction of these different options is
4412017-08-24T19:12:41  <kanzure> needs an interaction matrix visualization
4422017-08-24T19:12:52  *** chjj has joined #bitcoin-core-dev
4432017-08-24T19:12:52  <kanzure> where the cells indicate interaction :-)
4442017-08-24T19:12:53  <morcos> we need to move towards getting rid of blockmaxsize, its confusion for no benefit....
4452017-08-24T19:12:55  <achow101> is blockmaxsize taken into consideration with segwit or just ignored?
4462017-08-24T19:13:01  <sipa> achow101: it is!
4472017-08-24T19:13:04  <wumpus> deprecation is likely a good idea on the longer run, but not a fix to the misunderstanding created
4482017-08-24T19:13:05  <instagibbs> taken into account
4492017-08-24T19:13:15  <gmaxwell> achow101: it does something stupid, it truncates block construction when you reach that size.
4502017-08-24T19:13:19  <achow101> bleh :/
4512017-08-24T19:13:33  <luke-jr> it does what it's supposed to do
4522017-08-24T19:13:48  <gmaxwell> it originally went away and luke threw a fit.  With segwit not active it made sense as a legacy support thing but it's active now.
4532017-08-24T19:13:57  <morcos> wait a second
4542017-08-24T19:13:57  *** jimpo has quit IRC
4552017-08-24T19:13:59  <BlueMatt> wumpus: I disagree here, I was explicitly asked why it was not deprecated, because the consensus limit is around weight, so thats what people expect to be setting
4562017-08-24T19:14:07  <luke-jr> gmaxwell: you're rewriting history now
4572017-08-24T19:14:12  <BlueMatt> deprecation is, itself, documentation
4582017-08-24T19:14:17  <wumpus> BlueMatt: but we're already in the screwed state that those options exist
4592017-08-24T19:14:19  <morcos> i might be wrong (b/c the interaction is complicated) but isn't it just flat out wrong to say the default is 750K
4602017-08-24T19:14:32  <morcos> isn't the default infinity?
4612017-08-24T19:14:44  <sdaftuar> morcos: no, i don't think so.
4622017-08-24T19:14:45  <sipa> morcos: i honestly don't know anymore
4632017-08-24T19:14:49  <achow101> morcos: how so?
4642017-08-24T19:14:50  <morcos> if you don't set blockmaxsize it doesn't even calculate it
4652017-08-24T19:15:05  <gmaxwell> morcos: the default is 1/4 the configured weight which defaults to 3m.
4662017-08-24T19:15:06  <sdaftuar> if you set nothing, you get a 750k default, i believe.  and a 3M weight max.
4672017-08-24T19:15:07  <wumpus> I'm fine with marking it as deprecated anyhow
4682017-08-24T19:15:09  <morcos> ok well we'll get to the bottom of it in a second, but look how ridiculous it is that we don't know
4692017-08-24T19:15:18  <sdaftuar> if you set just blockmaxweight, then blockmaxsize is effectively infinity, i think.
4702017-08-24T19:15:26  <bitcoin-git> [bitcoin] romanornr opened pull request #11127: Make Bitcoin Core compatible with NYA segwit2x (master...s2x) https://github.com/bitcoin/bitcoin/pull/11127
4712017-08-24T19:15:29  <gmaxwell> sdaftuar: right.
4722017-08-24T19:15:35  <sipa> if you set only one of them, the other is taken as infinity
4732017-08-24T19:15:41  <gmaxwell> oh jesus.
4742017-08-24T19:15:43  <sipa> if you set both, both are enforced independently
4752017-08-24T19:15:43  <sdaftuar> but blockmaxsize is absurd, it should be removed.
4762017-08-24T19:15:48  <morcos> sdaftuar: you think if you set no options you can not produce a segwit-tx containing block bigger than 750k?
4772017-08-24T19:15:52  <morcos> that doesn't seem right to me
4782017-08-24T19:16:03  <sipa> morcos: i believe that is correct
4792017-08-24T19:16:08  <instagibbs> morcos, pretty sure that's correct
4802017-08-24T19:16:09  <sdaftuar> correct, you are capped at 750kb
4812017-08-24T19:16:09  <gmaxwell> That is correct.
4822017-08-24T19:16:18  <meshcollider> if you set blockmaxsize then blockmaxweight becomes blockmaxsize * WITNESS_SCALE_FACTOR doesn't it?
4832017-08-24T19:16:19  <bitcoin-git> [bitcoin] romanornr closed pull request #11127: Make Bitcoin Core compatible with NYA segwit2x (master...s2x) https://github.com/bitcoin/bitcoin/pull/11127
4842017-08-24T19:16:20  <instagibbs> all miners have cranked up to 1MB
4852017-08-24T19:16:20  <morcos> ugh, we should never have released it in this state
4862017-08-24T19:16:41  <sdaftuar> +1
4872017-08-24T19:16:53  <sipa> yes
4882017-08-24T19:17:03  <wumpus> but we're there anyhow, what now?
4892017-08-24T19:17:14  <gmaxwell> instagibbs: which now means a cranking down to 1MB. :(
4902017-08-24T19:17:27  <sdaftuar> wumpus: we should remove it and deprecate the command line option
4912017-08-24T19:17:28  <bitcoin-git> [bitcoin] hovah opened pull request #11128: Make Bitcoin Core compatible with NYA segwit2x (master...s2x) https://github.com/bitcoin/bitcoin/pull/11128
4922017-08-24T19:17:37  <sdaftuar> as we indicated we may do in the future in the 0.13 release notes, iirc
4932017-08-24T19:17:41  <morcos> Announcement that you should set only blockmaxweight and you should set it to 4,000,000.  Plus change code to ignore blockmaxsize unless specifically set, and deprecate it.
4942017-08-24T19:17:44  <gmaxwell> Well we should remove the silly option. The maximum size is not really correlated with anything that is interesting to be set anymore.
4952017-08-24T19:17:47  <luke-jr> miners producing blocks larger than 750k (or 1 MB at most) is malicious toward the network, and advising they do so or deprecating the blockmaxsize option needed to control this, it what is absurd.
4962017-08-24T19:17:47  *** abpa has joined #bitcoin-core-dev
4972017-08-24T19:17:50  <luke-jr> morcos: absolutely not
4982017-08-24T19:18:02  <jtimon> BlueMatt: ack on removing blockmaxsize and leaving only maxblockweight
4992017-08-24T19:18:02  <gmaxwell> Luke is faulty.
5002017-08-24T19:18:14  <wumpus> luke-jr: so they can still choose to do that with that option removed, right?
5012017-08-24T19:18:25  <wumpus> luke-jr: e.g. by setting the blockmaxweight lower?
5022017-08-24T19:18:33  <sdaftuar> or by using the gbt results and truncating themselves
5032017-08-24T19:18:35  <BlueMatt> anyway, so it sounds like #11100
5042017-08-24T19:18:38  <wumpus> that doesn't need two options
5052017-08-24T19:18:39  <luke-jr> wumpus: not effectively
5062017-08-24T19:18:48  <sdaftuar> luke-jr: why not?
5072017-08-24T19:18:55  <morcos> In general it is good that we have a culture of arguing things to death here, sometimes useful things result.  But in this case, we've been over this, we've heard Luke's arguments, and last time we gave in to end the argument
5082017-08-24T19:18:56  <sipa> luke-jr: the assumption behind segwit is that size doesn't matter nearly as much as a new metric, weight
5092017-08-24T19:18:56  <wumpus> the complication here is having two options that interact in a complicated way
5102017-08-24T19:19:01  <BlueMatt> luke-jr: you're the one who always advocates for policy at the other end of gbt, or isnt that the design of gbt?
5112017-08-24T19:19:03  <wumpus> please don't confuse it with what the value should be
5122017-08-24T19:19:09  <praxeology1> I don't think you should depricate the maxblocksize option.  If anything, if you want the software to enforce a legacy block size of 1MB, then hard code the limit...  and remove the maxblocksize setting from the configuration.
5132017-08-24T19:19:12  <sipa> luke-jr: i'm sorry to hear you disagree about that point, but that ship has sailed
5142017-08-24T19:19:13  <luke-jr> the only way to limit size to 750k with blockmaxweight is =750000, which will make 250k blocks unless 100% of tx are segwit
5152017-08-24T19:19:18  <morcos> Unless someone else agrees with Luke, I htink its just time to say unfortunately we're proceeding against his objections on this issue
5162017-08-24T19:19:29  <jnewbery> Concept ACK 11100
5172017-08-24T19:19:37  <gmaxwell> praxeology1: oh jesus christ you're also confused
5182017-08-24T19:19:58  <wumpus> yes, that sounds confused
5192017-08-24T19:19:58  <luke-jr> sipa: that ship has not sailed. that's not an argument.
5202017-08-24T19:20:13  <gmaxwell> praxeology1: THERE IS NO "LEGACY BLOCK SIZE" LIMIT ANYMORE!  Compatibility with old nodes achieved implicitly through how weight is constructed.
5212017-08-24T19:20:25  <BlueMatt> praxeology1: these options only effect the type of blocks miners mine, and are currently a maze of confusing
5222017-08-24T19:20:38  <sipa> luke-jr: segwit is active, regardless of your preferences, you should assume that rational actors will produce what the rules allow them to
5232017-08-24T19:20:44  <achow101> the parameter interaction is defined here: https://github.com/bitcoin/bitcoin/blob/master/src/miner.cpp#L81 for reference
5242017-08-24T19:20:49  <luke-jr> sipa: then Bitcoin is dead.
5252017-08-24T19:20:56  <BlueMatt> praxeology1: whats worse, the current options default to pissing away a significant amount of profit (so are always being overridden in practice, which has resulted in much confusion)
5262017-08-24T19:21:00  <jnewbery> what, dead again?!
5272017-08-24T19:21:03  <sipa> luke-jr: then Bitcoin is evolving to actually be tested
5282017-08-24T19:21:03  <gmaxwell> luke-jr: you've failed to address any of the points which I raised against your last rant on this on github.
5292017-08-24T19:21:24  <praxeology1> OK... so if there is no legacy limit anymore... then why would there be a configuration option for it? :o  Are you saying post segwit activation, it has no effect now?
5302017-08-24T19:21:25  <kanzure> does 11100 completely encompass the proposed changes
5312017-08-24T19:21:38  <BlueMatt> kanzure: I believe so
5322017-08-24T19:21:38  <sipa> luke-jr: i'm only interested in a Bitcoin that survives under the assumption that miners act rationally
5332017-08-24T19:21:47  <achow101> praxeology1: it has an effect, kind of. it really shouldn't though
5342017-08-24T19:21:55  <sipa> luke-jr: and you should too
5352017-08-24T19:22:02  <luke-jr> gmaxwell: your "points" depend on assertions that have no evidence at this time, which you are trying to CAUSE to be true
5362017-08-24T19:22:06  <gmaxwell> luke-jr: in particular expecting people to throw money on the floor to protect interests like keeping IBD times slightly lower is a failed expectation. (which we knew would fail, which is also why many of us don't support those reckless blocksize uncapping proposals)
5372017-08-24T19:22:20  <wumpus> if you think a defaults change kills bitcoin, you're severly underestimating it
5382017-08-24T19:22:22  <luke-jr> sipa: incentives are too broken for that to be possible right now
5392017-08-24T19:22:30  <sipa> luke-jr: how so?
5402017-08-24T19:22:30  <luke-jr> sipa: unless "rationally" includes altruism
5412017-08-24T19:22:34  <instagibbs> I motion to move onto a new discussion unless there's some new information to be shared
5422017-08-24T19:22:40  <sdaftuar> seconded
5432017-08-24T19:22:43  <wumpus> people are already overriding it on large scale, no one is using that stupid default
5442017-08-24T19:22:44  <sipa> seconded
5452017-08-24T19:22:48  <BlueMatt> ok, other topics?
5462017-08-24T19:22:57  <wumpus> #topic 0.15.0 release
5472017-08-24T19:22:59  <luke-jr> wumpus: overriding it to 1 MB, not 4 MB
5482017-08-24T19:23:00  <BlueMatt> second round of congrats on segwit?
5492017-08-24T19:23:01  <morcos> i'm against moving on unless we have agreed to get rid of the option and make an announcement
5502017-08-24T19:23:13  <kanzure> i could see luke-jr maybe working on the calculation there and showing numbers at some point. but probably not this moment. in the mean time i think 11100 review status should be checked?
5512017-08-24T19:23:13  <BlueMatt> morcos: I think we did
5522017-08-24T19:23:15  <morcos> we can't constantly do the wrong thing because luke is willing to argue longer than the rest of us
5532017-08-24T19:23:19  <morcos> at some point we must overrrule
5542017-08-24T19:23:36  <morcos> with 3 r's
5552017-08-24T19:23:37  <luke-jr> morcos: you're the one who wants to do the wrong thing
5562017-08-24T19:23:39  <praxeology1> BlueMatt: Congratulations! wahoo!!!! :) :) :) :)
5572017-08-24T19:23:44  <BlueMatt> morcos: go ack 11100, I dont think there was any concept objection
5582017-08-24T19:23:50  <sdaftuar> luke-jr: he is not "the one" who wants to do what he is suggesting
5592017-08-24T19:23:53  <sdaftuar> he is one of many
5602017-08-24T19:23:53  <gmaxwell> morcos: a point of order, I prefer we don't force 'final' decisions to be made in the meetings due to attendance complications. I think what you suggest it clearly the general thrust of where things are going, however.
5612017-08-24T19:24:08  <BlueMatt> okkkkkk, so 0.15.0
5622017-08-24T19:24:14  <instagibbs> reviewing the PR is the action item
5632017-08-24T19:24:26  <gmaxwell> s/it/is/
5642017-08-24T19:24:27  <wumpus> this is getting really unruly
5652017-08-24T19:24:37  <BlueMatt> dooglus finally got some backtraces on #9683, which I think needs to be investigated for 0.15
5662017-08-24T19:24:41  <wumpus> I'm going to end this meeting if this continues
5672017-08-24T19:24:42  <BlueMatt> also #11126
5682017-08-24T19:25:12  <wumpus> any reports of new regressions with rc2?
5692017-08-24T19:26:07  <achow101> probably not
5702017-08-24T19:26:08  <wumpus> to be honest dooglus has been having issues no one else is having, for a long time, we should assist him but I'm not sure we should hold up a release for it
5712017-08-24T19:26:28  <BlueMatt> wumpus: well are we gonna release today? I'll take a look at his issues this afternoon :)
5722017-08-24T19:26:32  <BlueMatt> i mean I'm not saying hold it up
5732017-08-24T19:26:39  <meshcollider> only issue I've heard with rc2 has been fanquakes gitian issue :)
5742017-08-24T19:26:40  <BlueMatt> just make sure its not an obvious "oh, thats broken" kind of thing
5752017-08-24T19:26:43  <wumpus> 11126 is an issue that only affects DEBUG_LOCKORDER in ithe initialization; nothing else is running at that moment
5762017-08-24T19:26:47  <wumpus> so it doesn't cause any real issue
5772017-08-24T19:26:57  <BlueMatt> ah, ok, i hadnt investigated it significantly
5782017-08-24T19:27:04  <cfields> i've had a few crashes lately that i mentioned here i think. I've finally been able to track them down to local changes. So, no concern for 0.15.
5792017-08-24T19:27:26  <BlueMatt> hmmmm, looks like dooglus' qt crash is the same one I couldnt debug
5802017-08-24T19:27:38  <BlueMatt> i wonder if he's also running qt over X forwarding
5812017-08-24T19:27:43  <BlueMatt> that appears to make it more likely
5822017-08-24T19:27:57  <jonasschnelli> Seems like a free/alloc race in the table weak loading
5832017-08-24T19:28:10  <BlueMatt> it doesnt appear to be harmful, at least, some race in setting the table sort order or something like that
5842017-08-24T19:28:20  <jonasschnelli> Could also be a Qt bug
5852017-08-24T19:28:25  <BlueMatt> indeed, could be
5862017-08-24T19:28:36  <BlueMatt> mine was 9883
5872017-08-24T19:29:22  <jonasschnelli> They are related
5882017-08-24T19:29:46  <jonasschnelli> setSortingEnabled()
5892017-08-24T19:29:52  <jonasschnelli> I'll investigate
5902017-08-24T19:29:56  <BlueMatt> thanks
5912017-08-24T19:29:58  <jtimon> the deault of one is a function of what you set in another? that interaction should definitely go away asap, ideally to me by removing the size one, I don't care the weight default is 2000000 or whatever
5922017-08-24T19:30:04  <jonasschnelli> If its racy,.. could be due to a large wallet
5932017-08-24T19:30:10  <jonasschnelli> (many txns)
5942017-08-24T19:30:13  <wumpus> #9883 crashed in the leveldb iter?!
5952017-08-24T19:30:29  <BlueMatt> the wallet I saw that on is not so large...maybe 1k txn?
5962017-08-24T19:30:46  <wumpus> oh wait, wrong thread, that was just going on at the time
5972017-08-24T19:30:52  <jonasschnelli> wumpus: not that I know...  I think it crashes via setSortingEnabled
5982017-08-24T19:31:04  <jonasschnelli> QTableView::setSortingEnabled(bool) -> QCollator::QCollator(QLocale const&
5992017-08-24T19:31:11  <BlueMatt> dooglus also has some crashes where quick-exit races openssl mutex unlocking....I assume that is an openssl bug or so
6002017-08-24T19:31:22  *** bitstein has joined #bitcoin-core-dev
6012017-08-24T19:31:27  <BlueMatt> its the old mutex-locked-during-destruction crash, though, so not harmful
6022017-08-24T19:31:30  <wumpus> jonasschnelli: yes, I see now, that's a more recognizable trace
6032017-08-24T19:31:31  <BlueMatt> just a scary warning
6042017-08-24T19:32:04  <wumpus> is something outside the GUI thread calling Qt functions perhaps?
6052017-08-24T19:32:10  <jonasschnelli> BlueMatt: your 9883, self compiled Qt? What version?
6062017-08-24T19:32:20  <BlueMatt> yes...uhhh, sec
6072017-08-24T19:32:28  <BlueMatt> wumpus: that was my assumption
6082017-08-24T19:32:31  <wumpus> if so, that can explain the crashes with remote X, as well as this
6092017-08-24T19:32:39  <BlueMatt> jonasa: qt5 something
6102017-08-24T19:32:57  <wumpus> *only* the GUI thread may call Qt GUI functions, the rest should queue signals on the GUI thread
6112017-08-24T19:33:22  <wumpus> I haven't seen any violation of that, though
6122017-08-24T19:33:27  *** promag has quit IRC
6132017-08-24T19:33:29  *** jimmysong__ is now known as jimmysong
6142017-08-24T19:33:38  <jonasschnelli> wumpus: Yeah. But that would very likely show another thread calling a relevant Qt function during the crash
6152017-08-24T19:33:39  <jonasschnelli> (which it doesn't)
6162017-08-24T19:35:14  *** ekerstein has joined #bitcoin-core-dev
6172017-08-24T19:35:27  <wumpus> PSA regarding 0.15.0 final - I will not be able to tag releases while in the US, and I'm leaving wednesday night 30th, and return to NL the 12th
6182017-08-24T19:35:32  <BlueMatt> anyway, it appears to be an only-at-startup thing and afaict, at least for me is a very reliable either-crashes-or-works-fine thing, so I'm still not too worried
6192017-08-24T19:35:57  <wumpus> jonasschnelli: you'd say so, but not necessarily, it could just mess up some internal table state, or even internal X state
6202017-08-24T19:35:58  <BlueMatt> (hence the closure of the original bug, may be a qt bug)
6212017-08-24T19:35:58  <achow101> wumpus: so, final this week?
6222017-08-24T19:36:08  <jonasschnelli> wumpus: Yes. Possible.
6232017-08-24T19:36:26  <wumpus> achow101: yes, or second half of september
6242017-08-24T19:37:35  <gmaxwell> I would rather have 0.15 out sooner rather than later. so far I haven't seen any clear blockers.
6252017-08-24T19:37:41  <wumpus> and I guess we should work on 0.15.1 during coredev
6262017-08-24T19:37:46  <BlueMatt> gmaxwell: agreed
6272017-08-24T19:37:50  <jonasschnelli> wumpus: Yes. Ideally.
6282017-08-24T19:37:53  <wumpus> segwit wallet support etc
6292017-08-24T19:37:57  <jonasschnelli> Yes
6302017-08-24T19:38:09  <luke-jr> wumpus: maybe tag locally, and delay pushing?
6312017-08-24T19:38:33  <wumpus> luke-jr: well it's more complicated, I could possibly push the tag, but I can't upload executables
6322017-08-24T19:38:49  <luke-jr> wumpus: there are others who can, right?
6332017-08-24T19:38:58  *** promag has joined #bitcoin-core-dev
6342017-08-24T19:39:02  <jonasschnelli> I think wumpus should do it.
6352017-08-24T19:39:09  <wumpus> yes, but they'll have to us their own release signing key
6362017-08-24T19:39:12  <jonasschnelli> It's just 12 days (max +/-)
6372017-08-24T19:39:24  <BlueMatt> luke-jr: no (I mean theoretically we can *give* others access, but I see no reason to do so at this time)
6382017-08-24T19:39:27  <achow101> I think we should sign with a differnt release key and see if anyone notices :)
6392017-08-24T19:39:32  <meshcollider> yeah wumpus should do it, its not that time critical
6402017-08-24T19:39:45  <jonasschnelli> achow101: they will...
6412017-08-24T19:39:45  * luke-jr shrugs
6422017-08-24T19:39:46  <wumpus> oh people notice, my mail was full after stupping using my personal key for that
6432017-08-24T19:40:04  <wumpus> even though it was announced on the mailing lists etc
6442017-08-24T19:40:47  <wumpus> anyhow... let's release 0.15.0 soon if possible
6452017-08-24T19:40:57  <wumpus> if there's still something you'd like to debug over the weekend I can wait until after that
6462017-08-24T19:40:59  <BlueMatt> anyway, so I have no objections to tagging 0.15 this weekend/tomorrow if no other issues come up in that time
6472017-08-24T19:41:14  *** promag has quit IRC
6482017-08-24T19:41:25  <wumpus> but hearing that cfields's concerns were with local code puts me at ease a bit about 0.15.0 at least :)
6492017-08-24T19:41:26  <luke-jr> the lock issue can probably be ignored, I guess?
6502017-08-24T19:41:43  <wumpus> luke-jr: not ignored, just fixed on master and next 0.15 branch release
6512017-08-24T19:41:53  <luke-jr> sure, that's what I mean. ignored for 0.15.0
6522017-08-24T19:42:06  <luke-jr> would be nice to get a test that reproduces it, but I'm not sure how
6532017-08-24T19:42:08  <wumpus> well as I understand it there are no threads in flight yet at that point
6542017-08-24T19:42:18  <gmaxwell> we understand it, it shouldn't block the release. (it's in init)
6552017-08-24T19:42:27  <cfields> wumpus: if that puts you at ease, i should invent some local problems and solve them more often :)
6562017-08-24T19:42:48  <meshcollider> 😂
6572017-08-24T19:42:49  <BlueMatt> lol
6582017-08-24T19:42:50  <wumpus> cfields: haha!
6592017-08-24T19:43:08  <wumpus> can cfields create an issue even cfields cannot debug
6602017-08-24T19:43:25  <cfields> haha
6612017-08-24T19:43:36  <wumpus> ok, any other topics?
6622017-08-24T19:43:45  <BlueMatt> Segwit is active!
6632017-08-24T19:43:59  <sipa> what? how?!
6642017-08-24T19:44:01  <wumpus> yeah! we can remove the point 'activate segwit' from the weekly agenda
6652017-08-24T19:44:10  <BlueMatt> heh
6662017-08-24T19:44:12  <kanzure> i have a topic. it can wait.
6672017-08-24T19:44:18  <luke-jr> what is it waiting for?
6682017-08-24T19:44:25  <wumpus> ther's only 15 minutes left so don't wait too long
6692017-08-24T19:44:36  <kanzure> i am collecting topic ideas for coredev.tech meetup. either pm me with things you want to see or in here.
6702017-08-24T19:44:45  <kanzure> and i will publish small document somewhere
6712017-08-24T19:44:51  <wumpus> segwit wallet support
6722017-08-24T19:44:53  <kanzure> it's not a schedule. just a braindump sorta.
6732017-08-24T19:44:55  <kanzure> oh.
6742017-08-24T19:44:58  <kanzure> okay added
6752017-08-24T19:45:53  <wumpus> (which is very general, probably should be divided up...)
6762017-08-24T19:46:23  <jonasschnelli> kanzure: thanks for collecting stuff for the CoreDev.tech in SF!
6772017-08-24T19:46:40  <kanzure> sure
6782017-08-24T19:46:52  <jnewbery> wumpus: I'd like #11053 to be reopened / reconsidered
6792017-08-24T19:47:02  <wumpus> GUI support, bech32 yes/no for this release, etc
6802017-08-24T19:47:11  <jnewbery> refactor: Make all #includes relative to project root
6812017-08-24T19:48:00  <cfields> jnewbery: +1. I think my concerns there were mistaken for a NACK. I pretty much regret bringing them up.
6822017-08-24T19:48:11  <luke-jr> wumpus: eh, at least sending bech32 seems a necessity
6832017-08-24T19:48:41  <wumpus> cfields: no, not really, it just made me reconsider whether it's really a good idea
6842017-08-24T19:48:52  <wumpus> cfields: ideally we'd clear out src and move everything to subdirs
6852017-08-24T19:49:02  <cfields> wumpus: agree with that.
6862017-08-24T19:49:15  <wumpus> cfields: on the other hand this doesn't make things worse at least
6872017-08-24T19:49:32  <wumpus> cfields: #include "" is severly misused in our source code
6882017-08-24T19:49:48  <bitcoin-git> [bitcoin] sipa closed pull request #11128: Make Bitcoin Core compatible with NYA segwit2x (master...s2x) https://github.com/bitcoin/bitcoin/pull/11128
6892017-08-24T19:50:17  <wumpus> if used it should be used to include relative to the directory of the source file, but it's used as a kind of wildcard include
6902017-08-24T19:50:35  <wumpus> *find it somewhere!*
6912017-08-24T19:51:48  <bitcoin-git> [bitcoin] laanwj reopened pull request #11053: refactor: Make all #includes relative to project root (master...2017_08_includes_absolute) https://github.com/bitcoin/bitcoin/pull/11053
6922017-08-24T19:51:54  <gmaxwell> 12:44:01 < wumpus> yeah! we can remove the point 'activate segwit' from the weekly agenda
6932017-08-24T19:52:03  <wumpus> anyhow reopening the pull, it wasn't my intent to stop discussion on it, just to make it clear there's no urgency in mergin a certain solution
6942017-08-24T19:52:09  <gmaxwell> we should also go dig up the wallet improvements we couldn't make without segwit... and start working on them. :)
6952017-08-24T19:52:13  <instagibbs> wumpus, oh thought you just implemented those changes just now, haha
6962017-08-24T19:52:15  <jnewbery> thanks wumpus
6972017-08-24T19:52:20  <gmaxwell> (perhaps see the log of the meeting where we added that item)
6982017-08-24T19:52:24  <cfields> wumpus: agreed, i just don't see a ton of benefit in changing something that works
6992017-08-24T19:52:38  *** Bluewolf33 has quit IRC
7002017-08-24T19:52:44  <cfields> however, if benches show that it's noticibly faster, i'm all for it :)
7012017-08-24T19:53:13  <wumpus> cfields: well the current state prevents having files with the same name in multiple places in the tree sanely
7022017-08-24T19:53:14  <sipa> cfields: eh, what are you talking about?
7032017-08-24T19:53:40  <gmaxwell> how are include paths going to change the speed of anything?
7042017-08-24T19:53:44  <wumpus> cfields: that's what kind of triggered this, we can't have wallet/init.h and init.h right now because #include "" as we use it now gets confused
7052017-08-24T19:53:53  <wumpus> gmaxwell: it can reduce the amount of probing the compiler has to do
7062017-08-24T19:54:07  <meshcollider> (compile speed not runtime speed)
7072017-08-24T19:54:12  <cfields> wumpus made that point ^^ in the PR, i believe
7082017-08-24T19:54:23  <gmaxwell> okay, I'll look at the PR then.
7092017-08-24T19:54:26  <wumpus> gmaxwell: e.g. including "primitives/primitives.h" in "primitvies/transaction.h" makes it look in primitives/primitives/transaction.h
7102017-08-24T19:54:42  <wumpus> gmaxwell: which can affect compile speed in some setups
7112017-08-24T19:54:49  <wumpus> gmaxwell: it's not the primary reason for making the change, though
7122017-08-24T19:55:52  <BlueMatt> ok, other topics?
7132017-08-24T19:56:00  <cfields> anyway, i'm happy to see it reopened
7142017-08-24T19:56:12  <luke-jr> how about meeting plans?
7152017-08-24T19:56:19  <luke-jr> or should we just discuss that in the dedicated channel later?
7162017-08-24T19:56:28  <sipa> yes
7172017-08-24T19:56:30  <wumpus> I thin kthe best reason for it is that it makes it immediately clear where to look for a file to developers
7182017-08-24T19:56:39  <luke-jr> (specifically, are people sticking around Friday, or leaving as soon as it's over?)
7192017-08-24T19:56:53  <BlueMatt> luke-jr: dedicated channel, i think
7202017-08-24T19:56:57  *** telberrak has joined #bitcoin-core-dev
7212017-08-24T19:57:10  <wumpus> instead of eh, it's included with "", is it in the current dir? no? oh maybe it's under src/ directly
7222017-08-24T19:57:38  <meshcollider> which channel is that?
7232017-08-24T19:57:59  *** jimpo has joined #bitcoin-core-dev
7242017-08-24T19:58:05  <kanzure> #bitcoin-core-dev
7252017-08-24T19:58:25  <jonasschnelli> ##
7262017-08-24T19:58:29  *** telberrak has quit IRC
7272017-08-24T19:58:58  <kanzure> i didn't say what you thought i said
7282017-08-24T19:59:27  *** Dizzle has joined #bitcoin-core-dev
7292017-08-24T19:59:29  <kanzure> luke-jr: anyway there's enough people local to the area that you'll find friendlies even if the visitors leave.
7302017-08-24T19:59:29  <meshcollider> I guess there's some sort of filtering happening yae
7312017-08-24T20:00:08  <wumpus> and that concludes the meeting, thanks everyone
7322017-08-24T20:00:11  <wumpus> #endmeeting
7332017-08-24T20:00:11  <lightningbot> Meeting ended Thu Aug 24 20:00:11 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
7342017-08-24T20:00:11  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-08-24-19.01.html
7352017-08-24T20:00:11  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-08-24-19.01.txt
7362017-08-24T20:00:11  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-08-24-19.01.log.html
7372017-08-24T20:00:32  <wumpus> we can back to shouting at each other about default values now :)
7382017-08-24T20:01:33  <morcos> well re: the shouting, i think there is time to argue on github about the changes for next release
7392017-08-24T20:01:47  <morcos> what i'm more interested in is letting miners know what they need to do
7402017-08-24T20:01:59  * BlueMatt thinks we should just merge all currently open prs for 0.15 and see what happens
7412017-08-24T20:02:11  <kanzure> chaos branch?
7422017-08-24T20:02:19  <gmaxwell> luke-jr: I'm concerned that you seem to be fixated on size rather than on the greater goal of keeping bitcoin decenteralized, secure, usable. Size is increasingly not an interesting magic metric for that, moreover, single miners reducing their size does nothing to help here-- if it did there would be much less reason for a blocksize limit.
7432017-08-24T20:02:39  <cfields> morcos: let's forego some of the arguments and s/what they need to do/what their options are/ :)
7442017-08-24T20:03:01  <morcos> well i think the only option that has a legitimate chance of getting approved is something that says
7452017-08-24T20:03:36  <kanzure> gmaxwell: luke was arguing that his reasoning is directly related to IBD. perhaps IBD growth should be capped some other way in a more explicit way.
7462017-08-24T20:03:38  <morcos> If you want to just produce the blocks with the most fee that you can without limiting anyting about them more than required by consenus then you should do X
7472017-08-24T20:03:58  <cfields> morcos: yes, exactly.
7482017-08-24T20:04:05  <wumpus> BlueMatt: luckily that's never going to work, most PRs conflict with a few other PRs :)
7492017-08-24T20:04:22  <luke-jr> gmaxwell: there's only so much improvement that is possible. supposedly that's 17% per year, which gives us only room for 300-450k blocks. I don't think we have a magic leap to fix that..
7502017-08-24T20:04:34  <BlueMatt> wumpus: merge at random until the only remaining ones conflict, then resolve conflicts at random until it compiles :p
7512017-08-24T20:05:09  <kanzure> (would an IBD limiting value  get to safely ignore signatures for the same reason that a signature validation skip mechanism was implemented for firstpass?)
7522017-08-24T20:05:19  <gmaxwell> kanzure: the only thing that can save IBD is something like a utxo sync; any plausable blocksize results in a growth rate well in excess of computers/links getting faster, so its only a question of when things fail not if, absent. it.
7532017-08-24T20:05:34  <wumpus> BlueMatt: it would be kind of nice if github had a way of showing what PRs don't conflict, or *shudders* what the biggest subset of PRs would be that could be merged without conflicting
7542017-08-24T20:05:35  <kanzure> well that's an interesting argument.
7552017-08-24T20:05:38  <gmaxwell> luke-jr: we do, stop syncing the whole history, and only sync the last year worth or whatever.
7562017-08-24T20:05:58  <morcos> luke-jr: do you have an opinion on Core making such a statement via tweet or blog post or both?  where X is set maxblockweight=4000000 and don't set maxblocksize
7572017-08-24T20:06:06  <luke-jr> gmaxwell: UTXO sync is a change to the security model, and you were just going after praxeology1 for wanting to work on it earlier unless I totally misunderstood that?
7582017-08-24T20:06:14  <kanzure> gmaxwell: ok then what about argument about limiting IBD until utxo commitment sync stuff
7592017-08-24T20:06:16  <gmaxwell> luke-jr: and as I mentioned in the meeting for many (perhaps most) IO costs in maintaining the chainstate dominate sync time, so witness size increases don't matterh much.
7602017-08-24T20:06:26  <luke-jr> morcos: yes, I think we shouldn't recommend things that harm Bitcoin.
7612017-08-24T20:06:31  *** blznblzn2 has quit IRC
7622017-08-24T20:06:38  <kanzure> well i think IBD concerns weren't about validation cost, mostly bandwidth over the interwebs
7632017-08-24T20:06:40  <morcos> i don't think my statement recommended anything
7642017-08-24T20:07:04  <kanzure> sorry, i mean, those specific IBD concerns
7652017-08-24T20:07:05  <gmaxwell> luke-jr: what is the security model of a bitcoin with no nodes?  But with the assumevalid approach I don't know that it's really a meaningful change in the security model.
7662017-08-24T20:07:08  <luke-jr> gmaxwell: we aren't only getting witness size increases with Segwit..
7672017-08-24T20:07:19  <morcos> i think it was just informing miners of how to do something that most of us (probably including you) guess that a lot of them want to do, without commenting on its "goodness"
7682017-08-24T20:07:32  <sipa> luke-jr: the worst case I/O effect of a block has not changed at all with SegWit
7692017-08-24T20:07:35  <cfields> luke-jr: if bitcoin is as fickle as a default setting, the value of that setting isn't the issue...
7702017-08-24T20:07:43  <luke-jr> morcos: that statement sounded like a recommendation. maybe a neutral blog post that explains how to get different policies configured would be fine
7712017-08-24T20:07:46  <sipa> luke-jr: the average just got closer to the worst case, which is a good thing
7722017-08-24T20:08:01  <gmaxwell> luke-jr: moreover the thing you're insisting on (maxsize) doesn't correlate with those IO costs well.
7732017-08-24T20:08:02  <bitcoin-git> [bitcoin] MarcoFalke pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/affe9271aa49...4ae6d0fbef60
7742017-08-24T20:08:03  <bitcoin-git> bitcoin/master b23549f John Newbery: [tests] add TestNodeCLI class for calling bitcoin-cli for a node
7752017-08-24T20:08:03  <bitcoin-git> bitcoin/master c6ec435 John Newbery: [tests] Add bitcoin_cli.py test script
7762017-08-24T20:08:04  <bitcoin-git> bitcoin/master 4ae6d0f MarcoFalke: Merge #10798: [tests] [utils] test bitcoin-cli...
7772017-08-24T20:08:17  <luke-jr> cfields: all the more reason we should make the default something advisable (or nothing at all)
7782017-08-24T20:08:18  <kanzure> surely it was bandwidth not IO concern?
7792017-08-24T20:08:27  <jtimon> luke-jr: if we delete the maxsize and set de default weight to 2MB, do you think many miners won't change it to 4MB ?
7802017-08-24T20:08:28  <gmaxwell> luke-jr: if you want to argue that maxsize=4m maxweight=3m .. at least that makes more sense (though I would disagree there too)
7812017-08-24T20:08:29  <morcos> luke-jr: at some point we have to consider what our customers (miners in this case) want.   i suppose we could just get jeff to tweet it, since they claim to be running his software anyway.
7822017-08-24T20:08:32  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #10798: [tests] [utils] test bitcoin-cli (master...cli_tests) https://github.com/bitcoin/bitcoin/pull/10798
7832017-08-24T20:08:33  <morcos> maybe i'll just do that
7842017-08-24T20:08:49  <gmaxwell> kanzure: read faster. For a lot of systems they are _not_ bandwidth limited in IBD.
7852017-08-24T20:09:02  <kanzure> but is that luke's concern?
7862017-08-24T20:09:05  <gmaxwell> kanzure: they're chainstate IO limited, etc.
7872017-08-24T20:09:08  *** Bluewolf33 has joined #bitcoin-core-dev
7882017-08-24T20:09:49  <luke-jr> morcos: they can configure the settings for what they want; it doesn't mean we need to suggest what those should be, if it's against what others might want
7892017-08-24T20:11:36  <gmaxwell> It's a fact that setting in any way other than 4m vs 4m will be leaving money on the floor, potentially quite a lot.
7902017-08-24T20:12:00  <luke-jr> morcos: I think documenting how to use the settings is good. I don't think suggesting settings harmful to the network, over more benevolent settings, is good.
7912017-08-24T20:12:11  <luke-jr> gmaxwell: only if other miners set that
7922017-08-24T20:12:20  <luke-jr> no miners right now AFAIK set 4/4
7932017-08-24T20:13:07  <gmaxwell> luke-jr: no, you'll still miss out on what you could have earned even if no one else sets it.
7942017-08-24T20:13:08  <morcos> ok in the meantime i'm just going to tweet it myself in the event that some miners don't know, i think many would like to know what to do
7952017-08-24T20:13:20  <gmaxwell> which is why expecting people to set it some other way is unrealistic and has simply failed in the past.
7962017-08-24T20:13:30  <luke-jr> gmaxwell: you have a probability to get it next block of yours
7972017-08-24T20:13:41  *** Guyver2 has quit IRC
7982017-08-24T20:14:09  <luke-jr> gmaxwell: do you disagree with #3229 ?
7992017-08-24T20:14:33  <luke-jr> (it was originally shot down by Hearn and Garzik)
8002017-08-24T20:15:18  <gmaxwell> I think it's phenominally dumb but better than the current behavior. (not really much of an endorsement)
8012017-08-24T20:15:34  *** Bluewolf33 has quit IRC
8022017-08-24T20:15:45  <luke-jr> sigh
8032017-08-24T20:17:02  <luke-jr> either miners are setting the config or not. if they are, then defaults don't matter, and we should either set what would be ideal, or require configuration. if they aren't, then the same conclusions make sense
8042017-08-24T20:17:41  <gmaxwell> I don't think these things should be configurable at all.
8052017-08-24T20:17:51  <gmaxwell> it's harmful to the network to have discrepencies.
8062017-08-24T20:18:11  <gmaxwell> Do we have a setting to set a maximum number of 1-bits in a seralized block. No.
8072017-08-24T20:18:26  <gmaxwell> Would we support such a setting if someone asked for one, ... almost certantly not.
8082017-08-24T20:18:44  <gmaxwell> discrepancies*
8092017-08-24T20:19:03  <sipa> if you want to less insane example; we also don't have a setting to control how many sigops in a block (which correlates much more strongly with actual cost to the network)
8102017-08-24T20:19:15  <gmaxwell> (I mean that for both weight and size, but especially size because it doesn't very map well to anything that matters and causes a lot of confusion)
8112017-08-24T20:19:19  <wumpus> we wouldn't add it, but if we had such an option since the beginning, then removing it would still be difficult
8122017-08-24T20:19:40  <luke-jr> size does matter though
8132017-08-24T20:20:00  <sipa> luke-jr: yes, a bit
8142017-08-24T20:20:03  <luke-jr> at the very least, there is the clear case of the blocksonly node
8152017-08-24T20:20:07  <sipa> so do many other things
8162017-08-24T20:20:42  <gmaxwell> it's easy to demonstrate that the size option is seriously confusing people; they think it's controls the "legacy block size" and that if they set it over 1mb their blocks will be invalid. :( so much disinformation spread by people like garzik means that people are primed to have a screwed up understanding, and it's not like it's especially clear even without being setup to fail.
8172017-08-24T20:20:56  <gmaxwell> luke-jr: what about the blocksonly node?
8182017-08-24T20:21:16  <luke-jr> gmaxwell: its bandwidth requirement is primarily affected by the block sizes
8192017-08-24T20:21:18  <gmaxwell> luke-jr: it matters a small bit yes, but other things matter a lot more.
8202017-08-24T20:21:54  <sipa> luke-jr: let's work on compressed blocks then
8212017-08-24T20:22:26  <gmaxwell> luke-jr: you can reduce its bandwidth requirement by almost 30%, in a way that isn't economically unstable and won't fail in a couple months,  by helping finish the compacted seralization.  But do you work on that? No.  You throw rocks here and emotionally exhaust people who are working on things like that.
8222017-08-24T20:22:36  <luke-jr> compressed blocks are going to make 100% year-over-year improvements? :/
8232017-08-24T20:23:10  <praxeology1> True or false... 0.14.2 nodes by default currently limit the weight to 4M?
8242017-08-24T20:23:26  <sipa> praxeology1: to 3M
8252017-08-24T20:23:33  <sipa> praxeology1: for mining, that is
8262017-08-24T20:23:41  <sipa> the consensus rules are obviously not configurable
8272017-08-24T20:23:43  <gmaxwell> luke-jr: expecting to trick miners with a default that works against their interests isn't going to meaningfully keep the size down, all it's going to do is amplify segwit 2x drama.
8282017-08-24T20:23:52  <luke-jr> gmaxwell: it's not a trick
8292017-08-24T20:24:02  <wumpus> tip: you can see the default for every option with bitcoind --help
8302017-08-24T20:24:09  <praxeology1> sipa: yea I am talking about consensus rules, not what miners create by default
8312017-08-24T20:24:50  <sipa> praxeology1: that's entirely offtopic
8322017-08-24T20:24:56  <sipa> and irrelevant here
8332017-08-24T20:25:01  <wumpus> praxeology1: huh, then you shouldn't ask 'by default'
8342017-08-24T20:25:24  <luke-jr> praxeology1: the consensus rule is max weight of 4M.
8352017-08-24T20:25:28  <gmaxwell> wumpus: elsewhere he's suffering the "but if miners set things higher they'll produce invalid blocks" confusion.
8362017-08-24T20:25:39  <wumpus> (unless you mean this in the extremely twisted sense of 'without source code changes'? )
8372017-08-24T20:25:51  <sipa> praxeology1: the weight, which is defined as 3*witsize + basesize must be less than 4M
8382017-08-24T20:26:03  <sipa> praxeology1: that implies that basesize must be less than 1M
8392017-08-24T20:26:22  <praxeology1> I'm trying to find out what you guys are talking about... it wasn't clear to me that "maxweight" configuration doesn't effect the consensus rule
8402017-08-24T20:26:35  <sipa> praxeology1: we're only talking about the mining code
8412017-08-24T20:26:39  <gmaxwell> sipa: don't use witsize as your variable. sounds like the size of the witnesses.
8422017-08-24T20:26:49  <sipa> -blockmaxsize and -blockmaxweight control the size of blocks the mining code produce
8432017-08-24T20:27:03  <sipa> but the mining code will never ever produce a consensus-invalid block, regardless of settings
8442017-08-24T20:27:05  <gmaxwell> praxeology1: consensus rules are not configurable because that would be extremely negligant, incompetent, and pointless.
8452017-08-24T20:27:21  <gmaxwell> negligent*
8462017-08-24T20:27:30  * luke-jr notes miners could set blockmaxsize=8000000 safely
8472017-08-24T20:27:41  <BlueMatt> eg https://eprint.iacr.org/2017/686.pdf (as to why making consensus limits configurable is an astoundingly stupid idea)
8482017-08-24T20:27:41  <morcos> sipa: i think you got your formula wrong there
8492017-08-24T20:27:49  <gmaxwell> or 16123123
8502017-08-24T20:27:57  <gmaxwell> morcos: by witsize he means the total size of the block.
8512017-08-24T20:28:04  <morcos> oh
8522017-08-24T20:28:15  <gmaxwell> he should have said 3*size + stripped size.
8532017-08-24T20:28:19  <sipa> sorry, by witsize i meant "size including witnesses"
8542017-08-24T20:28:22  <morcos> isn't that still wrong
8552017-08-24T20:28:31  <sipa> yes.
8562017-08-24T20:28:37  <luke-jr> (3 * stripped size) + size
8572017-08-24T20:28:42  <morcos> thanks luke
8582017-08-24T20:28:49  <gmaxwell> derp.
8592017-08-24T20:28:52  <gmaxwell> yea.
8602017-08-24T20:29:05  <morcos> i can't wait to read r/btc tonight
8612017-08-24T20:29:31  <luke-jr> I'm thinking of unsub'ing r/btc
8622017-08-24T20:29:54  <BlueMatt> lol, you're just *now* thinking of that?
8632017-08-24T20:30:09  <luke-jr> tbf, not just now. ;)
8642017-08-24T20:32:03  <clarkmoody> gmaxwell sipa Can you guys look at https://github.com/bitcoin/bips/pull/553 ?
8652017-08-24T20:32:52  <praxeology1> sipa: gmaxwell: ok, its clear to me know what you guys are talking about...  thanks.  Sorry for injecting myself into the conversation, now I see I don't even care about it (has nothing to do with consensus rules)
8662017-08-24T20:43:01  *** bitstein has quit IRC
8672017-08-24T20:43:59  *** shesek has joined #bitcoin-core-dev
8682017-08-24T20:49:32  <praxeology1> gmaxwell: given one was using rolling utxo hashes to verify the state of a utxo snapshot...  what kind of data structure would be used to store old snapshots for new nodes to synch from?
8692017-08-24T20:51:03  <praxeology1> maintaining such a data structure w/ no block height delay on the hash... sounds hard
8702017-08-24T20:54:02  <praxeology1> Make the heights one can synch from periodic instead of each block.  Store the spends in a new DB for that specific snapshot height.  remember the block height for new utxos in the current chainstate
8712017-08-24T20:57:31  <praxeology1> So then to reproduce the utxos at a given height... its the set of spent txs in that snapshot's DB, plus any utxo in the current chainstate from a block <= given height.
8722017-08-24T20:59:39  <sipa> praxeology1: our database already supports snapshotting
8732017-08-24T21:00:10  <sipa> so make a snapshot, then process that snaoshot in the background into a compact utxo representation, and continue with normal procoessing
8742017-08-24T21:00:15  <sipa> and yes, periodically
8752017-08-24T21:01:15  <praxeology1> sounds good to me
8762017-08-24T21:02:35  <praxeology1> then we just need some kind of standardization on how the "compact utxo representation" is hashed so that people can download from multiple sources piecewise
8772017-08-24T21:03:10  <sipa> yes
8782017-08-24T21:03:18  *** Chris_Stewart_5 has quit IRC
8792017-08-24T21:05:41  *** bitstein has joined #bitcoin-core-dev
8802017-08-24T21:06:04  <praxeology1> Hopefully also some automated process for people to generate these utxo hashes, and communicate them over insecure networks
8812017-08-24T21:06:55  <praxeology1> Or is there talk bout making it a commitment?
8822017-08-24T21:09:04  <praxeology1> *trying to get a feel for the core dev's current position on this... thinking it might be a touchy subject
8832017-08-24T21:09:17  <sipa> i think it's gettingna bit offtopic here
8842017-08-24T21:10:18  <praxeology1> Well, whether the rolling utxo hash was committed on, or was communicated outside of blocks... would have a big impact on... how it was communicated
8852017-08-24T21:11:01  *** Dyaheon has quit IRC
8862017-08-24T21:13:38  *** Dyaheon has joined #bitcoin-core-dev
8872017-08-24T21:13:47  <bitcoin-git> [bitcoin] MarcoFalke opened pull request #11129: [qa] util: Poll cookie file size before reading (master...Mf1708-qaPollCookie) https://github.com/bitcoin/bitcoin/pull/11129
8882017-08-24T21:13:56  *** abpa has quit IRC
8892017-08-24T21:14:00  <praxeology1> Where would it be on topic?
8902017-08-24T21:17:20  <sipa> mailing list
8912017-08-24T21:17:53  <sipa> or bitcoin-wizards
8922017-08-24T21:25:01  *** ekerstein has quit IRC
8932017-08-24T21:25:22  *** bitstein has quit IRC
8942017-08-24T21:34:34  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/4ae6d0fbef60...77fc469fc78c
8952017-08-24T21:34:34  <bitcoin-git> bitcoin/master cd0ea48 Matt Corallo: Changing -txindex requires -reindex, not -reindex-chainstate
8962017-08-24T21:34:35  <bitcoin-git> bitcoin/master 77fc469 MarcoFalke: Merge #11108: Changing -txindex requires -reindex, not -reindex-chainstate...
8972017-08-24T21:35:09  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #11108: Changing -txindex requires -reindex, not -reindex-chainstate (master...2017-08-fix-reindex-txindex-err) https://github.com/bitcoin/bitcoin/pull/11108
8982017-08-24T21:48:23  <bitcoin-git> [bitcoin] jtimon closed pull request #9271: There's two types of flags: consensus and script (master...0.13-consensus-flags-error) https://github.com/bitcoin/bitcoin/pull/9271
8992017-08-24T21:53:31  *** Bluewolf33 has joined #bitcoin-core-dev
9002017-08-24T21:54:22  *** Aaronvan_ has joined #bitcoin-core-dev
9012017-08-24T21:55:02  *** AaronvanW has quit IRC
9022017-08-24T21:55:21  *** cheese_ has joined #bitcoin-core-dev
9032017-08-24T21:58:34  *** RoyceX has joined #bitcoin-core-dev
9042017-08-24T21:59:11  *** Cryptocide has quit IRC
9052017-08-24T21:59:27  *** Cryptocide has joined #bitcoin-core-dev
9062017-08-24T22:01:35  *** cheese_ has quit IRC
9072017-08-24T22:03:49  *** cheese_ has joined #bitcoin-core-dev
9082017-08-24T22:03:49  *** RoyceX has quit IRC
9092017-08-24T22:09:09  *** vicenteH has quit IRC
9102017-08-24T22:27:05  *** jimpo has quit IRC
9112017-08-24T22:27:31  <meshcollider> 8:21 am <sipa> luke-jr: let's work on compressed blocks then
9122017-08-24T22:27:32  <meshcollider> What's the current to-do for them?
9132017-08-24T22:28:36  <sipa> morcos: designing, experimenting, implementating :)
9142017-08-24T22:28:44  <sipa> s/morcos/meshcollider/
9152017-08-24T22:29:10  <luke-jr> it's too bad the UTXO set doesn't store the absolute output index in the blockchain
9162017-08-24T22:29:42  <sipa> luke-jr: it's easy enough to add if that's needed
9172017-08-24T22:29:53  <luke-jr> sipa: wouldn't it require a re-sync for all pruned nodes?
9182017-08-24T22:30:03  <luke-jr> otoh, maybe there's some way to do a gradual upgrade..?
9192017-08-24T22:33:16  <meshcollider> sipa: doesn't BIP 152 cover at least the design step? Or is it still being thought out
9202017-08-24T22:33:30  <sipa> meshcollider: bip152 is completely unrelated
9212017-08-24T22:33:41  <sipa> meshcollider: we're just talking about an efficient encoding for transactions
9222017-08-24T22:33:56  <sipa> luke-jr: if you really mean absolute index, yes
9232017-08-24T22:34:15  <sipa> hmm, even for relative index in the block
9242017-08-24T22:34:23  <luke-jr> relative index isn't quite as useful
9252017-08-24T22:34:31  <luke-jr> I was thinking have all the inputs just address by index
9262017-08-24T22:35:01  <meshcollider> Oh am I confusing compressed blocks with compact blocks
9272017-08-24T22:35:17  <luke-jr> I suppose relative index in the sense of "<this tx abs index> - <relative index> = <input's TXO abs index>" might be good
9282017-08-24T22:35:27  <luke-jr> might make varint more optimal
9292017-08-24T22:35:48  <gmaxwell> luke-jr: I can't figure out what you're talking about.
9302017-08-24T22:35:58  <luke-jr> I suppose a per-block index might also be combinable with UTXO height, but I don't see a clear advantage to that
9312017-08-24T22:36:10  <luke-jr> gmaxwell: replace the input txid+index with an absolute tx index in the blockchain
9322017-08-24T22:36:46  <gmaxwell> how does that have anything to do with the utxo set?
9332017-08-24T22:37:00  <luke-jr> you'd need to store/index by the absolute tx index to do the lookup
9342017-08-24T22:37:30  <luke-jr> saying blockchain tx #1934 isn't useful unless the node can easily figure out what tx that is
9352017-08-24T22:37:33  <luke-jr> utxo*
9362017-08-24T22:37:35  <gmaxwell> I think what you're trying to suggest is this: make a transfered block smaller by rekeying its inputs with indexes.
9372017-08-24T22:37:48  <sipa> luke-jr: i think needing a UTXO set in order to just decompress a block is already a no-go
9382017-08-24T22:37:53  *** Cryptocide has quit IRC
9392017-08-24T22:37:58  <gmaxwell> I think all you need is an index to txid table, seperate from the utxo set. Which you can build on the fly as you sync.
9402017-08-24T22:38:08  <sipa> luke-jr: as that means an attacker can make you do arbitrarily much I/O before you can figure out PoW
9412017-08-24T22:38:11  *** Cryptocide has joined #bitcoin-core-dev
9422017-08-24T22:38:16  <gmaxwell> but as sipa is pointing out it would be a layering mess.
9432017-08-24T22:38:20  <sipa> s/figure out/validate/
9442017-08-24T22:38:27  <luke-jr> hm
9452017-08-24T22:39:04  <gmaxwell> luke-jr: the compacted seralization I proposed (which sipa later refined) reduces tx sizes by around 28% without doing anything like that, working just one tx at a time... so it's useful for loose transction relay as well as blocks.
9462017-08-24T22:39:44  <gmaxwell> yes, there is a lot more savings if you could replace txin hashes with indexes, but ... layering mess.
9472017-08-24T22:40:07  <luke-jr> what if we add a commitment to the index-based format?
9482017-08-24T22:40:36  *** jimpo has joined #bitcoin-core-dev
9492017-08-24T22:40:43  <gmaxwell> yes, we could do something like have a compressed block, format where there was a tree-root in the software, assume valid style, no commitment needed.
9502017-08-24T22:41:42  <gmaxwell> but: I think we'd better off spending effort on from utxo sync (needed to escape eventual doom); or on compact seralization (works also for loose transaction relay)
9512017-08-24T22:42:37  <meshcollider> gmaxwell: is your serialisation format posted anywhere? Sorry I'm just catching up
9522017-08-24T22:43:39  <gmaxwell> meshcollider: yes, but sipa's revised version is better and I don't think thats posted anywhere.
9532017-08-24T22:44:19  *** owowo has quit IRC
9542017-08-24T22:44:38  <sipa> https://gist.github.com/sipa/1d29c1019e00874a61e533b2b050046f
9552017-08-24T22:44:51  <sipa> very much WIP
9562017-08-24T22:49:35  *** Guest79199 has quit IRC
9572017-08-24T22:49:38  *** owowo has joined #bitcoin-core-dev
9582017-08-24T22:50:02  <morcos> damn, i skipped down to Analysis
9592017-08-24T22:53:03  <sipa> haha
9602017-08-24T22:54:10  *** hasten has joined #bitcoin-core-dev
9612017-08-24T22:55:28  <jimpo> I'm looking into writing a P2P test for this: https://github.com/bitcoin/bitcoin/pull/11113
9622017-08-24T22:55:45  <jimpo> What's the best way from the test framework to fast-forward time or create blocks in the future
9632017-08-24T22:56:17  <jimpo> or start the chain with blocks far in the past would work too
9642017-08-24T22:57:01  *** hasten has quit IRC
9652017-08-24T23:04:25  *** Aaronvan_ is now known as AaronvanW
9662017-08-24T23:06:45  <jimpo> nvm, I found the setmocktime method
9672017-08-24T23:09:06  *** cheese_ has quit IRC
9682017-08-24T23:15:49  *** Dyaheon has quit IRC
9692017-08-24T23:16:55  *** chjj has quit IRC
9702017-08-24T23:18:18  *** Dyaheon has joined #bitcoin-core-dev
9712017-08-24T23:20:20  *** cheese_ has joined #bitcoin-core-dev
9722017-08-24T23:27:50  <gmaxwell> morcos: IIRC sipa's version is ~28% size reduction for the history.
9732017-08-24T23:28:42  *** chjj has joined #bitcoin-core-dev
9742017-08-24T23:35:36  *** RoyceX has joined #bitcoin-core-dev
9752017-08-24T23:36:33  *** cheese_ has quit IRC
9762017-08-24T23:39:05  *** Dizzle has quit IRC
9772017-08-24T23:47:20  *** davec has quit IRC
9782017-08-24T23:49:15  *** jimpo has quit IRC
9792017-08-24T23:55:23  *** sniip3r has joined #bitcoin-core-dev
9802017-08-24T23:56:22  *** Aaronvan_ has joined #bitcoin-core-dev
9812017-08-24T23:58:03  *** AaronvanW has quit IRC