1 2017-08-24T00:00:49  *** abpa has quit IRC
  2 2017-08-24T00:07:50  *** Dyaheon has quit IRC
  3 2017-08-24T00:08:09  *** Dyaheon has joined #bitcoin-core-dev
  4 2017-08-24T00:09:28  *** Murch has joined #bitcoin-core-dev
  5 2017-08-24T00:19:28  *** Zimbo has joined #bitcoin-core-dev
  6 2017-08-24T00:27:50  *** Aaronvan_ is now known as AaronvanW
  7 2017-08-24T00:30:20  *** Zimbo has quit IRC
  8 2017-08-24T00:41:53  *** Murch has quit IRC
  9 2017-08-24T00:42:22  *** Murch has joined #bitcoin-core-dev
 10 2017-08-24T00:44:00  *** Chris_St1 has joined #bitcoin-core-dev
 11 2017-08-24T00:48:32  *** jimpo has quit IRC
 12 2017-08-24T00:51:56  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 13 2017-08-24T00:52:16  *** Chris_St1 has quit IRC
 14 2017-08-24T01:07:07  *** Aaronvan_ has joined #bitcoin-core-dev
 15 2017-08-24T01:08:20  *** AaronvanW has quit IRC
 16 2017-08-24T01:08:58  *** Murch has quit IRC
 17 2017-08-24T01:10:59  *** Aaronvan_ is now known as AaronvanW
 18 2017-08-24T01:13:44  *** dabura667 has joined #bitcoin-core-dev
 19 2017-08-24T01:14:08  *** treebeardd has joined #bitcoin-core-dev
 20 2017-08-24T01:29:04  *** Chris_Stewart_5 has quit IRC
 21 2017-08-24T01:38:16  *** Murch has joined #bitcoin-core-dev
 22 2017-08-24T01:47:12  <meshcollider> is there any style preference for atomic_bool vs atomic<bool> and similar for other atomic types?
 23 2017-08-24T01:47:24  <meshcollider> Its not mentioned in the style guidelines
 24 2017-08-24T01:50:02  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 25 2017-08-24T01:59:30  *** cluelessperson has quit IRC
 26 2017-08-24T01:59:33  *** gmaxwell has quit IRC
 27 2017-08-24T02:09:13  *** Aaronvan_ has joined #bitcoin-core-dev
 28 2017-08-24T02:09:14  *** gmaxwell has joined #bitcoin-core-dev
 29 2017-08-24T02:09:42  *** lrvick has joined #bitcoin-core-dev
 30 2017-08-24T02:10:15  *** Aaronva__ has joined #bitcoin-core-dev
 31 2017-08-24T02:10:42  *** AaronvanW has quit IRC
 32 2017-08-24T02:12:51  <BlueMatt> meshcollider: not atm, I dont believe
 33 2017-08-24T02:13:26  <meshcollider> ok sweet as
 34 2017-08-24T02:13:52  *** Aaronvan_ has quit IRC
 35 2017-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
 36 2017-08-24T02:18:30  <cfields> (i'm pretty sure i haven't even been consistent with my own preference though)
 37 2017-08-24T02:18:55  *** mryandao has joined #bitcoin-core-dev
 38 2017-08-24T02:22:22  *** ula has quit IRC
 39 2017-08-24T02:22:25  *** Chris_Stewart_5 has quit IRC
 40 2017-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
 41 2017-08-24T02:31:16  <cfields> i don't really mind either way
 42 2017-08-24T02:57:54  *** Guest71977 has joined #bitcoin-core-dev
 43 2017-08-24T03:01:06  <achow101> happy segwit activation
 44 2017-08-24T03:02:44  *** cluelessperson has joined #bitcoin-core-dev
 45 2017-08-24T03:02:44  *** cluelessperson has joined #bitcoin-core-dev
 46 2017-08-24T03:05:03  <BlueMatt> indeed it is
 47 2017-08-24T03:30:27  *** goatpig has quit IRC
 48 2017-08-24T03:30:44  *** Bluewolf33 has quit IRC
 49 2017-08-24T03:32:27  *** Dyaheon has quit IRC
 50 2017-08-24T03:32:53  *** Dyaheon has joined #bitcoin-core-dev
 51 2017-08-24T03:34:51  *** Aaronva__ has quit IRC
 52 2017-08-24T03:37:26  *** Guest71977 has quit IRC
 53 2017-08-24T03:42:29  *** treebeardd has quit IRC
 54 2017-08-24T04:06:20  *** fanquake has joined #bitcoin-core-dev
 55 2017-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.
 56 2017-08-24T04:09:57  *** Murch has quit IRC
 57 2017-08-24T04:17:29  *** Murch has joined #bitcoin-core-dev
 58 2017-08-24T04:22:00  <gmaxwell> w
 59 2017-08-24T04:42:58  *** treebeardd has joined #bitcoin-core-dev
 60 2017-08-24T05:17:45  *** Bluewolf33 has joined #bitcoin-core-dev
 61 2017-08-24T05:28:08  <wumpus> fanquake: for rc2? no, haven't heard issues reported
 62 2017-08-24T05:29:49  <gmaxwell> wumpus: someone on reddit was saying it was segfaulting for them, I prodded them to open an issue.
 63 2017-08-24T05:29:53  <fanquake> wumpus yes rc2. Had no issues with rc1.
 64 2017-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.
 65 2017-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.
 66 2017-08-24T05:34:16  <meshcollider> ah in that case should i drop the commit to change them from my PR?
 67 2017-08-24T05:34:17  <meshcollider> https://github.com/bitcoin/bitcoin/pull/11107/commits/f334f44bad5a78978f714148b799cea6e12a525f
 68 2017-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
 69 2017-08-24T05:35:22  <wumpus> yes, no need to make a rule about it, it doesn't affect safety
 70 2017-08-24T05:35:33  *** arowser has quit IRC
 71 2017-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
 72 2017-08-24T05:36:24  *** Dyaheon has quit IRC
 73 2017-08-24T05:36:58  *** arowser has joined #bitcoin-core-dev
 74 2017-08-24T05:37:03  *** Dyaheon has joined #bitcoin-core-dev
 75 2017-08-24T05:37:20  <meshcollider> removed
 76 2017-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
 77 2017-08-24T05:40:16  <wumpus> then some things like consistent variable naming which are reasonably important to be able to distinguish various scopes
 78 2017-08-24T05:42:16  <wumpus> btw has anyone tried cross-compiling bitcoin core for windows from ubuntu zesty/17.04 or pre-.10
 79 2017-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
 80 2017-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?
 81 2017-08-24T05:51:48  <sipa> wumpus: agree, for many things it really doesn't matter what approach is used
 82 2017-08-24T05:52:18  <fanquake> wumpus my win-unsigned sigs match yours. Will PR them in a sec.
 83 2017-08-24T05:52:39  *** laurentmt has joined #bitcoin-core-dev
 84 2017-08-24T05:53:13  *** laurentmt has quit IRC
 85 2017-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.
 86 2017-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
 87 2017-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 :)
 88 2017-08-24T05:58:54  <luke-jr> wumpus: sure, just saying, if he doesn't answer, it's probably made-up
 89 2017-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
 90 2017-08-24T06:02:18  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/8858b6ddd3bc...00ada17230f7
 91 2017-08-24T06:02:18  <bitcoin-git> bitcoin/master fa14b67 MarcoFalke: [doc] build-windows: Mention that only trusty works
 92 2017-08-24T06:02:19  <bitcoin-git> bitcoin/master 00ada17 Wladimir J. van der Laan: Merge #11119: [doc] build-windows: Mention that only trusty works...
 93 2017-08-24T06:02:28  <fanquake> wumpus opened a PR at the gitian sigs repo if you want to compare sigs.
 94 2017-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
 95 2017-08-24T06:03:02  *** marcoagner has quit IRC
 96 2017-08-24T06:05:25  <wumpus> fanquake: all ok
 97 2017-08-24T06:09:58  *** marcoagner has joined #bitcoin-core-dev
 98 2017-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
 99 2017-08-24T06:15:02  <wumpus> PE checksum is the same, Calculated message digest : 73AAB82BB3761BE13A9DC0ACAC0BD35AC51C48DC matches in my case though
