1 2013-01-01 00:42:19 <muhoo> i'm running bitcoinj 0.7-SNAPSHOT (also tried this with 0.5.2 release, same problem), and DnsDiscovery, and every peer it finds is connection refused or no route to host
2 2013-01-01 00:42:40 <muhoo> i ran it for 24 hours even, 0 connected peers, logs filled with connection refused or timed out
3 2013-01-01 00:43:01 <muhoo> but, bitcoin c++ node, no problem, on the same machine, same network
4 2013-01-01 00:43:37 <muhoo> am i doing something wrong, or is bitcoinj not functional?
5 2013-01-01 00:46:31 <muhoo> this is what i'm getting, fyi: https://www.refheap.com/paste/7991
6 2013-01-01 01:13:18 <muhoo> nevermind, i am an idiot. it's on testnet. doh.
7 2013-01-01 03:06:46 <stealth222> happy new year everyone
8 2013-01-01 15:52:27 <novusordo> is the latest github version of bitcoin still using berkeley DB 4.8?
9 2013-01-01 16:02:17 <sipa> novusordo: the source code uses whatever version of BDB you compile it against
10 2013-01-01 16:02:48 <sipa> release binaries to date have always used 4.8 though (well, 4.7 has been used in the past as well)
11 2013-01-01 16:03:06 <sipa> hello grau
12 2013-01-01 16:13:23 <grau> hi, first time lurking here
13 2013-01-01 16:14:05 <grau> wonder if its worth installing an irc client
14 2013-01-01 16:15:02 <Luke-Jr> grau: yes
15 2013-01-01 16:16:33 <grau> ok, the last time I used chat on internet was with compuserve around 1994 I think...
16 2013-01-01 16:16:37 <sipa> grau: activity here varies from 12 hours nothing to pages of very interesting discussion :)
17 2013-01-01 16:16:44 <sipa> grau: welcome, by the way
18 2013-01-01 16:16:57 <grau> thans hapy to see you all aroud
19 2013-01-01 16:17:01 <etotheipi_> grau: high-five for CompuServe
20 2013-01-01 16:17:11 <novusordo> welcome, grau
21 2013-01-01 16:18:01 <sipa> grau: i'm just looking at the bitsofproof code for the first time; i wonder where the com.bitsofproof.supernode.api sourcecode is?
22 2013-01-01 16:19:14 <sipa> ah, different repository
23 2013-01-01 16:19:25 <grau> Just checked I was 100273,3607 :)
24 2013-01-01 16:20:10 <grau> yes, that is in a separate repository just like supernode-testclient and -cpuminer
25 2013-01-01 16:20:34 <grau> api is a dependency to all, the later two are just ssimple demos
26 2013-01-01 16:24:48 <grau> is there some intro to this or just free talk about whatever you like ?
27 2013-01-01 16:25:10 <Luke-Jr> the latter
28 2013-01-01 16:25:30 <grau> great, thanks Luke
29 2013-01-01 16:26:08 <Luke-Jr> grau: you might (or might not) find #bitcoin-watch useful also (not for chat) if you're debugging transaction code
30 2013-01-01 16:26:28 <Luke-Jr> grau: there's also a multitude of other Bitcoin-related channels
31 2013-01-01 16:27:40 <grau> will check in going forward...
32 2013-01-01 16:28:01 <sipa> grau: any hint on where i can find the code that validates transactions/blocks?
33 2013-01-01 16:28:21 <novusordo> 694e275896107cea391d24417616c9d641e59dca5b126b7ccdb8c615c5f3beef < lol, beef in the transaction
34 2013-01-01 16:28:28 <a1111> Luke-Jr: The black background is not so friendly
35 2013-01-01 16:29:07 <a1111> Luke-Jr: Also, the text is hard to read
36 2013-01-01 16:29:09 <Luke-Jr> a1111: black background is standard/default <.<
37 2013-01-01 16:29:58 <etotheipi_> grau: just be careful with IRC -- I've found myself losing entire days of productivity because of all-too-interesting discussions in here :)
38 2013-01-01 16:30:31 <Luke-Jr> a1111: here's how it looks with an ordinary IRC client: https://en.bitcoin.it/wiki/Bitcoin-Watch
39 2013-01-01 16:30:36 <grau> sipa: start at https://github.com/bitsofproof/supernode/blob/master/src/main/java/com/bitsofproof/supernode/core/CachedBlockStore.java
40 2013-01-01 16:31:07 <a1111> Luke-Jr: I am using KVIrc
41 2013-01-01 16:31:22 <grau> sipa: the method public void storeBlock (final Blk b)
42 2013-01-01 16:31:36 <a1111> Luke-Jr: http://www.kvirc.net/
43 2013-01-01 16:31:53 <grau> sipa: and public boolean validateTransaction (Tx t, TxOutCache resolvedInputs)
44 2013-01-01 16:32:19 <grau> It is an honor that you take a look.
45 2013-01-01 16:33:47 <grau> etotheeipi : since I spend most of my time in a shop with internet access limited and controlled, I wont be tempted. It will however steal more time from my family I guess
46 2013-01-01 16:33:47 <sipa> grau: i think you're missing a piece of logic in the validation
47 2013-01-01 16:34:07 <sipa> grau: i may be missing things of course now too
48 2013-01-01 16:34:29 <sipa> grau: it's related to bip 16
49 2013-01-01 16:35:09 <grau> sipa: it seems you all enjoy giving me puzzles :) never mind. Thanks
50 2013-01-01 16:35:39 <sipa> grau: if you prefer i'll just tell you
51 2013-01-01 16:35:45 <a1111> Luke-Jr: http://i.imgur.com/mQbH0.png
52 2013-01-01 16:36:01 <Luke-Jr> a1111: kinda eww
53 2013-01-01 16:36:12 <sipa> my eyes!
54 2013-01-01 16:36:19 <etotheipi_> hold on, mine is even worse
55 2013-01-01 16:36:20 <a1111> sipa: yes mine too
56 2013-01-01 16:36:59 <Luke-Jr> a1111: your client is interpreting the cyan colour codes wrong, using the wrong encoding (should be UTF-8), and ugly font rendering (should be fixed-width, ideally with black background)
57 2013-01-01 16:37:24 <Luke-Jr> weird that it's only cyan it messes up
58 2013-01-01 16:37:36 <grau> sipa: I know that I should count number of sigs within scripts I do not yet.
59 2013-01-01 16:37:44 <etotheipi_> Luke-Jr: I think the point is your color scheme is not friendly to other IRC clients
60 2013-01-01 16:37:46 <grau> is this its?
61 2013-01-01 16:37:54 <sipa> grau: part of it, but the rest is related
62 2013-01-01 16:37:59 <Luke-Jr> etotheipi_: it's friendly to standard-compatible clients :P
63 2013-01-01 16:38:02 <a1111> etotheipi_: Yes, i agree
64 2013-01-01 16:38:28 <a1111> Luke-Jr: Is it possible for you to remove your color scheme ?
65 2013-01-01 16:38:32 <sipa> grau: in non-bip16, checkmultisig is always counted as 20 (legacy rule); it's only inside bip16 subscripts that the "accurate counting" is used
66 2013-01-01 16:38:41 <Luke-Jr> a1111: it's possible to have some IRC clients filter colours
67 2013-01-01 16:39:07 <Luke-Jr> but much of the usability of -watch comes from the colour-coding
68 2013-01-01 16:39:15 <sipa> grau: i noticed that the accurate counting is the only one implemented
69 2013-01-01 16:39:33 <etotheipi_> Luke-Jr: you can't just tell people that their software is wrong and expect them to change it when it works for everything else except yours
70 2013-01-01 16:40:35 <grau> sipa : that distinction is made in https://github.com/bitsofproof/supernode-api/blob/master/src/main/java/com/bitsofproof/supernode/api/ScriptFormat.java, method, public static int sigOpCount (byte[] script)
71 2013-01-01 16:41:01 <etotheipi_> http://imgur.com/qkgDc
72 2013-01-01 16:41:14 <sipa> grau: i don't see it
73 2013-01-01 16:41:41 <grau> sipa: it was us cross talking.
74 2013-01-01 16:41:52 <a1111> etotheipi_: http://i.imgur.com/mQbH0.png
75 2013-01-01 16:41:57 <Luke-Jr> etotheipi_: better than telling people that their software looks bad (due to their viewer's bugs) and expect them to change it by removing a key feature when it works for everything else that is compliant ;)
76 2013-01-01 16:42:00 <a1111> Mine is worse than yours
77 2013-01-01 16:42:40 <sipa> grau: not sure we're saying the same thing
78 2013-01-01 16:43:02 <a1111> Luke-Jr: Please could you remove the color scheme ?
79 2013-01-01 16:43:08 <a1111> my eyes!!!!!
80 2013-01-01 16:43:32 <Luke-Jr> etotheipi_: yours doesn't look that bad IMO; just a bit dark mainly
81 2013-01-01 16:43:36 <etotheipi_> a1111: it's pretty bad for both of us
82 2013-01-01 16:43:39 <grau> sipa: I say countingis implemented there, line 504 refers to BIP16, is not what you look for?
83 2013-01-01 16:43:51 <etotheipi_> Luke-Jr: but it makes me not want to use it
84 2013-01-01 16:44:02 <Luke-Jr> a1111: would defeat the point
85 2013-01-01 16:44:27 <grau> have to sign-off for lunch. I will be back with a proper clint later
86 2013-01-01 16:45:03 <a1111> Now my eyes hurt after looking at #bitcoin-watch
87 2013-01-01 16:45:49 <a1111> I might become blind if i stay on #bitcoin-watch too long
88 2013-01-01 16:49:34 <a1111> ACTION leave #bitcoin-watch to protect his eyes
89 2013-01-01 17:00:34 <Luke-Jr> a1111: KVirc has a stripcolors function that might work in a script
90 2013-01-01 17:10:31 <grau> back again
91 2013-01-01 17:12:30 <sipa> grau: there are 3 sources of sigop counts: a) in txout scripts b) in txin scripts c) for bip16 txins, in the subscript
92 2013-01-01 17:13:02 <sipa> grau: a) and b) are counted "inaccurately" (checkmultisig is always counted as 20), in c) it uses the better formula that you implemented already
93 2013-01-01 17:13:33 <sipa> afaik, you only have a) so far, but with the formula to be used in c)
94 2013-01-01 17:13:57 <grau> thanks will correct
95 2013-01-01 17:14:46 <grau> i am a bit annoyed of complexity inroduced with these rules, at least new ones should be simpler
96 2013-01-01 17:15:13 <grau> e.g. jgarzik started a question today on transaction fees
97 2013-01-01 17:15:23 <grau> I hope whatever it will bve will be simple
98 2013-01-01 17:15:40 <sipa> well if anything, transaction fees are a policy, not a rule
99 2013-01-01 17:16:07 <sipa> getting an policy that multiple client author agree about is certainly better, but it's by no means required
100 2013-01-01 17:17:20 <grau> ok, they do not fork if not same, but have agreat influence to the system.
101 2013-01-01 17:18:05 <sipa> sure
102 2013-01-01 17:18:21 <grau> I wish the policy would be motivated more by costs it imposes to the system
103 2013-01-01 17:19:38 <sipa> well many people agree that the fee policy should take the effect on the UTXO set into account (adding txouts = expensive, consuming txouts = bonus)
104 2013-01-01 17:20:34 <grau> great thet was also my stance. I did not know it is already common
105 2013-01-01 17:20:48 <sipa> nobody suggested an exact formula yet, though
106 2013-01-01 17:21:17 <grau> well I did : numnber of outs/ number of ins * FEE
107 2013-01-01 17:22:07 <sipa> well, sigops should be taken into account as well, imho
108 2013-01-01 17:22:36 <sipa> and that formula has no aging at all (if the priority is not good enough now, waiting a day will not help)
109 2013-01-01 17:22:53 <grau> why should aging help at all ?
110 2013-01-01 17:23:14 <grau> it will cost the sztem utxo sooner or later
111 2013-01-01 17:23:14 <sipa> people do expact their transactions to be included if they wait
112 2013-01-01 17:23:26 <sipa> increasing priority should help it get priority
113 2013-01-01 17:23:33 <grau> they should not expect that if they do not pay minimum fee
114 2013-01-01 17:23:33 <sipa> eh, increasing fee should increase priority
115 2013-01-01 17:24:02 <sipa> maybe over time not
116 2013-01-01 17:24:15 <sipa> but a lot of things would break if transactions wouldn't confirm at all
117 2013-01-01 17:24:23 <grau> until there are free transactions no incentive system will work
118 2013-01-01 17:24:28 <sipa> there is - right now - basically no solution for a non-confirming transaction
119 2013-01-01 17:24:34 <sipa> it's in limbo
120 2013-01-01 17:24:35 <grau> this is why we have to eliminate free rider
121 2013-01-01 17:24:50 <sipa> over time, sure
122 2013-01-01 17:24:58 <grau> why wait?
123 2013-01-01 17:25:14 <MC-Eeepc> happy new year dev team
124 2013-01-01 17:25:20 <MC-Eeepc> and everyone and stuff
125 2013-01-01 17:25:20 <sipa> because right now it helps making the system more attractive
126 2013-01-01 17:25:38 <grau> happy new yer
127 2013-01-01 17:25:42 <sipa> you too!
128 2013-01-01 17:26:24 <Scrat> anyone know the current state of the linux PRNG? this (http://www.pinkas.net/PAPERS/gpr06.pdf) implies that livecds always start with a predetermined entropy pool
129 2013-01-01 17:26:34 <grau> i think that a fee smaller than you can express in a fiat currency does not change attractiveness but saves us lots of DoS trouble
130 2013-01-01 17:26:39 <grau> and enables incentives
131 2013-01-01 17:26:48 <Scrat> so if you use one to create privkeys you're basically basing your randomness on a few seconds of mouse movement
132 2013-01-01 17:27:01 <sipa> grau: i think the difference between "free" and "ridiculously low" is immense, psychologically
133 2013-01-01 17:27:41 <grau> there is no free lunch is what I learned early in my carrier
134 2013-01-01 17:27:41 <Scrat> it is my understanding that openssl seeds its prng with /dev/urandom and the pid
135 2013-01-01 17:27:46 <grau> i mean career
136 2013-01-01 17:27:59 <sipa> and the only ones getting paid from fees are miners (not all other full nodes in the system), and they already get paid anyway (for now, again)
137 2013-01-01 17:28:14 <sipa> the most important reason for fees right now is anti-DoS
138 2013-01-01 17:28:21 <sipa> not economics of block size
139 2013-01-01 17:28:22 <grau> yes,
140 2013-01-01 17:28:36 <sipa> (which certainly will change, but this is an easy change to make)
141 2013-01-01 17:28:37 <grau> I believe that nodes profit from fees since they contain their load
142 2013-01-01 17:28:45 <grau> that is their implicit benefit
143 2013-01-01 17:29:25 <grau> fees reduce badwith and disk needed and we all buy it, right ?
144 2013-01-01 17:30:02 <sipa> not sure what you mean
145 2013-01-01 17:31:13 <sipa> anyway, i'm no economsit and don't pretend to be - i don't know the best way to incentivize through fees what is necessary
146 2013-01-01 17:31:37 <sipa> what i do know is that (right now), a priority calculation that doesn't take confirmation count into account, would break things badly
147 2013-01-01 17:31:46 <grau> incentives do not work until there is a free ride
148 2013-01-01 17:32:02 <grau> since you can not go below that
149 2013-01-01 17:32:51 <sipa> so eventually with feeless transactions, you should expect not more than minimal service (at most best effort)
150 2013-01-01 17:33:01 <sipa> but i'm talking about right now
151 2013-01-01 17:33:52 <grau> you should not expect any service at zero fee
152 2013-01-01 17:34:27 <sipa> well, people *do* - whether they should isn't relevant in the short term
153 2013-01-01 17:34:34 <sipa> in the long term i agree with you
154 2013-01-01 17:34:43 <grau> I do not think people do
155 2013-01-01 17:35:08 <sipa> well, i'm sure there will still be interesting discussions about fee policy
156 2013-01-01 17:35:34 <grau> let see what other say, thanks
157 2013-01-01 17:35:43 <sipa> i??m just trying to say that it's more complex than how you present it
158 2013-01-01 17:35:54 <grau> what is your experience with leveldb ?
159 2013-01-01 17:36:06 <sipa> very good
160 2013-01-01 17:36:18 <sipa> the only problems i've seen so far are on windows
161 2013-01-01 17:36:20 <grau> i see its fast like hell but not yet trusting its consistency
162 2013-01-01 17:36:45 <sipa> well i'm working on coindb (=utxo set) consistency checks now
163 2013-01-01 17:36:59 <sipa> when that is done, i'll experiment with trying to break it :)
164 2013-01-01 17:37:22 <sipa> i trust its consistency far more than BDB in any case, just by the way it works
165 2013-01-01 17:37:25 <grau> i use the batch feature to simulate transactions it does not have. it worked until now
166 2013-01-01 17:37:41 <sipa> batches do guarantee atomic writes
167 2013-01-01 17:37:57 <grau> but have no rollback
168 2013-01-01 17:37:57 <sipa> (as they are written as a single blob to the logfile)
169 2013-01-01 17:38:24 <sipa> indeed
170 2013-01-01 17:57:18 <TD> Scrat: any hardware interrupts
171 2013-01-01 17:57:35 <TD> Scrat: from what i know. but yeah, live CDs and other entirely deterministic setups aren't exactly ideal for key generation
172 2013-01-01 18:12:16 <kuzetsa> ?
173 2013-01-01 18:12:42 <kuzetsa> are you suggesting that the random entropy pool can't be established on a livecd?
174 2013-01-01 18:37:24 <Diapolo> sipa: I made a strange observation with one of the changes in your LevelDB1.7 branch
175 2013-01-01 18:38:11 <Diapolo> you added win32:QMAKE_LFLAGS *= -static-libgcc -static-libstdc++ to the project-file and when I leave this in I can only get a testnet OR mainnet instance running
176 2013-01-01 18:38:44 <Diapolo> when one is running and I try to start the other, the to be started instance crashes with an MSVC++ error
177 2013-01-01 18:39:05 <Diapolo> removing that linker flag allows me to use 2 instances like intended
178 2013-01-01 18:39:27 <sipa> wtf...?
179 2013-01-01 18:39:53 <sipa> which error?
180 2013-01-01 18:40:51 <Diapolo> I need to re-compile and will tell you the exact error.
181 2013-01-01 18:44:34 <gmaxwell> kuzetsa: Can't is not the same as isn't. A problem with random sources is that it's easy to miss when they're broken.
182 2013-01-01 18:46:27 <Diapolo> sipa: "Microsoft Visual C++ Runtime Library: This application has requested the Runtime to terminate it in an unusal way. Please contact the application's support team for more information."
183 2013-01-01 18:47:34 <sipa> Diapolo: bleh...
184 2013-01-01 18:47:37 <sipa> anything in debug.log ?
185 2013-01-01 18:48:40 <Diapolo> sipa: nope sorry ... do you have a recent build I could try from you, to see if it's a problem with my local IDE/compiler suite.
186 2013-01-01 18:49:18 <sipa> not one without known problems
187 2013-01-01 18:49:43 <Diapolo> one that survives startup seems sufficient in that case
188 2013-01-01 18:51:33 <sipa> http://bitcoin.sipa.be/builds/pre-0.8/2012-12-28-turbo-ldb17/
189 2013-01-01 18:51:40 <Diapolo> I'll try that
190 2013-01-01 18:51:42 <Diapolo> just a sec
191 2013-01-01 18:51:48 <sipa> what OS version are you on?
192 2013-01-01 18:52:42 <Diapolo> Win7 x64 SP1
193 2013-01-01 18:52:47 <sipa> ok
194 2013-01-01 18:54:13 <Diapolo> nice your build doesn't suffer from win32:QMAKE_LFLAGS *= -static-libgcc -static-libstdc++ problems I have, so it's related to my local stuff, good for your work ;)
195 2013-01-01 18:54:34 <sipa> well if it's a problem to build with those settings on windows, it's a problem!
196 2013-01-01 18:54:56 <sipa> and without those settings, binaries won't work without additional libraries
197 2013-01-01 18:55:36 <Diapolo> I'll do some research if these switches are known to cause problems on Win
198 2013-01-01 18:57:29 <Diapolo> most obvious thing is file size, your binary is ~20MB, mine is 9MB
199 2013-01-01 19:01:43 <Diapolo> sipa: seems I didn't build my Qt libs with the -static switch
200 2013-01-01 19:03:57 <sipa> gmaxwell: i was able to detect an error when modifying a single byte in (the last) .sst file, and correct by finding a point to roll back to using undo files
201 2013-01-01 19:04:06 <sipa> that's kinda fragile though
202 2013-01-01 19:04:20 <sipa> i'm not sure what should happen in such a case
203 2013-01-01 19:05:50 <gmaxwell> sipa: mark the database broken. Refuse to run until reindexed?
204 2013-01-01 19:07:21 <sipa> yeah, the old checkblocks code tried to reorganize until a point before the error
205 2013-01-01 19:08:10 <sipa> that's only possible in a probabilistic way now
206 2013-01-01 19:09:29 <gmaxwell> even then was likely to not be correct??? e.g. if your index is corrupt it may be corrupt before the depth it checked to too.
207 2013-01-01 19:13:14 <sipa> hmm, and what if an error is found in a block file?
208 2013-01-01 19:13:56 <etotheipi_> ACTION mumbles curses under his breath about block file errors
209 2013-01-01 19:13:56 <sipa> you can try to reorganize until before the faulty block, but that reorganisation is risky, as undoing does need some data from the original blocks
210 2013-01-01 19:15:31 <sipa> ?
211 2013-01-01 19:15:39 <MC-Eeepc> wow i got android bitcoin for testnet to connect to the network once and now it wont find any peers again
212 2013-01-01 19:15:48 <MC-Eeepc> i hope it does, i sent coins to it :/
213 2013-01-01 19:19:32 <MC-Eeepc> ah these it goes
214 2013-01-01 19:19:59 <MC-Eeepc> it didnt boop for receive coins, how disappointing
215 2013-01-01 19:21:06 <MC-Eeepc> i wonder if the guy who makes this android client will try to port the new database stuff from you guys
216 2013-01-01 19:21:18 <MC-Eeepc> i dare not even try to sync the main net on this device....
217 2013-01-01 19:21:23 <sipa> ??
218 2013-01-01 19:21:29 <sipa> it's an SPV client
219 2013-01-01 19:21:41 <sipa> it doesn't store the block chain at all
220 2013-01-01 19:21:55 <MC-Eeepc> no bitcoin wallet for android is a full client
221 2013-01-01 19:22:01 <MC-Eeepc> spinner is the spv one
222 2013-01-01 19:22:12 <sipa> spinner is not a client at all, it relies on a central server
223 2013-01-01 19:22:33 <sipa> and bitcoin wallet for android (by andreas schildbach) is most certainly an SPV client
224 2013-01-01 19:22:48 <MC-Eeepc> oh
225 2013-01-01 19:22:53 <sipa> it runs on BitcoinJ, which (until very recently) only supported SPV in the first place
226 2013-01-01 19:23:02 <sipa> running a full node on a phone would be crazy
227 2013-01-01 19:23:54 <MC-Eeepc> wait what does spv do again
228 2013-01-01 19:24:07 <sipa> verify block headers, but not transactions
229 2013-01-01 19:25:36 <jgarzik> ACTION reads email
230 2013-01-01 19:25:43 <jgarzik> ACTION will remove the rest of the 'T's
231 2013-01-01 19:26:15 <sipa> i'm being inconsistent in terminology: spinner is obviously a client (like electrum is), but it doesn't implement a P2P node
232 2013-01-01 19:29:19 <MC-Eeepc> oh
233 2013-01-01 19:29:43 <MC-Eeepc> and spv checks for the blocks after its txns in order to verify them
234 2013-01-01 19:29:51 <MC-Eeepc> a full node checks all te blocks before it
235 2013-01-01 19:30:03 <sipa> SPV clients don't verify *any* blocks
236 2013-01-01 19:30:17 <sipa> it needs to download them, to check for incoming transactions
237 2013-01-01 19:30:23 <sipa> but it doesn't store nor verify anything
238 2013-01-01 19:30:26 <MC-Eeepc> it verifies that they exist
239 2013-01-01 19:30:27 <sipa> except the headers
240 2013-01-01 19:30:54 <MC-Eeepc> it verifies that they exist vis the headers, it doesnt verify the contents, is that right?
241 2013-01-01 19:31:00 <sipa> correct
242 2013-01-01 19:31:07 <MC-Eeepc> ok
243 2013-01-01 19:31:26 <sipa> it downloads full blocks, but only stores and verifies the headers (and checks that the downloaded block data matches the headers, but not that it's valid)
244 2013-01-01 19:32:18 <MC-Eeepc> right so it relies on other full nodes having done the real work, and on its connection to the network not being tampered with is crucial
245 2013-01-01 19:32:29 <MC-Eeepc> whereas a ful node can cope with a tampered connection right
246 2013-01-01 19:32:31 <sipa> not at all
247 2013-01-01 19:32:45 <sipa> the connection is not a problem - it can be tampered with all they want
248 2013-01-01 19:33:02 <sipa> the only risk for SPV nodes is an evil miner
249 2013-01-01 19:33:15 <sipa> who creates blocks with valid proof-of-work, but with invalid transactions
250 2013-01-01 19:34:37 <sipa> tampering is exactly what an SPV node would detecty
251 2013-01-01 19:37:08 <MC-Eeepc> the wiki says an sv cn be fooled with a mitm attack
252 2013-01-01 19:37:14 <MC-Eeepc> spv
253 2013-01-01 19:37:30 <gmaxwell> especially if that evil miner can prevent the SPV node from hearing about the real chain??? because if they can they don't even have to produce a longer chain for an attack of unbounded duration.
254 2013-01-01 19:37:39 <gmaxwell> MC-Eeepc: yes, but the MITM must also mine.
255 2013-01-01 19:38:29 <weex> mirceapopescue has thrown down a bounty of 100 btc to prove positively or negatively if SD is playing with itself
256 2013-01-01 19:38:42 <MC-Eeepc> ok so
257 2013-01-01 19:39:27 <TD> MC-Eeepc: SPV clients can't verify unconfirmed transactions and therefore rely on the assumption that they are connected to genuine nodes and those nodes are not (all) going to announce invalid transactions
258 2013-01-01 19:39:37 <weex> seems an interesting problem whether it gets worked on or not
259 2013-01-01 19:39:39 <TD> MC-Eeepc: however as the transactions get confirmations the chances of anyone playing games goes down
260 2013-01-01 19:39:47 <gmaxwell> weex: what will he consider proof?
261 2013-01-01 19:39:48 <TD> (assuming those confirmations arrive quickly enough)
262 2013-01-01 19:40:07 <MC-Eeepc> an SPV trusts a consensus (even if thats wrong), a full node verifies everything for itself
263 2013-01-01 19:40:12 <MC-Eeepc> ?
264 2013-01-01 19:40:41 <weex> gmaxwell: not exactly sure but i guess it comes down to taint between raked and played funds
265 2013-01-01 19:40:55 <gmaxwell> TD: if the SPV node is isolated they're still in a sad shape. (one reason that I hope we would someday increase the minimum difficulty)
266 2013-01-01 19:41:46 <gmaxwell> weex: its trivial to make simulated play look like isolated users. I suppose that means you could prove that incompetent simulated play was simulated, but you can't prove that competent simulated play is simulated or that non-simulated play is non-simulate.
267 2013-01-01 19:43:57 <MC-Eeepc> so an SPV has little to gain from sipas work, and i could probably try to sync on this android tablet without risk of a fire
268 2013-01-01 19:44:34 <gmaxwell> SPV gains from sipas work by the full nodes that SPV needs to exist continuing to exist. :P
269 2013-01-01 19:45:02 <MC-Eeepc> haha yes quite
270 2013-01-01 19:53:58 <jgarzik> indeed. no full nodes, no SPV.
271 2013-01-01 20:07:43 <MC-Eeepc> It should be retty viable to have the satoshi client start in spv mode and just do the ful node stuff in the background then right
272 2013-01-01 20:07:53 <MC-Eeepc> perhaps after surveying the host machine to see if thats a good idea
273 2013-01-01 20:08:09 <MC-Eeepc> it would make sync complaints go away overnight
274 2013-01-01 20:08:11 <sipa> patches welcome :)
275 2013-01-01 20:09:00 <MC-Eeepc> lol
276 2013-01-01 20:09:02 <gmaxwell> MC-Eeepc: 'overnight' presumably not including the time to develop and test it.. But yes, thats a good idea and would generally make things much better.
277 2013-01-01 20:09:28 <MC-Eeepc> yeah guys obviously i know you have a lot on the list...
278 2013-01-01 20:09:43 <MC-Eeepc> im just babbling
279 2013-01-01 20:11:23 <TD> MC-Eeepc: you can use multibit
280 2013-01-01 20:13:07 <sipa> ideally, i think Bitcoin-Qt just became an SPV client on itself, with the ability to start a bitcoind in a separate process
281 2013-01-01 20:18:09 <gmaxwell> sipa: I like that too??? although, if you have your own bitcoind it can be more efficient to run electrum style where you can count on it to scan blocks for you. I guess probably not worth the complexity.
282 2013-01-01 20:19:48 <sipa> gmaxwell: let's spend time on getting an address-indexed p2p-retrievable UTXO set that is authenticated via the coinbase instead :)
283 2013-01-01 20:20:58 <gmaxwell> I was really hoping that namecoin would go and do that by now, and we could learn from someone elses mistakes.
284 2013-01-01 20:21:01 <gmaxwell> :(
285 2013-01-01 20:21:06 <TD> i think there's enough to do without these sorts of extensions.
286 2013-01-01 20:21:16 <sipa> agree
287 2013-01-01 20:21:55 <sipa> just saying that if we're going to use any kind of optimization by having a fully-indexed blockchain available, we better do it in a way that it's accessible for the entire network
288 2013-01-01 20:22:55 <gmaxwell> TD: dunno if you saw, the bitsofproof thing found and fixed some (but not all) of the issues.
289 2013-01-01 20:23:02 <TD> yes i saw
290 2013-01-01 20:26:10 <gmaxwell> oh I see you did now.
291 2013-01-01 21:20:52 <sipa> gmaxwell: in case an inconsistency is found - any reason not to just wipe the coindb immediately and start rebuilding it?
292 2013-01-01 21:46:46 <gavinandresen> sipa: picking up conversation from github RE: leveldb / mingw / printf : I think I broke it when I took out the -stdc++0x option
293 2013-01-01 21:46:59 <gavinandresen> See: http://sourceforge.net/project/shownotes.php?release_id=24832
294 2013-01-01 21:48:21 <gavinandresen> Fix should be easy: compile with -posix or -D__USE_MINGW_ANSI_STDIO=1 (or any of about a dozen other flags that will get the mingw *printf routines)
295 2013-01-01 21:49:13 <sipa> aha, that's good news
296 2013-01-01 21:52:35 <sipa> i'll update the makefiles, do a new build, and ask on the forum to retry
297 2013-01-01 21:53:04 <gavinandresen> I'll see if I can reproduce in my Windows VM, too
298 2013-01-01 21:55:35 <sipa> gavinandresen: btw, while working on coindb consistency checking, i added a checksum to the on-disk format for the undo files
299 2013-01-01 21:55:56 <sipa> any problems with breaking that?
300 2013-01-01 22:06:47 <gavinandresen> sipa: no problem from me; there are a small enough number of people running git HEAD that we shouldn't worry too much about compatibility
301 2013-01-01 22:24:45 <gavinandresen> sipa: my windows VM showed the bug-- I just didn't notice the .(null) files before (and only downloaded the testnet chain, so didn't run out of disk space).
302 2013-01-01 22:25:02 <gavinandresen> sipa: adding PLATFORM_CXXFLAGS="-posix" fixes it.
303 2013-01-01 22:25:15 <TradeFortress> Hi, I would like to know how to make wallet.dat only accessible to root / su
304 2013-01-01 22:25:25 <gavinandresen> sipa: ... which means the workaround I wrote for the logging 64-bit values can be ripped out, too
305 2013-01-01 22:26:07 <denisx> TradeFortress: "man chmod"
306 2013-01-01 22:26:44 <sipa> gavinandresen: good
307 2013-01-01 22:27:36 <sipa> /home/ubuntu/build/bitcoin/src/leveldb/libleveldb.a(env_win.o):env_win.cc:(.text+0x1bc6): undefined reference to `__imp__PathFileExistsW@4'
308 2013-01-01 22:27:51 <TradeFortress> Can someone with RPC access get a list of all accounts?
309 2013-01-01 22:27:57 <sipa> yes
310 2013-01-01 22:28:07 <sipa> RPC access == access to the wallet
311 2013-01-01 22:28:30 <sipa> except for spending coins, which may still require the passphrase, but that's not really intended as an authentication mechanism
312 2013-01-01 22:29:28 <TradeFortress> sipa: how would I do so?
313 2013-01-01 22:29:34 <andytoshi> sipa, TradeFortress is hoping to create accounts named with a user's hashed password
314 2013-01-01 22:29:34 <sipa> do what>?
315 2013-01-01 22:29:39 <TradeFortress> get a list of al accounts
316 2013-01-01 22:29:40 <TradeFortress> all*
317 2013-01-01 22:29:43 <andytoshi> but not expose things to his PHP script
318 2013-01-01 22:30:05 <sipa> TradeFortress: listaccounts
319 2013-01-01 22:30:22 <TradeFortress> OK, if I remove the listaccounts call from source it'll work?
320 2013-01-01 22:31:09 <andytoshi> you probably want to disable -every- RPC call except ones you know you need
321 2013-01-01 22:31:15 <sipa> yeah
322 2013-01-01 22:31:20 <TradeFortress> yep
323 2013-01-01 22:31:30 <andytoshi> but yeah, that sounds like a good idea to me
324 2013-01-01 22:31:35 <sipa> and if you need anything that sends coins, i think your efforts are a bit wasted anyway
325 2013-01-01 22:36:04 <andytoshi> no, if you can keep the account names secret, that's a win no matter what
326 2013-01-01 22:36:13 <andytoshi> as they contain hashed passwords
327 2013-01-01 22:36:31 <andytoshi> the addresses themselves of course will be exposed
328 2013-01-01 22:36:46 <TradeFortress> yes, I only need about 5 RPC calls actually
329 2013-01-01 22:36:52 <TradeFortress> so I'm going to comment out the rest
330 2013-01-01 22:37:46 <andytoshi> cool, you know how to use git and everything to keep your changes across upgrades?
331 2013-01-01 22:43:45 <TradeFortress> nope, I'll just do it the manual way
332 2013-01-01 22:45:10 <TradeFortress> maybe I should make RPC calls disable-able in bitcoin.conf?
333 2013-01-01 22:50:46 <andytoshi> yeah, that's probably best
334 2013-01-01 22:56:30 <andytoshi> i'll implement something to that effect and put a pull request in..
335 2013-01-01 22:58:41 <TradeFortress> I was thinking of doing that but I have no knowledge of git so
336 2013-01-01 23:02:50 <andytoshi> i'm good with git, but not the STL..
337 2013-01-01 23:07:48 <gavinandresen> a pull request for disabling RPC commands will be rejected unless you give a good use case that makes sense
338 2013-01-01 23:10:24 <andytoshi> suppose you are interfacing with (say) a PHP application which you don't trust
339 2013-01-01 23:13:02 <gavinandresen> don't trust... how? don't trust to send coins? get balances? move coins from account to account ?
340 2013-01-01 23:13:34 <gavinandresen> whitelisting commands makes more sense than blacklisting, I think. Because if we add a new type of 'send' command, your blacklist would stop working when you upgrade
341 2013-01-01 23:13:57 <andytoshi> oh, that's a very good point
342 2013-01-01 23:14:17 <gavinandresen> ... and i'd suggest that a little proxy in front of the RPC port is probably the right way to do whitelisting/blacklisting of RPC commands.
343 2013-01-01 23:14:20 <andytoshi> but yeah, the premise is that you might have an application that should be able to read balances, say
344 2013-01-01 23:15:20 <andytoshi> i dunno, i could probably add a whitelist to bitcoind with ~10 LOC
345 2013-01-01 23:15:32 <andytoshi> whereas a proxy would introduce a lot more complexity
346 2013-01-01 23:15:55 <gavinandresen> but a proxy gives you other features you probably want, like a whitelist per username/password combination....
347 2013-01-01 23:16:34 <andytoshi> yeah, that's true...i'm really targeting a very specific usecase here
348 2013-01-01 23:17:08 <andytoshi> which is almost guaranteed to expand as an appliction gets more serious
349 2013-01-01 23:18:01 <gavinandresen> sipa: https://gist.github.com/4431213 <-- is compiling/running in my mingw32 Windows VM. Are you compiling mingw32 or 64 ?
350 2013-01-01 23:18:06 <andytoshi> i'll probably wind up doing it, just for fun, and if anyone else requests it on irc, i might put in a pull request
351 2013-01-01 23:18:40 <andytoshi> but for now, i don't see any real usecases
352 2013-01-01 23:24:10 <TradeFortress> andytoshi: you're going to write code that you won't use yourself for no reason?
353 2013-01-01 23:24:50 <andytoshi> that's correct :}
354 2013-01-01 23:25:18 <andytoshi> it would take me 30 seconds once i learn the STL junk to deal with the data structures
355 2013-01-01 23:25:29 <andytoshi> and i need to learn that stuff anyway, so this is a good excuse
356 2013-01-01 23:30:49 <TradeFortress> also, could I embed a small message in the blockchain with RPC calls?
357 2013-01-01 23:40:58 <DDDD> 10 FREE BIT COINS ON EVERYONES ORDER WITHIN THE NEXT 48 HOURS HURRY UP AND HAPPY NEW YEAR FROM WWW.BITCOINBERUDECHANGE.COM WE ACCEPT CREDIT CARDS PAYPAL AND MANY MORE DONT MISS OUT !!!!!
358 2013-01-01 23:41:04 <DDDD> 10 FREE BIT COINS ON EVERYONES ORDER WITHIN THE NEXT 48 HOURS HURRY UP AND HAPPY NEW YEAR FROM WWW.BITCOINBERUDECHANGE.COM WE ACCEPT CREDIT CARDS PAYPAL AND MANY MORE DONT MISS OUT !!!!!
359 2013-01-01 23:41:30 <TradeFortress> what
360 2013-01-01 23:42:06 <TradeFortress> 10 coins on bitcoinderudechange.com is a scam site like mtgax
361 2013-01-01 23:58:42 <gmaxwell> Yea, BITCOINBERUDECHANGE is a scam site as far as anyone can tell.