1 2016-11-21T00:09:57  *** alpalp has quit IRC
  2 2016-11-21T00:12:30  *** Chris_Stewart_5 has joined #bitcoin-core-dev
  3 2016-11-21T00:18:48  *** musalbas has quit IRC
  4 2016-11-21T00:24:14  *** musalbas has joined #bitcoin-core-dev
  5 2016-11-21T00:29:20  *** alpalp has joined #bitcoin-core-dev
  6 2016-11-21T00:35:57  *** CubicEarth has quit IRC
  7 2016-11-21T00:38:13  *** owowo has quit IRC
  8 2016-11-21T00:43:26  *** owowo has joined #bitcoin-core-dev
  9 2016-11-21T00:45:37  *** alpalp has quit IRC
 10 2016-11-21T00:47:38  *** kinlo has quit IRC
 11 2016-11-21T00:48:40  *** kinlo has joined #bitcoin-core-dev
 12 2016-11-21T00:53:47  *** CubicEarth has joined #bitcoin-core-dev
 13 2016-11-21T00:54:34  *** alpalp has joined #bitcoin-core-dev
 14 2016-11-21T01:25:31  *** takashi has joined #bitcoin-core-dev
 15 2016-11-21T01:28:04  *** btcdrak has quit IRC
 16 2016-11-21T01:30:31  *** echonaut has quit IRC
 17 2016-11-21T01:30:53  *** echonaut has joined #bitcoin-core-dev
 18 2016-11-21T01:40:22  *** CubicEarth has quit IRC
 19 2016-11-21T01:55:42  *** CubicEarth has joined #bitcoin-core-dev
 20 2016-11-21T02:05:08  *** CubicEarth has quit IRC
 21 2016-11-21T02:08:11  *** windsok has quit IRC
 22 2016-11-21T02:12:39  *** Ylbam has quit IRC
 23 2016-11-21T02:27:28  *** Chris_Stewart_5 has quit IRC
 24 2016-11-21T02:36:33  *** xiangfu has quit IRC
 25 2016-11-21T02:36:55  *** xiangfu has joined #bitcoin-core-dev
 26 2016-11-21T02:56:17  *** ibrightly has quit IRC
 27 2016-11-21T02:57:37  *** DigiByteDev has joined #bitcoin-core-dev
 28 2016-11-21T02:58:33  *** ibrightly has joined #bitcoin-core-dev
 29 2016-11-21T03:05:57  *** CubicEarth has joined #bitcoin-core-dev
 30 2016-11-21T03:08:15  *** aalex__ has joined #bitcoin-core-dev
 31 2016-11-21T03:11:03  *** CubicEarth has quit IRC
 32 2016-11-21T03:13:06  *** kinlo has quit IRC
 33 2016-11-21T03:13:44  *** murchandamus has quit IRC
 34 2016-11-21T03:14:13  *** Bootvis_ has quit IRC
 35 2016-11-21T03:14:33  *** aalex__ has quit IRC
 36 2016-11-21T03:14:33  *** kinlo has joined #bitcoin-core-dev
 37 2016-11-21T03:14:33  *** murchandamus has joined #bitcoin-core-dev
 38 2016-11-21T03:15:18  *** Bootvis has joined #bitcoin-core-dev
 39 2016-11-21T03:17:57  *** alpalp has quit IRC
 40 2016-11-21T03:31:09  *** windsok has joined #bitcoin-core-dev
 41 2016-11-21T04:06:43  *** CubicEarth has joined #bitcoin-core-dev
 42 2016-11-21T04:12:38  *** CubicEarth has quit IRC
 43 2016-11-21T04:28:27  *** CubicEarth has joined #bitcoin-core-dev
 44 2016-11-21T04:40:22  *** Alopex has quit IRC
 45 2016-11-21T04:40:56  *** CubicEarth has quit IRC
 46 2016-11-21T04:41:00  *** kanzure has quit IRC
 47 2016-11-21T04:41:27  *** Alopex has joined #bitcoin-core-dev
 48 2016-11-21T04:43:22  *** kanzure has joined #bitcoin-core-dev
 49 2016-11-21T04:53:16  *** DigiByteDev has quit IRC
 50 2016-11-21T04:54:58  *** btcdrak has joined #bitcoin-core-dev
 51 2016-11-21T05:04:10  *** Giszmo has quit IRC
 52 2016-11-21T05:12:54  *** kadoban has joined #bitcoin-core-dev
 53 2016-11-21T05:13:03  *** DigiByteDev has joined #bitcoin-core-dev
 54 2016-11-21T05:15:06  *** Alopex has quit IRC
 55 2016-11-21T05:16:11  *** Alopex has joined #bitcoin-core-dev
 56 2016-11-21T05:41:49  *** CubicEarth has joined #bitcoin-core-dev
 57 2016-11-21T05:46:09  *** CubicEarth has quit IRC
 58 2016-11-21T05:56:12  *** Alopex has quit IRC
 59 2016-11-21T05:56:49  *** kadoban has quit IRC
 60 2016-11-21T05:57:17  *** Alopex has joined #bitcoin-core-dev
 61 2016-11-21T05:58:04  *** CubicEarth has joined #bitcoin-core-dev
 62 2016-11-21T06:24:30  *** jtimon has quit IRC
 63 2016-11-21T07:03:13  *** CubicEarth has quit IRC
 64 2016-11-21T07:03:27  *** CubicEarth has joined #bitcoin-core-dev
 65 2016-11-21T07:04:59  *** luke-jr has quit IRC
 66 2016-11-21T07:05:08  *** luke-jr has joined #bitcoin-core-dev
 67 2016-11-21T07:25:41  *** rb___ has joined #bitcoin-core-dev
 68 2016-11-21T07:27:15  *** cysm has quit IRC
 69 2016-11-21T07:27:29  *** justanotheruser has quit IRC
 70 2016-11-21T07:33:06  *** justanotheruser has joined #bitcoin-core-dev
 71 2016-11-21T07:37:53  <bitcoin-git> [bitcoin] laanwj closed pull request #9193: Update copyright year to 2016 (master...patch-1) https://github.com/bitcoin/bitcoin/pull/9193
 72 2016-11-21T07:43:28  *** rb___ has quit IRC
 73 2016-11-21T07:46:12  *** Ylbam has joined #bitcoin-core-dev
 74 2016-11-21T08:00:20  *** CubicEarth has quit IRC
 75 2016-11-21T08:10:08  *** aalex__ has joined #bitcoin-core-dev
 76 2016-11-21T08:17:41  *** aalex__ has quit IRC
 77 2016-11-21T08:50:42  *** achow101 has quit IRC
 78 2016-11-21T08:50:45  *** gribble has quit IRC
 79 2016-11-21T08:52:03  *** achow101 has joined #bitcoin-core-dev
 80 2016-11-21T09:01:05  *** e6xit has joined #bitcoin-core-dev
 81 2016-11-21T09:05:25  *** rubensayshi has joined #bitcoin-core-dev
 82 2016-11-21T09:16:12  *** jannes has joined #bitcoin-core-dev
 83 2016-11-21T09:22:16  *** gribble has joined #bitcoin-core-dev
 84 2016-11-21T09:52:11  <bitcoin-git> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/44adf683ad23...7490ae8b699d
 85 2016-11-21T09:52:12  <bitcoin-git> bitcoin/master 0e85204 Pieter Wuille: Add serialization for unique_ptr and shared_ptr
 86 2016-11-21T09:52:12  <bitcoin-git> bitcoin/master da60506 Pieter Wuille: Add deserializing constructors to CTransaction and CMutableTransaction
 87 2016-11-21T09:52:13  <bitcoin-git> bitcoin/master 1662b43 Pieter Wuille: Make CBlock::vtx a vector of shared_ptr<CTransaction>
 88 2016-11-21T09:52:21  <bitcoin-git> [bitcoin] laanwj closed pull request #9125: Make CBlock a vector of shared_ptr of CTransactions (master...sharedblock) https://github.com/bitcoin/bitcoin/pull/9125
 89 2016-11-21T09:52:50  <gmaxwell> \O/
 90 2016-11-21T10:02:50  *** justanotheruser has quit IRC
 91 2016-11-21T10:03:01  *** Victor_sueca has joined #bitcoin-core-dev
 92 2016-11-21T10:05:25  *** Victorsueca has quit IRC
 93 2016-11-21T10:07:30  *** justanotheruser has joined #bitcoin-core-dev
 94 2016-11-21T10:07:39  *** Guyver2 has joined #bitcoin-core-dev
 95 2016-11-21T10:12:05  *** Victor_sueca is now known as Victorsueca
 96 2016-11-21T10:23:39  <BlueMatt> sipa: did you ever benchmark how much of #9125's performance improvement was actually just the #9014 stuff? (I assume a lot, though the real benifit is compact block speedups here, which reindex cannot test)
 97 2016-11-21T10:23:41  <gribble> https://github.com/bitcoin/bitcoin/issues/9125 | Make CBlock a vector of shared_ptr of CTransactions by sipa · Pull Request #9125 · bitcoin/bitcoin · GitHub
 98 2016-11-21T10:23:44  <gribble> https://github.com/bitcoin/bitcoin/issues/9014 | Fix block-connection performance regression by TheBlueMatt · Pull Request #9014 · bitcoin/bitcoin · GitHub
 99 2016-11-21T10:51:28  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7490ae8b699d...c3906403c8ed
