1 2014-11-12 00:01:11 <moa> yuck
  2 2014-11-12 00:03:34 <Luke-Jr> gmaxwell: curiously, XP isn't listed - because it's abandoned, or unaffected is unclear
  3 2014-11-12 00:18:04 <cfields> gmaxwell: i suppose i'm spoiled. I looked around for the patch to help understand the issue for ~5min before remembering where i was
  4 2014-11-12 00:18:39 <gmaxwell> cfields: hah. yea.
  5 2014-11-12 00:19:00 <Luke-Jr> XD
  6 2014-11-12 00:20:19 <cfields> sipa: did you notice any pattern/possible reason for your travis failure yesterday? Looked like there were a few random ones, but i don't see anything common between em
  7 2014-11-12 03:21:14 <sipa> gmaxwell: sure
  8 2014-11-12 04:15:41 <rgenito_> so in the world of Bitcoin... (RPC commands)... what is an "account"? for example, "bitcoind getaccount ..." ?
  9 2014-11-12 04:18:56 <rgenito_> nevermind, i found this: https://en.bitcoin.it/wiki/Accounts_explained
 10 2014-11-12 04:19:17 <rgenito_> accounts sound kind of stupid actually. or maybe the ambiguous name is an issue... maybe call it "groups" or "class"
 11 2014-11-12 04:19:25 <rgenito_> then again maybe it makes sense -.-
 12 2014-11-12 04:20:42 <Dizzle> Either way, I wouldn't rely on it for accounting for an app's users and such.
 13 2014-11-12 04:23:41 <rgenito_> Dizzle, it doesn't sound like a scalable idea, as the wiki mentions
 14 2014-11-12 04:33:23 <mrebola> Anyone know how to calculate the public bitcoin address from a Private Key in Hexadecimal Format ?
 15 2014-11-12 04:59:31 <rgenito_> mrebola, i believe the wiki has that actually
 16 2014-11-12 05:14:10 <Belxjander> it is on the wiki and the bitcoin-qt sources are on github along with other tools for the same
 17 2014-11-12 05:20:10 <mrebola> thanks rgenito_ and Belxjander
 18 2014-11-12 05:23:23 <rgenito_> np :)
 19 2014-11-12 07:41:35 <sipa> cfields: just saw one failure
 20 2014-11-12 07:58:05 <BlueMatt> sipa: I thought the point of undo data was to be useful without block data?
 21 2014-11-12 08:10:32 <sipa> BlueMatt: how so?
 22 2014-11-12 08:10:51 <sipa> you can fetch block data agin in theory
 23 2014-11-12 08:10:54 <BlueMatt> ie to be able to undo a block during a reorg without needing the block
 24 2014-11-12 08:11:21 <sipa> that would make undo data huge
 25 2014-11-12 08:11:47 <sipa> almost as large as the blocks themselves iirc
 26 2014-11-12 08:11:53 <BlueMatt> yes, roughly
 27 2014-11-12 08:11:58 <sipa> or like 1/2 of it
 28 2014-11-12 08:12:06 <sipa> now tjey're 1/10
 29 2014-11-12 08:13:30 <jonasschnelli> anyone willing to help compile Bitcoin-Qt 0.9.0 on OSX, ./configure runs through, but no Makefile is present
 30 2014-11-12 08:14:27 <sipa> did 0.9 even have autoconf already?
 31 2014-11-12 08:14:45 <jonasschnelli> sipa: yes. ./autogen and autoreconf -i was fine
 32 2014-11-12 08:15:47 <phantomcircuit> sipa, yes but did it work on os x? no idea
 33 2014-11-12 08:15:56 <phantomcircuit> jonasschnelli, ^
 34 2014-11-12 08:16:40 <jonasschnelli> hmm... wait. oops. I was suppose to use 0.9.3 instead 0.9.0 sorry for the noise.
 35 2014-11-12 08:29:35 <jonasschnelli> hmm... same issue on tag/v0.9.3
 36 2014-11-12 08:29:47 <jonasschnelli> ./configure doesn't produce a Makefile.
 37 2014-11-12 08:29:57 <jonasschnelli> Maybe someone finds time to check my config.log (https://pastebin.mozilla.org/7262250)
 38 2014-11-12 08:36:29 <phantomcircuit> jonasschnelli, you're missing bdb
 39 2014-11-12 08:37:36 <phantomcircuit> run configure again and post the last few lines
 40 2014-11-12 08:37:41 <jonasschnelli> phantomcircuit ... hmm... configuring without qt works... maybe it's because i change the PKG_CONFIG_PATH manually... thanks. let me check
 41 2014-11-12 08:39:24 <jonasschnelli> a following ./configure without arguments solved the problem. :) probably because of hackish PKG_CONFIG_PATH="xyz" ./configure style
 42 2014-11-12 10:29:22 <elichai2> why the bitcoin core stops me from making transactions with low fee?
 43 2014-11-12 10:29:46 <elichai2> I mean why not put a warning and let you click "proceed"
 44 2014-11-12 10:29:46 <sipa> to prevent creation of transactions that won't confirm
 45 2014-11-12 10:30:21 <sipa> the software deals very badly with transactions that don't confirm... just allowing it would likely result in many unusable walets
 46 2014-11-12 10:30:29 <sipa> you can still use the raw transaction api if you really need to
 47 2014-11-12 10:31:43 <elichai2> hmmm
 48 2014-11-12 10:31:51 <elichai2> BTW, thanks for the answer
 49 2014-11-12 10:31:56 <elichai2> (in issues)
 50 2014-11-12 10:32:29 <elichai2> maybe i'll change it in my fork of the client....
 51 2014-11-12 10:33:06 <sipa> 0.10 is likely going to reduce that minimum tx creation fee
 52 2014-11-12 10:33:14 <sipa> since the relay fee was decreased long enough ago
 53 2014-11-12 10:34:32 <elichai2> wait, they do implemented the 'smart fee', right?
 54 2014-11-12 10:36:06 <sipa> the 'minimum' fee is for getting it relayed
 55 2014-11-12 10:36:20 <sipa> the smart fee is about how fast you want to get it mined
 56 2014-11-12 10:36:37 <sipa> nodes ignore transactions with too low fee, so you definitely need to meet that bar
 57 2014-11-12 10:36:46 <sipa> when miners pick it up is a different thing
 58 2014-11-12 10:39:03 <elichai2> wait, miners ignore tx with less than 0.0001btc fee?
 59 2014-11-12 10:40:00 <sipa> when the previous version of the reference client was released, *everyone* ignored transactions with less than 10k satoshi per kilobyte in fee
 60 2014-11-12 10:40:27 <sipa> whether miners did or didn't wasn't relevant... your transaction simply wouldn't make it there
 61 2014-11-12 10:40:53 <sipa> that minimum relay fee was hardcoded, and reduced since
 62 2014-11-12 10:40:56 <nicknack> whats the status now sipa?
 63 2014-11-12 10:41:03 <elichai2> you right
 64 2014-11-12 10:41:19 <elichai2> CFeeRate minRelayTxFee = CFeeRate(1000);
 65 2014-11-12 10:41:19 <nicknack> ok
 66 2014-11-12 10:41:51 <elichai2>  /** Fees smaller than this (in satoshi) are considered zero fee (for relaying and mining) */
 67 2014-11-12 10:41:59 <gmaxwell> elichai2: nothing "ignores tx", fees below some threshold are treated as free transactions; to prevent nussance behaviors like paying 1e-8 btc more to just queue jump.
 68 2014-11-12 10:43:59 <elichai2> ok, I just didn't knew that. I'm working on anti-double-spend script. so maybe i'll add a function that checks that there is atleast 10K satoshi per KB
 69 2014-11-12 10:44:18 <sipa> anti-double-spend?
 70 2014-11-12 10:45:09 <elichai2> yep
 71 2014-11-12 10:45:21 <sipa> how?
 72 2014-11-12 10:45:28 <elichai2> script that checks whats the probability of a double spend on a specific transaction
 73 2014-11-12 10:45:40 <elichai2> the first check is for conflicts in the mempool
 74 2014-11-12 10:45:40 <sipa> how do you calculate that?
 75 2014-11-12 10:46:01 <sipa> if there are conflicts in the mempool, you don't have the transaction
 76 2014-11-12 10:46:02 <elichai2> and then i check of "Blaclisted" addresses (SatoshiDice etc)
 77 2014-11-12 10:46:06 <sipa> are you comparing multiple nodes?
 78 2014-11-12 10:46:19 <elichai2> what do you mean?
 79 2014-11-12 10:46:35 <sipa> if a transaction conflicts with your mempool, it won't be in your own mempool or blockchain
 80 2014-11-12 10:46:41 <elichai2> i want too
 81 2014-11-12 10:46:49 <elichai2> really?
 82 2014-11-12 10:46:52 <sipa> yes
 83 2014-11-12 10:47:00 <elichai2> so there is a way to ask for another nodes mempool?
 84 2014-11-12 10:47:04 <sipa> yes
 85 2014-11-12 10:47:12 <sipa> the mempool is always consistent with your blockchain and with itself
 86 2014-11-12 10:47:17 <elichai2> ammm in python-bitcoinlib?
 87 2014-11-12 10:47:17 <sipa> so it won't contain any conflicts
 88 2014-11-12 10:47:26 <sipa> don't know
 89 2014-11-12 10:47:35 <elichai2> ok, i'll look for it
 90 2014-11-12 10:47:39 <elichai2> thanks for that
 91 2014-11-12 10:48:01 <elichai2> another check I do if this tx contains forbidden OP_CODES
 92 2014-11-12 10:48:07 <elichai2> (like OP_RETURN)
 93 2014-11-12 10:48:12 <sipa> if it does, it won't be in your mempool
 94 2014-11-12 10:48:14 <elichai2> or contain bare-multisig address
 95 2014-11-12 10:48:18 <sipa> ok
 96 2014-11-12 10:48:34 <elichai2> no, i meant forbidden by only some pools
 97 2014-11-12 10:48:38 <sipa> ok
 98 2014-11-12 10:48:47 <elichai2> the Core dosen't forbid OP_RETURN
 99 2014-11-12 10:48:55 <sipa> indeed
