1 2014-05-14 01:22:50 <aegis> Hi all...  Is something wrong with the network right now?
  2 2014-05-14 01:24:00 <gmaxwell> thats not a useful question.
  3 2014-05-14 01:30:23 <aegis> ;;tslb
  4 2014-05-14 01:30:30 <gribble> Time since last block: 7 minutes and 35 seconds
  5 2014-05-14 02:14:00 <warren> https://en.bitcoin.it/wiki/History apparently ended last year.
  6 2014-05-14 02:28:03 <Luke-Jr> warren: because we stopped caring at $100
  7 2014-05-14 02:52:03 <jaekwon> i haven't touched C++ in forever… does bitcoind use C++11?
  8 2014-05-14 03:05:53 <coryfields> warren: around?
  9 2014-05-14 03:05:54 <coryfields> jaekwon: no
 10 2014-05-14 03:06:39 <jaekwon> danke
 11 2014-05-14 03:06:45 <warren> coryfields: whats up
 12 2014-05-14 03:07:22 <coryfields> warren: would be great to get some builders for https://github.com/bitcoin/bitcoin/pull/4185
 13 2014-05-14 03:07:42 <coryfields> if you have anyone who is able
 14 2014-05-14 03:08:30 <coryfields> I haven't verified that the checksums line up with anyone else's yet (don't know of any reason why they wouldn't, though)
 15 2014-05-14 05:13:04 <michagogo> cloud|coryfields: is that a pr for gitian OS X?
 16 2014-05-14 05:13:48 <michagogo> cloud|If so, I'll check it out, maybe this afternoon/evening (currently 8:13 am)
 17 2014-05-14 10:37:23 <fanquake> ;;blocks
 18 2014-05-14 10:37:23 <gribble> 300680
 19 2014-05-14 10:51:25 <hearn> KuDeTa: to manage that many addresses with open source code - not sure it’s possible. you’d have to extend existing codebases. bitcoinj is being refactored as part of the hd wallets work to support pluggable key chains. a database backed key chain is certainly possible
 20 2014-05-14 12:47:25 <elichai2> which encryption algorithem bitcoin-qt use?
 21 2014-05-14 12:47:49 <t7> rot26
 22 2014-05-14 12:49:05 <elichai2> are you sure this is an encryption?
 23 2014-05-14 12:49:44 <t7> symmetric encryption
 24 2014-05-14 12:50:48 <elichai2> it's not a encoding?
 25 2014-05-14 12:51:35 <kinlo> elichai2: those questions might be better placed in #bitcoin, I'll answer them there if you ask them again there :)
 26 2014-05-14 12:51:44 <elichai2> ok lol sorry
 27 2014-05-14 12:58:13 <HaltingState> sipa, gmaxwell using ECDH, if I have someones public key P (private key p) , I can generate a public key Q with private key q; i send Q. they compute p*Q and I can compute q*P, which should be equal; that is the shared secret
 28 2014-05-14 12:58:37 <HaltingState> if i know someone's public key, i can send them a message encrypted using that shared secret, and only person with the private key should be able to read it
 29 2014-05-14 12:59:17 <HaltingState> if there way to show that a person knows the private key, without them producing a signature and that is not an online communication protocol like that?
 30 2014-05-14 13:01:32 <HaltingState> if i can communicate with them, obviously, i can just take their pubkey and send message like that and they can only read it if they know my private key or they know the private key for the pubkey and that proves to me that they have the private key; but if i took the communication and gave it to a third party, it would not prove to a third party that the response was created by someone with the private key
 31 2014-05-14 13:01:52 <elichai2> !me slaps t7
 32 2014-05-14 13:01:52 <gribble> Error: "me" is not a valid command.
 33 2014-05-14 13:01:56 <elichai2> 
