1 2013-07-15 03:46:32 <saivann> If anyone wants to review and comment https://github.com/bitcoin/bitcoin.org/pull/215 in the next days, this is an important change for bitcoin.org . This pull request applies many changes in the layout and content, and it adds a new "Getting started" page.
2 2013-07-15 05:27:47 <swulf--> What's the merkle root of a block defined to be if it has no transactions? (or: is a block even allowed to have 0 transactions?)
3 2013-07-15 05:28:12 <gmaxwell> a block must have a coinbase transaction in order to be valid.
4 2013-07-15 05:28:36 <swulf--> makes sense
5 2013-07-15 06:40:28 <swulf--> http://blockexplorer.com/rawtx/f412aa50ee871f7d8a777c24f4f034002d260ab8282709da8c2f398437e17254 this transaction's raw data says that the coinbase scriptSig should be 82 bytes (should end with "13deff").. why are there only 81 bytes?
6 2013-07-15 06:41:58 <swulf--> 0xff is specifically an invalid opcode, but is it supposed to be stripped out of the scriptSig?
7 2013-07-15 06:43:14 <BlueMatt> q
8 2013-07-15 06:46:10 <TD> no unregistered users anymore?
9 2013-07-15 06:46:16 <TD> that's kind of annoying for putting presence into your nick
10 2013-07-15 06:52:08 <swulf--> well, nvm..
11 2013-07-15 07:07:29 <petertodd> swulf--: the 0x51 at the start means the coinbase scritpSig should be 81 bytes, not 82
12 2013-07-15 07:08:45 <petertodd> ;;later tell sipa I don't know much about DNS.
13 2013-07-15 07:08:46 <gribble> The operation succeeded.
14 2013-07-15 07:11:57 <melvster> TD: re presence in nick, overloading identifiers is not to be encouraged! :D also you can get OTC trust ratings from gribble
15 2013-07-15 07:12:17 <TD> overloading identifiers? hehe. spoken like a true web guy :)
16 2013-07-15 07:12:37 <melvster> TD: i wish ... this happens on the web *all the time* ...
17 2013-07-15 07:13:13 <melvster> half the world thinks your email is your identity, the other half think your home page is ... and the two will never talk ...
18 2013-07-15 07:14:45 <melvster> the so-called 'axiom of opacity' ... the genius of adam back and satoshi was that they knew when to violate that axiom using proof of work
19 2013-07-15 07:15:26 <TD> does sipas dns seed work for anyone at all right now?
20 2013-07-15 07:15:47 <TD> andreas is telling me yesterday it worked for some people. but i can't reach it at all today from google (which definitely does not have a broken dns setup)
21 2013-07-15 07:16:28 <petertodd> nameserver for the seed nameserver is down
22 2013-07-15 07:19:24 <petertodd> Nifty, next p2pool block should use OP_RETURN for the share chain digest txout; network seems to now be on version 13
23 2013-07-15 07:19:30 <TD> cool
24 2013-07-15 07:43:06 <petertodd> interesting strange tx: c5510a5dd97a25f43175af1fe649b707b1df8e1a41489bac33a23087027a2f48
25 2013-07-15 07:43:21 <petertodd> txout #0 has the string: echo "U2FsdGVkX1+ZSnXut5eBy0fyGxbTVAVuSJl7jj3HxAiE2SdfvWsOSGO6c38XMt9C\\nT2IXIg0jHiV0O7nwR6dEFg==" > t; openssl enc -pass pass:[1JVMwQC-privkey-hex] -d -aes-256-cbc -a -in t
26 2013-07-15 07:57:59 <TD> how do you find these?
27 2013-07-15 07:58:19 <TD> blockexplorer.com?
28 2013-07-15 07:58:38 <petertodd> python script looking for strange transactions, blockchain.info works too
29 2013-07-15 07:58:56 <TD> that looks superficially like a mistake, but i wonder ... it also looks like it could be a deliberate template as part of some protocol someone is designing
30 2013-07-15 07:59:14 <petertodd> it has op-drop, that's not a mistake
31 2013-07-15 07:59:24 <petertodd> someone's just recording data in the blockchain
32 2013-07-15 07:59:34 <TD> right. that's what i meant. but the question is did they intend to op_drop the output of that command, or the command itself
33 2013-07-15 08:00:32 <petertodd> I'd be really surprised if this wasn't done manually given there's none other like it
34 2013-07-15 08:00:46 <gmaxwell> petertodd: did you check testnet?
35 2013-07-15 08:01:04 <gmaxwell> when people do this and don't get the byteorder wrong I assume they must have actually tested it first. Everyone gets the byteorder wrong.
36 2013-07-15 08:01:26 <petertodd> gmaxwell: well, it's op_drop, there's no byteorder to get wrong
37 2013-07-15 08:01:43 <gmaxwell> ah, the ones people get wrong are the ones embedded in keys.
38 2013-07-15 08:02:07 <petertodd> yeah, and the byteorder on the command line isn't so bad
39 2013-07-15 08:03:27 <petertodd> speaking of: https://github.com/bitcoin/bitcoin/pull/2830 been bothering me that we didn't have decodescript
40 2013-07-15 08:04:03 <petertodd> I was going to do encodescript, but the unittest ParseScript() uses diferent syntax than the CScript::To_String() function
41 2013-07-15 08:11:30 <warren> https://github.com/bitcoin/gitian.sigs/blob/master/0.8.3/gavinandresen/bitcoin-build.assert any idea what generates this file format?
42 2013-07-15 08:14:00 <warren> ../gitian-builder/result/bitcoin-res.yml appears to be similar but not exactly
43 2013-07-15 08:20:02 <sipa1024> warren: some ruby thing, i suppose
44 2013-07-15 08:21:38 <BlueMatt> warren: bin/gsign
45 2013-07-15 08:21:45 <BlueMatt> and bin/gverify
46 2013-07-15 08:29:11 <sipa> Goonie_: is my seed now working?
47 2013-07-15 08:31:04 <petertodd> sipa: yup
48 2013-07-15 08:32:04 <petertodd> sipa: dns over ipv6 isn't though, not that it matters much
49 2013-07-15 08:32:14 <Goonie> irc works less and less for me. Recently I started getting messages about not being able to post.
50 2013-07-15 08:33:04 <petertodd> Goonie: lots of spam lately - I'm tempted to suggest fidelity bonds
51 2013-07-15 08:33:34 <Goonie> sipa: dig seed.bitcoin.sipa.be works now. Thanks for fast fixing!
52 2013-07-15 08:33:57 <Goonie> now we need to get lukejr to update as well
53 2013-07-15 08:34:44 <petertodd> Goonie, sipa: update?
54 2013-07-15 08:35:48 <Goonie> petertodd: it was a casing issue. My ISP DNS rewrites queries to have different casing and the seeder did not like it.
55 2013-07-15 08:36:10 <petertodd> Goonie: bizzare, I'll have to update the testnet seed then
56 2013-07-15 08:36:18 <Goonie> petertodd: yes, please do
57 2013-07-15 08:36:57 <Goonie> btw. the discussion can be read here: http://code.google.com/p/bitcoinj/issues/detail?id=431
58 2013-07-15 08:37:06 <petertodd> sipa: merge my pull-req to add testnet support to the dnsseed
59 2013-07-15 08:38:46 <Goonie> Luke-Jr: can you update to dns-seeder to latest git? It adds support for my ISP (-:
60 2013-07-15 08:39:39 <petertodd> Goonie: reminds me: it'd be a good idea to add a seeds.txt -> amazon route 53 or similar system to turn the testnet seeds into something for a totally standard dns server too
61 2013-07-15 08:40:02 <petertodd> Goonie: gotta get around to that one day
62 2013-07-15 08:41:23 <Goonie> petertodd: yes I was going to suggest something like that too. It does not make sense to re-implement DNS, especially since the many resolved security issues of common servers like bind.
63 2013-07-15 08:42:37 <petertodd> yup, actually come to think of it a script that spits out a bind namefile is probably enough
64 2013-07-15 08:58:13 <sipa> petertodd: i completely missed there was a pullreq open for that!
65 2013-07-15 09:01:44 <petertodd> sipa: no worries, just upgraded testnet-seed-ns2.bitcoin.petertodd.org, I'll do ns1 later if ns2 seems to work
66 2013-07-15 09:02:35 <sipa> remarkably, just after restarting my seeder, i was getting 50-100 QPS for a while
67 2013-07-15 09:02:41 <sipa> while it's usually only 5 or so
68 2013-07-15 09:03:21 <petertodd> curious, hopefully jdillon isn't trying out that attack...
69 2013-07-15 09:03:36 <TD> hm
70 2013-07-15 09:03:45 <TD> i hope there's no bug in bitcoinj that can cause repeated queries. i don't think there is.
71 2013-07-15 09:03:50 <TD> ACTION -> lunch
72 2013-07-15 09:03:59 <petertodd> I'm suspicious someone is doing dns requests unrelated to actually running a node on testnet, because I get thousands a day and that just doesn't make sense
73 2013-07-15 09:04:25 <kinlo> petertodd: I've found bugs in your bitcoin seed dns server
74 2013-07-15 09:04:25 <petertodd> TD: even if there was caching at the ISP level should quench that
75 2013-07-15 09:04:38 <kinlo> nothing bad, but it didn't work for me :)
76 2013-07-15 09:04:49 <petertodd> kinlo: try it again, sipa found a case-related bug
77 2013-07-15 09:05:00 <kinlo> case-related?
78 2013-07-15 09:05:03 <petertodd> kinlo: specifically testnet-seed-ns2.bitcoin.petertodd.org, haven't upgraded ns1 yet
79 2013-07-15 09:05:18 <kinlo> well, I've already discussed this with sipa
80 2013-07-15 09:05:20 <petertodd> kinlo: yes, looks like some isp was modifying the case of dns queries
81 2013-07-15 09:05:49 <kinlo> ic
82 2013-07-15 09:05:51 <kinlo> well, not that :p
83 2013-07-15 09:06:09 <petertodd> kinlo: what else?
84 2013-07-15 09:06:47 <kinlo> petertodd: the constructor for the options is incomplete
85 2013-07-15 09:06:58 <kinlo> so you're using random data to initialize your options...
86 2013-07-15 09:07:11 <petertodd> kinlo: oh where?
87 2013-07-15 09:07:53 <sipa> the tor proxy initializer is missing, iirc
88 2013-07-15 09:08:03 <kinlo> main.cpp line 31
89 2013-07-15 09:08:18 <kinlo> the tor proxy initializer, but also the testnet initializer (petertodd's code only)
90 2013-07-15 09:08:56 <kinlo> and fWipeBan and fWipeIgnore too it seems
91 2013-07-15 09:09:15 <kinlo> no idea what they do but htey aren't initialized
92 2013-07-15 09:10:10 <petertodd> kinlo: the tor thing I see, how is the testnet initializer not initialized?
93 2013-07-15 09:10:41 <kinlo> petertodd: it's an int with no default value
94 2013-07-15 09:10:41 <sipa> fUseTestnet
95 2013-07-15 09:10:44 <petertodd> tor is missing because I don't know of any stable tor nodes
96 2013-07-15 09:11:00 <kinlo> no, tor is missing because it is a programming bug
97 2013-07-15 09:11:22 <kinlo> it should be tor(NULL), fUseTestNet(0)
98 2013-07-15 09:11:31 <kinlo> so they are zero at start of the program
99 2013-07-15 09:11:34 <sipa> but tor(NULL) is there?
100 2013-07-15 09:11:43 <sipa> i fixed that a long time ago, afaik
101 2013-07-15 09:11:48 <sipa> now that i look at it
102 2013-07-15 09:11:50 <petertodd> kinlo: oh, I thought fUseTestNet was set in the long_options
103 2013-07-15 09:11:57 <kinlo> coz C++ standard does not zero memory
104 2013-07-15 09:12:07 <sipa> petertodd: may be the case
105 2013-07-15 09:12:08 <kinlo> sipa: possible, I'm looking at petertodd's branch
106 2013-07-15 09:12:25 <petertodd> kinlo: look at master
107 2013-07-15 09:12:36 <kinlo> petertodd: it isn't it uses testnet at my test machine, and I never specified the parameter :)
108 2013-07-15 09:13:15 <sipa> fixed in master
109 2013-07-15 09:14:15 <petertodd> kinlo: yup, you're right
110 2013-07-15 09:14:21 <petertodd> kinlo: misread the getopt docs way back when
111 2013-07-15 09:14:24 <kinlo> petertodd: ofcourse :p
112 2013-07-15 09:15:38 <petertodd> kinlo: I must have been unlucky to have it set to off on my machine - I was running a mainnet seed to gather data for a bit and never noticed the issue... oddly after you mentioned it it now compiles to testnet on :P
113 2013-07-15 09:17:07 <kinlo> petertodd: I dunno... It depends on the memory returned by the os
114 2013-07-15 09:17:15 <kinlo> if it zeroes out mallocs.....
115 2013-07-15 09:17:29 <kinlo> I know linux didn't do that but perhaps some setting enabled it on your testbox
116 2013-07-15 09:17:44 <petertodd> kinlo: the OS *always* zeros out memory, it's libc that doesn't
117 2013-07-15 09:17:54 <petertodd> kinlo: specifically when you sbrk()
118 2013-07-15 09:18:32 <phantomcircuit> kinlo, in practice on linux systems you always get null
119 2013-07-15 09:18:35 <kinlo> petertodd: no, windows does it, linux doesn't afaik
120 2013-07-15 09:18:49 <kinlo> making linux faster, windows "more secure"
121 2013-07-15 09:19:09 <phantomcircuit> the only time you dont is if there's stack patterns
122 2013-07-15 09:19:10 <petertodd> kinlo: the OS giving you non-cleared memory is a security risk, believe me, the OS does. But as I say, libc is what does memory management and it doesn't.
123 2013-07-15 09:19:12 <phantomcircuit> but nobody uses those
124 2013-07-15 09:19:36 <kinlo> petertodd: well, my test machine doesn't... and it's running linux...
125 2013-07-15 09:19:50 <kinlo> I clearly get non-cleared memory
126 2013-07-15 09:20:03 <petertodd> kinlo: compile a C program not linked to libc and you'll see differently
127 2013-07-15 09:20:56 <kinlo> anyway
128 2013-07-15 09:20:57 <sipa> kinlo: malloc() doesn't ask the OS for memory
129 2013-07-15 09:21:09 <sipa> kinlo: it uses the heap the process already has
130 2013-07-15 09:21:17 <sipa> and if that doesn't suffice, it asks the OS to increase the heap
131 2013-07-15 09:21:23 <kinlo> sipa: it does in the end, in the end malloc is a complex wrapper around sbrk()
132 2013-07-15 09:21:42 <kinlo> eh
133 2013-07-15 09:21:44 <sipa> yes, but it doesn't guarantee that the memory areay you get hasn't already been used by your process
134 2013-07-15 09:21:51 <kinlo> true
135 2013-07-15 09:21:57 <sipa> sure, sbrk() will give you new, zeroed, memory
136 2013-07-15 09:22:11 <kinlo> but why does it crash on my computer and not on petertodd's etc?
137 2013-07-15 09:22:13 <petertodd> kinlo: try malloc()ing say, 16GB and see if it's zeroed
138 2013-07-15 09:22:28 <petertodd> kinlo: different linking options that wind up with different stack configurations and usage
139 2013-07-15 09:22:39 <kinlo> well, it's irrelevant :)
140 2013-07-15 09:23:02 <petertodd> kinlo: pff, not understanding your code down to the quantum level is a sin
141 2013-07-15 09:23:21 <petertodd> kinlo: (or a cos when rotated 90 degrees)
142 2013-07-15 09:23:40 <kinlo> :p
143 2013-07-15 09:24:03 <kinlo> petertodd: I do understand the code, the C++ standard describes that the memory is not initialized and that you should initialize it
144 2013-07-15 09:24:07 <kinlo> and you violated that :)
145 2013-07-15 09:24:16 <sipa> can't argue with that :D
146 2013-07-15 09:24:18 <kinlo> and it crashes for me
147 2013-07-15 09:24:32 <petertodd> heh
148 2013-07-15 09:24:40 <kinlo> which is in line with that rule :)
149 2013-07-15 09:24:51 <petertodd> I figure I could have thrown python at the problem and it would have been fast enough :P
150 2013-07-15 09:25:19 <sipa> i'm pretty sure my seeder can sustain higher QPS!
151 2013-07-15 09:26:00 <kinlo> so, when the bugs are fixed, I could run another seed
152 2013-07-15 09:26:12 <kinlo> if it is still needed
153 2013-07-15 09:26:14 <petertodd> My Python program would have spat out a conf file for bind and the bug would have never even happened. Well, that exact bug...
154 2013-07-15 09:26:17 <petertodd> kinlo: please do
155 2013-07-15 09:26:38 <sipa> petertodd: that's how BlueMatt's seed worked (or still works)
156 2013-07-15 09:26:58 <sipa> it means hammering one subset of 20 nodes for a minute :p
157 2013-07-15 09:26:59 <kinlo> sipa's seed looks nicer, but more dangerous :)
158 2013-07-15 09:27:00 <petertodd> kinlo: there's your answere, run BlueMatt's seed for some redundency
159 2013-07-15 09:27:08 <sipa> (or however frequently you update)
160 2013-07-15 09:27:18 <sipa> yes, i'm completely in favor of NOT having all seeds run my code
161 2013-07-15 09:27:22 <kinlo> petertodd: nah :)
162 2013-07-15 09:27:33 <kinlo> sipa: we are talking testnetseeds
163 2013-07-15 09:27:46 <sipa> but but... what if testnet explodes?
164 2013-07-15 09:27:49 <petertodd> sipa: bind can happily be updated as often as you want... actually, amazon route 53 would be interesting as it'll automatically figure out what ip's should be served to what routing domains
165 2013-07-15 09:27:53 <kinlo> which is just that - while a testnet seed is usefull, imho it isn't that important
166 2013-07-15 09:27:59 <lianj> sipa: testnet4?
167 2013-07-15 09:28:01 <kinlo> how many nodes are on testnet?
168 2013-07-15 09:28:21 <petertodd> kinlo: ~50, althoguh disturbingly my seed isn't yet showing any
169 2013-07-15 09:28:43 <kinlo> it would be better just to add a few more fixed nodes
170 2013-07-15 09:28:44 <sipa> petertodd: my seed serves a different subset for each query
171 2013-07-15 09:29:01 <sipa> petertodd: even updating a static config every second would mean some degree of hammering
172 2013-07-15 09:29:15 <kinlo> my testnet node is connected to 23 other nodes... so I'm connected to half testnet? :)
173 2013-07-15 09:29:21 <petertodd> sipa: heck, you could just dump all of seeds.txt into bind...
174 2013-07-15 09:29:28 <petertodd> kinlo: very likely yes
175 2013-07-15 09:29:35 <sipa> petertodd: will it serve a random subset?
176 2013-07-15 09:29:50 <petertodd> sipa: pretty sure it has that feature, haven't looked in awhile
177 2013-07-15 09:29:53 <sipa> (i'm not too familiar with bind)
178 2013-07-15 09:30:27 <petertodd> sipa: I used to be, then I wound up in art school
179 2013-07-15 09:31:26 <sipa> it seems there is such a feature, indeed
180 2013-07-15 09:38:32 <kinlo> sipa: so there are 2 versions, BlueMatt's and your?
181 2013-07-15 09:38:35 <kinlo> +s
182 2013-07-15 09:40:45 <sipa> not really versions
183 2013-07-15 09:40:53 <sipa> BlueMatt has written a seeder long before i did
184 2013-07-15 09:41:04 <sipa> and then later a newer one based on BitcoinJ
185 2013-07-15 09:43:49 <BlueMatt> I have 2 :)
186 2013-07-15 09:43:56 <BlueMatt> (dont use the first, it will kill your server)
187 2013-07-15 09:44:22 <BlueMatt> in fact, probably dont use the second, I should write a new one in bitcoinj from the ground up
188 2013-07-15 09:44:40 <BlueMatt> dont use sipa's either, its a custom dns implementation
189 2013-07-15 09:44:51 <petertodd> lets just go back to irc
190 2013-07-15 09:44:55 <BlueMatt> yes
191 2013-07-15 09:45:11 <TD> hah
192 2013-07-15 09:45:20 <petertodd> kinlo: so, if you want to be lazy, don't run a dns seed, just run a testnet node and point your seed to it, for testnet that's *fine*
193 2013-07-15 09:45:20 <TD> i'm rather fond of the static array of ints, actually.
194 2013-07-15 09:45:24 <TD> when was the last time we refreshed that?
195 2013-07-15 09:45:35 <BlueMatt> been a while...
196 2013-07-15 09:45:38 <petertodd> TD: few months ago, I made a fuss about it
197 2013-07-15 09:45:50 <kinlo> petertodd: the dnsseed not really the problem :)
198 2013-07-15 09:46:06 <petertodd> kinlo: ?
199 2013-07-15 09:46:31 <petertodd> Hmm... actually we've got enough nodes on mainnet these days that just scanning the whole IPv4 space with a LFSR is reasonable.
200 2013-07-15 09:46:33 <kinlo> petertodd: it was already running, but I still need to configure a domain for it
201 2013-07-15 09:46:33 <TD> thanks
202 2013-07-15 09:47:09 <petertodd> kinlo: Ah, well I'd go for testnet-seed.bitcoin.kinlo.whatever... and do a pull-req and we're good to go.
203 2013-07-15 09:47:12 <kinlo> petertodd: that's a bit aggresive, plus it would make banning bitcoin very easy.... also non-standard ports...
204 2013-07-15 09:47:38 <petertodd> kinlo: Actually the seeds can't handle non-standard ports at all.
205 2013-07-15 09:47:46 <kinlo> they can't?
206 2013-07-15 09:47:47 <kinlo> mmmz
207 2013-07-15 09:47:55 <petertodd> kinlo: Nope, all they do is return addresses remember.
208 2013-07-15 09:48:02 <kinlo> would make sense to return txt records with the correct information
209 2013-07-15 09:48:15 <petertodd> Anyway you'd "just" need to scan ~85k IPv4's to find one bitcoind...
210 2013-07-15 09:48:38 <petertodd> kinlo: txt records are surprisingly difficult to get access too cross-platform, the libraries usually just want to return the standard stuff
211 2013-07-15 09:48:55 <petertodd> kinlo: it's fine until we have to start randomizing ports for other reasons...
212 2013-07-15 09:49:11 <kinlo> true
213 2013-07-15 09:49:24 <petertodd> kinlo: dns seeds don't work so well in those kinds of circumstances anyway
214 2013-07-15 09:49:41 <kinlo> they are pretty easy to block
215 2013-07-15 09:52:12 <petertodd> kinlo: at that stage we've probably got bigger issues anyway - bitcoin depends on jam-free networking, but that's really hard in a decentralized network where you don't know who your peers are
216 2013-07-15 09:52:38 <kinlo> jam-free?
217 2013-07-15 09:52:52 <petertodd> yeah, as in information should be difficult to stifle and easy to propagate
218 2013-07-15 09:53:27 <petertodd> if an attacker can easily make up the vast majority of nodes on the network you have problems
219 2013-07-15 10:02:29 <TD> maybe one day we'll get the pubkey-per-node thing
220 2013-07-15 10:03:10 <sipa> ^
221 2013-07-15 10:04:57 <BlueMatt> or we'll rely on another layer to handle this crap instead of implementing it in bitcoind
222 2013-07-15 10:05:08 <BlueMatt> (read: tor)
223 2013-07-15 10:05:26 <petertodd> TD: jdillon said he and his partners would be willing to contribute funding for a node-to-node encryption prototype, though we're probably maxed out on people who could do it anyway
224 2013-07-15 10:05:50 <petertodd> BlueMatt: careful, tor will find that relying on bitcoin helps them resist sybil attacks...
225 2013-07-15 10:05:52 <TD> BlueMatt: tor isn't really usable as a library, last time i looked. unfortunately :(
226 2013-07-15 10:06:12 <petertodd> If tor was usable as a library all sorts of attacks would be easier...
227 2013-07-15 10:06:49 <TD> BlueMatt: a full onion network is overkill for just verifying you're talking to a "real" bitcoin node though.
228 2013-07-15 10:07:05 <BlueMatt> TD: I didnt say library, I said let people who are most concerned about losing connection fix the issue (ie bitcoin backbone, if you're worried about getting attacked, use tor, etc)
229 2013-07-15 10:07:31 <TD> well, everyone should worry about being attacked, and the software should protect everyone as much as possible by default
230 2013-07-15 10:07:33 <petertodd> It's not overkill, they solve different problems. The best way I know of to verify you are talking to a "real" node is via PoW, and that has obvious issues.
231 2013-07-15 10:07:43 <TD> well, time based reputation of keys works too
232 2013-07-15 10:07:46 <BlueMatt> or separate p2p protocol that does any kind of fancy stuff you want
233 2013-07-15 10:07:57 <TD> "realness" is defined as "has been around a long time and behaved as i expected"
234 2013-07-15 10:08:47 <TD> having all of bitcoin run over a tor-alike network would be cool though. more privacy == better. but tor relies on centrally controlled directory servers
235 2013-07-15 10:08:48 <petertodd> It'll be tricky to figure out if nodes are, say, passing on transactions as expected.
236 2013-07-15 10:08:59 <TD> *shrug* send a tx to a single node, see if it propagates
237 2013-07-15 10:09:05 <TD> but yes. you can never do things perfectly.
238 2013-07-15 10:09:19 <petertodd> Not propagates, gets mined.
239 2013-07-15 10:10:03 <petertodd> Sorting nodes by how often they pass us tx's that later get mined looks to be a very viable strategy against certain types of attacks.
240 2013-07-15 10:10:19 <petertodd> Just not the attack where someone is trying to monitor the whole network.
241 2013-07-15 10:11:43 <TD> yes, well, i suppose tor+some batching/padding to resist traffic analysis could maybe annoy PRISM operators. but an omniscient observer is practically the hardest threat model possible
242 2013-07-15 10:11:52 <TD> or rather, maybe Bitcoin-over-Poind
243 2013-07-15 10:11:55 <TD> er, Pond
244 2013-07-15 10:12:05 <TD> (https://github.com/agl/pond)
245 2013-07-15 10:15:01 <petertodd> Right, so it's tor - timing attacks really.
246 2013-07-15 10:15:44 <TD> why do you say tor would be more attackable if it were usable as a library?
247 2013-07-15 10:15:58 <petertodd> We can, and actually should, do something similar in Bitcoin in the flood fill algorithm; flooding to everyone simultaneously is actually non-ideal from an efficiency point of view.
248 2013-07-15 10:16:19 <petertodd> TD: makes it easier for attackers to write code that does stuff with tor, a weak defense, but a defense against the kiddies
249 2013-07-15 10:17:01 <swulf--> petertodd: ahh, you're right. My code that downloaded the block serialized it with an extra byte at the end. Oops:)
250 2013-07-15 10:19:27 <petertodd> swulf--: cool, what are you making?
251 2013-07-15 10:22:49 <swulf--> petertodd: two things - one a simple client that lets me be more specific with transaction creation. I can specify every source of every input and the order, as well as the order of outputs.
252 2013-07-15 10:23:10 <petertodd> swulf--: reasonable goals
253 2013-07-15 10:23:24 <swulf--> peter: the second bit is that because the bitcoin-network code stuff is separate from the gui, i intend to use it as a tx processor
254 2013-07-15 10:24:19 <petertodd> swulf--: also reasonable, diversity in tx engines isn't a bad thing so long as you don't mine with them
255 2013-07-15 10:24:43 <petertodd> swulf--: although I will say you are likely duplicating other work
256 2013-07-15 10:25:05 <swulf--> most likely
257 2013-07-15 10:25:18 <swulf--> that's ok, it's kinda self-educational too
258 2013-07-15 10:25:44 <swulf--> while the real goal is to make something usualable (mainly for myself), i'm also using it as an excuse to get a much better understanding of how bitcoin works
259 2013-07-15 10:26:02 <petertodd> yup, and it's much more useful than writing yet another irc client
260 2013-07-15 12:52:42 <helo> block propagation time is pretty important for miners, so would (a large portion of relaying nodes) running over tor would encourage pretty small blocks?
261 2013-07-15 12:55:10 <TD> the time needed to relay over tor is only a bit higher than normal once the circuits are built, that's why it's usable for interactive browsing. with a 10 minute solve time, it's probably not a big deal as long as the propagation is optimized (i.e. sending lists of hashes not repeating tx data)
262 2013-07-15 12:58:56 <petertodd> helo: what makes you think block propagation time is important?
263 2013-07-15 13:05:54 <helo> for miners, the chance of their block being orphaned increases with its propagation time
264 2013-07-15 13:06:16 <TD> Threema.ch is very interesting
265 2013-07-15 13:06:40 <petertodd> Yes, but the chance of their block also being orphaned depends on their hashing power - if you have more hashing power, you have less orphans regardless of other factors.
266 2013-07-15 13:06:48 <TD> end to end, highly usable android/ios messaging app. proprietary!!! but, they claim it's verifiable by decrypting messages using your exported private key and the messages it sends
267 2013-07-15 13:07:10 <BlueMatt> you just have to trust it doesnt upload your keys...
268 2013-07-15 13:07:11 <TD> uses ECDHE via a nacl cryptobox
269 2013-07-15 13:07:24 <TD> yeah, indeed. it seems like it's not really verifiable unless you can trace all network traffic and verify that
270 2013-07-15 13:07:26 <petertodd> In addition, you only need to reliably get your blocks to more than 50% of the hashing power to on average get your blocks confirmed; mining is a random process, but in the long run if fees matter that's the better strategy.
271 2013-07-15 13:07:43 <TD> still, they accept bitcoin, and they seem to have the right crypto chops to pull it off
272 2013-07-15 13:07:56 <TD> it's probably safe for now unless a state forces them to backdoor it, but they let you install it outside the play store for that reason
273 2013-07-15 13:08:14 <petertodd> It gets complex though, because your competitors can work on empty blocks, and block headers always can propegate very fast. But then again, those competitors don't need to validate your block to build upon it with an empty one.
274 2013-07-15 13:08:14 <TD> if they could make a more robust way to verify the app, it'd be very interesting
275 2013-07-15 13:08:39 <TD> as it has all the features you might want from a real messaging app like WhatsApp, etc. sync with your phone book, swap public keys via qrcode or using them as a keyserver, share media, locations, etc
276 2013-07-15 13:09:11 <petertodd> Finally some people want blocks that aren't "full enough" to be discouraged somehow, so with rules like that, who knows what the incentives will be?
277 2013-07-15 13:10:14 <TD> i mean there's a chance i could convince my family to use this (maybe)
278 2013-07-15 13:10:30 <TD> the crypto only really surfaces if you actually want to upgrade verifiability to web-of-trust level
279 2013-07-15 13:10:32 <TD> which is nice
280 2013-07-15 14:10:51 <petertodd> Threema isn't open source...
281 2013-07-15 14:11:45 <TD> indeed. open source and "usable gui" seem to be mutually incompatible, unfortunately.
282 2013-07-15 14:12:52 <TD> what intrigues me is their approach to verification. you can actually dump encrypted messages and decrypt them using NaCL
283 2013-07-15 14:13:15 <TD> it seems like this isn't worth much though, because you aren't really verifying the network traffic itself. and the app could sneak out your key via a side channel in a lot of different ways.
284 2013-07-15 14:14:09 <petertodd> indeed - I was very impressed when I noticed that whispersystems textsecure goes over standard text messages, letting me easily verify they really are encrypted
285 2013-07-15 14:14:15 <petertodd> far from full trust, but a nice touch
286 2013-07-15 14:14:32 <petertodd> keeps whispersystems away from knowing metadata too
287 2013-07-15 14:14:47 <TD> yeah. though your telco gets the data instead.
288 2013-07-15 14:14:59 <TD> avoiding metadata collection seems rather hard. i guess you could use threema to bootstrap pond.
289 2013-07-15 14:15:56 <TD> it seems with a few tweaks threema could be "good enough", at least for a lot of people. in particular the company and all infrastructure is based in switzerland
290 2013-07-15 14:16:18 <TD> the swiss government is rather non evil. they can be pressured by the US but it causes a giant very public ruckus when they do. at least until we find out that swiss intelligence cooperates with the NSA behind the back of parliament .....
291 2013-07-15 14:16:29 <petertodd> heh
292 2013-07-15 14:16:30 <TD> but it seems like you won't find a better way to do jurisdictional arbitrage
293 2013-07-15 14:17:14 <petertodd> Best way I know of re: metadata requires secure hardware really - remote attesting tor nodes that to constant rate traffic.
294 2013-07-15 14:17:19 <petertodd> Pipe dream
295 2013-07-15 14:17:20 <TD> if the app had a way to export all the keys you need to decrypt the wire traffic and then you could use their existing verification procedure, the remaining issue would be side channels. however, if you don't accept auto updates, and you start out by being boring to potential attackers, it's only an issue if the app is pre-backdoored
296 2013-07-15 14:17:23 <TD> which would be unlikely
297 2013-07-15 14:17:47 <TD> yeah, well pond does almost like that. timed, padded transfers across tor.
298 2013-07-15 14:18:12 <petertodd> Yes, but pond has no way of proving that you haven't been sybiled.
299 2013-07-15 14:18:24 <TD> well, the assumption is you swap keys offline
300 2013-07-15 14:18:28 <TD> so it just punts on the whole problem really
301 2013-07-15 14:19:05 <petertodd> Sure does. Freenet works great for instance... if you use it in darknet mode. Good luck on that.
302 2013-07-15 14:19:33 <petertodd> Bitcoin probably has more chance of working in darknet mode, but only because there are good incentives for merchants to do it. (less so for miners)
303 2013-07-15 14:19:39 <arthurb> Hello all, quick question. If I make an RPC call for getnewaddress on a non exisiting account, a new account is created. Is it guaranteed that this account will have a balance of 0?
304 2013-07-15 14:20:33 <arthurb> Because I was idly playing with this, offline, with a non up to date blockchain... and I created new accounts which were given a non zero balance. I haven't been able to reproduce it though.
305 2013-07-15 14:21:46 <petertodd> arthurb: The accounts code has very curious behavior - I'd be hesitent to use it for any projects myself.
306 2013-07-15 14:22:08 <arthurb> what do you suggest instead?
307 2013-07-15 14:22:35 <pigeons> external db
308 2013-07-15 14:22:37 <petertodd> arthurb: roll your own isn't an unreasonable idea (assuming you are making a website or something)
309 2013-07-15 14:23:05 <arthurb> so basically reimplement the account feature?
310 2013-07-15 14:23:35 <pigeons> yes
311 2013-07-15 14:23:37 <petertodd> arthurb: yes
312 2013-07-15 14:25:47 <arthurb> so I should poll addresses regularly to see if they have received coins with confirmations, and credit that to the associated account (in my own db). How do you suggest I don't add multiple time the amount? Keep a running tally of the coins "accounted for" for a given address?
313 2013-07-15 14:30:21 <petertodd> Remind me not to let people with math degrees touch my hardware... 12V into a 5V bus just made a few hundred dollars and a day or two worth of magic smoke leak out.
314 2013-07-15 14:30:32 <petertodd> ACTION shouldn't have eaten lunch.
315 2013-07-15 15:28:29 <helo> how are reorg implications (possibly reduced confirmations) handled when using -walletnotify?
316 2013-07-15 15:29:27 <sipa> if the transaction moves to a new chain, it's notified again
317 2013-07-15 15:31:48 <helo> so i guess a typical approach is to call gettransaction and verify that things are kosher?
318 2013-07-15 15:32:40 <runeks> Is there any way to list the transactions that have an output that pays to a specified address?
319 2013-07-15 15:32:50 <runeks> Using bitcoind
320 2013-07-15 15:33:15 <runeks> I'm using blockchain.info, but it's rather unstable. It's down now, for example.
321 2013-07-15 15:34:14 <sipa> listreceivedbyaddress
322 2013-07-15 15:34:54 <runeks> sipa: I should mention that I don't have the private key for the address in question.
323 2013-07-15 15:35:07 <runeks> (Ie. the address is not in the bitcoind wallet)
324 2013-07-15 15:36:42 <pigeons> there is a watch-only patch, doesn't seem to work against HEAD last i checked, where you can import the public key only and do listtransactions
325 2013-07-15 15:37:40 <runeks> pigeons: Interesting. Where would I find that? Does it work against 0.8.3?
326 2013-07-15 15:38:24 <runeks> pigeons: And do you know if it also works with getreceivedbyaddress?
327 2013-07-15 15:38:48 <pigeons> try here, i don't know it should at least help you find the latest https://github.com/bitcoin/bitcoin/pull/2121
328 2013-07-15 15:39:37 <runeks> pigeons: Thanks!
329 2013-07-15 15:39:49 <helo> be careful when compiling your own bitcoind that you link against libdb4.x and not libdb5.x
330 2013-07-15 15:40:21 <helo> unless you've already ran your wallet on a bitcoind linked against libdb5.x... then you're stuck.
331 2013-07-15 15:40:28 <pigeons> can't really convert a newer wallet back down easily
332 2013-07-15 15:41:32 <helo> pigeons: db has dump/load utils that should work, but it's probably best avoided if possible
333 2013-07-15 15:42:46 <helo> sipa: did you verify that there is a wallet backwards-compat issue between head and 0.8.3?
334 2013-07-15 15:44:04 <helo> i.e. that db5dump | db4load wasn't causing TradeFortress' problems
335 2013-07-15 15:44:52 <helo> (causing the wallet corrupted errors with db4.x bitcoind)
336 2013-07-15 17:12:25 <runeks> pigeons: Looks like something about key storage has changed in bitcoin-qt since that patch. I can't figure out how to rebase it :\\.
337 2013-07-15 17:13:28 <pigeons> yeah go back more
338 2013-07-15 17:14:33 <runeks> pigeons: What do you mean by that?
339 2013-07-15 17:15:20 <pigeons> are you applying to head?
340 2013-07-15 17:15:29 <pigeons> don't, go back earlier
341 2013-07-15 17:15:36 <runeks> Oh ok.
342 2013-07-15 17:16:19 <pigeons> obviously dont ever listen to me for anything important, etc
343 2013-07-15 17:18:39 <gmaxwell> if you run recent git but not head it will make your wallet incompatible with 0.8.3
344 2013-07-15 17:20:02 <runeks> Looks like this is the commit that changed it: https://github.com/bitcoin/bitcoin/commit/dfa23b94c24aae6466152fccbe896ba5dc0e97b4
345 2013-07-15 17:20:35 <runeks> gmaxwell: Thanks for the heads up.
346 2013-07-15 17:25:25 <runeks> The patch https://github.com/bitcoin/bitcoin/pull/2121.patch builds against ec0004aca0a2bf11f99c9587ddb2bf8ea818d3bb
347 2013-07-15 17:29:44 <runeks> But adding an address doesn't work :\\
348 2013-07-15 17:29:45 <runeks> error: {"code":-4,"message":"Error adding address to wallet"}
349 2013-07-15 17:30:04 <runeks> I'll look at it later, I'm outie.
350 2013-07-15 17:37:49 <michagogo> runeks: Is the wallet encrypted? If so, don
351 2013-07-15 17:38:02 <michagogo> runeks: Is the wallet encrypted? If so, don't forget to `walletpassphrase`
352 2013-07-15 18:06:58 <sipa> helo: yes, that problem was found