100 2014-11-12 10:48:57 <elichai2> (for my knowledge atleast)
101 2014-11-12 10:49:18 <elichai2> ammm and i'll now add fees check
102 2014-11-12 10:49:29 <elichai2> and maybe i'll have more ideas
103 2014-11-12 10:49:41 <elichai2> (if you have any i'll be glad to hear :) )
104 2014-11-12 10:50:19 <stonecoldpat> ive been reading timedata.cpp and timedata.h to learn about network adjusted time, I was under the impression that the time stamp of the last 11 blocks had an effect on the network adjusted time, but I just can't find the code to support that idea - can someone point me in the right direction?
105 2014-11-12 10:50:55 <gmaxwell> stonecoldpat: it absolutely doesn't, dunno why you'd think it would.
106 2014-11-12 10:51:07 <petertodd> stonecoldpat: they don't; read the AcceptBlock() and similar code
107 2014-11-12 10:52:18 <elichai2> sipa: and first i use the bitcoinlib Transaction Check https://github.com/petertodd/python-bitcoinlib/blob/master/bitcoin/core/__init__.py#L589
108 2014-11-12 10:52:53 <elichai2> petertodd: python-bitcoinlib allows me to pull the mempool from a node? (not use my mempool)
109 2014-11-12 10:53:06 <elichai2> (I mean there is a function for that?)
110 2014-11-12 10:53:35 <petertodd> elichai2: from another node? there's the low-level neworking code, but it's missing a lot of parts required to make it easy
111 2014-11-12 10:54:00 <petertodd> elichai2: I'd suggest you look at the code here: https://github.com/icook/pynode2
112 2014-11-12 10:54:43 <elichai2> i'll have a look on his code. thanks
113 2014-11-12 11:10:30 <stonecoldpat> I didn't think it did (was trying to confirm it with code)- i read it in a reference somewhere last week (trying to re-find it now), thanks for confirming it though :)
114 2014-11-12 12:07:25 <petertodd> stonecoldpat: I really, really, strongly suggest everyone who wants to work with this stuff read the Bitcoin Core C++ codebase and get familiar with the consensus-critical code for validating blocks, transactions, and scripts
115 2014-11-12 12:08:38 <petertodd> stonecoldpat: the code is actually pretty readable and straight forward - getting all the edge cases 100% right is a nightmare of insanity, but the code is remarkably easy to understand at a basic level
116 2014-11-12 12:09:40 <nicknack> whats the story on bitsat?
117 2014-11-12 12:41:45 <stonecoldpat> petertodd: your 100% right.
118 2014-11-12 14:12:13 <mhanne> are there any test vectors for bip44?
119 2014-11-12 18:08:35 <heath> http://www.wallstreetandtech.com/trading-technology/is-fix-protocol-use-declining/a/d-id/1252798
120 2014-11-12 18:08:41 <heath> does anyone have an idea what this "Bit Protocol" is and where more information is located on the interwebs?
121 2014-11-12 18:08:48 <heath> he mentions it toward the end of the article
122 2014-11-12 18:19:21 <Luke-Jr> thoughts on using http://n.tkte.ch/ or something similar to restore bitcoin/bitcoin to #bitcoin-commits ?
123 2014-11-12 18:30:08 <cbeams> Luke-Jr: why not just use GitHub's own IRC notifications?
124 2014-11-12 18:31:01 <Luke-Jr> cbeams: because it connects a client for each time
125 2014-11-12 18:31:07 <Luke-Jr> so you get join/part spam
126 2014-11-12 18:31:20 <cbeams> Luke-Jr: there's an option to disable that
127 2014-11-12 18:32:49 <Luke-Jr> cbeams: is there? well, either way, it'd be a nice thing to fix :p
128 2014-11-12 18:33:32 <cbeams> Luke-Jr: yeah. it's easy to set up. we have it working nicely in #bitsquare.
129 2014-11-12 19:30:52 <dgenr8> justanotheruser
130 2014-11-12 19:31:03 <dgenr8> sorry, ignore
131 2014-11-12 19:59:36 <mappum> has this proposal made any headway? https://gist.github.com/gavinandresen/88be40c141bc67acb247
132 2014-11-12 20:38:36 <sipa> cfields: travis master fails?
133 2014-11-12 20:39:25 <sipa> seems just to stop at 10000 lines of debug output
134 2014-11-12 20:39:59 <jonasschnelli> any ideas why i get error while gitian-building the master branch? I tried a OS X build and the log says "atomic_pointer.h": fatal error: "atomic" file not found.
135 2014-11-12 20:40:35 <cfields> sipa: it's been weird for the last few days, i'm still trying to figure out what's happening
136 2014-11-12 20:41:31 <sipa> jonasschnelli: isn't atomic a c++11 thing?
137 2014-11-12 20:42:10 <cfields> that sounds like it's missing the bdb atomic patch
138 2014-11-12 20:42:16 <jonasschnelli> sipa i have no plan what "atomic" is. :)
139 2014-11-12 20:42:40 <cfields> oh no wait
140 2014-11-12 20:42:50 <cfields> that's likely caused by the new leveldb
141 2014-11-12 20:42:50 <jonasschnelli> something leads to port_posix.h
142 2014-11-12 20:43:53 <cfields> sipa: for some reason, win32 configure doesn't find qt, then continues to build, then ends up failing because it can't build/install bitcoin-qt...
143 2014-11-12 20:44:09 <cfields> sipa: i'll PR a change that explicitly turns it on in travis, so configure will fail if it's missing and we can see why
144 2014-11-12 20:49:10 <sinetek> sounds like a boost error.
145 2014-11-12 20:49:11 <sinetek> eh.
146 2014-11-12 20:51:24 <sipa> :p
147 2014-11-12 20:52:29 <cfields> the atomic thing is 99% due to the fact that leveldb now uses c++11 atomics if it can
148 2014-11-12 20:53:00 <cfields> there's something about your env that gets the switch turned on, but then it doesn't end up working
149 2014-11-12 20:53:01 <cfields> *99% likely
150 2014-11-12 20:53:41 <jonasschnelli> cfields, gitian building for osx: can i just build the three gitian-osx-* descriptors and move them to the inputs/ or do i have to build also the other deps?
151 2014-11-12 20:54:22 <cfields> jonasschnelli: no clue for osx. i didn't even realize it worked there
152 2014-11-12 20:54:37 <cfields> jonasschnelli: what's your reason for building master+gitian atm?
153 2014-11-12 20:55:27 <cfields> jonasschnelli: but in general yes, you need to build the deps first, in the correct order
154 2014-11-12 20:55:37 <jonasschnelli> fields no, i'm building in a debian VM after laanwj's doc/gitian-building.md
155 2014-11-12 20:56:26 <jonasschnelli> cfields: reason, i'd like to test some issues to see if there are differences between my local osx builds and the build coming out of gitian-build vm
156 2014-11-12 20:56:56 <jonasschnelli> cfields: (reason2: and also to come more into gitian)
157 2014-11-12 20:57:19 <cfields> jonasschnelli: the reason i ask is that the current gitian build process is about to be obsoleted by #4727
158 2014-11-12 20:59:02 <cfields> sipa: hard-coded test is running now on travis. I'll track down the problem and PR the fix asap
159 2014-11-12 21:02:59 <jonasschnelli> fields okay... let me read 4727. thanks
160 2014-11-12 22:10:00 <cfields> sipa: aha, got it. mingw's running out of mem and ICE'ing
161 2014-11-12 22:25:56 <phantomcircuit> can i scrub an unconfirmed transaction easily?
162 2014-11-12 23:21:31 <cfields> sipa: See #5268. If that builds successfully, please consider merging it with some priority, since it's likely to cause failures for other PRs in the meantime
163 2014-11-12 23:52:10 <BlueMatt> cfields: maybe already caused failure on https://github.com/bitcoin/bitcoin/pull/5267 ?
164 2014-11-12 23:53:01 <cfields> BlueMatt: it's possible, but definitely not the same failure
165 2014-11-12 23:53:14 <BlueMatt> ok...next question: how the hell does one debug that thing?
166 2014-11-12 23:53:52 <cfields> BlueMatt: that looks more like the busted comparison-tool before your last round of fixes
167 2014-11-12 23:54:11 <BlueMatt> passes locally :(
168 2014-11-12 23:54:32 <cfields> BlueMatt: bitcoind is dying while the tester is running...
169 2014-11-12 23:54:40 <BlueMatt> yes, segfault :(
170 2014-11-12 23:54:41 <cfields> BlueMatt: didn't you fix a race like that once before?
171 2014-11-12 23:54:53 <BlueMatt> a segfault in bitcoind caused by the tester?
172 2014-11-12 23:55:09 <cfields> ah no, i didn't see that it was a segfault
173 2014-11-12 23:55:22 <cfields> iirc last time it exited gracefully, no?
174 2014-11-12 23:55:42 <BlueMatt> last time what? last time there was a race in the block tester?
175 2014-11-12 23:55:58 <cfields> (not relevant, i realize)
176 2014-11-12 23:56:00 <cfields> ok, nm that