100 2016-11-21T10:51:28  <bitcoin-git> bitcoin/master 4662553 Cory Fields: net: don't send feefilter messages before the version handshake is complete
101 2016-11-21T10:51:29  <bitcoin-git> bitcoin/master c390640 Wladimir J. van der Laan: Merge #9117: net: don't send feefilter messages before the version handshake is complete...
102 2016-11-21T10:51:39  <bitcoin-git> [bitcoin] laanwj closed pull request #9117: net: don't send feefilter messages before the version handshake is complete (master...feefilter-assert) https://github.com/bitcoin/bitcoin/pull/9117
103 2016-11-21T10:52:42  *** DigiByteDev has quit IRC
104 2016-11-21T10:52:59  *** MarcoFalke has joined #bitcoin-core-dev
105 2016-11-21T10:56:40  *** xiangfu has quit IRC
106 2016-11-21T10:57:48  *** xiangfu has joined #bitcoin-core-dev
107 2016-11-21T11:07:09  *** laurentmt has joined #bitcoin-core-dev
108 2016-11-21T11:11:51  *** laurentmt has quit IRC
109 2016-11-21T11:20:07  *** MarcoFalke has left #bitcoin-core-dev
110 2016-11-21T11:48:04  *** e6xit has quit IRC
111 2016-11-21T11:48:16  *** e6xit has joined #bitcoin-core-dev
112 2016-11-21T12:08:37  *** aalex__ has joined #bitcoin-core-dev
113 2016-11-21T12:16:24  *** aalex__ has quit IRC
114 2016-11-21T12:49:19  <jonasschnelli> wumpus: do you have plans to rebase #7729? Otherwise I can pick it up.
115 2016-11-21T12:49:20  <gribble> https://github.com/bitcoin/bitcoin/issues/7729 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
116 2016-11-21T12:49:41  <wumpus> yes, I'll get back to that at some point
117 2016-11-21T12:50:29  <wumpus> happy some people are finally commenting on the API
118 2016-11-21T12:52:18  <jonasschnelli> Yes. Thanks to last weeks meeting.
119 2016-11-21T13:06:12  *** cjcj has quit IRC
120 2016-11-21T13:20:11  <instagibbs> wumpus, I'm not an old timer, which is why I'm asking more basic account questions. It's always been deprecated in my Bitcoin lifetime :P
121 2016-11-21T13:21:11  <wumpus> right, it's always been deprecated, it's time to move forward there
122 2016-11-21T13:21:20  <wumpus> "always"
123 2016-11-21T13:22:17  <instagibbs> But my assumption is correct, yes? That accounts gave balances which were often screwy/inconsistent, people should be doing this at higher layers by getting lists of outputs under labels or whatever?
124 2016-11-21T13:23:04  <wumpus> yes, it's a mess, people have shot themselves in the foot using it many times, and also most expect it to be something else than it is (eg "subwallets" with their own utxos)
125 2016-11-21T13:23:18  <wumpus> it's indeed not something that belongs at the wallet level
126 2016-11-21T13:23:37  <instagibbs> Yes I recall finding the comment in code about using * was incorrect in retrieving same balances, but I couldn't even describe the replacement text and gave up
127 2016-11-21T13:24:00  *** YOU-JI has joined #bitcoin-core-dev
128 2016-11-21T13:24:01  *** Giszmo has joined #bitcoin-core-dev
129 2016-11-21T13:24:38  *** justanotheruser has quit IRC
130 2016-11-21T13:29:36  <wumpus> so should the argument to importaddress and sendtoaddress etc be called "address" or "bitcoinaddress"? we use a mix of both, which isn't very consistent
131 2016-11-21T13:30:20  *** justanotheruser has joined #bitcoin-core-dev
132 2016-11-21T13:30:29  <wumpus> same with importprivkey which uses "bitcoinprivkey" as argument name, but "importpubkey" which just uses "pubkey". Should make these consistent for #8811
133 2016-11-21T13:30:31  <gribble> https://github.com/bitcoin/bitcoin/issues/8811 | rpc: Add support for JSON-RPC named arguments by laanwj · Pull Request #8811 · bitcoin/bitcoin · GitHub
134 2016-11-21T13:30:53  <wumpus> my preference would be the shorter name, it *is* bitcoin we don't have any other context where we use address/pubkey/privkey
135 2016-11-21T13:35:29  <instagibbs> shorter is better unless it results in overload in the context
136 2016-11-21T13:36:24  <wumpus> right
137 2016-11-21T13:36:42  <wumpus> changing to just "address" then
138 2016-11-21T13:49:50  *** Chris_Stewart_5 has joined #bitcoin-core-dev
139 2016-11-21T13:49:56  *** BonyM1 has quit IRC
140 2016-11-21T13:55:41  *** e6xit has quit IRC
141 2016-11-21T13:59:54  *** e6xit has joined #bitcoin-core-dev
142 2016-11-21T14:04:28  *** takashi has quit IRC
143 2016-11-21T14:05:33  *** BonyM1 has joined #bitcoin-core-dev
144 2016-11-21T14:09:28  *** e6xit has quit IRC
145 2016-11-21T14:09:38  *** e6xit has joined #bitcoin-core-dev
146 2016-11-21T14:28:14  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c3906403c8ed...b9a87b459d25
147 2016-11-21T14:28:14  <bitcoin-git> bitcoin/master fa7cc5a MarcoFalke: Set DEFAULT_LIMITFREERELAY = 0 kB/minute
148 2016-11-21T14:28:15  <bitcoin-git> bitcoin/master b9a87b4 Wladimir J. van der Laan: Merge #9179: Set DEFAULT_LIMITFREERELAY = 0 kB/minute...
149 2016-11-21T14:28:26  <bitcoin-git> [bitcoin] laanwj closed pull request #9179: Set DEFAULT_LIMITFREERELAY = 0 kB/minute (master...Mf1611-blockFreeTxs) https://github.com/bitcoin/bitcoin/pull/9179
150 2016-11-21T14:33:46  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/b9a87b459d25...210891143ba0
151 2016-11-21T14:33:46  <bitcoin-git> bitcoin/master 7451cf5 jnewbery: Allow bitcoin-tx to parse partial transactions...
152 2016-11-21T14:33:47  <bitcoin-git> bitcoin/master 2108911 Wladimir J. van der Laan: Merge #8837: allow bitcoin-tx to parse partial transactions...
153 2016-11-21T14:33:53  <bitcoin-git> [bitcoin] laanwj closed pull request #8837: allow bitcoin-tx to parse partial transactions (master...bitcoin-tx-partial-transactions) https://github.com/bitcoin/bitcoin/pull/8837
154 2016-11-21T14:41:57  <bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/210891143ba0...0c577f2638b7
155 2016-11-21T14:41:58  <bitcoin-git> bitcoin/master d768f15 mrbandrews: [qa] Make comptool push blocks instead of relying on inv-fetch
156 2016-11-21T14:41:58  <bitcoin-git> bitcoin/master 3451203 Matt Corallo: [qa] Respond to getheaders and do not assume a getdata on inv
157 2016-11-21T14:41:59  <bitcoin-git> bitcoin/master 037159c Matt Corallo: Remove block-request logic from INV message processing
158 2016-11-21T14:42:08  <bitcoin-git> [bitcoin] laanwj closed pull request #8872: Remove block-request logic from INV message processing (master...fetchflags2) https://github.com/bitcoin/bitcoin/pull/8872
159 2016-11-21T14:42:10  *** BonyM1 has quit IRC
160 2016-11-21T14:44:09  *** crudel has quit IRC
161 2016-11-21T14:47:09  *** jtimon has joined #bitcoin-core-dev
162 2016-11-21T14:48:01  *** Chris_Stewart_5 has quit IRC
163 2016-11-21T14:56:46  *** BonyM1 has joined #bitcoin-core-dev
164 2016-11-21T15:02:18  *** Chris_Stewart_5 has joined #bitcoin-core-dev
165 2016-11-21T15:15:00  *** e6xit has quit IRC
166 2016-11-21T15:15:19  *** e6xit has joined #bitcoin-core-dev
167 2016-11-21T15:18:53  *** YOU-JI has quit IRC
168 2016-11-21T15:20:39  *** AaronvanW has quit IRC
169 2016-11-21T15:23:45  *** AaronvanW has joined #bitcoin-core-dev
170 2016-11-21T15:23:45  *** AaronvanW has quit IRC
171 2016-11-21T15:23:45  *** AaronvanW has joined #bitcoin-core-dev
172 2016-11-21T15:31:20  *** aalex__ has joined #bitcoin-core-dev
173 2016-11-21T15:34:30  *** e6xit has quit IRC
174 2016-11-21T15:34:40  *** e6xit has joined #bitcoin-core-dev
175 2016-11-21T15:38:04  *** aalex__ has quit IRC
176 2016-11-21T15:44:32  *** e6xit has quit IRC
177 2016-11-21T15:44:41  *** e6xit has joined #bitcoin-core-dev
178 2016-11-21T16:03:03  <bitcoin-git> [bitcoin] ryanofsky opened pull request #9196: Send tip change notification from invalidateblock (master...pr/notify-tip) https://github.com/bitcoin/bitcoin/pull/9196
179 2016-11-21T16:06:50  *** kadoban has joined #bitcoin-core-dev
180 2016-11-21T16:08:56  *** e6xit has quit IRC
181 2016-11-21T16:14:11  <thermoman> hi. I've got a transaction that's somehow not relayed to the network. but when doing getrawtransaction and sendrawtransaction afterwards it's relayed to the network
182 2016-11-21T16:14:18  <thermoman> is this a known issue somehow?
183 2016-11-21T16:15:54  <sdaftuar> thermoman: is this for a brand new transaction you created, or an old wallet transaction?
184 2016-11-21T16:16:06  <thermoman> ok, it just was relayed to the network - but a hughe delay
185 2016-11-21T16:16:13  <thermoman> sdaftuar: it's a brand new tx
186 2016-11-21T16:16:31  <thermoman> we have noticed big delays since 2 or 3 days
187 2016-11-21T16:16:50  <sipa> thermoman: define huge?
188 2016-11-21T16:17:01  <thermoman> doing sendrawtransaction as a workaround after the initial TX the TX was then immediately visible
189 2016-11-21T16:17:28  <sdaftuar> thermoman: can you clarify how you're telling that the tx is "visible"?
190 2016-11-21T16:17:58  <sdaftuar> ie, visible on some 3rd party explorer?
191 2016-11-21T16:18:11  <sdaftuar> or are you looking at your node's relay behavior more directly?
192 2016-11-21T16:18:12  <thermoman> lemme get that info from our dev
193 2016-11-21T16:18:20  <thermoman> I guess 3rd party
194 2016-11-21T16:18:23  <thermoman> like blockchain.info
195 2016-11-21T16:18:44  <thermoman> i query the dev right now
196 2016-11-21T16:20:32  <sipa> also, what kind of delays are we talking about? second? minutes? hours?
197 2016-11-21T16:21:44  <thermoman> http://pastebin.com/LXT4GmnP
198 2016-11-21T16:21:51  <thermoman> sipa, sdaftuar ^
199 2016-11-21T16:22:05  <thermoman> delay ~20 minutes
200 2016-11-21T16:24:55  <sipa> thermoman: can you show a few lines that come after the first broadcast?
201 2016-11-21T16:30:29  <thermoman> sure, one moment
202 2016-11-21T16:35:20  <thermoman> sipa: http://pastebin.com/8TEFK0Ee
203 2016-11-21T16:35:27  <thermoman> this comes directly below it
204 2016-11-21T16:35:54  <thermoman> the node in question is connected to a proxy node via connect=<IP>:8333
205 2016-11-21T16:36:05  <thermoman> it seems like the connection to the proxy node got reset
206 2016-11-21T16:36:18  <thermoman> all nodes run 0.13.1
207 2016-11-21T16:36:19  <sdaftuar> right, so you had no peer to broadcast to initially
208 2016-11-21T16:37:28  <sdaftuar> which would explain the delays you're seeing, though it raises the question of why you're getting disconnected
209 2016-11-21T16:37:41  <thermoman> right. the proxy node is on the LAN
210 2016-11-21T16:38:23  <sdaftuar> if you can share the debug log info around the time of a disconnect, that might help indicate if it's a bitcoind issue
211 2016-11-21T16:38:45  <thermoman> you mean from the proxy node, right?
212 2016-11-21T16:39:00  <thermoman> the proxy node isn't running with debug=1 - will have to change that
213 2016-11-21T16:39:02  <sdaftuar> well it might be helpful to see it from both sides' point of view
214 2016-11-21T16:39:22  <sdaftuar> if you just have one debug log, we can look at that
215 2016-11-21T16:40:17  <thermoman> lemme activate debug=1 on the proxy node. and when the error occurs again tomorrow i'll put both debug logs on pastebin
216 2016-11-21T16:40:20  <thermoman> ok?
217 2016-11-21T16:41:00  <sipa> thermoman: i believe you were not even connected to your proxy node when the transaction was creates
218 2016-11-21T16:42:16  <sipa> oh, sdaftuar already told you thay
219 2016-11-21T16:42:52  <sdaftuar> thermoman: does your proxy node -whitelist your internal node?
220 2016-11-21T16:43:39  <thermoman> sdaftuar: yes
221 2016-11-21T16:43:51  <thermoman> # Whitelist internal networks
222 2016-11-21T16:44:01  <thermoman> whitelist=a.b.c.d/24
223 2016-11-21T16:44:11  <thermoman> from bitcoin.conf on proxy node
224 2016-11-21T16:46:13  <thermoman> we now have debug=1 on proxy node. we'll monitor the debug.log from the proxy for new connections from our nodes and when this happens again I will come back here
225 2016-11-21T16:46:18  <thermoman> thanks so far
226 2016-11-21T16:47:24  <sdaftuar> ok, sounds good.  if you have the debug.log from your internal node available where you saw the disconnect, we should be able to tell if your internal node decided to disconnect your proxy for some reason.
227 2016-11-21T16:48:02  <sdaftuar> also, if the proxy rejected something your node sent it, causing a disconnect, we would be able to see that as well, i thnk
228 2016-11-21T16:57:16  <thermoman> ok
229 2016-11-21T16:57:35  <thermoman> here is the interesting part from the node behind the proxy
230 2016-11-21T17:05:23  <thermoman> sdaftuar, sipa: http://pastebin.com/ZzLpLiLU
231 2016-11-21T17:05:40  <thermoman> this is the stripped down log from the node sending the TX (behind the proxy)
232 2016-11-21T17:05:44  *** luke-jr has quit IRC
233 2016-11-21T17:05:53  *** luke-jr has joined #bitcoin-core-dev
234 2016-11-21T17:05:54  <thermoman> the issue occured several times after importing a privkey
235 2016-11-21T17:06:52  *** rubensayshi has quit IRC
236 2016-11-21T17:07:05  <sdaftuar> ah.  i wonder if your node was too busy to respond to ping messages, causing a disconnect?
237 2016-11-21T17:07:14  <thermoman> that might be
238 2016-11-21T17:07:29  <thermoman> it seems the import did block everything else
239 2016-11-21T17:07:58  <thermoman> and directly after the import the TX was created (while being disconnected from the proxy)
240 2016-11-21T17:08:41  <thermoman> should timeouts be upped on our nodes?
241 2016-11-21T17:08:43  <sdaftuar> the second disconnect seems a bit different though
242 2016-11-21T17:08:55  <thermoman> yeah
243 2016-11-21T17:09:00  <thermoman> it's directly after
244 2016-11-21T17:09:00  <thermoman> Erased 100 orphan tx from peer 1
245 2016-11-21T17:09:16  <thermoman> should the nodes behind the proxy whitelist the proxy-ip, too?
246 2016-11-21T17:09:28  <thermoman> at the moment only the proxy has whitelisted the client ips
247 2016-11-21T17:09:59  *** grubles has joined #bitcoin-core-dev
248 2016-11-21T17:10:06  <sdaftuar> thermoman: i don't think it would hurt, though i'm not sure yet what's going on
249 2016-11-21T17:14:00  <sdaftuar> ok i guess the interesting thing about the second disconnect is that your node tried to connect to it at 15:28:07, and then didn't send the version message untl 15:51
250 2016-11-21T17:14:31  <sdaftuar> so this looks like the wallet operation is contending with the p2p code, and network timeouts are being hit
251 2016-11-21T17:15:38  <thermoman> ah ok, didn't miss the connection between "Added connection" and "sending version message"
252 2016-11-21T17:15:44  <thermoman> s/didn't/did/
253 2016-11-21T17:16:29  <thermoman> current workaround for us is to wait a minute after importing is done
254 2016-11-21T17:17:15  <sdaftuar> thermoman: seems like a reasonable workaround for now.  thanks for reporting this, i think this is something we should look into and improve
255 2016-11-21T17:22:01  <thermoman> do you add an issue in github or should I?
256 2016-11-21T17:23:40  <thermoman> we've only seen this issue after upgrading the proxy node von 0.11.2 to 0.13.1
257 2016-11-21T17:24:14  <thermoman> the node with the TX was running 0.11.2 until some hours ago and we noticed this behaviour with 0.11.2 and even after upgrading the node to 0.13.1
258 2016-11-21T17:24:42  <thermoman> so it seems to have started after upgrading the proxy node
259 2016-11-21T17:25:04  <thermoman> if I don't hear from you I'll open an issue on github tomorrow
260 2016-11-21T17:25:06  <sdaftuar> hmm, this issue really seems like it's specific to the internal node.
261 2016-11-21T17:25:27  <sdaftuar> please go ahead and open the issue, thanks!
262 2016-11-21T17:25:33  <thermoman> we never had this with 0.11.2 on both nodes
263 2016-11-21T17:25:46  <thermoman> (or didn't notice?)
264 2016-11-21T17:26:33  <sdaftuar> my memory is failing me right now about when and whether we've made changes from 0.11 to 0.13 with locking/thread contention.  so in my view it's possible there's a performance regression, i'd need to investigate more.
265 2016-11-21T17:26:59  <thermoman> ok, thanks so far. will open the issue tomorrow
266 2016-11-21T17:43:52  <sdaftuar> thermoman: do you often call importprivkey in your setup, ie you were doing that on 0.11.2 as well as regularly on your 0.13.1 nodes?
267 2016-11-21T17:44:29  <sdaftuar> it looks to me like that is always a slow operation, and will cause bitcoind to be unresponsive while rescanning
268 2016-11-21T17:47:37  <sdaftuar> (and i think this would have been true in 0.11.2 as well)
269 2016-11-21T17:49:27  *** crudel has joined #bitcoin-core-dev
270 2016-11-21T17:52:09  *** paveljanik has joined #bitcoin-core-dev
271 2016-11-21T17:52:10  *** paveljanik has joined #bitcoin-core-dev
272 2016-11-21T17:52:23  *** AtashiCon has quit IRC
273 2016-11-21T17:57:58  *** Chris_Stewart_5 has quit IRC
274 2016-11-21T18:04:07  <gmaxwell> sdaftuar: importing a private key with rescan caused timeouts and disconnects for me w/ 0.12 too. If thermoman saw a change it could have also just been a bit of chain growth taking it above threshold.
275 2016-11-21T18:09:46  *** AtashiCon has joined #bitcoin-core-dev
276 2016-11-21T18:14:33  *** Chris_Stewart_5 has joined #bitcoin-core-dev
277 2016-11-21T18:17:21  *** laurentmt has joined #bitcoin-core-dev
278 2016-11-21T18:18:19  *** laurentmt has quit IRC
279 2016-11-21T18:23:31  <sipa> gmaxwell: or rescans became a bit slower since
280 2016-11-21T18:38:30  *** cysm has joined #bitcoin-core-dev
281 2016-11-21T18:47:42  *** To7 has quit IRC
282 2016-11-21T19:04:40  <sdaftuar> instagibbs: in #9194, wouldn't it make sense (if we're going down this road) to also support legacy serializations for zmq and rest?
283 2016-11-21T19:04:42  <gribble> https://github.com/bitcoin/bitcoin/issues/9194 | Add flags to getrawtransaction and getblock to return non-segwit seri… by instagibbs · Pull Request #9194 · bitcoin/bitcoin · GitHub
284 2016-11-21T19:10:54  <instagibbs> sdaftuar, yes, I have literally no experience with those interfaces, what would that entail
285 2016-11-21T19:13:40  <instagibbs> fwiw I think the number of spots we'll need this for is basically two, the ones I've done. We support backwards compatbility when talking to non-segwit nodes(and maybe future serializations!), I'm just giving an option for that at rpc level.
286 2016-11-21T19:13:56  <instagibbs> so whatever makes sense for that
287 2016-11-21T19:28:54  <sdaftuar> instagibbs: see for instance rest.cpp:371
288 2016-11-21T19:29:11  <sdaftuar> oh wait, i made a mistake
289 2016-11-21T19:31:23  <sdaftuar> oh maybe not -- sorry i've never really looked at this code. looks like that function gets a transaction and serializes it for a user
290 2016-11-21T19:32:05  <sdaftuar> similarly in the rest_block() function in that same file
291 2016-11-21T19:32:42  <sdaftuar> and then i think there are two analogous places in zmq/zmqpublishnotifier.cpp
292 2016-11-21T19:33:10  <sdaftuar> maybe that's it though... if your changes were comprehensive for the RPC stuff (sorry I need to review still), then perhaps this isn't as bad as I feared
293 2016-11-21T19:53:41  *** dermoth has quit IRC
294 2016-11-21T19:54:36  *** asoltys has quit IRC
295 2016-11-21T19:58:19  <instagibbs> gettransaction also returns a hex field I'm not converting, but it feels weird messing with an api that is wallet-based for this purpose.
296 2016-11-21T19:59:46  <instagibbs> I think "raw" apis are a better fit for these changes. If you're using wallet features, just use wallet and what the wallet understands
297 2016-11-21T20:02:24  <gmaxwell> the overall goal should be "no one should need to hesitate to install 0.13.1+ simply because they haven't updated their applications yet".  This was part of the attractiveness of having the segwit code in a release ahead of activation and avoiding behavior changes at activation time.
298 2016-11-21T20:03:23  *** cysm has quit IRC
299 2016-11-21T20:25:07  *** cysm has joined #bitcoin-core-dev
300 2016-11-21T20:34:53  <kanzure> should there be a nonce in rpc client requests? otherwise how does sendmany work if you had a socket timeout on the response? or other must-only-run-once critical rcp endpoints.
301 2016-11-21T20:35:13  <kanzure> 'scuse me, *rpc endpoints
302 2016-11-21T20:36:20  <gmaxwell> kanzure: 'check listtransactions' :-/  you're right, it should have a nonce. Well the whole rpc thing was not well designed.
303 2016-11-21T20:36:55  <kanzure> alternatively, you could say "well, just call an event log, and check before you retry" (someone posted a "retry all rpc requests" to petertodd's python-bitcoinlib repo and it raised my eyebrow)
304 2016-11-21T20:37:42  <kanzure> if sending money is the only scenario where something bad happens, then listtransactions is probably sufficient...
305 2016-11-21T20:37:43  <gmaxwell> (or, better, a nonce, sequence number pair, and a nonce can be reused but only with a strictly greater sequence number)
306 2016-11-21T20:39:51  <kanzure> what about: in RPC request to sendmany (or whatever else is broken here), include expected state and also the actual request. and if the expected state doesn't match, then raise error or don't send.
307 2016-11-21T20:42:40  <kanzure> someone outside the channel proposes, 'if you want to enforce balance checking, make the server require the client to make a balance call before making a send call.'
308 2016-11-21T20:51:58  <kanzure> do these problems exist in the http api?
309 2016-11-21T20:56:25  <sipa> you mean the REST api? that's read only
310 2016-11-21T20:56:48  <sipa> and only for public data (nothing wallet related)
311 2016-11-21T21:03:12  <sipa> gcc 7.0 has -Wmisleading-indentation
312 2016-11-21T21:04:57  *** sanada has quit IRC
313 2016-11-21T21:09:18  *** Alina-malina has quit IRC
314 2016-11-21T21:11:27  *** sanada has joined #bitcoin-core-dev
315 2016-11-21T21:11:37  *** jannes has quit IRC
316 2016-11-21T21:12:03  *** Alina-malina has joined #bitcoin-core-dev
317 2016-11-21T21:30:42  *** cysm has quit IRC
318 2016-11-21T21:32:30  <Chris_Stewart_5> Just to be clear, there is no compact size uint to indicate how many CTxInWitness inside of the serialization of a tx right?
319 2016-11-21T21:32:37  <Chris_Stewart_5> You need to infer it from the number of inputs?
320 2016-11-21T21:39:40  *** ryan`c is now known as ryan-c
321 2016-11-21T21:43:19  *** CubicEarth has joined #bitcoin-core-dev
322 2016-11-21T21:47:42  <sipa> Chris_Stewart_5: indeed
323 2016-11-21T21:49:07  <kanzure> okay i posted an issue about the abovementioned rpc replay protection concerns https://github.com/bitcoin/bitcoin/issues/9197
324 2016-11-21T21:56:56  <Chris_Stewart_5> Thanks sipa
325 2016-11-21T22:05:14  <bsm1175321> Are there any RPC requests that would NOT be idempotent?  I think kanzure's suggestion is that bitcoind always complete the action of an RPC call even in event of an I/O error while sending the response.  Is it possible that this wouldn't be the case?
326 2016-11-21T22:05:39  <bsm1175321> Further, is it possible for a truncated RPC request to end up being valid and acted upon?
327 2016-11-21T22:06:35  <bsm1175321> BTW I think this is probably RPC "atomicity" not "idempotency".
328 2016-11-21T22:11:26  <kanzure> no, my suggestion is not "always complete the action of an RPC call even in event of an I/O error while sending the response" -- that's a related topic i guess.
329 2016-11-21T22:11:36  <bsm1175321> Nah kanzure's right in using idempotent -- CS lingo.  Too much math over here.
330 2016-11-21T22:12:08  <kanzure> my suggestion is "change from 'always execute any RPC request' to 'check whether the nonce is the same first, and fail if the nonce is the same'"
331 2016-11-21T22:13:23  <bsm1175321> Sure.  From the client's perspective the two situations are the same...he didn't get the response and doesn't know if the RPC sendmany was executed.  So he retries with the same nonce...
332 2016-11-21T22:14:17  <kanzure> yes, retrying with the same nonce would be OK
333 2016-11-21T22:14:18  <sipa> an alternative is having meta support for any asynchronous command
334 2016-11-21T22:14:27  <bsm1175321> I like that idea...
335 2016-11-21T22:14:51  <bsm1175321> (I like kanzure's nonce idea).  What's meta support?
336 2016-11-21T22:14:58  <sipa> you call an RPC "schedule" with 3 args: 1) command 2) command args 3) call id
337 2016-11-21T22:15:18  <sipa> and then you have a separate RPC through which you can chrck the result
338 2016-11-21T22:15:38  <kanzure> have you poked at database internals before, like transactional concept?
339 2016-11-21T22:15:58  <sipa> define 'poked'
340 2016-11-21T22:16:06  <gmaxwell> sipa: that kind of framework is _necessary_ for some commands.
341 2016-11-21T22:16:20  <kanzure> eh, 'poked' could be reading i guess :)
342 2016-11-21T22:16:29  <gmaxwell> For example automatic sendmany batching and replacement will not know the txid until later.
343 2016-11-21T22:17:32  <kanzure> daisychaining and 'schedule' sure. although if you require some of the prior information before generating the next call, ... can't send all at once.
344 2016-11-21T22:18:02  <bsm1175321> To be clear -- the issue we're having is that bitcoind closes its RPC connections on a timer.  These are connections on localhost and python-bitcoinlib doesn't reopen them (I consider that it's bug).  But this could also be improved on the bitcoind side if we could configure it to not close RPC connections...
345 2016-11-21T22:18:12  *** skyraider has joined #bitcoin-core-dev
346 2016-11-21T22:18:17  <bsm1175321> That's separate from calling RPC's over a flaky connection...
347 2016-11-21T22:18:30  <kanzure> rpc connection closing behavior is somewhat unrelated; your application still needs to know whether to retry. and currently it can't possibly know that.
348 2016-11-21T22:18:41  <bsm1175321> Yep yep
349 2016-11-21T22:18:41  <gmaxwell> "not close RPC connections." < guarentees file descriptor exhaustion.  And is unlike any http server ever.
350 2016-11-21T22:19:36  <gmaxwell> bsm1175321: I think your concern is just a "fix the client" concern. (the python-bitcoinlib behavior has burned me many times too)
351 2016-11-21T22:19:45  <bsm1175321> But there's only one RPC user and it's on localhost.  I think this is a common configuration.
352 2016-11-21T22:20:12  <bsm1175321> gmaxwell: I agree.  I'm gonna fix it to re-open and not bother me with I/O exceptions.
353 2016-11-21T22:20:38  <kanzure> "only one rpc user" what?
354 2016-11-21T22:20:41  <sipa> didn't we fix that issue in our in-tree fork of python-bitcoinlib?
355 2016-11-21T22:20:50  <gmaxwell> often still results in exhaustion, e.g. when you get long idle connection objects that aren't GCed yet and so they've left their connections open.
356 2016-11-21T22:21:48  *** CubicEarth has quit IRC
357 2016-11-21T22:22:34  <bsm1175321> sipa: yes it looks like it is fixed there.
358 2016-11-21T22:22:47  *** cysm has joined #bitcoin-core-dev
359 2016-11-21T22:23:00  *** CubicEarth has joined #bitcoin-core-dev
360 2016-11-21T22:24:24  <kanzure> oh there is an "id" parameter sent https://github.com/petertodd/python-bitcoinlib/blob/2e4d51a482a4331d91de9bae2ab7be56229e664a/bitcoin/rpc.py#L188
361 2016-11-21T22:24:45  <kanzure> .. which is auto-incremented in this particular client library..
362 2016-11-21T22:26:59  <bsm1175321> sipa: the fix here: https://github.com/bitcoin/bitcoin/blob/master/qa/rpc-tests/test_framework/authproxy.py#L134 looks like it is effectively a retry, and would, e.g. sendmany again.
363 2016-11-21T22:29:34  <skyraider> connection handling is distinct from client state management. i think kanzure's concern is that it seems possible for a bitcoind client to say "hey, i didn't receive a reply" and then resend the same request to bitcoind - perhaps resulting in the accidental execution of two identical requests. banks used to behave this way when you clicked "do wire transfer"
364 2016-11-21T22:29:35  <skyraider> then pressed "back" in internet explorer - they'd do another POST to send the wire transfer again. now we have idempotency via request nonces for the web, so it's not a problem - your nonce is considered expired once the nonce's corresponding request is processed. with python-bitcoinlib in particular, i think the concern is that you can still get "oops i
365 2016-11-21T22:29:35  <skyraider> sent wire transfer twice" type behavior, due to no client state management facilities in bitcoind to code against.. is that right?
366 2016-11-21T22:31:37  <gmaxwell> skyraider: applications can check list transactions to determine if the order has been executed yet.
367 2016-11-21T22:31:48  <sipa> kanzure: that's just for ordering of responses within one connection
368 2016-11-21T22:32:07  <gmaxwell> A common model is to poll outstanding requests, check list transactions, anything not paid yet, pay... anything already paid remove from the list.
369 2016-11-21T22:32:35  <kanzure> gmaxwell: no, that doesn't work.   listtransactions will  not matter because you might have anohter concurrent attempt. then both sendmanys execute one after another.
370 2016-11-21T22:33:09  <gmaxwell> "Don't do that."
371 2016-11-21T22:33:10  <kanzure> ok well at the very least we should insist that client librares implement that pattern, maybe by rejecting sendmany rpc requests if previous required rpc requests have not been detected
372 2016-11-21T22:33:34  <gmaxwell> I'm just describing to you an architecture I've seen before, which has generally acceptable properties.
373 2016-11-21T22:34:08  <gmaxwell> I don't disagree that an optional nonce/sequence with replay protection would be good-- though it has some scalability challenges.
374 2016-11-21T22:34:40  *** Guyver2 has quit IRC
375 2016-11-21T22:35:28  <kanzure> sipa: oh like for ordering responses to the _batch call?
376 2016-11-21T22:36:24  <sipa> kanzure: you can send two rpcs with the same id, and you could get two different answers with the same id back
377 2016-11-21T22:37:21  <sipa> gmaxwell, kanzure: a more lightway idea, just for send* calls, is passing as an argument to the rpc the expected wallet balance
378 2016-11-21T22:37:46  <sipa> anything that actually interferes would cause failure, while other rpcs could still happen concurrently
379 2016-11-21T22:37:46  <kanzure> wallet balance isn't good either... many simultaneous deposits/debits could put you back to the same balance anyway.
380 2016-11-21T22:38:27  <kanzure> excuse me, credits/debits
381 2016-11-21T22:38:35  <skyraider> so 'read before you try to send lots of bitcoin' - alright. but if another RPC connection writes in the meantime, won't my read be stale, or is there transaction isolation somehow? is the recommended policy therefore 'only ever use a single RPC writer' ?
382 2016-11-21T22:38:42  <gmaxwell> sipa: ugh. so if you send some and recieve the same amount ... the double payment still goes through?
383 2016-11-21T22:39:27  <kanzure> 'transaction isolation' probably means database-kind of transaction model, not transactions?
384 2016-11-21T22:39:49  <skyraider> uh, yeah, not bitcoin transaction. isolation as in the I from ACID.
385 2016-11-21T22:39:51  <gmaxwell> skyraider: yes, you just retry in that model.
386 2016-11-21T22:40:18  <kanzure> isn't that a failure
387 2016-11-21T22:40:25  <kanzure> the idea is to prevent stales from causing you to retry
388 2016-11-21T22:41:08  <gmaxwell> why would that be a failure? The retry causes no harm. The system is concurrent and you want an atomic change, there will always be retries needed.
389 2016-11-21T22:41:35  <kanzure> you mean existing system, or proposed system is concurrent?
390 2016-11-21T22:41:42  <gmaxwell> kanzure: so going back to the nonce, how do you propose avoding having to store nonces forever?
391 2016-11-21T22:42:29  <skyraider> gmaxwell: sorry, could you clarify please - is RPC safe for concurrent writes at the moment, or are you saying stale reads (if you have, say, two concurrent connections) are possible, and therefore one should use a single RPC writer?
392 2016-11-21T22:43:37  <gmaxwell> skyraider: your question is underspecified. It's perfectly fine to make concurrent writes.  But kanzure is asking about what happens when you get a socket failure on one of your writes.
393 2016-11-21T22:43:48  <gmaxwell> If you just retry you may double pay.
394 2016-11-21T22:43:52  <midnightmagic> wtf man another earthquake near fukushima?
395 2016-11-21T22:47:59  <skyraider> right, i don't mean to ask whether the application will crash if you do concurrent writes. rather, whether a client can expect the situation of "1) read balance in client thread A, 2) write balance in client thread B that makes 1's read stale, 3) write balance in client thread A" can result in the client double paying, due to making a decision based upon the
396 2016-11-21T22:47:59  <skyraider> balance data in read 1).
397 2016-11-21T22:48:50  <sipa> skyraider: there is no 'write balance'
398 2016-11-21T22:49:05  <sipa> there is 'attempt to make a transaction'
399 2016-11-21T22:49:31  <skyraider> yes, sorry, shorthand for "try to send some bitcoin"
400 2016-11-21T22:51:14  <gmaxwell> skyraider: I think you're overthinking things now.  If you call send* you will probably send.  If you call send once per payment you want to make you will never double pay.
401 2016-11-21T22:51:42  <gmaxwell> if you are doing things based on 'balance' then god knows what will happen, as balance is not monotone. :)
402 2016-11-21T22:51:48  <sipa> skyraider: if you "attempt to make a transaction" twice, it will obviously send twice... anything else would be highly unexpected behaviour
403 2016-11-21T22:52:19  <kanzure> i think bitcoind seems to really very strongly want all applications to have only one rpc connection
404 2016-11-21T22:52:30  <gmaxwell> kanzure: not at all.
405 2016-11-21T22:52:38  <kanzure> there is no protection against stale reads at all
406 2016-11-21T22:52:45  <kanzure> there is nothing in here at all like ACID
407 2016-11-21T22:53:05  <gmaxwell> which is orthorgonal to "have only one rpc connection"
408 2016-11-21T22:53:17  <kanzure> look i'm fine with one rpc client in serial. that's fine with me.  but i'm not sure everyone else knows to do that.
409 2016-11-21T22:57:10  <skyraider> it might help to put on a client's shoes here. context was https://github.com/petertodd/python-bitcoinlib/pull/128 in which a blind retry python decorator was considered. turns out this can a) result in actually sending bitcoin multiple times, b) result in decisions made on stale read data (balance was just an example - really any bitcoind state subject to
410 2016-11-21T22:57:11  <skyraider> change via concurrent writes). it seems a safe solution for b) is "only ever execute RPC writes serially" and for a), "because we are doing serial writes, in which another write can't occur after my safety-check-read, we can query to see whether the send already occurred (the safety-check-read) before retrying." tldr; serial writes enables "should i retry?"
411 2016-11-21T22:57:11  <skyraider> logic in a safe way.
412 2016-11-21T22:57:49  *** abpa has joined #bitcoin-core-dev
413 2016-11-21T22:58:08  <gmaxwell> I disagree.
414 2016-11-21T22:58:27  <gmaxwell> What you want is a write which is ordered with respect to a read.
415 2016-11-21T22:58:39  <gmaxwell> Have you already paid is not something which can become untrue.
416 2016-11-21T22:58:58  <kanzure> previous answer to "have you already paid" can become untrue
417 2016-11-21T22:59:18  <gmaxwell> yes but only by performing a write that makes that payment.
418 2016-11-21T22:59:19  <skyraider> yes, a write ordered with respect to a particular read (i.e., transaction isolation in the database sense) is a more general and better solution than serial writes.
419 2016-11-21T23:01:02  <gmaxwell> Both of you keep repeating serial, and that is just wrong and in a meaningful way compared to typical usage.  You can perform as many sends as you want. But if you want to retry a send you must read first to make sure the send wasn't already performed.   Running two sends for the same payment in parallel is insanity in any case, as you have no way of knowing if the other went through (and usuall
420 2016-11-21T23:01:08  <gmaxwell> y it does).
421 2016-11-21T23:01:39  *** CubicEarth has quit IRC
422 2016-11-21T23:04:36  <bsm1175321> Of course, there are probably many people performing this logic now, since the "commit" of a send doesn't actually occur until it's mined.  The need to fee-bump is probably a more common cause of retries than RPC connection drops...
423 2016-11-21T23:04:53  <skyraider> if you are e.g. running a group of ec2 servers or something and experience a temporary DNS failure of the kind that's common on AWS, that python-bitcoinlib decorator could result in probably 1-50 double payments per month, assuming you are sending every 30 seconds or so. serial writes seems to be a quick, safe way to get don't-pay-twice safety while querying
424 2016-11-21T23:04:53  <skyraider> the current version of bitcoind. as to running sends concurrently, yes, it seems unusual / nonrealistic use case to do this.
425 2016-11-21T23:05:50  <kanzure> fwiw i don't actually use sendmany
426 2016-11-21T23:07:43  <kanzure> or any spends for that matter... heh.
427 2016-11-21T23:07:53  <sipa> you hodler
428 2016-11-21T23:08:36  *** CubicEarth has joined #bitcoin-core-dev
429 2016-11-21T23:08:41  <kanzure> (yeah who would ever want to spend coins??)
430 2016-11-21T23:10:51  <midnightmagic> gmaxwell: that's how MP (operating manually) managed to rip himself off.
431 2016-11-21T23:13:08  <kanzure> midnightmagic: go on?
432 2016-11-21T23:13:27  <skyraider> and yeah i understand the criticism about serial writes - it seems at first it should be more like 'read before you write'.  but, you have to be careful with that because your read could easily be stale. and if you are running concurrent bitcoind sends in different client-application-level thread of execution, well - you shouldn't do this. you should write
433 2016-11-21T23:13:27  <skyraider> in one thread because the lack of transaction isolation (read/write ordering) means client implementors might not know to handle what happens when a balance they just checked is now gone.
434 2016-11-21T23:13:55  <skyraider> but, yes, this is not an actual real-world use case over here at the moment. so admitted.
435 2016-11-21T23:14:01  <skyraider> thanks
436 2016-11-21T23:14:19  <midnightmagic> kanzure: not respending himself, instead sending multiple sends to the same destination more than once, and the receivers obviously refused to give anything back (which was fair by MP's own mercenrary rules.) If he had properly respent himself, updated his sends, or otherwise presumed the sends could be mined at any time, he wouldn't have lost anything.
437 2016-11-21T23:22:35  *** laurentmt has joined #bitcoin-core-dev
438 2016-11-21T23:23:18  <kanzure> is the assumption that there is always a single node worker and never more than one? if so, we should probably add this to docs.
439 2016-11-21T23:23:42  <kanzure> *node worker (rpc client communicating to bitcoind)
440 2016-11-21T23:25:22  <bsm1175321> Having more than one violates the Isolation requirement of ACID.  Would it be interesting to require isolation on open wallets WRT rpc clients?  That is, two RPC connections must have mutually exclusive wallets?
441 2016-11-21T23:28:22  *** laurentmt has quit IRC
442 2016-11-21T23:30:08  <gmaxwell> kanzure: I keep telling you that there is no such assumption.
443 2016-11-21T23:33:43  <sipa> kanzure: that also doesn't in any way help with the double issue problem
444 2016-11-21T23:53:47  <kanzure> ah, there is a lockunspent at least.