1 2015-07-14 02:12:39 <Diablo-D3> jgarzik, gmaxwell: btw, when one of you isnt busy, ban emma from #bitcoin
  2 2015-07-14 02:12:45 <Diablo-D3> yet another argumentative troll
  3 2015-07-14 02:14:18 <Diablo-D3> nm
  4 2015-07-14 02:14:24 <Diablo-D3> after being called out as a troll, he or she left
  5 2015-07-14 02:14:37 <Diablo-D3> its no fun when they leave =/
  6 2015-07-14 02:15:08 <gmaxwell> Diablo-D3: don't ask a question like that in here again.
  7 2015-07-14 02:16:06 <Diablo-D3> meh
  8 2015-07-14 04:56:39 <platinum4> Hey what does: "Transaction rejected by our node. Reason: Transaction was previously accepted but has been pruned rom our database." mean
  9 2015-07-14 04:58:10 <gmaxwell> platinum4: it means you're asking a bc.i question, see topic.
 10 2015-07-14 05:00:14 <platinum4> Ah ok thx, that same TX ID doesn't show up on blockr.io but it still is unconfirmed in wallet
 11 2015-07-14 08:14:13 <jonasschnelli> sipa: i have started a node (+PR 6410) with -maxmempool=20 but my mempool is around 200mb.
 12 2015-07-14 08:14:18 <jonasschnelli> http://bitcoin.jonasschnelli.ch/charts/mempool6410/
 13 2015-07-14 08:15:36 <jonasschnelli> with, it's PR6421
 14 2015-07-14 08:15:40 <jonasschnelli> s/with/wait
 15 2015-07-14 08:18:22 <jonasschnelli> and the mem usage for bitcoind constantly grow while the tx amount stick around ~3000
 16 2015-07-14 08:20:30 <jonasschnelli> sipa: sorry. The mempool is limited to 20MB. That perfectly fine. It's just strange that bitcoind requires more and more memory while keeping the mempool constant.
 17 2015-07-14 08:24:17 <wumpus> jonasschnelli: it's not one of the other caches (eg dbcache) growing?
 18 2015-07-14 08:24:49 <jonasschnelli> wumpus: it could be. i just log the "ps" mem size.
 19 2015-07-14 08:24:53 <wumpus> not all bitcoind's memory usage is mempool, you know :)
 20 2015-07-14 08:25:16 <jonasschnelli> wumpus: Yes. Totally. Could also be a always-been-behavior.
 21 2015-07-14 08:25:25 <wumpus> in the case of cache it should saturate at some point, though.
 22 2015-07-14 08:26:04 <jonasschnelli> wumpus: the chart is right now only a window of 12h. So yes. It might be okay.
 23 2015-07-14 08:26:14 <wumpus> if it keeps growing until crash it's obviously a (probably new) mem leak
 24 2015-07-14 08:27:03 <jonasschnelli> yeah. Lets wait a bit,.. but i guess this system has 32gb of ram.. so it might take a while..
 25 2015-07-14 08:29:42 <wumpus> as for dbcache it shows the size in UpdateTip entries: cache=231.0MiB(91167tx)
 26 2015-07-14 08:31:44 <wumpus> other data structures are not as precisely accounted for, yet (though there should be no more unbounded ones), it'd make sense to add that at some point
 27 2015-07-14 08:36:31 <jonasschnelli> wumpus: update tip says: "cache=0.8MiB(0tx)"
 28 2015-07-14 08:36:33 <jonasschnelli> ?
 29 2015-07-14 08:52:34 <wumpus> well that counts out the dbcache then.
 30 2015-07-14 08:53:41 <wumpus> dbcache usage is a sawtooth pattern, when it reaches the maximum value it is flushed and back to 0
 31 2015-07-14 11:27:37 <priidu> wouldn't it be a good idea to set "-spendzeroconfchange" to "0" by default?
 32 2015-07-14 11:27:44 <priidu> wouldn't that decrease the number of potential txns stuck in limbo?
 33 2015-07-14 11:31:16 <haakonn> spent zero-conf change won't confirm until its parent does
 34 2015-07-14 11:39:22 <priidu> haakonn: yes, but if you allow it to be used for another txn before it actually confirms, the chain of unconfirmed txn only grows?
 35 2015-07-14 11:40:10 <priidu> maybe i'm not just getting it correctly
 36 2015-07-14 11:40:20 <haakonn> are you talking about double-spending?
 37 2015-07-14 11:41:13 <haakonn> well yes, my point was that spending unconfirmed change only grows the chain of unconfirmed tx
 38 2015-07-14 11:41:42 <priidu> yes, hence wouldn't it be a good idea to set it to "0" by default?=
 39 2015-07-14 11:42:13 <haakonn> oh! i misread you, thought you meant enable it. you may have a point
 40 2015-07-14 11:42:46 <haakonn> i always disable it in my own wallet
 41 2015-07-14 11:42:53 <priidu> yup, same here
 42 2015-07-14 11:43:00 <wumpus> nah - if you want to disable it, just disable it; it's even an option in the UI. Changing around defaults is just confusing.
 43 2015-07-14 11:43:24 <priidu> wumpus: that's fine :p just something that popped into my head :p
 44 2015-07-14 11:44:12 <wumpus> (it can give some quite unexpected behavior from the viewpoint of the user, for example not being able to spend their entire balance)
 45 2015-07-14 11:44:27 <priidu> wumpus: yes, that is true I suppose
 46 2015-07-14 11:44:41 <priidu> the confusion would probably outweigh the benefits
 47 2015-07-14 11:44:56 <haakonn> i find that increasing my balance solves that issue
 48 2015-07-14 11:44:56 <wumpus> so it's better if it is changed consciously
 49 2015-07-14 13:47:01 <leakypat> petertodd: Fyi mycelium for iOS allows spending unconfirmed
 50 2015-07-14 13:48:15 <GAit> leakypat: I heard on reddit that android too.
 51 2015-07-14 13:49:08 <leakypat> GAit: cool, saved me digging out my android phone thx!
 52 2015-07-14 13:49:31 <GAit> leakypat: nw
 53 2015-07-14 15:16:58 <jgarzik> hrm, disappointing...   'sendfrom' has a 'minconf' function that does not guarantee minconf
 54 2015-07-14 15:17:10 <jgarzik> it checks for a balance with minconf
 55 2015-07-14 15:17:20 <jgarzik> then fails to pass minconf into coin selection
 56 2015-07-14 15:17:28 <jgarzik> resulting in use of unconfirmed inputs
 57 2015-07-14 15:17:52 <jgarzik> kinda surprised CCoinControl does not include minconf param
 58 2015-07-14 15:18:08 <sipa> heh
 59 2015-07-14 15:18:12 <sipa> that's surprising indeed
 60 2015-07-14 15:20:38 <wumpus> well, coin control is about manual selection - I think the GUI shows the number of confirmations for each selectable output
 61 2015-07-14 15:20:53 <wumpus> but a broken minconf parameter is kind of sad, surprised no one noticed before
 62 2015-07-14 15:20:59 <sipa> i guess it's historical
 63 2015-07-14 15:21:16 <sipa> we didn't have CCoinControl when sendfrom was created, so no way to pass that information down
 64 2015-07-14 15:21:22 <helo> would be helpful to alert users whenever estimatefee results change significantly (over time, or compared to last transaction sent, or ...), so a user will know to ensure their fee settings are adequate?
 65 2015-07-14 15:23:18 <jgarzik> wumpus, heh, indeed.  Probably no one noticed because a low volume wallet would fail to produce unconfirmed inputs, following a minconf=1 balance check.
 66 2015-07-14 15:23:36 <jgarzik> It's just a very poor approximation of actually passing that to coin selection.
 67 2015-07-14 15:26:25 <gmaxwell> jgarzik: yea, it adjusts the balance check. It makes more sense in the context of accounts.
 68 2015-07-14 15:26:43 <gmaxwell> jgarzik: I was aware of this, though it surprised me at some point a long time ago.
 69 2015-07-14 15:26:50 <gmaxwell> But I believe what it does is entirely intended.
 70 2015-07-14 15:27:01 <gmaxwell> Just useless(tm).
 71 2015-07-14 15:29:49 <jgarzik> It makes sense in the context of accounts
 72 2015-07-14 15:30:09 <jgarzik> at a minimum should pass that down to coin selection
 73 2015-07-14 15:34:36 <gmaxwell> For accounts it shouldn't but I'd agree with repurposing it for coin selection.
 74 2015-07-14 15:48:21 <jgarzik> gmaxwell, Yeah - I should have qualified my statement - accounts do not select coins - the "do not select coins less than N confirms" request should be passed down to the CreateTransaction() call stack in the wallet
 75 2015-07-14 15:49:52 <gmaxwell> yea, what send from is currently doing is not about coin selection. It's about "do not allow this transaction if there is insufficient (account) balance according to coins with at least N confirms" ... e.g. not about the risk of a single txn getting conflicted by about the risk that you'd potentially be left insolvent if it did.
 76 2015-07-14 15:50:38 <gmaxwell> which only makes sense in the anadvisable case where accounts being used as an exclusive multiuser accounting system.
 77 2015-07-14 15:50:38 <jgarzik> Yes I know that :)
 78 2015-07-14 15:51:04 <jgarzik> In the field it is illogical to pass 'minconf' and then have coins selected with less than 1 confirm though
 79 2015-07-14 15:51:14 <sipa> gmaxwell: the inadvisable and intended case :)
 80 2015-07-14 15:52:35 <gmaxwell> jgarzik: I think its the intended behavior still, crazy and useless as it is. :) (less than 1 would just be spending your own change)
 81 2015-07-14 15:53:12 <sipa> i think jgarzik is just complaining that it's counterintuitive
 82 2015-07-14 15:53:21 <sipa> which i agree with :)
 83 2015-07-14 15:53:26 <gmaxwell> I do too.
 84 2015-07-14 15:53:48 <jgarzik> The specific user complaint - which I agree with - is that sendfrom generated a transaction with unconfirmed inputs
 85 2015-07-14 15:54:05 <jgarzik> which, in turn, were taking a long time to confirm thanks to dust-asshole
 86 2015-07-14 15:54:18 <jgarzik> which was, sadly, an attempt to consolidate and remove dust
 87 2015-07-14 15:54:36 <gmaxwell> That shouldn't be possible, and if that is true then its a seperate bug.
 88 2015-07-14 15:55:24 <sipa> why not?
 89 2015-07-14 15:55:29 <gmaxwell> The only case where bitcoin core should spend a unconfirmed input is when (1) there is no other choice, send would fail otherwise, and (2) all the history of the unconfirmed coin is either a send-to-self or confirmed.
 90 2015-07-14 15:55:42 <sipa> uhu
 91 2015-07-14 15:55:53 <sipa> ah, you assume the dust can't be change?
 92 2015-07-14 15:56:15 <gmaxwell> perhaps I misparsed who the 'asshole' was in jgarzik's comment. :)
 93 2015-07-14 15:56:46 <gmaxwell> I understood the comment to be some jerk rained dust on the user and the user tried to consolidate the unconfirmed dust.  This shouldn't be possible without raw transactions.
 94 2015-07-14 15:56:59 <jgarzik> nod
 95 2015-07-14 15:57:00 <sipa> ah, yes, indeed
 96 2015-07-14 15:58:32 <gmaxwell> though I suppose a single raw consoidation transaction would result in a case where sendfrom would actually spend something that failed the above criteria. It would decicde it was from-me and then not notice there were unconfirmed inputs that weren't.
 97 2015-07-14 16:00:04 <gmaxwell> As far as counter intutive goes, I'm afraid that if change isn't given a bypass there will always be some counterintutive behavior (though it could be much better)
 98 2015-07-14 16:01:38 <gmaxwell> E.g. consider an account recieves 10 BTC payment, 10 confirms, then you spend 4 with minconf=5 .. all good. Change is generated. Then immediately you spend 4 with minconf 5 again.  The transaction failing would surprise most users (though at least it would be intutive to _us_, where the current behavior is probably intutive to no one :) )
 99 2015-07-14 16:13:32 <CodeShark> fungibility could use improvements...
