1 2013-01-23 13:27:50 <sipa> i think it's too late for that
2 2013-01-23 13:28:31 <gavinandresen> way too late for wallet changes. Maybe a wallet re-implementation for 0.9
3 2013-01-23 13:29:06 <kinlo> I'd like that, berkley still gives me the creeps
4 2013-01-23 13:29:13 <Luke-Jr> hmm, didn't know it was late yet, ok
5 2013-01-23 13:29:18 <Luke-Jr> maybe I should give master another try
6 2013-01-23 13:29:37 <sipa> yes, i'd like to do all three wallet changes for 0.9 (drop vfWallet/ReacceptWalletTransactions, move away from bdb, BIP32)
7 2013-01-23 13:30:29 <gavinandresen> ??? support for multi device wallets....
8 2013-01-23 13:30:42 <kinlo> I'd hope to see the wallet to be seperated in 2 files, one containing only the keys and plaintext, one containing the transactions cache that could be rebuild at any time
9 2013-01-23 13:30:49 <Luke-Jr> gavinandresen++
10 2013-01-23 13:30:55 <gavinandresen> lets not design that now, though. I'd like to get a 0.8 release candidate out in the next few days
11 2013-01-23 13:30:55 <sipa> kinlo: i'm completely against that :)
12 2013-01-23 13:31:16 <Luke-Jr> kinlo: what about transaction metadata? ;)
13 2013-01-23 13:31:22 <sipa> kinlo: transactions in a wallet are not a cache, and using it like that means you're using the blockchain as your wallet
14 2013-01-23 13:31:35 <sipa> sure you won't lose confirmed money that way
15 2013-01-23 13:32:17 <TheSeven> can't hurt to be able to recover keys easily from a somehow broken wallet though
16 2013-01-23 13:32:54 <sipa> that's something else :0
17 2013-01-23 13:33:15 <iwoter> Luke-Jr--
18 2013-01-23 13:33:23 <TheSeven> but then again, instead of basically exporting the keys into a key backup file, you could back up the wallet in the first place
19 2013-01-23 13:33:32 <kinlo> Luke-Jr: put it in the plaintext one
20 2013-01-23 13:33:39 <Luke-Jr> TheSeven: an append-only wallet file is pretty backup-friendly
21 2013-01-23 13:34:03 <Luke-Jr> sipa: although rsync seems to play poorly with append-only files - it might make sense to split the file every so often
22 2013-01-23 13:34:08 <TheSeven> and pretty unlikely to get corrupted in the first place
23 2013-01-23 13:34:18 <sipa> kinlo: i just don't like the idea of depending on the ability to easily do a rescan of the blockchain
24 2013-01-23 13:34:26 <iwoter> hey people, why cache transactions in a wallet file? aren't there indices around to the blockchain?
25 2013-01-23 13:38:18 <sipa> iwoter: as an optional feature, i'm in favor of that
26 2013-01-23 13:38:27 <sipa> iwoter: but not for wallets to depend on
27 2013-01-23 13:38:33 <sipa> there is really no need for that
28 2013-01-23 13:39:34 <sipa> in fact, i think wallets shouldn't depend on any local data present
29 2013-01-23 13:40:17 <iwoter> depends on what you want a "wallet" to be
30 2013-01-23 13:40:22 <TheSeven> ACTION kinda likes the ideas behind armory
31 2013-01-23 13:40:59 <iwoter> i always thought of it as just a collection of private keys, but i'm not into the code much. nice having a conversation here though!
32 2013-01-23 13:41:32 <sipa> the only long-term viable client that is still a p2p node, is an SPV client (stores block headers + keys + transactions affecting wallet)
33 2013-01-23 13:49:06 <iwoter> or states?
34 2013-01-23 13:49:08 <sipa> wth is mis-bootstrapping?
35 2013-01-23 13:49:19 <sipa> gavinandresen: not following re #2131... if you don't want malleability, it's certainly possible to introduce a v2 transaction with stronger restrictions, but you'll still need code to create even S signatures?
36 2013-01-23 13:49:25 <iwoter> getting IP addresses that don't belong to the real bitcoin network
37 2013-01-23 13:50:19 <iwoter> so if you have a protocol where a client asks for the state at a point, you could get a false state
38 2013-01-23 13:50:43 <gavinandresen> sipa: I'm saying the problem isn't only even-or-odd signatures, the problem is that the signature can be changed. I think we should allow either even or odd, and fix the "can be changed" part
39 2013-01-23 13:50:43 <iwoter> sipa: is this the difficulty you were talking about?
40 2013-01-23 13:51:35 <sipa> gavinandresen: well, preventing "can be changed" implies enforcing some constraint on the signature
41 2013-01-23 13:52:21 <gavinandresen> sipa: I'm saying put another signature on top of the txid. So if you change the inner sig, the outer sig (only used during relaying) becomes invalid
42 2013-01-23 13:52:34 <sipa> gavinandresen: how will you do that?
43 2013-01-23 13:52:45 <gavinandresen> extra data in the 'tx' message
44 2013-01-23 13:52:50 <sipa> eww
45 2013-01-23 13:53:04 <gavinandresen> well, extra data tacked onto the end of the 'tx' message, if tx.version==2
46 2013-01-23 13:53:30 <gavinandresen> why eww ? It is a new transaction message....
47 2013-01-23 13:53:52 <gavinandresen> old nodes will ignore the extra stuff, new nodes will parse it and enforce new rules
48 2013-01-23 13:54:01 <sipa> seems like trying to solve the problem in the wrong place
49 2013-01-23 13:54:17 <sipa> as you'll need to know a way to find the pubkey a transaction is coming from
50 2013-01-23 13:54:23 <gavinandresen> not if "the problem" is "relaying nodes can change the txid"
51 2013-01-23 13:54:34 <sipa> so the outer wrapping would still depend on the specifics of the script language
52 2013-01-23 13:54:48 <gavinandresen> yes??? To Be Determined...
53 2013-01-23 13:55:17 <sipa> i'd rather have a v2 script language in that case, which changes the hashing system altogether
54 2013-01-23 13:55:18 <gavinandresen> That's another "I don't' want to design it right now"
55 2013-01-23 13:55:52 <iwoter> how about a hash of a state?
56 2013-01-23 13:56:11 <sipa> iwoter: you mean the hash of the UTXO data?
57 2013-01-23 13:56:44 <iwoter> i'm not very into the code, really, so i don't know UTXO. i'm just saying the "state"
58 2013-01-23 13:56:53 <sipa> utxo = unspent transaction outputs
59 2013-01-23 13:57:05 <iwoter> i guess that would be it
60 2013-01-23 13:57:21 <iwoter> some normalized representation of it, hashed to give something that can be compared
61 2013-01-23 13:57:22 <sipa> that together with the hash of the tip of the block chain defines the state you need to do full transaction validation
62 2013-01-23 13:57:56 <iwoter> how about if one asked many nodes about a particular past state, to see if they agree
63 2013-01-23 13:58:10 <iwoter> and only then downloads it
64 2013-01-23 13:59:09 <sipa> that means you're exposing yourself to a sybil attack to enforce the most basic rules, like inflation
65 2013-01-23 13:59:28 <iwoter> enforce what?
66 2013-01-23 13:59:43 <sipa> sybil attack = all nodes you connect to are evil
67 2013-01-23 13:59:54 <iwoter> well, that could happen with a bootstrap
68 2013-01-23 13:59:55 <sipa> enforcing = verifying other nodes don't lie to you
69 2013-01-23 14:00:09 <sipa> inflation = the rules governing how many coins a new block is allowed to introduce
70 2013-01-23 14:00:50 <sipa> if you're going to trust other nodes to tell you the state, without its history, you're exposing yourself to the worst kind of lying
71 2013-01-23 14:01:37 <sipa> so to have a fully validating nodes, which needs no trust in the network, you need to validate all history
72 2013-01-23 14:01:42 <sipa> there is simply no way around that
73 2013-01-23 14:01:51 <sipa> but that doesn't mean you need to keep all history around forever
74 2013-01-23 14:02:02 <sipa> you can throw it away if you validated it
75 2013-01-23 14:02:12 <iwoter> the whole bootstrapping business takes an annoying long time though
76 2013-01-23 14:02:29 <iwoter> trying to get people to use bitcoin can be tough
77 2013-01-23 14:02:36 <sipa> it takes around 7 minutes on laptop, when importing block data from disk, to get to block 210000
78 2013-01-23 14:02:46 <sipa> *my
79 2013-01-23 14:02:50 <sipa> with the latest code
80 2013-01-23 14:03:00 <sipa> and a large cache
81 2013-01-23 14:03:19 <sipa> and some optimizations that haven't been merged
82 2013-01-23 14:03:25 <iwoter> i think it's like 6 GB now
83 2013-01-23 14:03:32 <sipa> yes
84 2013-01-23 14:03:44 <sipa> but downloading 6 GB isn't a problem these days, is it?
85 2013-01-23 14:03:57 <iwoter> hmm, well, i don't know
86 2013-01-23 14:04:20 <iwoter> depends where you are
87 2013-01-23 14:04:41 <sipa> the slowness of the clients is not because it's hard; it's because a) the block fetching algorithm is stupid and b) the database code is very inefficient and causes extremely much I/O
88 2013-01-23 14:04:48 <sipa> b) will be improved a ton in 0.8
89 2013-01-23 14:05:04 <sipa> a) can be fixed for now by using bootstrap.dat
90 2013-01-23 14:05:45 <gavinandresen> a UTXO hash at every checkpoint, compiled into the code, might be an OK idea. But what problem are we trying solve? Faster startup for newbies should be done by downloading headers first, then full blocks in the background IF (and only if) the newbie has a fast machine with lots of disk space.
91 2013-01-23 14:07:20 <HM> if it's a GUI let the user decide
92 2013-01-23 14:07:31 <HM> if it's a command line or server process then do the safest thing
93 2013-01-23 14:07:32 <sipa> if we have headers-only mode, i think checkpoints should go away entirely :)
94 2013-01-23 14:09:39 <sipa> you could have a "don't check signatures in history longer than X ago" - if you already have the headers in advance, you know you're on the best chain before validation of block data starts
95 2013-01-23 14:23:28 <CodeShark> what if a signature claims a txout from many blocks ago?
96 2013-01-23 14:24:25 <sipa> CodeShark: what then?
97 2013-01-23 14:24:44 <CodeShark> you need the tx to check the signature
98 2013-01-23 14:25:08 <sipa> you only need the spending tx; not the tx being spent
99 2013-01-23 14:25:13 <sipa> (only its txout is necessary)
100 2013-01-23 14:25:17 <Jouke_> does the bitcoin client always use a new change address?
101 2013-01-23 14:25:54 <sipa> CodeShark: and even that is irrelevant, as you'll have the tx at the time you're doing validation
102 2013-01-23 14:26:04 <sipa> Jouke_: yes
103 2013-01-23 14:26:17 <Jouke_> sipa: has it always done so?
104 2013-01-23 14:26:26 <sipa> since very long ago
105 2013-01-23 14:27:03 <Jouke_> 0.5.3?
106 2013-01-23 14:27:08 <sipa> Jouke_: long before that
107 2013-01-23 14:27:16 <Jouke_> Then I want to report a bug :P
108 2013-01-23 14:27:26 <Jouke_> about 5.3 :P
109 2013-01-23 14:27:30 <Jouke_> At least I think so
110 2013-01-23 14:27:38 <sipa> if you can reproduce on 0.7.2, feel free
111 2013-01-23 14:27:53 <Jouke_> tranasction: de9c987dbe2c6fd2d4fafbfdcbacabe04aa5af73ed3883d8305880f12102f2d1
112 2013-01-23 14:28:32 <sipa> what about it?
113 2013-01-23 14:29:04 <Jouke_> well, the 1EMnec address is used as an input aswell as the output
114 2013-01-23 14:29:33 <Jouke_> that address is the one in my wallet
115 2013-01-23 14:29:51 <sipa> then i assume the other address is the change :)
116 2013-01-23 14:30:14 <sipa> judging from the amount, that is even likelier
117 2013-01-23 14:30:22 <CodeShark> I was about to say the same thing
118 2013-01-23 14:30:29 <sipa> so you probably did a send-to-self
119 2013-01-23 14:30:38 <Jouke_> Oh, hmmm
120 2013-01-23 14:30:42 <CodeShark> highly unlikely that you send exactly .0101536 to someone and you get .01 change
121 2013-01-23 14:30:52 <CodeShark> unless you intended it that way
122 2013-01-23 14:31:10 <sipa> CodeShark: idea is: client starts up in headers-only mode (= SPV client), and in the background downloads history for the chain it considers best and validates it
123 2013-01-23 14:31:31 <Jouke_> yes, you are right
124 2013-01-23 14:31:36 <Jouke_> I did indeed
125 2013-01-23 14:31:56 <sipa> CodeShark: so you do have all transactions available (this is independent from pruning, which could still be done after validationg), you just don't validate signatures for a part of the chain that you already know is buried deep
126 2013-01-23 14:32:22 <CodeShark> sipa: I'm thinking that SPV clients' greatest vulnerability is for the most recent blocks
127 2013-01-23 14:32:44 <sipa> sure
128 2013-01-23 14:33:28 <CodeShark> so if you were to download entire blocks and just trust the current state (without validating signatures) and only validated the most recent several blocks, you'd probably be pretty safe
129 2013-01-23 14:33:55 <sipa> which stage are you talking about?
130 2013-01-23 14:34:10 <sipa> the SPV stage, or the upgrade-to-full stage?
131 2013-01-23 14:34:21 <CodeShark> well, I'm thinking there's sort of an in-between stage
132 2013-01-23 14:34:30 <CodeShark> SPV just deals with block headers
133 2013-01-23 14:34:44 <CodeShark> full stage does full signature validation for the entire chain
134 2013-01-23 14:35:25 <CodeShark> if you just download all blocks up until, say, the last ten and don't validate those blocks, you'd still be able to validate the last ten blocks
135 2013-01-23 14:35:46 <TD> good day
136 2013-01-23 14:36:00 <CodeShark> I guess you only need block headers and txouts
137 2013-01-23 14:36:04 <sipa> CodeShark: you'd still need to build the UTXO set resulting from the N-10 first blocks, to be able to validate the last 10
138 2013-01-23 14:36:11 <CodeShark> right
139 2013-01-23 14:36:30 <sipa> and if you build the UTXO set, you're already almost validating everything except scripts
140 2013-01-23 14:36:40 <CodeShark> but isn't the script validation the most expensive part?
141 2013-01-23 14:36:52 <sipa> yes, but right now it's disabled before the last checkpoint
142 2013-01-23 14:37:30 <sipa> if we have headers-first mode, you could change the criterion "before the last checkpoint" to "long enough ago", as you've already validated the headers and know the PoW is valid
143 2013-01-23 14:37:42 <sipa> so you can have the same speedup advantage without needing compiled-in data
144 2013-01-23 14:37:53 <CodeShark> right, I was thinking rather than hardcoding checkpoints, you could just have an automatically sliding one
145 2013-01-23 14:38:04 <sipa> that's basically what this means
146 2013-01-23 14:38:19 <sipa> if you validate headers in advance, you don't need checkpoints to know you're on the right chain
147 2013-01-23 14:38:46 <sipa> gavinandresen: which leveldb17 version did you test?
148 2013-01-23 14:39:29 <gavinandresen> sipa: https://github.com/bitcoin/bitcoin/pull/2198
149 2013-01-23 14:40:26 <sipa> gavinandresen: ok
150 2013-01-23 14:40:33 <gavinandresen> ??? which I'll rebase right now....
151 2013-01-23 14:41:15 <sipa> Luke-Jr: you're running my bitcoin-seeder, right?
152 2013-01-23 14:41:40 <sipa> Luke-Jr: i have a script that combines the output of seeders to produce a seedlist in hex format like the net.cpp needs
153 2013-01-23 14:42:05 <Luke-Jr> sipa: yes
154 2013-01-23 15:08:58 <CodeShark> gavinandresen: I added a configure for bitcoin-qt
155 2013-01-23 15:11:12 <luke-jr_> CodeShark: in case it's helpful, here is my GNUmakefile: http://codepad.org/bwVyLaJs
156 2013-01-23 15:12:09 <gavinandresen> CodeShark: great. When you're done, squash all your commits. if it doesn't get pulled for the 0.8 release, it is likely to get pulled for 0.9
157 2013-01-23 15:13:09 <CodeShark> ok. I'd like to have it tested on a number of different distros and add any extra necessary details.
158 2013-01-23 15:13:16 <MC-Eeepc> configure?
159 2013-01-23 15:14:57 <eckey> ;;bcauth eckey
160 2013-01-23 15:14:58 <gribble> Request successful for user eckey, hostmask eckey!~chatzilla@gateway/tor-sasl/eckey. Your challenge string is: freenode:#bitcoin-otc:5d67fd141caaabcc4f3afe1687cd9a17ebad065d1b85fc0aa614d806
161 2013-01-23 15:15:55 <CodeShark> gavinandresen: we might also want to use the same flag names to set include and library paths for the different makefiles
162 2013-01-23 15:16:04 <sipa> CodeShark: i'd really like to have your refactors that move stuff to core.h/cpp merged quickly after 0.8 final
163 2013-01-23 15:17:30 <sipa> CodeShark: can you turn those in a commit that is strictly move only (so literally cut-pastes from main to core only) ?
164 2013-01-23 15:17:46 <CodeShark> sipa: I can try
165 2013-01-23 15:18:31 <sipa> so the first commit is just moves + an added #include "core.h" in main.h + core.o added to the makefiles
166 2013-01-23 15:18:35 <CodeShark> sipa: it's a little more involved than that, though - since some of the methods of those classes had to be turned into regular functions
167 2013-01-23 15:18:36 <luke-jr_> CodeShark: the existign makefiles already DO use the same config names..
168 2013-01-23 15:19:26 <sipa> CodeShark: you can still those in a move-only way: leave it a method of the original class (which doesn't move), but move the implementation to core.cpp
169 2013-01-23 15:19:47 <sipa> CodeShark: in a second commit you can then turn those into functions, with a definition in core.h
170 2013-01-23 15:19:50 <CodeShark> luke-jr_: there are a few small subtleties - like, for instance, makefile.osx has no option to change the BDB_INCLUDE_PATH
171 2013-01-23 15:20:25 <luke-jr_> CodeShark: doesn't OS X have some magic framework stuff?
172 2013-01-23 15:20:56 <CodeShark> luke-jr_:the include path for bdb is hardcoded into makefile.osx
173 2013-01-23 15:21:15 <luke-jr_> ah
174 2013-01-23 15:21:51 <CodeShark> sipa: so then in a third commit we move those back to main?
175 2013-01-23 15:22:01 <CodeShark> hmm
176 2013-01-23 15:22:10 <CodeShark> the problem is that those functions have dependencies on structures in main
177 2013-01-23 15:22:17 <sipa> CodeShark: oh, if it's things that remain in main, then they remain in main
178 2013-01-23 15:22:26 <CodeShark> and the whole point of this exercise was to remove all core's dependencies from main
179 2013-01-23 15:22:43 <CodeShark> so if they remain in main, we have to pull them out of the class
180 2013-01-23 15:22:51 <sipa> give an example
181 2013-01-23 15:22:52 <CodeShark> which means a little more than just cut/paste
182 2013-01-23 15:23:00 <CodeShark> ok, let me find one
183 2013-01-23 15:23:30 <sipa> here's the idea: every function/method that needs to move from main to core, does so in the very first commit, without any other changes
184 2013-01-23 15:23:56 <sipa> that means that this first commit doesn't help at all to break dependencies (you just get a #include "core.h" in main)
185 2013-01-23 15:24:20 <sipa> but it makes reviewing trivial, as the changes afterwards to do the actual dependency breaking becomes very small
186 2013-01-23 15:24:52 <CodeShark> ok, sipa, example: bool CTransaction::CheckTransaction() const becomes CheckTransaction(const CTransaction& tx)
187 2013-01-23 15:25:16 <CodeShark> https://github.com/bitcoin/bitcoin/pull/2154/files line 529/569 in main.cpp
188 2013-01-23 15:25:36 <sipa> so, no change for that at all in the first commit, as this code doesn't move
189 2013-01-23 15:26:04 <CodeShark> so just include main in core in the first commit?
190 2013-01-23 15:26:11 <CodeShark> and keep that method inside the class?
191 2013-01-23 15:26:14 <sipa> no, include main in core
192 2013-01-23 15:26:18 <sipa> eh
193 2013-01-23 15:26:27 <sipa> #include "core.h" in main.g
194 2013-01-23 15:26:39 <sipa> (just realized the sentence was ambiguous)
195 2013-01-23 15:26:40 <CodeShark> yes, that's what we want
196 2013-01-23 15:26:44 <CodeShark> we do not want the other way around
197 2013-01-23 15:26:59 <sipa> right, but i mean, the first commit doesn't do any dependency breaking
198 2013-01-23 15:27:08 <sipa> so no changing #includes anywhere else
199 2013-01-23 15:27:24 <sipa> it just does the code movement
200 2013-01-23 15:27:44 <CodeShark> I'm still not sure if I'm understanding what you're saying, though - if we just move CTransaction from main to core, it will break these methods that depend on structures declared in main
201 2013-01-23 15:29:09 <sipa> right
202 2013-01-23 15:29:14 <sipa> i was confused
203 2013-01-23 15:29:44 <sipa> so the first commit only changes stuff in .cpp files, i guess
204 2013-01-23 15:29:56 <CodeShark> yeah, I think we need to do the commits in the reverse order
205 2013-01-23 15:30:06 <CodeShark> first move the methods out from the class, then move the class to a new file
206 2013-01-23 15:30:23 <sipa> you can move everything from main.cpp to core.cpp without breaking anything, but core.cpp will indeed do a #include "main.h" then
207 2013-01-23 15:30:31 <CodeShark> right, that's the other alternative
208 2013-01-23 15:30:48 <CodeShark> then move the stuff back to main, then remove the include
209 2013-01-23 15:31:21 <CodeShark> I think I prefer the first way
210 2013-01-23 15:31:48 <sipa> no no, you never move stuff back
211 2013-01-23 15:32:06 <CodeShark> heh, I realize that "first way" is ambiguous
212 2013-01-23 15:32:22 <sipa> you just move all CTransaction methods (except those that become functions in main) to core.cpp
213 2013-01-23 15:32:23 <CodeShark> I mean, we first just edit main.cpp. then we pull stuff out to core
214 2013-01-23 15:32:27 <sipa> in a first step
215 2013-01-23 15:32:42 <CodeShark> ?
216 2013-01-23 15:32:53 <CodeShark> oh...
217 2013-01-23 15:32:53 <sipa> that cannot break anything, right?
218 2013-01-23 15:33:02 <CodeShark> well, I'm thinking now
219 2013-01-23 15:33:07 <CodeShark> there's the header files too
220 2013-01-23 15:33:49 <CodeShark> I have to check whether the class declarations depend on main
221 2013-01-23 15:34:15 <CodeShark> yes, they do
222 2013-01-23 15:35:03 <sipa> ... is there a problem moving the stuff in main.cpp that needs to be in core, to core.cpp in a first step?
223 2013-01-23 15:35:25 <sipa> without any touching of those methods/functions, and without any changes to header files
224 2013-01-23 15:35:36 <CodeShark> you mean without creating a core.h?
225 2013-01-23 15:35:39 <sipa> yes
226 2013-01-23 15:36:04 <CodeShark> no, I suppose if we leave the class declarations in main.h it won't break anything
227 2013-01-23 15:37:10 <sipa> then in a second commit, turn methods in main.cpp into functions that remain in main.cpp
228 2013-01-23 15:37:28 <sipa> then in a third commit, add core.h and include core.h in main.h, and move the classes to core.h
229 2013-01-23 15:37:37 <CodeShark> that's doable, I suppose
230 2013-01-23 15:37:40 <sipa> and in a fourth commit, break the dependencies
231 2013-01-23 15:38:13 <sipa> so the first and third commit are move-only
232 2013-01-23 15:39:02 <CodeShark> right, and the second is just pattern replacements, really
233 2013-01-23 15:39:24 <sipa> exactly
234 2013-01-23 15:39:54 <CodeShark> yeah, it makes sense to separate these two types of commits
235 2013-01-23 15:40:03 <CodeShark> easier to check for correctnes
236 2013-01-23 15:40:07 <CodeShark> *correctness
237 2013-01-23 15:40:55 <CodeShark> well, the second might need to be broken up into two parts
238 2013-01-23 15:41:02 <BlueMatt> in rpc methods table, safemd is...what?
239 2013-01-23 15:41:55 <CodeShark> sipa: consider the AllowFree method in CTransaction
240 2013-01-23 15:42:07 <CodeShark> it's implemented in main.h
241 2013-01-23 15:42:16 <CodeShark> but it needs to be moved out of the class
242 2013-01-23 15:42:34 <sipa> BlueMatt: allowed in safe mode
243 2013-01-23 15:42:43 <BlueMatt> ahh, thanks
244 2013-01-23 15:42:43 <CodeShark> which means it needs to be moved to main.cpp, then it needs to be turned into a regular function
245 2013-01-23 15:43:55 <CodeShark> actually, it needs to be gotten rid of altogether :)
246 2013-01-23 15:44:03 <sipa> CodeShark: that's a separate issue
247 2013-01-23 15:44:10 <CodeShark> no...it needs to be moved to main.h as a regular function
248 2013-01-23 15:44:24 <sipa> CodeShark: so, do that in the second commit?
249 2013-01-23 15:45:06 <CodeShark> I'm thinking it could be done in two commits - one that moves the implementation to outside the class declaration (still in main.h), the second that turns it into a regular function
250 2013-01-23 15:45:23 <CodeShark> so we keep the moves and pattern replacement commits separate
251 2013-01-23 15:46:28 <CodeShark> the move will not require any modifications in main.cpp
252 2013-01-23 15:46:37 <CodeShark> but the pattern replacement will
253 2013-01-23 15:48:41 <CodeShark> so four stages: 1) move core methods out of main.cpp and into core.cpp. 2) move implementations that should not be part of core classes out of their declarations and into either main.h or main.cpp. 3) turn these methods into regular functions and get rid of the method prototypes in the classes. 4) move the class declarations to core.h
254 2013-01-23 15:52:03 <xyyyz> The_Hidden_History_of_Money_and_Feudal_Order_Usury_Secrets.pdf\t29.265 MB http://host01.fileconvoy.com/gf.php?id=g5871bb622c940e7e999205310.210243c2e012ac872e8d5b&sts=1358959823592447f484e4902dec5e12dd40be8c6b
255 2013-01-23 15:52:31 <CodeShark> actually, for (2), into main.h only
256 2013-01-23 15:52:39 <CodeShark> as an example, the AllowFree method
257 2013-01-23 15:53:50 <CodeShark> so (1) only moves stuff out of main.cpp and into core.cpp. (2) only moves stuff within main.h. (3) only does pattern replacement in main.h and main.cpp. (4) only moves stuff from main.h to core.h.
258 2013-01-23 15:54:36 <BlueMatt> Im gonna rebase #1549 (addnode rpc stuff) if anyone is interested in it for 0.8?
259 2013-01-23 15:55:11 <Luke-Jr> BlueMatt++
260 2013-01-23 15:57:36 <Jouke_> I have a bitcoinaddress, the corresponding private key, and all the transactions that are relevant to the address. Do I need to get the scriptPubKey to create a raw transaction?
261 2013-01-23 15:59:00 <CodeShark> Jouke_: for standard transactions, scriptPubKey is just OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
262 2013-01-23 15:59:20 <CodeShark> the pubKeyHash can be computed from the bitcoin address
263 2013-01-23 16:00:14 <CodeShark> specifically, pubKeyHash is just the decoded value of the base58check encoding
264 2013-01-23 16:00:14 <Jouke_> I am trying to use this simplified example: https://bitcointalk.org/index.php?topic=101525.0
265 2013-01-23 16:00:30 <gavinandresen> BlueMatt: I like the add node stuff, if you can get a test plan written and executed by somebody other than yourself then I think it could sneak into 0.8
266 2013-01-23 16:00:57 <Jouke_> CodeShark: does the createrawtransction do that for me?
267 2013-01-23 16:01:08 <CodeShark> Jouke_: yes
268 2013-01-23 16:01:35 <Jouke_> Ok, that makes life easier :0
269 2013-01-23 16:01:37 <Jouke_> :)
270 2013-01-23 16:02:04 <Jouke_> I was reading gmaxwell's signdemo and it confused me a bit.
271 2013-01-23 16:02:16 <CodeShark> gavinandresen: what's the release timeframe for 0.8?
272 2013-01-23 16:02:58 <gavinandresen> I'm thinking release candidate 1???. friday or saturday or sunday or monday.
273 2013-01-23 16:03:38 <gavinandresen> then it depends on how testing goes. If all goes well, no major bugs, then release candidate 1 could be the final 0.8.0 release in a couple weeks.
274 2013-01-23 16:05:50 <BlueMatt> gavinandresen: you say that every time, but rc1 is NEVER final....
275 2013-01-23 16:06:07 <gavinandresen> never say never....
276 2013-01-23 16:06:11 <BlueMatt> well, ok
277 2013-01-23 16:06:50 <gavinandresen> but yeah, I'd put the chances that rc1 is the last rc at??? oh, 10%
278 2013-01-23 16:07:02 <BlueMatt> seems generous, but...sure
279 2013-01-23 16:07:34 <TD> hey there
280 2013-01-23 16:07:41 <BlueMatt> hi TD
281 2013-01-23 16:07:41 <gavinandresen> ho there
282 2013-01-23 16:08:34 <gavinandresen> TD: where we at on full disclosure of the 0-confirmation issue? are bitcoinj patches available to people who need them?
283 2013-01-23 16:10:06 <TD> they're on a branch. i asked for a review a couple of days ago, i think the review will be wrapped up by EOD today or tomorrow CET
284 2013-01-23 16:10:29 <gavinandresen> TD: good, that meshes with the 0.8rc release schedule
285 2013-01-23 16:10:30 <TD> unless anyone spots any major issues i'll merge into master. unfortunately most wallet apps won't release them until i release a new stable bitcoinj
286 2013-01-23 16:10:35 <TD> but i'm hoping that'll be RSN
287 2013-01-23 16:10:54 <TD> my only remaining tasks are to merge bloom filtering, which is nearly there, and allow spending of unconfirmed change.
288 2013-01-23 16:11:00 <TD> after that it's RC time.
289 2013-01-23 16:11:07 <TD> gavinandresen: what about for the C++ side?
290 2013-01-23 16:11:30 <CodeShark> sipa: I added a note to the pull request discussion so we don't forget :)
291 2013-01-23 16:11:38 <BlueMatt> TD: and I need to fix the new coinbase parsing bug
292 2013-01-23 16:12:13 <eckey> FYI, I'm wondering if gribble fell over because I used quote marks in a PM...
293 2013-01-23 16:13:46 <TD> BlueMatt: sure, though i don't want to hold 0.7 for full-verification bugs because there are a ton of improvements that will benefit SPV users.
294 2013-01-23 16:13:52 <TD> but if it's a matter of a few days, ok
295 2013-01-23 16:14:40 <BlueMatt> TD: yea, Im working on getting a test plan written for bitcoind #1549 now, then its on to bitcoinj...hopefully the bloom/full verif stuff can all be wrapped up in the coming day or two
296 2013-01-23 16:15:24 <TD> superb
297 2013-01-23 16:15:39 <BlueMatt> s/day/days/
298 2013-01-23 16:15:45 <TD> sure
299 2013-01-23 16:16:40 <BlueMatt> s/days/day/ arg, I need to stop trying to correct grammar when I just read two words...
300 2013-01-23 16:19:46 <CodeShark> would it be possible to get pull request 2187 included in 0.8?
301 2013-01-23 16:25:10 <BlueMatt> Luke-Jr: mind running the test plan I just posted on #1549?
302 2013-01-23 16:25:57 <BlueMatt> shouldnt take more than a few minutes if you have a dns name with TTL of like 1 and modify the Sleeps in ThreadOpenAddedConnections to make them like 1 second
303 2013-01-23 16:26:50 <CodeShark> sipa: thank you :)
304 2013-01-23 16:46:00 <tealcavalon> hi there...
305 2013-01-23 16:46:48 <tealcavalon> so is there anyone here that can tell me how the hell do I install a mining software in CENTOS 6?
306 2013-01-23 17:03:02 <muhoo> hmm, this says keys are 25 bytes, but i've never seen an address less than 34 chars http://rosettacode.org/wiki/Bitcoin/address_validation
307 2013-01-23 17:03:27 <gmaxwell> What says?
308 2013-01-23 17:03:36 <muhoo> the ripemd looks like it's 20 bytes, which makes sense, plus the 4 byte checksum and the 1-byte header. but what's with those extra chars?
309 2013-01-23 17:03:53 <muhoo> "a bitcoin address encodes 25 bytes"
310 2013-01-23 17:04:00 <gmaxwell> muhoo: Thats correct.
311 2013-01-23 17:04:08 <gmaxwell> _encodes_ 25 bytes into base 58.
312 2013-01-23 17:04:22 <gmaxwell> which results in more characters since 58<256.
313 2013-01-23 17:05:12 <muhoo> ok, then i need to stare at those code samples some more.
314 2013-01-23 17:06:33 <CodeShark> addresses can have fewer than 34 chars
315 2013-01-23 17:07:04 <CodeShark> look at the base58check encoding of the all zero pubkeyhash
316 2013-01-23 17:08:36 <CodeShark> https://bitcointools.appspot.com/?t=0000000000000000000000000000000000000000&f=hex
317 2013-01-23 17:11:11 <CodeShark> the version 0 base58check (bitcoin address) is only 27 characters long
318 2013-01-23 17:12:03 <CodeShark> technically speaking, a bitcoin address encodes 21 bytes since the last four are just a checksum
319 2013-01-23 17:12:21 <CodeShark> and the first byte is just a version byte - so in the end it really represents a 20 byte number
320 2013-01-23 17:12:26 <muhoo> and it seems to be encoding 0's as 1's too.
321 2013-01-23 17:12:45 <CodeShark> yes, indeed - 1 in base58 represents 0
322 2013-01-23 17:12:50 <muhoo> starting to make sense. i'm new to crypto so i apologize for the stupid questions.
323 2013-01-23 17:13:09 <CodeShark> base58 encoding doesn't use the symbol 0 to avoid confusion with the letter O
324 2013-01-23 17:14:03 <muhoo> aha, i see, it's an index in a table, "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz"
325 2013-01-23 17:15:20 <CodeShark> http://blockchain.info/address/1111111111111111111114oLvT2
326 2013-01-23 17:15:21 <CodeShark> :)
327 2013-01-23 17:16:05 <muhoo> what? you just used it?
328 2013-01-23 17:16:18 <muhoo> oh, someone did in november. bizarre.
329 2013-01-23 17:16:46 <CodeShark> yes - several of us have created such transactions to play around with bitcoin data structures :)
330 2013-01-23 17:17:07 <muhoo> like having a phonenumber of 555-555-5555
331 2013-01-23 17:17:24 <upb> base58 is pretty strong crypto
332 2013-01-23 17:17:27 <CodeShark> now finding a public key that hashes to all zeros is a serious challenge :)
333 2013-01-23 17:17:48 <CodeShark> and finding a private key that has a public key that hashes to all zeros is even a greater challenge :)
334 2013-01-23 17:17:53 <upb> in fact, the whole integrity of the bitcoin blockchain is based on the preimage resistiveness of base58
335 2013-01-23 17:18:15 <CodeShark> actually, bitcoin's security has nothing to do with base58
336 2013-01-23 17:18:27 <CodeShark> base58check is merely a convenience for human users to avoid typographical errors
337 2013-01-23 17:18:37 <CodeShark> internally, bitcoin doesn't use base58check at all
338 2013-01-23 17:18:58 <upb> you couldnt be more wrong
339 2013-01-23 17:19:04 <CodeShark> I should say typographical/copy-paste errors
340 2013-01-23 17:19:20 <CodeShark> the block chain's data structures have nothing to do with base58 encoding
341 2013-01-23 17:19:48 <muhoo> ripemd, looks like, under the hood
342 2013-01-23 17:20:03 <upb> sure they do, the base58 stream cipher is an integral part of the bitcoin integrity puzzle
343 2013-01-23 17:20:04 <CodeShark> yes, it's ripemd160 and sha256
344 2013-01-23 17:20:13 <CodeShark> and internally it's all binary
345 2013-01-23 17:20:18 <CodeShark> no base58
346 2013-01-23 17:20:22 <gavinandresen> upb stop trolling please
347 2013-01-23 17:21:25 <muhoo> don't worry, his attempted brain-cache-poisoning attack on me is failing.
348 2013-01-23 17:23:52 <sipa> CodeShark: actually, finding a pubkey that hashes to 160 zero bits is harder than finding a private key that matches a given pubkey :)
349 2013-01-23 17:24:05 <CodeShark> yes, I was going to say, sipa :)
350 2013-01-23 17:24:20 <CodeShark> true
351 2013-01-23 17:25:11 <CodeShark> not even a quantum computer would help much
352 2013-01-23 17:25:26 <upb> even with rainbow tables and DHT?
353 2013-01-23 17:27:03 <sipa> updrainbow tables do not speed up anything
354 2013-01-23 17:27:25 <sipa> they're just a compact way of storing a precomputed inversion table
355 2013-01-23 17:27:28 <gavinandresen> he's still trolling???. I can tell by the "DHT"
356 2013-01-23 17:27:37 <CodeShark> lol - totally incoherent technobabble
357 2013-01-23 17:29:11 <gavinandresen> ACTION thinks he'll have make a Quantum Rainbow DHT pull request on April 1....
358 2013-01-23 17:29:17 <CodeShark> lol
359 2013-01-23 17:30:35 <sipa> gavinandresen: also announce we're switching to triple XOR for wallet encryption
360 2013-01-23 17:31:24 <gavinandresen> "Eleventy-hundred times faster than AES!"
361 2013-01-23 17:32:25 <sipa> which means OVER 9000 times faster
362 2013-01-23 17:32:40 <sipa> oh, no
363 2013-01-23 17:32:44 <sipa> math fail
364 2013-01-23 17:32:48 <Luke-Jr> sipa: we can optimize triple XOR into a single XOR!
365 2013-01-23 17:32:56 <upb> why not switch to RMX?
366 2013-01-23 17:32:57 <kinlo> mmmz
367 2013-01-23 17:32:57 <upb> http://lesantint.com/leng/rmx_system.html
368 2013-01-23 17:33:07 <kinlo> guys use decent encryption please
369 2013-01-23 17:33:14 <kinlo> triple hilights me :p
370 2013-01-23 17:33:18 <upb> https://pbs.twimg.com/media/BBESuMICYAAvNn9.jpg:large
371 2013-01-23 17:33:24 <kinlo> use aes or something, don't have a hilight on that :p
372 2013-01-23 17:33:42 <Diablo-D3> gavinandresen, sipa: explain to me why aes256 is less secure than aes128
373 2013-01-23 17:33:48 <Diablo-D3> gmaxwell too
374 2013-01-23 17:33:50 <Luke-Jr> AFAIK, XOR isn't a bad idea in theory, but doing it right is probably less efficient than AES <.<
375 2013-01-23 17:33:53 <BlueMatt> kinlo: like triple rot13?
376 2013-01-23 17:34:11 <gmaxwell> Diablo-D3: You've mistaken us for Wikipedia, I fear.
377 2013-01-23 17:34:14 <kinlo> BlueMatt: exactly :p
378 2013-01-23 17:34:22 <Diablo-D3> wikipedia doesnt seem to cover it
379 2013-01-23 17:34:33 <gmaxwell> It does, in fact.
380 2013-01-23 17:34:44 <midnightmagic> Diablo-D3: There's an attack which works against aes-256 but not aes-128, which reduces the complexity of the attack on aes-256 to less than the complexity of a brute-force on aes-128
381 2013-01-23 17:35:03 <Diablo-D3> midnightmagic: ... that sucks
382 2013-01-23 17:35:11 <kinlo> Diablo-D3: it is on the wikipedia page
383 2013-01-23 17:35:13 <gmaxwell> The attack is still to complex to actually worry about- its a certificational weakness.
384 2013-01-23 17:35:25 <gmaxwell> s/to complex/too complex/
385 2013-01-23 17:35:30 <Diablo-D3> kinlo: wasnt last time I checked
386 2013-01-23 17:35:31 <kinlo> look for known attacks
387 2013-01-23 17:35:37 <kinlo> Diablo-D3: then check again...
388 2013-01-23 17:35:43 <midnightmagic> Diablo-D3: It's still basically pointless to make the attempt; the attack is theoretical. It's still so hard that nobody would ever solve it. Point is the attack exists, and attacks often gain momentum. IMO.
389 2013-01-23 17:35:54 <kinlo> look for Alex Biryukov
390 2013-01-23 17:35:56 <sipa> upb: sounds really unbreakable indeed!
391 2013-01-23 17:35:59 <Diablo-D3> so whats an alternative to AES?
392 2013-01-23 17:36:12 <midnightmagic> Diablo-D3: IDEA?
393 2013-01-23 17:36:15 <midnightmagic> ACTION ducks.
394 2013-01-23 17:36:15 <sipa> upb: thank god the chip cannot be reverse engineered
395 2013-01-23 17:36:24 <gmaxwell> Diablo-D3: any of the AES finalists- though they aren't quite as well analyized as AES anymore.
396 2013-01-23 17:36:25 <Diablo-D3> midnightmagic: ...
397 2013-01-23 17:37:14 <kinlo> I'd stick to aes until the others have been properly investigated
398 2013-01-23 17:37:28 <Diablo-D3> yeah, but using aes128 over aes256 doesnt seem like a valid solution
399 2013-01-23 17:38:17 <gmaxwell> kinlo: at the time AES was selected they were equal to (or sometimes a bit more or less) AES in terms of analysis... but since then AES is much more interesting to attack for obvious reasons. There will be no 'until'.
400 2013-01-23 17:42:12 <Diablo-D3> so what stops me from mashing together multiple AES finalists?
401 2013-01-23 17:42:53 <gmaxwell> nothing... just don't use related keys
402 2013-01-23 17:43:47 <Diablo-D3> what about key chaining, and the key output chooses the next algo
403 2013-01-23 17:44:26 <gmaxwell> being excessively clever is often a good way to add weaknesses.
404 2013-01-23 17:44:38 <Diablo-D3> well, that doesnt work anyhow
405 2013-01-23 17:44:47 <Diablo-D3> if any of the algos are busted, it busts those blocks and all blocks that follow them
406 2013-01-23 17:44:54 <gavinandresen> you're worried about the security of AES256???
407 2013-01-23 17:45:04 <Diablo-D3> gavinandresen: vaguely
408 2013-01-23 17:45:06 <gavinandresen> See: https://cryptolux.org/FAQ_on_the_attacks
409 2013-01-23 17:45:13 <Diablo-D3> theoretical attacks often turn into real attacks
410 2013-01-23 17:45:21 <CodeShark> there's a lot to be said for keeping the algos simple
411 2013-01-23 17:45:23 <Diablo-D3> I dont panic like the slashdot crowd does though
412 2013-01-23 17:45:38 <gavinandresen> "often" or "sometimes" ? I'm not a cryptographer, I don't actually know???.
413 2013-01-23 17:45:50 <Diablo-D3> gavinandresen: as in "more than once"
414 2013-01-23 17:46:00 <Diablo-D3> it only needs to happen once to ruin your day
415 2013-01-23 17:46:29 <gavinandresen> sure, but you have to take into the possibility that it is likely to ruin somebody else's day first, giving you a chance to react....
416 2013-01-23 17:46:36 <CodeShark> I don't think right now the greatest security weaknesses in our networks is in the crypto ciphers themselves
417 2013-01-23 17:47:03 <Diablo-D3> CodeShark: yes, but key generation is largely a solved problem
418 2013-01-23 17:47:29 <Diablo-D3> million round pbkdf2 sha512 is still pretty lethal to brute force
419 2013-01-23 17:47:31 <CodeShark> Diablo-D3: what do you
420 2013-01-23 17:47:31 <gmaxwell> Diablo-D3: you meant something different from 'mashing together' than I thought you did.
421 2013-01-23 17:47:39 <CodeShark> mean by "solved problem"?
422 2013-01-23 17:47:50 <Diablo-D3> gmaxwell: well, theres lots of ways of plugging them in
423 2013-01-23 17:47:56 <Diablo-D3> CodeShark: I just said
424 2013-01-23 17:47:56 <gmaxwell> Diablo-D3: I thought you means AES(k1,serpent(k2,data))
425 2013-01-23 17:48:33 <gmaxwell> s/means/meant/
426 2013-01-23 17:48:34 <Diablo-D3> gmaxwell: thats probably what I should have gone with
427 2013-01-23 17:48:46 <Diablo-D3> gmaxwell: I went with excessively clever instead. oops.
428 2013-01-23 17:49:10 <Diablo-D3> theres probably a way to wind them that works
429 2013-01-23 17:50:00 <CodeShark> is it possible to mathematically prove that chaining with unrelated keys is no weaker than each cipher individually?
430 2013-01-23 17:50:19 <Diablo-D3> CodeShark: yes
431 2013-01-23 17:50:23 <Diablo-D3> you still need the other keys
432 2013-01-23 17:51:00 <CodeShark> so weaknesses could still be introduced in the implementation, I suppose
433 2013-01-23 17:51:14 <CodeShark> if you're not careful
434 2013-01-23 17:51:19 <Diablo-D3> imagine a door with multiple locks, and you need all the keys
435 2013-01-23 17:51:26 <Diablo-D3> opening a lock for free doesnt open the rest
436 2013-01-23 17:51:33 <CodeShark> right, but weaknesses in the implementation can lead to timing attacks or other such things
437 2013-01-23 17:51:46 <Diablo-D3> yes, but thats a larger general issue thats impl specific
438 2013-01-23 17:51:52 <Diablo-D3> and thats not always a useful attack
439 2013-01-23 17:51:56 <gmaxwell> CodeShark: it's easy to be no stronger than the worst though, at least under some attack models. (e.g. a meet in the middle if you have known plaintext)
440 2013-01-23 17:51:57 <Diablo-D3> such as offline file storage
441 2013-01-23 17:52:10 <muhoo> funny, he did force a long debate about encryption algorithms, looks like
442 2013-01-23 17:52:28 <Diablo-D3> gmaxwell: yes, which is why I mentioned key generation being a solved problem
443 2013-01-23 17:53:33 <CodeShark> my point is just that when you add complexity to your implementation it also gives you a chance to introduce implementation-specific weaknesses
444 2013-01-23 17:53:44 <CodeShark> even if the cipher itself is theoretically sound
445 2013-01-23 17:54:36 <Diablo-D3> CodeShark: yes/no
446 2013-01-23 17:54:46 <Diablo-D3> what gmaxwell did adds no complexity
447 2013-01-23 17:54:55 <CodeShark> you mean just simple chaining?
448 2013-01-23 17:55:03 <CodeShark> yeah, I suppose so
449 2013-01-23 17:55:20 <Diablo-D3> [01:48:15] <gmaxwell> Diablo-D3: I thought you means AES(k1,serpent(k2,data))
450 2013-01-23 17:55:23 <gmaxwell> everything adds complexity.
451 2013-01-23 17:56:08 <CodeShark> it adds a very small amount of complexity
452 2013-01-23 18:00:29 <wizkid057> Diablo-D3: should just use a DHT
453 2013-01-23 18:00:39 <CodeShark> lol
454 2013-01-23 18:11:41 <Diablo-D3> okay so
455 2013-01-23 18:11:43 <Diablo-D3> the AES attack
456 2013-01-23 18:11:53 <sipa> gavinandresen: cool, how did you import those upstream leveldb changes into your branch?
457 2013-01-23 18:12:06 <Diablo-D3> does this assume 256 bit keys?
458 2013-01-23 18:12:20 <gavinandresen> git format-patch from a git clone of the leveldb repo, then a git am
459 2013-01-23 18:12:50 <gavinandresen> git am --directory=src/leveldb to be specific to remap the paths. worked very nicely
460 2013-01-23 18:13:59 <gavinandresen> sipa: I'm compiling git HEAD on my 32-bit mac, I'll try a 2+gigabyte import and see what happens. I believe it should Just Work.
461 2013-01-23 18:24:12 <midnightmagic> Diablo-D3: You might want to look at the 100-year-cryptography project that zooko et al were looking at. They were talking about strong hashes and strong cryptography based on composable cryptographic algos..
462 2013-01-23 18:36:25 <midnightmagic> speaking of key generation, does anybody know anything about intel's old 82802 fwh random number generator? has there been any new information about whether the old ones have been analyzed and maybe found lacking?
463 2013-01-23 18:38:08 <CodeShark> are those the ones that use two oscillators, one modulated by a thermistor?
464 2013-01-23 18:38:38 <CodeShark> I guess I could look it up but I'm too lazy :p
465 2013-01-23 18:39:01 <midnightmagic> correct.
466 2013-01-23 18:40:36 <midnightmagic> and then fed through a von neuman filter
467 2013-01-23 18:40:51 <BlueMatt> TD: have you reproduced the coinbase parse fail in bitcoinj? I dont see how getSigOpCount could have thrown anything and I cant reproduce
468 2013-01-23 18:41:31 <TD> i haven't tried
469 2013-01-23 18:46:14 <gavinandresen> anybody know off the top of their heads about which block number blk0001.dat rolled into blk0002.dat ?
470 2013-01-23 18:46:14 <midnightmagic> Could I make a suggestion? Could you guys (the devs) create a key bundle and communally sign it with your gpg keys?
471 2013-01-23 18:46:51 <midnightmagic> or maybe just all sign each others' keys?
472 2013-01-23 18:46:53 <gmaxwell> gavinandresen: its wildly different for different people due to orphans, though I assume you mean in a compacted copy?
473 2013-01-23 18:47:48 <gavinandresen> gmaxwell: sure, I just need an "at about block 111,000" estimate
474 2013-01-23 18:50:27 <midnightmagic> For the individual PGP keys on bitcoin.org, you all don't appear to have signed each others' keys, so even though I'm fairly certain my copy of gmaxwell's key is accurate, he hasn't warranted that the rest of your keys are, so I can't triangulate naughtiness.
475 2013-01-23 18:53:30 <gavinandresen> midnightmagic: https://github.com/bitcoin/bitcoin.org has copies of our keys, and the nature of git means you can be pretty sure they haven't been tampered with
476 2013-01-23 18:55:57 <midnightmagic> gavinandresen: The gpg WoT is still helpful when using keyservers. Have you guys started fully signing commit pushes now?
477 2013-01-23 18:57:18 <gavinandresen> midnightmagic: i have no idea what "fully signing commit pushes" means. If it means digging out my private key on every push, that sounds like a bad idea.
478 2013-01-23 18:59:41 <midnightmagic> gavinandresen: The Linux kernel devs do it to help audit the origin of code commits. Actual origin signed keys aren't necessary for this; a code-signing key can just be signed by your main key (or repudiated in the event you think it was compromised).
479 2013-01-23 19:01:20 <gavinandresen> midnightmagic: okey dokey. We're using github accounts instead; if we start getting lots of patches from non-github-account-people then I suppose that would make sense.
480 2013-01-23 19:02:10 <gmaxwell> midnightmagic: I will not sign keys for people whos identity I haven't verified in person. Key hygiene in this community is terrible. We're also single threaded for security through github in any case. Persumably one sneaky addition to the repository can steal all our keys.
481 2013-01-23 19:04:05 <midnightmagic> gmaxwell: What's the difference between seeing some random douche presenting you with a "midnight magic" key and you just verifying that the person you are communicating with has been 100% consistently able to prove he is the owner of the key he's using on-demand?
482 2013-01-23 19:04:15 <midnightmagic> gmaxwell: Oh.. you verify the name too using ID?
483 2013-01-23 19:04:44 <gmaxwell> midnightmagic: Yes.
484 2013-01-23 19:05:04 <gmaxwell> And the email address by mailing back the signature instead of pushing it myself.
485 2013-01-23 19:05:36 <Jouke_> With sendrawtransaction I got an error: {"code":-22,"message":"TX rejected"}. What does that mean?
486 2013-01-23 19:06:02 <gmaxwell> Jouke_: see your debug.log, there is usually more information.
487 2013-01-23 19:06:03 <midnightmagic> So.. would you sign my email-less key if you met me in person and I showed you ID?
488 2013-01-23 19:06:10 <gmaxwell> Most common case is you didn't meet the fee rules for relay.
489 2013-01-23 19:06:55 <midnightmagic> or rather.. *have* you ever signed anyone's key?
490 2013-01-23 19:07:01 <gmaxwell> midnightmagic: Sure. I don't care to validate something that isn't there- "nameless" is harder. What is the point of my signature if I validated _nothing_? You might as well use a timestamping service to show a key is old.
491 2013-01-23 19:07:21 <gmaxwell> midnightmagic: you could easily answer that question yourself. :P
492 2013-01-23 19:07:32 <gmaxwell> (yes, dozens of them)
493 2013-01-23 19:07:48 <gavinandresen> sendrawtransaction should be more specific in it's rejected reason, it'd be nice to know if it is rejected for fees or because it is non-standard or because signatures are invalid or some other reason
494 2013-01-23 19:09:53 <Jouke_> gmaxwell: I can't see anything in debug.log
495 2013-01-23 19:09:59 <midnightmagic> And here's an irritating WoT problem again, this time warranting trust.
496 2013-01-23 19:10:41 <gmaxwell> Jouke_: tail the log and try again- you might just be missing it. (though there may be reject reasons that don't get logged, I do know that fees get logged at least when debug is st)
497 2013-01-23 19:10:46 <gmaxwell> s/st/set/
498 2013-01-23 19:10:47 <midnightmagic> gmaxwell: How would you evaluate your trust of the other developers and their keys then?
499 2013-01-23 19:10:58 <lianj> Jouke_: might pasting the tx?
500 2013-01-23 19:11:02 <lianj> *mind
501 2013-01-23 19:11:20 <midnightmagic> gmaxwell: Like, by the same notion, there's no real way for you to know gavin is gavin, and yet you work with him in a way that could significantly impact your finances.\\
502 2013-01-23 19:11:37 <midnightmagic> well "him" anyway.
503 2013-01-23 19:12:10 <gavinandresen> code review is where most of our security comes from
504 2013-01-23 19:12:20 <gavinandresen> ??? not blind trust that we won't screw up
505 2013-01-23 19:12:24 <Jouke_> lianj: it is quite large
506 2013-01-23 19:12:29 <gmaxwell> midnightmagic: I don't care that much if gavin is "gavin" but there is a convention in PGP keys, and no way to express that you didn't validate anything.
507 2013-01-23 19:12:57 <lianj> Jouke_: the hex of the tx is large? put in on some pastesite
508 2013-01-23 19:13:06 <gmaxwell> and as gavinandresen says... Trust really doesn't matter _that_ much, because mistakes are such an issue even when people are honest.
509 2013-01-23 19:13:09 <midnightmagic> gavinandresen: I'm thinking of the untrustworthy github scenario where they feed everyone but you guys different data.
510 2013-01-23 19:13:33 <gmaxwell> midnightmagic: if github is evil they stuff in a commit that adjusts the makefile to steal our gpg keys.
511 2013-01-23 19:13:35 <midnightmagic> or.. more narrowly, feed me different data than anyone else, were I a paranoid git.
512 2013-01-23 19:14:16 <midnightmagic> gmaxwell: Which ideally would trigger a repudiation of code-signing keys when you notice.
513 2013-01-23 19:14:25 <gmaxwell> And unfortunately since we use the github merges, even if all the commits were signed that wouldn't really help you- since a github merge could insert malicious stuff for you.
514 2013-01-23 19:14:35 <Jouke_> lianj: should I post the signed tx?
515 2013-01-23 19:14:44 <gmaxwell> midnightmagic: if we even notice- of course once we've run the payload it could become invisible on our systems.
516 2013-01-23 19:15:04 <lianj> Jouke_: if you dont manage to read the reason in the detail logs
517 2013-01-23 19:15:10 <gmaxwell> I suppose it would be noticed eventually.. might be a while.
518 2013-01-23 19:15:10 <lianj> s/detail/debug/
519 2013-01-23 19:15:54 <midnightmagic> gmaxwell: The github merges are different than normal git merges?
520 2013-01-23 19:16:17 <gmaxwell> midnightmagic: they're authored by github, so even if we're signing our commits they wouldn't be signed.
521 2013-01-23 19:16:21 <Jouke_> Yeah I was overlooking it in the detail log
522 2013-01-23 19:16:23 <gmaxwell> And the repository is full of them.
523 2013-01-23 19:16:24 <Jouke_> ERROR: ConnectInputs() : 6c19611eb2 prev tx already used at (nFile=1, nBlockPos=1191915617, nTxPos=1192033414)
524 2013-01-23 19:16:24 <Jouke_> ThreadRPCServer method=sendrawtransaction
525 2013-01-23 19:16:33 <gmaxwell> Jouke_: there ya go.
526 2013-01-23 19:17:10 <midnightmagic> O.O
527 2013-01-23 19:17:46 <midnightmagic> I must be missing something. Can you tell me what's the purpose of that?
528 2013-01-23 19:18:00 <Jouke_> So I did use an allready spent transaction.
529 2013-01-23 19:18:03 <midnightmagic> ACTION 's google-fu sometimes fails.
530 2013-01-23 19:18:40 <gmaxwell> midnightmagic: purpose of what?
531 2013-01-23 19:19:50 <midnightmagic> gmaxwell: I thought merges are submitted by humans and pushed. I guess I'm ignorant of why github is authoring commits.
532 2013-01-23 19:21:15 <gmaxwell> people issue pull requests on the github site. There is a little merge button that does something analogous to git am -3 on the pull request (but with much more powerful conflict resolution than anything in the open source git software).
533 2013-01-23 19:22:58 <midnightmagic> aaargh
534 2013-01-23 19:27:58 <midnightmagic> I guess the additional step of committing and signing the patch is an onerous pita.
535 2013-01-23 19:28:10 <midnightmagic> f'in github. :(
536 2013-01-23 19:29:28 <midnightmagic> well.. at least, the next time you guys meet in person, please consider doing some keysigning. :-)
537 2013-01-23 19:49:29 <muhoo> so what is the current best-practices way in bitcoinj to connect wallet to peergroup? is it PeerGroup.addWallet() ? or PeerGroup.addEventListener(Wallet.getPeerEventListener())?
538 2013-01-23 19:49:37 <TD> addwallet
539 2013-01-23 19:49:40 <TD> (on head)
540 2013-01-23 19:49:43 <muhoo> thx
541 2013-01-23 19:49:45 <TD> always use the most specific
542 2013-01-23 19:50:36 <muhoo> in my testing so far, doing that doesn't actually make new transactions show up in the wallet, though they definitely show up in .isRelevantTransaction
543 2013-01-23 19:51:32 <muhoo> wallet says "0 pending transactions" . but if i manually add it with commitTx, it works
544 2013-01-23 19:55:48 <CodeShark> gavinandresen: I would also like pull request 2209 merged with master before 0.8 if possible
545 2013-01-23 19:56:54 <muhoo> and PeerGroup.getPeerEventListener() clearly shows the wallet is there
546 2013-01-23 19:57:09 <gavinandresen> CodeShark: not going to happen, will have to wait (too much risk, zero reward)
547 2013-01-23 19:57:24 <CodeShark> it's very simple to confirm its correctness
548 2013-01-23 19:58:23 <CodeShark> I'm trying to make these pull requests as minimal as possible so it's super simple to verify they don't break anything
549 2013-01-23 19:58:31 <gavinandresen> you need to argue the 'zero reward' part if you want to budge me
550 2013-01-23 19:58:49 <CodeShark> it will make merges much simpler later on :)
551 2013-01-23 19:58:50 <gavinandresen> ??? and please don't bother
552 2013-01-23 19:59:02 <CodeShark> we'll need to add this at some point
553 2013-01-23 19:59:02 <gmaxwell> gavinandresen: Have I been rubbing off on you?
554 2013-01-23 19:59:18 <CodeShark> one could argue that not having the locks is a bug
555 2013-01-23 19:59:19 <gavinandresen> gmaxwell: yes, probably!
556 2013-01-23 19:59:32 <CodeShark> even though the feature is not being used, something will break at some point if it isn't fixed
557 2013-01-23 19:59:45 <gavinandresen> ACTION puts his fingers in his ears and goes nanananananananana
558 2013-01-23 19:59:49 <CodeShark> lol
559 2013-01-23 20:00:00 <gmaxwell> CodeShark: 0.8 is kind of overfull overscarry already. I'd much rather work to make sure it can go in the next release than try to get it into 0.8. I can see lots of reasons to regret 0.8 and little to regret delaying it a little.
560 2013-01-23 20:01:10 <CodeShark> I'm almost getting to the point now where rather than committing now and trying to merge later, I'm thinking how to write good patches that can survive any modifications to files like main.cpp
561 2013-01-23 20:01:44 <muhoo> that's usually a good plan
562 2013-01-23 20:02:36 <CodeShark> most of the changes I'm looking at involve only cut/pastes or pattern replacements
563 2013-01-23 20:02:36 <muhoo> if you've hung around worlds like the linux kernel... jeebus, patches and patchsets are the currency there. you could make a full-time job out of just trying to make sure your patches survive what some other guy is doing in parallel to you
564 2013-01-23 20:02:41 <gmaxwell> CodeShark: fortunately were in fixing mode now- so I don't expect any major breakage for a bit.
565 2013-01-23 20:03:31 <CodeShark> less central source files aren't as big an issue - but main.cpp is a huge one
566 2013-01-23 20:03:51 <CodeShark> it's better to merge in the stuff that we know will need to go there at some point in the future and doesn't break anything sooner rather than later
567 2013-01-23 20:03:55 <muhoo> i wouldn't fuck with something like main.cpp without taking a global lock :-)
568 2013-01-23 20:04:22 <CodeShark> the qualifier, of course, is that it needs to be easy to assess its correctness and test it
569 2013-01-23 20:04:50 <gavinandresen> yes, which is why right now is a bad time for do-nothing changes.
570 2013-01-23 20:05:21 <CodeShark> ok...so if it doesn't make it into 0.8, could we try to merge it in right after 0.8?
571 2013-01-23 20:06:30 <gavinandresen> no promises, but if the changes are easy to review and make the code obviously better then sure
572 2013-01-23 20:06:51 <CodeShark> yes on both counts :)
573 2013-01-23 20:06:56 <gavinandresen> but if there are 100 changes to review, then no matter how small that doesn't count as "easy to review"
574 2013-01-23 20:08:37 <Jamesonwa_> Looking to hire a bitcoin developer for a classified/bitcoin wallet based website
575 2013-01-23 20:15:33 <Diapolo> CodeShark: I guess it would be easier to review, to squash related commits and create smaller pulls of the big one. Easier to review and perhaps mergable without depending on the other pull?
576 2013-01-23 20:17:54 <CodeShark> yes, Diapolo - that's the idea
577 2013-01-23 20:18:48 <CodeShark> I have a couple branches with a bunch of modifications to a bunch of source files that, while not excessively complicated, are still not trivial to review and to test
578 2013-01-23 20:19:04 <CodeShark> so I'd like to break it down into simple pulls
579 2013-01-23 20:19:25 <CodeShark> I'd especially like to isolate commits that make modifications to files like main.cpp
580 2013-01-23 20:20:00 <Diapolo> I would love it, if you do this because smaller pulls are things I often merge into my local build and check them out. The tooooo big ones I leave for more skilled devs ^^.
581 2013-01-23 20:27:31 <TD> muhoo: ok, so the wallet thinks the transaction isn't relevant
582 2013-01-23 20:27:37 <TD> muhoo: did you get it figured out?
583 2013-01-23 20:38:12 <CodeShark> Diapolo: I've been tinkering a bit with bitcoin-qt...I'd like to develop a strategy for development on those branches so we won't be stepping on each other's toes
584 2013-01-23 20:43:59 <Diapolo> CodeShark: It's quite a lot about motivation so yeah, tell me your thougts ... I inted to be online for ~10 mins from now on ^^.
585 2013-01-23 20:47:42 <CodeShark> so the main changes I've made revolve around supporting multiple wallets and dynamic loading/unloading
586 2013-01-23 20:48:24 <CodeShark> so the main thrust is to have a control that can support multiple wallet views embedded into the BitcoinGUI window
587 2013-01-23 20:49:08 <Diapolo> CodeShark: My problem with that pull is mostly that it is really hard to track those code-moves in there, which don't change base code.
588 2013-01-23 20:49:25 <CodeShark> right, so I'm looking to clean up the commits
589 2013-01-23 20:49:40 <CodeShark> I'm sort of a git noob - just getting the hang of it
590 2013-01-23 20:49:52 <Diapolo> Git is massive yeah
591 2013-01-23 20:50:20 <CodeShark> when I first started out on the qt branch, I was at the same time studying the existing code and adding new functionality...so the commits are a little messy
592 2013-01-23 20:50:56 <CodeShark> I'd move some stuff around, then I'd implement some new stuff, then I'd move stuff around again, etc...
593 2013-01-23 20:51:10 <CodeShark> so I'd like to isolate the move-only commits from the implement new stuff commits
594 2013-01-23 20:51:28 <Diapolo> CodeShark: pretty good idea and much easier to track
595 2013-01-23 20:52:17 <CodeShark> I'd also like to stage the commits in such a way that the greatest dependency commits are staged earlier and in such a way as to avoid breaking things
596 2013-01-23 20:52:49 <CodeShark> so simple reorganizations that then support the additional functionality but don't necessarily add new functionality in and of themselves should come first
597 2013-01-23 20:53:13 <CodeShark> because these will be the hardest to merge later
598 2013-01-23 20:53:33 <Diapolo> I really love to see someone working on the Qt side of things :). You rise another good point, where wumpus comes into play I think. Merge-prio (which leads to a rebase for smaller pulls perhaps and we need to get the best priority).
599 2013-01-23 20:54:07 <wumpus> I think multi-wallet support is nice for 0.9
600 2013-01-23 20:54:38 <CodeShark> the goal is to quickly arrive at a good common parent commit so we can each work on our own branch and merge only from that common parent
601 2013-01-23 20:54:42 <wumpus> then again, the core stuff first needs to be merged, and that's up to gavin et al
602 2013-01-23 20:55:14 <CodeShark> but we don't even need to add the multiple wallet backend yet to simply support the controls
603 2013-01-23 20:55:38 <wumpus> yeah, that's true
604 2013-01-23 20:57:17 <CodeShark> perhaps the biggest rearchitecture I did of bitcoin-qt was to move the wallet view stuff out of BitcoinGUI and into a separate class
605 2013-01-23 20:57:33 <CodeShark> so overviewpage, sendcoinsdialog, etc...
606 2013-01-23 20:57:46 <wumpus> yes which IMO was a good idea
607 2013-01-23 20:58:01 <CodeShark> rather than making them part of centralWidget in the main window, I created a separate class called WalletView
608 2013-01-23 20:58:26 <CodeShark> then on top of that, I created another class called WalletStack that manages multiple WalletViews
609 2013-01-23 20:58:36 <CodeShark> so BitcoinGUI now makes the WalletStack object the centralWidget
610 2013-01-23 20:58:45 <CodeShark> and just passes on messages to wallets to it
611 2013-01-23 20:58:52 <CodeShark> and it then passes on those messages to the WalletViews
612 2013-01-23 20:59:05 <wumpus> makes sense
613 2013-01-23 21:00:02 <CodeShark> for a first merge commit, we don't have to incorporate any of the wallet loading/unloading code at all - we can just hardcode a single wallet in the init
614 2013-01-23 21:00:25 <CodeShark> pwalletMain
615 2013-01-23 21:00:31 <wumpus> right
616 2013-01-23 21:01:32 <CodeShark> After doing the above, I added a list control so you could select a wallet...but that could be done in a later commit
617 2013-01-23 21:01:55 <CodeShark> then I added the load/unload functionality
618 2013-01-23 21:02:39 <CodeShark> anyhow, importantly, the BitcoinGUI class will be the biggest point of contention in merges if we don't have a good strategy
619 2013-01-23 21:02:44 <wumpus> but indeed if you have a gui-only pull that doesn't depend on any core changes, that'd be much easier to merge
620 2013-01-23 21:03:10 <CodeShark> changes to WalletView and WalletStack can be merged later without as much difficulty
621 2013-01-23 21:03:22 <wumpus> it can be merged as soon as 0.8.0 becomes final
622 2013-01-23 21:04:58 <CodeShark> I didn't think it merited to create a new widget class for the list control + the wallet stack...and could just make them both owned by BitcoinGUI and have BitcoinGUI connect all the signals and slots...but I'm starting to think that perhaps it would be a good idea to write a new Widget class
623 2013-01-23 21:05:20 <CodeShark> since that means that we won't have to be editing BitcoinGUI.cpp and BitcoinGUI.h as much later on
624 2013-01-23 21:05:51 <CodeShark> BitcoinGUI just sticks an instance of this widget as its central widget
625 2013-01-23 21:05:59 <CodeShark> and passes on messages to it
626 2013-01-23 21:06:08 <CodeShark> and we can leave BitcoinGUI alone
627 2013-01-23 21:06:09 <wumpus> we should also be careful not to create too much (espeically small) classes and files, but if you can chop up bitcoingui.cpp into significant parts that'd be nice
628 2013-01-23 21:06:57 <CodeShark> well, there are two competing interests here: on the one hand, we don't want to create a bunch of tiny classes and additional source files to keep track of...bot on the other hand, we want to make it so that classes like BitcoinGUI require the least amount of modification later on
629 2013-01-23 21:07:43 <CodeShark> so basically I'm proposing one more class in addition to the two that I already mentioned
630 2013-01-23 21:08:05 <CodeShark> for the first commit, we can just have it display a single walletstack instance
631 2013-01-23 21:08:12 <CodeShark> and not incorporate the wallet list yet
632 2013-01-23 21:08:13 <Diapolo> CodeShark: your view of things is much wider than mine, but nearly everything you said makes a lot of sense
633 2013-01-23 21:08:40 <Diapolo> What I like is a good documentation of what your pull does, that helps me understanding your intentions :).
634 2013-01-23 21:08:41 <CodeShark> Diapolo: thank you :)
635 2013-01-23 21:08:55 <wumpus> yes it makes a lot of sense
636 2013-01-23 21:10:05 <Diapolo> I have really had zero experience with Qt or GUI stuff at all before getting interrested in bitcoin, you said you have a fair amount of experience so ... ^^
637 2013-01-23 21:10:37 <CodeShark> I've only done a tiny bit with Qt in the past - but it's fairly simple to use and well-documented
638 2013-01-23 21:10:58 <Diapolo> the documentation is great indeed
639 2013-01-23 21:11:00 <CodeShark> it's a very nice library, actually
640 2013-01-23 21:11:32 <Diapolo> cross-platform, which is what makes it perfect for us :) and digia seems to keep it updated, which is good
641 2013-01-23 21:11:33 <CodeShark> I used to do MFC stuff on win32 back in the day - Qt is SOOO much nicer :)
642 2013-01-23 21:13:02 <CodeShark> Qt even gets the subtle details of specific platform widgets right - like whether the OK button should be to the right or to the left of the Cancel button.
643 2013-01-23 21:13:02 <Diapolo> I did that stuff via Borland C++ Builder, which we used at school ^^ I never ever directly touched MFC
644 2013-01-23 21:13:14 <wumpus> be happy Diapolo ^^
645 2013-01-23 21:13:27 <Diapolo> ACTION is happe
646 2013-01-23 21:13:29 <CodeShark> MFC required some hideous hacks to work
647 2013-01-23 21:13:43 <CodeShark> a bunch of added macros to support message pumps
648 2013-01-23 21:13:50 <Diapolo> wumpus: bzw. I reverted that hated deleteAction thing in the pull ^^
649 2013-01-23 21:13:54 <wumpus> yes MFC was really hideous, probably made a whole generation hate on C++ and OOP :-)
650 2013-01-23 21:14:36 <CodeShark> so I'll document the proposed changes - the three new classes and the proposed changes to BitcoinGUI
651 2013-01-23 21:14:52 <CodeShark> if we can agree on this early on it will make things go much more smoothly moving forward
652 2013-01-23 21:15:12 <wumpus> and MFC was from the VC6.0 times, also the worst c/++ compiler ever
653 2013-01-23 21:15:53 <CodeShark> heh, yeah...and it sort of forced you to think in terms of an Office-like application
654 2013-01-23 21:16:22 <CodeShark> multiple documents inside a main window, etc...
655 2013-01-23 21:16:28 <Diapolo> CodeShark: agreed document what is intended and start implementing it with small pulls that don't rely on core stuff :)
656 2013-01-23 21:18:12 <Diapolo> I hope you are okay with me commenting even "small" things I think are worth to get mentioned. I can be rather perfectionistic sometimes :D
657 2013-01-23 21:18:20 <CodeShark> please do :)
658 2013-01-23 21:18:26 <CodeShark> even stylistic things
659 2013-01-23 21:18:37 <CodeShark> like the isEmpty() thing
660 2013-01-23 21:18:53 <CodeShark> we're working in a few different stylistic frameworks: Qt, std, and boost
661 2013-01-23 21:19:22 <CodeShark> boost tries to imitate std - but both of those are very different from Qt stylistically
662 2013-01-23 21:19:39 <wumpus> yes, the gui is an isolated island from the rest of the code
663 2013-01-23 21:19:41 <wumpus> that's on purpose
664 2013-01-23 21:19:42 <Diapolo> I'm better at small things and support people that can create the bigger ones ^^.
665 2013-01-23 21:20:15 <CodeShark> there will also be another point of contention with the multiwallet stuff - which is how to deal with supporting both RPC and an interactive GUI
666 2013-01-23 21:20:33 <CodeShark> perhaps some RPC features will have to be disabled for the qt version
667 2013-01-23 21:20:36 <wumpus> every communication with the core code goes through models, this is to make it easier to detach the two in separate processes communciating through a pipe later on
668 2013-01-23 21:20:48 <CodeShark> yes, that's a good design
669 2013-01-23 21:20:56 <gmaxwell> CodeShark: I thought the rpc was solved by just having a wrapper command?
670 2013-01-23 21:21:12 <CodeShark> well, for instance, say a wallet is unloaded via RPC
671 2013-01-23 21:21:18 <gmaxwell> I'd assume the gui could be solved via wraper tabs.
672 2013-01-23 21:21:20 <CodeShark> what if the GUI had that wallet in focus
673 2013-01-23 21:21:31 <gmaxwell> you can close an in-focus tab. :P
674 2013-01-23 21:21:38 <wumpus> then close it
675 2013-01-23 21:21:41 <CodeShark> so the RPC should override the GUI?
676 2013-01-23 21:21:42 <wumpus> use a notification
677 2013-01-23 21:21:44 <wumpus> yes
678 2013-01-23 21:21:47 <wumpus> the RPC is king
679 2013-01-23 21:21:56 <Diapolo> guys that was / is a great talk, but my bed is calling very loud ... see ya
680 2013-01-23 21:21:58 <wumpus> try sending quit while someone is using the UI :-)
681 2013-01-23 21:22:09 <CodeShark> good night, Diapolo - to be continued
682 2013-01-23 21:22:28 <wumpus> later Diapolo
683 2013-01-23 21:23:12 <CodeShark> there are a few other differences between a GUI wallet and an RPC wallet - for instance, for the RPC wallet, it makes more sense to use startup options to determine what wallets to load at startup
684 2013-01-23 21:23:24 <CodeShark> whereas with the GUI, it makes more sense to remember the state when you closed it
685 2013-01-23 21:23:39 <wumpus> sure, that difference makes sense
686 2013-01-23 21:23:44 <Diapolo> QSettings? and out :)
687 2013-01-23 21:23:54 <wumpus> yes qsettings, the ui already has its own settings
688 2013-01-23 21:24:21 <wumpus> which could include the currently loaded wallets
689 2013-01-23 21:25:04 <wumpus> of course the ui should then be robust if though it should check then that the wallets are actually reachable, and not on some external harddrive that was detached
690 2013-01-23 21:25:24 <CodeShark> right - if a wallet is not found, it might issue a warning but will recover gracefully
691 2013-01-23 21:25:30 <CodeShark> and continue loading as many wallets as possible
692 2013-01-23 21:25:59 <wumpus> it also adds an interesting mode: running without wallet?
693 2013-01-23 21:26:12 <CodeShark> yeah - that makes a lot of sense for the headless version
694 2013-01-23 21:26:28 <CodeShark> I have several bitcoind instances that I use strictly as verification/relay daemons
695 2013-01-23 21:26:33 <CodeShark> and haven't even touched their wallets
696 2013-01-23 21:26:55 <CodeShark> for the GUI version, without a wallet it doesn't make as much sense
697 2013-01-23 21:27:12 <CodeShark> although there's no reason why we can't support loading no wallets
698 2013-01-23 21:27:28 <CodeShark> other than backwards compatibility of the RPC
699 2013-01-23 21:27:38 <wumpus> yeah it probably should be possible, though on the other hand having some 'default wallet' that cannot be unloaded may make sense for users...
700 2013-01-23 21:28:34 <wumpus> otherwise they may screw themselves by unloading the wallet and thinking their coins are gone
701 2013-01-23 21:28:51 <CodeShark> yeah, perhaps we can have a "basic" and an "advanced" mode
702 2013-01-23 21:29:00 <CodeShark> the basic mode just loads one default wallet
703 2013-01-23 21:29:25 <CodeShark> or dunno - perhaps not worth the additional complexity
704 2013-01-23 21:29:43 <gmaxwell> well, no wallet loaded is more potenitally buggy corner cases.
705 2013-01-23 21:29:46 <CodeShark> perhaps just a good warning message if the user tries to close a wallet
706 2013-01-23 21:30:08 <CodeShark> explaining what's happening - and with an option to not display it next time
707 2013-01-23 21:30:30 <CodeShark> but we needn't worry about that too much just yet
708 2013-01-23 21:30:50 <CodeShark> for the first integration, I envision still keeping a default wallet in a file called wallet.dat for backwards compatibility
709 2013-01-23 21:30:56 <CodeShark> and denying the user the ability to unload it
710 2013-01-23 21:31:11 <CodeShark> more advanced users will probably not even use that wallet at all
711 2013-01-23 21:31:38 <wumpus> exactly
712 2013-01-23 21:31:43 <wumpus> they're always free to not use it
713 2013-01-23 21:41:06 <CodeShark> it's interesting how it totally changes your coding strategy when you're able to reorder and reorganize commits :)
714 2013-01-23 21:41:34 <CodeShark> I'm still getting used to having the ability to do that
715 2013-01-23 21:54:03 <sipa> CodeShark: would more advanced users that don't even use the wallet, use the Qt GUI?
716 2013-01-23 21:54:42 <CodeShark> if it supported things like BIP32 and could detach from a headless daemon, sure :)
717 2013-01-23 21:55:01 <sipa> wait... you said no wallet
718 2013-01-23 21:55:09 <sipa> so how is BIP32 relevant?
719 2013-01-23 21:55:17 <CodeShark> oh, you mean just using it as a verification/relay node?
720 2013-01-23 21:55:28 <CodeShark> the GUI doesn't really make too much sense for such usage
721 2013-01-23 21:55:30 <sipa> well you guys are talking about a walletless mode, no?
722 2013-01-23 21:55:45 <CodeShark> just saying that in principle you don't need to load a wallet to run bitcoind
723 2013-01-23 21:55:50 <sipa> agree
724 2013-01-23 21:56:21 <CodeShark> a GUI without a loaded wallet would be like a Word instance without an open document
725 2013-01-23 21:56:52 <sipa> exactly
726 2013-01-23 21:57:53 <CodeShark> I suppose the GUI could still provide realtime monitoring of the network and historical database query capabilities
727 2013-01-23 21:59:07 <CodeShark> but I'm tempted to say these are separate apps
728 2013-01-23 21:59:14 <CodeShark> perhaps they could all be integrated into a suite
729 2013-01-23 21:59:45 <D34TH> --loadapp=nowallet.app
730 2013-01-23 21:59:52 <D34TH> apps for everyone
731 2013-01-23 21:59:54 <D34TH> :D
732 2013-01-23 22:00:17 <gavinandresen> sipa: my 32-bit OSX laptop has been loading a 5+GB bootstrap.dat all day, it is up to block 187,000, should hit the 2GB mark soon
733 2013-01-23 22:01:25 <sipa> gavinandresen: oh, if it even manages to open it, it's fine
734 2013-01-23 22:01:54 <sipa> gavinandresen: as 0.8 doesn't do far seeks anymore
735 2013-01-23 22:02:30 <sipa> on 32-bit linux it simply seems to ignore bootstrap.dat entirely
736 2013-01-23 22:03:02 <sipa> gavinandresen: also, "all day"... how ancient is it?
737 2013-01-23 22:21:31 <benkay> hey y'all, what is a "chain code", as referred to in BIP_0032?
738 2013-01-23 22:21:51 <benkay> https://en.bitcoin.it/wiki/BIP_0032
739 2013-01-23 22:22:16 <sipa> it's just 256 bits of extra entropy
740 2013-01-23 22:22:29 <gavinandresen> sipa: it's a 5-year-old Macbook Pro??? so pretty ancient.
741 2013-01-23 22:22:31 <sipa> so one can't just derive the subkeys using the parent key
742 2013-01-23 22:22:45 <sipa> gavinandresen: still, all day sounds very bad
743 2013-01-23 22:23:42 <gmaxwell> gavinandresen: do you have logs with timestamps?
744 2013-01-23 22:24:05 <gmaxwell> it would be interesting to know if most of the time was before signature checking.
745 2013-01-23 22:24:09 <benkay> thanks, sipa.
746 2013-01-23 22:24:11 <gavinandresen> sipa: well, it's making steady progress, just slow. no logs, I'm running -printtoconsole
747 2013-01-23 22:24:45 <gavinandresen> sipa: memory usage looks ok, CPU usage is 10-20%, so my guess would be the hard drive is the bottleneck.
748 2013-01-23 22:24:54 <sipa> what block are you at?
749 2013-01-23 22:25:48 <gavinandresen> just passed 190,000
750 2013-01-23 22:25:59 <sipa> 0.7.x or head?
751 2013-01-23 22:26:09 <gmaxwell> ACTION hopes
752 2013-01-23 22:27:04 <gavinandresen> head
753 2013-01-23 22:27:15 <gmaxwell> darn.
754 2013-01-23 22:29:19 <sipa> gavinandresen: mind trying with a larger -dbcache (depending on how much ram you have) ?
755 2013-01-23 22:29:30 <sipa> gavinandresen: -reindex should automatically continue from where it left off
756 2013-01-23 22:29:39 <gavinandresen> sure; it's got 2GB ram
757 2013-01-23 22:29:54 <sipa> a few hundred MB dbcache won't hurt then
758 2013-01-23 22:30:08 <sipa> (don't specify -reindex again, i mean)
759 2013-01-23 22:31:24 <gavinandresen> -dbcache=500 will get me 500MB cache?
760 2013-01-23 22:31:38 <sipa> approximately, and up to
761 2013-01-23 22:33:25 <gavinandresen> re-running with logtimestamps and -dbcache=500 ???.
762 2013-01-23 22:36:23 <benkay> how would one go about generating new public keys from a master public key, compatible with, say, electrum?
763 2013-01-23 22:36:41 <benkay> i'm staring at bitcoin-address-utility in total confusion.
764 2013-01-23 22:37:06 <sipa> benkay: no idea about any tool, but i heard electrum will implement bip32-style derivation when it becomes finalized
765 2013-01-23 22:37:43 <gavinandresen> sipa: Verifying last 2500 blocks took almost 5 minutes???.
766 2013-01-23 22:38:15 <sipa> gavinandresen: CPU usage?
767 2013-01-23 22:39:13 <benkay> neat! i assume that the client doesn't need the seed hashed with the public key to sign transactions that verify against the descendant public key?
768 2013-01-23 22:39:50 <sipa> benkay: to sign transactions you need a private key, to verify them you need the corresponding public key
769 2013-01-23 22:40:01 <sipa> benkay: bip32 or deterministic wallets in general don't change that
770 2013-01-23 22:40:21 <sipa> it only changes how you obtain those private or public keys
771 2013-01-23 22:40:30 <benkay> that's what I thought, thanks.
772 2013-01-23 22:45:37 <muhoo> i'm getting a ton of "ERROR: FetchInputs() : df8dabe670 mempool Tx prev not found fb2366df43" etc errors, while waiting for the blockchain to catch up.... very slowly...
773 2013-01-23 22:45:55 <sipa> don't worry about those
774 2013-01-23 22:46:16 <muhoo> ok. on december 7th at the moment :-/ i'll let it run another day
775 2013-01-23 22:46:23 <sipa> which version?
776 2013-01-23 22:48:32 <muhoo> 0.7.1-maverick1
777 2013-01-23 22:48:49 <sipa> ok, what is your cpu usage?
778 2013-01-23 22:49:08 <muhoo> minimal, 1.7% for bitcoind (this is an i7)
779 2013-01-23 22:49:33 <muhoo> hmm, peaking to 30% cpu when it's actually getting blocks
780 2013-01-23 22:49:46 <sipa> 30% of one CPU, or of all?
781 2013-01-23 22:49:48 <gavinandresen> sipa: ark for dinner. But it is verifying blocks much, much faster now.
782 2013-01-23 22:49:49 <muhoo> one
783 2013-01-23 22:50:00 <gavinandresen> ^ark^afk
784 2013-01-23 22:51:05 <muhoo> prolly just slow network, i reckon.
785 2013-01-23 22:51:15 <muhoo> what's that error though?
786 2013-01-23 22:51:34 <muhoo> a transaction flying by and bitcoind being unable to make sense of it because its chain is too far behind?
787 2013-01-23 22:51:48 <muhoo> just curious
788 2013-01-23 22:52:43 <muhoo> up to december 9th now. i think it was disk-bound (was running off of an sdcard, moved to a nice fast drive now), and still a bit network bound, atm (comcast).
789 2013-01-23 22:53:21 <muhoo> bitcoind does not like running off of an sdcard, at all, at all.
790 2013-01-23 22:55:13 <sipa> muhoo: yes, unconfirmed transactions on the network that spend outputs you don't have yet
791 2013-01-23 22:55:17 <muhoo> ah, that's what that error is: http://bitcoin.stackexchange.com/questions/5673/debug-log-how-do-i-analyze-an-orphaned-transaction
792 2013-01-23 22:55:28 <muhoo> sipa: thanks
793 2013-01-23 22:55:28 <sipa> muhoo: probably peer-bound and disk-bound
794 2013-01-23 22:55:46 <sipa> (as in: using a bad peer to sync from slows things down terribly)
795 2013-01-23 22:55:55 <muhoo> oh? interesting to know.
796 2013-01-23 23:05:15 <benkay> if someone sends a bitcoin to a bip32 address (generated with some chain code and my public address), do I need the chain code to sign those coins on again?
797 2013-01-23 23:05:23 <benkay> -> that coin
798 2013-01-23 23:07:09 <sipa> no, you need its private key
799 2013-01-23 23:07:33 <sipa> benkay: to sign transactions you need a private key, to verify them you need the corresponding public key
800 2013-01-23 23:07:36 <sipa> benkay: bip32 or deterministic wallets in general don't change that
801 2013-01-23 23:07:46 <sipa> it only changes how you obtain those private or public keys
802 2013-01-23 23:08:09 <sipa> "chain codes" are just things inside the bip32 derivation
803 2013-01-23 23:08:15 <sipa> they don't have a meaning outside of it
804 2013-01-23 23:08:37 <benkay> ah, and the private key will validate against any public key from bip32
805 2013-01-23 23:09:21 <benkay> more specifically, signatures generated with the private key will validate against the derived public key?
806 2013-01-23 23:09:50 <sipa> you sign using private key x, then you validate using public key G*x
807 2013-01-23 23:17:03 <benkay> so even if G = f(some other G, some other crap), G*x still validates
808 2013-01-23 23:17:23 <sipa> G is the generator of the secp256k1 curve
809 2013-01-23 23:17:23 <sipa> there is no other G
810 2013-01-23 23:17:34 <sipa> it's a constant
811 2013-01-23 23:19:20 <benkay> so for each bip32 public key there is one and only one private key?
812 2013-01-23 23:19:39 <sipa> yes, but this has nothing to do with bip32
813 2013-01-23 23:20:18 <benkay> i (sortof) get that. i'm still trying to understand the math behind acceptbit
814 2013-01-23 23:20:26 <sipa> acceptbit?
815 2013-01-23 23:20:36 <benkay> http://www.acceptbit.com
816 2013-01-23 23:20:41 <benkay> it's a bip32 implementation
817 2013-01-23 23:20:48 <benkay> supposedly.
818 2013-01-23 23:21:24 <sipa> where do you read that?
819 2013-01-23 23:22:15 <sipa> afaik there is no public implementation of bip32, as the standard isn't final yet
820 2013-01-23 23:22:48 <benkay> http://bitcoinmagazine.com/review-of-acceptbit-the-trust-free-payment-processor/
821 2013-01-23 23:23:59 <sipa> both electrum and acceptbit probably do deterministic key generation
822 2013-01-23 23:24:05 <sipa> but they don't use bip32
823 2013-01-23 23:24:17 <benkay> !
824 2013-01-23 23:24:18 <sipa> bip32 is just one specific standard for doing deterministic keys
825 2013-01-23 23:24:42 <benkay> i feel like i've been trying to fit a square peg into a round hole
826 2013-01-23 23:24:47 <benkay> derp and derp.
827 2013-01-23 23:24:58 <benkay> thanks, sipa. really appreciate your patience.
828 2013-01-23 23:25:14 <sipa> :)
829 2013-01-23 23:25:47 <phantomcircuit> sipa, heh ecdsa.org is down
830 2013-01-23 23:26:20 <benkay> so the whole deterministic wallet trick is just multiplying the public key by some integer point, and the private key by the same point
831 2013-01-23 23:26:30 <sipa> phantomcircuit: it moved to electrum.org
832 2013-01-23 23:26:46 <benkay> increment along a known set of points and that way your wallet knows all possible potential addresses
833 2013-01-23 23:26:47 <sipa> benkay: integers are not points
834 2013-01-23 23:26:58 <benkay> right right scratch that
835 2013-01-23 23:26:59 <phantomcircuit> sipa, i know i was clicking the links on acceptbit and realized they dont have redirects
836 2013-01-23 23:27:04 <benkay> but some set of known points
837 2013-01-23 23:27:11 <sipa> you multiply the public key (which is a point) and the private key (which is a number) by the same number
838 2013-01-23 23:27:31 <benkay> ACTION nods vigorously
839 2013-01-23 23:27:50 <sipa> and it's not some "set of known points" - it is the secp256k1 curve
840 2013-01-23 23:28:13 <sipa> which has a very specific definition of multiplication between points and numbers
841 2013-01-23 23:28:59 <benkay> is the curve continuous?
842 2013-01-23 23:29:06 <benkay> duh
843 2013-01-23 23:29:26 <sipa> "continuous" doesn't have a meaning in a finite field
844 2013-01-23 23:29:37 <HM> this is slightly offtopic, but for those making diagrams for any documentation they're writing -> http://www.websequencediagrams.com/
845 2013-01-23 23:30:04 <sipa> benkay: i'd try to explain things a bit better, but i need sleep now
846 2013-01-23 23:30:23 <benkay> no worries. i'll be on tomorrow. my partner's nagging me to get off irc and review some docs anyways
847 2013-01-23 23:30:34 <benkay> thanks a million, mon frere
848 2013-01-23 23:31:32 <sipa> yw