1 2014-10-30 00:03:13 <coryfields_> Luke-Jr: that seems to have worked. thanks for the idea
2 2014-10-30 00:03:40 <Luke-Jr> side note, shouldn't it be bitcoin-cli now?
3 2014-10-30 00:04:40 <coryfields_> ?
4 2014-10-30 00:20:05 <Luke-Jr> coryfields_: bitcoind isn't a JSON-RPC client anymore
5 2014-10-30 00:21:38 <coryfields_> Luke-Jr: erm, did you s/bitcoin-cli/bitcoind/ my text above in your head? :)
6 2014-10-30 00:22:09 <Luke-Jr> haha, probably
7 2014-10-30 00:22:19 <Luke-Jr> I did actually open a file, maybe I saw it there
8 2014-10-30 00:22:40 <Luke-Jr> ah, yep. I was suggesting a wrapper on the wrong one :D
9 2014-10-30 01:06:48 <BlueMatt> yay! coinbase just stole my money trying to pay a merchant
10 2014-10-30 01:06:50 <BlueMatt> why am I not surprised
11 2014-10-30 01:33:33 <Luke-Jr> ugh, PR 5100
12 2014-10-30 03:03:24 <Luke-Jr> Can anyone help get #5106 and/or #5103 merged? I can dedicate some time myself to "trade" an in-depth review of some other PR that needs it? :p
13 2014-10-30 03:03:33 <Luke-Jr> (these are dependencies of block proposal support)
14 2014-10-30 03:05:57 <Luke-Jr> ACTION trying to help stick to wumpus's planned 0.10 schedule :p
15 2014-10-30 03:11:10 <phantomcircuit> Luke-Jr, Ctx ?
16 2014-10-30 03:11:27 <Luke-Jr> phantomcircuit: ConTeXtual
17 2014-10-30 03:11:40 <Luke-Jr> as opposed to the non-contextual functions
18 2014-10-30 03:11:46 <phantomcircuit> right
19 2014-10-30 03:11:52 <phantomcircuit> is that used anywhere else?
20 2014-10-30 03:11:57 <phantomcircuit> if not then maybe just
21 2014-10-30 03:12:02 <phantomcircuit> Contextual instead of Ctx
22 2014-10-30 03:12:23 <Luke-Jr> phantomcircuit: I don't believe so - before they were always just part of the action function
23 2014-10-30 03:12:46 <phantomcircuit> currently trying to debug code in which all variables are single letters, so maybe im being a bit picky here...
24 2014-10-30 03:15:59 <phantomcircuit> also im pretty sure the logic in CtxCheckBlock around the version numbers can be safely simplified to check for a specific block height
25 2014-10-30 03:16:27 <phantomcircuit> since to go backwards you would have to fork from the first block with version=2
26 2014-10-30 03:16:59 <Luke-Jr> phantomcircuit: you're considering that CtxCheckBlock is used on ancient blocks?
27 2014-10-30 03:17:14 <Luke-Jr> and may be desirable to extend in the future for new versions
28 2014-10-30 03:18:26 <phantomcircuit> Luke-Jr, yes i agree, im just saying that the existing logic is identical to requiring version=2 above a specific block height
29 2014-10-30 03:18:40 <phantomcircuit> unless we're thinking there is going to be a reorg all the way back to version=1
30 2014-10-30 03:18:59 <Luke-Jr> perhaps, but unrelated to this PR
31 2014-10-30 03:19:04 <Luke-Jr> that code is merely moved
32 2014-10-30 03:19:21 <phantomcircuit> agreed
33 2014-10-30 03:19:28 <phantomcircuit> it just reminded me
34 2014-10-30 03:19:41 <phantomcircuit> if you compile with -O0 that block of code is like 25% of verification time btw
35 2014-10-30 03:19:48 <phantomcircuit> at -O2 it's <0.1%
36 2014-10-30 03:20:32 <sipa> Luke-Jr: i was thinking earlier that all logic in AcceptBlockHeader can safely go into CheckBlockHeader now, requiring you know the previous block headers already
37 2014-10-30 03:20:37 <sipa> Luke-Jr: as that's always the case now
38 2014-10-30 03:21:19 <sipa> phantomcircuit: it could easily be optimized further; keep window-sums-per-version around, and update them in connecttip/disconnecttip
39 2014-10-30 03:21:25 <Luke-Jr> sipa: do I need to combine them as part of this PR?
40 2014-10-30 03:21:38 <sipa> just thought it may simplify things for you
41 2014-10-30 03:21:50 <phantomcircuit> sipa, as it stands it's only an issue if you're debugging at -O0 or -O1
42 2014-10-30 03:22:07 <sipa> phantomcircuit: for block v3 it will be doubled, though
43 2014-10-30 03:22:18 <phantomcircuit> true
44 2014-10-30 03:22:37 <phantomcircuit> anyways the important realization is that once the condition triggers it's effectively impossible to go back
45 2014-10-30 03:23:06 <phantomcircuit> so no need to be checking it
46 2014-10-30 03:23:28 <sipa> after the 95% point, yes
47 2014-10-30 03:23:33 <phantomcircuit> iirc i rewrote that at somepoint with a static int minimum_version
48 2014-10-30 03:23:43 <sipa> but after 75% it is still possible
49 2014-10-30 03:23:58 <phantomcircuit> which only worked if everything ran in order
50 2014-10-30 03:24:34 <Luke-Jr> if (version < height / 204303)
51 2014-10-30 03:24:36 <Luke-Jr> :P
52 2014-10-30 03:24:46 <phantomcircuit> ...
53 2014-10-30 03:24:49 <phantomcircuit> >.>
54 2014-10-30 03:25:06 <phantomcircuit> it could easily be part of the checkpoints
55 2014-10-30 03:25:12 <Luke-Jr> (disclaimer: i didn't bother to find the exact block height applicable)
56 2014-10-30 03:26:00 <sipa> now someone goes on to write a BIP based on this
57 2014-10-30 03:26:07 <sipa> attaches this piece of irc log as reference
58 2014-10-30 03:26:11 <sipa> and woops -> fork
59 2014-10-30 03:26:37 <phantomcircuit> ha
60 2014-10-30 03:26:39 <Luke-Jr> sipa: at this point, the bottleneck IMO is review, and "simplifying things" in that way (combining funcs) increases time to review, so I'll just leave it for now unless there's a reason to change it
61 2014-10-30 03:27:06 <phantomcircuit> Luke-Jr, can you change the function names from Ctx to Contextual
62 2014-10-30 03:27:13 <phantomcircuit> it's not like the extra few bytes matter
63 2014-10-30 03:27:28 <Luke-Jr> phantomcircuit: Ctx is a pretty common abbreviation, though.. sipa: thoughts? :P
64 2014-10-30 03:27:31 <sipa> fair enough; i'll have a look at your patch and see whether it would actually result in a simpler change
65 2014-10-30 03:27:37 <sipa> ACTION needs sleep first, though
66 2014-10-30 03:27:51 <phantomcircuit> Luke-Jr, i know but just... why?
67 2014-10-30 03:28:07 <phantomcircuit> it's not like typing Contextual is the bottleneck on any development
68 2014-10-30 03:28:08 <phantomcircuit> :P
69 2014-10-30 03:28:15 <Luke-Jr> phantomcircuit: effort to rebase the 3 PRs built on top it? <.<
70 2014-10-30 03:28:27 <phantomcircuit> sigh
71 2014-10-30 03:28:32 <phantomcircuit> why u acronym in the first place
72 2014-10-30 03:29:17 <Luke-Jr> habit
73 2014-10-30 03:29:27 <sipa> Ctx is not an acronym
74 2014-10-30 03:30:08 <phantomcircuit> sipa, words
75 2014-10-30 03:30:19 <sipa> no, it's not a word either :p
76 2014-10-30 03:30:20 <phantomcircuit> abbreviation
77 2014-10-30 03:31:11 <petahash> after reading the whitepaper
78 2014-10-30 03:31:27 <Luke-Jr> time to argue > time to change
79 2014-10-30 03:31:35 <petahash> I am describing the blockchain to someone as an open ledger system and encrypted key exchange
80 2014-10-30 03:31:36 <Luke-Jr> renaming
81 2014-10-30 03:31:49 <Luke-Jr> done
82 2014-10-30 03:31:54 <cfields> anyone happen to know if there have been any issues reported wrt alertnotify on windows?
83 2014-10-30 03:31:58 <petahash> would this be accurate?
84 2014-10-30 03:31:58 <sipa> petahash: there is no encryption
85 2014-10-30 03:32:16 <cfields> if wine can be trusted, it appears to be busted there
86 2014-10-30 03:32:18 <petahash> hm.
87 2014-10-30 03:32:21 <sipa> and certainly the blockchain does not exchange keys
88 2014-10-30 03:32:31 <sipa> you do that beforehand (by sending someone an address)
89 2014-10-30 03:32:49 <sipa> it's just a ledger with authenticated transactions
90 2014-10-30 03:33:57 <petahash> I came from using pgp messaging before getting into Bitcoin, forgive me if I think of encryption keys and its exchange as a type of transaction
91 2014-10-30 03:34:22 <sipa> there are no encryption keys as there is no encryption :)
92 2014-10-30 03:34:25 <petahash> so open ledger system
93 2014-10-30 03:34:53 <petahash> there is encryption
94 2014-10-30 03:34:58 <sipa> no...
95 2014-10-30 03:35:08 <sipa> except locally in the wallet if you set a passphrase
96 2014-10-30 03:35:41 <sipa> but the protocol or the blockchain do not employ encryption anywhere
97 2014-10-30 03:36:18 <petahash> bitcoin is based on encryption
98 2014-10-30 03:36:26 <sipa> no
99 2014-10-30 03:36:29 <sipa> sorry
100 2014-10-30 03:36:49 <joeykrug> based on cryptography != based on encryption
101 2014-10-30 03:36:59 <sipa> #bitcoin please - this channel is about development
102 2014-10-30 03:37:01 <gmaxwell> #bitcoin for the bitcoin 101 please.
103 2014-10-30 03:37:05 <petahash> yea
104 2014-10-30 04:28:43 <Luke-Jr> weird, checkpoints are randomly enabled for tests? :/
105 2014-10-30 05:04:45 <sipa> ?
106 2014-10-30 05:13:44 <Luke-Jr> sipa: the miner_tests fixes were failing due to checkpoints, but Travis missed it at least once
107 2014-10-30 06:40:08 <BlueMatt> gmaxwell: before I go email github complaining that the emails are truncating the git hashes...you did post the ack on https://github.com/bitcoin/bitcoin/pull/5167 with the ``` first, and didnt just edit the post to add those?
108 2014-10-30 06:40:10 <BlueMatt> or wumpus?
109 2014-10-30 06:41:06 <sipa> i've before put a _ in front of commit hashes to prevent them from disappearing
110 2014-10-30 06:41:46 <gmaxwell> BlueMatt: I edited it to add the quotes, did it mangle it first? darn
111 2014-10-30 06:42:12 <BlueMatt> gmaxwell: git mangles it to shorhashes without the quotes
112 2014-10-30 06:42:29 <gmaxwell> sorry, was cargo culting and didn't realize I needed the quotes until I saw the font difference.. /me fixes
113 2014-10-30 06:42:56 <BlueMatt> no big deal, I just wanted to check before I went off and emailed github complainging that my notfication emails have invalid pgp signatures
114 2014-10-30 06:44:51 <gmaxwell> oh interesting it shows fine on the site now. Guess it only shortened in the email
115 2014-10-30 06:45:35 <BlueMatt> well if you missed the code tagging then it shortens
116 2014-10-30 06:45:54 <BlueMatt> I just wanted to see if it was an edit, as if it was, it would have emailed the old version
117 2014-10-30 07:39:59 <wumpus> BlueMatt: yes, I added them later when I noticed that the hash was truncated
118 2014-10-30 08:02:28 <wumpus> BlueMatt: I wonder if there a way to get shorter signatures in GPG - I like the idea of signing messages on github, but 7 lines of base64 crap for a one-line message is a bit over-the-top
119 2014-10-30 08:03:25 <gmaxwell> well, could use smaller keys. or the new ecc support in pre-rel GPG.
120 2014-10-30 08:03:27 <BlueMatt> wumpus: yes, I was thinking this
121 2014-10-30 08:03:39 <gmaxwell> or bitcoin signmessages...
122 2014-10-30 08:03:44 <BlueMatt> wumpus: I might email github anyway and just ask them to hide the signature behind a --click to see--
123 2014-10-30 08:03:55 <BlueMatt> gmaxwell: ewwww
124 2014-10-30 08:04:21 <gmaxwell> well... I mean... they're small.
125 2014-10-30 08:04:29 <BlueMatt> ewwwwww
126 2014-10-30 08:04:34 <sipa> and they blow people's mind
127 2014-10-30 08:04:42 <BlueMatt> ^ ok, this is true
128 2014-10-30 08:04:48 <sipa> "how the hell can it verify it without me telling it the public key!!!??!"
129 2014-10-30 08:05:11 <wumpus> BlueMatt: hiding it behind a 'click to see' would be another option, but I wouldn'te xpect prompt support from github itself here
130 2014-10-30 08:05:30 <wumpus> well, bitcoin signmessages are short, it's not that a bad idea
131 2014-10-30 08:05:53 <BlueMatt> wumpus: oh? Ive noted support@github being rather quick for simple things
132 2014-10-30 08:06:05 <BlueMatt> wumpus: I do prefer keeping it with the same keys as is used to sign git commits
133 2014-10-30 08:06:31 <BlueMatt> ACTION -> zzzZZZzzz
134 2014-10-30 08:06:33 <gmaxwell> BlueMatt: I kinda don't simply because I'd rather not have commit keys on a web-browsing machine. Seperation of concerns and all that.
135 2014-10-30 08:06:51 <BlueMatt> gmaxwell: you ACK commits on a web-browsing machine?
136 2014-10-30 08:06:54 <wumpus> why? you could sign the public key used for message verification with the GPG key to provide a trail
137 2014-10-30 08:07:07 <sipa> so all we need is a mechanism where you add a commit which adds your signmessage key to the git tree (in a commit message for example) :)
138 2014-10-30 08:07:22 <BlueMatt> all we need is a bitcoin-address WoT
139 2014-10-30 08:07:24 <BlueMatt> wait...no
140 2014-10-30 08:07:26 <sipa> NO
141 2014-10-30 08:07:40 <gmaxwell> ACTION stabs
142 2014-10-30 08:07:45 <wumpus> hah
143 2014-10-30 08:07:59 <wumpus> is there a way to browse github on a non-webbrowsing machine?
144 2014-10-30 08:08:11 <cfields> git fetch :)
145 2014-10-30 08:08:12 <BlueMatt> wumpus: git fetch, review code, ACK the commithash
146 2014-10-30 08:08:19 <wumpus> ncurses github interface :-)
147 2014-10-30 08:08:23 <BlueMatt> heh
148 2014-10-30 08:08:23 <gmaxwell> how do you get that ack onto the site?
149 2014-10-30 08:08:25 <wumpus> cfields: that doesn't get the comments
150 2014-10-30 08:08:37 <BlueMatt> gmaxwell: I have a directory sync'ed between machiens (well, sshfs)
151 2014-10-30 08:08:45 <wumpus> obviously I know how to access *git* without a webbrowser...
152 2014-10-30 08:08:49 <cfields> aren't comments in refs/notes/ or so ?
153 2014-10-30 08:08:52 <BlueMatt> where ssh is ssh-ftp-only and chroot'd
154 2014-10-30 08:09:04 <BlueMatt> wumpus: Ive been doing all my review on a non-web-browsing machine
155 2014-10-30 08:09:10 <sipa> 'comments' ?
156 2014-10-30 08:09:15 <BlueMatt> cfields: does anyone use those (github?)
157 2014-10-30 08:09:15 <sipa> ah, github comments
158 2014-10-30 08:09:18 <sipa> there's an api
159 2014-10-30 08:09:39 <gmaxwell> hm. we should be using it to mirror things in any case.
160 2014-10-30 08:09:51 <wumpus> gmaxwell: yes
161 2014-10-30 08:09:54 <sipa> yes
162 2014-10-30 08:09:55 <cfields> BlueMatt: pretty sure they're setup as a remote refspec so you can fetch 'em
163 2014-10-30 08:09:56 <gmaxwell> the fact that comments can be edited with no apparent history is sometimes annoying.
164 2014-10-30 08:10:10 <sipa> cfields: really?
165 2014-10-30 08:10:14 <wumpus> the github comments can be downloaded through a REST API, but not through git
166 2014-10-30 08:10:17 <gmaxwell> (there are some cases of sipa and I continually editing our responses in response to each other...)
167 2014-10-30 08:10:45 <BlueMatt> we all need to take a month off of development and build a distributed github linus-style
168 2014-10-30 08:11:07 <cfields> sipa: i swear i saw they were doing that at one point. googling.
169 2014-10-30 08:11:09 <BlueMatt> ACTION -> actually zzZZZzz
170 2014-10-30 08:11:15 <wumpus> let's not take this over the top
171 2014-10-30 08:11:29 <BlueMatt> wumpus: awwwww, buzzkill
172 2014-10-30 08:11:29 <sipa> clearly we need a blockchain with all commits in it
173 2014-10-30 08:11:33 <sipa> ... wait, that's git
174 2014-10-30 08:11:41 <wumpus> lol sipa
175 2014-10-30 08:11:46 <BlueMatt> sipa: noooo, we MUST ADD PROOF OF WORK
176 2014-10-30 08:12:09 <wumpus> proof of coding work?
177 2014-10-30 08:12:10 <sipa> showing that the unit tests passed is enough work
178 2014-10-30 08:12:18 <sipa> now all we need is a SNARK for that...
179 2014-10-30 08:12:22 <cfields> https://github.com/blog/707-git-notes-display
180 2014-10-30 08:12:27 <cfields> looks like that's what i was thinking of
181 2014-10-30 08:12:55 <wumpus> cfields: ah yes, that's yet another kind of notes which *are* embedded in the repo
182 2014-10-30 08:13:23 <cfields> wumpus: yes. i thought that github's comments were implemented as notes, or could be
183 2014-10-30 08:13:40 <wumpus> cfields: indeed, they could be
184 2014-10-30 08:13:51 <cfields> looks like i was mistaken though :(
185 2014-10-30 08:15:48 <wumpus> gmaxwell: it's quite easy to download all comments from github, where I was stuck is how to do it incremementally, so that we don't have to download the entire database every day (or whatever the mirroring time)
186 2014-10-30 08:16:23 <wumpus> but there's no notification for changed comments and such
187 2014-10-30 08:23:54 <wumpus> "
188 2014-10-30 08:27:38 <CodeShark> has anyone compiled any sort of usage statistics on the different JSON-RPC commands?
189 2014-10-30 08:27:55 <CodeShark> i.e. how much they are used in third-party projects
190 2014-10-30 08:29:04 <CodeShark> I'd guess probably not - but I thought I'd ask anyhow :)
191 2014-10-30 08:30:11 <wumpus> how could you do that? I can imagine adding profile counters for every call, but a phone-home to report statistics wouldn't be acceptable
192 2014-10-30 08:31:00 <CodeShark> actually, I was more looking at just parsing through open source projects and seeing which projects use what commands
193 2014-10-30 08:31:22 <CodeShark> I don't really care about each invocation - I just care about whether or not a project uses the command
194 2014-10-30 08:32:48 <CodeShark> I'm trying to work on some compatibility issues
195 2014-10-30 08:33:27 <CodeShark> I'm also curious as to the error handling
196 2014-10-30 08:33:51 <CodeShark> i.e. how seriously would it break projects if, i.e., the error codes were different
197 2014-10-30 08:35:08 <wumpus> the way to go about that would be to introduce a completely new API version, it'd allow cleaning up some deprecated functionality as well
198 2014-10-30 08:35:45 <wumpus> there's a github issue about that somewhere...
199 2014-10-30 08:36:02 <CodeShark> I'm working on an interface for a set of tools with the goal of making them as much a drop-in replacement for bitcoind in existing projects as possible
200 2014-10-30 08:36:39 <CodeShark> so a new API version wouldn't really help here - although I would definitely like to coordinate on API extensions
201 2014-10-30 08:37:18 <wumpus> ok, well, if that is the goal the obvious route would be to emulate bitcoind output as well as possible, at least not make any changes on purpose
202 2014-10-30 08:38:09 <CodeShark> besides strict formatting issues, there are also a few issues with the use model that are a bit of a challenge
203 2014-10-30 08:38:12 <wumpus> why would a drop-in replacement change error codes?
204 2014-10-30 08:38:37 <CodeShark> because these tools can sometimes give better error information - more granular error reporting
205 2014-10-30 08:39:09 <wumpus> but then it's no longer a drop-in replacement, that's already a step ahead of that, so provide a 'compatibility' layer as well as an improved API for example
206 2014-10-30 08:39:27 <CodeShark> right - I could suppress granular errors
207 2014-10-30 08:39:48 <CodeShark> I'm more concerned about the use model - in particular, the use of accounts poses some challenges
208 2014-10-30 08:40:18 <CodeShark> my tools also have a concept of "accounts" but it's completely different. what bitcoind calls an "account" my tools would call a "script label"
209 2014-10-30 08:40:21 <wumpus> we noticed that:p https://github.com/bitcoin/bitcoin/issues/3816
210 2014-10-30 08:41:04 <phantomcircuit> CodeShark, i would like to just remove the accounts stuff
211 2014-10-30 08:41:07 <wumpus> for accounts I indeed doubt that's what you want to emulate exactly
212 2014-10-30 08:41:13 <phantomcircuit> so much potential for brokenness
213 2014-10-30 08:41:41 <CodeShark> yeah - it's good to be able to label addressesâ¦but the account system is something I've always avoided
214 2014-10-30 08:41:54 <wumpus> that's exactly what is proposed in the issue
215 2014-10-30 08:42:05 <wumpus> replace the account system with a pure system of labeling addresses
216 2014-10-30 08:42:34 <wumpus> so no more account *balances*, no more sending *from* an account
217 2014-10-30 08:42:52 <wumpus> labels only receive
218 2014-10-30 08:43:01 <CodeShark> right
219 2014-10-30 08:43:13 <CodeShark> then getnewaddress could take a label parameter, i.e.
220 2014-10-30 08:44:29 <CodeShark> I've been considering associating several fields with receiving addresses - sender id, description, time issued, etc...
221 2014-10-30 08:44:38 <phantomcircuit> CodeShark, dont do that
222 2014-10-30 08:44:59 <phantomcircuit> you cant do incremental backups of the wallet reasonably
223 2014-10-30 08:45:11 <CodeShark> ?
224 2014-10-30 08:45:16 <phantomcircuit> so everytime you changes the associations you would need a new complete backup
225 2014-10-30 08:45:24 <CodeShark> I have a synchronization protocol
226 2014-10-30 08:45:24 <wumpus> something could be said about associating data to labels belonging in the merchant system
227 2014-10-30 08:45:33 <wumpus> not in the wallet
228 2014-10-30 08:45:57 <CodeShark> you can import labels into another instance of the same "wallet" - and have the option of keeping the labels you already had or replacing them when there's a conflict
229 2014-10-30 08:46:38 <wumpus> if we were to redesign it would be really minimal, provide identifiers so users can associate data with it on their side, but don't encourage storing data in the wallet
230 2014-10-30 08:47:24 <CodeShark> right - I suppose you could do the associations at another levelâ¦but I really want to be able to show the user detailed history without requiring them to write an entirely new app
231 2014-10-30 08:48:08 <phantomcircuit> wumpus, the address is already a unique identifier
232 2014-10-30 08:48:10 <CodeShark> I guess the associations could be stored in a separate db which can be synched independently from the core wallet stuff
233 2014-10-30 08:48:45 <wumpus> phantomcircuit: right
234 2014-10-30 08:48:54 <CodeShark> the only associations intrinsic to the wallet are things like BIP32 derivation path
235 2014-10-30 08:49:45 <wumpus> yes, those are essential
236 2014-10-30 08:49:53 <phantomcircuit> CodeShark, put the metadata in the system with the invoice information
237 2014-10-30 08:50:20 <phantomcircuit> CodeShark, the tree part of HD wallets might be an issue there actually
238 2014-10-30 08:50:28 <phantomcircuit> exponential possible paths
239 2014-10-30 08:50:52 <phantomcircuit> nasty if you're generating lots of addresses at weird indexes without many actualy transactions
240 2014-10-30 08:51:34 <CodeShark> right - you'd want to have small gaps if you want to be able to do scans
241 2014-10-30 08:52:13 <phantomcircuit> or you do it as a chain and not a tree
242 2014-10-30 08:52:35 <wumpus> gmaxwell,jgarzik,gavinandresen,sipa: I'm thinking of bumping autoprune to 0.11 instead of 0.10; it looks like we still have enough wrinkles to work out in headers-first, pulling in another major change in block handling seems risky
243 2014-10-30 09:10:44 <CodeShark> I'm using BIP32 parallel trees to generate multisig addresses
244 2014-10-30 09:10:46 <phantomcircuit> just seems like pre generating lots of private key/address pairs is going to be safer, then modify bitcoin such that it wont expand the keypool unless the rpc call is made
245 2014-10-30 09:11:35 <CodeShark> pregenerating lots of keys means having to transmit a crapton of data to deploy accountsâ¦and such an approach is highly intolerant of even the smallest discrepancies
246 2014-10-30 09:12:06 <phantomcircuit> CodeShark, maybe for sidechains it doesn't matter
247 2014-10-30 09:12:09 <phantomcircuit> er
248 2014-10-30 09:12:10 <phantomcircuit> does
249 2014-10-30 09:12:29 <phantomcircuit> transaction volume on bitcoin is low enough that even a ridiculous number of addresses could be small
250 2014-10-30 09:14:20 <CodeShark> BIP32 is capped at a little over 2 billion children per node
251 2014-10-30 09:14:42 <CodeShark> in practice you could probably safely go down a few orders of magnitude
252 2014-10-30 09:14:45 <phantomcircuit> even if you filled each block and you were every single transaction in the chain
253 2014-10-30 09:14:53 <phantomcircuit> that would only be like 225m transactions
254 2014-10-30 09:15:00 <phantomcircuit> so lets say 500m addresses
255 2014-10-30 09:15:14 <phantomcircuit> CodeShark, it's just not that much
256 2014-10-30 09:15:20 <CodeShark> and if you ran out of addresses, you could always deploy a new account and transfer everything over
257 2014-10-30 09:16:07 <phantomcircuit> eh
258 2014-10-30 09:16:29 <phantomcircuit> i see the appeal of an hd wallet scheme
259 2014-10-30 09:16:39 <phantomcircuit> but it feels more dangerous
260 2014-10-30 09:17:12 <CodeShark> in principle it could be done with pregenerated keys - we could devise a hierarchical account scheme using pregenerated keys and a hash to identify the account uniquely - but this doesn't ensure that different accounts don't share addresses
261 2014-10-30 09:18:04 <CodeShark> I guess that's not 100% ensured by an HD scheme eitherâ¦but the probability of collision is astronomically tiny :)
262 2014-10-30 09:22:59 <CodeShark> the two main dangers in HD wallet schemes are that you cannot delegate signing control over subtrees while also providing watching control over the entire treeâ¦and if the chain code gets leaked it compromises privacy
263 2014-10-30 09:23:45 <CodeShark> the first issue can be tackled to an extent for certain use cases - i.e. audits
264 2014-10-30 09:24:13 <CodeShark> by using a "dummy" pubkey in multisig addresses
265 2014-10-30 09:24:28 <CodeShark> but not for decentralized address generation
266 2014-10-30 09:25:56 <CodeShark> and the second issue is probably more of a feature than an issueâ¦you want it to be easy to deploy the tree. and even if you use pregenerated keys, if someone gains access to your data it compromises your privacy. the only difference is they need to copy more data
267 2014-10-30 09:27:14 <CodeShark> aside from that, barring a quantum computer I don't think there are any known attacks
268 2014-10-30 09:28:03 <CodeShark> you still have at least 128 bits of entropy
269 2014-10-30 09:29:47 <CodeShark> anyhow, back to the account thing with the bitcoind wallet - it's annoyingâ¦hard to find a way to be totally compatible with the existing API using my use model
270 2014-10-30 09:30:53 <CodeShark> I have at least two intrinsic attributes for each address and at least one metaattribute
271 2014-10-30 09:31:11 <CodeShark> the two intrinsic attributes are the root of the tree and the derivation path
272 2014-10-30 09:31:24 <CodeShark> and the metaattribute is the descriptive label
273 2014-10-30 09:33:02 <CodeShark> getbalance for a particular subtree completely sensible - but not really for the label
274 2014-10-30 09:33:10 <CodeShark> *is completely sensible
275 2014-10-30 09:33:57 <CodeShark> and you wouldn't want to do a getaddresseswithlabel (usually)
276 2014-10-30 09:34:08 <CodeShark> you'd usually want to do a getaddressesinsubtree
277 2014-10-30 09:35:13 <CodeShark> and for getnewaddress, you want to be able to select the parent node AND give the newly generated address a label in a single call
278 2014-10-30 09:43:44 <CodeShark> one of the reasons I wanted some statistics on usage is because if the account feature isn't being used too much it would probably be ok to just not support it at all
279 2014-10-30 09:44:34 <CodeShark> we can develop a new API version which distinguishes between labels and accounts
280 2014-10-30 09:46:30 <iwilcox> I'd expect a number of folks have built code around accounts that isn't open for security reasons.
281 2014-10-30 09:52:49 <CodeShark> yeah - probably not worth supporting at all
282 2014-10-30 09:58:43 <CodeShark> I've always maintained that the "account" feature in the bitcoind wallet was a bad idea to begin with
283 2014-10-30 10:00:18 <CodeShark> heck - integrating a wallet into the consensus engine was a bad idea to begin with :p
284 2014-10-30 10:00:31 <Luke-Jr> CodeShark: accounts are pretty handy, but not as implemented :p
285 2014-10-30 10:00:51 <Luke-Jr> needs automatic replication/backup..
286 2014-10-30 10:00:56 <Luke-Jr> and not part of the consensus engine
287 2014-10-30 10:01:26 <CodeShark> even running the wallet as part of the same process is a bad idea :p
288 2014-10-30 10:01:48 <CodeShark> the consensus engine is a runtime service - the wallet is a user-facing app
289 2014-10-30 10:02:06 <Luke-Jr> right
290 2014-10-30 10:02:20 <Luke-Jr> CodeShark: consider how far we've come from a Windows-only GUI-only all-in-one ;D
291 2014-10-30 10:02:25 <CodeShark> heh
292 2014-10-30 10:02:25 <sipa> CodeShark: you're preaching to the choir :)
293 2014-10-30 10:04:18 <wumpus> CodeShark: yes, we're kind of aware of that already... :)
294 2014-10-30 10:04:21 <CodeShark> heh
295 2014-10-30 10:05:18 <wumpus> we're aware it shouldn't be like this, it's more of a matter of 'how do we get there from here', we can't just drop accounts, or the wallet for that matter, from one release to the next
296 2014-10-30 10:05:54 <CodeShark> yes, I know we're all on the same page here
297 2014-10-30 10:07:24 <CodeShark> on a completely separate API issue, are there any proposals to add decimal types to JSON? :)
298 2014-10-30 10:07:34 <Luke-Jr> CodeShark: no need?
299 2014-10-30 10:07:48 <Luke-Jr> JSON's Number covers pretty much all possible use cases :P
300 2014-10-30 10:08:28 <Luke-Jr> ..what do you mean your JSON parser explodes on 2e65536?
301 2014-10-30 10:08:34 <CodeShark> there is a very strong need in the case of financial software - the distinction between internal representation as a base2 exponent vs a base10 exponent is significant
302 2014-10-30 10:08:39 <wumpus> well I has a pull open for a while that replaced the monetary amounts with strings or whole number satoshis, but no one really cared about it and I didn't feel like maintaining it anymore
303 2014-10-30 10:08:49 <Luke-Jr> CodeShark: Number has no internal representation
304 2014-10-30 10:09:09 <Luke-Jr> wumpus: I think I had the same a year or two prior to yours :P
305 2014-10-30 10:09:14 <Luke-Jr> wumpus: genjix as well
306 2014-10-30 10:09:24 <Luke-Jr> we even had Spesmilo use it IIRC
307 2014-10-30 10:09:28 <wumpus> Luke-Jr: so, while it's certainly an issue, it's not one that bothers people very strongly
308 2014-10-30 10:09:50 <Luke-Jr> it's an issue with JSON implementations, not JSON
309 2014-10-30 10:10:08 <wumpus> there are known cases of people using floating point for monetary amounts and messing up very badly... but it's not really bitcoin core's fault how people interpret the JSON
310 2014-10-30 10:10:09 <wumpus> right
311 2014-10-30 10:10:13 <CodeShark> Luke-Jr: the problem is that most architectures and environments use base2 floating points by default
312 2014-10-30 10:10:39 <CodeShark> doesn't matter how much precision you have - you cannot represent 1/5 exactly as a base2 floating point
313 2014-10-30 10:10:45 <CodeShark> whereas in decimal it's 0.2
314 2014-10-30 10:10:46 <wumpus> in Python it's quite easy to use Decimals instead, but not all JSON parsers allow such configuratbility
315 2014-10-30 10:10:53 <Luke-Jr> CodeShark: that's an implementation matter
316 2014-10-30 10:11:23 <Luke-Jr> using satoshis everywhere is more sane anyway
317 2014-10-30 10:11:37 <CodeShark> using satoshis everywhere is certainly more sane when dealing specifically with bitcoin
318 2014-10-30 10:11:54 <wumpus> Luke-Jr: watch for overflows though in languages without arbitrary-sized integers
319 2014-10-30 10:12:48 <Luke-Jr> wumpus: yes, GBT forced BFGMiner users to upgrade libjansson :P
320 2014-10-30 10:12:57 <wumpus> a decimal type can be safer in that case, as it was generally designed for usage with monetary amounts
321 2014-10-30 10:13:01 <Luke-Jr> (to a version like 10 years old)
322 2014-10-30 10:13:19 <wumpus> (and accountants really hate number overflows :P)
323 2014-10-30 10:15:41 <wumpus> anyhow, it's indeed an implementation issue, not so much an API issue; although numbers *looking like* floating point can be considered a trap for hapless developers
324 2014-10-30 10:16:58 <CodeShark> the most sane and least dangerous approaches are to either always use satoshisâ¦or to use a separate mantissa and base10 exponent
325 2014-10-30 10:17:14 <Luke-Jr> it's not sane to use decimal at all for bitcoin *shrug*
326 2014-10-30 10:17:21 <Luke-Jr> even if it worked perfectly
327 2014-10-30 10:17:53 <CodeShark> for bitcoin, always using satoshis is fine - problem is that other currencies might use different units
328 2014-10-30 10:18:21 <Luke-Jr> sure, but I only worry about bitcoin for JSON :P
329 2014-10-30 10:18:21 <wumpus> you'd have to specify the unit per currency
330 2014-10-30 10:18:48 <Luke-Jr> CodeShark: and what about inherently imprecise currenciesâ :p
331 2014-10-30 10:18:56 <Luke-Jr> *cough* Freicoin *cough*
332 2014-10-30 10:18:59 <CodeShark> lol
333 2014-10-30 10:19:18 <wumpus> hehe
334 2014-10-30 10:19:49 <sipa> freicoin is perfectly precise
335 2014-10-30 10:19:55 <sipa> just time-dependent :)
336 2014-10-30 10:20:22 <Luke-Jr> sipa: it's precise if you round it :p
337 2014-10-30 10:20:49 <CodeShark> uncertainty principle? (delta-E) (delta-t) >= h-bar/2 ?
338 2014-10-30 10:21:40 <Luke-Jr> CodeShark: there's a % fee levied against UTXOs every block
339 2014-10-30 10:21:48 <justanotheruser> Freicoins demmurage is block based, not real time based right?
340 2014-10-30 10:21:55 <Luke-Jr> pretty sure
341 2014-10-30 10:22:09 <Luke-Jr> but blocks are the new unit of time ;)
342 2014-10-30 10:22:22 <justanotheruser> clocks, the next blockchain app!
343 2014-10-30 10:23:22 <CodeShark> at the macro level, the block count is a fairly good clock :)
344 2014-10-30 10:23:26 <sipa> does anyone have an idea of the current max speed of generating vanity addresses?
345 2014-10-30 10:23:44 <sipa> (no, i'm not interested in a vanity address, but in hardware EC addition speed)
346 2014-10-30 10:23:53 <CodeShark> sipa: doesn't that lend itself to massive parallization?
347 2014-10-30 10:23:58 <CodeShark> I assume you're talking about a single thread
348 2014-10-30 10:24:02 <Luke-Jr> sipa: public, or the secret vanitygen?
349 2014-10-30 10:24:08 <CodeShark> *parallelization
350 2014-10-30 10:24:23 <Luke-Jr> sipa: the secret edition is faster than GPUs I hear
351 2014-10-30 10:24:26 <Luke-Jr> on CPUs
352 2014-10-30 10:24:30 <sipa> secret edition?
353 2014-10-30 10:24:51 <CodeShark> shhh, don't tell anyone about that
354 2014-10-30 10:25:31 <sipa> haha
355 2014-10-30 10:25:47 <sipa> i'm not interested in a vanity secret no
356 2014-10-30 10:25:50 <Luke-Jr> sipa: PM'd
357 2014-10-30 10:43:52 <CodeShark> hmmâ¦another option for the label vs. account thing is to use bitcoind "accounts" as labels in my toolsâ¦and to have a global state where you can set the "account" in the sense of my tools for multiple calls
358 2014-10-30 10:44:30 <wumpus> making the api stateful is kind of ugly
359 2014-10-30 10:44:45 <wumpus> why not make the global account part of the URI, for example?
360 2014-10-30 10:45:01 <CodeShark> would be betterâ¦but it breaks compatibility
361 2014-10-30 10:45:16 <CodeShark> that's how my own APIs work
362 2014-10-30 10:45:18 <wumpus> or even based on the authentication
363 2014-10-30 10:45:30 <wumpus> but stateful is... meh
364 2014-10-30 10:46:07 <CodeShark> yeah, it's not ideal - but otherwise I really can't make a compatible sendtoaddress, i.e.
365 2014-10-30 10:46:28 <Luke-Jr> you can put it in the URI and be compatible..
366 2014-10-30 10:46:33 <wumpus> how would that break compatibility? JSON RPC implementations generally allow specifying the URI
367 2014-10-30 10:47:23 <CodeShark> the call sendtoaddress <address> <amount> is perfectly legit in the JSON-RPC
368 2014-10-30 10:48:01 <CodeShark> the only way to make that work with my tools is to either always use a single accountâ¦or to allow a global account state to be set
369 2014-10-30 10:49:23 <Luke-Jr> CodeShark: or to use the URI, or username, â¦
370 2014-10-30 10:50:02 <CodeShark> yes, I suppose you could do thatâ¦but that would require changing the client-side code
371 2014-10-30 10:50:31 <Luke-Jr> certainly the username wouldn't
372 2014-10-30 10:50:51 <CodeShark> hmmm...
373 2014-10-30 10:50:55 <CodeShark> perhaps
374 2014-10-30 10:51:20 <CodeShark> that's not such a terrible idea
375 2014-10-30 10:52:55 <CodeShark> although if the client isn't using accounts to begin with, we could just specify the account name in a config file and use it for all calls
376 2014-10-30 10:53:10 <Luke-Jr> â¦
377 2014-10-30 10:53:19 <Luke-Jr> not like you need the username for something else :P
378 2014-10-30 10:53:57 <CodeShark> well, not sure I like the idea of mixing account selection with authentication mechanisms
379 2014-10-30 10:54:05 <CodeShark> in principle it seems like a bad idea
380 2014-10-30 10:54:21 <Luke-Jr> username is account selection normally
381 2014-10-30 10:54:28 <CodeShark> depends on use model
382 2014-10-30 10:54:39 <CodeShark> the use model I envision is multiple accounts with differing security policies
383 2014-10-30 10:54:45 <CodeShark> but called by the same application
384 2014-10-30 10:55:40 <CodeShark> using the username for the account would work as a temporary hack - but it's certainly not the way to do this going forward
385 2014-10-30 10:55:51 <CodeShark> it would work for the drop-in replacement idea
386 2014-10-30 10:56:33 <CodeShark> but eventually I intend to have an authentication mechanism that's based on API keys with access controls
387 2014-10-30 10:56:44 <wumpus> I'd personally prefer to have it URI based
388 2014-10-30 10:56:54 <wumpus> it's trivial to change the URI in clients
389 2014-10-30 10:56:59 <CodeShark> yeah, agreed
390 2014-10-30 10:56:59 <Luke-Jr> wumpus: not in bitcoin-cli :p
391 2014-10-30 10:57:10 <wumpus> Luke-Jr: who cares about bitcoin-cli
392 2014-10-30 10:57:20 <CodeShark> yeah, nobody is going to be using this with bitcoin-cli :p
393 2014-10-30 10:57:35 <wumpus> he could pack his own fancy bitcoin cli tool
394 2014-10-30 10:57:40 <CodeShark> exactly
395 2014-10-30 10:57:51 <CodeShark> or even a simple bash script that makes curl calls :p
396 2014-10-30 11:04:26 <CodeShark> I don't want to encourage people to specify accounts in the URI, though - I'd much rather provide a new command for anyone who wants to make use of multiple accounts (in the sense of my tools, not the bitcoind wallet sense)
397 2014-10-30 11:04:52 <wumpus> well, do that then
398 2014-10-30 11:05:11 <wumpus> arguably if you want to use those you're breaking compatibility already
399 2014-10-30 11:05:18 <CodeShark> right
400 2014-10-30 11:05:34 <CodeShark> compatibility would only cover the case where people are not using accounts in the sense of my tools
401 2014-10-30 11:05:45 <CodeShark> so might as well just specify the account in a config file :)
402 2014-10-30 11:07:27 <CodeShark> defaultaccount=foo
403 2014-10-30 11:29:38 <dabura667> Is the pruned commit mentioned on Twitter a utxo based pruning, or does it just prune chronologically old blocks regardless of utxos or none?
404 2014-10-30 11:30:40 <paveljanik> Anyone seen a problem with sanity_test_memcpy<1025>()?
405 2014-10-30 11:30:58 <paveljanik> I have an old Mac OS X system where this sometimes fails...
406 2014-10-30 11:30:59 <paveljanik> 8)
407 2014-10-30 11:31:51 <paveljanik> I can reproduce it - when I fprintf something to stderr before this, it is OK. The clean master fails though.
408 2014-10-30 11:33:40 <wumpus> what that test does is: fill an array on the stack with increasing integers, copy it to a new location (also on the stack), then compare
409 2014-10-30 11:34:01 <paveljanik> yup
410 2014-10-30 11:34:03 <wumpus> if that fails either your CPU or memory is pretty much broken
411 2014-10-30 11:34:11 <paveljanik> I'm now investogating the contents of the array...
412 2014-10-30 11:34:15 <wumpus> I wouldn't suggest using it for any cryptocurrency activity
413 2014-10-30 11:34:25 <paveljanik> it could be the compiler...
414 2014-10-30 11:34:28 <wumpus> (that's what the sanity tests are for)
415 2014-10-30 11:34:42 <paveljanik> but yes, the reasoning is good anyway ;-)
416 2014-10-30 11:34:44 <wumpus> yes, but if that is broken, other uses of memcpy could be broken too, that's very dangerous
417 2014-10-30 11:35:54 <wumpus> also that it seems to fail *randomly* seems to indicate a hardware not compiler issue
418 2014-10-30 11:37:35 <paveljanik> it is not random...
419 2014-10-30 11:37:41 <paveljanik> it fails consistently
420 2014-10-30 11:37:56 <paveljanik> when I put fprintf(stderr, ...) before the call, it is OK.
421 2014-10-30 11:38:01 <paveljanik> I'll investigate more.
422 2014-10-30 11:38:11 <wumpus> dabura667: it deletes old blocks
423 2014-10-30 11:38:24 <wumpus> dabura667: the utxo set is maintained separately in a database, so is not affected by that
424 2014-10-30 11:38:40 <dabura667> Oic
425 2014-10-30 11:38:57 <dabura667> So all utxo raw transactions are still there
426 2014-10-30 11:39:00 <dabura667> Gotcha
427 2014-10-30 11:39:19 <wumpus> unspent, theoretically spendable outputs are still there in the utxo set
428 2014-10-30 11:39:26 <wumpus> (that's not 'transactions')
429 2014-10-30 11:42:08 <wumpus> looking up the accompanying transaction happens in the block files, which could have been deleted, so that's not possible anymore (neither is -txindex IIRC)
430 2014-10-30 11:44:35 <paveljanik> PJ: memcpy_test[01] = 01
431 2014-10-30 11:44:35 <paveljanik> PJ: memcpy_test[02] = 02
432 2014-10-30 11:44:35 <paveljanik> wumpus: PJ: memcpy_test[00] = 01
433 2014-10-30 11:44:40 <paveljanik> 00 -> 01
434 2014-10-30 11:45:04 <paveljanik> 8)
435 2014-10-30 11:45:04 <paveljanik> when I fprintf something at the beginning of sanity_test_memcpy(), 00 -> 00
436 2014-10-30 11:45:46 <wumpus> interesting, so it misaligns the array
437 2014-10-30 11:46:09 <wumpus> eh, no
438 2014-10-30 11:46:36 <paveljanik> I do not like ++i 8)
439 2014-10-30 11:46:46 <wumpus> ?
440 2014-10-30 11:47:23 <paveljanik> it always remind me I have to think about its value ;-)
441 2014-10-30 11:47:28 <jgarzik> wumpus, +1 autoprune bump
442 2014-10-30 11:47:49 <wumpus> for (a;b;c) { d } is equivalent to a; while(c); { d; c; } , so using ++i or i++ in c doesn't make a difference for the array
443 2014-10-30 11:48:17 <wumpus> s/while(c)/while(b)
444 2014-10-30 11:51:25 <sipa> this is not a programming class
445 2014-10-30 11:52:03 <wumpus> sipa: his compiler could use a programming class though ;)
446 2014-10-30 11:52:47 <paveljanik> it is probably very old gcc
447 2014-10-30 11:52:48 <paveljanik> mmnt
448 2014-10-30 11:53:02 <paveljanik> gcc version 4.2.1 (Apple Inc. build 5666) (dot 3)
449 2014-10-30 11:53:05 <wumpus> well, upgrade it
450 2014-10-30 11:53:30 <paveljanik> this is not my primary machine and I'm testing git master on various systems...
451 2014-10-30 11:53:40 <paveljanik> I can upgrade or forget about the machine...
452 2014-10-30 11:53:42 <paveljanik> ;-)
453 2014-10-30 11:56:41 <Luke-Jr> paveljanik: broken compilers are not a concern
454 2014-10-30 11:59:01 <paveljanik> ok, accepted.
455 2014-10-30 12:00:00 <paveljanik> for the records: the machine is mac os x 10.6.8
456 2014-10-30 12:02:12 <paveljanik> gcc version above
457 2014-10-30 12:03:07 <paveljanik> we should probably write it down somewhere for our users
458 2014-10-30 12:03:49 <paveljanik> the f is called glibc_sanity_test() but it looks like it is gcc_sanity_test in this case ;-)
459 2014-10-30 12:04:09 <Luke-Jr> paveljanik: not even Apple supports OS X 10.6
460 2014-10-30 12:04:35 <paveljanik> yes
461 2014-10-30 12:06:00 <paveljanik> ok, I'll skip this and do some further testing, just for the fun
462 2014-10-30 14:26:22 <paveljanik> LogPrintf("\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n"); - why only 20? 8)
463 2014-10-30 14:33:14 <sipa> paveljanik: not enough?
464 2014-10-30 14:33:42 <paveljanik> when watching -printtoconsole -debug, I always call for 1 max ;-)
465 2014-10-30 14:39:46 <gdm85> sipa: do you have gpg?
466 2014-10-30 14:40:23 <sipa> yes?
467 2014-10-30 14:40:31 <gdm85> sipa: is it on a public keyserver?
468 2014-10-30 14:40:49 <wumpus> you could just have queried a public keyserver to find out? :p
469 2014-10-30 14:40:53 <sipa> yes, and on bitcoin.org/pieterwuille.asc
470 2014-10-30 14:41:13 <Jouke> wumpus: we are having problems with finding keys on keyservers atm
471 2014-10-30 14:41:16 <gdm85> for some reason pgp.mit.edu was not returning my key and some of my friends
472 2014-10-30 14:41:29 <wumpus> Jouke: ok - strange
473 2014-10-30 14:41:46 <sipa> (and i use it to sign all merges)
474 2014-10-30 14:42:47 <Naphex> in bitcoin-core is it sufficient to SetAddressBook label back to null to return an address back into the reserve?
475 2014-10-30 14:43:32 <wumpus> Naphex: no
476 2014-10-30 14:43:45 <wumpus> there's no way to return a key to the pool
477 2014-10-30 14:44:25 <sipa> if you remove the label programmatically, it will be considered a change key
478 2014-10-30 14:44:47 <Naphex> how about if i insert it back into setSort?
479 2014-10-30 14:44:47 <sipa> to put it back into reserve, you have to explicitly add its id back as a pool entry
480 2014-10-30 14:44:58 <Naphex> i'm trying to code up a wallet function to return an address back to reserve
481 2014-10-30 14:45:08 <wumpus> indeed, if you manage to completely remove the label (instead of setting it to ''), it will just disappear from view and it will consider it a used change key
482 2014-10-30 14:45:37 <Naphex> aye, and a change key in the back in the pool set is reserve
483 2014-10-30 14:45:50 <sipa> indeed
484 2014-10-30 14:46:01 <Naphex> so if i do a setKeyPool.clear() and reimport it should be enough
485 2014-10-30 14:46:15 <phantomcircuit> Naphex, ... why?
486 2014-10-30 14:46:46 <Naphex> phantomcircuit: for the moment i just want to have addresses allocated to accounts temporarily
487 2014-10-30 14:46:49 <wumpus> clear the keypool?
488 2014-10-30 14:46:52 <Naphex> and return to keypool after expiration
489 2014-10-30 14:47:33 <phantomcircuit> Naphex, ... why?
490 2014-10-30 14:48:09 <Naphex> phantomcircuit: cause i want too
491 2014-10-30 14:49:28 <phantomcircuit> sounds dangerous
492 2014-10-30 14:49:34 <wumpus> clearing the key pool will result in a new keypool being generated
493 2014-10-30 14:50:06 <Naphex> phantomcircuit: why would it, what if you create an account to receive something, and never receive for 4 years
494 2014-10-30 14:50:22 <wumpus> normally that's only done when encrypting the wallet, or after recovery
495 2014-10-30 14:50:25 <phantomcircuit> DO NOT USE THE ACCOUNTS SYSTEM FOR REAL ACCOUNTING
496 2014-10-30 14:50:26 <iwilcox> gdm85: Were you searching on key ID?
497 2014-10-30 14:50:49 <gdm85> iwilcox: yes
498 2014-10-30 14:50:49 <Naphex> phantomcircuit: i am not
499 2014-10-30 14:50:59 <Naphex> i just want to get a unused address per account
500 2014-10-30 14:51:07 <Naphex> and if its never used i want to return it back to the reserve
501 2014-10-30 14:51:12 <Naphex> concious of the risks
502 2014-10-30 14:51:23 <phantomcircuit> Naphex, it costs close to nothing to keep the address as active instead of in the key pool
503 2014-10-30 14:51:32 <iwilcox> gdm85: The web interface pgp.mit uses seems to be picky about the 0x, in my experience
504 2014-10-30 14:52:00 <gdm85> iwilcox: I didn't specify that. mit.edu keyservers are currently troubled, but apparently also some other server
505 2014-10-30 14:52:01 <Naphex> phantomcircuit: i know but i want to have the ability to return a key back in the pool
506 2014-10-30 14:52:14 <phantomcircuit> but like.... why
507 2014-10-30 14:52:47 <wumpus> I guess you could keep your own reserve of addresses, outside of bitcoind, and prefer to deal those out, seems safer than trying to hack the wallet code
508 2014-10-30 14:53:32 <Naphex> i am working on java code to p2p sync with trusted bitcoin node, index that data and feed it over various interfaces
509 2014-10-30 14:53:36 <Naphex> but this is for something else
510 2014-10-30 14:53:55 <Naphex> pretty specific, i checked most other functions including import and dump and it should react fine
511 2014-10-30 14:54:09 <Naphex> not hacking much in just adding a new rpcwallet function to return the key back to reserve
512 2014-10-30 14:54:12 <Naphex> and remove its labe
513 2014-10-30 14:54:13 <Naphex> label
514 2014-10-30 14:54:15 <phantomcircuit> so far i dont think you've actually articulated a good reason why....
515 2014-10-30 14:54:16 <Naphex> for extra control
516 2014-10-30 14:54:34 <phantomcircuit> shrug
517 2014-10-30 14:54:35 <phantomcircuit> gtg
518 2014-10-30 14:54:36 <wumpus> (ie, query bitcoind for a new address only if you haven't got anything left in your 'return' pool)
519 2014-10-30 14:55:00 <wumpus> then again - I agree with phantomcircuit that I wouldn't bother, keys are cheap
520 2014-10-30 14:55:20 <iwilcox> gdm85: Well, for future reference (just tested): no 0x means no results.
521 2014-10-30 14:56:54 <Naphex> i just want to experiment with the wallet code
522 2014-10-30 14:56:56 <gdm85> iwilcox: true. but I found the status page of keyservers, now it's clear what's going on. </OT>
523 2014-10-30 14:57:01 <Naphex> and want more control over the labing of addreses over rpc
524 2014-10-30 14:57:06 <Naphex> so i can test and experiment easier
525 2014-10-30 14:57:16 <Naphex> its not going to end up production code or anything
526 2014-10-30 14:57:18 <Naphex> labling*
527 2014-10-30 14:57:46 <Naphex> i dont want to have another addressbook just to label this, bitcoin-core one should do fine.
528 2014-10-30 14:58:57 <Naphex> also setaccount will call a getnewaddress again if you want to relable an address and its just annoying
529 2014-10-30 15:24:59 <wumpus> Naphex: did you see CReserveKey::ReturnKey() ? it does exactly what you want (but for a shorter timespan)
530 2014-10-30 15:30:04 <Naphex> wumpus: thank you, i will check it out
531 2014-10-30 16:30:04 <maaku> is autoprune #4701 really ready for 0.10?
532 2014-10-30 16:30:58 <maaku> I thought there ws concern that without pruned nodes storing ranges of historical blocks (and advertising those ranges via version messages, etc.) it'd be too risky to deploy
533 2014-10-30 17:03:58 <sipa> maaku: that's not really a concern, as 1) they don't advertize as full nodes 2) without wallet support, those running such a pruned node would be unlikely to be running a node in the first place
534 2014-10-30 17:04:44 <maaku> "without wallet support'?
535 2014-10-30 17:04:59 <sipa> enabling pruning forces -disablewallet
536 2014-10-30 17:05:10 <sipa> as the interaction between the two has not been tested
537 2014-10-30 17:05:25 <maaku> people are going to be wondering what the point is then
538 2014-10-30 17:05:35 <sipa> i'd definitely run a pruned node :)
539 2014-10-30 17:05:47 <maaku> sure this channel is full of exceptoins
540 2014-10-30 17:06:16 <sipa> thanks!
541 2014-10-30 17:06:42 <maaku> but every person i've interacted with that requested pruning (at conferences, etc.) wanted it so they could use bitcoin-qt as their wallet without gigabytes of ever growing disk usage
542 2014-10-30 17:07:12 <maaku> forcing -disablewallet is a big surprise
543 2014-10-30 17:07:34 <sipa> i think the solution for those people is an SPV version of bitcoin-qt
544 2014-10-30 17:07:36 <gwillen> maaku: well, you don't have to announce it
545 2014-10-30 17:08:00 <sipa> and wallet support can come later of course, there is no fundamental reason why pruning would require nowallet
546 2014-10-30 17:08:01 <gwillen> you can put it in to get some people using it in production
547 2014-10-30 17:08:22 <sipa> but as hardly anyone develops or uses or tests the wallet code in those actively contributing to the project...
548 2014-10-30 17:08:38 <maaku> gwillen: sure but that doesn't help avoid a pr snafu
549 2014-10-30 17:09:20 <gwillen> maaku: well, just make sure that anywhere 'pruning' is mentioned (i.e. release notes, usage message, etc.) you make it clear what it isn't
550 2014-10-30 17:09:42 <rdponticelli> Well, I'm running a wallet on a pruned node, but launching that for productions would require a lot of extra work
551 2014-10-30 17:10:10 <maaku> running a full node that can't (a) help serve IBD, or (b) provide wallet functionality is a very special use case
552 2014-10-30 17:10:39 <phantomcircuit> maaku, compact utxo proofs would make that useful :P
553 2014-10-30 17:10:53 <maaku> true :)
554 2014-10-30 17:10:54 <phantomcircuit> until then i dont see what the point is except as the trusted node for an spv client
555 2014-10-30 17:11:28 <maaku> phantomcircuit: right. which is why I assumed it wouldn't be a release feature until pruned nodes could at least contribute to IBD
556 2014-10-30 17:11:36 <maaku> which is not that hard a patch to do now that headers first is in
557 2014-10-30 17:12:23 <sipa> i'm not worried about IBD really
558 2014-10-30 17:18:21 <rdponticelli> btw, sipa or wumpus: should I acquire some lock to use the writing methods on CBlockTreeDB?
559 2014-10-30 17:18:36 <sipa> yes, cs_main
560 2014-10-30 17:18:53 <rdponticelli> Ok, I thought so
561 2014-10-30 17:19:47 <sipa> well, for pblocktree that is
562 2014-10-30 17:19:59 <sipa> you _could_ create another CBlockTreeDB instance of course :)
563 2014-10-30 17:21:46 <rdponticelli> No, I'll keep pblocktree
564 2014-10-30 17:22:04 <rdponticelli> I've been already testing the locks