1 2017-08-24 01:47:14	0|meshcollider|is there any style preference for atomic_bool vs atomic<bool> and similar for other atomic types?
  2 2017-08-24 01:47:25	0|meshcollider|Its not mentioned in the style guidelines
  3 2017-08-24 02:12:52	0|BlueMatt|meshcollider: not atm, I dont believe
  4 2017-08-24 02:13:27	0|meshcollider|ok sweet as
  5 2017-08-24 02:18:16	0|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
  6 2017-08-24 02:18:31	0|cfields|(i'm pretty sure i haven't even been consistent with my own preference though)
  7 2017-08-24 02:23:33	0|meshcollider|might as well change the couple of atomic_ to atomic<> and add it to the developer notes then aye? Or not worth it
  8 2017-08-24 02:31:17	0|cfields|i don't really mind either way
  9 2017-08-24 03:01:07	0|achow101|happy segwit activation
 10 2017-08-24 03:05:03	0|BlueMatt|indeed it is
 11 2017-08-24 04:08:35	0|fanquake|Has anyone had trouble gitian building the signed windows build? I'm getting a message digest mismatch. Never seen that before.
 12 2017-08-24 04:22:00	0|gmaxwell|w
 13 2017-08-24 05:28:08	0|wumpus|fanquake: for rc2? no, haven't heard issues reported
 14 2017-08-24 05:29:50	0|gmaxwell|wumpus: someone on reddit was saying it was segfaulting for them, I prodded them to open an issue.
 15 2017-08-24 05:29:54	0|fanquake|wumpus yes rc2. Had no issues with rc1.
 16 2017-08-24 05:31:19	0|fanquake|Details here if anyone is interested. https://pastebin.com/WCPjd1gE Will submit built sigs and play around with it later.
 17 2017-08-24 05:33:20	0|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.
 18 2017-08-24 05:34:17	0|meshcollider|ah in that case should i drop the commit to change them from my PR?
 19 2017-08-24 05:34:18	0|meshcollider|https://github.com/bitcoin/bitcoin/pull/11107/commits/f334f44bad5a78978f714148b799cea6e12a525f
 20 2017-08-24 05:34:53	0|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
 21 2017-08-24 05:35:23	0|wumpus|yes, no need to make a rule about it, it doesn't affect safety
 22 2017-08-24 05:36:00	0|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
 23 2017-08-24 05:37:21	0|meshcollider|removed
 24 2017-08-24 05:39:01	0|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
 25 2017-08-24 05:40:16	0|wumpus|then some things like consistent variable naming which are reasonably important to be able to distinguish various scopes
 26 2017-08-24 05:42:17	0|wumpus|btw has anyone tried cross-compiling bitcoin core for windows from ubuntu zesty/17.04 or pre-.10
 27 2017-08-24 05:43:05	0|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
 28 2017-08-24 05:48:10	0|wumpus|fanquake: whoa, I never saw that one before. Maybe cfields can comment what it means.  Did your unsigned assert match?
 29 2017-08-24 05:51:49	0|sipa|wumpus: agree, for many things it really doesn't matter what approach is used
 30 2017-08-24 05:52:18	0|fanquake|wumpus my win-unsigned sigs match yours. Will PR them in a sec.
 31 2017-08-24 05:55:49	0|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.
 32 2017-08-24 05:57:36	0|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
 33 2017-08-24 05:58:41	0|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 :)
 34 2017-08-24 05:58:55	0|luke-jr|wumpus: sure, just saying, if he doesn't answer, it's probably made-up
 35 2017-08-24 06:00:37	0|wumpus|agree, making up segfaults just to sabotage the rc process would be a new low, but yeah you never know here
 36 2017-08-24 06:02:19	0|bitcoin-git|13bitcoin/06master 14fa14b67 15MarcoFalke: [doc] build-windows: Mention that only trusty works
 37 2017-08-24 06:02:19	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/8858b6ddd3bc...00ada17230f7
 38 2017-08-24 06:02:20	0|bitcoin-git|13bitcoin/06master 1400ada17 15Wladimir J. van der Laan: Merge #11119: [doc] build-windows: Mention that only trusty works...
 39 2017-08-24 06:02:28	0|fanquake|wumpus opened a PR at the gitian sigs repo if you want to compare sigs.
 40 2017-08-24 06:02:59	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11119: [doc] build-windows: Mention that only trusty works (06master...06Mf1708-docBuildWinTrusty) 02https://github.com/bitcoin/bitcoin/pull/11119
 41 2017-08-24 06:05:26	0|wumpus|fanquake: all ok
 42 2017-08-24 06:14:02	0|wumpus|fanquake: I retried that part of gitian process here, got this output: https://0bin.net/paste/63Ek6D3S2Skvx3j7#2hu2HQVGq49WrG1g0a3-HRT/77bV80g7lpMDgES7KUs
 43 2017-08-24 06:15:03	0|wumpus|PE checksum is the same, Calculated message digest : 73AAB82BB3761BE13A9DC0ACAC0BD35AC51C48DC matches in my case though
 44 2017-08-24 06:20:21	0|wumpus|however your input file's sha256sum af3da01beda391e06f2fb4d2dced316b580f989b71ee886582aaddac5c00374f for bitcoin-0.15.0-win64-setup-unsigned.exe matches
 45 2017-08-24 06:21:07	0|wumpus|some faulty case of caching maybe?
 46 2017-08-24 06:21:44	0|fanquake|wumpus not sure. I'm re-running the windows build now.
 47 2017-08-24 06:25:58	0|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?)
 48 2017-08-24 06:36:13	0|fanquake|wumpus it should have been the right one. Will check shortly as it will still be in /inputs
 49 2017-08-24 06:37:19	0|wumpus|maybe we should add a sha256sum of the input file to that descriptor's build output, to diagnose cases like this
 50 2017-08-24 06:54:26	0|bitcoin-git|13bitcoin/06master 1479191f5 15Joe Harvell: Add option -stdinrpcpass to allow RPC password to be read from standard input
 51 2017-08-24 06:54:26	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/00ada17230f7...affe9271aa49
 52 2017-08-24 06:54:27	0|bitcoin-git|13bitcoin/06master 14affe927 15Wladimir J. van der Laan: Merge #10997: RPC: Add option -stdinrpcpass to bitcoin-cli to allow RPC password to be read from standard input...
 53 2017-08-24 06:54:59	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10997: RPC: Add option -stdinrpcpass to bitcoin-cli to allow RPC password to be read from standard input (06master...06stdinrpcpass) 02https://github.com/bitcoin/bitcoin/pull/10997
 54 2017-08-24 07:18:38	0|bitcoin-git|[13bitcoin] 15practicalswift closed pull request #10961: Improve readability of DecodeBase58Check(...) (06master...06DecodeBase58Check-cleanup) 02https://github.com/bitcoin/bitcoin/pull/10961
 55 2017-08-24 07:19:37	0|bitcoin-git|[13bitcoin] 15practicalswift reopened pull request #10961: Improve readability of DecodeBase58Check(...) (06master...06DecodeBase58Check-cleanup) 02https://github.com/bitcoin/bitcoin/pull/10961
 56 2017-08-24 10:49:43	0|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?
 57 2017-08-24 10:51:27	0|meshcollider|(unrelated to the issue fanquake was having btw)
 58 2017-08-24 12:40:07	0|michagogo|meshcollider: looks like the former script exports an env variable to use that device
 59 2017-08-24 12:40:20	0|michagogo|The latter*
 60 2017-08-24 12:40:43	0|michagogo|br0 is the default that gitian uses (and if I'm not mistaken, that's what's set up on my system)
 61 2017-08-24 12:44:43	0|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?
 62 2017-08-24 12:46:01	0|instagibbs|GAit, looks like a "normal" failure: assert wait_until(lambda: len(self.nodes[1].getrawmempool()) == 5)
 63 2017-08-24 12:48:06	0|GAit|What do you mean normal? it shouldn't fail and indeed it doesn't fail on the other runners nor locally.
 64 2017-08-24 12:49:31	0|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.
 65 2017-08-24 12:56:07	0|fanquake1|GAit I restarted the tests
 66 2017-08-24 13:00:43	0|jnewbery|fanquake1 - I was just looking at the Travis output and it disappeared under my feet :(
 67 2017-08-24 13:01:15	0|jnewbery|in any case, if it's a new test and it failed first time on Travis it's probably reproducible
 68 2017-08-24 13:07:20	0|instagibbs|GAit, it means that it appears to be related to your changes, or maybe you got unlucky
 69 2017-08-24 13:09:17	0|fanquake1|jnewbery sorry. Looks like the same two have failed anyways.
 70 2017-08-24 13:10:19	0|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.
 71 2017-08-24 13:11:44	0|GAit|jnewbery: seems we get the same failure, but only on some builders
 72 2017-08-24 13:13:23	0|jnewbery|ok, I'll try to reproduce locally
 73 2017-08-24 13:17:06	0|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)
 74 2017-08-24 13:17:27	0|jnewbery|Try rebasing on master and changing the `assert wait_until()`s to `wait_until()`s
 75 2017-08-24 13:19:57	0|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?
 76 2017-08-24 13:25:05	0|jnewbery|GAit: Github automatically creates a merge into master, which is what Travis takes for its build: https://github.com/bitcoin/bitcoin/commit/30dfb2ceda2e8aae954a25b6a3cef63d24cf6512
 77 2017-08-24 13:25:28	0|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
 78 2017-08-24 13:25:43	0|jnewbery|if you merge or rebase locally and then test I expect it'll fail in the same way
 79 2017-08-24 13:26:40	0|jnewbery|And yes, probably a good idea to squash at this point
 80 2017-08-24 13:28:54	0|GAit|thanks! i thought i was crazy :) indeed fails locally now, will fix and squash
 81 2017-08-24 13:31:16	0|jnewbery|GAit: no problem. I'll re-review once you've pushed
 82 2017-08-24 13:35:11	0|GAit|jnewbery: done but i'd wait for travis before reviewing
 83 2017-08-24 13:40:21	0|promag|jnewbery: do you think travis should merge with master and then run the tests?
 84 2017-08-24 13:43:33	0|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
 85 2017-08-24 13:45:30	0|GAit|i guess is better to fail earlier rather merge day but it was confusing for me
 86 2017-08-24 13:46:56	0|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.
 87 2017-08-24 13:47:41	0|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?
 88 2017-08-24 13:49:54	0|promag|usually unless you point the diff between the old and new commit.
 89 2017-08-24 14:01:20	0|instagibbs|wish github had gitlab feature of "diff since last push"
 90 2017-08-24 14:32:09	0|GAit|jnewbery: i like what you are doing in #11121
 91 2017-08-24 14:33:34	0|jnewbery|GAit thanks. Just working on some nits from kallewoof and MarcoFalke. I'll push an updated branch soon. Reviews always appreciated :)
 92 2017-08-24 14:36:50	0|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?
 93 2017-08-24 14:44:26	0|GAit|mempool_persist seems to work fine locally without the sleeps (and 3 whole seconds faster!)
 94 2017-08-24 15:09:28	0|jnewbery|GAit - yes there are probably sleeps that can be removed
 95 2017-08-24 15:39:09	0|MarcoFalke|Indeed, we should remove all sleeps other than for explicit polling
 96 2017-08-24 16:39:41	0|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
 97 2017-08-24 16:39:47	0|adrh|here is my script: https://pastebin.com/fESuZDvz
 98 2017-08-24 16:41:11	0|adrh|it works to list my address, but i can't make sendtoaddress work
 99 2017-08-24 16:50:45	0|adrh|anyone ?
