1 2016-04-07 00:01:02	0|jtimon|never mind, origin/0.12 already has 68/112/113
  2 2016-04-07 07:21:25	0|jonasschnelli|wumpus: does "getlabeladdress" would still make sense for labels only? https://github.com/bitcoin/bitcoin/pull/7729/files#diff-df7d84ff2f53fcb2a0dc15a3a51e55ceR2506
  3 2016-04-07 07:21:36	0|jonasschnelli|What if an the same label is used for multiple addresses?
  4 2016-04-07 07:21:58	0|wumpus|jonasschnelli: I don't think so, I say the same in my OP :) (see the discussion with Luke-Jr in the pull)
  5 2016-04-07 07:22:07	0|jonasschnelli|Okay.
  6 2016-04-07 07:22:36	0|wumpus|he's using the functionality for his miner and that was my only reason to make that consession, I suggested another way of working but haven't heard back.
  7 2016-04-07 07:22:38	0|jonasschnelli|Haven't seen that.
  8 2016-04-07 07:23:15	0|jonasschnelli|I cloned now the wallet, made it runnable in parallel and removing accounts. I take some parts out of 7729
  9 2016-04-07 07:25:06	0|wumpus|awesome!
 10 2016-04-07 07:28:13	0|wumpus|well I wouldn't blame you if you don't take getlabeladdress, it makes very little sense for labels and makes it necessary to keep around a CAccount structure we'd rather get rid of. I honestly think he should find a different solution
 11 2016-04-07 07:35:33	0|jonasschnelli|Yes. I have removed it.
 12 2016-04-07 08:53:31	0|GitHub110|[13bitcoin] 15jonasschnelli opened pull request #7830: [Wallet] Add cloned wallet, remove accounts, reset version (06master...062016/04/wallet2) 02https://github.com/bitcoin/bitcoin/pull/7830
 13 2016-04-07 09:34:03	0|GitHub72|[13bitcoin] 15jonasschnelli opened pull request #7831: [CLI] refactor wallets RPC JSON conversions (06master...062016/04/cli_conversion) 02https://github.com/bitcoin/bitcoin/pull/7831
 14 2016-04-07 09:59:33	0|wumpus|for anyone that wants to do perf measurements of their own I've open sourced the lmdb experiment, be sure to read README.md https://github.com/laanwj/bitcoin/tree/2016_04_mdb
 15 2016-04-07 10:02:21	0|sipa|If you manage to
 16 2016-04-07 10:02:21	0|sipa|+suffer financial or other losses due to this code I demand compensation for
 17 2016-04-07 10:02:24	0|sipa|+feelings of misplaced guilt.
 18 2016-04-07 10:02:26	0|sipa|LOL
 19 2016-04-07 10:03:24	0|wumpus|:-)
 20 2016-04-07 10:59:52	0|GitHub82|13bitcoin/06master 1407398e8 15Wladimir J. van der Laan: init: allow shutdown during 'Activating best chain...'...
 21 2016-04-07 10:59:52	0|GitHub82|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/3bc71e1572cb...bbaf5976af84
 22 2016-04-07 10:59:53	0|GitHub82|13bitcoin/06master 14bbaf597 15Wladimir J. van der Laan: Merge #7821: init: allow shutdown during 'Activating best chain...'...
 23 2016-04-07 10:59:56	0|GitHub122|[13bitcoin] 15laanwj closed pull request #7821: init: allow shutdown during 'Activating best chain...' (06master...062016_04_shutdown_during_activate_best_chain) 02https://github.com/bitcoin/bitcoin/pull/7821
 24 2016-04-07 11:00:58	0|GitHub0|13bitcoin/060.12 144226aac 15Wladimir J. van der Laan: init: allow shutdown during 'Activating best chain...'...
 25 2016-04-07 11:00:58	0|GitHub0|[13bitcoin] 15laanwj pushed 1 new commit to 060.12: 02https://github.com/bitcoin/bitcoin/commit/4226aacdba7d0e1e22555dac69363b3b460a166b
 26 2016-04-07 11:07:31	0|GitHub95|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/bbaf5976af84...1ddf0cee679d
 27 2016-04-07 11:07:32	0|GitHub95|13bitcoin/06master 140e24bbf 15Pieter Wuille: Self check after the last peer is removed
 28 2016-04-07 11:07:32	0|GitHub95|13bitcoin/06master 142d1d658 15Pieter Wuille: Track block download times per individual block...
 29 2016-04-07 11:07:33	0|GitHub95|13bitcoin/06master 141ddf0ce 15Wladimir J. van der Laan: Merge #7804: Track block download times per individual block...
 30 2016-04-07 11:07:41	0|GitHub85|[13bitcoin] 15laanwj closed pull request #7804: Track block download times per individual block (06master...06betterkicktimeout) 02https://github.com/bitcoin/bitcoin/pull/7804
 31 2016-04-07 11:16:40	0|GitHub39|13bitcoin/060.12 1490f1d24 15Pieter Wuille: Track block download times per individual block...
 32 2016-04-07 11:16:40	0|GitHub39|[13bitcoin] 15laanwj pushed 1 new commit to 060.12: 02https://github.com/bitcoin/bitcoin/commit/90f1d246d38803eb546c6652ddce5ebea55eec98
 33 2016-04-07 11:19:35	0|GitHub161|[13bitcoin] 15laanwj opened pull request #7832: Reduce block timeout to 10 minutes (06master...062016_04_reduce_block_timeout) 02https://github.com/bitcoin/bitcoin/pull/7832
 34 2016-04-07 11:44:13	0|jonasschnelli|wumpus: did you already try to run it (your LMDB branch) on a standard 64 bit Linux?
 35 2016-04-07 11:44:29	0|wumpus|yep
 36 2016-04-07 11:44:54	0|wumpus|passes the tests and seems to work
 37 2016-04-07 11:45:18	0|jonasschnelli|Okay. Then I'll give it a try on my Debian Server (fresh sync from random peers).
 38 2016-04-07 11:52:58	0|GitHub3|13bitcoin/06master 1462b9a55 15Wladimir J. van der Laan: Reduce block timeout to 10 minutes...
 39 2016-04-07 11:52:58	0|GitHub3|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/1ddf0cee679d...5851915a006a
 40 2016-04-07 11:52:59	0|GitHub3|13bitcoin/06master 145851915 15Wladimir J. van der Laan: Merge #7832: Reduce block timeout to 10 minutes...
 41 2016-04-07 11:53:05	0|GitHub61|[13bitcoin] 15laanwj closed pull request #7832: Reduce block timeout to 10 minutes (06master...062016_04_reduce_block_timeout) 02https://github.com/bitcoin/bitcoin/pull/7832
 42 2016-04-07 11:58:45	0|jonasschnelli|wumpus: is there a reason to reserve 8GB for the chainstate2/data.mdb db?
 43 2016-04-07 11:58:56	0|jonasschnelli|or is that just on my end...
 44 2016-04-07 11:59:08	0|wumpus|well it's bound to not be too little, for now
 45 2016-04-07 11:59:20	0|wumpus|see https://github.com/laanwj/bitcoin/tree/2016_04_mdb#mapsize
 46 2016-04-07 11:59:44	0|jonasschnelli|Ah. The readme was shortened on my smartphone. Nice.
 47 2016-04-07 11:59:54	0|wumpus|you can patch the code to set it lower, but I didn't feel like finding the lower bound
 48 2016-04-07 12:00:59	0|GitHub32|13bitcoin/060.12 144c3a00d 15Wladimir J. van der Laan: Reduce block timeout to 10 minutes...
 49 2016-04-07 12:00:59	0|GitHub32|[13bitcoin] 15laanwj pushed 2 new commits to 060.12: 02https://github.com/bitcoin/bitcoin/compare/90f1d246d388...cada7c2418ef
 50 2016-04-07 12:01:00	0|GitHub32|13bitcoin/060.12 14cada7c2 15Wladimir J. van der Laan: Fill in rest of release notes
 51 2016-04-07 12:01:28	0|jonasschnelli|> Only 64-bit. Sorry, life is not fair.
 52 2016-04-07 12:01:29	0|jonasschnelli|hah
 53 2016-04-07 12:02:39	0|wumpus|doing some last-minute tests, going to tag 0.12.0rc1 in a bit
 54 2016-04-07 12:03:32	0|assder|0.12.1rc1?
 55 2016-04-07 12:03:41	0|wumpus|yes, .1
 56 2016-04-07 12:09:13	0|wumpus|:D
 57 2016-04-07 12:10:41	0|sipa|hmm, wallet.py rpc test doesn't work here, even though i didn't change anything wallet related
 58 2016-04-07 12:11:08	0|wumpus|on 0.12?
 59 2016-04-07 12:11:31	0|wumpus|Passed here: Running testscript wallet.py ... Tests successful Duration: 62 s
 60 2016-04-07 12:12:30	0|sipa|no, master
 61 2016-04-07 12:12:40	0|sipa|Unexpected exception caught during testing: No JSON object could be decoded
 62 2016-04-07 12:13:28	0|sipa|let me try actual master
 63 2016-04-07 12:14:01	0|wumpus|seems to work fine here, too
 64 2016-04-07 12:19:08	0|sipa|hmm, master fails for me
 65 2016-04-07 12:19:29	0|sipa|actually, all rpc tests fail
 66 2016-04-07 12:29:57	0|sipa|eh, HTTP 403
 67 2016-04-07 12:33:19	0|sipa|how is the test framework supposed to authenticate?
 68 2016-04-07 12:33:58	0|MarcoFalke|rpcuser, rpcpassword
 69 2016-04-07 12:33:59	0|wumpus|there's only one way to get forbidden: if your IP isn't allowed to connect
 70 2016-04-07 12:34:22	0|sipa|ah, it writes a bitcoin.conf file
 71 2016-04-07 12:34:28	0|sipa|with username/password rt
 72 2016-04-07 12:35:42	0|wumpus|wrong user or password will get you HTTP_UNAUTHORIZED (401)
 73 2016-04-07 12:38:33	0|wumpus|no idea how an RPC test could end up connecting through a non-allowed IP though, afaik  none of the tests sets rpcallow
 74 2016-04-07 12:39:40	0|sipa|2016-04-07 12:38:02 Received a POST request for / from 192.168.44.1:58356
 75 2016-04-07 12:39:58	0|sipa|why is it using my LAN address...?
 76 2016-04-07 12:40:05	0|wumpus|yes that seems wrong
 77 2016-04-07 12:40:15	0|wumpus|why is it binding on your LAN address
 78 2016-04-07 12:40:18	0|sipa|i played with iptables a while ago, perhaps i haven't rebooted yet
 79 2016-04-07 12:41:16	0|sipa|sorry for bothering you with it
 80 2016-04-07 12:41:41	0|wumpus|well I'd still like to know what caused this
 81 2016-04-07 12:43:57	0|sipa|iptables -A FORWARD -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
 82 2016-04-07 12:43:57	0|sipa|iptables -t nat -A POSTROUTING -j MASQUERADE
 83 2016-04-07 12:44:00	0|sipa|iptables -A FORWARD -i eth0 -j ACCEPT
 84 2016-04-07 12:47:07	0|wumpus|rpc_url, the function to determine the RPC URL to connect to, hardcodes 127.0.0.1 unless variable rpchost is set - the only test crazy enough to set that is rpcbind_test.py
 85 2016-04-07 12:47:32	0|wumpus|(which isn't ever started automatically IIRC)
 86 2016-04-07 12:48:33	0|wumpus|so this must be a really strange network configuration indeed :)
 87 2016-04-07 12:52:45	0|wumpus|maybe connections to localhost got masqueraded to your LAN address
 88 2016-04-07 12:56:06	0|wumpus|probably the error "Unexpected exception caught during testing: No JSON object could be decoded" could be improved though, it shouldn't really expect a JSON object in the case of a non-OK response
 89 2016-04-07 12:57:47	0|wumpus|oh fuck it does, JSONErrorReply still converts some JSON RPC errors to HTTP errors, thought that was changed at some point
 90 2016-04-07 12:57:56	0|wumpus|not 401 or 403 though
 91 2016-04-07 13:14:23	0|wumpus|easy solution though: actually check that "Content-Type" is "application/json" before starting decoding
 92 2016-04-07 13:32:50	0|Luke-Jr|why not make it both JSON-RPC and HTTP error?
 93 2016-04-07 13:37:27	0|wumpus|that's exactly what happens, JSON RPC errors are mapped to HTTP errors here:  https://github.com/bitcoin/bitcoin/blob/master/src/httprpc.cpp#L75    I don't know what the JSON RPC spec says I think it's a bit of a level violation
 94 2016-04-07 13:38:05	0|wumpus|in any case for this it doesn't matter, it just shouldn't be trying to parse responses with the wrong content type as JSON
 95 2016-04-07 13:38:47	0|sipa|wumpus: the 0.12 travis failure is spurious, i think?
 96 2016-04-07 13:42:00	0|wumpus|make[5]: Entering directory `/home/travis/build/bitcoin/bitcoin/bitcoin-i686-w64-mingw32/src/secp256k1' random seed = 7810890d4968c3f148a3cdd563177c92 err:seh:setup_exception_record stack overflow 1040 bytes in thread 0009 eip 7bc46e38 esp 00540f20 stack 0x540000-0x541000-0x740000 FAIL: tests.exe
 97 2016-04-07 13:42:06	0|wumpus|wow that's one I've never seen before
 98 2016-04-07 13:42:31	0|wumpus|but it must be a transient failure, yes
 99 2016-04-07 13:43:13	0|wumpus|there haven't been any recent changes to secp256k1
100 2016-04-07 13:43:29	0|wumpus|(at least the one in bitcoin)
101 2016-04-07 13:47:00	0|GitHub136|[13bitcoin] 15laanwj opened pull request #7833: tests: Check Content-Type header returned from RPC server (06master...062016_04_rpc_tests_check_content_type) 02https://github.com/bitcoin/bitcoin/pull/7833
102 2016-04-07 15:50:59	0|wumpus|* [new tag]         v0.12.1rc1 -> v0.12.1rc1
103 2016-04-07 16:13:09	0|instagibbs|a failed assert for onlyMaybeDeadlock means it's actually deadlocked?
104 2016-04-07 16:27:52	0|wumpus|instagibbs: probably not, it's  a common intermittent error: https://github.com/bitcoin/bitcoin/issues/7470
105 2016-04-07 16:29:07	0|instagibbs|oh, right, i didn't see "Assertion" in the issue before. Thanks.
106 2016-04-07 16:35:05	0|sipa|why is that case classified as a potential deadlock?
107 2016-04-07 16:35:16	0|sipa|there are not even 2 locks that overlap
108 2016-04-07 16:35:46	0|sipa|cs_main is the only one shared
109 2016-04-07 16:56:30	0|instagibbs|how am I supposed to read the log?
110 2016-04-07 18:02:43	0|jonasschnelli|wumpus: F.Y.I: the lmdb node crashed.
111 2016-04-07 18:02:44	0|jonasschnelli|LockStack&): Assertion `onlyMaybeDeadlock' failed.
112 2016-04-07 18:02:44	0|jonasschnelli|sync.cpp:112: void potential_deadlock_detected(const std::pair<void*, void*>&, const LockStack&, const
113 2016-04-07 18:03:12	0|wumpus|another potential deadlock, ugh
114 2016-04-07 18:03:21	0|wumpus|that should be unrelated to lmdb though, I haven't touched any locking
115 2016-04-07 18:03:24	0|jonasschnelli|Seems unrelated to lmdb
116 2016-04-07 18:03:32	0|wumpus|yes it's the #7470
117 2016-04-07 18:03:45	0|wumpus|another such report and I'm going to just reip out the potential deadlock detection
118 2016-04-07 18:03:55	0|wumpus|travis also crashes on it frequently
119 2016-04-07 18:04:40	0|jonasschnelli|http://pastebin.com/raw/zWehjWKw
120 2016-04-07 18:05:02	0|wumpus|the problem is that at some point the lock debugging was enabled by default with --enable-debug
121 2016-04-07 18:05:15	0|wumpus|ever since people have been getting this frequenltly
122 2016-04-07 18:05:25	0|instagibbs|wumpus, I just deactivated it in my config :/
123 2016-04-07 18:05:30	0|jonasschnelli|Is the crash-assert only active in --enable-debug?
124 2016-04-07 18:05:35	0|instagibbs|it was literally firing off each time my wallet rebroadcast a txn
125 2016-04-07 18:05:49	0|instagibbs|jonasschnelli, if you enable that it has it, yes
126 2016-04-07 18:05:56	0|wumpus|jonasschnell: that's the only way to enable it with autoconf, yes
127 2016-04-07 18:06:01	0|instagibbs|-    CPPFLAGS="$CPPFLAGS -DDEBUG -DDEBUG_LOCKORDER"
128 2016-04-07 18:06:03	0|instagibbs|+    CPPFLAGS="$CPPFLAGS -DDEBUG"
129 2016-04-07 18:06:25	0|jonasschnelli|hmm.. we should have an extra autoconf -enable for -DDEBUG_LOCKORDER...
130 2016-04-07 18:06:37	0|jonasschnelli|IIRC it once was like this.
131 2016-04-07 18:06:50	0|wumpus|it used to be that you had to manually provide `CPPFLAGS=-DDEBUG_LOCKORDER` after configure to enable it
132 2016-04-07 18:07:00	0|wumpus|yes it was
133 2016-04-07 18:07:11	0|wumpus|this seemed like a good idea at the time to get more test coverage
134 2016-04-07 18:07:16	0|wumpus|and theoretically it is
135 2016-04-07 18:07:24	0|wumpus|but not if the check is broken in the first place
136 2016-04-07 18:08:08	0|wumpus|because those things have *never* got me a deadlock when not building without -enable-debug
137 2016-04-07 18:08:13	0|wumpus|-not
138 2016-04-07 18:08:46	0|wumpus|I'd be ok with a --debug-locks though jonasschnelli :)
139 2016-04-07 18:09:03	0|wumpus|or rather --enable-debug-locks, which isn't implied by --enable-debug
140 2016-04-07 18:09:06	0|jonasschnelli|I mean we could still enable it by default..
141 2016-04-07 18:09:11	0|wumpus|nah
142 2016-04-07 18:09:23	0|wumpus|only if we can fix it
143 2016-04-07 18:09:40	0|wumpus|we know the drill by now - false alarms are worse than no alarms
144 2016-04-07 18:09:49	0|jonasschnelli|Indeed!
145 2016-04-07 18:15:03	0|gmaxwell|never having gotten wedged in practice doesn't mean there isn't a lock inversion that needs to be fixed though.
146 2016-04-07 18:15:17	0|gmaxwell|but yes, false alarms are worse than no alarms.
147 2016-04-07 18:16:19	0|gmaxwell|the historical low accessiblity of the detector means that relatively little testing has been done with it... we should probably get it out of travis but also go beat on it some.
148 2016-04-07 18:19:14	0|phantomcircuit|gmaxwell, it detects some stuff where the lock ordering is different in init.cpp from everywhere else
149 2016-04-07 18:19:24	0|phantomcircuit|which never causes a deadlock
150 2016-04-07 18:22:02	0|jtimon|sorry, the meeting is in 1 h 40 mins, right?
151 2016-04-07 18:22:09	0|jonasschnelli|jtimon: in 40mins
152 2016-04-07 18:22:35	0|jtimon|jonasschnelli: ok, thank you, I definitely needed to ask :)
153 2016-04-07 18:22:40	0|wumpus|40 minutes, yes
154 2016-04-07 18:24:20	0|gmaxwell|phantomcircuit: we shouldn't be doing that in init.cpp then, yes it doesn't cause a deadlock -- but it undermines the simple and useful error detection here and produces false positives. An alernative would be to have the lock detector not activate until there are multiple threads... without looking at the specific cases I don't know which would be easier.
155 2016-04-07 18:26:08	0|wumpus|in my experience the deadlock detector code is hard to understand, and changes are hard to review
156 2016-04-07 18:28:09	0|wumpus|anything that makes it even harder to debug, like making it check if there are multiple threads, doesn't sound like a good idea to me
157 2016-04-07 18:28:59	0|wumpus|I think it already does that though. It keeps a lock stack per thread, and if the order of acquiring the locks differs it signals that
158 2016-04-07 18:29:04	0|wumpus|at least it used to do that
159 2016-04-07 18:29:18	0|sipa|wumpus: i'll have a look, i think i know how it works and how it should work
160 2016-04-07 18:29:22	0|wumpus|it seems pretty broken now
161 2016-04-07 18:29:44	0|wumpus|so let's disable it for --enable-debug and travis at least, keeping it as option makes sense
162 2016-04-07 18:30:34	0|wumpus|I think where it mainly fails is when try_lock is used
163 2016-04-07 18:32:54	0|morcos|wumpus: i'm not familiar with that code at all, but what you are tlaking about changing wouldn't get rid of the AssertLockHeld checks would it?  b/c i think its important to keep those routinely tested
164 2016-04-07 18:33:37	0|wumpus|yes I think we should keep AssertLockHeld checks, they don't give problems
165 2016-04-07 18:33:48	0|wumpus|(I added many of them actually :)
166 2016-04-07 18:34:18	0|wumpus|it's only the deadlock detection that gives trouble, so yes makes sense to split that out
167 2016-04-07 18:34:37	0|morcos|yeah, right now they're both under -DDEBUG_LOCKORDER
168 2016-04-07 18:35:28	0|wumpus|yes they use the same underlying tracking
169 2016-04-07 18:37:58	0|wumpus|but maybe sipa can solve it :) I'd say he has enough to do though
170 2016-04-07 18:40:52	0|sipa|wumpus: the report in that bug report is wrong, it should not trigger the warning
171 2016-04-07 18:41:04	0|sipa|not even if they weren't try locks
172 2016-04-07 18:41:35	0|wumpus|yes it seems to be a false alert
173 2016-04-07 18:42:18	0|wumpus|and a lot of those happen, all with slightly different locks involved
174 2016-04-07 18:42:52	0|wumpus|if there are any real reports it's really hard to narrow down *which* locks are the problem from that output
175 2016-04-07 18:43:20	0|wumpus|it's very possible that the detection is just broken and generating spurious reports
176 2016-04-07 18:46:42	0|gmaxwell|another option is to stop using it and switch to helgrind for this purpose.
177 2016-04-07 18:47:44	0|wumpus|yes
178 2016-04-07 18:48:43	0|gmaxwell|(it wouldn't replace assert-lockheld though)
179 2016-04-07 18:49:18	0|gmaxwell|though due to performance I don't think helgrind would be usable on arm.
180 2016-04-07 18:49:28	0|wumpus|assert-lockheld works so we should just keep that, and disable the lockorder check until someone fixes it
181 2016-04-07 18:49:58	0|gmaxwell|But it helgrind will also catch a lot more than potential lock inversions.
182 2016-04-07 18:50:57	0|wumpus|yes the drawback of the *grind tools is the performance loss involved in instrumenting the code
183 2016-04-07 18:52:26	0|gmaxwell|seems people have not been running helgrind on the codebase.
184 2016-04-07 18:53:38	0|wumpus|(-DDEBUG_LOCKORDER also adds overhead, but only on aquiring/releasing locks)
185 2016-04-07 18:53:57	0|gmaxwell|and the overhead of being wrong and not getting used? :P
186 2016-04-07 18:54:38	0|wumpus|yes and the overhead of tons of open issues on the repository
187 2016-04-07 19:00:58	0|lightningbot|Meeting started Thu Apr  7 19:00:58 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
188 2016-04-07 19:00:58	0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
189 2016-04-07 19:00:58	0|wumpus|#startmeeting
190 2016-04-07 19:01:47	0|wumpus|PSA: 0.12.1rc1 has been tagged, please start your gitian builders
191 2016-04-07 19:01:54	0|jonasschnelli|(1) How to proceed with cores wallet (I have a proposal)
192 2016-04-07 19:01:54	0|jonasschnelli|(2) CoreDev Hacking convention in Zurich (short announcement)
193 2016-04-07 19:01:54	0|jonasschnelli|(3) Dealing with RBF RPC/UI
194 2016-04-07 19:01:54	0|jonasschnelli|I have three topic proposals
195 2016-04-07 19:02:16	0|petertodd|jonasschnelli: ack, and I need an excuse to visit Zurich :)
196 2016-04-07 19:02:42	0|jonasschnelli|http://coredev.tech
197 2016-04-07 19:02:53	0|jonasschnelli|(sketch)
198 2016-04-07 19:02:56	0|wumpus|for the last meeting we have ACTION: start generating mtp violating transactions (gmaxwell) (wumpus, 19:08:21)
199 2016-04-07 19:03:05	0|wumpus|ACTION: #7543 has 5 tested ACKs so far. It should be ready for merge (wumpus, 19:22:52)
200 2016-04-07 19:03:28	0|wumpus|that was done
201 2016-04-07 19:03:33	0|gmaxwell|RE: mtp violations, I did. I generated a number... none were mined. I am still working on this-- I suspect I need to relay harder.
202 2016-04-07 19:03:40	0|wumpus|ACTION: disable bad-chain alert for 0.12.1 (wumpus, 19:38:39)
203 2016-04-07 19:03:43	0|wumpus|that was also done
204 2016-04-07 19:04:37	0|wumpus|ACTION: disable bad-alert detection in master if it doesn't improve enough by 0.13 (and don't forget!) - well I tagged dgenr8's issue for 0.13, not sure what the progress there was
205 2016-04-07 19:05:02	0|wumpus|ok let's start with jonasschnelli's topics
206 2016-04-07 19:05:15	0|wumpus|#topic How to proceed with cores wallet
207 2016-04-07 19:05:16	0|btcdrak|wumpus ack
208 2016-04-07 19:05:26	0|jonasschnelli|My proposal for a concept: extend #7830: copy the wallet, remove backward compatibility (not required), remove accounts, replace BDB with LogDB, add BIP32, add SPV (= process separation)
209 2016-04-07 19:05:35	0|jonasschnelli|It would help to merge it as soon as it is usefull (remove accounts and add label RPC calls, reset wallet-version)
210 2016-04-07 19:05:52	0|jonasschnelli|If we agree on the concept. I'm happy to write tests, etc.
211 2016-04-07 19:06:13	0|jonasschnelli|So we can ensure that the second wallet runs smoothly along with the main wallet
212 2016-04-07 19:06:19	0|gmaxwell|This sounds conceptually okay to me, though how will we deal with improvements that flow to the current wallet? apply them twice (as applicable)?
213 2016-04-07 19:06:20	0|wumpus|sounds good to me, we're kind of held up on updates on the current wallet, if you want to work on a  new one that makes sense
214 2016-04-07 19:06:41	0|btcdrak|jonasschnelli: sounds great
215 2016-04-07 19:06:41	0|jonasschnelli|gmaxwell: Yes. Important improvments could be applied on both wallets.
216 2016-04-07 19:06:43	0|gmaxwell|I think it's much better than a boil the ocean rewrite.
217 2016-04-07 19:06:49	0|jonasschnelli|The second wallet should not have a stable API for now.
218 2016-04-07 19:07:01	0|jonasschnelli|And we could merge more aggressively there.
219 2016-04-07 19:07:20	0|sipa|well if you intentionally break things in it, it may not get sufficient testing
220 2016-04-07 19:07:24	0|jonasschnelli|I would also be happy to be the maintainer of that second / currently experimental wallet.
221 2016-04-07 19:07:25	0|sipa|but concept ack
222 2016-04-07 19:07:31	0|wumpus|or maybe it will get sufficient testing
223 2016-04-07 19:07:42	0|wumpus|some people are waiting for things to be broken, especially the account system
224 2016-04-07 19:08:14	0|wumpus|but any update to the current wallet goes so slow, partially because every time backwards compatiblity has to be considered
225 2016-04-07 19:08:20	0|gmaxwell|it probably won't get 'sufficient' testing for now. But thats okay. It'll get some toying around with, which will be good feed back-- but most importantly we can make incremental progress.
226 2016-04-07 19:08:26	0|wumpus|so it's kind of circular
227 2016-04-07 19:08:52	0|gmaxwell|we really will need to up the quality and rigor of wallet tests for new functionality there; right now our testing for the wallet (what exists) has many checks that check exact behavior, which makes development hard. That kind of test can be tolerable for consensus code... it's a huge burden for wallet code.
228 2016-04-07 19:08:54	0|jonasschnelli|Yes. We could mark it as experimental, don't use it with large amounts.
229 2016-04-07 19:09:03	0|wumpus|also updates to the current wallet don't get sufficient testing/review either, there's just no energy behind it
230 2016-04-07 19:09:04	0|morcos|is the idea that every important change to the existing wallet will need to be replicated though?  if so we maybe shouldn't stay in this state too long.  or someone has to volunteer to do those copies.
231 2016-04-07 19:09:22	0|sipa|was just about the bring that up
232 2016-04-07 19:09:27	0|wumpus|morcos: well I expect them to diverge soon enough that that won't say a problem for long
233 2016-04-07 19:09:32	0|GitHub118|[13bitcoin] 15sdaftuar opened pull request #7835: Version 2 transactions remain non-standard until CSV activates (06master...06CSV-relay-after-softfork) 02https://github.com/bitcoin/bitcoin/pull/7835
234 2016-04-07 19:09:39	0|phantomcircuit|gmaxwell: i can help you with relaying harder
235 2016-04-07 19:09:41	0|jonasschnelli|morcos: I think as we proceed, most features will only make sense on one or the other side.
236 2016-04-07 19:09:43	0|sipa|we can't put the burden on external contributors to duplicate
237 2016-04-07 19:09:59	0|wumpus|features will mostly end up in the new wallet
238 2016-04-07 19:10:08	0|wumpus|the old wallet should still receive bugfixes etc
239 2016-04-07 19:10:17	0|wumpus|it's a bit like stable versions/master
240 2016-04-07 19:10:20	0|jonasschnelli|wumpus: +1
241 2016-04-07 19:10:20	0|morcos|hmm..  lots of things would apply to both,  conflicts, abandoned transactions, fee estimates
242 2016-04-07 19:10:50	0|wumpus|in any case I'd say this is up to the people doing the work
243 2016-04-07 19:10:52	0|morcos|wumpus: oh ok.  that makes sense, but when would the target be for the new wallet to be production ready
244 2016-04-07 19:10:55	0|morcos|0.14
245 2016-04-07 19:10:56	0|morcos|?
246 2016-04-07 19:11:02	0|wumpus|morcos: when it's ready
247 2016-04-07 19:11:09	0|jonasschnelli|morcos: sure. But the second wallet should once be independent from the core. So we should work towards a clear interface.
248 2016-04-07 19:11:22	0|morcos|i guess i dont' wnat us to be in a state where the old wallet has deteriorated due to lack of attention and the new wallet is not yet stable
249 2016-04-07 19:11:29	0|gmaxwell|wumpus: things like the recent performance improvements would apply to both; (sufficiently) poor performance is a bug.  ... I think doing this will have a _serious_ cost, but the alternative of continuing to not advance in that area of the software is worse.
250 2016-04-07 19:11:30	0|morcos|we need something that is good to use
251 2016-04-07 19:11:43	0|jonasschnelli|New wallet without account and without BDB could be in 0.13, stable API in 0.15, ... non-beta in 0.16
252 2016-04-07 19:11:47	0|morcos|right, i'm not opposed to doing this, i think we need to do something
253 2016-04-07 19:11:48	0|wumpus|morcos: it's a risk, but you can't stop people from working on a new wallet if that's what they prefer
254 2016-04-07 19:12:05	0|sipa|yes, i think we should aim to have the new wallet production ready soon, but just no stable onterface
255 2016-04-07 19:12:10	0|sipa|*interface
256 2016-04-07 19:12:10	0|wumpus|(or maybe jonasschnelli and me should start a fork of bitcoin core *ducks*)
257 2016-04-07 19:12:40	0|jonasschnelli|wumpus: I did that already... but the amount of reviewers was... lets say ... extremely tiny.
258 2016-04-07 19:12:46	0|jonasschnelli|We can't say SPV is doomed and not improvig the wallet at the same time.
259 2016-04-07 19:12:47	0|sipa|also, a lot of the unit tests for non-wallet features rely on having a wallet
260 2016-04-07 19:13:06	0|wumpus|yes, the unit tests should be less dependent on the wallet
261 2016-04-07 19:13:11	0|wumpus|but that's a different issue
262 2016-04-07 19:13:23	0|jonasschnelli|Yes. Hard to send around coins then. But agree.
263 2016-04-07 19:13:41	0|sipa|iwe can replicate a wallet in the python framework *ducjs*
264 2016-04-07 19:13:43	0|wumpus|(well, the non-wallet unit tests). In any case the unit tests can use the old wallet for now.
265 2016-04-07 19:13:52	0|petertodd|sipa: please do; python-bitcoinlib needs a wallet :)
266 2016-04-07 19:13:56	0|wumpus|sipa: yes :)
267 2016-04-07 19:13:59	0|wumpus|a python wallet please
268 2016-04-07 19:14:08	0|wumpus|:D
269 2016-04-07 19:14:09	0|sipa|the why do we need a wallet in core? ;)
270 2016-04-07 19:14:15	0|btcdrak|!
271 2016-04-07 19:14:25	0|paveljanik|for testing...
272 2016-04-07 19:14:27	0|wumpus|well one idea was to begin a new wallet outside of core
273 2016-04-07 19:14:32	0|jonasschnelli|I agree long term we could remove the wallet... but in tiny steps.
274 2016-04-07 19:14:37	0|sipa|ok
275 2016-04-07 19:14:43	0|sipa|who is gavel?
276 2016-04-07 19:14:55	0|jonasschnelli|Outside of core does not work for now.
277 2016-04-07 19:15:00	0|sipa|indeed
278 2016-04-07 19:15:05	0|wumpus|but anyhow the work is currently in the direction of adding a new-wallet in core, so I'd just like to support that
279 2016-04-07 19:15:20	0|wumpus|if you want to create a wallet outside of core no one needs any permission at all from anyone here :p
280 2016-04-07 19:15:24	0|jonasschnelli|As soon as the wallet can run SPV, we can think about moving it.
281 2016-04-07 19:15:28	0|btcdrak|sipa: do I need to call an ambulance?
282 2016-04-07 19:15:41	0|paveljanik|can't just work on the interaface/API for wallet and the new wallet to be outside of Core?
283 2016-04-07 19:15:55	0|sipa|jonasschnelli: i think it will still share a large part of the codebase, even if it's not runnijg in the same process
284 2016-04-07 19:15:58	0|wumpus|sure, feel free to do what you want to do outside of core paveljanik
285 2016-04-07 19:16:28	0|petertodd|jonasschnelli: why worry about SPV? write one that scans full blocks, grabbing them from a local bitcoind
286 2016-04-07 19:16:30	0|jonasschnelli|sipa: Yes. Once it can run SPV, it shares some base code, also the net stuff.
287 2016-04-07 19:16:34	0|sipa|jonasschnelli: please, modularization first, separate process next, and then we can start talking about other repository
288 2016-04-07 19:16:41	0|paveljanik|wumpus, that nees Core to provide API/something Jonas is already working on...
289 2016-04-07 19:16:41	0|wumpus|it makes sense, e.g. joinmarket has a wallet outside of core, although it's somewhat suboptimal
290 2016-04-07 19:16:48	0|sipa|petertodd: that's the idea
291 2016-04-07 19:16:56	0|sipa|petertodd: spv does not imply bip37
292 2016-04-07 19:17:05	0|wumpus|(still relies on the wallet inside core but using watch-only)
293 2016-04-07 19:17:11	0|jonasschnelli|I think it's to early to remove the wallet from core. We can think about it in 2-3 years.
294 2016-04-07 19:17:34	0|wumpus|jonasschnelli: yes
295 2016-04-07 19:17:50	0|wumpus|no one is actually proposing doing that now, but it's always how this discussion goes
296 2016-04-07 19:17:53	0|wumpus|and has gone for years
297 2016-04-07 19:17:58	0|morcos|would it be helpful to try to document the plan a bit more clearly  (not the whole future long term plan, but exactly what jonas is going to be workign on and how we can best support him)
298 2016-04-07 19:18:03	0|jonasschnelli|petertodd: Right. Running Core in full-block SPV is easy. Adapting the wallet so its not depending on a mempool, etc. is a bit harder.
299 2016-04-07 19:18:03	0|morcos|in an issue or something
300 2016-04-07 19:18:06	0|wumpus|any progress you make is helpful jonasschnelli
301 2016-04-07 19:18:24	0|btcdrak|next topic?
302 2016-04-07 19:18:28	0|sipa|agree
303 2016-04-07 19:18:31	0|jonasschnelli|morcos: I'll write a proposal.
304 2016-04-07 19:18:34	0|jonasschnelli|agree next t.
305 2016-04-07 19:18:41	0|sipa|(my battery is at 11%)
306 2016-04-07 19:18:49	0|morcos|i'm just worried about falling into a position where the new wallet is not ready fast enough and needed improvements / bug fixes / etc are sometimes applied to one and sometimes the other and sometimes both
307 2016-04-07 19:18:58	0|wumpus|#topic CoreDev Hacking convention in Zurich (short announcement)
308 2016-04-07 19:19:02	0|morcos|the plan doesn't have to be perfect, but it helps if its clear
309 2016-04-07 19:19:13	0|wumpus|morcos: it's a risk, but it's how it goes in open source
310 2016-04-07 19:19:25	0|jonasschnelli|I think we could all meet together and hack at some important stuff.
311 2016-04-07 19:19:26	0|jonasschnelli|http://coredev.tech
312 2016-04-07 19:19:29	0|gmaxwell|jonasschnelli: please just propose things for the short/mid term for now.
313 2016-04-07 19:19:35	0|phantomcircuit|petertodd: spv in this context really just means that the spv proofs are being saved such that the wallet could operate in a true spv mode, not that it will
314 2016-04-07 19:19:57	0|jonasschnelli|Best would be to get SW nailed at the meeting in ZH.
315 2016-04-07 19:20:10	0|jonasschnelli|I'm also convinced if we do that, we find sponsors pretty easy.
316 2016-04-07 19:20:10	0|wumpus|awesome jonasschnelli
317 2016-04-07 19:20:26	0|jonasschnelli|Room, food, etc. is organized.
318 2016-04-07 19:20:44	0|jonasschnelli|If someone needs travel subsidy, please tell me.
319 2016-04-07 19:20:53	0|morcos|i like the idea, but unfortunately can't attend that weekend
320 2016-04-07 19:20:58	0|jonasschnelli|Important: Because of the short timelime, please tell me if you are interested to attend during the next 7 days.
321 2016-04-07 19:21:22	0|sipa|is the date fixed?
322 2016-04-07 19:21:25	0|wumpus|sure I will
323 2016-04-07 19:21:34	0|jtimon|I probably will as well
324 2016-04-07 19:21:37	0|jonasschnelli|Date is semi-fixed. :)
325 2016-04-07 19:21:39	0|petertodd|jonasschnelli: I can attend
326 2016-04-07 19:21:50	0|sipa|i can attend
327 2016-04-07 19:22:01	0|sipa|(13 minute tram ride)
328 2016-04-07 19:22:04	0|sdaftuar|jonasschnelli: i'm interested, though not sure yet if i can make it
329 2016-04-07 19:22:05	0|jonasschnelli|Hah.
330 2016-04-07 19:22:08	0|wumpus|i can attend too, nothing else on that date at laest
331 2016-04-07 19:22:23	0|jonasschnelli|Its soon. Please try to give me a yes/no during the next 7 days.
332 2016-04-07 19:22:38	0|jonasschnelli|Okay. I'll flag wumpus, petertodd and sipa as "confirmed".
333 2016-04-07 19:22:51	0|jonasschnelli|and jtimon (he lives in spain and needs to come!)
334 2016-04-07 19:23:12	0|gmaxwell|If you want people to come, more advanced planning would help, in the future! :)
335 2016-04-07 19:23:22	0|jtimon|jonasschnelli: yeah, unless something unexpected prevents me from going, sounds great to me
336 2016-04-07 19:23:34	0|jonasschnelli|gmaxwell: Agree. I just can't in June/Juli/Aug!
337 2016-04-07 19:23:49	0|jonasschnelli|If it wont work, I'll organize another one in fall.
338 2016-04-07 19:24:01	0|petertodd|gmaxwell: heh, I feel lucky when I have a whole two months of notice to travel halfway around the world - a week is more common :)
339 2016-04-07 19:24:02	0|btcdrak|jonasschnelli: seems like you have a lot of takers already
340 2016-04-07 19:24:15	0|sipa|petertodd: agree
341 2016-04-07 19:24:21	0|jonasschnelli|And Zurich is great! :-)
342 2016-04-07 19:24:40	0|jtimon|never been there, happy to visit it
343 2016-04-07 19:24:40	0|petertodd|I was in Zug for a week, and it was so beautiful that a cup of coffee cost $10
344 2016-04-07 19:24:53	0|jonasschnelli|</topic>
345 2016-04-07 19:24:58	0|wumpus|hehe
346 2016-04-07 19:25:12	0|sipa|next topic?
347 2016-04-07 19:25:14	0|jtimon|maybe I've been in the airport...sorry, yeah, next topic
348 2016-04-07 19:25:14	0|wumpus|#topic Dealing with RBF RPC/UI
349 2016-04-07 19:25:42	0|michagogo|(null) <jonasschnelli> New wallet without account and without BDB could be in 0.13, stable API in 0.15, ... non-beta in 0.16
350 2016-04-07 19:25:56	0|michagogo|Sorry I'm late, but: Bitcoin Core is still in beta, no?
351 2016-04-07 19:26:05	0|sipa|haha
352 2016-04-07 19:26:12	0|petertodd|speaking of, opt-in RBF is getting used by someone at least: http://p2sh.info/dashboard/db/replace-by-fee
353 2016-04-07 19:26:19	0|jonasschnelli|RBF: I dont have a clear vision how the RPC should deal with RBF
354 2016-04-07 19:26:27	0|gmaxwell|michagogo: the "beta" was dropped from the description years ago.
355 2016-04-07 19:26:29	0|michagogo|Huh, that timestamp broke weirdly
356 2016-04-07 19:26:41	0|michagogo|gmaxwell: really? I must have missed that
357 2016-04-07 19:26:44	0|gmaxwell|michagogo: and some stupid lable wouldn't excuse shoddy support.
358 2016-04-07 19:27:06	0|michagogo|gmaxwell: obviously, I was just commenting on the "non-beta" milestone
359 2016-04-07 19:27:12	0|jonasschnelli|Opt-in is one issue to deal with, the second one is: how does the process looks like if someone adds an output/input?
360 2016-04-07 19:27:41	0|jonasschnelli|Ensure that the RBF rules are respected (>fee, pay for the bandwith, etc.)
361 2016-04-07 19:27:56	0|petertodd|so, I think what you actually need to do here from an RPC point of view is think in terms of what addresses the user wanted to pay, and whether or not known (confirmed) txs succesfully did that - which isn't really how the wallet works right now
362 2016-04-07 19:28:10	0|MarcoFalke_|Shouldn't we only support fee bump as a fist step?
363 2016-04-07 19:28:16	0|petertodd|MarcoFalke_: ack
364 2016-04-07 19:28:27	0|paveljanik|MarcoFalke: +1
365 2016-04-07 19:28:30	0|sipa|ack
366 2016-04-07 19:28:38	0|jonasschnelli|*exhales*
367 2016-04-07 19:28:49	0|gmaxwell|In many ways, adding outputs is more useful... but "fee bump only" was also my initial impression at jonasschnelli's efforts.
368 2016-04-07 19:28:55	0|phantomcircuit|petertodd: the wallet does track which outputs are change, so nominally it's also trakcing which outputs where intended as payments
369 2016-04-07 19:28:57	0|jtimon|one step at a time sounds good to me
370 2016-04-07 19:29:01	0|jonasschnelli|I think we should have a fee-bump RBF in 0.13 (RBF was in 0.11.x and 0.12).
371 2016-04-07 19:29:05	0|petertodd|MarcoFalke_: and with fee bump, first implementation should probably *not* add inputs, which complicates things
372 2016-04-07 19:29:23	0|jonasschnelli|| How would a feebump over RPC looks like?
373 2016-04-07 19:29:33	0|petertodd|jonasschnelli: hmm? I released RBF for v0.11, but Core didn't
374 2016-04-07 19:29:56	0|jonasschnelli|sry, mixed up with CLTV... right. 0.12
375 2016-04-07 19:30:47	0|petertodd|jonasschnelli: https://github.com/petertodd/replace-by-fee-tools/blob/master/bump-fee.py <- there's my implementation, with is basically bumpfee <txid> <ratio/delta-fees> => <new txid>
376 2016-04-07 19:31:19	0|gmaxwell|for adding outputs, I think the best way involves some larger workflow changes. E.g. the ability to queue sends, and auto-sendmany from the queue.. then that could be extended to auto-add-outputs for queued sends where the original is sent.
377 2016-04-07 19:31:24	0|gmaxwell|or something like that.
378 2016-04-07 19:31:26	0|jonasschnelli|petertodd: bumpfee ... yes. maybe we find a call-name that is more flexible for the future?
379 2016-04-07 19:31:35	0|petertodd|jonasschnelli: I didn't handle the case where you'd respent the change, but just having fee bumping error out in that case isn't all that bad; a slightly smarter version could combine the dependent txs (assuming they're all yours)
380 2016-04-07 19:31:57	0|sipa|related: cpfp?
381 2016-04-07 19:31:58	0|gmaxwell|RE: feebump, I think a different approach should be used.
382 2016-04-07 19:32:07	0|phantomcircuit|petertodd: there's significant privacy implications to combining payments
383 2016-04-07 19:32:10	0|petertodd|jonasschnelli: AbstractRespendWithSomeThingChangedFactoryBean?
384 2016-04-07 19:32:19	0|jonasschnelli|^^
385 2016-04-07 19:32:32	0|petertodd|phantomcircuit: sure, which is why getting estimates right in the first place helps a lot
386 2016-04-07 19:32:51	0|petertodd|phantomcircuit: but if fee bumping is a once-in-a-while thing, I'm not that concerned re: privacy
387 2016-04-07 19:32:51	0|sipa|jonasschnelli: it shall be called BeeFump
388 2016-04-07 19:32:55	0|jonasschnelli|altertransaction was something we once have talked about
389 2016-04-07 19:32:56	0|Lightsword|petertodd, your factory needs a factory :P
390 2016-04-07 19:32:56	0|petertodd|sipa: +1
391 2016-04-07 19:33:10	0|gmaxwell|Instead of having a command to 'bump' we should implement "adaptive fee" where it just precreates the bumps with nlocktimes and queues them.  Expecting the user to always need to manually bump will not make for a good expirence.
392 2016-04-07 19:33:11	0|sipa|gmaxwell: elaborate?
393 2016-04-07 19:33:22	0|sipa|ah
394 2016-04-07 19:33:24	0|petertodd|Lightsword: I'm not going to grey-goo the world just to bump fees... :)
395 2016-04-07 19:33:53	0|wumpus|sure, that'd be even better, but even a simple 'bump fee' command would be better than nothing
396 2016-04-07 19:33:57	0|petertodd|gmaxwell: yeah, ack on that being better, although the code to do feebumping will get reused by the nlocktime version
397 2016-04-07 19:34:11	0|gmaxwell|Also, for a direct manual bumprpc. it sould probably have an api that encourages a multiplicative increase. Since otherwise you can end up needing to bump stupid numbers of time.
398 2016-04-07 19:34:13	0|jonasschnelli|Okay. Will work on "bumpfee".
399 2016-04-07 19:34:29	0|jonasschnelli|How do we estimate fees for replacements?
400 2016-04-07 19:34:31	0|petertodd|gmaxwell: my python script does it based on a ratio
401 2016-04-07 19:34:42	0|kanzure|#action bumpfee work
402 2016-04-07 19:34:46	0|petertodd|jonasschnelli: double every time by default? it's a good start
403 2016-04-07 19:34:52	0|gmaxwell|where as 1.5x each time (subject to the protocol constraint) can span all possible values is a fairly small number of bumps with a maximum overpayment of 50%.
404 2016-04-07 19:35:02	0|petertodd|jonasschnelli: having to bump a fee implies that your fee estimation isn't working anyway :)
405 2016-04-07 19:35:12	0|jonasschnelli|petertodd: indeed!
406 2016-04-07 19:35:17	0|wumpus|exponential fee backoff
407 2016-04-07 19:35:20	0|gmaxwell|petertodd: well it could be working now, just not precognative. :)
408 2016-04-07 19:35:51	0|phantomcircuit|gmaxwell: we'd need to be very careful with automatic fee bumping to ensure that people are aware of it and expect that behavior
409 2016-04-07 19:35:57	0|gmaxwell|unrelated, it would be kinda cool to run the fee estimator on all unconfirmed txn in the mempool and display the current estimate on them.
410 2016-04-07 19:35:58	0|paveljanik|BTW - when we bump fee, will we just lower the change? Or different way to do so to not help Sybil-network-attackers to identify the change?
411 2016-04-07 19:36:05	0|wumpus|phantomcircuit: agreed
412 2016-04-07 19:36:17	0|gmaxwell|phantomcircuit: jonasschnelli had a checkbox in the UI for the things he was doing so far.
413 2016-04-07 19:36:56	0|jonasschnelli|Yes. We don't opt-in automatically for now I guess.
414 2016-04-07 19:36:56	0|petertodd|paveljanik: just lowering the change is by far the easiest; doing better re: privacy is always going to be more expensive, and tricky to be succesful at
415 2016-04-07 19:37:02	0|gmaxwell|paveljanik: the main thing to do is to get the estimate right in the first place, though right now change is so throughly identifyable you're closing the barn door after the horse has left. :)
416 2016-04-07 19:37:08	0|wumpus|phantomcircuit: automatic behavior in the wallet can be somewhat scary, at least now you have to click confirm to pay a certain fee
417 2016-04-07 19:37:24	0|wumpus|phantomcircuit: (although you could have the same, just agree on a certain *max* fee)
418 2016-04-07 19:37:32	0|gmaxwell|wumpus: what I suggested on the PR for that was just to list the possible fees (by the checkbox)
419 2016-04-07 19:37:37	0|jonasschnelli|wumpus: Agree. No automatic behavior that spends inputs automatically.
420 2016-04-07 19:37:55	0|btcdrak|I would just have "increase fee" and give an amount.
421 2016-04-07 19:37:59	0|gmaxwell|Fee of x/y/z/q after 0/2/3/4 blocks.
422 2016-04-07 19:38:26	0|morcos|Ok so not to beat a dead horse here, but just b/c i want to understand.  This kind of change to wallet behavior is something would be only added to new wallet or to both?
423 2016-04-07 19:38:33	0|jonasschnelli|I though we could re-use the fee slider (but with ~x2 values).
424 2016-04-07 19:38:51	0|petertodd|morcos: fee bumping itself I think we should add to the existing wallet; more complex strategies may be infeasible with the current wallet
425 2016-04-07 19:39:03	0|wumpus|morcos: depends on the order in which things actually get implemented, I'd say
426 2016-04-07 19:39:08	0|wumpus|yes agree with petertodd there
427 2016-04-07 19:39:27	0|gmaxwell|morcos: for example the queuing behavior I described above may be unrealistic to do in the current wallet because all our apis expect to return txid.
428 2016-04-07 19:39:34	0|jonasschnelli|morcos: the old wallet could just have a fee bump, ..the new wallet a feature to add outputs.
429 2016-04-07 19:39:47	0|gmaxwell|I think new wallet API should break that and instead return a handle, that can be used to get the txid if it's available yet.
430 2016-04-07 19:39:57	0|jtimon|jonasschnelli: will the new and the old wallet share a common interface (even if one of them just throws a non-implemented error on some methods or something)?
431 2016-04-07 19:40:09	0|sipa|jtimon: imho, no
432 2016-04-07 19:40:13	0|sipa|or not initially
433 2016-04-07 19:40:16	0|wumpus|the idea is tthat the new wallet can have a completely new interface
434 2016-04-07 19:40:27	0|wumpus|throwing out all the old cruft
435 2016-04-07 19:40:28	0|jonasschnelli|jtimon: if we want to depracate the old wallet and remove it once, it should probably be independent.
436 2016-04-07 19:40:51	0|wumpus|of course if there are things that make sense they can be kept
437 2016-04-07 19:40:56	0|morcos|it seems to me that there ought to be an rpc call to jus tincrease the fee by an amount (as btcdrak says) and then there ought to be an rpc call/gui option that says expedite which replaces the fee on an existing transaction wiht the new estimates (assumign the new estimate is higher), you may have changed the target.
438 2016-04-07 19:41:06	0|jonasschnelli|Also while writing on the new wallet, we can care more about core interaction. No mempool access everywhere.
439 2016-04-07 19:41:24	0|sipa|jonasschnelli: that may be... hard
440 2016-04-07 19:41:28	0|wumpus|jonasschnelli: at least make it event driven
441 2016-04-07 19:41:31	0|jtimon|mhmm, I'm just worried about calling code for both wallets from the same place
442 2016-04-07 19:41:35	0|wumpus|jonasschnelli: no assumption on *immediate* mempool access
443 2016-04-07 19:41:47	0|gmaxwell|jonasschnelli: many good features benefit from mempool access.
444 2016-04-07 19:41:58	0|sipa|jtimon: is that a problem?
445 2016-04-07 19:42:09	0|wumpus|the mistake we made in the GUI is to do a lot of calls directly, which makes it very hard to move things to another process or make them network transparent
446 2016-04-07 19:42:22	0|jtimon|with my suggestion the new wallet could have a different interface in practice (as said the old wallet can just throw errors)
447 2016-04-07 19:42:24	0|wumpus|and it also holds up the GUI thread for things that shouldn't
448 2016-04-07 19:42:31	0|sipa|hey, main.cpp used to call the gui directly
449 2016-04-07 19:42:42	0|jonasschnelli|:-)
450 2016-04-07 19:42:44	0|wumpus|it's fine to have a query mempool, but it should be regarded as asynchronous
451 2016-04-07 19:42:57	0|wumpus|heh true sipa, we made a step forward with  bitcoin-qt :-)
452 2016-04-07 19:43:24	0|sipa|other topic?
453 2016-04-07 19:43:35	0|petertodd|wumpus: once you're talking about async access, probably easier just to keep a copy of the mempool on your local app
454 2016-04-07 19:43:36	0|sipa|as we seem to have backtracked to a previous o e
455 2016-04-07 19:43:38	0|wumpus|better to have something then make a wild plan which grows so huge it can never be executed
456 2016-04-07 19:44:00	0|jtimon|sipa: mhmm, seems that code of the form if(fSomething) { // call old wallet } else { // call new wallet} doesn't really make removing the old wallet easier in the future
457 2016-04-07 19:44:04	0|wumpus|petertodd: I don't know, depends on the application
458 2016-04-07 19:44:15	0|sipa|jtimon: oh hell no, that isn't allowed
459 2016-04-07 19:44:23	0|sipa|jtimon: everything through validationinterface
460 2016-04-07 19:44:32	0|petertodd|wumpus: well, unless you're memory constrained, keeping a copy locally and keeping that in sync can't be that hard
461 2016-04-07 19:44:36	0|jtimon|sipa: oh, that was my question then, thanks
462 2016-04-07 19:45:24	0|wumpus|jtimon: yes, wallets (as well as other modules) register their own RPC calls, there's no need for if(fSomething) logic
463 2016-04-07 19:46:06	0|wumpus|any other topics?
464 2016-04-07 19:46:11	0|jtimon|great, that was my only concern about jonasschnelli's plan, I knew I was probably misunderstanding something
465 2016-04-07 19:46:29	0|jonasschnelli|I'll write a clean concept.
466 2016-04-07 19:47:07	0|sipa|oh, small question: are we ok with backporting master's script/tx unit tests to 0.12?
467 2016-04-07 19:47:44	0|petertodd|sipa: ack
468 2016-04-07 19:47:49	0|paveljanik|why not?
469 2016-04-07 19:47:51	0|wumpus|well if the tests are better it always makes sense to backport them
470 2016-04-07 19:48:04	0|sipa|testd are not typically something we backport
471 2016-04-07 19:48:08	0|wumpus|I'm fine with copying all the tests from master to 0.12 given that the funcitnality is supported
472 2016-04-07 19:48:17	0|sipa|but i think it makes total sense as we want softforks backported too
473 2016-04-07 19:48:22	0|sdaftuar|wumpus: i wanted to flag #7835 which i just opened for 0.12.1
474 2016-04-07 19:48:24	0|petertodd|sipa: agreed
475 2016-04-07 19:48:39	0|wumpus|sdaftuar: too late, 0.12.1 was just tagged
476 2016-04-07 19:48:49	0|sipa|sdaftuar: just rc1?
477 2016-04-07 19:48:55	0|sipa|wumpus: ^
478 2016-04-07 19:48:59	0|wumpus|yes
479 2016-04-07 19:49:03	0|sipa|or no rc cycle?
480 2016-04-07 19:49:17	0|btcdrak|Freudian slip
481 2016-04-07 19:49:23	0|jtimon|well, as a not important topic, I would appreciate some feedback on a little experiment in #7829 . I still need to improve the PR description, but the basic idea is helping new people to get their first PR merged and get familiar with git, the review process or whatever, by telling them to do stuff I want done
482 2016-04-07 19:49:30	0|MarcoFalke_|lets hope rc1 one is the final release ;)
483 2016-04-07 19:49:38	0|wumpus|[21:01:15] <wumpus> PSA: 0.12.1rc1 has been tagged, please start your gitian builders
484 2016-04-07 19:49:50	0|morcos|right, so its not too late for 0.12.1 right?
485 2016-04-07 19:49:58	0|btcdrak|20:01:47 <wumpus> PSA: 0.12.1rc1 has been tagged, please start your gitian builders
486 2016-04-07 19:50:10	0|wumpus|well there will only be a rc2 if necessary, does this need to block the release?
487 2016-04-07 19:50:55	0|sdaftuar|i think so.  i think there's a problem with the mempool being able to be filled with things that may not be mined
488 2016-04-07 19:50:57	0|sipa|wumpus: we should consider it i thonk
489 2016-04-07 19:51:08	0|sdaftuar|without the change, which is simple
490 2016-04-07 19:51:19	0|wumpus|ok...
491 2016-04-07 19:51:24	0|sipa|sowwy
492 2016-04-07 19:51:32	0|wumpus|rc1 is dead folks
493 2016-04-07 19:51:36	0|wumpus|don't bother building it
494 2016-04-07 19:51:50	0|wumpus|long live rc2
495 2016-04-07 19:51:57	0|btcdrak|I thought we had discussed this exact thing before regarding V2
496 2016-04-07 19:52:09	0|morcos|wumpus you know i save these things until after your release candidates just for the entertainment value right?
497 2016-04-07 19:52:41	0|wumpus|morcos: I know, no offense taken :) better now than later, almost no one wasted cycles on rc1 yet
498 2016-04-07 19:52:55	0|morcos|btcdrak: yeah i dont' think we properly thought through what happens when things end up in your mempool that won't be reliably mined
499 2016-04-07 19:52:58	0|btcdrak|sdaftuar: that's quite an elegant solution.
500 2016-04-07 19:53:16	0|sdaftuar|btcdrak: that's because i stole it from sipa's segwit
501 2016-04-07 19:53:36	0|wumpus|#action review and ACK https://github.com/bitcoin/bitcoin/pull/7835/files asap
502 2016-04-07 19:53:37	0|btcdrak|long live sipa
503 2016-04-07 19:53:49	0|morcos|we should add this to our list of standard ways to implement things whenever we relax standardness rules
504 2016-04-07 19:53:58	0|btcdrak|morcos: agreed
505 2016-04-07 19:55:11	0|sipa|2% battery left for me; anything else?
506 2016-04-07 19:55:20	0|morcos|travel charger?
507 2016-04-07 19:55:23	0|jonasschnelli|lol
508 2016-04-07 19:55:34	0|wumpus|I don't think so
509 2016-04-07 19:55:45	0|wumpus|#endmeeting
510 2016-04-07 19:55:46	0|lightningbot|Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-04-07-19.00.log.html
511 2016-04-07 19:55:46	0|lightningbot|Meeting ended Thu Apr  7 19:55:45 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
512 2016-04-07 19:55:46	0|lightningbot|Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-04-07-19.00.html
513 2016-04-07 19:55:46	0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-04-07-19.00.txt
514 2016-04-07 19:56:43	0|achow101|wait, is rc1 actually dead?
515 2016-04-07 19:56:54	0|wumpus|yes, dead as a doornail
516 2016-04-07 19:57:15	0|btcdrak|"it's dead Jim"
517 2016-04-07 19:57:40	0|wumpus|we'll probably tag rc2 tomorrow
518 2016-04-07 19:58:03	0|achow101|ok
519 2016-04-07 19:58:05	0|wumpus|doesn't make sense to do a gitian process in the mean time