1 2014-03-12 00:00:39 <gmaxwell> Luke-Jr: wiki copy was hidden so we didn't have conflicting versions.
2 2014-03-12 00:00:47 <super3> ACTION defends Github
3 2014-03-12 00:01:59 <raid5> gmaxwell: https://github.com/bitcoin/bitcoin/issues/3778 already being tracked :)
4 2014-03-12 00:02:06 <vrs> phantomcircuit: did you by any chance try that db stuff yourself, does the composite key come with a penalty?
5 2014-03-12 00:02:13 <Luke-Jr> gmaxwell: well, readability is more important :/
6 2014-03-12 00:03:00 <phantomcircuit> vrs, i just blacklisted them and left it as a unique key on transactions(hash)
7 2014-03-12 00:03:03 <gmaxwell> raid5: cool you should say you hit it too. :)
8 2014-03-12 00:03:16 <phantomcircuit> but theoretically there shouldn't be a significant penalty for using (hash, block_hash)
9 2014-03-12 00:03:23 <phantomcircuit> dont do (block_hash, hash) thought
10 2014-03-12 00:03:29 <phantomcircuit> s/thought/though/
11 2014-03-12 00:04:03 <vrs> yeah I googled around a bit and (hash, block_hash) seemed more sensible
12 2014-03-12 00:04:56 <phantomcircuit> vrs, the primary penalty there is a much much larger index
13 2014-03-12 00:05:11 <gmaxwell> just drop the unique constraint... make your inserts faster too generally.
14 2014-03-12 00:05:11 <phantomcircuit> if you do it block_hash, hash then the index will be much much smaller
15 2014-03-12 00:05:13 <gmaxwell> :P
16 2014-03-12 00:05:17 <melvster> Luke-Jr: sorry if this is a noob question, but one think I could not work out from the BIP is want to send back in response to a "submitblock" ?
17 2014-03-12 00:05:30 <phantomcircuit> gmaxwell, why not also run around with giant scissors all day also?
18 2014-03-12 00:05:40 <phantomcircuit> ACTION imagines gmaxwell running around with comically large scissors
19 2014-03-12 00:06:03 <phantomcircuit> melvster, iirc it takes hex endcoded block
20 2014-03-12 00:06:09 <vrs> phantomcircuit: but slower too if I query for tx hashes?
21 2014-03-12 00:06:24 <phantomcircuit> vrs, right
22 2014-03-12 00:06:46 <melvster> phantomcircuit: yes that's the request, but what's the response (ive written a little pooled miner in node)
23 2014-03-12 00:06:46 <phantomcircuit> vrs, fyi if you load the entire blockchain into postgres the indexes will be roughly the same size as the tables
24 2014-03-12 00:06:47 <vrs> how much larger are we talking? roughly twice as much?
25 2014-03-12 00:07:03 <phantomcircuit> melvster, i have no idea
26 2014-03-12 00:07:10 <phantomcircuit> does it really matter?
27 2014-03-12 00:07:27 <vrs> I don't know if it matters
28 2014-03-12 00:07:37 <melvster> yeah kinda with bfgminer, it kind of retries alot if it doesnt get the right response
29 2014-03-12 00:07:53 <phantomcircuit> oh
30 2014-03-12 00:08:10 <phantomcircuit> i never card i just send it directly to a bunch of nodes anyways
31 2014-03-12 00:08:47 <gmaxwell> phantomcircuit: you know bfgminer can do that directly?
32 2014-03-12 00:11:55 <melvster> Ah found it: This method MUST return either null (when a share is accepted), a String describing briefly the reason the share was rejected, or an Object of these with a key for each merged-mining chain the share was submitted to.
33 2014-03-12 00:12:03 <melvster> so just null then
34 2014-03-12 00:12:15 <phantomcircuit> gmaxwell, yeah i do
35 2014-03-12 00:12:40 <phantomcircuit> gmaxwell, all of our pool servers are <1ms away from the machines though so it's kind of irrelevant
36 2014-03-12 00:20:28 <ryanxcharles> are bitcoin public keys big endian or little endian?
37 2014-03-12 00:21:35 <jgarzik> ryanxcharles, http://luca.ntop.org/Teaching/Appunti/asn1.html
38 2014-03-12 00:21:38 <jgarzik> DER
39 2014-03-12 00:22:05 <defrostr> when mining btc in testnet mode, are all shares considered blocks?
40 2014-03-12 00:23:21 <ryanxcharles> thanks. reading.
41 2014-03-12 00:24:01 <phantomcircuit> defrostr, no
42 2014-03-12 00:24:10 <gmaxwell> defrostr: "share" doesn't have any particular definition, and regardless, testnet actually has a difficulty.. though its low and switches back to 1 if there hasn't been a block recently.
43 2014-03-12 00:24:56 <defrostr> gmaxwell, phantomcircuit: thanks!
44 2014-03-12 00:25:26 <jgarzik> ryanxcharles, it's a data structure, not a simple Big Number
45 2014-03-12 00:26:01 <Luke-Jr> melvster: "This method MUST return either null (when a share is accepted), a String describing briefly the reason the share was rejected, or an Object of these with a key for each merged-mining chain the share was submitted to."
46 2014-03-12 00:26:32 <melvster> Luke-Jr: thanks :)
47 2014-03-12 00:27:09 <jgarzik> Since other people mentioned it on twitter, might as well mention it here:
48 2014-03-12 00:27:11 <jgarzik> https://gist.github.com/jgarzik/9494153
49 2014-03-12 00:27:24 <jgarzik> Payment channel protocol, for a demo server
50 2014-03-12 00:28:06 <jgarzik> once we figure out a payment channel protocol (TD prefers protobufs), will look to Bitcoin Core wallet integration
51 2014-03-12 00:28:20 <jgarzik> need to make locked outputs persistent
52 2014-03-12 00:28:54 <phantomcircuit> jgarzik, personally i have found that protobuf is annoying to use externally
53 2014-03-12 00:29:45 <jgarzik> phantomcircuit, which part(s) are annoying to use? Seems supported in every language under the sun (ditto JSON)
54 2014-03-12 00:30:23 <phantomcircuit> jgarzik, that fields aren't self descriptive ends up being a nuisance to support
55 2014-03-12 00:30:44 <phantomcircuit> parsing protobuf is significantly faster than json, but who really cares for something like payment requests?
56 2014-03-12 00:31:12 <Luke-Jr> well, I learned why people make pull requests for older version branches/tagsâ¦
57 2014-03-12 00:31:22 <gmaxwell> oh?
58 2014-03-12 00:31:34 <Luke-Jr> they're making a *request* to *pull* that older version into their git checkout.
59 2014-03-12 00:32:33 <gmaxwell> oh I didn't think you could do that on third party repos.
60 2014-03-12 00:32:43 <Luke-Jr> https://github.com/luke-jr/bfgminer/pull/418
61 2014-03-12 00:33:01 <gmaxwell> oh I get what you mean.
62 2014-03-12 00:33:06 <Luke-Jr> thanks github, for confusingly calling merge requests "pull request", sigh
63 2014-03-12 00:33:09 <gmaxwell> they're trying to pull the tag into their repo.. and right.
64 2014-03-12 00:33:16 <gmaxwell> Ah ha.
65 2014-03-12 00:33:35 <gmaxwell> I'd just assumed it was secret ninjas slipping exploit code into the pull tester.
66 2014-03-12 00:34:35 <Imbue> is there a page somewhere that details the use of each file in the bitcoin 'appdata' folder?
67 2014-03-12 00:34:44 <Imbue> the bitcoin wiki is quite light on detail
68 2014-03-12 00:34:47 <jgarzik> phantomcircuit, I actually wrote several versions of a json parser... including one with lex+yacc (well flex+bison)
69 2014-03-12 00:34:54 <jgarzik> in search of speed
70 2014-03-12 00:35:03 <sipa> Imbue: if i explain them to you, will you update the wiki with that informations? :)
71 2014-03-12 00:35:05 <Imbue> i've managed to figure out that I can recover the chain with only blk***.dat and -reindex
72 2014-03-12 00:35:22 <jgarzik> Imbue, yes, that is the correct method for rebuilding
73 2014-03-12 00:35:41 <Imbue> sipa: i'm not sure I can update wiki, but I could see
74 2014-03-12 00:35:51 <Imbue> let me try and make a harmless edit
75 2014-03-12 00:35:53 <jgarzik> Luke-Jr, I still get the occasional cgminer pull request, misdirected automatically into cpuminer's repo.
76 2014-03-12 00:36:04 <jgarzik> Luke-Jr, it appears as 500+ commits to my tree ;p
77 2014-03-12 00:36:12 <Imbue> jgarzik: what I am trying to do is give a friend my blockchain without handing out logs, wallet.dat, and other unnecessary 'identifiable' stuff
78 2014-03-12 00:36:32 <Luke-Jr> SomeoneWeird: ping
79 2014-03-12 00:36:32 <sipa> Imbue: do you think he should trust you?
80 2014-03-12 00:36:42 <SomeoneWeird> Luke-Jr, pong
81 2014-03-12 00:36:43 <Imbue> jgarzik: it strikes me that a total reindex is unnecessary unless i am trying to perform an incredibly complex attack on him
82 2014-03-12 00:37:01 <sipa> Imbue: if you copy blocks/* and chainstate/*, the reindex isn't necessary
83 2014-03-12 00:37:09 <Luke-Jr> SomeoneWeird: Imbue may need wiki approval
84 2014-03-12 00:37:20 <sipa> but that means you can pretty much make him believe any balance/ledger state of the blockchain
85 2014-03-12 00:37:37 <sipa> (and that is not hard)
86 2014-03-12 00:38:05 <SomeoneWeird> Imbue, ping me when you register and i'll enable your account
87 2014-03-12 00:38:16 <Imbue> sipa: but he could -reindex if he felt it necessary, still
88 2014-03-12 00:38:26 <sipa> correct
89 2014-03-12 00:38:34 <sipa> and that makes it perfectly saf ein any case
90 2014-03-12 00:40:32 <jgarzik> Imbue, he could also -checklevel -checkblocks
91 2014-03-12 00:40:34 <jgarzik> post-copy
92 2014-03-12 00:41:10 <sipa> jgarzik: that doesn't nearly provide anything remotely comparable to a reindex
93 2014-03-12 00:41:30 <sipa> as the the rollback check that checkblocks does is at most a few 100 blocks
94 2014-03-12 00:42:10 <sipa> you can increase how far it goes back with -dbcache, but you may need several gigabytes to rollback to genesis
95 2014-03-12 00:51:07 <Imbue> i have registered with this username now
96 2014-03-12 00:51:35 <Imbue> what I am mainly looking for is, which directories contain files that have 'valuable' data in, if for example friend decides to give my copy to his friend, and so on
97 2014-03-12 00:52:32 <Imbue> wallet.dat and debug.log are obvious, but do the levelDB databases have any 'special markings' that could identify addresses 'used' at some point?
98 2014-03-12 00:53:02 <sipa> no
99 2014-03-12 00:53:14 <Luke-Jr> Imbue: to ping someone, you must state their nickname
100 2014-03-12 00:53:27 <sipa> all personal information is in wallet.dat, and (at run time) in database/*
101 2014-03-12 00:53:31 <Imbue> ah yes. SomeoneWeird :)
102 2014-03-12 00:54:33 <SomeoneWeird> Imbue, done
103 2014-03-12 00:54:42 <Imbue> debug.log has hashes which look like they might be pubkeys
104 2014-03-12 00:54:47 <Imbue> and IP addresses
105 2014-03-12 00:55:02 <sipa> it shouldn't ever list public keys
106 2014-03-12 00:55:09 <sipa> it may list txids relevant to your wallet
107 2014-03-12 00:55:23 <Imbue> ah yes. txid
108 2014-03-12 00:55:36 <Imbue> let me check blockexplorer
109 2014-03-12 00:55:38 <Imbue> thanks SomeoneWeird
110 2014-03-12 00:55:55 <wbaw> debug.log can be safely deleted
111 2014-03-12 00:56:10 <Imbue> yes. 'addtowallet txid'. checked.
112 2014-03-12 00:56:23 <wbaw> may contain some personal information
113 2014-03-12 00:56:37 <wbaw> wallet.dat is the important file not to share
114 2014-03-12 00:57:56 <Luke-Jr> and database/
115 2014-03-12 01:00:05 <Imbue> okay. so chainstate and blocks/index are purely 'metadata' about the chain itself
116 2014-03-12 01:01:39 <wbaw> sipa, are there any plans for cutting the blockchain size?
117 2014-03-12 01:02:28 <wbaw> or the time it takes to download/verify it first time?
118 2014-03-12 01:02:51 <Luke-Jr> wbaw: the latter, yes
119 2014-03-12 01:03:18 <wbaw> it seems to use 100% of one cpu for hours
120 2014-03-12 01:03:41 <wbaw> could it be multi-threaded?
121 2014-03-12 01:04:21 <sipa> wbaw: the cpu intensive part is
122 2014-03-12 01:04:43 <sipa> there are several ways to improve performance still
123 2014-03-12 01:04:56 <sipa> but it's unlikely to become less than "hours"
124 2014-03-12 01:05:18 <wbaw> would checkpointing be impossible to implement?
125 2014-03-12 01:05:32 <sipa> we already have checkpoints
126 2014-03-12 01:05:36 <sipa> and we want to get rid of them
127 2014-03-12 01:06:13 <wbaw> it seems a bit useless to be verifying years old transactions
128 2014-03-12 01:06:42 <sipa> the alternative is trusting someone to give you the state that results from these old transactions
129 2014-03-12 01:06:53 <sipa> that's very much breaking bitcoin's security assumptions
130 2014-03-12 01:07:23 <sipa> and we already don't verify signatures on old transactions, which is the most cpu intensive part
131 2014-03-12 01:08:24 <wbaw> ~20gb is a lot already & it'll only grow
132 2014-03-12 01:08:45 <Luke-Jr> forever
133 2014-03-12 01:09:13 <sipa> meh
134 2014-03-12 01:09:33 <sipa> like people don't ever download 10gb+ files from the internet
135 2014-03-12 01:09:54 <wbaw> that doesn't use 100% cpu too
136 2014-03-12 01:10:15 <wbaw> it's not downloading at full speed on my computers, cpu limited
137 2014-03-12 01:10:33 <wbaw> or memory access time, whatever, not bandwidth
138 2014-03-12 01:10:34 <sipa> oh, that's just the crappy download mechanism, which is being worked on
139 2014-03-12 01:11:04 <sipa> but if you want to skip the processing, you can copy the chainstate/blocks from another trusted node
140 2014-03-12 01:11:16 <wbaw> and it'd be nice to be able to run a full node on lower spec hardware, even phones & tablets
141 2014-03-12 01:11:30 <sipa> i'd also like a unicorn :)
142 2014-03-12 01:11:35 <wbaw> i know
143 2014-03-12 01:12:31 <wbaw> i will have a look to see if i can make any optimisations, but i'm still just starting to read the code
144 2014-03-12 01:12:54 <Arnavion> It depends on what nodes you have the (mis)fortune to bootstrap off of too
145 2014-03-12 01:13:10 <Arnavion> A lot of them like to give orphan blocks when fetching years-old blocks
146 2014-03-12 01:13:12 <sipa> for now, yes
147 2014-03-12 01:13:26 <Arnavion> which is just a waste of time and CPU to fetch and ignore
148 2014-03-12 01:13:30 <sipa> Arnavion: not at all
149 2014-03-12 01:13:47 <wbaw> it seems a waste to be fetching years old blocks at all
150 2014-03-12 01:14:05 <sipa> Arnavion: they're reported as orphans because they arrive in the incorrect order
151 2014-03-12 01:14:13 <Arnavion> Oh is that the reason
152 2014-03-12 01:14:19 <sipa> which is the result of the crappy download code
153 2014-03-12 01:14:21 <Arnavion> Never mind me then
154 2014-03-12 01:14:34 <sipa> wbaw: well, that's just inevitable
155 2014-03-12 01:14:47 <sipa> wbaw: you can't have zero trust confidence in history, if you don't get to see history
156 2014-03-12 01:15:10 <wbaw> couldn't checkpoints be stored in a distributed way?
157 2014-03-12 01:15:39 <wbaw> so you'd only need from the last checkpoint or two to run a node?
158 2014-03-12 01:16:09 <justanotheruser> wbaw: Then you are vulnerable to sybil attacks
159 2014-03-12 01:16:20 <sipa> wbaw: that's not really zero trust anymore :)
160 2014-03-12 01:16:25 <wbaw> after it's had a few months of confirmations you can trust it
161 2014-03-12 01:16:54 <wbaw> sipa, confirmations are a type of trust system
162 2014-03-12 01:16:59 <gmaxwell> what does that even mean?.
163 2014-03-12 01:17:09 <wbaw> trust?
164 2014-03-12 01:17:11 <uiop> i pinged out..
165 2014-03-12 01:17:13 <uiop> <uiop> would nodes compressing data sent over the wire give you much?
166 2014-03-12 01:17:17 <uiop> <uiop> "ssh -C" and "curl --compress" certainly do wonders
167 2014-03-12 01:17:19 <uiop> <uiop> (am i still connected?)
168 2014-03-12 01:17:21 <gmaxwell> no, not really, miners are incentivized to do the right thing because they can't profitable cheat.
169 2014-03-12 01:17:57 <gmaxwell> if you start letting them just make up arbritary history the incentives are very different. There may be cases where thats justifyable, but there ought to exist a system which can't be cheated.
170 2014-03-12 01:18:22 <Arnavion> Could you make a chain of checkpoints that needs to be mined but has a super-high difficulty? You only get to mine a checkpoint block every few X (days, weeks, months) ?
171 2014-03-12 01:18:32 <wbaw> every system can be cheated, you just need to make it hard and/or unprofitable
172 2014-03-12 01:18:34 <sipa> Arnavion: what does that solve?
173 2014-03-12 01:19:01 <sipa> wbaw: right now, no bitcoin full node will _ever_ accept a block which 1) spends coins which don't exist 2) spends coins twice 3) spends coins without valid signature 4) creates m
174 2014-03-12 01:19:08 <sipa> wbaw: right now, no bitcoin full node will _ever_ accept a block which 1) spends coins which don't exist 2) spends coins twice 3) spends coins without valid signature 4) creates more coins than allowed
175 2014-03-12 01:19:14 <sipa> wbaw: under _no_ circumstances
176 2014-03-12 01:19:19 <Arnavion> sipa: It would allow you to trust the checkpoint chain to a certain block, and not need to fetch blocks before that
177 2014-03-12 01:19:32 <Imbue> made a small edit to the data directory wiki page. many thanks for the help.
178 2014-03-12 01:19:33 <sipa> Arnavion: why would it allow you to trust the checkpoint?
179 2014-03-12 01:19:58 <Arnavion> Because the checkpoint is mined in the same way as the bitcoin blockchain is
180 2014-03-12 01:20:02 <gmaxwell> if you're interested in trusting things, there are systems like paypal which are more more efficient and scalable than bitcoin.
181 2014-03-12 01:20:06 <sipa> we're currently not trusting miners
182 2014-03-12 01:20:11 <wbaw> it'd be a trade-off for security, sure
183 2014-03-12 01:20:27 <sipa> yes
184 2014-03-12 01:20:37 <wbaw> but it could be minimised
185 2014-03-12 01:20:39 <sipa> if you want that trade-off, run a SPV node
186 2014-03-12 01:20:46 <Arnavion> sipa: You don't trust them, but you verify the block they create is valid, no?
187 2014-03-12 01:20:53 <sipa> Arnavion: yes
188 2014-03-12 01:20:56 <wbaw> and still cut the blockchain size required to run a node/miner
189 2014-03-12 01:21:03 <gmaxwell> Arnavion: the verification is what makes the system secure. Otherwise why wouldn't all miners just startâ sayâ rewarding themselves 100 BTC/block ... because the system prohibits it through verification.
190 2014-03-12 01:21:09 <Arnavion> gmaxwell: Yes
191 2014-03-12 01:21:11 <Arnavion> So why can't you do the same for a chain of checkpoints?
192 2014-03-12 01:21:17 <sipa> Arnavion: but there wouldn't be a way to verify the checkpoint if you don't download the blocks it is contrucxted from
193 2014-03-12 01:21:34 <Imbue> Arnavion: you can; it involves checking all the blocks
194 2014-03-12 01:21:38 <Arnavion> Instead of transaction + nonce -> verifiable block you get set of blocks + nonce -> verifiable checkpoint
195 2014-03-12 01:21:39 <Imbue> ;p
196 2014-03-12 01:21:48 <wbaw> after so many hundreds or thousands of verifications i think you can be pretty sure though
197 2014-03-12 01:21:50 <sipa> Arnavion: that's not how it works
198 2014-03-12 01:21:52 <Arnavion> Ah
199 2014-03-12 01:21:53 <Arnavion> Yes
200 2014-03-12 01:21:53 <gmaxwell> Arnavion: that isn't what goes into verifying a block.
201 2014-03-12 01:22:18 <sipa> wbaw: you don't get it; if you're not interested in the zero-trust model bitcoind provides, just use an SPV node, which doesn't evne need to download the block chain at all
202 2014-03-12 01:22:21 <gmaxwell> Every node enforces all the rules tightly, blocks are responsible just for ordering transactions.
203 2014-03-12 01:22:39 <gmaxwell> yea, if you don't care about verification bitcoin already has a super efficient mode that doesn't do it.
204 2014-03-12 01:22:49 <Arnavion> gmaxwell: sipa: I didn't mean that was the process of verifying blocks. I meant that was the thing that was verified
205 2014-03-12 01:22:58 <Arnavion> but what sipa said is right anyway
206 2014-03-12 01:23:14 <Arnavion> that to verify the checkpoint you'd need to download the blocks it claims to checkpoint in the first place
207 2014-03-12 01:23:58 <wbaw> sipa, it's not really a zero trust model, the confirmations are part of the trust model
208 2014-03-12 01:24:13 <sipa> that's a totally different thing
209 2014-03-12 01:24:28 <gmaxwell> wbaw: it isâ up to ordering. Because there is no decenteralized way to provide ordering known.
210 2014-03-12 01:24:29 <sipa> confirmations tell you how likely your transactions is to be reverted or not
211 2014-03-12 01:24:50 <sipa> which is the only (and unfortunate) part that cannot be decided deterministically
212 2014-03-12 01:24:52 <gmaxwell> wbaw: but even there the verification limits the amount of evil that can be done by twiddling the ordering, thus narrowing the incentives for doing so.
213 2014-03-12 01:25:05 <sipa> but for everything else, namely _validity_, we don't trust anyone
214 2014-03-12 01:25:11 <wbaw> yes, it's a decentralised trust model
215 2014-03-12 01:25:22 <gmaxwell> s/trust// validity is zero trust.
216 2014-03-12 01:25:50 <gmaxwell> ordering involves an incentive assumption, which is partially upheld by the fact that validity isn't in question.
217 2014-03-12 01:25:50 <wbaw> you have to trust that a transaction is valid after x number of confirmations
218 2014-03-12 01:25:59 <sipa> wbaw: AND is valid
219 2014-03-12 01:26:05 <sipa> no, sorry
220 2014-03-12 01:26:25 <sipa> we accept a transaction if it is valid AND has x number of confirmations
221 2014-03-12 01:26:33 <sipa> but we don't compromise on validity
222 2014-03-12 01:27:05 <sipa> if you don't care about that validity verification part, use an SPV node
223 2014-03-12 01:27:10 <sipa> it only relies on confirmations
224 2014-03-12 01:27:15 <wbaw> i do care about that
225 2014-03-12 01:27:30 <sipa> then run a full node, and accept that to get that security model, you have to see everything
226 2014-03-12 01:27:31 <wbaw> but, not for really old transactions
227 2014-03-12 01:27:40 <sipa> then copy the state from a node you trust
228 2014-03-12 01:30:09 <gmaxwell> wbaw: right now miners today could rewrite the entire chain in only 60 days of computation, part of the reason they don't do this is because doing so wouldn't allow them to give themselves a 1m btc bonus (perhaps pay back mtgox lost funds?) while still keeping everyone elses funds instact. Eliminating verification of the old history would permit that.
229 2014-03-12 01:31:21 <wbaw> maybe it'd need an altered blockchain to implement properly & wouldn't be possible with btc
230 2014-03-12 01:31:39 <sipa> unicorns :)
231 2014-03-12 01:32:09 <gmaxwell> it's just a really substantially different tradeoff. I think its one that should exist, e.g. namecoin should work that way. But not Bitcoin.
232 2014-03-12 01:32:53 <sipa> p2pool has a model where it forgets old shares, no?
233 2014-03-12 01:32:55 <wbaw> i confess i've been thinking more about namecoin & maybe another alt based on that recently
234 2014-03-12 01:33:40 <lagarde> anyone care to donate some testnet coins? mjZdKtFQtfQpkLnnEefJY97PxfC8dYsNKa
235 2014-03-12 01:34:11 <gmaxwell> sipa: yes. doesn't need anything past the PPLNS window, and it's basically clocked against the bitcoin chain, meaning you'd have to throw out a lot of bitcoin mining work to attack its history.
236 2014-03-12 01:34:21 <sipa> yup
237 2014-03-12 01:34:37 <sipa> but you *could* create an invalid share chain (with huge mining power)
238 2014-03-12 01:35:16 <gmaxwell> yep. and right now there isn't a lot of sanity checking (it should probably just refuse to reorg onto a sharechain that removes too much of its work)
239 2014-03-12 01:36:32 <Imbue> lagarde: sent
240 2014-03-12 01:37:31 <lagarde> Imbue: thanks :)
241 2014-03-12 01:41:41 <Imbue> does anyone know why I would have to add nodes manually in order to get testnet to connect to anyone?
242 2014-03-12 01:41:53 <warren> hmm... trying 0.9 rc2 win64. gets stuck during verifying..
243 2014-03-12 01:42:12 <Imbue> upon start it will connect to the 'seed', then disconnect, and sit at 0, unless I go in and addnode xxxx
244 2014-03-12 01:43:05 <Luke-Jr> Imbue: do you have IPv6, or just deprecated IPv4? :P
245 2014-03-12 01:43:21 <Imbue> Luke-Jr: using tor (-proxy=...)
246 2014-03-12 01:44:50 <Imbue> i'm not sure if it has full v6 support
247 2014-03-12 01:45:39 <Luke-Jr> â¦
248 2014-03-12 01:46:23 <Imbue> i think it is only supported for the initial connection (bridge to relay)
249 2014-03-12 01:51:03 <sipa> Imbue: do you want all your connections to go through tor?
250 2014-03-12 01:51:36 <Imbue> sipa: the machine is firewalled off to other traffic
251 2014-03-12 01:53:42 <Imbue> it looks like i can fix this by creating bitcoin.conf addnode entries, but i am wondering why it fails to connect to the node(s) that the seed gives me
252 2014-03-12 01:54:11 <davec> I noticed what looks like a very minor bug in the block template generation code. When the sort order is changed to fees, the tx isn't inserted back into the priority queue and skipped if the priority is too low or it won't fit
253 2014-03-12 01:54:45 <davec> that means a single too low prio or too large tx can sneak into the high-prio area
254 2014-03-12 02:00:39 <sipa> hmm, interesting
255 2014-03-12 02:02:39 <davec> I'll ticket it if you concur, but I wanted to make sure I'm reading that correctly first
256 2014-03-12 02:02:54 <sipa> i haven't read that code in a long time, i must admit
257 2014-03-12 02:03:00 <Luke-Jr> davec: miners shouldn't be using the example code there in the real world anyway
258 2014-03-12 02:03:07 <Imbue> mainnet appears to manage fine
259 2014-03-12 02:03:12 <Luke-Jr> davec: plus, it's mere policy
260 2014-03-12 02:03:19 <sipa> sure, it's only policy
261 2014-03-12 02:03:27 <sipa> but it should implement whatever it intends to implement
262 2014-03-12 02:53:03 <skinnkavaj> Is there trust involved with this? https://bitcointalk.org/index.php?topic=270180.0
263 2014-03-12 02:56:39 <jcorgan> i think you'd be trusting the website not to store your private key when it gets constructed from the two halves. that's probably done in JS in your browser, but either local or remote malware could compromise that.
264 2014-03-12 02:58:59 <SomeoneWeird> why does any letter after q take longer?
265 2014-03-12 02:59:02 <SomeoneWeird> 0_o
266 2014-03-12 03:54:56 <SomeoneWeird> https://pbs.twimg.com/media/Bie9GrgCQAEdTrc.png
267 2014-03-12 06:44:38 <olalonde> is it possible to programmatically detect a master public key (the one from HD BIP)
268 2014-03-12 06:45:13 <olalonde> as opposed to a regular public key
269 2014-03-12 06:48:54 <jcorgan> olalonde: no, the public keys (and generated addresses) are indistinguishable from public keys generated from fresh randomness each time
270 2014-03-12 06:50:05 <jcorgan> but, a "master public key" is actually a public key plus more information, so if you have one, you'd know it
271 2014-03-12 06:52:45 <olalonde> jcorgan: yes that's what I mean
272 2014-03-12 06:53:08 <olalonde> jcorgan: it's possible to detect some string is a master public key
273 2014-03-12 08:31:23 <CodeShark> I think I'm actually starting to like getwork better than getblocktemplate despite its hideous formatting :(
274 2014-03-12 08:31:25 <CodeShark> it's more abstract
275 2014-03-12 08:31:41 <CodeShark> I don't like the idea of the miner program having to know a damn thing about the block format
276 2014-03-12 08:32:42 <wumpus> it has to, to be able to increase the nonce itself and such
277 2014-03-12 08:32:49 <wumpus> otherwise it's not scaleable
278 2014-03-12 08:33:03 <CodeShark> but that's just because of original poor design :p
279 2014-03-12 08:33:10 <CodeShark> the miner should be passed raw data and a nonce
280 2014-03-12 08:33:12 <CodeShark> period :)
281 2014-03-12 08:33:15 <wumpus> it's all for a reason
282 2014-03-12 08:33:37 <wumpus> should it? I'd like miners more involved, not less
283 2014-03-12 08:33:57 <CodeShark> in that case there should be a separate service that sits between the p2p node and the miner
284 2014-03-12 08:34:07 <wumpus> having all kinds of protocol/transaction specific decisions at the end user means less centralization in decisions with pools etc...
285 2014-03-12 08:34:08 <CodeShark> which does things like block construction and tx selection
286 2014-03-12 08:35:02 <Ademan> gmaxwell: I don't suppose you went to the local bitcoin event tonight did you?
287 2014-03-12 08:36:13 <CodeShark> point is the piece of software that directly connects to the mining hardware should require as little knowledge of block structure as possible
288 2014-03-12 08:36:25 <CodeShark> that should be handled by a separate layer
289 2014-03-12 08:36:47 <CodeShark> that way we can work with proof-of-work abstractly
290 2014-03-12 08:37:48 <CodeShark> said piece of software should be concerned with one thing and one thing only - driving hardware to find a nonce
291 2014-03-12 08:38:41 <CodeShark> then we'll have much greater flexibility to either change block header formats or experiment with alts
292 2014-03-12 08:39:07 <CodeShark> I feel like these things are slowing down the rate of innovation
293 2014-03-12 08:40:14 <beachandbytes> the more you abstract away the structure the slower you make it
294 2014-03-12 08:40:20 <CodeShark> huh?!
295 2014-03-12 08:40:21 <beachandbytes> so I doubt you will see that in the mining space
296 2014-03-12 08:40:47 <CodeShark> how much faster could you possibly get than a midstate, a nonce range, and a target?
297 2014-03-12 08:42:08 <beachandbytes> barely even know what tha tis
298 2014-03-12 08:43:23 <CodeShark> by "abstract" I mean we just feed the software that drives the mining hardware the data it needs to search for nonces - we don't even burden this layer with formatting of block headers and preprocessing them
299 2014-03-12 08:43:27 <beachandbytes> actually, I recognize the terminology but new to this space so my comment was more general, if your writing code with performance in mind you can optimize further if you don't develop to an abstract model
300 2014-03-12 08:43:39 <wumpus> in any case you're welcome to propose new standards for that
301 2014-03-12 08:44:24 <CodeShark> all the formatting and preprocessing is done by a software layer which will certainly NOT be the bottleneck
302 2014-03-12 08:47:13 <beachandbytes> so what advantage do you gain from this abstraction
303 2014-03-12 08:47:30 <CodeShark> decoupling of block chain logic from nonce finding
304 2014-03-12 08:48:05 <CodeShark> allows development of block chain protocols to proceed independently of mining equipment
305 2014-03-12 08:48:35 <beachandbytes> so calls into differnt nonce finding hardware or software?
306 2014-03-12 08:48:35 <CodeShark> and mining/pool software
307 2014-03-12 08:49:00 <CodeShark> the "work" in "proof-of-work" comes down to finding nonces