ACTION slaps t7

 34 2014-05-14 13:01:59 <elichai2> lol
 35 2014-05-14 13:16:13 <michagogo> cloud|I find it confusing that people use notation like p*Q, q*P
 36 2014-05-14 13:16:47 <michagogo> cloud|When I first saw that, I was like, wait, can't you divide by Q to find p?
 37 2014-05-14 13:16:57 <epscy> yeh, mind your p's and q's
 38 2014-05-14 13:32:14 <saizai> hm, I think my host dropped that
 39 2014-05-14 13:32:19 <saizai> > any of y’all going to bitcoin2014?
 40 2014-05-14 13:33:23 <saizai> also, any of you happen to be in nyc or dc?
 41 2014-05-14 13:33:29 <saizai> would be nice to meet up irl
 42 2014-05-14 13:33:45 <saizai> (I’m traveling through both at the moment)
 43 2014-05-14 14:23:23 <arubi> hey, another user at #openssl just confirmed with me that he as able to reproduce a weird glitch in the openssl command line utility
 44 2014-05-14 14:23:57 <arubi> running `openssl ecparam -name secp256k1 -noout -text -genkey | openssl ec -text` , the hex private key is sometimes 32 bytes long, and sometimes 33 bytes long with leading '00'
 45 2014-05-14 14:24:49 <arubi> I don't know how important that is, but I figured I'd share
 46 2014-05-14 14:26:01 <Eremes> -bash: !2013: event not found
 47 2014-05-14 14:26:01 <Eremes> bitcoind walletpassphrase hello!2013 9999
 48 2014-05-14 14:26:09 <Eremes> how do i unlock my wallet ?
 49 2014-05-14 14:26:14 <Eremes> I have "!" in my password
 50 2014-05-14 14:26:21 <arubi> use quotes around the password
 51 2014-05-14 14:26:25 <Eremes> its worked on windows
 52 2014-05-14 14:26:31 <arubi> "pass word123"
 53 2014-05-14 14:26:41 <Eremes> let me try
 54 2014-05-14 14:27:09 <Eremes> can't
 55 2014-05-14 14:27:11 <Eremes> same result
 56 2014-05-14 14:27:14 <arubi> then add a
 57 2014-05-14 14:27:18 <arubi> \
 58 2014-05-14 14:27:26 <arubi> before the !
 59 2014-05-14 14:27:47 <Eremes> with " or not
 60 2014-05-14 14:27:51 <edcba> ^
 61 2014-05-14 14:27:53 <arubi> with
 62 2014-05-14 14:28:25 <edcba> oh it's bash...
 63 2014-05-14 14:28:32 <edcba> ^ would be for windows
 64 2014-05-14 14:28:38 <Eremes> its worked
 65 2014-05-14 14:28:45 <Eremes> with \
 66 2014-05-14 14:28:53 <arubi> great.
 67 2014-05-14 14:28:56 <Eremes> thanks
 68 2014-05-14 14:29:02 <Eremes> if I already encrypted my wallet.dat
 69 2014-05-14 14:29:04 <arubi> welcome
 70 2014-05-14 14:29:07 <Eremes> and my root password is strong
 71 2014-05-14 14:29:12 <Eremes> could someone steal my btc ?
 72 2014-05-14 14:29:16 <Eremes> its on VPS
 73 2014-05-14 14:29:38 <Eremes> both wallet & root access is very complicated pass
 74 2014-05-14 14:29:48 <arubi> this isn't the channel reall, let's talk in #bitcoin
 75 2014-05-14 14:30:03 <Eremes> ok
 76 2014-05-14 14:41:34 <coryfields> michagogo|cloud: (from backlog) yes.
 77 2014-05-14 14:42:18 <michagogo> cloud|coryfields: Ah, I forgot about that.
 78 2014-05-14 14:42:22 <michagogo> cloud|
ACTION fires up a vm

 79 2014-05-14 14:42:52 <michagogo> cloud|What was the name of the proprietary file from apple? OSX10.6.pkg or something?
 80 2014-05-14 14:43:32 <coryfields> MacOSX10.6.pkg
 81 2014-05-14 14:43:37 <michagogo> cloud|Thanks
 82 2014-05-14 14:43:47 <michagogo> cloud|
