1 2013-06-20 00:00:08 <The_Fly> if you dont need a wallet
2 2013-06-20 00:02:43 <scripting> thats a point... why dont ppl just have a service where all the transactions are indexed with the received address?
3 2013-06-20 00:03:00 <scripting> so look ups on that data is nice fast and efficient?
4 2013-06-20 00:03:28 <scripting> I guess blockchain.org already has that in place :P
5 2013-06-20 00:04:00 <scripting> but isnt there any apps for just that functionality or bitcoind mods for that same thing supporting rpc calls
6 2013-06-20 00:04:32 <lianj> scripting: its just a huge index
7 2013-06-20 00:04:51 <scripting> blockexplorer.com i meant
8 2013-06-20 00:05:20 <scripting> yeh... although it wouldnt be too big with a recent start date
9 2013-06-20 00:05:30 <scripting> just have stuff starting from say yesterday
10 2013-06-20 00:05:35 <scripting> to the future?
11 2013-06-20 00:05:44 <scripting> then auto delete stuff from so many months ago
12 2013-06-20 00:05:50 <scripting> to keep it all small
13 2013-06-20 00:06:18 <lianj> removing doesn't really work like that
14 2013-06-20 00:06:34 <scripting> just to keep the database small
15 2013-06-20 00:06:42 <scripting> does too :P
16 2013-06-20 00:07:08 <scripting> because after every removal process say thats done once a month you can just reform all the indexing
17 2013-06-20 00:07:14 <scripting> from scratch
18 2013-06-20 00:07:40 <scripting> The_Fly what you think of that?
19 2013-06-20 00:08:46 <lianj> what about old addresses that still have balance. like The_Fly said, "then put together a p2p node which just scans [or indexes] the blockchain and responds to tx's in your address list"
20 2013-06-20 00:09:26 <scripting> yeah that would be better actually, your right...
21 2013-06-20 00:09:45 <scripting> Im guessing no one done this yet and published it?
22 2013-06-20 00:09:57 <scripting> great more work for me to do!
23 2013-06-20 00:10:23 <The_Fly> have fun
24 2013-06-20 00:10:36 <scripting> ACTION cries a river
25 2013-06-20 00:11:44 <scripting> there is no better solution, I agree, thats the way to keep it all efficient, and not lose info from previous (old) transactions
26 2013-06-20 00:18:55 <scripting> i just thought of a flaw in that design...if a new key is added, a rescan will still have to be done, then the problem is the data wont be there to rescan...
27 2013-06-20 00:19:10 <scripting> *bump*
28 2013-06-20 00:20:17 <The_Fly> address->tx map
29 2013-06-20 00:20:57 <scripting> but the data wont be there... the_fly
30 2013-06-20 00:21:31 <The_Fly> you can find all tx affecting a new address without a rescan
31 2013-06-20 00:21:35 <scripting> because it would of filtered everything that hasnt got anything to do with the pre-existing address list
32 2013-06-20 00:21:39 <lianj> thats why its easier to have a index of all and not delete anything
33 2013-06-20 00:21:45 <The_Fly> ^
34 2013-06-20 00:21:46 <lianj> no rescan, no nothing
35 2013-06-20 00:21:49 <scripting> Yes.
36 2013-06-20 00:21:55 <The_Fly> so do that! lol
37 2013-06-20 00:22:00 <scripting> lol!
38 2013-06-20 00:22:01 <lianj> 100gb diskspace
39 2013-06-20 00:22:06 <scripting> pwnd!
40 2013-06-20 00:22:12 <The_Fly> space is cheap
41 2013-06-20 00:22:13 <scripting> thats fisable at least
42 2013-06-20 00:22:14 <The_Fly> very cheap
43 2013-06-20 00:22:16 <lianj> right
44 2013-06-20 00:22:16 <scripting> at this stage
45 2013-06-20 00:22:18 <scripting> and...
46 2013-06-20 00:22:33 <scripting> with that solution say I can only have the data starting from like 3 months ago onward
47 2013-06-20 00:22:37 <scripting> so save space.
48 2013-06-20 00:22:44 <The_Fly> whatever you like
49 2013-06-20 00:22:54 <scripting> since my service doesnt need really old transactions
50 2013-06-20 00:23:04 <scripting> so it will be probably only like 5Gb
51 2013-06-20 00:23:05 <lianj> no, you need all
52 2013-06-20 00:23:08 <scripting> and grow from there
53 2013-06-20 00:23:10 <scripting> why:
54 2013-06-20 00:23:24 <lianj> dont like to repeat myself
55 2013-06-20 00:23:34 <The_Fly> you need all if you want the balance for an address which may have unspent tranactions
56 2013-06-20 00:23:41 <The_Fly> which occur before your index
57 2013-06-20 00:23:55 <scripting> I wont have any such addresses
58 2013-06-20 00:24:05 <scripting> I will only have newly formed addresses
59 2013-06-20 00:24:09 <scripting> thats why I dont need the old data
60 2013-06-20 00:24:13 <lianj> then have fun
61 2013-06-20 00:24:21 <The_Fly> so if you have only new addresses... whats the problem
62 2013-06-20 00:24:32 <The_Fly> just import to bitcoind with no rescan!
63 2013-06-20 00:24:40 <lianj> besides the validation of txs sent to your addresses
64 2013-06-20 00:25:25 <scripting> hmmmm thats a point!
65 2013-06-20 00:25:36 <The_Fly> you can check they receive validations
66 2013-06-20 00:25:46 <The_Fly> after block notifications from bitcoind
67 2013-06-20 00:25:56 <The_Fly> until reaches some value where you care no longer
68 2013-06-20 00:25:57 <The_Fly> 6
69 2013-06-20 00:26:13 <scripting> yup I guess I been crying for nothing all this time
70 2013-06-20 00:26:15 <scripting> silly me
71 2013-06-20 00:26:44 <The_Fly> crying will make you a stronger man
72 2013-06-20 00:26:59 <Luke-Jr> ???
73 2013-06-20 00:27:00 <scripting> hahaha I'll try to keep that in mind for the future
74 2013-06-20 00:27:07 <gmaxwell> gee if only you'd described what you were doing in any detail at all an hour ago and someone could have pointed out that you didn't need the old data.
75 2013-06-20 00:27:33 <scripting> my bad, I humbly apologise
76 2013-06-20 00:27:36 <gmaxwell> :P
77 2013-06-20 00:28:21 <gmaxwell> Keeping a bunch of archival stuff is incompatible with pruning, so we're generally not eager to add a bunch of functionality which depends on things like that.
78 2013-06-20 00:30:07 <scripting> aye
79 2013-06-20 02:15:26 <owowo> the addnode command in bitcoin.conf goes like: addnode= node1, node2, nodeX ?
80 2013-06-20 02:16:27 <gmaxwell> owowo: you simply use the addnode line multiple times.. though there usually isn't a reason to do more than a couple.
81 2013-06-20 02:16:50 <owowo> ok, thx
82 2013-06-20 03:51:29 <LLckfan> I have Linksys WRT120N that when it is plugged in and hooked to the modem the port, wifi, and internet lights flash. Is it shoot or is there a way to fix this? I have already unplugged it
83 2013-06-20 05:15:25 <Luke-Jr> saivann: skin getting tough? :p
84 2013-06-20 05:16:45 <saivann> Luke-Jr : I don't want to lose another second on that :) But I will remain polite, of course
85 2013-06-20 06:19:59 <midnightmagic> saivann: I was having trouble not posting a link to http://www.youtube.com/watch?v=Qq4j1LtCdww
86 2013-06-20 06:20:29 <midnightmagic> saivann: Lucky I'm just a kid with stars in my eyes.
87 2013-06-20 06:20:57 <TD[gone]> hello
88 2013-06-20 06:25:33 <midnightmagic> hey TD
89 2013-06-20 09:11:41 <TheSeven> hey, as some of you might know, I'm running a ppcoin pool. ppcoind is based on bitcoind 0.6, and I'm not sure if many things changed since then in that area.
90 2013-06-20 09:12:06 <TheSeven> I just noticed that my pool server for some reason lost network connectivity briefly tonight, which killed all of its p2p connections
91 2013-06-20 09:12:24 <TheSeven> it took ppcoind more than 17 minutes to realize that and even attempt to reintegrate into the network
92 2013-06-20 09:12:50 <TheSeven> to be more exact, it took until it found a block and attempted to announce that
93 2013-06-20 09:13:02 <TheSeven> doesn't look quite right to me
94 2013-06-20 09:31:23 <The_Fly> < LLckfan> I have Linksys WRT120N that when it is plugged in and hooked to the modem the port, wifi, and internet lights flash. Is it shoot or is there a way to fix this? I have already unplugged it
95 2013-06-20 09:32:21 <bitRipperX> Aside from armory what are the most stable and mature options for generating and using multiple wallets on a single machine?
96 2013-06-20 09:34:22 <The_Fly> im using the multiwallet branch on codeshark's fork
97 2013-06-20 09:34:32 <TD> multibit allows multiple wallets
98 2013-06-20 09:35:01 <The_Fly> (but im not using the most stable and mature option by doing so)
99 2013-06-20 09:36:55 <The_Fly> for server applications im not sure of any other multiwallet support
100 2013-06-20 09:37:42 <The_Fly> and the branch required some hacking to get it up to date
101 2013-06-20 09:38:07 <The_Fly> and is not maintained, so i am doing so just for myself here
102 2013-06-20 09:38:22 <TD> bitRipperX: you want a desktop wallet?
103 2013-06-20 09:38:55 <The_Fly> the whole SPV node concept will make multiwallet bitcoind unnecessary
104 2013-06-20 09:39:15 <bitRipperX> nah, something headless. I'm creating an application and I want to be able to auto-generate and use them remotely
105 2013-06-20 09:39:15 <The_Fly> so is just an interim solution for now
106 2013-06-20 09:39:47 <TD> The_Fly: how does it not already? multibit is spv wallet that can load multiple wallets at once
107 2013-06-20 09:40:52 <TD> bitRipperX: you could try with bitcoinj, but it's not very well supported. each wallet shares the same chain, so if a wallet is unloaded for a while it can miss blocks (it won't rewind and replay missed data). you can of course run multiple instances of the whole library in the same process, but it's a bit inefficient
108 2013-06-20 09:43:06 <The_Fly> TD: it does, but i too am looking at headless multiwallet
109 2013-06-20 09:43:18 <TD> i see
110 2013-06-20 09:43:22 <The_Fly> and it works for me, ive had little trouble keeping the branch up to date
111 2013-06-20 09:43:25 <TD> is this to keep addresses isolated?
112 2013-06-20 09:44:03 <The_Fly> the idea was that id have several projects compartmentalised via their wallet
113 2013-06-20 09:44:17 <The_Fly> so in a hosting environment only one box dedicated to bitcoind
114 2013-06-20 09:44:38 <The_Fly> and each project uses its own wallet (for my own convenience)
115 2013-06-20 09:45:46 <TD> i see
116 2013-06-20 09:46:01 <bitRipperX> ]TD: actually bitcoinj doesn't work with the newest version of nodejs. I tried for about a week and a half to get it running but eventually found out there's a probelm with the internal db they use.
117 2013-06-20 09:46:28 <bitRipperX> TD: ah fuck, never mind. Im thinking of bitcoinjs
118 2013-06-20 09:46:28 <The_Fly> yeah, i will share the multiwallet branch soon
119 2013-06-20 09:46:39 <The_Fly> and split it up into meaningful commit history
120 2013-06-20 09:46:45 <TD> right
121 2013-06-20 09:46:53 <The_Fly> but i dont think people here are up for integrating it
122 2013-06-20 09:47:30 <The_Fly> so it wont really act as a long-term solution bitRipperX
123 2013-06-20 09:47:42 <bitRipperX> The_Fly: hey mate, how you doing
124 2013-06-20 09:47:42 <The_Fly> unless others help maintain it, which is doubtful
125 2013-06-20 09:49:11 <bitRipperX> Yeah, everything is so new, i guess this is one of those things that isn't fully baked yet.
126 2013-06-20 09:49:37 <The_Fly> bitRipperX: im ok thanks, off out for a meeting soon
127 2013-06-20 09:49:57 <The_Fly> yeah, i think amir taaki was speaking of this issue on letstalkbitcoin
128 2013-06-20 09:50:27 <The_Fly> and his libbitcoin project
129 2013-06-20 09:52:29 <bitRipperX> what do the online wallet providers do under the hood?
130 2013-06-20 09:52:38 <The_Fly> ermmmmm
131 2013-06-20 09:53:16 <The_Fly> either their own solution (coinbase have written node in ruby)
132 2013-06-20 09:53:59 <The_Fly> or they use "accounts"
133 2013-06-20 09:54:59 <The_Fly> or some database layer outside bitcoind which allows for calculation of individual balances
134 2013-06-20 09:56:25 <The_Fly> but yeah, these wallet solutions are not exactly secure
135 2013-06-20 09:56:34 <The_Fly> people still use them though
136 2013-06-20 09:58:06 <The_Fly> https://www.strongcoin.com/
137 2013-06-20 09:58:07 <The_Fly> is interesting
138 2013-06-20 09:59:08 <bitRipperX> The_Fly: didn't know abotu strongcoin. I'll check it out. thanks
139 2013-06-20 10:00:03 <The_Fly> and i think there's another which offer to keep one half of your keys
140 2013-06-20 10:00:11 <The_Fly> for 2-of-2 transactions
141 2013-06-20 10:00:27 <The_Fly> bit im having trouble finding it, maybe im just imagining it
142 2013-06-20 10:05:33 <epscy> did coinbase write an entire bitcoin node in ruby?
143 2013-06-20 10:05:49 <epscy> or just the wallet/account stuff?
144 2013-06-20 10:08:00 <The_Fly> its a custom node in pure ruby
145 2013-06-20 10:08:07 <The_Fly> and that's a good effort!
146 2013-06-20 10:08:24 <The_Fly> im assuming their web backend is also ruby but could be wrong
147 2013-06-20 10:08:33 <The_Fly> it doesn't really matter
148 2013-06-20 10:14:37 <TD> i think it's open source and just a partial node
149 2013-06-20 10:14:48 <epscy> open source?
150 2013-06-20 10:14:58 <epscy> yeah i would be surprised if it was a full node
151 2013-06-20 10:15:41 <The_Fly> lianj described it as such, but i could be mistaken
152 2013-06-20 10:16:14 <The_Fly> and i dont think they have opensourced it
153 2013-06-20 10:16:38 <The_Fly> oops https://github.com/lian/bitcoin-ruby
154 2013-06-20 10:17:40 <lianj> thats just the core (parsing/network) code
155 2013-06-20 10:18:14 <lianj> TD: its a full node, written ontop of that lib. we plan to opensource it at some point.
156 2013-06-20 10:18:33 <The_Fly> i assumed so
157 2013-06-20 10:18:53 <epscy> lianj: cool, what is performance like?
158 2013-06-20 10:19:01 <The_Fly> otherwise a lot of people would be talking about it
159 2013-06-20 10:19:16 <sipa> lianj: full node, as in including maintaining na UTXO set, and verifying scripts/signatures?
160 2013-06-20 10:19:17 <TD> ok
161 2013-06-20 10:19:58 <lianj> sipa: all minus the utxo because we don't want/need utxo for our service
162 2013-06-20 10:20:47 <sipa> lianj: so... how do you find the output script being spent?
163 2013-06-20 10:21:22 <TD> presumably he means a pre-ultraprune style design
164 2013-06-20 10:21:58 <sipa> oh i don't necessarily mean maintaining an explicit UTXO set; just some way of knowing which outputs aren't spent yet, and what their amount/script are
165 2013-06-20 10:22:26 <lianj> Output.mainchain.where(:address_ids => address.id, :spent => false)
166 2013-06-20 10:22:47 <The_Fly> yes, at the db level, but there's no verification
167 2013-06-20 10:22:57 <TD> address id?
168 2013-06-20 10:23:09 <lianj> TD: internal db entry id
169 2013-06-20 10:23:39 <lianj> The_Fly: the verification happens when storing txs/blocks, so it happened earlier already
170 2013-06-20 10:24:17 <The_Fly> ah right
171 2013-06-20 10:24:28 <lianj> im not saying its suggested to keep a real full index of everything if you make a small service, but for a blockexplorer like service you kinda need it
172 2013-06-20 10:24:45 <sipa> sure, of course
173 2013-06-20 10:26:17 <TheSeven> sipa: is it expected behavior that bitcoind would take 15+ minutes to notice a dropped network connection and reconnect to the p2p network? has anything in that area changed since 0.6?
174 2013-06-20 10:26:54 <sipa> TheSeven: it should detect it within a minute
175 2013-06-20 10:27:34 <TheSeven> my ppcoind (which is a bitcoind 0.6 fork) didn't notice it until it attempted to announce a newly found block to the network
176 2013-06-20 10:27:35 <sipa> if nothing is received on a network connection for 1 minute, it is droppd
177 2013-06-20 10:27:48 <sipa> and if there are less than 8 outgoing connections, new ones are made
178 2013-06-20 10:28:07 <TheSeven> can you point me to the code for that? I'd like to double check if the ppcoin guys broke it :P
179 2013-06-20 10:28:12 <TheSeven> which file is it in?
180 2013-06-20 10:30:18 <sipa> maybe i'm mistaken and the timeout is longer
181 2013-06-20 10:30:49 <sipa> apparently it's 90 minutes
182 2013-06-20 10:31:03 <sipa> but 1 minute after establishing the connection
183 2013-06-20 10:31:10 <TheSeven> hm, crap :/
184 2013-06-20 10:31:25 <TheSeven> that could cause funny things
185 2013-06-20 10:32:11 <sipa> and there is a keep-alive ping every 30 minutes
186 2013-06-20 10:32:20 <sipa> i think those numbers could be decreased significantly
187 2013-06-20 10:35:18 <The_Fly> lol, yes
188 2013-06-20 10:37:00 <sipa> would a keep-alive every 1 minute, and drop after 2 or 3 minutes not be appropriate?
189 2013-06-20 10:46:27 <TheSeven> given how many transactions are floating around these days you shouldn't even need the keepalive part of that :)
190 2013-06-20 10:46:44 <TheSeven> sipa: so where is the code for this? I'd like to patch it locally...
191 2013-06-20 10:47:03 <TheSeven> thanks for investigating btw :)
192 2013-06-20 10:47:26 <sipa> TheSeven: net.cpp, search for "socket inactivity timeout"
193 2013-06-20 10:47:58 <sipa> and in main.cpp, search for pto->PushMessage("ping")
194 2013-06-20 10:48:07 <TheSeven> thanks!
195 2013-06-20 10:54:48 <BlueMatt> hmm...looks like my testnet seed is down and I dont feel like rebuilding bitcoind here with my alert patch, so...no testnet alert today
196 2013-06-20 11:01:18 <BlueMatt> on a related note, does anyone have a testnet seed that they want to run the alert-sender on?
197 2013-06-20 11:02:03 <jgarzik> mornin'
198 2013-06-20 11:02:08 <TheSeven> wow, chanserv was late to that party :P
199 2013-06-20 11:39:59 <OutletBL> any developers here?
200 2013-06-20 11:40:00 <OutletBL> :D
201 2013-06-20 11:40:44 <nsh> not since the last Purge...
202 2013-06-20 11:41:36 <OutletBL> :(
203 2013-06-20 11:41:52 <OutletBL> Was looking for some help with www.btc-outlet.com I have a merchant account on bitpay aswell.
204 2013-06-20 11:42:01 <jgarzik> not really. We're all just hanging out, waiting around for gavinandresen to descend from the mount with another glorious sermon
205 2013-06-20 11:42:11 <jgarzik> ;p
206 2013-06-20 11:42:12 <sipa> s/gavinandresen/Satoshi/
207 2013-06-20 11:42:53 <OutletBL> hmm but is anyone interested? Money is to be made :P
208 2013-06-20 11:43:18 <sipa> most developers here have their own projects, and the channel is mostly about client/protocol development
209 2013-06-20 11:43:43 <jgarzik> OutletBL, This channel is largely for core bitcoin development, not really website and related dev
210 2013-06-20 11:43:57 <OutletBL> :(
211 2013-06-20 11:44:16 <OutletBL> its for bitcoin's advantage ;( do you no where I can go for web devs?
212 2013-06-20 11:48:05 <helo> #bitcoin-otc or #bitcoin from time to time has some people willing to do web dev
213 2013-06-20 13:11:18 <epscy> "it's like facebook but with bitcoins!"
214 2013-06-20 13:14:22 <jgarzik> saivann, how to ban someone from a repo? I know Gavin did it with one troll.
215 2013-06-20 13:16:47 <fanquake> jgarzik https://github.com/blog/862-block-the-bullies
216 2013-06-20 13:18:09 <jgarzik> fanquake, Saw and used that? but was left wondering if that's a personal block, i.e. something that shields me from troll posts, but continues to permit the troll to dump drek into others' inboxes
217 2013-06-20 13:20:22 <fanquake> jgarzik hmm, that could very well be personal. Are you trying to block a user from an organisation? I'm wondering if you can block the user while under the org account, if thats what your trying todo.
218 2013-06-20 13:21:20 <jgarzik> fanquake, Trying to stop a user from continuing to post to a bitcoin/bitcoin.org.git pull request
219 2013-06-20 13:21:53 <TD> lol. someone is trying to steal all the correct horse battery staple coins and consolidate them. address is http://blockchain.info/fb/1stop1
220 2013-06-20 13:22:07 <jgarzik> heh
221 2013-06-20 13:23:07 <kinlo> that's not consolidating :)
222 2013-06-20 13:23:24 <kinlo> I was thinking about doing the same, just including 1 huge transaction that consumes them all
223 2013-06-20 13:23:48 <kinlo> never got around doing so
224 2013-06-20 13:23:48 <TD> well it has to be several txns because you can't make ones that have too many inputs
225 2013-06-20 13:24:01 <kinlo> define "too many"
226 2013-06-20 13:24:11 <TD> MAX_STANDARD_TX_SIZE
227 2013-06-20 13:24:24 <kinlo> I would include the tx inside a block I mine so fee's wouldn't be an issue
228 2013-06-20 13:24:37 <TD> although it seems the 1stop1 transactions are sitting unconfirmed anyway
229 2013-06-20 13:24:40 <fanquake> jgarzik if your switch account context to the Bitcoin org, you can block the user that way. Although I'm pretty sure that will block them from interacting will all the repos in the bitcoin org
230 2013-06-20 13:24:48 <TD> ah well if you control your own blocks and mine on them, then sure
231 2013-06-20 13:25:00 <kinlo> well, yeah
232 2013-06-20 13:25:08 <sipa> create a 1 MB block with a single TX that just consumes them all :p
233 2013-06-20 13:25:21 <kinlo> just put some time in cleaning up the txo database would be good for everybody
234 2013-06-20 13:25:21 <sipa> (note: won't trigger a fork)
235 2013-06-20 13:25:36 <kinlo> but I have been too busy to get that inside my bitcoind
236 2013-06-20 13:25:39 <TD> sipa: WILL trigger a fork. would get rid of 0.7 finally ;)
237 2013-06-20 13:25:47 <TD> unless we did that already whilst i wasn't watching
238 2013-06-20 13:25:49 <sipa> TD: no, it wouldn't
239 2013-06-20 13:25:52 <sipa> eh
240 2013-06-20 13:26:02 <sipa> no, it wouldn't
241 2013-06-20 13:26:02 <TD> wouldn't that hit the locks limit due to having so many inputs?
242 2013-06-20 13:26:08 <sipa> you need many outputs, not many inputs
243 2013-06-20 13:26:13 <sipa> as inputs are larger than outputs
244 2013-06-20 13:26:24 <sipa> and just a whole block of inputs isn't enough
245 2013-06-20 13:26:33 <TD> oh, ok
246 2013-06-20 13:26:49 <sipa> slush's march 11 block was really quite an exception already
247 2013-06-20 13:28:06 <jgarzik> fanquake, hrm, how to switch "account context"? any idea?
248 2013-06-20 13:29:10 <fanquake> jgarzik on the github.com home page, theres a button on the top left.
249 2013-06-20 13:29:32 <fanquake> Clicking that should give you a drop down of all the orgs your a part of
250 2013-06-20 13:30:17 <TD> satoshidice is using 5430 satoshis as the limit instead of 5460, oops.
251 2013-06-20 13:30:37 <sipa> not very surprising, as 5430 was the number announced everywhere
252 2013-06-20 13:31:45 <TD> yes. unfortunate :(
253 2013-06-20 13:31:51 <TD> i wonder how many apps will get it wrong now
254 2013-06-20 13:32:06 <sipa> the point is that none should assume a fixed limit in the first place...
255 2013-06-20 13:33:03 <sipa> the problem was that it was announced as "minimum 5430 satoshi limit!" instead of "minimum txout amount 3 times the marginal cost for spending a normal transaction according to the active but now configurable relay policy!"
256 2013-06-20 13:33:09 <sipa> eh, well, maybe not :p
257 2013-06-20 13:33:55 <TD> tee hee. well, hopefully gavin will be ready to merge the payment protocol work soon
258 2013-06-20 13:34:00 <TD> i guess it needs more review but i already did one round
259 2013-06-20 13:34:19 <TD> and then SD can implement it and 6 months later when blockchain.info and electrum implements it, i suppose SD will be willing to use it :)
260 2013-06-20 13:35:37 <jgarzik> heh
261 2013-06-20 13:35:38 <sipa> TD: btw, what in your opinion is the correct behaviour when a payment request specifies a URI, but it can't be reached?
262 2013-06-20 13:35:46 <TD> for submission?
263 2013-06-20 13:35:48 <sipa> yes
264 2013-06-20 13:35:54 <TD> treat it as you would any offline payment.
265 2013-06-20 13:35:59 <TD> i.e. store it in the wallet and try again later.
266 2013-06-20 13:36:13 <sipa> because gavin insisted that it should be broadcast nonetheless
267 2013-06-20 13:36:14 <TD> at least that's my plan for bitcoinj
268 2013-06-20 13:36:50 <TD> well, i guess we can see what works best. i suppose i'm struggling to see situations in which you can fetch the request file but not submit to the server, except for server-side faults and programmer errors.
269 2013-06-20 13:36:51 <sipa> which seems to break the guarantee that as a merchant, you're guaranteed to receive it through the uri
270 2013-06-20 13:37:03 <TD> i suppose you could open up a payment request, go offline for a while, then click send without noticing you have no network.
271 2013-06-20 13:37:26 <TD> any good merchant server will have to handle both eventualities no matter what happens
272 2013-06-20 13:37:33 <TD> so i think it depends mostly on the most sensible user experience
273 2013-06-20 13:38:09 <sipa> well, if you guarantee that no broadcast to p2p is done before having a succesfull sent to the merchant, there is no way it can ever appear
274 2013-06-20 13:38:19 <sipa> though sure, you'll need to handle both cases
275 2013-06-20 13:38:19 <TD> but merchants can't assume correct clients, really
276 2013-06-20 13:38:22 <TD> yeah
277 2013-06-20 13:38:45 <sipa> but ideally, the "i never got the payment submission" would be something so uncommon that it can be dealt with manually
278 2013-06-20 13:39:20 <sipa> my worry is that if it's so common that you need to deal with it as frequently as the other case, there is no way to rely on knowing a refund address, for example
279 2013-06-20 13:39:42 <daybyter> TD, you're a java dev?
280 2013-06-20 13:39:58 <TD> depends on the year. over time i've been pretty much an everything dev
281 2013-06-20 13:40:24 <TD> sipa: why would it be common? it's just regular HTTP[S] right. doesn't get simpler than that.
282 2013-06-20 13:40:53 <sipa> TD: if a client implementation for example broadcasts on P2P immediately, and only tries to contact the submission URI once
283 2013-06-20 13:41:02 <sipa> TD: and if that fails, never retries
284 2013-06-20 13:41:03 <daybyter> great! Someone, who doesn't greet java devs with 'java must die!'
285 2013-06-20 13:41:15 <daybyter> <= likes TD...
286 2013-06-20 13:41:32 <TD> sipa: well, hopefully bogus clients don't end up being the most popular ones ..... we'll see :)
287 2013-06-20 13:41:49 <jgarzik> the more mature among us just greets Java with a patronizing pat on the head
288 2013-06-20 13:41:51 <jgarzik> ACTION runs
289 2013-06-20 13:41:51 <TD> daybyter: i got over language wars a long time ago. now i feel they all suck more or less equally, just in slightly different ways :-)
290 2013-06-20 13:41:56 <jgarzik> indeed
291 2013-06-20 13:42:19 <jgarzik> geek wars are tiresome. Each is a tool with strengths and weaknesses.
292 2013-06-20 13:42:20 <BlueMatt> TD: yes
293 2013-06-20 13:42:27 <daybyter> I like java...
294 2013-06-20 13:42:49 <TD> as a language it's rather limited, but the surrounding tools are often excellent. and it has the benefit of being the lingua franca
295 2013-06-20 13:42:55 <TD> so it all sort of balances out in the end
296 2013-06-20 13:43:04 <daybyter> I would use scheme or lisp, but java has all those nice methods for internet stuff, UI stuff etc etc
297 2013-06-20 13:43:17 <daybyter> I do trading stuff in java...
298 2013-06-20 13:46:52 <TD> internet stuff is quite important yes :)
299 2013-06-20 13:47:02 <TD> although i haven't been very impressed with network libraries available for java. netty was a bit of a disaster.
300 2013-06-20 13:47:10 <TD> still, the libraries simplify a lot of things
301 2013-06-20 13:47:20 <TD> i quite like the look of kotlin at the moment. but i don't really have time to play with it.
302 2013-06-20 13:48:33 <TD> jetbrains have a lot of good ideas.
303 2013-06-20 13:49:57 <jgarzik> ACTION just started with node.js, and is has a lot of the annoyances of Java and python: one class per file, leading to thousands of tiny files
304 2013-06-20 13:50:52 <TD> yeah i don't really get using server-side javascript. now that really IS a limited language. but whatever ...
305 2013-06-20 13:50:56 <Ry4an> we're doing more and and more Go here at the office. It really hits a sweet spot in some ways that weren't immediately obvious to me.
306 2013-06-20 13:51:14 <lianj> yea, node.js has great threading, oh wait???
307 2013-06-20 13:57:05 <MC1984> TD does bitcoinj .9 have a real full verify + chain store mode now
308 2013-06-20 13:57:13 <TD> it has had one for a while
309 2013-06-20 13:57:25 <MC1984> something to rival bitcoind?
310 2013-06-20 13:57:38 <jgarzik> rivalry!
311 2013-06-20 13:57:40 <TD> i mean, one equivalent to bitcoind. it's experimental in the sense that it likely still has chain splitting bugs in it, but that's true of all reimplementations. i think bitcoinj is the closest to being correct. matt has done a great job with it
312 2013-06-20 13:57:58 <jgarzik> grau's implementation seems decent on the correctness angle
313 2013-06-20 13:58:22 <jgarzik> dunno if anyone is far enough along to be used for mining
314 2013-06-20 13:58:23 <MC1984> well thats pretty cool
315 2013-06-20 13:58:43 <TD> yeah, his is probably also very good by now. i am just less familiar with it.
316 2013-06-20 13:58:45 <sipa> TD: it doesn't maintain a mempool, does it?
317 2013-06-20 13:58:51 <sipa> (bitcoinj)
318 2013-06-20 13:58:51 <TD> but he works on it full time so it should beat us sooner or later, if not already
319 2013-06-20 13:59:04 <TD> sipa: nope. it's not a real bitcoind replacement. it just verifies equivalently, it doesn't try and serve
320 2013-06-20 13:59:16 <sipa> i find it a pity that people mimick bitcoind :p
321 2013-06-20 13:59:29 <sipa> and write a full node when they just need a powerful wallet server
322 2013-06-20 13:59:48 <sipa> the first is ridiculously risky, the second needs all innovation it can get
323 2013-06-20 14:00:01 <Ry4an> heterogenaity is a strength in P2P systems
324 2013-06-20 14:00:23 <sipa> for consensus, i'm not convinced
325 2013-06-20 14:00:32 <sipa> (not saying otherwise either, btw)
326 2013-06-20 14:00:55 <Diablo-D3> ;;ticker
327 2013-06-20 14:00:57 <gribble> BTCUSD ticker | Best bid: 113.00001, Best ask: 113.77324, Bid-ask spread: 0.77323, Last trade: 113.00000, 24 hour volume: 34890.32303765, 24 hour low: 106.46088, 24 hour high: 114.00113, 24 hour vwap: 110.51592
328 2013-06-20 14:01:01 <gmaxwell> I'll say otherwise. It's a significant ongoing risk and weakness for a consensus system. You get the sum of all bugs.
329 2013-06-20 14:01:20 <gmaxwell> (But its one we have to deal with??? I'm not saying otherwise than that)
330 2013-06-20 14:01:43 <TD> well, i focus on wallet code a lot for that exact reason
331 2013-06-20 14:01:47 <MC1984> whats the ideal distribution
332 2013-06-20 14:01:49 <TD> full verification doesn't excite me very much
333 2013-06-20 14:01:52 <Ry4an> true you get the sum of all bugs, but with enough variety any 1 bug affects a minority of clients.
334 2013-06-20 14:02:10 <petertodd> remember that the worst case is an attacker finds different chain splitting bugs for each of the n implementations and exploits them simultaneously to do what is now a 1/n * 50% attack
335 2013-06-20 14:02:11 <MC1984> one implementatin with >51% hashpower at least, and rest spread out?
336 2013-06-20 14:03:17 <BlueMatt> ACTION sure as hell hopes no one is mining on any alt implementations until our test coverage goes up a few orders of magnitude
337 2013-06-20 14:03:18 <gmaxwell> Ry4an: no, thats not really how _attacks_ work, they're not uncorrelated. And in a consensus system otherwise harmless behaviors become fatal bugs because being _consistent_ is important.
338 2013-06-20 14:04:44 <MC1984> sometimes someone says something that reminds you that bitcoin is essentially a hectare of spinning plates
339 2013-06-20 14:05:38 <TD> lol
340 2013-06-20 14:05:39 <TD> brilliant quote
341 2013-06-20 14:05:42 <TD> we should have it on our website
342 2013-06-20 14:06:47 <TD> i put in sending a mempool message after version nego, and my bitcoind is sitting at around 400mb rss
343 2013-06-20 14:06:58 <sipa> sounds good
344 2013-06-20 14:07:11 <TD> right
345 2013-06-20 14:07:13 <TD> home time
346 2013-06-20 14:26:47 <saivann> jgarzik : I guess that if you are the owner of the github rep, the first solution mentionned should work
347 2013-06-20 14:26:49 <saivann> https://help.github.com/articles/blocking-a-user
348 2013-06-20 14:27:13 <saivann> (I doubt that it will work in my case, I have pull access only)
349 2013-06-20 14:43:11 <LordOfTime> EC2|is it possible to run the bitcoin-qt client from a flash drive on $anysystem ?
350 2013-06-20 14:43:19 <bx_> hey bro
351 2013-06-20 14:43:22 <bx_> Any coders here
352 2013-06-20 14:43:24 <LordOfTime> EC2|(where $anysystem is a placeholder to mean "any system in existence)
353 2013-06-20 14:43:51 <sipa> dunno... are there still OS/2 systems in existence?
354 2013-06-20 14:43:58 <LordOfTime> EC2|sipa: okay, any MODERN systems
355 2013-06-20 14:44:08 <MC1984> im doing it
356 2013-06-20 14:44:30 <sipa> including recent ubuntu's on x86/x86_64, recent windows, recent OSX'es... sure
357 2013-06-20 14:44:46 <MC1984> theres no real portable mode so the drive has to be mounted as the same volume on each computer
358 2013-06-20 14:45:22 <jgarzik> LordOfTime|EC2, sure, as long as you have 10GB of space or so, plus sufficient memory
359 2013-06-20 14:45:33 <sipa> MC1984: -datadir ?
360 2013-06-20 14:45:39 <LordOfTime> EC2|jgarzik: 32GB USB drive should be more than enough
361 2013-06-20 14:45:49 <MC1984> yeah
362 2013-06-20 14:45:50 <LordOfTime> EC2|jgarzik: besides, i have a 10.2GB copy of the blockchain on a 16GB drive :P
363 2013-06-20 14:46:04 <LordOfTime> EC2|i could probably run the client from that :P
364 2013-06-20 14:46:11 <MC1984> and you still cant load a bitcoin.conf from the -datadir
365 2013-06-20 14:46:47 <MC1984> most littl flash drives are ultrashit in write performance
366 2013-06-20 14:47:03 <MC1984> mine took all night to catch up 11 days of blocks
367 2013-06-20 14:48:02 <LordOfTime> EC2|MC1984: USB 3.0 drive ;)
368 2013-06-20 14:48:38 <LordOfTime> EC2|my point was is it possible not is it universally feasible
369 2013-06-20 14:54:04 <gjs278> of course it's possible
370 2013-06-20 14:54:16 <gjs278> you can run it on any filesystem
371 2013-06-20 14:58:48 <MC1984> its not the interface
372 2013-06-20 14:58:52 <MC1984> its the flash controlles
373 2013-06-20 14:59:30 <allban> well for windows you can use thinapp or thelike
374 2013-06-20 14:59:32 <MC1984> usually produced in china in the same building where noodles are churned out by the tonne
375 2013-06-20 15:03:16 <Diablo-D3> [12:41:16] <sipa> dunno... are there still OS/2 systems in existence?
376 2013-06-20 15:03:20 <Diablo-D3> yes, but they're all os/2 fanboys
377 2013-06-20 15:03:34 <jgarzik> or cash registers
378 2013-06-20 15:07:45 <Diablo-D3> jgarzik: that scares the fuck out of me
379 2013-06-20 15:09:11 <saivann> jgarzik : Ah, blocking MillyBitcoin didn't work
380 2013-06-20 15:09:31 <jgarzik> saivann, nope. I think we need Gavin or MT to do it
381 2013-06-20 15:14:04 <MC1984> ive seen some os/2 atm machines around still i think
382 2013-06-20 15:14:23 <MC1984> usually ones with fag burns all over the inside, and smells of piss
383 2013-06-20 15:18:32 <jgarzik> MC1984, a fag? What colour were the burns? Was a sleeping policeman nearby? :)
384 2013-06-20 15:18:47 <jgarzik> ACTION fishes out every Brit-ism he can think of
385 2013-06-20 15:19:35 <MC1984> chopsin m8?
386 2013-06-20 15:20:56 <MC1984> we havent called them sleeping policemen since the 60s
387 2013-06-20 15:21:20 <MC1984> we call them god damn fucking exhaust scrapers
388 2013-06-20 15:21:39 <jgarzik> heh
389 2013-06-20 15:22:04 <MC1984> cos councils chaged to bolting down square rubber mat things into the tarmac that are about 8 inches in height
390 2013-06-20 15:22:19 <handle> whois Diablo-D3
391 2013-06-20 15:22:32 <jgarzik> handle, nobody knows.
392 2013-06-20 15:22:39 <jgarzik> handle, he might be Satoshi, is the current speculation
393 2013-06-20 15:22:40 <handle> :P
394 2013-06-20 15:22:45 <handle> haha
395 2013-06-20 15:22:49 <MC1984> cos they worked out joyriders just see the old types as happy fun ramps
396 2013-06-20 15:23:02 <handle> sorry Diablo-D3, wanted to make sure I was still connected
397 2013-06-20 15:23:36 <jgarzik> MC1984, hah, creative
398 2013-06-20 15:24:09 <MC1984> yeah
399 2013-06-20 15:24:40 <MC1984> theres one roard in town that has them every 50 feet, a ?20,000 speed camera and a limit of 20mph
400 2013-06-20 15:24:47 <MC1984> a councillor lives on that road, by complete coincidence
401 2013-06-20 15:27:52 <jgarzik> total and complete coincedence
402 2013-06-20 15:45:44 <grau> sipa: How do you think a wallet server would work without being backed by a full node?
403 2013-06-20 15:47:50 <sipa> grau: i don't mean it can't maintain blocks or a mempool or a utxo set
404 2013-06-20 15:48:09 <sipa> grau: but there's no need to give it the responsability of verifying
405 2013-06-20 15:51:04 <sipa> if anything, i want to separate those in bitcoind as well
406 2013-06-20 15:55:11 <grau> one can not maintain a wallet without verifying transactions. If verification would be a separate module in bitcoind I would call it.
407 2013-06-20 15:56:45 <gmaxwell> grau: Parsing your own transactions isn't the same as verifying the network.
408 2013-06-20 15:57:11 <sipa> yes that's what i'd like to move to: have bitcoind only do p2p network and verification
409 2013-06-20 15:57:33 <grau> sipa: that is what my server does.
410 2013-06-20 15:57:59 <sipa> grau: i wouldn't trust myself to implement it from scratch
411 2013-06-20 15:58:01 <grau> if bitcoind was that way I would not have to write it
412 2013-06-20 15:58:30 <grau> sipa: well I also had to underestimate the problem to do it.
413 2013-06-20 16:00:56 <sipa> well it's not particularly hard to just not use anything bitcoind does you don't need
414 2013-06-20 16:02:32 <sipa> anyway, i don't want to claim bitcoind is superior in an way - rather the opposite - but i'm afraid of the complexity of having
415 2013-06-20 16:02:35 <sipa> anyway, i don't want to claim bitcoind is superior in an way - rather the opposite - but i'm afraid of the complexity of having
416 2013-06-20 16:03:10 <sipa> anyway, i don't want to claim bitcoind is superior in an way - rather the opposite - but i'm afraid of the complexity of having N different verifiers on the network, with N^2 ways in which they conflict with eachother
417 2013-06-20 16:03:19 <sipa> it's likely inevitable
418 2013-06-20 16:03:41 <grau> Do you think it is realistic to adapt bitcoind to different uses?
419 2013-06-20 16:03:53 <sipa> i don't think it needs any other use
420 2013-06-20 16:04:23 <sipa> if you want to write a fast wallet server that stores and indexes and serves clients, perfect
421 2013-06-20 16:04:24 <BlueMatt> ACTION sure as hell hopes no one starts mining on any alt implementations until our test coverage goes up a few orders of magnitude
422 2013-06-20 16:04:49 <BlueMatt> ACTION would like to see bitcoin-qt and all bitcoind wallet parts get ripped out
423 2013-06-20 16:04:52 <sipa> and put it behind a bitcoin daemon so it only sees verified stuff
424 2013-06-20 16:05:22 <grau> it is a bit more complex than seeing only verified
425 2013-06-20 16:05:25 <sipa> that's what i mean: bitcoind is giving a very bad example about how to write software, by not showing how concerns can be separated
426 2013-06-20 16:05:42 <sipa> grau: for example?
427 2013-06-20 16:05:50 <grau> you need proper notification of reorgs to see if a transaction is rendered double spend in retrospective
428 2013-06-20 16:06:11 <BlueMatt> you get that
429 2013-06-20 16:06:19 <BlueMatt> I mean you have to be an spv node at least
430 2013-06-20 16:06:38 <sipa> grau: well, your server can do that, no?
431 2013-06-20 16:06:40 <grau> BlueMatt: I have a bus protocol that does that without SPV
432 2013-06-20 16:07:06 <BlueMatt> you are doing the same logic either way, whether its in your wallet or in some other trusted daemon
433 2013-06-20 16:07:35 <grau> sipa: yes it can. That is why I mean bitcoind would need to be extended with some similar communication so you can connect extensions that delegate verification
434 2013-06-20 16:07:39 <BlueMatt> whether full verification happens there is entirely irrelevant for a wallet
435 2013-06-20 16:07:55 <BlueMatt> meh, just make an spv node
436 2013-06-20 16:07:55 <sipa> grau: just talk P2P protocol with it, and maintain your own best chain
437 2013-06-20 16:07:59 <sipa> grau: like an SPV node
438 2013-06-20 16:08:11 <sipa> and leave the verification to bitcoind
439 2013-06-20 16:08:20 <BlueMatt> and, yea, you dont even have to do as much verification as a standard spv node if you trust the only bitcoind you're connected to
440 2013-06-20 16:08:43 <sipa> that server can then notify whatever it wants in whatever way they want about reorganizations or new transactions or alerts or whatever
441 2013-06-20 16:09:20 <sipa> maybe it feels bad to duplicate the logic for maintaining a best chain
442 2013-06-20 16:09:43 <sipa> but it's imho a lot less dangerous than trying to do everything from scratch
443 2013-06-20 16:10:12 <BlueMatt> the amount of logic you actually duplicate is quite low
444 2013-06-20 16:10:22 <BlueMatt> (compared to the amount of logic in a wallet to begin with)
445 2013-06-20 16:10:28 <sipa> (which doesn't mean there shouldn't be any competition about verification implementations, only that it can be done entirely separate then)
446 2013-06-20 16:11:41 <sipa> and it's certainly a "do as i say, don't do as i do", because so far it doesn't seem like bitcoind will be splitting off responsabilities soon :(
447 2013-06-20 16:11:59 <grau> sipa: I do not get you now. How could there be competition and have only bitcoind
448 2013-06-20 16:12:03 <grau> verifing
449 2013-06-20 16:12:17 <sipa> grau: i'm not saying there should be only bitcoind
450 2013-06-20 16:12:35 <sipa> grau: i'm saying that to implement a wallet service, you don't need to implement verification
451 2013-06-20 16:12:40 <sipa> you can use bitcoind
452 2013-06-20 16:12:47 <sipa> and maybe others can write a full node implementation
453 2013-06-20 16:12:52 <sipa> that maybe over time can get trusted
454 2013-06-20 16:12:55 <grau> but you said competition in verification
455 2013-06-20 16:13:11 <sipa> but they can develop independently: verification implementations, and wallet implementations
456 2013-06-20 16:13:20 <sipa> and i expect the latter to have much more innovation
457 2013-06-20 16:13:41 <sipa> if every wallet implementation however starts by reimplementation full verification, that is burdening
458 2013-06-20 16:14:16 <grau> I know, but now I offer a verifying server the thing you would want to se, but is not bitcoind.
459 2013-06-20 16:14:40 <grau> and it can be used to build different wallets on it and I hope people will innnovate. I certainly wil
460 2013-06-20 16:14:43 <sipa> but can i use your server if i don't trust its capability as a verification engines?
461 2013-06-20 16:14:59 <sipa> (regardless of whether there is reason for that)
462 2013-06-20 16:15:02 <BlueMatt> can you switch off full verification and still use the wallet?
463 2013-06-20 16:15:25 <grau> What would create trust? Eg. that it is running in sync since quite a few months?
464 2013-06-20 16:15:48 <BlueMatt> that really doesnt mean much
465 2013-06-20 16:15:48 <sipa> i'm much more concerned about it accepting things that it shouldn't than the other way around
466 2013-06-20 16:16:05 <sipa> and that is much harder to test
467 2013-06-20 16:16:15 <BlueMatt> what would create trust is writing test-cases that get large test coverage of bitcoind and then proving that your implementation passes them too
468 2013-06-20 16:16:28 <BlueMatt> that + lots of code review
469 2013-06-20 16:16:51 <BlueMatt> sadly getting reviewers for something this large and which requires this much expertise is not easy...
470 2013-06-20 16:17:38 <jrmithdobbs> thought the foundation or whatever was supposed to be devoting funds to getting someone to do that?
471 2013-06-20 16:18:05 <BlueMatt> they are hiring a qa person, I dont think thats the same as creating general test-cases for all bitcoin implementations
472 2013-06-20 16:18:07 <BlueMatt> but, we'll see
473 2013-06-20 16:18:23 <BlueMatt> gavin is big on test plans and integration testing over unit tests, so it doesnt seem like it
474 2013-06-20 16:26:04 <grau> sipa: what do you think of adding a trusted channel to bitcoind similar to the bus I have, so it would be efficient to build clients (Wallets) and extensions to it that do not need verification.
475 2013-06-20 16:27:01 <grau> at some point people would migrate to those wallets and bitcoind could be stripped down to verification.
476 2013-06-20 16:27:14 <sipa> grau: someone wrote a ZeroMQ server implementation for bitcoind
477 2013-06-20 16:27:30 <sipa> through which you can listen for new block events and other things
478 2013-06-20 16:27:35 <sipa> but i don't know the details
479 2013-06-20 16:28:28 <sipa> but if you're talking about stripping it to pure verification/p2p, i'd argue that even notifying others about such event should be dealt with externally
480 2013-06-20 16:28:40 <grau> What do you think of a joint project? I would buy into if it is close to the bus I have
481 2013-06-20 16:28:58 <sipa> what kind of notifications do you need?
482 2013-06-20 16:29:15 <sipa> or queries
483 2013-06-20 16:30:28 <grau> a feed of transactions verified, that also identify those reverted. a feed of reorgs. query by extended public key and bloom filter, supscription by bloom filter (all verified)
484 2013-06-20 16:31:11 <sipa> querying by key/address/script is not in the scope of a verification engine
485 2013-06-20 16:31:15 <grau> and it has to be async not sync RPC but publish subscribe
486 2013-06-20 16:31:19 <sipa> you need a featureful index for that
487 2013-06-20 16:32:34 <grau> Yes query is not strictly in scope, but it is efficient if supported since e.g. only the verification engine knows the current trunk
488 2013-06-20 16:32:46 <sipa> that's my point
489 2013-06-20 16:33:02 <sipa> it doesn't need to be the only thing that knows the current trunk
490 2013-06-20 16:33:19 <sipa> every SPV wallet also knows the current best chain, it's cheap to do
491 2013-06-20 16:34:19 <grau> sipq: we are moving in circles, either you want to redice complexity for clients so they innovate elsewhere or not
492 2013-06-20 16:34:57 <sipa> the point is that if you don't object to duplicating a tiny bit (maintaining a chain), innovation can happen separately
493 2013-06-20 16:35:31 <grau> so you suggest a trusted SPV?
494 2013-06-20 16:35:38 <sipa> if you insist on having just one server that knows the best chain (like bitcoind now, which is why i say i find it sad that everyone copies that), then you have no choice but to put all logic in a single server
495 2013-06-20 16:36:07 <sipa> i'm suggesting a very minimal service, that receives blocks and transactions, and indexes them, and implements your bus protocol
496 2013-06-20 16:36:17 <sipa> but does not do any effort to validate its correctness
497 2013-06-20 16:36:26 <sipa> you place it behind something that verifies
498 2013-06-20 16:37:37 <gmaxwell> [p2p daemon] - [indexing daemon] - [wallet] if you want.
499 2013-06-20 16:37:40 <sipa> when i say splitting off the wallet from bitcoind, i mean making it an SPV node to still connects to a bitcoind (or spawns one in the background)
500 2013-06-20 16:37:53 <sipa> so that will also imply it maintaining its own best chain
501 2013-06-20 16:38:10 <grau> what is the protocol between p2p and indexing?
502 2013-06-20 16:38:22 <sipa> the P2P protocol
503 2013-06-20 16:38:38 <sipa> it can ignore pretty much everything except tx and block messages
504 2013-06-20 16:38:50 <sipa> i believe people have already written python scripts that just do that
505 2013-06-20 16:38:52 <grau> the indexing only connects the trusted p2p?
506 2013-06-20 16:39:02 <sipa> yes, or even multiple, for failover
507 2013-06-20 16:41:20 <grau> the indexing deamon would be SPV right?
508 2013-06-20 16:41:27 <sipa> SPV or even less
509 2013-06-20 16:41:53 <grau> can not be less, how to figure the trunk otherwise through p2p?
510 2013-06-20 16:42:02 <sipa> it can assume the blocks it sees satisfy proof-of-work, for example
511 2013-06-20 16:42:18 <sipa> but that's not worth removing
512 2013-06-20 16:42:25 <sipa> unless you're on some TI-83 CPU
513 2013-06-20 16:42:39 <sipa> so yes, i'd say it's SPV
514 2013-06-20 16:43:00 <sipa> that gives you a very nice modularization: want full verification? run a verification server
515 2013-06-20 16:43:14 <sipa> want thin-client wallets? run an index server
516 2013-06-20 16:43:22 <sipa> want an SPV wallet? run an SPV wallet client
517 2013-06-20 16:43:50 <sipa> all three are completely independent from eachother (though running thin-client wallets without verification would be stupid in many cases...)
518 2013-06-20 16:46:01 <sipa> there's one more thing being duplicated though... the block data
519 2013-06-20 16:46:45 <Mad7Scientist> 0.8.2 isn't accepting connections from all of my miners
520 2013-06-20 16:46:53 <grau> Yes, the indexing daemon is not just index but full blockchain store
521 2013-06-20 16:46:55 <Mad7Scientist> 3 hosts are mining, and only 2 can connect
522 2013-06-20 16:47:33 <Luke-Jr> Mad7Scientist: p2pool or BFGMiner?
523 2013-06-20 16:47:35 <sipa> Mad7Scientist: if you shutdown those 3, can the 2 others connect?
524 2013-06-20 16:47:44 <Mad7Scientist> solo mining
525 2013-06-20 16:48:02 <Mad7Scientist> 2 of 3 are connecting
526 2013-06-20 16:48:05 <sipa> Luke-Jr: solo, a few GH/s on GPUs to a single bitcoind
527 2013-06-20 16:48:21 <sipa> Mad7Scientist: ok, if you shut those 2 down, can the 3rd one then connect?
528 2013-06-20 16:48:22 <Luke-Jr> Mad7Scientist: Are you using the --coinbase-addr option?
529 2013-06-20 16:48:30 <Mad7Scientist> just -server
530 2013-06-20 16:48:36 <sipa> Luke-Jr: ???
531 2013-06-20 16:48:42 <Luke-Jr> Mad7Scientist: I mean with BFGMiner
532 2013-06-20 16:48:54 <sipa> why do you think he's using BFGminer?
533 2013-06-20 16:48:57 <Luke-Jr> sipa: my initial guess is that he's using deprecated getwork, and bitcoind can't handle the load
534 2013-06-20 16:49:03 <Luke-Jr> only BFGMiner supports GBT in solo mode
535 2013-06-20 16:49:14 <Luke-Jr> afaik
536 2013-06-20 16:49:15 <sipa> Luke-Jr: my guess he's using GUIminer or something
537 2013-06-20 16:49:21 <Mad7Scientist> yes
538 2013-06-20 16:49:25 <sipa> and certainly it's getwork-based
539 2013-06-20 16:49:30 <sipa> but he says 0.7 works and 0.8 doesn't
540 2013-06-20 16:49:35 <Luke-Jr> hmm
541 2013-06-20 16:49:40 <Mad7Scientist> 0.8.1 works
542 2013-06-20 16:49:48 <sipa> and 0.8.2 doesn't?
543 2013-06-20 16:49:52 <Mad7Scientist> correct
544 2013-06-20 16:49:57 <Mad7Scientist> I shut down two mining hosts
545 2013-06-20 16:49:58 <Luke-Jr> O.o
546 2013-06-20 16:49:58 <owowo> Mad7Scientist: why don't you join p2pool?
547 2013-06-20 16:50:01 <Mad7Scientist> and the 3rd one connects
548 2013-06-20 16:50:03 <sipa> then it's the threading overhaul
549 2013-06-20 16:50:06 <Mad7Scientist> solo works fine for me
550 2013-06-20 16:50:26 <sipa> Mad7Scientist: can you compile from source?
551 2013-06-20 16:50:30 <Mad7Scientist> I think one of the three miners on the 3rd host is still not connecting
552 2013-06-20 16:50:37 <Mad7Scientist> I don't know if I can compile
553 2013-06-20 16:50:42 <sipa> ok
554 2013-06-20 16:50:44 <Mad7Scientist> I have debian
555 2013-06-20 16:51:04 <Luke-Jr> shouldn't be too hard then
556 2013-06-20 16:51:04 <sipa> i know of a change in the source code that would likely help
557 2013-06-20 16:51:29 <sipa> increasing the number of RPC threads should help
558 2013-06-20 16:52:00 <Mad7Scientist> what do I need to install to build this
559 2013-06-20 16:52:16 <sipa> but really, run p2pool and you'll have much steadier income, and less load on bitcoin
560 2013-06-20 16:52:30 <Mad7Scientist> I see the readme file
561 2013-06-20 16:52:40 <sipa> if you really hate pool fees, you can set them to 0 for p2pool
562 2013-06-20 16:53:00 <Mad7Scientist> how could solo mining not produce the least load?
563 2013-06-20 16:53:14 <Luke-Jr> or any pool
564 2013-06-20 16:53:16 <sipa> because bitcoind isn't designed to constantly generate new work
565 2013-06-20 16:53:21 <sipa> p2pool or any poolserver is
566 2013-06-20 16:53:34 <Luke-Jr> least load = getwork centralized pool
567 2013-06-20 16:53:36 <grau> sipa: I could actually make Bits of Proof behave an "indexing deamon" quite quickly. All I need is to force connection to a single trusted node and skip all verifications.
568 2013-06-20 16:53:43 <Luke-Jr> but that's crazy to use today
569 2013-06-20 16:54:02 <sipa> grau: yes, that's what i was aiming at, i'm expecting you have almost all pieces in play
570 2013-06-20 16:54:13 <sipa> grau: btw, doesn't mean you need to make that the only way of operation
571 2013-06-20 16:54:41 <grau> I am following up with this idea. Thank you very much for pointing me to this.
572 2013-06-20 16:54:45 <sipa> but i think saying that you have the option of doing verification in a trusted bitcoind is an asset
573 2013-06-20 16:55:05 <grau> That is why I got interested.
574 2013-06-20 16:55:31 <sipa> now we only need to get rid of bitcoind storing all blocks :p
575 2013-06-20 16:55:45 <jgarzik> ;p
576 2013-06-20 16:56:15 <gmaxwell> leveldb corruption issues need to be completely solved before pruning is an exposed option. :P
577 2013-06-20 16:56:19 <sipa> jgarzik: did you get to test that wallet patch yesterday?
578 2013-06-20 16:56:32 <sipa> gmaxwell: yeah... we better get those 386's that NASA uses out...
579 2013-06-20 16:56:49 <jgarzik> sipa, heh, just sat down to do that. Want to get it in ASAP
580 2013-06-20 16:57:38 <DiabloD3> gmaxwell: leveldb corruption? =/
581 2013-06-20 16:58:08 <sipa> jgarzik: so what i'm aiming at is changing the key storage in the wallet, where just (keyid,privkey,checksum,metadata,keypoolinfo) are stored once for each key, instead of 3x pubkey + 1 hugely overcomplex privkey representation + metadata
582 2013-06-20 16:58:20 <gmaxwell> DiabloD3: OSX users seem to reporting random corruption.
583 2013-06-20 16:58:25 <grau> I have not yet had a leveldb corruption. Is there a known problem or just mistery?
584 2013-06-20 16:58:27 <DiabloD3> oh, on osx
585 2013-06-20 16:58:29 <DiabloD3> meh
586 2013-06-20 16:58:29 <gmaxwell> It may be OSX specific.
587 2013-06-20 16:58:32 <DiabloD3> bitcoin still sucks badly on osx
588 2013-06-20 16:58:32 <sipa> grau: to me it's a mystery
589 2013-06-20 16:58:39 <sipa> grau: linux users have reported it as well
590 2013-06-20 16:58:42 <sipa> eh gmaxwell:
591 2013-06-20 16:59:09 <sipa> grau: on my own systems i've never ever been able to reproduce a leveldb error
592 2013-06-20 16:59:26 <sipa> grau: including with tests like forcefully powering down mid-sync
593 2013-06-20 16:59:38 <sipa> while others get it consistently
594 2013-06-20 17:00:36 <grau> I had a few core dumps if memory was set very low. But even that did not corrupt it.
595 2013-06-20 17:00:59 <gmaxwell> The consistently is what concerns me... I do expect some random failures here and there.
596 2013-06-20 17:01:34 <sipa> gmaxwell: coingenuity reported he has had 0.8.x crash like 10 times already on linux, mid-sync (so not at startup, just during operation a corruption was detected)
597 2013-06-20 17:01:46 <sipa> gmaxwell: on a brand new server-class hardware
598 2013-06-20 17:02:09 <Mad7Scientist> Do i need to have CXXFLAGS set before running qmake?
599 2013-06-20 17:02:13 <sipa> Mad7Scientist: no
600 2013-06-20 17:02:25 <Mad7Scientist> so it automatically does optimizations
601 2013-06-20 17:02:28 <gmaxwell> coingenuity was also reporting some crazy bad performance on one of the amd apu chips.
602 2013-06-20 17:02:28 <sipa> yes
603 2013-06-20 17:04:58 <Mad7Scientist> are -march= lines not of much use on 64-bit systems?
604 2013-06-20 17:05:05 <diki> When a pool requests work from the bitcoin server, which part can be rolled so that it instead of requesting a work unit from the server every time a worker requests one, it can generate it locally?
605 2013-06-20 17:05:26 <Mad7Scientist> since it is not defaulting to an 80's architecture
606 2013-06-20 17:11:16 <gmaxwell> Mad7Scientist: IIRC GCC -march default on x86 is i686 now. (at least it is on my system). Also, IIRC as of 4.8 i386 arch is deprecated.
607 2013-06-20 17:13:49 <MC1984> sipa brand new doesnt automatically mean known to work
608 2013-06-20 17:13:55 <MC1984> bathtub curve and all that
609 2013-06-20 17:15:33 <Luke-Jr> gmaxwell: but what about my 486-SX machine???
610 2013-06-20 17:15:34 <sipa> true, though it's not a 10 year old overclocked winXP machine
611 2013-06-20 17:16:59 <gmaxwell> Luke-Jr: will still work with the right arch flag. i386 lacks a bunch of the atomic operators and gcc had to have a ton of code to emulate them.. and apparently the C++11 atomics required even more from them, so as I recall they decided to drop i386. i486 is still supported iirc.
612 2013-06-20 17:17:09 <Mad7Scientist> what package do I need to install to build upnp support?
613 2013-06-20 17:17:14 <Luke-Jr> :p
614 2013-06-20 17:18:48 <Mad7Scientist> I guess my debian doesn't have it
615 2013-06-20 17:18:51 <sipa> Mad7Scientist: qmake USE_UPNP=-
616 2013-06-20 17:18:56 <sipa> and just disable upnp
617 2013-06-20 17:19:01 <MC1984> you know theres a reason nasa takes those 486 chips into space
618 2013-06-20 17:19:19 <MC1984> perhaps sipa has acidentally created the worlds most distributed solar activity array
619 2013-06-20 17:19:22 <Scrat> they have massive transistors which cant be flipped by cosmic rays
620 2013-06-20 17:19:23 <Scrat> hur
621 2013-06-20 17:19:35 <sipa> tin-foit hat CPU's
622 2013-06-20 17:19:39 <sipa> *foil
623 2013-06-20 17:19:50 <MC1984> hurr
624 2013-06-20 17:19:56 <Mad7Scientist> ok
625 2013-06-20 17:20:50 <Mad7Scientist> $ qmake USE_UPNP=-q
626 2013-06-20 17:20:51 <Mad7Scientist> Project MESSAGE: Building with UPNP support
627 2013-06-20 17:20:54 <Mad7Scientist> still says on
628 2013-06-20 17:22:08 <Mad7Scientist> oh it is a variable
629 2013-06-20 17:22:42 <Mad7Scientist> there it worked
630 2013-06-20 17:28:16 <BlueMatt> sipa: not sure it counts if it turned out to be true (they've already had one of the primary cpus fail, iirc they have 3 redundant ones)
631 2013-06-20 17:36:38 <dugo> 20 years after it would be a serious porting efoort to bring NetBSD back on the 386 where it hatched
632 2013-06-20 17:38:51 <dugo> speaking of which, we recently discovered the original encumbered Net/2 based NetbSD 0.8 sources complete with the 71 files missing in CVS
633 2013-06-20 17:42:43 <petertodd> http://virtual-notary.org <- first service that doesn't do one tx per timestamp, other than my opentimestamps stuff
634 2013-06-20 17:43:14 <sipa> and chronobit?
635 2013-06-20 17:43:17 <petertodd> though they're still idiots: they make two txouts for one 64byte hash
636 2013-06-20 17:43:24 <petertodd> chronobit isn't a service :)
637 2013-06-20 17:43:26 <sipa> (though that is technically not a service)
638 2013-06-20 17:43:27 <sipa> right
639 2013-06-20 17:45:22 <TheLordOfTime> sipa: data directory for bitcoin-qt on windows default is %APPDATA%/.bitcoin right?
640 2013-06-20 17:45:28 <sipa> yes