1 2013-12-04 00:01:01 <cfields> it won't work as-is anyway for dependency resolution (it'll try to build twice) because ../leveldb != ../../leveldb
2 2013-12-04 00:15:44 <Luke-Jr> cfields: O.o? it seemed to work
3 2013-12-04 00:16:27 <cfields> Luke-Jr: you probably already had .a's in there
4 2013-12-04 00:16:39 <Luke-Jr> cfields: I removed the entire leveldb dir to make sure
5 2013-12-04 00:17:36 <Luke-Jr> cfields: how do I mount the dmg? :/
6 2013-12-04 00:17:49 <cfields> Luke-Jr: mount -o loop -t hfsplus
7 2013-12-04 00:18:02 <cfields> you'll need the hfs tools and modules ofc
8 2013-12-04 00:18:04 <gavinandresen> FYI: I've stopped the pull-tester VM (jenkins), it is be
9 2013-12-04 00:18:11 <Luke-Jr> cfields: doesn't like it..
10 2013-12-04 00:18:47 <Luke-Jr> [89797.026059] hfsplus: unable to find HFS+ superblock
11 2013-12-04 00:19:07 <cfields> Luke-Jr: iirc i didn't have much luck with it in linux either
12 2013-12-04 00:34:19 <Luke-Jr> wtf, Apple can't mount it either
13 2013-12-04 00:34:26 <Luke-Jr> calculated CRC32 $ABAF1392, expected CRC32 $60727D28
14 2013-12-04 00:37:00 <cfields> ?
15 2013-12-04 00:37:50 <Luke-Jr> cfields: apparently Apple gave me a bad file
16 2013-12-04 00:38:29 <cfields> heh, great. checksums aren't any help either, seems everyone's is different
17 2013-12-04 00:39:03 <Luke-Jr> O.o;;;
18 2013-12-04 00:39:07 <Luke-Jr> fingerprinted downloads?
19 2013-12-04 00:39:19 <rweichler> okay. i did bitcoind -reindex
20 2013-12-04 00:39:24 <rweichler> i had the entire blockchain downloaded
21 2013-12-04 00:39:28 <rweichler> and its been, like, an hour.
22 2013-12-04 00:39:30 <rweichler> what gives.
23 2013-12-04 00:39:45 <rweichler> is there a way to speed it up?
24 2013-12-04 00:40:00 <Luke-Jr> rweichler: faster CPU and/or HD
25 2013-12-04 00:40:34 <cfields> Luke-Jr: presumably your apple-id is in it
26 2013-12-04 00:41:08 <Luke-Jr> cfields: btw, could you ACK or otherwise post on the autoconf_pt3 PR a note that the stuff there is resolved?
27 2013-12-04 00:41:25 <cfields> Luke-Jr: sure, when it is :)
28 2013-12-04 00:41:36 <cfields> want me to push my fixups somewhere?
29 2013-12-04 00:41:36 <Luke-Jr> cfields: it isn't?
30 2013-12-04 00:42:06 <Luke-Jr> ?
31 2013-12-04 00:43:49 <cfields> Luke-Jr: my notes above.
32 2013-12-04 00:45:31 <cfields> give me a few min, i'll push something up
33 2013-12-04 00:45:41 <cfields> meanwhile, i got the dmg mounted in linux:
34 2013-12-04 00:46:25 <cfields> http://vu1tur.eu.org/tools/ . Grab and make dmg2img. My distro's wasn't new enough, needs to be 1.6.5.
35 2013-12-04 00:46:56 <cfields> once built: dmg2img xcode_3.2.6_and_ios_sdk_4.3.dmg -p 5 -o xcode_3.2.6_and_ios_sdk_4.3.final.dmg
36 2013-12-04 00:47:08 <cfields> then you can mount xcode_3.2.6_and_ios_sdk_4.3.final.dmg as expected
37 2013-12-04 00:55:27 <rweichler> Luke-Jr: Oh. Okay. I guess I shall wait.
38 2013-12-04 01:06:04 <Luke-Jr> cfields: opening partition 5 ⦠0.01%ERROR: Inflation failed
39 2013-12-04 01:06:39 <cfields> Luke-Jr: that's the one that complained about bad crc?
40 2013-12-04 01:06:42 <Luke-Jr> yes
41 2013-12-04 01:06:46 <Luke-Jr> well, that dmg
42 2013-12-04 01:06:53 <Luke-Jr> about 30 mins left on 2nd download
43 2013-12-04 01:06:55 <cfields> sounds like it's really bad, then :\
44 2013-12-04 01:07:51 <Luke-Jr> cfields: re "Else if the file is touched it'll build the internal one." - what file is touched?
45 2013-12-04 01:08:21 <Luke-Jr> that target should never be used, since there's no dependency on it
46 2013-12-04 01:08:24 <cfields> Luke-Jr: /usr/lib/libleveldb.so or whatever
47 2013-12-04 01:08:42 <Luke-Jr> cfields: I'm just using -lleveldb, which isn't a filename
48 2013-12-04 01:08:53 <Luke-Jr> so make ignores it
49 2013-12-04 01:10:17 <cfields> Luke-Jr: er, it won't ignore it. If anything, it just treats it special because it starts with a -
50 2013-12-04 01:11:05 <Luke-Jr> "a: b" gets ignored unless the target "a" is needed
51 2013-12-04 01:11:21 <Luke-Jr> and adding -lleveldb to LDADD does not create a dependency on target "-lleveldb"
52 2013-12-04 01:13:14 <cfields> hmm.
53 2013-12-04 01:15:53 <Luke-Jr> cfields: your suggestion won't hurt, so we can add it I guess - but it has no practical use I think
54 2013-12-04 01:17:29 <cfields> Luke-Jr: it seems you're correct, but i was assuming your LIBLEVELDB incorrectly, so i'm re-reading
55 2013-12-04 01:18:21 <Luke-Jr> cfields: here is what i was testing with: http://codepad.org/5BbGOIDj
56 2013-12-04 01:22:10 <cfields> Luke-Jr: ok
57 2013-12-04 01:23:26 <cfields> Luke-Jr: if you'll move the "$(LIBLEVELDB) $(LIBMEMENV):" rule up into the EMBEDDED_LEVELDB case so that there's not a crazy rule defined, i'll shattup
58 2013-12-04 01:24:33 <Luke-Jr> cfields: in both files?
59 2013-12-04 01:25:06 <warren> Luke-Jr: is anyone but you in favor of making external leveldb easy?
60 2013-12-04 01:25:07 <Luke-Jr> actually, I guess it's only variable'd in one
61 2013-12-04 01:25:18 <Luke-Jr> warren: that's not what we're discussing right now
62 2013-12-04 01:25:39 <cfields> Luke-Jr: ah crap, you can't move it up 'cause then you'll have rules defined before variables. need a new guard.
63 2013-12-04 01:26:58 <Luke-Jr> cfields: I wonder if I should just de-variable that rule?
64 2013-12-04 01:27:06 <cfields> eh, or not, i dunno. seems my brain is mush by now.
65 2013-12-04 01:27:38 <Luke-Jr> meh, a new guard is safe
66 2013-12-04 01:28:03 <Luke-Jr> done
67 2013-12-04 01:28:29 <cfields> as long as there's not a rule like "-libleveldb -libmemenv:", i'm happy
68 2013-12-04 01:30:37 <licnep> gmaxwell: pm
69 2013-12-04 01:33:01 <gavinandresen> pull-tester is happy again. Not sure why it burped.
70 2013-12-04 01:33:51 <cfields> gavinandresen: sorry for falling behind on pull-tester hacking. Have been distracted by shinier things.
71 2013-12-04 01:33:52 <Luke-Jr> gavinandresen++
72 2013-12-04 01:34:07 <Luke-Jr> a happy pull-tester is good to have
73 2013-12-04 01:34:53 <gavinandresen> cfields: no worries
74 2013-12-04 01:35:24 <Luke-Jr> also, +1 to whoever made it delete stale comments..
75 2013-12-04 01:36:17 <Luke-Jr> 5 mins left on new xcode download..
76 2013-12-04 01:37:36 <ekkis> gavinandresen: Scott's in Australia just now. if you have a little free time perhaps you guys could hook up.
77 2013-12-04 01:37:56 <gmaxwell> http://bitcoinity.org/markets < bitcoinity is 1mbtc units now.
78 2013-12-04 01:38:18 <gavinandresen> does "hook up" still mean something sexual?
79 2013-12-04 01:39:36 <cfields> only if you're not already down-under, i think
80 2013-12-04 01:39:46 <Luke-Jr> lol
81 2013-12-04 01:42:51 <ekkis> gavinandresen: haha
82 2013-12-04 01:42:56 <ekkis> not in my vocabulary
83 2013-12-04 01:43:01 <ekkis> but then, I'm not American
84 2013-12-04 01:43:16 <ekkis> perhaps "connect" is better
85 2013-12-04 01:43:23 <ekkis> meet for coffee as the Dutch say
86 2013-12-04 01:45:15 <Luke-Jr> woo, this download works
87 2013-12-04 01:59:13 <Luke-Jr> cfields: got your gitian outputs posted somewhere?
88 2013-12-04 02:00:18 <jaakkos> might be cool to create a storage altcoin
89 2013-12-04 02:01:04 <jaakkos> merged mine an altcoin where each block gives a new merkle tree root for a ZFS filesystem
90 2013-12-04 02:01:17 <jaakkos> also, have a consensus of disk space limit
91 2013-12-04 02:01:31 <cfields> Luke-Jr: want me to gpg sign the final gpg hash for proof before you post yours?
92 2013-12-04 02:01:34 <jaakkos> the disk space is divided among coin holders
93 2013-12-04 02:01:45 <wiretapped> gavinandresen: depends on context, often yes, but in this context it seems unlikely
94 2013-12-04 02:02:01 <cfields> *final dmg hash
95 2013-12-04 02:02:07 <Luke-Jr> cfields: signature shouldn't matter, but sure
96 2013-12-04 02:02:23 <jaakkos> also prevent people from deleting stuff... though that would be doomed to failure because someone would just upload cp
97 2013-12-04 02:03:03 <Luke-Jr> cfields: bash: line 13: cd: osx-native/contrib/macdepends: No such file or directory
98 2013-12-04 02:03:46 <wiretapped> i realized another dataspam avenue recently... brute force keys that have your data in their hash
99 2013-12-04 02:03:55 <Luke-Jr> ACTION ponders
100 2013-12-04 02:03:59 <cfields> Luke-Jr: mmm, you'll need to edit the descriptors to point to your local file:///...bitcoin/.git, since it's not in the upstream repo yet
101 2013-12-04 02:04:35 <Luke-Jr> cfields: it's pointing at your private git clone though
102 2013-12-04 02:04:38 <cfields> Luke-Jr: i'll be taking your advice and breaking that out into a new repo
103 2013-12-04 02:05:36 <cfields> Luke-Jr: ah, need to use a commit with that in it, then
104 2013-12-04 02:05:48 <cfields> Luke-Jr: gbuild -c bitcoin=deterministic-dmg
105 2013-12-04 02:05:48 <Luke-Jr> I did.. :/
106 2013-12-04 02:05:49 <cfields> or so
107 2013-12-04 02:06:20 <Luke-Jr> native goes first, right?
108 2013-12-04 02:06:56 <cfields> yea
109 2013-12-04 02:08:54 <Luke-Jr> cfields: there is no osx-native dir
110 2013-12-04 02:12:15 <Luke-Jr> cfields: changing it to 'bitcoin' in the yml fixes it
111 2013-12-04 02:12:44 <cfields> Luke-Jr: clearly i don't know how those things work in gitian :)
112 2013-12-04 02:12:57 <cfields> i changed those last-minute before i pushed, i thought they were cosmetic
113 2013-12-04 02:13:16 <Luke-Jr> in the 'cd' command :p
114 2013-12-04 02:13:20 <Luke-Jr> cd bitcoin/contrib/macdepends
115 2013-12-04 02:13:35 <Luke-Jr> that one's not cosmetic :D
116 2013-12-04 02:13:58 <Luke-Jr> I suppose alternately, you could change the "dir" above
117 2013-12-04 02:14:24 <cfields> oh, hah. I guess I assumed gitian always gave you a 'bitcoin' dir to work in. i realize now that makes no sense.
118 2013-12-04 02:14:42 <Luke-Jr> ⦠<.<
119 2013-12-04 02:14:53 <Luke-Jr> cd osx-native/contrib/macdepends <-- this is what you have now :P
120 2013-12-04 02:15:00 <Luke-Jr> cd bitcoin/contrib/macdepends <-- this is what works, because of "dir" above
121 2013-12-04 02:16:06 <cfields> heh ok, so i changed _something_ there last-minute. Clearly it was half-baked :)
122 2013-12-04 02:16:27 <cfields> that'll likely be the case for all of the descriptors then
123 2013-12-04 02:17:40 <Luke-Jr> looks okay in the others
124 2013-12-04 02:17:45 <cfields> i'm going to go ahead and do a clean one, and fix up those things as I go. I'm not 100% sure which of these dmg's laying around was my final one
125 2013-12-04 02:18:02 <Luke-Jr> post hashes of em all :D
126 2013-12-04 02:18:22 <cfields> in case i get lucky: f1d1fd9a117529d466e23a34cb5f19c3585cad38d8a4ebf35f6b9468a0441ab2 Bitcoin-Qt.dmg
127 2013-12-04 02:18:52 <cfields> well the interims aren't deterministic. I didn't bother, since they're not for win32/linux either.
128 2013-12-04 02:19:01 <cfields> not all, anyway
129 2013-12-04 02:24:54 <cfields> Luke-Jr: exactly what change did you make, so i don't end up invalidating the test?
130 2013-12-04 02:25:33 <Luke-Jr> [02:14:51] <Luke-Jr> cd osx-native/contrib/macdepends <-- this is what you have now :P
131 2013-12-04 02:25:34 <Luke-Jr> [02:14:58] <Luke-Jr> cd bitcoin/contrib/macdepends <-- this is what works, because of "dir" above
132 2013-12-04 02:25:36 <Luke-Jr> just that
133 2013-12-04 02:26:21 <cfields> ok
134 2013-12-04 02:28:15 <Luke-Jr> gavinandresen: what is "Broke on 8f342eb7cbc2efb64fbc1f3eb0bf411a24dfbf35" referring to? my git doesn't have that object.. O.o
135 2013-12-04 02:44:41 <gumpus> what development environment do you guys use to work on bitcoin(-qt)?
136 2013-12-04 02:45:20 <gumpus> qtcreator? editor of choice + shells?
137 2013-12-04 02:45:54 <Luke-Jr> 332e43aa2c75582a0703ec21b198babfe9667a4b71a3f684de481b0d6793b29d Bitcoin-Qt.dmg
138 2013-12-04 02:46:08 <Luke-Jr> cfields: no match ^
139 2013-12-04 02:46:14 <Luke-Jr> gumpus: Kate here
140 2013-12-04 02:51:23 <cfields> Luke-Jr: i don't think i built after my last changes, which would've busted the version-string hashes. Still building here.
141 2013-12-04 02:51:52 <gumpus> I notice that the 0.8.5 source has a qmake .pro file but the main git repo does not - is this intentional?
142 2013-12-04 02:52:43 <Luke-Jr> gumpus: qmake -> autoconf is post-0.8
143 2013-12-04 02:53:25 <gumpus> ok
144 2013-12-04 02:58:27 <gavinandresen> Luke-Jr: 8f342eb7cbc2efb64fbc1f3eb0bf411a24dfbf35 is "Merge branch 'autoconf_pt3' of git://github.com/luke-jr/bitcoin" in my tree
145 2013-12-04 02:59:52 <Luke-Jr> ah
146 2013-12-04 03:00:18 <Luke-Jr> gavinandresen: git show 8f342eb7cbc2efb64fbc1f3eb0bf411a24dfbf35^2
147 2013-12-04 03:01:45 <gavinandresen> Luke-Jr: https://gist.github.com/gavinandresen/7781628
148 2013-12-04 03:01:48 <cfields> Luke-Jr: damn, no match. mind pasting your output ymls so i can see what went wrong?
149 2013-12-04 03:02:58 <Luke-Jr> cfields: gavinandresen's test was with the most recent branch :<
150 2013-12-04 03:03:30 <Luke-Jr> cfields: http://codepad.org/X7kBSnkb
151 2013-12-04 03:03:39 <Luke-Jr> gavinandresen: thanks for testing btw
152 2013-12-04 03:03:57 <cfields> gavinandresen: did you clean before build? If you had one of the non-final branches, it would've left a corrupt .a in there
153 2013-12-04 03:04:31 <gavinandresen> cfields: you mean 'make clean' ? yes. I didn't git cleanâ¦.
154 2013-12-04 03:04:44 <cfields> nah, make clean should've done it
155 2013-12-04 03:10:09 <gumpus> if I say 'listaccounts' to bitcoin and get one line with a negative number, what does that mean?
156 2013-12-04 03:10:39 <phantomcircuit> gumpus, accounts can be negative
157 2013-12-04 03:10:47 <phantomcircuit> the total value of all accounts cannot be negative
158 2013-12-04 03:10:56 <phantomcircuit> (well actually it can be but you'll never trigger that)
159 2013-12-04 03:12:12 <gumpus> so.. that means that all the coins that were at all the addresses for that account have been sent to other addresses?
160 2013-12-04 03:14:39 <cfields> Luke-Jr / gavinandresen: i'm really not sure what to say. we guard against exactly that case.
161 2013-12-04 03:14:45 <phantomcircuit> gumpus, that's not how accounts work at all
162 2013-12-04 03:14:55 <cfields> in fact, that didn't change in this PR
163 2013-12-04 03:15:24 <phantomcircuit> gumpus, credit entries for accounts can be either bitcoin transactions where an output is to an address assigned to the account
164 2013-12-04 03:15:29 <gavinandresen> okey dokey. I'll test with master. Might be a "make check" versus just "make" difference.
165 2013-12-04 03:15:37 <phantomcircuit> credit entires can also be just a "move" from one account to another
166 2013-12-04 03:16:21 <phantomcircuit> all debit entires on an account are from sendfrom which create an accounting entry just like "move" but will use outputs from any of the transactions in the entire wallet
167 2013-12-04 03:16:35 <phantomcircuit> accounts do not form groups of addresses for transaction generation purposes
168 2013-12-04 03:16:45 <cfields> gavinandresen: either way if you see it again it's obviously a problem and i'll work it out. I just can't see anything obvious in that PR.
169 2013-12-04 03:17:17 <Luke-Jr> gumpus: coins aren't "at" addresses. once received by an address, they just sit in the wallet independent of the address.
170 2013-12-04 03:19:17 <gumpus> phantomcircuit: i'll do some reading then
171 2013-12-04 03:19:23 <cfields> Luke-Jr: ah wait, i wonder if AM_CONDITIONALS wouldn't execute in an included file
172 2013-12-04 03:20:28 <cfields> gavinandresen: do you still have that branch checked out?
173 2013-12-04 03:21:20 <gumpus> Luke-Jr: but only the private key for whatever address received them can spend them, right? -- but in the bitcoin-qt client that's hidden?
174 2013-12-04 03:23:15 <gavinandresen> cfields: no, working on paymentrequest stuff
175 2013-12-04 03:23:28 <cfields> gavinandresen: ok, i'll test that in a bit.
176 2013-12-04 03:24:12 <cfields> Luke-Jr: could you paste your output ymls? The tar.gz's are no help since they're not deterministic anyway
177 2013-12-04 03:36:23 <Luke-Jr> gumpus: yes, that's at a low level; addresses are a high-level concept
178 2013-12-04 03:36:36 <Luke-Jr> cfields: I didn't save them
179 2013-12-04 03:36:57 <Luke-Jr> cfields: which specifically do you want? I'll rebuild..
180 2013-12-04 03:37:55 <gumpus> Luke-Jr: ok, thanks for the clarification. am still trying to understand the internals of the bitcoin-qt client and of bitcoin itself
181 2013-12-04 03:51:41 <diki> A wumpus and gumpus 0_o
182 2013-12-04 03:52:09 <rweichler> hey... i think im doing something wrong.
183 2013-12-04 03:52:20 <rweichler> i went to a couple testnet faucets and asked them to send BTC to mxdgopxRdW6NwL5cCLPSjyYDgzbLPVuo4C
184 2013-12-04 03:52:32 <rweichler> and nothing is showing up in the block explorer online nor with bitcoind getbalance
185 2013-12-04 03:52:46 <rweichler> i tried http://testnet.mojocoin.com/ and http://tpfaucet.appspot.com/
186 2013-12-04 03:53:09 <andytoshi> rweichler: did they give you a transaction id?
187 2013-12-04 03:53:55 <andytoshi> if you'd like i can just send you some coins
188 2013-12-04 03:54:08 <rweichler> nope, neither andytoshi
189 2013-12-04 03:54:19 <andytoshi> hmm
190 2013-12-04 03:54:20 <rweichler> that'd be great
191 2013-12-04 03:54:28 <rweichler> i can send them back when im done
192 2013-12-04 03:54:36 <andytoshi> ok, one sec
193 2013-12-04 03:55:32 <kalebe> i'm trying to configure my bitcoin wallet with manual config file. what does keypoll=100?? i must increase or decrease this value to enhace the security of my wallet??
194 2013-12-04 03:55:39 <andytoshi> ok, i sent you 30, txid 041cbb049acea2fde6ddc4bbba4ba8f387e2fc0cbce1672abac9b62a7949b057
195 2013-12-04 03:56:00 <andytoshi> a return address is n21UpuEXg3tvMq45ETsDK7uPBrzCkh78fL, but i don't mind if you forget
196 2013-12-04 03:56:08 <andytoshi> or don't want to :)
197 2013-12-04 03:56:18 <kjj> kalebe: keypool is just the number of keys your wallet tries to maintain in the wallet
198 2013-12-04 03:56:44 <andytoshi> kalebe: its effect is basically, the higher you set the number, the less frequently you need to back up the wallet
199 2013-12-04 03:56:53 <Luke-Jr> cfields: http://codepad.org/zVGF1miu osx-native-res.yml
200 2013-12-04 03:57:12 <andytoshi> i didn't know about that option, i should set mine to a million or so..
201 2013-12-04 03:57:27 <rweichler> andytoshi: i dont see it O_O
202 2013-12-04 03:57:36 <rweichler> its not on blockchain.info
203 2013-12-04 03:57:46 <rweichler> not on blockexplorer.com/testnet
204 2013-12-04 03:57:54 <rweichler> not showing up in my wallet
205 2013-12-04 03:57:57 <andytoshi> weird
206 2013-12-04 03:57:58 <rweichler> testnet3, right?
207 2013-12-04 03:58:09 <andytoshi> yep
208 2013-12-04 03:58:12 <andytoshi> my debug.log shows,
209 2013-12-04 03:58:14 <andytoshi> 2013-12-04 03:50:44 Relaying wtx 041cbb049acea2fde6ddc4bbba4ba8f387e2fc0cbce1672abac9b62a7949b057
210 2013-12-04 03:58:32 <kalebe> andytoshi: so it's better if i set it high values?
211 2013-12-04 03:58:44 <kalebe> kjj: keys from other wallets?
212 2013-12-04 03:58:45 <andytoshi> kalebe: yeah, the tradeoff is that it'll make wallet.dat bigger
213 2013-12-04 03:59:02 <kjj> kalebe: no, your keys
214 2013-12-04 03:59:06 <andytoshi> kalebe: no, it generates keys randomly
215 2013-12-04 04:00:11 <rweichler> andytoshi: OH i see it now.
216 2013-12-04 04:00:18 <andytoshi> awesome
217 2013-12-04 04:00:21 <rweichler> OH IM SO STUPID. i forgot to do the blockcount=0
218 2013-12-04 04:00:24 <rweichler> gah. thank you!
219 2013-12-04 04:00:25 <andytoshi> lol
220 2013-12-04 04:00:32 <cfields> Luke-Jr: thanks. I'm working on making the tarballs deterministic for easier testing.
221 2013-12-04 04:00:49 <cfields> Luke-Jr: i'll ping you for a re-test when i think i've got it worked out.
222 2013-12-04 04:00:49 <kalebe> ok, i'm thinking in put it on 1000, some problemm? dafult value is 100... kinda low i think...
223 2013-12-04 04:01:00 <cfields> Luke-Jr: thanks for taking the time.
224 2013-12-04 04:01:18 <Luke-Jr> cfields: ok
225 2013-12-04 04:01:53 <kjj> kalebe: keys are marked as "used" when presented to the user (getnewaddress, etc). if you have less than keypool keys available, the wallet makes more.
226 2013-12-04 04:02:35 <kjj> kalebe: if you back up your wallet, and then request more than keypool addresses, your live wallet now has keys that your backup does not have
227 2013-12-04 04:03:00 <andytoshi> lol, i ran keypoolrefill 1000000 and it ran so long that walletpassphrase timed out
228 2013-12-04 04:03:50 <kjj> unless you are doing a LOT of transactions, like a busy ecommerce site, the default is fine. your effort would be better spent by making a cron job to back up your wallet
229 2013-12-04 04:05:54 <diki> andytoshi:Last time I attempted to make 200k keys
230 2013-12-04 04:05:57 <diki> it took me 2 days
231 2013-12-04 04:06:05 <diki> not even funny how slow it was
232 2013-12-04 04:06:22 <gumpus> how big did that make your wallet.dat?
233 2013-12-04 04:06:30 <diki> 130 megabytes
234 2013-12-04 04:06:50 <diki> I am not sure if I let it finish though.
235 2013-12-04 04:06:53 <gumpus> interesting
236 2013-12-04 04:06:55 <gumpus> oh
237 2013-12-04 04:07:08 <diki> it wa 2 years ago
238 2013-12-04 04:07:10 <gumpus> keygeneration is non-deterministic, I assume?
239 2013-12-04 04:07:13 <diki> *was
240 2013-12-04 04:07:14 <andytoshi> diki: oh, thakns for the warning
241 2013-12-04 04:07:17 <andytoshi> my laptop is 5 years old
242 2013-12-04 04:07:20 <andytoshi> i killed it :P
243 2013-12-04 04:15:46 <kalebe> some one use bitcoind on linux?
244 2013-12-04 04:15:58 <kalebe> someone here**
245 2013-12-04 04:16:01 <kjj> a few people, yes
246 2013-12-04 04:19:39 <diki> a lot of people actually
247 2013-12-04 04:19:56 <diki> Most people here don't even want to hear about Windows.
248 2013-12-04 04:20:58 <diki> But I am a gamer, what I lack in brains I more than make up for it in skill and reaction time.
249 2013-12-04 04:26:33 <andytoshi> i'd guess most people here use linux
250 2013-12-04 04:29:05 <kalebe> i'm new on this, can i get different addresses to receive payment on one wallet..?
251 2013-12-04 04:29:09 <Ryan52> diki: well put
252 2013-12-04 04:29:13 <Ryan52> I guess
253 2013-12-04 04:33:09 <super3> where was that website that showed the bitcoin-qt version distribution?
254 2013-12-04 04:33:28 <super3> my memory tells me it came from Luke-Jr
255 2013-12-04 04:38:37 <andytoshi> kalebe: of course
256 2013-12-04 04:38:41 <andytoshi> try reading http://download.wpsoftware.net/bitcoin/bitcoin-faq.pdf
257 2013-12-04 04:39:24 <kalebe> do you use what version of bitcoin?? bitcoin-qt, bitcoind, multibiti, armory...
258 2013-12-04 04:40:40 <andytoshi> i use a slightly modified bitcoind
259 2013-12-04 04:42:27 <kalebe> andytoshi: why modified? Isn't the official version good enought?
260 2013-12-04 05:16:26 <rweichler> hey is there a way to convert the bitcoin ASM to hex?
261 2013-12-04 05:16:56 <kjj> https://en.bitcoin.it/wiki/Script
262 2013-12-04 05:19:47 <BlueMatt> nanotube: can we get gribble in #bitcoinj ?
263 2013-12-04 05:20:20 <nanotube> ;;join #bitcoinj
264 2013-12-04 05:21:25 <BlueMatt> well, that was easy (tm)
265 2013-12-04 05:21:28 <BlueMatt> thanks
266 2013-12-04 05:55:31 <nanotube> :)
267 2013-12-04 05:57:10 <Fistful_of_LTC> my rigs are autonomous agents that pay for themselves
268 2013-12-04 05:57:44 <Fistful_of_LTC> they heat my basement.
269 2013-12-04 07:20:31 <gmaxwell> P2Pool all time cumulative luck is up to 117.6% now. :P
270 2013-12-04 07:29:19 <wumpus> lucky bastards :P
271 2013-12-04 07:32:15 <Luke-Jr> that means future p2pool luck will be poor!
272 2013-12-04 07:32:17 <Luke-Jr> <.<
273 2013-12-04 09:24:37 <keymone> i have a hypothetical question
274 2013-12-04 09:24:56 <keymone> say bitcoin becomes a threat to some government (hypothetically)
275 2013-12-04 09:25:25 <keymone> and they invest enough money to make a virus that will target everything that runs bitcoin
276 2013-12-04 09:25:29 <keymone> and just destroy the coins
277 2013-12-04 09:25:37 <keymone> how are we protected against that?
278 2013-12-04 09:28:00 <jyf> i think bitcoin could be used as the prepare money for people or org who want to invent their own bank or virtual money
279 2013-12-04 09:28:53 <jyf> and it could also used as a settlement currency for banks
280 2013-12-04 09:30:15 <keymone> but it doesn't really fix the problem - just shifts the burden to somebody else
281 2013-12-04 09:43:29 <jyf> its recorded and public account and transation gave people the credits
282 2013-12-04 09:43:44 <jyf> which is the most problem when you launch a real bank
283 2013-12-04 10:36:08 <stonecoldpat> mmm, with the same bitcoind - can you use testnet and normal network at same time?
284 2013-12-04 10:36:18 <stonecoldpat> as in i close normal network access and boot up bitcoind with -testnet
285 2013-12-04 10:36:27 <stonecoldpat> and i wouldnt have to reindex for the normal network?
286 2013-12-04 10:49:41 <Lifeofcray> god i both love and hate coding at the same time
287 2013-12-04 10:50:21 <e-dard> Hi, does anyone know of a headless bitcoin client to be used on servers? The idea is to provide wallets to users, I guess by generating new keys from a master wallet
288 2013-12-04 10:50:43 <e-dard> every time a user adds money to their wallet we would want to get that transaction confirmed etc
289 2013-12-04 10:51:49 <e-dard> ah looks like https://en.bitcoin.it/wiki/Bitcoind is all I need
290 2013-12-04 11:01:18 <e-dard> Is this the right channel to discuss building stuff around crypto currencies, or is it just for development of the bitcoin client/network?
291 2013-12-04 11:06:40 <wumpus> this channel is for development of bitcoin clients/network, but questions about the APIs and such are of course also allowed
292 2013-12-04 11:07:45 <e-dard> wumpus: ah OK. I had more of a general question â namely, how does an exchange that has markets for many coins maintain all the wallets and block chains?
293 2013-12-04 11:08:10 <wumpus> e-dard: big iron and lots of *coind's
294 2013-12-04 11:08:57 <e-dard> I assume the simplest way is to have one wallet for each coin, and all the users' "wallets" are actually sub-keys of the same wallet?
295 2013-12-04 11:09:07 <wumpus> the specifics would depend on the exchange, but in general, they'd just have lots of servers with nodes and wallets, and of course cold wallets for the bulk of the coins
296 2013-12-04 11:09:12 <e-dard> So you need to have say 30 wallets instead of 100,000.
297 2013-12-04 11:09:39 <wumpus> yes, one (or, depending on scaling, more) wallets per coin, not per user usually
298 2013-12-04 11:09:40 <e-dard> I was thinking something like Cryptsy where there are lots of coins
299 2013-12-04 11:09:48 <e-dard> right. Makes sense
300 2013-12-04 11:10:01 <wumpus> keeping track of which coins belong to which user is done on a higher level
301 2013-12-04 11:10:50 <e-dard> Hmmm, I guess that would allow you to not have to do transactions when someone buys coin A for coin B, since no coins actually went anywhere
302 2013-12-04 11:11:00 <e-dard> :)
303 2013-12-04 11:11:23 <wumpus> yes for user-to-user transfers they do not need block chain transactions
304 2013-12-04 11:12:05 <wumpus> they would need transactions when depositing/withdrawing and from/to their cold wallet
305 2013-12-04 11:12:15 <e-dard> right. So basically for every coin you need to find a coind
306 2013-12-04 11:12:28 <wumpus> yes
307 2013-12-04 11:12:42 <e-dard> I guess that's why there is sometimes a lag between a new coin arriving and it being listed on an exchange
308 2013-12-04 11:14:13 <wumpus> indeed, they first have to vet and install the daemon somewhere.. I'd also recommend using separate servers or practicing some other form of isolation/virtualization, in case one of them turns out to have a backdoor or exploitable bug
309 2013-12-04 11:16:04 <e-dard> thanks wumpus; I understand better now
310 2013-12-04 11:16:14 <e-dard> Apologies if my questions were OT :)
311 2013-12-04 11:33:29 <stonecoldpat> does anyone know on average how long it takes to verify a transaction?
312 2013-12-04 11:36:40 <TD> depends when it's verified
313 2013-12-04 11:37:31 <stonecoldpat> I suppose when your constructing a new block as case 1 and case 2 when verifying another block
314 2013-12-04 11:37:49 <stonecoldpat> i imagine creating a block and doing the verification would take longer ?
315 2013-12-04 11:40:32 <TD> no
316 2013-12-04 11:40:37 <TD> the answer is "it depends"
317 2013-12-04 11:40:46 <TD> the slow part of verifying a tx is signature checking. however signatures are cached.
318 2013-12-04 11:40:56 <TD> so how fast you can verify depends on whether you saw the transaction when it was first broadcast
319 2013-12-04 11:41:10 <TD> once a node has been online for a while and is "warmed up" it shouldn't be seeing very many txns in blocks that are truly new.
320 2013-12-04 11:41:22 <TD> so checking those blocks should be faster
321 2013-12-04 11:45:05 <stonecoldpat> ah ok, am I right in thinking - once you hear a tx broadcast for the first time you verify it and cache it. Then if its included in subsequent blocks it can verified quicker - but what im wondering is that when a new transaction is created (so sending 5 btc to my friend) will generate a new signature (although using the same public key of a previous transaction) - this signature will look
322 2013-12-04 11:45:05 <stonecoldpat> different to any of my previous transactions and would require fresh verification?
323 2013-12-04 11:46:24 <TD> yeah
324 2013-12-04 13:38:56 <wumpus> I've made some small progress on debugging issue #3190 https://github.com/bitcoin/bitcoin/issues/3190 ... looks like the evil no-vin transaction is being transmitted as "wtxprev" for a wallet transaction that isn't being transmitted itself
325 2013-12-04 13:45:28 <gmaxwell> ah we already knew from phantomcircuit that dependency transactions were generally not getting stored.
326 2013-12-04 13:45:43 <gmaxwell> IIRC phantomcircuit even has a patch to avoid trying to store them.
327 2013-12-04 13:45:55 <gmaxwell> I didn't think we'd rebroadcast them.
328 2013-12-04 13:46:54 <wumpus> yep... we not only broadcast dependency transaction, but dependency transactions for transactions that don't need to be transmitted itself
329 2013-12-04 13:47:32 <wumpus> I still don't understand why that transaction has a dependency transaction deemed to be without vins though..
330 2013-12-04 13:50:36 <wumpus> lots of hits on google for d21633ba23f70118185227be58a63527675641ad37967e2aa461559f577aec43
331 2013-12-04 13:50:59 <wumpus> but gettransaction/getrawtransaction refuses to show info for it
332 2013-12-04 13:53:09 <warren> wumpus: curious that google has d21633ba23f70118185227be58a63527675641ad37967e2aa461559f577aec43 given that it was generated by litecoin testnet.
333 2013-12-04 13:53:12 <gmaxwell> I think thats just the hash of 00000000 or something like that.
334 2013-12-04 13:53:19 <warren> yeah
335 2013-12-04 13:53:25 <wumpus> would it be a good idea to only transmit wtx prev's for transactions that we're actually going to transmit?
336 2013-12-04 13:53:32 <warren> litecoin's testnet addresses are the same as bitcoin
337 2013-12-04 13:53:45 <TD> i guess the idea is that if a tx exists, it should be public, so why distinguish
338 2013-12-04 13:53:52 <gmaxwell> wumpus: yes, but also, I don't think we pretty much ever have actual wtx prevs.
339 2013-12-04 13:54:13 <wumpus> gmaxwell: yes, good point
340 2013-12-04 13:56:16 <warren> Is this serious enough to fix in 0.8?
341 2013-12-04 13:56:24 <wumpus> need to debug CWalletTx::AddSupportingTransactions anyway to find out the why
342 2013-12-04 13:56:36 <wumpus> warren: yes, it is, people are getting banned
343 2013-12-04 13:56:47 <wumpus> it should at least be worked around in 0.8
344 2013-12-04 13:57:19 <warren> can people be induced to become banned, or this to be used to identify their nodes?
345 2013-12-04 13:57:22 <gmaxwell> yea, It should be fixed in 0.8 if the fix is small, or at least a small workaround should be added.
346 2013-12-04 13:57:58 <gmaxwell> phantomcircuit: can you explain why AddSupportingTransactions doesn't work, I've forgotten,
347 2013-12-04 13:58:23 <wumpus> warren: I don't think it can be remotely triggered, but some people end up getting banned without doing anything wrong, which is wrong in itself
348 2013-12-04 14:00:32 <warren> FYI: I've been shipping mem barrier + phantomcircuit's no-mmap patch for MacOS X only. Zero reports of corruption or crashes with that combo.
349 2013-12-04 14:00:57 <warren> I added an ifdef to do no-mmap only on Mac. Not changing linux at the last minute when it has working code.
350 2013-12-04 14:18:52 <wumpus> hmm... I made it re-call AddSupportingTransactions for the transaction with the crazy vtxPrev, and now those supporting transactions are gone
351 2013-12-04 14:19:47 <wumpus> so the vtxPrev that were stored in the wallet with the transaction were wrong
352 2013-12-04 14:21:55 <wumpus> oh of course, maybe with a different COPY_DEPTH it will include them
353 2013-12-04 14:23:25 <wumpus> yes, that did it 2013-12-04 14:22:51 Adding vtxPrev transaction d21633ba23f70118185227be58a63527675641ad37967e2aa461559f577aec43
354 2013-12-04 14:25:17 <wumpus> HAH
355 2013-12-04 14:26:04 <wumpus> https://github.com/litecoin-project/litecoin/blob/master-0.8/src/wallet.cpp#L745 this needs an "else continue;"
356 2013-12-04 14:26:36 <wumpus> currenly, if none of the two cases is hit, it stores an emptty transaction
357 2013-12-04 14:27:54 <wumpus> so there's two problems that need to be solved: invalid vtxPrev's being stored (a matter of adding the else), and invalid vtxPrevs in current wallets that are broadcasted
358 2013-12-04 14:38:08 <michagogo> cloud|stonecoldpat: You're not signing "this output can be spent"
359 2013-12-04 14:38:27 <michagogo> cloud|You're signing "this output can be spent as part of this specific transaction"
360 2013-12-04 14:39:30 <michagogo> cloud|Uh, is this stuck?
361 2013-12-04 14:39:35 <michagogo> cloud|brb, refreshing
362 2013-12-04 14:44:15 <jgarzik_> mornin'
363 2013-12-04 14:46:05 <TD> morning
364 2013-12-04 14:48:37 <wumpus> ok, this should fix the empty vin ban issue see https://github.com/bitcoin/bitcoin/pull/3357 and https://github.com/bitcoin/bitcoin/pull/3356
365 2013-12-04 14:58:19 <gmaxwell> I wonder if we should be adding a validity check in there. Say I give you tx A which pays you {at address x} and spends B, now I go get a double spend of B mined. You're going to continue to broadcast B forever, which identifies you as the holder of address X, and also leaves you broadcasting txn with unknown parents forever (though at least we won't ban you for that)
366 2013-12-04 15:00:05 <gmaxwell> not something to fix now I guess.
367 2013-12-04 15:08:47 <typex> don't know if this is a suitable channel, but: I read about a project the other day but can't find it. it was aimed at Localbitcoins.com and other escrows to verify a bank transfer had been made by supplying a ssl-key + the bank statement. anyone know?
368 2013-12-04 15:09:25 <gmaxwell> typex: it was discussed on bitcointalk at least, but that generally cannot work with ssl as it is today.
369 2013-12-04 15:09:35 <TD> they have a neat approach
370 2013-12-04 15:09:50 <TD> typex: https://bitcointalk.org/index.php?topic=173220.0
371 2013-12-04 15:10:22 <typex> thanks!
372 2013-12-04 15:10:31 <typex> gmaxwell, oh ok that's a shame
373 2013-12-04 15:10:48 <typex> is there a specific channel for bitcoin projects and development like that?
374 2013-12-04 15:10:54 <typex> would be sweet :-)
375 2013-12-04 15:10:58 <gmaxwell> Oh thats cute. Kludgey but cute!
376 2013-12-04 15:11:01 <TD> gmaxwell: they are using a very interesting design that involves routing traffic via an oracle running on amazon web services
377 2013-12-04 15:11:12 <TD> so it's "possible" as long as your bank doesn't throw a fit at seeing connections coming from AWS
378 2013-12-04 15:11:17 <TD> (which unfortunately some do)
379 2013-12-04 15:11:26 <TD> but it's the most promising line of research i've seen yet for a truly decentralised exchange
380 2013-12-04 15:11:33 <gmaxwell> the proxy logs the encrypted traffic so you know that the user couldn't have forged it. you still have to trust the oracle to perform this task faithfully.
381 2013-12-04 15:11:49 <TD> yes, but, the oracle is done using the AWS recipe. so amazon acts as the root of trust
382 2013-12-04 15:11:56 <TD> and then it's possible to do a remote attestation to the state of the VPS
383 2013-12-04 15:12:12 <TD> it's a very, very clever solution. i'd never have thought of it (don't know enough about AWS)
384 2013-12-04 15:12:17 <gmaxwell> typex: #bitcoin-wizards is usually where we discuss future and fancy stuff that isn't directly connected to the bitcoin network of today.
385 2013-12-04 15:12:32 <TD> i believe they want testing at the moment
386 2013-12-04 15:14:36 <typex> gmaxwell, cool
387 2013-12-04 15:15:23 <rdn> around how many peers does the bitcoin client stop trying to acquire more?
388 2013-12-04 15:17:37 <gmaxwell> rdn: it always makes 8 outbound, inbound is whatever comes in up to the maximum connection count (125 by default)
389 2013-12-04 16:37:09 <kalebe> hi
390 2013-12-04 16:37:33 <kalebe> i'm new on bitcoin. use linux and started using bitcoind.
391 2013-12-04 16:38:04 <kalebe> what are the steps to get an bit coin address? I already downloaded the blocks.
392 2013-12-04 16:40:04 <lclc> kalebe: since you ask here (developer channel) I guess you want to talk to the API: https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list otherways #bitcoin may be the right channel
393 2013-12-04 16:41:37 <kalebe> but here isn't related to tecnical details? my questions are mostly about software procedures...
394 2013-12-04 16:42:38 <kalebe> i thought #bitcoin was more for discussions related to bitcoin itself
395 2013-12-04 16:42:40 <kalebe> but ok
396 2013-12-04 16:42:48 <lclc> you want to use the RPC-API to talk to bitcoind or using the source?
397 2013-12-04 16:45:13 <gesell> there is no way to get the public key from someones address? So if I wanted to do a multi-signature address with a friend I would need to explain to them how to get their public key, right? no other way
398 2013-12-04 16:45:26 <bluesceada> hey which is the cheapest fpga board that is a normal dev board (still some I/O pins broken out / available), that can also be used for mining (or could, with minimal integration work of some opensource vhdl/verilog design?)
399 2013-12-04 16:45:33 <kalebe> lclc: i use linux, installed bitcoind and edited the bitcoin.conf at my will... after that start runin bitcoind and it downloaded almost 8GB of blocks, and still downloading...
400 2013-12-04 16:45:56 <kalebe> now i don't know what i must do to use it or generete and account...
401 2013-12-04 16:46:13 <lclc> just start bitcoin-qt
402 2013-12-04 16:46:17 <gmaxwell> gesell: no good way, you wouldn't want to use a random key you think someone else can use in any caseâ that key might be, for example, part of their coinbase wallet, and they can't use it for a multisignature signing.
403 2013-12-04 16:46:17 <kalebe> i already saw bitcoind manual..
404 2013-12-04 16:46:40 <gmaxwell> gesell: you'd have to explain to them how to release the transaction in any case.
405 2013-12-04 16:47:16 <kalebe> lclc: i can only make it work with an graphic program?
406 2013-12-04 16:47:46 <kalebe> can't i just use bitcoind to do all stuff related to bitcoin?
407 2013-12-04 16:47:48 <gesell> gmaxwell: do you know when this type of functionality might slowly find its way into clien UI's? and yes, the issue with online wallets is a total other problem
408 2013-12-04 16:48:30 <lclc> kalebe: no you can also do it with the API from the link I send you. e.g: bitcoind getinfo
409 2013-12-04 16:49:35 <gmaxwell> gesell: You can already get a public key via the UI, I'm not sure that we'll ever do more for "get public key" than that. What I hope we'll eventually implement is a full multisignature wallet, at some point. But no one is working on that right now.
410 2013-12-04 16:50:23 <kalebe> lclc: i'm already runing bitcoind as daemon... when i try to send commands like getinfo or setaccount it say's "error: no response from server"
411 2013-12-04 16:50:47 <gmaxwell> Okay. Maybe someone is working on it.
412 2013-12-04 16:51:12 <kalebe> when I say send, I mean type bitcoind getinfo, when bitcoind is already runing
413 2013-12-04 16:54:35 <lclc> kalebe: do you have set server=1 in your bitcoin.conf file?
414 2013-12-04 17:01:23 <shesek> are transactions removed eventually from the mempool if they don't get mined?
415 2013-12-04 17:02:45 <Apocalyptic> yes shesek
416 2013-12-04 17:03:50 <shesek> how is it determined? after some fixed amount of time is passed, or what?
417 2013-12-04 17:04:36 <TD> no
418 2013-12-04 17:04:47 <TD> though if your node restarts it won't reload the transactions (in existing releases)
419 2013-12-04 17:04:59 <kalebe> lclc: i put server=1 on bitcoin.conf and restarted the server. I still can't use any command, even "bitcoind getinfo"
420 2013-12-04 17:07:12 <shesek> TD, but it'll still be in everyone else's mempool
421 2013-12-04 17:08:19 <lclc> kalebe: hm ok, ehm I don't have any other idea what could be wrong atm, sorry
422 2013-12-04 17:08:33 <TD> yes
423 2013-12-04 17:10:10 <lclc> have to go, back in 40min
424 2013-12-04 17:10:24 <kalebe> lclc: thx bro
425 2013-12-04 17:14:53 <kalebe> must i open rpc connection port on my firewall or it's just for receiving external commands??
426 2013-12-04 17:19:38 <pigeons> kalebe: don't allow external RPC connections except unusual special applications
427 2013-12-04 17:33:23 <cfields> Luke-Jr: ping. All stages and outputs are now deterministic. http://pastebin.com/raw.php?i=3fhkedS8
428 2013-12-04 17:35:53 <cfields> Luke-Jr: gah, helps if i hash the right file: http://pastebin.com/raw.php?i=E4q1SEEk
429 2013-12-04 17:49:29 <gmaxwell> hm. running my testnet wallet in valgrind with master as of a few minutes ago.. haven't run it in valgrind for a while, have some uninit jumps at
430 2013-12-04 17:49:32 <gmaxwell> ==17609== at 0x227984: CWallet::LoadKeyMetadata(CPubKey const&, CKeyMetadata const&) (wallet.cpp:96)
431 2013-12-04 17:56:06 <CodeShark> even with txindex on, getrawtransaction won't fetch the transaction of the genesis block, huh?
432 2013-12-04 17:56:40 <CodeShark> minor annoyance - simple fix, but I guess nobody has thought it worthwhile
433 2013-12-04 17:59:15 <CodeShark> or simple patch, might be a better term - since the behavior of the first block in satoshi's implementation was always errant
434 2013-12-04 18:00:06 <CodeShark> as far as everyone's concerned, that transaction only exists to give the genesis block its hash :)
435 2013-12-04 18:04:40 <onscreen> anyone have any x1 > x16 risers to sell?
436 2013-12-04 18:08:02 <TD> does anyone know who is behind Kraken? is that Michael Gronager's company (payward)?
437 2013-12-04 18:11:55 <TD> seems so
438 2013-12-04 18:17:20 <BlueMattBot> Project Bitcoin build #493: FIXED in 42 min: http://jenkins.bluematt.me/job/Bitcoin/493/
439 2013-12-04 18:17:20 <BlueMattBot> Yippie, build fixed!
440 2013-12-04 18:31:23 <gmaxwell> TD: I was a bit confused that someone in my office came up and asked me about it yesterday, I'd never heard of it before. Then I looked back at my screen and #bitcoin was chattering about it.
441 2013-12-04 18:31:56 <TD> just co-incidence i guess. i just realised i didn't know anything about them
442 2013-12-04 18:43:20 <Luke-Jr> cfields: I read over my original requirements list and noted: - A single yml (or equivalent) per dependency, leading up to a final deterministic Bitcoin-Qt DMG.
443 2013-12-04 18:43:39 <Luke-Jr> probably trivial
444 2013-12-04 18:44:37 <cfields> Luke-Jr: i can do that if you'd like, but it seems rather senseless to break it up into ~15 ymls...
445 2013-12-04 18:47:02 <cfields> Luke-Jr: it's broken up logically by make targets, i'd call that a reasonable equivalent?
446 2013-12-04 18:47:57 <Luke-Jr> cfields: maybe - I'm thinking of the perspective of reusing the individual ymls for other targets though
447 2013-12-04 18:48:16 <cfields> i have no problem splitting it out if you think it's necessary, i just don't see how it'd be helpful
448 2013-12-04 18:52:57 <JyZyXEL> how do i remove a tx from bitcoind's mempool?
449 2013-12-04 18:53:06 <JyZyXEL> it seems to persist over restarts
450 2013-12-04 18:53:26 <cfields> Luke-Jr: how about if i split them into individual makefiles, then gitian can make each one individually? It's important to me to be able to build without gitian, so that it's useful for eg. pulltester
451 2013-12-04 18:54:23 <Luke-Jr> cfields: sure
452 2013-12-04 18:54:51 <berndj> Luke-Jr, is ljrbot ok? (in case you didn't know - and assuming it's yours)
453 2013-12-04 18:55:05 <cfields> Luke-Jr: you'd consider the requirements met in that case?
454 2013-12-04 18:55:50 <shesek> oh wow, people are starting to talk about bitrated - https://twitter.com/search?q=bitrated
455 2013-12-04 18:56:28 <shesek> that's really cool :)
456 2013-12-04 19:11:50 <davispuh> something really weird just happened, with bitcoin-qt on windows, I did "sendfrom davispuh 1651BHWarSxvj2twccBCGPNHYXguRBZrt2 0.0002385" but seems something went wrong
457 2013-12-04 19:12:00 <davispuh> this tx https://blockchain.info/tx/3fb559f8c0fc73882c9d45e15ec7f074f38d43af079c386f07b202c3898da191
458 2013-12-04 19:13:02 <davispuh> and davispuh addreess is 1DMT1fPDdh1o9UCWkx1ZmwV7eNnxmSad6k from which I wanted to send, not from that 1651...
459 2013-12-04 19:13:28 <pigeons> sendfrom means account not address i think
460 2013-12-04 19:13:45 <gmaxwell> davispuh: First I direct your attention to the channel topic.
461 2013-12-04 19:14:07 <gmaxwell> in particular, the "There is no from address" part.
462 2013-12-04 19:14:16 <gmaxwell> Transactions do not have a from address.
463 2013-12-04 19:14:46 <gmaxwell> You're misunderstanding what the accounts functionality does. Accounts are _purely_ local bookkeeping. They do not change what happens on the network in the slightest.
464 2013-12-04 19:14:48 <ryan-c> What does it take to get a new transaction template made standard?
465 2013-12-04 19:14:59 <davispuh> sendfrom <fromaccount> <tobitcoinaddress> <amount>
466 2013-12-04 19:15:00 <Luke-Jr> cfields: when it's split out of the bitcoin git repo, yes
467 2013-12-04 19:15:15 <Luke-Jr> ryan-c: show a use case
468 2013-12-04 19:15:20 <ryan-c> davispuh: Accounts are not addresses.
469 2013-12-04 19:15:27 <gmaxwell> ryan-c: Test it on testnet, describe the application in an issue or (preferrably) pull request. If it's using opcodes which aren't well tested, you may be asked to help improve the test cases.
470 2013-12-04 19:16:12 <davispuh> I thought accounts are labels for addreses :|
471 2013-12-04 19:16:29 <ryan-c> davispuh: Accounts are labels for groups of addresses.
472 2013-12-04 19:16:33 <gmaxwell> davispuh: no, they're just local book keeping, like spending categories in a memo field in your checkbook.
473 2013-12-04 19:16:42 <gmaxwell> "This week I spend 0.02 btc on groceries!"
474 2013-12-04 19:16:49 <cfields> Luke-Jr: ok. i don't suppose you've tried building again with the last round of fixes?
475 2013-12-04 19:16:59 <ryan-c> davispuh: Read up on how change addresses work.
476 2013-12-04 19:17:15 <Luke-Jr> cfields: in the process
477 2013-12-04 19:17:22 <cfields> ok
478 2013-12-04 19:17:50 <ryan-c> gmaxwell: Thanks. How long does the approval process normally take?
479 2013-12-04 19:17:53 <davispuh> I wanted to send from X address to Y, but it sent from Y to Y with change in Z
480 2013-12-04 19:17:58 <Luke-Jr> cfields: none of the depends match; doing b-qt now
481 2013-12-04 19:18:38 <cfields> Luke-Jr: mm. In the past, what has differed between gitian instances?
482 2013-12-04 19:19:01 <cfields> I've verified multiple times that I get the same results locally.
483 2013-12-04 19:19:05 <gmaxwell> ryan-c: mostly the time delays would just be in getting into a release and it being deployed in the network. Timeframe of months.
484 2013-12-04 19:19:05 <Luke-Jr> ACTION shrugs
485 2013-12-04 19:19:30 <gmaxwell> ryan-c: what do you want made not non-standard?
486 2013-12-04 19:19:57 <cfields> Luke-Jr: ok. Mind sending one of the tarballs for diffing?
487 2013-12-04 19:20:17 <Luke-Jr> cfields: are there any copyright concerns?
488 2013-12-04 19:20:17 <ryan-c> gmaxwell: Efficiently encoded 'master key or N-of-M'
489 2013-12-04 19:21:12 <ryan-c> Well, that generally. In my specific use case, N == M.
490 2013-12-04 19:21:22 <andytoshi> davispuh: http://download.wpsoftware.net/bitcoin/bitcoin-faq.pdf
491 2013-12-04 19:22:09 <gmaxwell> ryan-c: so it's A or C&&D&&E&&F... ?
492 2013-12-04 19:22:16 <ryan-c> gmaxwell: yes
493 2013-12-04 19:22:20 <cfields> Luke-Jr: only if you want to be very pedantic. You'd be sending me files I already have and have the rights to.
494 2013-12-04 19:23:46 <ryan-c> Also, I just saw a note that multisig transactions with more than three pubkeys are considered non-standard, is that accurate?
495 2013-12-04 19:24:40 <Luke-Jr> cfields: uploading files to <PM> - my upload is slow tho
496 2013-12-04 19:24:56 <davispuh> I think that account thing is quite confusing, besides it doesn't appear anywhere in GUI
497 2013-12-04 19:26:18 <gmaxwell> ryan-c: yes, right now.
498 2013-12-04 19:26:55 <ryan-c> gmaxwell: Is that mostly for size reasons, or something else?
499 2013-12-04 19:28:28 <gmaxwell> ryan-c: yes, in general we've avoided permitting things as IsStandard that have higher abuse potential (e.g. encoding edgy content into the blockchain, or just wasting a bunch of CPU with checksig operators) unless someone had an actual application for them. E.g. an implementation, even if its preproduction.
500 2013-12-04 19:28:54 <ryan-c> gmaxwell: I do have a useful application in mind.