1 2014-05-01 00:02:27 <SoftwareMechanic> ANSI X9.17 Looks promising
  2 2014-05-01 00:06:51 <SoftwareMechanic> https://www.schneier.com/paper-prngs.pdf
  3 2014-05-01 00:06:57 <SoftwareMechanic> Looks like it has some issues though
  4 2014-05-01 01:30:26 <akstunt600> hey anyone else have problems with GPA on ubuntu/debian
  5 2014-05-01 01:30:39 <akstunt600> its buggy as all hell anymore
  6 2014-05-01 01:39:09 <cpacia> ya it doesn't work right on trusty tahr
  7 2014-05-01 01:53:06 <akstunt600> cpacia, Thanks
  8 2014-05-01 01:53:16 <akstunt600> Ill just do it the ole fashion way
  9 2014-05-01 06:07:03 <rccola> Hey, anyone around?
 10 2014-05-01 06:07:54 <sipa> no
 11 2014-05-01 06:08:02 <sipa> sorry, you're all alone
 12 2014-05-01 06:08:33 <rccola> foreveralone
 13 2014-05-01 06:10:11 <rccola> I'm trying to build an online wallet with Rails on Heroku... was wondering the best route to take.  Would this typically be communicating through the JSON-RPC on a seperate server running bitcoind or using something like bitcoin-ruby?
 14 2014-05-01 06:15:32 <Dizzle> rccola: I'd say a good start is that it depends on the number of transactions you expect to be making and if you'll be having to track separate "balance"s for this app/site's users.
 15 2014-05-01 06:17:51 <rccola> Dizzle: How so?  Sorry for the ignorance.
 16 2014-05-01 06:19:50 <rccola> better to have a separate server running bitcoind for higher volume?  does that create issues with balance tracking for multiple users?
 17 2014-05-01 06:20:43 <survic> you'll struggle scaling anything with bitcoind. it's not designed for anything like that.
 18 2014-05-01 06:23:43 <rccola> why's that?
 19 2014-05-01 06:23:53 <Dizzle> a multi-user application or automated spender.
 20 2014-05-01 06:23:53 <Dizzle> So, bitcoind's balance tracking in general is best not to rely upon, even for one person, so if you're tracking balances, already you want to be using a custom solution. It does an OK job of scaling simple HTTP back and forths, but scaling anything else, not so great. For example, the decision making process for which unspent outputs to aggregate as inputs for a new transaction... the algorithm is built for a personal wallet user, not for
 21 2014-05-01 06:24:38 <rccola> Cool. Thanks.
 22 2014-05-01 06:24:46 <Dizzle> i.e. it will start to take longer and longer to figure out a combinations of unspent outputs to use as input.
 23 2014-05-01 06:25:15 <gmaxwell> Dizzle: it won't— what generally, but for unspent its slow and basically intentionally so.
 24 2014-05-01 06:26:08 <gmaxwell> the normal coin selection is reasonable fast even with many tens of thousands of inputs to choose form.
 25 2014-05-01 06:26:57 <Dizzle> gmaxwell: is it when it gets to the change outputs that it has a bottleneck?
 26 2014-05-01 06:27:27 <gmaxwell> Dizzle: unconfirmed change in particular.
 27 2014-05-01 06:27:39 <Dizzle> ahh, thanks for the clarification
 28 2014-05-01 06:28:04 <gmaxwell> (change itself is fine, but when its unconfirmed it does a rather sillyly constructed traversal to see if the parents are also change or confirmed.
 29 2014-05-01 06:28:18 <gmaxwell> And that is something like O(n!))
 30 2014-05-01 06:28:38 <sipa> gmaxwell: not since 0.9 afaik
 31 2014-05-01 06:29:03 <gmaxwell> oh did that get fixed? ... hm yea it would be.
 32 2014-05-01 06:29:37 <sipa> it uses isconfirmed or (isinmempool and isfromme) afaik
 33 2014-05-01 06:33:44 <rccola> So, what are the big sites like Coinbase/Bitpay using for the wallet?  I read somewhere bitcoin-ruby.  Got it running.  But, am trying to wrap my head around what it actually does.
 34 2014-05-01 06:34:09 <rccola> Looks like it connects directly to the network, right?
 35 2014-05-01 06:34:43 <survic> no, you wouldn't want that. they would be running something custom behind a bitcoind node (or many)
 36 2014-05-01 06:36:02 <rccola> interesting
 37 2014-05-01 06:36:24 <sipa> rccola: you have to understand that bitcoind provides two separate functions: block and transaction validation on the network, and a wallet implementation
 38 2014-05-01 06:36:37 <sipa> there are many other wallet implementations though
 39 2014-05-01 06:37:14 <sipa> and if you connect them to a bitcoind node that you can teust/control, you get the same validation for your wallet
 40 2014-05-01 06:37:47 <survic> you don't really want to be running your own networking code. it's just asking for disaster (bitcoin-ruby has had consensus issues like that in the past)
 41 2014-05-01 06:38:02 <sipa> networking code is fine
 42 2014-05-01 06:38:08 <Belxjander> What are teh essentials for blockchain storage and forwarding?
 43 2014-05-01 06:38:19 <Belxjander> What are the essentials for the "Wallet" functionality?
 44 2014-05-01 06:38:20 <survic> can't find the post on it, but somebody on bitcointalk managed to fork bitcoin-ruby off the network with an edge rule
 45 2014-05-01 06:38:25 <sipa> reimplementing the consensus rules is asking for trouble
 46 2014-05-01 06:38:30 <Belxjander> is there any "overlap" of operations between the two sets?
 47 2014-05-01 06:38:57 <sipa> Belxjander: well there are enough wallet that do not do any blockchain storage or validation
 48 2014-05-01 06:39:26 <sipa> survic: happened more than once
 49 2014-05-01 06:40:15 <survic> sipa: can't imagine btcd (bitcoind concensus rules in go) will fare much better unfortunately.
 50 2014-05-01 06:40:47 <Belxjander> sipa: I've been considering what is required just to become present...and run my own blockchain storage mechanism with it deliberately caching upto a 1 hour previous to current timeframe...ignoring validation and consensus rules
 51 2014-05-01 06:41:13 <sipa> Belxjander: what for?
 52 2014-05-01 06:41:35 <Belxjander> sipa: an "AmigaOS" blockchain store and Wallet library
 53 2014-05-01 06:41:56 <gmaxwell> You didn't answer the question.
 54 2014-05-01 06:41:58 <sipa> what do you want the blockchain store for?
 55 2014-05-01 06:42:01 <Belxjander> I would have nothing "base" to work from so would need to start at network level and build up an essential base...and then import what I can from core
 56 2014-05-01 06:42:05 <sipa> it's a means to end an
 57 2014-05-01 06:42:25 <Dizzle> rccola: here's an example multi-user-ready wallet implementation that relies upon bitcoind in the end for realizing the transactions on the bitcoin network. It's what localbitcoins.com uses: https://github.com/kangasbros/django-bitcoin
 58 2014-05-01 06:42:45 <rccola> Dizzle:  Sweet, thanks!
 59 2014-05-01 06:45:57 <Belxjander> is there anything in the bitcoin-qt or another project with the consensus rules able to be seperated out and used as a link library?
 60 2014-05-01 06:46:27 <sipa> not right now, though there is slow work towards that
 61 2014-05-01 06:47:14 <sipa> but if you just want a wallet, an SPV implementation osn't that hard
 62 2014-05-01 06:47:23 <sipa> or rather, s/hard/critical/
 63 2014-05-01 06:47:26 <Belxjander> sipa: well I have a little bit of spare time and can probably work on Endianness issues along with abstraction and separation though I am still slogging through trying to get to grips with the internal workings of bitcoin-qt without being able to compile it
 64 2014-05-01 06:47:47 <Belxjander> sipa: well I want to start with a Wallet
 65 2014-05-01 06:47:54 <gmaxwell> Belxjander: why would you link that as a library? you really don't want to have a network daemon in the same memory space as your wallet.
 66 2014-05-01 06:48:24 <sipa> yeah, bitcoin core sets a bad example for that
 67 2014-05-01 06:48:33 <Belxjander> gmaxwell: "shared memory model"...the library would be it's own thing with the daemon embedded there...the Wallet would be the Application using the library
 68 2014-05-01 06:49:12 <sipa> just run an spv wallet and a validation node separately
 69 2014-05-01 06:51:02 <gmaxwell> Belxjander: you really shouldn't have a network node in the same process as a wallet.
 70 2014-05-01 06:51:22 <gmaxwell> Thats a choice I certantly wouldn't emulate.
 71 2014-05-01 06:52:39 <rccola> I assume blockchain.info uses the Javascript wallet from https://github.com/blockchain/My-Wallet... is that sitting on top of a bitcoind node?
 72 2014-05-01 06:54:24 <Dizzle> Belxjander: if you simply prefer programming against an imported API vs writing the web service calls to talk to bitcoind, there are plenty of libs to handle that part for ya, like https://github.com/sinisterchipmunk/bitcoin-client (C#), https://github.com/petertodd/python-bitcoinlib (Python), and https://github.com/sinisterchipmunk/bitcoin-client (Ruby) to name a few of many.
 73 2014-05-01 06:55:48 <Dizzle> correction, https://github.com/GeorgeKimionis/BitcoinLib/ (C#)
 74 2014-05-01 06:57:22 <Belxjander> dizko: and the assumption of a Windows/Linux/Mac OS X host generally gets put on its nose and out the door... which is why I am even considering writing any code for this myself
 75 2014-05-01 06:59:16 <Dizzle> rccola: their's is a little more complicated than that django example. Here's the basics: https://blockchain.info/wallet/how-it-works <- the key being the part where it talks to blockchain's API. At that point, somewhere in the blockchain infrastructure, bitcoind might be responsible for putting a transaction on the bitcoin network, but others in here might be able to speak to the site's backend better than I.
 76 2014-05-01 06:59:44 <Dizzle> s/their's/theirs/
 77 2014-05-01 07:01:13 <rccola> interesting
 78 2014-05-01 07:02:46 <Dizzle> Belxjander: well, the beauty of web services such as bitcoind's RPC calls is just that: just about every platform has a way to make an HTTP request.
 79 2014-05-01 09:07:53 <survic> you need to compile with ncurses.
 80 2014-05-01 09:08:47 <survic> (really need to fix my bindings)
 81 2014-05-01 09:20:34 <wumpus> ncurses? are you going oldschool on us? :)
 82 2014-05-01 09:21:53 <survic> wumpus: cgminer/bfgminer needs ncurses for it's pretty interface, I wouldn't be against an ncurses bitcoin client though.
 83 2014-05-01 09:22:16 <wumpus> survic: https://github.com/bit-c/bitc :D
 84 2014-05-01 09:24:26 <survic> wumpus: that's genuinely impressive
 85 2014-05-01 09:24:28 <wumpus> (can't vouch for its safety or security, but have compiled it and tried it out and it does what it promises)
 86 2014-05-01 09:26:01 <survic> should make a good testnet client
 87 2014-05-01 09:31:49 <survic> wumpus: amazing. compiled first time, it feels lightning fast and has great features. I'd love to use this on mainnet when it's more mature.
 88 2014-05-01 09:39:52 <FManTropyx> latest commits 2-3 months ago...
 89 2014-05-01 09:50:53 <wumpus> it doesn't seem to be actively maintained, which is a pity
 90 2014-05-01 09:52:49 <wumpus> the C code is very readable so it's not like it would be difficult to pick up for someone interested
 91 2014-05-01 11:19:36 <wumpus> also if you're not sure about the security of the SPV part, you could point it at your own trusted (walletless) bitcoind node
 92 2014-05-01 11:21:35 <survic> I'd be more worried about a catastrophic failure of private key generation / storage or something like that.
 93 2014-05-01 11:21:40 <wumpus> (though you'd still need to audit that key generation for the wallet is ok)
 94 2014-05-01 11:24:34 <wumpus> yes, (basic) BIP32 support would be great and would mostly alleviate those concerns
 95 2014-05-01 11:28:39 <survic> BIP0032 is quite comforting like that actually. as long as the initial seed is strong the RNG is less of an issue. of course you still need a good one for your EC k, but it's one less thing to worry about.
 96 2014-05-01 11:28:43 <wumpus> though, in principle, bitcoin-qt has that same concern - we use OpenSSL for secure randomness
 97 2014-05-01 11:29:16 <SomeoneWeird> "secure"
 98 2014-05-01 11:29:17 <SomeoneWeird> >_>
 99 2014-05-01 11:29:18 <SomeoneWeird> <_<
100 2014-05-01 11:29:24 <SomeoneWeird> 
ACTION ducks

101 2014-05-01 11:29:24 <survic> you really can't do any worse than Sony.
102 2014-05-01 11:29:28 <wumpus> should be OK, but bugs happen
103 2014-05-01 11:30:09 <survic> if your rng has more than a single possible output, you're better than Sony at EC.
104 2014-05-01 11:30:16 <wumpus> hehe
105 2014-05-01 11:33:39 <wumpus> SomeoneWeird: I think we should switch to using the Intel random instructions ;)
106 2014-05-01 11:35:03 <SomeoneWeird> wumpus, absolutely! we still haven't fixed issue #3615 or #3152 either
107 2014-05-01 11:37:50 <survic> using a static k while signing would reduce the dependency on OpenSSL and prevent address reuse.
108 2014-05-01 11:47:54 <michagogo> cloud|survic: AIUI it can't be a static value
109 2014-05-01 11:48:08 <michagogo> cloud|Because it needs to be secret, not just unique
110 2014-05-01 11:48:49 <survic> you could hash your private key and use that as the secret, static value. I was being stupid so I didn't give it much thought as to how it would work.
111 2014-05-01 11:53:30 <michagogo> cloud|survic: not exactly static
112 2014-05-01 11:53:43 <michagogo> cloud|Also, that's a bad idea
113 2014-05-01 11:54:12 <michagogo> cloud|Because it means you couldn't, for example, rebroadcast a transaction with a higher fee
114 2014-05-01 11:55:59 <survic> it was meant to be a terrible idea, Sony style
115 2014-05-01 11:58:52 <Plarkplark_> What is going on here. https://blockchain.info/tx/6ea5c6f1a97f382f87523d13ef9f2ef17b828607107efdbba42a80b8a6555356
116 2014-05-01 11:59:06 <Plarkplark_> Darkwallet transaction? Does this not break the blockchain
117 2014-05-01 12:00:22 <sipa> wth is "break the blockchain" ?
118 2014-05-01 12:00:28 <survic> what do you think is broken about that?
119 2014-05-01 12:00:36 <sipa> if it wasn't valid, it wouldn't get into the blockchain
120 2014-05-01 12:06:54 <Plarkplark_> I meant: where did the bitcoin go?
121 2014-05-01 12:07:50 <Plarkplark_> sipa, small question. I have a discussion with a guy really into mining. He says that running a full node 24/7 with 30+ connections does not help the network because it does not mine.
122 2014-05-01 12:08:14 <survic> it's OP_RETURN, no amount went anythere
123 2014-05-01 12:08:54 <wumpus> Plarkplark_: not true; you'd still be helping the network by verifying/relaying transactions and blocks, and serving the stored blocks to other nodes
124 2014-05-01 12:09:22 <Plarkplark_> Ok. Because I invested a 100 bucks to get a few big ones running to help the network.
125 2014-05-01 12:10:25 <wumpus> Plarkplark_: great!
126 2014-05-01 12:12:41 <FManTropyx> excuse me, is the lack of good nodes the reason why transactions take time to go through?
127 2014-05-01 12:12:50 <sipa> no
128 2014-05-01 12:13:20 <sipa> miners deicde which transactions they put in blocks
129 2014-05-01 12:14:53 <FManTropyx> the people sit on their computers pressing Y or N? or does it just depend from the size of the fee?
130 2014-05-01 12:15:13 <sipa> it's software that makes that decision of course
131 2014-05-01 12:15:23 <sipa> but they do select transactions with more fee first yes
132 2014-05-01 12:57:29 <survic> the "is this breaking bitcoin" question seems to come from people proving that "dark wallet" is anonymous by linking to a transaction with an OP_RETURN output in it. blockchain.info can't display them, and that's seen as proof of it's transactions being private. I see that being asked a lot.
133 2014-05-01 12:58:49 <hearn> lol
134 2014-05-01 12:59:16 <arubi> any independent implementation of bitcoin transactions could be seen as private
135 2014-05-01 12:59:33 <arubi> question is if _anyone_ can decode the tx, or only the sender \ recevier
136 2014-05-01 13:01:06 <survic> seeing as the wallet in question makes requests to a remote API owned by the author by default, they're not private for the vast majority of people. if they want to or not the remote API knows exactly who they are.
137 2014-05-01 13:05:13 <arubi> from what I see on the infographic, payer and payee rely on a shared secret when making a transaction
138 2014-05-01 13:05:56 <arubi> the dark wallet server should'nt really have to know who they are to provide services to them
139 2014-05-01 13:06:43 <hearn> stealth addresses do elliptic curve diffie hellman between sender and receiver, effectively
140 2014-05-01 13:06:51 <hearn> using the data in OP_RETURN
141 2014-05-01 13:06:58 <arubi> yea, that's what I see
142 2014-05-01 13:07:00 <survic> it can't help but know it. by requesting balances they naturally give up their addresses. I don't think they're operating with bloom filters or anything actually privacy conscious.
143 2014-05-01 13:07:02 <hearn> it’s not about remaining private from the server
144 2014-05-01 13:07:11 <hearn> survic: no they aren’t. they say they want to in future.
145 2014-05-01 13:08:20 <arubi> it could possibly be that darkwallet server only provides a sane access to OP_RETURN data to be used by a darkwallet client
146 2014-05-01 13:09:12 <survic> arubi: you're missing the point. if the client requests balances for all of the source addresses, they can't help but work out the destinations as well.
147 2014-05-01 13:09:30 <arubi> why would a client need to "ask" for balance?
148 2014-05-01 13:09:56 <arubi> how is me asking for a balance of an address, and you asking is different?
149 2014-05-01 13:10:03 <arubi> i mean, for the same address
150 2014-05-01 13:10:36 <survic> we have different IP addresses, different time zones when we might be opening the client.
151 2014-05-01 13:11:25 <arubi> that's really a physical difference. there are ways to circumvent that
152 2014-05-01 13:12:05 <hearn> imo the future of “stealth addresses” is they go away in favour of an extension to BIP 70
153 2014-05-01 13:12:12 <arubi> I don't know how the darkwallet server works, it might as well have no privacy
154 2014-05-01 13:12:12 <hearn> but that may be long term
155 2014-05-01 13:12:21 <hearn> right. it’s basically like blockchain.info
156 2014-05-01 13:12:25 <hearn> you get no privacy from the server ops
157 2014-05-01 13:12:30 <hearn> so better hope you trust them!
158 2014-05-01 13:13:32 <survic> and whoever else has access to their server.
159 2014-05-01 13:14:08 <arubi> I'm not sure how much use anyone would have for encrypted transactions without having any private keys
160 2014-05-01 13:14:54 <arubi> either that or i'm completely missing some flaw with darkwallet (except that it's currently centralized)
161 2014-05-01 13:15:45 <survic> given what it is there's almost no scope for it to become decentralized.
162 2014-05-01 13:16:24 <hearn> over time i think wallets will all converge on the features where they currently compete
163 2014-05-01 13:16:43 <hearn> the dark wallet guys decided to focus on privacy features at the cost of decentralisation features. other wallets have done the opposite. eventually they’ll all do both
164 2014-05-01 13:16:59 <hearn> decentralisation is a lot of work though. i’m not sure they realise how much.
165 2014-05-01 13:18:06 <arubi> electrum does pretty well with it's "un"centralized approach to light clients
166 2014-05-01 13:18:24 <arubi> that could happen with darkwallet, if the service actually works as advertised
167 2014-05-01 13:19:40 <survic> electrum doesn't scale very well. eventually those that run electrum servers will give up.
168 2014-05-01 13:20:07 <wumpus> electrum was sort of a predecessor to bloom-filter based SPV clients
169 2014-05-01 13:20:27 <arubi> 
ACTION has to read up on bloom-filters

