1 2015-02-12 00:05:47 <sipa> L_Cranston_Shado: it likely works
2 2015-02-12 00:07:03 <L_Cranston_Shado> so⦠theuniâs trivial branch is pretty much the defacto official branch for âtrivialâ issues?
3 2015-02-12 00:08:08 <L_Cranston_Shado> ignoring for the fact that people have no way of knowing that, or really even that the branch exists, until they create an issue thatâs already been posted there, I just want to confirm that before I close my PR that duplicates it
4 2015-02-12 00:08:21 <L_Cranston_Shado> since the one from theuni was never PRed to the main repo
5 2015-02-12 00:09:41 <L_Cranston_Shado> since fanquake called me out on it
6 2015-02-12 00:12:46 <sipa> L_Cranston_Shado: don't bithrr; theuni will pull in the changes into his branch
7 2015-02-12 00:12:49 <sipa> *bother
8 2015-02-12 00:13:33 <L_Cranston_Shado> strikes me as kind of a roundabout way to do things and somewhat antithetical to transparency, especially for changes that donât rely on a build release
9 2015-02-12 00:14:22 <L_Cranston_Shado> I realize Iâm the new guy, but whatâs the point of doing them separately rather than a specific PR/merge for each one in the main repo? Iâm not trying to be a smartass, I really am interested.
10 2015-02-12 00:20:48 <sipa> L_Cranston_Shado: review bandwidth
11 2015-02-12 00:21:27 <sipa> we're very serieus about looking at all code changes carefully
12 2015-02-12 00:21:42 <sipa> but many trivial changes can easily be batched and rebased, and then later reviewed at once
13 2015-02-12 00:22:14 <L_Cranston_Shado> makes sense, thanks for the explanation. Iâll close my PR then
14 2015-02-12 00:22:45 <sipa> no!
15 2015-02-12 00:22:59 <sipa> not before theuni has pulled the changes into the trivial branch :)
16 2015-02-12 00:23:41 <L_Cranston_Shado> theyâre already in his branch
17 2015-02-12 00:23:48 <sipa> ah, then you can close
18 2015-02-12 00:23:49 <sipa> sorry
19 2015-02-12 00:23:51 <L_Cranston_Shado> https://github.com/theuni/bitcoin/pull/3
20 2015-02-12 00:25:44 <L_Cranston_Shado> I wish there was a way to watch a specific branch, rather than a whole repo
21 2015-02-12 01:00:33 <fanquake> L_Cranston_Shado Sorry I should have explained further when I commented.
22 2015-02-12 01:01:16 <fanquake> The plan is to merge theuniâs trivial branch every few weeks. As sipa said itâs just to remove everythign trival from the review pipeline.
23 2015-02-12 01:01:36 <fanquake> If it turns out to work well the repo will be moved underneath the bitcoin org.
24 2015-02-12 01:14:02 <earlz> really gonedrk
25 2015-02-12 01:14:21 <earlz> er, wrong room
26 2015-02-12 01:42:13 <Luke-Jr> gdm85: gitian already supports using containersâ¦
27 2015-02-12 01:42:59 <midnightmagic> LXC mac builds don't work for everyone yet
28 2015-02-12 03:20:44 <fanquake> ;;blocks
29 2015-02-12 03:20:45 <gribble> 343095
30 2015-02-12 05:24:42 <throughnothing> Is there a good document with details on how to build an SPV client. I know there's some high-level info on the bitcoin.org developer guide, and theres some useful stuff in BIP37, but wondering if anyone has put together anything more comprehensive on this?
31 2015-02-12 05:24:53 <throughnothing> or is the best way just to look at other implementations and slowly figure out what they're doing
32 2015-02-12 05:25:21 <phantomcircuit> throughnothing, the latter probably
33 2015-02-12 05:25:35 <phantomcircuit> of course put a giant warning sign on your code about being alpha quality :P
34 2015-02-12 05:25:39 <throughnothing> :/ ok, thats what I was afraid of
35 2015-02-12 05:25:44 <throughnothing> yeah, I want to do this more as learning for me
36 2015-02-12 05:26:14 <throughnothing> not as something I would encourage others to use :)
37 2015-02-12 05:26:26 <throughnothing> I've been kinda looking at bitcoinJ and breadwallet implementations
38 2015-02-12 05:26:40 <throughnothing> but its kinda like without a full understanding, its difficult to see why certain things are being done
39 2015-02-12 05:26:51 <throughnothing> will just take me a lot longer the reverse engineering way
40 2015-02-12 05:27:07 <phantomcircuit> have you read the whitepaper?
41 2015-02-12 05:27:24 <phantomcircuit> it's actually a very effective piece of writing
42 2015-02-12 05:27:33 <throughnothing> yeah, I have read it a few times
43 2015-02-12 05:27:34 <throughnothing> :)
44 2015-02-12 05:27:57 <phantomcircuit> try building something that speaks the p2p protocol but doesn't do any of the spv logic yet
45 2015-02-12 05:28:12 <phantomcircuit> that is definitely a minimum barrier type project that might help you understand things a bit more
46 2015-02-12 05:28:33 <throughnothing> yes, I've looked over the protocol, and stolen the list of seed nodes from other projects mentioned above
47 2015-02-12 05:28:41 <phantomcircuit> heh
48 2015-02-12 05:28:48 <throughnothing> and have code connecting to peers from the seeds, and sending versison, and getting version ack's
49 2015-02-12 05:28:50 <throughnothing> thats about it :)
50 2015-02-12 05:28:54 <phantomcircuit> iirc most of those will push an "addr" to you and then disconnect
51 2015-02-12 05:29:03 <throughnothing> hmm
52 2015-02-12 05:29:08 <throughnothing> they do give me start_height, etc.
53 2015-02-12 05:29:11 <phantomcircuit> oh nvm you're talking dns seeds
54 2015-02-12 05:29:12 <throughnothing> and some of them inv me
55 2015-02-12 05:29:19 <throughnothing> yeah
56 2015-02-12 05:29:21 <throughnothing> the dns seeds
57 2015-02-12 05:29:28 <throughnothing> bluematt, sippa.be or whatever
58 2015-02-12 05:29:30 <phantomcircuit> throughnothing, get a list of the block hashes and handle getdata/block messages
59 2015-02-12 05:29:30 <throughnothing> those
60 2015-02-12 05:29:47 <phantomcircuit> dont worry about the getblocks stuff initially
61 2015-02-12 05:29:53 <throughnothing> i think what i struggle with, is that there don't seem to be recommendations for like, hwo many nodes to keep connections too
62 2015-02-12 05:30:05 <throughnothing> I see things in other implementations like 'track evil/malicious nodes'
63 2015-02-12 05:30:07 <phantomcircuit> throughnothing, less than 8 more than 2
64 2015-02-12 05:30:10 <throughnothing> and best practices to do all of that stuff
65 2015-02-12 05:30:21 <throughnothing> phantomcircuit: great, thx
66 2015-02-12 05:30:30 <phantomcircuit> and yeah it's generally a good idea to disconnect from nodes that send you obviously wrong stuff
67 2015-02-12 05:30:30 <throughnothing> i was starting with 2, but have tested with 8
68 2015-02-12 05:30:31 <throughnothing> hehe
69 2015-02-12 05:30:42 <phantomcircuit> otherwise you'll waste a bunch of effort trying to make sense of nonsense
70 2015-02-12 05:30:49 <throughnothing> phantomcircuit: it seems like rules of thumb would be nice, b/c I can make up my own heuristics, but it seems like I wont do that 'right'
71 2015-02-12 05:30:50 <throughnothing> like
72 2015-02-12 05:30:57 <throughnothing> just take the majority start_height agreement
73 2015-02-12 05:30:59 <phantomcircuit> but that isn't really important for an initial implementation
74 2015-02-12 05:31:02 <throughnothing> and ignore nodes that give me something way off
75 2015-02-12 05:31:02 <throughnothing> etc.
76 2015-02-12 05:31:05 <throughnothing> but is that 'standard'?
77 2015-02-12 05:31:18 <mappum> phantomcircuit: just wondering, why less than 8? more would put too much load on the network?
78 2015-02-12 05:31:19 <phantomcircuit> throughnothing, nope since there will be nodes that are legitimately behind
79 2015-02-12 05:31:34 <phantomcircuit> mappum, it doesn't get you much of anything and is annoying for everybody else
80 2015-02-12 05:31:40 <throughnothing> phantomcircuit: right, but if one node gives me something 100 blocks behind, its probably not gonna be useful/
81 2015-02-12 05:31:41 <phantomcircuit> bitcoins a gossip network
82 2015-02-12 05:31:55 <phantomcircuit> do you really need to have more than 8 sources of gossip?
83 2015-02-12 05:32:05 <throughnothing> another thing I haven't figured out yet, is....doesn't getblocks() have the nodes give you NEWER blocks
84 2015-02-12 05:32:09 <phantomcircuit> throughnothing, nonsense :P
85 2015-02-12 05:32:09 <throughnothing> how do i go backwards?
86 2015-02-12 05:32:32 <throughnothing> do u just start at a hard-coded genesis block?
87 2015-02-12 05:32:35 <throughnothing> and start asking from there, etc.
88 2015-02-12 05:32:44 <phantomcircuit> throughnothing, have you seen https://en.bitcoin.it/wiki/Protocol_specification#getblocks
89 2015-02-12 05:32:52 <throughnothing> i also notice many implementations re-implement the 'checkpoints' from bitcoin core
90 2015-02-12 05:32:57 <throughnothing> not sure if there's actually value in that
91 2015-02-12 05:33:27 <throughnothing> phantomcircuit: yeah, thats what im looking at, but the nodes respond with blocks *newer* than the block you send, right?
92 2015-02-12 05:33:34 <throughnothing> so how would I find out the block BEFORE a block
93 2015-02-12 05:33:53 <throughnothing> or can you not do that :)
94 2015-02-12 05:33:56 <phantomcircuit> throughnothing, you walk from the genesis up
95 2015-02-12 05:34:01 <phantomcircuit> not from the latest block down
96 2015-02-12 05:34:07 <throughnothing> ok... cool
97 2015-02-12 05:34:11 <throughnothing> it seems like the inbound inv's that I get
98 2015-02-12 05:34:16 <throughnothing> they are giving me their latest blocks
99 2015-02-12 05:34:18 <phantomcircuit> iirc each node gives you it's idea of the longest chain
100 2015-02-12 05:34:19 <throughnothing> thats why I was confused
101 2015-02-12 05:34:32 <phantomcircuit> throughnothing, you need to hard code the genesis block either way
102 2015-02-12 05:34:38 <throughnothing> yeah, makes sense
103 2015-02-12 05:34:51 <phantomcircuit> technically i think you just need the genesis block hash
104 2015-02-12 05:34:52 <throughnothing> so, my first task was goin to be to try to get ALL of the headers
105 2015-02-12 05:34:53 <phantomcircuit> but like
106 2015-02-12 05:34:58 <phantomcircuit> just have the full block
107 2015-02-12 05:34:58 <throughnothing> in a chain that lines up
108 2015-02-12 05:35:01 <throughnothing> is that a right approach?
109 2015-02-12 05:35:07 <phantomcircuit> absolutely
110 2015-02-12 05:35:22 <throughnothing> so, just start asking at the genesis block, and try to build a hash chain all the way to the latest block
111 2015-02-12 05:35:40 <mr_burdell> you can get the previous block from the current block header
112 2015-02-12 05:35:41 <phantomcircuit> yup
113 2015-02-12 05:35:44 <throughnothing> will have to figure out the coordination amongst my 2-8 threads to do this most efficiently
114 2015-02-12 05:35:52 <throughnothing> mr_burdell: how do you do that
115 2015-02-12 05:35:53 <phantomcircuit> mr_burdell, one block at a time
116 2015-02-12 05:35:57 <throughnothing> ah
117 2015-02-12 05:36:06 <phantomcircuit> throughnothing, the prevblock field in each block
118 2015-02-12 05:36:15 <phantomcircuit> but that's gonna be stupid slow
119 2015-02-12 05:36:18 <throughnothing> ahh
120 2015-02-12 05:36:20 <throughnothing> makes sense
121 2015-02-12 05:36:23 <throughnothing> but also
122 2015-02-12 05:36:26 <throughnothing> u could be fooled that way
123 2015-02-12 05:36:32 <throughnothing> b/c u could get to the 'end' (beginning) and not be at genesis
124 2015-02-12 05:36:36 <throughnothing> so it seems u have to start at genesis
125 2015-02-12 05:36:39 <mr_burdell> yeah... but if you only needed a few blocks, it would work
126 2015-02-12 05:36:42 <throughnothing> or someone could feed you a wrong backwards tree, and you wouldn't know
127 2015-02-12 05:36:48 <phantomcircuit> throughnothing, you definitely need the genesis
128 2015-02-12 05:36:48 <throughnothing> s/tree/chain
129 2015-02-12 05:36:57 <throughnothing> so, another thought I had
130 2015-02-12 05:37:01 <phantomcircuit> the issue is more that peers lie to you and give you a fork
131 2015-02-12 05:37:01 <throughnothing> to speed things up for frist time users
132 2015-02-12 05:37:10 <phantomcircuit> rather than they lie and dont let you walk back to the genesis
133 2015-02-12 05:37:11 <throughnothing> say, I know i'm writing my client on Feb 11 2015
134 2015-02-12 05:37:15 <phantomcircuit> but this is solved by asking 8 peers
135 2015-02-12 05:37:19 <throughnothing> can I hard code a current block that is like 50 blocks deep
136 2015-02-12 05:37:22 <throughnothing> and just start there
137 2015-02-12 05:37:23 <phantomcircuit> what are the odds 8 random peers all lie to you?
138 2015-02-12 05:37:26 <throughnothing> and trust that its good
139 2015-02-12 05:37:32 <throughnothing> so i don't have to sync the whole chain
140 2015-02-12 05:37:37 <throughnothing> since nobody could have used my wallet before then
141 2015-02-12 05:37:45 <mr_burdell> if no one will ever use a previously generated priv key in your client...
142 2015-02-12 05:37:47 <mappum> throughnothing: that's what checkpointing is, generally people make them 1 month back
143 2015-02-12 05:38:00 <throughnothing> mappum: ok, so thats not a dumb thing to do, other ppl do that?
144 2015-02-12 05:38:10 <phantomcircuit> throughnothing, so bitcoin core has "checkpoints" which are a performance thing that allows bitcoind to ignore block validation rules that are expensive for blocks that are like 6 months old
145 2015-02-12 05:38:15 <throughnothing> these are the kinda questions that I feel like, not being a cryptographer, I do'nt feel compartable just making these decisions arbitrarily
146 2015-02-12 05:38:28 <mappum> yes, it's basically having people trust you instead of nodes on the chain to use
147 2015-02-12 05:38:30 <throughnothing> phantomcircuit: right, i'm aware of those
148 2015-02-12 05:38:42 <throughnothing> mappum: yes, and they can inspect the code, so don't have to trust me per se
149 2015-02-12 05:38:47 <throughnothing> if they check the code and agree on that block
150 2015-02-12 05:38:48 <mappum> exactly
151 2015-02-12 05:38:50 <throughnothing> (and its open source)
152 2015-02-12 05:39:01 <phantomcircuit> throughnothing, the easier thing would be to ship the ~32MB of block headers and then run the full validation logic for headers since it's so cheap
153 2015-02-12 05:39:23 <mappum> also, you said nobody would have transactions before that certain date, that might not be true if you let people import keys from other wallets
154 2015-02-12 05:39:41 <phantomcircuit> i've actually suggested bitcoind do that but it's not ideal for a number of reasons
155 2015-02-12 05:39:56 <mappum> if they generate new keys in your wallet, you know the creation date though and you don't have to look for transactions before that date
156 2015-02-12 05:40:01 <phantomcircuit> mappum, that's easy to solve "dont do dat"
157 2015-02-12 05:40:36 <mappum> don't import keys? why not?
158 2015-02-12 05:43:13 <mappum> well i was thinking like BIP32 standard format wallets
159 2015-02-12 05:43:13 <phantomcircuit> ew
160 2015-02-12 05:43:13 <phantomcircuit> iirc chomebooks have automated google auto update
161 2015-02-12 05:43:13 <phantomcircuit> mappum, because users are dumb and generate shitty keys in stupid ways
162 2015-02-12 05:43:13 <phantomcircuit> so think linux but with a google backdoor
163 2015-02-12 05:43:13 <phantomcircuit> throughnothing, "im baking my bread in this lovely converted sewer pipe"
164 2015-02-12 05:43:13 <throughnothing> (I also am working on trezor support, have written a chrome-compatible usb-hid trezor library)
165 2015-02-12 05:43:13 <throughnothing> I think (non-dev mode) chromebook could be a cheap and really secure way for people to have a wallet
166 2015-02-12 05:43:13 <throughnothing> javascript/chrome
167 2015-02-12 05:43:13 <throughnothing> much more secure than on a linux or mac laptop
168 2015-02-12 05:43:13 <throughnothing> :-O
169 2015-02-12 05:43:13 <throughnothing> phantomcircuit: meh, i should add that i'm doing this in javascript with an eye towards making a full spv node for a chromebook
170 2015-02-12 05:43:13 <throughnothing> why ew?
171 2015-02-12 05:43:43 <throughnothing> phantomcircuit: but for grandma, its probably the most secure computer she could ever use
172 2015-02-12 05:43:51 <throughnothing> and those people are already trusting MS or Apple
173 2015-02-12 05:44:07 <throughnothing> i think chromebook is a way better option for someone like my mom, and I would feel much more secure with her having bitcoin there, than on her windows laptop
174 2015-02-12 05:44:08 <phantomcircuit> i guess :|
175 2015-02-12 05:44:13 <throughnothing> their CSP model is very good
176 2015-02-12 05:44:15 <throughnothing> on chromebook
177 2015-02-12 05:44:20 <phantomcircuit> anyways gtg
178 2015-02-12 05:44:27 <throughnothing> yes, you have to log in with google (unfortunately, i hate this too), but it is pretty secure
179 2015-02-12 05:44:28 <phantomcircuit> it's late and i have to drive for forever to get home
180 2015-02-12 05:44:30 <throughnothing> phantomcircuit: great, thanks for your help!
181 2015-02-12 05:44:33 <throughnothing> really appreciate it
182 2015-02-12 05:44:55 <phantomcircuit> youre welcome
183 2015-02-12 05:45:04 <mappum> possibility of backdoors isn't always a good reason not to try to build stuff, baseband processors of smartphones already have full code execution access by mobile carriers
184 2015-02-12 05:45:22 <throughnothing> the one thing chrome lacks apparently, which surprised me, is a keychain
185 2015-02-12 05:45:24 <throughnothing> at least a good one
186 2015-02-12 05:45:30 <throughnothing> :/
187 2015-02-12 05:45:41 <throughnothing> but anyway, thats work-aroundable
188 2015-02-12 05:45:51 <throughnothing> they don't provide secure storage either, so u have to do that in your app
189 2015-02-12 05:45:55 <throughnothing> which is arguable better
190 2015-02-12 05:45:59 <mappum> at least mozilla is finally developing a js crypto api
191 2015-02-12 05:46:00 <throughnothing> arguably*
192 2015-02-12 05:46:11 <throughnothing> granted, chromeOS is open source, so I don't know that they can be THAT nefarious
193 2015-02-12 05:46:28 <throughnothing> no deterministic builds to verify the code running on your machine, of course
194 2015-02-12 05:46:32 <throughnothing> or anything like that
195 2015-02-12 05:46:47 <throughnothing> but, compared to what an average user will be using (windows or OSX), chromebook is leaps and bounds more secure IMO
196 2015-02-12 05:46:58 <throughnothing> it scares me that ppl keep wallets on a windows/mac/even linux computer
197 2015-02-12 05:47:30 <throughnothing> also, things like keyloggers in a chrome app on a chromebook are very difficult to achieve
198 2015-02-12 05:47:38 <throughnothing> (at least it seems that way to me)
199 2015-02-12 05:47:48 <throughnothing> mappum: huh, cool, i didn't know that
200 2015-02-12 05:48:10 <throughnothing> mappum: I would like to make it work cross-browser, but that doesn't seem super feasible atm, and chrome seems like the best option b/c of chromebooks
201 2015-02-12 05:48:18 <throughnothing> i'm much more of a fan of firefox than chrome
202 2015-02-12 05:49:31 <throughnothing> anyway, mappum thanks for your help too, that gives me a starting point, until i run into all sorts of more questions to come back with :P
203 2015-02-12 05:50:19 <mappum> throughnothing: just wondering, why not use existing libraries? there are things like bitcore or bitcoinjs
204 2015-02-12 05:50:33 <throughnothing> i am
205 2015-02-12 05:50:38 <throughnothing> i'm using bitcore currently
206 2015-02-12 05:50:44 <mappum> ah, ok
207 2015-02-12 05:50:50 <mappum> and they don't do SPV for you?
208 2015-02-12 05:50:54 <throughnothing> but, as practice, i've implemented some of the low level stuff myself, with bitcore as a guide
209 2015-02-12 05:50:55 <throughnothing> to learn
210 2015-02-12 05:51:00 <throughnothing> but I expect my final version will use bitcore
211 2015-02-12 05:51:06 <throughnothing> b/c it will be more developed and maintained by bitpay
212 2015-02-12 05:51:08 <throughnothing> than what I will do
213 2015-02-12 05:51:26 <throughnothing> mappum: they give me peer connecting and all that (which i've re-implemented for learning), and message sending
214 2015-02-12 05:51:28 <throughnothing> but there's no like
215 2015-02-12 05:51:34 <throughnothing> bitcore-p2p.run_spv()
216 2015-02-12 05:51:35 <throughnothing> heh
217 2015-02-12 05:51:47 <throughnothing> as far as I can tell, you have to manage the messages to send, and what to do with the data received yourself
218 2015-02-12 05:51:57 <throughnothing> but they give you everything below that point
219 2015-02-12 05:51:58 <mappum> i see, i thought they would have a full client
220 2015-02-12 05:52:08 <throughnothing> maybe there is an example of one somewhere that I haven't seen
221 2015-02-12 05:52:10 <throughnothing> as like a demo
222 2015-02-12 05:52:25 <throughnothing> http://bitcore.io/guide/module/p2p/index.html
223 2015-02-12 05:52:32 <throughnothing> is what im going with
224 2015-02-12 05:52:53 <mappum> there's a good chance there isn't, there hasn't been much financial incentive to develop wallet software, but there is a ton of shitty exchange software (since it is profitable)
225 2015-02-12 05:52:56 <throughnothing> the docs aren't great, so digging through the source/tests is more fruitful
226 2015-02-12 05:53:04 <throughnothing> mappum: heh, yeah
227 2015-02-12 05:53:16 <throughnothing> mappum: what projects do you work on? bitcoin core?
228 2015-02-12 05:53:43 <mappum> right now i'm working on a trustless exchange+wallet
229 2015-02-12 05:53:55 <throughnothing> also, I was using bitcoinjs at first, but then realized i think bitcore is being much more well maintained by bitpay, since they have a financial incentive
230 2015-02-12 05:54:01 <throughnothing> I also looked at 'fullnode' by ryan charles
231 2015-02-12 05:54:07 <throughnothing> but it seemes like bitcore makes the most sense
232 2015-02-12 05:54:18 <mappum> it's a SPV desktop wallet that runs different coins and can make trades between different currencies with the atomic swap protocol
233 2015-02-12 05:54:20 <throughnothing> mappum: oooh nice, trustless AND decentralized? or just trustless
234 2015-02-12 05:54:47 <mappum> it's *mostly* decentralized, the order matching isn't though (by default at least)
235 2015-02-12 05:54:51 <throughnothing> this is something open transaction is trying to do also, right?
236 2015-02-12 05:54:54 <throughnothing> in a different way
237 2015-02-12 05:55:55 <mappum> it's possible, i don't know much about them
238 2015-02-12 05:56:29 <throughnothing> its pseudo-federated, but you don't have to trust any of the nodes, and you can guarantee they can't steal your coins
239 2015-02-12 05:56:31 <throughnothing> don't fully understand it either
240 2015-02-12 05:56:34 <throughnothing> but it sounds interesting
241 2015-02-12 06:03:17 <mappum> i can't seem to find anything about that, do you have a link to what you mean?
242 2015-02-12 06:03:50 <mappum> to clarify i'm doing trades across blockchains, i think OT only deals with stuff built on bitcoin?
243 2015-02-12 06:16:42 <throughnothing> mappum: ah, you may be right, im not sure, most of what I know, i found in a talk on youtube
244 2015-02-12 06:16:46 <throughnothing> by the head guy, can't remember his name
245 2015-02-12 06:17:43 <throughnothing> err oops
246 2015-02-12 06:17:44 <throughnothing> did that link go through?
247 2015-02-12 06:19:44 <mappum> throughnothing: nope
248 2015-02-12 06:20:37 <throughnothing> lets try again
249 2015-02-12 06:20:38 <throughnothing> i think this one: https://www.youtube.com/watch?v=teNzIFu5L70
250 2015-02-12 06:20:46 <throughnothing> was the talk I watched
251 2015-02-12 07:10:08 <dfletcher> just did my first multisig tx on testnet that works neat. couple questions. 1) is there some way to now do equiv of `listunspent`for it somehow or maybe using some online service like blockchain.info? 2) this example doesn't put a fee. just put a fee field when doing the createtransaction? and umm... how much fee? :)
252 2015-02-12 07:11:43 <gmaxwell> you can import the addresses you wish to watch (watching wallet functionality); and you create a fee by making the outputs less in value than the inputs.
253 2015-02-12 07:17:22 <L_Cranston_Shado> If I need to reinstall gitian builder (the previous install stopped part-way through) I just need to rm the two gitian precise folders, right?
254 2015-02-12 07:17:37 <dfletcher> ahh ok just did importaddress and listunspent shows it, genius thanks gmaxwell
255 2015-02-12 07:17:55 <L_Cranston_Shado> evening gmaxwell
256 2015-02-12 07:18:40 <dfletcher> guess I should try do it before the sendrawtransaction and not have it scan the wallet every time heh that took a while.
257 2015-02-12 07:21:33 <dfletcher> ok right gmaxwell re fees right i forgot that. no prob, subtract it from the change should work. what about the value? call estimatefee?
258 2015-02-12 07:25:36 <dfletcher> also heh i wonder why the explorer calls my multisig inputs and outputs "strange" http://blockexplorer.com/testnet/t/6EFV5rt7Mt
259 2015-02-12 07:42:26 <L_Cranston_Shado> I think me saying good evening scared gmaxwell away :)
260 2015-02-12 07:43:39 <jonasschnelli> L_Cranston_Shado, to reinstall gitian best maybe would be to rm the whole gitian.git-dir clone
261 2015-02-12 07:43:52 <jonasschnelli> then do a fresh checkout and build your base images again
262 2015-02-12 07:44:03 <jonasschnelli> be aware of the LXC KVM differences
263 2015-02-12 07:49:59 <L_Cranston_Shado> while Iâm waiting for the source files to download, howâs your morning going Jonas?
264 2015-02-12 07:57:26 <L_Cranston_Shado> jonasschnelli, I followed the rest of the steps to the letter, including the two on the release process page that it said to do, but I keep getting some gnarly errors on the build - https://gist.github.com/L-Cranston-Shadow/ac30de60df5fbb890443, any thoughts?
265 2015-02-12 08:01:08 <jonasschnelli> L_Cranston_Shado, you gist gives a 404
266 2015-02-12 08:01:41 <L_Cranston_Shado> https://gist.github.com/L-Cranston-Shadow/ac30de60df5fbb890443
267 2015-02-12 08:01:44 <fanquake> L_Cranston_Shado did you export VERSION=0.10.0rc4 ?
268 2015-02-12 08:02:24 <L_Cranston_Shado> I did not, doesnât like not having a version?
269 2015-02-12 08:02:45 <fanquake> Correct, you have to define which version your building.
270 2015-02-12 08:03:24 <L_Cranston_Shado> correct me if Iâm wrong, but isnât it pretty much doing the build within a virtual machine which is within a virtual machine?
271 2015-02-12 08:04:03 <fanquake> Yep.
272 2015-02-12 08:04:12 <L_Cranston_Shado> where are the human batteries?
273 2015-02-12 08:04:14 <jonasschnelli> L_Cranston_Shado, did you built your base images first?
274 2015-02-12 08:04:44 <L_Cranston_Shado> Iâm pretty much just following the instructions
275 2015-02-12 08:04:52 <jonasschnelli> you should set the VERSION and SIGNER env vars
276 2015-02-12 08:05:08 <jonasschnelli> Also have a look at gpg (create a key and make sure SIGNER matches your key name/email)
277 2015-02-12 08:05:48 <L_Cranston_Shado> Iâm not actually going to be exporting the signatures at this point so if it lets me get away with it Iâll make sure to do it next time but not stop it already in progress
278 2015-02-12 08:15:08 <jonasschnelli> L_Cranston_Shado, you can also add a "-j 5" argument for the gbuild command. This will speed up things
279 2015-02-12 08:15:42 <jonasschnelli> And if you have enough ram on your machine, maybe a "-m 2048" will help as well
280 2015-02-12 08:15:43 <L_Cranston_Shado> Iâm not even seeing a build.log, despite the fact that itâs gotten to that point and says there should be one, Iâm wondering if the process hanged (hung?)
281 2015-02-12 08:16:14 <jonasschnelli> build.log is in ./var and will only created if the build could started... see also target.log
282 2015-02-12 09:08:53 <L_Cranston_Shado> at what point do I get worried? Iâm running the build using terminal but I confirmed direct from the vm shell using PS that gbuild and lxc are running
283 2015-02-12 09:09:16 <L_Cranston_Shado> itâs been about an hour at this point
284 2015-02-12 09:10:58 <Luke-Jr> L_Cranston_Shado: check out var/build.log
285 2015-02-12 09:11:33 <L_Cranston_Shado> no build.log in /var/log
286 2015-02-12 09:11:57 <Luke-Jr> var, not /var
287 2015-02-12 09:16:35 <L_Cranston_Shado> got it, thanks. Itâs working, albeit slowly
288 2015-02-12 09:18:12 <L_Cranston_Shado> next time Iâm going to try bumping the vm up to 2048 and see if that makes a significant difference, along with trying the -j 5 argument that jonas suggested
289 2015-02-12 09:21:01 <Luke-Jr> I don't think 2048 MB is enough for -j 5
290 2015-02-12 09:21:23 <Luke-Jr> probably need more
291 2015-02-12 09:21:50 <Luke-Jr> 32-bit host OS are limited to 2047 MB though, so just decrease -j if necessary
292 2015-02-12 09:22:32 <jonasschnelli> Luke-Jr, good to know. Let me try with 4098 and see if it makes a difference in performance
293 2015-02-12 09:22:36 <wumpus> I've had trashing problems with -j5 with 8GB of memory at some point (though with plenty of other things running)
294 2015-02-12 09:23:10 <wumpus> ah, no, that was with -j6 ... anyhow
295 2015-02-12 09:23:48 <wumpus> c++ uses loads and loads of memory
296 2015-02-12 09:24:12 <L_Cranston_Shado> I have 16gb of memory and now that weâre discussing it, Iâm almost tempted to to see what happens if I dedicate 3/4ths (12gb) to the VM and then run the install normally
297 2015-02-12 09:24:41 <wumpus> it will eventually finish of course given that you have enough swap space, but it'd not improve run time compared to a lower -j
298 2015-02-12 09:25:27 <jonasschnelli> on my end, a full gitian build took 13m with -j 5 -m 2048. Now i try with "-j 5 -m 8192": https://builds.jonasschnelli.ch/nightlybuilds/2015-02-12/
299 2015-02-12 09:26:36 <Luke-Jr> jonasschnelli: I'm surprised that worked at all :o
300 2015-02-12 09:26:45 <L_Cranston_Shado> jonasschnelli, presumably youâre using a dedicated box for your builds?
301 2015-02-12 09:26:55 <Luke-Jr> I suppose it may be close enough that success is a race
302 2015-02-12 09:27:14 <Luke-Jr> L_Cranston_Shado: that'd be silly
303 2015-02-12 09:27:28 <jonasschnelli> L_Cranston_Shado, yes. A root server 16GB ram, debian 7, Intel(R) Xeon(R) CPU E31245 @ 3.30GHz
304 2015-02-12 09:27:35 <Luke-Jr> :o
305 2015-02-12 09:27:45 <L_Cranston_Shado> Luke-Jr, he does automated builds, or at least did, so not necessarily
306 2015-02-12 09:27:46 <jonasschnelli> not much other things running there... apache and some basic things
307 2015-02-12 09:28:04 <Luke-Jr> ah, well, I guess if you're building all the time it makes sense
308 2015-02-12 09:30:09 <L_Cranston_Shado> Luke-jr, per PR builds plus nightlies, even on nights when there are no commits
309 2015-02-12 09:30:17 <L_Cranston_Shado> now thatâs dedication :)
310 2015-02-12 09:30:20 <Luke-Jr> XD
311 2015-02-12 09:33:18 <jonasschnelli> Luke-Jr, yes. I'll now active automatic build of pull requests. This will make the machine building all the time...
312 2015-02-12 09:33:37 <aliakbar> Hi everyone! A question regarding the SELFISH MINER ATTACK: according to http://hackingdistributed.com/2013/11/04/bitcoin-is-broken/ and the official paper the researchers from Cornwell claimed they've got a fix for the protocol since there was no actual threshold and they claimed they'd put the threshold up to 25%
313 2015-02-12 09:33:43 <jonasschnelli> i only have to finish the sanity checks (not changes at the gitian descriptors) and excluding of docs-only-change builds
314 2015-02-12 09:34:00 <aliakbar> Was this fix ever implemented?
315 2015-02-12 09:34:34 <aliakbar> Sorry for the irrelevant question..but i thought i'd have the right people to ask here
316 2015-02-12 09:35:04 <Luke-Jr> aliakbar: IIRC their fix was not, but another fix was in place long before their paper
317 2015-02-12 09:35:23 <Luke-Jr> (and it does more than a mere 25%)
318 2015-02-12 09:35:48 <aliakbar> whats the 'implemented' threshold right now?
319 2015-02-12 09:37:20 <Luke-Jr> aliakbar: deployment is small, because it was never really an issue
320 2015-02-12 09:38:22 <aliakbar> so you say the statement that a threshold is non-existent is true?
321 2015-02-12 09:38:48 <Luke-Jr> I don't recall the exact details.
322 2015-02-12 09:39:43 <Luke-Jr> just that it isn't and never was a serious concern
323 2015-02-12 09:39:47 <L_Cranston_Shado> it looks like my build built the linux versions (32 and 64 bit) and then quit
324 2015-02-12 09:39:59 <Luke-Jr> L_Cranston_Shado: ok? they're in build/out then
325 2015-02-12 09:40:34 <L_Cranston_Shado> I meant to build all 3, thatâs why I mention it
326 2015-02-12 09:40:56 <Luke-Jr> L_Cranston_Shado: uh, there's a different yml for each OS
327 2015-02-12 09:41:10 <Luke-Jr> and when you begin a build, it deletes previous buildddddddd/out
328 2015-02-12 09:45:18 <L_Cranston_Shado> I used the block from the Build Bitcoin Core for Linux, Windows, and OS X section of https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md, did I miss something?
329 2015-02-12 11:13:01 <jonasschnelli> night
330 2015-02-12 13:32:05 <gdm85> Luke-Jr: yes, one could just tune the cpu shares via LXC templates in order to limit resources that can be used by different concurrent builds. (although shares != quotas)
331 2015-02-12 14:51:12 <wumpus> "bitcore v0.10.0 released" eh, right, I was confused for a moment
332 2015-02-12 14:54:57 <wumpus> tho it's now been 6 days since tagging rc4 and no new critical issues have come up, so I say we tag it final
333 2015-02-12 15:01:04 <paveljanik> +1
334 2015-02-12 15:20:35 <linelevel> Hi, say I'm running an online wallet service. Each user may have many addresses. What is the best way to monitor all of my users' addresses so I know as soon as a user receives coins?
335 2015-02-12 15:27:38 <wumpus> watch the network for new blocks and transactions, recognize output scripts and match them against your set of pubkeys/addresses, any wallet will do this
336 2015-02-12 15:28:37 <wumpus> but do mind that it is not enough to watch for incoming coins, you also need to track the number of confirmations and be able to handle reorganizations and double-spends
337 2015-02-12 15:29:39 <linelevel> wumpus: Yes, I realize that. So would it be a bad idea to rely on a single bitcoind instance to watch tens of thousands of addresses, then query a db to match addresses to users when a change is detected?
338 2015-02-12 15:31:06 <wumpus> should be possible, yes
339 2015-02-12 15:32:11 <wumpus> so depending on the receiving address you associate the incoming payment with a user
340 2015-02-12 15:32:48 <linelevel> Right.
341 2015-02-12 15:33:50 <linelevel> and presumably I can stop worrying about reorganization/orphaning after 6 confirmations. Or at least I can safely absorb the risk of considering a transaction irreversible after that point.
342 2015-02-12 15:38:56 <wumpus> yes, that's a fair assumption
343 2015-02-12 15:45:37 <gdm85> on 0.10.0rc1: bitcoind: checkqueue.h:183: CCheckQueueControl<T>::CCheckQueueControl(CCheckQueue<T>*) [with T = CScriptCheck]: Assertion `pqueue->nTotal == pqueue->nIdle' failed.
344 2015-02-12 15:45:40 <gdm85> is this a known issue?
345 2015-02-12 15:46:18 <gdm85> ACTION is building rc4
346 2015-02-12 16:39:44 <wumpus> gdm85: yes
347 2015-02-12 16:42:16 <throughnothing> if you start doing getheaders() from the genesis block, is it common to get a decent number of 'invalid' headers from other nodes?
348 2015-02-12 16:42:42 <throughnothing> seems invalid blocks/headers from that early wouldn't be floating around still?
349 2015-02-12 16:44:09 <wumpus> it shouldn't be common, but you need to be able to handle it