ACTION searches to make sure he still has it

 83 2014-05-14 14:44:14 <michagogo> cloud|Got it.
 84 2014-05-14 14:45:59 <michagogo> cloud|FYI: I'll be testing in a precise 64-bit vm
 85 2014-05-14 14:46:33 <coryfields> that's fine, but gitian has to be 32bit
 86 2014-05-14 14:46:48 <michagogo> cloud|Pretty sure I have both VMs built
 87 2014-05-14 14:47:31 <michagogo> cloud|BTW, are you keeping any files created unique with their names?
 88 2014-05-14 14:48:00 <michagogo> cloud|(should I set up a separate gitian environment in case of filename conflicts?)
 89 2014-05-14 14:48:44 <coryfields> not sure what you mean
 90 2014-05-14 14:48:47 <michagogo> cloud|Also: is the branch on that pull based off of master or 0.9.x or something similarly recent?
 91 2014-05-14 14:48:56 <michagogo> cloud|coryfields: things like rev numbers on deps
 92 2014-05-14 14:49:39 <coryfields> michagogo|cloud: those aren't set in stone until it's in merged. at that point, any change will require a bump
 93 2014-05-14 14:49:47 <coryfields> for now, yea, -rX.tar.gz are recycled
 94 2014-05-14 14:49:57 <michagogo> cloud|Okay. But are the files all new ones?
 95 2014-05-14 14:51:30 <coryfields> still not really sure what you mean. no output files conflict with any other builds, if that's what you're asking
 96 2014-05-14 15:24:22 <elichai2>  /j #javascript
 97 2014-05-14 15:24:29 <elichai2> ops
 98 2014-05-14 15:43:18 <posita> hearn: are you around?
 99 2014-05-14 15:43:23 <hearn> yup
100 2014-05-14 15:44:03 <posita> I know this is probably the wrong place to ask, but I can't seem to find the answer to this. Does bitcoinj accept non-standard mainnet transactions into its equivalent of the mempool?
101 2014-05-14 15:44:26 <hearn> it doesn’t have a mempool. or rather, confusingly, it has a class called MemoryPool, which does not do the same thing. i plan to rename it.
102 2014-05-14 15:44:35 <hearn> bitcoinj is not intended to be a full node so, it doesn’t listen or relay
103 2014-05-14 15:44:46 <posita> Ah, okay. That might be the source of my confusion. :-)
104 2014-05-14 15:45:00 <posita> Thanks. My apologies for bringing this up on dev.
105 2014-05-14 15:45:08 <hearn> it will accept non-standard txns in some cases into the wallet, if the remote node announces them. it doesn’t have a full IsStandard() implementation
106 2014-05-14 15:45:19 <hearn> it’s a dev question, no worries! but there’s also a #bitcoinj channel if you want to use it
107 2014-05-14 15:45:55 <posita> Fair enough. I will do that in the future. By "some cases" do you mean those that match the supported BIPs?
108 2014-05-14 15:46:14 <posita> Per: https://bitcoinj.github.io/bitcoin-standards
109 2014-05-14 15:46:38 <posita> (Actually most of those look standard to me.)
110 2014-05-14 15:47:01 <hearn> for instance it does not reject transactions with non-standard scripts
111 2014-05-14 15:47:40 <posita> From the remote node (i.e., once they're in the blockchain, everybody gets them)?
112 2014-05-14 15:48:11 <posita> Thanks for the walkthrough. My apologies if this was easily answered by the existing documentation.
113 2014-05-14 15:48:20 <hearn> right, if a loose tx is relayed that is non standard it’s only rejected in a few cases. and actually that code is buggy :)
114 2014-05-14 15:48:22 <hearn> so it needs work
115 2014-05-14 15:48:53 <posita> Do you remember off hand where that is? If I run into problems, I might be in a position to submit pull requests.
116 2014-05-14 15:48:58 <hearn> it’s probably not. the code assumes the remote node is doing IsStandard checks at the moment. that’s sort of normally true but occasionally false, and in general it should be done (repeated) client side for max security and decentralisation
117 2014-05-14 15:49:08 <hearn> DefaultRiskAnalysis
118 2014-05-14 15:49:24 <hearn> there’s a notion of a “risky” transaction. it’s only applied to pending / unconfirmed transactions.
119 2014-05-14 15:50:00 <hearn> the problem is, there’s a nasty bug. the wallet actually drops such transactions completely. it should keep them around but not count them for balance purposes and not list them by default. and eventually time them out, but not until a long time has passed.
120 2014-05-14 15:50:37 <hearn> or rather, sorry, it could do that. but at minimum it needs to keep them in memory for the current session. otherwise if they do get confirmed, the remote node won’t send us the tx data again and we’ll miss the tx
121 2014-05-14 15:50:43 <hearn> anyway i will fix this at some point
122 2014-05-14 15:51:51 <posita> I'll take a look. Who knows, maybe I can help with a fix? I'm assuming it doesn't have the ability to turn this "feature" off (e.g., via caller parameter)?
123 2014-05-14 15:52:40 <hearn> sure it can be turned off. you can override the risk analysis with one that simply accepts everything. then there’s no problem.
124 2014-05-14 15:52:51 <hearn> but then you have to deal with the 1Enjoy 1Sochi spam
125 2014-05-14 15:52:56 <hearn> the fix isn’t very complicated.
126 2014-05-14 15:53:14 <hearn> there’s just a million things to do and i have a lot on my plate
127 2014-05-14 15:53:34 <posita> Ah, I see re: replacing RiskAnalysis implementation (smacks forehead). Yes, of course.
128 2014-05-14 15:53:50 <posita> What do you mean? You don't seem busy at all! ;-)
129 2014-05-14 15:54:46 <hearn> 
ACTION has an IRC bot that emulates him very well :)

