1 2015-03-16 00:03:01 <koobs> Luke-Jr: eta for next point release of 0.10.0?
  2 2015-03-16 00:04:45 <Luke-Jr> koobs: afaik that's still in wumpus's management
  3 2015-03-16 00:04:52 <Luke-Jr> and no ETAs in general
  4 2015-03-16 00:05:16 <koobs> rog
  5 2015-03-16 00:06:35 <gmaxwell> koobs: why do you ask?
  6 2015-03-16 00:06:50 <koobs> gmaxwell: for all of the recent changes/build improvements
  7 2015-03-16 00:06:55 <koobs> assertion fails, etc
  8 2015-03-16 00:07:12 <koobs> can backport, just wondering re timelines
  9 2015-03-16 00:09:11 <skyzer> hey there
 10 2015-03-16 00:09:33 <skyzer> is there in bitcoin core call where i can see my latest transactions in reverse chronological order?
 11 2015-03-16 00:09:51 <Luke-Jr> skyzer: listtransactions; also this kind of question is really #bitcoin material
 12 2015-03-16 00:10:07 <skyzer> okay thanks
 13 2015-03-16 05:45:47 <wumpus> koobs: is whatever you're expecting to be in 0.10.1 already on the 0.10 branch
 14 2015-03-16 05:49:21 <wumpus> e.g. I wouldn't expect any  'build improvements' in  0.10.1, the point of minor releases is bugfixes
 15 2015-03-16 05:49:23 <koobs> wumpus: i believe the main pits were merged (pr's)
 16 2015-03-16 05:49:33 <koobs> s/pits/bits
 17 2015-03-16 05:50:19 <wumpus> to the 0.10 branch?
 18 2015-03-16 08:05:21 <bedeho> should DER signatures be presented/exchanged with some sort of basecheck encoding, or just hex encoding?
 19 2015-03-16 08:10:50 <sipa> bedeho: no
 20 2015-03-16 08:10:56 <sipa> usually just hex
 21 2015-03-16 08:11:08 <bedeho> thanks!
 22 2015-03-16 08:11:18 <sipa> a checksum doesn't help; if you modify a signature it should be invalid anyway :)
 23 2015-03-16 08:11:52 <bedeho> good point :D
 24 2015-03-16 09:55:04 <jonasschnelli> wumpus: needs GUI lable: https://github.com/bitcoin/bitcoin/pull/5891, https://github.com/bitcoin/bitcoin/pull/5893, https://github.com/bitcoin/bitcoin/pull/5896, https://github.com/bitcoin/bitcoin/pull/5898, https://github.com/bitcoin/bitcoin/pull/5905
 25 2015-03-16 09:55:08 <jonasschnelli> (sry to bother)
 26 2015-03-16 09:55:40 <sipa> on it
 27 2015-03-16 09:59:56 <sipa> done
 28 2015-03-16 10:00:59 <jonasschnelli> thanks sipa
 29 2015-03-16 10:08:03 <jonasschnelli> just tried to run a nightly gitian build on my ubuntu vm. Get segmentation fault when tring to run bitcoin-qt, bitcoind works fine. Is this because of the static qt-framework linking?
 30 2015-03-16 10:12:38 <wumpus> eh
 31 2015-03-16 10:12:46 <wumpus> where does it segfault?
 32 2015-03-16 10:17:47 <wumpus> can you give a gdb backtrace
 33 2015-03-16 10:18:26 <jonasschnelli> 0x0000555555a5238d in ?? ()
 34 2015-03-16 10:18:26 <jonasschnelli> [New Thread 0x7ffff4f3f700 (LWP 14859)]
 35 2015-03-16 10:18:26 <jonasschnelli> Program received signal SIGSEGV, Segmentation fault.
 36 2015-03-16 10:18:26 <jonasschnelli> sadly but there is not much:
 37 2015-03-16 10:18:26 <jonasschnelli> [Thread debugging using libthread_db enabled]
 38 2015-03-16 10:18:26 <jonasschnelli> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
 39 2015-03-16 10:18:59 <sipa> jonasschnelli: run in valgrind?
 40 2015-03-16 10:19:04 <wumpus> ok that looks very bad :(
 41 2015-03-16 10:19:20 <wumpus> as in gitian is producting completely junk executables
 42 2015-03-16 10:19:21 <sipa> stack smashed
 43 2015-03-16 10:19:23 <wumpus> I'll give it a try too
 44 2015-03-16 10:20:05 <wumpus> I'm not going to backport any of the gitian changes to 0.10.1
 45 2015-03-16 10:20:43 <jonasschnelli> here is the full build log if this helps: https://builds.jonasschnelli.ch/nightlybuilds/2015-03-16/build-linux.log
 46 2015-03-16 10:20:46 <wumpus> clearly needs some maturing first
 47 2015-03-16 10:21:36 <wumpus> are there any X-related errors before the crash?
 48 2015-03-16 10:21:43 <jonasschnelli> but could also be a local gitian problem on my site because i recently played around with it. But the fact that bitcoind is running smooth...
 49 2015-03-16 10:21:59 <sipa> jonasschnelli: does running in valgrind give anything useful?
 50 2015-03-16 10:22:11 <jonasschnelli> let me try...
 51 2015-03-16 10:22:26 <wumpus> I vaguely remember another report from someone that had a X11/xcb protocol conflict with the static executable
 52 2015-03-16 10:22:56 <jonasschnelli> Segmentation fault (core dumped)
 53 2015-03-16 10:22:56 <jonasschnelli> user@ubuntu:~/bitcoin$ /home/user/bitcoin-0.10.99/bin/bitcoin-qt --regtest
 54 2015-03-16 10:22:56 <jonasschnelli> wumpus, theres no errors before the crash:
 55 2015-03-16 10:23:01 <wumpus> ok
 56 2015-03-16 10:23:18 <wumpus> but that was when running bitcoin-qt on a very old distro
 57 2015-03-16 10:23:44 <jonasschnelli> the issues appears on my ubuntu 14.04 vm
 58 2015-03-16 10:24:47 <jonasschnelli> valgrind without args: https://gist.github.com/jonasschnelli/25364b571c3ef756af6a
 59 2015-03-16 10:25:02 <wumpus> I think one problem is that we link qt statically not, but not the backend X11 libraries - but I wouldn't expect this to give a problem on *newer* distros, those libraries are usually backward compatible
 60 2015-03-16 10:26:57 <wumpus> s/qt statically not/qt statically/
 61 2015-03-16 10:27:51 <wumpus> can you please pastebin the output of `elfread -a bitcoin-qt |grep NEEDED`
 62 2015-03-16 10:37:57 <jonasschnelli> wumpus, https://gist.github.com/jonasschnelli/f038dfc5e1b4cc2b6eb8
 63 2015-03-16 10:40:49 <wumpus> jonasschnelli: ok so my guess would be an API incompatibility in one of those libraries... to bad we can't see in the backtrace which one
 64 2015-03-16 10:41:33 <jonasschnelli> wumpus, would it be possible to enable dSYM over gitian and see the bt?
 65 2015-03-16 10:41:50 <wumpus> dSYM?
 66 2015-03-16 10:41:59 <wumpus> I have Ubuntu 14.04 as well, so if this goes as expected I'm going to see this as well
 67 2015-03-16 10:42:08 <jonasschnelli> debugging symboles
 68 2015-03-16 10:42:27 <wumpus> yes you can - removing the strip step likely already goes a long way
 69 2015-03-16 10:42:28 <jonasschnelli> s/symboles/symbols
 70 2015-03-16 10:43:07 <jonasschnelli> i assume i have to fiddle with the descriptor?
 71 2015-03-16 10:43:12 <wumpus> ofcourse
 72 2015-03-16 10:44:07 <jonasschnelli> okay... can try this tmr
 73 2015-03-16 10:47:20 <jcorgan> is there a site that tracks statistics of the utxo set? things like total number, statistical distribution of redeemable amounts, etc.?
 74 2015-03-16 10:49:26 <sipa> jcorgan: getutxosetinfo rpc :)
 75 2015-03-16 10:49:33 <sipa> or gettxoutsetinfo
 76 2015-03-16 10:51:19 <jcorgan> lol, thanks for that.  looking for tracking that snapshot over time; was being #lazyirc and hoping someone else had already done the work for me :)
 77 2015-03-16 11:01:36 <phantomcircuit> sipa, plz2kb "nickguest" from wizards
 78 2015-03-16 11:08:21 <wumpus> jcorgan: I had a node running that called it for every block for a while so I have getutxosetinfo for a subset of the block heights, unfortunately my node doing that died so it's not up to date, but may save some work if you intend to do the same :)
 79 2015-03-16 11:10:02 <wumpus> jonasschnelli: segfaulting here too
 80 2015-03-16 11:11:00 <wumpus> jonasschnelli: interestingly, only the 64-bit bitcoin-qt segfaults - the 32-bit one works
 81 2015-03-16 12:07:13 <wumpus> jonasschnelli: traceback http://hastebin.com/uvucobejit.txt
 82 2015-03-16 12:08:40 <wumpus> as expected an xcb related error
 83 2015-03-16 12:10:09 <wumpus> https://github.com/bitcoin/bitcoin/issues/5910
 84 2015-03-16 17:07:02 <jonasschnelli> wumpus: thanks for reporting. Is this something for cfields?
 85 2015-03-16 17:16:16 <wumpus> jonasschnelli: he may have an idea
 86 2015-03-16 17:16:46 <wumpus> I'm fairly sure we need to either downgrade or upgrade the version of libxcb used in depends
 87 2015-03-16 17:17:00 <wumpus> probably the former, for compatibility
 88 2015-03-16 19:16:30 <morcos> i'm trying to working through the p2p send/recv logic.  is it possible to get in a situation where your pfrom->nSendSize > SendBufferSize , but thats also true with the corresponding peer, so neither of you are willing to drain your end?
 89 2015-03-16 19:21:59 <morcos> I think the new rpc test I created for autoprune sometimes triggers this condition.  Perhaps I'm abusing the level of p2p traffic I should be able to test in an rpc test, but it seems a bit concerning if such a deadlock is possible
 90 2015-03-16 19:33:58 <morcos> well nm, it seems like each side should keep draining their end and filling up vRecvMsg, so now I'm back to no clue...
 91 2015-03-16 19:38:59 <morcos> ah ok, i found it i think, ReceiveFloodSize, set by -maxreceivebuffer    Thanks!
 92 2015-03-16 20:06:53 <cfields> wumpus: hmm, i've run into that before and worked through it. I believed it to be fixed
 93 2015-03-16 20:09:45 <gmaxwell> wumpus: well, now that we have invalidateblock / reconsider block, you can fill in your gaps without too much effort.
 94 2015-03-16 21:05:16 <BlueMatt> does anyone have any opinions on relative-to-my-inputs-OP_CLTV?
 95 2015-03-16 21:05:21 <BlueMatt> ie <N> RCLTV is equivalent to <N + height the input I'm spending is confirmed at> CLTV?
 96 2015-03-16 21:05:27 <BlueMatt> its useful in some contracts that take the form OP_IF everyone_signs OP_ELSE something_is_published_in_this_output (maybe just the fact that this output exists) <wait until N after this is published OP_ENDIF
 97 2015-03-16 21:08:18 <BlueMatt> maaku, petertodd might
 98 2015-03-16 21:22:41 <petertodd> BlueMatt: where did you write this up? I've got some options for that as well (one of them in the CLTV bip)
 99 2015-03-16 21:22:54 <petertodd> BlueMatt: (or is the above the only writeup?)
100 2015-03-16 21:23:11 <BlueMatt> not sure ive seen anyone write it up anywhere, no
101 2015-03-16 21:23:50 <petertodd> BlueMatt: if you could write that up for the mailing list that'd be great
102 2015-03-16 21:25:01 <petertodd> BlueMatt: keys thing to consider is reorg safety - in the BIP is a mention of the idea of a "check prevout mined height/time verify" opcode, but it'd have to fail the script if the txout hadn't had >=100 # of confirms at least to give the same reorg safety as we currently have
103 2015-03-16 21:49:35 <BlueMatt> petertodd: yea, thinking about a RCLTV I dont really see many of the usual reorg-safety corner cases rearing their head - the exception being that during a reorg where the prevout you're spending is part of the reorg, you'd have to re-run the script on the RCLTV script in the mempool
104 2015-03-16 21:57:14 <hearn> BlueMatt: OP_CLTV?
105 2015-03-16 21:57:48 <BlueMatt> hmm?
106 2015-03-16 21:58:12 <hearn> BlueMatt: was wondering about your comment earlier. what does that do?
107 2015-03-16 21:58:18 <hearn> the name is not highly descriptive :)
108 2015-03-16 21:58:32 <BlueMatt> relative-CLTV
109 2015-03-16 21:58:40 <BlueMatt> ie relative-to-the-input-I'm-spending
110 2015-03-16 22:00:41 <hearn> CLTV is the part that i find non descriptive
111 2015-03-16 22:00:54 <sipa> checklocktimeverify
112 2015-03-16 22:00:58 <hearn> ah right
113 2015-03-16 22:00:59 <hearn> thanks
114 2015-03-16 22:01:32 <hearn> BlueMatt: how do you decide if such a tx is allowed in the memory pool if the dependency isn't confirmed?
115 2015-03-16 22:01:53 <sipa> well it never is
116 2015-03-16 22:02:11 <sipa> assuming the relative number is 1 or 0
117 2015-03-16 22:02:12 <maaku> BlueMatt: http://www.reddit.com/r/Bitcoin/comments/2z2l91/time_to_lobby_bitcoins_core_devs_sf_bitcoin_devs/cpgc154
118 2015-03-16 22:02:21 <BlueMatt> hearn: if the relative number is 0, you're good, otherwise it never is
119 2015-03-16 22:02:31 <BlueMatt> sipa: no, because you assume they need to be confirm-able at the same height
120 2015-03-16 22:02:48 <sipa> BlueMatt: the mempool is evaluated as for the next block
121 2015-03-16 22:03:10 <BlueMatt> sipa: yes, I believe the question is what about the case where both txn are unconfirmed, ie the relative number must be 0
122 2015-03-16 22:03:22 <sipa> uh, yes
123 2015-03-16 22:03:34 <sipa> brainfart
124 2015-03-16 22:03:47 <BlueMatt> :)
125 2015-03-16 22:04:52 <BlueMatt> maaku: thanks
126 2015-03-16 22:05:00 <maaku> petertodd: with CMV/RCLTV there is no case where a reorg makes a transaction permanently invalid, although a deep reorg which hits the input may delay the child hitting the chain
127 2015-03-16 22:05:19 <maaku> s/input/parent/
128 2015-03-16 22:05:41 <BlueMatt> maaku: yes, but, more practically, for bitcoin core you have to have the semantics of "mempool can fit in next block", so there are cases where things need removed
129 2015-03-16 22:05:42 <sipa> well, reorgs do require reevaluation of the mempool
130 2015-03-16 22:05:57 <sipa> which is pretty annoying
131 2015-03-16 22:06:11 <sipa> of course, you could just make that a not-actually-invariant
132 2015-03-16 22:06:42 <BlueMatt> sipa: they do? All they require is re-checking locktime and checking coinbase spend depths?
133 2015-03-16 22:06:57 <BlueMatt> which are two very specific cases that could be special-cased so you dont have to check each tx
134 2015-03-16 22:07:01 <sipa> BlueMatt: i mean with a RCLTV
135 2015-03-16 22:07:13 <BlueMatt> yes
136 2015-03-16 22:07:29 <maaku> BlueMatt: btw I wouldn't call it relative cltv. i find that very confusing. what you're checking is the depth of the input
137 2015-03-16 22:07:46 <BlueMatt> (you technically /could/ have a set of transactions which called the opcode in question and then only reevaluate those, buttttt)
138 2015-03-16 22:08:10 <sipa> well if you aleady know cltv, its semantics are most succintly defined as relative cltv :)
139 2015-03-16 22:08:16 <sipa> if you don't, it's probably a weird leap
140 2015-03-16 22:08:46 <BlueMatt> maaku: well, you're checking the input is X deeper than the locktime
141 2015-03-16 22:08:57 <BlueMatt> so...not /entirely/ just checking the depth of the input
142 2015-03-16 22:08:58 <maaku> i find either check-maturity-verify or check-depth-verify more explanitory
143 2015-03-16 22:09:25 <hearn> BlueMatt: bitcoin doesn't currently require the mempool to fit entirely in the next block
144 2015-03-16 22:09:30 <sipa> indeed
145 2015-03-16 22:09:40 <BlueMatt> hearn: no, but it requires that it is all confirmable in the next block
146 2015-03-16 22:09:52 <sipa> but not all at once :)
147 2015-03-16 22:10:01 <BlueMatt> and no txn in the mempool would make the block invalid (assuming dependencies are also included)
148 2015-03-16 22:10:02 <BlueMatt> well, sure
149 2015-03-16 22:10:39 <sipa> yeah, that's true, but i'm not so convinced it's all required
150 2015-03-16 22:10:41 <BlueMatt> maaku: well check-lock-time-verify is checking the locktime is > X, so it makes sense to call it check-maturity-against-lock-time-verify
151 2015-03-16 22:11:07 <BlueMatt> sipa: sure, nothing would break if we removed that invariant (and a few asserts()), but...belt-and-suspenders.....
152 2015-03-16 22:11:18 <BlueMatt> at least afaik
153 2015-03-16 22:11:20 <sipa> the reason for those invariants now is mostly dos protection
154 2015-03-16 22:11:35 <sipa> if we move a more resource-availability-constrained mempool, not all of that is that necessary
155 2015-03-16 22:12:09 <sipa> as in: they could become more best-effort policies, but with a fallback to "they'll kicked out by OOM anyway" at some point
156 2015-03-16 22:12:37 <BlueMatt> true, but you end up with a ruleset similar to what we have (ie "this tx is locktime in a year, so memory cost * 1 year....fuck this, this is too expensive")
157 2015-03-16 22:12:51 <sipa> yes, sure
158 2015-03-16 22:13:08 <sipa> but if you have a mempool that used some scoring to decide what to evict if memory pressure was high
159 2015-03-16 22:13:14 <sipa> and it takes locktime into account...
160 2015-03-16 22:13:31 <moa1> like fees?
161 2015-03-16 22:13:47 <hearn> https://github.com/BitcoinAuthenticator/Subspace
162 2015-03-16 22:13:48 <hearn> oops
163 2015-03-16 22:13:50 <hearn> wrong window, sorry
164 2015-03-16 22:14:14 <BlueMatt> sipa: yesyes, sure
165 2015-03-16 22:14:33 <BlueMatt> still, the this-is-all-confirmable invariant is really nice from a belt-and-suspenders pov
166 2015-03-16 22:14:40 <BlueMatt> though the code complexity involved is...annoying
167 2015-03-16 22:14:40 <sipa> BlueMatt: agree
168 2015-03-16 22:23:25 <petertodd> BlueMatt: yeah, RCLTV doesn't; implementing RCLTV with a CHECK_PREVOUT_HEIGHT_VERIFY <delta height> ADD CHECKLOCKTIMEVERIFY does if the prevout-height opcode doesn't have a reorg-safety window where it fails. (e.g. needs cur-height - txout-height > 100 or the opcode fails)
169 2015-03-16 22:24:13 <BlueMatt> ahh, yes, the classic "push my height on the stack"-problem
170 2015-03-16 22:24:53 <petertodd> BlueMatt: yup, which I *am* totally fine with, if we force using that opcode to be possible only if the txout has been buried as deeply as the coinbase maturity threshold
171 2015-03-16 22:25:12 <petertodd> BlueMatt: reorg-safety is a fragile goal anyway frankly...
172 2015-03-16 22:27:39 <maaku> petertodd: but it can be achieved rather easily here
173 2015-03-16 22:27:55 <BlueMatt> its more of a "nice property to have" in that it simplifies some logic in a few places
174 2015-03-16 22:28:03 <BlueMatt> so, where possible, its nice to have it :)
175 2015-03-16 22:28:33 <BlueMatt> still, not unreasonable to have a "push-my-prevouts-height" if it requires "my-prevouts-height" be some large number
176 2015-03-16 22:28:51 <petertodd> maaku: I'm not sure it can be achieved easily - I'm not sure what kind of things people need a relative checklocktimeverify for yet. Doing it with an op-add will probably make things much easier for some more complex use-cases.
177 2015-03-16 22:29:30 <BlueMatt> petertodd: I ran up against it creating the confirmation window for sidechain validation, IIRC maaku ran up against it doing some trading stuff
178 2015-03-16 22:29:32 <sipa> OP_PUSH_HEIGHT 1000 OP_LESS
179 2015-03-16 22:29:33 <petertodd> maaku: like I keep saying, people need to actually implement some demos of CLTV before we can do a soft-fork of it or we won't get the semantics right
180 2015-03-16 22:29:45 <sipa> ^- self-destroying txout
181 2015-03-16 22:29:54 <maaku> petertodd: are we talking about different things? the construction BlueMatt and I are talking about are provably reorg safe. you can't invalidate a transaction except via double-spend
182 2015-03-16 22:30:06 <maaku> *durin a reorg
183 2015-03-16 22:30:23 <sipa> maaku: yes, petertodd is talking about simulating it using CHECK_PREVOUT_HEIGHT_VERIFY <delta height> ADD CHECKLOCKTIMEVERIFY
184 2015-03-16 22:30:26 <petertodd> maaku: I'm talking about how to achieve the *goal* of a relative checklocktimeverify - ie what people will use it for
185 2015-03-16 22:30:31 <BlueMatt> maaku: nooo, petertodd was just saying "well, you can make it more flexible if you throw reorg safety out the window"
186 2015-03-16 22:30:48 <maaku> ok well that's a terrible idea. don't conflate it. OP_HEIGHT is bonkers
187 2015-03-16 22:31:01 <petertodd> BlueMatt: exactly! and I won't know if that's worth it given No-One Is Writing CLTV Demos
188 2015-03-16 22:31:22 <petertodd> BlueMatt: so write some and we can have this discussion properly - what exactly do you want to use RCLTV for?
189 2015-03-16 22:31:30 <maaku> petertodd: fed peg
190 2015-03-16 22:31:41 <petertodd> maaku: so go and write that up with running code...
191 2015-03-16 22:31:53 <maaku> we have and it will be released soon
192 2015-03-16 22:32:34 <BlueMatt> huh? its not useful in bitcoin for the fedpeg, but it is useful in bitcoin for a sidechain-validation routine
193 2015-03-16 22:32:45 <petertodd> maaku: sigh... why are we constantly waiting for "in full" apps to be written, rather than short, easily understandable, demos?
194 2015-03-16 22:33:22 <sipa> don't expect a huge full app :p
195 2015-03-16 22:33:40 <petertodd> the review process works a lot better when people haven't put too much effort into their proposals, but are past the point of pure speculation on IRC
196 2015-03-16 22:33:41 <BlueMatt> as defined, sidechain validation needs a contest period (ie a time which an output must be spendable by a fraud/reorg proof before it is spendable by the user making the withdraw)
197 2015-03-16 22:33:50 <BlueMatt> so rcltv makes obvious sense there
198 2015-03-16 22:35:54 <petertodd> right
199 2015-03-16 22:38:34 <BlueMatt> (of course, as with everything bitcoin, it may make sense for the fraud/reorg proof to be replaced with an oracle
200 2015-03-16 22:38:52 <BlueMatt> so that use-case becomes rather generic
201 2015-03-16 22:39:11 <petertodd> ...and then you have the fidelity bonded ledgers I proposed two years ago... :)
202 2015-03-16 22:40:47 <BlueMatt> that is one example, sure
203 2015-03-16 22:57:22 <phantomcircuit> sipa, lold at self destroying outputs