1 2017-12-07 02:45:06	0|Usman_Mutawakil|Is their any documentation that expands on the details of the source code? I'm having difficulty finding the entry points.
  2 2017-12-07 02:45:13	0|Usman_Mutawakil|there*
  3 2017-12-07 03:00:12	0|meshcollider|Usman_Mutawakil: The entry points of the programs, or the entry point to understanding it?
  4 2017-12-07 03:01:00	0|Usman_Mutawakil|Both, initially the former
  5 2017-12-07 03:31:31	0|meshcollider|Usman_Mutawakil: the main() function for bitcoind is in bitcoind.cpp, for bitcoin-qt it is in qt/bitcoin.cpp and there is one in bitcoin-tx.cpp and bitcoin-cli.cpp for their respective binaries too
  6 2017-12-07 05:14:23	0|BGL|can anyone help me with instructions on storing the blockchain &/or the wallet seperately on windows, via symbolic link, drive/mount or anything that works?
  7 2017-12-07 05:49:10	0|meshcollider|BGL: are you using 0.15.1 or build of master?
  8 2017-12-07 05:49:24	0|BGL|yeah newest copy
  9 2017-12-07 05:50:01	0|BGL|0.15.1
 10 2017-12-07 05:58:29	0|jonasschnelli|cfields: ping (in case you are still awake)
 11 2017-12-07 06:03:47	0|cfields|jonasschnelli: pong, hi
 12 2017-12-07 06:04:03	0|jonasschnelli|hi
 13 2017-12-07 06:05:21	0|cfields|jonasschnelli: any chance you can get ahold of a dummy certificate signing request?
 14 2017-12-07 06:05:37	0|jonasschnelli|cfields: I have one here... one sec
 15 2017-12-07 06:05:45	0|cfields|oh, that was easy :)
 16 2017-12-07 06:07:18	0|jonasschnelli|cfields: there is now also the option to request ECC (up to 521 bits... though not sure if they will be accepted
 17 2017-12-07 06:07:35	0|cfields|ah, nice
 18 2017-12-07 06:07:43	0|cfields|we'd need to check back-compat too, though
 19 2017-12-07 06:07:50	0|cfields|oh, i guess that's what you meant :)
 20 2017-12-07 06:09:41	0|jonasschnelli|cfields: Yes. Not sure if its accepted and backward compat... so better to go for RSA
 21 2017-12-07 06:10:47	0|cfields|got the dummies, thanks a bunch. It's late now, but I'll have a look in the morning.
 22 2017-12-07 06:11:14	0|jonasschnelli|cfields: Sure. Just tell me if you want access to the apple developer programm interface
 23 2017-12-07 06:13:08	0|cfields|jonasschnelli: hmm, we probably need to keep that locked down. assuming that access would allow me to revoke the current or request a new cert.
 24 2017-12-07 06:13:48	0|jonasschnelli|cfields: I don't know how to best deal with that...
 25 2017-12-07 06:19:56	0|cfields|jonasschnelli: i wonder if it's possible to cancel your account without revoking the certs. a quick search turned up an email address to use for revoking without an account, so maybe that's possible?
 26 2017-12-07 06:20:20	0|cfields|then a new account could be created for each renewal. Or would that require re-certification?
 27 2017-12-07 06:21:09	0|jonasschnelli|cfields: the account setup is somehow cumbersome. I had to verify the account (by phone) because it's an organisation. You need a DUNS number, and need to pay 99USD.
 28 2017-12-07 06:22:11	0|cfields|ah damn, ok. I was thinking the dev account and corp id might not be 100% tied together.
 29 2017-12-07 06:22:17	0|jonasschnelli|cfields: and finally, it's social hackable. If we lock ourselfs out,.. apple probably has a solution to lock in again if the right person from the organisation authorizes himself
 30 2017-12-07 06:22:55	0|jonasschnelli|cfields: I can setup an new "team member". Maybe I can even revoke my own admin user (after have setup a new one)... but not sure how this would allow to improve things
 31 2017-12-07 06:24:30	0|cfields|yea, maybe not
 32 2017-12-07 06:25:13	0|cfields|well, i guess the same threshold scheme would work for revocation as well. if ever necessary.
 33 2017-12-07 06:25:58	0|cfields|ah nm, it'd be a different key
 34 2017-12-07 06:26:40	0|cfields|(assuming someone got control of the account and created a new key)
 35 2017-12-07 06:27:09	0|cfields|blah, I'll dive in tomorrow. thanks again :)
 36 2017-12-07 07:11:04	0|jonasschnelli|cfields: Yeah. Have some rest. I think it's not solvable in a secure way. On top, apple has control over everything. It's just code signing and does not ensure the binary has built properly. It's far less valuable then the gitian signatures...
 37 2017-12-07 07:45:40	0|warren|A while ago checkpoints were there in part to allow IBD to go a lot faster. The checkpoints are still in there now. After headersfirst, are those checkpoints in there still serving any IBD performance purpose?
 38 2017-12-07 07:47:45	0|sipa|warren: no, we have assumevalid for that now
 39 2017-12-07 07:47:58	0|sipa|the checkpoints are just there to prevent a low-work headers spam attack
 40 2017-12-07 07:49:33	0|warren|thx.
 41 2017-12-07 07:50:31	0|sipa|assumevalid was introduced in 0.13 or 0.14 iirc
 42 2017-12-07 07:50:55	0|sipa|https://bitcoin.org/en/release/v0.14.0#introduction-of-assumed-valid-blocks
 43 2017-12-07 09:40:26	0|GAit|wumpus: is the ARM assembly optimization the one enabled by --enable-experimental-asm or there's something ARM specific that I missed?
 44 2017-12-07 09:40:50	0|sipa|GAit: the libsecp256k1 ARM assembly? i don't think so
 45 2017-12-07 09:41:55	0|GAit|I was just going on about a comment from wumpus above about considering enabling by default the ARM assembly opt and I was wondering which flag would do that manually today
 46 2017-12-07 09:47:37	0|Sentineo|GAit: ./configure --with-asm=arm --enable-experimental
 47 2017-12-07 09:47:56	0|GAit|Sentineo: thanks
 48 2017-12-07 09:48:03	0|Sentineo|yw
 49 2017-12-07 09:49:49	0|GAit|maybe it's just me but i find having both --enable-experimental-asm and having --with-asm=arm --enable-experimetal is a tiny bit confusing
 50 2017-12-07 10:00:15	0|meshcollider|Yeah GAit wumpus mentioned earlier today that some documentation is probably needed but he's not sure where the best place to put it is
 51 2017-12-07 10:04:39	0|sipa|GAit: "--with-asm=arm --enable-experimental" are libsecp256k1 configure options; the " --enable-experimental-asm" is a bitcoin core configure option
 52 2017-12-07 10:05:16	0|sipa|together it does look confusing, i agree
 53 2017-12-07 10:52:27	0|wumpus|--with-asm=arm enables the secp256k1 arm assembly, --enable-experimental-asm does nothing for ARM afaik
 54 2017-12-07 10:53:12	0|wumpus|(it might in the future if someone adds support for the ARM crypto intrinsics to bitcoin)
 55 2017-12-07 10:54:50	0|wumpus|it'd be nice to be able to run gitian on non-x86 platforms, doing at least one such build would add reassurance against intel ME antics
 56 2017-12-07 10:56:56	0|sipa|syncing on my kdroid was painfully slow as it flushed every few blocks in order to prune
 57 2017-12-07 10:57:18	0|sipa|by making it only prune whwn kver 2x the prune target i made it an order of magnitude faster, i think
 58 2017-12-07 10:57:23	0|sipa|*odroid
 59 2017-12-07 11:02:24	0|Sentineo|I run an odroid as well, the arm optimisation did help it a lot
 60 2017-12-07 11:02:32	0|Sentineo|but my node is not pruned
 61 2017-12-07 11:11:26	0|Provoostenator|sipa: I'll keep my Xiaomi A1 around in case someone want to get some measurements for more efficient pruning during IDB...
 62 2017-12-07 11:12:16	0|Provoostenator|It took a little under 2 weeks
 63 2017-12-07 11:12:43	0|Provoostenator|Using ABCore; I don't know if that uses any optimization.
 64 2017-12-07 11:14:05	0|esotericnonsense|pimping https://github.com/bitcoin/bitcoin/pull/11658 https://github.com/bitcoin/bitcoin/pull/11359
 65 2017-12-07 11:15:05	0|Provoostenator|I also put a small bounty on #11720, as I'd love to try and run a full node on my iPhone X. I don't even have to prune it :-)
 66 2017-12-07 11:15:06	0|gribble|https://github.com/bitcoin/bitcoin/issues/11720 | iOS Deployment Target for RPC · Issue #11720 · bitcoin/bitcoin · GitHub
 67 2017-12-07 11:15:32	0|wumpus|Provoostenator: their source is here: https://github.com/greenaddress/abcore  couldn't find the configure/compile flags there so quickly
 68 2017-12-07 11:15:42	0|esotericnonsense|on pruning there's the seemingly longer-term thing of having writeback not flush (i haven't been paying attention to this for a while)
 69 2017-12-07 11:16:03	0|wumpus|I don't think they're using our ARM builds, at least they didn't use to
 70 2017-12-07 11:18:28	0|Provoostenator|esotericnonsense: 11658 is wonderfully small
 71 2017-12-07 11:19:41	0|esotericnonsense|i've only just seen it, i'm ill at the moment and trying to reason through the code isn't working. if it actually does what it says on the tin i like it and agree with promag that 10% is too little.
 72 2017-12-07 11:21:13	0|esotericnonsense|wondering if there's some weird interaction with minimum prune size like if you are at 550MiB and use 50% can you end up with very few blocks.
 73 2017-12-07 11:24:24	0|Provoostenator|wumpus: I just nagged the author on Twitter, we'll see
 74 2017-12-07 11:25:22	0|wumpus|might make sense to make their ndk build part of the standard gitian targets at some point
 75 2017-12-07 11:25:51	0|Provoostenator|Maybe it should never go below 550, but any prune size above that will use some intelligent percentage.
 76 2017-12-07 11:26:01	0|wumpus|anyhow if they reply please let me know what they use now
 77 2017-12-07 11:34:20	0|wumpus|jonasschnelli: Provoostenator: I also wonder if abcore added android ndk to the depends system (but never upstreamed it) or they're building their own dependencies somehow
 78 2017-12-07 11:35:01	0|sipa|GAit is the author of abcore
 79 2017-12-07 11:35:12	0|wumpus|oh lol
 80 2017-12-07 11:36:31	0|Provoostenator|No, we should reach him through a screenshot of Twitter posted on Reddit with a link to this IRC log...
 81 2017-12-07 11:36:43	0|wumpus|hahahahah
 82 2017-12-07 11:38:14	0|sipa|Provoostenator: excuse me, but i'm sure you meant a screenshot of a slack with a bridge of this IRC channel :p
 83 2017-12-07 11:39:33	0|Provoostenator|That too. How hard would it be to make that bridge two-way, somehow mapping and authenticating Slack names to IRC names for those who use both?
 84 2017-12-07 11:41:33	0|wumpus|I'm would be surprised if there's not already software for that and you just have to stash it somewhere and configure it. But to be honest I'd prefer no bridges *to* this channel, in the interest of managing signal-to-noise.
 85 2017-12-07 11:42:29	0|Provoostenator|I suppose most people who can compile from source can figure out IRC.
 86 2017-12-07 11:42:32	0|GAit|lol
 87 2017-12-07 11:43:17	0|GAit|so abcore used to use debian/archlinux build until core provided arm binaries. Now it uses ndk native builds, using github.com/greenaddress/bitcoin_ndk for the building part
 88 2017-12-07 11:43:52	0|GAit|would love some feedback, it's very hacked up together (though I'm not too worried as abcore is experimental and in alpha)
 89 2017-12-07 11:44:50	0|GAit|to enable the arm optimization i will need to enable armv-7a (for Thumb-2)
 90 2017-12-07 11:45:10	0|wumpus|Provoostenator: there you go: https://github.com/42wim/matterbridge  (#monero-dev seems to have this, not sure what they're bridging from)
 91 2017-12-07 11:45:23	0|wumpus|GAit: thanks
 92 2017-12-07 11:46:26	0|GAit|I'm using clang as android ndk deprecated gcc and they are going to remove it
 93 2017-12-07 11:47:17	0|GAit|however i had to use an older ndk than the latest because the latest has some issues/bad headers
 94 2017-12-07 11:47:48	0|wumpus|GAit: one suggestion would be to benchmark whether thumb or arm instructions gives the best performance. I vaguely remember that for me, simple ARM32 instructions gave the best performance at some point at least on the secp256k1 benches, on i.mx6.
 95 2017-12-07 11:48:26	0|Provoostenator|wumpus: nice. I suppose you don't really need individual user authentication for this, just as long as all messages end up on both services (without feedback loops).
 96 2017-12-07 11:48:52	0|GAit|wumpus: you mean things like field_10x26_arm.s
 97 2017-12-07 11:49:22	0|wumpus|GAit: I mean the code generation of the compiler, what kind of instructions it generates, whether it uses the processor in ARM or THUMB mode (or interwork)
 98 2017-12-07 11:50:19	0|GAit|indeed to make sure one would  need to benchmark. but before you can benchmark you need to get it to work, and i will have to enable v7a/thumb-2 otherwise i get rc/asm/field_10x26_arm.s:109:2: error: instruction requires: thumb2
 99 2017-12-07 11:50:33	0|wumpus|THUMB usually results in more compact code, but ARM instructions allow more flexibility, so doing more in less instructions. Then again this was relevant for ARM32, probably not for AARCH64.