130 2014-05-14 15:59:21 <posita> http://www.oldtimeradiodownloads.com/sci-fi/X%20Minus%20One/Marionettes-Inc-December-21-1955-show-3969.html
131 2014-05-14 15:59:37 <posita> Not that you have time to listen to old timey radio shows…
132 2014-05-14 16:00:00 <posita> Like I said, I'll take a look and see what I can find/fix. I'm not looking at opening the floodgates, just adding support for an additional transaction pattern I've found useful. Something akin to: OP_IF 2 WWW XXX 2 OP_CHECKMULTISIGVERIFY OP_ELSE 2 YYY ZZZ 2 OP_CHECKMULTISIGVERIFY OP_ENDIF
133 2014-05-14 16:00:17 <posita> (There's probably a more efficient way to represent that, but it gets the idea across.)
134 2014-05-14 16:01:25 <hearn> well, add support where?
135 2014-05-14 16:01:34 <posita> Sorry, not adding support.
136 2014-05-14 16:01:38 <hearn> you don’t need to whitelist it in bitcoinj, as i said, because we don’t apply the IsStandard checks to begin with :-)
137 2014-05-14 16:01:44 <justanotheruser> posita: when does that evaluate to true? What's supposed to be in the scriptsig?
138 2014-05-14 16:01:54 <hearn> you need to whitelist it in bitcoin core. or, write an app that uses it on the testnet and then show everyone how awesome it is
139 2014-05-14 16:02:50 <posita> Right. Sorry. I didn't mean a whitelist approach. I think I'm talking about something else now (not the wallet losing transactions bug, but not replacing DefaultRiskAnalysis either).
140 2014-05-14 16:03:55 <posita> justanotheruser: 0 SIG_W SIG_X 1 -or- 0 SIG_Y SIG_Z 1
141 2014-05-14 16:03:57 <posita> (I think.)
142 2014-05-14 16:04:17 <posita> hearn: Will do (re: awesomeness). :-)
143 2014-05-14 16:04:26 <hearn> cool
144 2014-05-14 16:04:42 <posita> justanotheruser: Type. I meant: 0 SIG_W SIG_X 1 -or- 0 SIG_Y SIG_Z 0
145 2014-05-14 16:04:47 <posita> ^ Typo
146 2014-05-14 16:04:58 <posita> (I can't type apparently.)
147 2014-05-14 16:05:10 <justanotheruser> posita: 2 of 2 or another 2 of 2?
148 2014-05-14 16:05:15 <posita> Yes.
149 2014-05-14 16:05:24 <posita> An alternate pair of two parties.
150 2014-05-14 16:05:29 <posita> Not the same as 2-of-4.
151 2014-05-14 16:05:30 <hearn> what app is it for?
152 2014-05-14 16:05:46 <dabura667> I can't think of a use case... but seems like it would have one...
153 2014-05-14 16:06:56 <posita> Let's say you want release of funds for a child's college, but you want both parents' approval before the money gets released.
154 2014-05-14 16:07:14 <posita> You also want to allow for the possibility that the parents are no longer around, and the god parents are in charge.
155 2014-05-14 16:07:23 <posita> But you don't want one of the parents colluding with one of the godparents to release the money.
156 2014-05-14 16:07:35 <posita> That's a silly example, but illustrative.
157 2014-05-14 16:07:49 <justanotheruser> KeyA checksig keyB checksig and keyC checksig keyD checksig and or
158 2014-05-14 16:08:09 <justanotheruser> 7 opcodes and 4 keys
159 2014-05-14 16:08:51 <posita> justanotheruser: Yup. I knew there were more efficient ways to represent that. (I guess that would most often be the case with X-of-X transactions where X is small.)
160 2014-05-14 16:08:55 <justanotheruser> Slightly smaller :) it probably can be optimized further
161 2014-05-14 16:09:13 <posita> Thanks. That's actually much better.
162 2014-05-14 16:09:17 <posita> Non-standard, but still much better.
163 2014-05-14 16:10:11 <posita> It's actually a much better approach since it won't be penalized for non-standard OP_CHECKMULTISIG operations.
164 2014-05-14 16:10:36 <dabura667> All: speaking of opcodes, what are your thoughts on Stealth Addresses a la Dark Wallet? Keeping them as OP_RETURN 0 amount txOuts seems silly... would it be possible to wedge them into the stealth txOut, do you think?
165 2014-05-14 16:11:33 <dabura667> similar to the way the serialized script is wedged into P2SH txes.
166 2014-05-14 16:13:05 <justanotheruser> posita: you could have key owners generate new key pairs and sign their public keys with their old public keys. Then keyA and keyB could be combined and keyC and keyD could be combined (after they signed their newly generated pub keys as well)
167 2014-05-14 16:14:42 <justanotheruser> After they have pubkeyA and pubkeyB combined, a signature for it can be made from a combination of privkeyA and privkeyB. Them releasing their privkey is necessary to sign the tx, but it doesn't effect their security because they generated this key for one time use.
168 2014-05-14 16:15:36 <justanotheruser> Then you have a standard 1 of 2 tx
169 2014-05-14 16:17:21 <dabura667> hmmmm
170 2014-05-14 16:17:30 <justanotheruser> s/sign their public keys with their old public keys/sign their new public keys with their old non-disposable keys
171 2014-05-14 16:18:19 <dabura667> How many bytes would that script take?
172 2014-05-14 16:20:24 <dabura667> I feel like the method they're using right now is not exactly optimal...
173 2014-05-14 16:21:21 <justanotheruser> dabura667: its 2 pub keys one opcode and 1 1-byte numerical argument to the opcode
174 2014-05-14 16:21:52 <dabura667> that's for the txOut, correct?
175 2014-05-14 16:22:00 <dabura667> how would I redeem that?
176 2014-05-14 16:22:28 <justanotheruser> I mean 2 1-byte args
177 2014-05-14 16:22:45 <dabura667> ok, so a multisig, correct?
178 2014-05-14 16:23:37 <justanotheruser> dabura667: yez
179 2014-05-14 16:23:41 <justanotheruser> Yes*
180 2014-05-14 16:24:09 <justanotheruser> To redeem it, you would communicated with keyA holder if you were keyB holder
181 2014-05-14 16:24:31 <justanotheruser> same for keyC holder with keyD holdrt
182 2014-05-14 16:25:09 <dabura667> so the tx out would be OP_FALSE OP_1 pubkey1(sender generated) pubkey2(from receiver's stealth address) OP_2 OP_CHECKMULTISIG
183 2014-05-14 16:25:11 <dabura667> ?
184 2014-05-14 16:25:19 <justanotheruser> You would tell one another your private keys and create a signature for the transaction using the sum (or whatever the operation is) of your private keys
185 2014-05-14 16:26:06 <justanotheruser> dabura667: why opfalse?
186 2014-05-14 16:26:24 <justanotheruser> Brb
187 2014-05-14 16:26:34 <dabura667> isn't that a bug where you need to place 00 at front of multisig txout?
188 2014-05-14 16:27:49 <posita> justanotheruser: I stepped away for a few minutes and got lost…. Do you mean like for maintaining chain of identity type situation?
189 2014-05-14 16:28:55 <justanotheruser> posita: you just make a disposable key pair because making the signature means giving up your private key
190 2014-05-14 16:28:56 <posita> justanotheruser: Never mind. I see what you mean now.
191 2014-05-14 16:29:44 <justanotheruser> dabura667: maybe. I didn't know about it
192 2014-05-14 16:30:10 <justanotheruser> posita: what are you trying to do with this script though?
193 2014-05-14 16:30:20 <posita> So, this might be embarrassing to admit, but I'm not up to speed on how keys get "combined". Do you mean using aspects of each to create a shared secret? Or do you mean creating a new key pair from two existing key pairs?
194 2014-05-14 16:30:58 <justanotheruser> posita: the latter, and I didn't know it was possible until a week ago either :)
195 2014-05-14 16:31:19 <nassty> hey guys, question about listtransactions over RCP. Is there any way I can tell bitcoind to skip the 'account' parameter but maintain the 'count' and 'offset' parameters? I tried sending 'null', but it complains
196 2014-05-14 16:31:46 <posita> justanotheruser: Wow…I didn't know it was possible until just now. Probably off topic here (more a discussion for #bitcoin-wizards?), but do you have any pointers on where to read up?
197 2014-05-14 16:32:07 <justanotheruser> Paging gmaxwell
198 2014-05-14 16:32:50 <posita> I'll ask him later, but that sounds really neat.
199 2014-05-14 16:32:58 <nassty> (RPC*, oops)
200 2014-05-14 16:33:24 <justanotheruser> We were discussing combining pubkeys and privkeys. Can you link that document you linked me?
201 2014-05-14 16:33:33 <justanotheruser> posita: good
202 2014-05-14 16:34:36 <justanotheruser> Yeah, I think its really interesting how that's possible. We were discussing it in the context of an oracle releasing a private key when an event happens and creating a gambling script based on that oracle.
203 2014-05-14 16:35:54 <posita> I'm obviously missing some of the details, but it sounds neat. Although I'm not sure why anyone would release a private key?
204 2014-05-14 16:38:17 <posita> BRB (offline for a few minutes…I might miss stuff…apologies in advance).
205 2014-05-14 16:44:55 <nassty> I'm back just for further reference. to send a different 'count' or 'offset' to listtransactions without specifying the account, you need to send "*" as the first parameter.
206 2014-05-14 16:45:56 <nassty> I mean, rpc.listtransactions("*", 200, 0) retrives the last 200 transactions for all accounts. Hope it helps anyone!
207 2014-05-14 17:17:06 <coryfields> michagogo|cloud: any luck?
208 2014-05-14 17:19:16 <justanotheruser> posita: I sent you a memo because I thought you were offline :p
209 2014-05-14 17:22:08 <posita> justanotheruser: Thanks for that! I'm back now. :-)
210 2014-05-14 17:22:27 <posita> I got the message. I understand now. It's like a verification of destruction (or equivalent).
211 2014-05-14 17:24:02 <justanotheruser> Well its for one time use, that's for sure
212 2014-05-14 17:25:50 <michagogo> cloud|coryfields: not yet -- VM had about 2-3 months of updates to install
213 2014-05-14 17:26:14 <michagogo> cloud|Looks like it's done, though
214 2014-05-14 17:27:56 <michagogo> cloud|I could have sworn I had the guest additions installed...
215 2014-05-14 17:37:39 <posita> justanotheruser: That's a more accurate way of putting it. :-) That's pretty cool.
216 2014-05-14 18:14:54 <michagogo> cloud|coryfields: uh, what happened to the osx readme?
217 2014-05-14 18:16:39 <michagogo> cloud|Oh, nvm
218 2014-05-14 18:16:43 <michagogo> cloud|Just refreshed the PR page
219 2014-05-14 18:23:05 <michagogo> cloud|coryfields: the indents are off, I think
220 2014-05-14 18:25:20 <michagogo> cloud|coryfields: Also, you didn't need to add "mkdir -p inputs; cd inputs/"
221 2014-05-14 18:25:36 <michagogo> cloud|That's already at the top of Fetch and build inputs: (first time, or when dependency versions change)
222 2014-05-14 18:25:50 <michagogo> cloud|Following your version, you'll end up with gitian-builder/inputs/inputs/
223 2014-05-14 18:27:02 <michagogo> cloud|coryfields: Also: How come you used tgz for the deps and not zips like the rest of them?
224 2014-05-14 18:28:16 <michagogo> cloud|I mean, in theory it doesn't matter, but a) consistency is nice, and b) it provides an easy way to determine at a glance what's source (tarballs) and what's built deps (zipa)
225 2014-05-14 18:28:21 <michagogo> cloud|zips*
226 2014-05-14 18:28:50 <michagogo> cloud|Anyway, build running now
227 2014-05-14 18:28:55 <michagogo> cloud|native first
228 2014-05-14 18:29:44 <michagogo> cloud|Oh, and you di- you know what, I'll just make these a comment
229 2014-05-14 18:35:09 <coryfields> michagogo|cloud: heh, thanks
230 2014-05-14 18:35:48 <coryfields> michagogo|cloud: whoops, i forgot to remove the 2nd mkdir
231 2014-05-14 18:36:02 <michagogo> cloud|coryfields: why move it?
232 2014-05-14 18:36:18 <coryfields> michagogo|cloud: so it's clear that the dmg/pkg need to be in the inputs dir
233 2014-05-14 18:36:47 <michagogo> cloud|coryfields: I would move the instructions for getting the pkg into the inputs section
234 2014-05-14 18:37:11 <michagogo> cloud|Below the "Fetch and build inputs: (first time, or when dependency versions change)" line, perhaps above the code box
235 2014-05-14 18:38:04 <michagogo> cloud|Erm, how do I stop github from turning what it thinks is a commit hash into a short link?
236 2014-05-14 18:38:30 <coryfields> that would mean that you can't just c/p them anymore
237 2014-05-14 18:38:40 <coryfields> but it doesn't matter to me, whatever seems more clear
238 2014-05-14 18:38:42 <michagogo> cloud|coryfields: hmm?
239 2014-05-14 18:38:51 <michagogo> cloud|What do you mean, you can't just c/p them anymore?
240 2014-05-14 18:39:54 <michagogo> cloud|How about this:
241 2014-05-14 18:40:05 <michagogo> cloud|Under "fetch and build"... have the mkdir and cd
242 2014-05-14 18:40:09 <coryfields> michagogo|cloud: above that, user has to download the dmg. but at that point, the inputs dir doesn't exist
243 2014-05-14 18:40:23 <coryfields> so i moved the mkdir up to before that
244 2014-05-14 18:40:27 <michagogo> cloud|Then, outside of a code box, have "Register and download the Apple SDK..."
245 2014-05-14 18:40:36 <michagogo> cloud|And then under that, have the big code box
246 2014-05-14 18:40:50 <michagogo> cloud|Including the extraction commands
247 2014-05-14 18:41:02 <coryfields> ok, will fix up when i get a chance
248 2014-05-14 18:41:21 <coryfields> i'm packing and getting ready to fly out now, likely can't hack on it til i get back
249 2014-05-14 18:42:08 <michagogo> cloud|Ah, okay -- for the conference?
250 2014-05-14 18:42:20 <michagogo> cloud|Or something else?
251 2014-05-14 18:42:35 <michagogo> cloud|Either way, have a safe and pleasant flight!
252 2014-05-14 18:42:40 <coryfields> yea
253 2014-05-14 18:42:43 <coryfields> thanks :)
254 2014-05-14 18:43:02 <coryfields> i'll kick off a clean gitian build now, in case anyone manages to build it all
255 2014-05-14 18:43:13 <coryfields> my priority atm is making sure the results line up
256 2014-05-14 18:43:58 <michagogo> cloud|coryfields: post the hashes on the PR, and I'll see if they match mine
257 2014-05-14 18:44:08 <coryfields> ok, thanks
258 2014-05-14 18:44:12 <michagogo> cloud|Though that may need to be tomorrow or later
259 2014-05-14 18:44:25 <coryfields> michagogo|cloud: note that i moved back to qt 5.2.0 to match windows
260 2014-05-14 18:44:29 <coryfields> so be sure you have that input
261 2014-05-14 18:44:37 <michagogo> cloud|I haven't been feeling great, so I think I'm going to go to sleep early
262 2014-05-14 18:44:47 <michagogo> cloud|coryfields: Eh? What had you been using?
263 2014-05-14 18:44:48 <coryfields> ah, sorry to hear :\
264 2014-05-14 18:45:16 <coryfields> 5.2.1
265 2014-05-14 18:45:24 <michagogo> cloud|Ah, didn't see that
266 2014-05-14 18:45:36 <michagogo> cloud|But yeah, already had 5.2.0
267 2014-05-14 18:45:56 <coryfields> ok, headed out for a bit. feel better!
268 2014-05-14 18:46:01 <michagogo> cloud|Thanks
269 2014-05-14 18:46:13 <michagogo> cloud|(also, apparently the conference is coinciding with my birthday)
270 2014-05-14 20:19:04 <reipr> http://people.xiph.org/~greg/signdemo.txt
271 2014-05-14 20:19:12 <reipr> know the input value and this txn could be paying a ton of change out
272 2014-05-14 20:19:12 <reipr> " Note: Since we don't have the input transaction we don't
273 2014-05-14 20:19:13 <reipr> to fees."
274 2014-05-14 20:20:10 <reipr> I'm confused. He says we dont have the input transaction, but the input transaction is the original transaction that paied him the 50.00
275 2014-05-14 20:20:30 <reipr> Is he just saying "In general"...?
276 2014-05-14 20:20:48 <michagogo> cloud|yes
277 2014-05-14 20:24:12 <reipr> Also, when sending change, it seems that maybe I should have a few different change addresses. 1. An address that receives largish amounts of change so that when spending it's outputs I can void fees. 2. An address that always receives ridiculously small amounts of change
278 2014-05-14 20:25:07 <reipr> in other words, should I do that, or is there a better way to select which addresses to send change to?
279 2014-05-14 20:25:34 <reipr> (all change addressess will also be from offline wallets)
280 2014-05-14 20:26:41 <michagogo> cloud|reipr: well, you should only ever use each address once
281 2014-05-14 20:26:48 <michagogo> cloud|And that includes change addresses
282 2014-05-14 20:27:54 <michagogo> cloud|In the ideal situation, no address should ever have more than one output sent to it
283 2014-05-14 20:27:55 <reipr> michagogo|cloud: I have deposit addressess that are offline, and the transactions I am talking about are to send the deposits to another set of offline wallets. I thought that was the best way because I can "age" the coins in those main wallets.
284 2014-05-14 20:27:58 <reipr> Maybe Im way off base
285 2014-05-14 20:28:17 <michagogo> cloud|reipr: Not sure exactly what you mean
286 2014-05-14 20:28:26 <michagogo> cloud|I was responding to 23:24:13 <reipr> Also, when sending change, it seems that maybe I should have a few different change addresses.
287 2014-05-14 20:28:39 <michagogo> cloud|You should have as many change addresses as you have change outputs.
288 2014-05-14 20:29:13 <reipr> I get what you mean there. But you generalized the statement, so I explained further hoping that even that assumption of mine can be checked :)
289 2014-05-14 20:29:53 <michagogo> cloud|I'm not sure I understand what your setup is.
290 2014-05-14 20:30:15 <reipr> For some reason, I am assuming the best situation is to have several deposit addressess. Deposits to those addressess are moved to a set of main wallets after a few days.
291 2014-05-14 20:30:24 <michagogo> cloud|Why move them?
292 2014-05-14 20:30:50 <reipr> hmm.
293 2014-05-14 20:30:53 <reipr> maybe I shouldnt
294 2014-05-14 20:31:24 <reipr> I just thought that if I moved them it would help me to pick unpent txouts better. But now that I think about it. That is false
295 2014-05-14 20:32:19 <reipr> I guess the only benefit that I can still see in moving them is the proof of assets. I can publish a small number of cold storage addressses rather than tons of them
296 2014-05-14 21:22:52 <gidze> Hi all. What is a good libboost version to compile bitcoind under ubuntu 14.04? In the docs says to use 1.53 but it’s not available. I have compiled it before on another system without a problem
297 2014-05-14 22:22:06 <helo> you should be able to install 1.53 after you add-apt-repository ppa:bitcoin/bitcoin
298 2014-05-14 22:23:16 <gidze> helo I tried with 1.55 and it worked
299 2014-05-14 22:23:30 <helo> yeah, it should work
300 2014-05-14 22:24:12 <gidze> In the past I lost many hours because of boost
301 2014-05-14 22:24:43 <gidze> but now it seems to work smoothly
302 2014-05-14 22:25:39 <gidze> btw I noticed that it doesn’t compile staticaly boost so I had to install the boost libs on the server
303 2014-05-14 22:26:11 <helo> oh, there is no bitcoin ppa for 14.04 yet
304 2014-05-14 22:26:31 <gidze> these are all it asked: libboost-system1.55.0 libboost-filesystem1.55.0 libboost-program-options1.55.0 libboost-thread1.55.0
305 2014-05-14 22:27:15 <gidze> but compiling them statically would be better
306 2014-05-14 23:49:51 <gigamike_> hello
307 2014-05-14 23:50:45 <gigamike_> guys, maybe someone can help me on this one https://litecointalk.org/index.php?topic=19680.0 :(
308 2014-05-14 23:55:47 <jcorgan> um, no, this channel is for bitcoin development work