170 2014-05-01 13:20:27 <hearn> arubi: well it’s got a handful of servers vs 8500
171 2014-05-01 13:20:48 <arubi> 8500 what? clients?
172 2014-05-01 13:20:48 <hearn> i mean we worry about the falling number of nodes, rightfully so, but it’s still way better than a handful of people with no business model bleeding money
173 2014-05-01 13:20:52 <hearn> p2p nodes
174 2014-05-01 13:20:56 <hearn> SPV clients use the p2p nodes as their servers
175 2014-05-01 13:20:57 <arubi> ah
176 2014-05-01 13:21:48 <hearn> bloom filters are basically a garbled set of addresses/keys. the node that receives the filter can’t extract addresses directly, just test the filter against transactions. the filter can have false positives - the rate is chosen by the client
177 2014-05-01 13:22:05 <hearn> so nodes can end up sending back useless tx data, but, the idea is, the node doesn’t know which transactions are real hits vs the fakes
178 2014-05-01 13:22:24 <hearn> now in practice the only client that uses these is bitcoinj and we don’t garble the filters very much currently. volunteers wanted :)
179 2014-05-01 13:23:07 <arubi> sounds interesting! so genuine tx's get mixed with "noise" tx's?
180 2014-05-01 13:23:09 <wumpus> bitc also uses bloom filters, although I doubt it garbles any better than bitcoinj
181 2014-05-01 13:23:16 <hearn> ah yes. bitc
182 2014-05-01 13:23:19 <hearn> arubi: right
183 2014-05-01 13:23:31 <hearn> wumpus: well it might do. i mean we could make bitcoinj garble like crazy with a one line change.
184 2014-05-01 13:23:48 <hearn> wumpus: but then we’d break the mobile experience. that’s why it’s not done yet. bitc probably does not care about moble phones
185 2014-05-01 13:24:52 <arubi> and how do other p2p nodes react to noise tx's?
186 2014-05-01 13:24:56 <wumpus> hearn: hm yes, it might; but I mean seeing that the rest of the code is still a bit in the early stages, I don't know whether it has been given very deep thought
187 2014-05-01 13:25:18 <hearn> arubi: p2p nodes don’t request bloom filtering, only lightweight clients.
188 2014-05-01 13:25:27 <hearn> arubi: but those lightweight clients ignore them
189 2014-05-01 13:25:34 <hearn> wumpus: indeed
190 2014-05-01 13:25:42 <arubi> Oh I see, so it's up to the client to request that
191 2014-05-01 13:25:48 <survic> arubi: the noise is just transactions the SPV client doesn't want. they can just be ignored. they're valid but not interesting.
192 2014-05-01 13:26:01 <hearn> in future we will probably use them actually
193 2014-05-01 13:26:07 <hearn> arubi: right
194 2014-05-01 13:26:44 <arubi> cool, thanks
195 2014-05-01 13:27:21 <michagogo> cloud|hearn: for what?
196 2014-05-01 13:27:51 <hearn> estimating fees. for the first stage of floating fees i guess we’ll just poll p2p nodes and ask them what they think. that’s easy to implement and we need to do the damn launch :)
197 2014-05-01 13:28:18 <hearn> later on, we can keep FPs that are broadcast after we set up the connection, and then see how long they take to confirm
198 2014-05-01 13:28:37 <hearn> we need some protocol extensions to make this scheme really work, but they’re fairly simple
199 2014-05-01 13:57:27 <maaku> sipa gmaxwell: I'm considering eliding balance summations from the utxo tree network serialization when they can be fully calculated from the data provided (no pruned branches)
200 2014-05-01 13:59:19 <maaku> this would save some space, but you'd have to process a whole proof before you can know the overall balance summation and/or verify the hash of an inner node (which covers the balance-sum)
201 2014-05-01 13:59:31 <maaku> do you think this is a bad tradeoff?
202 2014-05-01 14:56:28 <r0sc0e> whats the correct command for allowing more than 8 connections at the current bitcoinqt client
203 2014-05-01 14:57:16 <helo> it does by default, but upnp must be enabled if you're behind a firewall/router
204 2014-05-01 14:58:14 <arubi> r0sc0e, try running with '-upnp=1' flag
205 2014-05-01 14:58:38 <helo> (your router must support it as well)
206 2014-05-01 14:58:45 <Joric> soo what's very new and exciting in the bitcoin world now
207 2014-05-01 14:58:48 <arubi> true
208 2014-05-01 16:42:13 <tyrick> What is the benefit of using signals2 for the nodeSignals?
209 2014-05-01 17:53:29 <helo> yes that is true
210 2014-05-01 17:57:35 <tyrick> oh?
211 2014-05-01 17:57:43 <tyrick> the benefit of using signals2 for the nodeSignals?
212 2014-05-01 18:03:12 <hearn> saivann__: the new video is cool
213 2014-05-01 18:03:25 <hearn> somehow even though it’s the same voiceover guy, he sounds a little less enthusiastic. not sure …. might just be in my mind
214 2014-05-01 18:05:00 <saivann__> hearn: Funny that you'are saying that, I had the same impression. But the content is better regardless I think :)
215 2014-05-01 18:07:26 <hearn> perhaps he is not a bitcoin fan :)
216 2014-05-01 18:07:50 <hearn> i guess someone paid for it now, but i wonder if stephanie murphy would be willing to do a voiceover too. she is a pro voiceover artist and also big bitcoiner
217 2014-05-01 18:08:04 <hearn> anyway yes content is definitely better. it’s a really nice refresh
218 2014-05-01 18:15:39 <saivann__> hearn: Sounded to me like he was just tired the wrong day. Anyway, I just helped the weusecoins guys a little bit with the script, they did mostly all the good work.
219 2014-05-01 18:16:11 <hearn> yeah that could also be
220 2014-05-01 18:16:53 <hearn> i should ask stefan if we have the soundtrack independent of the voiceover still. maybe if stephanie is at the conference i can grab her and ask her to try it out
221 2014-05-01 19:22:29 <rccola> what are the pros/cons of using Redis to store the blockchain for faster lookups in a Rails/Heroku app?
222 2014-05-01 19:24:32 <tyrick> faster lookups sounds like a pro
223 2014-05-01 19:27:36 <freewil> i dont think redis would be a good storage solution for the blockchain since it stores all the data in memory
224 2014-05-01 19:28:53 <rccola> why's that? expensive in $$$ terms?
225 2014-05-01 19:38:19 <Ry4an> redis's win isn't really speed -- it's flexibility.  set-operations, multi-key commands, filering, etc. are what make developing in redis and some query workloads fast
226 2014-05-01 19:39:17 <Ry4an> but if you're just doing key/value lookup you'd be much faster w/ an embedded key-value store that ruby talks to via a C extension rather than over a network (as it does with redis)
227 2014-05-01 19:41:44 <rccola> Interesting.  Thanks Ry4an.  What do you think the best way to do balance checking/creating transactions through a Rails app?  Just have it make service calls to a server running bitcoind?
228 2014-05-01 19:42:11 <Ry4an> almost certainly.  It won't be faster, but it'll be correct and that's more important.
229 2014-05-01 19:44:09 <rccola> gracias
230 2014-05-01 20:05:34 <maaku> but don't actually have any private keys in that bitcoind instance
231 2014-05-01 20:39:56 <skinnkavaj> When is this going to be added?
232 2014-05-01 20:39:57 <skinnkavaj> https://en.bitcoin.it/wiki/Sweepprivkey_proposal
233 2014-05-01 20:40:08 <skinnkavaj> And why is it not already?
234 2014-05-01 20:40:44 <wumpus> skinnkavaj: never, if no one adds it...
235 2014-05-01 20:44:00 <wumpus> proposals are one thing, but to merge it we'd really need an implementation
236 2014-05-01 20:51:26 <gmaxwell> I've never seen that.
237 2014-05-01 20:51:55 <Luke-Jr> me either..
238 2014-05-01 20:51:58 <gmaxwell> Mike Caldwell made a bunch of things like that that he never got public attention to; some of it because he kept sending mail to bitcoin development without subscribing.
239 2014-05-01 20:53:44 <gmaxwell> That should probably have an exponentially distributed delay so if multiple wallets are running they don't all create transactions at once. (and also to give it a bit of time to batch multiple payments)
240 2014-05-01 20:55:38 <Luke-Jr> gmaxwell: why would you sweep the same privkey to multiple wallets?
241 2014-05-01 20:56:31 <gmaxwell> Luke-Jr: you have the same sweep loaded into multiple wallets because you're a user and users eat suppositories when given a chance.
242 2014-05-01 20:57:09 <tyrick> I want a suppository
243 2014-05-01 21:03:33 <Luke-Jr> 
ACTION sanitises the page.

