1 2013-02-18 00:59:57 <Luke-Jr> #bitcoin-watch now running 0.8
2 2013-02-18 01:05:08 <BCB> Luke-Jr, what is your bot
3 2013-02-18 01:05:16 <Luke-Jr> BCB: Supybot?
4 2013-02-18 01:05:29 <BCB> what is it doing
5 2013-02-18 01:05:45 <Luke-Jr> #Bitcoin-Watch announces transactions and trades in realtime
6 2013-02-18 01:05:53 <Luke-Jr> 0.8 is still catching up on blocks tho
7 2013-02-18 01:06:11 <BCB> what is it broadcasting right now
8 2013-02-18 01:06:13 <BCB> blocks
9 2013-02-18 01:06:25 <Luke-Jr> I think it's 1-2 weeks behind now
10 2013-02-18 01:06:47 <BCB> it's posting all thes3 25 btc trades. very strange
11 2013-02-18 01:06:54 <Luke-Jr> they're blocks
12 2013-02-18 01:07:50 <BCB> ahh
13 2013-02-18 01:08:07 <BCB> is amt after the decimal fees
14 2013-02-18 01:08:17 <Luke-Jr> yes
15 2013-02-18 01:13:32 <K1773R> Luke-Jr: why isnt it being killed for flooding?
16 2013-02-18 01:14:11 <Luke-Jr> K1773R: because it's not flooding, according to freenode :P
17 2013-02-18 01:14:28 <Luke-Jr> that's also why it's takign so long to catch up :/
18 2013-02-18 01:15:27 <Luke-Jr> hmm, kinda surprising to see so many repeat block-payees
19 2013-02-18 01:15:49 <Luke-Jr> looks like some miners are quite capable at double-spending at 1-2 confirms
20 2013-02-18 02:37:38 <muhoo> wat?
21 2013-02-18 02:41:02 <cjd> \\o/
22 2013-02-18 03:16:58 <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.
23 2013-02-18 03:17:47 <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.
24 2013-02-18 03:18:14 <cjd> Based on the assumption that if you enable `-net cjdns` then you do not care about using the fc space for anything else
25 2013-02-18 03:18:41 <cjd> I originally thought the patch did just this but I'm not so sure given the reactions.
26 2013-02-18 04:14:39 <phantomcircuit> cjd, the patch as supplied is correct
27 2013-02-18 04:15:13 <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
28 2013-02-18 04:15:49 <phantomcircuit> iirc cjdns uses a smaller prefix than onioncat or i2p
29 2013-02-18 04:15:58 <cjd> it uses a /8
30 2013-02-18 04:16:24 <phantomcircuit> isn't that like
31 2013-02-18 04:16:29 <phantomcircuit> trillions of addresses?
32 2013-02-18 04:16:44 <cjd> enough that a collision is not likely
33 2013-02-18 04:16:56 <phantomcircuit> well anyways im just saying i think that's what sipa's comment was
34 2013-02-18 04:17:04 <phantomcircuit> i dont see any issues with the patch other than that
35 2013-02-18 04:17:17 <phantomcircuit> i doubt it would merge perfectly anymore but an updated patch would be trivial
36 2013-02-18 04:20:04 <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
37 2013-02-18 04:49:09 <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.
38 2013-02-18 04:49:55 <cjd> hmm but won't it consider fc addresses non-routable?
39 2013-02-18 04:50:10 <gmaxwell> It will connect to non-routable addresses if you explicitly tell it to.
40 2013-02-18 04:50:29 <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.
41 2013-02-18 04:50:31 <cjd> ideally it would share fc addresses with nodes behind other fc addresses
42 2013-02-18 04:50:49 <gmaxwell> Thats not how any of the bitcoin networking currently works.
43 2013-02-18 04:50:52 <cjd> indeed, it should not relay fc addresses to non-cjdns nodes
44 2013-02-18 04:51:01 <cjd> ok so non-trivial
45 2013-02-18 04:51:04 <cjd> that's unfortunate
46 2013-02-18 04:51:35 <cjd> thanks for the explanation
47 2013-02-18 04:51:36 <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)
48 2013-02-18 04:51:59 <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.
49 2013-02-18 04:52:41 <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
50 2013-02-18 04:52:55 <cjd> and vice versa
51 2013-02-18 04:53:44 <cjd> it poisons the address pool for them to be shared but it doesn't mean they can't be shared at all
52 2013-02-18 04:53:53 <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).
53 2013-02-18 04:54:41 <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
54 2013-02-18 04:54:54 <cjd> so they end up trying to connect to nodes which aren't there
55 2013-02-18 04:55:04 <cjd> but it doesn't actually fail, it just sucks
56 2013-02-18 04:55:55 <BTCTrader> ACTION now feels highly informed about this
57 2013-02-18 04:57:12 <gmaxwell> ugh. Why is 2112 such a blinking jerk.
58 2013-02-18 04:57:30 <cjd> o_O
59 2013-02-18 04:58:45 <gmaxwell> cjd: that was WRT context that isn't apparent from IRC.
60 2013-02-18 04:59:01 <cjd> ic
61 2013-02-18 04:59:29 <cjd> do nodes announce capabilities when they connect to other nodes?
62 2013-02-18 04:59:44 <cjd> I should know this but my memory is like that of a goldfish
63 2013-02-18 05:01:04 <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
64 2013-02-18 05:01:28 <gmaxwell> cjd: There are node flags which are part of the address announcements. As well as a protocol version sent on conncet.
65 2013-02-18 05:01:48 <gmaxwell> cjd: it would still have conflicting usage of the address space.
66 2013-02-18 05:02:16 <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...
67 2013-02-18 05:02:31 <gmaxwell> We need this in order to support I2P since its node identifiers can't be fit in v6.
68 2013-02-18 05:02:46 <cjd> interesting
69 2013-02-18 05:03:13 <BTCTrader> i2p support would also be very useful
70 2013-02-18 05:04:18 <BTCTrader> when is a possible roadmap for such a change? version 0.9 of bitcoin?
71 2013-02-18 05:04:47 <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..
72 2013-02-18 05:05:35 <cjd> so that's an approach, ofc it all depends on enough people being mutually interested in bitcoin and cjdns
73 2013-02-18 05:05:45 <gmaxwell> BTCTrader: not any time soon.
74 2013-02-18 05:06:40 <gmaxwell> cjd: I think that we're not really inclined to gobble up all the FC space for something less popular than tor. :(
75 2013-02-18 05:06:41 <BTCTrader> personally i compare cjdns to networks as bitcoin is to currencies
76 2013-02-18 05:06:54 <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
77 2013-02-18 05:07:46 <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.
78 2013-02-18 05:07:51 <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
79 2013-02-18 05:08:58 <cjd> and ofc if network ids were added later then the problem of collisions would be solved before it occured
80 2013-02-18 05:09:19 <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'.
81 2013-02-18 05:11:42 <BTCTrader> gotchya. that's freaking cool btw :D
82 2013-02-18 05:25:54 <cjd> https://github.com/bitcoin/bitcoin/pull/1498#issuecomment-13708066 <-- I kind of took minutes and stated my position
83 2013-02-18 05:26:55 <gmaxwell> cjd: thanks.
84 2013-02-18 05:27:27 <cjd> yeah, at least if someone else comes along, they'll know what the costs and benefits are
85 2013-02-18 05:28:50 <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.
86 2013-02-18 05:28:54 <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 :/
87 2013-02-18 05:29:45 <zooko> http://blog.freedomsponsors.org/freedomsponsors-is-now-accepting-bitcoins/
88 2013-02-18 05:30:02 <cjd> interesting thought, I'd like cjdns to just work like normal internet but without the nats if at all possible
89 2013-02-18 05:30:23 <cjd> although I suppose a protocol could be designed around making use of lag and packet loss =]
90 2013-02-18 05:30:36 <SomeoneWeird> cjd, "(changing this isn non-trivial)"
91 2013-02-18 05:31:18 <cjd> fixed, thanks
92 2013-02-18 05:32:08 <cjd> although people relying on lag and packet loss features are likely to be broken in future releases :)
93 2013-02-18 05:34:54 <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.
94 2013-02-18 05:36:19 <cjd> Interesting thought
95 2013-02-18 05:36:55 <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
96 2013-02-18 05:37:41 <cjd> in other news my main ipv6 access is tunneled over cjdns
97 2013-02-18 05:37:41 <SomeoneWeird> gmaxwell, that'd be cool
98 2013-02-18 05:37:48 <SomeoneWeird> speed up blockchain download a bit
99 2013-02-18 05:38:20 <cjd> my main ipv4 was tunneled over cjdns until my VPN endpoint went offline and I never inserted the default route again
100 2013-02-18 05:39:42 <gmaxwell> what VPN encap are you running over cjdns?
101 2013-02-18 05:40:25 <cjd> ipv6 is tunneled directly under the CryptoAuth headers which is under the switch header
102 2013-02-18 05:40:51 <cjd> if a node knows to expect a certain type of packet, it doesn't matter to the switches whct they forward
103 2013-02-18 05:40:57 <gmaxwell> ah, and then you're natting on the far side?
104 2013-02-18 05:41:06 <gmaxwell> or routing, I guess.. v6.. nevermind! :)
105 2013-02-18 05:41:10 <cjd> no, I just know someone with lots of addrs :)
106 2013-02-18 05:41:22 <cjd> he gave me 2 ipv4s
107 2013-02-18 05:41:49 <SomeoneWeird> they're not hard to get lol
108 2013-02-18 05:41:55 <phantomcircuit> cjd, i dont think the huge ip space gobble is a big issue
109 2013-02-18 05:42:20 <phantomcircuit> someone using fc will just end up with all the cjdns nodes timing out on him
110 2013-02-18 05:42:21 <phantomcircuit> that's it
111 2013-02-18 05:42:30 <cjd> phantomcircuit: I agree but it is big if like 2 people in the world want to run cjdns/bitcoin nodes
112 2013-02-18 05:42:53 <cjd> as per my comment in github
113 2013-02-18 05:44:31 <Luke-Jr> cjd: then 2 fc IPs timeout. big deal
114 2013-02-18 05:44:42 <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.
115 2013-02-18 05:44:47 <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
116 2013-02-18 05:45:57 <cjd> gmaxwell: good point, I think it's still valid to consider it but there should be a minimum popularity bar of entry
117 2013-02-18 05:46:13 <cjd> and if cjdns has not reached that point then we wait
118 2013-02-18 05:46:39 <phantomcircuit> gmaxwell, addr2 containing network flags?
119 2013-02-18 05:46:44 <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
120 2013-02-18 05:46:44 <gmaxwell> How has cjdns been going?
121 2013-02-18 05:46:48 <phantomcircuit> that's certainly a more permanent solution
122 2013-02-18 05:47:25 <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.
123 2013-02-18 05:47:40 <phantomcircuit> sorry what?
124 2013-02-18 05:48:29 <gmaxwell> there are some lame dos attacks that can happen because a malicious peer can feed you modified addr updates.
125 2013-02-18 05:48:39 <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.
126 2013-02-18 05:49:06 <cjd> which means stacked switch labels so we don't have a 64 bit horizon
127 2013-02-18 05:49:09 <Luke-Jr> cjd: multicast is a killer feature you could use to improve adoption too ;)
128 2013-02-18 05:49:17 <cjd> ;)
129 2013-02-18 05:49:45 <BTCTrader> funny
130 2013-02-18 05:50:30 <cjd> https://ezcrypt.it/SY5n#V7C5LWs7p1vUbFfd86tGhZ5S <-- this is what we're thinking about currently
131 2013-02-18 05:50:41 <cjd> it's got me pretty excited because it "looks" like it will scale
132 2013-02-18 05:51:11 <phantomcircuit> gmaxwell, i've actually tested that extensively
133 2013-02-18 05:51:41 <phantomcircuit> caddrman works exceptionally well
134 2013-02-18 05:52:51 <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)
135 2013-02-18 05:53:11 <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
136 2013-02-18 05:54:11 <cjd> someone did a check of "recent" ipv6 addrs in the network and got 300
137 2013-02-18 05:54:41 <phantomcircuit> gmaxwell, i can understand that
138 2013-02-18 05:54:42 <BTCTrader> https://www.cjdnscloud.com/ added 3 this week
139 2013-02-18 05:55:04 <cjd> And our first commercial cjdns enterprise! :D
140 2013-02-18 05:55:07 <phantomcircuit> actually a few days ago i accidentally launched about 1/10th of an enormous sybil attack
141 2013-02-18 05:55:13 <phantomcircuit> was interested that nobody noticed
142 2013-02-18 05:55:39 <phantomcircuit> (broken conditional statement)
143 2013-02-18 05:56:43 <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...
144 2013-02-18 05:57:29 <cjd> We're talking about switching to a bucket system so the amount of work done by each node is less
145 2013-02-18 05:57:40 <cjd> I liked the flat DHT but it's inefficient
146 2013-02-18 05:57:59 <phantomcircuit> BTCTrader, you run that?
147 2013-02-18 05:58:09 <BTCTrader> yes
148 2013-02-18 05:58:59 <zooko> I'm really happy to see bitcoin and cjdns people collaborating like this.
149 2013-02-18 05:59:08 <zooko> Not that I'm reading carefully enough to understand what you're saying...
150 2013-02-18 05:59:12 <gmaxwell> Does anyone offer VPSes that have only tor connectivity?
151 2013-02-18 05:59:15 <SomeoneWeird> oh
152 2013-02-18 05:59:17 <SomeoneWeird> BTCTrader,
153 2013-02-18 05:59:17 <SomeoneWeird> lol
154 2013-02-18 05:59:19 <SomeoneWeird> it's s1w
155 2013-02-18 05:59:30 <SomeoneWeird> HAI
156 2013-02-18 05:59:31 <SomeoneWeird> lol
157 2013-02-18 05:59:39 <BTCTrader> gmaxwell sortof yes. that made me think of this for a service...
158 2013-02-18 05:59:40 <phantomcircuit> gmaxwell, im not aware of any
159 2013-02-18 05:59:49 <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
160 2013-02-18 05:59:57 <phantomcircuit> there are some which offer NAT only service
161 2013-02-18 06:00:06 <BTCTrader> in combination of the pain asking for a peer on irc can be
162 2013-02-18 06:00:13 <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)
163 2013-02-18 06:00:18 <BTCTrader> torcloud
164 2013-02-18 06:00:27 <gmaxwell> (but I'm not interested in running one??? too many other projects)
165 2013-02-18 06:00:40 <BTCTrader> ditto
166 2013-02-18 06:01:10 <BTCTrader> i'm not thrilled to handle abuse complaints B-)
167 2013-02-18 06:01:18 <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
168 2013-02-18 06:01:27 <cjd> nice thing with cjdns vpsen is you can allocate ipv4 and ipv6 addrs to them via the tunneling code
169 2013-02-18 06:04:57 <gmaxwell> Luke-Jr: don't include IPv4 for the abuse handling reason?
170 2013-02-18 06:05:14 <Luke-Jr> gmaxwell: no, to encourage IPv6 mainly :p
171 2013-02-18 06:05:20 <Luke-Jr> and I only have so many IPv4 addresses
172 2013-02-18 06:08:22 <phantomcircuit> i haven't actually had that many issues with abuse
173 2013-02-18 06:10:07 <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.
174 2013-02-18 06:12:27 <phantomcircuit> im not sure
175 2013-02-18 06:12:33 <phantomcircuit> i was offering a ridiculously cheap
176 2013-02-18 06:12:36 <phantomcircuit> terrible service
177 2013-02-18 06:13:00 <phantomcircuit> and all i was getting were complaints from middle eastern universities complaining about port scanning
178 2013-02-18 06:13:05 <phantomcircuit> (which is totally bizarre)
179 2013-02-18 06:15:14 <SomeoneWeird> >.>
180 2013-02-18 06:15:15 <SomeoneWeird> <.<
181 2013-02-18 06:15:49 <Luke-Jr> lol
182 2013-02-18 06:15:56 <Luke-Jr> as if port scanning is a problem
183 2013-02-18 06:16:08 <Luke-Jr> I portscan my own servers to try to figure out what port I put ssh on
184 2013-02-18 06:16:57 <SomeoneWeird> haha
185 2013-02-18 07:47:20 <doublec> cjd: I'll rebase the cjdns patch so it's at least usable on recent bitcoin code
186 2013-02-18 07:47:50 <cjd> I think the consensus was that it will not be pulled because there is not enough interest
187 2013-02-18 07:48:33 <doublec> yeah but at least it'll be available for those that want to run nodes
188 2013-02-18 07:49:11 <cjd> that's up to you, thanks for your effort
189 2013-02-18 07:49:28 <Luke-Jr> no reason to keep it out of next-test either
190 2013-02-18 07:49:55 <doublec> at some point when all 300 cjdns nodes are running a bitcoind it might be compelling enough to reconsider ;)
191 2013-02-18 07:50:02 <Luke-Jr> lol
192 2013-02-18 07:50:44 <cjd> given some of them are rasberryPi and even smaller, I don't think that'll happen too soon ;)
193 2013-02-18 07:50:47 <doublec> I used to have cjdns entrypoint for my pool but it's populatirty was limited
194 2013-02-18 07:51:00 <cjd> yeah
195 2013-02-18 07:51:53 <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.
196 2013-02-18 07:52:08 <gmaxwell> That said, assuming you have enough storage??? bitcoin apparently keeps up on it.
197 2013-02-18 07:52:19 <doublec> does cjdns run on android? Might be fun to run it on a firefox phone.
198 2013-02-18 07:53:11 <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.
199 2013-02-18 10:43:23 <Goonie> will there be a rc2 before 0.8 final?
200 2013-02-18 10:54:08 <JWU42> just wanted to advise 0.8 running well and mined first block with it last night
201 2013-02-18 10:54:29 <JWU42> been running it for over 10 days now and no issues
202 2013-02-18 10:54:42 <JWU42> though mem usage is tad higher than 0.7.2
203 2013-02-18 11:15:51 <jgarzik> Goonie: sounds like "probably no rc2"
204 2013-02-18 12:58:29 <fdsagew> Official ???itcoin shop http://www.silkroadtor.com 1 ???itcoin=$17.77
205 2013-02-18 12:58:30 <fdsagew> 15 ???itcoin + Free extra 2 ???itcoin=$186.66 http://www.silkroadtor.com
206 2013-02-18 12:58:30 <fdsagew> 2 ???itcoin=$36.66
207 2013-02-18 12:58:30 <fdsagew> 3 ???itcoin=$53.99 http://www.silkroadtor.com
208 2013-02-18 12:58:30 <fdsagew> 4 ???itcoin=$69.99
209 2013-02-18 12:58:30 <fdsagew> 5 ???itcoin=$85.55
210 2013-02-18 12:58:30 <fdsagew> 9 ???itcoin + Free extra 1 ???itcoin=$130.99
211 2013-02-18 12:58:31 <fdsagew> 20 ???itcoin + Free extra 4 ???itcoin=$228.88
212 2013-02-18 12:58:31 <fdsagew> 30 ???itcoin + Free extra 6 ???itcoin=$323.33
213 2013-02-18 12:58:32 <fdsagew> http://www.silkroadtor.com
214 2013-02-18 12:58:33 <fdsagew> 2 ???itcoin=$36.66
215 2013-02-18 12:58:33 <fdsagew> Official ???itcoin shop http://www.silkroadtor.com 1 ???itcoin=$17.77
216 2013-02-18 12:58:34 <fdsagew> 3 ???itcoin=$53.99 http://www.silkroadtor.com
217 2013-02-18 12:58:44 <fdsagew> 3 ???itcoin=$53.99 http://www.silkroadtor.com
218 2013-02-18 12:58:45 <fdsagew> 4 ???itcoin=$69.99
219 2013-02-18 12:58:46 <fdsagew> 5 ???itcoin=$85.55
220 2013-02-18 12:58:47 <fdsagew> 9 ???itcoin + Free extra 1 ???itcoin=$130.99
221 2013-02-18 12:58:48 <fdsagew> 15 ???itcoin + Free extra 2 ???itcoin=$186.66 http://www.silkroadtor.com
222 2013-02-18 12:58:49 <fdsagew> 20 ???itcoin + Free extra 4 ???itcoin=$228.88
223 2013-02-18 12:58:50 <fdsagew> 30 ???itcoin + Free extra 6 ???itcoin=$323.33
224 2013-02-18 12:58:51 <fdsagew> http://www.silkroadtor.com
225 2013-02-18 12:58:52 <fdsagew> http://www.silkroadtor.com
226 2013-02-18 12:58:53 <fdsagew> Official ???itcoin shop http://www.silkroadtor.com 1 ???itcoin=$17.77
227 2013-02-18 12:58:55 <fdsagew> 2 ???itcoin=$36.66
228 2013-02-18 12:58:56 <fdsagew> 3 ???itcoin=$53.99 http://www.silkroadtor.com
229 2013-02-18 12:58:57 <fdsagew> 4 ???itcoin=$69.99
230 2013-02-18 12:58:58 <fdsagew> 5 ???itcoin=$85.55
231 2013-02-18 12:58:59 <fdsagew> 9 ???itcoin + Free extra 1 ???itcoin=$130.99
232 2013-02-18 12:59:00 <fdsagew> 15 ???itcoin + Free extra 2 ???itcoin=$186.66 http://www.silkroadtor.com
233 2013-02-18 12:59:01 <fdsagew> 20 ???itcoin + Free extra 4 ???itcoin=$228.88
234 2013-02-18 12:59:02 <fdsagew> 30 ???itcoin + Free extra 6 ???itcoin=$323.33
235 2013-02-18 12:59:03 <fdsagew> http://www.silkroadtor.com
236 2013-02-18 12:59:04 <fdsagew> http://www.silkroadtor.com
237 2013-02-18 12:59:05 <fdsagew> Official ???itcoin shop http://www.silkroadtor.com 1 ???itcoin=$17.77
238 2013-02-18 12:59:06 <fdsagew> 2 ???itcoin=$36.66
239 2013-02-18 12:59:07 <fdsagew> 3 ???itcoin=$53.99 http://www.silkroadtor.com
240 2013-02-18 12:59:08 <fdsagew> 4 ???itcoin=$69.99
241 2013-02-18 12:59:09 <fdsagew> 5 ???itcoin=$85.55
242 2013-02-18 12:59:35 <Prattler> nooo, he was saying something valuable to everyone :D
243 2013-02-18 13:01:24 <SomeoneWeird> damni
244 2013-02-18 13:12:15 <fdsagew> Official ???itcoin shop http://www.silkroadtor.com 1 ???itcoin=$17.77
245 2013-02-18 13:12:16 <fdsagew> 2 ???itcoin=$36.66
246 2013-02-18 13:12:16 <fdsagew> 3 ???itcoin=$53.99 http://www.silkroadtor.com
247 2013-02-18 13:12:22 <fdsagew> 2 ???itcoin=$36.66
248 2013-02-18 13:12:22 <fdsagew> Official ???itcoin shop http://www.silkroadtor.com 1 ???itcoin=$17.77
249 2013-02-18 13:12:23 <fdsagew> 2 ???itcoin=$36.66
250 2013-02-18 13:12:23 <fdsagew> 3 ???itcoin=$53.99 http://www.silkroadtor.com
251 2013-02-18 13:12:23 <fdsagew> 4 ???itcoin=$69.99
252 2013-02-18 13:12:23 <fdsagew> Official ???itcoin shop http://www.silkroadtor.com 1 ???itcoin=$17.77
253 2013-02-18 13:12:24 <fdsagew> 5 ???itcoin=$85.55
254 2013-02-18 13:12:24 <fdsagew> 9 ???itcoin + Free extra 1 ???itcoin=$130.99
255 2013-02-18 13:12:25 <fdsagew> 15 ???itcoin + Free extra 2 ???itcoin=$186.66 http://www.silkroadtor.com
256 2013-02-18 13:12:25 <fdsagew> 20 ???itcoin + Free extra 4 ???itcoin=$228.88
257 2013-02-18 13:12:26 <fdsagew> 30 ???itcoin + Free extra 6 ???itcoin=$323.33
258 2013-02-18 13:12:26 <fdsagew> http://www.silkroadtor.com
259 2013-02-18 13:12:27 <fdsagew> http://www.silkroadtor.com
260 2013-02-18 13:12:37 <fdsagew> Official ???itcoin shop http://www.silkroadtor.com 1 ???itcoin=$17.77
261 2013-02-18 13:12:38 <fdsagew> 2 ???itcoin=$36.66
262 2013-02-18 13:12:39 <fdsagew> 3 ???itcoin=$53.99 http://www.silkroadtor.com
263 2013-02-18 13:12:40 <fdsagew> 4 ???itcoin=$69.99
264 2013-02-18 13:12:41 <fdsagew> 5 ???itcoin=$85.55
265 2013-02-18 13:12:42 <fdsagew> 9 ???itcoin + Free extra 1 ???itcoin=$130.99
266 2013-02-18 13:12:43 <fdsagew> 15 ???itcoin + Free extra 2 ???itcoin=$186.66 http://www.silkroadtor.com
267 2013-02-18 13:12:44 <fdsagew> 20 ???itcoin + Free extra 4 ???itcoin=$228.88
268 2013-02-18 13:12:45 <fdsagew> 30 ???itcoin + Free extra 6 ???itcoin=$323.33
269 2013-02-18 13:12:47 <fdsagew> http://www.silkroadtor.com
270 2013-02-18 13:12:49 <fdsagew> Official ???itcoin shop http://www.silkroadtor.com 1 ???itcoin=$17.77
271 2013-02-18 13:12:50 <fdsagew> 2 ???itcoin=$36.66
272 2013-02-18 13:12:51 <fdsagew> 3 ???itcoin=$53.99 http://www.silkroadtor.com
273 2013-02-18 13:12:52 <fdsagew> 4 ???itcoin=$69.99
274 2013-02-18 13:12:53 <fdsagew> 5 ???itcoin=$85.55
275 2013-02-18 13:12:54 <fdsagew> 9 ???itcoin + Free extra 1 ???itcoin=$130.99
276 2013-02-18 13:12:55 <fdsagew> 15 ???itcoin + Free extra 2 ???itcoin=$186.66 http://www.silkroadtor.com
277 2013-02-18 13:12:56 <fdsagew> 20 ???itcoin + Free extra 4 ???itcoin=$228.88
278 2013-02-18 13:12:57 <fdsagew> 30 ???itcoin + Free extra 6 ???itcoin=$323.33
279 2013-02-18 13:12:58 <fdsagew> http://www.silkroadtor.com
280 2013-02-18 13:12:59 <fdsagew> http://www.silkroadtor.com
281 2013-02-18 13:13:00 <fdsagew> Official ???itcoin shop http://www.silkroadtor.com 1 ???itcoin=$17.77
282 2013-02-18 13:13:01 <fdsagew> 2 ???itcoin=$36.66
283 2013-02-18 13:13:02 <fdsagew> 3 ???itcoin=$53.99 http://www.silkroadtor.com
284 2013-02-18 13:13:03 <fdsagew> 4 ???itcoin=$69.99
285 2013-02-18 13:13:04 <fdsagew> 5 ???itcoin=$85.55
286 2013-02-18 13:13:05 <fdsagew> 9 ???itcoin + Free extra 1 ???itcoin=$130.99
287 2013-02-18 13:13:06 <fdsagew> 15 ???itcoin + Free extra 2 ???itcoin=$186.66 http://www.silkroadtor.com
288 2013-02-18 13:13:07 <fdsagew> 20 ???itcoin + Free extra 4 ???itcoin=$228.88
289 2013-02-18 13:13:12 <ThomasV> jgarzik, SomeoneWeird, gmaxwell : spam attack
290 2013-02-18 13:13:25 <SomeoneWeird> ffs
291 2013-02-18 13:13:28 <ThomasV> oh, ok :)
292 2013-02-18 13:14:49 <jgarzik> yah, ongoing in #bitcoin too :(
293 2013-02-18 13:25:00 <kinlo> perhaps a few more ops might help
294 2013-02-18 13:25:20 <TD> good day
295 2013-02-18 13:25:39 <MC1984> im suprised #bitcoin has lasted this long without 24/7 spam tbh
296 2013-02-18 13:26:17 <MC1984> i wonder if the mainstream-ness of a technology is proportional to the amount of spam shit on it
297 2013-02-18 13:26:19 <MC1984> like email
298 2013-02-18 13:31:52 <jgarzik> yeah, the Internet was never the same after those damned AOL users found Usenet
299 2013-02-18 13:32:23 <upb> lol
300 2013-02-18 13:34:38 <SomeoneWeird> heh
301 2013-02-18 13:39:50 <epscy> aol keywords were such a good idea
302 2013-02-18 13:39:53 <epscy> j/k
303 2013-02-18 13:56:45 <MC1984> i got the olduse.net thing in a nntp reader right now
304 2013-02-18 13:56:48 <MC1984> pretty cool
305 2013-02-18 13:58:55 <MC1984> its curently 18 feb 1983
306 2013-02-18 14:02:41 <BlueMatt> gmaxwell: baseline coverage? as in a link to the coverage result of not being run (ie 0%?)
307 2013-02-18 14:02:47 <BlueMatt> what am I missing?
308 2013-02-18 14:02:59 <TD> good morning matt
309 2013-02-18 14:03:21 <TD> BlueMatt: i was wondering if you're after any more tasks to do on bitcoinj :)
310 2013-02-18 14:04:07 <BlueMatt> TD: yea, Id like to work more on the download algorithms to do upgrading
311 2013-02-18 14:04:20 <BlueMatt> and probably expose the fact that you are a full node to the p2p network
312 2013-02-18 14:04:45 <BlueMatt> though, sadly, other projects have come up too
313 2013-02-18 14:05:07 <BlueMatt> TD: is there anything in particular you want?
314 2013-02-18 14:05:11 <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
315 2013-02-18 14:05:23 <TD> not to mention that disk usage is not O(1)
316 2013-02-18 14:05:39 <BlueMatt> ahh, yes, I could look into that eventually too
317 2013-02-18 14:06:06 <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
318 2013-02-18 14:06:26 <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
319 2013-02-18 14:06:45 <BlueMatt> yes, but we should still have an upgrade path for those who want to do that
320 2013-02-18 14:07:06 <BlueMatt> tor makes it easy "just check this button in vidalia/mark these config options" and you are running an exit node/etc
321 2013-02-18 14:07:34 <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
322 2013-02-18 14:07:48 <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...
323 2013-02-18 14:08:09 <TD> i don't think full nodes will be running even on laptops/consumer desktops, in the medium term.
324 2013-02-18 14:08:17 <BlueMatt> well full node network diversity is also important
325 2013-02-18 14:08:23 <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?
326 2013-02-18 14:08:33 <TD> the instability from people turning them on/off is probably a net negative for the network
327 2013-02-18 14:09:16 <BlueMatt> meh, I dont think rollover is a big deal (not ideal, obv, but not that hard to deal with)
328 2013-02-18 14:09:46 <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
329 2013-02-18 14:10:00 <BlueMatt> the bitcoinj side could be better optimized (mostly sigchecking) but its not that unreasonable
330 2013-02-18 14:10:16 <TD> i think it's still pretty expensive. people are complaining about running full nodes even on VPS systems.
331 2013-02-18 14:10:47 <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
332 2013-02-18 14:10:53 <TD> which means it'll take longer to get connected to the p2p network
333 2013-02-18 14:10:56 <BlueMatt> meh, vps's are way less powerful than a reasonably powerful desktop/laptop
334 2013-02-18 14:11:24 <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
335 2013-02-18 14:11:39 <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
336 2013-02-18 14:12:07 <BlueMatt> I wouldnt call bitcoin an intensive p2p app after initial sync
337 2013-02-18 14:12:16 <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
338 2013-02-18 14:12:39 <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
339 2013-02-18 14:12:53 <TD> and we hope load will increase, right?
340 2013-02-18 14:13:28 <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
341 2013-02-18 14:13:48 <TD> if bitcoin stalls and never goes much beyond its current traffic levels, sure
342 2013-02-18 14:14:01 <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...
343 2013-02-18 14:14:33 <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
344 2013-02-18 14:14:43 <BlueMatt> in either case, Id really like to see some full node diversity
345 2013-02-18 14:14:50 <TD> yeah that's my plan, just try 50-100 IPs simultaneously and hope at least 5 or 10 connect, then drop the rest
346 2013-02-18 14:14:55 <BlueMatt> having one implementation that is used everywhere is pretty ugly...
347 2013-02-18 14:15:19 <BlueMatt> but yes, I agree that it will likely not be run on laptops of everyone eventually
348 2013-02-18 14:15:35 <BlueMatt> but I still think its important that such an option is available to everyone
349 2013-02-18 14:15:55 <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
350 2013-02-18 14:16:10 <TD> they can run a full node without moving their wallet.
351 2013-02-18 14:16:19 <BlueMatt> yes, but its not ideal
352 2013-02-18 14:16:30 <BlueMatt> Id usually just say "meh" if I have to download another app
353 2013-02-18 14:16:40 <BlueMatt> if I can just check a box, I may be more inclined to do so
354 2013-02-18 14:16:56 <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
355 2013-02-18 14:17:21 <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.
356 2013-02-18 14:19:03 <MC1984> if the block cap stays, it wont be long before node running is trivial
357 2013-02-18 14:19:13 <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
358 2013-02-18 14:19:17 <MC1984> be doing it on my phone in 5 years
359 2013-02-18 14:19:46 <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
360 2013-02-18 14:20:07 <TD> MC1984: but if it is lifted, you won't. so don't bet on that.
361 2013-02-18 14:20:20 <MC1984> i dont think it will ever be lifted
362 2013-02-18 14:20:30 <MC1984> raised but not lifted
363 2013-02-18 14:21:00 <TD> we'll see.
364 2013-02-18 14:21:28 <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
365 2013-02-18 14:21:40 <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
366 2013-02-18 14:21:54 <MC1984> without a block cap, there are no fees
367 2013-02-18 14:23:44 <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
368 2013-02-18 14:23:46 <helo> yay, this
369 2013-02-18 14:23:46 <TD> let alone do them automatically
370 2013-02-18 14:23:55 <TD> MC1984: that is not a valid assumption
371 2013-02-18 14:24:15 <MC1984> ?
372 2013-02-18 14:24:34 <helo> zero trust or bust
373 2013-02-18 14:24:44 <MC1984> ^
374 2013-02-18 14:24:45 <TD> MC1984: that without a block cap there are no fees. there are several alternative models that have no caps and fees
375 2013-02-18 14:24:46 <MC1984> hehe
376 2013-02-18 14:25:14 <MC1984> TD like what?
377 2013-02-18 14:25:22 <helo> if it's not easily zero trust for most users, then it's back to trusting centralized financial institutions
378 2013-02-18 14:25:31 <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)
379 2013-02-18 14:25:59 <BlueMatt> TD: and I really feel strongly about full node diversity
380 2013-02-18 14:26:25 <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
381 2013-02-18 14:26:32 <BlueMatt> TD: which is just plain brokwn
382 2013-02-18 14:26:33 <BlueMatt> en
383 2013-02-18 14:26:58 <MC1984> 10?
384 2013-02-18 14:27:11 <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
385 2013-02-18 14:27:12 <BlueMatt> ok, probably like 5
386 2013-02-18 14:27:20 <BlueMatt> but I know we have quite a few
387 2013-02-18 14:27:22 <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
388 2013-02-18 14:27:23 <TD> the trick is managing the switch at the app level
389 2013-02-18 14:27:51 <TD> and then allowing listening, which requires a lot more work (there's no anti-DoS code currently, things like that)
390 2013-02-18 14:28:03 <BlueMatt> TD: even the app level isnt all that hard... https://code.google.com/r/bluemattme-bitcoinj/source/list?name=headersfirstsync
391 2013-02-18 14:28:10 <TD> MC1984: some were discussed on the forum. network assurance contracts is one example.
392 2013-02-18 14:28:17 <TD> BlueMatt: sure
393 2013-02-18 14:28:22 <BlueMatt> yea, listening/exposing the full node layer to p2p is the hard part, really
394 2013-02-18 14:28:40 <MC1984> link?
395 2013-02-18 14:28:45 <TD> kinlo: I think for refunds we decided to let the user submit their own preferred outputs?
396 2013-02-18 14:29:14 <kinlo> TD: yes, but I'm requesting to let the user sign that request somehow
397 2013-02-18 14:29:25 <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.
398 2013-02-18 14:29:27 <TD> kinlo: sign it with what?
399 2013-02-18 14:30:04 <MC1984> sounds sort of awkward
400 2013-02-18 14:30:26 <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
401 2013-02-18 14:30:44 <kinlo> now the request the merchant sends to the enduser is signed with x509 as proposed
402 2013-02-18 14:31:11 <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)
403 2013-02-18 14:31:15 <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.
404 2013-02-18 14:31:34 <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...
405 2013-02-18 14:31:55 <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
406 2013-02-18 14:31:56 <MC1984> i will have to read on this further
407 2013-02-18 14:32:27 <gavinandresen> TD: as I implement payment requests??? I'm thinking it was dumb to separate PaymentRequest/SignedPaymentRequest.
408 2013-02-18 14:32:28 <TD> kinlo: i suppose a signature using a key from the first scriptSig could work yes.
409 2013-02-18 14:33:03 <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.
410 2013-02-18 14:33:19 <TD> which is why we arrived at the solution of a wrapper message.
411 2013-02-18 14:33:20 <gavinandresen> ??? but we're not signing a binary blob anymore, anyway
412 2013-02-18 14:33:24 <kinlo> gavinandresen: that's your call ofcourse, but I'd recommend implementing it asap so it only needs to be implemented once...
413 2013-02-18 14:33:25 <TD> we're not?
414 2013-02-18 14:33:44 <gavinandresen> lemme double-check the gist....
415 2013-02-18 14:34:03 <kinlo> gavinandresen: I also have a different use case for signing it, so I could use it :)
416 2013-02-18 14:34:05 <TD> gavinandresen: if i recall the code correctly, what we sign is the hash of the "bytes" field containing a serialized PaymentRequest
417 2013-02-18 14:34:30 <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."
418 2013-02-18 14:34:32 <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
419 2013-02-18 14:34:47 <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 :)
420 2013-02-18 14:34:55 <gavinandresen> TD: ??? because it is important to sign everything except the signature itself
421 2013-02-18 14:35:13 <TD> gavinandresen: let me check
422 2013-02-18 14:35:25 <kinlo> TD: it does, but it isn't signed in any way so it cannot be proven to remain unaltered by the merchant
423 2013-02-18 14:35:35 <TD> gavinandresen: the only data in SignedPaymentRequest is the signature, more or less.
424 2013-02-18 14:35:41 <TD> oh, and the cert
425 2013-02-18 14:35:51 <TD> i don't think you need the signature to sign the certificates, do you, as they're already signed up to the root
426 2013-02-18 14:35:54 <gavinandresen> TD: and pki_type
427 2013-02-18 14:36:10 <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.
428 2013-02-18 14:36:40 <gavinandresen> TD: the point is not to open up any possible chinks in the armor...
429 2013-02-18 14:36:59 <TD> the problem with signing a re-serialized protocol buffer is that you can't sign any new fields added after v1
430 2013-02-18 14:37:17 <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.
431 2013-02-18 14:37:42 <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.
432 2013-02-18 14:37:46 <TD> so signing the raw bytes was safer.
433 2013-02-18 14:38:37 <TD> the payment request version field could probably be moved into the PaymentRequest message
434 2013-02-18 14:39:01 <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
435 2013-02-18 14:40:14 <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?
436 2013-02-18 14:41:27 <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.
437 2013-02-18 14:41:40 <TD> i think it's OK to have a version number that makes old clients print a "Please upgrade your wallet app" message.
438 2013-02-18 14:41:59 <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.
439 2013-02-18 14:42:30 <gavinandresen> I'll spend some time thinking through the upgrade scenarios. I'm not convinced (yet) that we need separate messages for Payment/SignedPayment
440 2013-02-18 14:42:37 <TD> how about renaming PaymentRequest to PaymentRequestInternal and SignedPaymentRequest to just PaymentRequest
441 2013-02-18 14:42:53 <TD> well, it's just a workaround for issues with protobufs. namely that people like to reimplement them in incomplete ways :)
442 2013-02-18 14:43:13 <gavinandresen> I don't have a problem with signatures failing if your protobuf implementation sucks.
443 2013-02-18 14:43:33 <gavinandresen> ??? that's a "fail safe" failure
444 2013-02-18 14:43:35 <TD> you will once somebody (trezor?) ships a popular device that recognizes todays payment requests and then fails the next versions.
445 2013-02-18 14:43:48 <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.
446 2013-02-18 14:44:01 <TD> i really don't think this is a big deal. almost all interesting data is/will be in the PaymentRequest part.
447 2013-02-18 14:44:50 <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?
448 2013-02-18 14:45:20 <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.
449 2013-02-18 14:45:56 <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.
450 2013-02-18 14:46:41 <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.
451 2013-02-18 14:46:44 <TD> version is still 1
452 2013-02-18 14:47:02 <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.
453 2013-02-18 14:47:30 <TD> then edit the raw binary? why is this simpler than just having a wrapper message?
454 2013-02-18 14:48:38 <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
455 2013-02-18 14:48:53 <gavinandresen> (signature version should be first in sequence, perhaps)
456 2013-02-18 14:49:33 <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
457 2013-02-18 14:50:07 <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.
458 2013-02-18 14:50:29 <TD> i think the current design works ok: required bytes serialized_payment_request = 4;
459 2013-02-18 14:50:36 <TD> hash that. check the signature. done. can't mess it up.
460 2013-02-18 14:50:55 <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.
461 2013-02-18 14:51:13 <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.
462 2013-02-18 14:51:20 <gavinandresen> exactly
463 2013-02-18 14:51:41 <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
464 2013-02-18 14:51:47 <TD> there are almost always backwards compatible ways to do things.
465 2013-02-18 14:52:09 <TD> if calculating the signature hash depends on details of peoples protobuf libraries though, it opens up new scope for errors
466 2013-02-18 14:52:41 <gavinandresen> msg.load() will throw out any new fields that the implementation doesn't understand, right?
467 2013-02-18 14:53:25 <lianj> yes, dont make signature hash worse the currently
468 2013-02-18 14:53:36 <lianj> s/the/than
469 2013-02-18 14:54:00 <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
470 2013-02-18 14:54:20 <gavinandresen> If we bump signature version then we don't want that dumb code to be backwards compatible.
471 2013-02-18 14:54:47 <TD> it actually won't, on the C++/Java implementations from Google. but it may change the ordering of unknown field.s
472 2013-02-18 14:55:09 <TD> however i bet some implementations in ruby or haskell or whatever will throw them away
473 2013-02-18 14:55:30 <jouke> TD: when confidence type is not building, will the transaction be removed from memory? (Custom program that uses BitcoinJ)
474 2013-02-18 14:55:32 <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.
475 2013-02-18 14:55:51 <TD> gavinandresen: then the hash won't match. that's the concern.
476 2013-02-18 14:55:57 <TD> gavinandresen: what's the big advantage of a single message?
477 2013-02-18 14:55:59 <gavinandresen> TD: that's my point, the data signed by the merchant would not include the new fields, if signature.version==1
478 2013-02-18 14:56:15 <TD> Jouke: hmm? it'll be garbage collected when there are no more references to it beyond the MemoryPool.
479 2013-02-18 14:56:33 <TD> gavinandresen: why would you want that? the merchant would always want to sign everything, there's no downside to doing so.
480 2013-02-18 14:57:00 <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)
481 2013-02-18 14:57:35 <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.
482 2013-02-18 14:57:52 <TD> ACTION doesn't really get the motivation for all this - the versioning and signing scheme previously agreed works fine for all use cases
483 2013-02-18 14:58:04 <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.....
484 2013-02-18 14:58:45 <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)
485 2013-02-18 14:59:05 <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.
486 2013-02-18 14:59:40 <TD> (it probably should be in the PaymentRequest message really)
487 2013-02-18 14:59:47 <TD> that's a simple change though
488 2013-02-18 15:00:33 <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
489 2013-02-18 15:01:21 <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
490 2013-02-18 15:01:33 <TD> even a web of trust model would have some data there signed by ?????? someone
491 2013-02-18 15:02:02 <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.
492 2013-02-18 15:02:34 <TD> older software would just treat such requests as unsigned. newer apps that require you to sign your own PKI data could implement that.
493 2013-02-18 15:02:38 <TD> but it'd be odd.
494 2013-02-18 15:06:22 <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
495 2013-02-18 15:06:56 <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
496 2013-02-18 15:07:00 <gavinandresen> PaymentRequest --> PaymentRequestData, and SignedPaymentRequest --> PaymentRequest. With pki_data and signature optional.
497 2013-02-18 15:07:19 <gavinandresen> GMP: no, not send over the p2p network.
498 2013-02-18 15:07:22 <TD> sure
499 2013-02-18 15:07:34 <TD> GMP: directly from receiver to sender. eg via http or some other mechanism.
500 2013-02-18 15:07:40 <TD> gavinandresen: sure
501 2013-02-18 15:07:47 <TD> gavinandresen: or PaymentRequest -> PaymentDetails ?
502 2013-02-18 15:08:05 <gavinandresen> PaymentDetails: ACK.
503 2013-02-18 15:08:23 <TD> btw looks like i'll be announcing bitcoinj 0.7 in parallel with bitcoin 0.8
504 2013-02-18 15:08:37 <TD> so the timing on that is quite spiffy
505 2013-02-18 15:08:41 <gavinandresen> nice
506 2013-02-18 15:10:35 <TD> i assume it'll be out in the next day or so?
507 2013-02-18 15:11:08 <MC1984> is bitcoin wallet going to have the experimental full node stuff
508 2013-02-18 15:11:12 <MC1984> you know, for lols
509 2013-02-18 15:14:51 <gavinandresen> TD: yes, one nagging issue I want to understand better and then I'll tag 0.8 final
510 2013-02-18 15:14:51 <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
511 2013-02-18 15:14:51 <MC1984> oh well
512 2013-02-18 15:14:51 <TD> MC1984: that would be a no :)
513 2013-02-18 15:15:22 <TD> :)
514 2013-02-18 15:15:49 <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
515 2013-02-18 15:15:53 <TD> if you're _really_ keen
516 2013-02-18 15:16:45 <sipa> gavinandresen: did you figure out the leveldb assert failure?
517 2013-02-18 15:17:18 <gavinandresen> sipa: not yet. It is completely reproducible for me, compling with clang -g
518 2013-02-18 15:18:11 <sipa> gavinandresen: the only thing I see is an error in bitcoin, saying that the difficulty of block 1 is out of range
519 2013-02-18 15:19:36 <gavinandresen> sipa: any idea what the leveldb VersionSet class does?
520 2013-02-18 15:19:48 <sipa> no
521 2013-02-18 15:20:02 <sipa> i can have a look tonight
522 2013-02-18 15:20:11 <sipa> but how did you create that datadir?
523 2013-02-18 15:20:12 <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.
524 2013-02-18 15:21:00 <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
525 2013-02-18 15:21:18 <gavinandresen> I have no idea which bytes it corrupted, or how many....
526 2013-02-18 15:22:00 <TD> there's a unit test that does random corruption too
527 2013-02-18 15:22:11 <TD> I think VersionSet is to do with the details of how it stores data internally
528 2013-02-18 15:23:30 <sipa> i find it strange that you get an assert failure, and i don't
529 2013-02-18 15:23:57 <gavinandresen> yes, I find that strange and troubling, too. I'm compiling with clang++ and -g
530 2013-02-18 15:25:02 <gavinandresen> sipa: hmm, I'm also compiling with the patch that passes CXXFLAGS down into the leveldb build
531 2013-02-18 15:27:22 <gavinandresen> sipa: is your leveldb compiled -DNDEBUG ?
532 2013-02-18 15:28:29 <sipa> perhaps, can't check now
533 2013-02-18 15:29:50 <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
534 2013-02-18 15:30:09 <gavinandresen> ACTION will wait until sipa gets home tonight
535 2013-02-18 15:34:23 <TD> does ruby gems not do dependency resolution or something>?
536 2013-02-18 15:34:39 <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
537 2013-02-18 15:35:05 <TD> gavinandresen: would you accept a pull to move the FAQ as-is from wiki to website?
538 2013-02-18 15:36:52 <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?
539 2013-02-18 15:37:03 <TD> sure. i got a long list of things i want to do.
540 2013-02-18 15:37:10 <TD> the empty News page is an embarrassment, for instance
541 2013-02-18 16:03:38 <TD> gavinandresen: do you know why the wiki is still locked down so i can't edit anything?
542 2013-02-18 16:05:44 <sipa> TD: apparently spam protection reasons or something
543 2013-02-18 16:05:45 <gavinandresen> TD: logout and log back in-- and you'll be asked to send a token amount of BTC
544 2013-02-18 16:05:49 <sipa> ah
545 2013-02-18 16:05:52 <gavinandresen> ??? yes, for spam protection
546 2013-02-18 16:06:09 <TD> i see
547 2013-02-18 16:07:01 <TD> neat. i guess.
548 2013-02-18 16:07:04 <TD> though 1 bitcent is quite expensive.
549 2013-02-18 16:07:36 <gavinandresen> apply for a Foundation grant to cover it....
550 2013-02-18 16:07:42 <gavinandresen> (d'oh! deadline passed...)
551 2013-02-18 16:14:06 <gmaxwell> better if you get someone with mtgox btc to pay it??? zero confirms.
552 2013-02-18 16:15:12 <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
553 2013-02-18 16:57:08 <TD> my god jekyll must be the slowest text rendering engine ever made
554 2013-02-18 17:19:17 <kuu> I got a bag of bitcoins right here! Who wants em?
555 2013-02-18 17:21:14 <jouke> Me
556 2013-02-18 17:22:00 <jouke> I
557 2013-02-18 17:25:25 <kuu> how much?
558 2013-02-18 17:25:34 <jouke> Everything?
559 2013-02-18 17:25:38 <jouke> :)
560 2013-02-18 17:26:39 <kuu> Everything? Right now? you got it!
561 2013-02-18 17:38:56 <jouke> kuu: where is the private key?
562 2013-02-18 17:39:02 <jouke> I don't see it
563 2013-02-18 17:44:59 <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?
564 2013-02-18 17:45:33 <Luke-Jr> yes and no
565 2013-02-18 17:46:03 <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)
566 2013-02-18 17:46:22 <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?
567 2013-02-18 17:46:45 <zackham> Luke-Jr: got a link handy to your pull req?
568 2013-02-18 17:47:09 <Luke-Jr> https://github.com/bitcoin/bitcoin/pull/1583
569 2013-02-18 17:47:21 <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
570 2013-02-18 17:47:59 <Luke-Jr> zackham: Eligius mining pool is available for priority processing deals ;)
571 2013-02-18 17:49:05 <zackham> noted, ill be in touch if we end up going this route
572 2013-02-18 17:49:33 <zackham> ive got a lot more reading before i understand things well enough
573 2013-02-18 17:49:48 <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?
574 2013-02-18 17:49:48 <zackham> thanks for the quick help and link
575 2013-02-18 17:50:40 <helo> Eliel_: to cleanly exclude a group (or class) of transactions from having to live in the blockchain forever
576 2013-02-18 17:55:26 <andytoshi> helo: in principle it could be done, since the bitcoin network timestamps everything with the block depth
577 2013-02-18 17:55:41 <andytoshi> that is, it would be unambiguous to say "do XXX when bitcoin says YYY" in your protocol
578 2013-02-18 17:56:50 <andytoshi> you even start a blockchain where "coin creation" and "coin destruction" correspond to certain P2SH transaction on bitcoin
579 2013-02-18 17:56:55 <helo> could have a nlocktime'd spend so everyone knows when the chain will collapse
580 2013-02-18 17:57:32 <Eliel_> helo: hot potato? :P
581 2013-02-18 17:57:35 <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
582 2013-02-18 17:58:10 <sipa> Andy McCloudComputing
583 2013-02-18 17:58:45 <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.
584 2013-02-18 18:00:03 <andytoshi> Eliel_: i think with some cleverness, you could make sure the coin destructor and the coin's owner are always the same
585 2013-02-18 18:00:19 <andytoshi> make it merged-mining-able and entirely funded by fees, and you've got a microtransaction blockchain
586 2013-02-18 18:00:49 <Eliel_> andytoshi: potentially possible but I'd expect that would require support from bitcoin network too to work.
587 2013-02-18 18:01:41 <Eliel_> which would essentially pair the networks tightly enough that there's probably not much point having the division anymore.
588 2013-02-18 18:02:24 <Luke-Jr> whoa
589 2013-02-18 18:02:28 <Luke-Jr> my Bitcoin-Qt has an error
590 2013-02-18 18:02:56 <Luke-Jr> EXCEPTION: St12out_of_range CInv::GetCommand() : type=3 unknown type bitcoin in ProcessMessages()
591 2013-02-18 18:03:29 <andytoshi> Eliel_: it wouldn't be so tight, the altchain would only depend on bitcoin when translating bitcoins into altchains
592 2013-02-18 18:03:33 <andytoshi> altcoins*
593 2013-02-18 18:03:39 <sipa> Luke-Jr: that's a BIP37 filteredblock request, i think
594 2013-02-18 18:03:53 <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
595 2013-02-18 18:04:58 <Luke-Jr> sipa: why is it being requested of me? :x
596 2013-02-18 18:05:16 <Luke-Jr> or I guess, the better question is why it isn't just ignored
597 2013-02-18 18:05:20 <sipa> Luke-Jr: recent bitcoinj just sends it to everyone
598 2013-02-18 18:05:25 <sipa> it expects it to be ignored
599 2013-02-18 18:05:36 <Eliel_> andytoshi: both bitcoin and the altchain would have to constantly watch the other chain for transactions moving coins between the chains
600 2013-02-18 18:05:38 <sipa> i think
601 2013-02-18 18:05:44 <Luke-Jr> sipa: pretty ugly for it to make the statusbar 3 or 4 lines tall with an error :/
602 2013-02-18 18:05:50 <sipa> outch
603 2013-02-18 18:06:06 <sipa> that's not supposed to happen
604 2013-02-18 18:06:21 <gmaxwell> I think it's an absolute bug??? and a security concern??? if network traffic can trigger exceptions like that.
605 2013-02-18 18:06:42 <sipa> agree
606 2013-02-18 18:07:12 <gavinandresen> agreed. This is version 0.8 only ?
607 2013-02-18 18:07:24 <jgarzik> +1
608 2013-02-18 18:07:50 <Luke-Jr> gavinandresen: I'm still using 0.7-based code
609 2013-02-18 18:07:55 <sipa> gavinandresen: nothing changed to the network handling in 0.8, so i think it's very old
610 2013-02-18 18:08:03 <Luke-Jr> http://luke.dashjr.org/tmp/screenshots/snapshot91.png
611 2013-02-18 18:08:25 <gavinandresen> ok, then a high priority to fix for 0.8.1, not a 0.8 showstopper
612 2013-02-18 18:08:31 <sipa> at least 0.4
613 2013-02-18 18:09:37 <Luke-Jr> yeah, doesn't look like it killed network processing or anything
614 2013-02-18 18:09:40 <Luke-Jr> just an ugly message
615 2013-02-18 18:10:02 <sipa> it doesn't push you into safe mode?
616 2013-02-18 18:10:37 <Luke-Jr> doesn't seem to, is there a good way to check for sure?
617 2013-02-18 18:10:38 <Goonie> like: I tested bloom filtering a lot against 0.8, and never saw this. Or is this not about bloom filtering?
618 2013-02-18 18:10:50 <Goonie> s/like/luke/
619 2013-02-18 18:10:56 <sipa> just so you know: this problem has existed since v0.1.5
620 2013-02-18 18:11:15 <sipa> Goonie: it's about not having bloom filtering
621 2013-02-18 18:11:29 <Luke-Jr> Goonie: 0.8 implements bloom filtering, I think? so it's only an error before that
622 2013-02-18 18:11:30 <sipa> Goonie: if you request it from a node that doesn't know filtered blocks, this errors results
623 2013-02-18 18:11:47 <Luke-Jr> sipa: if it's only an ugly message, it may have not appeared in wx
624 2013-02-18 18:11:51 <Goonie> hmm, but how can you fix old clients by releasing a 0.8.1?
625 2013-02-18 18:11:58 <sipa> you can't
626 2013-02-18 18:12:12 <sipa> but the problem still exists in 0.8.0: just request any not defined inv type
627 2013-02-18 18:12:19 <Luke-Jr> Goonie: once the fix is in master, I'll backport it to the older branches
628 2013-02-18 18:12:31 <Goonie> ok thanks for the explaination
629 2013-02-18 18:16:52 <gmaxwell> Whatever happened to tcatm's GUI work?
630 2013-02-18 18:17:52 <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
631 2013-02-18 18:18:25 <andytoshi> and these would be valid bitcoin transactions, so bitcoin needn't care that those scripts said magic things to some altcoin
632 2013-02-18 18:20:22 <sipa> gmaxwell: different priorities, no more time to work on it, ...
633 2013-02-18 18:20:54 <Eliel_> andytoshi: that's not enough to add any restrictions to who the bitcoin transaction goes to.
634 2013-02-18 18:21:44 <andytoshi> Eliel_: it's not obvious to me that you're right (though I suspect you are)
635 2013-02-18 18:22:26 <gmaxwell> (I asked because every time I see the GUI I managed to be surprised at how clunky it seems to me)
636 2013-02-18 19:14:19 <sipa> gavinandresen: seems my leveldb is indeed built with -DNDEBUG
637 2013-02-18 19:16:46 <gavinandresen> sipa: good, that explains the assert difference...
638 2013-02-18 19:17:34 <sipa> if the pass-flags-down-to-leveldb patch changes that, there's something wrong with it imho
639 2013-02-18 19:18:07 <gavinandresen> something wrong with that patch? if I'm compiling for development (-g), then I want leveldb compiled -g, too....
640 2013-02-18 19:18:24 <sipa> ah ok, sure
641 2013-02-18 19:18:30 <sipa> but not when building a release binary
642 2013-02-18 19:18:33 <gavinandresen> Compiling for release it'll pass down -O3 (or whatever)
643 2013-02-18 19:18:52 <sipa> leveldb's makefile itself sets -DNDEBUG by default
644 2013-02-18 19:19:39 <gavinandresen> sipa: right, the patch overrides leveldb's default OPT ?= -O2 -DNDEBUG
645 2013-02-18 19:19:45 <sipa> ok
646 2013-02-18 19:21:03 <Luke-Jr> gavinandresen: Isn't -O3 a "known to break good code" level?
647 2013-02-18 19:21:13 <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
648 2013-02-18 19:21:35 <gavinandresen> (purposely ignoring an assert makes me nervous, though)
649 2013-02-18 19:22:03 <sipa> technically, any assert that fails means there's a bug in the code
650 2013-02-18 19:22:12 <sipa> as it is a should-not-ever-happen case
651 2013-02-18 19:22:48 <gavinandresen> yes. No sure whose code has the bug, though???. leveldb or the way you're re-setting leveldb before re-indexing.
652 2013-02-18 19:23:11 <sipa> i don't reset it - i destroy the db/env objects and create new ones
653 2013-02-18 19:24:24 <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>
654 2013-02-18 19:24:24 <sipa> best guess is that you triggered a weird condition in leveldb by random byte corruptions
655 2013-02-18 19:24:43 <sipa> (which are not a common failure pattern)
656 2013-02-18 19:24:45 <gavinandresen> yay me!
657 2013-02-18 19:24:46 <Luke-Jr> ???
658 2013-02-18 19:25:34 <sipa> i'm not sure if i like 0.8 being release already - reports of crashes and unbounded memory usage scare me
659 2013-02-18 19:26:38 <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....
660 2013-02-18 19:26:52 <Luke-Jr> lol
661 2013-02-18 19:27:03 <Luke-Jr> let's try -dbcache=100000000
662 2013-02-18 19:27:23 <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
663 2013-02-18 19:27:49 <sipa> typically, for high -dbcache values, the heuristics are a bit off and you get less
664 2013-02-18 19:28:22 <gavinandresen> sipa: do you have some ideas for how to proceed? we can't seem to reproduce these problems on our machines....
665 2013-02-18 19:28:27 <dhill> boost 1.53.0 seems to be working better for me. no crashes yet.
666 2013-02-18 19:33:37 <sipa> gavinandresen: going through the 0.8.0rc1 announce thread, as my memory of what i saw may be biased
667 2013-02-18 19:34:42 <TD> my 0.8 node is sitting at around 450mb resident
668 2013-02-18 19:34:54 <TD> sipa: well obviously people who test it and it all works are less likely to post ...
669 2013-02-18 19:37:34 <sipa> even then, the majority seems actually very positive
670 2013-02-18 19:38:18 <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)
671 2013-02-18 19:38:40 <sipa> one interesting case of someone who deleted some leveldb files, and was unable to start bitcoin afterwards
672 2013-02-18 19:39:21 <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.
673 2013-02-18 19:39:48 <gavinandresen> Stress testing / deleting files: not a showstopper bug, but would be Nice To Fix later. Same with crash on shutdown bug.
674 2013-02-18 19:40:34 <sipa> personal experience: i've found it very hard to actually get bitcoin to detect errors when messing with the leveldb files
675 2013-02-18 19:41:00 <sipa> far in the chain the error checks seem fine, as 288 is a ton of transactions that need to be checked
676 2013-02-18 19:41:49 <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
677 2013-02-18 19:42:16 <gavinandresen> in that case what happens? stuck chain?
678 2013-02-18 19:42:21 <sipa> yeah
679 2013-02-18 19:42:40 <sipa> i don't think these are likely scenarios though
680 2013-02-18 19:43:13 <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
681 2013-02-18 19:45:00 <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...
682 2013-02-18 19:45:45 <sipa> -reindex should always work
683 2013-02-18 19:46:50 <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"
684 2013-02-18 19:47:10 <sipa> crash-at-shutdown should be fixed
685 2013-02-18 19:47:29 <sipa> (the ~CCheckQueue destructor calling Quit())
686 2013-02-18 19:48:24 <gavinandresen> ok, then just the stuck blockchain note. User-visible symptom is the "???transactions may not be correct, you may have to upgrade" warning?
687 2013-02-18 19:48:38 <sipa> yes
688 2013-02-18 19:48:59 <sipa> not sure if i've seen any report of that, actually
689 2013-02-18 19:49:06 <sipa> so it's probably hard to reproduce
690 2013-02-18 19:50:02 <gavinandresen> maybe I shouldn't mention it, then, so we DO see reports if it happens
691 2013-02-18 19:51:50 <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"
692 2013-02-18 19:56:19 <TD> hmmmm
693 2013-02-18 19:56:25 <TD> ACTION wonders if he can trust a cryptographer who uses a hotmail address
694 2013-02-18 19:56:32 <sipa> haha
695 2013-02-18 19:56:48 <TD> the ed25519 paper has 5 authors, 4 of which have email addresses in which the domain name has something to do with crypto
696 2013-02-18 19:56:53 <TD> the 5th has a hotmail address :)
697 2013-02-18 19:57:57 <sipa> hmm? the paper i've open has by@crypto.tw as fifth author
698 2013-02-18 19:58:16 <lianj> TD: because he is pivoting :P
699 2013-02-18 19:58:27 <TD> http://ed25519.cr.yp.to/ed25519-20110926.pdf
700 2013-02-18 19:58:29 <TD> that one ?
701 2013-02-18 19:58:38 <TD> it has nielsduif@hotmail.com
702 2013-02-18 19:59:01 <sipa> ah, second author here
703 2013-02-18 19:59:19 <sipa> "high-speed high-security signatures"
704 2013-02-18 20:13:34 <pjorrit_> hotmail isn't too is it? it looked much better the few times i had that page open in the last few years
705 2013-02-18 20:13:37 <pjorrit_> +bad*
706 2013-02-18 20:13:52 <Luke-Jr> pjorrit_: besides blocking everyone? <.<
707 2013-02-18 20:14:29 <pjorrit_> who are they blocking? (for me it's an extra account i don't really use but still forward)
708 2013-02-18 20:14:47 <TD> yeah i'm sorta joking
709 2013-02-18 20:14:50 <TD> it's not terrible anymore
710 2013-02-18 20:15:19 <Luke-Jr> pjorrit_: seems 75% of the time when I have to email someone at hotmail, they never get it
711 2013-02-18 20:16:13 <pjorrit_> maybe they're just blocking you :D
712 2013-02-18 20:17:20 <TD> http://crypto.stackexchange.com/questions/3596/is-it-possible-to-pick-your-ed25519-public-key
713 2013-02-18 20:17:24 <TD> awesome diagram of ed25519 there
714 2013-02-18 20:17:53 <sipa> TD: yeah, that really helped me understand it
715 2013-02-18 20:49:58 <CoinBit> Hello!
716 2013-02-18 20:50:11 <pierre`> /wjpo/win16
717 2013-02-18 20:50:15 <pierre`> @#@#
718 2013-02-18 20:50:28 <CoinBit> I have a question: can you hotswap java code in netbeans?
719 2013-02-18 20:50:47 <Luke-Jr> CoinBit: does this look like #Java ?
720 2013-02-18 20:50:53 <Zarutian> TD: wait? what? is ed25519 that "simple"?
721 2013-02-18 20:51:09 <CoinBit> No... Bye then...
722 2013-02-18 20:57:12 <upb> CoinBit: dunno if thats what youre asking but theres a product called javarebel for hotswapping java code in appservers
723 2013-02-18 20:57:48 <CoinBit> i,ll check it out thx
724 2013-02-18 21:07:54 <dhill> my last 'bitcoind stop' caused blkindex.dat corruption
725 2013-02-18 21:08:07 <dhill> http://gbpaste.org/QexK2 <-- anything stick out as being out of order?
726 2013-02-18 21:15:25 <TD> Zarutian: what do you mean by simple?
727 2013-02-18 21:16:40 <Zarutian> I thought it would be much harder to describe.
728 2013-02-18 21:17:00 <gmaxwell> dhill: where is the rest? Everything there looks normal and happy. Where is the next startup logging unhappyness?
729 2013-02-18 21:17:07 <sipa> the same diagram for ECDSA would be even simpler
730 2013-02-18 21:17:15 <sipa> the difficulty is in the layers underneath
731 2013-02-18 21:17:25 <dhill> let me start it up
732 2013-02-18 21:19:34 <TD> hm, colour me impressed. javafx is really nice.
733 2013-02-18 21:21:25 <dhill> ahh, my assumption was wrong
734 2013-02-18 21:22:15 <dhill> are the invalidchainfound warnings.. and reorganized fails ok?
735 2013-02-18 21:22:30 <sipa> if it happens once, yes
736 2013-02-18 21:22:39 <dhill> no, i am just beeing flooding
737 2013-02-18 21:22:40 <dhill> ed
738 2013-02-18 21:22:49 <sipa> in that case, most certainly no
739 2013-02-18 21:23:15 <dhill> db_verify blkindex.dat failed after my 'bitcoind stop'
740 2013-02-18 21:23:20 <sipa> it typically means an error in the block index, and failed verifications as a result of it
741 2013-02-18 21:23:21 <dhill> which is why i thought it was corrupt
742 2013-02-18 21:25:40 <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?