1 2015-01-13 00:07:20 <michagogo> devrandom: oh, so would that be RSYNC_CONNECT_PROG=lxc-execute rsync something?
2 2015-01-13 00:17:12 <PRab> If I'm doing a gitian release, can the SIGNER=prab, but my gpg key have my email address?
3 2015-01-13 00:23:34 <PRab> Also, is the "git checkout v${VERSION}" required? It looks like gbuild automatically does that.
4 2015-01-13 00:24:06 <sipa> PRab: it does, after reading the descriptor
5 2015-01-13 00:24:17 <sipa> the checkout is so you get the descriptors corresponding to that release too
6 2015-01-13 00:25:17 <PRab> ok, any ideas about my SIGNER question?
7 2015-01-13 00:25:35 <sipa> no, but i've wondered the same but never bothered to look it up
8 2015-01-13 00:25:55 <PRab> fair enough. I'll try it and see what happens.
9 2015-01-13 00:26:47 <dmne> When I sign a message, the signature is not unique?
10 2015-01-13 00:27:12 <PRab> It just looks like everyone has been using all lowercase usernames in the gitian.sigs repository.
11 2015-01-13 00:27:12 <sipa> dmne: in 0.10, it will be
12 2015-01-13 00:27:27 <sipa> dmne: but ECDSA does not require that, and it cannot be enforced
13 2015-01-13 00:27:30 <michagogo> PRab: here's the answer
14 2015-01-13 00:27:53 <michagogo> The argument to gsign is the dir name that the sig is placed in
15 2015-01-13 00:27:55 <dmne> sipa: How will bitcoin in 0.10 make it unique?
16 2015-01-13 00:28:04 <dmne> What's the process it will use?
17 2015-01-13 00:28:06 <michagogo> And it's also what's passed to gpg's-u
18 2015-01-13 00:28:20 <sipa> dmne: ECDSA signing takes a random nonce (which is secret) as input to the signing algorithm
19 2015-01-13 00:28:31 <michagogo> I think it's -u, that is
20 2015-01-13 00:28:40 <sipa> dmne: as of 0.10, that nonce is computed deterministically from the message and the private key, rather than randomly generated
21 2015-01-13 00:28:42 <PRab> michagogo: Got it.
22 2015-01-13 00:28:46 <sipa> dmne: see RFC6979
23 2015-01-13 00:28:53 <michagogo> Whichever GPG flag you use to tell it which key to use
24 2015-01-13 00:29:13 <dmne> sipa: If someone knows what random nonce you used to generate the signature, you will leak your private key?
25 2015-01-13 00:29:19 <sipa> yes
26 2015-01-13 00:29:21 <PRab> michagogo: So I'll probably just use SIGNER=prab and do the signature after.
27 2015-01-13 00:29:36 <michagogo> PRab: so if `gpg --sign -u prab` works, then that should work
28 2015-01-13 00:29:39 <michagogo> PRab: or that
29 2015-01-13 00:29:52 <dmne> sipa: Is there a way for the person verifying the signature to know if you used a determanistic process or not?
30 2015-01-13 00:29:58 <rudy_> do i need to have bitcoins to interact with the blockchain
31 2015-01-13 00:30:03 <sipa> dmne: no, and if there was, it would imply knowing their nonce
32 2015-01-13 00:30:04 <michagogo> It's just gpg --detached-sign or something like that
33 2015-01-13 00:30:22 <PRab> michagogo: Oh, cool that found the correct gpg key.
34 2015-01-13 00:30:48 <PRab> now I just have to figure out why rc3 isn't building.
35 2015-01-13 00:30:56 <michagogo> PRab: what's the key id?
36 2015-01-13 00:30:58 <PRab> "./bin/gbuild:21:in `system!': failed to run on-target setarch x86_64 bash -x < var/build-script > var/build.log 2>&1 (RuntimeError)"
37 2015-01-13 00:31:12 <michagogo> PRab: pastebin the log
38 2015-01-13 00:31:22 <michagogo> var/build.lo
39 2015-01-13 00:31:25 <michagogo> g
40 2015-01-13 00:31:46 <PRab> http://paste.debian.net/140393/
41 2015-01-13 00:32:30 <dmne> sipa: Thanks! Are there any other asymetric signature schemes you're aware of where signing a particular message gives a single output (like a cryptographic hash) but doesn't reveal your private key
42 2015-01-13 00:33:01 <sipa> dmne: yes, those exist, but they rely on different cryptographic constructs
43 2015-01-13 00:33:10 <michagogo> PRab: Ah.
44 2015-01-13 00:33:20 <sipa> dmne: none that are as efficient as ecdsa
45 2015-01-13 00:33:21 <michagogo> PRab: re-seed the depends
46 2015-01-13 00:33:23 <dmne> sipa: Know the names of it, so i can further look into it?
47 2015-01-13 00:33:26 <PRab> ?
48 2015-01-13 00:33:34 <dmne> Performance isn't a big concern for me
49 2015-01-13 00:33:38 <michagogo> PRab: in release-process.md
50 2015-01-13 00:33:40 <PRab> nm, I got it.
51 2015-01-13 00:33:42 <dmne> (or space efficiency)
52 2015-01-13 00:33:46 <michagogo> There's a command to download the sources
53 2015-01-13 00:33:55 <michagogo> make -C something
54 2015-01-13 00:34:00 <sipa> gmaxwell: ping, what is the name of the strong signing algorithm based on pairing crypto?
55 2015-01-13 00:34:40 <sipa> BLS, apparently
56 2015-01-13 00:34:42 <PRab> michagogo: New version of openssl?
57 2015-01-13 00:34:53 <michagogo> PRab: yeah
58 2015-01-13 00:34:55 <sipa> dmne: BLS is one
59 2015-01-13 00:35:07 <dmne> sipa: Thanks! Looking into it now
60 2015-01-13 00:35:30 <michagogo> rc1 was 1.0.1j I think, rc3 is 1.0.1k
61 2015-01-13 00:36:42 <PRab> what happened to rc2? I see the tag, but it wasn't even out for a day.
62 2015-01-13 00:36:58 <michagogo> PRab: openssl changed their build system a bit
63 2015-01-13 00:37:20 <michagogo> So the date call that we edit out is in a different file
64 2015-01-13 00:37:38 <michagogo> Which meant that the openssl build ended up with an embedded timestamp
65 2015-01-13 00:37:42 <PRab> ah, so basically gitian did its job.
66 2015-01-13 00:38:36 <michagogo> PRab: you can compare the two tags to see that it's just a change of file name in a sed command
67 2015-01-13 00:38:38 <michagogo> (Of
68 2015-01-13 00:39:02 <michagogo> (Oh, and updated release notes that didn't get updated for rc2)
69 2015-01-13 00:39:40 <PRab> I probably drive you guys nuts, but I tend to use https://github.com/bitcoin/bitcoin/compare/v0.10.0rc2...v0.10.0rc3 to compare 2 tags.
70 2015-01-13 00:40:13 <michagogo> PRab: why do you say that?
71 2015-01-13 00:40:45 <michagogo> Nothing wrong with that interface
72 2015-01-13 00:40:54 <PRab> Centralized and if github is compromised it could be showing false information.
73 2015-01-13 00:41:07 <gmaxwell> sipa: technically thats a unique signature, not a strong signature.
74 2015-01-13 00:41:18 <sipa> gmaxwell: ah, difference?
75 2015-01-13 00:41:24 <michagogo> Well, yeah, but we use GH for a lot already
76 2015-01-13 00:41:39 <michagogo> I mean, you're the one being potentially hurt by it :P
77 2015-01-13 00:41:54 <gmaxwell> sipa: a strong signature is like low-s fixed ecdsa.
78 2015-01-13 00:41:59 <michagogo> If you choose to do that rather than git diff/git log, that's your decision
79 2015-01-13 00:42:06 <PRab> true enough.
80 2015-01-13 00:42:10 <gmaxwell> (maybe)
81 2015-01-13 00:42:22 <gmaxwell> knowing one valid signature you can't get any more distinct signatures without knowing the private key, even of the same message.
82 2015-01-13 00:42:23 <michagogo> Anyway, 2:42 am here...
83 2015-01-13 00:42:23 <sipa> gmaxwell: oh, right, strong means non-malleable by non-signers; unique means non-malleable by signers
84 2015-01-13 00:42:28 <michagogo> ACTION &
85 2015-01-13 00:42:30 <PRab> I'll try to open a gitian pull request for rc3 tonight.
86 2015-01-13 00:42:32 <gmaxwell> sipa: yep.
87 2015-01-13 00:42:35 <sipa> fg michagogo
88 2015-01-13 00:42:43 <michagogo> killall sipa
89 2015-01-13 00:42:52 <PRab> Ouch, 7:42pm here.
90 2015-01-13 00:43:15 <michagogo> ACTION reads a very big file or something
91 2015-01-13 00:43:17 <sipa> 1:43 am here
92 2015-01-13 00:43:34 <PRab> you guys are a bit crazy.
93 2015-01-13 00:43:35 <gmaxwell> sipa: there are a number of other unique signatures; e.g. most hash-based signatures are unique. I think RSA is unique if the right padding scheme is used.
94 2015-01-13 00:44:18 <sipa> oh, right
95 2015-01-13 00:44:20 <sipa> RSA too
96 2015-01-13 00:44:24 <dmne> ohh nice
97 2015-01-13 00:44:31 <dmne> That's what I need, unique signatures
98 2015-01-13 00:44:39 <sipa> dmne: what for, if i may ask?
99 2015-01-13 00:45:15 <dmne> The mechanisms of a game. You know the persons public key, and send them a message
100 2015-01-13 00:45:26 <dmne> They sign the message, and you gamble on the outcome of the signature
101 2015-01-13 00:45:40 <dmne> If the person can craft many unique signatures, it doesn't work
102 2015-01-13 00:45:48 <dmne> So I need a guarantee of a unique signature
103 2015-01-13 00:45:59 <gmaxwell> dmne: a single show signature works for that too.
104 2015-01-13 00:46:25 <dmne> gmaxwell: Got a link for that, I can't find that term
105 2015-01-13 00:46:36 <gmaxwell> dmne: they send you an augmented pubkey which contains a regular pubkey and a nonce. You send them a message. They sign using the proposed nonce. The result is unique.
106 2015-01-13 00:47:06 <gmaxwell> (well upto the ECDSA sign malleability; which can be handled by just mandating low-s)
107 2015-01-13 00:47:30 <dmne> Ah, that doesn't work. I simplified the problem too much. The person is actually signing a message '1', '2', '3', '4', '5', '6'
108 2015-01-13 00:47:35 <dmne> and people are gambling on the outcome of that
109 2015-01-13 00:47:49 <dmne> (multiple people can gamble at once)
110 2015-01-13 00:48:36 <gmaxwell> dmne: uh, with a unique signaute someone can grind their pubkey to make sure the signatures of predictable messages have desirable values.
111 2015-01-13 00:48:44 <gmaxwell> signature*
112 2015-01-13 00:49:26 <gmaxwell> dmne: so you need a nonce in your message. and if you have that the one show scheme I described should work. Though maybe you're just saying that it doesn't work for you because you need multiple signatures with the same key?
113 2015-01-13 00:50:03 <dmne> gmaxwell: There is no such thing as a desirable value, because people can gamble "it'll be low" or "it'll be high"
114 2015-01-13 00:50:22 <dmne> gmaxwell: And the reason I think yours doesn't work, is because the person is broadcasting the signature to *many* people
115 2015-01-13 00:50:26 <dmne> It's a global system
116 2015-01-13 00:50:34 <dmne> So no particular person can provide input to the person signing messages
117 2015-01-13 00:51:15 <dmne> It's basically like an automated lottery, someone broadcasting numbers that multiple people can gamble upon
118 2015-01-13 00:51:46 <gmaxwell> "someone broadcasting numbers that multiple people can gamble upon" is called a random beacon.
119 2015-01-13 00:52:12 <gmaxwell> But whats the signing for then, I can broadcast random numbers and just sing them. "My dice for today says 5 -- gmaxwell".
120 2015-01-13 00:52:15 <gmaxwell> er sign
121 2015-01-13 00:52:22 <dmne> But I want a way for people to trust the random beacon
122 2015-01-13 00:52:29 <dmne> So that the outcomes of the random beacon aren't in response to someones bet
123 2015-01-13 00:53:18 <dmne> So I know for a fact, you'll use GMAXWELL_PUBKEY to sign the message: "lottery draw number 144"
124 2015-01-13 00:53:25 <gmaxwell> But if your messages are 1,2,3... etc. I can select a pubkey so that a particular bet will have a particular value. e.g. It may be that you haven't described this enough for me.
125 2015-01-13 00:53:55 <dmne> But you'll have to select the pubkey before hand
126 2015-01-13 00:54:00 <dmne> before knowing anyones bets
127 2015-01-13 00:54:13 <gmaxwell> dmne: right and I can select GMAXWELL_PUBKEY to make sure that "lottery draw number 144" has a value, say, congruent to 0 mod 57.
128 2015-01-13 00:54:16 <sipa> start with a random value, hash it a million times, store the intermediate results; than reveal the 1000000th result, then the 999999th, then ..., ... all participants can verify that every value is a preimage of the next, but can't guess it
129 2015-01-13 00:54:19 <dmne> And since there's no "good outcomes" and "bad outcomes" it's not a problem
130 2015-01-13 00:54:38 <dmne> sipa: Yeah, that's my current solution
131 2015-01-13 00:54:49 <dmne> I was hoping for a solution where I didn't need to store 100M hashes
132 2015-01-13 00:55:11 <gmaxwell> dmne: sure okay if you can promise that I won't know the terms in advance when setting the pubkey, then you have just a coin-flip protocol; but I see you want it multiparty.
133 2015-01-13 00:55:52 <sipa> dmne: storing just every 1000th one sufficies; you can easily recompute any value from the latest predecessor
134 2015-01-13 00:55:54 <gmaxwell> I can see why you woul prefer unique to single show.
135 2015-01-13 00:56:30 <dmne> sipa: The main problem I have is, I need to know how many to compute before hand
136 2015-01-13 00:56:35 <dmne> once the lottery has started, I am committed
137 2015-01-13 00:57:00 <dmne> But storing every 1000th is a clever idea, I didn't think of that. That would save my storage space hugely =)
138 2015-01-13 00:57:14 <dmne> Computing a billion hashes isn't a big deal, just storing them is annoying
139 2015-01-13 00:57:33 <gmaxwell> dmne: well if you have a bag of values and you reveal certian preimages determinstically, and the answer is just the hash of those... then that works too, but at that point we've just reinvented an existing hash based signature scheme.
140 2015-01-13 00:57:44 <gmaxwell> dmne: you don't have to store them as sipa pointed out.
141 2015-01-13 00:57:55 <gmaxwell> you can store one in a million and just recompute the middle ones.
142 2015-01-13 00:58:53 <ajweiss> why not just a prng with a different seed each day that you publish at the end of the day?
143 2015-01-13 00:59:11 <dmne> Two reasons, it takes longer for people to verify
144 2015-01-13 00:59:13 <gmaxwell> ajweiss: because thats not immediately verifyable? kinda lame.
145 2015-01-13 00:59:18 <dmne> (they have to wait till end of day)
146 2015-01-13 00:59:28 <dmne> And "end of day" is quite a fuzzy criterea
147 2015-01-13 00:59:35 <dmne> The switching is always suspitious
148 2015-01-13 01:00:04 <gmaxwell> dmne: nah, the latter point is bogus, you have a mac you use for e.g. 12 hours, and then 12 hours after you stop using it you release it and there is no real ambiguity.
149 2015-01-13 01:00:51 <dmne> If a game happens on the second boundary, it's pretty ambigious I think
150 2015-01-13 01:01:29 <dmne> It's also annoying for people to verify historical games
151 2015-01-13 01:02:36 <ajweiss> "here is the verification script!
152 2015-01-13 01:02:36 <dmne> Here's an example of how it's doing now: https://bitcointalk.org/index.php?topic=922898.0
153 2015-01-13 01:02:37 <ajweiss> "
154 2015-01-13 01:02:56 <ajweiss> people see it, it's simple to understand. it runs, and answers "yup."
155 2015-01-13 01:03:20 <dmne> But a scheme that doesn't involve storing intermediate hashes is nice -- as I was hoping to be able to offer such a thing as a service
156 2015-01-13 01:03:30 <dmne> So other gambling operators can generate their own sequences
157 2015-01-13 01:04:47 <gmaxwell> dmne: you can still happily conspire with people to rig the outcome, so, meh.
158 2015-01-13 01:04:56 <dmne> gmaxwell: How so?
159 2015-01-13 01:05:09 <gmaxwell> dmne: by helping them grind their query.
160 2015-01-13 01:05:30 <gmaxwell> dmne: e.g. "no no gmaxwell, you want to play in lottery 413 not 412"
161 2015-01-13 01:05:36 <gmaxwell> "wink wink"
162 2015-01-13 01:05:47 <gmaxwell> You can see the future. :)
163 2015-01-13 01:06:05 <dmne> Yeah, it's only provably fair for players not casinos
164 2015-01-13 01:06:12 <dmne> Same as all the online gambling schemes
165 2015-01-13 01:06:25 <dmne> The players get the provable fairness, the casino/investors rely on trust
166 2015-01-13 01:08:04 <dmne> But the real useful thing would be to be able to have a signature scheme that generates unique signatures per message
167 2015-01-13 01:12:56 <ajweiss> you could use the blockchain itself as your random number generator
168 2015-01-13 01:13:15 <phantomcircuit> ajweiss, no you cant
169 2015-01-13 01:13:46 <ajweiss> a winning bet is H(prevhash|nonce) = nbits of prevblocks merkleroot or whatever
170 2015-01-13 01:14:08 <sipa> ajweiss: and if the bet result becomes more valuable than the block reward, miners will grind their nonces to win
171 2015-01-13 01:14:29 <ajweiss> true
172 2015-01-13 01:14:36 <phantomcircuit> and if you're using the merkle tree root then they can do that at virtually no cost
173 2015-01-13 01:14:42 <phantomcircuit> grinding the mtr is cheap
174 2015-01-13 01:14:51 <PRab> Hash more blocks together.
175 2015-01-13 01:15:08 <PRab> Each additional block makes it exponentially harder to grind.
176 2015-01-13 01:19:35 <lianj> any guesses when secp256k1 is updated in master to use rfc6979
177 2015-01-13 01:19:54 <sipa> lianj: it has been
178 2015-01-13 01:20:02 <sipa> oh
179 2015-01-13 01:20:34 <sipa> we're using RFC6979 already, but not libsecp256k1's implementation of it
180 2015-01-13 01:21:11 <lianj> yea, whats blocking libsecp256k1's implementation? just curious
181 2015-01-13 01:21:23 <sipa> review
182 2015-01-13 01:21:38 <sipa> the 0.10 release has a bit higher priority now
183 2015-01-13 01:21:46 <lianj> planning to use libsecp256k1 and wonder if i should just go with bitcoin's subtree and not official git repo
184 2015-01-13 01:22:26 <sipa> as long as you only use it for signing, it shouldn't matter
185 2015-01-13 01:22:47 <sipa> if you want to use it for (Bitcoin) transaction validation, i advise against it
186 2015-01-13 01:23:04 <lianj> yea, that is my second question. you don't suggest using it for verify yet? noticed bitcoin core does only signing for now
187 2015-01-13 01:23:11 <lianj> ok thanks
188 2015-01-13 01:23:22 <sipa> yes, we haven't established that it is bug-for-bug compatible with openssl
189 2015-01-13 01:23:55 <sipa> and more testing and review are still very welcome too before making the decision to let bitcoin's consensus rely on it
190 2015-01-13 01:24:51 <lianj> yep sounds good
191 2015-01-13 01:26:27 <gmaxwell> lianj: the 6979 implementations should produce identical results; uh if they don't you should report that.
192 2015-01-13 01:38:49 <sipa> pushed by rc3 sigs
193 2015-01-13 01:38:51 <sipa> *my
194 2015-01-13 03:40:40 <warren> Note: If you plan on releasing 0.9.4, gitian Linux won't succeed in pulling in the new openssl yet.
195 2015-01-13 03:41:36 <warren> oh nevermind, I'm wrong, 0.9.4 builds its own openssl.
196 2015-01-13 03:43:46 <PRab> I think I did it! https://github.com/bitcoin/gitian.sigs/pull/77/files
197 2015-01-13 03:45:40 <blockchain> hi developers
198 2015-01-13 03:46:15 <felipelalli> hi
199 2015-01-13 03:46:38 <blockchain> who is professional programmer here ?
200 2015-01-13 03:46:47 <felipelalli> almost everyone.
201 2015-01-13 03:47:26 <blockchain> I need private talk
202 2015-01-13 03:47:43 <felipelalli> do you work to blockchain.info?
203 2015-01-13 03:47:44 <blockchain> about 2btc per 10 minutes
204 2015-01-13 03:52:43 <blockchain> any programmer up here ?
205 2015-01-13 03:53:30 <blockchain> hello
206 2015-01-13 03:53:46 <PRab> Just ask the question. Most people are happy to help out.
207 2015-01-13 03:54:39 <blockchain> ok , I need a api and php programmer , to earn out to 2btc per 10 minuets , seriously it will
208 2015-01-13 03:54:53 <blockchain> but the fist thing is this is a test
209 2015-01-13 03:55:39 <blockchain> and a challenge
210 2015-01-13 04:01:50 <blockchain> hello guys
211 2015-01-13 04:05:58 <mr_burdell> I heard there's a guy that goes by MagicalTux that knows PHP
212 2015-01-13 04:06:03 <mr_burdell> oh, he left
213 2015-01-13 04:44:06 <coinucopia> will adding "paytxfee=0.0001" to bitcoin.conf mean that all tx will be sent with at least a .0001 BTC tx fee?
214 2015-01-13 05:41:48 <earlz> Why does the blockheader code use uint32_t for all data types, while the block index code uses `unsigned int` and such?
215 2015-01-13 05:44:55 <phantomcircuit> er
216 2015-01-13 05:44:56 <phantomcircuit> "blocks" : 338247,
217 2015-01-13 05:44:56 <phantomcircuit> "headers" : 338221,
218 2015-01-13 05:44:58 <phantomcircuit> wat
219 2015-01-13 05:45:08 <phantomcircuit> sipa, ^
220 2015-01-13 05:52:46 <phantomcircuit> earlz, ?
221 2015-01-13 05:53:44 <earlz> lol I'm still learning.. no idea about that
222 2015-01-13 06:52:46 <devrandom> michagogo: I think so, but I haven't tried
223 2015-01-13 07:23:29 <jonasschnelli> needs GUI tag: https://github.com/bitcoin/bitcoin/pull/5649 and https://github.com/bitcoin/bitcoin/pull/5651
224 2015-01-13 07:54:32 <jonasschnelli> needs GUI tag: https://github.com/bitcoin/bitcoin/issues/5650, https://github.com/bitcoin/bitcoin/issues/5653
225 2015-01-13 08:41:26 <michagogo> coinucopia: yes, but I think that's per kb
226 2015-01-13 08:41:53 <michagogo> Not sure whether it rounds up or does the math on that, though
227 2015-01-13 08:43:18 <wumpus> jonasschnelli: any GUI pulls that can be merged?
228 2015-01-13 08:43:32 <jonasschnelli> wumpus, let me check
229 2015-01-13 08:43:39 <michagogo> PRab: on my phone ATM so can't easily check the hashes and signature, but LGTM
230 2015-01-13 08:44:10 <jonasschnelli> i would say https://github.com/bitcoin/bitcoin/pull/5489 can be merged...
231 2015-01-13 08:44:49 <jonasschnelli> wumpus, https://github.com/bitcoin/bitcoin/pull/5144 is ready for merge
232 2015-01-13 08:47:51 <jonasschnelli> wumpus, rest of the PR will need more testing and confirmation
233 2015-01-13 08:48:04 <jonasschnelli> (i mean the GUI labels PRs)
234 2015-01-13 08:48:24 <wumpus> earlz: serialization relies on in-memory sizes of types, so anything used with serialization *must* use [u]int8_t, [u]int16_t, [u]int32_t, [u]int64_t, float or double.
235 2015-01-13 08:49:08 <wumpus> jonasschnelli: OK thanks
236 2015-01-13 09:31:46 <fanquake> jonasschnelli Is the optimize png pull now outputting the same for everyone?
237 2015-01-13 09:32:00 <jonasschnelli> fanquake, i assume.
238 2015-01-13 09:32:24 <jonasschnelli> fanquake, pngcrush -brute will give the same output for everyone i guess.
239 2015-01-13 09:32:40 <jonasschnelli> fanquake, you can give it a shot if you like... (we can compare sha256)
240 2015-01-13 09:32:42 <fanquake> Will test it this arvo
241 2015-01-13 09:35:12 <sipa> earlz: a block header is a protocol data structure with exact encodings, so it must use types of exact size; index entries are memory only
242 2015-01-13 09:35:28 <sipa> phantomcircuit: that looks wrong; can you reproduce?
243 2015-01-13 09:58:11 <wumpus> jonasschnelli: hmm, just adding set -e at the top will make the png strip script fail on the diff (which has a non-zero return value)
244 2015-01-13 09:58:43 <jonasschnelli> wumpus, will review and overhaul it
245 2015-01-13 09:59:11 <jonasschnelli> wumpus, it needs also a better output. List of png with sha256 would be good
246 2015-01-13 09:59:14 <jonasschnelli> (to compare)
247 2015-01-13 09:59:18 <wumpus> I'm not convinced that diff ther is necessary anyway
248 2015-01-13 09:59:26 <wumpus> exactly; it is too noisy
249 2015-01-13 10:00:20 <wumpus> not that it's worth spending too much time on, but printing one line per processed image (with the old and new sha256 and size) would be nice
250 2015-01-13 10:10:45 <wumpus> jonasschnelli: also: you're no longer processing e.g. the spinner images, just src/qt/res/icons, is that intended?
251 2015-01-13 10:12:42 <wumpus> another tip: `git ls-files \*.png` may be useful
252 2015-01-13 10:13:23 <wumpus> this avoids descending into e.g. the fractal nightmare beneath depends, which might contain an extracted qt with loots of images :-)
253 2015-01-13 10:13:25 <jonasschnelli> wumpus, no the spinners must also be included. Will include these as well.
254 2015-01-13 10:13:55 <jonasschnelli> yes. we need to have it to produce stable output. will work on it soon
255 2015-01-13 10:14:20 <wumpus> well this would make it process just the png files known to git
256 2015-01-13 10:15:58 <jonasschnelli> wumpus, hmm... yes. I think this make sense.
257 2015-01-13 10:16:22 <wumpus> I'm not sure what you mean by stable output, but determinitic output is a rabbit hole too deep: I've e.g. already noticed that my pngcrush crushes better than your pngcrush
258 2015-01-13 10:17:37 <jonasschnelli> wumpus, meh. Is it? But i guess the script don't need to produce deterministic stable output... it's just a optimize once thing. Other optimization should only cover new added images.
259 2015-01-13 10:17:46 <jonasschnelli> or significant more optimized images.
260 2015-01-13 10:21:01 <wumpus> e.g. your about.png is 4006 bytes, mine is 2723 bytes, apart from that one my output is consistenly a few bytes (50<N<100) smaller
261 2015-01-13 10:21:18 <wumpus> what if you commit the script and I'll commit the result?
262 2015-01-13 10:21:46 <wumpus> not that it's a big deal :)
263 2015-01-13 10:25:52 <jonasschnelli> wumpus, yes. totally fine with that. But first i'd like to take a closer look at it... maybe i switch pngcrush to the tool gmaxwell proposed..
264 2015-01-13 10:26:13 <mbelshe_> hey guys - looking for some help clearing a transaction. anyone have insight into why this tx is not clearing? https://blockchain.info/tx/2861aa70a24364a35143ced4c5906167bae67b2cbba53ea5a3f1b5251ac7844f
265 2015-01-13 10:28:40 <rubensayshi> mbelshe_,
266 2015-01-13 10:28:58 <rubensayshi> you should ask that in #bitcoin not in #bitcoin-dev, but anyway, as you can see here (https://www.blocktrail.com/BTC/tx/2861aa70a24364a35143ced4c5906167bae67b2cbba53ea5a3f1b5251ac7844f) it marks it as 'no fee'
267 2015-01-13 10:29:30 <wumpus> jonasschnelli: FYI from --help output: "pngcrush 1.7.65" "and zlib version 1.2.8" "png.h version: 1.2.49" "png.c version: 1.2.50" "It was compiled with gcc version 4.8.2"
268 2015-01-13 10:29:53 <mbelshe_> @rubensayshi: thanks. yes, accidentally used it as an input and now need it to go through. seems like it has priority enough.
269 2015-01-13 10:30:33 <rubensayshi> mbelshe_, blocktrail should say "high priority" if it was (I build it)
270 2015-01-13 10:32:23 <mbelshe_> @rubensayshi: thanks. indeed blocktrail does not say that :-) i guess the blockchain.info report is not to be trusted. does blocktrail compute the actual priority and display it somewhere?
271 2015-01-13 10:32:48 <ThomasZ> can someone point me to the compile instructions on Windows?
272 2015-01-13 10:33:23 <ThomasZ> how do I get a visual studio file, or any other windows-compatible buildsystem.
273 2015-01-13 10:33:47 <rubensayshi> no, mbelshe_ but it will in 5 minutes ;-)
274 2015-01-13 10:34:05 <mbelshe_> @rubensayshi: very cool :-)
275 2015-01-13 10:34:07 <jonasschnelli> wumpus, i run version '1.7.80' libpng version 1.6.14, gcc version 4.2.1 (zlib not mentioned)
276 2015-01-13 10:34:17 <fanquake> thomasz there are no compile instructions for windows at present
277 2015-01-13 10:35:00 <ThomasZ> fanquake: any hints? Obviously I can't use autoreconf...
278 2015-01-13 10:35:39 <fanquake> ThomasZ Maybe #1401, or on the forum.
279 2015-01-13 10:36:10 <wumpus> in theory at least it should be possible to use depends+autoconf on msys2, but I don't think anyone ever worked through that
280 2015-01-13 10:36:42 <wumpus> cross-compile is the recommended (and easiest, certainly with depends) way to create windows executables
281 2015-01-13 10:37:58 <wumpus> (e.g., making win64 executables is as easy as: cd depends; make HOST=i686-w64-mingw32; cd ..; ./configure --prefix=`pwd`/depends/i686-w64-mingw32; make )
282 2015-01-13 10:39:39 <wumpus> (you also need the toolchain,e.g. apt-get install g++-mingw-w64 mingw-w64 )
283 2015-01-13 10:40:57 <ThomasZ> wumpus: ehm, This is a windows8.1 machine.
284 2015-01-13 10:41:12 <ThomasZ> With visual studio and related toolchains.
285 2015-01-13 10:41:24 <wumpus> as said, cross-compile is the recommended way to make windows executables
286 2015-01-13 10:41:28 <wumpus> anything else and you're on your own
287 2015-01-13 10:41:49 <ThomasZ> why did you drop the buildsystem that supported Windows builds?
288 2015-01-13 10:41:51 <wumpus> it may be possible to run depends with the native compiler of msys2
289 2015-01-13 10:42:05 <wumpus> but as far as I know no one worked through that ever
290 2015-01-13 10:42:15 <ThomasZ> in favour of the only one that really will never work on Windows :D
291 2015-01-13 10:42:31 <wumpus> well, it can certainly work
292 2015-01-13 10:43:07 <wumpus> but msys2 shell has some irregularities so it's not guaranteed to work as-is at it is now
293 2015-01-13 10:43:13 <ThomasZ> automake on Windows? Unlikely. CMake or similar is what you need for cross-platform development.
294 2015-01-13 10:43:32 <ThomasZ> sure; I get checking for non-GNU ld... no configure: error: no acceptable ld found in $PATH
295 2015-01-13 10:43:43 <wumpus> no, automake can work on windows, but it could need some extra work
296 2015-01-13 10:45:05 <ThomasZ> ok, well, interesting choice of buildsystem. Thanks for the info.
297 2015-01-13 10:51:50 <jonasschnelli> ThomasZ, i do windows cross compile on ubuntu with 'cd depends; make HOST=i686-w64-mingw32; cd ..; ./configure --prefix=`pwd`/depends/i686-w64-mingw32'
298 2015-01-13 10:52:16 <rubensayshi> mbelshe_, priority is 48,682,784 (need 57,600,000 for high priority) - working on the UI to display it :D
299 2015-01-13 10:52:30 <fanquake> unfortunately that doesnât work on osx.
300 2015-01-13 10:52:34 <mbelshe_> @rubensayshi: thanks!
301 2015-01-13 10:53:09 <jonasschnelli> fanquake, you can use a ubuntu vm on osx
302 2015-01-13 10:53:22 <wumpus> fanquake: why not?
303 2015-01-13 10:54:36 <wumpus> fanquake: should work on any unix-ish OS, only dependency is a mingw-w64 cross toolchain
304 2015-01-13 10:54:52 <fanquake> wumpus error: provided command 'i686-w64-mingw32-g++' not found when it tries to compile boost
305 2015-01-13 10:55:13 <wumpus> fanquake: right, so you don't have the g++ compiler (or it's named differently?)
306 2015-01-13 10:55:44 <jonasschnelli> ThomasZ, i think it's not useful to discuss general thing in pull requests; regarding 5625
307 2015-01-13 10:55:56 <wumpus> fanquake: there is work underway to also include scripts to build the toolchain
308 2015-01-13 10:56:20 <wumpus> fanquake: (as that'd allow deterministic building using just a 'golden' toolchain, and no more need for a VM)
309 2015-01-13 10:56:37 <jonasschnelli> ThomasZ, you might continue the discussion there: https://github.com/bitcoin/bitcoin/pull/5219
310 2015-01-13 10:56:40 <fanquake> wumpus, definitely have g++ Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
311 2015-01-13 10:56:54 <wumpus> fanquake: yes but do you have a *cross* gcc for mingw-w64?
312 2015-01-13 10:57:56 <jonasschnelli> ThomasZ, our 'mailinglist' for GUI stuff is more or less github, you can easily "watch" the bitcoin/bitcoin repository and see what's going on.
313 2015-01-13 10:58:07 <fanquake> wumpus Iâd assume not then.
314 2015-01-13 10:58:37 <jonasschnelli> fanquake, i would recommend you to use a ubuntu vm rather then trying to cross build on osx. It can be a rabbit hole.
315 2015-01-13 10:59:36 <jonasschnelli> if you have a nice SSD and around >16GB of ram, vm up and down is pretty easy and fast. Ubuntu startup from hibernated state take around 5s.
316 2015-01-13 11:00:33 <fanquake> jonasschnelli Dunno how nice my SSD is, but Iâve got 16GB.
317 2015-01-13 11:00:43 <fanquake> Iâll spin up a VM tonight then.
318 2015-01-13 11:00:57 <wumpus> jonasschnelli: hm it looks like my pngcrush actually corrupts about.png (verified with the simple script here https://gist.github.com/laanwj/dec1ac25d7aa805f0fad ), so it's cheating :(
319 2015-01-13 11:01:41 <jonasschnelli> wumpus, ah. thats a nice idea. Verifying the output after the optimize/crush.
320 2015-01-13 11:01:43 <wumpus> jonasschnelli: the challenge to create the smallest PNG file is only valid as long as the result is lossless
321 2015-01-13 11:02:05 <jonasschnelli> wumpus, yes. PNG should be non-destructive with standard parameters
322 2015-01-13 11:02:18 <sinetek> ubuntu itself works pretty well on a mac
323 2015-01-13 11:02:35 <jonasschnelli> wumpus, i also think image-magick can maybe be removed because png-crush will probably also remove ICC profiles.
324 2015-01-13 11:02:38 <wumpus> jonasschnelli: (although, thinking of it, it may be doing something harmless like change pixels with alpha=0)
325 2015-01-13 11:02:45 <wumpus> jonasschnelli: good point
326 2015-01-13 11:03:12 <jonasschnelli> so i will overhaul the script with proper output, use of one-tool only if possible and some verifying
327 2015-01-13 11:04:07 <wumpus> jonasschnelli: this is so much easier to with with a python script
328 2015-01-13 11:04:28 <jonasschnelli> and color profile are not by default bad. That's why i'm not sure about the `git ls-files \*.png`
329 2015-01-13 11:04:55 <jonasschnelli> wumpus, yes. i'll switch to python. Bash is cool but takes endless time.
330 2015-01-13 11:05:37 <wumpus> bash script is kludgy, very hard to make robust, and without a lot of hardening croaks on spaces in directory names and such
331 2015-01-13 11:06:12 <wumpus> jonasschnelli: well you could filter just the directories that make sense (e.g. movies and icons)
332 2015-01-13 11:06:55 <jonasschnelli> wumpus, Yes. Good idea.
333 2015-01-13 11:07:37 <wumpus> then again that *is* almost all our png files
334 2015-01-13 11:08:04 <wumpus> (well, excluding doc/ makes sense)
335 2015-01-13 11:08:21 <wumpus> what about just including src/qt/*?
336 2015-01-13 11:09:54 <wumpus> or, even, src/qt/res/, as that's where all the resources are
337 2015-01-13 11:10:32 <jonasschnelli> wumpus, yes. would make sense. But the bitcoin.png (Large Icon) has valid ICC profile for further editing. But also works without... maybe people adding png in future in res/img/src/
338 2015-01-13 11:11:26 <jonasschnelli> IMO: best would be src/res/icons, src/res/images, src/res/movies
339 2015-01-13 11:11:55 <wumpus> jonasschnelli: files for further ediiing should *not* be beneath res
340 2015-01-13 11:12:07 <wumpus> jonasschnelli: there's good reason to keep those separated
341 2015-01-13 11:12:09 <jonasschnelli> wumpus, thought the same a minute ago. :)
342 2015-01-13 11:12:28 <wumpus> in most cases the 'original editing format' will not be png
343 2015-01-13 11:12:38 <jonasschnelli> wumpus, i'll check if the profile make sense and if yes, i'll move it (a copy) to src
344 2015-01-13 11:13:00 <jonasschnelli> png could be totally suitable for editing (see adobe fireworks)
345 2015-01-13 11:13:21 <jonasschnelli> they include layers, vector elements, etc. into the png binary
346 2015-01-13 11:13:44 <jonasschnelli> and it's getting more and more accepted as src format
347 2015-01-13 11:13:51 <jonasschnelli> (next to svg/psd, etc)
348 2015-01-13 11:15:01 <wumpus> jonasschnelli: sure, I'm not saying it is impossible to include all kinds of funny sections in a PNG and use it as editing format, but indeed it should be separate from what gets included into the binary which are post-processed to be as small as possible
349 2015-01-13 11:15:22 <jonasschnelli> yes. totally.
350 2015-01-13 11:17:01 <wumpus> ah and right now, the 'source images' are under src/qt/res/src. Yes it makes sense to exclude that, then.
351 2015-01-13 11:17:18 <wumpus> a better directory structure could help but one thing at a time
352 2015-01-13 11:17:46 <wumpus> ACK on src/qt/res/icons, src/qt/res/images, src/qt/res/movies
353 2015-01-13 11:22:27 <jonasschnelli> wumpus, i'll go with 'find' rather then with 'git ls-files' because we might prefer including also non-added files. Or what do you think?
354 2015-01-13 11:24:21 <wumpus> jonasschnelli: something could be said for both, if you restrict the directories to just files directly underneath the mentioned directories (no recursive descent) I'm OK with not asking git
355 2015-01-13 11:24:46 <jonasschnelli> okay
356 2015-01-13 11:24:51 <wumpus> s/restrict the directories/restrict the affected files/
357 2015-01-13 11:26:26 <wumpus> (e.g. just use os.listdir or glob.glob instead of a find)
358 2015-01-13 11:26:45 <jonasschnelli> okay
359 2015-01-13 12:26:14 <kurzalevski> is there a way to get a -1 confirmation transaction on testnet in order to reproduce a case from production?
360 2015-01-13 12:27:04 <wumpus> kurzalevski: yes, -1 confirmations happen when there is a conflicted transaction
361 2015-01-13 12:27:12 <wumpus> kurzalevski: (at least with bitcoin core's wallet)
362 2015-01-13 12:27:57 <wumpus> kurzalevski: see e.g. qa/rpc-tests/conflictedbalance.py
363 2015-01-13 12:28:55 <kurzalevski> its conflictedbalance.sh?
364 2015-01-13 12:29:15 <wumpus> yes, sh
365 2015-01-13 12:29:29 <wumpus> it the odd duck out, still needs to be converted to python some time
366 2015-01-13 12:30:03 <kurzalevski> it will take me forever to clear the steps i have to take in order to reproduce it
367 2015-01-13 12:30:10 <kurzalevski> can you give me a hint how to do it?
368 2015-01-13 12:30:18 <wumpus> just follow that script/
369 2015-01-13 12:30:42 <wumpus> it results in a regtest wallet with conflicted transactions
370 2015-01-13 12:31:13 <kurzalevski> i just run it?
371 2015-01-13 12:31:31 <wumpus> that'd be easiest?
372 2015-01-13 12:32:09 <kurzalevski> sorry, im not a dev and asking silly questions is my way to figure things out
373 2015-01-13 12:34:31 <kurzalevski> and if im using binary ?
374 2015-01-13 12:35:26 <kurzalevski> there's no qa folder in the bitcoind dir as it's the binary from bitcoin.org
375 2015-01-13 12:36:59 <wumpus> you need to check out git to get the qa tests (eg git clone -bv0.9.4 https://github.com/bitcoin/bitcoin), though you can use them with the pre-compiled executable if you want
376 2015-01-13 12:38:00 <kurzalevski> how do i use them with the precompiled executable?
377 2015-01-13 12:38:22 <kurzalevski> im on centos 6.5 if thaats relevant
378 2015-01-13 12:40:01 <wumpus> make sure the BITCOIND and CLI variables in the script refer to your bitcoind and bitcoin-cli
379 2015-01-13 12:40:07 <jonasschnelli> kurzalevski, you could try use them with the precompiled binary by placing them into the src folder...
380 2015-01-13 12:40:37 <kurzalevski> okay lemme try that
381 2015-01-13 12:40:49 <wumpus> e.g. export BITCOIND=/path/to/bitcoind export CLI=/path/to/bitcoin-cli
382 2015-01-13 12:41:01 <jonasschnelli> i assume if src/bitcoind and src/bitcoin-cli are there, you can run qa/pull-tester/rpc-tests.sh
383 2015-01-13 12:41:09 <jonasschnelli> an no.. you like to run a sh script
384 2015-01-13 12:41:18 <jonasschnelli> just execute the sh script then
385 2015-01-13 12:41:28 <jonasschnelli> or follow wumpus solution
386 2015-01-13 12:41:32 <wumpus> jonasschnelli: sure, it will find them there too
387 2015-01-13 12:42:16 <wumpus> eh or not: echo "Usage: $0 path_to_binaries"
388 2015-01-13 12:42:22 <wumpus> it helps to read the help message :-)
389 2015-01-13 12:42:38 <wumpus> you can just provide the path to the binaries, voila
390 2015-01-13 12:43:09 <jonasschnelli> ha.
391 2015-01-13 12:43:28 <michagogo> wumpus: do you know if we're doing the OS X detached sig thing this time for rc3? (I asked this yesterday, don't think I got an answer)
392 2015-01-13 12:43:31 <jonasschnelli> will convert this last test soon...
393 2015-01-13 12:43:34 <jonasschnelli> to python
394 2015-01-13 12:43:44 <wumpus> michagogo: I don't know, better to ask cfields
395 2015-01-13 12:43:52 <michagogo> cfields: do you know if we're doing the OS X detached sig thing this time for rc3? (I asked this yesterday, don't think I got an answer)
396 2015-01-13 12:44:06 <wumpus> michagogo: I can't do anything osx-related
397 2015-01-13 12:44:53 <michagogo> wumpus: actually, isn't it probably better to ask gavinandresen, since he's the one with the key? I think last time the answer was "no because Gavin's busy" or something
398 2015-01-13 12:47:51 <jonasschnelli> michagogo, can i run gbuild as root?
399 2015-01-13 12:48:03 <michagogo> jonasschnelli: can you? I don't know.
400 2015-01-13 12:48:07 <sipa> jonasschnelli: why would you?
401 2015-01-13 12:48:17 <michagogo> But there's no reason to
402 2015-01-13 12:48:19 <jonasschnelli> sipa, because i'm lazy . :)
403 2015-01-13 12:48:21 <wumpus> don't run things as root
404 2015-01-13 12:48:24 <sipa> bad reason
405 2015-01-13 12:48:27 <michagogo> jonasschnelli: huh?
406 2015-01-13 12:48:44 <jonasschnelli> okay. was a bad idea... let me check my permissions issues
407 2015-01-13 12:48:56 <wumpus> especially not fickle ruby scripts that copy and move files all over the place
408 2015-01-13 12:49:27 <michagogo> If you mean the sudo password prompts, just use sudoers to exempt yourself from a password for lxc-start/lxc-execute
409 2015-01-13 12:49:43 <michagogo> wumpus: not even Ruby, a hybrid of bash and ruby scripts that call each other
410 2015-01-13 12:49:46 <jonasschnelli> is there a gist or something with the expected output signatures of the rc2 build?
411 2015-01-13 12:49:52 <michagogo> jonasschnelli: no, don't build rc2
412 2015-01-13 12:49:57 <michagogo> rc2 doesn't match
413 2015-01-13 12:50:02 <jonasschnelli> okay...
414 2015-01-13 12:50:03 <michagogo> Use rc3 instead
415 2015-01-13 12:50:51 <michagogo> (rc3 is identical to rc2, except for the one-line change that makes it match)
416 2015-01-13 12:51:21 <wumpus> jonasschnelli: the gitian.sigs repository?
417 2015-01-13 12:51:49 <michagogo> But to answer the question, existing sigs are at https://github.com/bitcoin/gitian.sigs
418 2015-01-13 12:51:53 <wumpus> although not many people committed their rc2 sigs, as no single pair of them matched
419 2015-01-13 12:52:08 <michagogo> (btw, there's another PR open, https://github.com/bitcoin/gitian.sigs/pull/77)
420 2015-01-13 12:52:12 <wumpus> (you should, if you build you should always commit the sigs, even if they don't match)
421 2015-01-13 12:52:27 <wumpus> (*especially* if they don't match)
422 2015-01-13 12:52:57 <wumpus> but yes rc2 was a misfire
423 2015-01-13 12:53:20 <michagogo> ACTION didn't commit rc2 sigs because he was building 0.9.4, and rc2 was found to be broken before he had a chance to start building it
424 2015-01-13 12:53:59 <wumpus> michagogo: sure, no problem, just talking in general
425 2015-01-13 12:54:30 <jonasschnelli> okay. My user missed the KVM permissions.
426 2015-01-13 12:54:37 <kurzalevski> wumpus, i exported those two variables and followed the "Usage:" by specifying the bitcoind executable path but i get the following error - > Error: Specified data directory "test.fePCP/node1" does not exist.
427 2015-01-13 12:54:47 <kurzalevski> looping
428 2015-01-13 12:55:13 <wumpus> kurzalevski: weird, it is supposed to create data directories for you
429 2015-01-13 12:56:13 <michagogo> oh, KVM
430 2015-01-13 12:56:38 <jonasschnelli> michagogo, so KVM will produce the same sigs a LXC i guess?
431 2015-01-13 12:56:45 <michagogo> jonasschnelli: that's the idea
432 2015-01-13 12:57:02 <jonasschnelli> okay, .. its building right now, lets see then.
433 2015-01-13 12:57:12 <michagogo> It's broken a few times (permissions issues, for example), but it should be working atm I think
434 2015-01-13 12:57:46 <kurzalevski> wumpus, it did, however they are empty and as i said the error message is still going
435 2015-01-13 12:59:40 <wumpus> michagogo: btw, https://github.com/bitcoin/gitian.sigs/pull/26 seems kind of stuck
436 2015-01-13 13:02:33 <jonasschnelli> getting gitian errors: WARNING: The following packages cannot be authenticated!
437 2015-01-13 13:02:47 <jonasschnelli> lib32gcc1 lib32gomp1 lib32quadmath0 gcc-4.6-multilib gcc-multilib, etc.
438 2015-01-13 13:05:36 <jonasschnelli> was a one-time error, no it works
439 2015-01-13 13:08:51 <wumpus> distribution keyrings issue
440 2015-01-13 13:09:07 <wumpus> luckily it has an insecure fallback to just continue
441 2015-01-13 13:10:00 <jonasschnelli> but now gitian seams to stuck after "ldconfig deferred processing now taking place"
442 2015-01-13 13:11:44 <michagogo> wumpus: heh, forgot about that
443 2015-01-13 13:11:51 <michagogo> jonasschnelli: are you tailing install.log?
444 2015-01-13 13:12:19 <michagogo> check gitian's output, there should be more there now
445 2015-01-13 13:12:24 <michagogo> wumpus: stuck how?
446 2015-01-13 13:13:29 <wumpus> michagogo: well, it's still open and not moving forward
447 2015-01-13 13:13:39 <michagogo> ah
448 2015-01-13 13:13:50 <michagogo> well, do you know git, and how those files work?
449 2015-01-13 13:13:53 <wumpus> michagogo: at some point we'll have to either merge it or not merge it
450 2015-01-13 13:14:04 <wumpus> I know git, but not that specific flag
451 2015-01-13 13:15:16 <michagogo> looking at http://git-scm.com/docs/gitattributes, it *should* do what it's supposed to, I think
452 2015-01-13 13:15:53 <michagogo> "Unsetting the text attribute on a path tells Git not to attempt any end-of-line conversion upon checkin or checkout."
453 2015-01-13 13:16:34 <michagogo> Which is what we need, because the asserts need to be keps exactly as-is
454 2015-01-13 13:17:27 <michagogo> Actually
455 2015-01-13 13:17:53 <michagogo> maybe it should just match *.assert*?
456 2015-01-13 13:18:21 <jonasschnelli> michagogo, wumpus ... never mind. it was running.
457 2015-01-13 13:18:31 <michagogo> jonasschnelli: yeah, that's what I thought
458 2015-01-13 13:18:47 <kurzalevski> wumpus, couldnt get it to work, seems that i'll have to get the source from github
459 2015-01-13 13:18:47 <michagogo> I recognized that as the last line in install.log before the next step happens
460 2015-01-13 13:18:50 <kurzalevski> thank you for your time man
461 2015-01-13 13:19:41 <wumpus> kurzalevski: you're using version 0.9.3/0.9.4?
462 2015-01-13 13:19:55 <wumpus> as using the tests of the wrong version won't work
463 2015-01-13 13:21:49 <kurzalevski> 094
464 2015-01-13 13:23:53 <jonasschnelli> kurzalevski, notice that the conflictedbalance.sh script probably won't run without errors.
465 2015-01-13 13:24:37 <jonasschnelli> IMO: the test is broken and misses awareness of potential fees
466 2015-01-13 13:25:08 <kurzalevski> anyways, is there another way to generate -1 transaction ?
467 2015-01-13 13:25:13 <jonasschnelli> why do you wan't to use this?
468 2015-01-13 13:25:59 <wumpus> sure, you could manually go around mutating transactions, using the script would just be the easy way
469 2015-01-13 13:26:02 <jonasschnelli> follow the scripts logic
470 2015-01-13 13:26:12 <jonasschnelli> i assume the magic lies in : MUTATEDTX_C=${RAWTX_C:0:82}${NEWLEN}4c${RAWTX_C:84}
471 2015-01-13 13:26:19 <kurzalevski> fuck me : D
472 2015-01-13 13:28:21 <jonasschnelli> kurzalevski, more or less, you should be able to use line 118 till 122 if you did load a raw tx over 'getrawtransaction' into $RAWTX_C
473 2015-01-13 13:30:59 <kurzalevski> i'll try it now
474 2015-01-13 13:37:24 <michagogo> wumpus: I updated it to only exclude *assert*, so README gets converted (or not) however the user decides to have that set up
475 2015-01-13 13:37:41 <michagogo> But as far as I can tell, that *should* work
476 2015-01-13 13:38:13 <michagogo> (rebased, too)
477 2015-01-13 13:39:13 <maaku> will an invalid block ever be written to disk?
478 2015-01-13 13:39:46 <maaku> or put differently, can I parse blk*.dat files with SPV semantics, and assume the most work is the best valid block?
479 2015-01-13 13:41:05 <wumpus> maaku: with headers-first and out-of-order download, there's no guarantee that blocks are completely validated before writing them to disk
480 2015-01-13 13:42:00 <wumpus> but as headers are validated you will get SPV-level security
481 2015-01-13 13:43:10 <maaku> hrm. what about pre-headersfirst?
482 2015-01-13 13:43:18 <wumpus> what the linearize script does is ask bitcoind for the list of hashes of the best chain
483 2015-01-13 13:43:21 <wumpus> https://github.com/bitcoin/bitcoin/blob/master/contrib/linearize/linearize-hashes.py
484 2015-01-13 13:43:56 <maaku> hrm that's an option. maybe i'll just run linearize.py first for this application
485 2015-01-13 13:43:59 <wumpus> then use that to determine what blocks to let through
486 2015-01-13 13:44:38 <wumpus> (and also, put them in the right order)
487 2015-01-13 13:45:51 <wumpus> asking bitcoind for the hashes is quite fast with RPC batching
488 2015-01-13 13:46:15 <michagogo> maaku: and then you can look at linearize-data.py to see how it handles the blocks, if you need ideas
489 2015-01-13 13:46:24 <michagogo> (it reads directly from disk)
490 2015-01-13 13:46:29 <wumpus> yes
491 2015-01-13 13:48:18 <maaku> thanks
492 2015-01-13 13:51:57 <jonasschnelli> can anyone explain this shell script fragment? NEWLEN=$( printf "%x" $(( 16#$L + 1 )) )?
493 2015-01-13 13:52:12 <jonasschnelli> (try to rewrite this in python)
494 2015-01-13 13:53:00 <wumpus> whoa
495 2015-01-13 13:53:03 <jonasschnelli> does it a create a hex representation of $L+1?
496 2015-01-13 13:53:31 <wumpus> it interprets L as a hexadecimal number, adds 1 to it, and formats the result as hex?
497 2015-01-13 13:54:02 <wumpus> eg just hex(l+1), or "%x" % (l+1) , given that you (sanely) keep the number as just a number in python :)
498 2015-01-13 13:54:17 <jonasschnelli> okay. i'll try
499 2015-01-13 13:54:35 <wumpus> at least, only convert to hex where it's used
500 2015-01-13 13:55:05 <jonasschnelli> it's some manipulating of a raw transactions hex output
501 2015-01-13 13:55:17 <jonasschnelli> should then be easy in py
502 2015-01-13 14:00:46 <Luke-Jr> wumpus: QChar would require a global or static identifier, wouldn't be combineable with string concatenation, is inconsistent with the existing UTF-8 code, and breaks at least one case a trinary op - do you still want me to try to do it?
503 2015-01-13 14:01:23 <wumpus> Luke-Jr: string concatentaion using QStrings should support a QChar fine
504 2015-01-13 14:01:35 <Luke-Jr> wumpus: I meant "abc" "def" style
505 2015-01-13 14:02:08 <wumpus> Luke-Jr: oh, right, well I don't know, I don't really care that much, as said QChar() is slightly more readable but your solution is just as correct.
506 2015-01-13 14:02:43 <Luke-Jr> for consistency, I'd prefer to merge as-is, and someone can QChar all the UTF-8 stuff later if desired
507 2015-01-13 14:03:20 <wumpus> yes
508 2015-01-13 14:04:28 <wumpus> there's even a bare unicode char here and there in the source (I think in units.cpp), that's bad- you escape it as bytes using \x12\x23\x... so that it doesn't rely on the compiler, so it is fine
509 2015-01-13 14:06:54 <wumpus> do make sure that the character doesn't make it into translation strings
510 2015-01-13 14:07:15 <wumpus> translators will likely replace it with something else (e.g. a tilde :p)
511 2015-01-13 14:08:08 <Luke-Jr> not sure how to check that
512 2015-01-13 14:09:11 <wumpus> well - make sure it's never passed to tr(...) - alternatively, run make translate and verify that it doesn't appear in bitcoin_en.ts
513 2015-01-13 14:12:55 <Luke-Jr> make: â No rule to make target 'translate'. Stop.
514 2015-01-13 14:14:09 <wumpus> Luke-Jr: hm, try in src
515 2015-01-13 14:14:54 <wumpus> also - â?
516 2015-01-13 14:16:53 <jonasschnelli> hmm... conflictbalance.sh is broken because of https://github.com/bitcoin/bitcoin/commit/307f7d48d4733da016bf73676f6ebff9144365c1
517 2015-01-13 14:21:24 <Luke-Jr> wumpus: can't find it in there
518 2015-01-13 14:21:30 <Luke-Jr> wumpus: what about â?
519 2015-01-13 14:21:44 <michagogo> wumpus: do we get PR binaries anymore? Or did we lose that with Travis?
520 2015-01-13 14:22:28 <Luke-Jr> michagogo: the latter
521 2015-01-13 14:22:39 <michagogo> :-/
522 2015-01-13 14:22:52 <jonasschnelli> Luke-Jr, why we not just write "Bytes: aprox. 226"?
523 2015-01-13 14:23:02 <Luke-Jr> jonasschnelli: too long?
524 2015-01-13 14:23:02 <michagogo> ACTION checks if he had cross-builds set up
525 2015-01-13 14:23:13 <jonasschnelli> meh. Plenty of space there.
526 2015-01-13 14:24:07 <Luke-Jr> jonasschnelli: what if I'm making a 1 GB transaction?
527 2015-01-13 14:24:10 <jonasschnelli> Luke-Jr, or even ca.
528 2015-01-13 14:24:19 <Luke-Jr> ca? wtf is ca? O.o
529 2015-01-13 14:24:22 <Luke-Jr> Canada?
530 2015-01-13 14:24:24 <jonasschnelli> :)
531 2015-01-13 14:24:37 <jonasschnelli> http://en.wikipedia.org/wiki/Circa
532 2015-01-13 14:25:09 <Luke-Jr> circa kinda implies a date
533 2015-01-13 14:26:17 <jonasschnelli> i would prefer s/~/approx. /
534 2015-01-13 14:26:45 <jonasschnelli> maybe its to long but i would first check the UI
535 2015-01-13 14:26:57 <jonasschnelli> because the double-tilde could confuse user?
536 2015-01-13 14:28:39 <jonasschnelli> gitian: is it normal to get a 'sha256sum: MacOSX10.7.sdk.tar.gz: No such file or directory' when compiling for mac? The MacOSX10.7.sdk.tar.gz is in my inputs
537 2015-01-13 14:28:44 <xabbix> Is there any way of solving the whole NAT 'issue' for bitcoin-core so that almost everyone who runs bitcoin-core will be a full node? Teamviewer for example, managed to somehow 'bypass' this issue.
538 2015-01-13 14:29:20 <Luke-Jr> xabbix: UPnP seems to work?
539 2015-01-13 14:29:56 <xabbix> Luke-Jr, yeah that should be working, right? How come there are so few full nodes then.. weird.
540 2015-01-13 14:30:00 <Luke-Jr> few?
541 2015-01-13 14:30:22 <Luke-Jr> how come = people have no patience
542 2015-01-13 14:31:04 <xabbix> ~6500 full nodes is pretty low
543 2015-01-13 14:31:41 <michagogo> jonasschnelli: that doesn't seem like it should happen
544 2015-01-13 14:31:48 <michagogo> Are you sure it's there?
545 2015-01-13 14:31:52 <michagogo> Named correctly?
546 2015-01-13 14:32:16 <jonasschnelli> michagogo, ls -la cache/common/MacOSX10.7.sdk.tar.gz -> 40635533 Jan 13 06:22 cache/common/MacOSX10.7.sdk.tar.gz
547 2015-01-13 14:32:28 <michagogo> jonasschnelli: no, that goes in inputs/
548 2015-01-13 14:32:31 <michagogo> not cache/common/
549 2015-01-13 14:33:09 <jonasschnelli> michagogo, grml. right. let try again
550 2015-01-13 14:34:48 <test__> hi, where can i download a compiled x64 exe for v 0.10 rc ?
551 2015-01-13 14:35:19 <xabbix> Luke-Jr, what do you mean by patience?
552 2015-01-13 14:35:27 <Luke-Jr> xabbix: initial blockchain sync
553 2015-01-13 14:35:32 <jonasschnelli> test__ ask Luke-Jr
554 2015-01-13 14:35:34 <xabbix> oh
555 2015-01-13 14:35:52 <Luke-Jr> he left already
556 2015-01-13 14:35:55 <fanquake> test__ https://bitcoin.org/bin/0.10.0/test/
557 2015-01-13 14:35:56 <xabbix> Luke-Jr, so this will improve with upcoming release
558 2015-01-13 14:36:22 <Luke-Jr> xabbix: hopefully
559 2015-01-13 14:36:34 <Luke-Jr> fanquake: that's outdated
560 2015-01-13 14:36:56 <fanquake> Arenât we pushing new rcâs up?
561 2015-01-13 14:37:27 <Luke-Jr> fanquake: nothing goes up without sufficient signatures
562 2015-01-13 14:37:45 <Luke-Jr> although rc3 has them by now..
563 2015-01-13 14:37:54 <fanquake> yes rc3 has plenty atm
564 2015-01-13 14:38:30 <fanquake> A few new contributors as well by the looks. Which is good to see.
565 2015-01-13 14:39:45 <jonasschnelli> soon one more. :) but building boost and qt takes ages...
566 2015-01-13 14:42:02 <jonasschnelli> gitian: while building osx the first time i got 'configure: error: C compiler cannot create executables' in build.log ... any ideas?
567 2015-01-13 14:42:45 <notaegis> I have a transaction stuck since yesterday so almost 24 hours
568 2015-01-13 14:43:22 <notaegis> Can anyone help?
569 2015-01-13 14:43:51 <jonasschnelli> notaegis, better at #bitcoin but did you gave your tx some fees?
570 2015-01-13 14:44:11 <notaegis> some fees, yes
571 2015-01-13 14:44:14 <notaegis> it wasn't 0
572 2015-01-13 14:44:27 <jonasschnelli> notaegis, your TX id?