1 2014-08-02 00:11:33 <sipa> log2_work=79.99997
  2 2014-08-02 00:12:28 <gmaxwell> 17:12 < dsnrk> UpdateTip: new best=000000000000000038bbefc70a1a5c86215082fd134c1e43172e7857f8cac406  height=313563  log2_work=80.000066  tx=43685132  date=2014-08-02  00:12:01 progress=1.000000
  3 2014-08-02 00:20:23 <sipa> tweeted and reddited :)
  4 2014-08-02 00:37:05 <OneBraveHog> noob question with 1 compiler error -> Error
  5 2014-08-02 00:37:18 <OneBraveHog> well ignore the path there.
  6 2014-08-02 00:37:23 <OneBraveHog> was going to trim that off for clarity
  7 2014-08-02 00:37:33 <OneBraveHog> it's on my line:  if (DBOP.TestDBConnection(GetConnectionString()))
  8 2014-08-02 00:37:55 <OneBraveHog> GetConnectionString is defined in the Form class (for now - I know, move it out), as public string GetConnectionString...
  9 2014-08-02 00:38:28 <OneBraveHog> GetConnectionString simply constructs my connection string (ADO.NET) and returns it as a string
 10 2014-08-02 00:38:37 <sipa> this is not a help channel for programming 101
 11 2014-08-02 00:38:51 <OneBraveHog> sipa - ok - I'll google that error
 12 2014-08-02 00:39:01 <OneBraveHog> it is 100 or 101 though no doubt.
 13 2014-08-02 00:57:10 <OneBraveHog> when using private variables inside a class- is there a prefix naming convention that is common?
 14 2014-08-02 00:57:17 <OneBraveHog> such as to prefix it with 'm'  or something?
 15 2014-08-02 00:57:23 <OneBraveHog> anyone have any habits ?
 16 2014-08-02 00:57:39 <OneBraveHog> nuns excluded
 17 2014-08-02 00:58:26 <dsnrk> OneBraveHog: super off topic, take it elsewhere.
 18 2014-08-02 00:59:56 <jgarzik> super off topic, unless adding a class, method or variable to Bitcoin Core C++ codebase, in which case, we would be happy to bikeshed over naming for an hour.
 19 2014-08-02 01:00:25 <sipa> just an hour? that's insulting
 20 2014-08-02 01:03:28 <OneBraveHog> I"m confused
 21 2014-08-02 01:03:41 <OneBraveHog> humor?
 22 2014-08-02 01:03:54 <OneBraveHog> oh shit
 23 2014-08-02 01:03:58 <OneBraveHog> WRONG channel
 24 2014-08-02 01:04:00 <OneBraveHog> holy crap
 25 2014-08-02 01:04:02 <OneBraveHog> I'm sorry
 26 2014-08-02 01:04:04 <gmaxwell> This is not the channel you're looking for.
 27 2014-08-02 01:04:10 <OneBraveHog> yeah - I thought I had a dev channel open :)
 28 2014-08-02 01:04:12 <OneBraveHog> oh my god.
 29 2014-08-02 01:04:14 <OneBraveHog> no wonder
 30 2014-08-02 01:04:19 <OneBraveHog> I thoguth the dev's were screwing with me
 31 2014-08-02 01:04:32 <OneBraveHog> I just looked up - because I saw bitcoin and was like- why would they bring up bitcoin?
 32 2014-08-02 01:04:41 <OneBraveHog> hahaha- ok - please understand-  my error.
 33 2014-08-02 01:04:44 <OneBraveHog> whooops
 34 2014-08-02 01:04:57 <OneBraveHog> yeah- I had this chan open from 2 days ago - forgot to close it
 35 2014-08-02 01:05:18 <OneBraveHog> wow - that was so damned strange... It all makes sense now - lol
 36 2014-08-02 01:05:28 <OneBraveHog> NOW I understand Sipa's comment 'this is not 101 programming' hahahahah
 37 2014-08-02 01:05:55 <OneBraveHog> poor sipa - yeah - BIG whoops there.  I do realize this is for serious bitcoin dev - please understand none of my posts were meant for this chan
 38 2014-08-02 01:06:23 <OneBraveHog> I'll close out chan - and pop in if I ever do have bitcoin dev questions, I'm good currently.  I was in the other day asking about max pub keys and learned a lot
 39 2014-08-02 02:34:20 <jgarzik> http://www.keylimepi.net/  "key lime pi offline wallet"
 40 2014-08-02 02:34:21 <jgarzik> cute
 41 2014-08-02 02:37:15 <dsnrk> jgarzik: why the fuck are they supplying a web based "paper wallet" tool!?
 42 2014-08-02 02:37:54 <dsnrk> mouse movement entropy my ass.
 43 2014-08-02 03:57:07 <arioBarzan> 55BTC in tx/f316dbd9937419172c5d9d3c7d751bc5ab5e403cf4209fe5676e562cad1bd5ca is lost forever? b472a266d0bd89c13706a4132ccfb16f7c3b9fcb is sha256(ripemd160(''))
 44 2014-08-02 04:00:55 <Luke-Jr> is that MtGox's?
 45 2014-08-02 04:01:49 <arioBarzan> not sure
 46 2014-08-02 04:03:14 <BlueMatt> gmaxwell: if you (or anyone else) wants to try the new relay node stuff, http://bitcoin.ninja/RelayNodeClient.jar
 47 2014-08-02 04:03:29 <BlueMatt> I make no guarantees the servers wont be un-backwards-compatibly upgraded without notice
 48 2014-08-02 04:13:51 <btc111> hey guys, anyone know how long on avg. it takes a standard android phone (galaxys5/etc) to generate 1000 addresses in an HD wallet?
 49 2014-08-02 04:22:29 <gmaxwell> BlueMatt: wheres the source?
 50 2014-08-02 04:25:49 <btc111> should I assume generating 1000 addresses on an iphone/galaxy will take longer then 10 seconds?
 51 2014-08-02 04:26:36 <Luke-Jr> btc111: I doubt it
 52 2014-08-02 04:26:57 <Luke-Jr> btc111: generating addresses is pretty cheap
 53 2014-08-02 04:28:28 <btc111> cool, i was thinking that a way you can stop a color coin user from sending to a non-colored wallet would be to have a protocol rule that hashes a bitcoin address and looks for a pattern so that only 1 in 1000 are 'color addresses'
 54 2014-08-02 04:29:28 <Luke-Jr> bad idea :x
 55 2014-08-02 04:29:44 <Luke-Jr> just don't use addresses for coloured coins, problem solved
 56 2014-08-02 04:29:56 <Luke-Jr> or if you must, make a new address format that has a bitfield for features or something
 57 2014-08-02 04:31:33 <btc111> how would you suggest not using addresses?
 58 2014-08-02 04:32:30 <Luke-Jr> something like the payment protocol?
 59 2014-08-02 04:32:47 <Luke-Jr> maybe extend it
 60 2014-08-02 04:33:10 <Luke-Jr> btc111: if you're thinking of doing coloured coins, I'd talks to maaku and jtimon; they're working on that kind of thing
 61 2014-08-02 04:34:53 <gmaxwell> btc111: that doesn't make a lot of sense, how about you ... just not do that?  ... it very much should not be using ordinary bitcoin address, because how would you know that it knew how to properly handle the transactions? ... it's not like the addresses show up in the wire protocol anyways.
 62 2014-08-02 04:36:50 <btc111> i've heard of some people suggesting using nSequence bits to mark colored coins
 63 2014-08-02 04:39:03 <btc111> gmaxwell: i was going to have a server with a list of signed color definitions, and my wallet will query the server with each new tx and ask 'is this utxo colored with anything'? if the server says yes it tells the wallet which color defintion to download
 64 2014-08-02 04:39:39 <btc111> server just gives the wallet hints of course, the user can check the color definition is signed by the issuer manually if they dont trust my server
 65 2014-08-02 04:41:23 <btc111> its a mobile app so if it has some thin-client centralization i dont think its too bad. i'm looking at openassets and order-based coloring right now to see whats better
 66 2014-08-02 04:58:02 <btc111> i'm also going to set up a bunch of nodes that remove the dust limit and have my mobile wallets connect to those first by default so they can send 1 satoshi transactions (which my server will push to miners)
 67 2014-08-02 04:58:38 <luke-jr_> btc111: why 1 satoshi?
 68 2014-08-02 04:58:41 <luke-jr_> why not 0 satoshis?
 69 2014-08-02 04:58:45 <btc111> i figure 100 nodes would be alright.. cost me $500 a month and would be expensive for attackers to ddos
 70 2014-08-02 04:59:09 <arioBarzan> scriptPubKey: "OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG" wastes both processing and storage resources. for e.g. in tx/2df665d6e6f76192f0d0aae6290985acdab0aa9e985e8b9730ace276b3946a3b nodes compute OP_HASH160 for same pubKey (04ec896e0e...) almost 200 times, and for same tx the pubKey is repeatedly stored in blockchain.
 71 2014-08-02 04:59:10 <btc111> luke-jr_: how does the 0 satoshi utxo send the asset to soemeone else?
 72 2014-08-02 04:59:26 <luke-jr_> btc111: there's no concept of assets right now.. so depends how you define that O.o
 73 2014-08-02 05:00:06 <luke-jr_> arioBarzan: consider that addresses are supposed to only ever be used once.
 74 2014-08-02 05:00:51 <btc111> luke: i didn't know i could create 0 satoshi outputs? can you point me to a tx in the blockchain that has one?
 75 2014-08-02 05:01:36 <luke-jr_> btc111: can't be bothered, but I know they exist
 76 2014-08-02 05:01:41 <luke-jr_> (I've spent a few at least)
 77 2014-08-02 05:04:27 <arioBarzan> but you guys changed bitcoind's code such that users have no formal easy option for generating different types of addresses (like <pubKey> OP_CHECKSIG) which are being used more than 'once'.
 78 2014-08-02 05:04:45 <gmaxwell> arioBarzan: changed?!
 79 2014-08-02 05:05:00 <gmaxwell> there is no address encoding of pay to pubkey, never has been
 80 2014-08-02 05:05:45 <gmaxwell> It's a style used by the internal miner, which is mostly where you've seen that before. (was also used by pay to ip, which was eventually removed due to being insecure)
 81 2014-08-02 05:10:16 <Luke-Jr> arioBarzan: the only reusable address has ever been IP addresses, which were totally insecure
 82 2014-08-02 05:13:27 <arioBarzan> early versions of bitcoind should have generated '<pubKey> OP_CHECKSIG' addresses, the dude who received first payment from Satoshi in tx/f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16 would have had 76a914<...>88ac type of address, otherwise.
 83 2014-08-02 05:13:59 <gmaxwell> arioBarzan: no such 'addresses' ever existed.
 84 2014-08-02 05:14:18 <gmaxwell> arioBarzan: That was pay-to-ip (as menitoned), which is how bitcoin was originally used.
 85 2014-08-02 05:15:15 <gmaxwell> arioBarzan: also pay to ip guaranteed scriptpubkeys were _never_ reused.
 86 2014-08-02 05:16:48 <gmaxwell> As luke says, the system was really designed such that scriptpubkeys wouldn't be reused, ... reuse really screws up the privacy model badly (e.g. to common spending in seperate transactions).
 87 2014-08-02 05:20:18 <arioBarzan> for those who want to reuse an address, isn't it better to provide them with a tool or guidance to use '<pubKey> OP_CHECKSIG' addresses instead?
 88 2014-08-02 05:20:55 <arioBarzan> this way they don't waste storage and processing resources of other nodes
 89 2014-08-02 05:21:11 <Luke-Jr> arioBarzan: no such thing exists
 90 2014-08-02 05:21:21 <Luke-Jr> arioBarzan: and '<pubkey> OP_CHECKSIG' is still NOT reusable
 91 2014-08-02 05:21:55 <gmaxwell> arioBarzan: huh? I think you're confused about something but I'm not sure what the nature of your cryptocurrency confusion is. :(
 92 2014-08-02 05:22:35 <gmaxwell> There is no such thing as a "'<pubKey> OP_CHECKSIG' address" and never has been, but lets pretend there were— it's no different wrt reuse than 1-type addresses.
 93 2014-08-02 05:24:14 <arioBarzan> my question is for those who reuse scriptPubKey: "OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG", isn't it better to tell them to use scriptPubKey: "<pubKey> OP_CHECKSIG" instead?
 94 2014-08-02 05:24:46 <Luke-Jr> arioBarzan: no, worse
 95 2014-08-02 05:25:19 <gmaxwell> arioBarzan: doesn't matter— the couple bytes overhead would easily compress out if anyone cared. And people really shouldn't be reusing scriptPubKeys in general, since it hurts the privacy of other people.
 96 2014-08-02 05:30:25 <arioBarzan> yes, in general people shouldn't use it. but for those specific people who reuse their scriptPubKey anyway, (like companies, miners, exchanges, etc.) there could be an alternative option.
 97 2014-08-02 05:31:38 <arioBarzan> and in reality for them it doesn't matter how much developers them not to reuse their scriptPubKey, just look at their transactions on blockchain.
 98 2014-08-02 05:31:48 <arioBarzan> *tell them
 99 2014-08-02 05:32:19 <Luke-Jr> I hope no exchange is clueless enough to reuse addresses :x
100 2014-08-02 05:37:48 <gmaxwell> arioBarzan: why should there be an alternative option?  How does the scriptpubkey type has _anything_ to do with reuse?
101 2014-08-02 05:38:01 <gmaxwell> (also, fwiw, payment protocol lets you use whatever scriptpubkey you like)
102 2014-08-02 05:44:48 <arioBarzan> for e.g. one miner has generated 415,557.14979622 coins and sent them to 'OP_DUP OP_HASH160 80ad90d403581fa3bf46086a91b2d9d4125db6c1 OP_EQUALVERIFY OP_CHECKSIG'. other nodes thousand of times have computed OP_DUP OP_HASH160 for 02b8c918bd169a5e669cc149549f822dd5f2c50872eb83172a1c69172277fe378f and the same pubKey wasted lots of storage on blockchain.
103 2014-08-02 05:45:40 <arioBarzan> I have nothing more to say in this regard. thanks anyway for your replies.
104 2014-08-02 05:46:30 <gmaxwell> arioBarzan: it doesn't waste any storage at all, if anyone cares— it all compresses right out. (also, the number of bitcoins is more or less irrelevant, the number of txouts is what matters).
105 2014-08-02 05:47:25 <gmaxwell> also if you're talking about a _miner_ the miner is free to use whatever scriptpubkey they want, bitcoin's internal miner already uses the pay to pubkey style scriptpubkey.
106 2014-08-02 11:37:34 <randy-waterhouse> is there a minimum version of openssl required for bitcoin core?
107 2014-08-02 11:40:05 <sipa> randy-waterhouse: whatever works, works
108 2014-08-02 11:40:15 <sipa> randy-waterhouse: but i very strongly suggest you use a recent version
109 2014-08-02 11:40:23 <sipa> there have been many problems with openssl lately
110 2014-08-02 11:40:45 <randy-waterhouse> sipa ... looking at putting a min required into autotools configure.ac ...
111 2014-08-02 11:41:01 <randy-waterhouse> wth option to point to custom builds also
112 2014-08-02 11:41:21 <sipa> all things we use in openssl have been there for a long time
113 2014-08-02 11:41:38 <randy-waterhouse> so pick an old old number?
114 2014-08-02 11:41:41 <randy-waterhouse> 0.9.8?
115 2014-08-02 11:42:26 <randy-waterhouse> or no min required is an option also
116 2014-08-02 11:42:39 <randy-waterhouse> seems to be what you are suggesting
117 2014-08-02 11:43:09 <randy-waterhouse> go with that for now
118 2014-08-02 11:43:19 <sipa> i can't remember any complaint from anyone ever that their build failed because their openssl was too old
119 2014-08-02 11:43:28 <sipa> so i don't think it's a problem in practice
120 2014-08-02 11:44:32 <randy-waterhouse> ok
121 2014-08-02 11:47:55 <wumpus> generally we can handle extremely old versions of dependencies
122 2014-08-02 11:48:35 <wumpus> I don't remember any complaint at all from someone using an too-old version of anything
123 2014-08-02 11:49:21 <randy-waterhouse> never too old ... sounds like good advice
124 2014-08-02 11:50:06 <wumpus> it's not advice, it's always advised to use newer versions, but if you want you can build bitcoin on some older 'stable' distributions, which is good
125 2014-08-02 11:52:00 <randy-waterhouse> ok
126 2014-08-02 11:52:43 <wumpus> the only hard requirement I remember now is qt > 4.6, oh and of course bdb=4.8, but that's just for compatibility reasons of the file format
127 2014-08-02 11:54:48 <wumpus> for boost I don't know, minimum must be 1.3x as that's used for the pulltester
128 2014-08-02 11:55:00 <randy-waterhouse> 1.37?
129 2014-08-02 11:55:16 <wumpus> yes I think so
130 2014-08-02 11:56:33 <randy-waterhouse> any long term plan to move away from boost?
131 2014-08-02 11:58:33 <wumpus> no, none at all
132 2014-08-02 11:59:13 <sipa> i hope that at some point we'll be able to switch to c++11, and replace several boost constructs by native constructs
133 2014-08-02 11:59:20 <sipa> but certainly not all
134 2014-08-02 11:59:24 <wumpus> possibly, but in itself it is no goal
135 2014-08-02 12:00:02 <sipa> right, c++11 is the goal because of very useful features - and if that allows us to remove parts of out boost dependency, so much the better
136 2014-08-02 12:00:10 <wumpus> if c++11 provides comparable functions, and we require c++11, it makes sense to use those
137 2014-08-02 12:00:15 <wumpus> right
138 2014-08-02 12:02:40 <randy-waterhouse> ta
139 2014-08-02 12:03:29 <randy-waterhouse> boost chrono debacle would be good to leave behind
140 2014-08-02 18:10:11 <jtimon> any idea what I'm getting this when make check?
141 2014-08-02 18:10:11 <jtimon> ../src/build-aux/test-driver: line 107: 17258 Aborted                 "$@" > $log_file 2>&1
142 2014-08-02 19:09:08 <jtimon> nevermind, seems specific to a commit