1 2014-09-14 00:01:24 <Luke-Jr> I guess so
2 2014-09-14 00:02:39 <Luke-Jr> ironic it added a comment stating reasoning for NOT doing so, but oh well
3 2014-09-14 00:13:34 <arowseer> set password ggsnpdsn
4 2014-09-14 00:28:38 <sqlhelp> hi all
5 2014-09-14 00:29:01 <sqlhelp> im looking for someone skilled in sql
6 2014-09-14 00:31:11 <sipa> not here
7 2014-09-14 00:35:34 <sqlhelp> Anyone help me found a vuln link ?
8 2014-09-14 01:46:52 <jgarzik_> GAit, http://www.reddit.com/r/Bitcoin/comments/2gc4g5/where_is_the_bitcoin_version_of_lwnnet/
9 2014-09-14 01:51:12 <Luke-Jr> jgarzik: can I send you some testnet to send back plz?
10 2014-09-14 01:53:19 <jgarzik> Luke-Jr, sure, if you can wait 5 min or so for me to sync up
11 2014-09-14 01:54:15 <Luke-Jr> jgarzik: np
12 2014-09-14 02:09:54 <nullbyte> on tnet as well
13 2014-09-14 02:10:20 <nullbyte> i think if the developer with the right motivations came along, a btc ver of lwn would thrive
14 2014-09-14 02:10:40 <nullbyte> otherwise i see those bitcoin-focused news sites devolve linearly into ad-soup
15 2014-09-14 02:18:01 <Luke-Jr> jgarzik: sync'd? ;)
16 2014-09-14 02:29:19 <jgarzik> Luke-Jr, sync'd
17 2014-09-14 02:29:27 <jgarzik> Luke-Jr, sorry! baby alarm went off.
18 2014-09-14 02:30:00 <Luke-Jr> jgarzik: that's life ⺠address?
19 2014-09-14 02:30:03 <jgarzik> Luke-Jr, mtHxLYfRL5VEZ53XcqTbbL1UNoNqnz9FFb is a fresh testnet address for me
20 2014-09-14 02:30:32 <jgarzik> Luke-Jr, do you want me to return the exact same coins back to you, or just send you any old coins?
21 2014-09-14 02:30:50 <Luke-Jr> jgarzik: doesn't matter
22 2014-09-14 02:31:52 <jgarzik> Luke-Jr, address for you? any special requirements of your test, such as waiting for confirmations before sending coins to you?
23 2014-09-14 02:34:20 <Luke-Jr> jgarzik: nah, really just doing some basic testing of my 0.9.3 fork before I use it with my real wallets
24 2014-09-14 02:37:02 <Luke-Jr> jgarzik: mnwhfuDpqUZ1N1uxkkHhcVqZQFJpDefHp2
25 2014-09-14 02:37:02 <nullbyte> why didn't you just send coins to a wallet opened by 0.9.2?
26 2014-09-14 02:38:18 <Luke-Jr> nullbyte: I'm not sure what you're trying to ask there.
27 2014-09-14 02:39:04 <jgarzik> Luke-Jr, See incoming a0ee4cf6090691953ea5ee6eaaa0a1f513ada4e7fb7a80e3374ff27f1f64fa5c. Sent outgoing 6765b4525756cd2073c26192ced9d02f82e85ab6402bf180bea1d2dbc618976b.
28 2014-09-14 02:40:03 <Luke-Jr> jgarzik: thanks
29 2014-09-14 02:40:03 <nullbyte> well you apparently waited hours for that test, what's your fork contain that couldn't have been tested using stable/master?
30 2014-09-14 02:40:38 <nullbyte> maybe its not clear, i suppose it seems simpler to just start another testnet node than wait
31 2014-09-14 02:40:42 <Luke-Jr> nullbyte: testing stable or master would not be testing my fork, and would still have taken hours
32 2014-09-14 02:40:55 <Luke-Jr> no, it's simpler to wait - just takes patience :P
33 2014-09-14 02:41:09 <nullbyte> heh, if you say so :)
34 2014-09-14 02:41:36 <Luke-Jr> ACTION ponders if there's any simple way to send to an arbitrary script in BCCore yet
35 2014-09-14 02:42:07 <jgarzik> Luke-Jr, huh? P2SH...
36 2014-09-14 02:42:11 <nullbyte> define arbitrary? nonstandard?
37 2014-09-14 02:42:23 <nullbyte> arbitrary: *nonstandard
38 2014-09-14 02:42:37 <jgarzik> Luke-Jr, you can build a raw transaction sending to any hash, even one for a script that uses non-existent opcodes
39 2014-09-14 02:42:58 <sipa> that wouldn't be an arbitrary script
40 2014-09-14 02:43:08 <sipa> just a p2sh script with arbitrary redeemscript
41 2014-09-14 02:43:27 <Luke-Jr> right
42 2014-09-14 02:43:31 <nullbyte> hm
43 2014-09-14 02:43:50 <nullbyte> whats the point? i guess
44 2014-09-14 02:43:57 <jgarzik> <shrug> use bitcoin-tx
45 2014-09-14 02:44:02 <jgarzik> to build a raw transaction
46 2014-09-14 02:44:09 <Luke-Jr> to test my "automatically spend anything redeemable with OP_1" code :p
47 2014-09-14 02:44:25 <nullbyte> haha
48 2014-09-14 02:44:28 <jgarzik> If you meant putting an arbitrary script directly in the output... use bitcoin-tx
49 2014-09-14 02:44:51 <jgarzik> it will encode any sequence of opcodes and bytes
50 2014-09-14 02:46:08 <nullbyte> well, jgarzik, that wouldn't be simple ;)
51 2014-09-14 02:46:20 <nullbyte> 'simple'
52 2014-09-14 02:51:14 <jgarzik> Luke-Jr, ./bitcoin-tx -create in=6765b4525756cd2073c26192ced9d02f82e85ab6402bf180bea1d2dbc618976b:0 outscript=0.9995:1
53 2014-09-14 02:51:45 <jgarzik> "outscript" command takes a 'VALUE:SCRIPT' argument
54 2014-09-14 02:52:05 <jgarzik> the SCRIPT is the same as the test suite script parser. Input opcodes, sans OP_ prefix.
55 2014-09-14 02:52:20 <jgarzik> or hex for a raw push
56 2014-09-14 02:53:03 <Luke-Jr> jgarzik: space-delimited?
57 2014-09-14 02:55:06 <sipa> yes 'in=' and 'outscript=' are dd-style commands
58 2014-09-14 02:56:08 <jgarzik> Luke-Jr, yes, for both script and command line
59 2014-09-14 02:56:16 <jgarzik> Luke-Jr, see src/test/data/script*.json for examples
60 2014-09-14 02:56:41 <nullbyte> is bitcoin-tx new? i'm running 0.9.2
61 2014-09-14 02:57:20 <jgarzik> ./bitcoin-tx -create in=6765b4525756cd2073c26192ced9d02f82e85ab6402bf180bea1d2dbc618976b:0 "outscript=0.9995:HASH160 0x14 0xda1745e9b549bd0bfa1a569971c77eba30cd5a4b EQUAL"
62 2014-09-14 02:57:43 <jgarzik> nullbyte, yes
63 2014-09-14 02:58:00 <jgarzik> Luke-Jr, ^ example of a more familiar script"
64 2014-09-14 02:58:45 <nullbyte> hm, i guess i'll peek at the makefiles next time i pull tip
65 2014-09-14 02:59:00 <nullbyte> i'll have to*
66 2014-09-14 02:59:01 <sipa> nullbyte: will be in 0.10.0
67 2014-09-14 02:59:09 <nullbyte> damn
68 2014-09-14 02:59:17 <sipa> and it's in master
69 2014-09-14 02:59:43 <nullbyte> i must have missed the bump...
70 2014-09-14 02:59:58 <sipa> well 0.10 is not released
71 2014-09-14 03:00:10 <sipa> but master will become 0.10 at some point
72 2014-09-14 03:00:34 <nullbyte> ah right
73 2014-09-14 03:00:56 <nullbyte> makes sense
74 2014-09-14 03:02:05 <nullbyte> i suppose that's part of moving things out of bitcoind (?)
75 2014-09-14 03:02:27 <jgarzik> bitcoind and bitcoin-cli don't need to provide pure-function APIs for manipulating raw transactions
76 2014-09-14 03:02:43 <jgarzik> I want to move those to libraries with thin CLI wrappers
77 2014-09-14 03:03:27 <jgarzik> It was always silly to me that a client<->server round trip was required to createrawtransaction
78 2014-09-14 03:03:38 <sipa> +1
79 2014-09-14 03:05:30 <nullbyte> or you could just let userspace develop its own tools and slim core code
80 2014-09-14 03:05:50 <nullbyte> perhaps the start of an off-topic discussion, if so, disregard
81 2014-09-14 03:06:27 <jgarzik> Certainly true, and some other projects already have some CLI tools (notably genjix's toolkit)
82 2014-09-14 03:06:54 <sipa> well core code needs a way to sign transactions anyway
83 2014-09-14 03:07:13 <jgarzik> The general long term direction for our code is a library. You can build bitcoind and CLI tools from the same library.
84 2014-09-14 03:07:22 <jgarzik> well, many libraries.
85 2014-09-14 03:07:26 <sipa> reusing the same codebase to implement a lightweight external tool for stuff that needs no blockchain state
86 2014-09-14 03:07:56 <nullbyte> yeah well /src is going to look pretty bloated if you take everything in `bitcoind help` and turn it into its own tool
87 2014-09-14 03:08:14 <sipa> things will get to move to subdirs too
88 2014-09-14 03:08:40 <nullbyte> now thats what i call direction... ;)
89 2014-09-14 03:08:48 <jgarzik> nullbyte, nobody plans "everything"
90 2014-09-14 03:09:03 <sipa> for example, in master, most of the script code was moved to script/
91 2014-09-14 03:09:06 <jgarzik> as sipa said, some things do not require external chain state, and are useful on the command line
92 2014-09-14 03:09:13 <nullbyte> kidding, if we had more developers in this space, maybe thats feasible, but yea i agree, providing that is probably a good idea
93 2014-09-14 03:09:14 <jgarzik> Thus, we exercise... taste and judgement
94 2014-09-14 03:09:15 <jgarzik> ;p
95 2014-09-14 03:09:20 <nullbyte> hehe
96 2014-09-14 03:09:37 <nullbyte> +1 libbitcoin/obelisk
97 2014-09-14 03:09:56 <jgarzik> bitcoin-key and bitcoin-script are the only other tools I plan to work on
98 2014-09-14 03:10:24 <sipa> and bitcoin-rule-the-world
99 2014-09-14 03:10:36 <jgarzik> bitcoin-DWIM
100 2014-09-14 03:12:18 <nullbyte> bitcoin-key?
101 2014-09-14 03:12:48 <nullbyte> and here i thought docs would have been key...
102 2014-09-14 03:13:33 <jgarzik> HD derivations, generating the odd key on the command line, other misc stuff related to keys
103 2014-09-14 03:13:33 <nullbyte> i shouldn't pun probably
104 2014-09-14 03:13:53 <nullbyte> right, very good
105 2014-09-14 03:18:27 <Luke-Jr> jgarzik: so bitcoin-key will be a C++ rewrite of pycoin?
106 2014-09-14 03:22:08 <jgarzik> Luke-Jr, no
107 2014-09-14 03:26:15 <nullbyte> its strange to keep usertools in the same repository as the core node logic
108 2014-09-14 03:26:16 <moa> bitcoin-key bitcoin-script ... good idea
109 2014-09-14 03:27:15 <Luke-Jr> jgarzik: in what way different?
110 2014-09-14 03:27:27 <Luke-Jr> nullbyte: indeed, I think it ought to be moved out :p
111 2014-09-14 03:27:51 <nullbyte> simply since node operators probably dont care about them heh
112 2014-09-14 03:29:27 <nullbyte> there's the added benefit of lowering the barriers to entry for a starting point to working with bitcoin concepts too
113 2014-09-14 03:29:39 <nullbyte> er, concepts being
114 2014-09-14 03:29:43 <sqlinj> Hi all, im look for an experient with sql inject Pm me for more info. donating btc.
115 2014-09-14 03:29:45 <nullbyte> keys, scripts etc
116 2014-09-14 03:31:14 <nullbyte> actually it would be really useful for arsepipes who like to pump data onto the blockchain
117 2014-09-14 03:32:04 <nullbyte> good thing i dont associate with arsepipes
118 2014-09-14 03:33:09 <jgarzik> python tools to do that are already embedded within the blockchain :/
119 2014-09-14 03:34:09 <nullbyte> lol, kidding? that must have been expensive
120 2014-09-14 03:39:19 <jgarzik> python scripts are tiny compared to embedding wikileaks cables in the chain using said tools
121 2014-09-14 03:39:23 <nullbyte> it would only be a convenience, you're correct in stating its almost trivial to conjure up some tools using existng libs
122 2014-09-14 03:40:05 <nullbyte> i see why embedding data gets a bad rap...
123 2014-09-14 03:40:23 <jgarzik> some idiot wrote a filesystem using the blockchain as a backend
124 2014-09-14 03:40:29 <jgarzik> thankfully they got yelled at
125 2014-09-14 03:40:32 <nullbyte> that is really stupid
126 2014-09-14 03:42:34 <nullbyte> people shouldnt abuse the blockchain
127 2014-09-14 03:43:46 <nullbyte> did that other guy ever innovate a decentralized filesystem
128 2014-09-14 03:44:47 <nullbyte> i dont know
129 2014-09-14 03:44:53 <nullbyte> bitcoin is getting bigger, not smaller
130 2014-09-14 03:45:03 <nullbyte> more 'idiots' will try other crazy shit
131 2014-09-14 03:45:11 <nullbyte> kind of exciting to deal with it
132 2014-09-14 04:03:38 <Luke-Jr> odd
133 2014-09-14 04:03:57 <Luke-Jr> I've verified bitcoin-tx gave me a correct script, but signrawtransaction doesn't seem to want to sign it
134 2014-09-14 04:04:11 <Luke-Jr> just passing the hex as the only argument should be sufficient, right? :/
135 2014-09-14 04:16:02 <nullbyte> usually it spits an err
136 2014-09-14 04:17:49 <Luke-Jr> seems it's not finding the hash in mapKeys :|
137 2014-09-14 04:18:26 <nullbyte> nice
138 2014-09-14 04:18:43 <gmaxwell> Luke-Jr: are the inputs known, is the private key in the wallet, is it not multisig?
139 2014-09-14 04:20:35 <nullbyte> maybe just -rescan
140 2014-09-14 04:21:09 <Luke-Jr> aha, I was using the wrong inpoint index
141 2014-09-14 04:23:21 <gmaxwell> nullbyte: rescan should never fix anything. If it does something is seriously broken.
142 2014-09-14 04:25:50 <nullbyte> i think it depends, i cp'ed a wallet the other day and forgot to rescan, so all of my txs were failing to sign; there were no usable inputs
143 2014-09-14 04:26:44 <sipa> if it's a pretty old wallet file it is possible
144 2014-09-14 04:27:11 <Luke-Jr> jgarzik: bitcoin-tx errors "error: TX output missing separator" if I try to send to a null script :p
145 2014-09-14 04:27:48 <gmaxwell> nullbyte: bitcoin stores in the wallet the height that it was scanned upto, and auto rescans the missed portions.
146 2014-09-14 04:28:21 <gmaxwell> (plus a bit more to handle reorgs)
147 2014-09-14 04:28:51 <gmaxwell> though right, really old wallet formats didn't have the data.
148 2014-09-14 04:32:30 <Luke-Jr> I thought wallets lacking that data were rescanned entirely?
149 2014-09-14 04:32:33 <nullbyte> the wallet came from one fully-synced node and was dropped into another; my guess is the new node rescanned a few blocks and didn't find new inputs because AddToWallet hadn't been called for prior txs
150 2014-09-14 04:32:47 <sipa> that would be a major bug
151 2014-09-14 04:33:10 <nullbyte> in a roundabout way i guess i'm saying, the wallet tx data wasnt shared between the copies of the blockchain
152 2014-09-14 04:33:26 <gmaxwell> nullbyte: nothing about the blockchain is wallet specific.
153 2014-09-14 04:33:30 <sipa> the blockchain data is _completely_ independent of the wallet
154 2014-09-14 04:33:31 <nullbyte> i dont think i'm explaining it right
155 2014-09-14 04:33:38 <nullbyte> right
156 2014-09-14 04:33:57 <nullbyte> arent the inputs stored locally outside of the wallet file?
157 2014-09-14 04:34:00 <gmaxwell> All the transaction data that might be found is stored in the wallet.
158 2014-09-14 04:34:02 <gmaxwell> No.
159 2014-09-14 04:34:05 <nullbyte> wow well
160 2014-09-14 04:34:16 <nullbyte> i can try to reproduce it later
161 2014-09-14 04:34:24 <nullbyte> i think i remember what i was up to
162 2014-09-14 04:37:15 <gmaxwell> I'd be thankful. (This kind of thing has occasionally been claimed, though always also someone with an incorrect mental model of how it worked... and I've never been able to reproduce. It's possible that there is a bug, but I know sometimes people rescan because they didn't wait for it to sync at start, or the like... if there really is a problem we'd like to fix it and a reproduction seems necessary)
163 2014-09-14 04:41:21 <nullbyte> it seems like a tricky bug, i was in testnet, and fwiw i think it was generated in 0.9.x, and then loaded into tip as of a week ago
164 2014-09-14 04:41:59 <nullbyte> it meaning the wallet, i still have the file so if i can reproduce it i'll send it
165 2014-09-14 04:42:26 <nullbyte> sec
166 2014-09-14 04:43:00 <jgarzik> Luke-Jr, hum
167 2014-09-14 04:43:13 <jgarzik> Luke-Jr, I would be happy to support that... do we need null script support?
168 2014-09-14 04:43:54 <jgarzik> Luke-Jr, If you have a use case, file an issue and I'll fix it.
169 2014-09-14 04:46:07 <Luke-Jr> jgarzik: I don't have a real use case, just a cheap "anyone can spend"
170 2014-09-14 04:46:24 <Luke-Jr> so my only argument would be "It's valid!"
171 2014-09-14 04:51:26 <sipa> seems a valid enough reason to me
172 2014-09-14 04:51:27 <phantomcircuit> gmaxwell, i didn't notice that crypted keys generate the pubkey as a checksum before
173 2014-09-14 04:51:53 <phantomcircuit> that should have a hash just like "key" does
174 2014-09-14 04:58:45 <nullbyte> having daemon issues
175 2014-09-14 04:58:57 <nullbyte> few secs*
176 2014-09-14 05:04:49 <nullbyte> hm, i don't think i can reproduce it anymore, seeing utxos + able to generate proper inputs
177 2014-09-14 05:05:50 <nullbyte> apologies guys, now ive certainly lost my sanity
178 2014-09-14 05:06:21 <nullbyte> ill dig more though, see if i can turn something up
179 2014-09-14 05:10:48 <nullbyte> it'll take a few days, i clearly don't remember the steps taken
180 2014-09-14 05:26:16 <nullbyte> attempting a blowaway of testnet but not looking too promising, did anyone else mention any steps they took?
181 2014-09-14 05:31:16 <earlz> So, is it impossible to build a mac wallet without owning a mac?
182 2014-09-14 05:31:30 <Luke-Jr> earlz: no, master has gitian descriptors for it
183 2014-09-14 05:31:41 <earlz> I see that..
184 2014-09-14 05:31:53 <earlz> https://developer.apple.com/downloads/download.action?path=Developer_Tools/xcode_4.6.3/xcode4630916281a.dmg
185 2014-09-14 05:31:53 <earlz> Register and download the Apple SDK: (see OSX Readme for details)
186 2014-09-14 05:31:57 <earlz> Using a Mac, create a tarball for the 10.7 SDK and copy it to the inputs directory:
187 2014-09-14 05:32:01 <Luke-Jr> oh, that step
188 2014-09-14 05:32:03 <earlz> I don't have a mac :/
189 2014-09-14 05:32:14 <Luke-Jr> that's a somewhat-recent regression
190 2014-09-14 05:32:29 <Luke-Jr> Apple made their DMG not work with non-Apple extractors :/
191 2014-09-14 05:32:39 <earlz> fuck apple ugh
192 2014-09-14 05:32:50 <earlz> so, 7-zip or some such won't work?
193 2014-09-14 05:33:17 <Luke-Jr> and despite earlier Mac-gitian stuff working with redistributable files only, for some reason cfields thinks that's not possible anymore (I forget why)
194 2014-09-14 05:33:37 <cfields> hmm?
195 2014-09-14 05:33:43 <earlz> ugh
196 2014-09-14 05:33:54 <Luke-Jr> cfields: I forget why we need non-redistributable stuff
197 2014-09-14 05:34:07 <cfields> Luke-Jr: the osx sdk isn't redistributable
198 2014-09-14 05:34:12 <cfields> no way around that, unfortunately
199 2014-09-14 05:34:13 <Luke-Jr> cfields: the original work you did worked with redistributable portions of it
200 2014-09-14 05:34:27 <cfields> no, there are none. it's all behind a eula
201 2014-09-14 05:34:30 <Luke-Jr> which was inside a DMG that Linux could extract
202 2014-09-14 05:34:47 <cfields> 10.6 could be extracted deterministicly
203 2014-09-14 05:34:57 <earlz> ugh that's fugly
204 2014-09-14 05:35:03 <cfields> after that, they moved everything into xcode rather than a separate download
205 2014-09-14 05:35:13 <cfields> so you have to extract from there, and it's not deterministic
206 2014-09-14 05:35:14 <Luke-Jr> cfields: the bigger problem right now is that we can't extract it *at all*
207 2014-09-14 05:35:27 <Luke-Jr> (without having a Mac)
208 2014-09-14 05:35:37 <cfields> Luke-Jr: understood. the problem is that the tools can't cope with it (afaik)
209 2014-09-14 05:35:40 <earlz> ugh. I guess I'll skip mac for now then
210 2014-09-14 05:35:46 <Luke-Jr> Rright
211 2014-09-14 05:36:00 <cfields> it'd be great to fix those tools, but it hasn't been a priority for me yet
212 2014-09-14 05:36:05 <Luke-Jr> earlz: does 7zip normally do DMG? I don't know if I tried that
213 2014-09-14 05:36:09 <cfields> it's very possible that there's an existing too that i've missed, though
214 2014-09-14 05:36:19 <cfields> Luke-Jr: yes, i tried that. it doesn't work
215 2014-09-14 05:36:24 <Luke-Jr> :<
216 2014-09-14 05:36:29 <earlz> 7-zip is my go to extractor for everything on windows. I'm not aware of anything similar on linux though
217 2014-09-14 05:36:42 <earlz> when it's done downloading I'll see if it works
218 2014-09-14 05:36:54 <cfields> as well as self-bulds of cpio+xar. on linux, they're not compat
219 2014-09-14 05:37:01 <cfields> but i'd love to be proven wrong, that'd be great.
220 2014-09-14 05:37:24 <Luke-Jr> cfields: this is just for libs to link against, right?
221 2014-09-14 05:37:29 <cfields> Luke-Jr: i found a build of their cmdline-only toolchain that works and can be extracted
222 2014-09-14 05:37:42 <cfields> unfortunately, it doesn't include their libc
223 2014-09-14 05:38:02 <cfields> Luke-Jr: it's their frameworks. osx frameworks are a different beast
224 2014-09-14 05:38:15 <Luke-Jr> frameworks aren't just libs + pkg-config-equivalent? :|
225 2014-09-14 05:38:20 <cfields> they're like libs and headers rolled into one
226 2014-09-14 05:38:24 <Luke-Jr> bleh
227 2014-09-14 05:38:36 <Luke-Jr> actually
228 2014-09-14 05:38:42 <Luke-Jr> any reason we can't use the older frameworks?
229 2014-09-14 05:38:44 <cfields> it makes a ton of sense from an OS standpoint. just not really friendly towards existing tools
230 2014-09-14 05:38:57 <cfields> frameworks and toolchain are linked
231 2014-09-14 05:39:06 <Luke-Jr> :|
232 2014-09-14 05:39:22 <cfields> osx has a really weird notion of sdks
233 2014-09-14 05:39:36 <cfields> they're completely portable.. as long as you're using the version you're supposed to be
234 2014-09-14 05:39:43 <cfields> (translation: not at all portable)
235 2014-09-14 05:40:32 <cfields> which is why so many projects require a minimum version for building, regardless of the target
236 2014-09-14 05:40:52 <cfields> i have a branch that i've been working on that lifts those restrictions, we'll be able to target any version with any sdk...
237 2014-09-14 05:41:04 <cfields> but you'll still have to extract the sdk from osx :\
238 2014-09-14 05:41:35 <cfields> but again, that's just a tooling problem. the incompat problems can be fixed in 7zip/xar, and that won't be an issue anymore
239 2014-09-14 05:42:37 <cfields> sorry for the wall of text, but i think that sums up the full story :)
240 2014-09-14 05:42:49 <Luke-Jr> earlz: depending on your goals, you could perhaps borrow a Mac or get an illicit copy from someone else who did it
241 2014-09-14 05:44:55 <cfields> i heard a rumor there's there's a 10.7 sdk at github...
242 2014-09-14 05:45:10 <Luke-Jr> me too
243 2014-09-14 05:45:20 <Luke-Jr> who knows how long, or how trustworthy it is, though
244 2014-09-14 05:45:24 <earlz> lol
245 2014-09-14 05:45:36 <Luke-Jr> I even noticed there was a bitcointroll post linking it
246 2014-09-14 05:47:44 <cfields> well since it doesn't actually link to it, worst you'll get is busted symbols at load-time
247 2014-09-14 05:48:20 <Luke-Jr> cfields: unless the headers are dirty
248 2014-09-14 05:48:43 <cfields> Luke-Jr: a bunch of malicious inlines, i suppose
249 2014-09-14 05:49:41 <Luke-Jr> __attribute__((constructor)) is nasty too
250 2014-09-14 05:51:10 <Luke-Jr> cfields: travis is b0rked? :\
251 2014-09-14 05:51:45 <Luke-Jr> jgarzik: where do bitcoin-tx tests live?
252 2014-09-14 05:55:41 <Luke-Jr> nm found them
253 2014-09-14 05:59:30 <cfields> Luke-Jr: it is?
254 2014-09-14 05:59:46 <Luke-Jr> cfields: yes, it just failed my obviously-not-breaking-it PR
255 2014-09-14 06:00:09 <cfields> Luke-Jr: yea, see the log...
256 2014-09-14 06:00:22 <cfields> that's the same random false-negative we get on pull-tester now and then
257 2014-09-14 06:00:35 <Luke-Jr> I thought Travis was going to fix that <.<
258 2014-09-14 06:00:45 <cfields> i think we've pretty much decided to just ignore it since headers-first will require new tests
259 2014-09-14 06:00:53 <Luke-Jr> i c
260 2014-09-14 06:01:02 <Luke-Jr> at least it doesn't spam my emails every time :D
261 2014-09-14 06:01:06 <cfields> sec for link..
262 2014-09-14 06:01:20 <cfields> Luke-Jr: https://github.com/bitcoin/bitcoin/pull/4837
263 2014-09-14 06:02:17 <cfields> basically it's an issue with the comparison tool that isn't worth fixing
264 2014-09-14 06:02:31 <cfields> rather, isn't worth trying to find the cause-of
265 2014-09-14 06:03:12 <Luke-Jr> oh, *BitcoinJ* headers-first..?
266 2014-09-14 06:03:26 <Luke-Jr> cfields: would it be difficult to do 1 or 2 retries on failures?
267 2014-09-14 06:03:48 <cfields> dunno what BlueMatt has up his sleeve, he's been working on something
268 2014-09-14 06:03:59 <cfields> Luke-Jr: hmm, now that's a decent hackish idea...
269 2014-09-14 06:04:12 <sipa> Luke-Jr, cfields: don't confuse pulltester with comparison tool
270 2014-09-14 06:04:32 <sipa> the random failures are in comparison tool, which is run both by pulltester and travis
271 2014-09-14 06:04:45 <cfields> right
272 2014-09-14 06:04:51 <sipa> and headersfirst will be the current comparison tool unusable
273 2014-09-14 06:04:55 <sipa> *make
274 2014-09-14 06:05:55 <cfields> Luke-Jr: it's a total non-fix....
275 2014-09-14 06:05:57 <cfields> http://pastebin.com/raw.php?i=2J4ZyzMg
276 2014-09-14 06:06:03 <cfields> but that may be worth doing for now
277 2014-09-14 06:06:28 <Luke-Jr> heh, that's simple enough
278 2014-09-14 06:06:37 <Luke-Jr> assuming travis-retry fails at some point
279 2014-09-14 06:06:47 <cfields> yea, i think it tries 3x
280 2014-09-14 06:08:01 <BlueMatt> cfields: well the comparison tools have diverged in bitcoinj/the one used, so I'm merging them/supporting headers first on that
281 2014-09-14 06:08:01 <cfields> it's meant for trying network stuff which may fail once, we use it for apt-get, for ex
282 2014-09-14 06:08:09 <BlueMatt> cfields: its nothing special, but should make things work better
283 2014-09-14 06:08:15 <BlueMatt> also, no, you shouldnt retry
284 2014-09-14 06:08:29 <cfields> ?
285 2014-09-14 06:08:30 <Luke-Jr> O.o
286 2014-09-14 06:08:39 <BlueMatt> some of the tests are random and may fail based on the size of the key which is randomly on a border within a few bytes
287 2014-09-14 06:08:50 <BlueMatt> so sometimes retrying may hide an error
288 2014-09-14 06:09:03 <cfields> erm, why do tests use random data?
289 2014-09-14 06:09:10 <cfields> that's really nasty behavior for exactly this reason
290 2014-09-14 06:09:11 <BlueMatt> they generate keys...
291 2014-09-14 06:09:19 <Luke-Jr> BlueMatt: if the error is randomly not-detected, there is a bug in the tester
292 2014-09-14 06:09:32 <BlueMatt> its detected like 1/3 times or so, so....meh
293 2014-09-14 06:09:43 <BlueMatt> anyway, I'm too lazy to pregenerate keys and make sure they're on the border properly
294 2014-09-14 06:09:58 <Luke-Jr> x.x
295 2014-09-14 06:10:05 <BlueMatt> if y'all want to, I agree it would be better
296 2014-09-14 06:11:15 <cfields> tests need to pass/fail in a deterministic way, anything random is bad news
297 2014-09-14 06:11:37 <cfields> that means that random broken-ness can also pass
298 2014-09-14 06:11:44 <BlueMatt> random tests can certainly be useful in many cases, this is not neccessarily one of them
299 2014-09-14 06:12:08 <BlueMatt> in any case, I'm not /that/ concerned as such cases would be caught rather quickly
300 2014-09-14 06:13:09 <BlueMatt> also, if someone breaks one of those tests, hopefully the tests have been run on that branch 100 times before it gets merged...I mean who is gonna break pubkey parsing stuff without lots of review/testing?
301 2014-09-14 06:13:34 <Luke-Jr> anyhow, IMO, the testers are entirely useless if they always report a failure even when things are good; so missing a bug because of the tester being buggy is preferable over getting false-failures all the time
302 2014-09-14 06:14:01 <BlueMatt> probably
303 2014-09-14 06:14:13 <BlueMatt> as long as its caught soon before release
304 2014-09-14 06:16:00 <cfields> i'm not sure how generating a random key could ever be preferable
305 2014-09-14 06:16:14 <cfields> if a random key is generated that breaks the tests, add that to the list that's tested
306 2014-09-14 06:16:29 <BlueMatt> its not, feel free to fix it...patches welcome ;)
307 2014-09-14 06:17:11 <cfields> fair enough, but i was shot down when trying to update to mainline code suitable for patching against ;)
308 2014-09-14 06:18:22 <BlueMatt> hmm?
309 2014-09-14 06:18:38 <cfields> https://github.com/bitcoin/bitcoin/pull/4837
310 2014-09-14 06:19:20 <BlueMatt> I barely looked at that pull, you just updated the jar to bitcoinj's latest, no?
311 2014-09-14 06:19:41 <BlueMatt> bitcoinj latest appears to have quite a few tests missing that were never merged because I overlooked them
312 2014-09-14 06:20:06 <BlueMatt> plus headers-first needs to happen so I'm gonna pull those all in at once, or try to...having a time-constraint problem atm
313 2014-09-14 06:20:11 <cfields> i'm not sure how i can be helping here, then
314 2014-09-14 06:21:05 <BlueMatt> its my fault, sorry...I'm trying to get out from under some technical debt plus things dealing with work cropping up
315 2014-09-14 06:23:59 <cfields> not trying to assign blame, only to help. if it's a time constraint that's fine
316 2014-09-14 06:24:48 <cfields> but if there are short-term improvements that could be made until the real fixes go in, please let me know and i'll do what i can
317 2014-09-14 06:25:05 <BlueMatt> I mean do as required to make it work
318 2014-09-14 06:25:21 <BlueMatt> if #4837 is gonna remove the false negatives until I can get something in, go ahead and merge it
319 2014-09-14 06:25:23 <BlueMatt> I have no idea
320 2014-09-14 06:26:30 <cfields> well i don't either, ofc, it was only meant to bring us up to a point where we could beging debugging. sounds like there's till randomness involved, so it would likely still fail sometimes
321 2014-09-14 06:26:52 <BlueMatt> I dont think the key generation stuff could be the cause of thsoe failures
322 2014-09-14 06:26:52 <cfields> though.. it'd be worth logging what makes it fail, so that case can be isolated
323 2014-09-14 06:27:16 <BlueMatt> I dunno, that would certainly be duplicated effort if you're gonna start debugging from scratch
324 2014-09-14 06:27:50 <jgarzik> Luke-Jr, Thanks for the test. Just need to update Makefile.test.include EXTRA_DIST to fix pull tester, I think.
325 2014-09-14 06:27:59 <BlueMatt> if its a huge deal I can try to get it fixed sooner but not sure when I can get it finished up
326 2014-09-14 06:28:01 <BlueMatt> :(
327 2014-09-14 06:28:42 <Luke-Jr> jgarzik: pushed
328 2014-09-14 06:29:42 <cfields> BlueMatt: your call. I'm fairly ignorant on the subject, but i get the pings when builds fail. for now, i'll just continue to explain that false-negatives will happen from time-to-time
329 2014-09-14 06:29:55 <BlueMatt> yea, ok :(
330 2014-09-14 06:30:01 <Luke-Jr> ACTION votes travis-retry
331 2014-09-14 06:30:03 <cfields> BlueMatt: that wasn't me being passive-aggressive, just couldn't say it any other way :)
332 2014-09-14 06:30:30 <BlueMatt> cfields: didnt take it that way, I'm just pissed I havent been able to deal with all the technical debt Ive built up quickly enough
333 2014-09-14 06:30:33 <cfields> Luke-Jr: yea, i do too.
334 2014-09-14 06:30:37 <Luke-Jr> ACTION wonders if Travis's timer is in CPU time or real time.
335 2014-09-14 06:31:02 <cfields> BlueMatt: could you agree to that? if it's going to pass sometimes and not others, surely it's better for the pull-tester to retry if it fails the first time?
336 2014-09-14 06:31:40 <cfields> Luke-Jr: some crazy fantasy-world time
337 2014-09-14 06:31:47 <cfields> that's been my observation so far, anyway
338 2014-09-14 06:31:59 <Luke-Jr> cfields: not CPU time?
339 2014-09-14 06:32:08 <cfields> time seems to recalculate between steps
340 2014-09-14 06:32:16 <Luke-Jr> O.o
341 2014-09-14 06:32:30 <Luke-Jr> could be CPU time then.. that would seem idea
342 2014-09-14 06:32:32 <Luke-Jr> ideal*
343 2014-09-14 06:32:42 <cfields> for ex, build time may take 10 min. but if it was queued for 5 min before it started, the total build time was 15 min
344 2014-09-14 06:32:55 <cfields> then suddenly after build, it'll drop back down to 10 min again
345 2014-09-14 06:34:15 <cfields> i need to head to bed...
346 2014-09-14 06:34:26 <BlueMatt> cfields: hmm, I suppose for the time being its a reasonable bandaid
347 2014-09-14 06:34:41 <cfields> i think retrying is the most sane option for now, i'll pr it and see if BlueMatt disagrees too loudly
348 2014-09-14 06:34:45 <cfields> ok great
349 2014-09-14 06:34:57 <cfields> agreed it's nothing more than a hack, but seems the proper one for the moment
350 2014-09-14 06:35:37 <cfields> nnite
351 2014-09-14 06:35:44 <Luke-Jr> woo, Travis is happy
352 2014-09-14 06:38:05 <jgarzik> Luke-Jr, yep, looks good
353 2014-09-14 06:39:16 <jgarzik> Luke-Jr, BTW, if you were so inclined... more tests are welcome. Run "./bitcoin-tx" to get a list of all commands supported. The test suite is incomplete, and could always use additional "it works" tests, if nothing else.
354 2014-09-14 11:57:46 <dabura667> Hello all: If someone with a good understanding of BIP37 and how Bitcoinj and Breadwallet, for instance, use it to query the p2p network directly could help me out I would greatly appreciate it. I need to give an explanation of various developments in Bitcoin wallets from a technical perspective, but BIP37 confuses me...
355 2014-09-14 11:58:13 <dabura667> 1. How does it find peers?
356 2014-09-14 11:58:59 <dabura667> 2. What is the format of the query it sends to the peer? (I read the BIP, but I couldn't quite understand how that translated into data being sent)
357 2014-09-14 11:59:47 <dabura667> 3. What exactly does the peer send back to the client? (again, I read the format specs on the BIP, but didn't quite understand exactly what's being sent in laymans terms)
358 2014-09-14 12:00:21 <dabura667> Also, 4. What was the version number of QT that was first compatible with BIP 37?
359 2014-09-14 12:00:33 <dabura667> Again, thanks to anyone who can clear things up for me.
360 2014-09-14 13:23:32 <sipa> dabura667: do you understrand bloom filters? if not, first read the wikipedia article on it
361 2014-09-14 13:25:02 <sipa> dabura667: onna high level, the clients tells the servet "i'm really only interested in transactions that credit addresses X, Y, Z
362 2014-09-14 13:25:41 <sipa> dabura667: and then instead of asking for full transactions and blocks, the clients gets filtered transactions and blocks
363 2014-09-14 13:26:46 <dabura667> sipa: I read and understand the basic concept, but the implementation gets me confused in regards to bitcoinj and breadwallet...
364 2014-09-14 13:27:25 <sipa> can you be more specific?
365 2014-09-14 13:27:50 <sipa> i'm fine with answerimg specific questions, but the whole concept is a bit too complex to explain over irc
366 2014-09-14 13:28:39 <dabura667> Starting with #1 I am not sure how bitcoinj finds peers... does it just use the same method core does? Or does it implement some other method? And if so, what does that method entail on a high level?
367 2014-09-14 13:29:00 <dabura667> does it just find one random full node?
368 2014-09-14 13:29:03 <sipa> it uses the same method
369 2014-09-14 13:29:11 <sipa> it connects to a bunch of nodes
370 2014-09-14 13:30:00 <dabura667> Ok, then does it divie up the queries to each node or send the same query to each node.
371 2014-09-14 13:30:21 <sipa> bitcoin is a gossip network
372 2014-09-14 13:30:39 <sipa> that means each peer that kearns about something announcew that to all its peers
373 2014-09-14 13:30:59 <sipa> then they query the actual data from one (typically the first) that announced it
374 2014-09-14 13:31:06 <sipa> bip37 does not change that
375 2014-09-14 13:31:45 <sipa> except the server knows nkt to inform them about each and every transaction... they filter it and only announce what they believe we are ijnterested in
376 2014-09-14 13:33:22 <dabura667> ok. So the full nodes that support bloom filters receive a bloom filter query from the client and register the client while the client is connected... ie. ip address xxx.xxx.xxx.xxx (our client) only wants to know about things that meet the requirements of bloom filter xyz.
377 2014-09-14 13:33:36 <dabura667> Then upon disconnect the node forgets that bloom filter?
378 2014-09-14 13:33:41 <sipa> yes
379 2014-09-14 13:33:50 <dabura667> oh ok that makes much more sense.
380 2014-09-14 13:34:09 <dabura667> what about, for instance... past transaction lookup.
381 2014-09-14 13:34:32 <sipa> so there is a difference between transactions and blocks
382 2014-09-14 13:34:37 <dabura667> for instance, if I input a used BIP39 seed in breadwallet, and it has received txes from over 2 months ago... how does that work
383 2014-09-14 13:34:57 <sipa> it basically needs to start over
384 2014-09-14 13:35:02 <sipa> and fetch blocks again
385 2014-09-14 13:35:16 <dabura667> ok, that explains the long sync time
386 2014-09-14 13:35:25 <dabura667> is it just fetching headers?
387 2014-09-14 13:35:28 <dabura667> or whole blocks?
388 2014-09-14 13:35:33 <sipa> filtereed blocks
389 2014-09-14 13:35:47 <sipa> more than headers, but only the transactions in it thatnmatter
390 2014-09-14 13:35:53 <dabura667> ahhh i see... so are these blocks pruned of unrelated txes before being sent out?
391 2014-09-14 13:35:57 <sipa> yes
392 2014-09-14 13:36:22 <sipa> and replaced by merkle branches to prove that the ovcerall hash of the transactions is valid
393 2014-09-14 13:36:40 <dabura667> ok makes sense
394 2014-09-14 13:39:22 <dabura667> sipa: ok, I think I'm getting it now... so client side the only thing I really need to worry about is setting up the filter and broadcasting it to the peers I can find, and those peers will give me info as it comes in... ok
395 2014-09-14 13:39:35 <dabura667> What would be a use case for filteradd?
396 2014-09-14 13:40:00 <dabura667> adding new addresses to the wallet?
397 2014-09-14 13:41:29 <sipa> in something like a bip32/44 wallet, you probably have some lookahead number of addresses
398 2014-09-14 13:41:51 <sipa> if they get used quickly, you'll want to add new addresses on the fly
399 2014-09-14 13:42:05 <sipa> but this is really tricky actually
400 2014-09-14 13:42:15 <sipa> i'm not sure whether anyone uses it
401 2014-09-14 13:42:51 <dabura667> hmm, I see... adding addresses on the fly sounds tricky...
402 2014-09-14 13:43:18 <sipa> well you certainly want to add new addresses during sync
403 2014-09-14 13:43:30 <dabura667> Ok, so if I filterload the bloom filter on to the peers, will they just start sending me old blocks with related transactions? or do I need to query them?
404 2014-09-14 13:43:33 <sipa> but typically i guess that just happens by occasionally sending a new filter
405 2014-09-14 13:43:48 <sipa> peers never just send you blocks
406 2014-09-14 13:44:02 <sipa> they announce blocks, and you query them
407 2014-09-14 13:44:34 <dabura667> ok, so what command would I use to query the blocks related to a bloom filter x?
408 2014-09-14 13:44:43 <sipa> that's in the bip
409 2014-09-14 13:45:20 <sipa> iirc it's a getdata with invtype 3 instead of 1 or 2
410 2014-09-14 13:47:09 <dabura667> ok, thanks.
411 2014-09-14 13:48:08 <sipa> the bip does not cover everything about "how to write a light client"; it explains how, if you already have a client, make it light
412 2014-09-14 13:49:11 <dabura667> I gathered that it was written with a lot of prerequisite knowledge in mind, and without any code examples... so I was having a hard time. Thanks for the help.
413 2014-09-14 14:51:13 <jgarzik> hum
414 2014-09-14 14:51:19 <jgarzik> what is that script-as-lib pull req#?
415 2014-09-14 15:17:28 <sipa> jgarzik: it was closed temporarily
416 2014-09-14 15:17:45 <sipa> 4692
417 2014-09-14 15:30:32 <sipa> jgarzik: there have been some refactors since to make libbitcoinscript cleaner (including splitting up util, splitting up script, and making the sigcache optional)
418 2014-09-14 16:45:50 <chichov> are the transaction fees calculated per 1000 or 1024 bytes?
419 2014-09-14 17:06:01 <sipa> chichov: 1000
420 2014-09-14 17:08:18 <chichov> sipa: thank you
421 2014-09-14 21:15:47 <nullbyte> .
422 2014-09-14 22:44:25 <zwischenzug> say we have a script that reads the following:
423 2014-09-14 22:44:46 <zwischenzug> sig pk 1 1 OP_EQUALVERIFY OP_CHECKSIG
424 2014-09-14 22:45:22 <zwischenzug> when OP_EQUALVERIFY gets popped on the stack and evaluated, it returns true
425 2014-09-14 22:45:58 <zwischenzug> then is takes the stack, and runs OP_VERIFY
426 2014-09-14 22:46:18 <zwischenzug> so, sig pk OP_VERIFY
427 2014-09-14 22:46:52 <sipa> ?
428 2014-09-14 22:46:53 <zwischenzug> when in this process does the OP_CHECKSIG instruction get pushed on the stack?
429 2014-09-14 22:47:08 <sipa> instructions do not get pushed on the stack
430 2014-09-14 22:47:15 <sipa> they are just executed sequentially
431 2014-09-14 22:47:30 <zwischenzug> ok
432 2014-09-14 22:47:45 <zwischenzug> so, stack is [sig pk]
433 2014-09-14 22:48:01 <zwischenzug> instructions are [OP_VERIFY, OP_CHECKSIG]
434 2014-09-14 22:48:18 <nullbyte> its alarming because i've seen execution of opcodes been described as a stack almost everywhere i've read about bitcoin
435 2014-09-14 22:49:11 <zwischenzug> yea, that's kinda confusing
436 2014-09-14 22:49:21 <zwischenzug> but this makes way more sense though
437 2014-09-14 22:50:10 <zwischenzug> what exactly does OP_VERIFY do? is executes the rest of the intstructions sequentially, and if they return true txn is marked as valid?