1 2013-01-07 00:00:32 <gmaxwell> BlueMatt: sending negative bits sometimes perhaps?
2 2013-01-07 00:02:48 <BlueMatt> gmaxwell: sounds tricky to implement without giving away which txn were fp, though same is true of resending a filter (in the non-bitcoinj case) as resending would probably mean giving away exactly which txn were fp
3 2013-01-07 00:02:52 <BlueMatt> or at least most of them
4 2013-01-07 00:03:14 <BlueMatt> (the case where a client actually uses weird tx types and has to keep the auto-added objects)
5 2013-01-07 00:04:52 <sipa> bitcoinj needs the auto-added objects too, no?
6 2013-01-07 00:05:09 <sipa> how would you detect spends of wallet outputs otherwise?
7 2013-01-07 00:06:02 <jgarzik_> ACTION reads scrollback
8 2013-01-07 00:06:13 <jgarzik_> false positives are automatically added?
9 2013-01-07 00:06:37 <jgarzik> seems odd
10 2013-01-07 00:06:38 <sipa> the server has no way to know they are false, so ues
11 2013-01-07 00:06:41 <sipa> *yes
12 2013-01-07 00:07:16 <BlueMatt> in spend-to-pubkey case it does, true...
13 2013-01-07 00:07:24 <jgarzik> Seems like the server should just send whatever matches the filter, but not touch the filter without client input?
14 2013-01-07 00:07:43 <sipa> jgarzik: so the client would need to ask the server to update the filter after every single match?
15 2013-01-07 00:07:55 <sipa> that would add a ton of latency to syncing
16 2013-01-07 00:07:56 <BlueMatt> jgarzik: adds outpoints automatically if the output matches so that you dont have to re-send filter in the case of pay-to-pubkey
17 2013-01-07 00:07:59 <jgarzik> sipa: if it matched, why would the filter need to be update?
18 2013-01-07 00:08:04 <jgarzik> *updated
19 2013-01-07 00:08:16 <sipa> jgarzik: so you can detect transactions which spend its outputs
20 2013-01-07 00:08:50 <sipa> BlueMatt: but isn't that the main cause of the fp blowup... this process happens recursively
21 2013-01-07 00:09:02 <jgarzik> yep. it's not the huge penalty implied, if the client handles it
22 2013-01-07 00:09:03 <sipa> if you add the outputs of every matched transaction
23 2013-01-07 00:09:19 <BlueMatt> sipa: yes
24 2013-01-07 00:09:20 <jgarzik> and that leaves server logic nice and tidy
25 2013-01-07 00:09:29 <BlueMatt> sipa: wait...no
26 2013-01-07 00:09:45 <jgarzik> satoshidice is the only user that will care about added latency
27 2013-01-07 00:09:46 <BlueMatt> sipa: it adds outpoints of outputs that match, not txn that match or inputs that spend a matched outpoint
28 2013-01-07 00:09:51 <jgarzik> everyone else is just too small
29 2013-01-07 00:10:10 <BlueMatt> jgarzik: where were you when this was discussed thoroughly 6 months ago?
30 2013-01-07 00:10:17 <BlueMatt> :)
31 2013-01-07 00:11:14 <jgarzik> KISS. The latency is not a problem.
32 2013-01-07 00:17:55 <BlueMatt> landing, Ill bbl, maybe tomorrow
33 2013-01-07 00:18:24 <sipa> jgarzik: if you need to add outpoints yourself, you can't do a "send me blocks 5000-6000" in one request
34 2013-01-07 00:18:52 <sipa> jgarzik: it means you have to ask for one block, see if it matches anything that causes you to need to add something to the filter, ask for the same block again, ...
35 2013-01-07 00:21:46 <gmaxwell> jgarzik: its not just a latency issue, you'll miss transactions you wanted and didn't know you wanted.
36 2013-01-07 00:22:10 <sipa> jgarzik: in case of standard transactions, that isn't really a problem, as you don't need the outpoints to be added in the first place
37 2013-01-07 00:23:03 <sipa> but in the general case, as soon as you have one single pay-to-pubkey you want to match on, you need to update your filter continuously and re-request blocks all the time
38 2013-01-07 00:23:17 <sipa> unless the server adds the outpoints automatically to the filter in-loop
39 2013-01-07 00:25:43 <sipa> i wonder if a trick like: try to match output scripts, and also "_" + output script, and only add the outpoint automatically if the _ version matched
40 2013-01-07 00:26:14 <sipa> *data element of output script
41 2013-01-07 00:27:28 <maaku> anyone know of a sql backing store for bitcoinj?
42 2013-01-07 01:05:03 <MC1984> has anyone tried an IBD without the checkpoints
43 2013-01-07 01:07:00 <MC1984> with full verification from block 0
44 2013-01-07 01:07:22 <MC1984> seeing as the checkpoints are sort of just your opinion mans
45 2013-01-07 01:07:44 <andytoshi> no, but i bet it wouldn't be terrible
46 2013-01-07 01:07:51 <andytoshi> the huge blocks started fairly recently
47 2013-01-07 01:08:28 <MC1984> is there any way to try it with satoshi
48 2013-01-07 01:10:05 <andytoshi> checkpoints.cpp
49 2013-01-07 01:10:39 <andytoshi> just comment out all of the checkpoints
50 2013-01-07 01:11:05 <MC1984> .............wat
51 2013-01-07 01:11:38 <andytoshi> there is a big list in src/checkpoint.cpp that looks like
52 2013-01-07 01:11:41 <andytoshi> ( 11111, uint256("0x0000000069e244f73d78e8fd29ba2fd2ed618bd6fa2ee92559f542fdb26e7c1d"))
53 2013-01-07 01:11:42 <andytoshi> ( 33333, uint256("0x000000002dd5588a74784eaa7ab0507a18ad16a236e7b1ce69f00d7ddfb5d0a6"))
54 2013-01-07 01:11:54 <andytoshi> and so forth..you can definitely remove all but the first one
55 2013-01-07 01:12:01 <andytoshi> i'm not sure how to just give it an empty list
56 2013-01-07 01:13:05 <MC1984> maybe i could do that but i couldnt build it
57 2013-01-07 01:13:51 <andytoshi> if you're using linux 64, i could build you one
58 2013-01-07 01:14:01 <andytoshi> of course, you'd be trusting me
59 2013-01-07 01:14:12 <MC1984> windows
60 2013-01-07 01:14:23 <andytoshi> oh, sorry
61 2013-01-07 01:14:45 <MC1984> sok
62 2013-01-07 01:16:49 <MC1984> wow spvclient syncs the whole chain within minutes
63 2013-01-07 01:17:01 <MC1984> well the headers part of it anyway
64 2013-01-07 01:17:11 <MC1984> i wish real bitcoin was like that :/
65 2013-01-07 01:22:50 <sipa> MC1984: -nocheckpoints
66 2013-01-07 01:24:34 <MC1984> cool :)
67 2013-01-07 01:25:11 <MC1984> is there a list of arguments somewhere?
68 2013-01-07 01:25:25 <MC1984> inb4 bitcointalk.org
69 2013-01-07 01:26:24 <gmaxwell> MC1984: the help output ... --help
70 2013-01-07 01:28:33 <MC1984> theres no checkpoints on testnet anyway right
71 2013-01-07 01:33:16 <gmaxwell> no so
72 2013-01-07 01:33:20 <gmaxwell> er not
73 2013-01-07 01:47:17 <jgarzik> gmaxwell: https://github.com/tlhunter/node-news-daemon Another Daemon fan.
74 2013-01-07 01:47:23 <jgarzik> nothing bitcoin related
75 2013-01-07 01:47:50 <SomeoneWeird> another node fan
76 2013-01-07 01:50:06 <MC1984> satoshi wont even relay zero fee txn? wtf
77 2013-01-07 01:52:34 <gmaxwell> MC1984: what the heck are you talking about?
78 2013-01-07 01:52:45 <gmaxwell> MC1984: it relays things that meet the anti-DOS rules.
79 2013-01-07 01:52:56 <gmaxwell> Some free transactions do, some do not.
80 2013-01-07 01:53:08 <gmaxwell> Without this restriction and dipstick with a shellscript could knock out the network.
81 2013-01-07 01:53:13 <MC1984> oh yeah
82 2013-01-07 01:53:28 <MC1984> whats the minimum btc to qualify for free txn
83 2013-01-07 01:54:27 <MC1984> wait im talking shit
84 2013-01-07 01:54:38 <MC1984> i dont know what the dos rules are
85 2013-01-07 01:56:03 <SomeoneWeird> lol
86 2013-01-07 01:57:33 <jgarzik> MC1984: it is more complicated than just minimum BTC. priority includes details like coin age -- thus punishing people trying to resend the same coin(s) over and over again
87 2013-01-07 01:59:31 <SomeoneWeird> that's neat
88 2013-01-07 02:46:27 <BTCOxygen> <@jgarzik> MC1984: it is more complicated than just minimum BTC. priority includes details like coin age -- thus punishing people trying to resend the same coin(s) over and over again
89 2013-01-07 02:46:34 <BTCOxygen> ^^^^ Any wiki links?
90 2013-01-07 02:46:56 <gmaxwell> https://en.bitcoin.it/wiki/Transaction_fees#Rules_for_calculating_minimum_fees
91 2013-01-07 02:47:42 <BTCOxygen> gmaxwell: Thanks
92 2013-01-07 02:48:12 <gmaxwell> like all things on that wiki??? I can't promise that it's completely accurate or current.
93 2013-01-07 02:49:41 <BTCOxygen> gmaxwell: seriously?
94 2013-01-07 02:49:47 <BTCOxygen> LOL
95 2013-01-07 02:50:35 <gmaxwell> What? this isn't a surprising statement. There is a lot of editing by clueless people there, anyone can edit it and many people do. Clueful people don't need to consult the pages often.
96 2013-01-07 02:50:42 <nanotube> it's a wiki that "anyone can edit", what do you expect? :)
97 2013-01-07 02:51:04 <gmaxwell> The stuff I _know_ is wrong I usually fix... but that still leaves a bunch of stuff I haven't looked at (recently)
98 2013-01-07 02:51:40 <Adifex> sorry, I just joined???which wiki?
99 2013-01-07 02:52:23 <gmaxwell> bitcoin.it
100 2013-01-07 02:52:28 <kuzetsa> heh
101 2013-01-07 02:52:47 <gmaxwell> It's find and helpful, I don't dislike it. I was just pointing out that by providing the URL it doesn't mean I'd checked the page for accuracy.
102 2013-01-07 02:52:50 <Adifex> lol
103 2013-01-07 02:53:06 <SomeoneWeird> so is 500kb still the max blocksize?
104 2013-01-07 02:53:37 <kuzetsa> gmaxwell: well... can you confirm? Is the method for calculating fees based on age of coins correct? (sum the coins in base units multiplied by their respective ages and divide by whatever it was)
105 2013-01-07 02:53:52 <Graet> ;;seen jine
106 2013-01-07 02:53:52 <gribble> jine was last seen in #bitcoin-dev 3 days, 21 hours, 48 minutes, and 2 seconds ago: <jine> paybitcoin: Need more testnet coins, just tell me. :)
107 2013-01-07 02:53:54 <SomeoneWeird> "priority = sum(input_value_in_base_units * input_age)/size_in_bytes"
108 2013-01-07 02:53:55 <kuzetsa> like... the size of the transaction and some sort of constant
109 2013-01-07 02:54:01 <kuzetsa> yeah, that.
110 2013-01-07 02:54:36 <kuzetsa> gmaxwell: it looks about right, but I haven't reviewed the source in a while.
111 2013-01-07 02:54:37 <gmaxwell> yes, priority = sum(input_value_in_base_units * input_confirms)/tx_size_in_bytes is correct
112 2013-01-07 02:55:04 <gmaxwell> SomeoneWeird: blocksizes don't have much to do with minimum fees for relaying.
113 2013-01-07 02:55:08 <gmaxwell> s/much/any/
114 2013-01-07 02:55:25 <SomeoneWeird> yeah, but still, is it? :P
115 2013-01-07 02:55:30 <gmaxwell> ACTION dreds opening the page to see what confusion it spreads
116 2013-01-07 02:55:41 <gmaxwell> ugh.
117 2013-01-07 02:55:49 <gmaxwell> yes, of course, the page inspires confusion.
118 2013-01-07 02:55:59 <SomeoneWeird> heh
119 2013-01-07 02:56:04 <BTCOxygen> heh
120 2013-01-07 02:56:17 <SomeoneWeird> heh
121 2013-01-07 02:56:19 <BTCOxygen> gmaxwell: Edits Welcome
122 2013-01-07 02:56:28 <MC1984> Current default rules for the original Bitcoin client (Bitcoin 0.3.23):
123 2013-01-07 02:56:29 <MC1984> um
124 2013-01-07 02:56:32 <gmaxwell> SomeoneWeird: the blocksize target is 250k now.
125 2013-01-07 02:56:41 <SomeoneWeird> right
126 2013-01-07 02:57:12 <BTCOxygen> gmaxwell: I guess that page needs some editing
127 2013-01-07 02:57:47 <gmaxwell> but that doesn't really have anything to do with the fees, unlike the page seems to suggest... simply because the mining and relay rules are very different and the mining rules are stateful, so even if the 'current' block is very full the next one probably isn't.
128 2013-01-07 02:58:28 <SomeoneWeird> right
129 2013-01-07 02:58:54 <gmaxwell> (and in no case does the state of other transactions/blocks now influence what the client imposes as a minimum on transactions)
130 2013-01-07 03:08:16 <BTCOxygen> gmaxwell: How much time can i expect a 3678 byte transaction to take ?
131 2013-01-07 03:08:26 <BTCOxygen> *I
132 2013-01-07 03:09:58 <gmaxwell> -ENOTENOUGHDATA
133 2013-01-07 03:12:12 <BTCOxygen> gmaxwell: Does blockchain.info shows the tx priority like (500000000 * 10 + 200000000 * 3) / 500 = 11,800,000 ?
134 2013-01-07 03:12:58 <gmaxwell> ACTION looks around for the phantom gmaxwell' that has anything at all to do with blockchain.info
135 2013-01-07 03:14:02 <gmaxwell> BTCOxygen: dunno why you're asking me that??? as far as I know blockchain.info doesn't even let you see what inputs a transaction is spending, much less the resulting priority.
136 2013-01-07 03:15:42 <BTCOxygen> gmaxwell: It does show you the inputs you spend
137 2013-01-07 03:16:55 <gmaxwell> http://blockchain.info/tx/95508c9e7d88e244aa6f4dc52d934f729ffe1aa92111c9a5188ee14d88569cdf < where?
138 2013-01-07 03:17:26 <MC1984> how many testnet nodes are there
139 2013-01-07 03:17:36 <MC1984> this ones been open over an hour with nothing
140 2013-01-07 03:18:02 <gmaxwell> MC1984: plenty. have you manually disabled IRC or something?
141 2013-01-07 03:18:26 <MC1984> no but
142 2013-01-07 03:18:28 <MC1984> 2013-01-07 04:11:46 IRC connect failed
143 2013-01-07 03:18:30 <MC1984> wut
144 2013-01-07 03:19:07 <gmaxwell> welp thats why
145 2013-01-07 03:19:21 <MC1984> 0 addresses found from DNS seeds
146 2013-01-07 03:19:22 <MC1984> wut
147 2013-01-07 03:20:15 <gmaxwell> There is no dnsseed in testnet.
148 2013-01-07 03:20:27 <gmaxwell> You must have IRC to find your initial peers, or provide one manually.
149 2013-01-07 03:20:35 <MC1984> lawd
150 2013-01-07 03:20:51 <MC1984> how do i fix the irc method then
151 2013-01-07 03:21:15 <gmaxwell> no clue, I have no idea why it's not working??? is there some connectivity difference why outbound port 6667 would be blocked?
152 2013-01-07 03:22:53 <BTCOxygen> gmaxwell: http://blockchain.info/tx/95508c9e7d88e244aa6f4dc52d934f729ffe1aa92111c9a5188ee14d88569cdf?show_adv=true
153 2013-01-07 03:23:43 <gmaxwell> I still don't see them. Which transaction IDs and vout indexes is that transaction spending?
154 2013-01-07 03:24:21 <gmaxwell> I should have probably picked one with multiple inputs.
155 2013-01-07 03:24:33 <MC1984> well time for router reset
156 2013-01-07 03:25:05 <BTCOxygen> gmaxwell: Yeah, that would have been a better example
157 2013-01-07 03:25:27 <BTCOxygen> ACTION goes to find a muti-input tx for gmaxwell
158 2013-01-07 03:26:03 <MC1984> cool i didnt even dc
159 2013-01-07 03:26:29 <BTCOxygen> gmaxwell: http://blockchain.info/tx/68ae570017f042c5140b83ec2e165eca358932072a2d4d84262394836a6cfa08
160 2013-01-07 03:26:57 <BTCOxygen> gmaxwell: http://blockchain.info/tx/68ae570017f042c5140b83ec2e165eca358932072a2d4d84262394836a6cfa08?show_adv=true
161 2013-01-07 03:27:28 <gmaxwell> BTCOxygen: so, okay, again??? what txid/vouts are it spending. I don't see it listing any input txids.
162 2013-01-07 03:29:56 <BTCOxygen> gmaxwell: It does if you click one of those Output links
163 2013-01-07 03:30:28 <MC1984> wow this is inexplicable
164 2013-01-07 03:30:45 <BTCOxygen> gmaxwell: http://blockchain.info/tx-index/41848149/0
165 2013-01-07 03:31:02 <BTCOxygen> First Output link for transaction http://blockchain.info/tx/68ae570017f042c5140b83ec2e165eca358932072a2d4d84262394836a6cfa08?show_adv=true
166 2013-01-07 03:31:34 <gmaxwell> BTCOxygen: ah, you have to click on them. Well, there you go, you can now calculate the priority yourself.
167 2013-01-07 03:31:42 <gmaxwell> might have to do a bunch of clicking! :P
168 2013-01-07 03:32:30 <BTCOxygen> gmaxwell: Any Examples?
169 2013-01-07 03:32:36 <BTCOxygen> On how
170 2013-01-07 03:34:05 <gmaxwell> BTCOxygen: for each input, go get the confirmation count, and its value. and do the aformentioned math.
171 2013-01-07 03:34:32 <BTCOxygen> gmaxwell: Ok, got it.
172 2013-01-07 03:34:50 <BTCOxygen> size_in_bytes == ?????
173 2013-01-07 03:34:58 <BTCOxygen> gmaxwell: ^^
174 2013-01-07 03:35:52 <gmaxwell> Size 258 (bytes)
175 2013-01-07 03:35:57 <gmaxwell> on the transaction itself, at the top
176 2013-01-07 03:36:39 <BTCOxygen> gmaxwell: Oh
177 2013-01-07 03:36:46 <BTCOxygen> Found It
178 2013-01-07 03:37:16 <BTCOxygen> gmaxwell: btw, Thanks for the help
179 2013-01-07 03:40:11 <stealth222> I'm trying to remove dependencies in the satoshi client source - moving it away from everything depending on main.h and init.h
180 2013-01-07 03:40:44 <stealth222> I've noticed a few things - like the way that main.h is indirectly included many times via wallet.h
181 2013-01-07 03:41:53 <stealth222> and db.h
182 2013-01-07 03:42:12 <stealth222> I've managed to remove db.h's dependencies on main by including sync.h and serialize.h explicitly
183 2013-01-07 03:42:53 <stealth222> but there are a few tricky things about removing wallet and walletdb's dependencies on main and ui_interface
184 2013-01-07 03:43:12 <andytoshi> stealth222: if you're doing this to speed compilation, note that compilers are really good at this these days
185 2013-01-07 03:43:21 <stealth222> no, I'm doing this to make the codebase more modular
186 2013-01-07 03:43:23 <andytoshi> not even opening files that have already been included
187 2013-01-07 03:43:30 <stealth222> so it's easier to write new applications that reuse the same codebase
188 2013-01-07 03:43:35 <andytoshi> oh, then excellent
189 2013-01-07 03:44:19 <stealth222> I'd like to see bitcoind become optimized as a verification/relay agent
190 2013-01-07 03:44:30 <stealth222> and to create separate apps for wallets and historical databases
191 2013-01-07 03:44:43 <stealth222> and alerts
192 2013-01-07 03:45:45 <andytoshi> cool, but does libbitcoin also have that goal? (i don't know)
193 2013-01-07 03:46:28 <stealth222> yes, but we do need a reference implementation of verification/relay since this is the core of what's needed to keep the network in operation
194 2013-01-07 03:46:47 <stealth222> and I'd like to see the satoshi client evolve into a streamlined verification/relay agent
195 2013-01-07 03:47:03 <andytoshi> me too -- it would be nice if init.cpp were readable
196 2013-01-07 03:47:09 <andytoshi> instead of this AppInit and AppInit2 thing
197 2013-01-07 03:47:10 <stealth222> lol
198 2013-01-07 03:47:21 <andytoshi> good luck! sorry to interrupt your question
199 2013-01-07 03:49:17 <stealth222> I built dependency graphs http://108.60.150.142/bitcoindoc/files.html
200 2013-01-07 03:49:58 <stealth222> taking a look at http://108.60.150.142/bitcoindoc/net_8cpp.html for example, we see that net.cpp depends on main.h but main.h is included indirectly via wallet.h and db.h
201 2013-01-07 03:49:59 <gmaxwell> stealth222: hopefully cleaning up some of that speeds up compiles?
202 2013-01-07 03:50:21 <gmaxwell> oh, er, you're going the _opposite_ direction. bleh.
203 2013-01-07 03:50:24 <stealth222> gmaxwell: that would be a desirable effect, too. But the main motivation is a more mmodular codebase
204 2013-01-07 03:50:57 <stealth222> less entangled codebase
205 2013-01-07 03:51:39 <stealth222> db.h has forward declarations for CWallet and CWalletTx, for instance, but never uses these types
206 2013-01-07 03:53:53 <stealth222> furthermore, db.h does depend on sync.h and serialize.h, but not really on main.h
207 2013-01-07 03:55:21 <stealth222> sync.h and serialize.h are easy to isolate since they only depend on external libraries and version.h
208 2013-01-07 03:56:08 <stealth222> which means that explicit includes of sync.h and serialize.h, removal of the main.h include, and removal of the unused forward declarations would be a good idea :)
209 2013-01-07 03:56:31 <andytoshi> at first glance, this looks good, but it could become a huge job
210 2013-01-07 03:56:41 <andytoshi> looking in main.h, there seems to be a lot of stuff that doesn't belong
211 2013-01-07 03:56:49 <stealth222> it won't be easy - it is a pretty big job
212 2013-01-07 03:56:56 <stealth222> but it will save a lot of grief later
213 2013-01-07 03:56:58 <andytoshi> forward dec'l of RegisterWallet, for example, which should be in wallet.h i would think
214 2013-01-07 03:57:48 <stealth222> so after fixing db.h, I moved onto wallet.h and walletdb.h
215 2013-01-07 03:58:02 <stealth222> there's an interesting issue here as walletdb defies the enum DBError
216 2013-01-07 03:58:07 <stealth222> *defines
217 2013-01-07 03:58:31 <stealth222> so a mutual include fails
218 2013-01-07 03:58:46 <andytoshi> bleh
219 2013-01-07 03:58:52 <andytoshi> that's how things end up in main.h ;)
220 2013-01-07 03:59:23 <stealth222> we could move the DBError enum to a separate include file which is included in both wallet.h and walletdb.h
221 2013-01-07 03:59:38 <stealth222> not main.h - lol
222 2013-01-07 04:00:10 <andytoshi> i dunno, making a new file seems like going in the wrong direction
223 2013-01-07 04:00:31 <andytoshi> honestly, i'd probably throw it into main.h, because enums are cheap
224 2013-01-07 04:00:33 <stealth222> the other alternative is to either remove wallet.h's dependence on walletdb.h or vice versa
225 2013-01-07 04:01:01 <stealth222> circular includes can be a pain in the ass
226 2013-01-07 04:01:10 <andytoshi> how does walletdb.h depend on wallet.h? it seems like walletdb should be strictly lower-level
227 2013-01-07 04:01:31 <stealth222> agreed. the dependency could probably be eliminated. it's just the use of the CWalletTx class
228 2013-01-07 04:01:54 <stealth222> CWalletDB::WriteTx
229 2013-01-07 04:02:03 <andytoshi> can you forward declare it?
230 2013-01-07 04:02:11 <andytoshi> i'm not sure what the semantics are for reference parameters
231 2013-01-07 04:02:46 <andytoshi> oh :P it's actually used
232 2013-01-07 04:04:17 <stealth222> I certainly don't want to use main.h as the place to define shared types, andytoshi
233 2013-01-07 04:04:55 <andytoshi> fair enough
234 2013-01-07 04:05:05 <gladoscc> I recall that more readable addresses (eg emails) was one of the things on todo list
235 2013-01-07 04:05:07 <stealth222> main.h/main.cpp are the core implementation of the verification/block chain management piece
236 2013-01-07 04:05:20 <gladoscc> why not make a simple protocol for querying an address over http?
237 2013-01-07 04:05:32 <andytoshi> the Right Thing to Do would be to translate the DBError into a WalletError in wallet.cpp
238 2013-01-07 04:05:40 <andytoshi> to eliminate the use of the DBErrors enum
239 2013-01-07 04:05:46 <andytoshi> in wallet.h
240 2013-01-07 04:05:50 <gladoscc> eg: satoshidice.com:12345/lessthan512 -> 1diceFc2DeE ...
241 2013-01-07 04:06:15 <stealth222> yeah, probably, andytoshi
242 2013-01-07 04:06:41 <andytoshi> gladoscc: because that's an invitation to phishing and wrecks the trust model bitcoin is built on
243 2013-01-07 04:07:08 <andytoshi> stealth222: but of course, then you're losing the information in DBError, or duplicating it in WalletError
244 2013-01-07 04:07:17 <andytoshi> bleh, C++ can be awful sometimes
245 2013-01-07 04:07:22 <gladoscc> andytoshi: how?
246 2013-01-07 04:08:15 <andytoshi> gladoscc: because you've reduced the security inherent in a bitcoin address (it is a hash of a pubkey) to the security of HTTP
247 2013-01-07 04:08:38 <gladoscc> yes, but if the attacker compromises the HTTP site
248 2013-01-07 04:08:43 <gladoscc> then they can change the addresses on the page to theirs
249 2013-01-07 04:08:48 <gladoscc> it would be a client side lookup
250 2013-01-07 04:08:54 <andytoshi> ...or the attacker runs literally any router between you and the site
251 2013-01-07 04:08:55 <gladoscc> you enter a URL in bitcoin-qt, it tells you the address.
252 2013-01-07 04:09:05 <gladoscc> how else is it gonna worK?
253 2013-01-07 04:09:06 <andytoshi> that's a good point
254 2013-01-07 04:09:55 <Luke-Jr> gladoscc: there's a mailing list discussion about a new payment protocol
255 2013-01-07 04:10:24 <Luke-Jr> read that before piping in, IMO
256 2013-01-07 04:10:45 <andytoshi> gladoscc: there are secure ways to transfer addresses around, and it's dangerous for people to default to using http
257 2013-01-07 04:11:08 <andytoshi> generally if you are on a payment site, you've got HTTPS and everything going for you, like with traditional payments
258 2013-01-07 04:11:52 <stealth222> the only places that actually use that DBErrors return value from LoadWallet are init.cpp and test_bitcoin.cpp
259 2013-01-07 04:12:32 <andytoshi> stealth222: i think that LoadWallet belongs in walletdb.cpp
260 2013-01-07 04:12:40 <stealth222> yeah
261 2013-01-07 04:12:43 <andytoshi> it's a very thin wrapper around the CWalletDB constructor
262 2013-01-07 04:13:00 <andytoshi> that's what i'd do
263 2013-01-07 04:13:09 <stealth222> agreed
264 2013-01-07 04:14:29 <stealth222> CWalletDB already has a LoadWallet method
265 2013-01-07 04:14:52 <andytoshi> haha
266 2013-01-07 04:15:16 <andytoshi> yuck, it's totally different
267 2013-01-07 04:16:25 <andytoshi> ...oh, no, the CWallet one is a wrapper of the CWalletDB one
268 2013-01-07 04:18:09 <stealth222> yeah, it's pretty tricky to disentangle wallet from walletdb
269 2013-01-07 04:18:42 <andytoshi> i'd like to say, replace pwalletMain = new CWallet("wallet.dat");
270 2013-01-07 04:19:14 <andytoshi> with pwalletMain = new CWallet (new CWalletDB(), "wallet.dat"); or something
271 2013-01-07 04:19:34 <andytoshi> but that's ugly and allocates memory that nobody owns
272 2013-01-07 04:20:08 <stealth222> yeah, I sorta did something similar in pull request 2124 - I created a global structure that owns wallet instances
273 2013-01-07 04:20:16 <andytoshi> oh, never mind, add a getter in CWallet for the internal CWalletDB, and replace
274 2013-01-07 04:20:27 <andytoshi> DBErrors nLoadWalletRet = pwalletMain->LoadWallet(fFirstRun);
275 2013-01-07 04:20:29 <andytoshi> with
276 2013-01-07 04:20:34 <andytoshi> DBErrors nLoadWalletRet = pwalletMain->GetWalletDB()->LoadWallet(fFirstRun);
277 2013-01-07 04:20:54 <andytoshi> no, that's gross because you're using a getter then modifying the state with it
278 2013-01-07 04:21:09 <andytoshi> i dunno, i'm going to bed
279 2013-01-07 04:21:11 <andytoshi> have fun :)
280 2013-01-07 04:21:13 <stealth222> lol
281 2013-01-07 04:21:20 <stealth222> goodnight
282 2013-01-07 05:11:50 <stealth222> the usage of pchMessageStart is a bad idea :)
283 2013-01-07 05:12:22 <stealth222> different components, like the database and protocol handlers, should be initialized with a particular set of magic bytes
284 2013-01-07 05:12:39 <stealth222> and none of them should rely on a global defined in main.cpp
285 2013-01-07 05:27:00 <gmaxwell> stealth222: having per network magic is handy, it ensures you don't get data from different networks mixed up.. and also using the same one avoids the trouble of finding multiple good values. (ones that are emulation resistant)
286 2013-01-07 05:27:38 <stealth222> right, hence the ability to initialize the components with different magic bytes depending on network
287 2013-01-07 05:28:09 <stealth222> that's what I meant
288 2013-01-07 05:28:34 <stealth222> point is, the different components should not rely on a global variable externed via main.h
289 2013-01-07 05:30:02 <stealth222> for instance, the CAddrDB class could have a private member set to this in its constructor
290 2013-01-07 06:05:06 <stealth222> separating all these pieces out will also make unit testing a whole heck of a lot simpler
291 2013-01-07 06:13:02 <stealth222> I removed dependencies of db.cpp on main.h: http://108.60.150.142/bitcoindoc/dependencycleanup/html/db_8cpp.html
292 2013-01-07 06:14:08 <stealth222> here's what the graph used to look like: http://108.60.150.142/bitcoindoc/html/db_8cpp.html
293 2013-01-07 06:22:08 <gmaxwell> stealth222: you just broke testnet with that patch, congrats. :P
294 2013-01-07 06:22:21 <stealth222> did I?
295 2013-01-07 06:22:41 <gmaxwell> It has a different version string.
296 2013-01-07 06:22:48 <stealth222> I know - it gets initialized
297 2013-01-07 06:23:15 <stealth222> look in init.cpp line 901
298 2013-01-07 06:23:21 <gmaxwell> Ah??? then why give it a default value? the string shouldn't be repeated in the code.
299 2013-01-07 06:23:36 <stealth222> I could remove the default value
300 2013-01-07 06:25:18 <stealth222> now it gets initialized to 0x00000000
301 2013-01-07 06:47:49 <stealth222> why is the pull-tester giving me this error? util.cpp:955:46: error: 'struct boost::filesystem::basic_path<std::basic_string<char>, boost::filesystem::path_traits>::string_type' has no member named 'string'
302 2013-01-07 06:48:05 <stealth222> for pull request 2124
303 2013-01-07 06:48:19 <stealth222> it builds fine on my systems
304 2013-01-07 06:48:24 <stealth222> differences in boost library?
305 2013-01-07 06:48:58 <stealth222> I see a string method here: http://www.boost.org/doc/libs/1_52_0/boost/filesystem/path.hpp
306 2013-01-07 07:02:20 <sipa> stealth222: there is boost filesystem v2 and v3, and they are incompatible
307 2013-01-07 07:02:38 <stealth222> argh
308 2013-01-07 07:02:48 <stealth222> so how to fix that?
309 2013-01-07 07:03:11 <sipa> check how to do what you want in the old codr
310 2013-01-07 07:03:33 <sipa> and either use something that works in both
311 2013-01-07 07:03:44 <sipa> or use an #ifdef...
312 2013-01-07 07:05:29 <sipa> btw, calling rpcconvert from inside an rpc method is wrong: rpcconvert is part of the cli rpc client, while the rpc method runs serverside
313 2013-01-07 07:05:59 <sipa> you expect rpc clients to send correctly-formatted values
314 2013-01-07 07:06:48 <stealth222> aren't all rpc requests sent as strings?
315 2013-01-07 07:07:39 <sipa> no, not at all
316 2013-01-07 07:08:04 <BTCOxygen> gmaxwell: hi
317 2013-01-07 07:08:08 <BTCOxygen> gmaxwell: you here?
318 2013-01-07 07:08:18 <sipa> the rpc client parses arguments, and sends them fully structured to the server
319 2013-01-07 07:08:43 <BTCOxygen> Say for example
320 2013-01-07 07:08:52 <BTCOxygen> I have a Wallet on Computer A
321 2013-01-07 07:09:02 <BTCOxygen> and a copy of that on Computer B
322 2013-01-07 07:09:02 <stealth222> so then we need to add stuff to CommandLineRPC to deal with usewallet?
323 2013-01-07 07:09:21 <BTCOxygen> I send bitcoins only from Computer A
324 2013-01-07 07:09:39 <sipa> rpcconvertarguments needs magic tov deal with usewallet
325 2013-01-07 07:09:49 <stealth222> I could just move that code from usewallet to CommandLineRPC
326 2013-01-07 07:09:51 <BTCOxygen> And only watch Transactions from Computer B, Also i have never sent a transaction from Computer B
327 2013-01-07 07:10:08 <BTCOxygen> All my transactions are sent from Computer A
328 2013-01-07 07:10:08 <stealth222> or could use RPCConvertValues, yeah
329 2013-01-07 07:10:23 <sipa> yeah
330 2013-01-07 07:10:32 <BTCOxygen> Why does the Wallet on Computer B not match the wallet on Computer A after some time?
331 2013-01-07 07:10:36 <BTCOxygen> Any idea?
332 2013-01-07 07:11:02 <sipa> BTCOxygen: because both computers generate new addresses
333 2013-01-07 07:11:19 <sipa> for change
334 2013-01-07 07:11:44 <sipa> and as those are random, they will not generate the same ones
335 2013-01-07 07:12:26 <sipa> initially, they will use key pool addresses, which was copied along
336 2013-01-07 07:13:31 <sipa> but after by default 100 new keys, they won't be looking for the same addresses anymore
337 2013-01-07 07:13:58 <sipa> to do what you want, you need deterministic addresses
338 2013-01-07 07:14:34 <petertodd> are deterministic addresses on the roadmap for the satoshi client?
339 2013-01-07 07:14:55 <sipa> yes
340 2013-01-07 07:15:05 <sipa> see BIP 3
341 2013-01-07 07:15:17 <sipa> BIP 32, i mean
342 2013-01-07 07:16:01 <petertodd> yeah, I've been following that, I mean, are you guys thinking 0.8 possibly, 0.9?
343 2013-01-07 07:17:56 <sipa> 0.8 is too optimistic, i think
344 2013-01-07 07:18:48 <petertodd> figures, I haven't seen any related pull requests
345 2013-01-07 07:19:36 <sipa> it's not even fully implemented yet
346 2013-01-07 07:20:19 <sipa> i've asked Hal to take a look at it last month, but haven't heard back from him yet
347 2013-01-07 07:21:47 <petertodd> ah, vetting the crypto. are there any p2sh-related plans for it as well? I noticed the bip doesn't mention any of that
348 2013-01-07 07:24:37 <sipa> they're unrelated
349 2013-01-07 07:24:56 <sipa> bip32 just specifies how to generate keys
350 2013-01-07 07:25:30 <sipa> what you do with those keys is up to the application, i suppose
351 2013-01-07 07:26:09 <petertodd> ah, I see, so eventual wallet standardization is a next step
352 2013-01-07 07:26:33 <sipa> how do you mean?
353 2013-01-07 07:29:00 <petertodd> just the nitty gritty details of stuff like standards for how to combine BIP32-created keys into multisig addresses, for instance standardizing the order of keys in p2sh multisig
354 2013-01-07 07:30:48 <sipa> iirc alan reiner has been thinking/writing about that on the forum
355 2013-01-07 07:35:49 <petertodd> thanks, yeah I was thinking of doing up a simple 2-of-3 transaction signer to run on a separate computer for my latest project
356 2013-01-07 07:36:46 <petertodd> I'm still kinda surprised none of the services out there have bothered doing any of this stuff
357 2013-01-07 08:33:52 <stealth222> sipa: https://github.com/CodeShark/bitcoin/commit/74228a2228544556dc4822a154eac7f7c0331da4
358 2013-01-07 15:54:35 <jgarzik> gmaxwell: Daemon author Daniel Suarez mentioned you: https://plus.google.com/111341398160608381865/posts/dPFfy2ds7R5
359 2013-01-07 15:54:59 <gmaxwell> Very cool.
360 2013-01-07 16:03:25 <gavinandresen> we should try to get him to speak at the conference
361 2013-01-07 16:05:10 <kinlo> when is the next conference?
362 2013-01-07 16:06:12 <gavinandresen> kinlo: see http://www.bitcoin2013.com/ May 17-19
363 2013-01-07 16:06:42 <kinlo> shouldn't there be some kind of link on the official home page?
364 2013-01-07 16:06:54 <kinlo> anyway, too far away for me
365 2013-01-07 16:07:06 <gavinandresen> kinlo: conference is soft-launched right now, to round up speakers/panelists/etc
366 2013-01-07 16:07:11 <upb> is it organzied by bruce wagner?
367 2013-01-07 16:07:12 <kinlo> ic
368 2013-01-07 16:07:24 <gavinandresen> when the program is more set and you can actually sign up and pay there will be a bigger push
369 2013-01-07 16:07:43 <gavinandresen> upb: no, not organized by bruce.
370 2013-01-07 16:08:05 <gavinandresen> organized by Lindsay, who has experience with organizing conferences....
371 2013-01-07 16:08:22 <kinlo> well, CA is a bit too far away for me anyway
372 2013-01-07 16:08:46 <sipa> i'll try to get there
373 2013-01-07 16:09:05 <gavinandresen> sipa: awesome!
374 2013-01-07 16:09:07 <kinlo> yeah, but you're more involved :)
375 2013-01-07 16:09:21 <kinlo> it's a bit much to pay :)
376 2013-01-07 16:09:58 <gavinandresen> sipa: Google World Headquarters is close, you and Mike should figure out an excuse to go visit the mothership
377 2013-01-07 16:26:37 <gavinandresen> jgarzik: you don't happen to know Daniel Suarez personally, do you?
378 2013-01-07 16:40:43 <jgarzik> gavinandresen: kinda sorta not really
379 2013-01-07 16:41:51 <jgarzik> gavinandresen: I promoted his first book Daemon heavily on my blog/twitter/etc. because I was so taken with it. Since then, I comment semi-frequently on his twitter/G+
380 2013-01-07 16:42:08 <jgarzik> gavinandresen: so personally, no. but he did send me a free book once :)
381 2013-01-07 16:42:28 <gavinandresen> jgarzik: cool. I cc'ed you on an email to Lindsay RE: asking him to come to the conference
382 2013-01-07 16:42:52 <jgarzik> gavinandresen: he might be up for it. he's into disruptive technologies
383 2013-01-07 16:43:36 <gavinandresen> it'd be fun to meet him, Daemon is the best sci-fi book i've read in a long time
384 2013-01-07 16:44:43 <helo> sold!
385 2013-01-07 16:59:19 <TD> yeah i'd hope that the conference can move around the world
386 2013-01-07 16:59:57 <TD> ACTION -> out
387 2013-01-07 18:58:35 <MC1984> hey whats the DNS name of where bitcoin tries to connect for irc peer discovery
388 2013-01-07 18:59:54 <sroecker> imho, it doesn't anymore except when you configure bitcoind to do it
389 2013-01-07 19:00:02 <sroecker> but irc.lfnet.org #bitcoin
390 2013-01-07 19:00:44 <MC1984> what port
391 2013-01-07 19:01:07 <MC1984> is that the same server that testnet uses?
392 2013-01-07 19:02:13 <sroecker> normal irc port 6667
393 2013-01-07 19:06:05 <MC1984> 67.215.65.132
394 2013-01-07 19:06:34 <MC1984> thats irc.lfnet.org 6667 right
395 2013-01-07 19:07:54 <jurov> hello, can aomeone help me with bitcoind keypoolrefill ?
396 2013-01-07 19:08:17 <jurov> it won't show error, but "keypoolsize" remains 101
397 2013-01-07 19:08:39 <sroecker> MC1984: should be multiple servers (round robin(
398 2013-01-07 19:08:47 <gmaxwell> jurov: it's full tada.
399 2013-01-07 19:09:04 <jurov> so what should i do?
400 2013-01-07 19:09:33 <gmaxwell> jurov: What are you trying to do?
401 2013-01-07 19:09:52 <jurov> first. getnewaddress returns "Keypool ran out, please call keypoolrefill first." error
402 2013-01-07 19:10:19 <jurov> so i am trying to do as it says, but without effect.
403 2013-01-07 19:10:32 <jurov> version 7.0.1
404 2013-01-07 19:10:47 <jurov> bitcoind
405 2013-01-07 19:10:54 <gmaxwell> Do you use wallet encryption?
406 2013-01-07 19:11:22 <jurov> yes, i have to put walletpassphrase before keypoolrefill
407 2013-01-07 19:13:14 <jurov> i think it is 101 not 100 cause i have imported 1 additional privkey
408 2013-01-07 19:15:31 <MC1984> k so i can connect to irc.lfnet.org #bitcoin with this client (room is empty)
409 2013-01-07 19:15:42 <sipa> #bitcoin isn't used
410 2013-01-07 19:15:48 <MC1984> but i cannot sync the testnet on any computers on my network
411 2013-01-07 19:15:51 <sipa> mainnet uses #bitcoin00 - #bitcoin99
412 2013-01-07 19:16:00 <sipa> testnet uses #bitcoinTEST
413 2013-01-07 19:16:14 <sipa> well, uses - it's been off by default since 0.6.0
414 2013-01-07 19:16:18 <sipa> for mainnet
415 2013-01-07 19:16:29 <jurov> anyone? pls, it's urgent, i need pregenerate the addresses for new user registrations
416 2013-01-07 19:17:19 <sipa> jurov: just a sec
417 2013-01-07 19:18:20 <sipa> jurov: so what happens if you run keypoolrefill?
418 2013-01-07 19:18:26 <jurov> nothing
419 2013-01-07 19:19:04 <sipa> you can force a larger keypool by starting with the -keypool=N option
420 2013-01-07 19:20:05 <MC1984> ok #bitcoin00 is empty and bitcointest has what looks like 8 nodes in it
421 2013-01-07 19:20:18 <jurov> ok, restarting, we'll see...
422 2013-01-07 19:20:40 <MC1984> yet bitoin cant do irc discovery, i am confounded
423 2013-01-07 19:21:10 <sipa> there may be a problem with the irc server
424 2013-01-07 19:21:14 <sipa> gmaxwell: you know more?
425 2013-01-07 19:22:02 <gmaxwell> sipa: I don't think so now.
426 2013-01-07 19:22:15 <sipa> MC1984: maybe there are just very very little testnet nodes
427 2013-01-07 19:22:17 <gmaxwell> MC1984: it's not really empty, they disable who on connect, so you have to who manually.
428 2013-01-07 19:22:39 <gmaxwell> testnet is another channel. and there are few testnet nodes. but my own logs show it discoverting fine.
429 2013-01-07 19:23:44 <MC1984> im baffled
430 2013-01-07 19:25:01 <jurov> now keypoolrefill/getnewaddress works, thanks!
431 2013-01-07 19:25:19 <sipa> jurov: it should have worked before as well
432 2013-01-07 19:25:21 <gmaxwell> MC1984: can you join, from that network, #bitcoinTEST3 (note the 3) and then do a /who #bitcoinTEST3 ?
433 2013-01-07 19:25:45 <sipa> jurov: can you tell me how long it had been running, and what kind of RPCs you sent to it before?
434 2013-01-07 19:26:09 <jurov> sipa, maybe it's the imported address. try whether it can't be reproduced by importing addy and then exhausting keypool
435 2013-01-07 19:26:25 <MC1984> the /who command didnt seem to do anything
436 2013-01-07 19:26:42 <MC1984> wait yes it did
437 2013-01-07 19:26:46 <MC1984> in the server window
438 2013-01-07 19:27:16 <MC1984> #bitcoinTEST3 u5gAbVwRGV 115.Red-83-55-122.dynamicIP.rima-tde.net giraffe.heliacal.net u5gAbVwRGVASknX H :1 u5gAbVwRGVASknX
439 2013-01-07 19:27:17 <MC1984> etc
440 2013-01-07 19:27:35 <jurov> sipa, in fact my machine crashed today. but I did not call getnewaddress long before that . i used it only to send/receive
441 2013-01-07 19:28:07 <MC1984> if my irc client can do that why cant bitcoin :|||||||
442 2013-01-07 19:30:03 <Diapolo> You are seeing 2013-01-07 20:29:55 ThreadIRCSeed started
443 2013-01-07 19:30:39 <Diapolo> Well I have a IRC connect failed message with my testnet3 node ;).
444 2013-01-07 19:31:02 <MC1984> connection timeout
445 2013-01-07 19:31:10 <Diapolo> indeed, same here
446 2013-01-07 19:31:13 <sipa> i can't connect to irc.lfnet.org from my client either
447 2013-01-07 19:31:25 <MC1984> IM NOT GOING MAD
448 2013-01-07 19:33:05 <grau> BlueMatt: are you here?
449 2013-01-07 19:35:35 <grau> sipa: Did you use the BlueMatt blocktester ?
450 2013-01-07 19:35:57 <sipa> grau: it's ran automatically on all pull requests
451 2013-01-07 19:36:44 <grau> do you know how it actually checks bitcoind? WHat I see from code that it creates a sophisticated blockchain
452 2013-01-07 19:36:58 <grau> but do not see how it checks if bitcoind processes it correctly
453 2013-01-07 19:37:16 <sipa> i'm not familiar with the code myself
454 2013-01-07 19:37:32 <grau> I am asking what it does
455 2013-01-07 19:37:37 <grau> not how
456 2013-01-07 19:38:25 <gmaxwell> grau: I think it just queries to make sure bitcoin is on the correct best block.
457 2013-01-07 19:38:53 <sipa> it connects via P2P to a (patched) bitcoind, sends it blocks, and requests blocks back
458 2013-01-07 19:39:09 <gmaxwell> sipa: I'm still seeing IRC on my testnet node.
459 2013-01-07 19:39:21 <grau> ok, so to summarize what I see. It creates a complicated block scenario and at every step or end asks bitcoind what is the trunk head
460 2013-01-07 19:39:34 <sipa> i suppose, yes
461 2013-01-07 19:39:49 <grau> This is much less than I proposed to do yesterday and I got yelled down.
462 2013-01-07 19:40:27 <gmaxwell> ...
463 2013-01-07 19:40:28 <sipa> grau: i think you misunderstood me then; i'm very much in favor of you building something similar using bitsofproof and that story system
464 2013-01-07 19:40:53 <sipa> grau: but it's not a replacement for testing with an already existing alternate implementation of such a thing
465 2013-01-07 19:41:08 <gmaxwell> grau: I think we're failing to communicate. Because the yelling down was only because we thought you were proposing to rewrite it instead of just running it.
466 2013-01-07 19:41:21 <sipa> every testing tool is welcome
467 2013-01-07 19:41:32 <grau> thanks. I feel better now
468 2013-01-07 19:41:42 <grau> I did not ment to do less but more.
469 2013-01-07 19:41:43 <gmaxwell> If you want to run it _and_ write something more??? especially something that can run on multiple implementations??? thats great!
470 2013-01-07 19:42:24 <gmaxwell> (multiple implementations is important not just because I want to benefit from your work, but its important so the results can be compared)