1 2015-11-20T00:17:07  *** davec has quit IRC
  2 2015-11-20T00:20:12  *** tulip has quit IRC
  3 2015-11-20T00:23:07  *** PRab has quit IRC
  4 2015-11-20T00:23:13  *** davec has joined #bitcoin-core-dev
  5 2015-11-20T00:31:21  *** tulip has joined #bitcoin-core-dev
  6 2015-11-20T00:51:07  *** aburan28 has joined #bitcoin-core-dev
  7 2015-11-20T01:05:51  *** aburan28 has quit IRC
  8 2015-11-20T01:10:08  *** dcousens has joined #bitcoin-core-dev
  9 2015-11-20T01:10:19  <dcousens> everytime I read IBLT, I think to myself "inverted bacon lettuce tomato"
 10 2015-11-20T01:10:22  <dcousens> Sigh
 11 2015-11-20T01:15:03  <sipa> LOL
 12 2015-11-20T01:16:29  *** zooko has quit IRC
 13 2015-11-20T01:25:42  *** PaulCapestany has quit IRC
 14 2015-11-20T01:35:10  *** PaulCapestany has joined #bitcoin-core-dev
 15 2015-11-20T01:38:13  *** zooko has joined #bitcoin-core-dev
 16 2015-11-20T01:44:28  *** Ylbam has quit IRC
 17 2015-11-20T01:57:07  <gmaxwell> likewise, fwiw
 18 2015-11-20T02:08:45  *** guest234234 has joined #bitcoin-core-dev
 19 2015-11-20T02:29:44  <GitHub122> [bitcoin] pstratem opened pull request #7064: Perform entire CWallet::TopUpKeyPool in a transaction. (master...2015-11-19-wallet-topupkeypool) https://github.com/bitcoin/bitcoin/pull/7064
 20 2015-11-20T02:30:50  *** guest234234 has quit IRC
 21 2015-11-20T02:34:00  <phantomcircuit> CDB::Close abort's any active transaction, it seems like any time we're calling CDB::Close and have an active transaction in play that's an exception
 22 2015-11-20T02:35:51  *** belcher has quit IRC
 23 2015-11-20T02:57:59  *** zooko has quit IRC
 24 2015-11-20T03:07:16  *** teward has joined #bitcoin-core-dev
 25 2015-11-20T03:33:28  *** guest234234 has joined #bitcoin-core-dev
 26 2015-11-20T05:43:40  *** Guest23423 has joined #bitcoin-core-dev
 27 2015-11-20T05:45:15  *** guest234234 has quit IRC
 28 2015-11-20T06:02:23  *** Guest23423 has quit IRC
 29 2015-11-20T07:21:54  *** paveljanik has quit IRC
 30 2015-11-20T07:22:17  *** paveljanik has joined #bitcoin-core-dev
 31 2015-11-20T07:25:51  *** MarcoFalke has joined #bitcoin-core-dev
 32 2015-11-20T07:35:33  <GitHub13> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c983d6fcb47b...a1bfca80521e
 33 2015-11-20T07:35:33  <GitHub13> bitcoin/master 2798e0b daniel: add powerpc build support for openssl lib
 34 2015-11-20T07:35:34  <GitHub13> bitcoin/master a1bfca8 Wladimir J. van der Laan: Merge pull request #7059...
 35 2015-11-20T07:35:43  <GitHub156> [bitcoin] laanwj closed pull request #7059: add powerpc build support for openssl lib (master...ppc) https://github.com/bitcoin/bitcoin/pull/7059
 36 2015-11-20T07:38:42  <gmaxwell> I'm bummed that my ppc debian host stopped booting. I think something is wrong with the PSU.
 37 2015-11-20T07:39:31  <midnightmagic> I still got mine running!
 38 2015-11-20T07:40:28  <gmaxwell> midnightmagic: can you update to bitcoin core master and see that it still works there?
 39 2015-11-20T07:40:35  <midnightmagic> sure!
 40 2015-11-20T07:40:40  <gmaxwell> I'd wanted to use it to test the switch to libsecp256k1 validation.
 41 2015-11-20T07:41:07  <midnightmagic> hrm. i think it's trying to do a kernel update.
 42 2015-11-20T07:55:42  *** Ylbam has joined #bitcoin-core-dev
 43 2015-11-20T07:58:35  *** MarcoFalke has quit IRC
 44 2015-11-20T08:01:13  <GitHub118> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a1bfca80521e...07b770caf3f5
 45 2015-11-20T08:01:13  <GitHub118> bitcoin/master 33b7f83 MarcoFalke: [qa] travis: cover *receivedby* rpcs
 46 2015-11-20T08:01:14  <GitHub118> bitcoin/master 07b770c Wladimir J. van der Laan: Merge pull request #7019...
 47 2015-11-20T08:01:18  <GitHub39> [bitcoin] laanwj closed pull request #7019: [qa] travis: cover more tests (master...MarcoFalke-2015-receivedby) https://github.com/bitcoin/bitcoin/pull/7019
 48 2015-11-20T08:41:03  <jonasschnelli> sipa: you said when the mempool evicts a tx, the wallet threats it as conflicted. I wrote a test and "gettransaction" on a mempool-evicted tx responses confirmations:-1 but no walletconflicts (=[]). The GUI will probably threats -1 confirmations as conflicted.
 49 2015-11-20T08:41:39  <jonasschnelli> did you mean -1 confirmation = conflicted?
 50 2015-11-20T08:44:50  <Luke-Jr> jonasschnelli: -1 is conflicted; that it shows -1 is a bug
 51 2015-11-20T08:45:19  <Luke-Jr> I wonder if it's safe to use the same logic as walletconflicts for that
 52 2015-11-20T08:46:26  <jonasschnelli> Luke-Jr: But looking at CMerkleTx::GetDepthInMainChain(), it seems like that -1 just means:  "not in the chain, not in the mempool".
 53 2015-11-20T08:46:57  <Luke-Jr> jonasschnelli: at the time that was written, it implied a conflict
 54 2015-11-20T08:47:11  <Luke-Jr> there is an assumption that anything not conflicted, will be in the mempool or chain
 55 2015-11-20T08:47:34  <jonasschnelli> Luke-Jr: right. This assumption fails as soon as mempool can evict txes.
 56 2015-11-20T08:47:36  <Luke-Jr> it's possible doing a more through check could harm performance
 57 2015-11-20T08:47:45  <Luke-Jr> so I'm not sure what the best way to fix it is
 58 2015-11-20T08:48:14  <jonasschnelli> what about "removetransaction" call for -1 confirmations txes? GUI: right click -> remove tx?
 59 2015-11-20T08:48:37  <Luke-Jr> so only allow removing conflicted ones?
 60 2015-11-20T08:48:55  <jonasschnelli> right.
 61 2015-11-20T08:49:15  <Luke-Jr> sounds fine, except s/remove/hide/ at least in the low-level
 62 2015-11-20T08:49:25  <jonasschnelli> agreed.
 63 2015-11-20T08:49:44  <gmaxwell> gah, sipa pointed earlier that we can just check for the actual reason.
 64 2015-11-20T08:50:04  <gmaxwell> Luke-Jr: it won't harm performance any more than what we currently do.
 65 2015-11-20T08:50:13  <jonasschnelli> gmaxwell: did you mean that point: http://bitcoinstats.com/irc/bitcoin-dev/logs/2015/11/19#l1447960611.0
 66 2015-11-20T08:50:23  <Luke-Jr> gmaxwell: oh, good, so it should be easy
 67 2015-11-20T08:50:55  <gmaxwell> jonasschnelli: yes.
 68 2015-11-20T08:51:39  <jonasschnelli> gmaxwell: my issue with that is, that i slowly like to reduce mempool/wallet coupling to have the possibility to detact the wallet over a SPV like connection
 69 2015-11-20T08:51:51  <jonasschnelli> And also, how should SPV wallet deal with mempool eviction.
 70 2015-11-20T08:53:14  <gmaxwell> This is largely unrelated to the actual mempool, it has to do more with the utxo set.  Please don't overdesign right now. A SPV wallet cannot detect a non-in-wallet conflict, but we can.
 71 2015-11-20T08:54:24  <jonasschnelli> gmaxwell: Okay. I see the point. But sipas point would require a way to check if a tx *would* be accepted in the mempool IIRC?
 72 2015-11-20T08:55:18  <jonasschnelli> Luke-Jr : While working on this. How would RBF work in case of user interaction. Could a first feature be "altertransaction" where one could add inputs and or outputs while newfee > oldfee?
 73 2015-11-20T08:55:24  <gmaxwell> It's more of a 'would be accepted in a block', but testing the mempool is a stronger version of that.
 74 2015-11-20T08:56:09  <gmaxwell> For RBF fee revision the way that should work is to precalculate, with nlocktimes, transaction versions with higher fees. But do not broadcast them.  This avoids having to authorize signing multiple times.
 75 2015-11-20T08:56:53  <Luke-Jr> jonasschnelli: I would prefer it behind-the-scenes/automatic, but that may be simpler.
 76 2015-11-20T08:57:45  <jonasschnelli> gmaxwell: huh. Sounds after a nice solution, but probably relatively complex to implement. :)
 77 2015-11-20T08:57:49  <Luke-Jr> eg, sending another payment should probably by default be altering any outstanding unconfirmed one to add an output, but signing a normal one to broadcast in case the former confirms without it
 78 2015-11-20T08:58:11  <Luke-Jr> hah, what I just suggested probably makes gmaxwell's look simple :D
 79 2015-11-20T08:58:17  <gmaxwell> jonasschnelli: as far as remove, I think what would be better is 'archivetransaction' which can be done to any confirm/conflicted transaction or any unconfirmed non-conflicted at least (say) 72 hours old. (so people don't think they can cancel transactions this way)
 80 2015-11-20T08:58:56  <gmaxwell> I think thats fairly simple because it needs basically no interface. it could be litterally a couple line loop to produce the transactions. Storing them is a bit more work.
 81 2015-11-20T09:00:29  <jonasschnelli> Did i got this right; when the mempool evicts a wtx, the inputs automatically are release and can be used in a new transaction?
 82 2015-11-20T09:00:44  <Luke-Jr> jonasschnelli: that's a bug because the wallet thinks it was conflicted
 83 2015-11-20T09:01:04  <jonasschnelli> But also a feature? so "archivetransaction" is just a "visibility" thing?
 84 2015-11-20T09:01:13  <Luke-Jr> not a feature..
 85 2015-11-20T09:01:26  <Luke-Jr> unintended harmful behaviour <.<
 86 2015-11-20T09:01:33  <gmaxwell> It's not a feature; it's a recently introducted bug that is very harmful.
 87 2015-11-20T09:01:35  <sipa> jonasschnelli: hell no!
 88 2015-11-20T09:01:36  <jonasschnelli> But if your transaction got evicted (to less fees), you can automatically create a new-one?
 89 2015-11-20T09:02:07  <Luke-Jr> jonasschnelli: you can't deterministically respend it.. only accidentally
 90 2015-11-20T09:02:23  <gmaxwell> it could cause you to overdraft yourself and rip people off accidentally and be unable to make it right (at least not immediately) because you no longer have enough bitcoin.
 91 2015-11-20T09:02:29  <Luke-Jr> so if you tried to RBF this way, you could quite easily end up sendign the payment twice
 92 2015-11-20T09:02:38  <sipa> jonasschnelli: when the mempool evicts, you specifically do not want to make the coins available again
 93 2015-11-20T09:03:03  <jonasschnelli> sipa: so the only way to re-use the inputs would be with RBF?
 94 2015-11-20T09:03:28  <jonasschnelli> would be/should be
 95 2015-11-20T09:03:31  <sipa> jonasschnelli: you only do that when the reason for not being in the mempool is conflict with the blockchain
 96 2015-11-20T09:03:33  <gmaxwell> jonasschnelli: no, we need to fix that conflict check to work correctly now that eviction is possible.
 97 2015-11-20T09:03:48  <sipa> jonasschnelli: read the meeting log
 98 2015-11-20T09:04:18  <gmaxwell> They should only become available again once actually conflicted (or to a RBF respend which still pays the original destination)
 99 2015-11-20T09:04:23  <sipa> jonasschnelli: RBF is a full node side thing, not a wallet thing
100 2015-11-20T09:04:58  <gmaxwell> but we probably shouldn't be implementing wallet replacement behavior yet, not until after it's generally available in the network.
101 2015-11-20T09:05:19  <gmaxwell> Though yes, archive would be just a visibility thing.
102 2015-11-20T09:05:30  <gmaxwell> (and potentially memory usage and performance)
103 2015-11-20T09:07:05  <jonasschnelli> so we need something like this: if confirmations = -1, check if tx would be accepted to the mempool, if rejected due to non-existing inputs = conflicted
104 2015-11-20T09:07:46  <Luke-Jr> …no
105 2015-11-20T09:08:04  <gmaxwell> jonasschnelli: the whole -1 comes from checking the mempool, the specific behavior of that check just needs to be changed a bit so that it's not confused by the new behavior.
106 2015-11-20T09:08:23  <Luke-Jr> if the transaction isn't conflicted, then confirmations != -1
107 2015-11-20T09:09:19  <gmaxwell> perhaps we should also add a field on the transaction that indicates if its in the local mempool or not. (or even what its position is, now that our mempool is usefully sorted)
108 2015-11-20T09:09:24  <sipa> the easiest, but ugly way, is to check the return validation state code from accepttomemorypool
109 2015-11-20T09:10:43  <gmaxwell> (well perhaps not, since position is uncachable.; though a mempoolposition <txid> wouldn't be bad.)
110 2015-11-20T09:12:52  <Luke-Jr> feels like something that we'd be likely to want to change after 0.12 IMO
111 2015-11-20T09:13:15  <Luke-Jr> (although I wanted to give a good example reason, but I couldn't come up with one)
112 2015-11-20T09:13:52  <gmaxwell> Luke-Jr: what would be?
113 2015-11-20T09:14:11  <Luke-Jr> gmaxwell: mempool position of tx stuff
114 2015-11-20T09:14:32  <Luke-Jr> the exposed interface seems not necessarily obvious
115 2015-11-20T09:17:28  <jonasschnelli> But while looking at https://github.com/bitcoin/bitcoin/blob/master/src/wallet/wallet.cpp#L1521, it looks like that the wallet does not spend evicted transaction (confirmations: -1)? Will test now...
116 2015-11-20T09:19:21  *** Guest23423 has joined #bitcoin-core-dev
117 2015-11-20T09:21:03  <Luke-Jr> jonasschnelli: that's not the issue
118 2015-11-20T09:21:12  <Luke-Jr> the UTXOs are confirmed, in this case
119 2015-11-20T09:21:32  <Luke-Jr> but they are also spent already.
120 2015-11-20T09:22:19  <Luke-Jr> that nDepth is the UTXO's transaction depth, not the spending transaction's depth
121 2015-11-20T09:23:35  <jonasschnelli> Argh. Right...
122 2015-11-20T09:24:32  <GitHub185> [bitcoin] laanwj opened pull request #7065: http: add Boost 1.49 compatibility (master...2015_11_httpserver_boost1_49) https://github.com/bitcoin/bitcoin/pull/7065
123 2015-11-20T09:25:55  <gmaxwell> https://www.reddit.com/r/Bitcoin/comments/3tigrp/comcast_data_caps_will_make_nodes_running_with/
124 2015-11-20T09:26:45  *** paveljanik has quit IRC
125 2015-11-20T09:26:46  *** Guest23423 has quit IRC
126 2015-11-20T09:29:26  <jonasschnelli> Luke-Jr: so that a relevant part?: https://github.com/bitcoin/bitcoin/blob/master/src/wallet/wallet.cpp#L459
127 2015-11-20T09:30:20  <sipa> jonasschnelli: no
128 2015-11-20T09:30:27  *** CodeShark has joined #bitcoin-core-dev
129 2015-11-20T09:30:36  <sipa> jonasschnelli: the relevant part is the GetDepthInMainChain computation
130 2015-11-20T09:30:40  <Luke-Jr> jonasschnelli: the only part that needs to be touched right now, is GetDepthInMainChain
131 2015-11-20T09:30:46  <sipa> which looks at the mempool
132 2015-11-20T09:31:05  <sipa> if it isn't in the mempool, it should just return 0
133 2015-11-20T09:31:31  <sipa> upon first submit, and upon eviction, we should check the return value of accepttomemorypool
134 2015-11-20T09:32:13  <sipa> and when that indicates it's due to missing input, set a boolean flag remember in the wallet
135 2015-11-20T09:32:14  <Luke-Jr> sipa: well, it needs to return -1 when conflicted or we break other stuff
136 2015-11-20T09:32:37  <Luke-Jr> or rather, <0
137 2015-11-20T09:32:46  <sipa> and when GetDepthInMemoryPool would return 0 and that flag is said, only then return -1
138 2015-11-20T09:32:53  <Luke-Jr> IIRC the original plan was -1 if the conflicting tx was 1 block deep; -2 and so on for more blocks
139 2015-11-20T09:33:17  <sipa> right, that's an older idea that becomes viable again
140 2015-11-20T09:33:18  <Luke-Jr> but no need to do that now
141 2015-11-20T09:33:22  <sipa> indeed
142 2015-11-20T09:34:43  <sipa> Luke-Jr: we also need to be informee on eviction, with the reason for that eviction (or alternatively, resubmit upon eviction)
143 2015-11-20T09:35:22  <Luke-Jr> sipa: well, if we're just going to resubmit as-is, we might as well just set a priority on our own transactions so they never get evicted
144 2015-11-20T09:35:53  <sipa> Luke-Jr: the resubmit would fail
145 2015-11-20T09:36:05  <sipa> Luke-Jr: the reason to do is to find out why it fails
146 2015-11-20T09:36:24  <Luke-Jr> ah
147 2015-11-20T09:40:55  *** guest234234 has joined #bitcoin-core-dev
148 2015-11-20T09:45:13  <jonasschnelli> sipa: what about informing/signaling the wallet in case of mempool eviction and set the wtx flag then (=confirmation: 0 instead of -1)? Would that be wrong?
149 2015-11-20T09:47:02  <sipa> jonasschnelli: read 5 lines up
150 2015-11-20T09:47:50  <gmaxwell> We shouldn't depend on submission or resubmission.
151 2015-11-20T09:48:01  <sipa> gmaxwell: hmm?
152 2015-11-20T09:48:11  <sipa> submission certainly
153 2015-11-20T09:48:19  <gmaxwell> For example, if walletbroadcast=0 we should still learn when it goes conflicted.
154 2015-11-20T09:48:22  <jonasschnelli> Saw that. But would that still require to evaluate the pfMissingInputs on first submitting?
155 2015-11-20T09:48:27  <sipa> gmaxwell: ugh
156 2015-11-20T09:48:52  <sipa> so we need an AcceptToMemoryPool dryrun mode?
157 2015-11-20T09:48:57  <gmaxwell> When the transaction is added to wallet we should check if it is conflicted. Then on every block tip change we should check all unconfirmed transactions if they are conflicted.
158 2015-11-20T09:49:24  <sipa> ok, i guess it's easier then to add a main function CheckForConflicgts
159 2015-11-20T09:49:39  <sipa> and call then if submission fails or is skipped, or we are evicted
160 2015-11-20T09:49:48  <sipa> and cache the result
161 2015-11-20T09:49:59  <gmaxwell> I don't think we need to do anything with evicted?
162 2015-11-20T09:50:17  <sipa> eviction also happens on block confirm, no?
163 2015-11-20T09:50:22  <gmaxwell> just cache until blockchain tip changes,
164 2015-11-20T09:50:47  <sipa> ok, that seems reasonable
165 2015-11-20T09:51:21  <sipa> or even cache the blockindex itself, and as long as the active one descends from it, don't reevaluate if true
166 2015-11-20T09:51:42  <gmaxwell> seperately it would be interesting to know if a txn was in-mempool or not, but I think thats not really cachable. :(
167 2015-11-20T09:51:48  <sipa> right
168 2015-11-20T09:52:14  <gmaxwell> sipa: yes, right once conflicted it would be nice if it were cheap, so a bunch of these don't become a performance sink in the wallet. Good call.
169 2015-11-20T09:54:36  <gmaxwell> non-cachability of the mempool check is perhaps not that bad though, since it would only run on transactions which are not confirmed nor conflicted.
170 2015-11-20T10:04:32  <sipa> gmaxwell: yes, because such a conflict check will pull in dependent utxos from the chainstate
171 2015-11-20T10:04:42  <sipa> so icthink we want to avoid that at all costs
172 2015-11-20T10:08:19  <gmaxwell> sipa: hm? To test if a transaction is in mempool we would just access the mempool by txid and check the transaction hash itself against it. Not try submitting it.
173 2015-11-20T10:20:51  <jonasschnelli> gmaxwell, sipa: mind doing a quick concept-review if I'm going into the right direction (big !WIP!, just check the concept): https://github.com/jonasschnelli/bitcoin/commit/723b7c365ceaa1567c364e1ffc5602f5dfd1b7fb
174 2015-11-20T10:21:15  <jonasschnelli> There is no check right now when adding a wtx to the wallet.
175 2015-11-20T10:28:38  <sipa> gmaxwell: well you need to check whether all inputs are available
176 2015-11-20T10:28:53  <sipa> gmaxwell: which means looking at the utxo set, not just the wallet
177 2015-11-20T10:30:58  <sipa> jonasschnelli: GetDepthInMainChain should return 0 if not conflicted
178 2015-11-20T10:31:00  <gmaxwell> I don't think you do, you do that via the conflicted check, which is cached.
179 2015-11-20T10:31:28  <sipa> gmaxwell: i'm confused; how could you detect a conflict with mempool that limited to zero?
180 2015-11-20T10:31:46  <sipa> it's trivial if you see some inputs spent in the utxo set
181 2015-11-20T10:31:58  <jonasschnelli> sipa: i think it should return 0 in that case (GetDepthInMainChainINTERNAL will result in 0), but will check
182 2015-11-20T10:32:18  <gmaxwell> I am saying there should be a Conflicted check that doesn't touch the viewcache, but checks the utxo set directly and is cached and keyed by blockindex.
183 2015-11-20T10:32:34  <sipa> gmaxwell: ok, i agree there
184 2015-11-20T10:32:48  <gmaxwell> If a transaction is unconfirmed and unconflicted (by the above), we could also check if the transaction is in the mempool, which is cheap.
185 2015-11-20T10:32:56  <gmaxwell> What I suggest wouldn't distinguish an in-mempool conflict with too-low-fee, but I think thats no big loss.
186 2015-11-20T10:33:17  <sipa> gmaxwell: minimal viable solution firstz place
187 2015-11-20T10:33:21  <sipa> grrr
188 2015-11-20T10:33:27  <sipa> minimal viable solution first
189 2015-11-20T10:33:49  <gmaxwell> ya ya. mostly its an observation that the direct test doesn't preclude also having a reasonable cheap mempoolness check.
190 2015-11-20T10:34:35  <sipa> what difference does in-mempoolness make? how do we report the result?
191 2015-11-20T10:35:24  <gmaxwell> sipa: listtransactions output,  tells you if your unconfirmed tx is probably screwed. :)
192 2015-11-20T10:36:26  <sipa> gmaxwell: all i was saying is that jonas' conflict check shouldn't (only) look at the mempool but at the utxo set
193 2015-11-20T10:37:37  <sipa> in fact, i don't know if having a conflict in the mempool should matter at all for respendability... just because you accepted a different conflicting mempool tz does not mean the network will (though very likely...)
194 2015-11-20T10:38:16  <gmaxwell> yes, I agree, -1 should mean blockchain conflict.
195 2015-11-20T10:38:40  <gmaxwell> But if it does; it's useful to know that the transaction isn't in the mempool.
196 2015-11-20T10:38:47  <sipa> sure
197 2015-11-20T10:38:59  <gmaxwell> Ideally we'd give the depth of the earliest conflict, but sadly thats stupidly expensive to do. :(
198 2015-11-20T10:39:23  <gmaxwell> at least with how things are structured now.
199 2015-11-20T10:39:24  <sipa> not when there are other txouts of the txid still in the utxo set
200 2015-11-20T10:39:35  <gmaxwell> yes, sure but thats not reliable.
201 2015-11-20T10:39:38  <sipa> indeed
202 2015-11-20T10:39:48  <CodeShark> txindex? :)
203 2015-11-20T10:39:55  <gmaxwell> we could do it so long as we captured it as it flew by and recorded it in the wallet.
204 2015-11-20T10:40:01  <sipa> CodeShark: die!
205 2015-11-20T10:40:04  <CodeShark> lol
206 2015-11-20T10:40:17  <sipa> CodeShark: it's german for "the"
207 2015-11-20T10:41:07  <CodeShark> feminine nominative/accusative
208 2015-11-20T10:41:14  <sipa> correct!
209 2015-11-20T10:41:27  <gmaxwell> http://flyingscotsman.tumblr.com/post/3486957620/laywer-well-what-about-that-tattoo-on-your
210 2015-11-20T10:41:56  <CodeShark> Ich weiss etwas Deutch Grammatik :)
211 2015-11-20T10:42:22  <CodeShark> *Deutsch
212 2015-11-20T10:42:31  <CodeShark> not dutch :p
213 2015-11-20T10:42:51  <CodeShark> although dutch grammar is simpler
214 2015-11-20T10:42:53  <CodeShark> but offtopic
215 2015-11-20T10:43:43  <gmaxwell> in any case, the conflict depth is pretty much only interesting for small values  e.g. it would be superior to not release conflicted txins for general respond until -3 (or -6) ... but no one cares about -500 vs -600
216 2015-11-20T10:43:46  <CodeShark> Bart is a girl? :)
217 2015-11-20T10:45:21  <CodeShark> gmaxwell:  you mean only flush txs from mempool once they're sufficiently buried?
218 2015-11-20T10:45:51  <sipa> CodeShark: we're talking about the wallet
219 2015-11-20T10:46:03  <CodeShark> right - so the wallet needs its own mempool :)
220 2015-11-20T10:46:10  <CodeShark> I remember this topic a couple years ago
221 2015-11-20T10:46:15  <gmaxwell> it's not really a mempool thing at all.
222 2015-11-20T10:46:34  <CodeShark> well, it needs to keep track of its own transactions
223 2015-11-20T10:46:39  <CodeShark> and dependencies
224 2015-11-20T10:47:51  <gmaxwell> Right now the wallet will allow another transaction to reuse the non-conflicted txins from a conflicted transaction. This avoids the case when some malleated change vanishes on you, and a tx which has now been conflicted on account of it spent other coins as well, and now those coins are in limbo.
225 2015-11-20T10:47:58  <sipa> gmaxwell: it's really quite complicated... the question for each input is whether the corresponding is available or would become available.
226 2015-11-20T10:48:11  <sipa> . which means looking at the wallet, the mempool, and the utxo set
227 2015-11-20T10:48:43  <gmaxwell> Thats fine and all, but -1 depth is not a guarentee that the conflict will stick, there might be a reorg that unconflicts it.. so it would probably be better to not free up the inputs quite so fast.
228 2015-11-20T10:49:37  <gmaxwell> perhaps a cheaper approximation, is to record the height that it first hit -1 (side effect of the cache, in fact); and then make it available for respend N blocks later.
229 2015-11-20T10:50:37  <sipa> how do you define "hit -1"
230 2015-11-20T10:50:56  <sipa> all you can observe reliably is that there is an input missing
231 2015-11-20T10:51:24  <gmaxwell> I know, as I said 'approximation'.
232 2015-11-20T10:51:38  <sipa> ok
233 2015-11-20T10:51:47  <CodeShark> 2 + 2 approximates 5 for sufficiently large values of 2
234 2015-11-20T10:52:02  <sipa> but that check does not output a height
235 2015-11-20T10:52:08  <sipa> and it depends on the mempool
236 2015-11-20T10:52:44  <gmaxwell> why does it depend on the mempool?
237 2015-11-20T10:52:57  <CodeShark> dependencies
238 2015-11-20T10:53:09  <sipa> because unconfirmed inputs won't be in the utxo set
239 2015-11-20T10:53:23  <gmaxwell> They'll be in the wallet.
240 2015-11-20T10:53:26  <CodeShark> no
241 2015-11-20T10:53:28  <CodeShark> not necessarily
242 2015-11-20T10:53:36  <CodeShark> they don't necessarily belong to the wallet
243 2015-11-20T10:53:37  <sipa> not for things that pay you
244 2015-11-20T10:53:57  <CodeShark> someone could construct a chain of unconfirmed transactions, only the last one pays you
245 2015-11-20T10:54:00  <gmaxwell> oh right, also recieved transactions can be conflicted. It's true.
246 2015-11-20T10:54:17  <CodeShark> for intelligent conflict detection, the wallet must be alerted when any dependency is conflicted
247 2015-11-20T10:54:28  <gmaxwell> sorry, had slipped into thinking only in terms of sent because I was thinking about the free to reuse question.
248 2015-11-20T10:54:36  <sipa> received transactions matter even more, because they're the only ones that give spendable outputs
249 2015-11-20T10:54:56  <gmaxwell> sipa: 0_o. change.
250 2015-11-20T10:55:33  <sipa> oh, right
251 2015-11-20T10:55:39  <gmaxwell> (googlyeyes simply because basically all conflict originated problems are related to change; since change is the only thing we'll spend with few/no confirms!)
252 2015-11-20T10:55:41  <Luke-Jr> gmaxwell: just send all your change to sipa and that problem goes away
253 2015-11-20T10:56:08  * sipa approves
254 2015-11-20T10:56:17  <gmaxwell> new wallet feature: eliminates all malleability problems by sending your coins to sipa.
255 2015-11-20T10:56:34  <Luke-Jr> :D
256 2015-11-20T10:57:19  <sipa> gmaxwell: now.i wonder what googly eyes are...
257 2015-11-20T10:57:54  <Luke-Jr> sipa: "0_o"
258 2015-11-20T11:00:16  <CodeShark> basically, there currently is no safe way to spend an unconfirmed output ;)
259 2015-11-20T11:00:31  <CodeShark> even your own
260 2015-11-20T11:01:43  <CodeShark> for some malleability attacks about the best you can do is sign all likely cases
261 2015-11-20T11:02:03  <CodeShark> and have the txs ready to broadcast
262 2015-11-20T11:03:59  <wumpus> there's an option in bitcoin core's wallet to not spend any unconfirmed outputs
263 2015-11-20T11:04:15  <CodeShark> but then your funds potentially get tied up for a while
264 2015-11-20T11:04:44  <wumpus> it is only not the default because that was deemed too big a change from previous behavior
265 2015-11-20T11:04:58  <CodeShark> and it's also impractical in many scenarios
266 2015-11-20T11:05:06  <gmaxwell> CodeShark: well it'll be pratically pretty safe soon.
267 2015-11-20T11:05:13  <sipa> gmaxwell: the wallet does get informed about all blockchain transactions, so i think we can just use that to detect conflicts
268 2015-11-20T11:05:27  <CodeShark> yes, indeed - I'm very happy about that, gmaxwell
269 2015-11-20T11:05:36  <gmaxwell> The don't spend unconfirmed change thing is pretty obnoxious unless you understand bitcoins operation very well and intentionally create extra outputs.
270 2015-11-20T11:05:47  <wumpus> anything involving zero confirmation is risky
271 2015-11-20T11:06:01  <sipa> we should be creating extra outputs anyway for amount privacy
272 2015-11-20T11:06:09  <CodeShark> about the best way to mitigate having funds tied up for a while is to create denominated outputs up front
273 2015-11-20T11:06:24  <CodeShark> which is ugly in terms of block chain bloat
274 2015-11-20T11:06:26  <wumpus> absolutely, better output management could avoid having *all* your funds tied up
275 2015-11-20T11:06:55  <wumpus> e.g. by having multiple change outputs
276 2015-11-20T11:06:56  <gmaxwell> During the last malleability attacks I walked a bitcoin ATM operator through doing that. Hard part was explaining the need, once they got it the actual implementation was easy. (well also the wallet they were using to fill their ATMs ..... had no sendmany support. :( )
277 2015-11-20T11:07:00  <btcdrak> BIP68 bip text has been updated https://github.com/bitcoin/bips/issues/245
278 2015-11-20T11:07:51  <gmaxwell> sipa: yea, did I ever tell you my thought?  if the change would be 'large'  flip a coin and either split the change 50/50, or make one change equal to the payment and the other the remainder.
279 2015-11-20T11:08:17  <sipa> gmaxwell: yup, that'd be useful
280 2015-11-20T11:08:28  <sipa> gmaxwell: except when the payment is a nice round number
281 2015-11-20T11:08:52  <sipa> gmaxwell: then you probably always want to make the change identical to it (or a round fraction/muktiple)
282 2015-11-20T11:09:06  <CodeShark> denominating outputs in powers of 2 and limiting precision can help
283 2015-11-20T11:09:23  <CodeShark> sometimes having the extra precision means adding dust outputs :)
284 2015-11-20T11:09:37  <gmaxwell> sipa: well the decision could be biased, but the basic idea is reasonable.
285 2015-11-20T11:09:43  <sipa> gmaxwell: agree
286 2015-11-20T11:15:27  *** d_t has quit IRC
287 2015-11-20T11:19:13  <sipa> gmaxwell: if conflicting wallet transactions with change
288 2015-11-20T11:19:33  <sipa> can be accepted without conflicting
289 2015-11-20T11:19:44  <sipa> then inthink our balance calc will be off
290 2015-11-20T11:20:55  *** randy-waterhouse has quit IRC
291 2015-11-20T11:24:26  <CodeShark> a scheme that avoids the need for change outputs without bloating the blockchain would fix a bunch of problems
292 2015-11-20T11:24:38  <CodeShark> I've also had issues with asynchronous signing
293 2015-11-20T11:25:06  <CodeShark> perhaps some transaction is rejected by the authorization layer and never gets signed...which ties up the outputs
294 2015-11-20T11:26:01  <CodeShark> which means it ties up any attempts to sign dependencies
295 2015-11-20T11:26:02  <sipa> oh! we should only count unconfirmed transactions (from ourselves) if they are in the mempool
296 2015-11-20T11:26:26  <wumpus> sounds sensible sipa
297 2015-11-20T11:26:47  <sipa> but only mark them conflicted/respendable when they have a conflict in the chain
298 2015-11-20T11:26:58  <wumpus> right
299 2015-11-20T11:29:58  *** jtimon_ has joined #bitcoin-core-dev
300 2015-11-20T11:30:19  *** jtimon has quit IRC
301 2015-11-20T11:33:02  <CodeShark> more sensible than what we currently do...but still has issues
302 2015-11-20T11:33:59  <CodeShark> I guess the UI could indicate that certain transactions have failed
303 2015-11-20T11:34:09  <CodeShark> and prompt the user to resend
304 2015-11-20T11:34:59  <CodeShark> or automatically resign and resend if the keys are unencrypted
305 2015-11-20T11:35:14  <CodeShark> although that might open up security holes
306 2015-11-20T11:36:05  <sipa> CodeShark: the plan was to have a function to mark a tx as failed
307 2015-11-20T11:36:07  <sipa> manually
308 2015-11-20T11:36:33  <CodeShark> well, other than the usability complications, it technically is consistent behavior
309 2015-11-20T11:38:11  <CodeShark> and arguably less problematic than having a zero fee transaction in limbo for a long time :)
310 2015-11-20T11:38:23  <tulip> is there an opportunity in all this for a user to "remove" a transaction, make an alternative with different outputs, and both confirm?
311 2015-11-20T11:39:55  <gmaxwell> I'm really not keen on requiring the manual intervention, I can see this resulting in lost funds.
312 2015-11-20T11:40:53  <gmaxwell> Consider an automated user, ends up with some conflicted transactions.  Further spending gets rejected with insufficient funds, they think they're out of bitcoins and delete the wallet-- but they could have had a large amount remaining.
313 2015-11-20T11:41:37  <gmaxwell> tulip: you mean spending different outputs (different inputs)?
314 2015-11-20T11:41:49  <tulip> yes.
315 2015-11-20T11:42:32  <gmaxwell> That generally exists, even now. Though they don't have a remove button which they might misunderstand to abort the transaction.
316 2015-11-20T11:43:47  <gmaxwell> We can harden against that in the GUI by making the wallet warn you when you paid and address you've paid before. (something suggested before, because it can also avoid copied-the-wrong-line and double paid problems)
317 2015-11-20T11:45:29  <CodeShark> I've had to directly deal with this issue in production before...and had to enable deleting transactions that have already propagated...and yes, it's a mess to keep track of stuff
318 2015-11-20T11:46:17  <gmaxwell> well we have zapwallettx to knock out any conflicted/unconfirmeds from the wallet,  tech support via napalm.
319 2015-11-20T11:46:28  <CodeShark> lol
320 2015-11-20T11:46:37  <sipa> napalm is cool, when frozen
321 2015-11-20T11:47:05  <gmaxwell> ^ man, I want a bot that produces comments like that.
322 2015-11-20T11:48:04  <CodeShark> gmaxwell: I went ahead and added an API call to delete transactions - initially it would only allow deleting transactions that have not yet propagated (i.e. missing signatures)
323 2015-11-20T11:48:18  <gmaxwell> in any case a dialog that says "You've paid X before, are you sure?" then shows the most recent payments to X. would likely help a lot there for gui users.
324 2015-11-20T11:48:42  <CodeShark> but I had to eventually allow deleting even propagated transactions for malleability attacks and transactions that just won't confirm (low fees)
325 2015-11-20T11:49:08  <CodeShark> and for any sort of high volume operation it's a nightmare
326 2015-11-20T11:49:53  <gmaxwell> CodeShark: have you yet had someone have something deleted make it through and be surprised?
327 2015-11-20T11:50:36  <CodeShark> fortunately no terrible losses have occured...but it has required extra careful manual intervention
328 2015-11-20T11:51:21  *** guest234234 has quit IRC
329 2015-11-20T11:52:18  <gmaxwell> I once found a mtgox transaction that was created almost a year before but managed to never make it into the chain (maybe wasn't relayed well), and was still valid.
330 2015-11-20T11:52:45  <CodeShark> and ultimately, being extra careful also means creating a bottleneck and greatly reducing transaction processing volume (or grinding to a halt)...which some consider bad for business
331 2015-11-20T11:54:14  <GitHub86> [bitcoin] paveljanik opened pull request #7066: [Trivial,Doc] Add missing "blocktime" description to listtransactions help, fix formatting. (master...listtransactions_blocktime) https://github.com/bitcoin/bitcoin/pull/7066
332 2015-11-20T11:54:43  <CodeShark> gmaxwell: where did you find it? :)
333 2015-11-20T11:55:52  <gmaxwell> For people I've helped with this, they did batch correction, where basically they shut down operations temporarily, waited for all outstanding to confirm, extracted all the transactions, checked all the conflicted outputs against the blockchain to figure out who hadn't been paid yet. zapped the wallet. Redid the missing payments with a transaction that spend all their coins.
334 2015-11-20T11:56:31  <gmaxwell> (and also split up their wallet into new outputs, so they could reasonably run with spending unconfirmed change off)
335 2015-11-20T11:59:51  *** Thireus has quit IRC
336 2015-11-20T11:59:53  *** Thireus1 has joined #bitcoin-core-dev
337 2015-11-20T12:00:53  *** Thireus has joined #bitcoin-core-dev
338 2015-11-20T12:00:53  *** Thireus1 has quit IRC
339 2015-11-20T12:04:55  *** Thireus has quit IRC
340 2015-11-20T12:06:46  <kanzure> huh, what are the chances of an ancient mtgox transaction still being valid? i mean, that would require a lot of utxos..
341 2015-11-20T12:07:44  <gmaxwell> mtgox intentional split their wallet into tiny utxo.
342 2015-11-20T12:08:57  <gmaxwell> My memory is a bit fuzzy, I think what the sequence of events was is that when mtgox was imploding I was trying to determine all the addresses that were theirs. And someone had been logging their api output that listed all their transactions.. and I was going through all that to find every address they every claimed to sign for.
343 2015-11-20T12:09:15  <gmaxwell> And noticed that one of the old ones had an unspent input.
344 2015-11-20T12:09:29  <kanzure> smaller than dust?
345 2015-11-20T12:09:56  *** MarcoFalke has joined #bitcoin-core-dev
346 2015-11-20T12:10:12  <gmaxwell> no, not that small. The code that did that is public in that leaked php I think.
347 2015-11-20T12:10:36  <tulip> the repo with all of the logged transactions is on github, somewhere.
348 2015-11-20T12:11:27  <kanzure> tulip: ah didn't know, thanks
349 2015-11-20T12:11:39  <kanzure> v. nice to have this historical data
350 2015-11-20T12:12:58  <gmaxwell> I think the algorithim was something like if a txout is >threshold (10btc?) split, with a ration that is some exponential distribution, with 50/50 the most common, or something like that. (could be my imagination)
351 2015-11-20T12:13:16  <gmaxwell> s/ration/ratio/
352 2015-11-20T12:13:57  <tulip> https://gist.github.com/alainmeier/9319451#file-mtgox-php-L120-L151
353 2015-11-20T12:14:20  *** Thireus has joined #bitcoin-core-dev
354 2015-11-20T12:15:14  *** Thireus1 has joined #bitcoin-core-dev
355 2015-11-20T12:16:54  <midnightmagic> tulip: don't suppose you'd be willing to dig that github repo up would you?
356 2015-11-20T12:19:01  *** Thireus has quit IRC
357 2015-11-20T12:22:29  <midnightmagic> gmaxwell: corruption again on the ppc system. I'm doing a reindex..
358 2015-11-20T12:23:12  <tulip> kanzure: midnightmagic: https://github.com/mtgoxtxfeed/json
359 2015-11-20T12:23:20  <midnightmagic> tulip: thank you
360 2015-11-20T12:27:41  <GitHub15> [bitcoin] jonasschnelli opened pull request #7067: [Wallet] improve detection of conflicted transactions (master...2015/11/mempool_wallet) https://github.com/bitcoin/bitcoin/pull/7067
361 2015-11-20T12:28:08  <midnightmagic> gmaxwell: progress projects a 6-9 day reindex. do you want me to just let you know when it gets to head, or is that fact it's churning right now good enough for you? commitid: a1bfca80521ee99d70bc19a797484275d84e136f
362 2015-11-20T12:31:56  <gmaxwell> midnightmagic: that its churning is good information!
363 2015-11-20T12:32:12  *** PaulCape_ has joined #bitcoin-core-dev
364 2015-11-20T12:32:14  <midnightmagic> gmaxwell: okie doke.
365 2015-11-20T12:34:59  *** PaulCapestany has quit IRC
366 2015-11-20T13:05:43  <GitHub146> [bitcoin] jonasschnelli opened pull request #7068: [RPC-Tests] add simple way to run rpc test over QT clients (master...2015/11/rpc_tests_qt) https://github.com/bitcoin/bitcoin/pull/7068
367 2015-11-20T13:09:52  <gmaxwell> [OT] Sad news, ITU announces that they've decided to not stop creating leapseconds for now, and spend 8 more years researching the impact.
368 2015-11-20T13:21:31  *** tulip has quit IRC
369 2015-11-20T13:27:51  <GitHub117> [bitcoin] MarcoFalke opened pull request #7069: [trivial] Fix -maxmempool InitError (master...MarcoFalke-2015-maxmempoolInitError) https://github.com/bitcoin/bitcoin/pull/7069
370 2015-11-20T13:34:21  <GitHub192> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/07b770caf3f5...776848acefa8
371 2015-11-20T13:34:22  <GitHub192> bitcoin/master c197798 Jonas Schnelli: [Qt] simple mempool info in debug window
372 2015-11-20T13:34:22  <GitHub192> bitcoin/master 776848a Wladimir J. van der Laan: Merge pull request #6979...
373 2015-11-20T13:34:31  <GitHub105> [bitcoin] laanwj closed pull request #6979: [Qt] simple mempool info in debug window (master...2015/11/qt_mempool_easyinfo) https://github.com/bitcoin/bitcoin/pull/6979
374 2015-11-20T13:35:35  *** tulip has joined #bitcoin-core-dev
375 2015-11-20T13:39:41  *** tulip has quit IRC
376 2015-11-20T13:39:41  *** tulip has joined #bitcoin-core-dev
377 2015-11-20T13:54:08  *** guest234234 has joined #bitcoin-core-dev
378 2015-11-20T13:55:11  *** ParadoxSpiral has joined #bitcoin-core-dev
379 2015-11-20T14:02:19  *** teward has quit IRC
380 2015-11-20T14:03:19  *** gmaxwell has quit IRC
381 2015-11-20T14:03:26  *** gmaxwell has joined #bitcoin-core-dev
382 2015-11-20T14:03:49  *** gmaxwell is now known as Guest61914
383 2015-11-20T14:04:09  *** Guest61914 has joined #bitcoin-core-dev
384 2015-11-20T14:05:50  *** Guest61914 is now known as gmaxwell
385 2015-11-20T14:06:18  *** teward has joined #bitcoin-core-dev
386 2015-11-20T14:21:11  *** tulip has quit IRC
387 2015-11-20T14:33:23  *** guest234234 has quit IRC
388 2015-11-20T14:36:42  <jtimon_> morcos: ping https://github.com/jtimon/bitcoin/commit/6963b9ccb2c889564a2e0239aa73f03f6d406784
389 2015-11-20T14:47:40  <morcos> jtimon: i saw that.  i like the idea, but not exactly that.  I think it is usefull for TrimToSize still take an argument, and TrimToSize should then set the internal attribute of the mempool letting it know what size it has been set to.
390 2015-11-20T14:48:19  <morcos> That way the policy logic on what size the mempool should be trimmed to is outside the mempool.  GetMinFee could access that internal attribute in the same way you have it
391 2015-11-20T14:49:02  <morcos> I don't love calling that from txmempool.cpp, since I'd like that pass through function to go away, and the policy estimator to be called directly from the wallet I htink?
392 2015-11-20T14:49:54  <morcos> My concern about that is someone needs to know to ask the mempool for its min fee if you want to estimate fees?  Where should that logic live.  IN my opinion not in the mempool.
393 2015-11-20T14:50:54  <morcos> So it doesn't seem unreasonable to me that the policyestimator is going to need to ask the mempool questions.  what questions it needs to ask and what it does with them, seem logic that could live in the estimator itself.  and therefore you have to pass in a pool, but i don't know...
394 2015-11-20T14:53:39  <morcos> In any case, I'm out of town for the next week+ so I'm not really going to have much time to modify it myself.  However if we end up with some changes that we think are good, I'm happy for you or sdaftuar to incorporate them
395 2015-11-20T15:17:51  *** treehug88 has joined #bitcoin-core-dev
396 2015-11-20T15:21:19  *** zooko has joined #bitcoin-core-dev
397 2015-11-20T15:36:42  *** zooko is now known as zookolaptop
398 2015-11-20T15:51:39  *** CodeShark has quit IRC
399 2015-11-20T15:52:19  *** Guyver2 has joined #bitcoin-core-dev
400 2015-11-20T15:58:41  <GitHub11> [bitcoin] MarcoFalke opened pull request #7070: Move hardcoded maxFeeRate out of mempool (master...MarcoFalke-2015-feeRateRefactor) https://github.com/bitcoin/bitcoin/pull/7070
401 2015-11-20T16:12:44  *** zookolaptop has quit IRC
402 2015-11-20T16:27:30  *** zooko` has joined #bitcoin-core-dev
403 2015-11-20T16:37:15  *** zooko`` has joined #bitcoin-core-dev
404 2015-11-20T16:38:43  *** zooko` has quit IRC
405 2015-11-20T16:53:53  *** dcousens has quit IRC
406 2015-11-20T17:04:55  *** zooko`` has quit IRC
407 2015-11-20T17:27:43  *** skyraider has joined #bitcoin-core-dev
408 2015-11-20T17:30:26  *** trippysalmon has joined #bitcoin-core-dev
409 2015-11-20T17:35:35  *** d_t has joined #bitcoin-core-dev
410 2015-11-20T17:41:07  *** JackH has quit IRC
411 2015-11-20T18:39:14  <phantomcircuit> jgarzik, in CDB::Close activeTxn is closed if it's open, this is legacy code from satoshi, but your'e the last to have touched it
412 2015-11-20T18:39:18  <phantomcircuit> any idea why that's there?
413 2015-11-20T18:59:58  *** zooko` has joined #bitcoin-core-dev
414 2015-11-20T19:14:40  *** zooko` is now known as zookolaptop
415 2015-11-20T19:19:31  *** moli has quit IRC
416 2015-11-20T19:20:27  <jgarzik> phantomcircuit, speed IIRC.  We fiddled a lot with that during IBD tuning days.  IBD was very sensitive to when things were flushed
417 2015-11-20T19:20:37  <jgarzik> phantomcircuit, without special logic at close, shutdown would pause for a long time
418 2015-11-20T19:23:41  <phantomcircuit> jgarzik, i can see that support for nested transactions was dropped but i dont see what this has to do with flush logic
419 2015-11-20T19:24:29  <jgarzik> phantomcircuit, state mgmt -- during IBD you held the transaction open because you might get more blocks
420 2015-11-20T20:52:39  *** zookolaptop has quit IRC
421 2015-11-20T20:53:56  *** zookolaptop has joined #bitcoin-core-dev
422 2015-11-20T20:58:58  *** d_t has quit IRC
423 2015-11-20T20:59:48  *** d_t has joined #bitcoin-core-dev
424 2015-11-20T21:06:51  *** zookolaptop has quit IRC
425 2015-11-20T21:08:13  <phantomcircuit> jgarzik, hmm
426 2015-11-20T21:08:51  <jgarzik> phantomcircuit, since you might be in the middle of IBD during shutdown, you might have a transaction open on purpose
427 2015-11-20T21:09:09  <jgarzik> phantomcircuit, keeping the transaction open is poor man's write batching in the face of async "block" msgs
428 2015-11-20T21:09:25  <phantomcircuit> jgarzik, the wallet keeps a transaction open?
429 2015-11-20T21:09:35  <phantomcircuit> i can see leveldb doing that but why would the wallet need to do that
430 2015-11-20T21:09:35  <jgarzik> phantomcircuit, BDB transaction
431 2015-11-20T21:09:53  <phantomcircuit> ohhh it's from when we were using bdb for the chain state
432 2015-11-20T21:10:07  <jgarzik> phantomcircuit, nod -- I'm talking about logic put in place during the days when we stored chain state in there
433 2015-11-20T21:10:19  <phantomcircuit> ok so that can be safely changed to be an assert
434 2015-11-20T21:10:41  <jgarzik> phantomcircuit, wallet should never do that
435 2015-11-20T21:10:43  <jgarzik> indeed
436 2015-11-20T21:11:38  <phantomcircuit> jgarzik, great that will make a bunch of stuff much easier for me
437 2015-11-20T21:15:25  <GitHub82> [bitcoin] pstratem opened pull request #7071: Wallet: Replace TxnAbort with assert. (master...2015-11-20-wallet-activetxn) https://github.com/bitcoin/bitcoin/pull/7071
438 2015-11-20T21:19:01  *** trippysalmon has quit IRC
439 2015-11-20T21:55:20  *** zookolaptop has joined #bitcoin-core-dev
440 2015-11-20T21:58:49  <Luke-Jr> http://www.darlinghq.org/ maybe useful for running Mac test suite in Travis?
441 2015-11-20T22:05:06  *** treehug88 has quit IRC
442 2015-11-20T22:15:57  *** Guyver2 has quit IRC
443 2015-11-20T22:29:56  *** d_t has quit IRC
444 2015-11-20T22:30:06  *** d_t has joined #bitcoin-core-dev
445 2015-11-20T22:35:46  *** davec has quit IRC
446 2015-11-20T22:36:01  *** davec has joined #bitcoin-core-dev
447 2015-11-20T22:36:01  *** JackH has joined #bitcoin-core-dev
448 2015-11-20T22:48:49  *** PaulCape_ has quit IRC
449 2015-11-20T22:49:14  *** PaulCapestany has joined #bitcoin-core-dev
450 2015-11-20T22:49:35  *** zmanian_ has quit IRC
451 2015-11-20T22:50:28  *** btcdrak has quit IRC
452 2015-11-20T22:54:06  <midnightmagic> WOO 4.9% PROGRESS
453 2015-11-20T22:54:16  * midnightmagic stabs old crappy ppc
454 2015-11-20T22:54:31  <midnightmagic> I wonder if there's some assembly we could take advantage of on ppc..
455 2015-11-20T22:56:12  *** molly has joined #bitcoin-core-dev
456 2015-11-20T23:04:47  *** moli has joined #bitcoin-core-dev
457 2015-11-20T23:08:05  *** molly has quit IRC
458 2015-11-20T23:12:29  *** d_t_ has joined #bitcoin-core-dev
459 2015-11-20T23:14:55  *** d_t has quit IRC
460 2015-11-20T23:18:30  *** d_t_ has quit IRC
461 2015-11-20T23:20:18  *** molly has joined #bitcoin-core-dev
462 2015-11-20T23:24:04  *** zmanian_ has joined #bitcoin-core-dev
463 2015-11-20T23:24:20  *** moli has quit IRC
464 2015-11-20T23:26:35  *** btcdrak has joined #bitcoin-core-dev
465 2015-11-20T23:29:28  *** moli has joined #bitcoin-core-dev
466 2015-11-20T23:32:47  *** molly has quit IRC
467 2015-11-20T23:36:57  *** d_t has joined #bitcoin-core-dev
468 2015-11-20T23:38:04  *** guest234234 has joined #bitcoin-core-dev
469 2015-11-20T23:38:37  *** d_t_ has joined #bitcoin-core-dev
470 2015-11-20T23:41:53  *** d_t has quit IRC
471 2015-11-20T23:42:50  *** JackH has quit IRC
472 2015-11-20T23:48:37  <gmaxwell> anyone else notice the 2015-11-20 23:47:23 Invalid or missing banlist.dat; recreating
473 2015-11-20T23:48:41  <gmaxwell> at every start?
474 2015-11-20T23:48:51  <sipa> yup
475 2015-11-20T23:49:17  *** d_t_ has quit IRC
476 2015-11-20T23:50:01  *** d_t has joined #bitcoin-core-dev
477 2015-11-20T23:50:03  <jcorgan> yes