1 2012-10-09 02:36:03 <jgarzik> let's see how long -reindex takes, now that it stuffs everything into a big bdb transaction ;-)
2 2012-10-09 02:36:35 <jgarzik> ACTION thinks sipa's "do it within the environment" will take significantly longer than rm "blkindex.dat" ;p
3 2012-10-09 02:36:48 <jgarzik> if it doesn't blow up on some BDB transaction size limit
4 2012-10-09 02:43:54 <Luke-Jr> jgarzik: it probably will - even large reorgs hit limits there
5 2012-10-09 04:45:12 <sipa> jgarzik: heh?
6 2012-10-09 10:56:21 <jgarzik> the forum is such a clown circus
7 2012-10-09 10:56:26 <jgarzik> now Nefario has a scammer tag
8 2012-10-09 10:56:37 <jgarzik> and there is a lot thread about giving one to theymos as well
9 2012-10-09 10:59:19 <kjj_> I'm not sure that Nefario deserves one. Theymos almost certainly does not.
10 2012-10-09 10:59:56 <kjj_> the forum has a whole new english. words there don't mean what they mean in the real world
11 2012-10-09 11:02:36 <epscy> it's a hive of scum and villainy all right
12 2012-10-09 11:02:42 <epscy> why i like it
13 2012-10-09 11:03:24 <kjj_> it doesn't help that the community is made up of bitcoin enthusiasts trying to create businesses that they don't know how to run
14 2012-10-09 11:25:15 <epscy> kjj_: makes for some great drama though
15 2012-10-09 11:55:25 <jgarzik> kjj_: yep
16 2012-10-09 11:55:41 <jgarzik> kjj_: kids with more ambition than legal sense or business experience
17 2012-10-09 11:58:18 <edcba> or programming experience
18 2012-10-09 11:58:48 <drizztbsd> programming experience ftw
19 2012-10-09 11:58:57 <helo> would it be a bad thing to allow different crypto schemes to coexist?
20 2012-10-09 11:59:19 <helo> e.g. lamport signatures alongside ecdsa
21 2012-10-09 11:59:28 <edcba> oh in scripts
22 2012-10-09 11:59:33 <edcba> no it wouldn't
23 2012-10-09 12:00:00 <edcba> that was also the aim of scripts too i think
24 2012-10-09 12:00:53 <edcba> ACTION google lamport signatures
25 2012-10-09 12:01:03 <helo> it would be unhealthy for the blockchain to allow lamport sigs freely because of their size
26 2012-10-09 12:01:08 <edcba> http://en.wikipedia.org/wiki/Lamport_signature
27 2012-10-09 12:02:22 <edcba> ...sign only a single message, seems ok until now
28 2012-10-09 12:02:38 <Luke-Jr> helo: maybe charge more realistic fees for lamport
29 2012-10-09 12:02:51 <Luke-Jr> edcba: it'd need to enforce one-time-use addresses
30 2012-10-09 12:03:07 <Luke-Jr> (which is already advisable)
31 2012-10-09 12:03:39 <edcba> 8kb...
32 2012-10-09 12:03:44 <helo> if a qc-safe signature scheme like lamport was permitted with the right restrictions, people could park large coin in them for extended storage
33 2012-10-09 12:03:49 <edcba> yeah looks like a bit big :)
34 2012-10-09 12:04:37 <jgarzik> gah
35 2012-10-09 12:04:50 <jgarzik> It's embarrassing when pynode's IBD is faster than bitcoind's IBD
36 2012-10-09 12:05:01 <helo> if just two fundamentally different schemes were available, it could make people feel much more secure if some cryptanalysis yeilds a weakness on ecdsa
37 2012-10-09 12:05:17 <edcba> ok i didn't really understand everything but looks like interesting signature scheme
38 2012-10-09 12:05:43 <helo> it would be nice to introduce an alternative scheme now, while there isn't any pressure
39 2012-10-09 12:05:52 <edcba> you can with script
40 2012-10-09 12:06:04 <edcba> you can introduce rot13 scheme
41 2012-10-09 12:06:09 <Luke-Jr> jgarzik: are you really surprised? :P
42 2012-10-09 12:06:14 <helo> i don't think you can... a lot of ops aren't enabled
43 2012-10-09 12:06:17 <edcba> and other wonderful scheme like that
44 2012-10-09 12:06:27 <edcba> what !
45 2012-10-09 12:09:33 <Eliel_> what is IBD short for? Isomething Block Database?
46 2012-10-09 12:09:42 <helo> initial block download
47 2012-10-09 12:09:53 <helo> *blockchain
48 2012-10-09 12:10:16 <BlueMatt> jgarzik: in what way? (-loadblock/lan node/public p2p) multithreaded sigchecking, etc?
49 2012-10-09 12:12:18 <jgarzik> BlueMatt: both are via network
50 2012-10-09 12:12:33 <jgarzik> BlueMatt: both are vanilla git HEAD, which excluded M-T sigchecking
51 2012-10-09 12:12:46 <BlueMatt> does pynode do m-t sigchecking?
52 2012-10-09 12:12:51 <jgarzik> no
53 2012-10-09 12:13:24 <BlueMatt> so...the improvement is just doing a sane ibd download algorithm? (multi-peer/etc)
54 2012-10-09 12:14:02 <BlueMatt> (and Im assuming you used the same set of nodes/equivalent set for both)
55 2012-10-09 12:14:22 <drizztbsd> you can download the block from http
56 2012-10-09 12:14:33 <BlueMatt> ACTION facepalm
57 2012-10-09 12:14:56 <drizztbsd> bitcoin 0.7.0 has the check functionality
58 2012-10-09 12:16:40 <BlueMatt> the point of running a benchmark isnt to download fast, its to compare in some given setting...
59 2012-10-09 13:54:32 <jgarzik> wow
60 2012-10-09 13:54:34 <jgarzik> 35aba798
61 2012-10-09 13:54:38 <jgarzik> never hit that before
62 2012-10-09 13:54:49 <jgarzik> it is due to bitcoind's IBD taking >24 hours
63 2012-10-09 13:54:58 <jgarzik> ACTION hopes no wallet transactions were in there
64 2012-10-09 13:55:21 <OneEyed> Shouldn't it not store memory pool transactions while being far behind the blockchain top?
65 2012-10-09 13:55:52 <jgarzik> <shrug>
66 2012-10-09 13:56:27 <sipa> yeah, i think just about all mempool stuff can be disabled while in IBD
67 2012-10-09 13:57:28 <OneEyed> Except those related to the bitcoind wallet or injected through RPC
68 2012-10-09 13:58:01 <OneEyed> jgarzik: even if related to the wallet, they should have been at least propagated to peers, right?
69 2012-10-09 13:59:29 <gmaxwell> It could be disabled but.. unless it's a performance problem, why bother?
70 2012-10-09 14:02:43 <OneEyed> gmaxwell: you probably take more time to handle a new block, since I guess you check if transactions must be removed from mempool. It's not much per block, but after the memory pool is full and the block number increases, it starts to add. It will probably increase the memory pressure even more.
71 2012-10-09 14:03:22 <jgarzik> orphans are capped at 10,000
72 2012-10-09 14:03:30 <jgarzik> don't think mempool has a cap
73 2012-10-09 14:06:49 <jgarzik> someone who gave up on running a full node due to IBD: https://bitcointalk.org/index.php?topic=117216.msg1258952#msg1258952
74 2012-10-09 14:07:05 <TD> ouch, poor nefario
75 2012-10-09 14:07:27 <TD> on the other hand, it was inevitable. he must have been warned previously
76 2012-10-09 14:07:28 <jgarzik> maybe 0.7.1 is being too cautious, and we should adopt ultraprune ASAP, to release 0.8 more quickly, to forestall the loss of full nodes
77 2012-10-09 14:07:43 <jgarzik> TD: the scammer tag on Nefario is just silly
78 2012-10-09 14:07:50 <jgarzik> TD: the legal troubles... entirely predictable
79 2012-10-09 14:08:18 <gavinandresen> he won't be the last bitcoiner to get stuck in the legal swamp
80 2012-10-09 14:08:19 <TD> i'd like to see ultraprune reviewed and merged ASAP but it's up to gavin. i guess we can help by reviewing the patch, although it's huuuuge
81 2012-10-09 14:08:34 <TD> i started until i realized reviewing commits in isolation is a waste of time
82 2012-10-09 14:08:50 <TD> then i switched to chewing through matts changes to make bitcoinj fully validating
83 2012-10-09 14:09:28 <TD> and yes. legal swamps abound. in future i'd like to see tutorials, libraries etc to help people build truly P2P solutions right from the start
84 2012-10-09 14:09:33 <jgarzik> yeah for ultraprune, reviewing as One Big Diff helps
85 2012-10-09 14:09:49 <TD> there are too many people who just default to "make a web app, charge some fees, run a company" as the solution to any problem
86 2012-10-09 14:09:58 <jgarzik> yep
87 2012-10-09 14:11:04 <jgarzik> gavinandresen: do you have a 0.7.1 list tagged in github issues, or anything like that?
88 2012-10-09 14:11:10 <jgarzik> gavinandresen: could we do a 0.7.1rc1 today?
89 2012-10-09 14:11:52 <gavinandresen> jgarzik: yes, I created a 0.7.1 milestone, and yes, lets to a 0.7.1rc1 today
90 2012-10-09 14:13:21 <sipa> jgarzik: for ultraprune i actually tried to make sure all commits are more or less standalone changes, to make reviewing easier (and not do things like code movement, for exmaple)
91 2012-10-09 14:13:28 <sipa> but i guess it's just too much
92 2012-10-09 14:14:25 <jgarzik> sipa: just need to get the base package of database + database index changes in bitcoin.git/master, then changes should flow much easier I think
93 2012-10-09 14:15:07 <jgarzik> major changes always create a backlog somewhere :/ Nothing to do but get the basics into the upstream tree rapidly
94 2012-10-09 14:15:41 <sipa> true, maybe i should have waited doing several of the extra optimizations afterwards in the same branch
95 2012-10-09 14:15:52 <sipa> but then again, i had time back then, and don't have too much time now :)
96 2012-10-09 14:16:30 <gavinandresen> jgarzik: by the way, the peers.dat pchMessageStart issue was a red herring (I need to update the testnet3 testnet-in-a-box.zip on Sourceforge)
97 2012-10-09 14:17:06 <jgarzik> gavinandresen: it highlighted a minor bug that wanted fixing anyway, so it's a positive thing regardless
98 2012-10-09 14:18:48 <gavinandresen> ok, pulled "handle corrupt wallets better", I spent time yesterday testing that agai
99 2012-10-09 14:19:06 <sipa> jgarzik, gavinandresen: would it help if i wrote down a summary of the major infrastructure changes that the ultraprune branch has?
100 2012-10-09 14:19:07 <jgarzik> cool, that will make fixing -reindex easier
101 2012-10-09 14:19:28 <gavinandresen> sipa: sure, a high-level design doc would be very helpful
102 2012-10-09 14:19:33 <jgarzik> sipa: probably, yes
103 2012-10-09 14:19:47 <sipa> i started writing a document with the details of the encodings as well, but haven't finished that
104 2012-10-09 14:20:35 <gavinandresen> sipa: be sure to include a section on upgrade/downgrade issues, those are always easy to forget until users start, you know, running old versions of bitcoin because they click on the wrong thing....
105 2012-10-09 14:21:01 <sipa> gavinandresen: the ultraprune pull request and commit message are quite extensive already, but give more of an idea, not implementation details
106 2012-10-09 14:21:02 <gavinandresen> sipa: a test plan would also be helpful, I think.
107 2012-10-09 14:21:29 <sipa> oh, by the way: i have been mining with ultraprune for 1.5 weeks now, and have actually found a block with it
108 2012-10-09 14:22:17 <MC1984> damn, instant couple hundred dollar
109 2012-10-09 14:22:19 <MC1984> nice
110 2012-10-09 14:22:28 <sipa> MC1984: on p2pool, unfortunately :)
111 2012-10-09 14:22:44 <MC1984> ah well its all good
112 2012-10-09 14:22:47 <sipa> i got like 0.3 BTC from it
113 2012-10-09 14:22:57 <TD> hah
114 2012-10-09 14:23:08 <TD> i've been using ultraprune on my laptop too
115 2012-10-09 14:23:16 <sipa> TD: any more issues?
116 2012-10-09 14:23:19 <MC1984> very rarely do open source devs code directly spit money at them at all
117 2012-10-09 14:23:21 <TD> other than the time it got itself hopelessly corrupted and i had to resync from the network, no issues
118 2012-10-09 14:23:29 <TD> :)
119 2012-10-09 14:23:36 <TD> but that failure mode is not new
120 2012-10-09 14:23:53 <TD> it'd be nice to have a flag to reprocess all the blk dat files though, so at least you can recover without downloading from remote peers
121 2012-10-09 14:24:18 <sipa> TD: jgarzik's -reindex intends to do that
122 2012-10-09 14:25:01 <jgarzik> sipa: does the ultraprune forum post or any existing contain a "rationale"? i.e. not necessarily defining the high level design, but describing the problems being solved by the design
123 2012-10-09 14:25:07 <jgarzik> *any existing doc
124 2012-10-09 14:25:30 <sipa> i've been writing several things about it in several stages
125 2012-10-09 14:25:49 <sipa> but i'm not sure whether i've covered all of it
126 2012-10-09 14:25:50 <jgarzik> gavinandresen: Day job will likely prevent -reindex completion in time for rc1
127 2012-10-09 14:26:15 <gavinandresen> jgarzik: I assumed that, no problem.
128 2012-10-09 14:26:37 <jgarzik> things I think we desperately need in 0.8, to keep users from abandoning full nodes for web wallets: ultraprune, wallet logdb, better peer selection/rotation
129 2012-10-09 14:27:15 <jgarzik> add client mode to the list, and that sounds like bitcoin 1.0
130 2012-10-09 14:27:32 <jgarzik> (client mode obviously not 0.8 material, just to be clear)
131 2012-10-09 14:28:16 <sipa> jgarzik: btw, ultraprune's database changes include adding a flag field to the block index, which contains information about the degree of verification that block has
132 2012-10-09 14:28:37 <sipa> jgarzik: so it should be able to support things like multi-stage downloading/processing, headers-first mode, or headers-only mode
133 2012-10-09 14:28:56 <jgarzik> sipa: wallet already stores full merkle branch, right? (just to confirm)
134 2012-10-09 14:29:00 <sipa> yes
135 2012-10-09 14:29:10 <sipa> CWalletTx inherits from CMerkleTx
136 2012-10-09 14:29:32 <helo> client mode is somewhat like electrum?
137 2012-10-09 14:29:39 <TD> no
138 2012-10-09 14:29:42 <sipa> helo: HELL NO
139 2012-10-09 14:29:43 <TD> like multibit
140 2012-10-09 14:29:46 <jgarzik> ACTION watches helo troll gmaxwell ;-)
141 2012-10-09 14:29:47 <sipa> electrum is not a node
142 2012-10-09 14:30:25 <gmaxwell> hah.
143 2012-10-09 14:31:14 <sipa> afk
144 2012-10-09 14:31:46 <jgarzik> post ultraprune, was primarily thinking of wallet birthdays (#1863) in the context of client mode... simply go headers only until wallet birthday.
145 2012-10-09 14:32:20 <jgarzik> the main issue is uncommon events requiring a full rescan, like key import
146 2012-10-09 14:33:18 <gavinandresen> I don't care if key import is slow-- it should be a rare event. Importing multiple keys at once should be supported, though, so just one scan is needed.
147 2012-10-09 14:33:20 <gmaxwell> jgarzik: I think 1.0 also needs wallet + backend seperation so people can run just one backend and many wallets (useful for merchants, VPSes, privacy), and allows you to e.g. use a wallet remotely like a thin client off your own full node. Running one node is no big deal, running N nodes, even SPV ones, for N uses of bitcoin is a bit obnoxious, and a lack of support for that promotes thin/web clients.
148 2012-10-09 14:33:38 <gavinandresen> (I do like the idea of "key birthdays", too....)
149 2012-10-09 14:33:53 <gmaxwell> Yea, key birthdays are kind of a no brainer win.
150 2012-10-09 14:34:00 <TD> bitcoinj already does it
151 2012-10-09 14:34:02 <TD> it definitely helps
152 2012-10-09 14:34:08 <jgarzik> I think I stole the idea from bitcoinj
153 2012-10-09 14:34:18 <TD> well getheaders was there since v0.1 right?
154 2012-10-09 14:34:19 <TD> i think
155 2012-10-09 14:34:27 <TD> so it was part of satoshis plan all along
156 2012-10-09 14:34:38 <jgarzik> gmaxwell: support the idea -- but I think that's beyond 1.0 land, in terms of dev process
157 2012-10-09 14:34:56 <jgarzik> gmaxwell: I don't think Satoshi wanted 'perfect' for 1.0, just full node | client mode
158 2012-10-09 14:35:24 <epscy> what is a key birthday
159 2012-10-09 14:35:26 <gmaxwell> (not to mention the security implications, I'm still a little horrified by inbound connections from the internet to a process that has the private keys in memory)
160 2012-10-09 14:35:47 <jgarzik> gmaxwell: shall we import fork from cygwin, for windows? :)
161 2012-10-09 14:36:10 <gmaxwell> jgarzik: yea, well... fine enough version defintions are whatever. In my mind if software never got another feature beyond 1.0 the world wouldn't care much. But thats a pretty different definition.
162 2012-10-09 14:36:33 <jgarzik> TD: no, getheaders was more recent
163 2012-10-09 14:36:43 <gavinandresen> All righty, any objections to me tagging current git HEAD as 0.7.1 ?
164 2012-10-09 14:36:47 <gmaxwell> jgarzik: in windows you'd run 'bitcoind' as a service, then startup the wallet as required. (and if bitcoind is not running, the wallet would just fire it up)
165 2012-10-09 14:36:48 <jgarzik> ACTION goes to check the hist
166 2012-10-09 14:37:07 <gmaxwell> ACTION looks
167 2012-10-09 14:37:10 <gavinandresen> (well, after one final commit that bumps version numbers)
168 2012-10-09 14:38:20 <gavinandresen> mmm... need release notes....
169 2012-10-09 14:39:34 <jgarzik> TD: getheaders is not in <= 0.3.24
170 2012-10-09 14:39:39 <jgarzik> TD: getheaders is in 0.4.0
171 2012-10-09 14:39:51 <jgarzik> unless I'm missing something
172 2012-10-09 14:43:50 <TD> hmm
173 2012-10-09 14:43:51 <jgarzik> gmaxwell: on another topic, I think people expect -rescan to imply "fsck -fvy /dev/wallet"
174 2012-10-09 14:43:54 <TD> i thought it was around longer than that
175 2012-10-09 14:44:09 <TD> i guess i need to make sure bcj doesn't send it to older peers then!
176 2012-10-09 14:44:45 <gmaxwell> jgarzik: yup. I assume that comment is in response to my somewhat silly issue on the subject? I'm not sure how to handle it. Beyond irking me to see it constantly recommended I don't know that it causes much harm beyond wasting people's time.
177 2012-10-09 14:45:12 <jgarzik> TD: getheaders was added in...
178 2012-10-09 14:45:14 <jgarzik> commit f03304a9c79a6cc6096ed501ad38702fd012e7f7
179 2012-10-09 14:45:26 <TD> ah ha
180 2012-10-09 14:45:46 <BlueMatt> thats well before 0.3.24, no?
181 2012-10-09 14:45:57 <jgarzik> serialize.h:static const int VERSION = 31703;
182 2012-10-09 14:46:01 <gmaxwell> Dec 2010? not that far before..
183 2012-10-09 14:46:02 <jgarzik> TD, BlueMatt: ^^
184 2012-10-09 14:46:08 <BlueMatt> ah
185 2012-10-09 14:46:32 <BlueMatt> gmaxwell: I define "well before" as I was around before 0.3.24, I was not on Dec 5 ;)
186 2012-10-09 14:46:51 <jgarzik> WARNING: Dec 2010 may be git import date. I have not checked.
187 2012-10-09 14:46:55 <jgarzik> VERSION is the relevant check
188 2012-10-09 14:47:22 <jgarzik> >= 31703
189 2012-10-09 14:47:29 <gmaxwell> gavinandresen: ACK on 0.7.1 I went over all these changes and they all look okay to me. Nice improvements everyone.
190 2012-10-09 14:47:37 <jgarzik> gavinandresen: ditto
191 2012-10-09 14:47:52 <BlueMatt> awww, first release I have no commit in in...a long time :(
192 2012-10-09 14:48:06 <BlueMatt> did anyone fix the bip30 stuff?
193 2012-10-09 14:48:10 <jgarzik> I'm not writing the release notes, since I got flamed for inaccuracy last time ;p
194 2012-10-09 14:48:13 <gavinandresen> thanks. I'll put draft release notes in a gist in a few minutes....
195 2012-10-09 14:49:20 <gmaxwell> https://github.com/bitcoin/bitcoin/pull/1872 < kinda sad this didn't make it in. I can crash a node without this fix, but at least it's a weird case in a new call.
196 2012-10-09 14:50:22 <jgarzik> 0.7.1 should-go-in list:
197 2012-10-09 14:50:28 <jgarzik> minor peers.dat fix, https://github.com/bitcoin/bitcoin/pull/1916
198 2012-10-09 14:50:43 <jgarzik> remove i2p, https://github.com/bitcoin/bitcoin/pull/1913
199 2012-10-09 14:50:49 <gmaxwell> (and it's never been hit by a normal user AFAIK)
200 2012-10-09 14:51:39 <jgarzik> that's about it
201 2012-10-09 14:52:26 <gmaxwell> I'm indifferent to 1916 for 0.7.1, it's a fine change but I don't think anyone but us are likely to hit it. Likewise for 1913, as its harmless either way.
202 2012-10-09 14:53:09 <gavinandresen> draft release notes: https://gist.github.com/3860009
203 2012-10-09 14:53:48 <jgarzik> gavinandresen: is there any discussion of -detachdb, anywhere?
204 2012-10-09 14:54:02 <jgarzik> gavinandresen: I think it would be useful to note why people might want to run -detachdb
205 2012-10-09 14:54:06 <jgarzik> somewhere
206 2012-10-09 14:55:03 <gavinandresen> ... somewhere.... I could add a paragraph explaining what -detachdb does at the top of the release notes
207 2012-10-09 14:55:37 <gmaxwell> woah the ubuntu ppa's have a different bdb version than our static binaries?
208 2012-10-09 14:55:56 <BlueMattBot> Project Bitcoin build #101: FAILURE in 39 min: http://jenkins.bluematt.me/job/Bitcoin/101/
209 2012-10-09 14:55:56 <jgarzik> gavinandresen: sure
210 2012-10-09 14:56:08 <Luke-Jr> gmaxwell: they do?
211 2012-10-09 14:56:23 <gmaxwell> Luke-Jr: so says the release notes!
212 2012-10-09 14:56:32 <gmaxwell> If so that would explain a lot.
213 2012-10-09 14:56:39 <gavinandresen> somebody want to test?
214 2012-10-09 14:56:39 <Luke-Jr> :/
215 2012-10-09 14:57:12 <BlueMatt> heh, jenkins found an actual error this time...
216 2012-10-09 14:57:32 <Luke-Jr> I have an ubuntu netbook here atm
217 2012-10-09 14:57:40 <Luke-Jr> 1 sec
218 2012-10-09 14:57:46 <BlueMatt> (sorry 'bout all the recent false positives, the server is taking >1h to import a block in the block test, making it miss the timestamp so that the tester considers it invalid...really need to move the dnsseed)
219 2012-10-09 14:57:54 <gavinandresen> BlueMatt: yeah... should be fixed already
220 2012-10-09 14:57:55 <Luke-Jr> Get:4 http://us.archive.ubuntu.com/ubuntu/ lucid/main libdb4.8++ 4.8.24-1ubuntu1 [714kB]
221 2012-10-09 14:58:10 <BlueMatt> yes, they do
222 2012-10-09 14:58:16 <BlueMatt> they use 4.8, but its a different version
223 2012-10-09 14:58:36 <gmaxwell> init.cpp:443:17: error: ???const char* pszDataDir??? previously declared here < I think that's fixed in the most recent commit... so while it's right it's also slow. :P
224 2012-10-09 14:58:37 <Luke-Jr> does bdb Z versions not signify "no incompatible changes, just bugfixes"? :/
225 2012-10-09 14:58:55 <BlueMatt> gmaxwell/gavinandresn: ok, so I /really/ need to move the dnsseed...
226 2012-10-09 14:59:11 <gmaxwell> Luke-Jr: without detach you really can't count on anything. I absolutely have seen point versions break when detach isn't used.
227 2012-10-09 14:59:24 <Luke-Jr> bleh
228 2012-10-09 14:59:43 <BlueMatt> (why does the release static binary on linux not have a different version from the win32 version?
229 2012-10-09 14:59:46 <gmaxwell> BlueMatt: the dnsseed is that much of a performance burden?
230 2012-10-09 15:00:03 <BlueMatt> gmaxwell: it eats 50% cpu when there are 4 g++ jobs running...
231 2012-10-09 15:00:20 <gavinandresen> BlueMatt: where is your dns seed now? Moving it to a Foundation-paid-for-machine would make a lot of sense....
232 2012-10-09 15:00:26 <BlueMatt> gmaxwell: (and it appears to be in like one or two constant threads, so its something broken that should be easy to fix...)
233 2012-10-09 15:00:39 <BlueMatt> gavinandresen: its on the jenkins server, I have some hardware here I can use too though...
234 2012-10-09 15:01:05 <BlueMatt> (and Im planning on writing yet another dnsseed server...)
235 2012-10-09 15:01:27 <gmaxwell> gavinandresen: I'd rather have the foundation running a DNS seed then hosting matt's, unless matt is eager to dispense with it.
236 2012-10-09 15:01:30 <Luke-Jr> meh, Jenkins could probably use a nicer box from the Foundation too
237 2012-10-09 15:01:36 <gavinandresen> getting some budget for the jenkins server, a dns seed server, a testnet3 long-running node is on my TODO list
238 2012-10-09 15:01:43 <gmaxwell> and indeed jenkins would be an obvious support target.
239 2012-10-09 15:02:03 <BlueMatt> gavinandresen: and supporting the bitcoin backbond project (or taking it over)
240 2012-10-09 15:02:08 <gavinandresen> (putting together an overall Foundation budget is on other people's TODO lists)
241 2012-10-09 15:02:11 <BlueMatt> s/d/e/
242 2012-10-09 15:02:14 <gmaxwell> (god knows the foundation running a dnsseed will inspire the conspiracy theorists further)
243 2012-10-09 15:10:31 <jgarzik> BlueMatt: agree
244 2012-10-09 15:16:41 <BlueMatt> hmm...wonderful...sipa: dnsseed is giving me segfaults again (on arm this time)
245 2012-10-09 15:16:54 <gavinandresen> jgarzik: added explanation of -detachdb to https://gist.github.com/3860009
246 2012-10-09 15:16:58 <gmaxwell> BlueMatt: how are your arm things working?
247 2012-10-09 15:17:34 <BlueMatt> gmaxwell: great, cpu is pretty damn quick, bitcoin runs very happily with only a few %cpu, io is pretty far on the slow side, but disk cache saves it pretty well
248 2012-10-09 15:17:46 <Luke-Jr> gavinandresen: might mention that versions prior to 0.6 always detached
249 2012-10-09 15:17:56 <Luke-Jr> to answer the "why is this just a problem now?"
250 2012-10-09 15:18:11 <gavinandresen> Luke-Jr: ACK
251 2012-10-09 15:22:22 <robocoin> Sorry for talking on dev channel :) But is this serious: https://www.iana.org/assignments/uri-schemes/prov/bitcoin ?
252 2012-10-09 15:22:39 <BlueMatt> heh, who submitted that?
253 2012-10-09 15:23:00 <robocoin> Registering party: Dave Thaler <dthalerµsoft.com>
254 2012-10-09 15:23:10 <BlueMatt> f'ing kidding me...
255 2012-10-09 15:23:26 <robocoin> is big MS getting readdy for Bitcoin payments?
256 2012-10-09 15:23:51 <BlueMatt> na, just someone random who decided they wanted to submit a bitcoin uri officially...
257 2012-10-09 15:24:11 <BlueMatt> would be better if the submitter had registered *@bitcoinfoundation.org to update it though...
258 2012-10-09 15:24:30 <gavinandresen> Speaking of URIs... the URI BIP needs to say what encoding is used for label and message.
259 2012-10-09 15:24:37 <robocoin> ok would you guys write this Dave Thaler an email?
260 2012-10-09 15:25:00 <BlueMatt> robocoin: meh, let it sit until someone actually has reason to get it updated ;)
261 2012-10-09 15:25:02 <gavinandresen> e.g. is "Pay+Gavin+Lots+Of+Coin" displayed as "Pay Gavin..."
262 2012-10-09 15:25:12 <BlueMatt> gavinandresen: ack
263 2012-10-09 15:25:19 <robocoin> ok thx
264 2012-10-09 15:27:35 <MC1984> Registering party: Dave Thaler <dthalerµsoft.com>
265 2012-10-09 15:27:38 <MC1984> what the FUCK
266 2012-10-09 15:27:48 <kjj_> That isn't a proposal, it is a report of something observed in the wild
267 2012-10-09 15:29:07 <TD> the reference to webarch is misleading
268 2012-10-09 15:29:12 <TD> bitcoin uris aren't a part of the web
269 2012-10-09 15:29:17 <TD> it's just a convenient IPC scheme
270 2012-10-09 15:29:39 <Luke-Jr> ???
271 2012-10-09 15:29:45 <Luke-Jr> they're for use on websites and such
272 2012-10-09 15:31:41 <gavinandresen> bitcoin uri's should follow http://www.rfc-editor.org/rfc/rfc4395.txt , though... (I'm still not a fan of bitcoin: URIs,though)
273 2012-10-09 15:31:51 <BlueMatt> why not?
274 2012-10-09 15:32:12 <kjj_> well, they aren't resources...
275 2012-10-09 15:32:20 <_SlipCoin_> is it likely that bitcoin will impliment proof-of-stake at some point soon?
276 2012-10-09 15:32:36 <kjj_> _SlipCoin_: zero chance, I'd say
277 2012-10-09 15:32:40 <Luke-Jr> _SlipCoin_: no
278 2012-10-09 15:32:47 <_SlipCoin_> O_o
279 2012-10-09 15:32:48 <_SlipCoin_> why not?
280 2012-10-09 15:32:50 <gavinandresen> Yes, they're not resources. I like the notion of "payment request" packaged up into a payment protocol
281 2012-10-09 15:32:54 <BlueMatt> kjj_: meh, the definition of uri has changed over time...more like link anymore...
282 2012-10-09 15:33:14 <BlueMatt> gavinandresen: yes, and a bitcoin: uri should be used to define how to trigger a payment protocol request
283 2012-10-09 15:33:27 <gavinandresen> URI would be "start negotiating payment with FOO" ....
284 2012-10-09 15:33:27 <MC1984> i dont know what proof of stake is because i cant find a tldr
285 2012-10-09 15:33:38 <gavinandresen> ... where FOO is https://somewhere
286 2012-10-09 15:34:02 <Luke-Jr> _SlipCoin_: it's an unproven theory, would break compatibility with all older versions, and is a proposed change to the social contract Bitcoin represents and would require basically unanimous consent of all Bitcoin holders
287 2012-10-09 15:34:03 <kjj_> MC1984: Their chief proponent is good at the TL part
288 2012-10-09 15:34:06 <BlueMatt> gavinandresen: if you have a better way to trigger that to start from an email/web page, shoot
289 2012-10-09 15:34:14 <gavinandresen> ... in which case the URI is, I think, just https://somewhere/.... and it returns a bitcoin-payment-request MIME type
290 2012-10-09 15:34:40 <kjj_> on the other hand, mailto: isn't a resource either, and does about the same job
291 2012-10-09 15:35:22 <BlueMatt> gavinandresen: hides the link more and wouldnt be handled as nicely...
292 2012-10-09 15:35:32 <BlueMatt> s/nicely/neatly
293 2012-10-09 15:35:35 <Luke-Jr> BlueMatt: it could be
294 2012-10-09 15:35:56 <gavinandresen> BlueMatt: yeah, I lost the argument the last time around, too....
295 2012-10-09 15:35:59 <BlueMatt> afaik browsers wont display that quite the same as simply opening bitcoin and letting it run
296 2012-10-09 15:36:19 <Luke-Jr> BlueMatt: it's just a matter of registering a MIME type instead of a URI scheme
297 2012-10-09 15:36:23 <Luke-Jr> which might actually be more compatible
298 2012-10-09 15:36:25 <BlueMatt> gavinandresen: heh...I agree it makes more sense, it just doesnt work/look as nice in the current system
299 2012-10-09 15:37:07 <gavinandresen> speaking of making URIs work.... I'm going to tag 0.7.1 now. jgarzik : not pulling those little bugfixes, I think they can wait
300 2012-10-09 15:37:11 <BlueMatt> Luke-Jr: will all browsers not show a download bar, just open bitcoin and handle it right?
301 2012-10-09 15:37:14 <Luke-Jr> the only "problem" I see with it is then we get into the Aliases mess again - we're trusting HTTPS which usually has a higher cost to use
302 2012-10-09 15:37:21 <kjj_> I actually would very much prefer a plain URI that is visible when I hover over the link, rather than a link to a different document
303 2012-10-09 15:37:31 <BlueMatt> plus that
304 2012-10-09 15:37:31 <Luke-Jr> BlueMatt: not sure on the download bar in modern browsers
305 2012-10-09 15:37:51 <jgarzik> gavinandresen: 0.7.1 or 0.7.1rc1?
306 2012-10-09 15:37:56 <gmaxwell> 10:17 < BlueMatt> gmaxwell: great, cpu is pretty damn quick, bitcoin runs very happily with only a few %cpu < did you try doing an ultraprune sync to it? and if so how long did it take?
307 2012-10-09 15:38:00 <BlueMatt> anyway, we've had this argument before, a decision was made...unless there is huge reason to change, I see no reason to debate again...
308 2012-10-09 15:38:05 <gavinandresen> 0.7.1rc1 I suppose
309 2012-10-09 15:38:10 <Luke-Jr> IMO too much is changed to go straight to 0.7.1 final
310 2012-10-09 15:38:19 <jgarzik> I would like to see at least one -rc1
311 2012-10-09 15:38:20 <BlueMatt> gmaxwell: havent done ultraprune yet...no
312 2012-10-09 15:38:51 <jgarzik> target Thursday or Friday for 0.7.1, if no problems
313 2012-10-09 15:38:53 <jgarzik> ?
314 2012-10-09 15:40:26 <gavinandresen> To git@github.com:bitcoin/bitcoin.git
315 2012-10-09 15:44:55 <gmaxwell> _SlipCoin_: in addition to what luke said, so far all proposals I've seen have a form of flaw where stake holders can ~costlessly double-use their stake to mine both the 'honest' chain, and an unbounded number of attack chains. In bitcoin your POW can only be spent on bitcoin or on any one attack, but not on both.
316 2012-10-09 15:45:20 <_SlipCoin_> oh gmaxwell
317 2012-10-09 15:45:46 <gmaxwell> I'm not sure if that issue is fatal, but its significant and greatly reduces the attractiveness of the idea.
318 2012-10-09 15:46:45 <amiller> the main thing that all "proof of stake" proposals have in common is that there is absolutely nothing put at stake in an attack
319 2012-10-09 15:46:55 <gmaxwell> plus there are a large number of additional issues with POS... e.g. key management??? having to keep your private keys internet connected at all times to mine stake is very ugly.
320 2012-10-09 15:47:19 <gmaxwell> amiller: exactly, thats a more general and clear way I putting what I was pointing to there.
321 2012-10-09 15:48:29 <Luke-Jr> gavinandresen: mine will be delayed a bit, looks like we changed gitian qt
322 2012-10-09 15:49:16 <gmaxwell> A rational bitcoin miner mines only the honest chain??? he knows his attacks are not going to be successful. A rational POS miner mines the honest chain _and_ every attack that doesn't hurt him (if doing so increases his subsidy income)), or the honest chain _and_ every attack that directly benefits him (if it doesn't depending on how elegible stake is selected).
323 2012-10-09 15:49:23 <maaku> sipa: most recent bitcoin-seeder segfaults if '-o' option is not specified; I assume this is not desired behavior?
324 2012-10-09 15:52:41 <amiller> gmaxwell, slightly more to add to that - not only is a successful attack expensive, but an _unsuccessful_ attack attempt is also expensive
325 2012-10-09 15:54:03 <Luke-Jr> jgarzik: 1fcebc1 check tx.CheckTransaction for data-driven tx tests. <-- this looks like it might not be the expected behaviour?
326 2012-10-09 15:54:09 <Luke-Jr> BlueMatt: ^ can you comment?>
327 2012-10-09 15:54:45 <Luke-Jr> oh wait
328 2012-10-09 15:54:51 <Luke-Jr> BlueMatt wrote that O.o
329 2012-10-09 15:55:20 <Luke-Jr> somehow missed it being in a pullreq
330 2012-10-09 15:56:26 <_SlipCoin_> gmaxwell: what is proof-of-excellence?
331 2012-10-09 15:57:40 <sipa> maaku: that's certainly noy intended
332 2012-10-09 15:58:49 <Luke-Jr> Thaler sez: "As discussed on the IRI WG list the IANA provisional registry is a better place to track deployed but non-standardized schemes. As such, pretty much all the schemes that were listed on Wikipedia were added to the IANA provisional registry."
333 2012-10-09 15:58:54 <Luke-Jr> FWIW
334 2012-10-09 15:58:56 <maaku> ok expect a pull request; btw maybe i'm dumb but why is the server's hostname specified twice, for '-h' (host) and '-n' (nameserver)?
335 2012-10-09 15:59:55 <BlueMatt> maaku: thats been that way for a while
336 2012-10-09 16:00:23 <BlueMatt> maaku: host and nameserver should not be the same thing
337 2012-10-09 16:00:26 <sipa> maaku: somehow the server needs to be able to answer queries that mentions its own IP as ns
338 2012-10-09 16:00:38 <sipa> so you need to both the name of the ns and of the hostname
339 2012-10-09 16:00:44 <maaku> ah ok makes sense
340 2012-10-09 16:00:45 <maaku> thanks
341 2012-10-09 16:00:50 <sipa> the first could presumably be loaded from DNS itself, though
342 2012-10-09 16:01:00 <Luke-Jr> gavinandresen: might note that mined transactions show up early in the release notes
343 2012-10-09 16:01:28 <Luke-Jr> earlier*
344 2012-10-09 16:01:40 <BlueMatt> Luke-Jr: where is 1fcebc1?
345 2012-10-09 16:01:41 <gavinandresen> 1-confirmation instead of 2? If you're solo mining?
346 2012-10-09 16:01:45 <gavinandresen> meh
347 2012-10-09 16:01:55 <Luke-Jr> BlueMatt: master?
348 2012-10-09 16:02:04 <BlueMatt> which tx in tx_*.json is it?
349 2012-10-09 16:02:12 <Luke-Jr> gavinandresen: also for pools that generate payouts, like BitPenny, Eligius, and P2Pool
350 2012-10-09 16:02:27 <Luke-Jr> BlueMatt: uh, it's a commit
351 2012-10-09 16:02:36 <Luke-Jr> git show 1fcebc1
352 2012-10-09 16:02:53 <BlueMatt> Luke-Jr: why is that not intended behavior?
353 2012-10-09 16:03:48 <BlueMatt> (its what the commit says and what the pull did...)
354 2012-10-09 16:04:07 <Luke-Jr> BlueMatt: I'm not sure, it just looked odd to me and I thought it had been committed without a pullreq by jgarzik somehow, and thought it might need review. Since that isn't the case, maybe nevermind.
355 2012-10-09 16:05:30 <BlueMatt> (the idea was to allow data-driven test to do test more things...)
356 2012-10-09 16:06:24 <Luke-Jr> BlueMatt: ah, that explains my confusion then
357 2012-10-09 16:15:34 <_SlipCoin_> does anyone know what it is or how it works?
358 2012-10-09 16:25:40 <jgarzik> ACTION returns from lunch
359 2012-10-09 16:25:46 <jgarzik> Luke-Jr: so did I break something? ;p
360 2012-10-09 16:26:17 <phantomcircuit> ALL THE THINGS
361 2012-10-09 16:29:09 <jgarzik> are belong to us
362 2012-10-09 16:48:04 <nym> hey, does anyone here know how to reach bitcoin?
363 2012-10-09 16:48:18 <nym> er... bitfloor
364 2012-10-09 16:48:31 <nym> i tried their email address, but haven't heard back
365 2012-10-09 16:58:06 <phantomcircuit> nym, twitter?
366 2012-10-09 17:00:54 <helo> nym: problems?
367 2012-10-09 17:01:00 <helo> err... wrong channel
368 2012-10-09 17:04:59 <jgarzik> v0.7.1rc1 seems happy here
369 2012-10-09 17:10:13 <D34TH> time to git pull
370 2012-10-09 17:11:30 <D34TH> "version" : 70100,
371 2012-10-09 17:11:31 <D34TH> :D
372 2012-10-09 17:43:53 <nym> helo: hi
373 2012-10-09 17:57:23 <KimLee> Hi
374 2012-10-09 17:57:27 <helo> nym: we should probably take it to #bitcoin, as its not dev related
375 2012-10-09 17:58:09 <KimLee> I was wondering if it was possible to monitor transactions without having a wallet present on the server.
376 2012-10-09 17:58:27 <KimLee> For security purposes.
377 2012-10-09 17:58:30 <D34TH> KimLee: try jgarzik's mininode
378 2012-10-09 17:58:40 <KimLee> Does anyone know how to do so with bitcoind?
379 2012-10-09 18:00:12 <KimLee> thx
380 2012-10-09 18:00:14 <gavinandresen> I'm getting an error building deps-win32 : build process is trying to run a cross-compiled wingenminiupnpcstrings compiling libminiupnp
381 2012-10-09 18:08:00 <gmaxwell> KimLee: You can make a copy of the wallet, and encrypt it with an impossible key using the integrated wallet encryption, and put a backup of the encrypted wallet online.
382 2012-10-09 18:08:24 <KimLee> Wow thanks!
383 2012-10-09 18:08:49 <gmaxwell> But there are complications of running a copy of a wallet, if you don't increase the keypool size they'll go out of sync after 100 transactions/addresses pulled out.
384 2012-10-09 18:08:49 <KimLee> That's was what I was thinking, I was just wondering if it was safe to run two wallets at once.
385 2012-10-09 18:09:11 <gmaxwell> If you only ever spend from one it's safe. (if you spend from both you can make a mess of both of them)
386 2012-10-09 18:09:28 <gmaxwell> But the copy will become wrong eventually once the keypool is exausted.
387 2012-10-09 18:09:36 <KimLee> This is great because I've done allot of codding with the bitcoind on the server.
388 2012-10-09 18:09:59 <KimLee> So I will create an impossible encryption on the server, just to monitor transactions
389 2012-10-09 18:10:26 <KimLee> And make payouts using my other wallet on the computer.
390 2012-10-09 18:12:18 <gmaxwell> KimLee: there is an argument to increase the keypool size, if you go that route you should do that on the original wallet before you make the copy and encrypt it.
391 2012-10-09 18:12:25 <KimLee> If I generate 10 000 payment addresses before encrypting it on the server, will it be alright.
392 2012-10-09 18:12:31 <gmaxwell> (keep in mind you can't disable the encryption: only change the key, so be sure to encrypt a copy)
393 2012-10-09 18:12:36 <gmaxwell> KimLee: right.
394 2012-10-09 18:12:56 <gmaxwell> Assuming you don't send + getnewaddress more than 10,000 times.
395 2012-10-09 18:13:24 <gmaxwell> (the change created when sending also consumes addresses)
396 2012-10-09 18:13:38 <KimLee> ok, I can encrypt the wallet on the server and keep the one on my computer unecrypted correct?
397 2012-10-09 18:14:04 <gmaxwell> KimLee: I would personally never let the unencrypted wallet touch the server.. it might be left in some unused disk space.
398 2012-10-09 18:14:34 <KimLee> Smart, yes.
399 2012-10-09 18:14:36 <gavinandresen> BlueMatt: any ideas? https://gist.github.com/3861142
400 2012-10-09 18:15:19 <gmaxwell> What I have done is increase the keypool, then backup my wallet on the non-server, then encrypt it, backup the encrypted copy. Then restore the first backup. And assuming everything went fine, destroy the encryption key.
401 2012-10-09 18:15:26 <gmaxwell> Then copy the encrypted backup to hte server.
402 2012-10-09 18:15:46 <gavinandresen> Anybody else able to gitian-compile deps-win32 successfully ?
403 2012-10-09 18:17:00 <KimLee> Thanks allot GMaxWell for your help. I've had allot of trouble with this issue.
404 2012-10-09 18:19:11 <BlueMatt> gavinandresen: its an issue with one of wine, binfmt-support or mingw...
405 2012-10-09 18:19:17 <BlueMatt> iirc Luke-Jr has seen it?
406 2012-10-09 18:19:34 <BlueMatt> really, either binfmt-support or mingw
407 2012-10-09 18:20:16 <gavinandresen> ok... binfmt-support is to run windows binaries on linux?
408 2012-10-09 18:20:23 <BlueMatt> yes
409 2012-10-09 18:20:28 <BlueMatt> (without calling wine ./...)
410 2012-10-09 18:20:51 <BlueMatt> as to what to do...well there I have no clue, try sshing and see what options you have?
411 2012-10-09 18:20:56 <gavinandresen> hmmm. I wonder if I'd get different results under kvm
412 2012-10-09 18:21:43 <BlueMatt> TD: what is the best way to explicitly kill a connection to a Peer?
413 2012-10-09 18:21:54 <TD> one managed by a PeerGroup?
414 2012-10-09 18:21:58 <BlueMatt> sure
415 2012-10-09 18:22:38 <gavinandresen> BlueMatt: I'll do that after the linux build is done. (lemme remember... add libexec/ to PATH and then run on-target ?)
416 2012-10-09 18:22:47 <BlueMatt> gavinandresen: right (iirc)
417 2012-10-09 18:23:07 <BlueMatt> may need on-target -u root to apt-get reinstall binfmt-support
418 2012-10-09 18:23:09 <TD> hmm interesting. there used to be a close method on peer and the NetworkConnection object. seems that it got removed when we ported to netty
419 2012-10-09 18:23:18 <TD> the handler may have a way to do it but it's not in the javadocs
420 2012-10-09 18:23:22 <TD> let me spin up intellij and take a look
421 2012-10-09 18:23:48 <TD> the javadocs for Peer could use a lot of love
422 2012-10-09 18:24:37 <BlueMatt> all I see is getting the Peer's channel and killing that directly, but that sounds dangerous (its private for a reason)
423 2012-10-09 18:25:54 <TD> well the issue is that Peer doesn't really run itself.
424 2012-10-09 18:26:15 <TD> the way PeerGroup does it is to close the channel indeed
425 2012-10-09 18:26:53 <TD> there's no channelFromPeer() method :(
426 2012-10-09 18:27:14 <BlueMatt> btw, Im hacking together a dnsseed crawler in bitcoinj, just to see how well it will scale to tons of connections, and it shouldn't take longer than an hour or so to build...(in theory)
427 2012-10-09 18:27:27 <TD> ok
428 2012-10-09 18:27:33 <TD> if it does then we need better APIs
429 2012-10-09 18:27:40 <TD> i'm not sure PeerGroup is the way to go there though
430 2012-10-09 18:27:48 <TD> using Netty directly may be a better idea
431 2012-10-09 18:28:38 <BlueMatt> well, the goal is to keep build time down, learning how to use netty makes more...
432 2012-10-09 18:29:15 <BlueMatt> but...if it falls over and dies, Ill probably do that
433 2012-10-09 18:29:17 <TD> if you look at PrintPeers, it does a sort of crawl thing
434 2012-10-09 18:29:20 <TD> in the examples directory
435 2012-10-09 18:29:24 <TD> basically you can do this:
436 2012-10-09 18:29:32 <TD> ListenableFuture<TCPNetworkConnection> future =
437 2012-10-09 18:29:44 <TD> Futures.addCallback(future, new FutureCallback<TCPNetworkConnection>() {
438 2012-10-09 18:29:52 <BlueMatt> brb, quiz...
439 2012-10-09 18:29:52 <TD> public void onFailure(Throwable throwable) {}
440 2012-10-09 18:29:55 <TD> }
441 2012-10-09 18:30:19 <TD> of course then you work with direct message passing, but as you don't want to download the block chain or anything that's probably the level you want to work at
442 2012-10-09 18:55:22 <BlueMatt> TD: hmm, ok that seems pretty simple...maybe Ill just do that if it blows up
443 2012-10-09 18:55:49 <TD> by the time onSuccess is called the version handshake is done already
444 2012-10-09 18:56:04 <TD> so you can just use conn.getVersionMessage to read it
445 2012-10-09 18:56:53 <BlueMatt> fair enough
446 2012-10-09 19:01:56 <gavinandresen> bah.... lxc-start isn't working for me. I think I know what the problem is, though: /etc/init.d/binfmt-support: 76: cannot create /proc/sys/fs/binfmt_misc/register: Permission denied
447 2012-10-09 19:07:29 <BlueMatt> gavinandresen: looks like the problem...I wonder what happens if you run it on an ubuntu machine with binfmt-installed on the host?
448 2012-10-09 19:07:45 <BlueMatt> (nfc how lxc works though, so...)
449 2012-10-09 19:08:17 <gavinandresen> BlueMatt: good question. I'll try that (I'm building win32-deps on my old KVM machine as a workaround)
450 2012-10-09 19:27:00 <TD> BlueMatt: fyi the low level networking API needs a lot of post-netty love. there is a lot to like about netty but simplicity isn't it
451 2012-10-09 19:27:08 <TD> (no surprise, it's a java framework)
452 2012-10-09 19:27:40 <TD> BlueMatt: specifically TCPNetworkConnection.writeMessage() should have a .awaitUninterruptably() after it, as all netty operations (even writing) are async
453 2012-10-09 19:28:38 <TD> also it's not valid to assume the first message is a version message
454 2012-10-09 19:28:44 <TD> satoshis code can relay alerts before version nego is complete
455 2012-10-09 19:29:05 <TD> i just generally need to go in and improve this code, and write an article on how to do simple message passing with and without netty
456 2012-10-09 19:30:24 <BlueMatt> yea...reading through peergroup is a lot of abstraction that hides away wtf is actually going on...
457 2012-10-09 19:36:46 <phantomcircuit> gavinandresen, what sgornick was saying about bitfloor is that in the event a creditor (someone owed btc by bitfloor) forced bankruptcy usd held by bitfloor for other customers could (im guessing would) be used to partially repay the btc creditors for their loss
458 2012-10-09 19:37:08 <phantomcircuit> so putting additional funds on bitfloor raises the risk that your funds added after the hack would none the less be taken
459 2012-10-09 19:37:22 <phantomcircuit> sgornick, correct me if im wrong
460 2012-10-09 19:38:03 <midnightmagic> ACTION sighs.
461 2012-10-09 19:39:14 <sgornick> phantomcircuit: Correct. Unsecured funds get pooled. If an existing creditor were to convince a judge that they were owed funds and the judge agreed and gives a judgement, that creditor can go to BitFloor's bank and withdraw. IANAL though.
462 2012-10-09 19:40:39 <phantomcircuit> sgornick, you might be able to argue for separation of funds before/after but it would be a very costly argument and i believe the odds of winning would be quite low
463 2012-10-09 19:41:02 <TD> BlueMatt: parts of PeerGroup can be simplified a lot
464 2012-10-09 19:41:06 <TD> by using more parts of netty
465 2012-10-09 19:41:21 <BlueMatt> well, that and docs...
466 2012-10-09 19:42:42 <TD> yeah. the Netty docs are actually quite good.
467 2012-10-09 19:42:47 <TD> it looks more complicated than it really is
468 2012-10-09 19:43:03 <TD> a "channel" is basically a connection. one per peer.
469 2012-10-09 19:43:47 <TD> the channel has a "pipeline" which is just an ordered list of objects called "handlers". data is passed in at the top and is transformed in various ways by the handlers as it flows up and down the pipeline
470 2012-10-09 19:44:00 <BlueMattBot> Yippie, build fixed!
471 2012-10-09 19:44:01 <BlueMattBot> Project Bitcoin build #102: FIXED in 4 hr 47 min: http://jenkins.bluematt.me/job/Bitcoin/102/
472 2012-10-09 19:44:37 <TD> the idea is that you have, e.g., a handler that knows how to read framed messages off the wire, another handler that knows how to to turn them into logical objects, another handler that knows how to manage the high level protocol state machine, etc
473 2012-10-09 19:45:10 <TD> the way we use Netty isn't very good. it's a holdover from the previous design.
474 2012-10-09 19:45:46 <BlueMatt> mmm, well just one more thing for the todo :)
475 2012-10-09 19:46:03 <TD> one day we should refactor things to fit better. TCPNetworkConnection doesn't make a whole lot of sense in a post-Netty world as it doesn't actually manage the network connection. what it really does is decode byte streams into objects representing the messages, and also has some version handshake handling gunk in there
476 2012-10-09 19:46:25 <TD> in fact there's nothing TCP specific about it at all
477 2012-10-09 19:46:36 <BlueMatt> heh
478 2012-10-09 19:47:02 <TD> unfortunately there are too many more important things to do first ???.. sigh.
479 2012-10-09 19:47:13 <TD> like sleep
480 2012-10-09 19:48:05 <BlueMatt> there are always more important things to do, but...yea, please sleep
481 2012-10-09 19:52:23 <jgarzik> sleep is overrated
482 2012-10-09 19:55:43 <Luke-Jr> BlueMatt: gavinandresen: sorry, deps-win32 works for me; I'm still using ancient pre-LXC gitian tho
483 2012-10-09 20:16:18 <sipa> gavinandresen: i'll start a build in half an hour
484 2012-10-09 20:23:36 <Luke-Jr> 281bc2046c1ccc856a51fe5d70f676c182d38129752bb938c341df4ed8517384 bitcoin-0.7.1-win32-setup.exe
485 2012-10-09 20:23:56 <Luke-Jr> pushed
486 2012-10-09 20:24:01 <maaku> sipa: is bitcoin-seeder under any license?
487 2012-10-09 20:24:57 <sipa> maaku: good question, actually
488 2012-10-09 20:28:10 <sipa> never thought about that, but i guess i'm ok with GPL or BSD
489 2012-10-09 20:29:02 <maaku> well since it contains parts of bitcoind, how about the same license?
490 2012-10-09 20:30:57 <Luke-Jr> maaku: that'd be MIT, which is basically the same as BSD
491 2012-10-09 21:07:18 <yellowhat> is there a practical limit to do a 15of20 multisig with BIP16?
492 2012-10-09 21:07:36 <sipa> such a transaction would currently not be considered standard
493 2012-10-09 21:07:43 <sipa> but it's certainly possible and valid
494 2012-10-09 21:08:22 <yellowhat> so not standard, what does that mean? is it relayed? mined? block reject if mined?
495 2012-10-09 21:08:48 <sipa> not relayed or mined by people running the reference client
496 2012-10-09 21:09:06 <yellowhat> i'm guessing no, no, no. so i would have to mine it myself if i want to include it
497 2012-10-09 21:09:22 <Luke-Jr> yellowhat: if you relay it directly to Eligius with a fee, you can probably get it in
498 2012-10-09 21:09:25 <sipa> not relayed, not mined, but accepted in a block
499 2012-10-09 21:09:37 <Luke-Jr> jgarzik: Is this a bugfix? 93dd68e P2P: Do not request blocks from peers with fewer blocks than us
500 2012-10-09 21:09:48 <sipa> Luke-Jr: i wouldn't consider it a bugfix
501 2012-10-09 21:10:38 <sipa> maaku: which altcoin are you interested in running seeder for?
502 2012-10-09 21:10:45 <maaku> freicoin
503 2012-10-09 21:10:49 <yellowhat> thanks for the hint Luke-Jr sounds like a practical solution.
504 2012-10-09 21:10:50 <sipa> maaku: be aware, i've recently had it lock up
505 2012-10-09 21:10:56 <maaku> http://www.freicoin.org
506 2012-10-09 21:11:12 <sipa> i've been planning to rewrite a part of it, but never gotten to doing so
507 2012-10-09 21:13:20 <maaku> it'll work for now; it supplements the current approach of few hardcoded IP seeds
508 2012-10-09 21:13:50 <maaku> i'm working on packaging it into an ubuntu PPA as well
509 2012-10-09 21:14:02 <jgarzik> gavinandresen: Perhaps in the release notes, include a link to bitcoin/bitcoin/issues as the canonical place to report issues?
510 2012-10-09 21:14:18 <jgarzik> gavinandresen: /issues is not mentioned anywhere, that I can see
511 2012-10-09 21:14:26 <gavinandresen> jgarzik: ACK
512 2012-10-09 21:15:01 <gavinandresen> Wait... release notes say: Please report bugs using the issue tracker at github:
513 2012-10-09 21:16:10 <sipa> jgarzik: why was the sending of mempool reverted?
514 2012-10-09 21:16:38 <sipa> ah, the compile error?
515 2012-10-09 21:16:51 <jgarzik> sipa: no, it compiles just fine. no idea bout that build bot nuttiness.
516 2012-10-09 21:17:08 <gavinandresen> Uploaded README to https://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.7.1/test/
517 2012-10-09 21:17:14 <jgarzik> sipa: tried to explain on the revert commit message: it was merged by accident
518 2012-10-09 21:17:29 <jgarzik> sipa: the pull request did not seem to have collected enough ACKs
519 2012-10-09 21:17:40 <sipa> ok
520 2012-10-09 21:17:43 <jgarzik> sipa: and gmaxwell raised a valid point, RE mempool TX expiration
521 2012-10-09 21:17:53 <Impaler> hey maaku
522 2012-10-09 21:17:53 <jgarzik> one that requires $THOUGHT
523 2012-10-09 21:17:54 <jgarzik> ;p
524 2012-10-09 21:18:09 <Impaler> finding more freicoin converts?
525 2012-10-09 21:18:12 <sipa> yes, agree
526 2012-10-09 21:20:03 <sipa> i need to rebuild Qt and deps for 0.7.1?
527 2012-10-09 21:20:35 <sipa> won't be for today then
528 2012-10-09 21:20:57 <Luke-Jr> sipa: just Qt I think?
529 2012-10-09 21:21:20 <sipa> seems it needs deps5, which i don't have
530 2012-10-09 21:21:51 <gavinandresen> yes, I've been struggling to compile deps5 for much of today...
531 2012-10-09 21:22:01 <Luke-Jr> :/
532 2012-10-09 21:22:06 <sipa> trying to do deps5 now
533 2012-10-09 21:22:26 <Luke-Jr> am I the only one who's managed to build 0.7.1rc1 so far then? :x
534 2012-10-09 21:22:43 <gavinandresen> Any idea why my KVM system would give me random "Connection timed out during banner exchange" errors? (ssh-ing to the target)
535 2012-10-09 21:23:02 <Luke-Jr> gavinandresen: VM too slow? Try increasing the timeout
536 2012-10-09 21:23:14 <gavinandresen> any idea how to increase the ssh timeout?
537 2012-10-09 21:23:20 <Luke-Jr> also, I think KVM just freezes the VM if the disk is full
538 2012-10-09 21:23:24 <Luke-Jr> the host disk
539 2012-10-09 21:23:36 <sipa> Luke-Jr: remarkable you did so without knowing that deps changed?
540 2012-10-09 21:23:44 <tcatm> Did you try ssh -v $host?
541 2012-10-09 21:23:51 <sipa> or did you already built deps5 for some next-test?
542 2012-10-09 21:23:54 <Luke-Jr> sipa: I must have built the deps earlier for some reason? next-test maybe
543 2012-10-09 21:24:18 <gmaxwell> 16:09 < Luke-Jr> jgarzik: Is this a bugfix? 93dd68e P2P: Do not request blocks from peers with fewer blocks than us
544 2012-10-09 21:24:33 <gmaxwell> ^ it's bugfixness depends on the density of broken listening nodes
545 2012-10-09 21:25:04 <gmaxwell> iff the first node you connect to is broken you'll be stuck until the next block.
546 2012-10-09 21:49:38 <Luke-Jr> FWIW, confirmed deps-win32.yml is identical in v0.7.1rc1 and next-test
547 2012-10-09 21:49:46 <Luke-Jr> so it didn't change in the interim
548 2012-10-09 21:56:51 <gavinandresen> finally managed to compile bitcoin-deps-0.0.5.zip .... (increasing -oConnectTimeout=5 in the libexec/on-target gitian script seemed to do the trick)
549 2012-10-09 21:59:53 <sipa> ah, bah... same bug as last time
550 2012-10-09 22:00:04 <Luke-Jr> interesting, from the docs I didn't expect ConnectTimeout to work for banner exchange timeout
551 2012-10-09 22:00:20 <sipa> i forgot to run gitian in linux32 wrapper
552 2012-10-09 22:00:59 <gavinandresen> sipa: I think devrandom fixed that
553 2012-10-09 22:01:06 <sipa> oh
554 2012-10-09 22:01:14 <gavinandresen> ... try git pulling latest gitian-builder
555 2012-10-09 22:01:17 <sipa> i should update; thought my script did that automatically, though
556 2012-10-09 22:08:47 <bcb> are the "comments" and "to" messages in the .7 sendtoaddress written into the transaction or only referenced on my local bitcoind?
557 2012-10-09 22:10:20 <gavinandresen> bcb: yes, they are stored in the wallet as part of the transaction information. Not sent anywhere.
558 2012-10-09 22:12:38 <bcb> so if I'm referencing my transactions there no one who received that transaction will see the "comments" message?
559 2012-10-09 22:13:31 <bcb> But they will see the "to" message?
560 2012-10-09 22:14:03 <sipa> no, transactions don't contain messages
561 2012-10-09 22:14:17 <sipa> those are purely a client-side thing
562 2012-10-09 22:15:28 <gavinandresen> Luke-Jr: my build matches yours
563 2012-10-09 22:15:49 <sipa> make: ./wingenminiupnpcstrings: Command not found
564 2012-10-09 22:16:04 <sipa> ACTION -> sleep 21600
565 2012-10-09 22:16:36 <jgarzik> gavinandresen: with regarding to testing & Bitcoin Foundation
566 2012-10-09 22:16:42 <gavinandresen> sipa: I uploaded my bitcoin-deps-0.0.5.zip to http://www.skypaint.com/bitcoin
567 2012-10-09 22:17:05 <gavinandresen> (and my qt-win32-4.8.2-gitian-r1.zip )
568 2012-10-09 22:17:05 <sipa> gavinandresen: i did see you post a git with the same error message as i got
569 2012-10-09 22:17:06 <jgarzik> gavinandresen: if someone manages to automate RPC and P2P testing, the Bitcoin Foundation could potentially spring for a round of many-node testing on Amazon EC2
570 2012-10-09 22:17:13 <jgarzik> gavinandresen: spin up 200 nodes, test, spin down
571 2012-10-09 22:17:23 <jgarzik> testnet-in-a-cloud
572 2012-10-09 22:17:43 <sipa> we should market that idea
573 2012-10-09 22:17:52 <sipa> money-in-the-cloud
574 2012-10-09 22:18:17 <sipa> certainly feels like a very solid foundation for a currency!
575 2012-10-09 22:18:19 <jgarzik> cloudcoins
576 2012-10-09 22:18:35 <gavinandresen> jgarzik: interesting idea. Defining/detecting success/failure would take some thinking
577 2012-10-09 22:18:49 <pjorrit> vapor meets where?
578 2012-10-09 22:19:02 <sipa> pjorrit: lol; in clouds!
579 2012-10-09 22:19:15 <jgarzik> gavinandresen: as I noted on the m-l, automated many-peer testing is Hard Problem ;p
580 2012-10-09 22:19:28 <jgarzik> but it would be nice to test, e.g. peer-becomes-stuck
581 2012-10-09 22:19:35 <jgarzik> (where it switches to another peer)
582 2012-10-09 22:19:38 <gmaxwell> There are some bits of instrumentation which would make it work much better. Make every hash a valid block, deactivate the peer selection port filtering so you can run a dozen nodes per host.
583 2012-10-09 22:19:49 <gavinandresen> don't the networking research folks have big test-beds for trying out net networking protocols and such?
584 2012-10-09 22:20:02 <gavinandresen> NEW networking protocols and such...
585 2012-10-09 22:20:19 <Luke-Jr> there are new networking protocols? :o
586 2012-10-09 22:20:32 <gmaxwell> gavinandresen: yes, well. R&E people do for writing papers. Actual real networking protocols get tested in production. :P
587 2012-10-09 22:20:54 <gavinandresen> just because they jump off a bridge....
588 2012-10-09 22:21:17 <gmaxwell> (so you get lovely things like 32-bit ASNs in BGP creating transitive failures that could have potentially knocked out the entire internet except they got triggered when only a few big networks had them deployed...)
589 2012-10-09 22:21:50 <jgarzik> ACTION echoes luke-jr, there...
590 2012-10-09 22:22:16 <jgarzik> anything beyond UDP/IP or TCP/IP only exists in tiny, focused niches
591 2012-10-09 22:22:32 <jgarzik> witness the stellar market penetration of SCTP
592 2012-10-09 22:22:46 <pjorrit> or ipv6 ;p
593 2012-10-09 22:22:49 <gmaxwell> jgarzik: well not quite; Linux loves merging the TCP congestion control dicipline of the week, for example. :P
594 2012-10-09 22:22:58 <jgarzik> any protocols on top of those are implemented by software guys writing python and php, and we know how well those clowns test stuff
595 2012-10-09 22:23:06 <Luke-Jr> pjorrit: IPv6 is ancient tho
596 2012-10-09 22:23:07 <gmaxwell> And that stuff gets tested in tools like NS2 and on R&E networks.
597 2012-10-09 22:23:17 <sipa> no place like ::1
598 2012-10-09 22:23:23 <jgarzik> gmaxwell: when Van Jacobsen knocks, people listen ;-)
599 2012-10-09 22:23:39 <jgarzik> the EF Hutton of the Internet
600 2012-10-09 22:24:05 <gmaxwell> But I think the academic testing is actually of fairly low testing value, though it does validate that the changes are worthwhile.
601 2012-10-09 22:24:44 <gmaxwell> Live fire tests are good for testing, less good for papers because you don't control it well enough.
602 2012-10-09 22:25:41 <gavinandresen> I was just thinking that the academics might have nice network simulation tools to run network-in-a-box on one machine.
603 2012-10-09 22:26:02 <gmaxwell> In any case, I'd rank things like getting really good jenkins infrastructure running basic single node and node+harness tests a lot high than cloud tests. :P
604 2012-10-09 22:26:20 <gavinandresen> yes, I agree-- bang for buck will be higher for other stuff
605 2012-10-09 22:26:24 <jgarzik> ACTION wrote a lot of glue and testing code for another DHT, http://www.nicemice.net/amc/research/tangle/
606 2012-10-09 22:26:31 <jgarzik> that entire thing was simulation
607 2012-10-09 22:26:44 <jgarzik> just rip out the TCP/UDP stuff, and replace with internal memory bus
608 2012-10-09 22:26:51 <jgarzik> run X threads
609 2012-10-09 22:26:51 <sipa> gavinandresen: i'm sure they have network simulation tools for something like UDP :)
610 2012-10-09 22:27:13 <gmaxwell> gavinandresen: a lot of those tools are basically unit test level. E.g. they don't test host, they test a C++ class that pretends to be one.
611 2012-10-09 22:27:20 <jgarzik> yep
612 2012-10-09 22:27:36 <gavinandresen> ok.
613 2012-10-09 22:27:57 <jgarzik> or like TANGLE, developed entirely in simulator (== academic, closed environment)
614 2012-10-09 22:28:04 <jgarzik> only to break horribly when met with real life
615 2012-10-09 22:28:18 <gmaxwell> Fortunately our protocol is very async and we should strive to keep it that way... minimizes the number of network level dynamic dependencies... and the stuff we have that is stateful like the special block pulls for IBD ... are a source of problems for us.
616 2012-10-09 22:28:29 <Luke-Jr> gavinandresen: qemu/kvm has some guest-only switch thing (VDE?)
617 2012-10-09 22:29:14 <jgarzik> gmaxwell: the P2P connection has always been minimally stateful... you set certain connection-wide state and behaviors at the beginning of the connection
618 2012-10-09 22:29:25 <jgarzik> async != state free
619 2012-10-09 22:29:52 <sipa> agree, it is stateful