1 2014-12-04 00:00:11 <kanzure> i would suggest using rpc instead of direct bindings into bitcoind
  2 2014-12-04 00:00:19 <dlax> thanks, I'll look into those locations first
  3 2014-12-04 00:03:29 <programmarchy> kanzure: my primary use case is creating and signing transactions
  4 2014-12-04 00:03:41 <sipa> then why do you need the blockchain...?
  5 2014-12-04 00:05:09 <programmarchy> i don't really need the blockchain. i'll just be using the ec and transaction modules. don't want to roll my own
  6 2014-12-04 02:51:50 <kryo_> any chance to decrease the variance of bitcoin block times
  7 2014-12-04 02:51:51 <kryo_> ?
  8 2014-12-04 02:52:43 <phantomcircuit> kryo_, no
  9 2014-12-04 02:52:55 <kryo_> :\
 10 2014-12-04 02:52:57 <gmaxwell> kryo_: No. The variance is important to the system. Without variance bitcoin is not convergent.
 11 2014-12-04 02:53:06 <kryo_> sometimes it goes up to 1h 30m though
 12 2014-12-04 02:53:23 <kryo_> what do you mean by convergent?
 13 2014-12-04 02:53:33 <gmaxwell> please head over to #bitcoin.
 14 2014-12-04 02:53:49 <kryo_> lol
 15 2014-12-04 02:54:28 <gmaxwell> kryo_: this channel isn't for bitcoin 101 talk, we'll be glad to talk about it there.
 16 2014-12-04 02:54:59 <kryo_> and you're the one that defines what constitutes "bitcoin 101"
 17 2014-12-04 02:55:10 <kryo_> great
 18 2014-12-04 02:55:13 <kryo_> love this place
 19 2014-12-04 02:55:15 <gmaxwell> oh jesus. come on.
 20 2014-12-04 08:12:39 <Enigmus> hey everyone, does anybody feel up to helping a bitcoin newb??
 21 2014-12-04 08:13:04 <Taek> What do you want help with?
 22 2014-12-04 08:13:46 <wumpus> unless that's bitcoin *development* new, better try #bitcoin
 23 2014-12-04 10:13:22 <BlueMatt> coryfields: cfields-away: ping
 24 2014-12-04 10:13:49 <BlueMatt> error: conflicting declaration of 'size_t strnlen(const char*, size_t)' with 'C' linkage
 25 2014-12-04 10:18:01 <paveljanik> rm config.h
 26 2014-12-04 10:18:12 <wumpus> yes,and rerun autoconf.sh
 27 2014-12-04 10:19:46 <Luke-Jr> Gentoo ebuild for 0.10 pre-discussion for interested parties: https://bugs.gentoo.org/show_bug.cgi?id=531634
 28 2014-12-04 10:23:12 <BlueMatt> oh, for some reason I missed that that also changed configure.ac...
 29 2014-12-04 12:40:51 <sipa> Luke-Jr: which of your secp256k1 commits are still relevant after #128 ?
 30 2014-12-04 12:42:23 <sipa> Luke-Jr: will x"$host_cpu" == x"x86_64" work on x32?
 31 2014-12-04 12:43:10 <Luke-Jr> sipa: I believe so, but $host_cpu is not guaranteed to have anything to do with the OS it seems
 32 2014-12-04 12:43:44 <sipa> the OS shouldn't matter anymore after #128 (we just try to compile a piece of x86_64 assembly code, and if it works, it works
 33 2014-12-04 12:44:06 <Luke-Jr> do we need $host_cpu at all then?
 34 2014-12-04 12:44:14 <sipa> not really :)
 35 2014-12-04 12:44:28 <sipa> but if there's a cheap possibly-too-wide check, why no
 36 2014-12-04 12:44:29 <sipa> t
 37 2014-12-04 12:45:25 <Luke-Jr> sipa: $host_cpu is basically the kernel's architecture, which is x86_64 for 32-bit, 64-bit, and x32 on x86_64 hardware
 38 2014-12-04 12:45:39 <Luke-Jr> sipa: unless you're on BSD, then it's amd64
 39 2014-12-04 12:45:42 <sipa> ha
 40 2014-12-04 12:45:50 <sipa> i'll just remove the check
 41 2014-12-04 12:47:35 <michagogo> Hm
 42 2014-12-04 12:48:19 <michagogo> Recent changes (libsecp256k1? among others?) have made autogen spit out a lot of warnings
 43 2014-12-04 12:48:27 <michagogo> About 55 lines of output
 44 2014-12-04 12:48:38 <michagogo> (it used to be <10 not too long ago, I think)
 45 2014-12-04 12:56:05 <sipa> Luke-Jr: can you try whether a default ./configure && make works on x32, after #128?
 46 2014-12-04 12:56:22 <Luke-Jr> sipa: I will need to install a x32 system, so maybe in a bit
 47 2014-12-04 12:56:30 <sipa> oh, no hurry in that case
 48 2014-12-04 12:56:52 <HM> I  know it's off topic but there's an Orion rocket launch soon on NASA TV. With any luck
 49 2014-12-04 12:56:53 <Luke-Jr> if no hurry, then I'd prefer to wait until RC1, and I can test the whole stack at once
 50 2014-12-04 12:56:59 <sipa> ok
 51 2014-12-04 15:13:40 <wumpus> travis is behaving strangely
 52 2014-12-04 15:14:34 <wumpus> it hangs on the windows builds again. Heh, Cory goes away for a few days... :-)
 53 2014-12-04 16:00:12 <sipa> Fetching native_ccache...
 54 2014-12-04 16:00:12 <sipa> wget: unable to resolve host address `bitcoincore.org'
 55 2014-12-04 16:00:12 <sipa> wget: unable to resolve host address `samba.org'
 56 2014-12-04 16:00:18 <sipa> wumpus: ever seen that?
 57 2014-12-04 16:00:26 <sipa> (trying to do a gitian build of master)
 58 2014-12-04 16:00:55 <sipa> just pinging those domains works fine
 59 2014-12-04 16:01:05 <wumpus> well the first time it fetches the source code for a few packages automatically
 60 2014-12-04 16:01:18 <wumpus> it first tries the original address, then a fallback address
 61 2014-12-04 16:01:22 <wumpus> both appear to fail
 62 2014-12-04 16:01:41 <wumpus> looks like somehow DNS doesn't work in the VM?
 63 2014-12-04 16:02:22 <wumpus> IIRC it's possible to fetch the sources locally so that the VM doesn't need network access
 64 2014-12-04 16:02:36 <sipa> i suppose the gitian vm just doesn't have network access
 65 2014-12-04 16:03:39 <wumpus> ie, 'make download' in depends, the copy the sources to ehh
 66 2014-12-04 16:03:50 <sipa> yes, the 'ehh' is the question :)
 67 2014-12-04 16:04:27 <wumpus> cache/common
 68 2014-12-04 16:04:43 <Luke-Jr> ugh, howto make Postfix proxy through SSH: http://codepad.org/H8dr05Io
 69 2014-12-04 16:05:01 <wumpus> (in the gitian directory)
 70 2014-12-04 16:07:04 <wumpus> Luke-Jr: that looks like an interposer lib that wraps connect?
 71 2014-12-04 16:07:18 <Luke-Jr> wumpus: yep
 72 2014-12-04 16:07:41 <Luke-Jr> totally leaky, so hopefully the process using it doesn't last too long <.<
 73 2014-12-04 16:08:09 <Luke-Jr> if it works, my bitcoin-development email should post as soon as my proxy server outlasts the greylist period
 74 2014-12-04 16:10:03 <wumpus> yeah, the non-leaky way would be to set a traffic redirect of the postfix user using iptables
 75 2014-12-04 16:10:40 <Luke-Jr> wumpus: well, I only want to redirect certain destinations :p
 76 2014-12-04 16:11:17 <wumpus> I'm sure that's possible with a combination of rules
 77 2014-12-04 16:11:31 <Luke-Jr> over SSH? :p
 78 2014-12-04 16:11:40 <wumpus> anyhow if the interposer works well enough why not, leaking is not an opsec failure here I suppose :)
 79 2014-12-04 16:12:20 <Luke-Jr> yeah, don't think it's worth spending more time on
 80 2014-12-04 16:12:49 <Luke-Jr> crazy postfix doesn't just have an option for something like this
 81 2014-12-04 16:16:58 <wumpus> it's probably not too common; I suspect that, like bitcoind's, the postfix developers don't want to turn their project into a kitchen sink monster
 82 2014-12-04 16:17:11 <wumpus> if you can handle it externally, handle it externally
 83 2014-12-04 16:22:22 <sipa> wumpus: but if i build the dependencies outside of github, they will likely not match the version that would be built inside gitian
 84 2014-12-04 16:22:36 <sipa> if they're linked statically, that means the binaries won't match either
 85 2014-12-04 16:22:42 <wumpus> sipa: don't *build* the dependencies out of gitian
 86 2014-12-04 16:22:53 <wumpus> sipa: I mentioned 'make download' to get the sources
 87 2014-12-04 16:22:57 <sipa> ah!
 88 2014-12-04 16:23:04 <wumpus> sipa: then copy from sources/* to cache/common
 89 2014-12-04 16:23:05 <sipa> of course
 90 2014-12-04 16:23:08 <sipa> got it
 91 2014-12-04 16:25:30 <sipa> gah, i forgot what a pain gitian was :)
 92 2014-12-04 16:25:39 <hearn> i feel your pain
 93 2014-12-04 16:25:41 <wumpus> it should be easy now
 94 2014-12-04 16:25:48 <hearn> though the docs are pretty great
 95 2014-12-04 16:26:06 <sipa> the gitiansomething.md is awesome
 96 2014-12-04 16:26:17 <sipa> but it's a bit outdated for master (since the depends system is in use)
 97 2014-12-04 16:26:44 <wumpus> at least there is no need to build the dependencies manually anymore
 98 2014-12-04 16:26:48 <wumpus> yes, Cory forgot to update that
 99 2014-12-04 16:28:22 <wumpus> conceptually if depends would include a c++ compiler and binutils (and whatever more is needed for a toolchain), we wouldn't need to build in a VM anymore
100 2014-12-04 16:30:03 <sipa> indeed!
101 2014-12-04 16:30:28 <sipa> clang-llvm-3.2
102 2014-12-04 16:30:31 <sipa> isn't that pretty old?
103 2014-12-04 16:30:49 <wumpus> that's the next step (we've sort of built our own copy of buildroot ;-)
104 2014-12-04 16:31:09 <wumpus> that sounds terribly old
105 2014-12-04 16:31:28 <wumpus> it's used for the macosx build
106 2014-12-04 16:31:33 <sipa> Luke-Jr: arrived
107 2014-12-04 16:38:15 <Luke-Jr> woo. seems to be unreliable on my end, but at least it retries XD
108 2014-12-04 16:54:32 <Luke-Jr> gavinandresen: payment protocol is nice, but I'm having trouble seeing how it could fit the use case I am targetting: anonymous recipients with unknown/potentially-unbounded number of future payments due
109 2014-12-04 16:55:34 <Luke-Jr> so there's no merchant or payee id, other than the recipient script(s) of the funds
110 2014-12-04 16:55:36 <gavinandresen> Luke-Jr: specific example of that use case?  What are you purchasing?
111 2014-12-04 16:55:50 <Luke-Jr> gavinandresen: I'm not purchasing anything, I'm paying a miner ;)
112 2014-12-04 16:56:39 <Luke-Jr> gavinandresen: right now, miners authenticate with a single address, and all payouts go to that address only
113 2014-12-04 16:56:50 <gavinandresen> Luke-Jr: the miner is submitting shares somehow… why can’t they just tell you the payout address then?
114 2014-12-04 16:57:03 <Luke-Jr> I want to avoid address reuse
115 2014-12-04 16:57:43 <gavinandresen> so have them authenticate with a recurring PaymentRequest instead of a bitcoin address
116 2014-12-04 16:58:16 <gavinandresen> you’ll end up reinventing the payment protocol if you go down the path of extending bitcoin addresses
117 2014-12-04 16:59:22 <Luke-Jr> gavinandresen: how does that work if they're just a user with no servers?
118 2014-12-04 16:59:25 <gavinandresen> (you’ll probably eventually want some kind of identity token, maybe tied to CHECKLOCKTIMEVERIFY locked funds….)
119 2014-12-04 17:00:24 <gavinandresen> Luke-Jr: I dunno, haven’t thought about it.  What would generate the P2SH token doo-hickey you proposed?  It’d just generate a PaymentRequest instead....
120 2014-12-04 17:01:21 <Luke-Jr> gavinandresen: don't have a very elegant idea for that either, admittedly - best way so far was to have the mining software get it from bitcoind directly
121 2014-12-04 17:02:47 <gavinandresen> Luke-Jr: mmm.  teaching the bitcoind wallet to spit out PaymentRequests would be pretty easy (except we want to get rid of wallet functionality, not add more)
122 2014-12-04 17:03:24 <Luke-Jr> s/bitcoind/wallet software/
123 2014-12-04 17:04:01 <Luke-Jr> gavinandresen: problem is even if bitcoind accepted a poll for the next scriptPubKey (which requires incoming connections), it's possible the wallet is not online at all when the payout is due
124 2014-12-04 17:07:49 <wumpus> you could pre-generate a couple of addresses, though it sounds like something better served with deterministic address generation with public derivation
125 2014-12-04 17:08:32 <Luke-Jr> wumpus: yeah, even if we knew how many addresses would be needed, pregenerating them all would have all the same problems as using a HD chain ;)
126 2014-12-04 17:09:50 <gavinandresen> Luke-Jr: well, whatever solution works for some pseudo-P2SH-HD bitcoin address should also work with a HD-extended PaymentRequest.
127 2014-12-04 17:10:55 <Luke-Jr> gavinandresen: oh, to be clear, I didn't mean necessarily making it an address format - just a binary format that could indeed be used in a PaymentRequest or similar
128 2014-12-04 17:11:58 <Luke-Jr> no reason it has to be an address at all, you're right
129 2014-12-04 17:12:24 <gavinandresen> Luke-Jr: if it is a PaymentRequest extension, then don’t invent another binary serialization format
130 2014-12-04 17:12:52 <gavinandresen> … just put the necessary information into binary or integer (or whatever) fields
131 2014-12-04 17:13:17 <Luke-Jr> that makes sense
132 2014-12-04 17:13:47 <Luke-Jr> repeated message { optional HDChain; optional LiteralData; } or something I guess
133 2014-12-04 17:18:30 <hearn> Luke-Jr: it'd be quite easy to knock together a little bitcoinj app that knows how to submit a series of payment requests via HTTP POST
134 2014-12-04 17:18:38 <hearn> with an HD [watching] wallet
135 2014-12-04 17:19:01 <hearn> of course it's more elegant to submit a single request that allows for infinite address extension
136 2014-12-04 17:19:11 <hearn> but, that requires some spec work
137 2014-12-04 17:19:32 <Luke-Jr> hearn: the former, without any identification of the payee?
138 2014-12-04 17:20:29 <hearn> well, depends what you mean by identification. unless getblocktemplate supports that, i guess you'd need some kind of username/password combo to link the payment request together with the mining activity?
139 2014-12-04 17:20:34 <hearn> 
ACTION doesn't know much about modern mining

140 2014-12-04 17:21:41 <Luke-Jr> hearn: modern mining has no password/secret
141 2014-12-04 17:21:45 <gmaxwell> What I think luke is trying to accomplish is this:  When you mine, you pass along payment information (today in the username). The server should be able to pay you many times without reusing addresses. You don't know at the time you connect how many times its going to pay you. You shouldn't need to have a server to get paid.
142 2014-12-04 17:22:00 <Luke-Jr> gmaxwell: right
143 2014-12-04 17:22:08 <hearn> yeah
144 2014-12-04 17:22:14 <hearn> that's what i thought.
145 2014-12-04 17:22:27 <hearn> i mean i guess you could serialize a payment request to base64 and use that as the username or something similar
146 2014-12-04 17:22:37 <hearn> in which case, sure, there'd be no identification stuff involved.
147 2014-12-04 17:22:51 <hearn> as the payment request would itself be the identity
148 2014-12-04 17:23:01 <gmaxwell> Protocols could change to send more information or what have you.   Also, the thing connecting is usually some embedded device with a web UI, not a wallet, so ideally the interface to that is somewhat compact too.
149 2014-12-04 17:24:32 <hearn> so yes. you'd spec an extension to BIP70 to let you embed an extended public key in the output message instead of a script. then you'd serialize that to text, and that'd become the username. then a specialised wallet would help users generate those text tokens. the user can then copy/paste it into their miner web ui
150 2014-12-04 17:24:46 <hearn> making these little specialised wallet apps is a lot easier than it used to be
151 2014-12-04 17:25:06 <dabura667> 687474703a2f2f7469702e6d652f6f6e63652f746545422d424b616538377143
152 2014-12-04 17:25:13 <sipa> wumpus: doesn't work; it still tries to fetch native_comparisontool from within gitian
153 2014-12-04 17:26:02 <wumpus> sipa: ok, don't know then - cory would probably know
154 2014-12-04 17:27:05 <hearn> technically i guess you could also use the xpubkey text serialization format for this instead of a serialized payment protocol request. but the latter is more general - who knows what other features might be wanted in future
155 2014-12-04 17:27:24 <hearn> and at some point it's all just a giant pile of binary pretending to be text, so the exact format doesn't seem that important from a usability pov
156 2014-12-04 17:27:35 <gmaxwell> yea, the limitation that prevents just using xpub stuff is the lack of multisig support mostly.
157 2014-12-04 17:28:22 <gmaxwell> hearn: the size matters though, but I don't know what the tradeoff surface is ... if the most basic case (single key non multisig) is too burdensom then people won't switch from the old way of doing things.
158 2014-12-04 17:28:41 <hearn> right.
159 2014-12-04 17:35:40 <Luke-Jr> maybe there's some way the wallet can "paymentrequest" from the mining software to configure it..
160 2014-12-04 17:35:49 <Luke-Jr> anyhow, gotta run, bbiab
161 2014-12-04 17:39:29 <phantomcircuit> Luke-Jr, this is a pretty good place for stealth addresses
162 2014-12-04 17:39:43 <phantomcircuit> but since that requires a non core client
163 2014-12-04 17:39:55 <phantomcircuit> i'd say just have them provide a long list
164 2014-12-04 17:40:14 <phantomcircuit> it's easy to do, obviously works, and is trivial to verify
165 2014-12-04 17:43:14 <hearn> Luke-Jr: so, the following program - http://pastebin.com/7HHV42he - prints a minimal pp request that contains a regular OP_CHECKMULTISIG output script. it produces:
166 2014-12-04 17:43:23 <hearn> Ik0SSRJHUiECpm1rIsOcaCf/CqL/YeqNXgcnQzb/+hfaawdi9u46xhEhAgoJfDU3M5mr++dfBG2gO5DiBiBVkVmLzjSLf26HEINeUq4YAA==
167 2014-12-04 17:43:28 <hearn> the final two == are unnecessary.
168 2014-12-04 17:43:50 <hearn> with a bit more data to indicate an expiry time, key range, etc, it'd be a bit longer
169 2014-12-04 17:43:52 <hearn> does that look tractable?
170 2014-12-04 17:45:33 <hearn> with just an address, it looks like this: Ih8SGxIZdqkUV2y5xhZoynIo4b0X3nJkl6j3ZWKIrBgA
171 2014-12-04 17:46:09 <hearn> not so bad actually. that might sound useless but it's not - the team that previous researched threshold secp256k1 has made a breakthrough and multi-sig no longer requires P2SH or OP_CHECKMULTISIG if you're willing to have a trusted dealer create the threshold key
172 2014-12-04 17:46:34 <hearn> and their new technique is HD compatible, too
173 2014-12-04 17:46:58 <hearn> anyway, no big deal either way.
174 2014-12-04 17:47:59 <average> hello
175 2014-12-04 17:48:07 <average> if I'm learning about bitcoin from the documentation
176 2014-12-04 17:48:13 <average> I mean developing for bitcoin api
177 2014-12-04 17:48:21 <average> what should I learn first ?
178 2014-12-04 17:48:29 <average> can I get like a small outline of what I should be focusing on ?
179 2014-12-04 17:49:09 <average> probably not.. it's near xmas and everyone's busy probably
180 2014-12-04 17:49:26 <wumpus> what do you mean with 'bitcoin api'?
181 2014-12-04 17:49:32 <average> wumpus: I don't know what I mean
182 2014-12-04 17:49:37 <average> because I've barely studied the documentation
183 2014-12-04 17:49:56 <average> I am trying to start reading it, but I thought I'd drop by here and ask first
184 2014-12-04 17:50:00 <wumpus> there is no one bitcoin API, you can use bitcoind with RPC, you can use bitcoinj, and there's various other libraries too
185 2014-12-04 17:50:28 <sipa> wumpus: when is cory back?
186 2014-12-04 17:50:35 <wumpus> sipa: next week
187 2014-12-04 17:50:38 <sipa> ah cool
188 2014-12-04 17:50:42 <sipa> we'll need him :)
189 2014-12-04 17:50:48 <average> sipa: i need beer
190 2014-12-04 17:50:49 <wumpus> yes, we certainly do
191 2014-12-04 17:51:04 <sipa> average: don't we all?
192 2014-12-04 17:51:11 <average> wumpus: so which of these apis is more popular ?
193 2014-12-04 17:51:22 <wumpus> average: I don't think popularity is a good measure here.
194 2014-12-04 17:51:38 <wumpus> what do you want to do?
195 2014-12-04 17:51:54 <average> sipa: yes, I suppose, except I buy the cheap 0.5gallon bottle ones
196 2014-12-04 17:52:16 <hearn> Luke-Jr: actually use this url: https://github.com/bitcoinj/bitcoinj/blob/master/examples/src/main/javascript/payprotocol.js
197 2014-12-04 17:52:22 <average> wumpus: I'd like to learn, I don't know what entry point I should start with in the documentation
198 2014-12-04 17:52:30 <average> wumpus: I don't know which api I should look at
199 2014-12-04 17:52:30 <gmaxwell> hearn: trusted dealer to create the keys and a multistep interactive protocol for signing. :( (meaning if you have an offlien wallet you must touch it twice)
200 2014-12-04 17:53:06 <hearn> gmaxwell: yeah but in practice a lot of multisig wallets will be online,  e.g. using a phone as second factor, TREZOR, etc.
201 2014-12-04 17:53:06 <sipa> average: well what do you want to do?
202 2014-12-04 17:53:12 <average> wumpus: I don't know what people usually develop with bitcoin. I kinda have a feeling that mostly there is some sort of automation going on, but I'm not sure to what extent or goal it is made..
203 2014-12-04 17:53:18 <hearn> gmaxwell: progress is good though!
204 2014-12-04 17:53:24 <gmaxwell> Yep yep.
205 2014-12-04 17:53:40 <average> sipa: I'd like to learn one of the bitcoin apis.. but I'm completely clueless about where to start, or what to try to achieve as a pet project
206 2014-12-04 17:53:47 <average> what's a good idea for a bitcoin pet project ?
207 2014-12-04 17:53:50 <sipa> average: that's a means and not a goal
208 2014-12-04 17:54:02 <average> sipa: yes...I agree.. unfortunately
209 2014-12-04 17:54:03 <gmaxwell> hearn: in libsecp256k1 there is a implementation of schnorr multisignature signing. Alas...
210 2014-12-04 17:54:09 <gmaxwell> (wel in a PR)
211 2014-12-04 17:54:12 <sipa> gmaxwell: not yet merged :)
212 2014-12-04 17:54:14 <sipa> right
213 2014-12-04 17:54:35 <hearn> average: http://whatcanidoforbitcoin.org/
214 2014-12-04 17:54:36 <sipa> average: it's pretty hard for us to tell you what to do, without any clue about what you want to can or aim to do
215 2014-12-04 17:54:41 <sipa> heh
216 2014-12-04 17:55:03 <hearn> average: that's not a joke, that website actually exists, is linked to from bitcoin.org, and pairs you up with projects after you answer a simple quiz :)
217 2014-12-04 17:55:14 <gmaxwell> I need to update that site. :) lots of stuff to add.
218 2014-12-04 17:55:40 <gmaxwell> That site is modeled after one for mozilla which has been surprisingly effective.
219 2014-12-04 17:57:43 <wumpus> average: IMO at this point it's better to get an idea how bitcoin works, say how transactions work, scripts work, how the crypto is used, etc than learning any specific API, as those will likely still change a lot over time
220 2014-12-04 17:58:16 <wumpus> average: of course it will follow that you need to use *some* api, but don't bet the farm on it
221 2014-12-04 18:01:26 <wumpus> average: the underlying concepts will be the same, see ie the developer guide here https://bitcoin.org/en/developer-documentation describes the concepts in general terms, then it doesn't make much difference what API you use, bitcoin is bitcoin
222 2014-12-04 18:03:13 <average> ok, thanks wumpus
223 2014-12-04 18:06:34 <shesek> hearn, how come only Hive and Brainwallet are listed under JavaScript? there are tons of other projects that could use help
224 2014-12-04 18:06:51 <hearn> shesek: i don't maintain that site. as gmaxwell said, it can use an update.
225 2014-12-04 18:07:15 <shesek> ah, right, I just saw that
226 2014-12-04 18:07:45 <shesek> well, we definitely wouldn't mind getting some help at cryptocoinjs
227 2014-12-04 18:08:18 <shesek> gmaxwell, is it up on github somewhere to send a pull request?
228 2014-12-04 18:08:38 <sipa> shesek: bitcoin/bitcoin.org
229 2014-12-04 18:09:29 <shesek> sipa, I was referring to whatcanidoforbitcoin.org
230 2014-12-04 18:09:44 <sipa> ah
231 2014-12-04 18:09:48 <sipa> no clue
232 2014-12-04 18:09:50 <shesek> but just noticed it has a link on the footer to https://github.com/andrewtian/asknot-bitcoin
233 2014-12-04 18:09:53 <hearn> yeah it is
234 2014-12-04 19:12:12 <gmaxwell> yea, it's asknot bitcoin
235 2014-12-04 19:49:18 <jonasschnelli> having problems building master on ubuntu 14.04... just freshly checkout out the master / autogen.sh / configure ends up in error: configure: error: no working bignum implementation found
236 2014-12-04 19:49:53 <sipa> jonasschnelli: either install gmp, or run with #5425
237 2014-12-04 20:04:46 <jonasschnelli> sipa thanks! i'll try
238 2014-12-04 20:17:37 <jonasschnelli> pulled #5425, compiled fine on ubuntu
239 2014-12-04 20:38:05 <Luke-Jr> hearn: xpub is explicitly not sufficient if I want multisig support too ;)
240 2014-12-04 20:38:41 <Luke-Jr> wait, I scrolled back too far XD
241 2014-12-04 20:38:52 <paveljanik> what does non-op(186) mean? https://www.biteasy.com/testnet/transactions/5dea81f9d9d2ea6d06ce23ff225d1e240392519017643f75c96fa2e4316d948a this transaction has output script 63bac0d0e0f0f1f2f3f3f4ff675168 ie. OP_IF and then 0xba. What happens with such non-op code?
242 2014-12-04 20:44:19 <phantomcircuit> paveljanik, they dont do anything
243 2014-12-04 20:45:14 <paveljanik> so they are like OP_NOP?
244 2014-12-04 20:51:38 <phantomcircuit> paveljanik, that actually looks like it's decoded incorrectly
245 2014-12-04 20:51:59 <phantomcircuit> 186 isn't a valid OP_NOP
246 2014-12-04 20:52:33 <phantomcircuit> i think that should fall through to the default in the switch statement and cause an error
247 2014-12-04 20:54:54 <paveljanik> so I can just ignore it?
248 2014-12-04 20:55:28 <paveljanik> it is not OP_NOP, it is decoded as NON_OP there.
249 2014-12-04 21:00:10 <kadoban> phantomcircuit: I thought those ones were okay in an unexecuted branch of an IF ? Which is what appears to be going on there.
250 2014-12-04 21:01:21 <kadoban> paveljanik: So, if I'm correct (I think I am), it behaves like OP_RESERVED. If that IF is executed, the transaction is invalid.
251 2014-12-04 21:01:53 <phantomcircuit> kadoban, ah you're right
252 2014-12-04 21:02:56 <phantomcircuit> there's something weird about that
253 2014-12-04 21:03:47 <phantomcircuit> i guess OP_IF always fail if the stack is empty
254 2014-12-04 21:04:11 <kadoban> I think it invalidates then, yeah.
255 2014-12-04 21:08:59 <paveljanik> looks like this is the case for <0xba, 0xfc>
256 2014-12-04 21:43:53 <michagogo> That script is decoded by Bitcoin Core to "OP_IF OP_UNKNOWN OP_UNKNOWN OP_UNKNOWN OP_UNKNOWN OP_UNKNOWN OP_UNKNOWN OP_UNKNOWN OP_UNKNOWN OP_UNKNOWN OP_UNKNOWN OP_INVALIDOPCODE OP_ELSE 1 OP_ENDIF"
257 2014-12-04 21:44:13 <michagogo> So the signature for that is just a false
258 2014-12-04 21:44:15 <phantomcircuit> michagogo, yup
259 2014-12-04 21:44:27 <phantomcircuit> invalid op codes but valid script because they never get executed
260 2014-12-04 21:44:28 <phantomcircuit> neat
261 2014-12-04 21:54:38 <AdrianG> interesting.
262 2014-12-04 21:55:39 <average> AdrianG: is it ?
263 2014-12-04 21:55:59 <AdrianG> to me it is
264 2014-12-04 21:56:17 <average> AdrianG: how are you btw
265 2014-12-04 21:56:36 <AdrianG> im ok, u?
266 2014-12-04 21:57:02 <average> keeping calm and writing code
267 2014-12-04 21:57:10 <AdrianG> cool.
268 2014-12-04 22:07:49 <AdrianG> why does bitcoin use secp256k1 instead of secp256r1 ?
269 2014-12-04 22:09:42 <Luke-Jr> AdrianG: because Satoshi wills it!
270 2014-12-04 22:10:07 <lechuga_> NIST = NSA
271 2014-12-04 22:10:22 <lechuga_> 
ACTION shines his hat (sort of)

272 2014-12-04 22:20:32 <average> lechuga_: do you mean that case where they intentionally had a weak elliptic curve which was proposed by the no-such-agency ?
273 2014-12-04 22:20:56 <average> i mean.. the no-such-agency proposed that NIST use the weak ECC..
274 2014-12-04 22:21:05 <average> at least that's what i understood from what i've read in the past..
275 2014-12-04 22:27:33 <lechuga_> average: from https://en.bitcoin.it/wiki/Secp256k1, "...Also, unlike the popular NIST curves, secp256k1's constants were selected in a predictable way, which significantly reduces the possibility that the curve's creator inserted any sort of backdoor into the curve."
276 2014-12-04 22:27:57 <StephenM347> Question on a part of the bitcoin mining code: http://bitcoin.stackexchange.com/questions/32878/why-does-the-bitcoin-mining-code-have-the-same-if-statement-twice?noredirect=1#comment38530_32878
277 2014-12-04 22:28:13 <lechuga_> but from an old bitcointalk thread it looks like hearn asked satoshi why: https://bitcointalk.org/index.php?topic=2699.msg37328#msg37328
278 2014-12-04 22:28:54 <lechuga_> no particular reason seems dubious but thats what we have
279 2014-12-04 22:29:33 <AdrianG> i see.
280 2014-12-04 22:29:45 <AdrianG> "no particular reason" lol sure.
281 2014-12-04 22:29:56 <waxwing> NSA has clearly backdoored 7.
282 2014-12-04 22:30:01 <waxwing> and 0
283 2014-12-04 22:30:27 <AdrianG> is this supposed to be a funny joke, waxwing
284 2014-12-04 22:30:45 <waxwing> well when you ask it like that, i hesitate to say yes
285 2014-12-04 22:33:57 <average> have you people ever been to an anticafe ?
286 2014-12-04 22:34:12 <AdrianG> whats that
287 2014-12-04 22:34:17 <average> AdrianG: exactly
288 2014-12-04 22:34:17 <lechuga_> no but this sounds OT
289 2014-12-04 22:34:27 <average> lechuga_: nobody was talking..
290 2014-12-04 22:34:48 <average> lechuga_: it's like saying "you crossed the street on the red light yet there were no cars passing"
291 2014-12-04 22:35:07 <AdrianG> you broke the law.
292 2014-12-04 22:35:21 <average> yes, don't pass go, don't collect 100 ..
293 2014-12-04 23:41:34 <eric___> What does "blockindex" : 216    refer to in the json output?
294 2014-12-04 23:41:44 <eric___> list in the output of bitcoind listsinceblock
295 2014-12-04 23:54:38 <harding> eric___: what number the transaction was in the block.  I don't know whether its indexed to 0 or 1.  (At a guess, 0 indexed.)
296 2014-12-04 23:55:11 <eric___> harding: ohhhhhh, thanks!
297 2014-12-04 23:55:17 <eric___> In hindsight, that was super obvious