100 2017-08-24T06:18:17  *** JackH has joined #bitcoin-core-dev
101 2017-08-24T06:18:18  *** JackH has quit IRC
102 2017-08-24T06:18:44  *** JackH has joined #bitcoin-core-dev
103 2017-08-24T06:20:20  <wumpus> however your input file's sha256sum af3da01beda391e06f2fb4d2dced316b580f989b71ee886582aaddac5c00374f for bitcoin-0.15.0-win64-setup-unsigned.exe matches
104 2017-08-24T06:21:06  <wumpus> some faulty case of caching maybe?
105 2017-08-24T06:21:43  <fanquake> wumpus not sure. I'm re-running the windows build now.
106 2017-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?)
107 2017-08-24T06:33:21  *** Murch has quit IRC
108 2017-08-24T06:33:34  *** jl2012 has joined #bitcoin-core-dev
109 2017-08-24T06:36:12  <fanquake> wumpus it should have been the right one. Will check shortly as it will still be in /inputs
110 2017-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
111 2017-08-24T06:46:24  *** treebeardd has quit IRC
112 2017-08-24T06:48:10  *** Deacyded has quit IRC
113 2017-08-24T06:54:25  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/00ada17230f7...affe9271aa49
114 2017-08-24T06:54:25  <bitcoin-git> bitcoin/master 79191f5 Joe Harvell: Add option -stdinrpcpass to allow RPC password to be read from standard input
115 2017-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...
116 2017-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
117 2017-08-24T06:55:23  *** SopaXorzTaker has joined #bitcoin-core-dev
118 2017-08-24T06:56:11  *** jannes has joined #bitcoin-core-dev
119 2017-08-24T06:56:34  *** eck has quit IRC
120 2017-08-24T06:57:42  *** alreadylate has joined #bitcoin-core-dev
121 2017-08-24T06:58:42  *** BashCo has quit IRC
122 2017-08-24T06:59:03  *** eck has joined #bitcoin-core-dev
123 2017-08-24T07:02:11  *** eck has quit IRC
124 2017-08-24T07:02:11  *** eck has joined #bitcoin-core-dev
125 2017-08-24T07:02:22  *** ghost43 has quit IRC
126 2017-08-24T07:02:36  *** ghost43 has joined #bitcoin-core-dev
127 2017-08-24T07:08:23  *** alreadylate has quit IRC
128 2017-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
129 2017-08-24T07:19:20  *** BashCo has joined #bitcoin-core-dev
130 2017-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
131 2017-08-24T07:22:04  *** jtimon has quit IRC
132 2017-08-24T07:52:05  *** Alina-malina has quit IRC
133 2017-08-24T07:52:45  *** alreadylate has joined #bitcoin-core-dev
134 2017-08-24T07:55:04  *** Alina-malina has joined #bitcoin-core-dev
135 2017-08-24T08:13:29  *** ghost43 has quit IRC
136 2017-08-24T08:13:45  *** ghost43 has joined #bitcoin-core-dev
137 2017-08-24T08:15:01  *** jonasa has quit IRC
138 2017-08-24T08:35:01  *** d9b4bef9 has quit IRC
139 2017-08-24T08:35:20  *** Deacyde has joined #bitcoin-core-dev
140 2017-08-24T08:36:08  *** d9b4bef9 has joined #bitcoin-core-dev
141 2017-08-24T08:49:20  *** Deacydal has joined #bitcoin-core-dev
142 2017-08-24T08:51:07  *** Deacyde has quit IRC
143 2017-08-24T08:54:28  *** Deacydal has quit IRC
144 2017-08-24T08:54:29  *** Deacyde has joined #bitcoin-core-dev
145 2017-08-24T08:57:42  *** Dyaheon has quit IRC
146 2017-08-24T08:58:51  *** Dyaheon has joined #bitcoin-core-dev
147 2017-08-24T09:10:41  *** justan0theruser has quit IRC
148 2017-08-24T09:20:01  *** fanquake has quit IRC
149 2017-08-24T09:23:05  *** fanquake has joined #bitcoin-core-dev
150 2017-08-24T10:02:58  *** fanquake1 has joined #bitcoin-core-dev
151 2017-08-24T10:03:45  *** fanquake has quit IRC
152 2017-08-24T10:06:54  *** dabura667 has quit IRC
153 2017-08-24T10:14:46  *** JackH has quit IRC
154 2017-08-24T10:22:33  *** laurentmt has joined #bitcoin-core-dev
155 2017-08-24T10:22:54  *** laurentmt has quit IRC
156 2017-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?
157 2017-08-24T10:51:26  <meshcollider> (unrelated to the issue fanquake was having btw)
158 2017-08-24T11:14:45  *** tiagotrs has joined #bitcoin-core-dev
159 2017-08-24T11:15:03  *** tonikt has joined #bitcoin-core-dev
160 2017-08-24T11:15:16  *** tonikt has left #bitcoin-core-dev
161 2017-08-24T11:41:20  *** Dyaheon has quit IRC
162 2017-08-24T11:42:28  *** Dyaheon has joined #bitcoin-core-dev
163 2017-08-24T11:49:21  *** AaronvanW has joined #bitcoin-core-dev
164 2017-08-24T11:50:49  *** jtimon has joined #bitcoin-core-dev
165 2017-08-24T11:56:33  *** laurentmt has joined #bitcoin-core-dev
166 2017-08-24T12:01:22  *** laurentmt has quit IRC
167 2017-08-24T12:09:56  *** goatpig has joined #bitcoin-core-dev
168 2017-08-24T12:16:03  *** Alina-malina has quit IRC
169 2017-08-24T12:16:03  *** Alina-malina has joined #bitcoin-core-dev
170 2017-08-24T12:26:57  *** Evel-Knievel has quit IRC
171 2017-08-24T12:28:30  *** Evel-Knievel has joined #bitcoin-core-dev
172 2017-08-24T12:40:06  <michagogo> meshcollider: looks like the former script exports an env variable to use that device
173 2017-08-24T12:40:19  <michagogo> The latter*
174 2017-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)
175 2017-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?
176 2017-08-24T12:46:00  <instagibbs> GAit, looks like a "normal" failure: assert wait_until(lambda: len(self.nodes[1].getrawmempool()) == 5)
177 2017-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.
178 2017-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.
179 2017-08-24T12:56:06  <fanquake1> GAit I restarted the tests
180 2017-08-24T13:00:16  *** Chris_Stewart_5 has joined #bitcoin-core-dev
181 2017-08-24T13:00:42  <jnewbery> fanquake1 - I was just looking at the Travis output and it disappeared under my feet :(
182 2017-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
183 2017-08-24T13:02:41  *** Deacydal has joined #bitcoin-core-dev
184 2017-08-24T13:04:46  *** ghost43 has quit IRC
185 2017-08-24T13:06:22  *** Deacyde has quit IRC
186 2017-08-24T13:06:30  *** ghost43 has joined #bitcoin-core-dev
187 2017-08-24T13:07:19  <instagibbs> GAit, it means that it appears to be related to your changes, or maybe you got unlucky
188 2017-08-24T13:09:16  <fanquake1> jnewbery sorry. Looks like the same two have failed anyways.
189 2017-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.
190 2017-08-24T13:10:43  *** Giszmo has joined #bitcoin-core-dev
191 2017-08-24T13:11:43  <GAit> jnewbery: seems we get the same failure, but only on some builders
192 2017-08-24T13:13:22  <jnewbery> ok, I'll try to reproduce locally
193 2017-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)
194 2017-08-24T13:17:26  <jnewbery> Try rebasing on master and changing the `assert wait_until()`s to `wait_until()`s
195 2017-08-24T13:19:23  *** Guyver2 has joined #bitcoin-core-dev
196 2017-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?
197 2017-08-24T13:22:35  *** Chris_Stewart_5 has quit IRC
198 2017-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
199 2017-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
200 2017-08-24T13:25:42  <jnewbery> if you merge or rebase locally and then test I expect it'll fail in the same way
201 2017-08-24T13:25:49  *** Chris_Stewart_5 has joined #bitcoin-core-dev
202 2017-08-24T13:25:58  *** Bluewolf33 has quit IRC
203 2017-08-24T13:26:16  *** Bluewolf33 has joined #bitcoin-core-dev
204 2017-08-24T13:26:39  <jnewbery> And yes, probably a good idea to squash at this point
205 2017-08-24T13:28:53  <GAit> thanks! i thought i was crazy :) indeed fails locally now, will fix and squash
206 2017-08-24T13:31:15  <jnewbery> GAit: no problem. I'll re-review once you've pushed
207 2017-08-24T13:34:07  *** Cheeseo has joined #bitcoin-core-dev
208 2017-08-24T13:35:10  <GAit> jnewbery: done but i'd wait for travis before reviewing
209 2017-08-24T13:35:33  *** alreadylate has quit IRC
210 2017-08-24T13:39:42  *** justanotheruser has joined #bitcoin-core-dev
211 2017-08-24T13:39:45  *** promag has joined #bitcoin-core-dev
212 2017-08-24T13:40:19  <promag> jnewbery: do you think travis should merge with master and then run the tests?
213 2017-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
214 2017-08-24T13:44:33  *** Dyaheon has quit IRC
215 2017-08-24T13:45:29  <GAit> i guess is better to fail earlier rather merge day but it was confusing for me
216 2017-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.
217 2017-08-24T13:47:36  *** Dyaheon has joined #bitcoin-core-dev
218 2017-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?
219 2017-08-24T13:49:53  <promag> usually unless you point the diff between the old and new commit.
220 2017-08-24T13:59:41  *** Giszmo has quit IRC
221 2017-08-24T14:01:19  <instagibbs> wish github had gitlab feature of "diff since last push"
222 2017-08-24T14:07:01  *** promag has quit IRC
223 2017-08-24T14:07:57  *** Evel-Knievel has quit IRC
224 2017-08-24T14:09:13  *** Evel-Knievel has joined #bitcoin-core-dev
225 2017-08-24T14:10:48  *** promag has joined #bitcoin-core-dev
226 2017-08-24T14:15:17  *** promag has joined #bitcoin-core-dev
227 2017-08-24T14:20:25  *** promag has quit IRC
228 2017-08-24T14:20:36  *** jonasa has joined #bitcoin-core-dev
229 2017-08-24T14:28:31  *** promag has joined #bitcoin-core-dev
230 2017-08-24T14:30:47  *** fanquake1 has quit IRC
231 2017-08-24T14:32:08  <GAit> jnewbery: i like what you are doing in #11121
232 2017-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 :)
233 2017-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?
234 2017-08-24T14:37:05  *** tiagotrs has quit IRC
235 2017-08-24T14:44:25  <GAit> mempool_persist seems to work fine locally without the sleeps (and 3 whole seconds faster!)
236 2017-08-24T14:45:28  *** promag has quit IRC
237 2017-08-24T14:50:40  *** Aaronvan_ has joined #bitcoin-core-dev
238 2017-08-24T14:50:48  *** AaronvanW has quit IRC
239 2017-08-24T15:09:27  <jnewbery> GAit - yes there are probably sleeps that can be removed
240 2017-08-24T15:13:18  *** promag has joined #bitcoin-core-dev
241 2017-08-24T15:13:47  *** tiagotrs has joined #bitcoin-core-dev
242 2017-08-24T15:14:38  *** promag has quit IRC
243 2017-08-24T15:15:38  *** tiagotrs has quit IRC
244 2017-08-24T15:15:38  *** tiagotrs has joined #bitcoin-core-dev
245 2017-08-24T15:34:56  *** SopaXorzTaker has quit IRC
246 2017-08-24T15:38:45  *** Murch has joined #bitcoin-core-dev
247 2017-08-24T15:39:08  <MarcoFalke> Indeed, we should remove all sleeps other than for explicit polling
248 2017-08-24T15:40:09  *** promag has joined #bitcoin-core-dev
249 2017-08-24T15:50:50  *** SopaXorzTaker has joined #bitcoin-core-dev
250 2017-08-24T15:51:11  *** promag has joined #bitcoin-core-dev
251 2017-08-24T15:51:37  *** Dyaheon has quit IRC
252 2017-08-24T15:52:46  *** promag has quit IRC
253 2017-08-24T15:53:22  *** btcdrak has joined #bitcoin-core-dev
254 2017-08-24T15:55:17  *** Dyaheon has joined #bitcoin-core-dev
255 2017-08-24T16:03:44  *** Dizzle has joined #bitcoin-core-dev
256 2017-08-24T16:07:07  *** chjj has quit IRC
257 2017-08-24T16:07:14  *** promag has joined #bitcoin-core-dev
258 2017-08-24T16:13:07  *** Dizzle has quit IRC
259 2017-08-24T16:16:57  *** tiagotrs has quit IRC
260 2017-08-24T16:18:51  *** Giszmo has joined #bitcoin-core-dev
261 2017-08-24T16:20:29  *** chjj has joined #bitcoin-core-dev
262 2017-08-24T16:21:31  *** Dizzle has joined #bitcoin-core-dev
263 2017-08-24T16:23:42  *** abpa has joined #bitcoin-core-dev
264 2017-08-24T16:36:27  *** adrh has joined #bitcoin-core-dev
265 2017-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
266 2017-08-24T16:39:46  <adrh> here is my script: https://pastebin.com/fESuZDvz
267 2017-08-24T16:41:10  <adrh> it works to list my address, but i can't make sendtoaddress work
268 2017-08-24T16:45:07  *** BashCo has quit IRC
269 2017-08-24T16:48:15  *** tiagotrs has joined #bitcoin-core-dev
270 2017-08-24T16:48:24  *** gwillen has joined #bitcoin-core-dev
271 2017-08-24T16:50:44  <adrh> anyone ?
272 2017-08-24T16:54:02  <instagibbs> adrh, try #bitcoin
273 2017-08-24T16:54:50  <adrh> i tried . nobody can help me there at the moment
274 2017-08-24T17:02:31  *** BashCo has joined #bitcoin-core-dev
275 2017-08-24T17:03:06  <instagibbs> sorry, off topic here
276 2017-08-24T17:03:15  *** alreadylate has joined #bitcoin-core-dev
277 2017-08-24T17:04:31  <adrh> i dont know where to ask to be honest. i'm trying for 8 hours to make it work...
278 2017-08-24T17:04:56  *** jimpo has joined #bitcoin-core-dev
279 2017-08-24T17:05:05  *** alreadylate has quit IRC
280 2017-08-24T17:21:21  *** adrh has quit IRC
281 2017-08-24T17:22:44  <luke-jr> I seem to have a reproducable crash at startup with rc2 on testnet
282 2017-08-24T17:23:34  <gmaxwell> luke-jr: whats the backtrace
283 2017-08-24T17:23:42  <luke-jr> getting it
284 2017-08-24T17:25:27  <luke-jr> http://codepad.org/aiVTgE08
285 2017-08-24T17:25:58  <luke-jr> lock order issue, so probably wouldn't affect prod bins
286 2017-08-24T17:28:24  <gmaxwell> what did the lockorder debugging print
287 2017-08-24T17:29:51  <luke-jr> it's in the pastebin
288 2017-08-24T17:30:55  <luke-jr> I don't understand how the walletdb.cpp lock is still in the lock order here
289 2017-08-24T17:44:00  <ryanofsky> probably the easiest way to fix this is to just change LoadWallet LOCK(wallet) to a LOCK2(main, wallet)
290 2017-08-24T17:44:19  <BlueMatt> ryanofsky: that feels strange...maybe cs_main in CreateWalletFromFile in wallet.cpp instead?
291 2017-08-24T17:44:24  <luke-jr> ryanofsky: do you understand the problem? why is walletdb's lock relevant here?
292 2017-08-24T17:44:26  <BlueMatt> taking cs_main inside of walletdb is...yuck
293 2017-08-24T17:44:33  <BlueMatt> luke-jr: cause its a lock inversion
294 2017-08-24T17:44:45  <BlueMatt> walletdb takes the wallet lock, so...lock inversion?
295 2017-08-24T17:44:47  <luke-jr> BlueMatt: but walletdb's lock is released before we get to the wallet lock?
296 2017-08-24T17:44:53  <BlueMatt> no it isnt
297 2017-08-24T17:44:59  <BlueMatt> ReadKeyValue calls back into wallet
298 2017-08-24T17:45:44  *** chjj has quit IRC
299 2017-08-24T17:46:16  <luke-jr> BlueMatt: to ReacceptWalletTransactions?
300 2017-08-24T17:46:18  <luke-jr> how?
301 2017-08-24T17:46:35  <MarcoFalke> wumpus: Mind to create a gitian.docs under bitcoin-core?
302 2017-08-24T17:46:45  <BlueMatt> luke-jr: yes
303 2017-08-24T17:46:47  <BlueMatt> LoadToWallet
304 2017-08-24T17:46:54  <MarcoFalke> You wanted me to write a fedora guide for it
305 2017-08-24T17:47:48  <luke-jr> BlueMatt: that doesn't call Reaccept
306 2017-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
307 2017-08-24T17:48:39  <promag> jnewbery: ^ as soon as you can? ty!
308 2017-08-24T17:49:11  <wumpus> MarcoFalke: you want a repo specifically for gitian docs?
309 2017-08-24T17:49:28  <BlueMatt> luke-jr: the conflict is MarkConflicted, not Reaccept
310 2017-08-24T17:49:46  * luke-jr peers at his editor
311 2017-08-24T17:50:35  <luke-jr> oh, the backtrace was in Reaccept
312 2017-08-24T17:50:37  <MarcoFalke> jup, they don't really belong in the main repo
313 2017-08-24T17:50:49  <MarcoFalke> Also, a GitHub wiki is not suitable
314 2017-08-24T17:51:22  <MarcoFalke> It is either open to be edited by anyone (with a GitHub account) or effectively none
315 2017-08-24T17:52:21  *** harding has joined #bitcoin-core-dev
316 2017-08-24T17:54:57  *** Aaronvan_ is now known as AaronvanW
317 2017-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?
318 2017-08-24T17:58:04  *** jimpo has quit IRC
319 2017-08-24T17:58:26  <luke-jr> wumpus: +1
320 2017-08-24T17:58:37  *** chjj has joined #bitcoin-core-dev
321 2017-08-24T17:58:38  * luke-jr wonders how to make a test that would pick up on this wallet lock issue
322 2017-08-24T17:58:55  <luke-jr> if (prevtx.nIndex == -1 && !prevtx.hashUnset()) { <-- this line needs a comment :/
323 2017-08-24T17:58:55  <MarcoFalke> wumpus: Fine with me
324 2017-08-24T17:59:09  <wumpus> MarcoFalke: ok
325 2017-08-24T17:59:21  <luke-jr> otoh, gitian docs may be unversioned, whereas other docs might be versioned?
326 2017-08-24T18:00:42  <wumpus> nah, all documentation tends to be about the newest versions
327 2017-08-24T18:01:01  <wumpus> could add sections for building older versions
328 2017-08-24T18:01:06  *** oooo has joined #bitcoin-core-dev
329 2017-08-24T18:01:08  <luke-jr> wumpus: I just mean, it makes sense to tag docs per release, but not gitian docs necessarily
330 2017-08-24T18:01:23  *** ghost43 has quit IRC
331 2017-08-24T18:01:24  <wumpus> I'd prefer not to do any tagging/brancing in the docs repo
332 2017-08-24T18:01:50  <wumpus> document change control tends to be very diffrent from source code
333 2017-08-24T18:01:54  <luke-jr> wumpus: so we keep release-specific docs with the main repo?
334 2017-08-24T18:02:15  *** jimpo has joined #bitcoin-core-dev
335 2017-08-24T18:02:17  <wumpus> yes, there are no plans to move anythingbesides the gitian building doc at this point
336 2017-08-24T18:02:52  <luke-jr> i c
337 2017-08-24T18:06:21  *** ghost43 has joined #bitcoin-core-dev
338 2017-08-24T18:08:30  *** oooo has quit IRC
339 2017-08-24T18:09:04  <wumpus> MarcoFalke: https://github.com/bitcoin-core/docs.git
340 2017-08-24T18:09:14  <MarcoFalke> ty
341 2017-08-24T18:09:48  <wumpus> you should have push access, we can add other maintainers later
342 2017-08-24T18:14:52  *** jimpo has quit IRC
343 2017-08-24T18:15:58  *** abpa has quit IRC
344 2017-08-24T18:19:35  <cfields> sipa: do you have local work on top of #11117? Anything I can help with there?
345 2017-08-24T18:22:00  *** Veseli_Zagorec has joined #bitcoin-core-dev
346 2017-08-24T18:22:28  *** ghost43 has quit IRC
347 2017-08-24T18:23:09  <sipa> cfields: nope
348 2017-08-24T18:23:12  *** ghost43 has joined #bitcoin-core-dev
349 2017-08-24T18:23:18  <sipa> but i don't expect it to be much
350 2017-08-24T18:24:22  *** jimpo has joined #bitcoin-core-dev
351 2017-08-24T18:27:27  <cfields> ok. let me know if there's anything i can help with without stepping on your toes
352 2017-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
353 2017-08-24T18:45:05  *** tiagotrs has quit IRC
354 2017-08-24T18:48:40  *** Veseli_Zagorec has quit IRC
355 2017-08-24T18:58:16  *** clarkmoody has quit IRC
356 2017-08-24T18:59:58  *** clarkmoody has joined #bitcoin-core-dev
357 2017-08-24T19:00:00  <sipa> WOOSH
358 2017-08-24T19:00:26  *** praxeology1 has joined #bitcoin-core-dev
359 2017-08-24T19:00:37  <sipa> meetingh?
360 2017-08-24T19:00:46  <jonasschnelli> \o/
361 2017-08-24T19:01:20  *** Guest79199 has joined #bitcoin-core-dev
362 2017-08-24T19:01:28  *** chjj has quit IRC
363 2017-08-24T19:01:45  <wumpus> #startmeeting
364 2017-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.
365 2017-08-24T19:01:45  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
366 2017-08-24T19:01:53  <gmaxwell> wumpus: you have the best nameping.
367 2017-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
368 2017-08-24T19:02:17  <kanzure> hi.
369 2017-08-24T19:02:18  <achow101> hi
370 2017-08-24T19:02:32  <BlueMatt> happy segwit everyone
371 2017-08-24T19:02:51  <sipa> short topic: thanks and congrats everyone with SegWit... it seems it activated on the network without a glitch
372 2017-08-24T19:02:57  <wumpus> yes, congratulations everyone!
373 2017-08-24T19:03:03  <jonasschnelli> wohoo!
374 2017-08-24T19:03:06  <achow101> yay!
375 2017-08-24T19:03:10  <cfields> hi
376 2017-08-24T19:03:14  <wumpus> it took lots of time, and lots of sweat, but we did it
377 2017-08-24T19:03:36  <kanzure> whole bitcoin community did it
378 2017-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.
379 2017-08-24T19:03:59  <sipa> gmaxwell: everything on its time
380 2017-08-24T19:04:00  <luke-jr> s/glitch/good thing/
381 2017-08-24T19:04:06  <sipa> misconceptions are hard to fix
382 2017-08-24T19:04:07  <gmaxwell> You may well have jinxed us, since things blowing up might only happen with a >1MB block. :)
383 2017-08-24T19:04:10  <BlueMatt> yes, some miner appear to be confused by maxblocksize/maxblockweight options, we need #11100
384 2017-08-24T19:04:11  <wumpus> we should probably publicize some segwit miner's faq thing
385 2017-08-24T19:04:14  <wumpus> on bitcoincore.org
386 2017-08-24T19:04:26  <achow101> wumpus: isn't there already one?
387 2017-08-24T19:04:28  <luke-jr> wumpus: not if they don't encourage big blocks. :/
388 2017-08-24T19:04:32  <luke-jr> err, not if they do*
389 2017-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.
390 2017-08-24T19:04:48  <wumpus> achow101: there is a segwit faq but it doesn't include this
391 2017-08-24T19:04:49  *** Dyaheon has quit IRC
392 2017-08-24T19:04:51  <achow101> https://bitcoincore.org/en/2016/10/27/segwit-upgrade-guide/#miners
393 2017-08-24T19:05:02  <achow101> not really an faq I guess
394 2017-08-24T19:05:36  <gmaxwell> achow101: says nothing about needing to remove the maxblocksize setting and setting maxblockweight=4000000
395 2017-08-24T19:05:48  <luke-jr> there is no such need, nor is it good for them to do so
396 2017-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.
397 2017-08-24T19:06:30  <wumpus> kanzure: +1
398 2017-08-24T19:06:55  <harding> Is there anything else that should go into a current segwit faq for miners?
399 2017-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
400 2017-08-24T19:07:12  <kanzure> sounds like there's some requests for a post-activation faq
401 2017-08-24T19:07:18  <wumpus> #topic segwit faq for miners
402 2017-08-24T19:07:23  <luke-jr> hm, I thought we had documented it before, but I can't find it
403 2017-08-24T19:07:31  *** Dyaheon has joined #bitcoin-core-dev
404 2017-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?)
405 2017-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.
406 2017-08-24T19:08:05  *** Dizzle has quit IRC
407 2017-08-24T19:08:06  <wumpus> not sure if there's any other ones, have there been any other frequent questions about segwit by miners?
408 2017-08-24T19:08:22  <luke-jr> BlueMatt: size is often the bottleneck today, so it makes sense to limit by size
409 2017-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. :(
410 2017-08-24T19:08:37  <BlueMatt> luke-jr: ok, then gbt clients can do so
411 2017-08-24T19:08:56  <gmaxwell> luke-jr: size is a bottleneck in _what_?
412 2017-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
413 2017-08-24T19:09:19  <luke-jr> gmaxwell: IBD mainly at this point I guess
414 2017-08-24T19:09:22  <BlueMatt> that option needs to die
415 2017-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
416 2017-08-24T19:09:38  <sipa> *constrained
417 2017-08-24T19:09:39  <achow101> luke-jr: IBD is too late to save already
418 2017-08-24T19:09:42  <luke-jr> sipa: blocksonly?
419 2017-08-24T19:09:43  <gmaxwell> luke-jr: not for anyone with an internet connection beyond a few megabits in speed.
420 2017-08-24T19:10:24  <gmaxwell> luke-jr: IBD time is limited by chainstate database operations for parties that aren't totally network starved.
421 2017-08-24T19:10:24  <luke-jr> achow101: it's nothing like as bad as it could be
422 2017-08-24T19:10:41  <cfields> i've seen a ton of questions about segwit and "the addresses that start with a 3"...
423 2017-08-24T19:10:50  <kanzure> ya i have seen mostly non-miner questions
424 2017-08-24T19:10:51  <BlueMatt> anyway, so aside from luke is there anyone who objects generally to removing -maxblocksize? (ala #11100)
425 2017-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
426 2017-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
427 2017-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 :/
428 2017-08-24T19:11:14  <kanzure> we can also copy-paste old segwit faq details anyway
429 2017-08-24T19:11:17  <kanzure> (or link to them)
430 2017-08-24T19:11:20  <sipa> luke-jr: prune
431 2017-08-24T19:11:27  <luke-jr> sipa: that doesn't eliminate IBD
432 2017-08-24T19:11:29  <wumpus> 'take the option away and the problem goes away' is a bit too simplistic at this point
433 2017-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...
434 2017-08-24T19:11:43  <BlueMatt> ehh, deprecates it
435 2017-08-24T19:11:51  <BlueMatt> and clearly states blockmaxsize is deprecated
436 2017-08-24T19:12:00  <BlueMatt> which roughly aligns with the expectation of everyone i spoke to
437 2017-08-24T19:12:06  <luke-jr> 11100 is stupid.
438 2017-08-24T19:12:13  <BlueMatt> there was confusion as to why blockmaxsize still existed in the context of segwit
439 2017-08-24T19:12:16  <meshcollider> deprecating makes sense to me
440 2017-08-24T19:12:30  <morcos> even i have trouble keeping up with what the interaction of these different options is
441 2017-08-24T19:12:41  <kanzure> needs an interaction matrix visualization
442 2017-08-24T19:12:52  *** chjj has joined #bitcoin-core-dev
443 2017-08-24T19:12:52  <kanzure> where the cells indicate interaction :-)
444 2017-08-24T19:12:53  <morcos> we need to move towards getting rid of blockmaxsize, its confusion for no benefit....
445 2017-08-24T19:12:55  <achow101> is blockmaxsize taken into consideration with segwit or just ignored?
446 2017-08-24T19:13:01  <sipa> achow101: it is!
447 2017-08-24T19:13:04  <wumpus> deprecation is likely a good idea on the longer run, but not a fix to the misunderstanding created
448 2017-08-24T19:13:05  <instagibbs> taken into account
449 2017-08-24T19:13:15  <gmaxwell> achow101: it does something stupid, it truncates block construction when you reach that size.
450 2017-08-24T19:13:19  <achow101> bleh :/
451 2017-08-24T19:13:33  <luke-jr> it does what it's supposed to do
452 2017-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.
453 2017-08-24T19:13:57  <morcos> wait a second
454 2017-08-24T19:13:57  *** jimpo has quit IRC
455 2017-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
456 2017-08-24T19:14:07  <luke-jr> gmaxwell: you're rewriting history now
457 2017-08-24T19:14:12  <BlueMatt> deprecation is, itself, documentation
458 2017-08-24T19:14:17  <wumpus> BlueMatt: but we're already in the screwed state that those options exist
459 2017-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
460 2017-08-24T19:14:32  <morcos> isn't the default infinity?
461 2017-08-24T19:14:44  <sdaftuar> morcos: no, i don't think so.
462 2017-08-24T19:14:45  <sipa> morcos: i honestly don't know anymore
463 2017-08-24T19:14:49  <achow101> morcos: how so?
464 2017-08-24T19:14:50  <morcos> if you don't set blockmaxsize it doesn't even calculate it
465 2017-08-24T19:15:05  <gmaxwell> morcos: the default is 1/4 the configured weight which defaults to 3m.
466 2017-08-24T19:15:06  <sdaftuar> if you set nothing, you get a 750k default, i believe.  and a 3M weight max.
467 2017-08-24T19:15:07  <wumpus> I'm fine with marking it as deprecated anyhow
468 2017-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
469 2017-08-24T19:15:18  <sdaftuar> if you set just blockmaxweight, then blockmaxsize is effectively infinity, i think.
470 2017-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
471 2017-08-24T19:15:29  <gmaxwell> sdaftuar: right.
472 2017-08-24T19:15:35  <sipa> if you set only one of them, the other is taken as infinity
473 2017-08-24T19:15:41  <gmaxwell> oh jesus.
474 2017-08-24T19:15:43  <sipa> if you set both, both are enforced independently
475 2017-08-24T19:15:43  <sdaftuar> but blockmaxsize is absurd, it should be removed.
476 2017-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?
477 2017-08-24T19:15:52  <morcos> that doesn't seem right to me
478 2017-08-24T19:16:03  <sipa> morcos: i believe that is correct
479 2017-08-24T19:16:08  <instagibbs> morcos, pretty sure that's correct
480 2017-08-24T19:16:09  <sdaftuar> correct, you are capped at 750kb
481 2017-08-24T19:16:09  <gmaxwell> That is correct.
482 2017-08-24T19:16:18  <meshcollider> if you set blockmaxsize then blockmaxweight becomes blockmaxsize * WITNESS_SCALE_FACTOR doesn't it?
483 2017-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
484 2017-08-24T19:16:20  <instagibbs> all miners have cranked up to 1MB
485 2017-08-24T19:16:20  <morcos> ugh, we should never have released it in this state
486 2017-08-24T19:16:41  <sdaftuar> +1
487 2017-08-24T19:16:53  <sipa> yes
488 2017-08-24T19:17:03  <wumpus> but we're there anyhow, what now?
489 2017-08-24T19:17:14  <gmaxwell> instagibbs: which now means a cranking down to 1MB. :(
490 2017-08-24T19:17:27  <sdaftuar> wumpus: we should remove it and deprecate the command line option
491 2017-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
492 2017-08-24T19:17:37  <sdaftuar> as we indicated we may do in the future in the 0.13 release notes, iirc
493 2017-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.
494 2017-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.
495 2017-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.
496 2017-08-24T19:17:47  *** abpa has joined #bitcoin-core-dev
497 2017-08-24T19:17:50  <luke-jr> morcos: absolutely not
498 2017-08-24T19:18:02  <jtimon> BlueMatt: ack on removing blockmaxsize and leaving only maxblockweight
499 2017-08-24T19:18:02  <gmaxwell> Luke is faulty.
500 2017-08-24T19:18:14  <wumpus> luke-jr: so they can still choose to do that with that option removed, right?
501 2017-08-24T19:18:25  <wumpus> luke-jr: e.g. by setting the blockmaxweight lower?
502 2017-08-24T19:18:33  <sdaftuar> or by using the gbt results and truncating themselves
503 2017-08-24T19:18:35  <BlueMatt> anyway, so it sounds like #11100
504 2017-08-24T19:18:38  <wumpus> that doesn't need two options
505 2017-08-24T19:18:39  <luke-jr> wumpus: not effectively
506 2017-08-24T19:18:48  <sdaftuar> luke-jr: why not?
507 2017-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
508 2017-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
509 2017-08-24T19:18:56  <wumpus> the complication here is having two options that interact in a complicated way
510 2017-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?
511 2017-08-24T19:19:03  <wumpus> please don't confuse it with what the value should be
512 2017-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.
513 2017-08-24T19:19:12  <sipa> luke-jr: i'm sorry to hear you disagree about that point, but that ship has sailed
514 2017-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
515 2017-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
516 2017-08-24T19:19:29  <jnewbery> Concept ACK 11100
517 2017-08-24T19:19:37  <gmaxwell> praxeology1: oh jesus christ you're also confused
518 2017-08-24T19:19:58  <wumpus> yes, that sounds confused
519 2017-08-24T19:19:58  <luke-jr> sipa: that ship has not sailed. that's not an argument.
520 2017-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.
521 2017-08-24T19:20:25  <BlueMatt> praxeology1: these options only effect the type of blocks miners mine, and are currently a maze of confusing
522 2017-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
523 2017-08-24T19:20:44  <achow101> the parameter interaction is defined here: https://github.com/bitcoin/bitcoin/blob/master/src/miner.cpp#L81 for reference
524 2017-08-24T19:20:49  <luke-jr> sipa: then Bitcoin is dead.
525 2017-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)
526 2017-08-24T19:21:00  <jnewbery> what, dead again?!
527 2017-08-24T19:21:03  <sipa> luke-jr: then Bitcoin is evolving to actually be tested
528 2017-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.
529 2017-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?
530 2017-08-24T19:21:25  <kanzure> does 11100 completely encompass the proposed changes
531 2017-08-24T19:21:38  <BlueMatt> kanzure: I believe so
532 2017-08-24T19:21:38  <sipa> luke-jr: i'm only interested in a Bitcoin that survives under the assumption that miners act rationally
533 2017-08-24T19:21:47  <achow101> praxeology1: it has an effect, kind of. it really shouldn't though
534 2017-08-24T19:21:55  <sipa> luke-jr: and you should too
535 2017-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
536 2017-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)
537 2017-08-24T19:22:20  <wumpus> if you think a defaults change kills bitcoin, you're severly underestimating it
538 2017-08-24T19:22:22  <luke-jr> sipa: incentives are too broken for that to be possible right now
539 2017-08-24T19:22:30  <sipa> luke-jr: how so?
540 2017-08-24T19:22:30  <luke-jr> sipa: unless "rationally" includes altruism
541 2017-08-24T19:22:34  <instagibbs> I motion to move onto a new discussion unless there's some new information to be shared
542 2017-08-24T19:22:40  <sdaftuar> seconded
543 2017-08-24T19:22:43  <wumpus> people are already overriding it on large scale, no one is using that stupid default
544 2017-08-24T19:22:44  <sipa> seconded
545 2017-08-24T19:22:48  <BlueMatt> ok, other topics?
546 2017-08-24T19:22:57  <wumpus> #topic 0.15.0 release
547 2017-08-24T19:22:59  <luke-jr> wumpus: overriding it to 1 MB, not 4 MB
548 2017-08-24T19:23:00  <BlueMatt> second round of congrats on segwit?
549 2017-08-24T19:23:01  <morcos> i'm against moving on unless we have agreed to get rid of the option and make an announcement
550 2017-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?
551 2017-08-24T19:23:13  <BlueMatt> morcos: I think we did
552 2017-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
553 2017-08-24T19:23:19  <morcos> at some point we must overrrule
554 2017-08-24T19:23:36  <morcos> with 3 r's
555 2017-08-24T19:23:37  <luke-jr> morcos: you're the one who wants to do the wrong thing
556 2017-08-24T19:23:39  <praxeology1> BlueMatt: Congratulations! wahoo!!!! :) :) :) :)
557 2017-08-24T19:23:44  <BlueMatt> morcos: go ack 11100, I dont think there was any concept objection
558 2017-08-24T19:23:50  <sdaftuar> luke-jr: he is not "the one" who wants to do what he is suggesting
559 2017-08-24T19:23:53  <sdaftuar> he is one of many
560 2017-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.
561 2017-08-24T19:24:08  <BlueMatt> okkkkkk, so 0.15.0
562 2017-08-24T19:24:14  <instagibbs> reviewing the PR is the action item
563 2017-08-24T19:24:26  <gmaxwell> s/it/is/
564 2017-08-24T19:24:27  <wumpus> this is getting really unruly
565 2017-08-24T19:24:37  <BlueMatt> dooglus finally got some backtraces on #9683, which I think needs to be investigated for 0.15
566 2017-08-24T19:24:41  <wumpus> I'm going to end this meeting if this continues
567 2017-08-24T19:24:42  <BlueMatt> also #11126
568 2017-08-24T19:25:12  <wumpus> any reports of new regressions with rc2?
569 2017-08-24T19:26:07  <achow101> probably not
570 2017-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
571 2017-08-24T19:26:28  <BlueMatt> wumpus: well are we gonna release today? I'll take a look at his issues this afternoon :)
572 2017-08-24T19:26:32  <BlueMatt> i mean I'm not saying hold it up
573 2017-08-24T19:26:39  <meshcollider> only issue I've heard with rc2 has been fanquakes gitian issue :)
574 2017-08-24T19:26:40  <BlueMatt> just make sure its not an obvious "oh, thats broken" kind of thing
575 2017-08-24T19:26:43  <wumpus> 11126 is an issue that only affects DEBUG_LOCKORDER in ithe initialization; nothing else is running at that moment
576 2017-08-24T19:26:47  <wumpus> so it doesn't cause any real issue
577 2017-08-24T19:26:57  <BlueMatt> ah, ok, i hadnt investigated it significantly
578 2017-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.
579 2017-08-24T19:27:26  <BlueMatt> hmmmm, looks like dooglus' qt crash is the same one I couldnt debug
580 2017-08-24T19:27:38  <BlueMatt> i wonder if he's also running qt over X forwarding
581 2017-08-24T19:27:43  <BlueMatt> that appears to make it more likely
582 2017-08-24T19:27:57  <jonasschnelli> Seems like a free/alloc race in the table weak loading
583 2017-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
584 2017-08-24T19:28:20  <jonasschnelli> Could also be a Qt bug
585 2017-08-24T19:28:25  <BlueMatt> indeed, could be
586 2017-08-24T19:28:36  <BlueMatt> mine was 9883
587 2017-08-24T19:29:22  <jonasschnelli> They are related
588 2017-08-24T19:29:46  <jonasschnelli> setSortingEnabled()
589 2017-08-24T19:29:52  <jonasschnelli> I'll investigate
590 2017-08-24T19:29:56  <BlueMatt> thanks
591 2017-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
592 2017-08-24T19:30:04  <jonasschnelli> If its racy,.. could be due to a large wallet
593 2017-08-24T19:30:10  <jonasschnelli> (many txns)
594 2017-08-24T19:30:13  <wumpus> #9883 crashed in the leveldb iter?!
595 2017-08-24T19:30:29  <BlueMatt> the wallet I saw that on is not so large...maybe 1k txn?
596 2017-08-24T19:30:46  <wumpus> oh wait, wrong thread, that was just going on at the time
597 2017-08-24T19:30:52  <jonasschnelli> wumpus: not that I know...  I think it crashes via setSortingEnabled
598 2017-08-24T19:31:04  <jonasschnelli> QTableView::setSortingEnabled(bool) -> QCollator::QCollator(QLocale const&
599 2017-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
600 2017-08-24T19:31:22  *** bitstein has joined #bitcoin-core-dev
601 2017-08-24T19:31:27  <BlueMatt> its the old mutex-locked-during-destruction crash, though, so not harmful
602 2017-08-24T19:31:30  <wumpus> jonasschnelli: yes, I see now, that's a more recognizable trace
603 2017-08-24T19:31:31  <BlueMatt> just a scary warning
604 2017-08-24T19:32:04  <wumpus> is something outside the GUI thread calling Qt functions perhaps?
605 2017-08-24T19:32:10  <jonasschnelli> BlueMatt: your 9883, self compiled Qt? What version?
606 2017-08-24T19:32:20  <BlueMatt> yes...uhhh, sec
607 2017-08-24T19:32:28  <BlueMatt> wumpus: that was my assumption
608 2017-08-24T19:32:31  <wumpus> if so, that can explain the crashes with remote X, as well as this
609 2017-08-24T19:32:39  <BlueMatt> jonasa: qt5 something
610 2017-08-24T19:32:57  <wumpus> *only* the GUI thread may call Qt GUI functions, the rest should queue signals on the GUI thread
611 2017-08-24T19:33:22  <wumpus> I haven't seen any violation of that, though
612 2017-08-24T19:33:27  *** promag has quit IRC
613 2017-08-24T19:33:29  *** jimmysong__ is now known as jimmysong
614 2017-08-24T19:33:38  <jonasschnelli> wumpus: Yeah. But that would very likely show another thread calling a relevant Qt function during the crash
615 2017-08-24T19:33:39  <jonasschnelli> (which it doesn't)
616 2017-08-24T19:35:14  *** ekerstein has joined #bitcoin-core-dev
617 2017-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
618 2017-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
619 2017-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
620 2017-08-24T19:35:58  <BlueMatt> (hence the closure of the original bug, may be a qt bug)
621 2017-08-24T19:35:58  <achow101> wumpus: so, final this week?
622 2017-08-24T19:36:08  <jonasschnelli> wumpus: Yes. Possible.
623 2017-08-24T19:36:26  <wumpus> achow101: yes, or second half of september
624 2017-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.
625 2017-08-24T19:37:41  <wumpus> and I guess we should work on 0.15.1 during coredev
626 2017-08-24T19:37:46  <BlueMatt> gmaxwell: agreed
627 2017-08-24T19:37:50  <jonasschnelli> wumpus: Yes. Ideally.
628 2017-08-24T19:37:53  <wumpus> segwit wallet support etc
629 2017-08-24T19:37:57  <jonasschnelli> Yes
630 2017-08-24T19:38:09  <luke-jr> wumpus: maybe tag locally, and delay pushing?
631 2017-08-24T19:38:33  <wumpus> luke-jr: well it's more complicated, I could possibly push the tag, but I can't upload executables
632 2017-08-24T19:38:49  <luke-jr> wumpus: there are others who can, right?
633 2017-08-24T19:38:58  *** promag has joined #bitcoin-core-dev
634 2017-08-24T19:39:02  <jonasschnelli> I think wumpus should do it.
635 2017-08-24T19:39:09  <wumpus> yes, but they'll have to us their own release signing key
636 2017-08-24T19:39:12  <jonasschnelli> It's just 12 days (max +/-)
637 2017-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)
638 2017-08-24T19:39:27  <achow101> I think we should sign with a differnt release key and see if anyone notices :)
639 2017-08-24T19:39:32  <meshcollider> yeah wumpus should do it, its not that time critical
640 2017-08-24T19:39:45  <jonasschnelli> achow101: they will...
641 2017-08-24T19:39:45  * luke-jr shrugs
642 2017-08-24T19:39:46  <wumpus> oh people notice, my mail was full after stupping using my personal key for that
643 2017-08-24T19:40:04  <wumpus> even though it was announced on the mailing lists etc
644 2017-08-24T19:40:47  <wumpus> anyhow... let's release 0.15.0 soon if possible
645 2017-08-24T19:40:57  <wumpus> if there's still something you'd like to debug over the weekend I can wait until after that
646 2017-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
647 2017-08-24T19:41:14  *** promag has quit IRC
648 2017-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 :)
649 2017-08-24T19:41:26  <luke-jr> the lock issue can probably be ignored, I guess?
650 2017-08-24T19:41:43  <wumpus> luke-jr: not ignored, just fixed on master and next 0.15 branch release
651 2017-08-24T19:41:53  <luke-jr> sure, that's what I mean. ignored for 0.15.0
652 2017-08-24T19:42:06  <luke-jr> would be nice to get a test that reproduces it, but I'm not sure how
653 2017-08-24T19:42:08  <wumpus> well as I understand it there are no threads in flight yet at that point
654 2017-08-24T19:42:18  <gmaxwell> we understand it, it shouldn't block the release. (it's in init)
655 2017-08-24T19:42:27  <cfields> wumpus: if that puts you at ease, i should invent some local problems and solve them more often :)
656 2017-08-24T19:42:48  <meshcollider> 😂
657 2017-08-24T19:42:49  <BlueMatt> lol
658 2017-08-24T19:42:50  <wumpus> cfields: haha!
659 2017-08-24T19:43:08  <wumpus> can cfields create an issue even cfields cannot debug
660 2017-08-24T19:43:25  <cfields> haha
661 2017-08-24T19:43:36  <wumpus> ok, any other topics?
662 2017-08-24T19:43:45  <BlueMatt> Segwit is active!
663 2017-08-24T19:43:59  <sipa> what? how?!
664 2017-08-24T19:44:01  <wumpus> yeah! we can remove the point 'activate segwit' from the weekly agenda
665 2017-08-24T19:44:10  <BlueMatt> heh
666 2017-08-24T19:44:12  <kanzure> i have a topic. it can wait.
667 2017-08-24T19:44:18  <luke-jr> what is it waiting for?
668 2017-08-24T19:44:25  <wumpus> ther's only 15 minutes left so don't wait too long
669 2017-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.
670 2017-08-24T19:44:45  <kanzure> and i will publish small document somewhere
671 2017-08-24T19:44:51  <wumpus> segwit wallet support
672 2017-08-24T19:44:53  <kanzure> it's not a schedule. just a braindump sorta.
673 2017-08-24T19:44:55  <kanzure> oh.
674 2017-08-24T19:44:58  <kanzure> okay added
675 2017-08-24T19:45:53  <wumpus> (which is very general, probably should be divided up...)
676 2017-08-24T19:46:23  <jonasschnelli> kanzure: thanks for collecting stuff for the CoreDev.tech in SF!
677 2017-08-24T19:46:40  <kanzure> sure
678 2017-08-24T19:46:52  <jnewbery> wumpus: I'd like #11053 to be reopened / reconsidered
679 2017-08-24T19:47:02  <wumpus> GUI support, bech32 yes/no for this release, etc
680 2017-08-24T19:47:11  <jnewbery> refactor: Make all #includes relative to project root
681 2017-08-24T19:48:00  <cfields> jnewbery: +1. I think my concerns there were mistaken for a NACK. I pretty much regret bringing them up.
682 2017-08-24T19:48:11  <luke-jr> wumpus: eh, at least sending bech32 seems a necessity
683 2017-08-24T19:48:41  <wumpus> cfields: no, not really, it just made me reconsider whether it's really a good idea
684 2017-08-24T19:48:52  <wumpus> cfields: ideally we'd clear out src and move everything to subdirs
685 2017-08-24T19:49:02  <cfields> wumpus: agree with that.
686 2017-08-24T19:49:15  <wumpus> cfields: on the other hand this doesn't make things worse at least
687 2017-08-24T19:49:32  <wumpus> cfields: #include "" is severly misused in our source code
688 2017-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
689 2017-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
690 2017-08-24T19:50:35  <wumpus> *find it somewhere!*
691 2017-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
692 2017-08-24T19:51:54  <gmaxwell> 12:44:01 < wumpus> yeah! we can remove the point 'activate segwit' from the weekly agenda
693 2017-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
694 2017-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. :)
695 2017-08-24T19:52:13  <instagibbs> wumpus, oh thought you just implemented those changes just now, haha
696 2017-08-24T19:52:15  <jnewbery> thanks wumpus
697 2017-08-24T19:52:20  <gmaxwell> (perhaps see the log of the meeting where we added that item)
698 2017-08-24T19:52:24  <cfields> wumpus: agreed, i just don't see a ton of benefit in changing something that works
699 2017-08-24T19:52:38  *** Bluewolf33 has quit IRC
700 2017-08-24T19:52:44  <cfields> however, if benches show that it's noticibly faster, i'm all for it :)
701 2017-08-24T19:53:13  <wumpus> cfields: well the current state prevents having files with the same name in multiple places in the tree sanely
702 2017-08-24T19:53:14  <sipa> cfields: eh, what are you talking about?
703 2017-08-24T19:53:40  <gmaxwell> how are include paths going to change the speed of anything?
704 2017-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
705 2017-08-24T19:53:53  <wumpus> gmaxwell: it can reduce the amount of probing the compiler has to do
706 2017-08-24T19:54:07  <meshcollider> (compile speed not runtime speed)
707 2017-08-24T19:54:12  <cfields> wumpus made that point ^^ in the PR, i believe
708 2017-08-24T19:54:23  <gmaxwell> okay, I'll look at the PR then.
709 2017-08-24T19:54:26  <wumpus> gmaxwell: e.g. including "primitives/primitives.h" in "primitvies/transaction.h" makes it look in primitives/primitives/transaction.h
710 2017-08-24T19:54:42  <wumpus> gmaxwell: which can affect compile speed in some setups
711 2017-08-24T19:54:49  <wumpus> gmaxwell: it's not the primary reason for making the change, though
712 2017-08-24T19:55:52  <BlueMatt> ok, other topics?
713 2017-08-24T19:56:00  <cfields> anyway, i'm happy to see it reopened
714 2017-08-24T19:56:12  <luke-jr> how about meeting plans?
715 2017-08-24T19:56:19  <luke-jr> or should we just discuss that in the dedicated channel later?
716 2017-08-24T19:56:28  <sipa> yes
717 2017-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
718 2017-08-24T19:56:39  <luke-jr> (specifically, are people sticking around Friday, or leaving as soon as it's over?)
719 2017-08-24T19:56:53  <BlueMatt> luke-jr: dedicated channel, i think
720 2017-08-24T19:56:57  *** telberrak has joined #bitcoin-core-dev
721 2017-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
722 2017-08-24T19:57:38  <meshcollider> which channel is that?
723 2017-08-24T19:57:59  *** jimpo has joined #bitcoin-core-dev
724 2017-08-24T19:58:05  <kanzure> #bitcoin-core-dev
725 2017-08-24T19:58:25  <jonasschnelli> ##
726 2017-08-24T19:58:29  *** telberrak has quit IRC
727 2017-08-24T19:58:58  <kanzure> i didn't say what you thought i said
728 2017-08-24T19:59:27  *** Dizzle has joined #bitcoin-core-dev
729 2017-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.
730 2017-08-24T19:59:29  <meshcollider> I guess there's some sort of filtering happening yae
731 2017-08-24T20:00:08  <wumpus> and that concludes the meeting, thanks everyone
732 2017-08-24T20:00:11  <wumpus> #endmeeting
733 2017-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)
734 2017-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
735 2017-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
736 2017-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
737 2017-08-24T20:00:32  <wumpus> we can back to shouting at each other about default values now :)
738 2017-08-24T20:01:33  <morcos> well re: the shouting, i think there is time to argue on github about the changes for next release
739 2017-08-24T20:01:47  <morcos> what i'm more interested in is letting miners know what they need to do
740 2017-08-24T20:01:59  * BlueMatt thinks we should just merge all currently open prs for 0.15 and see what happens
741 2017-08-24T20:02:11  <kanzure> chaos branch?
742 2017-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.
743 2017-08-24T20:02:39  <cfields> morcos: let's forego some of the arguments and s/what they need to do/what their options are/ :)
744 2017-08-24T20:03:01  <morcos> well i think the only option that has a legitimate chance of getting approved is something that says
745 2017-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.
746 2017-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
747 2017-08-24T20:03:58  <cfields> morcos: yes, exactly.
748 2017-08-24T20:04:05  <wumpus> BlueMatt: luckily that's never going to work, most PRs conflict with a few other PRs :)
749 2017-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..
750 2017-08-24T20:04:34  <BlueMatt> wumpus: merge at random until the only remaining ones conflict, then resolve conflicts at random until it compiles :p
751 2017-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?)
752 2017-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.
753 2017-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
754 2017-08-24T20:05:35  <kanzure> well that's an interesting argument.
755 2017-08-24T20:05:38  <gmaxwell> luke-jr: we do, stop syncing the whole history, and only sync the last year worth or whatever.
756 2017-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
757 2017-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?
758 2017-08-24T20:06:14  <kanzure> gmaxwell: ok then what about argument about limiting IBD until utxo commitment sync stuff
759 2017-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.
760 2017-08-24T20:06:26  <luke-jr> morcos: yes, I think we shouldn't recommend things that harm Bitcoin.
761 2017-08-24T20:06:31  *** blznblzn2 has quit IRC
762 2017-08-24T20:06:38  <kanzure> well i think IBD concerns weren't about validation cost, mostly bandwidth over the interwebs
763 2017-08-24T20:06:40  <morcos> i don't think my statement recommended anything
764 2017-08-24T20:07:04  <kanzure> sorry, i mean, those specific IBD concerns
765 2017-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.
766 2017-08-24T20:07:08  <luke-jr> gmaxwell: we aren't only getting witness size increases with Segwit..
767 2017-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"
768 2017-08-24T20:07:32  <sipa> luke-jr: the worst case I/O effect of a block has not changed at all with SegWit
769 2017-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...
770 2017-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
771 2017-08-24T20:07:46  <sipa> luke-jr: the average just got closer to the worst case, which is a good thing
772 2017-08-24T20:08:01  <gmaxwell> luke-jr: moreover the thing you're insisting on (maxsize) doesn't correlate with those IO costs well.
773 2017-08-24T20:08:02  <bitcoin-git> [bitcoin] MarcoFalke pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/affe9271aa49...4ae6d0fbef60
774 2017-08-24T20:08:03  <bitcoin-git> bitcoin/master b23549f John Newbery: [tests] add TestNodeCLI class for calling bitcoin-cli for a node
775 2017-08-24T20:08:03  <bitcoin-git> bitcoin/master c6ec435 John Newbery: [tests] Add bitcoin_cli.py test script
776 2017-08-24T20:08:04  <bitcoin-git> bitcoin/master 4ae6d0f MarcoFalke: Merge #10798: [tests] [utils] test bitcoin-cli...
777 2017-08-24T20:08:17  <luke-jr> cfields: all the more reason we should make the default something advisable (or nothing at all)
778 2017-08-24T20:08:18  <kanzure> surely it was bandwidth not IO concern?
779 2017-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 ?
780 2017-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)
781 2017-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.
782 2017-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
783 2017-08-24T20:08:33  <morcos> maybe i'll just do that
784 2017-08-24T20:08:49  <gmaxwell> kanzure: read faster. For a lot of systems they are _not_ bandwidth limited in IBD.
785 2017-08-24T20:09:02  <kanzure> but is that luke's concern?
786 2017-08-24T20:09:05  <gmaxwell> kanzure: they're chainstate IO limited, etc.
787 2017-08-24T20:09:08  *** Bluewolf33 has joined #bitcoin-core-dev
788 2017-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
789 2017-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.
790 2017-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.
791 2017-08-24T20:12:11  <luke-jr> gmaxwell: only if other miners set that
792 2017-08-24T20:12:20  <luke-jr> no miners right now AFAIK set 4/4
793 2017-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.
794 2017-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
795 2017-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.
796 2017-08-24T20:13:30  <luke-jr> gmaxwell: you have a probability to get it next block of yours
797 2017-08-24T20:13:41  *** Guyver2 has quit IRC
798 2017-08-24T20:14:09  <luke-jr> gmaxwell: do you disagree with #3229 ?
799 2017-08-24T20:14:33  <luke-jr> (it was originally shot down by Hearn and Garzik)
800 2017-08-24T20:15:18  <gmaxwell> I think it's phenominally dumb but better than the current behavior. (not really much of an endorsement)
801 2017-08-24T20:15:34  *** Bluewolf33 has quit IRC
802 2017-08-24T20:15:45  <luke-jr> sigh
803 2017-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
804 2017-08-24T20:17:41  <gmaxwell> I don't think these things should be configurable at all.
805 2017-08-24T20:17:51  <gmaxwell> it's harmful to the network to have discrepencies.
806 2017-08-24T20:18:11  <gmaxwell> Do we have a setting to set a maximum number of 1-bits in a seralized block. No.
807 2017-08-24T20:18:26  <gmaxwell> Would we support such a setting if someone asked for one, ... almost certantly not.
808 2017-08-24T20:18:44  <gmaxwell> discrepancies*
809 2017-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)
810 2017-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)
811 2017-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
812 2017-08-24T20:19:40  <luke-jr> size does matter though
813 2017-08-24T20:20:00  <sipa> luke-jr: yes, a bit
814 2017-08-24T20:20:03  <luke-jr> at the very least, there is the clear case of the blocksonly node
815 2017-08-24T20:20:07  <sipa> so do many other things
816 2017-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.
817 2017-08-24T20:20:56  <gmaxwell> luke-jr: what about the blocksonly node?
818 2017-08-24T20:21:16  <luke-jr> gmaxwell: its bandwidth requirement is primarily affected by the block sizes
819 2017-08-24T20:21:18  <gmaxwell> luke-jr: it matters a small bit yes, but other things matter a lot more.
820 2017-08-24T20:21:54  <sipa> luke-jr: let's work on compressed blocks then
821 2017-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.
822 2017-08-24T20:22:36  <luke-jr> compressed blocks are going to make 100% year-over-year improvements? :/
823 2017-08-24T20:23:10  <praxeology1> True or false... 0.14.2 nodes by default currently limit the weight to 4M?
824 2017-08-24T20:23:26  <sipa> praxeology1: to 3M
825 2017-08-24T20:23:33  <sipa> praxeology1: for mining, that is
826 2017-08-24T20:23:41  <sipa> the consensus rules are obviously not configurable
827 2017-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.
828 2017-08-24T20:23:52  <luke-jr> gmaxwell: it's not a trick
829 2017-08-24T20:24:02  <wumpus> tip: you can see the default for every option with bitcoind --help
830 2017-08-24T20:24:09  <praxeology1> sipa: yea I am talking about consensus rules, not what miners create by default
831 2017-08-24T20:24:50  <sipa> praxeology1: that's entirely offtopic
832 2017-08-24T20:24:56  <sipa> and irrelevant here
833 2017-08-24T20:25:01  <wumpus> praxeology1: huh, then you shouldn't ask 'by default'
834 2017-08-24T20:25:24  <luke-jr> praxeology1: the consensus rule is max weight of 4M.
835 2017-08-24T20:25:28  <gmaxwell> wumpus: elsewhere he's suffering the "but if miners set things higher they'll produce invalid blocks" confusion.
836 2017-08-24T20:25:39  <wumpus> (unless you mean this in the extremely twisted sense of 'without source code changes'? )
837 2017-08-24T20:25:51  <sipa> praxeology1: the weight, which is defined as 3*witsize + basesize must be less than 4M
838 2017-08-24T20:26:03  <sipa> praxeology1: that implies that basesize must be less than 1M
839 2017-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
840 2017-08-24T20:26:35  <sipa> praxeology1: we're only talking about the mining code
841 2017-08-24T20:26:39  <gmaxwell> sipa: don't use witsize as your variable. sounds like the size of the witnesses.
842 2017-08-24T20:26:49  <sipa> -blockmaxsize and -blockmaxweight control the size of blocks the mining code produce
843 2017-08-24T20:27:03  <sipa> but the mining code will never ever produce a consensus-invalid block, regardless of settings
844 2017-08-24T20:27:05  <gmaxwell> praxeology1: consensus rules are not configurable because that would be extremely negligant, incompetent, and pointless.
845 2017-08-24T20:27:21  <gmaxwell> negligent*
846 2017-08-24T20:27:30  * luke-jr notes miners could set blockmaxsize=8000000 safely
847 2017-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)
848 2017-08-24T20:27:41  <morcos> sipa: i think you got your formula wrong there
849 2017-08-24T20:27:49  <gmaxwell> or 16123123
850 2017-08-24T20:27:57  <gmaxwell> morcos: by witsize he means the total size of the block.
851 2017-08-24T20:28:04  <morcos> oh
852 2017-08-24T20:28:15  <gmaxwell> he should have said 3*size + stripped size.
853 2017-08-24T20:28:19  <sipa> sorry, by witsize i meant "size including witnesses"
854 2017-08-24T20:28:22  <morcos> isn't that still wrong
855 2017-08-24T20:28:31  <sipa> yes.
856 2017-08-24T20:28:37  <luke-jr> (3 * stripped size) + size
857 2017-08-24T20:28:42  <morcos> thanks luke
858 2017-08-24T20:28:49  <gmaxwell> derp.
859 2017-08-24T20:28:52  <gmaxwell> yea.
860 2017-08-24T20:29:05  <morcos> i can't wait to read r/btc tonight
861 2017-08-24T20:29:31  <luke-jr> I'm thinking of unsub'ing r/btc
862 2017-08-24T20:29:54  <BlueMatt> lol, you're just *now* thinking of that?
863 2017-08-24T20:30:09  <luke-jr> tbf, not just now. ;)
864 2017-08-24T20:32:03  <clarkmoody> gmaxwell sipa Can you guys look at https://github.com/bitcoin/bips/pull/553 ?
865 2017-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)
866 2017-08-24T20:43:01  *** bitstein has quit IRC
867 2017-08-24T20:43:59  *** shesek has joined #bitcoin-core-dev
868 2017-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?
869 2017-08-24T20:51:03  <praxeology1> maintaining such a data structure w/ no block height delay on the hash... sounds hard
870 2017-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
871 2017-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.
872 2017-08-24T20:59:39  <sipa> praxeology1: our database already supports snapshotting
873 2017-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
874 2017-08-24T21:00:15  <sipa> and yes, periodically
875 2017-08-24T21:01:15  <praxeology1> sounds good to me
876 2017-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
877 2017-08-24T21:03:10  <sipa> yes
878 2017-08-24T21:03:18  *** Chris_Stewart_5 has quit IRC
879 2017-08-24T21:05:41  *** bitstein has joined #bitcoin-core-dev
880 2017-08-24T21:06:04  <praxeology1> Hopefully also some automated process for people to generate these utxo hashes, and communicate them over insecure networks
881 2017-08-24T21:06:55  <praxeology1> Or is there talk bout making it a commitment?
882 2017-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
883 2017-08-24T21:09:17  <sipa> i think it's gettingna bit offtopic here
884 2017-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
885 2017-08-24T21:11:01  *** Dyaheon has quit IRC
886 2017-08-24T21:13:38  *** Dyaheon has joined #bitcoin-core-dev
887 2017-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
888 2017-08-24T21:13:56  *** abpa has quit IRC
889 2017-08-24T21:14:00  <praxeology1> Where would it be on topic?
890 2017-08-24T21:17:20  <sipa> mailing list
891 2017-08-24T21:17:53  <sipa> or bitcoin-wizards
892 2017-08-24T21:25:01  *** ekerstein has quit IRC
893 2017-08-24T21:25:22  *** bitstein has quit IRC
894 2017-08-24T21:34:34  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/4ae6d0fbef60...77fc469fc78c
895 2017-08-24T21:34:34  <bitcoin-git> bitcoin/master cd0ea48 Matt Corallo: Changing -txindex requires -reindex, not -reindex-chainstate
896 2017-08-24T21:34:35  <bitcoin-git> bitcoin/master 77fc469 MarcoFalke: Merge #11108: Changing -txindex requires -reindex, not -reindex-chainstate...
897 2017-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
898 2017-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
899 2017-08-24T21:53:31  *** Bluewolf33 has joined #bitcoin-core-dev
900 2017-08-24T21:54:22  *** Aaronvan_ has joined #bitcoin-core-dev
901 2017-08-24T21:55:02  *** AaronvanW has quit IRC
902 2017-08-24T21:55:21  *** cheese_ has joined #bitcoin-core-dev
903 2017-08-24T21:58:34  *** RoyceX has joined #bitcoin-core-dev
904 2017-08-24T21:59:11  *** Cryptocide has quit IRC
905 2017-08-24T21:59:27  *** Cryptocide has joined #bitcoin-core-dev
906 2017-08-24T22:01:35  *** cheese_ has quit IRC
907 2017-08-24T22:03:49  *** cheese_ has joined #bitcoin-core-dev
908 2017-08-24T22:03:49  *** RoyceX has quit IRC
909 2017-08-24T22:09:09  *** vicenteH has quit IRC
910 2017-08-24T22:27:05  *** jimpo has quit IRC
911 2017-08-24T22:27:31  <meshcollider> 8:21 am <sipa> luke-jr: let's work on compressed blocks then
912 2017-08-24T22:27:32  <meshcollider> What's the current to-do for them?
913 2017-08-24T22:28:36  <sipa> morcos: designing, experimenting, implementating :)
914 2017-08-24T22:28:44  <sipa> s/morcos/meshcollider/
915 2017-08-24T22:29:10  <luke-jr> it's too bad the UTXO set doesn't store the absolute output index in the blockchain
916 2017-08-24T22:29:42  <sipa> luke-jr: it's easy enough to add if that's needed
917 2017-08-24T22:29:53  <luke-jr> sipa: wouldn't it require a re-sync for all pruned nodes?
918 2017-08-24T22:30:03  <luke-jr> otoh, maybe there's some way to do a gradual upgrade..?
919 2017-08-24T22:33:16  <meshcollider> sipa: doesn't BIP 152 cover at least the design step? Or is it still being thought out
920 2017-08-24T22:33:30  <sipa> meshcollider: bip152 is completely unrelated
921 2017-08-24T22:33:41  <sipa> meshcollider: we're just talking about an efficient encoding for transactions
922 2017-08-24T22:33:56  <sipa> luke-jr: if you really mean absolute index, yes
923 2017-08-24T22:34:15  <sipa> hmm, even for relative index in the block
924 2017-08-24T22:34:23  <luke-jr> relative index isn't quite as useful
925 2017-08-24T22:34:31  <luke-jr> I was thinking have all the inputs just address by index
926 2017-08-24T22:35:01  <meshcollider> Oh am I confusing compressed blocks with compact blocks
927 2017-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
928 2017-08-24T22:35:27  <luke-jr> might make varint more optimal
929 2017-08-24T22:35:48  <gmaxwell> luke-jr: I can't figure out what you're talking about.
930 2017-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
931 2017-08-24T22:36:10  <luke-jr> gmaxwell: replace the input txid+index with an absolute tx index in the blockchain
932 2017-08-24T22:36:46  <gmaxwell> how does that have anything to do with the utxo set?
933 2017-08-24T22:37:00  <luke-jr> you'd need to store/index by the absolute tx index to do the lookup
934 2017-08-24T22:37:30  <luke-jr> saying blockchain tx #1934 isn't useful unless the node can easily figure out what tx that is
935 2017-08-24T22:37:33  <luke-jr> utxo*
936 2017-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.
937 2017-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
938 2017-08-24T22:37:53  *** Cryptocide has quit IRC
939 2017-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.
940 2017-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
941 2017-08-24T22:38:11  *** Cryptocide has joined #bitcoin-core-dev
942 2017-08-24T22:38:16  <gmaxwell> but as sipa is pointing out it would be a layering mess.
943 2017-08-24T22:38:20  <sipa> s/figure out/validate/
944 2017-08-24T22:38:27  <luke-jr> hm
945 2017-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.
946 2017-08-24T22:39:44  <gmaxwell> yes, there is a lot more savings if you could replace txin hashes with indexes, but ... layering mess.
947 2017-08-24T22:40:07  <luke-jr> what if we add a commitment to the index-based format?
948 2017-08-24T22:40:36  *** jimpo has joined #bitcoin-core-dev
949 2017-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.
950 2017-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)
951 2017-08-24T22:42:37  <meshcollider> gmaxwell: is your serialisation format posted anywhere? Sorry I'm just catching up
952 2017-08-24T22:43:39  <gmaxwell> meshcollider: yes, but sipa's revised version is better and I don't think thats posted anywhere.
953 2017-08-24T22:44:19  *** owowo has quit IRC
954 2017-08-24T22:44:38  <sipa> https://gist.github.com/sipa/1d29c1019e00874a61e533b2b050046f
955 2017-08-24T22:44:51  <sipa> very much WIP
956 2017-08-24T22:49:35  *** Guest79199 has quit IRC
957 2017-08-24T22:49:38  *** owowo has joined #bitcoin-core-dev
958 2017-08-24T22:50:02  <morcos> damn, i skipped down to Analysis
959 2017-08-24T22:53:03  <sipa> haha
960 2017-08-24T22:54:10  *** hasten has joined #bitcoin-core-dev
961 2017-08-24T22:55:28  <jimpo> I'm looking into writing a P2P test for this: https://github.com/bitcoin/bitcoin/pull/11113
962 2017-08-24T22:55:45  <jimpo> What's the best way from the test framework to fast-forward time or create blocks in the future
963 2017-08-24T22:56:17  <jimpo> or start the chain with blocks far in the past would work too
964 2017-08-24T22:57:01  *** hasten has quit IRC
965 2017-08-24T23:04:25  *** Aaronvan_ is now known as AaronvanW
966 2017-08-24T23:06:45  <jimpo> nvm, I found the setmocktime method
967 2017-08-24T23:09:06  *** cheese_ has quit IRC
968 2017-08-24T23:15:49  *** Dyaheon has quit IRC
969 2017-08-24T23:16:55  *** chjj has quit IRC
970 2017-08-24T23:18:18  *** Dyaheon has joined #bitcoin-core-dev
971 2017-08-24T23:20:20  *** cheese_ has joined #bitcoin-core-dev
972 2017-08-24T23:27:50  <gmaxwell> morcos: IIRC sipa's version is ~28% size reduction for the history.
973 2017-08-24T23:28:42  *** chjj has joined #bitcoin-core-dev
974 2017-08-24T23:35:36  *** RoyceX has joined #bitcoin-core-dev
975 2017-08-24T23:36:33  *** cheese_ has quit IRC
976 2017-08-24T23:39:05  *** Dizzle has quit IRC
977 2017-08-24T23:47:20  *** davec has quit IRC
978 2017-08-24T23:49:15  *** jimpo has quit IRC
979 2017-08-24T23:55:23  *** sniip3r has joined #bitcoin-core-dev
980 2017-08-24T23:56:22  *** Aaronvan_ has joined #bitcoin-core-dev
981 2017-08-24T23:58:03  *** AaronvanW has quit IRC