12016-11-21T00:09:57  *** alpalp has quit IRC
  22016-11-21T00:12:30  *** Chris_Stewart_5 has joined #bitcoin-core-dev
  32016-11-21T00:18:48  *** musalbas has quit IRC
  42016-11-21T00:24:14  *** musalbas has joined #bitcoin-core-dev
  52016-11-21T00:29:20  *** alpalp has joined #bitcoin-core-dev
  62016-11-21T00:35:57  *** CubicEarth has quit IRC
  72016-11-21T00:38:13  *** owowo has quit IRC
  82016-11-21T00:43:26  *** owowo has joined #bitcoin-core-dev
  92016-11-21T00:45:37  *** alpalp has quit IRC
 102016-11-21T00:47:38  *** kinlo has quit IRC
 112016-11-21T00:48:40  *** kinlo has joined #bitcoin-core-dev
 122016-11-21T00:53:47  *** CubicEarth has joined #bitcoin-core-dev
 132016-11-21T00:54:34  *** alpalp has joined #bitcoin-core-dev
 142016-11-21T01:25:31  *** takashi has joined #bitcoin-core-dev
 152016-11-21T01:28:04  *** btcdrak has quit IRC
 162016-11-21T01:30:31  *** echonaut has quit IRC
 172016-11-21T01:30:53  *** echonaut has joined #bitcoin-core-dev
 182016-11-21T01:40:22  *** CubicEarth has quit IRC
 192016-11-21T01:55:42  *** CubicEarth has joined #bitcoin-core-dev
 202016-11-21T02:05:08  *** CubicEarth has quit IRC
 212016-11-21T02:08:11  *** windsok has quit IRC
 222016-11-21T02:12:39  *** Ylbam has quit IRC
 232016-11-21T02:27:28  *** Chris_Stewart_5 has quit IRC
 242016-11-21T02:36:33  *** xiangfu has quit IRC
 252016-11-21T02:36:55  *** xiangfu has joined #bitcoin-core-dev
 262016-11-21T02:56:17  *** ibrightly has quit IRC
 272016-11-21T02:57:37  *** DigiByteDev has joined #bitcoin-core-dev
 282016-11-21T02:58:33  *** ibrightly has joined #bitcoin-core-dev
 292016-11-21T03:05:57  *** CubicEarth has joined #bitcoin-core-dev
 302016-11-21T03:08:15  *** aalex__ has joined #bitcoin-core-dev
 312016-11-21T03:11:03  *** CubicEarth has quit IRC
 322016-11-21T03:13:06  *** kinlo has quit IRC
 332016-11-21T03:13:44  *** murchandamus has quit IRC
 342016-11-21T03:14:13  *** Bootvis_ has quit IRC
 352016-11-21T03:14:33  *** aalex__ has quit IRC
 362016-11-21T03:14:33  *** kinlo has joined #bitcoin-core-dev
 372016-11-21T03:14:33  *** murchandamus has joined #bitcoin-core-dev
 382016-11-21T03:15:18  *** Bootvis has joined #bitcoin-core-dev
 392016-11-21T03:17:57  *** alpalp has quit IRC
 402016-11-21T03:31:09  *** windsok has joined #bitcoin-core-dev
 412016-11-21T04:06:43  *** CubicEarth has joined #bitcoin-core-dev
 422016-11-21T04:12:38  *** CubicEarth has quit IRC
 432016-11-21T04:28:27  *** CubicEarth has joined #bitcoin-core-dev
 442016-11-21T04:40:22  *** Alopex has quit IRC
 452016-11-21T04:40:56  *** CubicEarth has quit IRC
 462016-11-21T04:41:00  *** kanzure has quit IRC
 472016-11-21T04:41:27  *** Alopex has joined #bitcoin-core-dev
 482016-11-21T04:43:22  *** kanzure has joined #bitcoin-core-dev
 492016-11-21T04:53:16  *** DigiByteDev has quit IRC
 502016-11-21T04:54:58  *** btcdrak has joined #bitcoin-core-dev
 512016-11-21T05:04:10  *** Giszmo has quit IRC
 522016-11-21T05:12:54  *** kadoban has joined #bitcoin-core-dev
 532016-11-21T05:13:03  *** DigiByteDev has joined #bitcoin-core-dev
 542016-11-21T05:15:06  *** Alopex has quit IRC
 552016-11-21T05:16:11  *** Alopex has joined #bitcoin-core-dev
 562016-11-21T05:41:49  *** CubicEarth has joined #bitcoin-core-dev
 572016-11-21T05:46:09  *** CubicEarth has quit IRC
 582016-11-21T05:56:12  *** Alopex has quit IRC
 592016-11-21T05:56:49  *** kadoban has quit IRC
 602016-11-21T05:57:17  *** Alopex has joined #bitcoin-core-dev
 612016-11-21T05:58:04  *** CubicEarth has joined #bitcoin-core-dev
 622016-11-21T06:24:30  *** jtimon has quit IRC
 632016-11-21T07:03:13  *** CubicEarth has quit IRC
 642016-11-21T07:03:27  *** CubicEarth has joined #bitcoin-core-dev
 652016-11-21T07:04:59  *** luke-jr has quit IRC
 662016-11-21T07:05:08  *** luke-jr has joined #bitcoin-core-dev
 672016-11-21T07:25:41  *** rb___ has joined #bitcoin-core-dev
 682016-11-21T07:27:15  *** cysm has quit IRC
 692016-11-21T07:27:29  *** justanotheruser has quit IRC
 702016-11-21T07:33:06  *** justanotheruser has joined #bitcoin-core-dev
 712016-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
 722016-11-21T07:43:28  *** rb___ has quit IRC
 732016-11-21T07:46:12  *** Ylbam has joined #bitcoin-core-dev
 742016-11-21T08:00:20  *** CubicEarth has quit IRC
 752016-11-21T08:10:08  *** aalex__ has joined #bitcoin-core-dev
 762016-11-21T08:17:41  *** aalex__ has quit IRC
 772016-11-21T08:50:42  *** achow101 has quit IRC
 782016-11-21T08:50:45  *** gribble has quit IRC
 792016-11-21T08:52:03  *** achow101 has joined #bitcoin-core-dev
 802016-11-21T09:01:05  *** e6xit has joined #bitcoin-core-dev
 812016-11-21T09:05:25  *** rubensayshi has joined #bitcoin-core-dev
 822016-11-21T09:16:12  *** jannes has joined #bitcoin-core-dev
 832016-11-21T09:22:16  *** gribble has joined #bitcoin-core-dev
 842016-11-21T09:52:11  <bitcoin-git> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/44adf683ad23...7490ae8b699d
 852016-11-21T09:52:12  <bitcoin-git> bitcoin/master 0e85204 Pieter Wuille: Add serialization for unique_ptr and shared_ptr
 862016-11-21T09:52:12  <bitcoin-git> bitcoin/master da60506 Pieter Wuille: Add deserializing constructors to CTransaction and CMutableTransaction
 872016-11-21T09:52:13  <bitcoin-git> bitcoin/master 1662b43 Pieter Wuille: Make CBlock::vtx a vector of shared_ptr<CTransaction>
 882016-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
 892016-11-21T09:52:50  <gmaxwell> \O/
 902016-11-21T10:02:50  *** justanotheruser has quit IRC
 912016-11-21T10:03:01  *** Victor_sueca has joined #bitcoin-core-dev
 922016-11-21T10:05:25  *** Victorsueca has quit IRC
 932016-11-21T10:07:30  *** justanotheruser has joined #bitcoin-core-dev
 942016-11-21T10:07:39  *** Guyver2 has joined #bitcoin-core-dev
 952016-11-21T10:12:05  *** Victor_sueca is now known as Victorsueca
 962016-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)
 972016-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
 982016-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
 992016-11-21T10:51:28  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7490ae8b699d...c3906403c8ed
