1 2012-12-06 00:00:59 <nanotube> i'll put it on my desktop calendar as a backup just in case :)
2 2012-12-06 00:01:28 <gribble> The operation succeeded. Event #11 added.
3 2012-12-06 00:01:28 <nanotube> ;;scheduler add 30 echo moo
4 2012-12-06 00:01:58 <gribble> moo
5 2012-12-06 00:02:03 <nanotube> \\o/
6 2012-12-06 00:03:07 <gavinandresen> oooh, eleven is my favorite number
7 2012-12-06 00:03:14 <nanotube> gavinandresen: btw fyi this was the timeline for last year: http://www.google-melange.com/document/show/gsoc_program/google/gsoc2012/faqs?ModPagespeed=noscript#timeline
8 2012-12-06 00:04:10 <nanotube> there are 11 kinds of people in the world, those who understand binary, those who don't, and those who don't know what i'm talking about. :)
9 2012-12-06 00:04:25 <phantomcircuit> gavinandresen, can there be a subcommittee to review the findings of the subcommittee?
10 2012-12-06 00:04:30 <phantomcircuit> pleasssse
11 2012-12-06 00:04:40 <nanotube> committee on committees
12 2012-12-06 00:04:50 <nanotube> there actually is one in my university.
13 2012-12-06 00:04:57 <gavinandresen> phantomcircuit: good idea. I'll bring it up for a vote at the next committee-organizing-committee meeting
14 2012-12-06 00:05:08 <gmaxwell> and a subcommittee subcomittee ombudsman to hear appeals about the committee-committee?
15 2012-12-06 00:05:12 <phantomcircuit> all of a sudden
16 2012-12-06 00:05:16 <phantomcircuit> COMMITTEES
17 2012-12-06 00:07:34 <nanotube> but then we have to have a subcommittee subcomittee ombudsman oversight committee, or else the ombudsman can just do whatever he wants and we can't have that!
18 2012-12-06 00:09:19 <sipa> it's just committees all the way down!
19 2012-12-06 00:10:18 <nanotube> heh
20 2012-12-06 00:10:29 <nanotube> the only way to escape is to set up a loop.
21 2012-12-06 00:10:35 <sipa> no no no
22 2012-12-06 00:10:39 <sipa> to iterate is human
23 2012-12-06 00:11:09 <nanotube> to loop, divine? :)
24 2012-12-06 00:11:15 <sipa> to recurse, divine
25 2012-12-06 00:11:18 <nanotube> heh
26 2012-12-06 00:11:20 <sipa> so you have to recurse: let the committee oversee itself
27 2012-12-06 00:11:22 <sipa> :p
28 2012-12-06 00:11:28 <nanotube> ok that works :)
29 2012-12-06 00:20:32 <gmaxwell> TIL:
30 2012-12-06 00:20:33 <gmaxwell> -2
31 2012-12-06 00:21:02 <gmaxwell> I wonder how much of my code thats subtly broken over the years.
32 2012-12-06 00:23:01 <nanotube> heh yea python integer math has caused much wailing over the years.
33 2012-12-06 00:23:31 <nanotube> and yea, -3/2 = -2 is... weird.
34 2012-12-06 00:23:52 <Diablo-D3> okay so
35 2012-12-06 00:23:56 <Diablo-D3> nefario is a fucking faggot
36 2012-12-06 00:24:20 <Diablo-D3> nanotube: erm, -3/2 is -1.5
37 2012-12-06 00:24:21 <Diablo-D3> oh
38 2012-12-06 00:24:22 <Diablo-D3> nm, carry on
39 2012-12-06 00:24:33 <nanotube> heh
40 2012-12-06 00:27:55 <gmaxwell> nanotube: yea, it's not truncating. it's towards negative infinity.
41 2012-12-06 00:28:44 <sipa> it always rounds down?
42 2012-12-06 00:29:24 <gmaxwell> Yes.
43 2012-12-06 00:29:25 <gmaxwell> Yes.
44 2012-12-06 00:29:38 <gmaxwell> like shifting would.
45 2012-12-06 00:30:53 <nanotube> yep i gathered once i saw. still weird :)
46 2012-12-06 00:33:07 <Diablo-D3> its not weird
47 2012-12-06 00:33:15 <Diablo-D3> I think you can set integer rounding modes in C
48 2012-12-06 00:33:39 <Diablo-D3> dunno why python wouldnt either bankers round or round to zero by default though
49 2012-12-06 00:39:33 <D34TH> jgarzik i have it down to one error
50 2012-12-06 00:39:34 <D34TH> :D
51 2012-12-06 00:40:19 <D34TH> or it seems that way
52 2012-12-06 00:46:45 <D34TH> jgarzik, doesnt O_LARGEFILE make it 64bit only?
53 2012-12-06 00:48:29 <Diablo-D3> no
54 2012-12-06 00:48:57 <D34TH> it seems it will on winblows
55 2012-12-06 00:49:14 <Diablo-D3> windows does not implement the posix file api
56 2012-12-06 00:49:25 <D34TH> yea
57 2012-12-06 00:49:38 <D34TH> im working my ass off to find a win32 compat implementation
58 2012-12-06 00:49:46 <Diablo-D3> D34TH: mingw
59 2012-12-06 00:49:53 <D34TH> i'm using mingw
60 2012-12-06 00:49:59 <D34TH> doesnt support O_LARGEFILE
61 2012-12-06 00:50:06 <Diablo-D3> then just dont use it
62 2012-12-06 00:50:16 <Diablo-D3> windows transparently supports files >4gb in size on file systems that do
63 2012-12-06 00:50:20 <Diablo-D3> (ie, no fat32)
64 2012-12-06 00:54:24 <D34TH> im going to cry at net.c
65 2012-12-06 00:54:25 <D34TH> im going to cry at net.c
66 2012-12-06 00:57:42 <midnightmagic> will DoS protections kick in if a bad block is passed, or just an illegal tx?
67 2012-12-06 01:01:35 <gmaxwell> It should generally be things that _no_ node should have passed, especially if they were costly for you to verify.
68 2012-12-06 01:02:39 <midnightmagic> just wondering whether it would be worthwhile to detect a non-conformant node by passing it bad data which is normally rejected in some detectable way..
69 2012-12-06 01:02:53 <midnightmagic> "hey you're not a real bitcoin!" (report to trusted nodes)
70 2012-12-06 01:04:26 <midnightmagic> so was that you polluting p2pool tx with a negative txout.nValue?
71 2012-12-06 01:11:50 <jgarzik> D34TH: just "#define O_LARGEFILE /* nothing */" and move on
72 2012-12-06 01:12:02 <D34TH> i just removed it from the code
73 2012-12-06 01:12:22 <D34TH> im working on F_{g,s}ETF:
74 2012-12-06 01:12:24 <D34TH> **FL
75 2012-12-06 01:13:24 <D34TH> i think im going to rename fakepoll to mingw-compat
76 2012-12-06 01:13:35 <D34TH> and start stuffing all compat stuff in there
77 2012-12-06 01:14:47 <Luke-Jr> jgarzik: won't that cause an error since there needs to be a value? :P
78 2012-12-06 01:15:21 <jgarzik> D34TH: don't
79 2012-12-06 01:15:27 <jgarzik> D34TH: I want to delete fakepoll ASAP
80 2012-12-06 01:15:37 <jgarzik> D34TH: compat stuff belongs in..... wait for it... compat.h
81 2012-12-06 01:15:53 <jgarzik> D34TH: fakepoll will be deleted as soon as somebody ports poll() call over to libevent
82 2012-12-06 01:16:13 <jgarzik> Luke-Jr: it was illustrative not byte for byte
83 2012-12-06 01:16:24 <D34TH> dumping compats in compat.h
84 2012-12-06 01:16:28 <Luke-Jr> jgarzik: you realize libevent is the #1 reason pushpoold fails?
85 2012-12-06 01:16:59 <Luke-Jr> jgarzik: it leaks fds like crazy
86 2012-12-06 01:17:12 <jgarzik> Luke-Jr: oh brother. libevent does not leak fds.
87 2012-12-06 01:17:13 <jgarzik> Luke-Jr: oh brother. libevent does not leak fds.
88 2012-12-06 01:17:18 <D34TH> jgarzik, i have a mingw_poll function
89 2012-12-06 01:18:24 <Luke-Jr> jgarzik: it does with pushpoold, and I probably looked into it when I used it???
90 2012-12-06 01:18:43 <jgarzik> Luke-Jr: then that's a pushpool bug, not libevent
91 2012-12-06 01:19:10 <jgarzik> D34TH: probably easier just to use select(), which is present in both windows and linux
92 2012-12-06 01:19:24 <doublec> I use libevent and it doesn't leak fd's that I've noticed
93 2012-12-06 01:19:31 <D34TH> i grabbed code from polipo that seems to work
94 2012-12-06 01:19:40 <jgarzik> doublec: yah, you have to apply the standard Luke-Jr filter
95 2012-12-06 01:20:26 <Luke-Jr> I seem to recall it assuming HTTP requests never disconnect mid-request
96 2012-12-06 01:20:31 <D34TH> weird compat.h isn't included in net.c
97 2012-12-06 01:22:20 <doublec> Luke-Jr: there's an issue of not noticing a disconnect if you don't read from the connection
98 2012-12-06 01:22:36 <doublec> Luke-Jr: workaround was to occasionally ping all connections
99 2012-12-06 01:24:11 <Luke-Jr> jgarzik: there, see. libevent issue :P
100 2012-12-06 01:25:00 <doublec> this was in in the longpolling
101 2012-12-06 01:25:17 <doublec> if the client disconnected from the longpoll you didn't know and couldn't close it immediately.
102 2012-12-06 01:25:41 <doublec> So I would periodically write newlines to the longpolled connections and then get an error if it was a disconnected one
103 2012-12-06 01:37:26 <D34TH> screw it
104 2012-12-06 01:37:28 <D34TH> cygwin time
105 2012-12-06 01:37:29 <jgarzik> doublec: was this a pushpool clone? it's easy enough to turn on the signalling necessary
106 2012-12-06 01:39:13 <doublec> jgarzik: it wasn't pushpool - another project that used libevent
107 2012-12-06 01:40:47 <doublec> jgarzik: it's entirely possible that it was user error from not using the api right
108 2012-12-06 01:42:02 <doublec> similar to this http://archives.seul.org/libevent/users/Oct-2009/msg00028.html
109 2012-12-06 01:42:03 <doublec> similar to this http://archives.seul.org/libevent/users/Oct-2009/msg00028.html
110 2012-12-06 01:55:08 <da2ce7_d> hello
111 2012-12-06 01:55:30 <da2ce7_d> today I've been trying to compile bitcoin in Visual Studio 2012
112 2012-12-06 01:55:34 <da2ce7_d> *express
113 2012-12-06 01:56:06 <da2ce7_d> I've successfully got bitcoind to compile (no bitcoin-qt yet).
114 2012-12-06 01:57:33 <da2ce7_d> CBlockIndex *CCoinsViewDB::GetBestBlock() is getting a Access violation when trying to dereference it->second
115 2012-12-06 01:57:46 <da2ce7_d> *that is a bad pointer.
116 2012-12-06 01:59:59 <da2ce7_d> I'll delve into it more when I have time.
117 2012-12-06 02:00:00 <da2ce7_d> I'll delve into it more when I have time.
118 2012-12-06 02:02:05 <sipa> da2ce7_d: there's a bugfix for that in a pullreq
119 2012-12-06 02:02:26 <da2ce7_d> :)
120 2012-12-06 02:02:30 <sipa> though it should only occur when the coindb is missing while the blockdb exists
121 2012-12-06 02:40:38 <jgarzik> doublec: oh, libevent's http server is known broken in many ways
122 2012-12-06 02:40:56 <jgarzik> doublec: so I try to distinguish between libevent core and That Other Shite :)
123 2012-12-06 02:40:58 <doublec> jgarzik: ah ok, thanks
124 2012-12-06 02:45:38 <jgarzik> sigh
125 2012-12-06 02:45:45 <jgarzik> I suppose it's time for select()
126 2012-12-06 02:45:56 <jgarzik> (for the few cases where libevent is not used)
127 2012-12-06 03:07:02 <Luke-Jr> jgarzik: so I call libevent "libevent", and you "no true scotsman" it??? and *I'm* the one with a distorted reality? :P
128 2012-12-06 03:08:19 <jgarzik> -rwxr-xr-x. 1 root root 171952 Apr 6 2012 libevent_core-2.0.so.5.1.6
129 2012-12-06 03:08:51 <jgarzik> it is quite clear libevent_core is a separate entity, from the coding to the behavior to the library split
130 2012-12-06 03:09:09 <jgarzik> libevent_core is more widely used and tested and bugfixed
131 2012-12-06 03:09:45 <jgarzik> anybody serious implementing their own HTTP server quickly runs into one of many limits. it is basically a toy server.
132 2012-12-06 03:11:45 <jgarzik> anybody serious implementing their own HTTP server quickly runs into one of many limits with libevent_extra [in case that was not clear]
133 2012-12-06 03:11:53 <jgarzik> and evhttp
134 2012-12-06 03:14:59 <weex> when bitcoind advertises other nodes does it only advertise ones with an open firewall port?
135 2012-12-06 03:15:36 <jgarzik> weex: it advertises nodes it has seen, or heard of from other nodes
136 2012-12-06 03:15:47 <jgarzik> weex: individually, a node chooses to advertise itself (or not)
137 2012-12-06 03:16:10 <weex> -nolisten?
138 2012-12-06 03:17:21 <weex> sorry that wasn't much of a question, ... i'll look at some code now
139 2012-12-06 03:17:25 <jgarzik> weex: Not just that. For example, if an SPV client on jgarzik.broadband.isp.com (a) connects to mynode.example.com, but (b) does not send out 'addr' messages containing its address, mynode.example.com should not tell any other nodes about jgarzik.broadband.isp.com
140 2012-12-06 03:17:53 <weex> nice
141 2012-12-06 03:18:26 <jgarzik> weex: mynode.example.com will only remember jgarzik.broadband.isp.com if jgarzik.broadband.isp.com sends an "addr" network message to mynode.example.com, containing the IP address for jgarzik.broadband.isp.com
142 2012-12-06 03:21:05 <weex> so basically each node either advertises itself or doesn't, and that's how their address gets on the list to be passed around?
143 2012-12-06 03:23:40 <jgarzik> weex: that's how it should work, and how it generally works :)
144 2012-12-06 03:23:42 <muhoo> will bitcoind run effectively on a cheap VPS with 512MB RAM?
145 2012-12-06 03:23:56 <doublec> not if you want to run anything else on it
146 2012-12-06 03:24:16 <jgarzik> weex: you can be purposefully malicious etc.
147 2012-12-06 03:25:09 <jgarzik> muhoo: some do, but 512MB is pushing it really hard.
148 2012-12-06 03:25:19 <weex> right, guess it's hard to protect against...reminds me of ZeroAccess
149 2012-12-06 03:25:37 <weex> advertising and losing its list of nodes so aggresively that its owners can't control the botnet
150 2012-12-06 04:23:36 <jgarzik> hmmm
151 2012-12-06 04:23:51 <jgarzik> I wonder if I'm the first client developer, ever, to code a client-side "getheaders" download?
152 2012-12-06 04:24:17 <muhoo> getheaders?
153 2012-12-06 04:24:27 <jgarzik> muhoo: header only download
154 2012-12-06 04:24:47 <muhoo> curl -I ?
155 2012-12-06 04:25:20 <jgarzik> muhoo: this is #bitcoin-dev, I am talking about a bitcoin P2P message :)
156 2012-12-06 04:25:32 <muhoo> ah
157 2012-12-06 04:27:40 <muhoo> libccoin?
158 2012-12-06 04:28:56 <muhoo> hah, that's you :-)
159 2012-12-06 04:52:52 <muhoo> it looks like you are the first
160 2012-12-06 04:53:36 <muhoo> great work
161 2012-12-06 05:49:08 <jgarzik> hah!
162 2012-12-06 05:49:19 <jgarzik> no D34TH to taunt
163 2012-12-06 05:49:51 <jgarzik> it seems this tiny recipe will give me the essence of fork(), on Windows: http://msdn.microsoft.com/en-us/library/edze9h7e%28v=vs.80%29.aspx
164 2012-12-06 05:50:01 <jgarzik> multi-process security for the win
165 2012-12-06 06:00:35 <legitnick> So I have a backup of an encrypted wallet.dat, is it possible to dump the private key or import the wallet so I can attempt to bruteforce the password?
166 2012-12-06 06:02:04 <legitnick> or would it be easier to just sign a message with the wallet?
167 2012-12-06 06:02:34 <jgarzik> legitnick: "encrypted wallet.dat" means the standard bitcoin encryption? The only thing encrypted are the private keys, not the whole wallet. If you have the wallet passphrase, you have the private keys, otherwise you don't.
168 2012-12-06 06:03:03 <jgarzik> bruteforce just means trying all possible wallet passphrases
169 2012-12-06 06:03:19 <legitnick> Yes, I know the dictionary words in the password
170 2012-12-06 06:05:28 <legitnick> I'm trying to run bitcoin with the wallet.dat so I can guess the password but it crashes everytime I try to run it
171 2012-12-06 06:07:23 <jgarzik> legitnick: Sounds like something we should debug. I'd file an issue with crash details at https://github.com/bitcoin/bitcoin/issues
172 2012-12-06 06:09:50 <legitnick> before I do that could it be an issue with the version used to backup the wallet?
173 2012-12-06 06:13:44 <jgarzik> legitnick: Does the version used to back up the wallet still load the wallet ok? Do you have a specific version number that works, and a version number that does not work?
174 2012-12-06 06:14:45 <jgarzik> legitnick: And just to double-check... you are not trying to transport a wallet from another program, are you? Bitcoin-Qt wallets do not work with Armory or Electrum, for example.
175 2012-12-06 06:14:59 <legitnick> no I'm not jgarzik
176 2012-12-06 06:15:43 <legitnick> I can get the version number tomorrow but would it be easier to just sign a message with that wallet instead of importing the entire wallet?
177 2012-12-06 06:18:18 <legitnick> "version": 70100
178 2012-12-06 06:47:14 <DMCommit> [DiabloMiner] Diablo-D3 pushed 1 new commit to master: http://git.io/7GGH8A
179 2012-12-06 07:12:03 <muhoo> jgarzik: are you developing picocoin on linux and using mingw32 to xcompile?
180 2012-12-06 07:21:43 <jgarzik> muhoo: yes
181 2012-12-06 07:29:05 <jgarzik> Instawallet is under attack???!!! - https://bitcointalk.org/index.php?topic=129398.0
182 2012-12-06 07:29:16 <jgarzik> and man
183 2012-12-06 07:29:28 <jgarzik> someone needs to teach Roger Ver how to use a decentralized client, stat.
184 2012-12-06 11:02:49 <killerstorm> Anybody wants to try Colored Bitcoin Armory? Windows build is available.
185 2012-12-06 11:03:35 <drizztbsd> eh?
186 2012-12-06 11:05:09 <killerstorm> https://bitcointalk.org/index.php?topic=106373.0
187 2012-12-06 11:06:17 <drizztbsd> it's better to implement it in bitcoin-qt imho :)
188 2012-12-06 11:06:29 <drizztbsd> and bitcoind (of course)
189 2012-12-06 11:07:41 <killerstorm> I don't mind.
190 2012-12-06 12:03:37 <TD_> Luke-Jr: i seem to having trouble reaching your DNS seed :(
191 2012-12-06 12:04:14 <Luke-Jr> looks like it died
192 2012-12-06 12:04:43 <TD_> good morning!
193 2012-12-06 12:06:53 <sipa> TD_: you're drifting west?
194 2012-12-06 12:07:07 <TD_> hm?
195 2012-12-06 12:07:11 <sipa> xkcd #448 :0
196 2012-12-06 12:08:36 <Diablo-D3> sipa: goddamnit dont remind me of that one
197 2012-12-06 12:08:44 <TD_> heh
198 2012-12-06 12:09:37 <Diablo-D3> wait
199 2012-12-06 12:09:47 <Diablo-D3> thats not the one I was thinking of
200 2012-12-06 12:09:55 <Diablo-D3> still, dont remind me of ANY xkcd
201 2012-12-06 14:01:08 <jeremias> can I create a output with zero amount for transaction?
202 2012-12-06 14:01:21 <jeremias> if the transaction has other non-zero outputs
203 2012-12-06 14:04:35 <gavinandresen> jeremias: yes, but if I recall correctly transactions with zero-valued outputs are non-standard, so they won't get relayed or mined by default
204 2012-12-06 14:05:18 <gavinandresen> (and I think an "all fees" transaction with only zero-value outputs is legal, but, again, non-standard)
205 2012-12-06 14:05:21 <epscy> jeremias: why would you want to do that?
206 2012-12-06 14:19:04 <jeremias> epscy: I had a 10 BTC bet with a friend that someone would reply with that question and won
207 2012-12-06 14:19:12 <jeremias> gavinandresen: thanks for the info
208 2012-12-06 14:21:22 <kinlo> a non-standard transaction can be mined if wanted right? It's not that the client will reject such block, it's just that miners will not include such transactions by default?
209 2012-12-06 14:21:44 <sipa> it's just a policy, not a rule
210 2012-12-06 14:21:57 <sipa> but it's enforced by most miners and almost all relaying nodes
211 2012-12-06 14:23:39 <gmaxwell> The reference client would also never make a zero value output.
212 2012-12-06 14:24:17 <kinlo> I do remember something about non-standard stuff from the source
213 2012-12-06 14:24:38 <kinlo> now you're making me read the source again
214 2012-12-06 14:26:58 <gmaxwell> kinlo: sipa did answer you. :P it can still be mined, and relayed, but the reference software (or anything with the same policy) won't do so.
215 2012-12-06 14:28:16 <sipa> so: a block with such a transaction in it is undeniably valid (changing that would be a forking change)
216 2012-12-06 14:29:14 <sipa> but most software on the network will not relay such transactions, or mine it
217 2012-12-06 14:29:53 <gmaxwell> (soft)forking change, like deploying BIP16.
218 2012-12-06 14:30:01 <sipa> right; indeed
219 2012-12-06 14:32:24 <kinlo> actually I remember something about at most x non-standard transactions per block
220 2012-12-06 14:32:25 <gavinandresen> TD_ : RE: protobuf extensions: any downside (besides bloating the spec) of slapping extensions 1000 to max; ... on all the messages, including tiny ones like Output ?
221 2012-12-06 14:32:33 <kinlo> trying to find it back in the source
222 2012-12-06 14:33:13 <TD> gavinandresen: i don't think so. the generated code for accessing extended fields is a bit different, for reasons unclear to me. you can as well just use a comment that says // Please add your own extensions starting at tag 1000 and update the wiki page at <url>
223 2012-12-06 14:33:28 <TD> it means people have to modify their local .proto file to have whatever extensions they want to use. no big hassle, really
224 2012-12-06 14:33:29 <TD> it means people have to modify their local .proto file to have whatever extensions they want to use. no big hassle, really
225 2012-12-06 14:33:33 <TD> up to you
226 2012-12-06 14:33:40 <TD> a comment with a wiki page URL is a good idea anyway
227 2012-12-06 14:34:16 <gavinandresen> TD: ok. I think I'll just add an "Extensions" section to the spec, then (and put the comment in the .proto file)
228 2012-12-06 14:34:35 <TD> ok
229 2012-12-06 14:34:40 <sipa> adding extensions aftwerwards is also backward-compatible, afaik
230 2012-12-06 14:34:54 <gavinandresen> as long as they're not required, yep
231 2012-12-06 14:35:04 <sipa> you can't add required fields anyway
232 2012-12-06 14:35:23 <TD> sure you can. you just have to make sure all readers and writers are updated to the new protocol
233 2012-12-06 14:35:38 <sipa> well, yes... but at that point there's no need for compatibility whatsoever
234 2012-12-06 14:35:42 <gavinandresen> sipa: ACK, I misunderstood what you were saying
235 2012-12-06 14:36:04 <gavinandresen> (you mean we can add the extensions command to the .proto file later and remain compatible)
236 2012-12-06 14:36:09 <sipa> gavinandresen: indeed
237 2012-12-06 14:36:25 <sipa> extensions just allows delegation of the definition at the source level
238 2012-12-06 14:36:30 <sipa> it doesn't change anything protocol wise
239 2012-12-06 14:36:46 <gavinandresen> Any objections to making Output take EITHER a bitcoin address OR a script ?
240 2012-12-06 14:36:54 <sipa> why?
241 2012-12-06 14:36:55 <TD> why?
242 2012-12-06 14:37:18 <sipa> imho, an address is a shorthand for a script anyway
243 2012-12-06 14:37:33 <gavinandresen> Suggestion from Ben Reeves-- software creating PaymentRequests might have addresses but not scripts.
244 2012-12-06 14:38:06 <sipa> they have to deal with script templates anyway if they want to spend the incoming coins
245 2012-12-06 14:38:12 <gavinandresen> (e.g. load up a merchant with a bazillion deterministic-wallet-multisig addresses, it might not know the public keys involved)
246 2012-12-06 14:38:25 <sipa> so create a pubkeyhash script?
247 2012-12-06 14:38:26 <gavinandresen> front end might be separate from the payment-processing back-end
248 2012-12-06 14:38:59 <gavinandresen> sipa: yeah... small matter of writing some code, I suppose....
249 2012-12-06 14:39:58 <gavinandresen> Ok, I think I agree with KISS, and script is more general.
250 2012-12-06 14:40:49 <gavinandresen> although... one last concern: it is a lot easier to shoot yourself in the foot if it is script instead of bitcoin address.
251 2012-12-06 14:40:56 <TD> an address IS a script, in somewhat human typable form
252 2012-12-06 14:41:05 <TD> how so?
253 2012-12-06 14:41:13 <TD> by sending money to bogus scripts?
254 2012-12-06 14:41:19 <gavinandresen> e.g. bug in your address --> script code means customers sending to an unspendable scriptpbukey
255 2012-12-06 14:41:42 <sipa> it's prepending 4 bytes and adding 1 byte FFS
256 2012-12-06 14:41:42 <TD> i think most decent software doesn't actually work in terms of addresses internally, but rather keys
257 2012-12-06 14:42:19 <gavinandresen> yeah, I'm mostly playing devil's advocate here... there are lots of ways to shoot yourself in the foot.
258 2012-12-06 14:42:55 <TD> oh
259 2012-12-06 14:42:56 <sipa> if you're unable to write software to create a correct script, you're most likely also unlikely to generate the correct address in the first place
260 2012-12-06 14:43:01 <TD> the only thing addresses give us, is a network id
261 2012-12-06 14:43:04 <TD> (in some cases)
262 2012-12-06 14:43:10 <TD> it may be worth having a network == TEST, PROD enum in there
263 2012-12-06 14:43:14 <sipa> agree
264 2012-12-06 14:43:15 <TD> so testnet invoices can't get mixed up with prodnet invoices
265 2012-12-06 14:43:17 <sipa> good idea
266 2012-12-06 14:43:34 <gavinandresen> yes, good idea.
267 2012-12-06 14:43:35 <gavinandresen> yes, good idea.
268 2012-12-06 14:43:36 <TD> or MAIN (depending on your terminology preference)
269 2012-12-06 14:43:45 <gavinandresen> ACTION goes to look at how enums are done in protobuf format
270 2012-12-06 14:43:52 <TD> i'm so used to seeing "prod" as shorthand for "production" that i forget it looked weird to me at first
271 2012-12-06 14:43:55 <TD> gavinandresen: like this
272 2012-12-06 14:44:00 <TD> enum Network {
273 2012-12-06 14:44:03 <TD> MAIN = 1;
274 2012-12-06 14:44:06 <TD> TEST = 2;
275 2012-12-06 14:44:13 <TD> required Network network = 11;
276 2012-12-06 14:44:16 <TD> or
277 2012-12-06 14:44:17 <sipa> well, maybe you want this to be more extensible
278 2012-12-06 14:44:23 <TD> optional Network network = 11 [default = MAIN];
279 2012-12-06 14:44:27 <sipa> like have a uint32 for the network magic
280 2012-12-06 14:44:42 <TD> yeah either works
281 2012-12-06 14:44:53 <TD> i suppose some id or string that doesn't require extending the enum is better
282 2012-12-06 14:45:34 <TD> by the way, enums have a downside - if it's set to a value your app wasn't compiled with, the field won't deserialize at all. if it's optional that's ok. if it's required, it makes the whole message unreadable if the enum is extended. this sort of makes sense, if you think about it, but it does mean for forward compatibility you tend to want optional with a default
283 2012-12-06 14:45:57 <TD> by the way
284 2012-12-06 14:46:16 <TD> i'm nearly done with making bcj start pinging peers by default. currently my ping interval is 2 seconds.
285 2012-12-06 14:46:21 <TD> any preferences?
286 2012-12-06 14:46:46 <sipa> the default (connect) timeout if 5s in bitcoind iirc
287 2012-12-06 14:46:53 <sipa> *is
288 2012-12-06 14:47:10 <sipa> which is by no means an assessment of the quality of that number as a default
289 2012-12-06 14:47:31 <gavinandresen> So... required string network = 1 [default="main"];
290 2012-12-06 14:48:01 <TD> gavinandresen: required with default doesn't work. the default is compiled into the reader, not writer. so optional string network = 1 [default="main"]; works
291 2012-12-06 14:48:14 <TD> gavinandresen: required means it has to be present on the wire. so providing a default doesn't really make sense, it'd just be wasteful
292 2012-12-06 14:48:39 <gavinandresen> TD: got it.
293 2012-12-06 16:02:52 <jgarzik> quote davout "It's just Instawallet's bitcoind taking almost 45 minutes to restart with its 2GB wallet"
294 2012-12-06 16:11:16 <ciscoftw> Obviously don?t have the same insight as many here (pool operators ?specially) ?I understand not all transactions are created equally, and its left to miners to include or exclude specific transactions that will be included into their block, but why wouldn?t they just include everything? Transactions don?t affect the difficulty of solving the block, so why not just include everything that is broadcast?
295 2012-12-06 16:12:03 <Luke-Jr> ciscoftw: they do affect the speed at which blocks propagate the network
296 2012-12-06 16:12:18 <Luke-Jr> ciscoftw: so for example, a pool including every SatoshiDice transaction would get a huge amount of orphans
297 2012-12-06 16:12:20 <Luke-Jr> losing even the 25 BTC
298 2012-12-06 16:12:45 <ciscoftw> why would including alot of transaction cause your solved block to orphan?
299 2012-12-06 16:13:01 <Luke-Jr> ciscoftw: because peers check them all before relaying the block
300 2012-12-06 16:13:06 <Luke-Jr> so it can take minutes longer to relay
301 2012-12-06 16:13:20 <Luke-Jr> in the meantime, other pools might have solved the same block and relay faster
302 2012-12-06 16:13:35 <ciscoftw> after a peer has received a new block height, it check it?
303 2012-12-06 16:13:40 <Luke-Jr> yep
304 2012-12-06 16:14:03 <Luke-Jr> including verifying the signatures of every transaction in it
305 2012-12-06 16:14:13 <ciscoftw> i can understand the results of a slow relay, but blow my mind that it take a client longer to check a block with regard to how many trans have been included in it
306 2012-12-06 16:14:29 <ciscoftw> many thanx for info luke-jr
307 2012-12-06 16:14:29 <Luke-Jr> admittedly, this is really mostly bad design
308 2012-12-06 16:14:45 <Luke-Jr> it's theoretically possible to rewrite the p2p code so that it has minimal overhead
309 2012-12-06 16:14:53 <Luke-Jr> begin relaying as soon as only the header is checked, etc
310 2012-12-06 16:16:09 <helo> seems pretty bad to give incentive to disinclude transactions when there's room :(
311 2012-12-06 16:17:07 <gavinandresen> It would take a tiny bit longer to relay in any case (bigger block == longer to transmit). And signature caching makes it less of an issue.
312 2012-12-06 16:17:18 <ciscoftw> this is really outside my understanding... when a miner is solving for a block, all the trans he knows aobut are included... when he's exhausted that merkel key/root and needs to try anohter, does he get an updated trans list? or just keep trying with the info it started with?
313 2012-12-06 16:17:18 <gavinandresen> It would take a tiny bit longer to relay in any case (bigger block == longer to transmit). And signature caching makes it less of an issue.
314 2012-12-06 16:17:18 <Graet> not all pools have an issue, the race condition is rare
315 2012-12-06 16:17:20 <gavinandresen> Has anybody actually measured block-checking times?
316 2012-12-06 16:17:21 <gavinandresen> Has anybody actually measured block-checking times?
317 2012-12-06 16:18:06 <helo> ciscoftw: they tend to not ever exhaust
318 2012-12-06 16:18:07 <helo> ciscoftw: they tend to not ever exhaust
319 2012-12-06 16:18:24 <Luke-Jr> gavinandresen: the verification isn't the worst part of it
320 2012-12-06 16:18:25 <Luke-Jr> gavinandresen: the verification isn't the worst part of it
321 2012-12-06 16:18:29 <Graet> i havent, we dont have a high orphan rate so use default currently , shrug
322 2012-12-06 16:18:31 <Graet> i havent, we dont have a high orphan rate so use default currently , shrug
323 2012-12-06 16:18:34 <gavinandresen> Luke-Jr: what is the worst part?
324 2012-12-06 16:18:36 <gavinandresen> Luke-Jr: what is the worst part?
325 2012-12-06 16:19:00 <Luke-Jr> gavinandresen: as far as I can tell,l while PeerA is uploading to PeerB, it isn't doing anything else (including uploading to PeerC, D, etc)
326 2012-12-06 16:19:37 <gavinandresen> Luke-Jr: ah, so parallel broadcast would be the first bottleneck to fix.
327 2012-12-06 16:19:41 <Luke-Jr> yep
328 2012-12-06 16:20:11 <Luke-Jr> I'd like to see it send as it comes in, too. Since the header check eliminates DoS risk, it should be safe
329 2012-12-06 16:20:27 <ciscoftw> is there any 'visual' way i can see orphaned blocks propagate through the network? like two competeing blocks racing to get majority...
330 2012-12-06 16:20:47 <ciscoftw> like blockexplore.com style
331 2012-12-06 16:20:53 <Luke-Jr> ciscoftw: not without abusing the network I think :/
332 2012-12-06 16:21:19 <ciscoftw> abusing the network? i full of digital hate luke-jr
333 2012-12-06 16:21:46 <Luke-Jr> might be nice if someone could organize a single "central point for abusing the network, that anyone can use to conduct research" to avoid multiple nodes doing it <.<
334 2012-12-06 16:22:09 <gavinandresen> You might be able to convince people to install a little code that hooked into -blocknotify and told a central service when they saw a new block.....
335 2012-12-06 16:22:13 <Luke-Jr> the only thing worse than someone connecting to every node, is more than one person connecting to every node???
336 2012-12-06 16:22:14 <jgarzik> Bitcoin-Central, first exchange licensed to operate as a bank. This is HUGE - https://bitcointalk.org/index.php?topic=129461.0
337 2012-12-06 16:22:33 <jgarzik> (poster's emphasis, not mine)
338 2012-12-06 16:22:34 <gavinandresen> jgarzik: wow!
339 2012-12-06 16:22:37 <helo> i'd be more interested to see what happens when the network is abused
340 2012-12-06 16:23:03 <ciscoftw> thats really the only way to collect that info huh... is to span the entire p2p network (or just all relay nodes)???
341 2012-12-06 16:23:07 <helo> bitcoin is legit in france, if nowhere else... now lets see if the bank can survive a big crash :)
342 2012-12-06 16:23:23 <helo> ciscoftw: all relay nodes are essentially the entire p2p network
343 2012-12-06 16:23:41 <helo> ciscoftw: non-relaying nodes don't accept connections
344 2012-12-06 16:23:51 <ciscoftw> helo: good point
345 2012-12-06 16:24:17 <jgarzik> libccoin should have a block relay daemon going in another few days
346 2012-12-06 16:24:22 <jgarzik> P2P in picocoin seems to be working now
347 2012-12-06 16:24:43 <Luke-Jr> davout looks like in a good position to issue real Bitcoin debit cards <.<
348 2012-12-06 16:24:47 <jgarzik> then we can look as fast block relaying
349 2012-12-06 16:25:05 <jgarzik> sendfile(2) tricks and other fun
350 2012-12-06 16:25:29 <gavinandresen> jgarzik: a fast block relay daemon running on the dev team's server seems like a good use of bandwidth.
351 2012-12-06 16:25:48 <Luke-Jr> last I heard jgarzik wanted to charge for access to his block relay service <.<
352 2012-12-06 16:26:03 <jgarzik> ACTION is trying to choose between a small index (headers + file positions) with quick start-up time, and no index (just block file) with 2 minute startup time
353 2012-12-06 16:26:35 <gavinandresen> more than one fast block relay server is a good idea.
354 2012-12-06 16:26:54 <gavinandresen> jgarzik: I'd choose quick startup and small index. Disk space is cheap.
355 2012-12-06 16:27:55 <ciscoftw> uhhh, regarding shitty transactions (...again) I'd have to leave my client running to keep announcing that tranasaction to the network? will the p2p network drop it, if it hasnt been included in x number of blocks? ....tldr, after a transaction is broadcast to network, how long untill its either included in a block or dropped?
356 2012-12-06 16:28:24 <sipa> it's never deliberately dropped
357 2012-12-06 16:28:43 <sipa> but mempools are in memory, so nodes forget them when restarted
358 2012-12-06 16:28:58 <ciscoftw> so then it shulud just keep getting broadcast by OTHER p2p peers until its included?
359 2012-12-06 16:29:03 <sipa> no
360 2012-12-06 16:29:10 <sipa> they just remember, they don't reannounce
361 2012-12-06 16:29:29 <TD> jgarzik: that seems a bit FUD filled. i'm not totally sure about davout
362 2012-12-06 16:29:41 <sipa> your own node (and that of the receiver, it the transaction managed to reach his node) are the only ones reannouncing
363 2012-12-06 16:29:45 <TD> jgarzik: mtgox wasn't "kicked out" of France for not complying with the law, it was actually the bank that wasn't complying
364 2012-12-06 16:30:45 <ciscoftw> dude sipa, that what i basically siad, and you indicated i was incorrect? da fuk?
365 2012-12-06 16:30:52 <TD> jgarzik: still it's good news
366 2012-12-06 16:30:53 <jgarzik> Luke-Jr: sadly, that and many other business ideas fell by the wayside
367 2012-12-06 16:31:01 <jgarzik> Red Hat pays me too much ;p
368 2012-12-06 16:31:20 <jgarzik> Luke-Jr: free biz idea for _somebody_
369 2012-12-06 16:31:30 <jgarzik> the network, both miners and merchants, would benefit from a trusted backbone of relays
370 2012-12-06 16:31:33 <sipa> ciscoftw: the only time i said you were wrong was when you said that other nodes reannounce
371 2012-12-06 16:31:36 <jgarzik> fast, professional relays
372 2012-12-06 16:31:37 <jgarzik> fast, professional relays
373 2012-12-06 16:32:07 <sipa> ciscoftw: you asked whether it gets dropped by the network, and it doesn't get dropped - but it isn't reannounced either
374 2012-12-06 16:33:48 <ciscoftw> if both sender and reciever turn off there clients and the transaction has not been included into a block. it will NEVER be included after mempools from miners has been purged of it?
375 2012-12-06 16:34:08 <sipa> indeed
376 2012-12-06 16:34:11 <ciscoftw> ...then what happens to the bitcoins?
377 2012-12-06 16:34:12 <gavinandresen> somebody needs to start a "Red Hat for Bitcoin" business....
378 2012-12-06 16:34:53 <jgarzik> gavinandresen: minor payment proto nit: I would s/"test"/"testnet3" because we will reset the test chain periodically
379 2012-12-06 16:34:54 <sipa> ciscoftw: they're considered transferred by those that have the transactions, and not transferred by those that haven't
380 2012-12-06 16:34:57 <Luke-Jr> Isn't that what the Foundation is? more or less :P
381 2012-12-06 16:35:17 <gavinandresen> jgarzik: ACK
382 2012-12-06 16:35:28 <jgarzik> ACTION -> Tex-Mex
383 2012-12-06 16:35:30 <gavinandresen> Luke-Jr: no, Foundation is like the Linux Foundation.
384 2012-12-06 16:36:05 <midnightmagic> Did David Borrett find his way in here?
385 2012-12-06 16:36:12 <gavinandresen> Linux Foundation doesn't provide customer support, or a profesionally packaged distribution.....
386 2012-12-06 16:36:12 <midnightmagic> Barrett even
387 2012-12-06 16:37:11 <midnightmagic> http://lists.zooko.com/pipermail/p2p-hackers/2012-December/003195.html
388 2012-12-06 16:37:25 <ciscoftw> only the tranactions listed in my getmemorypool will be included into a block (assuming i solve it)?
389 2012-12-06 16:37:49 <gavinandresen> ciscoftw: yes, plus a coinbase transaction to reward you for solving the block
390 2012-12-06 16:38:16 <sipa> and even only those that make it through the block creation policy (which sets additional rules about fees/priority/size)
391 2012-12-06 16:40:53 <ciscoftw> the fact that a miner get to selectivly choose what trans are included pisses me off.
392 2012-12-06 16:41:00 <ciscoftw> fix that shit yo
393 2012-12-06 16:42:09 <sipa> no, pay them if you don't like them
394 2012-12-06 16:42:11 <sipa> or mine yourself
395 2012-12-06 16:42:13 <ciscoftw> is it possible to search or parse the getrawmempool data?
396 2012-12-06 16:42:18 <ciscoftw> i do mine myself
397 2012-12-06 16:42:22 <ciscoftw> and i solve blockS
398 2012-12-06 16:43:33 <ciscoftw> just pissed :( sd is f'ing me badly. thanx for your input sipa ./
399 2012-12-06 16:43:39 <sipa> the thing is that miners already are responsible for the only thing that cannot be dealt with otherwise: the ordering of otherwise valid transactions
400 2012-12-06 16:43:44 <Graet> pay for transactions to be included in blocks or pay for hardware to make your own blocks, most would pay the tn fee :)
401 2012-12-06 16:43:52 <sipa> so from a theoretical viewpoint, it is very hard to "fix" that
402 2012-12-06 16:45:37 <ciscoftw> what makes excellent sense (right or wrong) is the relay time leading to stale/orphanded blocks that is directly regarding the number of trans in that block... seems like that could be a potential big problem.
403 2012-12-06 16:49:08 <gmaxwell> ciscoftw: the caching in 0.7.x substantially reduces that issue.
404 2012-12-06 16:49:53 <gmaxwell> (because a big part of the relay time for blocks with many inputs was nodes doing the script validations)
405 2012-12-06 16:50:17 <sipa> and even if not... on git head + parallel script checking i can verify recents block (in somewhat laboratory conditions) in +- 40 ms
406 2012-12-06 16:50:22 <sipa> on average
407 2012-12-06 16:50:57 <gmaxwell> According to p2pool's stats, GBT latency for me is something on the order of 1/8th - 1/10th that of 0.7.1 for me.
408 2012-12-06 16:51:24 <gmaxwell> (and I assume GBT is at least somewhat predictive of network block validation speed)
409 2012-12-06 16:51:39 <sipa> but Luke-Jr's point remains valid: if you manage to have a slow peer sending you a block, there is nothing the network thread can do in between
410 2012-12-06 16:51:56 <gmaxwell> ciscoftw: so at least in the context of 0.8 I think the remaining issue for relay speed is just the network forwarding being sequential.
411 2012-12-06 16:52:04 <gmaxwell> exactly.
412 2012-12-06 16:52:23 <Luke-Jr> ciscoftw: miners' freedom to choose transactions is an important part of the design
413 2012-12-06 16:52:26 <sipa> i wonder if we can just add more network threads...
414 2012-12-06 16:53:17 <sipa> those only lock the node's send or receive buffers anyway
415 2012-12-06 16:53:37 <sipa> so it should be almost trivial to have two or three of them, imho
416 2012-12-06 16:53:42 <gmaxwell> sipa: I don't think fixing that should be a top priority. It could also be addressed by people running fast block forwarding nodes. E.g. a couple well know addresses that just check POW and prev. and blast out blocks would solve miners' concerns.
417 2012-12-06 16:54:08 <sipa> it does solve the 'a slow peer is blocking me' problem
418 2012-12-06 16:54:18 <sipa> (or at least improves upon it)
419 2012-12-06 16:54:19 <gmaxwell> until two slow peers block you! :P
420 2012-12-06 16:54:47 <gmaxwell> sipa: alternatively, putting inbound and outbound into seperate network threads may make a lot of DOS sense.
421 2012-12-06 16:55:26 <gmaxwell> (then at least it's harder for someone maliciously being slow to self select and greatly delay you from getting a block)
422 2012-12-06 16:55:58 <sipa> actually... i'm not sure whether that's true at all?
423 2012-12-06 16:56:07 <sipa> we only read/write nonblocking
424 2012-12-06 16:57:07 <sipa> blocks not being forwarder before being validated adds delay of course, but one that doesn't depend on the network system to be improved
425 2012-12-06 16:58:34 <gmaxwell> Luke had patches that changed it??? with a different getblock that indicated you didn't care if it was validated. (It would still DoS if the POW didn't match though). But IIRC they weren't useful because it was getting stuck feeding a slow peer.
426 2012-12-06 16:59:31 <Luke-Jr> gmaxwell: well, it didn't do anything because the p2p code is all synchronous
427 2012-12-06 16:59:47 <sipa> how do you mean synchronous?
428 2012-12-06 17:00:13 <sipa> it never does a blocking write or read
429 2012-12-06 17:00:15 <Luke-Jr> I wrote it assuming the p2p code kept running alongside block checking
430 2012-12-06 17:00:23 <Luke-Jr> it effectively does???
431 2012-12-06 17:00:26 <sipa> it does
432 2012-12-06 17:01:27 <Luke-Jr> sipa: did that change in ultraprune?
433 2012-12-06 17:01:31 <sipa> no
434 2012-12-06 17:01:51 <sipa> you have the network thread which sends/receives from/to the node buffers
435 2012-12-06 17:02:01 <Luke-Jr> IIRC when I looked at it, all the p2p activity was in a single thread that dealt with 1 command from 1 peer at a time
436 2012-12-06 17:02:15 <sipa> and the message handler that processing messages in the node buffers
437 2012-12-06 17:02:36 <sipa> but the network threads works perfectly fine while doing slow message handling, for example
438 2012-12-06 17:02:51 <sipa> both are only ever dealing with one node at a time, but the network part is not synchronous at all
439 2012-12-06 17:03:21 <sipa> if a block arrives in two parts, it should receive that in two parts, with data received from other nodes in the mean time potentially
440 2012-12-06 17:04:53 <sipa> it will only get processed when received entirely though, but processing can continue on other data received from other peers in the mean time
441 2012-12-06 17:18:31 <ciscoftw> possible to clear your rawmempool with killing bitcoind service?
442 2012-12-06 17:24:02 <gmaxwell> ciscoftw: no. Why would you want to do that?
443 2012-12-06 17:24:25 <gmaxwell> (in fact, there is a patch to basically do the opposite??? request a mempool dump from a peer at startup)
444 2012-12-06 17:28:09 <helo> ciscoftw: if you have a bad transaction in your wallet, i think you need to remove it and then -rescan (the rescan may be automatic...)
445 2012-12-06 17:28:39 <sipa> helo: 1) -rescan finds missing transactions, it doesn't remove them
446 2012-12-06 17:28:51 <sipa> 2) the wallet and the mempool have (almost) nothing to do with eachother
447 2012-12-06 17:30:17 <helo> if one manually removes a (bad) transaction from their wallet, will a -rescan recalculate the balance and allow the client to create a replacement transaction?
448 2012-12-06 17:30:24 <sipa> yes
449 2012-12-06 17:31:29 <helo> i thought ciscoftw was having problems with a bad transaction, and was asking the wrong question re: mempool purge
450 2012-12-06 17:31:57 <gmaxwell> considering that he mentioned killing, I think he really meant mempool. :)
451 2012-12-06 17:31:58 <ciscoftw> i do have a bad transaction, and i'd like to purge my mempool without stopping the service
452 2012-12-06 17:32:14 <gmaxwell> Clarity has not been added.
453 2012-12-06 17:32:16 <sipa> do you have a bad transaction in your wallet?
454 2012-12-06 17:32:20 <ciscoftw> :)
455 2012-12-06 17:32:20 <gmaxwell> ^?
456 2012-12-06 17:32:23 <helo> purging mempool won't help if the transaction is in your wallet
457 2012-12-06 17:32:30 <gmaxwell> ^.
458 2012-12-06 17:33:00 <ciscoftw> on a different system (wallet location), yes i have a SD transaction that is NOT being included into blocks
459 2012-12-06 17:34:02 <ciscoftw> but i wanna clear my mempool to increase the chances my solved block will NOT be orphaned/stale
460 2012-12-06 17:34:21 <gmaxwell> huh. That doesn't make much sense.
461 2012-12-06 17:34:59 <gmaxwell> If you want to produce a smaller block, you can request that with a commandline parameter. Whats the reason you don't want to restart?
462 2012-12-06 17:35:02 <helo> if you want your mempool to be cleared, just restart bitcoind... i don't think there's another practical way
463 2012-12-06 17:35:28 <ciscoftw> my uptime, dont wanna disconnect 90+ peers
464 2012-12-06 17:35:50 <helo> the way to ensure you have suitably small blocks is to filter the transactions as they come in
465 2012-12-06 17:36:01 <gmaxwell> you're mining directly on a node with 90 peers and you're worried about orphaned/stale rates? :P
466 2012-12-06 17:36:02 <gmaxwell> you're mining directly on a node with 90 peers and you're worried about orphaned/stale rates? :P
467 2012-12-06 17:36:16 <ciscoftw> :) it cant hurt
468 2012-12-06 17:36:32 <gmaxwell> it absolutely can and does!
469 2012-12-06 17:36:35 <helo> rather than try to purge the mempool... when the client starts back up it will start slurping up SD transactions just the same
470 2012-12-06 17:37:43 <gmaxwell> There are patches floating around to just block them. It does reduce the mempool size by a large amount.
471 2012-12-06 17:38:00 <ciscoftw> thanx gmax
472 2012-12-06 17:38:19 <gmaxwell> But yea, I wouldn't recommend so many connections on a mining node.
473 2012-12-06 17:38:32 <ciscoftw> i should limit it to how many?
474 2012-12-06 17:38:49 <ciscoftw> wish i could check to see how many stales i've had in my lifetime
475 2012-12-06 17:38:59 <gmaxwell> I run like ... 4-6. which are all hand selected known good nodes (including links to my public nodes that do have a good number of peers)
476 2012-12-06 17:39:14 <ciscoftw> figured i was just helping out the network by having large peers connected....
477 2012-12-06 18:17:47 <jgarzik> "Coin Publishing LLC is the new entity based in Florida that will be taking over the full operations of Bitcoin Magazine effective immediately, purchasing the assets and contracts from Bittalk Media Ltd for an undisclosed sum of cash plus bitcoins.
478 2012-12-06 18:17:48 <jgarzik> Coin Publishing LLC is collectively owned by individuals owning or working at BitPay, Butterfly Labs, Google, Casascius, 20 Mission, and Virtual Processing Solutions."
479 2012-12-06 18:18:32 <gavinandresen> Big day for announcements today
480 2012-12-06 18:19:48 <ThomasV> it's thursday, the day where central banks make announcement
481 2012-12-06 18:19:56 <helo> we're becoming them :(
482 2012-12-06 18:20:00 <Luke-Jr> jgarzik: yeah, Vladimir apparently ran it into the group
483 2012-12-06 18:20:02 <Luke-Jr> ground*
484 2012-12-06 18:20:06 <gavinandresen> I feel peer pressure to announce something....
485 2012-12-06 18:20:08 <ThomasV> .. so we have to answer :)
486 2012-12-06 18:20:20 <helo> new hairdo?
487 2012-12-06 18:20:26 <gavinandresen> ACTION goes to see how many downloads 0.7.2rc2 has had already
488 2012-12-06 18:20:53 <Luke-Jr> 33 ._.
489 2012-12-06 18:21:12 <sipa> there seem to be some misconceptions about 0.8 out there: http://www.reddit.com/r/Bitcoin/comments/148abf/my_first_experience_with_bitcoin_was_not_positive/c7aqut3
490 2012-12-06 18:21:13 <sipa> there seem to be some misconceptions about 0.8 out there: http://www.reddit.com/r/Bitcoin/comments/148abf/my_first_experience_with_bitcoin_was_not_positive/c7aqut3
491 2012-12-06 18:21:33 <gavinandresen> bah, should wait another day to make sure it doesn't make some weird version of Windoze catch fire.
492 2012-12-06 18:22:07 <sipa> gavinandresen: as long as that's on Windows ME, that'd be doing the world a serivce
493 2012-12-06 18:23:44 <Luke-Jr> hah
494 2012-12-06 19:51:32 <jgarzik> sipa: what is a good reference URL, for people who want to test 0.8? is there a forum thread?
495 2012-12-06 19:52:19 <D34TH> jgarzik, i got it to compile, it requires a few dll deps though
496 2012-12-06 19:52:48 <jgarzik> D34TH: I tried a naive conversion to select(), but that broke a few things :(
497 2012-12-06 19:53:00 <jgarzik> D34TH: however, I found http://msdn.microsoft.com/en-us/library/edze9h7e%28v=vs.80%29.aspx
498 2012-12-06 19:53:06 <D34TH> all i had to do was use cygwin and remove o_largefile
499 2012-12-06 19:53:11 <D34TH> and it compiled
500 2012-12-06 19:53:17 <jgarzik> D34TH: that page contains a recipe for doing fork on windows, with pipes
501 2012-12-06 19:53:35 <jgarzik> yeah, cygwin makes it all easier :)
502 2012-12-06 19:53:48 <sipa> jgarzik: next-test has the most up-to-date builds, i guess, but it also has some potentially buggy stuff
503 2012-12-06 19:54:01 <jgarzik> ACTION will get a build going for libevent and jansson on mingw, and then I can work on Windows stuff
504 2012-12-06 19:54:22 <jgarzik> cygwin is useful to get you going, but I dislike the requirement as a general rule
505 2012-12-06 19:54:24 <sipa> jgarzik: i posted a link to my pre builds in the ultraprune thread, but those are somewhat outdated now
506 2012-12-06 19:55:44 <D34TH> jgarzik, i only wanted to test as a proof of concept
507 2012-12-06 19:56:41 <jgarzik> D34TH: all good. any testing appreciated. long term, Windows will definitely be supported.
508 2012-12-06 20:01:36 <D34TH> jgarzik: http://pastebin.com/ViUNsk1N woot woot
509 2012-12-06 20:02:14 <D34TH> jgarzik, is O_LARGEFILE needed for linux?
510 2012-12-06 20:02:24 <jgarzik> D34TH: yes
511 2012-12-06 20:02:44 <jgarzik> D34TH: cool :)
512 2012-12-06 20:05:26 <D34TH> sipa: i totally think that 4 threads is good, but is it possible to optionally allow more/less?
513 2012-12-06 20:05:49 <D34TH> like 4 for default but with -verthread=6 or something
514 2012-12-06 20:07:10 <sipa> D34TH: -par sets how many threads you want
515 2012-12-06 20:07:24 <D34TH> sipa: thanks, didn't know
516 2012-12-06 20:07:30 <sipa> default equal to your number of cpu's
517 2012-12-06 20:11:43 <jgarzik> heh
518 2012-12-06 20:11:53 <jgarzik> ipv6 bitcoin nodes seem much more reliable, less transient, than ipv4 nodes
519 2012-12-06 20:13:30 <Diapolo> I'm also able to use IPv6 again, my provider messed up 6to4 ^^.
520 2012-12-06 20:14:15 <D34TH> Diapolo, i use HE's ipv6
521 2012-12-06 20:14:19 <sipa> Diapolo: the -benchmark pullreq was mainly as a precursor to the parallel script checker, so i could check how much was gained :)
522 2012-12-06 20:14:22 <D34TH> never failed for me
523 2012-12-06 20:14:39 <sipa> Diapolo: and as it seemed generally useful, i made it into a separate pullreq
524 2012-12-06 20:14:46 <D34TH> sipa: will both be in 0.7.2?
525 2012-12-06 20:14:54 <sipa> D34TH: hell no
526 2012-12-06 20:15:00 <sipa> 0.7.2 is bugfix only
527 2012-12-06 20:15:03 <D34TH> 0.8.0?
528 2012-12-06 20:15:05 <D34TH> :D
529 2012-12-06 20:15:08 <sipa> yes, hopefully
530 2012-12-06 20:15:22 <D34TH> bbl
531 2012-12-06 20:17:16 <denisx> argh, threadnaming for freebsd is still not turned on?
532 2012-12-06 20:17:58 <Diapolo> sipa: can you comment on the Windows results, they seem to be much slower only Flush os 0ms ... dunno
533 2012-12-06 20:19:19 <sipa> Diapolo: those flushes being zero is probably indeed just because of the lower resolution of the clock
534 2012-12-06 20:20:27 <Diapolo> sipa: What is benched in the pull? Block processing, LevelDB performance I'm not sure.
535 2012-12-06 20:21:40 <sipa> Diapolo: block processing, transaction verification, coin database lookups (which may cause leveldb lookups) and updates, ...
536 2012-12-06 20:21:49 <sipa> what CPU is that?
537 2012-12-06 20:22:09 <sipa> 3ms/txin is rather slow
538 2012-12-06 20:22:12 <Diapolo> AMD A8-3850K 4 core
539 2012-12-06 20:22:57 <BCBot2`> Diapolo: Error: "=" is not a valid command.
540 2012-12-06 20:22:57 <Diapolo> != high-end but sufficient Llano platform
541 2012-12-06 20:22:57 <gribble> Error: "=" is not a valid command.
542 2012-12-06 20:23:30 <sipa> Llano?
543 2012-12-06 20:23:35 <helo> a8-3850 is a pretty good value
544 2012-12-06 20:23:55 <helo> allows me to play most new games without buying a gpu
545 2012-12-06 20:23:58 <denisx> 120k blocks in 10min
546 2012-12-06 20:24:37 <Diapolo> sipa: AMD Family 10h Processor without L3 cache
547 2012-12-06 20:24:49 <Diapolo> 2.9 GHz
548 2012-12-06 20:24:54 <sipa> denisx: loading from where?
549 2012-12-06 20:25:03 <denisx> sipa: network
550 2012-12-06 20:25:07 <sipa> ok
551 2012-12-06 20:26:01 <Diapolo> sipa: question in between -onlynet="IPv6" but I have 3 incoming IPv4 connections listed with getpeerinfo? is that correct behaviour?
552 2012-12-06 20:26:44 <sipa> Diapolo: i forgot
553 2012-12-06 20:26:58 <sipa> i think -onlynet only controls which outgoing connections are attempted
554 2012-12-06 20:27:22 <sipa> Diapolo: those benchmark numbers, are they during IBD or not?
555 2012-12-06 20:27:47 <Diapolo> sipa: no during a normal sync after a few hours (catching up only a few blocks)
556 2012-12-06 20:28:03 <sipa> ok, that may have somewhat lower performance
557 2012-12-06 20:28:15 <sipa> as the coin cache is flushed after every block
558 2012-12-06 20:30:31 <Diapolo> I can post some numbers during IBD tomorrow for comparison
559 2012-12-06 20:32:48 <sipa> ok
560 2012-12-06 20:37:54 <casascius> Hey everyone, I'm wondering if I could get some feedback on https://en.bitcoin.it/wiki/BIP_0038 - Passphrase-protected private key format.
561 2012-12-06 20:41:33 <gavinandresen> casascius: wiki isn't loading for me right now
562 2012-12-06 20:42:08 <casascius> gavinandresen: possible net issues? loads for me at a normal speed
563 2012-12-06 20:44:53 <gavinandresen> casascius: yes, something wonky with my net connection....
564 2012-12-06 20:44:54 <gavinandresen> casascius: yes, something wonky with my net connection....
565 2012-12-06 20:50:27 <casascius> It's basically a revisit of a proposal I made in the past, but hopefully I have "done it right" this time.
566 2012-12-06 20:54:32 <sipa> casascius: i
567 2012-12-06 20:54:35 <sipa> casascius: i
568 2012-12-06 20:55:00 <sipa> casascius: i've skimmed over it, but i think i'm way too tired to give useful criticism now
569 2012-12-06 20:58:34 <sipa> casascius: btw, i've updated BIP32 with your suggestion for 4-char prefix
570 2012-12-06 21:03:08 <casascius> sipa: sweet
571 2012-12-06 21:08:07 <Jouke> casascius: does your proposal include puclic key cryptografy?
572 2012-12-06 21:08:28 <casascius> sipa: On BIP 32, the only thing that wasn't totally clear to me is whether depth=3 is a hard limit or just a recommendation (I'm sure it says somewhere, I just haven't found it)
573 2012-12-06 21:08:54 <sipa> casascius: i should clear that up; the spec is really two parts
574 2012-12-06 21:09:15 <sipa> casascius: the first is the key derivation mechanism and the tree formed by it
575 2012-12-06 21:09:16 <casascius> jouke: indeed: it allows an elliptic curve multiply to be an optional part of the scheme so that the person picking the passphrase can be different than the person generating addresses
576 2012-12-06 21:09:39 <sipa> casascius: the second is how to build a wallet on top of that tree
577 2012-12-06 21:09:53 <casascius> jouke: actually i suppose i should qualify, because that's not public key cryptograhy as it's defined
578 2012-12-06 21:09:54 <Jouke> casascius: ok, clear, thanks :)
579 2012-12-06 21:10:10 <Jouke> well, that was what I was asking for :)
580 2012-12-06 21:10:55 <casascius> jouke: true that public and private keys are involved, but the scheme is much more like a DH key derivation than a PGP message
581 2012-12-06 21:12:00 <sipa> casascius: i'll need to think a bit about compatibility issues, but in general i suppose clients could support any key chain (so an extended pubkey/privkey, and automatically use all addresses derived from it)
582 2012-12-06 21:12:18 <casascius> sipa: is there an expectation that depth=3 be adopted as a best practice even if the algorithm defines deeper than that? (i.e. to maximize the portability of chains among clients, assuming this is a desired feature)
583 2012-12-06 21:12:33 <sipa> casascius: something like that; call it a recommended wallet structure
584 2012-12-06 21:26:51 <Luke-Jr> casascius: j/w, but who assigned BIP num 38?
585 2012-12-06 21:27:45 <casascius> I contacted genjix
586 2012-12-06 21:29:51 <Luke-Jr> cool, good to know he's still there when people contact him :p
587 2012-12-06 21:40:17 <casascius> sipa: in bip32 serialization, what goes in parent key and child number fields when serializing a master key?
588 2012-12-06 21:40:32 <sipa> casascius: good point! zeroes
589 2012-12-06 21:40:33 <sipa> casascius: good point! zeroes
590 2012-12-06 21:48:27 <casascius> sipa: as I'm crunching through bip 32 i wanted to throw some ideas at you.
591 2012-12-06 21:49:09 <casascius> sipa: my thoughts are centered on one byte in your serialization format you have called "depth: 0x00 for master nodes, 0x01 for level-1 descendants, ...."
592 2012-12-06 21:49:26 <casascius> sipa: I'm trying to reconcile that with the "If I were to see this byte, what would I know to do with it" problem.
593 2012-12-06 21:50:03 <casascius> sipa: example: you've proposed "auditing" as an application, but if I'm trying to fly under the radar of an "audit" I merely need to choose an arbitrarily high chain code that I hope the auditor may not look.
594 2012-12-06 21:50:42 <casascius> sipa: What if your depth byte indicated, in addition to / opposed to literal "depth", what was the intended application of the chain code?
595 2012-12-06 21:50:42 <sipa> well, you could as well use a separate key entirely for your hidden dirty business
596 2012-12-06 21:51:01 <sipa> an audit typically happens because one wants to be audited
597 2012-12-06 21:51:05 <sipa> (or needs to)
598 2012-12-06 21:51:25 <casascius> sipa: re key: indeed, but by using arbitrarily high key I can maintain I have "disclosed my wallet"
599 2012-12-06 21:51:40 <sipa> that you can hide from it is inevitable, what the scheme allows is being voluntarily audited without giving up your private keys
600 2012-12-06 21:52:35 <casascius> idea that I had was that a couple of bits out of depth could be assigned to indicate the following: one bit to indicate an intent that new payment addresses should be derived from this code, and one bit to indicate that new chains should be derived from this code.
601 2012-12-06 21:53:07 <sipa> that sounds reasonable
602 2012-12-06 21:53:18 <casascius> (or perhaps a single combined bit, where 0 means "derive only new chains from this" and 1 means "derive only new addresses from this"
603 2012-12-06 21:53:22 <casascius> )
604 2012-12-06 21:53:47 <sipa> but i don't want to restrict the format for chains (which are general) to how one can use them
605 2012-12-06 21:54:04 <sipa> people may use arbitrarily complex derivations (though i suppose 99.9999% won't)
606 2012-12-06 21:54:21 <sipa> a/complex/deep/
607 2012-12-06 21:54:33 <casascius> sipa: agreed, these wouldn't be so much restrictions, but rather, hints such that an application parsing an "extended key" knows what to do with it, with reasonable bounds
608 2012-12-06 21:54:56 <casascius> I can think of one application for these that could occupy one more level depth
609 2012-12-06 21:55:01 <sipa> how about changing the depth byte to a height byte
610 2012-12-06 21:55:16 <casascius> this application would enhance anonymity
611 2012-12-06 21:55:20 <sipa> 0 = actual address; 1 = chain of addresses; 2 = chain of chains; ...
612 2012-12-06 21:55:47 <casascius> sipa: what you're suggesting is along the lines of what I am thinking
613 2012-12-06 21:56:13 <casascius> the extra object i would throw out would be like: 3 = single-use fork in the chain of addresses
614 2012-12-06 21:56:23 <casascius> here is why it might be useful:
615 2012-12-06 21:56:48 <casascius> it would allow me to send coins to somebody without having to combine inputs
616 2012-12-06 21:57:02 <casascius> assuming i needed anonymity and combining inputs compromised that
617 2012-12-06 21:57:23 <sipa> well that's perfectly possible without an extra level
618 2012-12-06 21:57:39 <sipa> but sure, could be
619 2012-12-06 21:57:59 <sipa> the problem is what if the distance from the root is variable
620 2012-12-06 21:58:18 <casascius> sipa: I am guessing that by it being already possible, you mean (for example) someone could create a new wallet chain to accept a payment of this nature?
621 2012-12-06 21:58:26 <sipa> yes
622 2012-12-06 21:58:31 <sipa> account chain
623 2012-12-06 21:58:32 <sipa> account chain
624 2012-12-06 22:00:21 <casascius> sipa: That makes total sense as being possible -
625 2012-12-06 22:01:33 <casascius> sipa: Suppose by convention, a serialized xpub record with a height value of 3 had the following understood meaning: "This is a chain of addresses meant for a single transaction. Payments sent to this chain will be understood to all belong to a single transaction. Please pay a contiguous series of addresses in the chain starting from the first."
626 2012-12-06 22:02:19 <casascius> So the problem I am proposing to solve isn't how to get it to fit in the chain, but rather, how to communicate between a payer and a payee that a group of txid's is really a single payment.
627 2012-12-06 22:03:13 <sipa> casascius: i have no problem with such usage or even intended meaning of that when used as a "recurring business-to-business transaction"
628 2012-12-06 22:03:27 <sipa> casascius: but an extended public key is not a payment request
629 2012-12-06 22:03:49 <sipa> and the payment protocol being developed is much more suited for that
630 2012-12-06 22:04:38 <sipa> iirc there was some way of specifying multiple outputs, and specifying the sum you expect to pay to them
631 2012-12-06 22:05:24 <sipa> (you could of course derive all addresses in there from a level-3 bip32 chain, but the payer doesn't need to know or care)
632 2012-12-06 22:09:23 <sipa> BlueMatt: is bitcoinpulltester alive?
633 2012-12-06 22:51:29 <jgarzik> pah
634 2012-12-06 22:51:34 <jgarzik> I see now why sipa did undo files
635 2012-12-06 22:51:51 <jgarzik> seems brd ("block relay daemon") either needs undo files, or an all-tx index
636 2012-12-06 22:51:58 <jgarzik> in order to handle reorgs properly
637 2012-12-06 22:52:37 <jgarzik> if you must rewind the UTXO set, you must recover outputs given just (hash,n)
638 2012-12-06 22:53:15 <sipa> blocks are authenticated patches to the UTXO set
639 2012-12-06 22:53:20 <sipa> undo files are reverse patches
640 2012-12-06 22:54:04 <sipa> but indeed, you only need them for reorganisations
641 2012-12-06 22:54:30 <sipa> or for delayed script validation, because they happen to contain all the txouts for which a blocks provides the txins
642 2012-12-06 22:54:32 <jgarzik> was trying to figure out a way to reverse-patch based on block data
643 2012-12-06 22:54:35 <jgarzik> but could not
644 2012-12-06 22:54:43 <sipa> haha, yeah me too :D
645 2012-12-06 22:55:09 <sipa> but you lost the spent txouts... quite obviously
646 2012-12-06 22:55:33 <jgarzik> well with the block data they are there...
647 2012-12-06 22:55:38 <jgarzik> just not indexed
648 2012-12-06 22:55:50 <jgarzik> hmmm
649 2012-12-06 22:55:54 <sipa> right, true
650 2012-12-06 22:56:07 <jgarzik> I suppose I could scan the entire 3GB+ data file for them, in the case of a reorg ;-)
651 2012-12-06 22:56:09 <jgarzik> rofl
652 2012-12-06 22:56:35 <sipa> in case it's not the last txout of a tx, you still know the height
653 2012-12-06 22:56:44 <jgarzik> ahhh, good point!
654 2012-12-06 22:56:46 <sipa> so you only need to scan one block in that case :p
655 2012-12-06 22:57:20 <jgarzik> sadly, would still need to handle the last-txout-deletes-CCoin case
656 2012-12-06 22:57:37 <sipa> yes, that's why you need undo files :D
657 2012-12-06 23:00:30 <jgarzik> disappointing :)
658 2012-12-06 23:00:40 <jgarzik> but agreed
659 2012-12-06 23:01:15 <jgarzik> I could reverse-scan the block file
660 2012-12-06 23:01:23 <jgarzik> find the transactions needed
661 2012-12-06 23:01:29 <jgarzik> would be faster than a forward scan, at least
662 2012-12-06 23:02:17 <sipa> no point
663 2012-12-06 23:02:41 <sipa> keep 2000 undo files around, and if that's not enough, just rebuild from scratch
664 2012-12-06 23:02:59 <sipa> they are around 9 times smaller than the blocks themself
665 2012-12-06 23:03:00 <sipa> they are around 9 times smaller than the blocks themself
666 2012-12-06 23:03:16 <sipa> so that's max 220 MB :)
667 2012-12-06 23:09:46 <jgarzik> sipa: true
668 2012-12-06 23:10:05 <jgarzik> sipa: but right now I must have the blocks file, as "brd" is a full node
669 2012-12-06 23:10:23 <jgarzik> I'm trying to see if I can avoid additional files and indices
670 2012-12-06 23:10:35 <jgarzik> it appears so, as long as you don't mind a 2.5 minute startup
671 2012-12-06 23:12:09 <sipa> and a 2.5 minute reorg?
672 2012-12-06 23:16:53 <jgarzik> sipa: for a worst case whole-chain reorg, yes :)
673 2012-12-06 23:17:22 <jgarzik> sipa: but with an in-memory block header index, it's just a matter of walking the block index linked list backwards
674 2012-12-06 23:17:53 <sipa> no, i mean to find all tx's whose txouts were spent, to rewind the UTXO set
675 2012-12-06 23:17:55 <jgarzik> the in-memory UTXO gives me height, if the transaction remains in that index. if it's the last txout spent, reverse block walk.
676 2012-12-06 23:18:08 <jgarzik> sipa: yes, reverse block walk
677 2012-12-06 23:18:28 <sipa> so: (up to) a 2.5 minute reorg
678 2012-12-06 23:18:30 <jgarzik> sipa: if someone spends genesis block transaction, worst case is 2.5 minutes
679 2012-12-06 23:18:37 <jgarzik> yes
680 2012-12-06 23:18:52 <sipa> i'm sure that whether it's from the genesis block or from block 100k hardly makes a difference
681 2012-12-06 23:19:26 <sipa> in any case, it's what i'd call a very non-scalable solution :)
682 2012-12-06 23:20:18 <sipa> oh, btw: you can't spend the genesis block txout :)
683 2012-12-06 23:20:51 <jgarzik> as most transactions spend recent bitcoins, and many transactions would still be in the UTXO set, worst case behavior is uncommon I would think
684 2012-12-06 23:20:56 <jgarzik> but yes, indices are inevitable
685 2012-12-06 23:21:02 <jgarzik> just trying to put them off as long as possible
686 2012-12-06 23:21:20 <jgarzik> once I implement undo files, might as well start storing UTXO set on disk, rather than rebuilding it at startup each time
687 2012-12-06 23:21:48 <jgarzik> and that requires opening the "database" can o worms
688 2012-12-06 23:21:53 <sipa> haha
689 2012-12-06 23:23:09 <jgarzik> hmmmm. I wonder about the cost of simply storing a list of transaction ids with each block header
690 2012-12-06 23:23:28 <jgarzik> we have, what, ~5 million transactions?
691 2012-12-06 23:23:32 <sipa> 9.6
692 2012-12-06 23:24:13 <jgarzik> so tightly packed that's ~300MB
693 2012-12-06 23:24:18 <jgarzik> of hashes
694 2012-12-06 23:25:28 <sipa> that also restricts you to keeping all blocks around forever (which seems you intention, but is not required at all if you just want a daemon that quickly relays)
695 2012-12-06 23:27:07 <jgarzik> indeed
696 2012-12-06 23:29:09 <jgarzik> Could go the other way and just store a block index on disk
697 2012-12-06 23:29:55 <jgarzik> with {txid->bitmap} index too perhaps
698 2012-12-06 23:30:17 <sipa> spentness bitmap?
699 2012-12-06 23:30:22 <jgarzik> yeah
700 2012-12-06 23:31:21 <sipa> but still keep the utxo set in memory?
701 2012-12-06 23:31:36 <jgarzik> hmmmm
702 2012-12-06 23:32:04 <jgarzik> nah, spentness checking suddenly makes reorg complicated
703 2012-12-06 23:32:08 <sipa> btw, the undo-files method doesn't require any index really (though probably need to read through them at startup as well)
704 2012-12-06 23:32:16 <jgarzik> reorg is quite easy, if you don't care about UTXO ;p
705 2012-12-06 23:32:29 <maaku> imho, it shouldn't be either-or: I'd want a framework that can do all of the above and customized at compile or runtime
706 2012-12-06 23:32:35 <maaku> different applications demand different indices
707 2012-12-06 23:32:37 <sipa> maaku: go write it
708 2012-12-06 23:32:47 <maaku> working on it ;)
709 2012-12-06 23:32:49 <sipa> haha
710 2012-12-06 23:33:27 <jgarzik> so, yeah, could do a block-index-only mode, no block/undo/UTXO data stored on disk, for a minimal block relay
711 2012-12-06 23:33:40 <jgarzik> then the full validation mode would store undo files and full block data
712 2012-12-06 23:33:53 <casascius> On the forums it is reported that somebody just did an escrow transaction with my bip38 sample app
713 2012-12-06 23:34:03 <jgarzik> if startup could read through undo files and not full block data, that could be nice
714 2012-12-06 23:34:09 <jgarzik> a nice compromise
715 2012-12-06 23:34:20 <sipa> jgarzik: store block positions inside the undo files; done
716 2012-12-06 23:34:29 <jgarzik> good point
717 2012-12-06 23:34:33 <jgarzik> /idea
718 2012-12-06 23:34:48 <sipa> casascius: what does bip38 have to do with escrowing?
719 2012-12-06 23:35:05 <jgarzik> that's a nice design actually :) it means I can avoid the dreaded "database" rathole
720 2012-12-06 23:35:20 <jgarzik> sipa: thanks :)
721 2012-12-06 23:35:28 <casascius> a lot apparently, i wasn't even expecting this
722 2012-12-06 23:36:46 <casascius> i proposed a method for doing 2 factor physical bitcoins. alice chooses a passphrase, my utility creates an "intermediate code" (it's random salt + an ec point), bob generates bitcoin addresses with it that need alice's passphrase, and also can give alice a "confirmation code" (it's alice's own salt plus bob's generated ec point)
723 2012-12-06 23:37:11 <sipa> maaku: anyway, i agree actually
724 2012-12-06 23:37:12 <casascius> both sides can see the bitcoin address and know it's encumbered by the key material they generated
725 2012-12-06 23:38:16 <casascius> in this case, somebody used my physical bitcoin generator, but in this case, they each kept the key material they created to themselves, encumbering the coins until either "alice" shared the passphrase or "bob" shared the encrypted key
726 2012-12-06 23:38:51 <sipa> maaku: but i think block validation is a specialized application, and deserves a index/database that's designed specifically for that (with just what is needed for block validation, and nothing else)... anything that can't be done with that should get an optional index
727 2012-12-06 23:39:01 <casascius> https://bitcointalk.org/index.php?topic=129399.msg1383296#msg1383296
728 2012-12-06 23:39:18 <casascius> forum thread where the person doing it reported having done so
729 2012-12-06 23:55:58 <korozion> blarg it's difficult getting hardware going on Linux
730 2012-12-06 23:55:59 <korozion> blarg it's difficult getting hardware going on Linux
731 2012-12-06 23:58:07 <Luke-Jr> korozion: only junk hardware, or Ubuntu
732 2012-12-06 23:58:53 <korozion> ubuntu :)
733 2012-12-06 23:59:25 <korozion> any decent Debian options?
734 2012-12-06 23:59:27 <korozion> or other?
735 2012-12-06 23:59:37 <D34TH> oh wow, bitcoin made the 7th page of reddit
736 2012-12-06 23:59:48 <Luke-Jr> isn't reddit bitcoin-specific? :P
737 2012-12-06 23:59:59 <D34TH> they have a subreddit for bitcoin