1 2017-01-24 00:07:24	0|Lightsword|think we can add an option to force bump fee even if opt-in RBF was not used? often transactions will relay regardless since they wouldn’t already be in mempools
  2 2017-01-24 00:12:14	0|gmaxwell|Lightsword: ugh. forcing the creation of a transaction that we won't relay ourselves is .. a bit ugly. :(
  3 2017-01-24 00:12:57	0|Lightsword|gmaxwell, well it would make sense to allow ourselves to relay it as well
  4 2017-01-24 00:13:22	0|sipa|Lightsword: that is equivalent to implementing full RBF
  5 2017-01-24 00:14:11	0|sipa|and we're not going to make an exception for your own transaction, as that's a privacy leak
  6 2017-01-24 00:56:11	0|Lightsword|sipa, would it make sense to have it only under a force flag? I’m mainly thinking it’s better to have the bumpfee option than having to do it manually
  7 2017-01-24 00:58:39	0|sipa|i think the only reasonable way to do it is to first have someone use abandontransaction (which will only work if it's already evicted from the mempool), and then a wrapper to recreate an abandoned transaction with a higher fee (but guaranteeing that some if its inputs are spent again)
  8 2017-01-24 00:58:52	0|sipa|that way you don't need an exception for relay
  9 2017-01-24 01:08:05	0|luke-jr|gmaxwell: what if we would relay it ourselves because it's dropped out of our mempool?
 10 2017-01-24 01:08:26	0|luke-jr|sipa: must it be abandoned explicitly?
 11 2017-01-24 01:09:32	0|sipa|luke-jr: otherwise the wallet won't allow you to respend
 12 2017-01-24 01:09:55	0|luke-jr|sipa: bumpfee will?
 13 2017-01-24 01:14:30	0|sipa|luke-jr: bumpfee won't let you bump without it being bip125
 14 2017-01-24 01:15:04	0|sipa|or are you saying that bumpfee should do that, IF the result would be acceptable to our own mempool?
 15 2017-01-24 01:16:32	0|luke-jr|sipa: and if a "force" option is provided
 16 2017-01-24 01:17:49	0|sipa|that seems reasonable
 17 2017-01-24 01:20:37	0|Lightsword|the user can restart their node to force the transaction out of the mempool right?
 18 2017-01-24 01:22:42	0|sipa|if they delete mempool.dat, yes
 19 2017-01-24 01:26:24	0|Lightsword|is it possible to manually evict a transaction from the mempool by doing a negative prioritisetransaction call so it goes below the minfee needed to stay in the mempool?
 20 2017-01-24 01:35:41	0|morcos|Lightsword: I  think that would only work if the mempool was full (and some other transaction came in to cause limiting)
 21 2017-01-24 01:35:56	0|morcos|however a restart combined with a negative prioritisetransaction might work
 22 2017-01-24 01:36:25	0|Lightsword|morcos, mempool is normally full with the way the limiter currently works right?
 23 2017-01-24 01:36:39	0|sipa|it won't be full shortly after a new block was found
 24 2017-01-24 01:37:26	0|morcos|it doesn't seem so recently..  and even if the network is busy it tends to not stay full b/c fee filter stops you getting cheap replacements
 25 2017-01-24 01:39:30	0|Lightsword|isn’t fee filter mostly based on feerate of recently evicted transactions?
 26 2017-01-24 01:40:22	0|morcos|sipa: i'm not around next week and #9371 or otherwise is necessary for 0.14..   could you take a look and if you agree with the approach, we could at least tag the PR 0.14 and i can give someone else repo access to carry it over the finish line
 27 2017-01-24 01:40:24	0|gribble|https://github.com/bitcoin/bitcoin/issues/9371 | Notify on removal by morcos · Pull Request #9371 · bitcoin/bitcoin · GitHub
 28 2017-01-24 01:40:36	0|morcos|right now just the issue is tagged for 0.14, b/c we never agreed what type of solution we want
 29 2017-01-24 01:41:08	0|sipa|morcos: will do
 30 2017-01-24 01:41:43	0|morcos|Lightsword: yes, but the minfee which the fee filter is set to = incrementalRelayRate (same as minRelayTxFee before 0.14) + the evicted rate.  in practice, this is 1000 sat/KB + 1000 sat/KB
 31 2017-01-24 01:42:13	0|morcos|therefore excluding all the garbage between 1000-2000 sat/KB which is the only way your mempool fills up
 32 2017-01-24 01:42:43	0|morcos|so until the fee rate declines below 1000 sat/KB again...  your mempool tends to get less full...
 33 2017-01-24 01:43:20	0|morcos|that was at least true with 3 day time expiration...    with 2 week time expiration in 0.14, your mempool might stay closer to full?   depending on current tx supply
 34 2017-01-24 01:45:09	0|gmaxwell|sipa: well we could allow abandond transactions to get bumped.
 35 2017-01-24 01:45:47	0|gmaxwell|but we aren't very permissive with abandonment.
 36 2017-01-24 01:46:15	0|morcos|i think we should try as hard as possible to not ever recommend abandoning
 37 2017-01-24 01:46:21	0|morcos|not that it doens't work well
 38 2017-01-24 01:46:43	0|morcos|but i think it'll inevitably lead to people spending different outputs and having both txs confirm
 39 2017-01-24 01:47:39	0|morcos|in that sense, i kind of think Lightsword is right...  if you have a "stuck" transaction and you forgot to make it opt-in RBF, it's probably better to still let you bumpfee it
 40 2017-01-24 01:48:03	0|Lightsword|I think it would be a good idea to let one broadcast as well with a force flag
 41 2017-01-24 01:48:05	0|morcos|otherwise you are going to use abandontransaction and try to do it manually and end up screwing yourself
 42 2017-01-24 01:48:13	0|Lightsword|since it’s a major useability issue
 43 2017-01-24 01:48:21	0|sipa|gmaxwell: i think what luke is suggesting is allowing /abandonable/ transactions to be bumped
 44 2017-01-24 01:49:14	0|sipa|i do think that's better... first fully abandoning them would perhaps introduce a race conditions where you respend the coins in between the abandon and the bump
 45 2017-01-24 01:49:18	0|gmaxwell|I think thats reasonable, but the set of abandonable transactions is so small as to make it hardly matter.
 46 2017-01-24 01:49:42	0|sipa|evicted from mempool is enough, no?
 47 2017-01-24 01:50:11	0|morcos|but that's basically not going to happen, unless you finagle it, and if you're going to finagle it, well why not just let you do it anyway
 48 2017-01-24 01:50:20	0|morcos|whats the downside, privacy leak?
 49 2017-01-24 01:52:10	0|gmaxwell|sipa: what morcos said.
 50 2017-01-24 01:52:42	0|sipa|is it reasonable to expect your transaction will propagate otherwise?
 51 2017-01-24 01:52:59	0|sipa|i would expect relatively similar mempool among your peers
 52 2017-01-24 01:53:02	0|gmaxwell|the major downside is that we'll end up with txn in our wallet that we don't expect to relay, which is something we kind of assume doesn't happen.
 53 2017-01-24 01:53:30	0|gmaxwell|sipa: well except peers change over time, so maybe not. or you might have a full rbf peer.
 54 2017-01-24 01:53:51	0|morcos|or you might want to construct a tx to submit in some out of band way to a miner
 55 2017-01-24 01:54:31	0|gmaxwell|yea, you might not really care about the relay at all.. just plan on extracting the hex and giving it to the antpool doublespending service (I mean free txn priority service)
 56 2017-01-24 02:00:41	0|Lightsword|sipa, I think there are enough nodes with inconsistant relay policy that you have a good chance of propagation even if your own mempool doesn’t accept the transaction, for example nodes with much more strict mempool limiting may accept it
 57 2017-01-24 02:00:55	0|sipa|i wonder if that's a temporary thing
 58 2017-01-24 02:02:11	0|Lightsword|well extreme mempool limiting is usually due to resource limitations(reducing ram usage)
 59 2017-01-24 02:04:39	0|Lightsword|I think in this case the privacy risks are far less of a risk than users messing up the feebump by trying to do it manually and using the wrong utxo’s
 60 2017-01-24 02:08:59	0|gmaxwell|well because bumpfee can only diminish change, it's already pretty limited.
 61 2017-01-24 04:05:38	0|bitcoin-git|[13bitcoin] 15luke-jr opened pull request #9621: Define, check, and use MIN_TRANSACTION_SIZE as a const (06master...06cleanup_mintxsize) 02https://github.com/bitcoin/bitcoin/pull/9621
 62 2017-01-24 05:41:28	0|bitcoin-git|[13bitcoin] 15kallewoof opened pull request #9622: [rpc] Bug-fix: listsinceblock should include lost transactions when parameter is a reorg'd block (06master...06listsinceblock-include-lost-txs) 02https://github.com/bitcoin/bitcoin/pull/9622
 63 2017-01-24 07:01:41	0|gmaxwell|sipa: please close 9616
 64 2017-01-24 07:03:59	0|gmaxwell|"you promised it would only be a three-line change and you delivered :)"  best pull request review comment ever.
 65 2017-01-24 07:17:38	0|sipa|?
 66 2017-01-24 07:18:05	0|bitcoin-git|[13bitcoin] 15sipa closed pull request #9616: Interested in Fixing Vulnerabilities. (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/9616
 67 2017-01-24 07:20:26	0|gmaxwell|sipa: thanks
 68 2017-01-24 08:25:10	0|bitcoin-git|13bitcoin/06master 14fa4d478 15MarcoFalke: qt: Use nPowTargetSpacing constant
 69 2017-01-24 08:25:10	0|bitcoin-git|[13bitcoin] 15jonasschnelli pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/71148b8947fe...50864529b6e7
 70 2017-01-24 08:25:11	0|bitcoin-git|13bitcoin/06master 145086452 15Jonas Schnelli: Merge #9588: qt: Use nPowTargetSpacing constant...
 71 2017-01-24 08:25:23	0|bitcoin-git|[13bitcoin] 15jonasschnelli closed pull request #9588: qt: Use nPowTargetSpacing constant (06master...06Mf1701-qtParams) 02https://github.com/bitcoin/bitcoin/pull/9588
 72 2017-01-24 09:08:33	0|bitcoin-git|[13bitcoin] 15laanwj pushed 4 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/50864529b6e7...4a1dc35ca532
 73 2017-01-24 09:08:34	0|bitcoin-git|13bitcoin/06master 144afbde6 15Alex Morcos: Introduce MemPoolConflictRemovalTracker...
 74 2017-01-24 09:08:34	0|bitcoin-git|13bitcoin/06master 14ff25c32 15Wladimir J. van der Laan: mempool: add notification for added/removed entries...
 75 2017-01-24 09:08:35	0|bitcoin-git|13bitcoin/06master 14094e4b3 15Alex Morcos: Better document usage of SyncTransaction
 76 2017-01-24 09:08:41	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9371: Notify on removal (06master...06notifyOnRemoval) 02https://github.com/bitcoin/bitcoin/pull/9371
 77 2017-01-24 10:04:59	0|gmaxwell|"systemd local root exploit"  ... gentoo user not affected.
 78 2017-01-24 11:14:14	0|morcos|wumpus: thanks for merging 9371!  i think we're starting to get 0.14 in our sights
 79 2017-01-24 11:14:46	0|wumpus|indeed! it's starting to look quit good
 80 2017-01-24 11:14:48	0|morcos|gmaxwell: which importmulti fixes did you want to get in for 0.14, besides the watch only timestamp PR that is already tagged?
 81 2017-01-24 11:14:50	0|wumpus|quitE
 82 2017-01-24 12:21:38	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #8549: zmq: mempool notifications (06master...06zmq_mempool) 02https://github.com/bitcoin/bitcoin/pull/8549
 83 2017-01-24 12:27:37	0|bitcoin-git|13bitcoin/06master 14be31a2b 15Lauda: [Trivial] Update license year range to 2017...
 84 2017-01-24 12:27:37	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/4a1dc35ca532...1ac878ace623
 85 2017-01-24 12:27:38	0|bitcoin-git|13bitcoin/06master 141ac878a 15Wladimir J. van der Laan: Merge #9617: [Trivial] Update license year range to 2017...
 86 2017-01-24 12:27:55	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9617: [Trivial] Update license year range to 2017 (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/9617
 87 2017-01-24 13:10:48	0|bitcoin-git|[13bitcoin] 15jonasschnelli closed pull request #9284: Suppress some annoying deprecation warnings (OSX) (06master...062016/12/osx_warnings) 02https://github.com/bitcoin/bitcoin/pull/9284
 88 2017-01-24 13:11:06	0|bitcoin-git|[13bitcoin] 15jonasschnelli closed pull request #9076: [WIP][Experimental] Add Hybrid full block SPV mode (06master...062016/10/spv) 02https://github.com/bitcoin/bitcoin/pull/9076
 89 2017-01-24 13:12:40	0|bitcoin-git|[13bitcoin] 15jonasschnelli closed pull request #8745: [PoC] Add wallet inspection and modification tool "bitcoin-wallet-tool" (06master...062016/09/wallet-tool) 02https://github.com/bitcoin/bitcoin/pull/8745
 90 2017-01-24 13:26:45	0|jonasschnelli|This little refactoring seems readyish: https://github.com/bitcoin/bitcoin/pull/9143
 91 2017-01-24 13:26:58	0|jonasschnelli|Ahm... right. The freeze.
 92 2017-01-24 13:41:13	0|wumpus|yeah I'm not sure whether it makes sense to do now - a pure refactor is not a bugfix but neither is it a feature - depends on the regression risk I suppose
 93 2017-01-24 13:48:06	0|jonasschnelli|Better after we branch of 0.14
 94 2017-01-24 14:00:54	0|bitcoin-git|[13bitcoin] 15s-matthew-english opened pull request #9623: fixing typo in README (06master...06patch-14) 02https://github.com/bitcoin/bitcoin/pull/9623
 95 2017-01-24 15:21:46	0|jonasschnelli|sf boost download issues in travis: https://travis-ci.org/bitcoin/bitcoin/jobs/194846204#L537
 96 2017-01-24 15:21:52	0|jonasschnelli|hope it's temp. only
 97 2017-01-24 15:25:30	0|BlueMatt|so it looks like the archlinux-arm bitcoin packages are being built using a PKGBUILD different from the one published and building a modified 0.13.2 source tree
 98 2017-01-24 15:25:35	0|BlueMatt|over under on a backdoor?
 99 2017-01-24 15:37:47	0|sipa|ugh
100 2017-01-24 15:48:14	0|BlueMatt|they're looking into it (the alarm guys)
101 2017-01-24 15:48:29	0|BlueMatt|(thats ArchLinux-ARM)
102 2017-01-24 16:43:28	0|cfields|jonasschnelli: crontab (to fetch sources on fallback server) wasn't running. should be fixed now, so fallback should work if sf.net 404's
103 2017-01-24 17:08:11	0|morcos|sipa: got any ideas on #9620?
104 2017-01-24 17:08:13	0|gribble|https://github.com/bitcoin/bitcoin/issues/9620 | Wallet lost track of funds · Issue #9620 · bitcoin/bitcoin · GitHub
105 2017-01-24 17:14:50	0|sipa|morcos: no :(
106 2017-01-24 17:27:20	0|sipa|morcos: "all i do is sendtoaddress" - "the manual CPFP transaction i created"
107 2017-01-24 17:32:48	0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #9624: [Trivial] fix logging typo in FlushStateToDisk() (06master...06TrivialTypo) 02https://github.com/bitcoin/bitcoin/pull/9624
108 2017-01-24 17:45:29	0|cfields|BlueMatt: holy crap, arch packages are built by hand and uploaded?
109 2017-01-24 17:45:44	0|BlueMatt|cfields: on regular arch, yes!
110 2017-01-24 17:45:52	0|BlueMatt|cfields: (as in, holy crap, dont trust arch packages)
111 2017-01-24 17:46:05	0|cfields|that's terrifying
112 2017-01-24 17:46:14	0|BlueMatt|cfields: archlinux-arm has a build farm, apparently
113 2017-01-24 17:46:25	0|BlueMatt|cfields: everything is, when you look closely
114 2017-01-24 17:46:27	0|cfields|i went looking for a build log, only to come to the depressing realization :(
115 2017-01-24 17:47:05	0|cfields|BlueMatt: looks like it's possible to me that their builder gets confused by the tag version, and doesn't end up checking out the tag
116 2017-01-24 17:47:06	0|BlueMatt|cfields: I dont think there is a single linux distro which I would trust almost in any way at all....even the ones with build farms end up accepting sigs from any one of a million people to update the source files :/
117 2017-01-24 17:47:34	0|BlueMatt|cfields: the binary reports "v0.13.2.0-0d719145b-dirty"
118 2017-01-24 17:47:39	0|BlueMatt|that commit is v0.13.2
119 2017-01-24 17:47:49	0|BlueMatt|(though dunno where the ".0" came from - is that normal for git describe?)
120 2017-01-24 17:47:59	0|cfields|hmm
121 2017-01-24 17:48:04	0|BlueMatt|the non-arm archlinux binary properly reports "v0.13.2"
122 2017-01-24 17:48:10	0|BlueMatt|well, I didnt run it, just strings'd it
123 2017-01-24 17:48:17	0|cfields|yes, i'm looking at the same now
124 2017-01-24 17:49:50	0|cfields|ok good, well at least it's based on the right version
125 2017-01-24 17:50:05	0|bitcoin-git|[13bitcoin] 15morcos opened pull request #9625: Increase minimum debug.log size to 9MB after shrink. (06master...06shrinkless) 02https://github.com/bitcoin/bitcoin/pull/9625
126 2017-01-24 17:50:07	0|BlueMatt|"based on" i mean the "-dirty" coul be anything
127 2017-01-24 17:50:19	0|cfields|right
128 2017-01-24 17:50:57	0|BlueMatt|I went through what appears to be their build farm tool at https://github.com/archlinuxarm/plugbuild and noted changes it makes to the PKGBUILD file at https://github.com/archlinuxarm/plugbuild/blob/master/client.pl#L344
129 2017-01-24 17:51:09	0|BlueMatt|but was still unable to reproduce the PKGBUILD hash claimed in the .BUILDINFO file
130 2017-01-24 17:53:37	0|cfields|where's the .BUILDINFO coming from?
131 2017-01-24 17:54:02	0|BlueMatt|the .pkg.tar.xz thing that is the package itself has a .BUILDINFO file in it
132 2017-01-24 17:54:17	0|cfields|ah, thanks. grabbing
133 2017-01-24 17:55:28	0|BlueMatt|(note that the pkgbuild_sha256sum in the non-arm archlinux packages also doesnt match, but I cant figure out what modifications might be happening before that hash is calculated)
134 2017-01-24 19:10:34	0|morcos|gmaxwell: that -shrinkdebugfile is only defaulted on if no debug options are present, you don't think 9MB is enough then?
135 2017-01-24 19:13:50	0|gmaxwell|morcos: I know-- my though is that I've troubleshoot people on nodes that went out of sync two weeks before, and their log was full of connect/disconnect messages. Maybe you're right that 9MB is enough.  I do sort of wish critical errors went into a seperate very low volume log that was never rotated.
136 2017-01-24 19:14:25	0|morcos|yeah i certainly don't mind doing more, was just tryign to make the patch as unobjectionable as possible
137 2017-01-24 19:14:37	0|gmaxwell|yea, it's fine.
138 2017-01-24 19:44:04	0|jonasschnelli|morcos: The new CWallet::IsChange() function does not work after a zapwallettx, right?
139 2017-01-24 19:52:14	0|morcos|hmm, jonasschnelli i think your question confused me.  Isn't that function old?  And I'm not very familiar with zapwallettx, so not really sure what it would do?
140 2017-01-24 19:53:05	0|jonasschnelli|morcos: I though it's a new one... I'm doing my bumpfee review pretty late. I know.. but I just had the feeling that detecting the change output based on the address book is kinda-bad
141 2017-01-24 19:54:30	0|jonasschnelli|Though,... is change when it's _not_ in the address book. I guess bumpfee should still work after a zapwallettx
142 2017-01-24 19:54:47	0|morcos|well as far as i can tell it doesn't really matter...  the failure modes are : 1) it can't find change (or finds more than 1) and can't bump the tx  or 2) it reduces another output to you instead of change, doesn't seem so bad
143 2017-01-24 19:55:56	0|jonasschnelli|Yes. Right.
144 2017-01-24 19:56:33	0|jonasschnelli|Have you guys already started working on the case where bumping requires new input?
145 2017-01-24 19:56:42	0|jonasschnelli|Like when you use subtractfeefromamount
146 2017-01-24 19:56:54	0|ryanofsky|have not done work on that
147 2017-01-24 19:57:25	0|jonasschnelli|ryanofsky: thanks for the info. Maybe its not worth the effort..
148 2017-01-24 19:57:30	0|gmaxwell|being able to spend bumped outputs is more important in that case... since the bumps will tie up more inputs.
149 2017-01-24 19:57:41	0|morcos|I don't think that makes sense for combination with subtract fee from amount
150 2017-01-24 19:58:17	0|morcos|well at least i think we should more narrowly define what we are trying to accomplish wiht subtractfeefromamount anyway..
151 2017-01-24 19:58:48	0|jonasschnelli|morcos: If you have a single input, assume 25BTC, and you spend the 25BTC with subtract-fee-from-amount you endup with a tx without change.
152 2017-01-24 19:58:50	0|morcos|it causes a lot of complication in the code when as far as i can tell the main use case is just send all this money over there
153 2017-01-24 19:59:13	0|jonasschnelli|I think its a fantastic feature (subtract fee from amount).
154 2017-01-24 19:59:15	0|morcos|yeah so the way to bump that is reduce the output in my opinion
155 2017-01-24 19:59:35	0|jonasschnelli|From other wallet uses-cases, I know that people are trying to send-out the wallet funds with often leaving some coins behind.
156 2017-01-24 19:59:50	0|morcos|yes, i agree thats a use case worse supporting
157 2017-01-24 20:00:46	0|morcos|but we use it in a more general sense...  which is annoying...  like reducing the outputs even further to give ourselves dust change if we would have had sub-dust change... see #9343
158 2017-01-24 20:00:48	0|gribble|https://github.com/bitcoin/bitcoin/issues/9343 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
159 2017-01-24 20:09:59	0|jonasschnelli|Another wild thought,... we should probably reject self created transactions with absurde high fee during signrawtransaction (additional to ATM over sendrawtx)
160 2017-01-24 20:17:18	0|bitcoin-git|13bitcoin/06master 14ac9a846 15John Newbery: [Trivial] fix logging typo in FlushStateToDisk()
161 2017-01-24 20:17:18	0|bitcoin-git|[13bitcoin] 15jonasschnelli pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/1ac878ace623...b68f898efa09
162 2017-01-24 20:17:19	0|bitcoin-git|13bitcoin/06master 14b68f898 15Jonas Schnelli: Merge #9624: [Trivial] fix logging typo in FlushStateToDisk()...
163 2017-01-24 20:17:40	0|bitcoin-git|[13bitcoin] 15jonasschnelli closed pull request #9624: [Trivial] fix logging typo in FlushStateToDisk() (06master...06TrivialTypo) 02https://github.com/bitcoin/bitcoin/pull/9624
164 2017-01-24 20:19:37	0|gmaxwell|morcos: there are a bunch of small issues, I need to find the branch and pick them up. It mishandles locked wallets (it should reject trying to import a private key when the wallet is locked),  if you ask it to import a key without a birthday it just assumes now and can cause funds loss,  it's easy to cause it to rescan everything when you didn't think it would... node out of comission for hours
165 2017-01-24 20:19:43	0|gmaxwell|...
166 2017-01-24 20:20:15	0|morcos|right.. well nudge nudge,  0.14 is in the car with the engine running..
167 2017-01-24 20:29:35	0|BlueMatt|gmaxwell: please at least file issues for known issues and ask to have them marked 0.14....
168 2017-01-24 20:31:06	0|gmaxwell|sorry for whining, but I already opened an issue for one of them where I _need_ feedback before doing anything, and only morcos commented a bit. #9491
169 2017-01-24 20:31:07	0|gribble|https://github.com/bitcoin/bitcoin/issues/9491 | Importmulti api is confusing in a way that could lead to funds loss. · Issue #9491 · bitcoin/bitcoin · GitHub
170 2017-01-24 20:31:19	0|gmaxwell|this is not convincing me of the utility of opening more issues.
171 2017-01-24 20:35:10	0|BlueMatt|behind on things, sorry :/
172 2017-01-24 20:35:29	0|BlueMatt|gmaxwell: opening issues gives us all a view into how close we are to release, and also ensures we dont end up with stuff outstanding until a day before rc
173 2017-01-24 20:35:58	0|BlueMatt|gmaxwell: there are multiple reasons to open issues
174 2017-01-24 20:49:12	0|gmaxwell|I don't disagree with anything you are saying there. This doesn't change that if you want people opening issues, you need to respond to the issues they open. Asking if fine too, but it will be ultimately ineffective if people feel that they're wasting their time.
175 2017-01-24 20:51:41	0|BlueMatt|sorry, somehow I had #9491 marked in my mental list of "oh, that one has an open pr for it to fix it already"
176 2017-01-24 20:51:43	0|gribble|https://github.com/bitcoin/bitcoin/issues/9491 | Importmulti api is confusing in a way that could lead to funds loss. · Issue #9491 · bitcoin/bitcoin · GitHub
177 2017-01-24 20:51:49	0|BlueMatt|not sure how it got there, but it did
178 2017-01-24 20:52:51	0|gmaxwell|s/if fine/is fine/
179 2017-01-24 22:19:59	0|bitcoin-git|[13bitcoin] 15TheBlueMatt opened pull request #9626: Clean up a few CConnman cs_vNodes/CNode things (06master...062017-01-remove-broken-unused-funcs) 02https://github.com/bitcoin/bitcoin/pull/9626
180 2017-01-24 23:28:20	0|cfields|BlueMatt: thanks for remembering those
181 2017-01-24 23:28:51	0|BlueMatt|can we mark #9622 as 0.14 since its a pretty big bugfix and isnt too complicated?
182 2017-01-24 23:28:53	0|gribble|https://github.com/bitcoin/bitcoin/issues/9622 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
183 2017-01-24 23:36:52	0|cfields|agree