100 2017-08-24 16:54:03	0|instagibbs|adrh, try #bitcoin
101 2017-08-24 16:54:51	0|adrh|i tried . nobody can help me there at the moment
102 2017-08-24 17:03:06	0|instagibbs|sorry, off topic here
103 2017-08-24 17:04:32	0|adrh|i dont know where to ask to be honest. i'm trying for 8 hours to make it work...
104 2017-08-24 17:22:45	0|luke-jr|I seem to have a reproducable crash at startup with rc2 on testnet
105 2017-08-24 17:23:35	0|gmaxwell|luke-jr: whats the backtrace
106 2017-08-24 17:23:41	0|luke-jr|getting it
107 2017-08-24 17:25:28	0|luke-jr|http://codepad.org/aiVTgE08
108 2017-08-24 17:25:59	0|luke-jr|lock order issue, so probably wouldn't affect prod bins
109 2017-08-24 17:28:25	0|gmaxwell|what did the lockorder debugging print
110 2017-08-24 17:29:52	0|luke-jr|it's in the pastebin
111 2017-08-24 17:30:55	0|luke-jr|I don't understand how the walletdb.cpp lock is still in the lock order here
112 2017-08-24 17:44:01	0|ryanofsky|probably the easiest way to fix this is to just change LoadWallet LOCK(wallet) to a LOCK2(main, wallet)
113 2017-08-24 17:44:20	0|BlueMatt|ryanofsky: that feels strange...maybe cs_main in CreateWalletFromFile in wallet.cpp instead?
114 2017-08-24 17:44:24	0|luke-jr|ryanofsky: do you understand the problem? why is walletdb's lock relevant here?
115 2017-08-24 17:44:27	0|BlueMatt|taking cs_main inside of walletdb is...yuck
116 2017-08-24 17:44:34	0|BlueMatt|luke-jr: cause its a lock inversion
117 2017-08-24 17:44:46	0|BlueMatt|walletdb takes the wallet lock, so...lock inversion?
118 2017-08-24 17:44:48	0|luke-jr|BlueMatt: but walletdb's lock is released before we get to the wallet lock?
119 2017-08-24 17:44:54	0|BlueMatt|no it isnt
120 2017-08-24 17:45:00	0|BlueMatt|ReadKeyValue calls back into wallet
121 2017-08-24 17:46:16	0|luke-jr|BlueMatt: to ReacceptWalletTransactions?
122 2017-08-24 17:46:19	0|luke-jr|how?
123 2017-08-24 17:46:35	0|MarcoFalke|wumpus: Mind to create a gitian.docs under bitcoin-core?
124 2017-08-24 17:46:46	0|BlueMatt|luke-jr: yes
125 2017-08-24 17:46:48	0|BlueMatt|LoadToWallet
126 2017-08-24 17:46:55	0|MarcoFalke|You wanted me to write a fedora guide for it
127 2017-08-24 17:47:48	0|luke-jr|BlueMatt: that doesn't call Reaccept
128 2017-08-24 17:48:07	0|bitcoin-git|[13bitcoin] 15promag opened pull request #11125: Add bitcoin-cli -stdinrpcpass functional test (06master...062017-08-stdinrpcpass-functional-test) 02https://github.com/bitcoin/bitcoin/pull/11125
129 2017-08-24 17:48:40	0|promag|jnewbery: ^ as soon as you can? ty!
130 2017-08-24 17:49:12	0|wumpus|MarcoFalke: you want a repo specifically for gitian docs?
131 2017-08-24 17:49:29	0|BlueMatt|luke-jr: the conflict is MarkConflicted, not Reaccept
132 2017-08-24 17:50:36	0|luke-jr|oh, the backtrace was in Reaccept
133 2017-08-24 17:50:38	0|MarcoFalke|jup, they don't really belong in the main repo
134 2017-08-24 17:50:50	0|MarcoFalke|Also, a GitHub wiki is not suitable
135 2017-08-24 17:51:23	0|MarcoFalke|It is either open to be edited by anyone (with a GitHub account) or effectively none
136 2017-08-24 17:57:45	0|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?
137 2017-08-24 17:58:26	0|luke-jr|wumpus: +1
138 2017-08-24 17:58:55	0|luke-jr|if (prevtx.nIndex == -1 && !prevtx.hashUnset()) { <-- this line needs a comment :/
139 2017-08-24 17:58:56	0|MarcoFalke|wumpus: Fine with me
140 2017-08-24 17:59:10	0|wumpus|MarcoFalke: ok
141 2017-08-24 17:59:22	0|luke-jr|otoh, gitian docs may be unversioned, whereas other docs might be versioned?
142 2017-08-24 18:00:43	0|wumpus|nah, all documentation tends to be about the newest versions
143 2017-08-24 18:01:01	0|wumpus|could add sections for building older versions
144 2017-08-24 18:01:08	0|luke-jr|wumpus: I just mean, it makes sense to tag docs per release, but not gitian docs necessarily
145 2017-08-24 18:01:24	0|wumpus|I'd prefer not to do any tagging/brancing in the docs repo
146 2017-08-24 18:01:51	0|wumpus|document change control tends to be very diffrent from source code
147 2017-08-24 18:01:55	0|luke-jr|wumpus: so we keep release-specific docs with the main repo?
148 2017-08-24 18:02:17	0|wumpus|yes, there are no plans to move anythingbesides the gitian building doc at this point
149 2017-08-24 18:02:53	0|luke-jr|i c
150 2017-08-24 18:09:05	0|wumpus|MarcoFalke: https://github.com/bitcoin-core/docs.git
151 2017-08-24 18:09:15	0|MarcoFalke|ty
152 2017-08-24 18:09:48	0|wumpus|you should have push access, we can add other maintainers later
153 2017-08-24 18:19:36	0|cfields|sipa: do you have local work on top of #11117? Anything I can help with there?
154 2017-08-24 18:23:10	0|sipa|cfields: nope
155 2017-08-24 18:23:19	0|sipa|but i don't expect it to be much
156 2017-08-24 18:27:28	0|cfields|ok. let me know if there's anything i can help with without stepping on your toes
157 2017-08-24 18:29:47	0|bitcoin-git|[13bitcoin] 15ryanofsky opened pull request #11126: Acquire cs_main lock before cs_wallet during wallet initialization (06master...06pr/loadlock2) 02https://github.com/bitcoin/bitcoin/pull/11126
158 2017-08-24 19:00:01	0|sipa|WOOSH
159 2017-08-24 19:00:38	0|sipa|meetingh?
160 2017-08-24 19:00:47	0|jonasschnelli|\o/
161 2017-08-24 19:01:46	0|lightningbot|Meeting started Thu Aug 24 19:01:45 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
162 2017-08-24 19:01:46	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
163 2017-08-24 19:01:46	0|wumpus|#startmeeting
164 2017-08-24 19:01:54	0|gmaxwell|wumpus: you have the best nameping.
165 2017-08-24 19:02:12	0|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
166 2017-08-24 19:02:17	0|kanzure|hi.
167 2017-08-24 19:02:19	0|achow101|hi
168 2017-08-24 19:02:33	0|BlueMatt|happy segwit everyone
169 2017-08-24 19:02:52	0|sipa|short topic: thanks and congrats everyone with SegWit... it seems it activated on the network without a glitch
170 2017-08-24 19:02:57	0|wumpus|yes, congratulations everyone!
171 2017-08-24 19:03:04	0|jonasschnelli|wohoo!
172 2017-08-24 19:03:07	0|achow101|yay!
173 2017-08-24 19:03:11	0|cfields|hi
174 2017-08-24 19:03:14	0|wumpus|it took lots of time, and lots of sweat, but we did it
175 2017-08-24 19:03:37	0|kanzure|whole bitcoin community did it
176 2017-08-24 19:03:45	0|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.
177 2017-08-24 19:04:00	0|luke-jr|s/glitch/good thing/
178 2017-08-24 19:04:00	0|sipa|gmaxwell: everything on its time
179 2017-08-24 19:04:07	0|sipa|misconceptions are hard to fix
180 2017-08-24 19:04:08	0|gmaxwell|You may well have jinxed us, since things blowing up might only happen with a >1MB block. :)
181 2017-08-24 19:04:11	0|BlueMatt|yes, some miner appear to be confused by maxblocksize/maxblockweight options, we need #11100
182 2017-08-24 19:04:12	0|wumpus|we should probably publicize some segwit miner's faq thing
183 2017-08-24 19:04:15	0|wumpus|on bitcoincore.org
184 2017-08-24 19:04:27	0|achow101|wumpus: isn't there already one?
185 2017-08-24 19:04:28	0|luke-jr|wumpus: not if they don't encourage big blocks. :/
186 2017-08-24 19:04:32	0|luke-jr|err, not if they do*
187 2017-08-24 19:04:34	0|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.
188 2017-08-24 19:04:48	0|wumpus|achow101: there is a segwit faq but it doesn't include this
189 2017-08-24 19:04:52	0|achow101|https://bitcoincore.org/en/2016/10/27/segwit-upgrade-guide/#miners
190 2017-08-24 19:05:03	0|achow101|not really an faq I guess
191 2017-08-24 19:05:37	0|gmaxwell|achow101: says nothing about needing to remove the maxblocksize setting and setting maxblockweight=4000000
192 2017-08-24 19:05:49	0|luke-jr|there is no such need, nor is it good for them to do so
193 2017-08-24 19:06:20	0|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.
194 2017-08-24 19:06:31	0|wumpus|kanzure: +1
195 2017-08-24 19:06:56	0|harding|Is there anything else that should go into a current segwit faq for miners?
196 2017-08-24 19:06:56	0|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
197 2017-08-24 19:07:13	0|kanzure|sounds like there's some requests for a post-activation faq
198 2017-08-24 19:07:18	0|wumpus|#topic segwit faq for miners
199 2017-08-24 19:07:24	0|luke-jr|hm, I thought we had documented it before, but I can't find it
200 2017-08-24 19:07:58	0|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?)
201 2017-08-24 19:08:05	0|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.
202 2017-08-24 19:08:07	0|wumpus|not sure if there's any other ones, have there been any other frequent questions about segwit by miners?
203 2017-08-24 19:08:23	0|luke-jr|BlueMatt: size is often the bottleneck today, so it makes sense to limit by size
204 2017-08-24 19:08:37	0|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. :(
205 2017-08-24 19:08:38	0|BlueMatt|luke-jr: ok, then gbt clients can do so
206 2017-08-24 19:08:57	0|gmaxwell|luke-jr: size is a bottleneck in _what_?
207 2017-08-24 19:09:18	0|BlueMatt|wumpus: I've literally heard confusion to the tone of what gmaxwell described from every mining pool operator I spoke to
208 2017-08-24 19:09:20	0|luke-jr|gmaxwell: IBD mainly at this point I guess
209 2017-08-24 19:09:23	0|BlueMatt|that option needs to die
210 2017-08-24 19:09:26	0|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
211 2017-08-24 19:09:39	0|sipa|*constrained
212 2017-08-24 19:09:40	0|achow101|luke-jr: IBD is too late to save already
213 2017-08-24 19:09:43	0|luke-jr|sipa: blocksonly?
214 2017-08-24 19:09:44	0|gmaxwell|luke-jr: not for anyone with an internet connection beyond a few megabits in speed.
215 2017-08-24 19:10:25	0|gmaxwell|luke-jr: IBD time is limited by chainstate database operations for parties that aren't totally network starved.
216 2017-08-24 19:10:25	0|luke-jr|achow101: it's nothing like as bad as it could be
217 2017-08-24 19:10:42	0|cfields|i've seen a ton of questions about segwit and "the addresses that start with a 3"...
218 2017-08-24 19:10:51	0|kanzure|ya i have seen mostly non-miner questions
219 2017-08-24 19:10:52	0|BlueMatt|anyway, so aside from luke is there anyone who objects generally to removing -maxblocksize? (ala #11100)
220 2017-08-24 19:10:56	0|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
221 2017-08-24 19:11:06	0|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
222 2017-08-24 19:11:11	0|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 :/
223 2017-08-24 19:11:15	0|kanzure|we can also copy-paste old segwit faq details anyway
224 2017-08-24 19:11:17	0|kanzure|(or link to them)
225 2017-08-24 19:11:21	0|sipa|luke-jr: prune
226 2017-08-24 19:11:27	0|luke-jr|sipa: that doesn't eliminate IBD
227 2017-08-24 19:11:30	0|wumpus|'take the option away and the problem goes away' is a bit too simplistic at this point
228 2017-08-24 19:11:34	0|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...
229 2017-08-24 19:11:44	0|BlueMatt|ehh, deprecates it
230 2017-08-24 19:11:52	0|BlueMatt|and clearly states blockmaxsize is deprecated
231 2017-08-24 19:12:01	0|BlueMatt|which roughly aligns with the expectation of everyone i spoke to
232 2017-08-24 19:12:07	0|luke-jr|11100 is stupid.
233 2017-08-24 19:12:13	0|BlueMatt|there was confusion as to why blockmaxsize still existed in the context of segwit
234 2017-08-24 19:12:17	0|meshcollider|deprecating makes sense to me
235 2017-08-24 19:12:31	0|morcos|even i have trouble keeping up with what the interaction of these different options is
236 2017-08-24 19:12:42	0|kanzure|needs an interaction matrix visualization
237 2017-08-24 19:12:53	0|kanzure|where the cells indicate interaction :-)
238 2017-08-24 19:12:54	0|morcos|we need to move towards getting rid of blockmaxsize, its confusion for no benefit....
239 2017-08-24 19:12:56	0|achow101|is blockmaxsize taken into consideration with segwit or just ignored?
240 2017-08-24 19:13:02	0|sipa|achow101: it is!
241 2017-08-24 19:13:05	0|wumpus|deprecation is likely a good idea on the longer run, but not a fix to the misunderstanding created
242 2017-08-24 19:13:06	0|instagibbs|taken into account
243 2017-08-24 19:13:16	0|gmaxwell|achow101: it does something stupid, it truncates block construction when you reach that size.
244 2017-08-24 19:13:20	0|achow101|bleh :/
245 2017-08-24 19:13:33	0|luke-jr|it does what it's supposed to do
246 2017-08-24 19:13:49	0|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.
247 2017-08-24 19:13:58	0|morcos|wait a second
248 2017-08-24 19:14:00	0|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
249 2017-08-24 19:14:08	0|luke-jr|gmaxwell: you're rewriting history now
250 2017-08-24 19:14:13	0|BlueMatt|deprecation is, itself, documentation
251 2017-08-24 19:14:18	0|wumpus|BlueMatt: but we're already in the screwed state that those options exist
252 2017-08-24 19:14:20	0|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
253 2017-08-24 19:14:33	0|morcos|isn't the default infinity?
254 2017-08-24 19:14:45	0|sdaftuar|morcos: no, i don't think so.
255 2017-08-24 19:14:46	0|sipa|morcos: i honestly don't know anymore
256 2017-08-24 19:14:50	0|achow101|morcos: how so?
257 2017-08-24 19:14:51	0|morcos|if you don't set blockmaxsize it doesn't even calculate it
258 2017-08-24 19:15:06	0|gmaxwell|morcos: the default is 1/4 the configured weight which defaults to 3m.
259 2017-08-24 19:15:07	0|sdaftuar|if you set nothing, you get a 750k default, i believe.  and a 3M weight max.
260 2017-08-24 19:15:08	0|wumpus|I'm fine with marking it as deprecated anyhow
261 2017-08-24 19:15:10	0|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
262 2017-08-24 19:15:19	0|sdaftuar|if you set just blockmaxweight, then blockmaxsize is effectively infinity, i think.
263 2017-08-24 19:15:27	0|bitcoin-git|[13bitcoin] 15romanornr opened pull request #11127: Make Bitcoin Core compatible with NYA segwit2x (06master...06s2x) 02https://github.com/bitcoin/bitcoin/pull/11127
264 2017-08-24 19:15:30	0|gmaxwell|sdaftuar: right.
265 2017-08-24 19:15:36	0|sipa|if you set only one of them, the other is taken as infinity
266 2017-08-24 19:15:42	0|gmaxwell|oh jesus.
267 2017-08-24 19:15:43	0|sipa|if you set both, both are enforced independently
268 2017-08-24 19:15:44	0|sdaftuar|but blockmaxsize is absurd, it should be removed.
269 2017-08-24 19:15:49	0|morcos|sdaftuar: you think if you set no options you can not produce a segwit-tx containing block bigger than 750k?
270 2017-08-24 19:15:53	0|morcos|that doesn't seem right to me
271 2017-08-24 19:16:04	0|sipa|morcos: i believe that is correct
272 2017-08-24 19:16:09	0|instagibbs|morcos, pretty sure that's correct
273 2017-08-24 19:16:10	0|gmaxwell|That is correct.
274 2017-08-24 19:16:10	0|sdaftuar|correct, you are capped at 750kb
275 2017-08-24 19:16:19	0|bitcoin-git|[13bitcoin] 15romanornr closed pull request #11127: Make Bitcoin Core compatible with NYA segwit2x (06master...06s2x) 02https://github.com/bitcoin/bitcoin/pull/11127
276 2017-08-24 19:16:19	0|meshcollider|if you set blockmaxsize then blockmaxweight becomes blockmaxsize * WITNESS_SCALE_FACTOR doesn't it?
277 2017-08-24 19:16:21	0|instagibbs|all miners have cranked up to 1MB
278 2017-08-24 19:16:21	0|morcos|ugh, we should never have released it in this state
279 2017-08-24 19:16:42	0|sdaftuar|+1
280 2017-08-24 19:16:54	0|sipa|yes
281 2017-08-24 19:17:04	0|wumpus|but we're there anyhow, what now?
282 2017-08-24 19:17:15	0|gmaxwell|instagibbs: which now means a cranking down to 1MB. :(
283 2017-08-24 19:17:28	0|sdaftuar|wumpus: we should remove it and deprecate the command line option
284 2017-08-24 19:17:29	0|bitcoin-git|[13bitcoin] 15hovah opened pull request #11128: Make Bitcoin Core compatible with NYA segwit2x (06master...06s2x) 02https://github.com/bitcoin/bitcoin/pull/11128
285 2017-08-24 19:17:38	0|sdaftuar|as we indicated we may do in the future in the 0.13 release notes, iirc
286 2017-08-24 19:17:42	0|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.
287 2017-08-24 19:17:45	0|gmaxwell|Well we should remove the silly option. The maximum size is not really correlated with anything that is interesting to be set anymore.
288 2017-08-24 19:17:47	0|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.
289 2017-08-24 19:17:51	0|luke-jr|morcos: absolutely not
290 2017-08-24 19:18:02	0|jtimon|BlueMatt: ack on removing blockmaxsize and leaving only maxblockweight
291 2017-08-24 19:18:03	0|gmaxwell|Luke is faulty.
292 2017-08-24 19:18:14	0|wumpus|luke-jr: so they can still choose to do that with that option removed, right?
293 2017-08-24 19:18:26	0|wumpus|luke-jr: e.g. by setting the blockmaxweight lower?
294 2017-08-24 19:18:34	0|sdaftuar|or by using the gbt results and truncating themselves
295 2017-08-24 19:18:36	0|BlueMatt|anyway, so it sounds like #11100
296 2017-08-24 19:18:39	0|wumpus|that doesn't need two options
297 2017-08-24 19:18:40	0|luke-jr|wumpus: not effectively
298 2017-08-24 19:18:49	0|sdaftuar|luke-jr: why not?
299 2017-08-24 19:18:56	0|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
300 2017-08-24 19:18:57	0|sipa|luke-jr: the assumption behind segwit is that size doesn't matter nearly as much as a new metric, weight
301 2017-08-24 19:18:57	0|wumpus|the complication here is having two options that interact in a complicated way
302 2017-08-24 19:19:02	0|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?
303 2017-08-24 19:19:04	0|wumpus|please don't confuse it with what the value should be
304 2017-08-24 19:19:09	0|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.
305 2017-08-24 19:19:13	0|sipa|luke-jr: i'm sorry to hear you disagree about that point, but that ship has sailed
306 2017-08-24 19:19:14	0|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
307 2017-08-24 19:19:19	0|morcos|Unless someone else agrees with Luke, I htink its just time to say unfortunately we're proceeding against his objections on this issue
308 2017-08-24 19:19:30	0|jnewbery|Concept ACK 11100
309 2017-08-24 19:19:38	0|gmaxwell|praxeology1: oh jesus christ you're also confused
310 2017-08-24 19:19:58	0|wumpus|yes, that sounds confused
311 2017-08-24 19:19:59	0|luke-jr|sipa: that ship has not sailed. that's not an argument.
312 2017-08-24 19:20:14	0|gmaxwell|praxeology1: THERE IS NO "LEGACY BLOCK SIZE" LIMIT ANYMORE!  Compatibility with old nodes achieved implicitly through how weight is constructed.
313 2017-08-24 19:20:26	0|BlueMatt|praxeology1: these options only effect the type of blocks miners mine, and are currently a maze of confusing
314 2017-08-24 19:20:39	0|sipa|luke-jr: segwit is active, regardless of your preferences, you should assume that rational actors will produce what the rules allow them to
315 2017-08-24 19:20:45	0|achow101|the parameter interaction is defined here: https://github.com/bitcoin/bitcoin/blob/master/src/miner.cpp#L81 for reference
316 2017-08-24 19:20:49	0|luke-jr|sipa: then Bitcoin is dead.
317 2017-08-24 19:20:57	0|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)
318 2017-08-24 19:21:01	0|jnewbery|what, dead again?!
319 2017-08-24 19:21:04	0|gmaxwell|luke-jr: you've failed to address any of the points which I raised against your last rant on this on github.
320 2017-08-24 19:21:04	0|sipa|luke-jr: then Bitcoin is evolving to actually be tested
321 2017-08-24 19:21:25	0|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?
322 2017-08-24 19:21:26	0|kanzure|does 11100 completely encompass the proposed changes
323 2017-08-24 19:21:39	0|BlueMatt|kanzure: I believe so
324 2017-08-24 19:21:39	0|sipa|luke-jr: i'm only interested in a Bitcoin that survives under the assumption that miners act rationally
325 2017-08-24 19:21:48	0|achow101|praxeology1: it has an effect, kind of. it really shouldn't though
326 2017-08-24 19:21:56	0|sipa|luke-jr: and you should too
327 2017-08-24 19:22:03	0|luke-jr|gmaxwell: your "points" depend on assertions that have no evidence at this time, which you are trying to CAUSE to be true
328 2017-08-24 19:22:07	0|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)
329 2017-08-24 19:22:21	0|wumpus|if you think a defaults change kills bitcoin, you're severly underestimating it
330 2017-08-24 19:22:22	0|luke-jr|sipa: incentives are too broken for that to be possible right now
331 2017-08-24 19:22:31	0|luke-jr|sipa: unless "rationally" includes altruism
332 2017-08-24 19:22:31	0|sipa|luke-jr: how so?
333 2017-08-24 19:22:35	0|instagibbs|I motion to move onto a new discussion unless there's some new information to be shared
334 2017-08-24 19:22:41	0|sdaftuar|seconded
335 2017-08-24 19:22:44	0|sipa|seconded
336 2017-08-24 19:22:44	0|wumpus|people are already overriding it on large scale, no one is using that stupid default
337 2017-08-24 19:22:49	0|BlueMatt|ok, other topics?
338 2017-08-24 19:22:57	0|wumpus|#topic 0.15.0 release
339 2017-08-24 19:23:00	0|luke-jr|wumpus: overriding it to 1 MB, not 4 MB
340 2017-08-24 19:23:01	0|BlueMatt|second round of congrats on segwit?
341 2017-08-24 19:23:02	0|morcos|i'm against moving on unless we have agreed to get rid of the option and make an announcement
342 2017-08-24 19:23:13	0|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?
343 2017-08-24 19:23:14	0|BlueMatt|morcos: I think we did
344 2017-08-24 19:23:16	0|morcos|we can't constantly do the wrong thing because luke is willing to argue longer than the rest of us
345 2017-08-24 19:23:20	0|morcos|at some point we must overrrule
346 2017-08-24 19:23:37	0|morcos|with 3 r's
347 2017-08-24 19:23:38	0|luke-jr|morcos: you're the one who wants to do the wrong thing
348 2017-08-24 19:23:40	0|praxeology1|BlueMatt: Congratulations! wahoo!!!! :) :) :) :)
349 2017-08-24 19:23:43	0|BlueMatt|morcos: go ack 11100, I dont think there was any concept objection
350 2017-08-24 19:23:51	0|sdaftuar|luke-jr: he is not "the one" who wants to do what he is suggesting
351 2017-08-24 19:23:54	0|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.
352 2017-08-24 19:23:54	0|sdaftuar|he is one of many
353 2017-08-24 19:24:09	0|BlueMatt|okkkkkk, so 0.15.0
354 2017-08-24 19:24:15	0|instagibbs|reviewing the PR is the action item
355 2017-08-24 19:24:27	0|gmaxwell|s/it/is/
356 2017-08-24 19:24:28	0|wumpus|this is getting really unruly
357 2017-08-24 19:24:38	0|BlueMatt|dooglus finally got some backtraces on #9683, which I think needs to be investigated for 0.15
358 2017-08-24 19:24:42	0|wumpus|I'm going to end this meeting if this continues
359 2017-08-24 19:24:43	0|BlueMatt|also #11126
360 2017-08-24 19:25:13	0|wumpus|any reports of new regressions with rc2?
361 2017-08-24 19:26:08	0|achow101|probably not
362 2017-08-24 19:26:09	0|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
363 2017-08-24 19:26:29	0|BlueMatt|wumpus: well are we gonna release today? I'll take a look at his issues this afternoon :)
364 2017-08-24 19:26:33	0|BlueMatt|i mean I'm not saying hold it up
365 2017-08-24 19:26:41	0|BlueMatt|just make sure its not an obvious "oh, thats broken" kind of thing
366 2017-08-24 19:26:41	0|meshcollider|only issue I've heard with rc2 has been fanquakes gitian issue :)
367 2017-08-24 19:26:43	0|wumpus|11126 is an issue that only affects DEBUG_LOCKORDER in ithe initialization; nothing else is running at that moment
368 2017-08-24 19:26:48	0|wumpus|so it doesn't cause any real issue
369 2017-08-24 19:26:57	0|BlueMatt|ah, ok, i hadnt investigated it significantly
370 2017-08-24 19:27:05	0|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.
371 2017-08-24 19:27:27	0|BlueMatt|hmmmm, looks like dooglus' qt crash is the same one I couldnt debug
372 2017-08-24 19:27:39	0|BlueMatt|i wonder if he's also running qt over X forwarding
373 2017-08-24 19:27:44	0|BlueMatt|that appears to make it more likely
374 2017-08-24 19:27:58	0|jonasschnelli|Seems like a free/alloc race in the table weak loading
375 2017-08-24 19:28:11	0|BlueMatt|it doesnt appear to be harmful, at least, some race in setting the table sort order or something like that
376 2017-08-24 19:28:21	0|jonasschnelli|Could also be a Qt bug
377 2017-08-24 19:28:26	0|BlueMatt|indeed, could be
378 2017-08-24 19:28:37	0|BlueMatt|mine was 9883
379 2017-08-24 19:29:23	0|jonasschnelli|They are related
380 2017-08-24 19:29:47	0|jonasschnelli|setSortingEnabled()
381 2017-08-24 19:29:53	0|jonasschnelli|I'll investigate
382 2017-08-24 19:29:57	0|BlueMatt|thanks
383 2017-08-24 19:29:59	0|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
384 2017-08-24 19:30:05	0|jonasschnelli|If its racy,.. could be due to a large wallet
385 2017-08-24 19:30:10	0|jonasschnelli|(many txns)
386 2017-08-24 19:30:14	0|wumpus|#9883 crashed in the leveldb iter?!
387 2017-08-24 19:30:30	0|BlueMatt|the wallet I saw that on is not so large...maybe 1k txn?
388 2017-08-24 19:30:46	0|wumpus|oh wait, wrong thread, that was just going on at the time
389 2017-08-24 19:30:52	0|jonasschnelli|wumpus: not that I know...  I think it crashes via setSortingEnabled
390 2017-08-24 19:31:05	0|jonasschnelli|QTableView::setSortingEnabled(bool) -> QCollator::QCollator(QLocale const&
391 2017-08-24 19:31:12	0|BlueMatt|dooglus also has some crashes where quick-exit races openssl mutex unlocking....I assume that is an openssl bug or so
392 2017-08-24 19:31:28	0|BlueMatt|its the old mutex-locked-during-destruction crash, though, so not harmful
393 2017-08-24 19:31:31	0|wumpus|jonasschnelli: yes, I see now, that's a more recognizable trace
394 2017-08-24 19:31:32	0|BlueMatt|just a scary warning
395 2017-08-24 19:32:05	0|wumpus|is something outside the GUI thread calling Qt functions perhaps?
396 2017-08-24 19:32:11	0|jonasschnelli|BlueMatt: your 9883, self compiled Qt? What version?
397 2017-08-24 19:32:21	0|BlueMatt|yes...uhhh, sec
398 2017-08-24 19:32:29	0|BlueMatt|wumpus: that was my assumption
399 2017-08-24 19:32:31	0|wumpus|if so, that can explain the crashes with remote X, as well as this
400 2017-08-24 19:32:40	0|BlueMatt|jonasa: qt5 something
401 2017-08-24 19:32:58	0|wumpus|*only* the GUI thread may call Qt GUI functions, the rest should queue signals on the GUI thread
402 2017-08-24 19:33:23	0|wumpus|I haven't seen any violation of that, though
403 2017-08-24 19:33:39	0|jonasschnelli|wumpus: Yeah. But that would very likely show another thread calling a relevant Qt function during the crash
404 2017-08-24 19:33:40	0|jonasschnelli|(which it doesn't)
405 2017-08-24 19:35:28	0|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
406 2017-08-24 19:35:33	0|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
407 2017-08-24 19:35:58	0|wumpus|jonasschnelli: you'd say so, but not necessarily, it could just mess up some internal table state, or even internal X state
408 2017-08-24 19:35:59	0|achow101|wumpus: so, final this week?
409 2017-08-24 19:35:59	0|BlueMatt|(hence the closure of the original bug, may be a qt bug)
410 2017-08-24 19:36:09	0|jonasschnelli|wumpus: Yes. Possible.
411 2017-08-24 19:36:26	0|wumpus|achow101: yes, or second half of september
412 2017-08-24 19:37:36	0|gmaxwell|I would rather have 0.15 out sooner rather than later. so far I haven't seen any clear blockers.
413 2017-08-24 19:37:41	0|wumpus|and I guess we should work on 0.15.1 during coredev
414 2017-08-24 19:37:47	0|BlueMatt|gmaxwell: agreed
415 2017-08-24 19:37:51	0|jonasschnelli|wumpus: Yes. Ideally.
416 2017-08-24 19:37:54	0|wumpus|segwit wallet support etc
417 2017-08-24 19:37:58	0|jonasschnelli|Yes
418 2017-08-24 19:38:10	0|luke-jr|wumpus: maybe tag locally, and delay pushing?
419 2017-08-24 19:38:33	0|wumpus|luke-jr: well it's more complicated, I could possibly push the tag, but I can't upload executables
420 2017-08-24 19:38:50	0|luke-jr|wumpus: there are others who can, right?
421 2017-08-24 19:39:03	0|jonasschnelli|I think wumpus should do it.
422 2017-08-24 19:39:10	0|wumpus|yes, but they'll have to us their own release signing key
423 2017-08-24 19:39:13	0|jonasschnelli|It's just 12 days (max +/-)
424 2017-08-24 19:39:25	0|BlueMatt|luke-jr: no (I mean theoretically we can *give* others access, but I see no reason to do so at this time)
425 2017-08-24 19:39:28	0|achow101|I think we should sign with a differnt release key and see if anyone notices :)
426 2017-08-24 19:39:34	0|meshcollider|yeah wumpus should do it, its not that time critical
427 2017-08-24 19:39:46	0|jonasschnelli|achow101: they will...
428 2017-08-24 19:39:47	0|wumpus|oh people notice, my mail was full after stupping using my personal key for that
429 2017-08-24 19:40:05	0|wumpus|even though it was announced on the mailing lists etc
430 2017-08-24 19:40:47	0|wumpus|anyhow... let's release 0.15.0 soon if possible
431 2017-08-24 19:40:58	0|wumpus|if there's still something you'd like to debug over the weekend I can wait until after that
432 2017-08-24 19:41:00	0|BlueMatt|anyway, so I have no objections to tagging 0.15 this weekend/tomorrow if no other issues come up in that time
433 2017-08-24 19:41:26	0|wumpus|but hearing that cfields's concerns were with local code puts me at ease a bit about 0.15.0 at least :)
434 2017-08-24 19:41:27	0|luke-jr|the lock issue can probably be ignored, I guess?
435 2017-08-24 19:41:43	0|wumpus|luke-jr: not ignored, just fixed on master and next 0.15 branch release
436 2017-08-24 19:41:54	0|luke-jr|sure, that's what I mean. ignored for 0.15.0
437 2017-08-24 19:42:07	0|luke-jr|would be nice to get a test that reproduces it, but I'm not sure how
438 2017-08-24 19:42:08	0|wumpus|well as I understand it there are no threads in flight yet at that point
439 2017-08-24 19:42:19	0|gmaxwell|we understand it, it shouldn't block the release. (it's in init)
440 2017-08-24 19:42:28	0|cfields|wumpus: if that puts you at ease, i should invent some local problems and solve them more often :)
441 2017-08-24 19:42:49	0|meshcollider|😂
442 2017-08-24 19:42:50	0|BlueMatt|lol
443 2017-08-24 19:42:50	0|wumpus|cfields: haha!
444 2017-08-24 19:43:08	0|wumpus|can cfields create an issue even cfields cannot debug
445 2017-08-24 19:43:26	0|cfields|haha
446 2017-08-24 19:43:37	0|wumpus|ok, any other topics?
447 2017-08-24 19:43:46	0|BlueMatt|Segwit is active!
448 2017-08-24 19:44:00	0|sipa|what? how?!
449 2017-08-24 19:44:02	0|wumpus|yeah! we can remove the point 'activate segwit' from the weekly agenda
450 2017-08-24 19:44:11	0|BlueMatt|heh
451 2017-08-24 19:44:13	0|kanzure|i have a topic. it can wait.
452 2017-08-24 19:44:19	0|luke-jr|what is it waiting for?
453 2017-08-24 19:44:26	0|wumpus|ther's only 15 minutes left so don't wait too long
454 2017-08-24 19:44:37	0|kanzure|i am collecting topic ideas for coredev.tech meetup. either pm me with things you want to see or in here.
455 2017-08-24 19:44:46	0|kanzure|and i will publish small document somewhere
456 2017-08-24 19:44:52	0|wumpus|segwit wallet support
457 2017-08-24 19:44:54	0|kanzure|it's not a schedule. just a braindump sorta.
458 2017-08-24 19:44:56	0|kanzure|oh.
459 2017-08-24 19:44:59	0|kanzure|okay added
460 2017-08-24 19:45:54	0|wumpus|(which is very general, probably should be divided up...)
461 2017-08-24 19:46:24	0|jonasschnelli|kanzure: thanks for collecting stuff for the CoreDev.tech in SF!
462 2017-08-24 19:46:41	0|kanzure|sure
463 2017-08-24 19:46:52	0|jnewbery|wumpus: I'd like #11053 to be reopened / reconsidered
464 2017-08-24 19:47:03	0|wumpus|GUI support, bech32 yes/no for this release, etc
465 2017-08-24 19:47:12	0|jnewbery|refactor: Make all #includes relative to project root
466 2017-08-24 19:48:01	0|cfields|jnewbery: +1. I think my concerns there were mistaken for a NACK. I pretty much regret bringing them up.
467 2017-08-24 19:48:12	0|luke-jr|wumpus: eh, at least sending bech32 seems a necessity
468 2017-08-24 19:48:42	0|wumpus|cfields: no, not really, it just made me reconsider whether it's really a good idea
469 2017-08-24 19:48:53	0|wumpus|cfields: ideally we'd clear out src and move everything to subdirs
470 2017-08-24 19:49:03	0|cfields|wumpus: agree with that.
471 2017-08-24 19:49:16	0|wumpus|cfields: on the other hand this doesn't make things worse at least
472 2017-08-24 19:49:32	0|wumpus|cfields: #include "" is severly misused in our source code
473 2017-08-24 19:49:49	0|bitcoin-git|[13bitcoin] 15sipa closed pull request #11128: Make Bitcoin Core compatible with NYA segwit2x (06master...06s2x) 02https://github.com/bitcoin/bitcoin/pull/11128
474 2017-08-24 19:50:17	0|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
475 2017-08-24 19:50:35	0|wumpus|*find it somewhere!*
476 2017-08-24 19:51:49	0|bitcoin-git|[13bitcoin] 15laanwj reopened pull request #11053: refactor: Make all #includes relative to project root (06master...062017_08_includes_absolute) 02https://github.com/bitcoin/bitcoin/pull/11053
477 2017-08-24 19:51:54	0|gmaxwell|12:44:01 < wumpus> yeah! we can remove the point 'activate segwit' from the weekly agenda
478 2017-08-24 19:52:03	0|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
479 2017-08-24 19:52:10	0|gmaxwell|we should also go dig up the wallet improvements we couldn't make without segwit... and start working on them. :)
480 2017-08-24 19:52:14	0|instagibbs|wumpus, oh thought you just implemented those changes just now, haha
481 2017-08-24 19:52:16	0|jnewbery|thanks wumpus
482 2017-08-24 19:52:21	0|gmaxwell|(perhaps see the log of the meeting where we added that item)
483 2017-08-24 19:52:25	0|cfields|wumpus: agreed, i just don't see a ton of benefit in changing something that works
484 2017-08-24 19:52:45	0|cfields|however, if benches show that it's noticibly faster, i'm all for it :)
485 2017-08-24 19:53:14	0|wumpus|cfields: well the current state prevents having files with the same name in multiple places in the tree sanely
486 2017-08-24 19:53:15	0|sipa|cfields: eh, what are you talking about?
487 2017-08-24 19:53:41	0|gmaxwell|how are include paths going to change the speed of anything?
488 2017-08-24 19:53:45	0|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
489 2017-08-24 19:53:53	0|wumpus|gmaxwell: it can reduce the amount of probing the compiler has to do
490 2017-08-24 19:54:08	0|meshcollider|(compile speed not runtime speed)
491 2017-08-24 19:54:13	0|cfields|wumpus made that point ^^ in the PR, i believe
492 2017-08-24 19:54:24	0|gmaxwell|okay, I'll look at the PR then.
493 2017-08-24 19:54:27	0|wumpus|gmaxwell: e.g. including "primitives/primitives.h" in "primitvies/transaction.h" makes it look in primitives/primitives/transaction.h
494 2017-08-24 19:54:43	0|wumpus|gmaxwell: which can affect compile speed in some setups
495 2017-08-24 19:54:49	0|wumpus|gmaxwell: it's not the primary reason for making the change, though
496 2017-08-24 19:55:53	0|BlueMatt|ok, other topics?
497 2017-08-24 19:56:01	0|cfields|anyway, i'm happy to see it reopened
498 2017-08-24 19:56:12	0|luke-jr|how about meeting plans?
499 2017-08-24 19:56:20	0|luke-jr|or should we just discuss that in the dedicated channel later?
500 2017-08-24 19:56:29	0|sipa|yes
501 2017-08-24 19:56:30	0|wumpus|I thin kthe best reason for it is that it makes it immediately clear where to look for a file to developers
502 2017-08-24 19:56:40	0|luke-jr|(specifically, are people sticking around Friday, or leaving as soon as it's over?)
503 2017-08-24 19:56:54	0|BlueMatt|luke-jr: dedicated channel, i think
504 2017-08-24 19:57:11	0|wumpus|instead of eh, it's included with "", is it in the current dir? no? oh maybe it's under src/ directly
505 2017-08-24 19:57:39	0|meshcollider|which channel is that?
506 2017-08-24 19:58:06	0|kanzure|#bitcoin-core-dev
507 2017-08-24 19:58:25	0|jonasschnelli|##
508 2017-08-24 19:58:58	0|kanzure|i didn't say what you thought i said
509 2017-08-24 19:59:30	0|kanzure|luke-jr: anyway there's enough people local to the area that you'll find friendlies even if the visitors leave.
510 2017-08-24 19:59:30	0|meshcollider|I guess there's some sort of filtering happening yae
511 2017-08-24 20:00:09	0|wumpus|and that concludes the meeting, thanks everyone
512 2017-08-24 20:00:12	0|lightningbot|Meeting ended Thu Aug 24 20:00:11 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
513 2017-08-24 20:00:12	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-08-24-19.01.html
514 2017-08-24 20:00:12	0|wumpus|#endmeeting
515 2017-08-24 20:00:13	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-08-24-19.01.log.html
516 2017-08-24 20:00:13	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-08-24-19.01.txt
517 2017-08-24 20:00:33	0|wumpus|we can back to shouting at each other about default values now :)
518 2017-08-24 20:01:34	0|morcos|well re: the shouting, i think there is time to argue on github about the changes for next release
519 2017-08-24 20:01:48	0|morcos|what i'm more interested in is letting miners know what they need to do
520 2017-08-24 20:02:12	0|kanzure|chaos branch?
521 2017-08-24 20:02:20	0|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.
522 2017-08-24 20:02:40	0|cfields|morcos: let's forego some of the arguments and s/what they need to do/what their options are/ :)
523 2017-08-24 20:03:02	0|morcos|well i think the only option that has a legitimate chance of getting approved is something that says
524 2017-08-24 20:03:37	0|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.
525 2017-08-24 20:03:39	0|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
526 2017-08-24 20:03:59	0|cfields|morcos: yes, exactly.
527 2017-08-24 20:04:05	0|wumpus|BlueMatt: luckily that's never going to work, most PRs conflict with a few other PRs :)
528 2017-08-24 20:04:22	0|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..
529 2017-08-24 20:04:35	0|BlueMatt|wumpus: merge at random until the only remaining ones conflict, then resolve conflicts at random until it compiles :p
530 2017-08-24 20:05:10	0|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?)
531 2017-08-24 20:05:20	0|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.
532 2017-08-24 20:05:35	0|kanzure|well that's an interesting argument.
533 2017-08-24 20:05:35	0|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
534 2017-08-24 20:05:39	0|gmaxwell|luke-jr: we do, stop syncing the whole history, and only sync the last year worth or whatever.
535 2017-08-24 20:05:59	0|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
536 2017-08-24 20:06:07	0|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?
537 2017-08-24 20:06:15	0|kanzure|gmaxwell: ok then what about argument about limiting IBD until utxo commitment sync stuff
538 2017-08-24 20:06:17	0|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.
539 2017-08-24 20:06:27	0|luke-jr|morcos: yes, I think we shouldn't recommend things that harm Bitcoin.
540 2017-08-24 20:06:39	0|kanzure|well i think IBD concerns weren't about validation cost, mostly bandwidth over the interwebs
541 2017-08-24 20:06:41	0|morcos|i don't think my statement recommended anything
542 2017-08-24 20:07:05	0|kanzure|sorry, i mean, those specific IBD concerns
543 2017-08-24 20:07:06	0|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.
544 2017-08-24 20:07:09	0|luke-jr|gmaxwell: we aren't only getting witness size increases with Segwit..
545 2017-08-24 20:07:20	0|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"
546 2017-08-24 20:07:32	0|sipa|luke-jr: the worst case I/O effect of a block has not changed at all with SegWit
547 2017-08-24 20:07:36	0|cfields|luke-jr: if bitcoin is as fickle as a default setting, the value of that setting isn't the issue...
548 2017-08-24 20:07:44	0|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
549 2017-08-24 20:07:47	0|sipa|luke-jr: the average just got closer to the worst case, which is a good thing
550 2017-08-24 20:08:02	0|gmaxwell|luke-jr: moreover the thing you're insisting on (maxsize) doesn't correlate with those IO costs well.
551 2017-08-24 20:08:03	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/affe9271aa49...4ae6d0fbef60
552 2017-08-24 20:08:04	0|bitcoin-git|13bitcoin/06master 14b23549f 15John Newbery: [tests] add TestNodeCLI class for calling bitcoin-cli for a node
553 2017-08-24 20:08:04	0|bitcoin-git|13bitcoin/06master 14c6ec435 15John Newbery: [tests] Add bitcoin_cli.py test script
554 2017-08-24 20:08:05	0|bitcoin-git|13bitcoin/06master 144ae6d0f 15MarcoFalke: Merge #10798: [tests] [utils] test bitcoin-cli...
555 2017-08-24 20:08:17	0|luke-jr|cfields: all the more reason we should make the default something advisable (or nothing at all)
556 2017-08-24 20:08:19	0|kanzure|surely it was bandwidth not IO concern?
557 2017-08-24 20:08:28	0|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 ?
558 2017-08-24 20:08:29	0|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)
559 2017-08-24 20:08:30	0|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.
560 2017-08-24 20:08:32	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #10798: [tests] [utils] test bitcoin-cli (06master...06cli_tests) 02https://github.com/bitcoin/bitcoin/pull/10798
561 2017-08-24 20:08:34	0|morcos|maybe i'll just do that
562 2017-08-24 20:08:50	0|gmaxwell|kanzure: read faster. For a lot of systems they are _not_ bandwidth limited in IBD.
563 2017-08-24 20:09:03	0|kanzure|but is that luke's concern?
564 2017-08-24 20:09:06	0|gmaxwell|kanzure: they're chainstate IO limited, etc.
565 2017-08-24 20:09:49	0|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
566 2017-08-24 20:11:37	0|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.
567 2017-08-24 20:12:01	0|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.
568 2017-08-24 20:12:11	0|luke-jr|gmaxwell: only if other miners set that
569 2017-08-24 20:12:21	0|luke-jr|no miners right now AFAIK set 4/4
570 2017-08-24 20:13:08	0|gmaxwell|luke-jr: no, you'll still miss out on what you could have earned even if no one else sets it.
571 2017-08-24 20:13:09	0|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
572 2017-08-24 20:13:21	0|gmaxwell|which is why expecting people to set it some other way is unrealistic and has simply failed in the past.
573 2017-08-24 20:13:30	0|luke-jr|gmaxwell: you have a probability to get it next block of yours
574 2017-08-24 20:14:10	0|luke-jr|gmaxwell: do you disagree with #3229 ?
575 2017-08-24 20:14:34	0|luke-jr|(it was originally shot down by Hearn and Garzik)
576 2017-08-24 20:15:19	0|gmaxwell|I think it's phenominally dumb but better than the current behavior. (not really much of an endorsement)
577 2017-08-24 20:15:45	0|luke-jr|sigh
578 2017-08-24 20:17:02	0|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
579 2017-08-24 20:17:42	0|gmaxwell|I don't think these things should be configurable at all.
580 2017-08-24 20:17:51	0|gmaxwell|it's harmful to the network to have discrepencies.
581 2017-08-24 20:18:12	0|gmaxwell|Do we have a setting to set a maximum number of 1-bits in a seralized block. No.
582 2017-08-24 20:18:27	0|gmaxwell|Would we support such a setting if someone asked for one, ... almost certantly not.
583 2017-08-24 20:18:45	0|gmaxwell|discrepancies*
584 2017-08-24 20:19:04	0|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)
585 2017-08-24 20:19:16	0|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)
586 2017-08-24 20:19:19	0|wumpus|we wouldn't add it, but if we had such an option since the beginning, then removing it would still be difficult
587 2017-08-24 20:19:41	0|luke-jr|size does matter though
588 2017-08-24 20:20:01	0|sipa|luke-jr: yes, a bit
589 2017-08-24 20:20:03	0|luke-jr|at the very least, there is the clear case of the blocksonly node
590 2017-08-24 20:20:07	0|sipa|so do many other things
591 2017-08-24 20:20:43	0|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.
592 2017-08-24 20:20:57	0|gmaxwell|luke-jr: what about the blocksonly node?
593 2017-08-24 20:21:17	0|luke-jr|gmaxwell: its bandwidth requirement is primarily affected by the block sizes
594 2017-08-24 20:21:19	0|gmaxwell|luke-jr: it matters a small bit yes, but other things matter a lot more.
595 2017-08-24 20:21:55	0|sipa|luke-jr: let's work on compressed blocks then
596 2017-08-24 20:22:27	0|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.
597 2017-08-24 20:22:36	0|luke-jr|compressed blocks are going to make 100% year-over-year improvements? :/
598 2017-08-24 20:23:11	0|praxeology1|True or false... 0.14.2 nodes by default currently limit the weight to 4M?
599 2017-08-24 20:23:25	0|sipa|praxeology1: to 3M
600 2017-08-24 20:23:34	0|sipa|praxeology1: for mining, that is
601 2017-08-24 20:23:42	0|sipa|the consensus rules are obviously not configurable
602 2017-08-24 20:23:44	0|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.
603 2017-08-24 20:23:52	0|luke-jr|gmaxwell: it's not a trick
604 2017-08-24 20:24:02	0|wumpus|tip: you can see the default for every option with bitcoind --help
605 2017-08-24 20:24:10	0|praxeology1|sipa: yea I am talking about consensus rules, not what miners create by default
606 2017-08-24 20:24:51	0|sipa|praxeology1: that's entirely offtopic
607 2017-08-24 20:24:57	0|sipa|and irrelevant here
608 2017-08-24 20:25:01	0|wumpus|praxeology1: huh, then you shouldn't ask 'by default'
609 2017-08-24 20:25:24	0|luke-jr|praxeology1: the consensus rule is max weight of 4M.
610 2017-08-24 20:25:29	0|gmaxwell|wumpus: elsewhere he's suffering the "but if miners set things higher they'll produce invalid blocks" confusion.
611 2017-08-24 20:25:40	0|wumpus|(unless you mean this in the extremely twisted sense of 'without source code changes'? )
612 2017-08-24 20:25:52	0|sipa|praxeology1: the weight, which is defined as 3*witsize + basesize must be less than 4M
613 2017-08-24 20:26:04	0|sipa|praxeology1: that implies that basesize must be less than 1M
614 2017-08-24 20:26:23	0|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
615 2017-08-24 20:26:36	0|sipa|praxeology1: we're only talking about the mining code
616 2017-08-24 20:26:40	0|gmaxwell|sipa: don't use witsize as your variable. sounds like the size of the witnesses.
617 2017-08-24 20:26:50	0|sipa|-blockmaxsize and -blockmaxweight control the size of blocks the mining code produce
618 2017-08-24 20:27:04	0|sipa|but the mining code will never ever produce a consensus-invalid block, regardless of settings
619 2017-08-24 20:27:06	0|gmaxwell|praxeology1: consensus rules are not configurable because that would be extremely negligant, incompetent, and pointless.
620 2017-08-24 20:27:22	0|gmaxwell|negligent*
621 2017-08-24 20:27:42	0|BlueMatt|eg https://eprint.iacr.org/2017/686.pdf (as to why making consensus limits configurable is an astoundingly stupid idea)
622 2017-08-24 20:27:42	0|morcos|sipa: i think you got your formula wrong there
623 2017-08-24 20:27:50	0|gmaxwell|or 16123123
624 2017-08-24 20:27:58	0|gmaxwell|morcos: by witsize he means the total size of the block.
625 2017-08-24 20:28:05	0|morcos|oh
626 2017-08-24 20:28:15	0|gmaxwell|he should have said 3*size + stripped size.
627 2017-08-24 20:28:20	0|sipa|sorry, by witsize i meant "size including witnesses"
628 2017-08-24 20:28:23	0|morcos|isn't that still wrong
629 2017-08-24 20:28:31	0|sipa|yes.
630 2017-08-24 20:28:38	0|luke-jr|(3 * stripped size) + size
631 2017-08-24 20:28:43	0|morcos|thanks luke
632 2017-08-24 20:28:50	0|gmaxwell|derp.
633 2017-08-24 20:28:53	0|gmaxwell|yea.
634 2017-08-24 20:29:06	0|morcos|i can't wait to read r/btc tonight
635 2017-08-24 20:29:32	0|luke-jr|I'm thinking of unsub'ing r/btc
636 2017-08-24 20:29:55	0|BlueMatt|lol, you're just *now* thinking of that?
637 2017-08-24 20:30:09	0|luke-jr|tbf, not just now. ;)
638 2017-08-24 20:32:04	0|clarkmoody|gmaxwell sipa Can you guys look at https://github.com/bitcoin/bips/pull/553 ?
639 2017-08-24 20:32:53	0|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)
640 2017-08-24 20:49:33	0|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?
641 2017-08-24 20:51:04	0|praxeology1|maintaining such a data structure w/ no block height delay on the hash... sounds hard
642 2017-08-24 20:54:03	0|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
643 2017-08-24 20:57:32	0|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.
644 2017-08-24 20:59:39	0|sipa|praxeology1: our database already supports snapshotting
645 2017-08-24 21:00:10	0|sipa|so make a snapshot, then process that snaoshot in the background into a compact utxo representation, and continue with normal procoessing
646 2017-08-24 21:00:16	0|sipa|and yes, periodically
647 2017-08-24 21:01:15	0|praxeology1|sounds good to me
648 2017-08-24 21:02:36	0|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
649 2017-08-24 21:03:10	0|sipa|yes
650 2017-08-24 21:06:05	0|praxeology1|Hopefully also some automated process for people to generate these utxo hashes, and communicate them over insecure networks
651 2017-08-24 21:06:56	0|praxeology1|Or is there talk bout making it a commitment?
652 2017-08-24 21:09:05	0|praxeology1|*trying to get a feel for the core dev's current position on this... thinking it might be a touchy subject
653 2017-08-24 21:09:18	0|sipa|i think it's gettingna bit offtopic here
654 2017-08-24 21:10:19	0|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
655 2017-08-24 21:13:48	0|bitcoin-git|[13bitcoin] 15MarcoFalke opened pull request #11129: [qa] util: Poll cookie file size before reading (06master...06Mf1708-qaPollCookie) 02https://github.com/bitcoin/bitcoin/pull/11129
656 2017-08-24 21:14:00	0|praxeology1|Where would it be on topic?
657 2017-08-24 21:17:21	0|sipa|mailing list
658 2017-08-24 21:17:54	0|sipa|or bitcoin-wizards
659 2017-08-24 21:34:35	0|bitcoin-git|13bitcoin/06master 14cd0ea48 15Matt Corallo: Changing -txindex requires -reindex, not -reindex-chainstate
660 2017-08-24 21:34:35	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/4ae6d0fbef60...77fc469fc78c
661 2017-08-24 21:34:36	0|bitcoin-git|13bitcoin/06master 1477fc469 15MarcoFalke: Merge #11108: Changing -txindex requires -reindex, not -reindex-chainstate...
662 2017-08-24 21:35:10	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #11108: Changing -txindex requires -reindex, not -reindex-chainstate (06master...062017-08-fix-reindex-txindex-err) 02https://github.com/bitcoin/bitcoin/pull/11108
663 2017-08-24 21:48:24	0|bitcoin-git|[13bitcoin] 15jtimon closed pull request #9271: There's two types of flags: consensus and script (06master...060.13-consensus-flags-error) 02https://github.com/bitcoin/bitcoin/pull/9271
664 2017-08-24 22:27:33	0|meshcollider|8:21 am <sipa> luke-jr: let's work on compressed blocks then
665 2017-08-24 22:27:33	0|meshcollider|What's the current to-do for them?
666 2017-08-24 22:28:36	0|sipa|morcos: designing, experimenting, implementating :)
667 2017-08-24 22:28:45	0|sipa|s/morcos/meshcollider/
668 2017-08-24 22:29:11	0|luke-jr|it's too bad the UTXO set doesn't store the absolute output index in the blockchain
669 2017-08-24 22:29:43	0|sipa|luke-jr: it's easy enough to add if that's needed
670 2017-08-24 22:29:54	0|luke-jr|sipa: wouldn't it require a re-sync for all pruned nodes?
671 2017-08-24 22:30:04	0|luke-jr|otoh, maybe there's some way to do a gradual upgrade..?
672 2017-08-24 22:33:17	0|meshcollider|sipa: doesn't BIP 152 cover at least the design step? Or is it still being thought out
673 2017-08-24 22:33:30	0|sipa|meshcollider: bip152 is completely unrelated
674 2017-08-24 22:33:42	0|sipa|meshcollider: we're just talking about an efficient encoding for transactions
675 2017-08-24 22:33:57	0|sipa|luke-jr: if you really mean absolute index, yes
676 2017-08-24 22:34:16	0|sipa|hmm, even for relative index in the block
677 2017-08-24 22:34:24	0|luke-jr|relative index isn't quite as useful
678 2017-08-24 22:34:32	0|luke-jr|I was thinking have all the inputs just address by index
679 2017-08-24 22:35:02	0|meshcollider|Oh am I confusing compressed blocks with compact blocks
680 2017-08-24 22:35:18	0|luke-jr|I suppose relative index in the sense of "<this tx abs index> - <relative index> = <input's TXO abs index>" might be good
681 2017-08-24 22:35:28	0|luke-jr|might make varint more optimal
682 2017-08-24 22:35:49	0|gmaxwell|luke-jr: I can't figure out what you're talking about.
683 2017-08-24 22:35:58	0|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
684 2017-08-24 22:36:11	0|luke-jr|gmaxwell: replace the input txid+index with an absolute tx index in the blockchain
685 2017-08-24 22:36:47	0|gmaxwell|how does that have anything to do with the utxo set?
686 2017-08-24 22:37:01	0|luke-jr|you'd need to store/index by the absolute tx index to do the lookup
687 2017-08-24 22:37:30	0|luke-jr|saying blockchain tx #1934 isn't useful unless the node can easily figure out what tx that is
688 2017-08-24 22:37:34	0|luke-jr|utxo*
689 2017-08-24 22:37:36	0|gmaxwell|I think what you're trying to suggest is this: make a transfered block smaller by rekeying its inputs with indexes.
690 2017-08-24 22:37:48	0|sipa|luke-jr: i think needing a UTXO set in order to just decompress a block is already a no-go
691 2017-08-24 22:37:59	0|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.
692 2017-08-24 22:38:09	0|sipa|luke-jr: as that means an attacker can make you do arbitrarily much I/O before you can figure out PoW
693 2017-08-24 22:38:17	0|gmaxwell|but as sipa is pointing out it would be a layering mess.
694 2017-08-24 22:38:21	0|sipa|s/figure out/validate/
695 2017-08-24 22:38:28	0|luke-jr|hm
696 2017-08-24 22:39:06	0|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.
697 2017-08-24 22:39:45	0|gmaxwell|yes, there is a lot more savings if you could replace txin hashes with indexes, but ... layering mess.
698 2017-08-24 22:40:08	0|luke-jr|what if we add a commitment to the index-based format?
699 2017-08-24 22:40:44	0|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.
700 2017-08-24 22:41:43	0|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)
701 2017-08-24 22:42:38	0|meshcollider|gmaxwell: is your serialisation format posted anywhere? Sorry I'm just catching up
702 2017-08-24 22:43:40	0|gmaxwell|meshcollider: yes, but sipa's revised version is better and I don't think thats posted anywhere.
703 2017-08-24 22:44:38	0|sipa|https://gist.github.com/sipa/1d29c1019e00874a61e533b2b050046f
704 2017-08-24 22:44:52	0|sipa|very much WIP
705 2017-08-24 22:50:03	0|morcos|damn, i skipped down to Analysis
706 2017-08-24 22:53:03	0|sipa|haha
707 2017-08-24 22:55:29	0|jimpo|I'm looking into writing a P2P test for this: https://github.com/bitcoin/bitcoin/pull/11113
708 2017-08-24 22:55:46	0|jimpo|What's the best way from the test framework to fast-forward time or create blocks in the future
709 2017-08-24 22:56:17	0|jimpo|or start the chain with blocks far in the past would work too
710 2017-08-24 23:06:45	0|jimpo|nvm, I found the setmocktime method
711 2017-08-24 23:27:51	0|gmaxwell|morcos: IIRC sipa's version is ~28% size reduction for the history.