100 2015-07-14 16:14:57 <CodeShark> other than denominated txouts I can't really think of much we can do, though
101 2015-07-14 16:17:38 <CodeShark> denominated txouts eat up more utxo up front...but can reduce change outputs later on
102 2015-07-14 16:18:27 <sipa> denominated txouts?
103 2015-07-14 16:18:51 <CodeShark> Yes...1 btc, 0.5 btc, 0.25 btc, etc...
104 2015-07-14 16:19:55 <CodeShark> using a set of fixed amounts for txouts rather than arbitrary values
105 2015-07-14 16:20:40 <sipa> how does that help fungibility?
106 2015-07-14 16:23:22 <CodeShark> it avoids locking up funds in change outputs, makes transaction sizes more predictable
107 2015-07-14 16:23:55 <CodeShark> also makes it easier to mix coins
108 2015-07-14 17:08:20 <cfields> wumpus: you'll be happy to know that i have a deterministic build for osx working outside of gitian
109 2015-07-14 17:08:33 <sipa> \o/
110 2015-07-14 17:08:34 <cfields> rather, a depends build that matches the gitian result
111 2015-07-14 17:08:47 <sipa> such awesome
112 2015-07-14 17:09:17 <cfields> linux/win will be much harder, but at least it points out where the problems are
113 2015-07-14 17:11:51 <cfields> opens up some interesting possibilities. Travis could potentially build matching releases even :)
114 2015-07-14 17:16:41 <cfields> sipa: atm, we don't use openssl's engine functionality at all do we? Other than maybe accidentally for keygen/passphrase in crypter?
115 2015-07-14 17:20:44 <sipa> cfields: 'engine' ?
116 2015-07-14 17:22:43 <cfields> sipa: runtime selectable implementations of some things. Provides for example hardware support for random/aes/sha/etc.
117 2015-07-14 17:22:52 <cfields> but I'll take your answer as a "no" :)
118 2015-07-14 17:25:50 <wumpus> cfields: great!
119 2015-07-14 17:29:00 <wumpus> no, we don't use any hardware support of anything in openssl, at least not willingly
120 2015-07-14 17:31:42 <cfields> ok, I'm going to explicitly drop engine support for the depends build then. Makes life easier for the deterministic build.
121 2015-07-14 18:09:11 <ajweiss> cfields: while trying to gitian build, i'm getting an error during the configure phase for qt claiming that it can't find opensslv.h... does this ring any bells?
122 2015-07-14 19:00:24 <sipa> heh, Q_EMIT / emit are just macros that expand to nothing
123 2015-07-14 19:00:32 <sipa> they're only for readability...
124 2015-07-14 19:05:10 <wumpus> sipa: heh - the qt preprocessor (moc) uses them
125 2015-07-14 19:05:11 <jonasschnelli> sipa: hah. Didn't knew that. So you are basically marking functions with Q_EMIT that they are used for signaling.
126 2015-07-14 19:05:24 <sipa> ah
127 2015-07-14 19:05:31 <jonasschnelli> ah... that could be. QT does some funny code parsing.
128 2015-07-14 19:06:20 <wumpus> didn't know they expand to nothing in the actual code, though
129 2015-07-14 19:06:33 <sipa> well what could it expand to?
130 2015-07-14 19:06:53 <sipa> how can <something> call(some_function(with,args)) be valid C++?
131 2015-07-14 19:07:28 <sipa> i guess it could expand to a prefix operator..
132 2015-07-14 19:07:30 <wumpus> "The following macros are our "extensions" to C++ They are used, strictly speaking, only by the moc."
133 2015-07-14 19:07:36 <wumpus> right.
134 2015-07-14 19:07:37 <jonasschnelli> isn't just a marco that forms <something> call(some_function(with,args))  into (call(some_function(with,args)))?
135 2015-07-14 19:07:49 <sipa> no
136 2015-07-14 19:08:07 <sipa> it would have to be <something>(call(some_function(with,args))) for that to work
137 2015-07-14 19:23:16 <sipa> morcos: do we have statistics about how many "zero fee" transactions are being confirmed?
138 2015-07-14 19:23:59 <morcos> one sec...
139 2015-07-14 19:24:09 <cfields> ajweiss: mm, vanilla 0.11 ?
140 2015-07-14 19:25:01 <ajweiss> cfields: yes.. but with -jX for parallelism... i'm rerunning completely vanilla now..
141 2015-07-14 19:25:42 <cfields> ajweiss: i use -j3 usually. I haven't run into that. Not sure what it'd be
142 2015-07-14 19:26:07 <ajweiss> cfields: ok, i'll dig around... just wanted to check to make sure i wasn't chasing my tail on a known issue...
143 2015-07-14 19:27:46 <cfields> not that i know of. We got lots of matches for 0.11, so i'd say it's likely something local
144 2015-07-14 19:27:58 <morcos> sipa: very roughly speaking..   i'd say about 6 transactions per block are still getting included because of priority and not fee.  most of those have 0 fee or at least less than minRelay
145 2015-07-14 19:28:04 <ajweiss> ok cool, thanks!
146 2015-07-14 19:34:11 <morcos> sipa: that number doesn't seem to have changed too much recently (in the last couple months)
147 2015-07-14 19:49:54 <maraoz> what is a good value for the new "-prune=N" option?
148 2015-07-14 19:56:58 <sipa> maraoz: if you can live with the downsides of pruning, the lowest allowed value is probably fine
149 2015-07-14 19:59:37 <maraoz> sipa: I'm just testing it. I used N=2048 for now
150 2015-07-14 20:00:41 <sipa> maraoz: what do you plan on doing with your node?
151 2015-07-14 20:01:01 <sipa> pruning in incompatible with relaying, wallets, or txindex
152 2015-07-14 20:01:37 <maraoz> sipa: development mainly. ah, I didn't know it was incompatible with relaying!
153 2015-07-14 20:02:22 <sipa> for now
154 2015-07-14 20:02:30 <sipa> hopefully fixed in 0.12
155 2015-07-14 20:03:13 <maraoz> sipa: good to know. thanks for the help!!
156 2015-07-14 20:21:09 <jonasschnelli> maraoz: your issue #6436 looks after a openssl QT bug?
157 2015-07-14 20:26:44 <maraoz> jonasschnelli: so, not bitcoin-core related?
158 2015-07-14 20:27:14 <jonasschnelli> maraoz: i think it is. But do you have the problem also when you don't use -prune?
159 2015-07-14 20:32:52 <cfields> mm, i think i know that one
160 2015-07-14 20:33:04 <cfields> that can happen if you don't call their setup function manually
161 2015-07-14 20:38:09 <jonasschnelli> cfields: it probably is related to the payment protocol?
162 2015-07-14 20:38:28 <cfields> jonasschnelli: yea, i'd guess there's a race to setup openssl properly. looking now
163 2015-07-14 20:38:42 <jonasschnelli> okay. cool.
164 2015-07-14 20:47:14 <cfields> looks like we should call OPENSSL_no_config first thing in bitcoin-qt
165 2015-07-14 20:47:45 <jonasschnelli> cfields: to avoid a conflict with cores OPENSSL config?
166 2015-07-14 20:48:13 <cfields> jonasschnelli: qt's
167 2015-07-14 20:50:36 <jonasschnelli> cfields: Ah. I see. But why there is no auto-fallback to OPENSSL_no_config in case of a non loadable config file?
168 2015-07-14 20:51:14 <cfields> jonasschnelli: hehe, look at the source...
169 2015-07-14 20:51:16 <cfields> (sec, i'll paste)
170 2015-07-14 20:52:25 <cfields> jonasschnelli: https://github.com/openssl/openssl/blob/master/crypto/conf/conf_sap.c
171 2015-07-14 20:53:02 <cfields> notice the exit(1). Ouch.
172 2015-07-14 20:53:31 <cfields> oh wait, that version doesn't have the exit. I guess they've fixed it up recently
173 2015-07-14 20:54:05 <jonasschnelli> Yeah. Was searching for the exit...
174 2015-07-14 20:54:06 <cfields> 1.0.1k calls exit if it fails
175 2015-07-14 20:54:12 <cfields> heh, sorry
176 2015-07-14 20:54:31 <jonasschnelli> cfields: https://github.com/openssl/openssl/blob/OpenSSL_1_0_0-stable/crypto/conf/conf_sap.c
177 2015-07-14 20:54:52 <jonasschnelli> Yeah. Was it's fixed now even in the 1.0.1 branch
178 2015-07-14 20:55:18 <cfields> https://github.com/openssl/openssl/commit/abdd677125f3a9e3082f8c5692203590fdb9b860
179 2015-07-14 20:55:59 <cfields> regardless, it looks like calling OPENSSL_no_config() at startup should be safe for all versions
180 2015-07-14 20:55:59 <jonasschnelli> But if we add a OPENSSL_no_config(), could this not have potential drawbacks?
181 2015-07-14 20:56:54 <cfields> see discussion from a few hours ago, we don't take advantage of any modules/engines
182 2015-07-14 20:57:39 <cfields> and afaik we handle cert management through other means
183 2015-07-14 20:58:12 <jonasschnelli> okay... sounds good.