1002016-11-21T10:51:28  <bitcoin-git> bitcoin/master 4662553 Cory Fields: net: don't send feefilter messages before the version handshake is complete
1012016-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...
1022016-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
1032016-11-21T10:52:42  *** DigiByteDev has quit IRC
1042016-11-21T10:52:59  *** MarcoFalke has joined #bitcoin-core-dev
1052016-11-21T10:56:40  *** xiangfu has quit IRC
1062016-11-21T10:57:48  *** xiangfu has joined #bitcoin-core-dev
1072016-11-21T11:07:09  *** laurentmt has joined #bitcoin-core-dev
1082016-11-21T11:11:51  *** laurentmt has quit IRC
1092016-11-21T11:20:07  *** MarcoFalke has left #bitcoin-core-dev
1102016-11-21T11:48:04  *** e6xit has quit IRC
1112016-11-21T11:48:16  *** e6xit has joined #bitcoin-core-dev
1122016-11-21T12:08:37  *** aalex__ has joined #bitcoin-core-dev
1132016-11-21T12:16:24  *** aalex__ has quit IRC
1142016-11-21T12:49:19  <jonasschnelli> wumpus: do you have plans to rebase #7729? Otherwise I can pick it up.
1152016-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.
1162016-11-21T12:49:41  <wumpus> yes, I'll get back to that at some point
1172016-11-21T12:50:29  <wumpus> happy some people are finally commenting on the API
1182016-11-21T12:52:18  <jonasschnelli> Yes. Thanks to last weeks meeting.
1192016-11-21T13:06:12  *** cjcj has quit IRC
1202016-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
1212016-11-21T13:21:11  <wumpus> right, it's always been deprecated, it's time to move forward there
1222016-11-21T13:21:20  <wumpus> "always"
1232016-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?
1242016-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)
1252016-11-21T13:23:18  <wumpus> it's indeed not something that belongs at the wallet level
1262016-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
1272016-11-21T13:24:00  *** YOU-JI has joined #bitcoin-core-dev
1282016-11-21T13:24:01  *** Giszmo has joined #bitcoin-core-dev
1292016-11-21T13:24:38  *** justanotheruser has quit IRC
1302016-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
1312016-11-21T13:30:20  *** justanotheruser has joined #bitcoin-core-dev
1322016-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
1332016-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
1342016-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
1352016-11-21T13:35:29  <instagibbs> shorter is better unless it results in overload in the context
1362016-11-21T13:36:24  <wumpus> right
1372016-11-21T13:36:42  <wumpus> changing to just "address" then
1382016-11-21T13:49:50  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1392016-11-21T13:49:56  *** BonyM1 has quit IRC
1402016-11-21T13:55:41  *** e6xit has quit IRC
1412016-11-21T13:59:54  *** e6xit has joined #bitcoin-core-dev
1422016-11-21T14:04:28  *** takashi has quit IRC
1432016-11-21T14:05:33  *** BonyM1 has joined #bitcoin-core-dev
1442016-11-21T14:09:28  *** e6xit has quit IRC
1452016-11-21T14:09:38  *** e6xit has joined #bitcoin-core-dev
1462016-11-21T14:28:14  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c3906403c8ed...b9a87b459d25
1472016-11-21T14:28:14  <bitcoin-git> bitcoin/master fa7cc5a MarcoFalke: Set DEFAULT_LIMITFREERELAY = 0 kB/minute
1482016-11-21T14:28:15  <bitcoin-git> bitcoin/master b9a87b4 Wladimir J. van der Laan: Merge #9179: Set DEFAULT_LIMITFREERELAY = 0 kB/minute...
1492016-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
1502016-11-21T14:33:46  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/b9a87b459d25...210891143ba0
1512016-11-21T14:33:46  <bitcoin-git> bitcoin/master 7451cf5 jnewbery: Allow bitcoin-tx to parse partial transactions...
1522016-11-21T14:33:47  <bitcoin-git> bitcoin/master 2108911 Wladimir J. van der Laan: Merge #8837: allow bitcoin-tx to parse partial transactions...
1532016-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
1542016-11-21T14:41:57  <bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/210891143ba0...0c577f2638b7
1552016-11-21T14:41:58  <bitcoin-git> bitcoin/master d768f15 mrbandrews: [qa] Make comptool push blocks instead of relying on inv-fetch
1562016-11-21T14:41:58  <bitcoin-git> bitcoin/master 3451203 Matt Corallo: [qa] Respond to getheaders and do not assume a getdata on inv
1572016-11-21T14:41:59  <bitcoin-git> bitcoin/master 037159c Matt Corallo: Remove block-request logic from INV message processing
1582016-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
1592016-11-21T14:42:10  *** BonyM1 has quit IRC
1602016-11-21T14:44:09  *** crudel has quit IRC
1612016-11-21T14:47:09  *** jtimon has joined #bitcoin-core-dev
1622016-11-21T14:48:01  *** Chris_Stewart_5 has quit IRC
1632016-11-21T14:56:46  *** BonyM1 has joined #bitcoin-core-dev
1642016-11-21T15:02:18  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1652016-11-21T15:15:00  *** e6xit has quit IRC
1662016-11-21T15:15:19  *** e6xit has joined #bitcoin-core-dev
1672016-11-21T15:18:53  *** YOU-JI has quit IRC
1682016-11-21T15:20:39  *** AaronvanW has quit IRC
1692016-11-21T15:23:45  *** AaronvanW has joined #bitcoin-core-dev
1702016-11-21T15:23:45  *** AaronvanW has quit IRC
1712016-11-21T15:23:45  *** AaronvanW has joined #bitcoin-core-dev
1722016-11-21T15:31:20  *** aalex__ has joined #bitcoin-core-dev
1732016-11-21T15:34:30  *** e6xit has quit IRC
1742016-11-21T15:34:40  *** e6xit has joined #bitcoin-core-dev
1752016-11-21T15:38:04  *** aalex__ has quit IRC
1762016-11-21T15:44:32  *** e6xit has quit IRC
1772016-11-21T15:44:41  *** e6xit has joined #bitcoin-core-dev
1782016-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
1792016-11-21T16:06:50  *** kadoban has joined #bitcoin-core-dev
1802016-11-21T16:08:56  *** e6xit has quit IRC
1812016-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
1822016-11-21T16:14:18  <thermoman> is this a known issue somehow?
1832016-11-21T16:15:54  <sdaftuar> thermoman: is this for a brand new transaction you created, or an old wallet transaction?
1842016-11-21T16:16:06  <thermoman> ok, it just was relayed to the network - but a hughe delay
1852016-11-21T16:16:13  <thermoman> sdaftuar: it's a brand new tx
1862016-11-21T16:16:31  <thermoman> we have noticed big delays since 2 or 3 days
1872016-11-21T16:16:50  <sipa> thermoman: define huge?
1882016-11-21T16:17:01  <thermoman> doing sendrawtransaction as a workaround after the initial TX the TX was then immediately visible
1892016-11-21T16:17:28  <sdaftuar> thermoman: can you clarify how you're telling that the tx is "visible"?
1902016-11-21T16:17:58  <sdaftuar> ie, visible on some 3rd party explorer?
1912016-11-21T16:18:11  <sdaftuar> or are you looking at your node's relay behavior more directly?
1922016-11-21T16:18:12  <thermoman> lemme get that info from our dev
1932016-11-21T16:18:20  <thermoman> I guess 3rd party
1942016-11-21T16:18:23  <thermoman> like blockchain.info
1952016-11-21T16:18:44  <thermoman> i query the dev right now
1962016-11-21T16:20:32  <sipa> also, what kind of delays are we talking about? second? minutes? hours?
1972016-11-21T16:21:44  <thermoman> http://pastebin.com/LXT4GmnP
1982016-11-21T16:21:51  <thermoman> sipa, sdaftuar ^
1992016-11-21T16:22:05  <thermoman> delay ~20 minutes
2002016-11-21T16:24:55  <sipa> thermoman: can you show a few lines that come after the first broadcast?
2012016-11-21T16:30:29  <thermoman> sure, one moment
2022016-11-21T16:35:20  <thermoman> sipa: http://pastebin.com/8TEFK0Ee
2032016-11-21T16:35:27  <thermoman> this comes directly below it
2042016-11-21T16:35:54  <thermoman> the node in question is connected to a proxy node via connect=<IP>:8333
2052016-11-21T16:36:05  <thermoman> it seems like the connection to the proxy node got reset
2062016-11-21T16:36:18  <thermoman> all nodes run 0.13.1
2072016-11-21T16:36:19  <sdaftuar> right, so you had no peer to broadcast to initially
2082016-11-21T16:37:28  <sdaftuar> which would explain the delays you're seeing, though it raises the question of why you're getting disconnected
2092016-11-21T16:37:41  <thermoman> right. the proxy node is on the LAN
2102016-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
2112016-11-21T16:38:45  <thermoman> you mean from the proxy node, right?
2122016-11-21T16:39:00  <thermoman> the proxy node isn't running with debug=1 - will have to change that
2132016-11-21T16:39:02  <sdaftuar> well it might be helpful to see it from both sides' point of view
2142016-11-21T16:39:22  <sdaftuar> if you just have one debug log, we can look at that
2152016-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
2162016-11-21T16:40:20  <thermoman> ok?
2172016-11-21T16:41:00  <sipa> thermoman: i believe you were not even connected to your proxy node when the transaction was creates
2182016-11-21T16:42:16  <sipa> oh, sdaftuar already told you thay
2192016-11-21T16:42:52  <sdaftuar> thermoman: does your proxy node -whitelist your internal node?
2202016-11-21T16:43:39  <thermoman> sdaftuar: yes
2212016-11-21T16:43:51  <thermoman> # Whitelist internal networks
2222016-11-21T16:44:01  <thermoman> whitelist=a.b.c.d/24
2232016-11-21T16:44:11  <thermoman> from bitcoin.conf on proxy node
2242016-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
2252016-11-21T16:46:18  <thermoman> thanks so far
2262016-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.
2272016-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
2282016-11-21T16:57:16  <thermoman> ok
2292016-11-21T16:57:35  <thermoman> here is the interesting part from the node behind the proxy
2302016-11-21T17:05:23  <thermoman> sdaftuar, sipa: http://pastebin.com/ZzLpLiLU
2312016-11-21T17:05:40  <thermoman> this is the stripped down log from the node sending the TX (behind the proxy)
2322016-11-21T17:05:44  *** luke-jr has quit IRC
2332016-11-21T17:05:53  *** luke-jr has joined #bitcoin-core-dev
2342016-11-21T17:05:54  <thermoman> the issue occured several times after importing a privkey
2352016-11-21T17:06:52  *** rubensayshi has quit IRC
2362016-11-21T17:07:05  <sdaftuar> ah.  i wonder if your node was too busy to respond to ping messages, causing a disconnect?
2372016-11-21T17:07:14  <thermoman> that might be
2382016-11-21T17:07:29  <thermoman> it seems the import did block everything else
2392016-11-21T17:07:58  <thermoman> and directly after the import the TX was created (while being disconnected from the proxy)
2402016-11-21T17:08:41  <thermoman> should timeouts be upped on our nodes?
2412016-11-21T17:08:43  <sdaftuar> the second disconnect seems a bit different though
2422016-11-21T17:08:55  <thermoman> yeah
2432016-11-21T17:09:00  <thermoman> it's directly after
2442016-11-21T17:09:00  <thermoman> Erased 100 orphan tx from peer 1
2452016-11-21T17:09:16  <thermoman> should the nodes behind the proxy whitelist the proxy-ip, too?
2462016-11-21T17:09:28  <thermoman> at the moment only the proxy has whitelisted the client ips
2472016-11-21T17:09:59  *** grubles has joined #bitcoin-core-dev
2482016-11-21T17:10:06  <sdaftuar> thermoman: i don't think it would hurt, though i'm not sure yet what's going on
2492016-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
2502016-11-21T17:14:31  <sdaftuar> so this looks like the wallet operation is contending with the p2p code, and network timeouts are being hit
2512016-11-21T17:15:38  <thermoman> ah ok, didn't miss the connection between "Added connection" and "sending version message"
2522016-11-21T17:15:44  <thermoman> s/didn't/did/
2532016-11-21T17:16:29  <thermoman> current workaround for us is to wait a minute after importing is done
2542016-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
2552016-11-21T17:22:01  <thermoman> do you add an issue in github or should I?
2562016-11-21T17:23:40  <thermoman> we've only seen this issue after upgrading the proxy node von 0.11.2 to 0.13.1
2572016-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
2582016-11-21T17:24:42  <thermoman> so it seems to have started after upgrading the proxy node
2592016-11-21T17:25:04  <thermoman> if I don't hear from you I'll open an issue on github tomorrow
2602016-11-21T17:25:06  <sdaftuar> hmm, this issue really seems like it's specific to the internal node.
2612016-11-21T17:25:27  <sdaftuar> please go ahead and open the issue, thanks!
2622016-11-21T17:25:33  <thermoman> we never had this with 0.11.2 on both nodes
2632016-11-21T17:25:46  <thermoman> (or didn't notice?)
2642016-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.
2652016-11-21T17:26:59  <thermoman> ok, thanks so far. will open the issue tomorrow
2662016-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?
2672016-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
2682016-11-21T17:47:37  <sdaftuar> (and i think this would have been true in 0.11.2 as well)
2692016-11-21T17:49:27  *** crudel has joined #bitcoin-core-dev
2702016-11-21T17:52:09  *** paveljanik has joined #bitcoin-core-dev
2712016-11-21T17:52:10  *** paveljanik has joined #bitcoin-core-dev
2722016-11-21T17:52:23  *** AtashiCon has quit IRC
2732016-11-21T17:57:58  *** Chris_Stewart_5 has quit IRC
2742016-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.
2752016-11-21T18:09:46  *** AtashiCon has joined #bitcoin-core-dev
2762016-11-21T18:14:33  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2772016-11-21T18:17:21  *** laurentmt has joined #bitcoin-core-dev
2782016-11-21T18:18:19  *** laurentmt has quit IRC
2792016-11-21T18:23:31  <sipa> gmaxwell: or rescans became a bit slower since
2802016-11-21T18:38:30  *** cysm has joined #bitcoin-core-dev
2812016-11-21T18:47:42  *** To7 has quit IRC
2822016-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?
2832016-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
2842016-11-21T19:10:54  <instagibbs> sdaftuar, yes, I have literally no experience with those interfaces, what would that entail
2852016-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.
2862016-11-21T19:13:56  <instagibbs> so whatever makes sense for that
2872016-11-21T19:28:54  <sdaftuar> instagibbs: see for instance rest.cpp:371
2882016-11-21T19:29:11  <sdaftuar> oh wait, i made a mistake
2892016-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
2902016-11-21T19:32:05  <sdaftuar> similarly in the rest_block() function in that same file
2912016-11-21T19:32:42  <sdaftuar> and then i think there are two analogous places in zmq/zmqpublishnotifier.cpp
2922016-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
2932016-11-21T19:53:41  *** dermoth has quit IRC
2942016-11-21T19:54:36  *** asoltys has quit IRC
2952016-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.
2962016-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
2972016-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.
2982016-11-21T20:03:23  *** cysm has quit IRC
2992016-11-21T20:25:07  *** cysm has joined #bitcoin-core-dev
3002016-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.
3012016-11-21T20:35:13  <kanzure> 'scuse me, *rpc endpoints
3022016-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.
3032016-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)
3042016-11-21T20:37:42  <kanzure> if sending money is the only scenario where something bad happens, then listtransactions is probably sufficient...
3052016-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)
3062016-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.
3072016-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.'
3082016-11-21T20:51:58  <kanzure> do these problems exist in the http api?
3092016-11-21T20:56:25  <sipa> you mean the REST api? that's read only
3102016-11-21T20:56:48  <sipa> and only for public data (nothing wallet related)
3112016-11-21T21:03:12  <sipa> gcc 7.0 has -Wmisleading-indentation
3122016-11-21T21:04:57  *** sanada has quit IRC
3132016-11-21T21:09:18  *** Alina-malina has quit IRC
3142016-11-21T21:11:27  *** sanada has joined #bitcoin-core-dev
3152016-11-21T21:11:37  *** jannes has quit IRC
3162016-11-21T21:12:03  *** Alina-malina has joined #bitcoin-core-dev
3172016-11-21T21:30:42  *** cysm has quit IRC
3182016-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?
3192016-11-21T21:32:37  <Chris_Stewart_5> You need to infer it from the number of inputs?
3202016-11-21T21:39:40  *** ryan`c is now known as ryan-c
3212016-11-21T21:43:19  *** CubicEarth has joined #bitcoin-core-dev
3222016-11-21T21:47:42  <sipa> Chris_Stewart_5: indeed
3232016-11-21T21:49:07  <kanzure> okay i posted an issue about the abovementioned rpc replay protection concerns https://github.com/bitcoin/bitcoin/issues/9197
3242016-11-21T21:56:56  <Chris_Stewart_5> Thanks sipa
3252016-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?
3262016-11-21T22:05:39  <bsm1175321> Further, is it possible for a truncated RPC request to end up being valid and acted upon?
3272016-11-21T22:06:35  <bsm1175321> BTW I think this is probably RPC "atomicity" not "idempotency".
3282016-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.
3292016-11-21T22:11:36  <bsm1175321> Nah kanzure's right in using idempotent -- CS lingo.  Too much math over here.
3302016-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'"
3312016-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...
3322016-11-21T22:14:17  <kanzure> yes, retrying with the same nonce would be OK
3332016-11-21T22:14:18  <sipa> an alternative is having meta support for any asynchronous command
3342016-11-21T22:14:27  <bsm1175321> I like that idea...
3352016-11-21T22:14:51  <bsm1175321> (I like kanzure's nonce idea).  What's meta support?
3362016-11-21T22:14:58  <sipa> you call an RPC "schedule" with 3 args: 1) command 2) command args 3) call id
3372016-11-21T22:15:18  <sipa> and then you have a separate RPC through which you can chrck the result
3382016-11-21T22:15:38  <kanzure> have you poked at database internals before, like transactional concept?
3392016-11-21T22:15:58  <sipa> define 'poked'
3402016-11-21T22:16:06  <gmaxwell> sipa: that kind of framework is _necessary_ for some commands.
3412016-11-21T22:16:20  <kanzure> eh, 'poked' could be reading i guess :)
3422016-11-21T22:16:29  <gmaxwell> For example automatic sendmany batching and replacement will not know the txid until later.
3432016-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.
3442016-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...
3452016-11-21T22:18:12  *** skyraider has joined #bitcoin-core-dev
3462016-11-21T22:18:17  <bsm1175321> That's separate from calling RPC's over a flaky connection...
3472016-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.
3482016-11-21T22:18:41  <bsm1175321> Yep yep
3492016-11-21T22:18:41  <gmaxwell> "not close RPC connections." < guarentees file descriptor exhaustion.  And is unlike any http server ever.
3502016-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)
3512016-11-21T22:19:45  <bsm1175321> But there's only one RPC user and it's on localhost.  I think this is a common configuration.
3522016-11-21T22:20:12  <bsm1175321> gmaxwell: I agree.  I'm gonna fix it to re-open and not bother me with I/O exceptions.
3532016-11-21T22:20:38  <kanzure> "only one rpc user" what?
3542016-11-21T22:20:41  <sipa> didn't we fix that issue in our in-tree fork of python-bitcoinlib?
3552016-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.
3562016-11-21T22:21:48  *** CubicEarth has quit IRC
3572016-11-21T22:22:34  <bsm1175321> sipa: yes it looks like it is fixed there.
3582016-11-21T22:22:47  *** cysm has joined #bitcoin-core-dev
3592016-11-21T22:23:00  *** CubicEarth has joined #bitcoin-core-dev
3602016-11-21T22:24:24  <kanzure> oh there is an "id" parameter sent https://github.com/petertodd/python-bitcoinlib/blob/2e4d51a482a4331d91de9bae2ab7be56229e664a/bitcoin/rpc.py#L188
3612016-11-21T22:24:45  <kanzure> .. which is auto-incremented in this particular client library..
3622016-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.
3632016-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"
3642016-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
3652016-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?
3662016-11-21T22:31:37  <gmaxwell> skyraider: applications can check list transactions to determine if the order has been executed yet.
3672016-11-21T22:31:48  <sipa> kanzure: that's just for ordering of responses within one connection
3682016-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.
3692016-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.
3702016-11-21T22:33:09  <gmaxwell> "Don't do that."
3712016-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
3722016-11-21T22:33:34  <gmaxwell> I'm just describing to you an architecture I've seen before, which has generally acceptable properties.
3732016-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.
3742016-11-21T22:34:40  *** Guyver2 has quit IRC
3752016-11-21T22:35:28  <kanzure> sipa: oh like for ordering responses to the _batch call?
3762016-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
3772016-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
3782016-11-21T22:37:46  <sipa> anything that actually interferes would cause failure, while other rpcs could still happen concurrently
3792016-11-21T22:37:46  <kanzure> wallet balance isn't good either... many simultaneous deposits/debits could put you back to the same balance anyway.
3802016-11-21T22:38:27  <kanzure> excuse me, credits/debits
3812016-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' ?
3822016-11-21T22:38:42  <gmaxwell> sipa: ugh. so if you send some and recieve the same amount ... the double payment still goes through?
3832016-11-21T22:39:27  <kanzure> 'transaction isolation' probably means database-kind of transaction model, not transactions?
3842016-11-21T22:39:49  <skyraider> uh, yeah, not bitcoin transaction. isolation as in the I from ACID.
3852016-11-21T22:39:51  <gmaxwell> skyraider: yes, you just retry in that model.
3862016-11-21T22:40:18  <kanzure> isn't that a failure
3872016-11-21T22:40:25  <kanzure> the idea is to prevent stales from causing you to retry
3882016-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.
3892016-11-21T22:41:35  <kanzure> you mean existing system, or proposed system is concurrent?
3902016-11-21T22:41:42  <gmaxwell> kanzure: so going back to the nonce, how do you propose avoding having to store nonces forever?
3912016-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?
3922016-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.
3932016-11-21T22:43:48  <gmaxwell> If you just retry you may double pay.
3942016-11-21T22:43:52  <midnightmagic> wtf man another earthquake near fukushima?
3952016-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
3962016-11-21T22:47:59  <skyraider> balance data in read 1).
3972016-11-21T22:48:50  <sipa> skyraider: there is no 'write balance'
3982016-11-21T22:49:05  <sipa> there is 'attempt to make a transaction'
3992016-11-21T22:49:31  <skyraider> yes, sorry, shorthand for "try to send some bitcoin"
4002016-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.
4012016-11-21T22:51:42  <gmaxwell> if you are doing things based on 'balance' then god knows what will happen, as balance is not monotone. :)
4022016-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
4032016-11-21T22:52:19  <kanzure> i think bitcoind seems to really very strongly want all applications to have only one rpc connection
4042016-11-21T22:52:30  <gmaxwell> kanzure: not at all.
4052016-11-21T22:52:38  <kanzure> there is no protection against stale reads at all
4062016-11-21T22:52:45  <kanzure> there is nothing in here at all like ACID
4072016-11-21T22:53:05  <gmaxwell> which is orthorgonal to "have only one rpc connection"
4082016-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.
4092016-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
4102016-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?"
4112016-11-21T22:57:11  <skyraider> logic in a safe way.
4122016-11-21T22:57:49  *** abpa has joined #bitcoin-core-dev
4132016-11-21T22:58:08  <gmaxwell> I disagree.
4142016-11-21T22:58:27  <gmaxwell> What you want is a write which is ordered with respect to a read.
4152016-11-21T22:58:39  <gmaxwell> Have you already paid is not something which can become untrue.
4162016-11-21T22:58:58  <kanzure> previous answer to "have you already paid" can become untrue
4172016-11-21T22:59:18  <gmaxwell> yes but only by performing a write that makes that payment.
4182016-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.
4192016-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
4202016-11-21T23:01:08  <gmaxwell> y it does).
4212016-11-21T23:01:39  *** CubicEarth has quit IRC
4222016-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...
4232016-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
4242016-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.
4252016-11-21T23:05:50  <kanzure> fwiw i don't actually use sendmany
4262016-11-21T23:07:43  <kanzure> or any spends for that matter... heh.
4272016-11-21T23:07:53  <sipa> you hodler
4282016-11-21T23:08:36  *** CubicEarth has joined #bitcoin-core-dev
4292016-11-21T23:08:41  <kanzure> (yeah who would ever want to spend coins??)
4302016-11-21T23:10:51  <midnightmagic> gmaxwell: that's how MP (operating manually) managed to rip himself off.
4312016-11-21T23:13:08  <kanzure> midnightmagic: go on?
4322016-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
4332016-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.
4342016-11-21T23:13:55  <skyraider> but, yes, this is not an actual real-world use case over here at the moment. so admitted.
4352016-11-21T23:14:01  <skyraider> thanks
4362016-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.
4372016-11-21T23:22:35  *** laurentmt has joined #bitcoin-core-dev
4382016-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.
4392016-11-21T23:23:42  <kanzure> *node worker (rpc client communicating to bitcoind)
4402016-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?
4412016-11-21T23:28:22  *** laurentmt has quit IRC
4422016-11-21T23:30:08  <gmaxwell> kanzure: I keep telling you that there is no such assumption.
4432016-11-21T23:33:43  <sipa> kanzure: that also doesn't in any way help with the double issue problem
4442016-11-21T23:53:47  <kanzure> ah, there is a lockunspent at least.