1 2013-02-18 00:06:06 <jaakkos> TD: hmm, i sent from the reference wallet 0.05BTC and i can't see the tx even if i'm sure the app was awake
2 2013-02-18 00:06:20 <jaakkos> http://blockchain.info/tx-index/53969042/13c87f72ed652dc85c3728440832ea9c078f5e98b26c90624eff99f5a67e4a95
3 2013-02-18 00:06:41 TD has quit (Quit: TD)
4 2013-02-18 00:08:08 word has joined
5 2013-02-18 00:12:34 asa1024 has joined
6 2013-02-18 00:12:43 vigilyn has joined
7 2013-02-18 00:18:31 RBecker is now known as rbecker
8 2013-02-18 00:18:31 bitcoinbulletin has quit (Quit: bitcoinbulletin)
9 2013-02-18 00:18:35 <gmaxwell> bluematt: awesome coverage results, though the link should include a link to the baseline coverage.
10 2013-02-18 00:21:19 zooko has joined
11 2013-02-18 00:21:50 <jaakkos> is it possible to make the reference wallet spend unconfirmed transactions, even if it's not change?
12 2013-02-18 00:22:25 <Luke-Jr> jaakkos: yes, it's a bad idea
13 2013-02-18 00:23:26 <jaakkos> what if i want to experiment
14 2013-02-18 00:23:30 <sipa> it's a trivial patch, but quite dangerous to do - you make yourself (and anyone you send coins to) vulnerable to long chains of invalidations
15 2013-02-18 00:24:33 <Luke-Jr> jaakkos: do it on testnet :P
16 2013-02-18 00:25:16 <sipa> TIL: GCC 4.6 on 64-bit platforms has a __int128 type
17 2013-02-18 00:25:21 zooko` has joined
18 2013-02-18 00:25:36 <Luke-Jr> sipa: useful?
19 2013-02-18 00:25:48 <sipa> Luke-Jr: very much so, if you want to implement your own bigint :)
20 2013-02-18 00:26:08 <sipa> or try to write an optimized secp256k1 ECDSA from scratch
21 2013-02-18 00:26:40 <sipa> the CPU can actually a multiplication of 2 64-bit numbers in a single operation, with 2 64 bits numbers as output
22 2013-02-18 00:27:02 zooko has quit (Ping timeout: 252 seconds)
23 2013-02-18 00:27:16 <Luke-Jr> sipa: as long as they don't overflow :P
24 2013-02-18 00:28:12 bitcoinbulletin has joined
25 2013-02-18 00:28:51 <sipa> ?
26 2013-02-18 00:29:31 <sipa> that's the point exactly: it allows you to do: __int128 x = (__int128)a*b, where a and b are 64-bit numbers
27 2013-02-18 00:29:48 <sipa> and then retrieve the low 64 and high 64 bit from x
28 2013-02-18 00:30:02 <Luke-Jr> oh
29 2013-02-18 00:30:21 <Luke-Jr> I thought you meant a * b and a * c in one operation
30 2013-02-18 00:30:39 <Luke-Jr> (pack b and c into a single register)
31 2013-02-18 00:30:41 <sipa> oh no, it's not simd
32 2013-02-18 00:30:51 <gmaxwell> yea, the processor already lets you do this but C doesn't expose it well except by using the type.
33 2013-02-18 00:31:20 <fiesh> what cpu?
34 2013-02-18 00:31:27 TwilightSparklee has joined
35 2013-02-18 00:31:34 <sipa> any 64-bit amd/intel
36 2013-02-18 00:31:38 <fiesh> nice
37 2013-02-18 00:31:41 <Luke-Jr> gmaxwell: I don't get why GCC doesn't just implement [u]int* with multiple opcodes and consider these things optimizations
38 2013-02-18 00:31:47 <gmaxwell> x86's low/high multiplies and carry flags, for example. The same thing was true for 64 bits on 32 bit cpus.
39 2013-02-18 00:31:56 <Luke-Jr> hide the details from the program
40 2013-02-18 00:32:21 axhlf has joined
41 2013-02-18 00:32:22 <gmaxwell> Luke-Jr: because e.g. getting atomiticy right for random types is hard.
42 2013-02-18 00:32:33 PhantomSpark has joined
43 2013-02-18 00:32:47 <Luke-Jr> gmaxwell: are int types supposed to be atomic? :o
44 2013-02-18 00:33:04 * Luke-Jr 's been writing with the assumption there's a possibility of a race <.<
45 2013-02-18 00:33:50 <sipa> is there a way to access the adc (add with carry) instruction in GCC?
46 2013-02-18 00:34:17 <sipa> clearly, adding two __int128's together with result in an adc instruction to add the two lower halfs together
47 2013-02-18 00:34:31 <sipa> but it must be possible for just 64-bit types too
48 2013-02-18 00:34:33 <gmaxwell> Luke-Jr: I'm a little unclear on what the C spec _requires_ but in practice all the primitive types are atomic for read and write, so long as they're correctly aligned.
49 2013-02-18 00:34:44 <gmaxwell> sipa: inline asm.
50 2013-02-18 00:34:49 <sipa> gmaxwell: meh
51 2013-02-18 00:35:15 <muhoo> with barriers?
52 2013-02-18 00:35:21 frosks has quit (Ping timeout: 244 seconds)
53 2013-02-18 00:35:32 TwilightSparklee has quit (Client Quit)
54 2013-02-18 00:35:55 TwilightSparklee has joined
55 2013-02-18 00:35:58 <fiesh> http://llvm.org/docs/doxygen/html/APInt_8cpp.html#a1dcb210aee6db4fbd6c608c9195a48d8
56 2013-02-18 00:36:26 <Luke-Jr> gmaxwell: if the spec doesn't require it, I'd personally prefer to just have them all work even if non-atomic :P
57 2013-02-18 00:37:29 <gmaxwell> Luke-Jr: and, in any case, you've gotta use a library if you want portable (to other compilers) code. ::shrugs::
58 2013-02-18 00:37:41 <Luke-Jr> gmaxwell: I don't ;)
59 2013-02-18 00:37:47 <EvanR3> concurrent C is infuriating
60 2013-02-18 00:37:54 <Luke-Jr> well, except maybe Clang, but anything GCC adds will get in there too
61 2013-02-18 00:42:46 TwilightSparkl-1 has joined
62 2013-02-18 00:43:51 TwilightSparklee has quit (Ping timeout: 256 seconds)
63 2013-02-18 00:47:23 <gmaxwell> sipa: I wouldn't be shocked if the compiler managed to convert some tests for overflow into a test of the carry flag.
64 2013-02-18 00:50:26 TwilightSparkl-1 has quit (Quit: Colloquy for iPhone - http://colloquy.mobi)
65 2013-02-18 00:57:44 BTCTrader has quit (Quit: BTCTrader)
66 2013-02-18 00:58:58 Eagle[TM] has joined
67 2013-02-18 01:02:52 moarrr has quit ()
68 2013-02-18 01:07:50 BTCTrader has joined
69 2013-02-18 01:21:37 ahbritto_ has joined
70 2013-02-18 01:26:17 zooko` has quit (Ping timeout: 248 seconds)
71 2013-02-18 01:28:23 kytv has joined
72 2013-02-18 01:29:42 ielo has joined
73 2013-02-18 01:31:49 i2pRelay has joined
74 2013-02-18 01:50:49 b4tt3r135 has quit (Ping timeout: 248 seconds)
75 2013-02-18 02:00:17 BTCTrader has quit (Quit: BTCTrader)
76 2013-02-18 02:01:34 zooko` has joined
77 2013-02-18 02:05:22 BTCTrader has joined
78 2013-02-18 02:17:49 <Luke-Jr> #bitcoin-watch now running 0.8
79 2013-02-18 02:18:19 haberdasher has joined
80 2013-02-18 02:23:00 <BCB> Luke-Jr, what is your bot
81 2013-02-18 02:23:08 <Luke-Jr> BCB: Supybot?
82 2013-02-18 02:23:22 <BCB> what is it doing
83 2013-02-18 02:23:37 <Luke-Jr> #Bitcoin-Watch announces transactions and trades in realtime
84 2013-02-18 02:23:45 <Luke-Jr> 0.8 is still catching up on blocks tho
85 2013-02-18 02:24:03 <BCB> what is it broadcasting right now
86 2013-02-18 02:24:05 <BCB> blocks
87 2013-02-18 02:24:07 HarriOrri has joined
88 2013-02-18 02:24:17 <Luke-Jr> I think it's 1-2 weeks behind now
89 2013-02-18 02:24:39 <BCB> it's posting all thes3 25 btc trades. very strange
90 2013-02-18 02:24:46 <Luke-Jr> they're blocks
91 2013-02-18 02:25:42 <BCB> ahh
92 2013-02-18 02:25:59 <BCB> is amt after the decimal fees
93 2013-02-18 02:26:09 <Luke-Jr> yes
94 2013-02-18 02:27:49 zooko` has quit (Ping timeout: 256 seconds)
95 2013-02-18 02:27:53 zackham has joined
96 2013-02-18 02:29:36 da2ce7_d has quit (Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/)
97 2013-02-18 02:30:43 LainZ has joined
98 2013-02-18 02:30:51 zooko` has joined
99 2013-02-18 02:31:24 <K1773R> Luke-Jr: why isnt it being killed for flooding?
100 2013-02-18 02:32:03 <Luke-Jr> K1773R: because it's not flooding, according to freenode :P
101 2013-02-18 02:32:20 <Luke-Jr> that's also why it's takign so long to catch up :/
102 2013-02-18 02:33:15 ielo has quit (Quit: Leaving)
103 2013-02-18 02:33:19 <Luke-Jr> hmm, kinda surprising to see so many repeat block-payees
104 2013-02-18 02:33:41 <Luke-Jr> looks like some miners are quite capable at double-spending at 1-2 confirms
105 2013-02-18 02:36:08 zooko`` has joined
106 2013-02-18 02:37:15 reizuki__ has joined
107 2013-02-18 02:39:03 zooko` has quit (Ping timeout: 264 seconds)
108 2013-02-18 02:53:38 BCBot has quit (Read error: Connection reset by peer)
109 2013-02-18 02:53:52 BCBot has joined
110 2013-02-18 03:09:47 paraipan has quit (Quit: Saliendo)
111 2013-02-18 03:30:44 vigilyn2 has joined
112 2013-02-18 03:30:45 vigilyn has quit (Read error: Connection reset by peer)
113 2013-02-18 03:32:34 darkskiez has quit (Ping timeout: 245 seconds)
114 2013-02-18 03:33:03 darkskiez has joined
115 2013-02-18 03:33:14 Goonie has quit (Ping timeout: 248 seconds)
116 2013-02-18 03:34:22 zooko`` is now known as zooko
117 2013-02-18 03:37:59 gjs278 has quit (Remote host closed the connection)
118 2013-02-18 03:38:42 v1rtex has joined
119 2013-02-18 03:48:00 denisx has joined
120 2013-02-18 03:51:01 fiesh has quit (Ping timeout: 276 seconds)
121 2013-02-18 03:51:52 denisx has quit (Client Quit)
122 2013-02-18 03:53:26 fiesh has joined
123 2013-02-18 03:54:33 gjs278 has joined
124 2013-02-18 03:55:30 <muhoo> wat?
125 2013-02-18 03:58:42 cjd has joined
126 2013-02-18 03:58:55 <cjd> \o/
127 2013-02-18 03:59:03 theorb has joined
128 2013-02-18 04:00:15 EagleTM has joined
129 2013-02-18 04:00:55 Eagle[TM] has quit (Ping timeout: 248 seconds)
130 2013-02-18 04:03:18 theorbtwo has quit (Ping timeout: 252 seconds)
131 2013-02-18 04:03:19 theorb is now known as theorbtwo
132 2013-02-18 04:04:10 meLon_ has joined
133 2013-02-18 04:04:17 meLon_ has quit (Client Quit)
134 2013-02-18 04:06:26 copumpkin has quit (Ping timeout: 252 seconds)
135 2013-02-18 04:07:00 copumpkin has joined
136 2013-02-18 04:10:59 Zarutian has quit (Quit: Zarutian)
137 2013-02-18 04:20:54 darkskiez has quit (Ping timeout: 245 seconds)
138 2013-02-18 04:23:17 darkskiez has joined
139 2013-02-18 04:27:30 da2ce7 has joined
140 2013-02-18 04:29:45 rbecker is now known as RBecker
141 2013-02-18 04:30:48 forrestv has quit (Changing host)
142 2013-02-18 04:30:48 forrestv has joined
143 2013-02-18 04:30:50 nimdAHK has joined
144 2013-02-18 04:34:50 <cjd> Hi guys, I understand there has been some renewed interest in pull 1498, the cjdns patch... Based on the responses I think maybe I don't understand the patch as much as I thought I did.
145 2013-02-18 04:35:39 <cjd> It seems to me that the "right" approach would be to have no effect unless `-net cjdns` is enabled, if it is then to share fc addrs only with fc nodes.
146 2013-02-18 04:36:06 <cjd> Based on the assumption that if you enable `-net cjdns` then you do not care about using the fc space for anything else
147 2013-02-18 04:36:33 <cjd> I originally thought the patch did just this but I'm not so sure given the reactions.
148 2013-02-18 04:44:11 swappermall has quit (Quit: ChatZilla 0.9.90 [Firefox 18.0.2/20130201065344])
149 2013-02-18 04:50:48 da2ce7 has quit (Ping timeout: 251 seconds)
150 2013-02-18 05:06:05 TheSeven has quit (Disconnected by services)
151 2013-02-18 05:06:14 [7] has joined
152 2013-02-18 05:08:52 ThomasV has joined
153 2013-02-18 05:11:36 da2ce7 has joined
154 2013-02-18 05:17:10 JDuke128 has joined
155 2013-02-18 05:18:20 denisx has joined
156 2013-02-18 05:19:57 WolfAlex_ has joined
157 2013-02-18 05:21:19 WolfAlex has quit (Read error: Operation timed out)
158 2013-02-18 05:25:14 gjs278 has quit (Remote host closed the connection)
159 2013-02-18 05:30:37 meLon has quit (Ping timeout: 260 seconds)
160 2013-02-18 05:30:51 FredEE has quit (Quit: FredEE)
161 2013-02-18 05:31:11 meLon has joined
162 2013-02-18 05:32:31 <phantomcircuit> cjd, the patch as supplied is correct
163 2013-02-18 05:33:05 <phantomcircuit> the issue sipa was bringing up was (I believe and im sure he'll correct me if im wrong) that using all of that link local address space might be an issue
164 2013-02-18 05:33:42 <phantomcircuit> iirc cjdns uses a smaller prefix than onioncat or i2p
165 2013-02-18 05:33:50 <cjd> it uses a /8
166 2013-02-18 05:34:16 <phantomcircuit> isn't that like
167 2013-02-18 05:34:21 <phantomcircuit> trillions of addresses?
168 2013-02-18 05:34:37 <cjd> enough that a collision is not likely
169 2013-02-18 05:34:49 <phantomcircuit> well anyways im just saying i think that's what sipa's comment was
170 2013-02-18 05:34:56 <phantomcircuit> i dont see any issues with the patch other than that
171 2013-02-18 05:35:09 <phantomcircuit> i doubt it would merge perfectly anymore but an updated patch would be trivial
172 2013-02-18 05:35:40 gjs278 has joined
173 2013-02-18 05:36:37 gjs278 has quit (Remote host closed the connection)
174 2013-02-18 05:37:56 <cjd> well if it in any way affects nodes which don't enable `-net cjdns` then it's not working as I would like it to, if it doesn't then it's a social decision whether we want to allow users the option of cjdns
175 2013-02-18 05:39:03 warren has left ("Leaving")
176 2013-02-18 05:39:41 meLon has quit (Quit: leaving)
177 2013-02-18 05:40:02 meLon has joined
178 2013-02-18 05:40:25 WolfAlex_ has quit (Read error: Operation timed out)
179 2013-02-18 05:40:28 WolfAlex has joined
180 2013-02-18 05:43:42 hahuang65 has joined
181 2013-02-18 05:46:53 JZavala has quit (Ping timeout: 260 seconds)
182 2013-02-18 05:54:28 WolfAlex_ has joined
183 2013-02-18 05:55:30 gjs278 has joined
184 2013-02-18 05:57:09 WolfAlex has quit (Ping timeout: 245 seconds)
185 2013-02-18 06:02:11 nimdAHK has quit (Ping timeout: 245 seconds)
186 2013-02-18 06:07:01 <gmaxwell> cjd: if you want behavior that has no effect of nodes not running cjdns then you don't need to modify bitcoin at all.
187 2013-02-18 06:07:48 <cjd> hmm but won't it consider fc addresses non-routable?
188 2013-02-18 06:08:02 <gmaxwell> It will connect to non-routable addresses if you explicitly tell it to.
189 2013-02-18 06:08:20 <gmaxwell> Bitcoin will happily connect to IPv6 addressesâ the patch is needed to get them to relay the addresses of CJDNS nodes... of course if you're relaying them then you're changing the behavior of other nodes.
190 2013-02-18 06:08:23 <cjd> ideally it would share fc addresses with nodes behind other fc addresses
191 2013-02-18 06:08:41 <gmaxwell> Thats not how any of the bitcoin networking currently works.
192 2013-02-18 06:08:44 <cjd> indeed, it should not relay fc addresses to non-cjdns nodes
193 2013-02-18 06:08:53 <cjd> ok so non-trivial
194 2013-02-18 06:08:56 <cjd> that's unfortunate
195 2013-02-18 06:09:27 <cjd> thanks for the explanation
196 2013-02-18 06:09:27 <gmaxwell> Maybe a good idea to support that too, though it presents some bootstrapping challenges. (e.g. you can find IPv6 peers by connecting to an IPv4 peer and hearing about IPv6 peers)
197 2013-02-18 06:09:50 <gmaxwell> If it did work that way we'd have less concerns about the huge chunk of address space CJDNS is gobbling up, I guess.
198 2013-02-18 06:10:33 <cjd> otoh the risk is that someone running a non-cjdns fc based network would receive cjdns addresses and try to connect to them and fail
199 2013-02-18 06:10:47 <cjd> and vice versa
200 2013-02-18 06:11:24 gjs278 has quit (Remote host closed the connection)
201 2013-02-18 06:11:36 <cjd> it poisons the address pool for them to be shared but it doesn't mean they can't be shared at all
202 2013-02-18 06:11:45 <gmaxwell> cjd: nodes know what network's they're connected toâ and wouldn't try to connect to cjdns (or if they are pre-cjdns â nonroutable).
203 2013-02-18 06:12:33 <cjd> I'm imagining cjdns and another network share an addr space, 2 nodes are connected over ipv4 and they have different meanings for fc space
204 2013-02-18 06:12:46 <cjd> so they end up trying to connect to nodes which aren't there
205 2013-02-18 06:12:56 <cjd> but it doesn't actually fail, it just sucks
206 2013-02-18 06:13:47 * BTCTrader now feels highly informed about this
207 2013-02-18 06:15:04 <gmaxwell> ugh. Why is 2112 such a blinking jerk.
208 2013-02-18 06:15:22 <cjd> o_O
209 2013-02-18 06:16:36 <gmaxwell> cjd: that was WRT context that isn't apparent from IRC.
210 2013-02-18 06:16:53 <cjd> ic
211 2013-02-18 06:17:21 <cjd> do nodes announce capabilities when they connect to other nodes?
212 2013-02-18 06:17:36 <cjd> I should know this but my memory is like that of a goldfish
213 2013-02-18 06:18:56 <cjd> anyway if there were a capability flag bitset then all of the alt networks could be piled into that and only shared on an as-requested basis, ofc I'm not writing a patch here, just musing randomly so I'll shutup
214 2013-02-18 06:19:20 <gmaxwell> cjd: There are node flags which are part of the address announcements. As well as a protocol version sent on conncet.
215 2013-02-18 06:19:40 <gmaxwell> cjd: it would still have conflicting usage of the address space.
216 2013-02-18 06:20:08 <gmaxwell> We we should probably do is change the protocol so that there is a seperate network identifier, and not require us to shove everything into a v6 address...
217 2013-02-18 06:20:23 <gmaxwell> We need this in order to support I2P since its node identifiers can't be fit in v6.
218 2013-02-18 06:20:39 <cjd> interesting
219 2013-02-18 06:21:05 <BTCTrader> i2p support would also be very useful
220 2013-02-18 06:22:10 <BTCTrader> when is a possible roadmap for such a change? version 0.9 of bitcoin?
221 2013-02-18 06:22:39 <cjd> well it looks like the problem is that if anyone else uses the fc space then nodes are going to be attempting to connect to addresses which overlap but they're in the wrong network, IMO it's not actually a disaster and if network ids were added later then it would be resolved w/o breaking backward compat..
222 2013-02-18 06:23:27 <cjd> so that's an approach, ofc it all depends on enough people being mutually interested in bitcoin and cjdns
223 2013-02-18 06:23:37 <gmaxwell> BTCTrader: not any time soon.
224 2013-02-18 06:24:32 <gmaxwell> cjd: I think that we're not really inclined to gobble up all the FC space for something less popular than tor. :(
225 2013-02-18 06:24:33 <BTCTrader> personally i compare cjdns to networks as bitcoin is to currencies
226 2013-02-18 06:24:46 <SomeoneWeird> <gmaxwell> cjd: I think that we're not really inclined to gobble up all the FC space for something less popular than tor. :( < less popular, atm :P
227 2013-02-18 06:25:08 owowo has joined
228 2013-02-18 06:25:38 <gmaxwell> Yes, sure, and if it became as popular as tor then I don't think we'd hesitate. ... I also would love to have good cjdns support regardless of how popular cjdns is.
229 2013-02-18 06:25:43 <cjd> gmaxwell: that's valid, IMO it's not actually gobbling up because multiple networks can share the space, just there will be failed connection attempts
230 2013-02-18 06:26:50 <cjd> and ofc if network ids were added later then the problem of collisions would be solved before it occured
231 2013-02-18 06:27:11 <gmaxwell> BTCTrader: we wouldn't make the change for the purpose of supporting I2P / CJDNS. If we change it it will be some that addr messages can be cryptographically signed (and potentially include proof of work). The seperated network bit would just be an improvement that would come along 'for free'.
232 2013-02-18 06:27:58 B0g4r7 has quit (Ping timeout: 276 seconds)
233 2013-02-18 06:29:34 <BTCTrader> gotchya. that's freaking cool btw :D
234 2013-02-18 06:32:31 B0g4r7 has joined
235 2013-02-18 06:35:53 gjs278 has joined
236 2013-02-18 06:38:20 b4tt3r135 has joined
237 2013-02-18 06:40:07 grau has joined
238 2013-02-18 06:43:46 <cjd> https://github.com/bitcoin/bitcoin/pull/1498#issuecomment-13708066 <-- I kind of took minutes and stated my position
239 2013-02-18 06:44:47 <gmaxwell> cjd: thanks.
240 2013-02-18 06:45:03 ThomasV has quit (Read error: Operation timed out)
241 2013-02-18 06:45:19 <cjd> yeah, at least if someone else comes along, they'll know what the costs and benefits are
242 2013-02-18 06:46:42 <gmaxwell> cjd: another alternative would be to design an alternative p2p protocol for bitcoin on cjdns. then nodes could -addnode localcjdnsgateway:port Doing this would let you take advantage of the different properties of cjdns to get better performance or reliablity.
243 2013-02-18 06:46:46 <Luke-Jr> cjd: if it wasn't such a huge amount of space, I'd suggest maybe you could get an IPv6 assignment similar to 6to4 :/
244 2013-02-18 06:47:37 <zooko> http://blog.freedomsponsors.org/freedomsponsors-is-now-accepting-bitcoins/
245 2013-02-18 06:47:54 <cjd> interesting thought, I'd like cjdns to just work like normal internet but without the nats if at all possible
246 2013-02-18 06:48:15 <cjd> although I suppose a protocol could be designed around making use of lag and packet loss =]
247 2013-02-18 06:48:29 <SomeoneWeird> cjd, "(changing this isn non-trivial)"
248 2013-02-18 06:49:10 <cjd> fixed, thanks
249 2013-02-18 06:49:57 MrTiggr has quit (Ping timeout: 252 seconds)
250 2013-02-18 06:50:01 <cjd> although people relying on lag and packet loss features are likely to be broken in future releases :)
251 2013-02-18 06:50:51 RazielZ has joined
252 2013-02-18 06:50:53 dedis has joined
253 2013-02-18 06:52:46 <gmaxwell> cjd: well, for exampleâ bitcoin relaly wants a broadcast network. Multicast is broken on the public internet but... And cjdns has some topology information most hosts don't have access to... e.g. if your direct peers have a block you're best off getting it from them instead of fetching it from far away.
254 2013-02-18 06:54:11 <cjd> Interesting thought
255 2013-02-18 06:54:48 <cjd> ofc cjdns works hard to make everything "just work and don't ask questions" so we would need a SO_NETLINK type information gathering socket
256 2013-02-18 06:55:33 <cjd> in other news my main ipv6 access is tunneled over cjdns
257 2013-02-18 06:55:34 <SomeoneWeird> gmaxwell, that'd be cool
258 2013-02-18 06:55:40 <SomeoneWeird> speed up blockchain download a bit
259 2013-02-18 06:56:10 Jouke has quit (Quit: leaving)
260 2013-02-18 06:56:12 <cjd> my main ipv4 was tunneled over cjdns until my VPN endpoint went offline and I never inserted the default route again
261 2013-02-18 06:57:34 <gmaxwell> what VPN encap are you running over cjdns?
262 2013-02-18 06:58:17 <cjd> ipv6 is tunneled directly under the CryptoAuth headers which is under the switch header
263 2013-02-18 06:58:43 <cjd> if a node knows to expect a certain type of packet, it doesn't matter to the switches whct they forward
264 2013-02-18 06:58:49 <gmaxwell> ah, and then you're natting on the far side?
265 2013-02-18 06:58:52 jouke has joined
266 2013-02-18 06:58:58 <gmaxwell> or routing, I guess.. v6.. nevermind! :)
267 2013-02-18 06:59:02 <cjd> no, I just know someone with lots of addrs :)
268 2013-02-18 06:59:15 <cjd> he gave me 2 ipv4s
269 2013-02-18 06:59:41 <SomeoneWeird> they're not hard to get lol
270 2013-02-18 06:59:47 <phantomcircuit> cjd, i dont think the huge ip space gobble is a big issue
271 2013-02-18 07:00:12 <phantomcircuit> someone using fc will just end up with all the cjdns nodes timing out on him
272 2013-02-18 07:00:13 <phantomcircuit> that's it
273 2013-02-18 07:00:22 <cjd> phantomcircuit: I agree but it is big if like 2 people in the world want to run cjdns/bitcoin nodes
274 2013-02-18 07:00:45 <cjd> as per my comment in github
275 2013-02-18 07:02:23 <Luke-Jr> cjd: then 2 fc IPs timeout. big deal
276 2013-02-18 07:02:34 <gmaxwell> phantomcircuit: yea sure, and then when xyzns shows up next and also wants a v6 /8? The decision falls down if its ever repeated.. which is kinda .. yuck.
277 2013-02-18 07:02:39 <Luke-Jr> but I do agree with gmaxwell that if you're going to implement your own networking abstraction, you should just fix multicast in it
278 2013-02-18 07:03:47 eoss has joined
279 2013-02-18 07:03:49 <cjd> gmaxwell: good point, I think it's still valid to consider it but there should be a minimum popularity bar of entry
280 2013-02-18 07:03:57 MobiusL has quit (Quit: Ex-Chat)
281 2013-02-18 07:04:06 <cjd> and if cjdns has not reached that point then we wait
282 2013-02-18 07:04:31 <phantomcircuit> gmaxwell, addr2 containing network flags?
283 2013-02-18 07:04:36 <gmaxwell> How has cjdns been going?
284 2013-02-18 07:04:36 <cjd> certainly people are not banging down the door asking for this patch to be merged so playing it safe is valid from your perspective
285 2013-02-18 07:04:40 <phantomcircuit> that's certainly a more permanent solution
286 2013-02-18 07:05:17 <gmaxwell> phantomcircuit: we want an addr2 for unrelated reasons in any caseâ we really need a way to allow rumored addr entries to only be updated by their authors.
287 2013-02-18 07:05:17 MobiusL has joined
288 2013-02-18 07:05:32 <phantomcircuit> sorry what?
289 2013-02-18 07:06:20 <gmaxwell> there are some lame dos attacks that can happen because a malicious peer can feed you modified addr updates.
290 2013-02-18 07:06:31 <cjd> I've been talking with a physics grad student about changes to the protocol. We have a new design which allows for DHT searches to be forwarded from node to node and we "think" that it will provide pretty adaquate routes in the first RTT, after that we're going to do everything at the switch level.
291 2013-02-18 07:06:59 <cjd> which means stacked switch labels so we don't have a 64 bit horizon
292 2013-02-18 07:07:01 <Luke-Jr> cjd: multicast is a killer feature you could use to improve adoption too ;)
293 2013-02-18 07:07:09 <cjd> ;)
294 2013-02-18 07:07:37 <BTCTrader> funny
295 2013-02-18 07:08:23 <cjd> https://ezcrypt.it/SY5n#V7C5LWs7p1vUbFfd86tGhZ5S <-- this is what we're thinking about currently
296 2013-02-18 07:08:33 <cjd> it's got me pretty excited because it "looks" like it will scale
297 2013-02-18 07:09:03 <phantomcircuit> gmaxwell, i've actually tested that extensively
298 2013-02-18 07:09:33 <phantomcircuit> caddrman works exceptionally well
299 2013-02-18 07:10:43 <gmaxwell> I'd rather not explain to you the weaknesses. :P also, some of the strength comes at a loss of flexiblity. (e.g. that we only process some of the updates one way)
300 2013-02-18 07:11:04 <cjd> as far as the network is concerned, by all measurements I can take, we're very slowly but steadily gaining popularity which is exactly what I want, rather than here-today-gone-tomorrow people
301 2013-02-18 07:12:03 <cjd> someone did a check of "recent" ipv6 addrs in the network and got 300
302 2013-02-18 07:12:33 <phantomcircuit> gmaxwell, i can understand that
303 2013-02-18 07:12:35 <BTCTrader> https://www.cjdnscloud.com/ added 3 this week
304 2013-02-18 07:12:56 <cjd> And our first commercial cjdns enterprise! :D
305 2013-02-18 07:12:59 <phantomcircuit> actually a few days ago i accidentally launched about 1/10th of an enormous sybil attack
306 2013-02-18 07:13:05 <phantomcircuit> was interested that nobody noticed
307 2013-02-18 07:13:31 <phantomcircuit> (broken conditional statement)
308 2013-02-18 07:14:35 <gmaxwell> cjd: that fastroute stuff looks exponential on path length? I guess it effectively precomputes so it does less work as a nodes' routing table grows...
309 2013-02-18 07:15:22 <cjd> We're talking about switching to a bucket system so the amount of work done by each node is less
310 2013-02-18 07:15:32 <cjd> I liked the flat DHT but it's inefficient
311 2013-02-18 07:15:51 <phantomcircuit> BTCTrader, you run that?
312 2013-02-18 07:16:01 <BTCTrader> yes
313 2013-02-18 07:16:07 meLon has quit (Ping timeout: 240 seconds)
314 2013-02-18 07:16:44 meLon has joined
315 2013-02-18 07:16:51 <zooko> I'm really happy to see bitcoin and cjdns people collaborating like this.
316 2013-02-18 07:16:56 JDuke128 has quit (Quit: ["Textual IRC Client: www.textualapp.com"])
317 2013-02-18 07:17:00 <zooko> Not that I'm reading carefully enough to understand what you're saying...
318 2013-02-18 07:17:04 <gmaxwell> Does anyone offer VPSes that have only tor connectivity?
319 2013-02-18 07:17:08 <SomeoneWeird> oh
320 2013-02-18 07:17:09 <SomeoneWeird> BTCTrader,
321 2013-02-18 07:17:10 <SomeoneWeird> lol
322 2013-02-18 07:17:11 <SomeoneWeird> it's s1w
323 2013-02-18 07:17:22 <SomeoneWeird> HAI
324 2013-02-18 07:17:23 <SomeoneWeird> lol
325 2013-02-18 07:17:32 <BTCTrader> gmaxwell sortof yes. that made me think of this for a service...
326 2013-02-18 07:17:33 <phantomcircuit> gmaxwell, im not aware of any
327 2013-02-18 07:17:42 <cjd> gmaxwell: not sure about exponential since each node just forwards it on. It is worth noting that each hop is potentially the worst possible optimal route since nearby nodes in keyspace could be halfway around the world in physical space
328 2013-02-18 07:17:49 <phantomcircuit> there are some which offer NAT only service
329 2013-02-18 07:17:58 <BTCTrader> in combination of the pain asking for a peer on irc can be
330 2013-02-18 07:18:05 <gmaxwell> I've thought it might be interesting to run one beforeâ removes a bunch of gnarly operational annoyances. (e.g. abuse complaints are mostly someone elses problem)
331 2013-02-18 07:18:10 <BTCTrader> torcloud
332 2013-02-18 07:18:19 <gmaxwell> (but I'm not interested in running oneâ too many other projects)
333 2013-02-18 07:18:29 owowo has quit (Quit: sayonara)
334 2013-02-18 07:18:32 <BTCTrader> ditto
335 2013-02-18 07:19:02 <BTCTrader> i'm not thrilled to handle abuse complaints B-)
336 2013-02-18 07:19:10 <Luke-Jr> gmaxwell: I have VPS plans that don't include IPv4, and I think at least one customer was using tor to get around that :P
337 2013-02-18 07:19:19 <cjd> nice thing with cjdns vpsen is you can allocate ipv4 and ipv6 addrs to them via the tunneling code
338 2013-02-18 07:22:49 <gmaxwell> Luke-Jr: don't include IPv4 for the abuse handling reason?
339 2013-02-18 07:23:06 <Luke-Jr> gmaxwell: no, to encourage IPv6 mainly :p
340 2013-02-18 07:23:11 v1rtex has quit ()
341 2013-02-18 07:23:11 <Luke-Jr> and I only have so many IPv4 addresses
342 2013-02-18 07:24:08 random_cat has joined
343 2013-02-18 07:26:14 <phantomcircuit> i haven't actually had that many issues with abuse
344 2013-02-18 07:27:58 <gmaxwell> I expect that abuse may be price related too.. e.g. a really inexpensive low quality of service service might be more abuse prone.
345 2013-02-18 07:30:19 <phantomcircuit> im not sure
346 2013-02-18 07:30:22 B0g4r7 has quit (Ping timeout: 276 seconds)
347 2013-02-18 07:30:26 <phantomcircuit> i was offering a ridiculously cheap
348 2013-02-18 07:30:28 <phantomcircuit> terrible service
349 2013-02-18 07:30:52 <phantomcircuit> and all i was getting were complaints from middle eastern universities complaining about port scanning
350 2013-02-18 07:30:57 <phantomcircuit> (which is totally bizarre)
351 2013-02-18 07:33:06 <SomeoneWeird> >.>
352 2013-02-18 07:33:07 <SomeoneWeird> <.<
353 2013-02-18 07:33:29 WolfAlex has joined
354 2013-02-18 07:33:41 <Luke-Jr> lol
355 2013-02-18 07:33:48 <Luke-Jr> as if port scanning is a problem
356 2013-02-18 07:34:00 <Luke-Jr> I portscan my own servers to try to figure out what port I put ssh on
357 2013-02-18 07:34:49 <SomeoneWeird> haha
358 2013-02-18 07:36:19 WolfAlex_ has quit (Ping timeout: 245 seconds)
359 2013-02-18 07:40:08 B0g4r7 has joined
360 2013-02-18 07:52:10 mappum has quit (Ping timeout: 252 seconds)
361 2013-02-18 08:12:39 JDuke128 has joined
362 2013-02-18 08:23:45 ThomasV has joined
363 2013-02-18 08:24:50 reizuki__ has quit (Read error: Operation timed out)
364 2013-02-18 08:26:43 CodesInChaos has joined
365 2013-02-18 08:28:48 jdnavarro has joined
366 2013-02-18 08:31:02 dhill has quit (Ping timeout: 252 seconds)
367 2013-02-18 08:32:09 rlifchitz has quit (Ping timeout: 246 seconds)
368 2013-02-18 08:37:02 b4tt3r135 has quit (Quit: Nettalk6 - www.ntalk.de)
369 2013-02-18 08:41:14 dhill has joined
370 2013-02-18 08:44:32 rlifchitz has joined
371 2013-02-18 08:51:20 LainZ has quit (Read error: Connection reset by peer)
372 2013-02-18 09:05:12 <doublec> cjd: I'll rebase the cjdns patch so it's at least usable on recent bitcoin code
373 2013-02-18 09:05:43 <cjd> I think the consensus was that it will not be pulled because there is not enough interest
374 2013-02-18 09:06:25 <doublec> yeah but at least it'll be available for those that want to run nodes
375 2013-02-18 09:07:03 <cjd> that's up to you, thanks for your effort
376 2013-02-18 09:07:20 <Luke-Jr> no reason to keep it out of next-test either
377 2013-02-18 09:07:47 <doublec> at some point when all 300 cjdns nodes are running a bitcoind it might be compelling enough to reconsider ;)
378 2013-02-18 09:07:54 <Luke-Jr> lol
379 2013-02-18 09:08:36 <cjd> given some of them are rasberryPi and even smaller, I don't think that'll happen too soon ;)
380 2013-02-18 09:08:39 <doublec> I used to have cjdns entrypoint for my pool but it's populatirty was limited
381 2013-02-18 09:08:40 moarrr has joined
382 2013-02-18 09:08:52 <cjd> yeah
383 2013-02-18 09:09:45 <gmaxwell> cjd: pft. you should make the cjd code detect a rpi and refuse to run. That device is so insanely underpowered that allowing people to run on it creates perverse demands.
384 2013-02-18 09:10:00 <gmaxwell> That said, assuming you have enough storageâ bitcoin apparently keeps up on it.
385 2013-02-18 09:10:11 <doublec> does cjdns run on android? Might be fun to run it on a firefox phone.
386 2013-02-18 09:10:31 toffoo has quit ()
387 2013-02-18 09:11:03 <cjd> gmaxwell: It does about 7Mb/s of raw crypto speed and I've connected to sites hosted in the darknet on rPi and they're surprisingly normal.
388 2013-02-18 09:12:11 kiceek has quit (Quit: Leaving)
389 2013-02-18 09:16:51 eoss has quit (Read error: Connection reset by peer)
390 2013-02-18 09:29:05 ByteUnit has joined
391 2013-02-18 09:30:03 Ken` has joined
392 2013-02-18 09:34:07 grau has quit (Remote host closed the connection)
393 2013-02-18 09:34:39 grau has joined
394 2013-02-18 09:36:38 cj_ has joined
395 2013-02-18 09:37:17 cj_ has quit (Client Quit)
396 2013-02-18 09:45:47 Insu has joined
397 2013-02-18 09:50:29 rdymac has joined
398 2013-02-18 09:50:29 Garr255 has joined
399 2013-02-18 09:51:51 brwyatt is now known as brwyatt|Away
400 2013-02-18 09:52:02 ByteUnit has quit (Remote host closed the connection)
401 2013-02-18 09:56:50 one_zero has quit ()
402 2013-02-18 09:58:12 Goonie has joined
403 2013-02-18 10:01:26 Hashdog has joined
404 2013-02-18 10:06:08 BTCOxygen has joined
405 2013-02-18 10:06:14 t7 has joined
406 2013-02-18 10:06:16 BTCOxygen has quit (Ping timeout: 256 seconds)
407 2013-02-18 10:08:10 Luke-Jr has quit (Excess Flood)
408 2013-02-18 10:08:16 BTCOxygen is now known as 1!~BTCOxygen@unaffiliated/mroxy/bot/btcoxygen|BTCOxygen
409 2013-02-18 10:08:31 Luke-Jr has joined
410 2013-02-18 10:12:24 JDuke128 has quit (Quit: ["Textual IRC Client: www.textualapp.com"])
411 2013-02-18 10:15:13 rdymac has quit (Remote host closed the connection)
412 2013-02-18 10:21:58 B0g4r7 has quit (Ping timeout: 276 seconds)
413 2013-02-18 10:23:54 CodesInChaos has quit (Ping timeout: 252 seconds)
414 2013-02-18 10:24:59 t7` has joined
415 2013-02-18 10:25:32 Garr255 has quit (Ping timeout: 252 seconds)
416 2013-02-18 10:27:04 B0g4r7 has joined
417 2013-02-18 10:27:05 MrTiggr has joined
418 2013-02-18 10:27:33 t7 has quit (Ping timeout: 256 seconds)
419 2013-02-18 10:27:34 AtashiCon has quit (Quit: AtashiCon)
420 2013-02-18 10:28:02 AtashiCon has joined
421 2013-02-18 10:42:37 MC1984 has quit (Read error: Connection reset by peer)
422 2013-02-18 10:43:05 MC1984 has joined
423 2013-02-18 11:01:33 petertodd has quit (Remote host closed the connection)
424 2013-02-18 11:03:03 Hashdog has quit (Remote host closed the connection)
425 2013-02-18 11:11:04 word has quit (Ping timeout: 252 seconds)
426 2013-02-18 11:11:22 rdponticelli has quit (Ping timeout: 276 seconds)
427 2013-02-18 11:11:40 rdponticelli_ has joined
428 2013-02-18 11:19:54 valparaiso has quit ()
429 2013-02-18 11:19:55 RBecker is now known as rbecker
430 2013-02-18 11:20:14 valparaiso has joined
431 2013-02-18 11:20:37 valparaiso is now known as Guest27622
432 2013-02-18 11:22:34 Guest27622 has quit (Client Quit)
433 2013-02-18 11:29:16 ProfMac has quit (Ping timeout: 245 seconds)
434 2013-02-18 11:34:45 drizztbsd has joined
435 2013-02-18 11:36:37 dparrish has quit (Remote host closed the connection)
436 2013-02-18 11:47:30 JZavala has joined
437 2013-02-18 11:49:01 valparaiso has joined
438 2013-02-18 11:51:53 ciphermonk has joined
439 2013-02-18 11:55:23 agricocb has quit (Remote host closed the connection)
440 2013-02-18 11:57:14 agricocb has joined
441 2013-02-18 12:01:15 <Goonie> will there be a rc2 before 0.8 final?
442 2013-02-18 12:07:59 drizztbsd has quit (Quit: Konversation terminated!)
443 2013-02-18 12:11:35 stick` has left ()
444 2013-02-18 12:12:00 <JWU42> just wanted to advise 0.8 running well and mined first block with it last night
445 2013-02-18 12:12:22 <JWU42> been running it for over 10 days now and no issues
446 2013-02-18 12:12:34 <JWU42> though mem usage is tad higher than 0.7.2
447 2013-02-18 12:14:28 t7` has quit (Quit: Leaving)
448 2013-02-18 12:18:02 drizztbsd has joined
449 2013-02-18 12:33:44 <jgarzik> Goonie: sounds like "probably no rc2"
450 2013-02-18 12:37:59 JZavala has quit (Ping timeout: 264 seconds)
451 2013-02-18 12:38:23 OneFixt has quit (Read error: Connection reset by peer)
452 2013-02-18 12:38:40 OneFixt has joined
453 2013-02-18 12:54:16 t7 has joined
454 2013-02-18 12:59:18 drizztbsd has quit (Quit: Konversation terminated!)
455 2013-02-18 13:07:07 drizztbsd has joined
456 2013-02-18 13:08:57 CodeShark has quit (Remote host closed the connection)
457 2013-02-18 13:10:32 MobGod has quit (Quit: Leaving...)
458 2013-02-18 13:16:32 xorgate has quit (Ping timeout: 276 seconds)
459 2013-02-18 13:21:51 reizuki__ has joined
460 2013-02-18 13:24:51 quijibo has joined
461 2013-02-18 13:32:09 cjd has left ()
462 2013-02-18 13:36:37 agricocb has quit (Quit: Leaving.)
463 2013-02-18 13:41:41 Zarutian has joined
464 2013-02-18 13:43:30 t7 has quit (Quit: Leaving)
465 2013-02-18 14:05:27 daybyter has joined
466 2013-02-18 14:16:17 fdsagew has joined
467 2013-02-18 14:16:21 <fdsagew> Official ฿itcoin shop http://www.silkroadtor.com 1 ฿itcoin=$17.77
468 2013-02-18 14:16:22 <fdsagew> 2 ฿itcoin=$36.66
469 2013-02-18 14:16:22 <fdsagew> 3 ฿itcoin=$53.99 http://www.silkroadtor.com
470 2013-02-18 14:16:22 <fdsagew> 4 ฿itcoin=$69.99
471 2013-02-18 14:16:22 <fdsagew> 5 ฿itcoin=$85.55
472 2013-02-18 14:16:22 <fdsagew> 9 ฿itcoin + Free extra 1 ฿itcoin=$130.99
473 2013-02-18 14:16:22 <fdsagew> 15 ฿itcoin + Free extra 2 ฿itcoin=$186.66 http://www.silkroadtor.com
474 2013-02-18 14:16:23 <fdsagew> 20 ฿itcoin + Free extra 4 ฿itcoin=$228.88
475 2013-02-18 14:16:23 <fdsagew> 30 ฿itcoin + Free extra 6 ฿itcoin=$323.33
476 2013-02-18 14:16:24 <fdsagew> http://www.silkroadtor.com
477 2013-02-18 14:16:24 <fdsagew> http://www.silkroadtor.com
478 2013-02-18 14:16:25 <fdsagew> Official ฿itcoin shop http://www.silkroadtor.com 1 ฿itcoin=$17.77
479 2013-02-18 14:16:25 <fdsagew> 2 ฿itcoin=$36.66
480 2013-02-18 14:16:26 <fdsagew> 3 ฿itcoin=$53.99 http://www.silkroadtor.com
481 2013-02-18 14:16:36 <fdsagew> 3 ฿itcoin=$53.99 http://www.silkroadtor.com
482 2013-02-18 14:16:37 <fdsagew> 4 ฿itcoin=$69.99
483 2013-02-18 14:16:38 rdponticelli_ has quit (Ping timeout: 276 seconds)
484 2013-02-18 14:16:38 <fdsagew> 5 ฿itcoin=$85.55
485 2013-02-18 14:16:39 <fdsagew> 9 ฿itcoin + Free extra 1 ฿itcoin=$130.99
486 2013-02-18 14:16:40 <fdsagew> 15 ฿itcoin + Free extra 2 ฿itcoin=$186.66 http://www.silkroadtor.com
487 2013-02-18 14:16:41 <fdsagew> 20 ฿itcoin + Free extra 4 ฿itcoin=$228.88
488 2013-02-18 14:16:42 <fdsagew> 30 ฿itcoin + Free extra 6 ฿itcoin=$323.33
489 2013-02-18 14:16:43 <fdsagew> http://www.silkroadtor.com
490 2013-02-18 14:16:44 <fdsagew> http://www.silkroadtor.com
491 2013-02-18 14:16:46 <fdsagew> Official ฿itcoin shop http://www.silkroadtor.com 1 ฿itcoin=$17.77
492 2013-02-18 14:16:47 <fdsagew> 2 ฿itcoin=$36.66
493 2013-02-18 14:16:48 <fdsagew> 3 ฿itcoin=$53.99 http://www.silkroadtor.com
494 2013-02-18 14:16:49 <fdsagew> 4 ฿itcoin=$69.99
495 2013-02-18 14:16:50 <fdsagew> 5 ฿itcoin=$85.55
496 2013-02-18 14:16:51 <fdsagew> 9 ฿itcoin + Free extra 1 ฿itcoin=$130.99
497 2013-02-18 14:16:52 <fdsagew> 15 ฿itcoin + Free extra 2 ฿itcoin=$186.66 http://www.silkroadtor.com
498 2013-02-18 14:16:53 <fdsagew> 20 ฿itcoin + Free extra 4 ฿itcoin=$228.88
499 2013-02-18 14:16:54 <fdsagew> 30 ฿itcoin + Free extra 6 ฿itcoin=$323.33
500 2013-02-18 14:16:55 <fdsagew> http://www.silkroadtor.com
501 2013-02-18 14:16:56 <fdsagew> http://www.silkroadtor.com
502 2013-02-18 14:16:57 <fdsagew> Official ฿itcoin shop http://www.silkroadtor.com 1 ฿itcoin=$17.77
503 2013-02-18 14:16:58 <fdsagew> 2 ฿itcoin=$36.66
504 2013-02-18 14:16:59 <fdsagew> 3 ฿itcoin=$53.99 http://www.silkroadtor.com
505 2013-02-18 14:17:00 <fdsagew> 4 ฿itcoin=$69.99
506 2013-02-18 14:17:01 <fdsagew> 5 ฿itcoin=$85.55
507 2013-02-18 14:17:27 <Prattler> nooo, he was saying something valuable to everyone :D
508 2013-02-18 14:19:16 <SomeoneWeird> damni
509 2013-02-18 14:20:21 moarrr has left ()
510 2013-02-18 14:20:34 moarrr has joined
511 2013-02-18 14:25:44 ciphermonk has quit (Ping timeout: 276 seconds)
512 2013-02-18 14:27:23 fdsagew has joined
513 2013-02-18 14:29:15 ciphermonk has joined
514 2013-02-18 14:29:23 petertodd has joined
515 2013-02-18 14:30:08 <fdsagew> Official ฿itcoin shop http://www.silkroadtor.com 1 ฿itcoin=$17.77
516 2013-02-18 14:30:08 <fdsagew> 2 ฿itcoin=$36.66
517 2013-02-18 14:30:08 <fdsagew> 3 ฿itcoin=$53.99 http://www.silkroadtor.com
518 2013-02-18 14:30:14 <fdsagew> Official ฿itcoin shop http://www.silkroadtor.com 1 ฿itcoin=$17.77
519 2013-02-18 14:30:15 <fdsagew> 2 ฿itcoin=$36.66
520 2013-02-18 14:30:15 <fdsagew> 3 ฿itcoin=$53.99 http://www.silkroadtor.com
521 2013-02-18 14:30:15 <fdsagew> Official ฿itcoin shop http://www.silkroadtor.com 1 ฿itcoin=$17.77
522 2013-02-18 14:30:15 <fdsagew> 2 ฿itcoin=$36.66
523 2013-02-18 14:30:15 <fdsagew> 3 ฿itcoin=$53.99 http://www.silkroadtor.com
524 2013-02-18 14:30:15 <fdsagew> 4 ฿itcoin=$69.99
525 2013-02-18 14:30:16 <fdsagew> 5 ฿itcoin=$85.55
526 2013-02-18 14:30:16 <fdsagew> 9 ฿itcoin + Free extra 1 ฿itcoin=$130.99
527 2013-02-18 14:30:17 <fdsagew> 15 ฿itcoin + Free extra 2 ฿itcoin=$186.66 http://www.silkroadtor.com
528 2013-02-18 14:30:17 <fdsagew> 20 ฿itcoin + Free extra 4 ฿itcoin=$228.88
529 2013-02-18 14:30:19 <fdsagew> 30 ฿itcoin + Free extra 6 ฿itcoin=$323.33
530 2013-02-18 14:30:19 <fdsagew> http://www.silkroadtor.com
531 2013-02-18 14:30:19 <fdsagew> http://www.silkroadtor.com
532 2013-02-18 14:30:30 <fdsagew> Official ฿itcoin shop http://www.silkroadtor.com 1 ฿itcoin=$17.77
533 2013-02-18 14:30:31 <fdsagew> 2 ฿itcoin=$36.66
534 2013-02-18 14:30:32 <fdsagew> 3 ฿itcoin=$53.99 http://www.silkroadtor.com
535 2013-02-18 14:30:33 <fdsagew> 4 ฿itcoin=$69.99
536 2013-02-18 14:30:34 <fdsagew> 5 ฿itcoin=$85.55
537 2013-02-18 14:30:35 <fdsagew> 9 ฿itcoin + Free extra 1 ฿itcoin=$130.99
538 2013-02-18 14:30:36 <fdsagew> 15 ฿itcoin + Free extra 2 ฿itcoin=$186.66 http://www.silkroadtor.com
539 2013-02-18 14:30:37 <fdsagew> 20 ฿itcoin + Free extra 4 ฿itcoin=$228.88
540 2013-02-18 14:30:38 <fdsagew> 30 ฿itcoin + Free extra 6 ฿itcoin=$323.33
541 2013-02-18 14:30:39 <fdsagew> http://www.silkroadtor.com
542 2013-02-18 14:30:40 <fdsagew> http://www.silkroadtor.com
543 2013-02-18 14:30:41 <fdsagew> Official ฿itcoin shop http://www.silkroadtor.com 1 ฿itcoin=$17.77
544 2013-02-18 14:30:42 <fdsagew> 2 ฿itcoin=$36.66
545 2013-02-18 14:30:43 <fdsagew> 3 ฿itcoin=$53.99 http://www.silkroadtor.com
546 2013-02-18 14:30:44 <fdsagew> 4 ฿itcoin=$69.99
547 2013-02-18 14:30:45 <fdsagew> 5 ฿itcoin=$85.55
548 2013-02-18 14:30:46 <fdsagew> 9 ฿itcoin + Free extra 1 ฿itcoin=$130.99
549 2013-02-18 14:30:47 <fdsagew> 15 ฿itcoin + Free extra 2 ฿itcoin=$186.66 http://www.silkroadtor.com
550 2013-02-18 14:30:47 sipa has quit (Changing host)
551 2013-02-18 14:30:47 sipa has joined
552 2013-02-18 14:30:48 <fdsagew> 20 ฿itcoin + Free extra 4 ฿itcoin=$228.88
553 2013-02-18 14:30:49 <fdsagew> 30 ฿itcoin + Free extra 6 ฿itcoin=$323.33
554 2013-02-18 14:30:50 <fdsagew> http://www.silkroadtor.com
555 2013-02-18 14:30:51 <fdsagew> http://www.silkroadtor.com
556 2013-02-18 14:30:52 <fdsagew> Official ฿itcoin shop http://www.silkroadtor.com 1 ฿itcoin=$17.77
557 2013-02-18 14:30:53 <fdsagew> 2 ฿itcoin=$36.66
558 2013-02-18 14:30:54 <fdsagew> 3 ฿itcoin=$53.99 http://www.silkroadtor.com
559 2013-02-18 14:30:55 <fdsagew> 4 ฿itcoin=$69.99
560 2013-02-18 14:30:56 <fdsagew> 5 ฿itcoin=$85.55
561 2013-02-18 14:30:57 <fdsagew> 9 ฿itcoin + Free extra 1 ฿itcoin=$130.99
562 2013-02-18 14:30:58 <fdsagew> 15 ฿itcoin + Free extra 2 ฿itcoin=$186.66 http://www.silkroadtor.com
563 2013-02-18 14:30:59 <fdsagew> 20 ฿itcoin + Free extra 4 ฿itcoin=$228.88
564 2013-02-18 14:31:04 <ThomasV> jgarzik, SomeoneWeird, gmaxwell : spam attack
565 2013-02-18 14:31:17 <SomeoneWeird> ffs
566 2013-02-18 14:31:20 <ThomasV> oh, ok :)
567 2013-02-18 14:32:41 <jgarzik> yah, ongoing in #bitcoin too :(
568 2013-02-18 14:33:27 xorgate has joined
569 2013-02-18 14:42:47 TD has joined
570 2013-02-18 14:42:52 <kinlo> perhaps a few more ops might help
571 2013-02-18 14:43:12 <TD> good day
572 2013-02-18 14:43:31 <MC1984> im suprised #bitcoin has lasted this long without 24/7 spam tbh
573 2013-02-18 14:44:09 <MC1984> i wonder if the mainstream-ness of a technology is proportional to the amount of spam shit on it
574 2013-02-18 14:44:12 <MC1984> like email
575 2013-02-18 14:45:39 Hashdog has joined
576 2013-02-18 14:47:16 fdsagew has joined
577 2013-02-18 14:49:10 agricocb has joined
578 2013-02-18 14:49:44 <jgarzik> yeah, the Internet was never the same after those damned AOL users found Usenet
579 2013-02-18 14:50:14 daybyter has quit (Quit: Konversation terminated!)
580 2013-02-18 14:50:15 <upb> lol
581 2013-02-18 14:52:31 <SomeoneWeird> heh
582 2013-02-18 14:52:36 Jackneill has joined
583 2013-02-18 14:52:37 Jackneill has quit (Changing host)
584 2013-02-18 14:52:37 Jackneill has joined
585 2013-02-18 14:53:14 d34th has joined
586 2013-02-18 14:53:57 fdsagew has quit (Ping timeout: 252 seconds)
587 2013-02-18 14:55:57 nus- has joined
588 2013-02-18 14:57:42 <epscy> aol keywords were such a good idea
589 2013-02-18 14:57:46 <epscy> j/k
590 2013-02-18 14:59:45 rdponticelli has joined
591 2013-02-18 15:00:32 nus has quit (Ping timeout: 276 seconds)
592 2013-02-18 15:04:44 rdponticelli has quit (Ping timeout: 276 seconds)
593 2013-02-18 15:05:35 t7 has joined
594 2013-02-18 15:06:29 fdsagew has joined
595 2013-02-18 15:06:56 fdsagew has left ()
596 2013-02-18 15:07:25 d34th has quit (Quit: Page closed)
597 2013-02-18 15:09:32 gruvfunk has joined
598 2013-02-18 15:14:38 <MC1984> i got the olduse.net thing in a nntp reader right now
599 2013-02-18 15:14:40 <MC1984> pretty cool
600 2013-02-18 15:16:47 <MC1984> its curently 18 feb 1983
601 2013-02-18 15:17:01 denisx_ has joined
602 2013-02-18 15:18:40 denisx has quit (Ping timeout: 264 seconds)
603 2013-02-18 15:18:41 denisx_ is now known as denisx
604 2013-02-18 15:19:12 xorgate has quit (Ping timeout: 252 seconds)
605 2013-02-18 15:20:16 OneFixt has quit (Remote host closed the connection)
606 2013-02-18 15:20:20 ciphermonk has quit (Ping timeout: 276 seconds)
607 2013-02-18 15:20:33 <BlueMatt> gmaxwell: baseline coverage? as in a link to the coverage result of not being run (ie 0%?)
608 2013-02-18 15:20:39 <BlueMatt> what am I missing?
609 2013-02-18 15:20:51 <TD> good morning matt
610 2013-02-18 15:21:13 <TD> BlueMatt: i was wondering if you're after any more tasks to do on bitcoinj :)
611 2013-02-18 15:21:59 <BlueMatt> TD: yea, Id like to work more on the download algorithms to do upgrading
612 2013-02-18 15:22:12 <BlueMatt> and probably expose the fact that you are a full node to the p2p network
613 2013-02-18 15:22:36 <BlueMatt> though, sadly, other projects have come up too
614 2013-02-18 15:22:59 <BlueMatt> TD: is there anything in particular you want?
615 2013-02-18 15:23:03 <TD> ok. if you tackle download algorithms, maybe you could also tackle making SPV mode run on partial chains? the time taken to sync headers (!) is apparently now the biggest pain point for the mobile app
616 2013-02-18 15:23:04 OneFixt has joined
617 2013-02-18 15:23:15 <TD> not to mention that disk usage is not O(1)
618 2013-02-18 15:23:31 <BlueMatt> ahh, yes, I could look into that eventually too
619 2013-02-18 15:23:35 nus- is now known as nus
620 2013-02-18 15:23:58 <TD> i'm not sure spv to full node upgrades is really going to be that useful in the long run, as you know â¦. i think the era of hobbyists running nodes without realizing it is coming to an end even now
621 2013-02-18 15:24:18 <TD> i think we'll end up like tor where people have to explicitly opt-in to being a full node and know what they're doing
622 2013-02-18 15:24:37 <BlueMatt> yes, but we should still have an upgrade path for those who want to do that
623 2013-02-18 15:24:58 <BlueMatt> tor makes it easy "just check this button in vidalia/mark these config options" and you are running an exit node/etc
624 2013-02-18 15:25:26 <TD> yeah, but if the upgrade path is just "go to bitcoin.org and download/run the app" then is it really that much harder? given that you're committing to running a node and keeping it up to date, etc
625 2013-02-18 15:25:40 <BlueMatt> in any case, I agree there will be little use of full nodes on cell phones, but if bitcoinj is going to be used on multibit/other desktop apps...
626 2013-02-18 15:26:01 <TD> i don't think full nodes will be running even on laptops/consumer desktops, in the medium term.
627 2013-02-18 15:26:09 <BlueMatt> well full node network diversity is also important
628 2013-02-18 15:26:15 <TD> they'll all end up on servers eventually. yes sure, you CAN run tor relays on your laptops. but how many people really do so?
629 2013-02-18 15:26:25 <TD> the instability from people turning them on/off is probably a net negative for the network
630 2013-02-18 15:27:04 OneFixt has quit (Remote host closed the connection)
631 2013-02-18 15:27:08 <BlueMatt> meh, I dont think rollover is a big deal (not ideal, obv, but not that hard to deal with)
632 2013-02-18 15:27:16 rdymac has joined
633 2013-02-18 15:27:38 <BlueMatt> <TD> i don't think full nodes will be running even on laptops/consumer desktops, in the medium term. <-- Im not sure about that, its really not that expensive with ultraprune, etc
634 2013-02-18 15:27:52 <BlueMatt> the bitcoinj side could be better optimized (mostly sigchecking) but its not that unreasonable
635 2013-02-18 15:28:08 <TD> i think it's still pretty expensive. people are complaining about running full nodes even on VPS systems.
636 2013-02-18 15:28:39 <TD> node instability will be more of an issue soon because we'll have to make SPV clients start using addr broadcasts. so most of the IPs they connect to will be stale, if most nodes are on consumer machines
637 2013-02-18 15:28:45 <TD> which means it'll take longer to get connected to the p2p network
638 2013-02-18 15:28:48 <BlueMatt> meh, vps's are way less powerful than a reasonably powerful desktop/laptop
639 2013-02-18 15:29:16 <TD> they also do less. people laptops load giant web pages and play HD video and run games and skype sessions and other things that don't sit well with an intensive p2p app churning away in the background
640 2013-02-18 15:29:31 <BlueMatt> ahh, well yes thats an issue, but they can still readily use dnsseeds to get one or two connections before they beat on addresses until they find a connection
641 2013-02-18 15:29:58 <BlueMatt> I wouldnt call bitcoin an intensive p2p app after initial sync
642 2013-02-18 15:30:08 <TD> they want t start syncing the chain ASAP so having a connection but not using it because you're looking for others isn't ideal. they really need to just open lots of connections to IPs in parallel and hope for the best
643 2013-02-18 15:30:31 <TD> you're assuming a machine that runs all the time. bitcoin is intensive on my laptop because whenever i shut the lid or stop it for a few days it gets behind
644 2013-02-18 15:30:45 <TD> and we hope load will increase, right?
645 2013-02-18 15:31:20 <TD> i just can't see any future in which bitcoin is both popular and successful, and people run full nodes on their laptops or desktops. it'll be like Tor where people who care about the project run nodes on colo machines, and then end users just connect to those nodes
646 2013-02-18 15:31:41 <TD> if bitcoin stalls and never goes much beyond its current traffic levels, sure
647 2013-02-18 15:31:52 vigilyn2 has quit (Read error: Connection reset by peer)
648 2013-02-18 15:31:53 <BlueMatt> re: node rollover, yes, ok its not ideal and could be ugly, but ultimately sending out 50 SYNs isnt all that expensive, even on a mobile device, as long as its all at once...
649 2013-02-18 15:31:58 vigilyn3 has joined
650 2013-02-18 15:32:26 <BlueMatt> and, yes, we hope load will increase, but Im not sure I see it taking another sd-style leap in the next 6 months...I may very well have to eat my words, but still
651 2013-02-18 15:32:35 <BlueMatt> in either case, Id really like to see some full node diversity
652 2013-02-18 15:32:36 SomeoneWeird has quit (Quit: ZNC - http://znc.in)
653 2013-02-18 15:32:42 <TD> yeah that's my plan, just try 50-100 IPs simultaneously and hope at least 5 or 10 connect, then drop the rest
654 2013-02-18 15:32:47 <BlueMatt> having one implementation that is used everywhere is pretty ugly...
655 2013-02-18 15:33:12 <BlueMatt> but yes, I agree that it will likely not be run on laptops of everyone eventually
656 2013-02-18 15:33:27 <BlueMatt> but I still think its important that such an option is available to everyone
657 2013-02-18 15:33:47 <BlueMatt> especially those who have been running one app and dont want to download another one just to run a full node when their wallet is already in multibit/etc
658 2013-02-18 15:34:02 <TD> they can run a full node without moving their wallet.
659 2013-02-18 15:34:11 <BlueMatt> yes, but its not ideal
660 2013-02-18 15:34:22 <BlueMatt> Id usually just say "meh" if I have to download another app
661 2013-02-18 15:34:32 <BlueMatt> if I can just check a box, I may be more inclined to do so
662 2013-02-18 15:34:48 <TD> then you aren't committed enough to run a full node. you won't bother upgrading, you won't keep it running, you probably won't even be patient enough to make it through the initial sync
663 2013-02-18 15:35:13 <TD> i don't think "download a dedicated app" is a big thing to ask of users. the kind of users who wouldn't bother with it, are the kind who we don't really want running nodes in the long run anyway.
664 2013-02-18 15:35:57 m00p has joined
665 2013-02-18 15:36:44 SomeoneWeird has joined
666 2013-02-18 15:36:54 SomeoneWeird is now known as Guest7551
667 2013-02-18 15:36:56 <MC1984> if the block cap stays, it wont be long before node running is trivial
668 2013-02-18 15:37:06 <BlueMatt> meh thats probably true to at least some extent...but Im not sure its so bad to do it gtk-gnutella style - very clearly display the user's uptime stats to them, and recommend an option...maybe dont even let them check the box unless the uptime is high enough
669 2013-02-18 15:37:09 <MC1984> be doing it on my phone in 5 years
670 2013-02-18 15:37:38 <TD> i'm all for finding users with high uptime in multibit ⦠and asking them to open a page introducing them to what running a full node means
671 2013-02-18 15:37:59 <TD> MC1984: but if it is lifted, you won't. so don't bet on that.
672 2013-02-18 15:38:13 <MC1984> i dont think it will ever be lifted
673 2013-02-18 15:38:23 <MC1984> raised but not lifted
674 2013-02-18 15:38:42 Guest7551 has quit (Changing host)
675 2013-02-18 15:38:42 Guest7551 has joined
676 2013-02-18 15:38:53 <TD> we'll see.
677 2013-02-18 15:39:21 <BlueMatt> TD: Id rather get more people who have high uptime but dont care at all about bitcoin (its not hard to bug them when updates come out) than miss a lot of people by trying to get them to read up on running a full node and all the details thereof
678 2013-02-18 15:39:28 Guest7551 is now known as SomeoneWeird
679 2013-02-18 15:39:33 <MC1984> at some point the block cap will be in rough equilibrium with world economic activity, then its only a matter of time until you can run a full node on any mobile device
680 2013-02-18 15:39:46 <MC1984> without a block cap, there are no fees
681 2013-02-18 15:41:36 <TD> BlueMatt: the question is, given the complexity of upgrading stuff transparently in the background to full node status, is it really the best use of time or are there more important things? multibit doesn't even notify users of upgrades yet
682 2013-02-18 15:41:38 <TD> let alone do them automatically
683 2013-02-18 15:41:39 <helo> yay, this
684 2013-02-18 15:41:41 gavinandresen has joined
685 2013-02-18 15:41:47 <TD> MC1984: that is not a valid assumption
686 2013-02-18 15:42:07 <MC1984> ?
687 2013-02-18 15:42:26 <helo> zero trust or bust
688 2013-02-18 15:42:36 <MC1984> ^
689 2013-02-18 15:42:37 <TD> MC1984: that without a block cap there are no fees. there are several alternative models that have no caps and fees
690 2013-02-18 15:42:39 <MC1984> hehe
691 2013-02-18 15:43:06 <MC1984> TD like what?
692 2013-02-18 15:43:15 <helo> if it's not easily zero trust for most users, then it's back to trusting centralized financial institutions
693 2013-02-18 15:43:24 <BlueMatt> TD: valid point, but I would have to say yes and no...upgrading transparently to full node is actually really quite simple if you already have a list of blocks (which is where the hard part is, but that has to be implemented either way, even if we do partial chains)
694 2013-02-18 15:43:51 <BlueMatt> TD: and I really feel strongly about full node diversity
695 2013-02-18 15:44:17 <BlueMatt> TD: we have 10 full node implementations but right now 100% of blocks are generated using bitcoind and 99.99% of full nodes are bitcoind
696 2013-02-18 15:44:24 <BlueMatt> TD: which is just plain brokwn
697 2013-02-18 15:44:25 <BlueMatt> en
698 2013-02-18 15:44:51 <MC1984> 10?
699 2013-02-18 15:45:03 <TD> hmm, well, we can agree to disagree on that. i guess upgrading to a full node is straightforward at the app layer, just bring up a new set of PeerGroup/BlockChain/Store objects and run them in parallel
700 2013-02-18 15:45:04 <BlueMatt> ok, probably like 5
701 2013-02-18 15:45:12 <BlueMatt> but I know we have quite a few
702 2013-02-18 15:45:14 <kinlo> gavinandresen: regarding the payment protocol, I was thinking, imagine I am a merchant, and I have refunded the buyer for some reason. Wouldn't it be neat that I could show an external auditor that the address I've sent the refund to is indeed the address the original payer intended? So wouldn't it make sense that the payment confirmation the payer would send to the payment server would be signed by one or all keys from the input transactions, proving that
703 2013-02-18 15:45:15 <TD> the trick is managing the switch at the app level
704 2013-02-18 15:45:43 <TD> and then allowing listening, which requires a lot more work (there's no anti-DoS code currently, things like that)
705 2013-02-18 15:45:55 <BlueMatt> TD: even the app level isnt all that hard... https://code.google.com/r/bluemattme-bitcoinj/source/list?name=headersfirstsync
706 2013-02-18 15:46:02 <TD> MC1984: some were discussed on the forum. network assurance contracts is one example.
707 2013-02-18 15:46:09 <TD> BlueMatt: sure
708 2013-02-18 15:46:14 <BlueMatt> yea, listening/exposing the full node layer to p2p is the hard part, really
709 2013-02-18 15:46:32 <MC1984> link?
710 2013-02-18 15:46:37 <TD> kinlo: I think for refunds we decided to let the user submit their own preferred outputs?
711 2013-02-18 15:47:07 <kinlo> TD: yes, but I'm requesting to let the user sign that request somehow
712 2013-02-18 15:47:17 <TD> MC1984: i don't think there's any link, but the principle is simple. you use an assurance contract (see contracts page on the wiki) but the output is zerod out so it all goes to fees. participants can club together to fund network security so if the target isn't reached none of them pay.
713 2013-02-18 15:47:20 <TD> kinlo: sign it with what?
714 2013-02-18 15:47:56 <MC1984> sounds sort of awkward
715 2013-02-18 15:48:19 <kinlo> TD: the proposal is as follows, the merchant sends a request to the user, the user puts a transaction in it, and adds the refund address and sends that to the merchant, so the merchant can push the transaction onto the bitcoin network
716 2013-02-18 15:48:36 <kinlo> now the request the merchant sends to the enduser is signed with x509 as proposed
717 2013-02-18 15:49:03 <gavinandresen> signed with one of the keys used in the payment would kinda-sorta work. Something more complicated using the scriptSig/scriptPubKey system could also work (e.g. create a scriptSig where the previous output hash is not a transaction id, but is the hash of the Payment message, maybe)
718 2013-02-18 15:49:07 <TD> MC1984: network security is a public good, it's a well studied problem in economics. assurance contracts are known to be a way of solving it.
719 2013-02-18 15:49:27 <kinlo> but I'm proposing/asking to sign the entire message the buyer sends back to the merchant so the merchant can proove that if he does a refund, that he has done the refund...
720 2013-02-18 15:49:47 <gavinandresen> kinlo: I don't want to let the perfect be the enemy of the good, so I think we should err on the side of getting a version 1.0 out and then iterating to add new features
721 2013-02-18 15:49:49 <MC1984> i will have to read on this further
722 2013-02-18 15:50:19 <gavinandresen> TD: as I implement payment requests⦠I'm thinking it was dumb to separate PaymentRequest/SignedPaymentRequest.
723 2013-02-18 15:50:20 <TD> kinlo: i suppose a signature using a key from the first scriptSig could work yes.
724 2013-02-18 15:50:55 <TD> gavinandresen: it was done that way so a binary blob can be signed. yes, pki_data/pki_type can be optional fields in the main message and then cleared before re-serializing. but then you run into the issue of unknown fields.
725 2013-02-18 15:51:12 <TD> which is why we arrived at the solution of a wrapper message.
726 2013-02-18 15:51:12 <gavinandresen> ⦠but we're not signing a binary blob anymore, anyway
727 2013-02-18 15:51:16 <kinlo> gavinandresen: that's your call ofcourse, but I'd recommend implementing it asap so it only needs to be implemented once...
728 2013-02-18 15:51:17 <TD> we're not?
729 2013-02-18 15:51:36 <gavinandresen> lemme double-check the gist....
730 2013-02-18 15:51:55 <kinlo> gavinandresen: I also have a different use case for signing it, so I could use it :)
731 2013-02-18 15:51:58 <TD> gavinandresen: if i recall the code correctly, what we sign is the hash of the "bytes" field containing a serialized PaymentRequest
732 2013-02-18 15:52:22 <gavinandresen> TD: not any more: "digital signature over a protocol buffer serialized variation of the SignedPaymentRequest message where signature is a zero-byte array and fields are serialized in numerical order (all current protocol buffer implementations serialize fields in numerical order), using the public key in pki_data."
733 2013-02-18 15:52:24 <GMP> whats the best proposition to increase/control blocksize cap so far? discarding blocks that takes too long to verify? it doesnt exactly guarantee fees to miners
734 2013-02-18 15:52:39 <TD> kinlo: i feel features in the payment protocol shouldn't just be thrown in there â¦.. "refunds" is quite a large feature, i suspect, far more complex than just having a field in a protocol. that said, i have a feeling v1 already has a refund field in it :)
735 2013-02-18 15:52:47 <gavinandresen> TD: ⦠because it is important to sign everything except the signature itself
736 2013-02-18 15:53:05 <TD> gavinandresen: let me check
737 2013-02-18 15:53:17 <kinlo> TD: it does, but it isn't signed in any way so it cannot be proven to remain unaltered by the merchant
738 2013-02-18 15:53:27 <TD> gavinandresen: the only data in SignedPaymentRequest is the signature, more or less.
739 2013-02-18 15:53:33 <TD> oh, and the cert
740 2013-02-18 15:53:43 <TD> i don't think you need the signature to sign the certificates, do you, as they're already signed up to the root
741 2013-02-18 15:53:46 <gavinandresen> TD: and pki_type
742 2013-02-18 15:54:02 <TD> what's the point of changing that? if you modify it the pki_data is no longer readable and the app will just die.
743 2013-02-18 15:54:32 <gavinandresen> TD: the point is not to open up any possible chinks in the armor...
744 2013-02-18 15:54:52 <TD> the problem with signing a re-serialized protocol buffer is that you can't sign any new fields added after v1
745 2013-02-18 15:54:55 rdponticelli has joined
746 2013-02-18 15:55:10 <TD> old clients will load the new protobuf with old generated code, which works fine, but when they re-serialize it they'll drop the extra data. so the signature can't cover them.
747 2013-02-18 15:55:34 <TD> protobuf library can be set up to avoid that happening, but we felt that people would forget or some obscure languages wouldn't treat unknown fields properly, etc.
748 2013-02-18 15:55:38 <TD> so signing the raw bytes was safer.
749 2013-02-18 15:56:29 <TD> the payment request version field could probably be moved into the PaymentRequest message
750 2013-02-18 15:56:52 m00p has quit (Remote host closed the connection)
751 2013-02-18 15:56:53 <TD> but it will cause pain if we can't evolve the protocol later due to a re-serialization step that some implementations get wrong
752 2013-02-18 15:58:06 <gavinandresen> mmmmmâ¦. is it correct to accept the signature on a version=11 PaymentRequest if your implementation has no idea what version=11 PaymentRequest is?
753 2013-02-18 15:59:19 <TD> that's why the original proposal didn't have a version field, i think. you have to define precise versioning semantics. perhaps the version field means "if you don't understand this version, abort" and then backwards compatible extensions don't result in versions getting bumped.
754 2013-02-18 15:59:33 <TD> i think it's OK to have a version number that makes old clients print a "Please upgrade your wallet app" message.
755 2013-02-18 15:59:51 <TD> but then it doesn't really have to be signed. it's just a number. it's got no impact on what the client does beyond whether it aborts early or not.
756 2013-02-18 15:59:59 rdponticelli has quit (Ping timeout: 276 seconds)
757 2013-02-18 16:00:22 <gavinandresen> I'll spend some time thinking through the upgrade scenarios. I'm not convinced (yet) that we need separate messages for Payment/SignedPayment
758 2013-02-18 16:00:29 <TD> how about renaming PaymentRequest to PaymentRequestInternal and SignedPaymentRequest to just PaymentRequest
759 2013-02-18 16:00:45 <TD> well, it's just a workaround for issues with protobufs. namely that people like to reimplement them in incomplete ways :)
760 2013-02-18 16:01:05 <gavinandresen> I don't have a problem with signatures failing if your protobuf implementation sucks.
761 2013-02-18 16:01:26 <gavinandresen> ⦠that's a "fail safe" failure
762 2013-02-18 16:01:28 <TD> you will once somebody (trezor?) ships a popular device that recognizes todays payment requests and then fails the next versions.
763 2013-02-18 16:01:40 <TD> because then you won't be able to add new features. ever. and that's exactly the reason we're using protobufs in the first place.
764 2013-02-18 16:01:53 <TD> i really don't think this is a big deal. almost all interesting data is/will be in the PaymentRequest part.
765 2013-02-18 16:02:42 <gavinandresen> well, lets think about that scenario. Even with the split paymentrequest/signedpayment request, what should the trezor do if it gets a SignedPaymentRequest with "You must support payment requests version 5 or higher" in it?
766 2013-02-18 16:03:12 <TD> also it might be more efficient on very constrained devices i guess. you can hash the serialized PaymentRequest bytes without much RAM, then check the signature, then throw away the wrapping message and deserialize the PaymentRequest directly. deserializing and then reserializing in a slightly different form (just to remove a few fields) means double the memory.
767 2013-02-18 16:03:18 xorgate has joined
768 2013-02-18 16:03:48 <TD> gavinandresen: abort. but hopefully there won't ever be a v5. new features just get added to v1. only features that fundamentally change the protocol in a backwards incompatible way would need that.
769 2013-02-18 16:04:33 <TD> for instance, let's say we want to add dispute mediation support to the protocol. one way to go is to add a new optional field like "optional DisputeMediationData mediation = 10;" to PaymentRequest. wallets that predate that feature ignore it, they just don't offer the user mediation features.
770 2013-02-18 16:04:36 <TD> version is still 1
771 2013-02-18 16:04:54 <gavinandresen> Here's a half-baked thought: Move everything to the PaymentRequest. Put the signature field last, and give it a very high sequence number. Rework version as "signature version", so if we add new fields implementions know which fields to pay attention to when creating the signature hash.
772 2013-02-18 16:05:22 <TD> then edit the raw binary? why is this simpler than just having a wrapper message?
773 2013-02-18 16:06:30 <gavinandresen> what do you mean edit the raw binary? How implementations compute the signature hash is up to them-- reserialize into a version N protobuf, or serialize on the fly as the bytes come over the wire
774 2013-02-18 16:06:45 <gavinandresen> (signature version should be first in sequence, perhaps)
775 2013-02-18 16:07:25 <TD> because how people will implement that is { msg.load(bytes); msg.clear_signature(); msg.serialize_to(new_bytes); check_signature(new_bytes); } and we have the same problem
776 2013-02-18 16:07:59 <TD> calculating the signature hash really has to be the most trivial and basic thing possible, otherwise people will screw it up, especially in ways that aren't obvious because they won't hit problems until we try and add new features.
777 2013-02-18 16:08:21 <TD> i think the current design works ok: required bytes serialized_payment_request = 4;
778 2013-02-18 16:08:28 <TD> hash that. check the signature. done. can't mess it up.
779 2013-02-18 16:08:48 <gavinandresen> Again, I'd rather fail safe and have them show version=2 paymentrequests as untrusted if they don't understand what a version=2 paymentrequest is.
780 2013-02-18 16:09:05 <TD> though also implementations shouldn't refuse to process signed requests where the signature doesn't validate. they should just silently treat them as unsigned.
781 2013-02-18 16:09:12 <gavinandresen> exactly
782 2013-02-18 16:09:33 <TD> yes, but version=2 doesn't mean "keep going as best you can". it should mean "stop because if you proceed, you will get it wrong" and then we try to not ever set it to v=2
783 2013-02-18 16:09:39 <TD> there are almost always backwards compatible ways to do things.
784 2013-02-18 16:10:01 <TD> if calculating the signature hash depends on details of peoples protobuf libraries though, it opens up new scope for errors
785 2013-02-18 16:10:33 <gavinandresen> msg.load() will throw out any new fields that the implementation doesn't understand, right?
786 2013-02-18 16:11:18 <lianj> yes, dont make signature hash worse the currently
787 2013-02-18 16:11:28 <lianj> s/the/than
788 2013-02-18 16:11:52 <gavinandresen> I think { msg.load(bytes); msg.clear_signature(); msg.serialize_to(new_bytes); check_signature(new_bytes); } IS backwards compatible, as long as signature version == 1
789 2013-02-18 16:12:13 <gavinandresen> If we bump signature version then we don't want that dumb code to be backwards compatible.
790 2013-02-18 16:12:39 <TD> it actually won't, on the C++/Java implementations from Google. but it may change the ordering of unknown field.s
791 2013-02-18 16:12:47 nouitfvf has joined
792 2013-02-18 16:13:01 <TD> however i bet some implementations in ruby or haskell or whatever will throw them away
793 2013-02-18 16:13:22 <jouke> TD: when confidence type is not building, will the transaction be removed from memory? (Custom program that uses BitcoinJ)
794 2013-02-18 16:13:24 <TD> gavinandresen: it's not compatible. the data signed by the merchant includes the new fields. when the app re-serializes the message, it dumbly throws out the data it didn't recognize instead of putting it all back in the right place.
795 2013-02-18 16:13:43 <TD> gavinandresen: then the hash won't match. that's the concern.
796 2013-02-18 16:13:49 <TD> gavinandresen: what's the big advantage of a single message?
797 2013-02-18 16:13:52 <gavinandresen> TD: that's my point, the data signed by the merchant would not include the new fields, if signature.version==1
798 2013-02-18 16:14:07 <TD> Jouke: hmm? it'll be garbage collected when there are no more references to it beyond the MemoryPool.
799 2013-02-18 16:14:25 <TD> gavinandresen: why would you want that? the merchant would always want to sign everything, there's no downside to doing so.
800 2013-02-18 16:14:52 <TD> gavinandresen: if you want to introduce additional signatures later that cover less, that can always be another set of optional fields that new clients understand and old clients ignore (but don't need to reserialize)
801 2013-02-18 16:15:28 <TD> gavinandresen: otherwise when you add new fields that you DO want to be signed, suddenly all the old clients will start ignoring the signatures entirely. which will discourage people from using extensions.
802 2013-02-18 16:15:44 * TD doesn't really get the motivation for all this - the versioning and signing scheme previously agreed works fine for all use cases
803 2013-02-18 16:15:48 veerboot has joined
804 2013-02-18 16:15:56 <gavinandresen> TD: I dunnoâ¦. what if the merchant adds a new field that says something like "All warranties advertised on our website are void for this transaction only." The customer never sees that extra data, merchant and customer get into a dispute.....
805 2013-02-18 16:16:37 <TD> that sounds like a good reason not to design such an extension :) but yes, if there's a new feature where old software cannot proceed because it'll screw up, there has to be a new version number (it's backwards incompatible)
806 2013-02-18 16:16:57 <TD> i'm not saying have no version field. it can even be moved into PaymentRequest. but i'd hope that it mostly stays at 1.
807 2013-02-18 16:17:32 <TD> (it probably should be in the PaymentRequest message really)
808 2013-02-18 16:17:39 <TD> that's a simple change though
809 2013-02-18 16:18:25 <gavinandresen> The sticky change that makes me nervous is not signing pki_type / pki_data. Sure, with X509 the certificates are already signed up to the root, but we're trying to be PKI-system-agnostic
810 2013-02-18 16:19:13 <TD> hm, well, is PKI data that isn't signed to _some_ root of trust a PKI system at all? i'm having a hard time imagining what you'd put there that isn't signed by something else
811 2013-02-18 16:19:25 <TD> even a web of trust model would have some data there signed by â¦â¦ someone
812 2013-02-18 16:19:54 <TD> i suppose you could always implement such a thing by setting pki_type to "none" and then putting whatever you needed into a different set of optional fields in the SignedPaymentRequest field.
813 2013-02-18 16:20:26 <TD> older software would just treat such requests as unsigned. newer apps that require you to sign your own PKI data could implement that.
814 2013-02-18 16:20:30 <TD> but it'd be odd.
815 2013-02-18 16:22:53 Zarutian has quit (Quit: Zarutian)
816 2013-02-18 16:24:14 <gavinandresen> ok, I think the versioning argument is a good reason to keep the structure we have. I think a name change is probably the right thing to do
817 2013-02-18 16:24:48 <GMP> what PaymentRequest is used for? is it supposed to be tunneled throught p2p network? if so, i dont think leaving unsigned _something_ is a good idea.. can cause all sort of problems
818 2013-02-18 16:24:52 <gavinandresen> PaymentRequest --> PaymentRequestData, and SignedPaymentRequest --> PaymentRequest. With pki_data and signature optional.
819 2013-02-18 16:25:11 <gavinandresen> GMP: no, not send over the p2p network.
820 2013-02-18 16:25:14 <TD> sure
821 2013-02-18 16:25:26 <TD> GMP: directly from receiver to sender. eg via http or some other mechanism.
822 2013-02-18 16:25:33 <TD> gavinandresen: sure
823 2013-02-18 16:25:34 rdponticelli has joined
824 2013-02-18 16:25:39 <TD> gavinandresen: or PaymentRequest -> PaymentDetails ?
825 2013-02-18 16:25:54 MrTiggr has quit (Ping timeout: 245 seconds)
826 2013-02-18 16:25:57 <gavinandresen> PaymentDetails: ACK.
827 2013-02-18 16:26:15 <TD> btw looks like i'll be announcing bitcoinj 0.7 in parallel with bitcoin 0.8
828 2013-02-18 16:26:29 <TD> so the timing on that is quite spiffy
829 2013-02-18 16:26:33 <gavinandresen> nice
830 2013-02-18 16:26:51 nus- has joined
831 2013-02-18 16:28:28 <TD> i assume it'll be out in the next day or so?
832 2013-02-18 16:28:28 nus has quit (Read error: Connection reset by peer)
833 2013-02-18 16:29:00 <MC1984> is bitcoin wallet going to have the experimental full node stuff
834 2013-02-18 16:29:04 <MC1984> you know, for lols
835 2013-02-18 16:29:41 <gavinandresen> TD: yes, one nagging issue I want to understand better and then I'll tag 0.8 final
836 2013-02-18 16:30:55 <TD> MC1984: that would be a no :)
837 2013-02-18 16:31:36 <MC1984> oh well
838 2013-02-18 16:32:19 <MC1984> i suppose ill have to stick to gta vice city for giving this 1.6g dual core arm cortex 9 a workout for now
839 2013-02-18 16:33:08 BCBot` has joined
840 2013-02-18 16:33:14 <TD> :)
841 2013-02-18 16:33:23 BCBot has quit (Ping timeout: 252 seconds)
842 2013-02-18 16:33:41 <TD> you could send me some code to multi-thread transaction signing, then play satoshidice a lot, get a gigantic wallet and then defragment it all at once
843 2013-02-18 16:33:45 <TD> if you're _really_ keen
844 2013-02-18 16:34:37 <sipa> gavinandresen: did you figure out the leveldb assert failure?
845 2013-02-18 16:34:52 zooko has quit (Ping timeout: 264 seconds)
846 2013-02-18 16:35:10 <gavinandresen> sipa: not yet. It is completely reproducible for me, compling with clang -g
847 2013-02-18 16:35:56 grau has quit (Remote host closed the connection)
848 2013-02-18 16:36:03 <sipa> gavinandresen: the only thing I see is an error in bitcoin, saying that the difficulty of block 1 is out of range
849 2013-02-18 16:37:28 <gavinandresen> sipa: any idea what the leveldb VersionSet class does?
850 2013-02-18 16:37:41 <sipa> no
851 2013-02-18 16:37:55 <sipa> i can have a look tonight
852 2013-02-18 16:38:03 <sipa> but how did you create that datadir?
853 2013-02-18 16:38:05 <gavinandresen> sipa: I stepped through in the debugger, and I'm definitely seeing VersionSet::AppendVersion called several times. Then the destructor is called, and the assert is tripped.
854 2013-02-18 16:38:53 <gavinandresen> sipa: I have a tool that randomly changes one or more bytes in a file, to corrupt things. that datadir is one I corrupted to test error handling
855 2013-02-18 16:39:10 <gavinandresen> I have no idea which bytes it corrupted, or how many....
856 2013-02-18 16:39:53 <TD> there's a unit test that does random corruption too
857 2013-02-18 16:40:03 <TD> I think VersionSet is to do with the details of how it stores data internally
858 2013-02-18 16:41:22 <sipa> i find it strange that you get an assert failure, and i don't
859 2013-02-18 16:41:50 <gavinandresen> yes, I find that strange and troubling, too. I'm compiling with clang++ and -g
860 2013-02-18 16:42:54 <gavinandresen> sipa: hmm, I'm also compiling with the patch that passes CXXFLAGS down into the leveldb build
861 2013-02-18 16:44:27 da2ce7_d has joined
862 2013-02-18 16:44:54 WolfAlex has quit (Read error: Connection reset by peer)
863 2013-02-18 16:44:59 WolfAlex_ has joined
864 2013-02-18 16:45:15 <gavinandresen> sipa: is your leveldb compiled -DNDEBUG ?
865 2013-02-18 16:46:21 <sipa> perhaps, can't check now
866 2013-02-18 16:46:25 da2ce7 has quit (Ping timeout: 252 seconds)
867 2013-02-18 16:47:42 <gavinandresen> I'm doing a release build, and noticing that leveldb is compiling -DNDEBUG, so the assert wouldn't trip for users. I'd still like to understand what is going on before shipping, though
868 2013-02-18 16:48:02 * gavinandresen will wait until sipa gets home tonight
869 2013-02-18 16:50:37 zooko has joined
870 2013-02-18 16:52:14 jdnavarro has quit (Remote host closed the connection)
871 2013-02-18 16:52:16 <TD> does ruby gems not do dependency resolution or something>?
872 2013-02-18 16:52:31 <TD> i'm attempting to run jekyll so i can edit the website and i seem to be 3 frames deep in some nightmarish dependency tree
873 2013-02-18 16:52:57 <TD> gavinandresen: would you accept a pull to move the FAQ as-is from wiki to website?
874 2013-02-18 16:54:44 <gavinandresen> TD: fine by me. while you're at it, could you replace the links to the downloads on the home page with a link to a slightly modified clients page?
875 2013-02-18 16:54:55 <TD> sure. i got a long list of things i want to do.
876 2013-02-18 16:55:02 <TD> the empty News page is an embarrassment, for instance
877 2013-02-18 16:55:14 ThomasV has quit (Quit: Leaving)
878 2013-02-18 17:04:19 Zarutian has joined
879 2013-02-18 17:06:46 t7 has quit (Quit: Leaving)
880 2013-02-18 17:06:55 bitafterbit has joined
881 2013-02-18 17:07:00 denisx has quit (Quit: denisx)
882 2013-02-18 17:16:34 OneFixt has joined
883 2013-02-18 17:17:44 rdymac has quit (Quit: This computer has gone to sleep)
884 2013-02-18 17:21:06 brwyatt is now known as Away!~brwyatt@brwyatt.net|brwyatt
885 2013-02-18 17:21:30 <TD> gavinandresen: do you know why the wiki is still locked down so i can't edit anything?
886 2013-02-18 17:22:00 andytoshi has joined
887 2013-02-18 17:22:34 nus- is now known as nuss
888 2013-02-18 17:23:36 <sipa> TD: apparently spam protection reasons or something
889 2013-02-18 17:23:38 <gavinandresen> TD: logout and log back in-- and you'll be asked to send a token amount of BTC
890 2013-02-18 17:23:42 <sipa> ah
891 2013-02-18 17:23:45 <gavinandresen> ⦠yes, for spam protection
892 2013-02-18 17:24:02 <TD> i see
893 2013-02-18 17:24:53 <TD> neat. i guess.
894 2013-02-18 17:24:57 <TD> though 1 bitcent is quite expensive.
895 2013-02-18 17:25:28 <gavinandresen> apply for a Foundation grant to cover it....
896 2013-02-18 17:25:35 <gavinandresen> (d'oh! deadline passed...)
897 2013-02-18 17:26:36 paraipan has joined
898 2013-02-18 17:26:40 Ken` has quit (Quit: leaving)
899 2013-02-18 17:27:22 paybitcoin1 has joined
900 2013-02-18 17:28:42 jevin has joined
901 2013-02-18 17:28:52 paybitcoin has quit (Ping timeout: 264 seconds)
902 2013-02-18 17:31:59 <gmaxwell> better if you get someone with mtgox btc to pay itâ zero confirms.
903 2013-02-18 17:32:05 Maddy has joined
904 2013-02-18 17:32:29 Maddy is now known as Guest67517
905 2013-02-18 17:33:04 <Guest67517> Heya guys, I had a question and I hope someone can help me out here (send me a message :)) I've been trying to launch my bitcoin service on TOR, no errors or faults anywhere yet the final step somehow isn't coming through
906 2013-02-18 17:34:37 FredEE has joined
907 2013-02-18 17:41:42 WolfAlex has joined
908 2013-02-18 17:42:09 WolfAlex_ has quit (Ping timeout: 252 seconds)
909 2013-02-18 17:45:37 ThomasV has joined
910 2013-02-18 17:49:02 discretefx has joined
911 2013-02-18 17:52:22 JDuke128 has joined
912 2013-02-18 17:52:58 mmoya has joined
913 2013-02-18 17:53:39 OneFixt has joined
914 2013-02-18 17:59:00 rbecker is now known as RBecker
915 2013-02-18 18:01:28 root2 has quit (Ping timeout: 248 seconds)
916 2013-02-18 18:02:47 OneFixt has quit (Remote host closed the connection)
917 2013-02-18 18:04:09 rdymac has joined
918 2013-02-18 18:08:16 OneFixt has joined
919 2013-02-18 18:10:45 OneFixt has quit (Read error: Connection reset by peer)
920 2013-02-18 18:15:01 <TD> my god jekyll must be the slowest text rendering engine ever made
921 2013-02-18 18:18:52 Guest67517 has quit (Ping timeout: 245 seconds)
922 2013-02-18 18:35:09 kuu has joined
923 2013-02-18 18:37:10 <kuu> ||@ip70-176-44-88.ph.ph.cox.net|I got a bag of bitcoins right here! Who wants em?
924 2013-02-18 18:39:07 <jouke> Me
925 2013-02-18 18:39:52 <jouke> I
926 2013-02-18 18:43:18 <kuu> ||@ip70-176-44-88.ph.ph.cox.net|how much?
927 2013-02-18 18:43:27 <jouke> Everything?
928 2013-02-18 18:43:30 <jouke> :)
929 2013-02-18 18:44:15 drizztbsd has quit (Read error: Connection reset by peer)
930 2013-02-18 18:44:31 <kuu> ||@ip70-176-44-88.ph.ph.cox.net|Everything? Right now? you got it!
931 2013-02-18 18:51:14 rdymac has quit (Quit: This computer has gone to sleep)
932 2013-02-18 18:52:10 TD has quit (Quit: TD)
933 2013-02-18 18:56:48 <jouke> kuu: where is the private key?
934 2013-02-18 18:56:55 <jouke> I don't see it
935 2013-02-18 18:57:15 nuss has quit (Read error: Connection reset by peer)
936 2013-02-18 18:58:12 kuu has quit (||@ip70-176-44-88.ph.ph.cox.net|Remote host closed the connection)
937 2013-02-18 18:58:15 grau has joined
938 2013-02-18 19:00:43 nus has joined
939 2013-02-18 19:02:51 <zackham> is it possible to speed up confirmation by broadcasting your transaction to a machine you control and prioritizing your transactions for inclusion in the block?
940 2013-02-18 19:03:25 <Luke-Jr> yes and no
941 2013-02-18 19:03:56 <Luke-Jr> 1) it's technically possible of course 2) mainline bitcoind does not support this 3) I have an open pullrequest to add support for this (pending rewrite)
942 2013-02-18 19:04:15 <helo> would it be possible to create a bitcoin-backed side-chain, so that the sidechain coins lose all value (and its blockchain can be discarded) when the backing coins are spent on mainnet?
943 2013-02-18 19:04:37 <zackham> Luke-Jr: got a link handy to your pull req?
944 2013-02-18 19:05:01 <Luke-Jr> https://github.com/bitcoin/bitcoin/pull/1583
945 2013-02-18 19:05:13 <zackham> im not afraid of getting my hands dirty in some code or at the protocol level if necessary just trying to understand my options thoroughly
946 2013-02-18 19:05:52 <Luke-Jr> zackham: Eligius mining pool is available for priority processing deals ;)
947 2013-02-18 19:06:58 <zackham> noted, ill be in touch if we end up going this route
948 2013-02-18 19:07:25 <zackham> ive got a lot more reading before i understand things well enough
949 2013-02-18 19:07:40 <zackham> thanks for the quick help and link
950 2013-02-18 19:07:41 <Eliel_> helo: I suppose that might be possible, but why not just use bitcoins directly if you're going to be depending on bitcoin blockchain anyway?
951 2013-02-18 19:08:33 <helo> Eliel_: to cleanly exclude a group (or class) of transactions from having to live in the blockchain forever
952 2013-02-18 19:09:24 dust-otc has quit (Remote host closed the connection)
953 2013-02-18 19:11:10 gritcoin has joined
954 2013-02-18 19:11:49 BTCTrader has quit (Quit: BTCTrader)
955 2013-02-18 19:13:18 <andytoshi> helo: in principle it could be done, since the bitcoin network timestamps everything with the block depth
956 2013-02-18 19:13:33 <andytoshi> that is, it would be unambiguous to say "do XXX when bitcoin says YYY" in your protocol
957 2013-02-18 19:14:43 <andytoshi> you even start a blockchain where "coin creation" and "coin destruction" correspond to certain P2SH transaction on bitcoin
958 2013-02-18 19:14:47 <helo> could have a nlocktime'd spend so everyone knows when the chain will collapse
959 2013-02-18 19:15:25 <Eliel_> helo: hot potato? :P
960 2013-02-18 19:15:27 <andytoshi> i think it's a cool idea, and it's on my list of "if i were immortal, i would spend time writing it" projects
961 2013-02-18 19:16:03 <sipa> Andy McCloudComputing
962 2013-02-18 19:16:37 <Eliel_> helo: the biggest disadvantage that idea has when compared to direct use of bitcoin is that in your system there exists a third party that can make your money worthless.
963 2013-02-18 19:17:56 <andytoshi> Eliel_: i think with some cleverness, you could make sure the coin destructor and the coin's owner are always the same
964 2013-02-18 19:18:11 <andytoshi> make it merged-mining-able and entirely funded by fees, and you've got a microtransaction blockchain
965 2013-02-18 19:18:42 <Eliel_> andytoshi: potentially possible but I'd expect that would require support from bitcoin network too to work.
966 2013-02-18 19:19:34 <Eliel_> which would essentially pair the networks tightly enough that there's probably not much point having the division anymore.
967 2013-02-18 19:20:00 RBecker is now known as rbecker
968 2013-02-18 19:20:16 <Luke-Jr> whoa
969 2013-02-18 19:20:21 <Luke-Jr> my Bitcoin-Qt has an error
970 2013-02-18 19:20:49 <Luke-Jr> EXCEPTION: St12out_of_range CInv::GetCommand() : type=3 unknown type bitcoin in ProcessMessages()
971 2013-02-18 19:21:21 <andytoshi> Eliel_: it wouldn't be so tight, the altchain would only depend on bitcoin when translating bitcoins into altchains
972 2013-02-18 19:21:26 <andytoshi> altcoins*
973 2013-02-18 19:21:32 <sipa> Luke-Jr: that's a BIP37 filteredblock request, i think
974 2013-02-18 19:21:46 <helo> it could allow some people to do a lot of cheap value exchanges, given that the cost would be one or two (large) bitcoin transactions
975 2013-02-18 19:22:50 <Luke-Jr> sipa: why is it being requested of me? :x
976 2013-02-18 19:23:09 <Luke-Jr> or I guess, the better question is why it isn't just ignored
977 2013-02-18 19:23:13 <sipa> Luke-Jr: recent bitcoinj just sends it to everyone
978 2013-02-18 19:23:18 <sipa> it expects it to be ignored
979 2013-02-18 19:23:29 <Eliel_> andytoshi: both bitcoin and the altchain would have to constantly watch the other chain for transactions moving coins between the chains
980 2013-02-18 19:23:31 <sipa> i think
981 2013-02-18 19:23:36 <Luke-Jr> sipa: pretty ugly for it to make the statusbar 3 or 4 lines tall with an error :/
982 2013-02-18 19:23:43 <sipa> outch
983 2013-02-18 19:23:59 <sipa> that's not supposed to happen
984 2013-02-18 19:24:14 <gmaxwell> I think it's an absolute bugâ and a security concernâ if network traffic can trigger exceptions like that.
985 2013-02-18 19:24:34 <sipa> agree
986 2013-02-18 19:25:04 <gavinandresen> agreed. This is version 0.8 only ?
987 2013-02-18 19:25:16 <jgarzik> +1
988 2013-02-18 19:25:43 <Luke-Jr> gavinandresen: I'm still using 0.7-based code
989 2013-02-18 19:25:47 <sipa> gavinandresen: nothing changed to the network handling in 0.8, so i think it's very old
990 2013-02-18 19:25:56 <Luke-Jr> http://luke.dashjr.org/tmp/screenshots/snapshot91.png
991 2013-02-18 19:26:18 <gavinandresen> ok, then a high priority to fix for 0.8.1, not a 0.8 showstopper
992 2013-02-18 19:26:23 <sipa> at least 0.4
993 2013-02-18 19:27:30 <Luke-Jr> yeah, doesn't look like it killed network processing or anything
994 2013-02-18 19:27:32 <Luke-Jr> just an ugly message
995 2013-02-18 19:27:54 <sipa> it doesn't push you into safe mode?
996 2013-02-18 19:28:29 <Luke-Jr> doesn't seem to, is there a good way to check for sure?
997 2013-02-18 19:28:30 <Goonie> like: I tested bloom filtering a lot against 0.8, and never saw this. Or is this not about bloom filtering?
998 2013-02-18 19:28:43 <Goonie> s/like/luke/
999 2013-02-18 19:28:48 <sipa> just so you know: this problem has existed since v0.1.5
1000 2013-02-18 19:29:07 <sipa> Goonie: it's about not having bloom filtering
1001 2013-02-18 19:29:21 <Luke-Jr> Goonie: 0.8 implements bloom filtering, I think? so it's only an error before that
1002 2013-02-18 19:29:22 <sipa> Goonie: if you request it from a node that doesn't know filtered blocks, this errors results
1003 2013-02-18 19:29:40 <Luke-Jr> sipa: if it's only an ugly message, it may have not appeared in wx
1004 2013-02-18 19:29:44 <Goonie> hmm, but how can you fix old clients by releasing a 0.8.1?
1005 2013-02-18 19:29:50 <sipa> you can't
1006 2013-02-18 19:29:56 reizuki__ has quit (Quit: Konversation terminated!)
1007 2013-02-18 19:30:05 <sipa> but the problem still exists in 0.8.0: just request any not defined inv type
1008 2013-02-18 19:30:07 root2 has joined
1009 2013-02-18 19:30:12 <Luke-Jr> Goonie: once the fix is in master, I'll backport it to the older branches
1010 2013-02-18 19:30:24 <Goonie> ok thanks for the explaination
1011 2013-02-18 19:30:29 nouitfvf has quit (Ping timeout: 252 seconds)
1012 2013-02-18 19:34:44 <gmaxwell> Whatever happened to tcatm's GUI work?
1013 2013-02-18 19:35:40 m00p has joined
1014 2013-02-18 19:35:45 <andytoshi> Eliel_: the altchain would need to constantly watch bitcoin, but not the other way around -- all bitcoin would see of an altcoin is a pair (creation/anhililation) of P2SH transactions
1015 2013-02-18 19:36:18 <andytoshi> and these would be valid bitcoin transactions, so bitcoin needn't care that those scripts said magic things to some altcoin
1016 2013-02-18 19:38:14 <sipa> gmaxwell: different priorities, no more time to work on it, ...
1017 2013-02-18 19:38:46 <Eliel_> andytoshi: that's not enough to add any restrictions to who the bitcoin transaction goes to.
1018 2013-02-18 19:39:37 <andytoshi> Eliel_: it's not obvious to me that you're right (though I suspect you are)
1019 2013-02-18 19:40:10 PhantomSpark has joined
1020 2013-02-18 19:40:18 <gmaxwell> (I asked because every time I see the GUI I managed to be surprised at how clunky it seems to me)
1021 2013-02-18 19:42:38 freakazoid_ has joined
1022 2013-02-18 19:43:18 freakazoid_ is now known as freakazoid
1023 2013-02-18 19:52:08 JDuke128 has quit (Quit: ["Textual IRC Client: www.textualapp.com"])
1024 2013-02-18 19:57:19 root2 has quit (Ping timeout: 256 seconds)
1025 2013-02-18 20:02:39 TD has joined
1026 2013-02-18 20:10:53 andytoshi has quit (Ping timeout: 276 seconds)
1027 2013-02-18 20:11:47 gritcoin has quit (Ping timeout: 245 seconds)
1028 2013-02-18 20:13:45 BTCOxygen has quit (Ping timeout: 256 seconds)
1029 2013-02-18 20:16:10 jdnavarro has joined
1030 2013-02-18 20:17:37 andytoshi has joined
1031 2013-02-18 20:26:15 BTCOxygen has joined
1032 2013-02-18 20:26:32 ielo has joined
1033 2013-02-18 20:28:58 xorgate has quit (Ping timeout: 260 seconds)
1034 2013-02-18 20:32:12 <sipa> gavinandresen: seems my leveldb is indeed built with -DNDEBUG
1035 2013-02-18 20:32:37 hahuang65 has quit (Quit: Textual IRC Client: http://www.textualapp.com/)
1036 2013-02-18 20:33:38 PhantomSpark has quit (2!~kvirc@137.125.143.209|Ping timeout: 276 seconds)
1037 2013-02-18 20:33:55 rbecker is now known as RBecker
1038 2013-02-18 20:34:39 <gavinandresen> sipa: good, that explains the assert difference...
1039 2013-02-18 20:35:27 <sipa> if the pass-flags-down-to-leveldb patch changes that, there's something wrong with it imho
1040 2013-02-18 20:35:27 BTCTrader has joined
1041 2013-02-18 20:35:59 <gavinandresen> something wrong with that patch? if I'm compiling for development (-g), then I want leveldb compiled -g, too....
1042 2013-02-18 20:36:16 <sipa> ah ok, sure
1043 2013-02-18 20:36:23 <sipa> but not when building a release binary
1044 2013-02-18 20:36:26 <gavinandresen> Compiling for release it'll pass down -O3 (or whatever)
1045 2013-02-18 20:36:45 <sipa> leveldb's makefile itself sets -DNDEBUG by default
1046 2013-02-18 20:37:32 <gavinandresen> sipa: right, the patch overrides leveldb's default OPT ?= -O2 -DNDEBUG
1047 2013-02-18 20:37:38 <sipa> ok
1048 2013-02-18 20:38:55 <Luke-Jr> gavinandresen: Isn't -O3 a "known to break good code" level?
1049 2013-02-18 20:39:05 <gavinandresen> so: I could tag 0.8 with your "reindex?" patch; and know that the assert is compiled away for release builds. I think the only consequence is a minor memory leak
1050 2013-02-18 20:39:27 <gavinandresen> (purposely ignoring an assert makes me nervous, though)
1051 2013-02-18 20:39:56 <sipa> technically, any assert that fails means there's a bug in the code
1052 2013-02-18 20:40:03 tsche has quit ()
1053 2013-02-18 20:40:05 <sipa> as it is a should-not-ever-happen case
1054 2013-02-18 20:40:40 <gavinandresen> yes. No sure whose code has the bug, thoughâ¦. leveldb or the way you're re-setting leveldb before re-indexing.
1055 2013-02-18 20:41:04 <sipa> i don't reset it - i destroy the db/env objects and create new ones
1056 2013-02-18 20:42:16 <gavinandresen> Luke-Jr: <annoyed snark mode> no, -O3 has never ever broken any known good code in any release of any compiler ever. I guarantee it, 100%. </annoyed snark>
1057 2013-02-18 20:42:17 <sipa> best guess is that you triggered a weird condition in leveldb by random byte corruptions
1058 2013-02-18 20:42:36 <sipa> (which are not a common failure pattern)
1059 2013-02-18 20:42:38 <gavinandresen> yay me!
1060 2013-02-18 20:42:39 <Luke-Jr> â¦
1061 2013-02-18 20:43:26 <sipa> i'm not sure if i like 0.8 being release already - reports of crashes and unbounded memory usage scare me
1062 2013-02-18 20:43:29 swappermall_ has joined
1063 2013-02-18 20:43:51 swappermall_ is now known as Guest49365
1064 2013-02-18 20:44:10 Guest49365 has quit (Client Quit)
1065 2013-02-18 20:44:31 <gavinandresen> unbounded memory usage seem to be people deciding that if -dbcache=1000 is good, then -dbcache=4000 must be four times better. Even if they only have 3GB of memory....
1066 2013-02-18 20:44:45 <Luke-Jr> lol
1067 2013-02-18 20:44:56 <Luke-Jr> let's try -dbcache=100000000
1068 2013-02-18 20:45:16 <sipa> it's people setting -dbcache high indeed, but even with -dbcache=2000, you shouldn't get the application grow to use 4 GB quickly + crash
1069 2013-02-18 20:45:42 <sipa> typically, for high -dbcache values, the heuristics are a bit off and you get less
1070 2013-02-18 20:46:14 <gavinandresen> sipa: do you have some ideas for how to proceed? we can't seem to reproduce these problems on our machines....
1071 2013-02-18 20:46:19 <dhill> boost 1.53.0 seems to be working better for me. no crashes yet.
1072 2013-02-18 20:51:29 <sipa> gavinandresen: going through the 0.8.0rc1 announce thread, as my memory of what i saw may be biased
1073 2013-02-18 20:52:34 <TD> my 0.8 node is sitting at around 450mb resident
1074 2013-02-18 20:52:47 <TD> sipa: well obviously people who test it and it all works are less likely to post ...
1075 2013-02-18 20:54:40 xorgate has joined
1076 2013-02-18 20:55:27 <sipa> even then, the majority seems actually very positive
1077 2013-02-18 20:55:27 MobPhone has joined
1078 2013-02-18 20:56:10 <sipa> there was one guy who had problems with -dbcache set very high, and a few who got reports of orphan blocks during reindex (expected if the actual block data is corrupted on disk)
1079 2013-02-18 20:56:16 tsche has joined
1080 2013-02-18 20:56:33 <sipa> one interesting case of someone who deleted some leveldb files, and was unable to start bitcoin afterwards
1081 2013-02-18 20:57:13 <gavinandresen> mmm, I'm re-reading that thread tooâ¦. there does seem to be some issue with large -dbcache values, but most users will sync with the (small) default, so that doesn't really worry me.
1082 2013-02-18 20:57:41 <gavinandresen> Stress testing / deleting files: not a showstopper bug, but would be Nice To Fix later. Same with crash on shutdown bug.
1083 2013-02-18 20:57:57 ielo has quit (Ping timeout: 256 seconds)
1084 2013-02-18 20:58:27 <sipa> personal experience: i've found it very hard to actually get bitcoin to detect errors when messing with the leveldb files
1085 2013-02-18 20:58:53 <sipa> far in the chain the error checks seem fine, as 288 is a ton of transactions that need to be checked
1086 2013-02-18 20:59:42 <sipa> but early in the chain, it's quite possible to make it not detect errors, and sometimes not ever notice a file was deleted, very occasionally actually still mark a chain as invalid
1087 2013-02-18 21:00:09 <gavinandresen> in that case what happens? stuck chain?
1088 2013-02-18 21:00:13 <sipa> yeah
1089 2013-02-18 21:00:33 <sipa> i don't think these are likely scenarios though
1090 2013-02-18 21:01:05 <sipa> one possibility for improving the early checks is having a -checktransactions instead of -checkblocks, and check the last N transactions, whether that's few or many blocks
1091 2013-02-18 21:02:53 <gavinandresen> if it was hard to recover from a stuck chain, or was common, then it'd be a showstopper for 0.8. Since it is pretty easy (delete chainstate/blocks, then re-download) and looks like it is rare...
1092 2013-02-18 21:03:38 <sipa> -reindex should always work
1093 2013-02-18 21:04:42 <gavinandresen> I think I'll add a KNOWN BUGS to the release notes, mentioning the crash-at-shutdown issue, and "sporadic reports of block chain database corruption, run -reindex if you get stuck"
1094 2013-02-18 21:05:02 <sipa> crash-at-shutdown should be fixed
1095 2013-02-18 21:05:22 <sipa> (the ~CCheckQueue destructor calling Quit())
1096 2013-02-18 21:06:16 <gavinandresen> ok, then just the stuck blockchain note. User-visible symptom is the "â¦transactions may not be correct, you may have to upgrade" warning?
1097 2013-02-18 21:06:30 <sipa> yes
1098 2013-02-18 21:06:52 <sipa> not sure if i've seen any report of that, actually
1099 2013-02-18 21:06:59 <sipa> so it's probably hard to reproduce
1100 2013-02-18 21:07:54 <gavinandresen> maybe I shouldn't mention it, then, so we DO see reports if it happens
1101 2013-02-18 21:09:42 <Luke-Jr> or put a "If you encounter this problem, you can fix it in a few hours with -reindex, but we'd prefer you work with us to troubleshoot the cause if you can wait"
1102 2013-02-18 21:11:23 mappum has joined
1103 2013-02-18 21:11:33 zooko has quit (Ping timeout: 256 seconds)
1104 2013-02-18 21:12:00 andytoshi has quit (Remote host closed the connection)
1105 2013-02-18 21:12:15 topi` has quit (Ping timeout: 252 seconds)
1106 2013-02-18 21:13:08 topi` has joined
1107 2013-02-18 21:14:11 <TD> hmmmm
1108 2013-02-18 21:14:17 * TD wonders if he can trust a cryptographer who uses a hotmail address
1109 2013-02-18 21:14:25 <sipa> haha
1110 2013-02-18 21:14:41 <TD> the ed25519 paper has 5 authors, 4 of which have email addresses in which the domain name has something to do with crypto
1111 2013-02-18 21:14:46 <TD> the 5th has a hotmail address :)
1112 2013-02-18 21:15:23 Jackneill has quit (Ping timeout: 244 seconds)
1113 2013-02-18 21:15:50 <sipa> hmm? the paper i've open has by@crypto.tw as fifth author
1114 2013-02-18 21:16:09 <lianj> TD: because he is pivoting :P
1115 2013-02-18 21:16:20 <TD> http://ed25519.cr.yp.to/ed25519-20110926.pdf
1116 2013-02-18 21:16:22 <TD> that one ?
1117 2013-02-18 21:16:31 <TD> it has nielsduif@hotmail.com
1118 2013-02-18 21:16:54 <sipa> ah, second author here
1119 2013-02-18 21:17:12 <sipa> "high-speed high-security signatures"
1120 2013-02-18 21:19:53 dparrish has joined
1121 2013-02-18 21:26:46 ThomasV has quit (Ping timeout: 255 seconds)
1122 2013-02-18 21:27:57 xorgate has quit (Read error: Connection reset by peer)
1123 2013-02-18 21:28:32 root2 has joined
1124 2013-02-18 21:29:02 PhantomSpark has joined
1125 2013-02-18 21:30:50 PhantomSpark has quit (Ping timeout: 276 seconds)
1126 2013-02-18 21:31:26 <pjorrit_> hotmail isn't too is it? it looked much better the few times i had that page open in the last few years
1127 2013-02-18 21:31:30 <pjorrit_> +bad*
1128 2013-02-18 21:31:40 ProfMac has joined
1129 2013-02-18 21:31:45 <Luke-Jr> pjorrit_: besides blocking everyone? <.<
1130 2013-02-18 21:32:22 <pjorrit_> who are they blocking? (for me it's an extra account i don't really use but still forward)
1131 2013-02-18 21:32:40 <TD> yeah i'm sorta joking
1132 2013-02-18 21:32:42 <TD> it's not terrible anymore
1133 2013-02-18 21:33:11 <Luke-Jr> pjorrit_: seems 75% of the time when I have to email someone at hotmail, they never get it
1134 2013-02-18 21:34:05 <pjorrit_> maybe they're just blocking you :D
1135 2013-02-18 21:35:13 <TD> http://crypto.stackexchange.com/questions/3596/is-it-possible-to-pick-your-ed25519-public-key
1136 2013-02-18 21:35:17 <TD> awesome diagram of ed25519 there
1137 2013-02-18 21:35:45 <sipa> TD: yeah, that really helped me understand it
1138 2013-02-18 21:38:04 [ken] has joined
1139 2013-02-18 21:44:43 bitafterbit has quit (Read error: Connection reset by peer)
1140 2013-02-18 21:51:21 BTCOxygen has quit (Ping timeout: 276 seconds)
1141 2013-02-18 21:55:35 occulta has joined
1142 2013-02-18 21:58:11 pierre` has joined
1143 2013-02-18 22:01:50 BTCTrader has quit (Quit: BTCTrader)
1144 2013-02-18 22:02:14 BTCOxygen has joined
1145 2013-02-18 22:06:00 zooko has joined
1146 2013-02-18 22:07:07 copumpkin has quit (Ping timeout: 240 seconds)
1147 2013-02-18 22:07:38 CoinBit has joined
1148 2013-02-18 22:07:49 copumpkin has joined
1149 2013-02-18 22:07:51 <CoinBit> Hello!
1150 2013-02-18 22:08:04 <pierre`> /wjpo/win16
1151 2013-02-18 22:08:08 <pierre`> @#@#
1152 2013-02-18 22:08:21 <CoinBit> I have a question: can you hotswap java code in netbeans?
1153 2013-02-18 22:08:23 grau has quit (Remote host closed the connection)
1154 2013-02-18 22:08:39 <Luke-Jr> CoinBit: does this look like #Java ?
1155 2013-02-18 22:08:46 <Zarutian> TD: wait? what? is ed25519 that "simple"?
1156 2013-02-18 22:09:00 grau has joined
1157 2013-02-18 22:09:02 <CoinBit> No... Bye then...
1158 2013-02-18 22:13:19 grau has quit (Ping timeout: 256 seconds)
1159 2013-02-18 22:15:05 <upb> CoinBit: dunno if thats what youre asking but theres a product called javarebel for hotswapping java code in appservers
1160 2013-02-18 22:15:05 TD has quit (Read error: Connection reset by peer)
1161 2013-02-18 22:15:10 TD_ has joined
1162 2013-02-18 22:15:10 TD_ has quit (Client Quit)
1163 2013-02-18 22:15:41 <CoinBit> i,ll check it out thx
1164 2013-02-18 22:19:11 Insu has quit (Remote host closed the connection)
1165 2013-02-18 22:21:49 TD has joined
1166 2013-02-18 22:24:01 TD_ has joined
1167 2013-02-18 22:25:14 ovidiusoft has quit (Quit: leaving)
1168 2013-02-18 22:25:47 <dhill> my last 'bitcoind stop' caused blkindex.dat corruption
1169 2013-02-18 22:26:00 <dhill> http://gbpaste.org/QexK2 <-- anything stick out as being out of order?
1170 2013-02-18 22:27:04 TD has quit (Ping timeout: 252 seconds)
1171 2013-02-18 22:27:05 TD_ is now known as TD
1172 2013-02-18 22:27:20 jdnavarro has quit (Remote host closed the connection)
1173 2013-02-18 22:28:48 xorgate has joined
1174 2013-02-18 22:31:44 ovidiusoft has joined
1175 2013-02-18 22:33:16 abracadabra has quit (Ping timeout: 248 seconds)
1176 2013-02-18 22:33:17 <TD> Zarutian: what do you mean by simple?
1177 2013-02-18 22:33:43 Diablo-D3 has joined
1178 2013-02-18 22:34:33 <Zarutian> I thought it would be much harder to describe.
1179 2013-02-18 22:34:53 <gmaxwell> dhill: where is the rest? Everything there looks normal and happy. Where is the next startup logging unhappyness?
1180 2013-02-18 22:34:59 <sipa> the same diagram for ECDSA would be even simpler
1181 2013-02-18 22:35:08 <sipa> the difficulty is in the layers underneath
1182 2013-02-18 22:35:18 <dhill> let me start it up
1183 2013-02-18 22:35:31 ovidiusoft has quit (Read error: Operation timed out)
1184 2013-02-18 22:37:26 <TD> hm, colour me impressed. javafx is really nice.
1185 2013-02-18 22:37:54 X-Scale has joined
1186 2013-02-18 22:38:52 abracadabra has joined
1187 2013-02-18 22:38:52 abracadabra has quit (Changing host)
1188 2013-02-18 22:38:53 abracadabra has joined
1189 2013-02-18 22:39:17 <dhill> ahh, my assumption was wrong
1190 2013-02-18 22:40:07 <dhill> are the invalidchainfound warnings.. and reorganized fails ok?
1191 2013-02-18 22:40:23 <sipa> if it happens once, yes
1192 2013-02-18 22:40:31 <dhill> no, i am just beeing flooding
1193 2013-02-18 22:40:33 <dhill> ed
1194 2013-02-18 22:40:42 <sipa> in that case, most certainly no
1195 2013-02-18 22:41:07 <dhill> db_verify blkindex.dat failed after my 'bitcoind stop'
1196 2013-02-18 22:41:13 <sipa> it typically means an error in the block index, and failed verifications as a result of it
1197 2013-02-18 22:41:13 <dhill> which is why i thought it was corrupt
1198 2013-02-18 22:43:07 zooko has quit (Ping timeout: 240 seconds)
1199 2013-02-18 22:43:33 <gmaxwell> dhill: if you're running db_verify on a non-detached DB than I have no clue what happens. Why are you running that?
1200 2013-02-18 22:43:35 TD has quit (Read error: No route to host)
1201 2013-02-18 22:44:33 MobPhone has quit (Read error: Connection reset by peer)
1202 2013-02-18 22:44:52 <dhill> just noticed that db_verify seems to always tell me if bitcoind is going to work or not
1203 2013-02-18 22:45:01 <dhill> whenever it passes, bitcoind starts up fine
1204 2013-02-18 22:45:10 <dhill> when it fails, bitcoind throws a fit
1205 2013-02-18 22:45:16 <gavinandresen> BlueMatt: I'm trying to figure out why the pull-tester is using g++ to compile a mingw32 leveldb with https://github.com/bitcoin/bitcoin/pull/2311
1206 2013-02-18 22:45:27 <gmaxwell> dhill: what are you doing where bitcoin _ever_ fails to start?
1207 2013-02-18 22:45:45 <dhill> i do 'bitcoind stop'
1208 2013-02-18 22:45:51 <dhill> and once in a while, that corrupts blkindex.dat
1209 2013-02-18 22:46:02 <gmaxwell> dhill: and you know its corrupt because?
1210 2013-02-18 22:46:31 <gmaxwell> I'm trying to figure out how you're distinguishing the case where db_verify corrupts the database and when its corrupt on its own.
1211 2013-02-18 22:47:31 <dhill> http://gbpaste.org/KVuCD
1212 2013-02-18 22:49:24 <dhill> assertion "pindexFirst" failed: file "main.cpp", line 983, function "GetNextWorkRequired"
1213 2013-02-18 22:49:27 <dhill> Abort trap (core dumped)
1214 2013-02-18 22:50:00 <sipa> can you try with 0.8 code instead of 0.7.2?
1215 2013-02-18 22:50:10 <Luke-Jr> gavinandresen: CXX is probably set in the OS/buildenv?
1216 2013-02-18 22:50:24 <dhill> sipa: is there a tarball, or should i try latest git?
1217 2013-02-18 22:50:35 <sipa> dhill: latest git
1218 2013-02-18 22:50:50 <sipa> you can use 0.8.0rc1, but we're close to a final 0.8 now anyway
1219 2013-02-18 22:51:02 <dhill> ok, i'll just yank git down.. no prob
1220 2013-02-18 22:51:07 root2 has quit (Ping timeout: 248 seconds)
1221 2013-02-18 22:51:35 <gavinandresen> Luke-Jr: right, that's probably it⦠pull-tester shouldn't do that
1222 2013-02-18 22:52:34 <Luke-Jr> gavinandresen: it's pretty standard for native builds, but cross-builds should really be overriding CXX with a cross-compiler too ..
1223 2013-02-18 22:52:58 <gavinandresen> mmm, I don't see that the build-script sets CXX anywhereâ¦.
1224 2013-02-18 22:53:03 <gavinandresen> https://github.com/TheBlueMatt/test-scripts/blob/master/build-script.sh
1225 2013-02-18 22:53:04 <Luke-Jr> so if it were me, I'd teach pulltester to pass the proper CXX
1226 2013-02-18 22:54:29 <Luke-Jr> try: make -f makefile.linux-mingw -j6 DEPSDIR=/mnt/mingw CXX='i586-mingw32msvc-g++' test_bitcoin.exe
1227 2013-02-18 23:04:20 * dhill makes local patches
1228 2013-02-18 23:04:22 occulta has quit (Quit: KVIrc 4.1.3 Equilibrium http://www.kvirc.net/)
1229 2013-02-18 23:05:13 <gavinandresen> pull-tester will probably be unhappy, but I just tagged version 0.8.0
1230 2013-02-18 23:07:08 <BlueMattBot> Project Bitcoin build #246: FAILURE in 13 min: http://jenkins.bluematt.me/job/Bitcoin/246/
1231 2013-02-18 23:07:10 <gmaxwell> I dunno if anyone else has noticed yet, but bluematt got the pull tester to remark when pulls reduce line-of-code test coverage. It appears to work correctly.
1232 2013-02-18 23:07:31 <gavinandresen> modulo somehow screwing up the mingw build environment....
1233 2013-02-18 23:07:32 root2 has joined
1234 2013-02-18 23:07:39 * sipa fires up gitian
1235 2013-02-18 23:08:20 PhantomSpark has quit (2!~kvirc@pool-71-251-16-105.nycmny.fios.verizon.net|Ping timeout: 276 seconds)
1236 2013-02-18 23:08:31 zooko has joined
1237 2013-02-18 23:10:01 MC1984 has quit (Read error: Connection reset by peer)
1238 2013-02-18 23:10:31 MC1984 has joined
1239 2013-02-18 23:11:17 <Luke-Jr> gavinandresen: no rc2?
1240 2013-02-18 23:11:41 <Luke-Jr> gmaxwell: nice!
1241 2013-02-18 23:11:42 <gavinandresen> nope. I'm living wild.
1242 2013-02-18 23:12:14 MrTiggr has joined
1243 2013-02-18 23:12:33 * sipa just increased the range of his graphs a bit
1244 2013-02-18 23:12:47 <Luke-Jr> gmaxwell: would be nice if it told you exactly which lines/branches :/
1245 2013-02-18 23:13:40 <Luke-Jr> gavinandresen: need gitian builds?
1246 2013-02-18 23:15:19 <BlueMatt> gavinandresen: wtf...it was working yesterday and I havent touched it...give me a minute
1247 2013-02-18 23:15:24 random_cat has quit (Remote host closed the connection)
1248 2013-02-18 23:15:53 <gavinandresen> BlueMatt: note that the pull that is wonky changed the way leveldb is built
1249 2013-02-18 23:16:43 <Luke-Jr> BlueMatt: it also fixed the bug you have workedaround in pulltester ;p
1250 2013-02-18 23:17:20 X-Scale has left ()
1251 2013-02-18 23:19:28 MobGod has joined
1252 2013-02-18 23:19:47 <EagleTM> is there any known memory leak introduced in the last two month? I used to run git head from 9th Dec without a hitch for two months, now running git head from 5th Feb lasted around 17 days before it crashed. weird thing is no specific crash message in the debug.log. I only have 8 connections and 4 GB of RAM in the box
1253 2013-02-18 23:19:47 CodeShark has joined
1254 2013-02-18 23:19:52 MobGod is now known as Guest62806
1255 2013-02-18 23:19:58 <jaakkos> can someone confirm that vanitygen addresses are safely generated?
1256 2013-02-18 23:20:09 <BlueMatt> gavinandresen: oh...the test script just isnt setting CC, so CC ?= ... must be broken?
1257 2013-02-18 23:20:14 <BlueMatt> gavinandresen: gitian works after that pull?
1258 2013-02-18 23:20:31 <sipa> jaakkos: depends who generates it and how
1259 2013-02-18 23:20:58 <sipa> if you do it yourself, obviously it's safe
1260 2013-02-18 23:21:11 <sipa> if not, you must be giving them a public key to combine the result with
1261 2013-02-18 23:21:14 <jaakkos> ...unless they wrote it stupidly
1262 2013-02-18 23:21:20 <sipa> for which they don't know the private key
1263 2013-02-18 23:21:22 <gavinandresen> BlueMatt: I'm 98% sure gitian works fine after that pull (tested manually in my gitian build environment), I'll be 100% sure in about half an hour
1264 2013-02-18 23:21:25 <jaakkos> eg. using predictable rng
1265 2013-02-18 23:21:42 Guest62806 is now known as Mobod
1266 2013-02-18 23:22:09 Mobod is now known as MobGod
1267 2013-02-18 23:22:18 MobGod has quit (Changing host)
1268 2013-02-18 23:22:18 MobGod has joined
1269 2013-02-18 23:22:25 <sipa> jaakkos: if they generate based on a public key you give them, it doesn't matter
1270 2013-02-18 23:22:25 <sipa> as long as they don't know your private key
1271 2013-02-18 23:23:39 <BlueMatt> gavinandresen: ping me when you're sure (and make sure the gitian build.log is calling make without a CXX flag as a result of MAKEOPTS
1272 2013-02-18 23:23:49 <BlueMatt> gavinandresen: I can tweak the test scripts if you're sure its pull-tester's fault
1273 2013-02-18 23:24:04 <jaakkos> sipa: i am not sure if i'm following
1274 2013-02-18 23:25:04 <gmaxwell> jaakkos: sipa is talking about the pooled vanity generation when he says 'if not' wrt doing it yourself.
1275 2013-02-18 23:25:05 <sipa> jaakkos: rule 1: do not import a private key someone else gives you, as they have access to the funds sent to it as well
1276 2013-02-18 23:25:36 <sipa> jaakkos: oh, yes, if you generate the vanity key completely yourself, and use a bad RNG, you're vulnerable
1277 2013-02-18 23:25:52 <jaakkos> haha, pooled key generation... people are doing that seriously?
1278 2013-02-18 23:25:52 <gmaxwell> There have been insecure vanity generators created in the past. "Vanitygen" is fineâ though all of them kinda stink because none will produce compressed keys. .. so your signatures with them are quite a bit bigger than otherwise.
1279 2013-02-18 23:25:59 <gmaxwell> jaakkos: sure, and its secure too.
1280 2013-02-18 23:26:18 <jaakkos> so how does it work without exposing the private key to the miners
1281 2013-02-18 23:26:32 root2_ has joined
1282 2013-02-18 23:27:18 etotheipi_ has joined
1283 2013-02-18 23:27:27 agricocb has quit (Quit: Leaving.)
1284 2013-02-18 23:27:33 <sipa> g++ -c -O2 -w -Wall -Wextra -Wformat -Wformat-security -Wno-unused-parameter -frandom-seed=bitcoin -D_MT -DWIN32 -D_WINDOWS -DBOOST_THR
1285 2013-02-18 23:27:33 <Luke-Jr> FWIW, v0.8.0.eligius1 (for poolservers) tagged based on v0.8.0 final
1286 2013-02-18 23:27:36 <sipa> EAD_USE_LIB -DBOOST_SPIRIT_THREADSAFE -DSTATICLIB -DUSE_UPNP=0 -DUSE_IPV6=1 -I"/home/ubuntu/build/bitcoin/src/leveldb/include" -I"/home
1287 2013-02-18 23:27:39 <sipa> /ubuntu/build/bitcoin/src/leveldb/helpers" -DHAVE_BUILD_INFO -I"/home/ubuntu/build/bitcoin/src" -I"/home/ubuntu/build/bitcoin/src"/obj
1288 2013-02-18 23:27:42 <sipa> -I"/home/ubuntu/build/boost_1_50_0" -I"/home/ubuntu/build/db-4.8.30.NC/build_unix" -I"/home/ubuntu/build/openssl-1.0.1c/include" -I"/ho
1289 2013-02-18 23:27:45 <sipa> me/ubuntu/build" -o obj/crypter.o crypter.cpp
1290 2013-02-18 23:27:47 <sipa> crypter.cpp:10:21: error: windows.h: No such file or directory
1291 2013-02-18 23:27:50 <sipa> sorry for spam
1292 2013-02-18 23:27:57 <jaakkos> ok, i just read it
1293 2013-02-18 23:28:07 <jaakkos> (re: vanitygen)
1294 2013-02-18 23:28:49 <sipa> gavinandresen: not sure if you were aware, but the windows build of 0.8.0 fails
1295 2013-02-18 23:29:09 <gavinandresen> frickin frackin...
1296 2013-02-18 23:30:04 <sipa> also, why does crypter.cpp need to include windows.h?
1297 2013-02-18 23:30:23 root2 has quit (Ping timeout: 256 seconds)
1298 2013-02-18 23:30:45 <gavinandresen> sipa: can you put the failing build.log somewhere? my gitian build is still building the linux64 binaries....
1299 2013-02-18 23:31:22 <gavinandresen> I'm going to untag v0.8.0
1300 2013-02-18 23:31:39 <BlueMatt> gavinandresen: same as pull-tester, you just need CXX=i586...
1301 2013-02-18 23:32:18 <sipa> gavinandresen: http://bitcoin.sipa.be/build-0.8.0.log
1302 2013-02-18 23:32:21 <dhill> sipa: ok, latest git running..
1303 2013-02-18 23:32:21 <gavinandresen> BlueMatt: ??? just need CXX=i586 where?
1304 2013-02-18 23:32:31 <gavinandresen> makefile.linux-mingw sets CXX
1305 2013-02-18 23:32:34 <BlueMatt> gavinandresen: on the make -f makefile.linux-mingw line
1306 2013-02-18 23:32:39 <BlueMatt> (untested but it looks like that)
1307 2013-02-18 23:32:48 <BlueMatt> it only does for qt, if im reading it right
1308 2013-02-18 23:32:59 <BlueMatt> or the CC ?= syntax is broken
1309 2013-02-18 23:33:27 <dhill> first thought.. leveldb seems way faster
1310 2013-02-18 23:34:08 <BlueMatt> not necessarily leveldb, it also does storage way differently
1311 2013-02-18 23:34:23 <sipa> well leveldb on itself is already a major speed improvement
1312 2013-02-18 23:34:42 <sipa> on a VPS with slow I/O, ultraprune on BDB was still painful
1313 2013-02-18 23:34:59 <BlueMatt> ahh, ok
1314 2013-02-18 23:36:19 <dhill> guess since bitcoind is running, i'll also run the UTs
1315 2013-02-18 23:36:25 <sipa> UTs ?
1316 2013-02-18 23:37:28 zooko has quit (Ping timeout: 244 seconds)
1317 2013-02-18 23:37:43 <dhill> unit tests
1318 2013-02-18 23:37:54 <dhill> test/
1319 2013-02-18 23:39:51 <HM> Unreal Tournament
1320 2013-02-18 23:40:20 <dhill> old school
1321 2013-02-18 23:41:40 <Luke-Jr> gavinandresen: btw, deleting a tag in git is very problematic - by default, git won't pull tags it already has, so everyone who pulled the old tag needs to delete it manually
1322 2013-02-18 23:41:59 <gavinandresen> sipa: can you on_target into your VM and see if the CXX environment variable is set? I can't see how the gitian build would break otherwise
1323 2013-02-18 23:42:17 <gavinandresen> Luke-Jr: yeah yeah, I assume the only people who pulled are here and know that.
1324 2013-02-18 23:42:43 * gavinandresen is extra grumpy today
1325 2013-02-18 23:43:27 <gavinandresen> sipa: never mind, my gitian build just caught up and is failing, too....
1326 2013-02-18 23:44:42 <Luke-Jr> I already started a gitian build setting CXX manually FWIW
1327 2013-02-18 23:46:55 RBecker is now known as rbecker
1328 2013-02-18 23:48:54 * gavinandresen learns Yet Another Obscure Fact about gnu make....
1329 2013-02-18 23:50:38 <gavinandresen> ok, so make implicitly defines CC and CXX, so ?= doesn't work for them, because make thinks they are already defined. So makefile.linux-mingw should, I think, just set them unconditionally. I think.
1330 2013-02-18 23:54:31 one_zero has joined
1331 2013-02-18 23:54:36 toffoo has joined
1332 2013-02-18 23:54:42 <Luke-Jr> gavinandresen: sounds right; commandline params will override even explicit assignments anyway
1333 2013-02-18 23:55:15 <Luke-Jr> I *think* env as well
1334 2013-02-18 23:55:44 JZavala has joined
1335 2013-02-18 23:56:42 i2pRelay has quit (Remote host closed the connection)
1336 2013-02-18 23:56:43 kytv has quit (Remote host closed the connection)
1337 2013-02-18 23:59:18 <dhill> sipa: with current git
1338 2013-02-18 23:59:20 <dhill> ./test_bitcoin
1339 2013-02-18 23:59:20 <dhill> Running 89 test cases...
1340 2013-02-18 23:59:20 <dhill> *** No errors detected
1341 2013-02-18 23:59:24 <dhill> \o/
1342 2013-02-18 23:59:54 JyZyXEL has quit (Quit: ZNC - http://znc.sourceforge.net)