100 2017-12-07 11:52:21	0|wumpus|GAit: just looked at the bitcoin_ndk build a bit and doesn't seem like it needs huge patches, I guess the introduction of src/ifaddrs.c is the biggest change
101 2017-12-07 11:53:40	0|GAit|wumpus: yes, it doesn't need much patching. Not with this ndk version anyway. Had to do a lot more with later and still didn't manage so i gave up.
102 2017-12-07 11:53:51	0|wumpus|I vaguely remember needing to do the "i686_linux_CC=$(default_host_CC) -m32" change in linux.mk as well. This was for building depends on ARM64, for ARM64. Depends is really rooted in 'we build from x86 linux' right now.
103 2017-12-07 11:54:09	0|wumpus|hmm okay
104 2017-12-07 11:54:59	0|GAit|I'm terrible at make/build otherwise i'd see if i could make a PR or more out of it
105 2017-12-07 11:55:09	0|wumpus|so building bitcoin core on most recent ndk is an open issue?
106 2017-12-07 11:55:15	0|GAit|(assuming there was interest)
107 2017-12-07 11:55:22	0|wumpus|there's certainly interest
108 2017-12-07 11:55:31	0|GAit|yes, i can do that on a branch so that you can see the travis log
109 2017-12-07 11:56:27	0|wumpus|going to open an issue for that
110 2017-12-07 12:02:42	0|gribble|https://github.com/bitcoin/bitcoin/issues/11844 | Bitcoin core build on Android NDK · Issue #11844 · bitcoin/bitcoin · GitHub
111 2017-12-07 12:02:42	0|wumpus|GAit: just opened #11844 feel free to post that there so people have an idea what the open problems are
112 2017-12-07 12:07:02	0|wumpus|FYI some people have also been building bitcoin core natively on android using termux (#11388), but that uses a debian derivative not NDK
113 2017-12-07 12:07:03	0|gribble|https://github.com/bitcoin/bitcoin/issues/11388 | Building within termux fails with incomplete type CBlock · Issue #11388 · bitcoin/bitcoin · GitHub
114 2017-12-07 12:07:46	0|wumpus|oh that was esotericnonsense :)
115 2017-12-07 12:07:50	0|GAit|great, thanks wumpus . Oh I didn't know about termux having core builds, i searched in their repos. I was going to try that after failing on NDK but eventually trying different things got it to work
116 2017-12-07 12:08:43	0|esotericnonsense|GAit: it doesn't, i built it on termux
117 2017-12-07 12:09:01	0|esotericnonsense|i don't have the time to maintain it so didn't submit to packages
118 2017-12-07 12:10:16	0|wumpus|agree, distro packages for bitcoin are a bad idea if they're not maintained
119 2017-12-07 12:10:43	0|wumpus|tends to keep a share of the users permanently stuck in the past
120 2017-12-07 12:13:02	0|Sentineo|bitcoins build system is awasome anyway, do not feel the lack of an official distro package per distribution
121 2017-12-07 12:16:07	0|wumpus|yes it's pretty neat, quite uncommon for open source projects to ship with scripts to easily build dependencies
122 2017-12-07 12:16:56	0|Sentineo|the only thing I could not manage is the gitian build
123 2017-12-07 12:17:05	0|Sentineo|but I did not try hard enough :)
124 2017-12-07 12:17:38	0|GAit|wumpus: indeed I would have never managed without the build system being 'generic' and being battle tested against arm
125 2017-12-07 12:17:46	0|wumpus|yeah gitian could definitely be easier
126 2017-12-07 12:18:33	0|Provoostenator|I still have some notes for a future Gitian documentation improvement PR, but I'd like to do a few more builds to wrap my head around it.
127 2017-12-07 12:19:30	0|Sentineo|Provoostenator: if you have a draft I would be happe to at least give you feedback :)
128 2017-12-07 12:19:34	0|Provoostenator|I'd like to get it to a point where anyone with OSX (others can do Linux / Windows) and very little sysadmin skills can sign a build.
129 2017-12-07 12:20:45	0|Provoostenator|Sentineo: my scribbled notes are worse than the actual documentation :-)
130 2017-12-07 12:21:10	0|Sentineo|:) ok, just in case ... let me know
131 2017-12-07 12:21:19	0|wumpus|but better than nothing at all probably
132 2017-12-07 12:22:01	0|Provoostenator|I also wonder if it's possible to verify an OSX signed binary without gitian signers having to sign off on the signed binary.
133 2017-12-07 12:22:39	0|Provoostenator|I.e. isn't it possible to unpack a signed binary, strip the signature and then check that against the unsigned gitian build?
134 2017-12-07 12:23:15	0|Provoostenator|I'd need to study how OSX code signing actually works.
135 2017-12-07 12:24:30	0|wumpus|it's possible, but if gitian signers don't sign off on the signed binary that makes verification of hashes a lot harder. No longer can you just use sha256, but need a script, which might have been tampered with itself!
136 2017-12-07 12:25:23	0|Provoostenator|Right, so that would only make sense if the script is trivial enough that it fits on a T-shirt.
137 2017-12-07 12:25:26	0|wumpus|we looked at the inverse approach that you describe back in the day that we introduced signed executables, but decided not to because of drawbacks like that
138 2017-12-07 12:25:49	0|wumpus|right, and it takes some serious binary surgery so that's likely not the case and will have dependencies of itself
139 2017-12-07 12:26:22	0|Provoostenator|"Binary surgery" - lol
140 2017-12-07 12:26:59	0|Provoostenator|It's weird though; these executables work, so you'd think everything is already in the system...
141 2017-12-07 12:53:31	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11602: utils: removed deprecated check and function for OpenSSL compatiblity (06master...06old_openssl_names) 02https://github.com/bitcoin/bitcoin/pull/11602
142 2017-12-07 12:59:02	0|GAit|wumpus: so for arm/thumb i can't just set global CFLAGS because otherwise native_ccaache will pick them up and break, suggest hacking linux.mk or is there an easy way maybe to disable native_ccache
143 2017-12-07 12:59:55	0|wumpus|could add a NO_CCACHE that works similar to NO_WALLET NO_QT etc, but no currently that doesn't exist
144 2017-12-07 13:00:36	0|wumpus|but I agree that is inconvenient, maybe cfields has a simpler sugggestion
145 2017-12-07 13:01:24	0|GAit|well disabling it would be a hack, if itn's not there i think is better that i patch directly linux.mk to add my cflags there. Or, I could set them maybe just for the core build and not for the dependencies.
146 2017-12-07 13:01:32	0|wumpus|"passing global cflags for the target" would be nice as a supported option for depends, no matter ccache
147 2017-12-07 13:01:45	0|GAit|yes indeed it would
148 2017-12-07 13:02:11	0|wumpus|I've run into similar issues in experimentation but also ended up patching makefiles
149 2017-12-07 13:02:31	0|GAit|i feel terrible/funny because i assumed it was possible and felt too embarassed to ask how so i've been looking and patching when i didn't find a better way
150 2017-12-07 13:04:01	0|GAit|anyway for now i'll try to set the flags just for the core build and not for the deps, unless that's stupid for some reason
151 2017-12-07 13:06:40	0|GAit|by the way, I think it's curious how ccache picks up my cflags but not my cc or cxx env vars
152 2017-12-07 13:07:47	0|wumpus|none of the dependencies that are not built into bitcoin's source tree are performance critical (maybe with the exception of boost, but that's mostly header only?)
153 2017-12-07 13:08:25	0|wumpus|so if you're experimenting with build flags setting them just for the core build is probably fine
154 2017-12-07 13:09:47	0|bitcoin-git|13bitcoin/06master 14529b866 15MeshCollider: Test datadir in conf file exists
155 2017-12-07 13:09:47	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/497d0e014cc7...7630a1fe9a4c
156 2017-12-07 13:09:48	0|bitcoin-git|13bitcoin/06master 147630a1f 15Wladimir J. van der Laan: Merge #11829: Test datadir specified in conf file exists...
157 2017-12-07 13:15:26	0|GAit|wumpus: cool, ta
158 2017-12-07 13:17:04	0|wumpus|(there's a similar consideration on whether to do flto on just bitcoin core or all the dependencies as well. Though that experiment was put on hold when it turned out flto somehow negatively affected performance, at least in a specific case)
159 2017-12-07 13:22:34	0|GAit|wumpus: i've updated the issue you raised with the specific failure, has to do with NDK doing something stupid and the woraround would be to not set FILE_OFFSET_BITS
160 2017-12-07 13:22:44	0|GAit|only breaks on 32 bit, on 64 bit it works
161 2017-12-07 13:22:55	0|wumpus|okay at least easy to work around then, good
162 2017-12-07 13:23:57	0|GAit|well it wasn't that easy for me, i tried to unset it in a couple of places but probably i just misunderstood how it worked
163 2017-12-07 13:24:15	0|GAit|or what was setting it. I think core sets it
164 2017-12-07 13:24:21	0|GAit|but maybe some of the deps too?
165 2017-12-07 13:25:08	0|GAit|anyway after a long intensive and unfruitful discussion with the ndk that's when i just went to an earlier version
166 2017-12-07 13:28:47	0|bitcoin-git|[13bitcoin] 15wjcloud opened pull request #11845: Add gitian PGP key: wjcloud (06master...06p) 02https://github.com/bitcoin/bitcoin/pull/11845
167 2017-12-07 13:39:10	0|wumpus|yes, core sets it in configure.ac
168 2017-12-07 13:39:55	0|GAit|yes so i tried to unset it there but i think it still failed, i.e. something else was setting it too, or at least that's what i recall
169 2017-12-07 13:41:49	0|wumpus|indeed,if that was all then we could just stop setting it when ndk build detected
170 2017-12-07 13:45:03	0|GAit|the asm flags passed to core only break the configure, doesn't find boost sleep, i assume both (or neither) need them can't do it half and half
171 2017-12-07 13:47:05	0|wumpus|can you pastebin configure.log part where the boost sleep test fails? it has the detailed error message
172 2017-12-07 13:47:20	0|wumpus|the "cannot find boost sleep" error is completely useless in that regard it can mean so many things
173 2017-12-07 13:48:48	0|wumpus|would make sense to structure the boost detection differently, so that it first tries if it can compile/link anything against boost and only then try to find the sleep function to use
174 2017-12-07 13:49:51	0|GAit|sure one sec
175 2017-12-07 13:52:55	0|GAit|wumpus: https://pastebin.com/vUVcQSV9
176 2017-12-07 13:53:39	0|GAit|chokes on choke me
177 2017-12-07 13:54:04	0|wumpus|errors like /build/bitcoin-0.15.1/depends/arm-linux-androideabi/share/../lib/libboost_system-mt.a(error_code.o)(.ARM.extab+0xc): error: undefined reference to '__gxx_personality_v0'  look scarier
178 2017-12-07 13:54:26	0|wumpus|looks like it can't even link the c++ standard libary
179 2017-12-07 13:54:38	0|wumpus|so yes, apparently that doesn't work
180 2017-12-07 13:55:34	0|GAit|for what is worth this is master of bitcoin_ndk with extra "-march=armv7-a -mthumb" cflags for the core part (not the deps) of arm (not arm64)
181 2017-12-07 13:55:46	0|GAit|cflags and cxxflags to be precise
182 2017-12-07 14:00:26	0|wumpus|strange
183 2017-12-07 14:06:43	0|wumpus|I wonder which of those two is the culprit
184 2017-12-07 14:07:36	0|wumpus|my guess would be at changing the arch
185 2017-12-07 14:08:57	0|wumpus|there are some compiler settings that effectively need a new build root but I've never noticed thumb/arm to be one of those
186 2017-12-07 14:10:27	0|wumpus|oh I remember it depends on the setting of interwork, ift that's not enabled you can't mix thumb and ARM. But it's pretyt much the default for a long time for linux distros at least.
187 2017-12-07 14:11:36	0|GAit|maybe because i'm using clang the toolchain is not assuming linux? not sure
188 2017-12-07 14:12:07	0|wumpus|it could all be different for ndk which is not really linux
189 2017-12-07 14:12:22	0|GAit|kernel is linux, but no gnuland
190 2017-12-07 14:12:54	0|wumpus|kernel is a specially patched kernel to add bind etc, or are the android patches upstream now?
191 2017-12-07 14:13:24	0|wumpus|binder*
192 2017-12-07 14:14:02	0|wumpus|but yes that part is compatible in one direction, you can run debian rootfs' on android, but not android rootfs on debian
193 2017-12-07 14:57:12	0|promag|wumpus: if you feel like merging something 11838 :P
194 2017-12-07 15:07:31	0|bitcoin-git|[13bitcoin] 15sdaftuar opened pull request #11847: Make boost::multi_index comparators const (06master...062017-12-fix-const-comparator) 02https://github.com/bitcoin/bitcoin/pull/11847
195 2017-12-07 15:24:42	0|promag|jnewbery: rebasing #10160?
196 2017-12-07 16:37:48	0|wumpus|promag: thanks
197 2017-12-07 16:38:07	0|bitcoin-git|13bitcoin/06master 14fa4c16d 15MarcoFalke: qa: Add getrawtransaction in_active_chain=False test
198 2017-12-07 16:38:07	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/7630a1fe9a4c...3e5002412002
199 2017-12-07 16:38:08	0|bitcoin-git|13bitcoin/06master 143e50024 15Wladimir J. van der Laan: Merge #11838: qa: Add getrawtransaction in_active_chain=False test...
200 2017-12-07 16:41:07	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11809: gui: Fix proxy setting options dialog crash (06master...062017_12_gui_proxy_robustness) 02https://github.com/bitcoin/bitcoin/pull/11809
201 2017-12-07 16:44:54	0|darklegacy|hii
202 2017-12-07 16:45:18	0|darklegacy|any one there
203 2017-12-07 16:45:53	0|darklegacy|hyyyyyyyyyyyyyyyyyyyy
204 2017-12-07 16:46:00	0|instagibbs|no
205 2017-12-07 16:46:01	0|darklegacy|helooo
206 2017-12-07 16:46:20	0|instagibbs|more seriously: this channel is for Core development discussion, please no chatter
207 2017-12-07 16:46:25	0|instagibbs|#bitcoin for chatter
208 2017-12-07 16:46:39	0|darklegacy|can some one teach me how to mine bitcoin
209 2017-12-07 16:47:13	0|darklegacy|where to start???
210 2017-12-07 16:50:51	0|promag_|wumpus: meeting in about 2 hours right?
211 2017-12-07 16:51:06	0|wumpus|promag_: yes
212 2017-12-07 16:51:35	0|promag|thank, probably I'll be late, have to get kids..
213 2017-12-07 16:52:52	0|wumpus|date -u -> 19:00 UTC
214 2017-12-07 16:52:57	0|promag|ok
215 2017-12-07 16:53:02	0|wumpus|ok well feel free to drop in later
216 2017-12-07 16:53:59	0|promag|I would like to discuss #11826 as it interacts with other PR's
217 2017-12-07 16:54:01	0|gribble|https://github.com/bitcoin/bitcoin/issues/11826 | RFC: Activity feature · Issue #11826 · bitcoin/bitcoin · GitHub
218 2017-12-07 16:54:16	0|promag|end of queue thou
219 2017-12-07 17:38:09	0|bitcoin-git|13bitcoin/06master 141ec0c0a 15Suhas Daftuar: Make boost::multi_index comparators const...
220 2017-12-07 17:38:09	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/80f9dad0b799...4ef4dfebbc07
221 2017-12-07 17:38:10	0|bitcoin-git|13bitcoin/06master 144ef4dfe 15Wladimir J. van der Laan: Merge #11847: Make boost::multi_index comparators const...
222 2017-12-07 17:38:45	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11847: Make boost::multi_index comparators const (06master...062017-12-fix-const-comparator) 02https://github.com/bitcoin/bitcoin/pull/11847
223 2017-12-07 18:12:28	0|Mg|Join
224 2017-12-07 18:13:35	0|Guest82059|CSbreakdown
225 2017-12-07 18:15:46	0|Guest82059|How can i do mining of bitcoin
226 2017-12-07 18:15:59	0|belcher|wrong channel, try #bitcoin
227 2017-12-07 18:16:00	0|sipa|#bitcoin
228 2017-12-07 18:16:27	0|Guest82059|Mining of #bitcoin
229 2017-12-07 18:16:41	0|sipa|please, not here. go to #bitcoin
230 2017-12-07 18:56:42	0|jonasschnelli|re BTC message signing: what is the "vchSig[0] = 27 + rec + (fCompressed ? 4 : 0);". Is that packing the recid together with the compress-flag into a single byte?
231 2017-12-07 18:56:55	0|jonasschnelli|Why 27?
232 2017-12-07 19:00:47	0|achow101|meeting?
233 2017-12-07 19:00:51	0|wumpus|#startmeeting
234 2017-12-07 19:00:52	0|instagibbs|yes
235 2017-12-07 19:00:52	0|lightningbot|Meeting started Thu Dec  7 19:00:51 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
236 2017-12-07 19:00:52	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
237 2017-12-07 19:01:04	0|meshcollider|hi
238 2017-12-07 19:01:21	0|wumpus|#bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag
239 2017-12-07 19:01:26	0|jonasschnelli|hi
240 2017-12-07 19:01:38	0|cfields|hi
241 2017-12-07 19:01:38	0|Provoostenator|hi
242 2017-12-07 19:01:46	0|wumpus|#topic high priority for review
243 2017-12-07 19:01:49	0|achow101|hi
244 2017-12-07 19:01:55	0|wumpus|https://github.com/bitcoin/bitcoin/projects/8
245 2017-12-07 19:02:52	0|wumpus|there was lots of review on #11403 this week
246 2017-12-07 19:02:57	0|gribble|https://github.com/bitcoin/bitcoin/issues/11403 | SegWit wallet support by sipa · Pull Request #11403 · bitcoin/bitcoin · GitHub
247 2017-12-07 19:02:59	0|wumpus|but nothing ready for merge yet AFAIK
248 2017-12-07 19:03:13	0|kanzure|hi.
249 2017-12-07 19:03:23	0|jnewbery|hello
250 2017-12-07 19:03:35	0|sipa|hi, only half here
251 2017-12-07 19:03:47	0|BlueMatt|re: high prio #11383 should probably be taken off
252 2017-12-07 19:03:50	0|gribble|https://github.com/bitcoin/bitcoin/issues/11383 | Basic Multiwallet GUI support by luke-jr · Pull Request #11383 · bitcoin/bitcoin · GitHub
253 2017-12-07 19:03:53	0|BlueMatt|cause luke-jr hasnt kept up with it
254 2017-12-07 19:04:08	0|wumpus|sipa: which half?
255 2017-12-07 19:04:11	0|BlueMatt|jnewbery: promised me he'd rebase #10740
256 2017-12-07 19:04:13	0|gribble|https://github.com/bitcoin/bitcoin/issues/10740 | [wallet] dynamic loading/unloading of wallets by jnewbery · Pull Request #10740 · bitcoin/bitcoin · GitHub
257 2017-12-07 19:04:19	0|wumpus|BlueMatt: ok
258 2017-12-07 19:04:47	0|instagibbs|will retest segwit wallet/qt pr on top of #11839
259 2017-12-07 19:04:49	0|gribble|https://github.com/bitcoin/bitcoin/issues/11839 | dont attempt mempool entry for wallet transactions on startup if alr… by instagibbs · Pull Request #11839 · bitcoin/bitcoin · GitHub
260 2017-12-07 19:04:49	0|jonasschnelli|I'll try to take over 11383 (we should have this in 0.16)
261 2017-12-07 19:04:50	0|promag|hi
262 2017-12-07 19:05:08	0|BlueMatt|oh, yea, 11839 should be tagged 0.16
263 2017-12-07 19:05:10	0|BlueMatt|its a trivial fix, I think
264 2017-12-07 19:05:44	0|BlueMatt|jonasschnelli: no need to take it over if instagibbs is active on it?
265 2017-12-07 19:05:51	0|wumpus|if it's a trival fix it should probably be merged instead of tagged?
266 2017-12-07 19:06:01	0|instagibbs|BlueMatt, wrong PR, just looks like he mentioned it i think?
267 2017-12-07 19:06:12	0|jonasschnelli|I'm doing the Multiwalltet GUI PR
268 2017-12-07 19:06:14	0|instagibbs|that's multiwallet
269 2017-12-07 19:06:20	0|BlueMatt|ohoh, yea, wrong #
270 2017-12-07 19:06:32	0|BlueMatt|all options are relatively trivial
271 2017-12-07 19:07:13	0|BlueMatt|#11824 may be mergeable with another review to fix reindex on master, jamesob indicated his issue was the result of "running wrong build"
272 2017-12-07 19:07:15	0|gribble|https://github.com/bitcoin/bitcoin/issues/11824 | Block ActivateBestChain to empty validationinterface queue by TheBlueMatt · Pull Request #11824 · bitcoin/bitcoin · GitHub
273 2017-12-07 19:08:10	0|achow101|I think #11824 can be merged.
274 2017-12-07 19:08:12	0|gribble|https://github.com/bitcoin/bitcoin/issues/11824 | Block ActivateBestChain to empty validationinterface queue by TheBlueMatt · Pull Request #11824 · bitcoin/bitcoin · GitHub
275 2017-12-07 19:08:37	0|wumpus|#action merge #11824
276 2017-12-07 19:08:39	0|gribble|https://github.com/bitcoin/bitcoin/issues/11824 | Block ActivateBestChain to empty validationinterface queue by TheBlueMatt · Pull Request #11824 · bitcoin/bitcoin · GitHub
277 2017-12-07 19:08:47	0|achow101|I did notice another OOM issue I think, but it looked like to be hard to reproduce and required significant uptime
278 2017-12-07 19:09:23	0|BlueMatt|achow101: I failed to find any hidden memory in massif, but I'm still doing runs in it so will look further
279 2017-12-07 19:10:23	0|wumpus|do we have a memory leak?
280 2017-12-07 19:11:00	0|BlueMatt|I dont (currently) believe so...master will OOM during reindex cause validation runs ahead of validationinterface and memory grows huge, but its not technically a leak cause it will catch up eventually if you have enough memory to do it
281 2017-12-07 19:11:03	0|wumpus|I haven't had any OOM crashes FWIW
282 2017-12-07 19:11:05	0|BlueMatt|11824 fixes that
283 2017-12-07 19:11:09	0|jonasschnelli|Did also a quick run with my leak tool and some stuff popped up. leveldb, bdb ansd some other things
284 2017-12-07 19:11:31	0|jonasschnelli|Will have a closer look soon
285 2017-12-07 19:11:42	0|wumpus|oh, only during reindex, I haven't done that recently
286 2017-12-07 19:11:44	0|BlueMatt|topics?
287 2017-12-07 19:12:02	0|BlueMatt|wumpus: could also happen directly after restart if you've been offline for a month or whatever
288 2017-12-07 19:12:18	0|achow101|or during IBD
289 2017-12-07 19:12:25	0|wumpus|I think an OOM issue is a pretty serious topic? but other suggestions are welcome of course
290 2017-12-07 19:12:45	0|morcos|if anyone objects to my "won't fix" of #11800, speak up now.  will update code comments per ryanofsky suggestion
291 2017-12-07 19:12:46	0|gribble|https://github.com/bitcoin/bitcoin/issues/11800 | Bitcoin is returning higher fees for 36 block window than 2 block window (on testnet) · Issue #11800 · bitcoin/bitcoin · GitHub
292 2017-12-07 19:12:50	0|BlueMatt|well I think we've at least gotten 97% of it down, several folks looking into the last 3 and it may be a false positive
293 2017-12-07 19:12:51	0|Provoostenator|OOM?
294 2017-12-07 19:13:00	0|michagogo|Out Of Memory
295 2017-12-07 19:13:13	0|achow101|wumpus: the only known OOM right now is fixed by 11824
296 2017-12-07 19:13:18	0|BlueMatt|achow101: ibd seems less likely cause time spent downloading blocks is time for wallet to catch up...
297 2017-12-07 19:13:20	0|wumpus|achow101: ok
298 2017-12-07 19:13:42	0|wumpus|on to morcos' topic
299 2017-12-07 19:13:47	0|gribble|https://github.com/bitcoin/bitcoin/issues/11363 | net: Split socket create/connect by theuni · Pull Request #11363 · bitcoin/bitcoin · GitHub
300 2017-12-07 19:13:47	0|wumpus|#topic Bitcoin is returning higher fees for 36 block window than 2 block window (on testnet)
301 2017-12-07 19:14:12	0|wumpus|#action review #11363
302 2017-12-07 19:14:14	0|gribble|https://github.com/bitcoin/bitcoin/issues/11363 | net: Split socket create/connect by theuni · Pull Request #11363 · bitcoin/bitcoin · GitHub
303 2017-12-07 19:14:27	0|wumpus|anyone opposing 'wontfix' there?
304 2017-12-07 19:14:44	0|jonasschnelli|we should at least know why
305 2017-12-07 19:14:53	0|BlueMatt|jonasschnelli: morcos had a writeup on the issue
306 2017-12-07 19:15:00	0|jonasschnelli|#?
307 2017-12-07 19:15:01	0|cfields|BlueMatt: thanks :)
308 2017-12-07 19:15:06	0|BlueMatt|#11800
309 2017-12-07 19:15:06	0|morcos|11800
310 2017-12-07 19:15:07	0|gribble|https://github.com/bitcoin/bitcoin/issues/11800 | Bitcoin is returning higher fees for 36 block window than 2 block window (on testnet) · Issue #11800 · bitcoin/bitcoin · GitHub
311 2017-12-07 19:15:08	0|wumpus|morcos posted that
312 2017-12-07 19:15:09	0|wumpus|right
313 2017-12-07 19:16:09	0|wumpus|so the situation is pretty much unique to testnet and extremely unlikley on mainnet
314 2017-12-07 19:16:13	0|jonasschnelli|IMO low prio or even "won't fix"
315 2017-12-07 19:16:52	0|BlueMatt|yea, I mean I think I'd prefer to not call it "wont fix", but certainly not anything worth spending time on compared to other priorities
316 2017-12-07 19:16:53	0|wumpus|I tend to agree, very low priority if it only affects testnet's wildness
317 2017-12-07 19:17:24	0|jonasschnelli|what BlueMatt said
318 2017-12-07 19:17:35	0|wumpus|we kind of know that the current testnet isn't realistic
319 2017-12-07 19:17:45	0|wumpus|a frequent request is a more realistic testnet FWIW
320 2017-12-07 19:18:46	0|BlueMatt|suggested topic: testnet4
321 2017-12-07 19:19:02	0|midnightmagic|the data in tn3 is fairly valuable on its own. if any tn reset is being considered for a pullreq it would be really nice to effect a high-quality preservation of tn3. like an option or something to put it into archive-mode.
322 2017-12-07 19:19:20	0|BlueMatt|you mean as test-cases?
323 2017-12-07 19:19:27	0|promag|next topic? btw I would like to have more NACK/ACK on #11826
324 2017-12-07 19:19:29	0|gribble|https://github.com/bitcoin/bitcoin/issues/11826 | RFC: Activity feature · Issue #11826 · bitcoin/bitcoin · GitHub
325 2017-12-07 19:19:29	0|midnightmagic|as test-cases and historical reference.
326 2017-12-07 19:19:33	0|Provoostenator|What about cherry-picking interesting testnet3 transactions?
327 2017-12-07 19:19:56	0|wumpus|no tn reset is being considered
328 2017-12-07 19:20:08	0|jonasschnelli|That's more regression testing?
329 2017-12-07 19:20:18	0|BlueMatt|wumpus: please add comma, or do you mean we're not considering it?
330 2017-12-07 19:20:20	0|wumpus|keeping tn3 support is fine
331 2017-12-07 19:20:22	0|midnightmagic|okay. sorry, carry on. :)
332 2017-12-07 19:20:52	0|wumpus|BlueMatt: huh? yes I mean we're not considering it. Any new testnet would be an addition, I think.
333 2017-12-07 19:21:21	0|BlueMatt|I meannn...I guess thats fine? I think I was considering just moving to testnet4
334 2017-12-07 19:21:29	0|wumpus|(still not sure where to add the comma)
335 2017-12-07 19:21:49	0|BlueMatt|if nothing else testnet3 with a mindiff higher than 1, and to not have a million blocks
336 2017-12-07 19:22:09	0|BlueMatt|lots of complaints about even spv sync time in testnet3 cause of so many blocks
337 2017-12-07 19:22:12	0|morcos|i vote we do segwit wallet support first
338 2017-12-07 19:22:17	0|wumpus|there was some talk of doing a testnet with signed blocks which simulates behavior of the mainnet
339 2017-12-07 19:22:26	0|wumpus|morcos: yes, absolutely
340 2017-12-07 19:22:27	0|BlueMatt|i mean thats also of interest, yea
341 2017-12-07 19:22:37	0|phantomcircuit|huh what im here
342 2017-12-07 19:22:46	0|meshcollider|topic suggestion: the various config file PRs
343 2017-12-07 19:22:56	0|adiabat|testnet having lots of headers needed for SPV may motivate more efficient header transmission
344 2017-12-07 19:22:59	0|meshcollider|e.g. #10996 and #10267
345 2017-12-07 19:23:01	0|gribble|https://github.com/bitcoin/bitcoin/issues/10996 | Add per-network config file network.conf by ajtowns · Pull Request #10996 · bitcoin/bitcoin · GitHub
346 2017-12-07 19:23:04	0|gribble|https://github.com/bitcoin/bitcoin/issues/10267 | New -includeconf argument for including external configuration files by kallewoof · Pull Request #10267 · bitcoin/bitcoin · GitHub
347 2017-12-07 19:23:08	0|wumpus|#topic config file handling
348 2017-12-07 19:24:11	0|meshcollider|We have to work out what configurations we should support, e.g. whether -conf should be repeatable, whether we have -includeconf, -netconf and -conf, etc.
349 2017-12-07 19:24:18	0|wumpus|so the question is pretty much whether to do per-network config file
350 2017-12-07 19:24:23	0|jonasschnelli|IMO the config layers are already complex... not sure if we want to add more
351 2017-12-07 19:24:24	0|meshcollider|its getting a bit messy
352 2017-12-07 19:24:25	0|wumpus|or -testnet-X and -regtest-X
353 2017-12-07 19:24:38	0|jonasschnelli|There are serval levels and multiple files
354 2017-12-07 19:24:50	0|wumpus|where X are options like port, walletdir, logfile, which are only useful per network
355 2017-12-07 19:25:38	0|wumpus|currently if you define e.g. port or bind in bitcoin.conf you will get collisions when you run both testnet and mainnet on the same machine
356 2017-12-07 19:25:54	0|meshcollider|one idea I had was suggested in https://github.com/bitcoin/bitcoin/pull/10996#issuecomment-346189099, basically we default to using root-level bitcoin.conf and network specific network.conf if they exist, but if -conf is specified then we just use that and not the network specific one too
357 2017-12-07 19:26:02	0|wumpus|so one potential solution for that was to do per-network config files, but as said that makes things reallly complex
358 2017-12-07 19:26:08	0|meshcollider|and then allow -conf to be repeatable?
359 2017-12-07 19:26:12	0|wumpus|so an alternative proposal was just to do -regtest-port -testnet-port etc
360 2017-12-07 19:26:26	0|jonasschnelli|wumpus: +1
361 2017-12-07 19:26:31	0|aj|from 10267, having conf repeatable or includeconf recursive seems hard to implement well; currently it only handles a single additional config file aiui
362 2017-12-07 19:26:32	0|wumpus|and I think I like that
363 2017-12-07 19:26:39	0|meshcollider|wumpus what about unique addnode's for each network
364 2017-12-07 19:26:48	0|wumpus|so bare -port will be only for mainnet
365 2017-12-07 19:26:58	0|wumpus|meshcollider: -regtest-addnode -testnet-addnode
366 2017-12-07 19:27:19	0|meshcollider|so just allow -regtest or -testnet to be prefixed to any existing arg?
367 2017-12-07 19:27:23	0|promag|yes, I think that is pretty simple and clear
368 2017-12-07 19:27:33	0|promag|if not set, defaults to?
369 2017-12-07 19:27:43	0|wumpus|these can be specified in any config file or on the command line, no difference, no *context sensitivity* like per-network config files
370 2017-12-07 19:27:44	0|jonasschnelli|promag: the default :)
371 2017-12-07 19:27:48	0|wumpus|yes,the default
372 2017-12-07 19:28:07	0|meshcollider|and then still support  #10267 ?
373 2017-12-07 19:28:07	0|wumpus|meshcollider: yes
374 2017-12-07 19:28:09	0|gribble|https://github.com/bitcoin/bitcoin/issues/10267 | New -includeconf argument for including external configuration files by kallewoof · Pull Request #10267 · bitcoin/bitcoin · GitHub
375 2017-12-07 19:28:18	0|wumpus|includeconf is orthogonal
376 2017-12-07 19:28:34	0|wumpus|I see no reason why not
377 2017-12-07 19:28:37	0|meshcollider|yeah but it would allow -regtest-includeconf=whatever
378 2017-12-07 19:28:39	0|promag|jonasschnelli: default of the network right?
379 2017-12-07 19:28:44	0|meshcollider|so it could be good :)
380 2017-12-07 19:28:47	0|jonasschnelli|promag: yes
381 2017-12-07 19:28:48	0|wumpus|it's pretty standard these days to allow including config files from config files for daemons
382 2017-12-07 19:28:56	0|morcos|wait, just so i understand, if you run ./bitcoind -regtest , then do you also have to add -regtest- to each of your command line options
383 2017-12-07 19:28:59	0|morcos|that would be super annoying
384 2017-12-07 19:29:02	0|cfields|an alternative to that would be sections in a config file. and on the cmdline they'd look like namespaces. so, [testnet] port=5. or -testnet::port=5.
385 2017-12-07 19:29:08	0|wumpus|almost any program supporting config files supports that in any way
386 2017-12-07 19:29:12	0|promag|wumpus: yes, like inherit other config
387 2017-12-07 19:29:15	0|morcos|cfields: that soudns way better
388 2017-12-07 19:29:32	0|wumpus|cfields: fine with me too
389 2017-12-07 19:29:58	0|wumpus|it's just that per-network config files make things too complex, so I'd like to avoid that
390 2017-12-07 19:30:11	0|meshcollider|morcos: I guess anything without a prefix would be used no matter what network was chosen
391 2017-12-07 19:30:12	0|wumpus|which kind of namespacing whether it's [net]option or -net-option I don't mind much
392 2017-12-07 19:30:16	0|cfields|and in time the sections could potentially be broken out an included/inerited. but the simple change seems like a simple enough first step to me.
393 2017-12-07 19:30:46	0|jonasschnelli|but morcos point is valid. What if you just start use CLI params and switch between networks...
394 2017-12-07 19:30:46	0|wumpus|meshcollider: yeah...
395 2017-12-07 19:30:47	0|cfields|simple == simple. nice.
396 2017-12-07 19:30:48	0|morcos|seems like it would make a lot of sense to have a single conf file, that has sections : [default] [mainnet] [testnet] [regtest] and you always end up reading default and one of the others
397 2017-12-07 19:30:58	0|jonasschnelli|do you need to add/switch the namespace all the times?
398 2017-12-07 19:31:11	0|wumpus|morcos: yes
399 2017-12-07 19:31:24	0|aj|morcos: +1
400 2017-12-07 19:31:51	0|sipa|ok, back
401 2017-12-07 19:32:01	0|meshcollider|cool, next topic then :)
402 2017-12-07 19:32:07	0|wumpus|yes seems we agree
403 2017-12-07 19:32:12	0|promag|#11826
404 2017-12-07 19:32:13	0|gribble|https://github.com/bitcoin/bitcoin/issues/11826 | RFC: Activity feature · Issue #11826 · bitcoin/bitcoin · GitHub
405 2017-12-07 19:32:24	0|meshcollider|jonasschnelli: what do you mean
406 2017-12-07 19:32:40	0|jonasschnelli|meshcollider: solves with the namespaces described by morcos.
407 2017-12-07 19:32:43	0|jonasschnelli|*solved
408 2017-12-07 19:33:01	0|meshcollider|promag: I like 11826
409 2017-12-07 19:33:02	0|wumpus|#topic activity feature
410 2017-12-07 19:33:08	0|jnewbery|seems like the namespace model gives you separate conf files for free: just add a -includeconf in your relevant network namespace
411 2017-12-07 19:33:08	0|meshcollider|concept ACK from me
412 2017-12-07 19:33:09	0|jonasschnelli|Yes. We should have that
413 2017-12-07 19:33:14	0|wumpus|I think everyone likes 11826
414 2017-12-07 19:33:29	0|jonasschnelli|Bitcoin Core does a lot of things under the hood... and there is no way to see/control that
415 2017-12-07 19:33:29	0|promag|I have one problem there
416 2017-12-07 19:33:39	0|jonasschnelli|An activity window is something should have IMO
417 2017-12-07 19:33:44	0|promag|should the activity have a boost::variant<> source?
418 2017-12-07 19:33:45	0|BlueMatt|seems like putting the cart before the horse, as it were
419 2017-12-07 19:34:00	0|BlueMatt|like, the only things that can go *into* the activity window are things you do from rpc debug window
420 2017-12-07 19:34:01	0|promag|or should we have class WalletActivity : Activity ?
421 2017-12-07 19:34:09	0|jonasschnelli|BlueMatt: most stuff in there should be read-only...
422 2017-12-07 19:34:15	0|promag|BlueMatt: why?
423 2017-12-07 19:34:20	0|sipa|promag: seems like an implementation details
424 2017-12-07 19:34:23	0|BlueMatt|in that case, building an activity window should probably come after making rescan, etc things that users have access to
425 2017-12-07 19:34:34	0|sipa|BlueMatt: reindex-chainstate too
426 2017-12-07 19:34:58	0|BlueMatt|isnt reindex-chainstate handled like ibd?
427 2017-12-07 19:35:01	0|BlueMatt|(as it should be)/
428 2017-12-07 19:35:05	0|sipa|yes, it is
429 2017-12-07 19:35:12	0|BlueMatt|(cause we cant get a progress indicator for reindex-chainstate)
430 2017-12-07 19:35:22	0|sipa|?
431 2017-12-07 19:35:51	0|BlueMatt|I mean the only progress indicator you can do is the same as ibd
432 2017-12-07 19:36:05	0|promag|BlueMatt: in those cases it's an indeterminate progress bar
433 2017-12-07 19:36:16	0|jonasschnelli|Maybe we should first fix the rescan GUI "abortness", then continue with the activity window (will take a while)
434 2017-12-07 19:36:40	0|jonasschnelli|A single progress bar does certainly limit use cases.
435 2017-12-07 19:36:48	0|wumpus|yes
436 2017-12-07 19:37:14	0|jonasschnelli|BlueMatt: not only the user triggered ones...
437 2017-12-07 19:37:42	0|promag|BlueMatt: also, activities could stays on the window even after finished, like a log, or your download history
438 2017-12-07 19:37:53	0|BlueMatt|download history?
439 2017-12-07 19:37:59	0|BlueMatt|you mean rescan history
440 2017-12-07 19:37:59	0|sipa|i do agree there are relatively few use cases now, but the concept is useful... and i think eventually we want to be able to do things more concurrently anyway
441 2017-12-07 19:38:08	0|jonasschnelli|Yeah.. a mix between Activity and short term log would be possible
442 2017-12-07 19:38:08	0|promag|no, I mean browser download history
443 2017-12-07 19:38:09	0|jonasschnelli|but hard to make it right
444 2017-12-07 19:38:16	0|promag|it's more friendly than a raw log
445 2017-12-07 19:38:28	0|phantomcircuit|BlueMatt, lots of users complain about ibd apparently stalling, something that indicated what was happening would be good
446 2017-12-07 19:38:41	0|jonasschnelli|[disappearing message] new block validated \n [disappearing message] new peer 1.1.1.1 connected
447 2017-12-07 19:38:52	0|BlueMatt|I mean if I'm a user, I dont really want to see a progress history thing, tbh....either I have all the transactions in my wallet or I dont...
448 2017-12-07 19:39:17	0|wumpus|for that, a debug log view would be more useful
449 2017-12-07 19:39:23	0|wumpus|let's not conflate ongoing activities with a log
450 2017-12-07 19:39:25	0|cfields|:q
451 2017-12-07 19:39:32	0|cfields|er, heh
452 2017-12-07 19:39:42	0|jonasschnelli|heh... Yes.
453 2017-12-07 19:40:12	0|jonasschnelli|previous attempts that are more or less a log where kinda accepted #5896
454 2017-12-07 19:40:14	0|gribble|https://github.com/bitcoin/bitcoin/issues/5896 | [Qt][PoC] introduce "core-pulse" by jonasschnelli · Pull Request #5896 · bitcoin/bitcoin · GitHub
455 2017-12-07 19:40:19	0|promag|ok, I'll try to keep it simple
456 2017-12-07 19:40:24	0|BlueMatt|but, ongoing activities are like....rescan, just rescan, and thats not something you should do all that often...ibd/reindex/sync is a rather separate thing
457 2017-12-07 19:40:47	0|BlueMatt|but, anyway, it sounds like I'm the only one who disagrees, so I'm happy to shut up :p
458 2017-12-07 19:40:57	0|wumpus|sending a transaction is also an ongoing activity
459 2017-12-07 19:41:14	0|wumpus|ideally the GUI would move to do all those things asynchronously instead of in the GUI thread
460 2017-12-07 19:41:17	0|BlueMatt|I mean it sounds like y'all want to restructure our entire gui around an activity log...
461 2017-12-07 19:41:19	0|achow101|I also don't really see the utility of an activity window. but I don't really care either way
462 2017-12-07 19:41:25	0|promag|un/loading wallets too
463 2017-12-07 19:41:34	0|wumpus|no, I want to structure the GUI asynchronously
464 2017-12-07 19:41:46	0|wumpus|an activity thing would be a nice thing that comes with it
465 2017-12-07 19:41:52	0|BlueMatt|sending txn is rather async already, no? I mean you send and then you wait on confirms, maybe with a feebump
466 2017-12-07 19:42:27	0|BlueMatt|(at a user level, that is)
467 2017-12-07 19:43:07	0|jonasschnelli|Lets promag work on that concept and see where it leads to. It's certenly good to have it around in case we can do more stuff in parallel and have other cases where we want to show progress
468 2017-12-07 19:43:12	0|wumpus|the point is that comments are executed in the GUI thread, with the various locks held
469 2017-12-07 19:43:15	0|wumpus|commands*
470 2017-12-07 19:43:38	0|jonasschnelli|Also it would be useful for IPC (GUI / node detatch)
471 2017-12-07 19:43:40	0|instagibbs|probably makes more sense if the wallet is more goal-driven, for now I don't mind the feature
472 2017-12-07 19:43:48	0|instagibbs|(re: wallet comments)
473 2017-12-07 19:44:08	0|wumpus|which is not a nice user experience
474 2017-12-07 19:44:12	0|promag|ok guys, I'll file the PR soon
475 2017-12-07 19:44:55	0|wumpus|e.g. what I've noticed is that when it's catching up to the chain, getting the information for coin control hangs the entire GUI for half a minute sometimes
476 2017-12-07 19:45:12	0|wumpus|which would be fine if it showed a progress indicator but not if everything just blocks
477 2017-12-07 19:45:29	0|Randolf|That would likely cause many users to think it crashed.
478 2017-12-07 19:45:41	0|wumpus|well the window manager starts to think that too
479 2017-12-07 19:45:43	0|wumpus|and wants to kill it
480 2017-12-07 19:46:10	0|jonasschnelli|The GUI synchronousness does sometimes lead to terrible UX.
481 2017-12-07 19:46:12	0|Randolf|Yes.  And under the Windows OS, the user sees a message along the lines of "Task not responding" with an option to kill the task.
482 2017-12-07 19:46:53	0|wumpus|jonasschnelli: it was always my intent to change that but I just don't get around to it
483 2017-12-07 19:47:05	0|jonasschnelli|wumpus: it's also pretty complex
484 2017-12-07 19:47:13	0|wumpus|nah, not really complex, just work
485 2017-12-07 19:47:17	0|BlueMatt|yea, cs_main-y-ness of gui sucks atm :(
486 2017-12-07 19:47:17	0|Randolf|So, if the GUI is on a separate thread, then it can always respond to the OS and the user's operations (e.g., open the Help menu, load/save wallets, print reports, etc.) while waiting for updates from the other threads.
487 2017-12-07 19:47:41	0|jonasschnelli|Randolf: we are trying that (ask ryanofsky) :)
488 2017-12-07 19:47:43	0|wumpus|Randolf: right
489 2017-12-07 19:47:51	0|Randolf|jonasschnelli:  Cool!
490 2017-12-07 19:48:30	0|BlueMatt|anyway, more topics in 10 minutes?
491 2017-12-07 19:48:43	0|sipa|i have one
492 2017-12-07 19:48:54	0|sipa|would a libgmp dependency by acceptable?
493 2017-12-07 19:49:20	0|BlueMatt|for....secp? or your muhash stuff?
494 2017-12-07 19:49:32	0|Randolf|jonasschnelli:  I've done a lot of Java development, and this is how JFC/Swing and the newer JavaFX handle things.  The use of atomic variables and thread-safe queues becomes pretty important.  Maybe the original GUI for Bitcoin was designed with more development convenience in mind just so that the
495 2017-12-07 19:49:32	0|Randolf|project could get completed faster?  I don't consider this to be a bad thing, necessarily, but I'm glad to know that there's an interest in improving this.
496 2017-12-07 19:49:33	0|BlueMatt|I mean doesnt secp optionally use it already?
497 2017-12-07 19:49:46	0|wumpus|#topic libgmp dependency
498 2017-12-07 19:49:54	0|wumpus|libgmp is GPL right?
499 2017-12-07 19:50:04	0|sipa|BlueMatt: it does, and there is a small performanc benefit from using it for validation itself
500 2017-12-07 19:50:09	0|wumpus|if it's MIT/BSD licensed it's ok with me
501 2017-12-07 19:50:11	0|meshcollider|wumpus: yep I think so
502 2017-12-07 19:50:17	0|wumpus|but if it's GPL, we have to say no
503 2017-12-07 19:50:18	0|sipa|but for UTXO hashes it would be a huge difference
504 2017-12-07 19:50:22	0|cfields|sipa: i assume you mean a non-optional dep?
505 2017-12-07 19:50:22	0|sipa|i see
506 2017-12-07 19:50:34	0|sipa|it's LGPLv3
507 2017-12-07 19:50:44	0|sipa|cfields: right
508 2017-12-07 19:50:50	0|ryanofsky|Randolf maybe see https://github.com/bitcoin/bitcoin/pull/10244 which separates bitcoin gui code from wallet/node code
509 2017-12-07 19:51:23	0|meshcollider|sipa: also uses GPLv2 I think
510 2017-12-07 19:51:27	0|wumpus|there's really no other library implementing that?
511 2017-12-07 19:51:30	0|Randolf|Thanks ryanofsky.
512 2017-12-07 19:51:40	0|wumpus|(which could have a more suitable license)
513 2017-12-07 19:51:49	0|sipa|wumpus: specifically, it's for jacobi symbol computation
514 2017-12-07 19:51:56	0|aj|meshcollider: it's user's discretion as to GPLv2+ or LGPLv3+
515 2017-12-07 19:52:05	0|cfields|sipa: license aside, it would feel a little backwards to introduce a new dep which may at some point be consensus critical :(
516 2017-12-07 19:52:09	0|sipa|which is not impossible to implement ourselves, and probably faster if we do, but it's very nontrivial
517 2017-12-07 19:52:12	0|sipa|cfields: it wouldn't be
518 2017-12-07 19:52:39	0|sipa|cfields: everything we'd use would be verified
519 2017-12-07 19:52:47	0|wumpus|cfields: also agree with that
520 2017-12-07 19:53:01	0|wumpus|so apart from using libgmp and implementing it ourselves there are no options?
521 2017-12-07 19:53:14	0|sipa|or take the performance hit
522 2017-12-07 19:53:21	0|aj|sipa: context is #10434 ?
523 2017-12-07 19:53:23	0|gribble|https://github.com/bitcoin/bitcoin/issues/10434 | [WIP] 3072-bit MuHash based hash_serialized by sipa · Pull Request #10434 · bitcoin/bitcoin · GitHub
524 2017-12-07 19:53:46	0|sipa|10434 uses the modular multiplication group approach, which doesn't need this - it's faster but much harder to cache
525 2017-12-07 19:54:37	0|sipa|the alternative approach is using EC based rolling hashes, for which using jacobi symbols would be a 2x speedup or so
526 2017-12-07 19:54:49	0|sipa|wumpus: so a 3rd option is not implementing EC-based rolling hashes
527 2017-12-07 19:54:50	0|promag|out-of-battery o/
528 2017-12-07 19:55:44	0|wumpus|also after all the work that was done to lose dependency on openssl for bignums, to introduce dependency on a new arbitrary precision library seems also a reversal to me
529 2017-12-07 19:55:47	0|sipa|so i just wanted to bring it up to see what the option were
530 2017-12-07 19:55:49	0|BlueMatt|so if we use lgpl gmp as a dep, and then someone wants to ship a bitcoincore-modified binary with all deps static-linked, they'd be screwed?
531 2017-12-07 19:56:11	0|sipa|wumpus: to be clear, nothing would be consensus critical (even if rolling hashes were somehow made a consensus rule)
532 2017-12-07 19:56:22	0|aj|BlueMatt: lgpl means they'd have to release sources or their .o/.a files
533 2017-12-07 19:57:02	0|BlueMatt|yea, ok, i meannnn, probably fine, but that is a real change in effective license of bitcoin core
534 2017-12-07 19:57:11	0|morcos|sipa: 2x speedup in what exactly
535 2017-12-07 19:57:30	0|morcos|when would those computations happen and what is the base latency
536 2017-12-07 19:57:40	0|cfields|sipa: at the risk of going too far off-topic, aren't there curves with potentially quicker and guaranteed O(1) map operations?
537 2017-12-07 19:58:05	0|morcos|piont being, perhaps we can punt on the question of libgmp until it becomes clear that optimizing the speed is an important tradeoff to make
538 2017-12-07 19:58:18	0|wumpus|good point morcos
539 2017-12-07 19:58:19	0|instagibbs|morcos, +1
540 2017-12-07 19:58:28	0|sipa|cfields: let's discuss outside of the meeting
541 2017-12-07 19:58:28	0|sipa|morcos: updating a rolling hash given a set of UTXOs created and spent
542 2017-12-07 19:58:40	0|cfields|ok
543 2017-12-07 19:58:50	0|BlueMatt|well meeting over anyway
544 2017-12-07 19:58:58	0|gmaxwell|ugh was missing meeting.
545 2017-12-07 19:59:05	0|instagibbs|gmaxwell, 2 minutes
546 2017-12-07 19:59:06	0|instagibbs|1 minute
547 2017-12-07 19:59:07	0|morcos|right, so how often are we envisioning doing that, does it happen async to everything else, and how long does it take without libgmp
548 2017-12-07 19:59:10	0|gmaxwell|why did we start talking about libgmp? :(
549 2017-12-07 19:59:13	0|sipa|in an absolutely first implementation, i would expect that that would just affect gettxoutsetinfo or its equivalent that just computes the hash from the UTXO set from scratch
550 2017-12-07 19:59:18	0|BlueMatt|gmaxwell: blame sipa
551 2017-12-07 19:59:41	0|gmaxwell|sipa: we do not want gmp as part of bitcoin's consensus critical paths,  totally independently of using it as a dependency.
552 2017-12-07 19:59:46	0|sipa|fatal: cannot stat path 'sipa': No such file or directory
553 2017-12-07 19:59:46	0|sipa|$ git blame sipa
554 2017-12-07 19:59:51	0|BlueMatt|yes, that point was made
555 2017-12-07 19:59:56	0|sipa|gmaxwell: absolutely
556 2017-12-07 20:00:01	0|sipa|no intention of changing that
557 2017-12-07 20:00:27	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-12-07-19.00.log.html
558 2017-12-07 20:00:27	0|lightningbot|Meeting ended Thu Dec  7 20:00:26 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
559 2017-12-07 20:00:27	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-12-07-19.00.html
560 2017-12-07 20:00:27	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-12-07-19.00.txt
561 2017-12-07 20:00:27	0|wumpus|#endmeeting
562 2017-12-07 20:00:39	0|gmaxwell|ah, you were talking about it for the jacobi symbol for aggregate validation?
563 2017-12-07 20:00:55	0|aj|libzmq is lgpl isn't it?
564 2017-12-07 20:00:56	0|wumpus|yes
565 2017-12-07 20:01:08	0|wumpus|aj: no
566 2017-12-07 20:01:30	0|sipa|more in the context of rolling hashes
567 2017-12-07 20:01:31	0|wumpus|aj: oh, you're actually right
568 2017-12-07 20:01:38	0|wumpus|aj: wtf, I never knew
569 2017-12-07 20:01:54	0|wumpus|aj: however zmq is optional
570 2017-12-07 20:02:38	0|BlueMatt|that sucks...our release binaries have lgpl crap in them and we dont have an easy way to get a bitcoind that is linked to everything but zmq?
571 2017-12-07 20:02:52	0|aj|the release binaries have zmq now?
572 2017-12-07 20:02:56	0|BlueMatt|almost certainly are
573 2017-12-07 20:03:08	0|achow101|releases have zmq and have had them for a while now
574 2017-12-07 20:05:34	0|wumpus|--disable-zmq
575 2017-12-07 20:06:13	0|wumpus|(or was it --without-zmq, I don't remember)
576 2017-12-07 20:07:20	0|wumpus|my preferred way for not linking against something is just to not have it installed on the VM
577 2017-12-07 20:10:23	0|aj|wumpus: btw, i got a manually runnable script that gives some approximate pr status's that might be worth a look; script and (edited) output are at https://gist.github.com/ajtowns/bdc91590471559b5c73682fdfa712b15
578 2017-12-07 20:12:45	0|jonasschnelli|aj: nice!
579 2017-12-07 20:12:59	0|aj|#10520 and #10149 could probably be closed
580 2017-12-07 20:13:01	0|gribble|https://github.com/bitcoin/bitcoin/issues/10520 | 0.14 by gentlejack · Pull Request #10520 · bitcoin/bitcoin · GitHub
581 2017-12-07 20:13:02	0|sc__|hi!
582 2017-12-07 20:13:04	0|gribble|https://github.com/bitcoin/bitcoin/issues/10149 | gentlejack by gentlejack · Pull Request #10149 · bitcoin/bitcoin · GitHub
583 2017-12-07 20:13:15	0|wumpus|aj: cool
584 2017-12-07 20:13:47	0|jonasschnelli|aj: What I really would like to have is something like this in a web-base script (CGI)
585 2017-12-07 20:13:49	0|sc__|does anybody know by chance, why bitcoind regtest is missing witness data in p2p messages?
586 2017-12-07 20:14:17	0|sc__|and how to get witness data via p2p?
587 2017-12-07 20:14:21	0|instagibbs|sc__, make sure you actually activated segwit by making a few hundred blocks...
588 2017-12-07 20:14:31	0|jonasschnelli|aj: That web-site/app could be an interactive mode of that script you wrote with some cookie based local editing... one could flag the PRs he wants to review (locally stored)
589 2017-12-07 20:14:32	0|wumpus|for me a console-based tool is better
590 2017-12-07 20:14:53	0|jonasschnelli|wumpus: nerd! :)
591 2017-12-07 20:14:54	0|sc__|instagibbs: I really did this (the block count is over 11000 now)
592 2017-12-07 20:14:55	0|jonasschnelli|wumpus: Yeah.. consol based would even make more sense...
593 2017-12-07 20:15:06	0|jonasschnelli|not sure if ncurses is more complex then HTML
594 2017-12-07 20:15:06	0|wumpus|jonasschnelli: just extremely paranoid :)
595 2017-12-07 20:15:48	0|jonasschnelli|wumpus: But I guess at some point, you have to link to the github issue to read more about it... or do you use lynx or some sort of console browsing?
596 2017-12-07 20:16:30	0|instagibbs|aj, very cool
597 2017-12-07 20:16:49	0|wumpus|jonasschnelli: sometimes, but lynx doesn't work very well/at all on github
598 2017-12-07 20:17:04	0|instagibbs|aj, maybe the submitter shouldn't be able to advance their own PR's labels, heh
599 2017-12-07 20:17:21	0|jonasschnelli|aj's tool should also include the discussion,.. ideally it would be a full fletched github console client... :)
600 2017-12-07 20:18:20	0|wumpus|jonasschnelli: I think it's a good argument for the tool to be low-level, just print the data in some format - anything like a UI can be added on top
601 2017-12-07 20:18:36	0|aj|instagibbs: oh, did someone ack their own PR? i didn't put a check in for that in the python version
602 2017-12-07 20:18:38	0|jonasschnelli|sure. However, well done aj
603 2017-12-07 20:19:03	0|instagibbs|aj you did in your PR testing it :P, unless I missed something
604 2017-12-07 20:19:15	0|jonasschnelli|kallewoof: re your BIP174,... I guess this also works perfectly fine for pure unsigned transaction...
605 2017-12-07 20:19:31	0|aj|instagibbs: oh, yeah, in that i specifically disabled the check so i could test it :)
606 2017-12-07 20:19:36	0|wumpus|and aj wrote it in python instead of (s)hellscript, I like that
607 2017-12-07 20:20:05	0|aj|wumpus: oh, i have some curl|jshon for loops i was using earlier if you prefer :)
608 2017-12-07 20:20:08	0|jonasschnelli|kallewoof: the "partially signed" tag makes it look that is "partially" unusable for pure softwallet<->hardware wallet interaction
609 2017-12-07 20:20:14	0|wumpus|aj: nooooooo :)
610 2017-12-07 20:20:47	0|aj|wumpus: curl -s https://api.github.com/repos/bitcoin/bitcoin/pulls?"page=$a;per_page=100" | jshon -a -e number -u -p -e updated_at -u -p -e head -e sha -u -p -p -e base -e ref -u; done | paste -s -d '   \n'
611 2017-12-07 20:21:22	0|instagibbs|jonasschnelli, link? haven't seen recent work on it
612 2017-12-07 20:21:46	0|jonasschnelli|https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki
613 2017-12-07 20:21:48	0|instagibbs|I have an ugly hww integration working, but am looking for a more generic signraw API
614 2017-12-07 20:21:59	0|instagibbs|jonasschnelli, I mean why kallewoof ? achow101 is the author of the bip?
615 2017-12-07 20:22:17	0|jonasschnelli|instagibbs: argh! Right... meant achow101
616 2017-12-07 20:22:34	0|instagibbs|aw darn :) thinking of writing that interface anyways...
617 2017-12-07 20:24:33	0|achow101|jonasschnelli: hmm?
618 2017-12-07 20:24:44	0|jonasschnelli|achow101: re your BIP174...
619 2017-12-07 20:25:03	0|instagibbs|jonasschnelli, yes the idea is that createraw, or something, would create a thing that is potentially signable
620 2017-12-07 20:25:04	0|jonasschnelli|I'm looking for a standard how software watch-only wallets (assume Core) can talk to a hardware wallet
621 2017-12-07 20:25:26	0|jonasschnelli|Need to read more into the BIP... but seems 174 does cover that case pretty well
622 2017-12-07 20:25:34	0|wumpus|seems there is suddenly lots of interest in signing messages
623 2017-12-07 20:25:35	0|aj|jonasschnelli: anyhoo, i could turn that RESULTS.txt into some html with links and nicer formatting, updated by cron once an hour or something without too much trouble; making it properly dynamic/current would take some effort though. worthwhile?
624 2017-12-07 20:25:51	0|achow101|jonasschnelli: how would it be unusable?
625 2017-12-07 20:26:08	0|jonasschnelli|wumpus: yeah! I'm feeling like I'm missing a party... don't know what people do sign now all the times
626 2017-12-07 20:26:49	0|instagibbs|wumpus, this time it's transactions, we swear!
627 2017-12-07 20:26:55	0|jonasschnelli|achow101: Assume I have a Core in watch only mode and did a fundrawtransaction with watch only inputs... then I'd like to hand "it" over to the hardware wallet.
628 2017-12-07 20:27:02	0|jonasschnelli|achow101: What data and what schemantics do I use
629 2017-12-07 20:27:09	0|jonasschnelli|BIP174 would be a way? woudln't it?
630 2017-12-07 20:27:18	0|achow101|yes, bip174 would
631 2017-12-07 20:27:46	0|jonasschnelli|because there is no other standard how to serialize a data-blob including the inputs and other elements required for signing
632 2017-12-07 20:27:56	0|instagibbs|that was the reason for the bip, ye
633 2017-12-07 20:28:04	0|achow101|the hardware wallet interaction was one of the motivators for making the bip
634 2017-12-07 20:28:13	0|jonasschnelli|achow101: would a mime type make sense?
635 2017-12-07 20:28:32	0|jonasschnelli|instagibbs: or what channels to transmit your data-package have you considered?
636 2017-12-07 20:28:37	0|jonasschnelli|mean achow101
637 2017-12-07 20:28:38	0|wumpus|aj: gives me a TypeError: https://0bin.net/paste/wG-O21gNtVhwBDA3#Y0XyZu5-tENRZZZSy14gX41LNcF9okNM2sTlIvnsvhK
638 2017-12-07 20:28:55	0|achow101|jonasschnelli: I haven't considered any channel for transmitting the data itself.
639 2017-12-07 20:29:02	0|achow101|I considered that to be out of scope
640 2017-12-07 20:29:09	0|aj|wumpus: you probably hit the rate limit
641 2017-12-07 20:29:37	0|achow101|jonasschnelli: I think that such a protocol would be a separate bip entirely as you could transmit the data any number of ways
642 2017-12-07 20:29:48	0|wumpus|aj: oh I should buy more github tokens? :p
643 2017-12-07 20:29:58	0|aj|wumpus: get a token from https://github.com/settings/tokens and set GITHUB_LOGIN=laanw and GITHUB_PASSWORD= your token.
644 2017-12-07 20:30:20	0|wumpus|ok, thanks
645 2017-12-07 20:30:25	0|jonasschnelli|achow101: yes... hard to figure out what ways could be standartized
646 2017-12-07 20:33:22	0|wumpus|aj: oh wowthis is pretty neat, even allows setting permissions per token
647 2017-12-07 20:33:56	0|aj|wumpus: yeah, doesn't suck.
648 2017-12-07 20:33:58	0|wumpus|I guess it needs no permissions at all as it's read-only?
649 2017-12-07 20:34:03	0|aj|wumpus: yup
650 2017-12-07 20:35:03	0|wumpus|I wish github ssh keys could be configured in the same way, e.g. a certain key can be set to only allow to push to a certain project
651 2017-12-07 20:37:44	0|aj|wumpus: guess they want you do do that by protecting branchs and pull request statuses (like "can't merge if travis doesn't give the ok")
652 2017-12-07 20:38:59	0|wumpus|aj: yes that can only allow certain users to push to certain branches, which is extremely useful
653 2017-12-07 20:39:45	0|wumpus|aj: but in my case it'd be useful to have a certain VM/user only have keys to push to a certain repo and not all repos my account has access to. I could create multiple accounts but meh.
654 2017-12-07 20:41:28	0|wumpus|aj: anyhow github has improved a lot with regard to more granular access control in the last few years which is very good
655 2017-12-07 20:42:26	0|aj|wumpus: i think you could make a "github app" which you could then assign to a repo and which could maybe then push to non-protected branches...
656 2017-12-07 20:43:20	0|wumpus|aj: yep non-protected branches would be fine; allow it to push to laanwj/bitcoin but not bitcoin/bitcoin master for example
657 2017-12-07 20:44:19	0|aj|wumpus: hmm, i might see if that works actually. i was thinking about having lightningbot update a repo of its meeting logs automatically (and use an Attendees file there to pick people to highlight), but got stuck on how to push... https://github.com/ajtowns/bitcoin-core-meetings
658 2017-12-07 20:46:31	0|wumpus|aj: I've enabled the token and with that, check_acks ran to completion without error, thanks
659 2017-12-07 20:56:25	0|promag|wumpus: considering the current lockunspent help description, #5584 can be closed right?
660 2017-12-07 20:56:33	0|gribble|https://github.com/bitcoin/bitcoin/issues/5584 | Ability to examine, save locked-UTXO state · Issue #5584 · bitcoin/bitcoin · GitHub
661 2017-12-07 20:58:27	0|wumpus|promag: I'm not sure; what does the help description change about a feature request?
662 2017-12-07 20:59:00	0|promag|ah right, feature request
663 2017-12-07 20:59:33	0|promag|not really something important to implement right?
664 2017-12-07 21:00:08	0|wumpus|no
665 2017-12-07 21:01:35	0|wumpus|well there are certainly use-cases for persistently locking UTXOs in the wallet
666 2017-12-07 21:03:06	0|wumpus|less if 'abandontransaction' always worked
667 2017-12-07 21:04:17	0|wumpus|the most common use case of locking UTXOs persistently would be a transaction, I think where the use case for explicit locking comes from is to be able to unlock them easily again, which isn't possible with the current wallet code
668 2017-12-07 21:07:39	0|wumpus|how long does it take for github to forgive you for rate limit exceeding? I can't use github-merge.py either anymore from this IP :-)
669 2017-12-07 21:09:58	0|promag|wumpus: I know a use case where there is explicit locking, and because of the lack of lock persistence, the locks are saved outside and verified/repeated
670 2017-12-07 21:10:25	0|wumpus|promag: yeah...
671 2017-12-07 21:13:17	0|aj|wumpus: curl -s -i https://api.github.com/repos/bitcoin/bitcoin/projects | grep ^X-RateLimit
672 2017-12-07 21:13:46	0|aj|wumpus: the RateLimit-Reset should give you a timestamp under an hour away
673 2017-12-07 21:14:44	0|wumpus|aj: X-RateLimit-Reset: 1512681788 -> date --date='@1512681788' -> Thu Dec  7 22:23:08 CET 2017
674 2017-12-07 21:15:04	0|wumpus|aj: ok, I'll probably not manage to add authentication support to gh-merge.py before then