244 2014-05-01 21:07:00 <coinmaster> anyone here know how to generate a merkel root hash for a new coin?
245 2014-05-01 21:07:09 <coinmaster> or if anyone knows what channel is more suited for this queston
246 2014-05-01 21:08:29 <justanotheruser> coinmaster: the wiki for merkle root has a picture that pretty much explains it
247 2014-05-01 21:09:04 <ndak> hi how do i autostart bitcoind (reboot) in linux?
248 2014-05-01 21:10:06 <tyrick> for a new block?
249 2014-05-01 21:10:10 <tyrick> are blocks called coins?
250 2014-05-01 21:10:18 <coinmaster> justanotheruser: could you point me to the page? and tyrick, no for a fork
251 2014-05-01 21:10:28 <coinmaster> the genesis block rather
252 2014-05-01 21:10:35 <tyrick> ah
253 2014-05-01 21:10:36 <coinmaster> sorry should have specified that
254 2014-05-01 21:11:13 <justanotheruser> coinmaster: http://en.m.wikipedia.org/wiki/Merkle_tree
255 2014-05-01 21:11:54 <coinmaster> yeah im learning as i go along, im stuck on generating the genesis block. I've got my epoch time, timestamp and genesis markel hash i'm trying to assert but after that it fails
256 2014-05-01 21:12:40 <justanotheruser> coinmaster: that's off topic, but you can look at the bitcoind source, it includes the defined genesis block
257 2014-05-01 21:12:49 <coinmaster> alright thanks
258 2014-05-01 21:12:58 <coinmaster> is there a channel more suited for this?
259 2014-05-01 21:13:44 <justanotheruser> Never been to either of these, but #altcoin or #cryptocurrency may exist
260 2014-05-01 21:14:12 <Luke-Jr> justanotheruser: #altcoin is run by the Altcoin scamcoin
261 2014-05-01 21:14:31 <justanotheruser> Luke-Jr: like an altcoin named altcoin?
262 2014-05-01 21:14:39 <justanotheruser> Weird
263 2014-05-01 21:15:17 <tyrick> Is this an altcoin question?
264 2014-05-01 21:15:49 <coinmaster> yes because im making a fork
265 2014-05-01 21:15:50 <Luke-Jr> justanotheruser: right
266 2014-05-01 21:15:59 <coinmaster> im wondering if there is a development channel for forks
267 2014-05-01 21:16:02 <coinmaster> i guess
268 2014-05-01 21:16:06 <Luke-Jr> coinmaster: #scams maybe
269 2014-05-01 21:16:15 <coinmaster> hue
270 2014-05-01 21:16:36 <coinmaster> i dont see how creating a fork for fun is a scam
271 2014-05-01 21:16:39 <coinmaster> i'm doing it to learn lol
272 2014-05-01 21:16:46 <tyrick> if you fork it, you will die
273 2014-05-01 21:16:49 <coinmaster> but apparently thats not allowed by Luke-Jr
274 2014-05-01 21:16:59 <Luke-Jr> coinmaster: because scammers will use it as a scam
275 2014-05-01 21:17:10 <sipa> if you do it to learn, no need to do it publically
276 2014-05-01 21:17:14 <Luke-Jr> ^
277 2014-05-01 21:17:16 <coinmaster> yeah but i'm seeking help
278 2014-05-01 21:17:19 <coinmaster> not advertising it
279 2014-05-01 21:17:30 <sipa> i will gladly explain how things in bitcoin work here
280 2014-05-01 21:17:31 <Luke-Jr> coinmaster: there are channels for experimenting in *bitcoin* testnets and the like
281 2014-05-01 21:17:48 <tyrick> sipa, I have a question in that case
282 2014-05-01 21:17:57 <sipa> shoot
283 2014-05-01 21:18:36 <justanotheruser> If a coredevs wife wrote "I love you" in a script hash and added it to the blockchain, would the coredev be upset?
284 2014-05-01 21:19:38 <Ry4an> likely.  They understand precedent perfectly well.
285 2014-05-01 21:19:53 <tyrick> Thanks, let me dig through some of my notes
286 2014-05-01 21:20:41 <sipa> justanotheruser: glad i'm not married :p
287 2014-05-01 21:21:02 <tyrick> AptInit() in bitcoind.cpp;  a thread called detectShutdownThread is created within threadGroup
288 2014-05-01 21:21:06 <maaku> justanotheruser: who was the transaction sent to ;)
289 2014-05-01 21:21:19 <justanotheruser> maaku: the coredev
290 2014-05-01 21:21:57 <hearn> justanotheruser: i’d be upset!
291 2014-05-01 21:21:59 <tyrick> Then threadGroup is passed to AppInit2, and various threads are added via create_thread()
292 2014-05-01 21:22:13 <hearn> because i’d discover i had a wife i didn’t know about!
293 2014-05-01 21:22:14 <sipa> tyrick: it's the main thread group
294 2014-05-01 21:22:25 <justanotheruser> hearn: are you a coredev?
295 2014-05-01 21:22:27 <hearn> although it’d be nice to know she loved me anyway :)
296 2014-05-01 21:22:32 <tyrick> sure, but why two different ways to create threads?
297 2014-05-01 21:22:38 <hearn> dunno. find another core dev and ask them :)
298 2014-05-01 21:22:40 <ndak> hi i am stuck in my openvpnserver install with ERROR: Linux route add command failed: external program exited with error status: 7.. if you know how to fix it please msg me. i gonna pay you /msg me
299 2014-05-01 21:22:46 <justanotheruser> What is your github?
300 2014-05-01 21:22:54 <sipa> ndak: 3rd time i ask you: not here
301 2014-05-01 21:23:20 <justanotheruser> Please ban, he posted on #bitcoin too
302 2014-05-01 21:23:24 <gmaxwell> weird chanserv delay.
303 2014-05-01 21:23:27 <tyrick> why not use new boost::thread() everytime?
304 2014-05-01 21:23:30 <ndak> sipa: ok i am sorry
305 2014-05-01 21:23:31 <hearn> justanotheruser: mikehearn. but i don’t write much code for bitcoin core. i’ve done some protocol design work. mostly i write bitcoinj
306 2014-05-01 21:23:35 <ndak> amessage
307 2014-05-01 21:23:42 <tyrick> this way a variable for each thread can be assigned?
308 2014-05-01 21:23:56 <sipa> tyrick: historical reasons, most likely
309 2014-05-01 21:24:09 <justanotheruser> hearn: I see. That's cool
310 2014-05-01 21:24:28 <justanotheruser> I am still trying to understand all of bitcoin source code
311 2014-05-01 21:25:00 <justanotheruser> *bitcoinds
312 2014-05-01 21:25:13 <tyrick> okay, you guys have really come a long way in organizing this project
313 2014-05-01 21:25:46 <tyrick> I am comparing the today's code with litecoin (since I assume it represents an earlier fork) and it is much more organized
314 2014-05-01 21:26:10 <sipa> i thought litecoin kept up pretty well
315 2014-05-01 21:26:56 <justanotheruser> tyrick: compare it to ixcoin
316 2014-05-01 21:27:08 <tyrick> It's possible, but I easily get lost when try to navigate through it
317 2014-05-01 21:27:09 <justanotheruser> IIRC, it is the first fork
318 2014-05-01 21:27:21 <tyrick> trying*
319 2014-05-01 21:27:50 <sipa> or namecoin :)
320 2014-05-01 21:29:35 <tyrick> Another question
321 2014-05-01 21:29:57 <tyrick> I haven't started getting into how data is stored in the .bitcoin folder
322 2014-05-01 21:30:14 <tyrick> If I attempt to cat a block file, nothing but craziness comes out
323 2014-05-01 21:30:26 <sipa> the block files just contain blocks
324 2014-05-01 21:30:33 <sipa> in network serialized format
325 2014-05-01 21:30:42 <sipa> one after the other
326 2014-05-01 21:30:59 <tyrick> ok, so they are just the block objects serialized?
327 2014-05-01 21:31:04 <sipa> yes
328 2014-05-01 21:31:05 <tyrick> that makes sense
329 2014-05-01 21:31:15 <sipa> with 8 byte prefixes
330 2014-05-01 21:31:38 <sipa> 4 bytes network magic + 4 bytes length descriptor of the following block
331 2014-05-01 21:31:55 <tyrick> I guess all of this is in serialize.h
332 2014-05-01 21:32:20 <sipa> serialize.h is the generic serialization framework + serializers for common data types
333 2014-05-01 21:32:43 <sipa> core.h contains the data definitions for blocks/transactions/..., and their serializations
334 2014-05-01 21:33:40 <tyrick> Oh wow. I've never looked in that file
335 2014-05-01 21:34:01 <tyrick> lots of goodies
336 2014-05-01 21:34:45 <tyrick> okay, this is more of a C++ question: What is this syntax
337 2014-05-01 21:35:00 <tyrick> CBlockHeader GetBlockHeader() const { ... }
338 2014-05-01 21:35:43 <tyrick> I am a Java guy, but 2 C programmers around me are baffled at it as well
339 2014-05-01 21:36:01 <sipa> it defines a method named GetBlockHeader, which takes no arguments and returns a CBlockHeader
340 2014-05-01 21:36:13 <sipa> and does not modify the objext it is called on
341 2014-05-01 21:36:16 <tyrick> and the const coming after the function name?
342 2014-05-01 21:36:30 <sipa> it means it can be called on a const object
343 2014-05-01 21:36:43 <sipa> as it does not modify the object
344 2014-05-01 21:38:14 <tyrick> so CBlock would need to be a const object for that function to be called?
345 2014-05-01 21:39:08 <sipa> yes
346 2014-05-01 21:39:41 <sipa> it's often the case that you pass around a pointer to a block, but don't want it to be modified by the callee
347 2014-05-01 21:39:58 <tyrick> even though the function clearly doesn't modify the original object, I guess const is added as a precaution?
348 2014-05-01 21:40:04 <sipa> so then it can take a const CBlock* argument
349 2014-05-01 21:40:39 <sipa> no, without that const modifier, you *cannot* call the method if the CBlock is const
350 2014-05-01 21:40:44 <tyrick> Makes sense, but in this function's case, a new CBlockHeader is being returned
351 2014-05-01 21:41:07 <tyrick> ohhh
352 2014-05-01 21:41:08 <tyrick> I see
353 2014-05-01 21:41:16 <sipa> yes, so it does not modify the CBlock, so it makes sense to be able to call it on a const CBlock, so it has to be a const method
354 2014-05-01 21:44:04 <maaku> tyrick: object references and pointers are automatically converted to be const if needed, so you can freely call a const method from a non-const reference
355 2014-05-01 21:44:55 <tyrick> sry, got d/c
356 2014-05-01 21:44:58 <tyrick> was that a yes?
357 2014-05-01 21:45:25 <maaku> tyrick: what was the question?
358 2014-05-01 21:46:29 <tyrick> Is it the case that SetNull *CANNOT* be called on a const CBlock
359 2014-05-01 21:47:22 <maaku> correct
360 2014-05-01 21:47:38 <maaku> on a const CBlock you can only call methods that are marked "const"
361 2014-05-01 21:47:56 <tyrick> sweet; I just leveled up my C++ skills
362 2014-05-01 21:48:00 <tyrick> Thanks
363 2014-05-01 22:16:59 <dokan> i want to buy something like this: www.bitrun.net .. if you have anything /msg me
364 2014-05-01 22:38:44 <Tiestoale> Hi All
365 2014-05-01 23:25:12 <lechuga_> some1 told me recently there was a protocol change to allow relay of partially signed txns
366 2014-05-01 23:25:16 <lechuga_> is that actually true?
367 2014-05-01 23:30:00 <justanotheruser> lechuga_: if they're valid?