1 2012-03-25 00:57:00 <luke-jr> well, *new* addrman bug& :/
  2 2012-03-25 01:00:00 <gribble> New news from bitcoinrss: luke-jr opened issue 982 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/982>
  3 2012-03-25 01:03:24 <luke-jr> dooglus: !
  4 2012-03-25 01:06:34 <sipa> luke-jr: bitcoin-qt deadlocks while being single threaded?
  5 2012-03-25 01:06:54 <luke-jr> sipa: yes, try the addr.dat I uploaded
  6 2012-03-25 01:09:08 <sipa> git head?
  7 2012-03-25 01:09:22 <luke-jr> yes
  8 2012-03-25 01:10:29 <luke-jr> might run with -testnet just in case it matters
  9 2012-03-25 01:10:42 <sipa> forbidden
 10 2012-03-25 01:13:34 <luke-jr> sipa: ?
 11 2012-03-25 01:13:41 <luke-jr> oh
 12 2012-03-25 01:13:43 <sipa> 403
 13 2012-03-25 01:13:59 <luke-jr> try now
 14 2012-03-25 01:14:49 <sipa> works perfectly
 15 2012-03-25 01:16:02 <sipa> luke-jr: does encrypting a wallet work?
 16 2012-03-25 01:16:09 <Tril> http://pastebin.com/tipH0r8M   - coderrr patch seems to use a qt4.7-ism. Latest qt on Debian squeeze is 4.6.4
 17 2012-03-25 01:16:11 <sipa> that also causes a rewrite, which is where your deadlock occurs
 18 2012-03-25 01:17:16 <luke-jr> sipa: the wallet is already encrypted
 19 2012-03-25 01:17:45 <sipa> doesn't matter, since you can't start in this situation
 20 2012-03-25 01:18:01 <sipa> but in general, can you encrypt a new wallet (with a new addr.dat)?
 21 2012-03-25 01:18:04 <luke-jr> Tril: mention it on his pullreq; other code uses it too, but inside #ifs
 22 2012-03-25 01:19:17 <luke-jr> sipa: it seems to hang
 23 2012-03-25 01:19:41 <luke-jr> wait no, it finally finished
 24 2012-03-25 01:19:44 <luke-jr> so about a minute
 25 2012-03-25 01:19:56 <luke-jr> no problems once finished
 26 2012-03-25 01:27:20 <sipa> shouldn't take that long...
 27 2012-03-25 01:27:51 <luke-jr> especially for a new wallet
 28 2012-03-25 01:29:18 <knotwork> I jsut did git pull again and now it needs some new  CAddrMan:: thing, that I evidently do not have, where does one get it?
 29 2012-03-25 01:30:03 <knotwork> its only been a week or two since last I pulled so whatever it is must be somewhat new
 30 2012-03-25 01:30:25 <sipa> knotwork: can you paste the exact error?
 31 2012-03-25 01:30:32 <sipa> also, how do you build?
 32 2012-03-25 01:32:07 <knotwork> hand on its maybe just that my makefile.fedora is out of sync with latest makefile.unix I will make it fresh again hope I remember what is needed to change makefile.unix into makefile.fedora
 33 2012-03-25 01:33:49 <knotwork> ah got it. thought is was some new dependency but its just new code my fedora makefile didnt know about
 34 2012-03-25 01:34:13 <luke-jr> knotwork: best to use makefile.unix; I fixed it up for 0.5
 35 2012-03-25 01:34:35 <luke-jr> http://paste.pocoo.org/show/570822/ is my GNUmakefile
 36 2012-03-25 01:35:02 <knotwork> Fedora does not include correct crypto in its ssh libs, I have to use my own specially compiled dependencies
 37 2012-03-25 01:35:34 <knotwork> so I have to add -I../../deps/include and -L../../deps/lib and also define the -mt suffix for boost-thread lib
 38 2012-03-25 01:35:34 <luke-jr> &
 39 2012-03-25 01:36:01 <knotwork> there is some stupid patent thing about the elliptic curve algos so fedora leaves them out
 40 2012-03-25 01:36:13 <luke-jr> knotwork: OPENSSL_INCLUDE_PATH OPENSSL_LIB_PATH BOOST_LIB_SUFFIX
 41 2012-03-25 01:37:05 <knotwork> ah ok so maybe I just make a fedora-env.sh to set them up instead of a makefile.fedora
 42 2012-03-25 01:37:23 <luke-jr> :p
 43 2012-03-25 01:37:56 <knotwork> yeah but that wont warn people its for fedora if I clone it into a git or something
 44 2012-03-25 01:38:17 <luke-jr> sounds like your setup is more specific than fedora :p
 45 2012-03-25 01:39:15 <sipa> knotwork: just add addrman.o
 46 2012-03-25 01:40:28 <knotwork> well long ago there was some kind of guide to making your own ssl libs to work with it, that is where the ../../deps thing came from I think
 47 2012-03-25 01:40:42 <knotwork> but Fedora is the only common distro I know of that actually needs it
 48 2012-03-25 01:41:05 <sipa> fedora/redhat/centos all miss ecc-enabled openssl i believe
 49 2012-03-25 01:41:33 <knotwork> oh ok
 50 2012-03-25 01:42:04 <knotwork> used to be I also had to add libdl but havent had to lately
 51 2012-03-25 01:44:42 <gmaxwell> http://people.xiph.org/~greg/openssl/fedora16/ < fwiw
 52 2012-03-25 01:45:01 <luke-jr> lol
 53 2012-03-25 05:54:37 <weex> hello, i have a question about importprivkey in rpcdump.cpp
 54 2012-03-25 05:55:01 <weex> i see that it causes the program to scan for wallet transactions starting from the genesis block
 55 2012-03-25 05:55:41 <weex> would it be possible to speed it up by, if i know an address was just generated, setting that to start at a later block index?
 56 2012-03-25 05:57:08 <weex> i'm interested in being able to see unconfirmed transactions from more than one bitcoind on the network and hoping importprivkey can help
 57 2012-03-25 06:11:31 <weex> another way i'm looking at doing this is with libbitcoin, subvertx, and txrad but since i can already build bitcoind i'd like to start there
 58 2012-03-25 08:04:14 <Joric> sipa, https://github.com/joric/pywallet <- added compressed keys support as in 0.5.99 (private keys use your draft with 33-byte entries)
 59 2012-03-25 08:05:06 <sje> anything in latest bitcoin that could be affecting my connections? i've had it off for a few weeks, just updated and rebuilt and i'm getting lots of orhpans from p2pool now...seems to be lack of connections into/out of bitcoind
 60 2012-03-25 08:05:28 <sje> desktop has only shown 1 connection since the update
 61 2012-03-25 08:26:22 <wumpus> removing addr.dat might help
 62 2012-03-25 08:26:58 <sje> i'll try that, cheers
 63 2012-03-25 08:40:18 <sje> grr...still no connections
 64 2012-03-25 08:40:23 <gribble> New news from bitcoinrss: laanwj opened pull request 983 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/983>
 65 2012-03-25 09:41:38 <ThomasV> can we get a new block please?
 66 2012-03-25 09:41:47 <SomeoneWeird> no
 67 2012-03-25 09:41:49 <SomeoneWeird> >.>
 68 2012-03-25 09:42:08 <Graet> hang on a minute - I'll just arrange one
 69 2012-03-25 09:42:12 <ThomasV> please..
 70 2012-03-25 09:45:29 <ThomasV> do I have to mine it myself?
 71 2012-03-25 09:45:48 <ThomasV> with my laptop cpu?
 72 2012-03-25 09:45:59 <ThomasV> come on guys
 73 2012-03-25 09:47:15 <Graet> looks like :(
 74 2012-03-25 09:49:04 <ThomasV> why does it take 1h to get a block precisely when I am testing a function that does new block notification?
 75 2012-03-25 09:49:32 <ThomasV> ah there it is
 76 2012-03-25 09:50:12 <Graet> yep
 77 2012-03-25 09:50:19 <Graet> wasnt me tho :(
 78 2012-03-25 11:10:28 <etotheipi_> gmaxwell, sipa, two questions about how the deterministic wallet will work:  (1) You end up with money in your change chain... when you spend that, where does the change go?  Into the change chain again?  a new chain?  (2) If you have X in your primary chain and X in your change chain and you need to send 1.5X, the wallet has to pull from both chains...are you preventing this?
 79 2012-03-25 11:17:07 <gmaxwell> (1) yes, the change change why not? and to do otherwise would cause accidental reuse of an address if someone is tracking the primary and sends at the same time. (2) It would spend from both as needed there isn't any terrible harm if some change addresses are asscoiated.
 80 2012-03-25 11:26:35 <sipa> inputs are allowed to come from anyway, change outputs only go into a change chain
 81 2012-03-25 11:26:39 <sipa> *anywhere
 82 2012-03-25 11:27:14 <sipa> there are possible anonimity improvements to limit the number of different chains inputs are pulled from, but that's for later
 83 2012-03-25 11:27:56 <sipa> sje: which version are you running?
 84 2012-03-25 11:28:45 <sje> pulled master from git yesterday i think
 85 2012-03-25 11:29:04 <sipa> how long did it take to get a connection?
 86 2012-03-25 11:29:08 <sipa> without addr.dat
 87 2012-03-25 11:29:37 <sje> without the incoming port forwarded, it didn't get one in a couple of hours i think
 88 2012-03-25 11:29:49 <sje> i forwarded the port...now it's got three
 89 2012-03-25 11:30:09 <sje> been watching the logs and at least two of those were incoming...probably the third as well
 90 2012-03-25 11:30:23 <sipa> hours?
 91 2012-03-25 11:30:54 <sje> debug log is showing lots of addresses being tried, all timing out
 92 2012-03-25 11:32:26 <sje> at least an hour, i think two...dunno, been trying to help the wife with her course work...that's so random when it comes to making time fly :)
 93 2012-03-25 11:32:53 <sipa> dns seeds must be returned bad seeds then
 94 2012-03-25 11:33:34 <sje> the timeout seems pretty quick...i'm in AU
 95 2012-03-25 11:33:54 <sipa> 5 seconds, you can change it with -timeout=
 96 2012-03-25 11:34:25 <sje> hm...ping delay from being way over here is usually only a couple of hundred milliseconds...
 97 2012-03-25 11:34:49 <sje> 5 seconds should be plenty
 98 2012-03-25 11:36:46 <sje> i was getting heaps of orphans on p2pool also....might be trouble with my connection
 99 2012-03-25 11:36:55 <Diablo-D3> oj?
100 2012-03-25 11:36:57 <Diablo-D3> oh?
101 2012-03-25 11:37:53 <sje> last run had 14 orphans out of 16 total 'won' shares
102 2012-03-25 11:38:12 <Diablo-D3> heh, I have zero shares atm
103 2012-03-25 11:38:18 <sje> this setup was working a few weeks ago, but turned it off 'cause of hot weather
104 2012-03-25 11:38:31 <sje> i updated bitcoin, p2pool, and cgminer
105 2012-03-25 11:38:47 <sje> and it's been crappy
106 2012-03-25 11:39:09 <sje> might be coincidence that i started up again when my connection is stuffed
107 2012-03-25 11:39:30 <sje> or the ISP started shaping bitcoin related traffic in the mean time...or something
108 2012-03-25 11:40:09 <sje> p2pool seemed to be making connections ok, incoming and outgoing
109 2012-03-25 11:40:21 <Graet> what isp?
110 2012-03-25 11:40:22 <sipa> no, without an addr.dat i'm also unable to get connections
111 2012-03-25 11:40:24 <sje> but bitcoin seems to not be able to make any outgoind
112 2012-03-25 11:40:37 <sje> Graet: optus
113 2012-03-25 11:40:39 <sje> :(
114 2012-03-25 11:40:47 <sje> too far from the exchange for adsl
115 2012-03-25 11:40:54 <Graet> ahh nk, yer who knows withn them ;)
116 2012-03-25 11:41:01 <Graet> ouch
117 2012-03-25 11:41:08 <sje> same with telstra though
118 2012-03-25 11:41:16 <sipa> wait, IRC connect failed?
119 2012-03-25 11:41:17 <sje> and those are my choices, here
120 2012-03-25 11:41:45 <Graet> :/
121 2012-03-25 11:41:49 <sje> sipa: how do i check that?
122 2012-03-25 11:42:23 <sje> Graet: back at ozcoin for the moment, suspecting the p2pool orphans were due to being too far away from most everyone else
123 2012-03-25 11:42:45 <Graet> ahh ok , hope we work good for you :)
124 2012-03-25 11:42:46 <sipa> sje: irc is deprecated disabled by default, i turned it on using -irc
125 2012-03-25 11:42:53 <sipa> but it is very strange that it fails
126 2012-03-25 11:44:05 <sje> sipa: i did try it but not for very long...but yes watching all the connection timeouts in the debug log, it seems it has plenty of addresses to try
127 2012-03-25 11:44:14 <sje> even without irc
128 2012-03-25 11:45:16 <sje> Graet: ozcoin has always worked really well for me...only moved to p2pool to test it out, learn a little more about about distributed chains etc, a little to support the philosophy :)
129 2012-03-25 11:47:24 <sipa> sje: found my problem, proxy was set
130 2012-03-25 11:48:22 <sje> ah...getinfo here shows no proxy
131 2012-03-25 11:48:30 <Graet> cool sje :D
132 2012-03-25 11:49:17 <sipa> sje: so, with no addr.dat, and all default settings, it still takes you hours to connect?
133 2012-03-25 11:49:25 <sipa> here it happens within seconds
134 2012-03-25 11:49:49 <sje> just since i updated from git yesterday
135 2012-03-25 11:50:41 <sje> it connects reasonably quickly if i open the incoming port, but i've been running for over an hour now and have 3 connections i think all incoming
136 2012-03-25 11:51:19 <sje> running for over an hour with the incoming port open, that is
137 2012-03-25 11:51:52 <sje> and yeah, all default settings
138 2012-03-25 11:51:59 <sipa> and you deleted addr.dat before?
139 2012-03-25 11:52:08 <sje> yep
140 2012-03-25 11:52:19 <sipa> can you paste your debug.log?
141 2012-03-25 11:52:44 <sje> all of it?
142 2012-03-25 11:53:47 <sipa> first few hundred lines at the start of the last connect should be fine
143 2012-03-25 11:56:23 <sje> sipa: http://pastebin.com/NHf4ETm7
144 2012-03-25 11:57:55 <sipa> any special settings in bitcoin.conf?
145 2012-03-25 11:59:17 <sje> nup, don't think i have one
146 2012-03-25 11:59:27 <sje> that would be in .bitcoin if i did wouldn't it/
147 2012-03-25 11:59:29 <sje> ?
148 2012-03-25 12:01:00 <Graet> yes
149 2012-03-25 12:01:13 <sje> then nope, don't have one
150 2012-03-25 12:01:36 <sipa> how can you access getinfo, in that case?
151 2012-03-25 12:01:50 <sipa> without rpcuser/rpcpassword
152 2012-03-25 12:02:21 <sje> i have it on another machine, with the same problem
153 2012-03-25 12:03:34 <sipa> no firewall problem?
154 2012-03-25 12:03:56 <sje> never had one before - usually allow all outgoing
155 2012-03-25 12:04:33 <sje> the server could probably use a reboot, silly wifi router i'm using for a hub could probably use power cycling :)
156 2012-03-25 12:05:45 <sje> i gotta crash though, and the wife is still making me turn it off at night atm...not quite chilly enough yet...so i might give the server and router a restart and fire up again tomorrow....will let you know
157 2012-03-25 12:06:00 <sje> thanks for looking into it
158 2012-03-25 12:11:26 <gribble> New news from bitcoinrss: sipa opened pull request 984 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/984>
159 2012-03-25 12:14:41 <da2ce7> g2g bbs
160 2012-03-25 12:19:52 <sipa> etotheipi_: by the way, if #974 is merged, 0.6.0 will not use compressed pubkeys by default (only when starting a fresh wallet, using -upgradewallet, or encrypting)
161 2012-03-25 12:35:20 <sipa> Joric: re compressed pubkeys: nice; you don't seem to look at minversion though (should be more informative than version, in the future)
162 2012-03-25 12:48:33 <etotheipi_> gmaxwell, so money spent from the change chain will send it's change back to the same chain?  doesn't that kind of defeat the purpose of it?  And similarly, it seems that the longer you use the wallet, tons of change addresses are going to get linked back to the original chain since the wallet will frequently be pulling one output from each... this also seems to defeat the purpose of it
163 2012-03-25 12:50:43 <etotheipi_> I suppose you could try to optimize the wallet so it only pulls from one chain at a time if possible, but of course it can't always succeed
164 2012-03-25 12:52:00 <etotheipi_> sipa, why the change in compressed key support?  is there are problem with mixing them within a wallet?
165 2012-03-25 12:52:33 <Joric> sipa, yeah, i think i still have to write a proper DER serializer maybe even submit a patch to python-ecdsa
166 2012-03-25 12:52:51 <sipa> etotheipi_: not at all; it's just to prevent breaking backward compatibility (with older version, other programs, ...)
167 2012-03-25 12:53:09 <etotheipi_> ooh, yeah Luke mentioned that
168 2012-03-25 12:54:04 <sipa> it may become sort of a wallet versioning policy: opening a wallet in a newer version will not update its format, unless the user takes an explicit action from which he can expect such breaking (like encryption)
169 2012-03-25 12:54:20 <sipa> s/breaking/updating/
170 2012-03-25 13:05:57 <etotheipi_> sipa, so that means that my wallet conversion tool will continue to work on old wallets, as long as it was never touched by any of the 0.6.0 pre-RC5 versions...?
171 2012-03-25 13:06:38 <etotheipi_> well, to clarify:  if 0.6.0rc3 was used on a wallet, and it generated any addresses:  it *did* use compressed keys, right?
172 2012-03-25 13:07:58 <sipa> yes
173 2012-03-25 13:08:14 <sipa> 0.5.99 up to git head do so
174 2012-03-25 13:13:18 <sje> sipa: fyi, rebooted server & router, checked firewall...still no luck...also it seems -listen=0 stops -irc from working?
175 2012-03-25 13:13:27 <gmaxwell> etotheipi_: no because you're not learning about change addresses via some high latency process.
176 2012-03-25 13:13:34 <sje> tried with -timeout=10000, didn't help
177 2012-03-25 13:13:59 <sipa> sje: very strange, does an explicit -connect work?
178 2012-03-25 13:14:24 <sje> to any address?
179 2012-03-25 13:14:34 <sipa> to any that is likely to accept them
180 2012-03-25 13:14:39 <sipa> see http://bitcoin.sipa.be/seeds.txt for exaple
181 2012-03-25 13:14:48 <sje> ah thanks
182 2012-03-25 13:14:56 <etotheipi_> gmaxwell, if you have one transaction that pulls 5 outputs from change chain and one address from the main chain, all those change chain addresses are now linked:  especially because they were used by the main chain originally
183 2012-03-25 13:15:32 <etotheipi_> it seems like, after doing dozens of transactions, depending on the tx amounts, you're going ot end up with like half of your change transactions identified/linked to the main chain
184 2012-03-25 13:15:33 <sipa> right, but that's not more than what you learn from inputs taken from randomly generated address, is it?
185 2012-03-25 13:15:34 <gmaxwell> etotheipi_: they're linked, but also exausted.
186 2012-03-25 13:16:06 <sipa> i agree an improvement on anonimity is possible by reducing linking, but that seems independent
187 2012-03-25 13:16:10 <gmaxwell> sipa: well it can link (indirectly) e.g. two payments to main chain addresses which would otherwise be seperate.
188 2012-03-25 13:16:22 <gmaxwell> But thats unavoidable at least as a corner case.
189 2012-03-25 13:16:38 <gmaxwell> You always must have linking in order to spend all your money. :)
190 2012-03-25 13:16:56 <sipa> the question is what does someone who knows all your public address but not your change addresses learn
191 2012-03-25 13:16:57 <sje> sipa: first two on that list timeout also :(
192 2012-03-25 13:17:24 <etotheipi_> I guess I'm going back to beat this dead horse again... It seems like a marginal benefit to me
193 2012-03-25 13:17:37 <etotheipi_> with a lot of complexity to accommodate it
194 2012-03-25 13:18:03 <gmaxwell> etotheipi_: I don't see how thats related to your question
195 2012-03-25 13:18:06 <etotheipi_> many of your change addresses will end up identified unless you write some kind of system to optimize it
196 2012-03-25 13:18:20 <sje> nm...must be something i'm doing wrong...nite all
197 2012-03-25 13:18:50 <etotheipi_> and you will still link some anyway... so you're only hiding some of the change addresses, and you don't really get to decide which ones (it will be based on SelectCoins trying to construct future tx for you)
198 2012-03-25 13:18:50 <gmaxwell> etotheipi_: of course, but thats universally true many addresses will be linked if you're not making effort to minimize the linkage.
199 2012-03-25 13:19:13 <gmaxwell> etotheipi_: we have support for completely controlling that, it's just a freestanding patch still.
200 2012-03-25 13:19:56 <etotheipi_> gmaxwell, I'm planning how to accommodate your system in Armory, and sipa suggested I can just import it as two separate wallets
201 2012-03-25 13:20:03 <sipa> how will you distinguish change outputs from other outputs?
202 2012-03-25 13:20:19 <sipa> there is never more than one transaction to it, in normal operation
203 2012-03-25 13:20:21 <etotheipi_> but that's confusing to the user
204 2012-03-25 13:20:31 <gmaxwell> sipa: because of jagged coins you can very often tell.
205 2012-03-25 13:20:40 <sipa> true
206 2012-03-25 13:20:56 <sipa> 55.18 -> 50 + 5.18 probably means 50 is the output
207 2012-03-25 13:21:04 <gmaxwell> (though there are ways to improve that)
208 2012-03-25 13:21:06 <etotheipi_> I guess I'm not seeing how you plan to implement it yourself, in a way that achieves your stated goal
209 2012-03-25 13:21:26 <gmaxwell> sipa: or more like 55.1234567 -> 54 and 1.1234567 :)
210 2012-03-25 13:21:37 <etotheipi_> (btw, Armory does have an optimization in it to try to make change indistinguishable)
211 2012-03-25 13:21:45 <sipa> nice
212 2012-03-25 13:21:59 <etotheipi_> I was quite proud of that... it's basically just comparing the number of trailing zeros on the two outputs (if expressed as satoshis)
213 2012-03-25 13:22:14 <gmaxwell> etotheipi_: even if you're completely stupid about it seperating it decreases the leak. Optimizing for it decreases it further. And I just mentioned that coin controll patches that do this (As well as giving manual control)
214 2012-03-25 13:22:16 <etotheipi_> if the number of trailing zeros is approximately the same, give it a higher score
215 2012-03-25 13:22:37 <gmaxwell> (oh you mean jaggedness handling, K)
216 2012-03-25 13:22:46 <etotheipi_> and if there happens to be more trailing zeros on the change output, then extra credit for being deceptive :)
217 2012-03-25 13:23:30 <etotheipi_> gmaxwell, I'm really not clear why the leaking is so important, especially when you're not necessarily reducing it much
218 2012-03-25 13:24:20 <gmaxwell> etotheipi_:  So, I think you should go back and reread the prior discussion we had on this. I don't really want to rehash it yet again.
219 2012-03-25 13:24:25 <etotheipi_> I guess it comes down to priorities:  I *personally* feel like it doesn't benefit me at all to have separate change outputs... you clearly believe it's important to have the option
220 2012-03-25 13:25:18 <sipa> assume that jaggedness is not a problem (since it sounds fixable), you can give someone your public chain, and he cannot (easily) know your real outputs
221 2012-03-25 13:25:27 <etotheipi_> I feel like it's not even close to being worth the extra complexity, when half your change outputs will end up linked, anyway
222 2012-03-25 13:26:04 <gmaxwell> etotheipi_: I don't see why you think there is a lot of extra complexity here just treat it as a second chain.
223 2012-03-25 13:26:25 <etotheipi_> because now you're talking about optimizing to minimize cross-chain linking
224 2012-03-25 13:27:07 <sipa> i think they are orthogonal improvements
225 2012-03-25 13:27:08 <gmaxwell> etotheipi_: the optimizing is mostly orthogonal it's useful with and without the change chain.
226 2012-03-25 13:27:34 <gmaxwell> morover, linking with chainge is strictly less bad those addresses are all use-once for sure.
227 2012-03-25 13:29:11 <etotheipi_> requiring multiple chains to represent a single wallet and organize where coins from or go to is extra complexity to something that I feel should be fairly simple
228 2012-03-25 13:29:58 <etotheipi_> but like I said, I guess it comes down to priorities... I've heard your arguments about why it's important, but I disagree and would like to persuade you out of it...  but you'll do what you'll do and we can respectfully disagree
229 2012-03-25 13:33:03 <sipa> privacy in bitcoin is a difficulty problem: there are various ways through which people may learn information about your wallet, and it may be impossible to hide everything
230 2012-03-25 13:33:08 <sipa> *difficult
231 2012-03-25 13:33:36 <sipa> but with a single-chain determinstic wallet, anyone who knows the public part of the chain, knows every payment you do
232 2012-03-25 13:33:58 <etotheipi_> they know every payment to that wallet
233 2012-03-25 13:34:05 <etotheipi_> *to/from
234 2012-03-25 13:34:09 <gmaxwell> etotheipi_: the only argument I've seen against it is the (modest) complexity of tracking a seperate list of change. The argument for it that it can improve privacy, isn't disputable only that the magitude of it may be small.
235 2012-03-25 13:34:27 <sipa> etotheipi_: indeed
236 2012-03-25 13:35:02 <gmaxwell> etotheipi_: they knows the INs but not the outs with the seperated change.
237 2012-03-25 13:35:07 <sipa> splitting the chain in two is one step that at least makes it possible to hide things; there may be more necessary to achieve real privacy, but it's a necessary step if you want to share public determinstic wallets
238 2012-03-25 13:35:58 <etotheipi_> gmaxwell, the argument against it is that it doesn't make sense... to me, you're splitting apart an "atomic unit" of Bitcoin operations in such a way that provides very little benefit... and any benefit you get from it could be done much simpler just by using multiple wallets
239 2012-03-25 13:36:02 <gmaxwell> And it's a change that can't be made later while keeping the wallets compatible.
240 2012-03-25 13:38:13 <gmaxwell> etotheipi_: What is the atomic unit being split? Addresses should be independant and unrelated (to the greatest extent possible) in order to uphold the bitcoin privacy model.
241 2012-03-25 13:39:04 <sipa> i believe a part of the dispute comes from the fact that we reason from the point of view of the current satoshi code, and etotheipi_ from the point of view from his client; for us, it's easier to add a second chain (since we have to add the first one still as well), for him it's easier to use two wallets
242 2012-03-25 13:39:37 <gmaxwell> I don't see why etotheipi_s code can't just treat this as two wallets.
243 2012-03-25 13:39:45 <gmaxwell> Foo and Foo (change)
244 2012-03-25 13:39:58 <etotheipi_> sipa, that's 20% of it for me... I don't want to make my code more complex to accommodate something that doesn't make sense to me
245 2012-03-25 13:40:13 <etotheipi_> and the reason I don't want to do that is that it would be confusing as hell to the users
246 2012-03-25 13:40:32 <sipa> depends how well your abstraction works
247 2012-03-25 13:41:15 <gmaxwell> etotheipi_: IIRC You already depend on some crazy stuff to identify change in order to show a correct transaction register precisely because you lack this seperation.
248 2012-03-25 13:41:45 <etotheipi_> "crazy stuff" is just identifying which output has the higher change index
249 2012-03-25 13:41:48 <etotheipi_> *chainindex
250 2012-03-25 13:42:05 <etotheipi_> and only for transactions sent-to-self
251 2012-03-25 13:42:19 <sipa> etotheipi_: if you want to achieve the same effect, you'll need two wallets, and some way to create an automated transaction that spends any funds sent to the first one, to the second
252 2012-03-25 13:42:36 <sipa> that has the same anonimity effect, but requires more bitcoin transactions
253 2012-03-25 13:43:00 <etotheipi_> I don't want to do *any* automated transactions, ever
254 2012-03-25 13:43:25 <sipa> then how can you achieve the ability to give someone a public chain, without revealing all your payments?
255 2012-03-25 13:43:27 <etotheipi_> I don't want money moving while the user isn't looking... it looks suspicious
256 2012-03-25 13:43:47 <sipa> if you don't feel this is an important possibility, then i guess we have nothing left to discuss
257 2012-03-25 13:45:47 <etotheipi_> you avoid revealing all your payments by using different wallets... and moving money between them as necessary
258 2012-03-25 13:46:03 <gmaxwell> (sorry, I'm tied up so I can't keep discussing now. :( )
259 2012-03-25 13:46:26 <etotheipi_> gmaxwell, no worries... I should get back to development anyway
260 2012-03-25 13:46:51 <etotheipi_> if I'm exchanging watching-only wallets with my mom so that we can exchange money... I give her a dedicated watching-only wallet
261 2012-03-25 13:47:15 <etotheipi_> if I want the balance on that wallet is unimportant... only that payments were sent/received
262 2012-03-25 13:47:17 <gmaxwell> (I'm at the fsf members meeting right now amusing sidebar with the FSF and creative commons bouncing bitcoin back and forth between each other)
263 2012-03-25 13:47:28 <etotheipi_> gmaxwell, cool
264 2012-03-25 13:48:14 <sipa> etotheipi_: sure, that works too, but 1) it requires more transactions 2) it's harder for a user
265 2012-03-25 13:49:19 <sipa> while if it were done using two chains, and you have an "export watch-income-only chain" and a "export watch-income-and-sends-only chain", you don't need to explain the internal machinery
266 2012-03-25 13:50:01 <sipa> using better buzzword-compliant terminology, of course
267 2012-03-25 13:50:12 <etotheipi_> sipa, sounds pretty complicated to describe to the user
268 2012-03-25 13:50:36 <etotheipi_> as a user:  if I give someone a watching-only wallet, I expect that they will see all the transactions on it... that's why I gave it to them
269 2012-03-25 13:50:58 <sipa> harder than explaining him that he first needs to send all his income to another wallet, if he wants to maintain his privacy?
270 2012-03-25 13:51:39 <etotheipi_> sipa, users think in terms of wallets... subwallets is confusing
271 2012-03-25 13:51:51 <sipa> there is no subwallet from the point of view of the user
272 2012-03-25 13:52:06 <sipa> only whether or not he can observe payments
273 2012-03-25 13:52:33 <etotheipi_> sure there is, you just said there would be two different options for exporting a watchingonly wallet
274 2012-03-25 13:52:43 <sipa> yes
275 2012-03-25 13:53:55 <etotheipi_> and the option for exporting one chain doesn't necessarily even do what they want:  the person receiving it half the time doesn't know what outputs are change and which are not... I'm not sure how that benefits the user
276 2012-03-25 13:54:29 <sipa> i doubt you'll typically give it to a user; rather put it on a webserver that needs to generate unique receive addresses
277 2012-03-25 13:54:43 <sipa> though for some types of auditing it may be interesting, i suppose
278 2012-03-25 13:55:05 <etotheipi_> sipa, perhaps it comes down to this: to me, this sounds like something I would put under the advanced, or maybe even only Developer mode
279 2012-03-25 13:55:09 <etotheipi_> I think default should be one chain
280 2012-03-25 13:55:19 <etotheipi_> and users who understand and desire this functionality, can enable two chains
281 2012-03-25 13:55:56 <sipa> but it still requires doing a extra send-to-other-wallet explicitly, in your model
282 2012-03-25 13:56:28 <sipa> and a user who doesn't care about it, never sees (or even knows) about the idea of several subchains
283 2012-03-25 13:56:30 <etotheipi_> perhaps we need a specific use case, because I'm not sure why yours doesn't
284 2012-03-25 13:56:55 <etotheipi_> I need to actually lay this all out with two parties, multiple wallets and a use-case for it
285 2012-03-25 13:57:21 <sipa> ok, i'm a merchant, i have a full chain (both subchains, including private keys)
286 2012-03-25 13:57:25 <etotheipi_> perhaps there's something I'm really missing because I don't see the chain of events that would lead to yours not requiring extra transactions
287 2012-03-25 13:57:40 <sipa> i have a webserver running on linode, whom i do not trust
288 2012-03-25 13:58:04 <sipa> i want to give someone who breaks into my webserver as little information as possible
289 2012-03-25 13:58:37 <etotheipi_> so the server is just for generating addresses
290 2012-03-25 13:58:41 <sipa> indeed
291 2012-03-25 13:59:07 <sipa> what you suggest: create a separate wallet for the webserver, and move funds to your spending wallet
292 2012-03-25 13:59:28 <sipa> what we suggest: only export the public chain of a single wallet
293 2012-03-25 14:00:19 <etotheipi_> so how is the full wallet used?  to execute all transactions for your business, ever?
294 2012-03-25 14:00:33 <sipa> for example, or part of it
295 2012-03-25 14:01:04 <sipa> the difference: it's only one wallet, and the implicit transactions that move funds from the public chain to the internal chain are the same as the payments done themselves
296 2012-03-25 14:01:48 <etotheipi_> I guess, I've always been of the opinion that you'd be using separate wallets for each device/register
297 2012-03-25 14:01:55 <etotheipi_> anyway
298 2012-03-25 14:03:12 <etotheipi_> then you combine the money from individual wallets into some other wallet which is your primary wallet for business
299 2012-03-25 14:03:45 <etotheipi_> but I'll think on the webserver scenario, and see if I envision your idea as a replacement for the multi-wallets
300 2012-03-25 14:06:11 <etotheipi_> I guess I've mostly been thinking along the lines of regular users:  they use watching-only wallets for themselves, and would create separate watching-only wallets for different applications (like my mother-son exchange scenario)--it seems quite simple to grok and money management makes sense right away (even if it requires an extra transaction here and there)
301 2012-03-25 14:06:41 <etotheipi_> your usage scenario seems more targeted at developers
302 2012-03-25 14:06:43 <Tykling> guys, where do "comment" and "comment-to" go if specified when using sendfrom in the API ?
303 2012-03-25 14:07:12 <sipa> etotheipi_: it allows for an easier abstraction: a user who knows how to use it will more easily be able to learn how it is implemented internally, in your case
304 2012-03-25 14:07:42 <sipa> Tykling: in the wallet?
305 2012-03-25 14:07:57 <Tykling> sipa: right, it is only local info, correct ?
306 2012-03-25 14:08:00 <sipa> Tykling: yes
307 2012-03-25 14:08:05 <Tykling> sipa: thanks
308 2012-03-25 14:08:07 <etotheipi_> sipa, I'm going to lay out some specific use cases and examples usage scenarios... but I need to get back to RAM-reduction right now
309 2012-03-25 14:08:22 <sipa> etotheipi_: but not necessarily easier to use
310 2012-03-25 14:08:40 <etotheipi_> I'll come back when I have (1) conceded defeat (2) have something more specific to support not using them, or that it shouldn't be default
311 2012-03-25 14:08:47 <etotheipi_> *or
312 2012-03-25 14:09:03 <sipa> no need to concede defeat; it's just a different philosophy
313 2012-03-25 14:09:19 <gmaxwell> Yea. This isn't a war. :)
314 2012-03-25 14:09:22 <etotheipi_> sipa, it's very possible I just haven't thought through a full end-to-end usage scenario
315 2012-03-25 14:09:42 <sipa> you can support single-chain wallets, and allow import of a double-chain as two wallet imports
316 2012-03-25 14:09:55 <sipa> (with some manual intervention or not)
317 2012-03-25 14:10:40 <etotheipi_> sipa, my concern is that when a user imports a Satoshi wallet into Armory, it becomes two wallets and it doesn't make any sense why it's two wallet, and I don't see why it should be either... so that's why I'm arguing that "regular" wallets should be single chain unless the user explicitly selects dual chain
318 2012-03-25 14:11:27 <Tykling> one more question: when calling the bitcoind binary with api commands on the command line, does it set the exit code to non-zero if something goes wrong ? like insufficient balance to make a transfer ?
319 2012-03-25 14:11:30 <sipa> right; it becomes harder to maintain the abstraction for a user who wants to combine tools that have a different idea of what the abstraction is
320 2012-03-25 14:11:32 <etotheipi_> or you could argue, I should just support dual-chain wallets the same way if I don't want to induce that kind of confusion... both are valid
321 2012-03-25 14:12:15 <etotheipi_> perhaps it's just a difference in philosophy... somehow I'll find a way to merge them
322 2012-03-25 14:13:00 <Joric> sipa why not use 0x81 for compressed privkeys?
323 2012-03-25 14:13:24 <etotheipi_> Joric, I would very much enjoy that...
324 2012-03-25 14:13:49 <sipa> Joric: i did that initially, but believed it's wrong to call it a new version of private key, if there is no correspond new version of the public key
325 2012-03-25 14:13:54 <sipa> and there is no need for the latter
326 2012-03-25 14:14:06 <sipa> *corresponding
327 2012-03-25 14:14:12 <sipa> s/public key/address/
328 2012-03-25 14:16:22 <Joric> you probably right
329 2012-03-25 14:18:40 <Joric> i even believed that senior byte means private key
330 2012-03-25 14:20:24 <Joric> that addrtype byte probably needs detailed specification
331 2012-03-25 14:20:45 <sipa> it's a bit of a mess right now
332 2012-03-25 14:21:30 <Joric> e.g. ixcoin use addrtype 138
333 2012-03-25 14:22:22 <sipa> Tykling: try it
334 2012-03-25 14:25:17 <Joric> there was no private key type for ixcoin i had to fix overflow (138+128) & 255
335 2012-03-25 14:29:13 <Joric> it's not very bitset friendly, bits 6 and 5 already used by testnet 0x01101111 (111d)
336 2012-03-25 14:32:41 <jan23> hello
337 2012-03-25 14:33:52 <jan23> after upgrading from 0.4.0 to 0.5.3 (qt) the GUI doesn't show any of my addresses, no transactions and zero value. any idea how to fix it?
338 2012-03-25 14:34:15 <Joric> the whole thing with compressed keys is rather questionnable i.e. why use another address for the same 32-byte secret
339 2012-03-25 14:34:54 <sipa> Joric: it's the only way to roll it out in a backward compatible way
340 2012-03-25 14:35:53 <sipa> jan23: hmm, strange. do you have a backup?
341 2012-03-25 14:36:11 <jan23> no :-(
342 2012-03-25 14:36:24 <sipa> make one now
343 2012-03-25 14:36:39 <jan23> yes!
344 2012-03-25 14:36:39 <sipa> and then try opening it in 0.4 again
345 2012-03-25 14:37:00 <jan23> and then?
346 2012-03-25 14:37:19 <sipa> well, are the transactions there?
347 2012-03-25 14:38:42 <jan23> the old 0.4 worked without a problem for several months. it showed the transactions. if i would open the old data with it, it will work. or do you mean go from 0.4 -> 0.5 -> 0.4 ?
348 2012-03-25 14:39:51 <sipa> if you don't have a backup 0.4 -> 0.5 -> 0.4 is the only option, right?
349 2012-03-25 14:40:31 <jan23> right. let me check...
350 2012-03-25 15:09:19 <jan23> sipa: when opening with 0.4: EXCEPTION: 22DbRunRecoveryException       DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery       bitcoin in AppInit()
351 2012-03-25 15:09:21 <jan23> But i will try to find a backup...
352 2012-03-25 15:28:23 <gribble> New news from bitcoinrss: TheBlueMatt opened pull request 985 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/985>
353 2012-03-25 15:33:32 <jan23> sipa:  i will have the backup restored by tomorrow. any suggestion how to open it with 0.5.3?
354 2012-03-25 15:33:45 <sipa> it should just work
355 2012-03-25 15:34:00 <sipa> i'm just trying to find out why it didn't for you
356 2012-03-25 17:10:10 <bluemoon23> hey
357 2012-03-25 17:10:17 <bluemoon23> oops
358 2012-03-25 17:16:43 <andytoshi> heya
359 2012-03-25 17:19:44 <bluemoon23> can i buy bitcoins with a moneypak?
360 2012-03-25 17:21:21 <sipa> bluemoon23: ask in #bitcoin-otc
361 2012-03-25 17:21:38 <bluemoon23> k
362 2012-03-25 17:21:47 <bluemoon23> otc?
363 2012-03-25 17:23:42 <sipa> over the counter
364 2012-03-25 17:37:23 <BlueMatt> woo fixed #956 and #981 in a like 3 line patch to boost headers (can be done in bitcoin's gitian file)
365 2012-03-25 17:38:12 <luke-jr> BlueMatt: no way to handle it Bitcoin-Qt side/
366 2012-03-25 17:38:14 <luke-jr> ?
367 2012-03-25 17:39:01 <BlueMatt> luke-jr: maybeish, its probably easier to patch boost's source for now and file a boost bug report :(
368 2012-03-25 17:39:25 <BlueMatt> Im still trying to find the real root cause (something to do with how boost calls/win32 responds to api requests)
369 2012-03-25 17:39:45 <BlueMatt> but a pretty simple 3-line patch to cache values instead of always re-requesting them seems to work fine
370 2012-03-25 17:39:57 <luke-jr> O.o
371 2012-03-25 17:42:08 <BlueMatt> note that /all/ of boost::interprocess is in headers, so no need to modify boost+recompile, you just have to modify the headers
372 2012-03-25 17:44:01 <sipa> bah
373 2012-03-25 17:44:55 <BlueMatt> yea, thats what I thought
374 2012-03-25 17:45:30 <sipa> does diapolo's patch also fix the problem(s) ?
375 2012-03-25 17:45:59 <BlueMatt> his patch is a workaround for #956, not #981
376 2012-03-25 17:46:21 <BlueMatt> they are both caused by the same issue in boost, but are fairly different by the time we see them
377 2012-03-25 17:46:33 <sipa> what is the issue in 981?
378 2012-03-25 17:46:53 <sipa> oh, i see
379 2012-03-25 17:46:56 <BlueMatt> when we try to open the uri message_queue it fails
380 2012-03-25 17:47:00 <bluemoon23> hey
381 2012-03-25 17:47:05 <BlueMatt> so we can never actually send uris in the message_queue
382 2012-03-25 17:47:18 <sipa> it looked like a patch/improvement rather than a bug report
383 2012-03-25 17:47:53 <bluemoon23> when i try to install bitcoin the latest version it says "Runtime Error! Program: c:program filesitcoinitcoin-qt.exe This application has requested the Runtime to terminate in an unusual way. Please contact the applications support team for more informatioN" does nayone know how to fix?
384 2012-03-25 17:48:21 <BlueMatt> bluemoon23: thats a pretty generic error message, does your debug.log show anything at the end?
385 2012-03-25 17:49:35 <sipa> rc4 has a bug that manifests in reorganisations
386 2012-03-25 17:50:16 <BlueMatt> we really need to get an rc5 out...
387 2012-03-25 17:51:35 <sipa> maybe the bug was not present in earlier boost versions?
388 2012-03-25 17:51:40 <BlueMatt> maybe
389 2012-03-25 17:52:01 <BlueMatt> though I thought diapolo said he did testing on newer/older versions too, so...
390 2012-03-25 17:58:41 <bluemoon23> debug shows nothing at the end
391 2012-03-25 18:00:44 <sipa> bluemoon23: paste it somewhere, please?
392 2012-03-25 18:04:21 <bluemoon23> when i try to install bitcoin the latest version it says "Runtime Error! Program: c:program filesitcoinitcoin-qt.exe This application has requested the Runtime to terminate in an unusual way. Please contact the applications support team for more informatioN" does nayone know how to fix?
393 2012-03-25 18:04:30 <bluemoon23> and ive tried older versions
394 2012-03-25 18:04:33 <bluemoon23> and get the same message
395 2012-03-25 18:05:08 <sipa> bluemoon23: yes, i've seen that, but what is in debug.log?
396 2012-03-25 18:07:17 <bluemoon23> rg
397 2012-03-25 18:07:32 <bluemoon23> debug.log?
398 2012-03-25 18:07:34 <bluemoon23> where is this found?
399 2012-03-25 18:07:48 <sipa> in the data directory
400 2012-03-25 18:08:17 <sipa> see https://en.bitcoin.it/wiki/Data_directory
401 2012-03-25 18:20:05 <bluemoon23> debug folder is long
402 2012-03-25 18:20:09 <bluemoon23> i dont want to paste all of it here
403 2012-03-25 18:20:18 <sipa> just the last few pages is fine
404 2012-03-25 18:20:22 <bluemoon23> k
405 2012-03-25 18:20:25 <sipa> and not here, use pastebin.org
406 2012-03-25 18:21:20 <bluemoon23> Bitcoin version 0.5.3.1-beta
407 2012-03-25 18:21:21 <bluemoon23> Default data directory C:Documents and SettingsOwnerApplication DataBitcoin
408 2012-03-25 18:21:21 <bluemoon23> Loading addresses...
409 2012-03-25 18:21:22 <bluemoon23> LoadBlockIndex(): hashBestChain=00000000000005c94d53  height=136093
410 2012-03-25 18:21:23 <bluemoon23> EXCEPTION: NSt8ios_base7failureE
411 2012-03-25 18:21:24 <bluemoon23> C:Program FilesBitcoinitcoin-qt.exe in Runaway exception
412 2012-03-25 18:22:04 <BlueMatt> ahh, bluemoon23 please post multi-line pastes to a site like pastebin.com and link it instead of pasting it in the chan...
413 2012-03-25 18:22:12 <BlueMatt> sipa/luke-jr should I pull request https://github.com/TheBlueMatt/bitcoin/commit/1b327daeb510d91c065ea3610c4b5740c743fffe
414 2012-03-25 18:22:29 <BlueMatt> or does someone want to do more digging into whats going on in boost's calls to the win32 api?
415 2012-03-25 18:22:32 <bluemoon23> here
416 2012-03-25 18:22:33 <bluemoon23> http://pastebin.com/c66KyCv1
417 2012-03-25 18:22:50 <sipa> bluemoon23: looks like your block database got corrupted
418 2012-03-25 18:23:04 <sipa> bluemoon23: try deleting (or moving away) blkindex.dat and blk0001.dat
419 2012-03-25 18:23:18 <sipa> and indeed, please don't paste more than 3 lines on IRC
420 2012-03-25 18:24:41 <bluemoon23> where can i find those two .dat files?
421 2012-03-25 18:24:46 <BlueMatt> in your datadir
422 2012-03-25 18:26:18 <BlueMatt> screw it: https://github.com/bitcoin/bitcoin/pull/986