1 2012-06-10 02:00:51 <matt2011> https://bitcointalk.org/index.php?topic=86318.0
  2 2012-06-10 02:00:55 <matt2011> http://luke.dashjr.org/programs/bitcoin/files/charts/bestblocks.html
  3 2012-06-10 02:00:57 <matt2011> related?
  4 2012-06-10 02:02:31 <Diablo-D3> that post is two days old, and we're on block 183818 now....
  5 2012-06-10 02:03:03 <Diablo-D3> so he should have been on 183530 or so
  6 2012-06-10 02:03:34 <Diablo-D3> so yeah, his numbers check out
  7 2012-06-10 02:03:37 <Diablo-D3> something is wrong with his client
  8 2012-06-10 02:37:25 <midnightmagic> BlueMatt: thanks for the clarification.
  9 2012-06-10 02:41:20 <midnightmagic> Diablo-D3: I was stuck on an older-ish block last night with 0.6.2; I would have stayed to debug it but my miners were all basically halted, so I hurried up to 0.6.99 as of last night and corrected it.  0.6.2 couldn't -rescan on my wallet either.
 10 2012-06-10 02:41:44 <Diablo-D3> weird
 11 2012-06-10 03:35:55 <weex> is there a calculator of confirmation risk somewhere? $X => n confirmations for y% risk.
 12 2012-06-10 03:44:36 <nanotube> it'd be hard to quantify the risk <->tx value relationship
 13 2012-06-10 03:52:24 <weex> well there's some relationship between cost to 51% attack per unit time so i thought that could be used
 14 2012-06-10 03:53:14 <weex> maybe its too easy for such a tool to miscalculate risk?
 15 2012-06-10 03:57:23 <weex> i see satoshi did it for q, the % of the network controlled by the attacker
 16 2012-06-10 03:58:31 <nanotube> yes but there's a precise mathematical relationship between fraction of hash power, and probability of success
 17 2012-06-10 03:58:40 <nanotube> not so much between value of tx, and attacker's motivation :)
 18 2012-06-10 03:59:02 <nanotube> and hash power
 19 2012-06-10 03:59:02 <weex> good point
 20 2012-06-10 03:59:28 <nanotube> but you could do some heuristic-based measure, that would probably be "interesting" :)
 21 2012-06-10 03:59:56 <weex> what i'd like to say is if you're selling a house, here's how many confirmations should be ok
 22 2012-06-10 04:03:46 <TuxBlackEdo> well if you are selling a house via bitcoins and signing over the title, i am pretty sure that you could wait for 1 days worth of confirmations before closing escrow
 23 2012-06-10 04:06:00 <nanotube> also - you know the name of the guy, and where he lives :D
 24 2012-06-10 04:06:24 <nanotube> so if there's a doublespend... you are not sol.
 25 2012-06-10 04:15:32 <weex> i'm going to wait for 7 confirmations just to be sure
 26 2012-06-10 06:34:53 <TuxBlackEdo> hello anyone alive here?
 27 2012-06-10 07:19:41 <archevety> I get "amp;" in labels with qt GUI, does anyone know how to fix?
 28 2012-06-10 07:22:46 <archevety> seems like it's only a problem in the swedish version
 29 2012-06-10 07:24:00 <archevety> found the faults
 30 2012-06-10 07:24:26 <archevety> there are &amp;amp; in some translations
 31 2012-06-10 07:24:50 <archevety> is there a reason why or is this a fault?
 32 2012-06-10 11:01:46 <xorgate> why won't bitcoind let me see a tx that's not part of my wallet?
 33 2012-06-10 11:02:20 <sipa> you mean gettransaction?
 34 2012-06-10 11:02:33 <xorgate> yeh i take a random tx from blockexplorer but it gives me an error
 35 2012-06-10 11:02:46 <sipa> 0.7 allows gettransaction for blockchain and mempool transactions
 36 2012-06-10 11:03:01 <sipa> in earlier versions it's strictly for wallets
 37 2012-06-10 11:03:17 <xorgate> i see, i updated the windows client a few days ago
 38 2012-06-10 11:03:29 <sipa> 0.7 is not yet released
 39 2012-06-10 11:03:49 <xorgate> right ok makes sense thanks
 40 2012-06-10 11:05:11 <xorgate> it's not that i *need* to see them i'm just getting my feet wet in programming some automation
 41 2012-06-10 11:31:26 <[7]> annoying bitcoin-qt is annoying
 42 2012-06-10 11:33:09 <[7]> oh, and does sendfrom with account "" behave the same way as sendtoaddress? i.e. is the latter redundant?
 43 2012-06-10 11:33:46 <[7]> and what's the deal with addmultisigaddress? does it serve any purpose these days?
 44 2012-06-10 11:34:50 <[7]> IIUC that's related to BIP16?
 45 2012-06-10 11:34:58 <[7]> the wiki says "Currently only available on testnet", is that outdated?
 46 2012-06-10 11:35:04 <sipa> yes
 47 2012-06-10 11:35:22 <sipa> sendfrom with account "" is the same as sendtoaddress yes
 48 2012-06-10 11:35:40 <sipa> addmultisigaddress creates a multisig address
 49 2012-06-10 11:36:23 <sipa> and it's mostly BIP12, but the actual protocol level implementation is specified in BIP16 indeed
 50 2012-06-10 11:36:50 <[7]> anyway, now that BIP16 is active on the production network, this isn't testnet-only any more contrary to what the wiki says?
 51 2012-06-10 11:37:22 <sipa> yes and no
 52 2012-06-10 11:37:35 <sipa> you can create realnet multisig addresses
 53 2012-06-10 11:37:41 <sipa> you can send to them
 54 2012-06-10 11:38:07 <sipa> and you can spend when all keys related to a multisig address are in one wallet
 55 2012-06-10 11:38:15 <sipa> which obviously defeats the purpose
 56 2012-06-10 11:39:07 <sipa> but it shows that the protocol level changes are done, what is left is client-side transaction negotiation between the different parties in a multisig
 57 2012-06-10 11:48:01 <[7]> hm, apparently there are incoming and outgoing accounts, and only the incoming ones are shown by listaccounts?
 58 2012-06-10 11:48:33 <[7]> with incoming accounts I mean accounts containing owned addresses, and outgoing accounts are accounts containing addresses of third parties
 59 2012-06-10 11:49:53 <luke-jr> sipa: BIP13, not BIP12 :p
 60 2012-06-10 11:53:47 <graingert> do multisig addresses still use the first few bytes of sha256 at the end for validation?
 61 2012-06-10 11:53:57 <graingert> if so why not switch to a sensible CRC
 62 2012-06-10 11:54:31 <luke-jr> because it's TOO LATE :p
 63 2012-06-10 11:54:47 <graingert> really? nobody uses the addresses yet
 64 2012-06-10 11:55:06 <graingert> and it never hits the underlying network
 65 2012-06-10 11:55:27 <graingert> luke-jr: it all gets stripped it's only a user facing fanciness
 66 2012-06-10 11:56:00 <luke-jr> yes we do
 67 2012-06-10 11:56:17 <graingert> really who's used them?
 68 2012-06-10 11:56:28 <luke-jr> me
 69 2012-06-10 11:56:32 <graingert> anyone else?
 70 2012-06-10 11:56:52 <BlueMatt> several sites already accept p2sh addresses
 71 2012-06-10 11:57:00 <luke-jr> 3P14159f73E4gFr7JterCCQh9QjiTjiZrG and 31igiusSdShicXmGAbJHNJuit1rzuJYKzF
 72 2012-06-10 11:57:08 <BlueMatt> I believe blockchain.info does?
 73 2012-06-10 11:57:10 <sipa> i would love sensible scheme, with base32 address encoding and crc30 checksums
 74 2012-06-10 11:57:13 <graingert> accept?
 75 2012-06-10 11:57:30 <sipa> but i prefer not introducing YET ANOTHER encoding
 76 2012-06-10 11:57:32 <luke-jr> and like sipa says, the checksum is the least of the problems with addresses
 77 2012-06-10 11:57:44 <graingert> fair enough
 78 2012-06-10 11:57:50 <BlueMatt> s/accept/use for something where if you changed everyone's addresses you would cause problems/
 79 2012-06-10 11:58:02 <graingert> well it would only change p2sh
 80 2012-06-10 11:58:04 <graingert> addresses
 81 2012-06-10 11:58:31 <graingert> and it would be possible to convert between them
 82 2012-06-10 11:58:59 <graingert> either way it's clear a sensible scheme would make more sense
 83 2012-06-10 11:59:09 <luke-jr> for example, it would be nice if the version bytes were really useful
 84 2012-06-10 11:59:20 <graingert> and better do it now while it's just blockchain.info and luke-jr that get affected
 85 2012-06-10 11:59:30 <nanotube> haha
 86 2012-06-10 11:59:33 <luke-jr> graingert: and every 0.6 user
 87 2012-06-10 11:59:49 <graingert> luke-jr: who've never used p2sh
 88 2012-06-10 11:59:55 <luke-jr> who will someday.
 89 2012-06-10 12:00:10 <[7]> but I think we agree that those will get more, not less, over time
 90 2012-06-10 12:00:10 <graingert> but they'll need to upgrade anyway to do negotiation
 91 2012-06-10 12:00:11 <someone42> the first few bytes of sha256 isn't a bad error detection code
 92 2012-06-10 12:00:23 <luke-jr> graingert: nonsense
 93 2012-06-10 12:00:35 <luke-jr> they're not necessarily going to receive
 94 2012-06-10 12:00:39 <luke-jr> but sending is necessary
 95 2012-06-10 12:01:01 <graingert> people don't seem that adverse to upgrading
 96 2012-06-10 12:01:10 <graingert> it's in goddamn beta
 97 2012-06-10 12:01:19 <graingert> that's what beta is for
 98 2012-06-10 12:01:20 <someone42> as far as error detection codes go, using a cryptographic hash is nearly optimal
 99 2012-06-10 12:01:23 <luke-jr> people might be willing to use 0.8 to get the benefits of P2SH themselves - but a lot less likely if it means everyone paying them must also use 0.8
100 2012-06-10 12:01:48 <sipa> someone42: wrong
101 2012-06-10 12:02:03 <sipa> it is the best against attackers, yes
102 2012-06-10 12:02:27 <sipa> but it is far from the best against random transmission errors
103 2012-06-10 12:02:55 <sipa> something that crcs give hard quantified guarantees against
104 2012-06-10 12:02:57 <graingert> luke-jr: old and "new style" addresses would still be operational
105 2012-06-10 12:03:34 <graingert> and I'm sure someone would backport it
106 2012-06-10 12:03:38 <luke-jr> <.<
107 2012-06-10 12:03:56 <sipa> i do not want another type of addresses
108 2012-06-10 12:04:19 <someone42> sipa: oh, i see; sha256 only gives you a probabilistic guarantee
109 2012-06-10 12:04:31 <sipa> exactly
110 2012-06-10 12:04:49 <sipa> it's not better than any random function
111 2012-06-10 12:04:57 <BlueMatt> graingert: if you can show that the chance of address corruption is somehow too high to be reasonable, sure, but if your only argument is, it would be cooler if we... then I really see no reason to change anything?
112 2012-06-10 12:05:03 <sipa> while crcs are effectively better
113 2012-06-10 12:05:26 <someone42> unfourtunately, crc doesn't really work with base58 :(
114 2012-06-10 12:05:32 <graingert> BlueMatt: I just think it's the last opportunity to do so
115 2012-06-10 12:05:42 <BlueMatt> its past the last opportunity
116 2012-06-10 12:05:45 <graingert> someone42: what
117 2012-06-10 12:05:46 <sipa> you can construct a base58 crc
118 2012-06-10 12:05:57 <graingert> BlueMatt: sigh
119 2012-06-10 12:06:09 <sipa> it'd require some research to get a good one
120 2012-06-10 12:06:14 <graingert> well next time we need a new address format
121 2012-06-10 12:06:27 <BlueMatt> hopefully we dont have a next time
122 2012-06-10 12:06:51 <sipa> graingert: i hope we don't need addresses at all anymore somewhere in the future
123 2012-06-10 12:07:05 <graingert> sipa: what wizardry are you going for there?
124 2012-06-10 12:07:13 <graingert> some webfinger protocol?
125 2012-06-10 12:07:20 <sipa> you'd have uri's and payment descriptor files
126 2012-06-10 12:07:30 <graingert> I want to send coin to graingert@mtgox.com
127 2012-06-10 12:07:36 <sipa> that are mailed and sent over the web
128 2012-06-10 12:07:51 <luke-jr> graingert: that will never be secure decentralized
129 2012-06-10 12:07:53 <graingert> and https://__bitcoin.mtgox.com/ describes the address
130 2012-06-10 12:07:59 <sipa> negotiated transactions out of band
131 2012-06-10 12:08:07 <luke-jr> graingert: there you go inventing new redundant crap
132 2012-06-10 12:08:12 <sipa> something like that
133 2012-06-10 12:08:18 <graingert> luke-jr: I'm suggesting that's mental
134 2012-06-10 12:08:22 <graingert> not suggesting it's a good idea
135 2012-06-10 12:08:32 <graingert> luke-jr: sipa wants addressless tx
136 2012-06-10 12:08:37 <luke-jr> at the very least use an existing standard :P
137 2012-06-10 12:09:02 <graingert> luke-jr: something like libravatar then
138 2012-06-10 12:09:04 <luke-jr> ie, _bitcoinpay._tcp.mtgox.com
139 2012-06-10 12:09:22 <graingert> or
140 2012-06-10 12:09:33 <sipa> https://gist.github.com/1237788
141 2012-06-10 12:09:35 <graingert> https://mtgox.com/.well_known/bitcoin.json
142 2012-06-10 12:09:36 <sipa> read that
143 2012-06-10 12:10:45 <graingert> sipa: go have a look at how browserID does communication and negotiation of keys
144 2012-06-10 12:10:52 <graingert> sipa: it might be usefull to copy them
145 2012-06-10 12:10:56 <BlueMatt> where was gavin's one covering taking bitcoin: uris and adding sanity checks/p2sh exchanging among multiple clients/payment processor verification/etc
146 2012-06-10 12:12:45 <graingert> everyone uses http these days
147 2012-06-10 12:13:02 <graingert> I think you want to go for the minimal setup route
148 2012-06-10 12:13:16 <BlueMatt> s/http/https/
149 2012-06-10 12:13:17 <graingert> ie no DNS entries and use existing http/TLS
150 2012-06-10 12:13:23 <sipa> my mail about bip22 to the ml still hasn't arrived?
151 2012-06-10 12:13:36 <graingert> BlueMatt everyone uses http
152 2012-06-10 12:13:42 <graingert> BlueMatt some people also use https
153 2012-06-10 12:13:44 <graingert> for protocol stuff
154 2012-06-10 12:13:51 <BlueMatt> graingert: and using http for anything payment-related is stupid
155 2012-06-10 12:13:56 <BlueMatt> https is ok
156 2012-06-10 12:14:01 <graingert> of course but not what I was refering to
157 2012-06-10 12:14:18 <graingert> I was refering to the fact that nobody builds real protocols on top of TCP
158 2012-06-10 12:14:26 <graingert> they use REST or something
159 2012-06-10 12:14:32 <sipa> ... except Satoshi
160 2012-06-10 12:14:36 <graingert> of course
161 2012-06-10 12:14:39 <graingert> because he's nuits
162 2012-06-10 12:14:54 <sipa> he was RESTless
163 2012-06-10 12:15:00 <BlueMatt> anyway, yea, using the existing pki and https or similar existing protocol for payment exchanging will probably be the end result
164 2012-06-10 12:15:08 <BlueMatt> I dont think anyone wants to reinvent the wheel here
165 2012-06-10 12:15:10 <graingert> BlueMatt agreed
166 2012-06-10 12:15:26 <graingert> what about webfinger/WebID/foaf ?
167 2012-06-10 12:15:44 <graingert> eg webfinger(user@foo.com) -> returns URI for user
168 2012-06-10 12:15:46 <sipa> anyone got my mail about bip22?
169 2012-06-10 12:15:50 <graingert> in that document is a PGP key
170 2012-06-10 12:15:51 <BlueMatt> sipa: no
171 2012-06-10 12:15:56 <graingert> that can sign bitcoin addresses
172 2012-06-10 12:15:56 <sipa> grmbl
173 2012-06-10 12:16:15 <graingert> eg crytpo:publickey
174 2012-06-10 12:16:28 <graingert> eg: http://www.w3.org/2005/Incubator/webid/spec/
175 2012-06-10 12:16:42 <BlueMatt> https://gist.github.com/2217885
176 2012-06-10 12:17:12 <BlueMatt> bitcoin: uri-based stuff
177 2012-06-10 12:17:22 <luke-jr> [14:09:35] <graingert> https://mtgox.com/.well_known/bitcoin.json <-- this is not a standard
178 2012-06-10 12:18:05 <luke-jr> BlueMatt: https forces centralization
179 2012-06-10 12:18:13 <graingert> luke-jr: https://tools.ietf.org/html/rfc5785
180 2012-06-10 12:18:17 <luke-jr> [14:14:18] <graingert> I was refering to the fact that nobody builds real protocols on top of TCP <-- utter nonsense
181 2012-06-10 12:18:30 <BlueMatt> luke-jr: and you are suggesting?
182 2012-06-10 12:18:52 <graingert> luke-jr: sigh s/nobody/very few people/
183 2012-06-10 12:19:16 <graingert> luke-jr: the vast majority of protocols on the internet is http
184 2012-06-10 12:19:21 <graingert> luke-jr: eg Twitter
185 2012-06-10 12:19:26 <graingert> luke-jr: Facebook
186 2012-06-10 12:19:28 <graingert> SPARQL
187 2012-06-10 12:19:29 <graingert> etc
188 2012-06-10 12:19:29 <luke-jr> BlueMatt: server+address pair URIs, where the address is only used to verify the server's key
189 2012-06-10 12:19:36 <luke-jr> graingert: those aren't protocols
190 2012-06-10 12:19:43 <luke-jr> graingert: they're websites for idiots
191 2012-06-10 12:20:04 <graingert> luke-jr: you're a bigot
192 2012-06-10 12:20:27 <sipa> please people
193 2012-06-10 12:20:52 <sipa> it's true that these days protocols are typically built on higher level protocols
194 2012-06-10 12:21:06 <luke-jr> graingert: protocols are things like IMAP4, POP3, SMTP, SNMP, etc
195 2012-06-10 12:21:08 <BlueMatt> luke-jr: read gavin's gist
196 2012-06-10 12:21:17 <sipa> since they are easier to get through firewalls, or integrated with browser apps
197 2012-06-10 12:21:29 <graingert> luke-jr: why isn't the Twitter api a protocol?
198 2012-06-10 12:21:34 <graingert> because it's a website for idiots
199 2012-06-10 12:21:38 <graingert> of course
200 2012-06-10 12:22:14 <luke-jr> BlueMatt: it doesn't address when the central entity isn't trusted
201 2012-06-10 12:22:34 <graingert> use namecoin certificate pinning
202 2012-06-10 12:22:49 <graingert> to avoid CAs
203 2012-06-10 12:22:57 <BlueMatt> luke-jr: if you trust no central entity, its impossible
204 2012-06-10 12:23:04 <graingert> BlueMatt ^
205 2012-06-10 12:23:10 <sipa> namecoin has an interesting approach, but a flawed solution imho
206 2012-06-10 12:23:19 <luke-jr> ^
207 2012-06-10 12:23:24 <BlueMatt> you have to trust someone to provide a trusted bitcoin: uri to begin with
208 2012-06-10 12:23:25 <graingert> /
209 2012-06-10 12:23:41 <luke-jr> BlueMatt: so that URI should be self-sufficient
210 2012-06-10 12:24:10 <sipa> but people can tamper with the URI in transit
211 2012-06-10 12:24:21 <sipa> unless you do it yourself in real life
212 2012-06-10 12:24:25 <BlueMatt> sipa: hence why you need https/etc for initial transit
213 2012-06-10 12:24:29 <sipa> indeed
214 2012-06-10 12:24:48 <BlueMatt> and hence my statement that at some point, you need trust, even if its only in your dns chain
215 2012-06-10 12:25:00 <sipa> but i prefer that solution, but it allows people to use a different transit mechanism if thry do not trust the SSL PKI
216 2012-06-10 12:25:12 <BlueMatt> (and no, even a well-done namecoin doesnt solve it imho, you need something that everyone uses, not a nice program)
217 2012-06-10 12:25:13 <sipa> s/but/because/
218 2012-06-10 12:25:36 <luke-jr> BlueMatt: a reasonably-written Namecoin alternative could be integrated into Bitcoin clients for payments.
219 2012-06-10 12:25:40 <BlueMatt> anyway, I have to go
220 2012-06-10 12:25:50 <BlueMatt> luke-jr: yay! lets double bitcoin's size to do payment processing...
221 2012-06-10 12:26:16 <BlueMatt> and require everyone to have TWO chains in their .bitcoin, because 2g just really isnt enough
222 2012-06-10 12:26:43 <luke-jr> I said reasonably-written
223 2012-06-10 12:27:42 <sipa> grr i wonder why my mail doesn't arrive
224 2012-06-10 12:59:26 <luke-jr> [14:45:57] <guruvan> so I have an old wallet - stopped working when I updated to 0.6.2 - I have it up and running again in 0.5.5, but all the balances read 0 - is there any recouse besides reverting to an older backup?
225 2012-06-10 13:09:33 <BlueMatt> sipa: the largest issue with using https to give the user a bitcoin:address?url-signed-with-address-to-get-payment-target link was the non-repudiation issue
226 2012-06-10 13:09:43 <BlueMatt> sipa: iirc, no one could come up with a good way to do that
227 2012-06-10 13:13:46 <sipa> explain?
228 2012-06-10 13:18:09 <BlueMatt> eg I get a link to pay to 1AMAZON from https://amazon.com, I then pay, and then amazon turns around and says "no, you paid the wrong address, I cant send you your product because I didnt actually get the coins"
229 2012-06-10 13:18:23 <BlueMatt> now I should be able to prove that amazon ripped me off
230 2012-06-10 13:18:53 <BlueMatt> by signing the final payment address directly with a pki-trusted cert from https://amazon.com I can do so
231 2012-06-10 13:21:47 <sipa> BlueMatt: did you ever read my proposal?
232 2012-06-10 13:22:28 <sipa> https://gist.github.com/1237788
233 2012-06-10 13:26:54 <sipa> it results in a notice signed by the payment processor
234 2012-06-10 13:27:18 <sipa> which is proof the transaction was accepted as payment for a particular order
235 2012-06-10 13:27:28 <BlueMatt> what is it signed with?
236 2012-06-10 13:28:11 <sipa> everything :)
237 2012-06-10 13:28:24 <sipa> eventually the key that was used in the URI
238 2012-06-10 13:29:00 <BlueMatt> but there is no method to prove the key used in the uri is held by the payment requestor?
239 2012-06-10 13:29:01 <sipa> obviously someone can claim that key in the URI they used isn't theirs
240 2012-06-10 13:29:36 <sipa> the payment descriptor is sigmed by that
241 2012-06-10 13:29:45 <BlueMatt> thats the problem trying to be solved here ;)
242 2012-06-10 13:29:57 <sipa> there is no solution to that
243 2012-06-10 13:30:00 <BlueMatt> ehhh...wow that sentence made no sense...
244 2012-06-10 13:30:09 <BlueMatt> pki works pretty well for that, actually
245 2012-06-10 13:30:15 <sipa> of course
246 2012-06-10 13:30:29 <sipa> if you trust the SSL PKI, there is no problem
247 2012-06-10 13:30:42 <sipa> but you cannot do that without trust
248 2012-06-10 13:30:55 <BlueMatt> well ofc not, but you cant really do any of this without trusting /someone/
249 2012-06-10 13:31:02 <sipa> exactly
250 2012-06-10 13:31:14 <sipa> well, or a WoT
251 2012-06-10 13:31:15 <BlueMatt> the point is, 99.999% of people trust the pki, so you can prove that amazon ripped you off
252 2012-06-10 13:31:20 <BlueMatt> well yea
253 2012-06-10 13:31:48 <BlueMatt> but you do have to have a final sig from a pki-valid cert
254 2012-06-10 13:32:33 <sipa> meh, big companies would just publish their descriptor-request-service's key
255 2012-06-10 13:33:01 <sipa> it'd be on their https website, maybe in DNSSEC-certified entries, ...
256 2012-06-10 13:33:20 <guruvan> luke-jr:  when I open the broken wallet in 0.5.5 a get a lot of these:
257 2012-06-10 13:33:20 <sipa> and any number of other ways of publishing they like
258 2012-06-10 13:33:21 <guruvan> ERROR: FetchInputs() : fc6610b04d mapTransactions prev not found f1f4057e75
259 2012-06-10 13:33:24 <BlueMatt> the issue then becomes how to enable key-rotation (esp of smaller sites) in such a way that clients can stil prove an old one
260 2012-06-10 13:33:24 <guruvan> ERROR: AcceptToMemoryPool() : FetchInputs failed fc6610b04d
261 2012-06-10 13:33:49 <sipa> BlueMatt: new key signed by old key :)
262 2012-06-10 13:34:33 <sipa> but those keys are entirely unrelated to the transaction keys
263 2012-06-10 13:34:36 <BlueMatt> sipa: I dont see how that would work in such a way that its enforceable, if a site simply changes their entire key set, claims that they've never had a set of keys, and screws their 5 users out of all their coins, what can I do?
264 2012-06-10 13:34:48 <BlueMatt> yea, ofc they are
265 2012-06-10 13:34:50 <sipa> nothing, obviously
266 2012-06-10 13:35:09 <BlueMatt> but if you use pki-signed certs to sign the final payment info, then there is
267 2012-06-10 13:35:49 <sipa> or just sign the descriptor uri (including key) with a PKI certified key, you have the same level of trust
268 2012-06-10 13:36:43 <sipa> but people will just click "yeah, proceed anyway, I want my iPad 7 HD, even if the cerrtificate chain fails"
269 2012-06-10 13:38:37 <BlueMatt> well users clicking "YES, I want to lose all my coins" cant be helped, but there should be a sane method to keep users safe, and users should be encouraged to use it...anyway, yea signing the list of addresses allowed to sign payment request info with pki-trusted certs works too
270 2012-06-10 13:39:05 <BlueMatt> in any case, the point is you should have pki-signing required, not just entirely optional
271 2012-06-10 13:39:34 <BlueMatt> or at least "If you click yes, you will send coins to someone who cannot be trusted"-type-required
272 2012-06-10 13:40:13 <luke-jr> great, I can only accept Bitcoins if I pay $500 to Random Centralized Trust Org
273 2012-06-10 13:40:32 <BlueMatt> luke-jr: startssl
274 2012-06-10 13:41:05 <BlueMatt> also, thats true to begin with, you have to have a https site, for the most part
275 2012-06-10 13:41:09 <[7]> hm... what's the deal with keypoolrefill?
276 2012-06-10 13:41:14 <[7]> what is it good for?
277 2012-06-10 13:41:20 <luke-jr> BlueMatt: no, you really don't.
278 2012-06-10 13:41:24 <BlueMatt> [7]: uhh...refilling keypool
279 2012-06-10 13:41:28 <[7]> I had the impression that bitcoind does that automatically when the wallet is unlocked
280 2012-06-10 13:41:36 <luke-jr> I'm perfectly comfortable with IM and PGP
281 2012-06-10 13:41:49 <BlueMatt> [7]: oh, the rpc command...
282 2012-06-10 13:42:02 <[7]> yes
283 2012-06-10 13:42:41 <BlueMatt> luke-jr: if you are communicating on-one-on using pgp/etc, you probably dont need to use a fancy use-this-url-to-get-your-dest scheme
284 2012-06-10 13:43:36 <BlueMatt> [7]: yea, its pretty much entirely redundant
285 2012-06-10 13:46:49 <luke-jr> BlueMatt: you do if addresses are gone
286 2012-06-10 13:47:39 <BlueMatt> luke-jr: meh, so go to startssl and get a cert there, its free
287 2012-06-10 13:49:53 <finway> Hi,devs,let's talk about prunning.
288 2012-06-10 13:50:10 <finway> I just saw that the blockchain will be 54GB next year.
289 2012-06-10 13:50:50 <finway> That makes pruning  high priority, right ?
290 2012-06-10 13:51:21 <BlueMatt> https://github.com/bitcoin/bitcoin/pull/1405
291 2012-06-10 13:51:24 <[7]> finway: buy a bigger disk :P
292 2012-06-10 13:51:41 <[7]> or implement a blockchaind
293 2012-06-10 13:52:07 <BlueMatt> pruning blkNNNN.dat is quite difficult with the current system, better off implementing spv
294 2012-06-10 13:52:14 <finway> I find out pruning infeasible.
295 2012-06-10 13:52:53 <finway> Because every unspent satoshi should link to the coinbase tx.
296 2012-06-10 13:52:56 <luke-jr> [15:50:11] <finway> I just saw that the blockchain will be 54GB next year. <-- wtf?
297 2012-06-10 13:53:08 <finway> This is a chain, so we can't prune.
298 2012-06-10 13:53:11 <BlueMatt> its not infeasible, just difficult
299 2012-06-10 13:53:32 <finway> luke-jr: bad english.
300 2012-06-10 13:54:05 <BlueMatt> luke-jr: guessing based on satoshidice, I wouldnt be surprised if, in a year (assuming we dont prune at least blkindex.dat) we hit 50GB
301 2012-06-10 13:54:18 <finway> [7], good idea, how about take 1 year to catch up the blockchain ?
302 2012-06-10 13:54:38 <[7]> that just needs a more efficient distribution system
303 2012-06-10 13:55:14 <finway> distribution is not the problem, verifing is the problem, because "trust nobody", right ?
304 2012-06-10 13:55:17 <[7]> I'd like if someone would fix the underlying issue that every client (wallet) needs a copy of the blockchain
305 2012-06-10 13:55:36 <BlueMatt> but pruning blkindex.dat should help a ton, really...if the db doesnt grow too fast, we can keep db lookup times down, and save a ton of disk space
306 2012-06-10 13:55:37 <[7]> finway: I trust my own servers, but don't want to carry a blockchain around on all of my devices
307 2012-06-10 13:55:52 <BlueMatt> [7]: see: electrum
308 2012-06-10 13:55:55 <[7]> so I'd be happy to have just one blockchaind which backs the other clients
309 2012-06-10 13:56:21 <[7]> BlueMatt: for now I've decided to go with just one central bitcoind + spesmilo or some web interface
310 2012-06-10 13:56:47 <[7]> kinda of a "private cloud ewallet"
311 2012-06-10 13:57:01 <[7]> btw, IIUC encrypting a wallet is irreversible? at least until now?
312 2012-06-10 13:57:02 <BlueMatt> and the stuff you are talking about is coming, both in the satoshi client, and others
313 2012-06-10 13:57:18 <[7]> BlueMatt: coming, sure, but not there yet :)
314 2012-06-10 13:57:18 <BlueMatt> yea, it currently is, well its not, but there is no code to do it
315 2012-06-10 13:57:42 <BlueMatt> iiuc, electrum is doing pretty well
316 2012-06-10 13:57:44 <finway> What if some big reorg happens,  and the orphan chain clients update, and cost 1 month to redownload the chain ?
317 2012-06-10 13:57:58 <[7]> i.e. I should make a backup before playing with encryption on my testnet wallet if I don't want to have to regenerate all the test TXNs at some point
318 2012-06-10 13:58:11 <BlueMatt> [7]: yes
319 2012-06-10 13:58:18 <[7]> finway: hope they organize into an efficient p2p network :P
320 2012-06-10 13:58:25 <[7]> bittorrent works well in such situations
321 2012-06-10 13:58:31 <[7]> so why not bitcoin as well :)
322 2012-06-10 13:58:46 <BlueMatt> finway: again, fixes are coming, we are probably gonna be pruning blkindex.dat very soon, and spv clients exist
323 2012-06-10 13:59:14 <finway> BlueMatt, What about blk001.dat ?
324 2012-06-10 13:59:39 <BlueMatt> [7]: more efficient downloads are on the horizon, but that actually will have little effect on chain sync speed (except in rare cases)
325 2012-06-10 14:00:29 <BlueMatt> finway: again, thats a pretty difficult thing to do in the current network, we could easily prune it, but as bitcoin stands now, you still need non-pruned nodes to distribute the chain to ibd-ers
326 2012-06-10 14:01:02 <BlueMatt> finway: its probably better to skip that and just implement spv mode, or use an existing spv client (or something very close to it, which exist)
327 2012-06-10 14:03:13 <finway> BlueMatt, I've saw the bitcoin folder size grow from 1.7GB to 2.2GB in a short time, I'm afraid one year later, if some bugs destroy my local blockchain database, how long would it take to redownload the blockchani...
328 2012-06-10 14:03:53 <finway> I want to support the bitcoin network, but redownloading happens a lot.
329 2012-06-10 14:16:43 <[7]> why is encrypting a wallet such a processing power intensive operation?
330 2012-06-10 14:19:15 <[7]> hm, or maybe rather disk-intensive operation, causing lots of iowait processor time
331 2012-06-10 14:20:35 <finway> Is MultiBit running SPV ?
332 2012-06-10 14:21:06 <[7]> hm... I guess the proper way to tell apart an encrypted or unencrypted wallet is looking for the "unlocked_until" field in getinfo?
333 2012-06-10 14:26:41 <[7]> oh, and two more questions:
334 2012-06-10 14:26:56 <[7]> 1. what's the format of the "errors" field in getinfo? plain text? can it contain newlines? or html?
335 2012-06-10 14:27:16 <[7]> 2. is there a way to figure out what the highest seen block number on the network is through RPC?
336 2012-06-10 14:27:46 <finway> bitcoind getblockcount
337 2012-06-10 14:28:09 <[7]> is that the network or local blockchain?
338 2012-06-10 14:28:33 <[7]> I'm looking for a way to figure out how many blocks bitcoind hasn't downloaded yet
339 2012-06-10 14:29:53 <finway> [7], local
340 2012-06-10 14:30:59 <[7]> well, bitcoin-qt shows the download progress, so I think bitcoind must have that information somewhere... but it doesn't expose it through RPC?
341 2012-06-10 14:31:11 <finway> Sure.
342 2012-06-10 14:34:40 <[7]> what do you think are the odds of getting a patch accepted that adds a field for this?
343 2012-06-10 14:35:27 <BlueMatt> finway: there is no reason redownloading should happen a lot
344 2012-06-10 14:36:19 <finway> BlueMatt, i was suggested to redownload the chain when some problem happens.
345 2012-06-10 14:36:29 <finway> More than once.
346 2012-06-10 14:37:06 <[7]> and I think I was even suggested to re-download the blockchain from time to time to get .bitcoin back to a sane size
347 2012-06-10 14:37:40 <finway> [7], re-downloading can save disk space, really ?
348 2012-06-10 14:38:01 <BlueMatt> [7]: yea, Ive been thinking of looking into pruning orphan blocks from blkNNNN.dat, but I dont see how it would save more than like 20MB
349 2012-06-10 14:38:22 <[7]> BlueMatt: I'm more concerned of various BDB files growing badly
350 2012-06-10 14:38:33 <[7]> and apparently there's no way to just rebuild the index without redownloading the chain
351 2012-06-10 14:38:38 <BlueMatt> finway: thats largely because people are lazy, there should always be a way to fix it...
352 2012-06-10 14:38:48 <[7]> I think my record was about 6-7GB for .bitcoin so far
353 2012-06-10 14:39:04 <BlueMatt> [7]: there is, actually
354 2012-06-10 14:39:06 <finway> BlueMatt, So, the "7. Reclaiming Disk Space" in bitcoin.pdf is difficult,right ?
355 2012-06-10 14:39:20 <BlueMatt> [7]: db_dump | db_load
356 2012-06-10 14:39:21 <[7]> well, people always keep telling me "anything wrong with a BDB file? => redownload the chain"
357 2012-06-10 14:39:40 <[7]> even though I think everything should be rebuildable from blk0001.dat and wallet.dat
358 2012-06-10 14:40:19 <BlueMatt> oh, you mean corrupted bdb, well, yea usually you have to redownload (note that with 0.7, you can reimport now)
359 2012-06-10 14:40:44 <finway> reimport, that's good.
360 2012-06-10 14:41:04 <finway> Saves the downloading time.
361 2012-06-10 14:41:18 <[7]> and a lot of network traffic and thus stress on the p2p network
362 2012-06-10 14:41:54 <BlueMatt> it saves time in the first ~100-150k blocks, after that, it saves only some time...
363 2012-06-10 14:42:17 <[7]> someone wants a sneak preview? :)
364 2012-06-10 14:42:23 <BlueMatt> s/some time/network/
365 2012-06-10 14:42:24 <[7]> https://theseven.bounceme.net:8338/ user: webuser, pass: webpass
366 2012-06-10 14:42:49 <BlueMatt> [7]: that is?
367 2012-06-10 14:43:05 <BlueMatt> an updated https://github.com/tcatm/bitcoin-js-remote ?
368 2012-06-10 14:43:09 <[7]> kinda
369 2012-06-10 14:43:14 <[7]> not updated, but rewritten
370 2012-06-10 14:43:28 <BlueMatt> nice
371 2012-06-10 14:43:34 <BlueMatt> took long enough
372 2012-06-10 14:43:45 <phantomcircuit> BlueMatt, reimport as in read blk0001.dat instead of a peer?
373 2012-06-10 14:43:47 <[7]> well, no idea why nobody seemd to care for that long
374 2012-06-10 14:43:47 <finway> What's this ?
375 2012-06-10 14:43:49 <BlueMatt> phantomcircuit: yea
376 2012-06-10 14:43:53 <phantomcircuit> smart
377 2012-06-10 14:43:57 <[7]> took me like 3 days to implement what's there currently
378 2012-06-10 14:44:03 <BlueMatt> phantomcircuit: -loadblock=file
379 2012-06-10 14:44:48 <[7]> so I hope to reach feature parity with bitcoind (but not bitcoin-qt, due to lacking RPC functions) within a couple of days
380 2012-06-10 14:44:59 <BlueMatt> [7]: nice!
381 2012-06-10 14:45:05 <finway> [7], what's this ?
382 2012-06-10 14:45:16 <[7]> I call it a "private cloud ewallet"
383 2012-06-10 14:45:32 <BlueMatt> finway: a web frontend for bitcoind's rpc interface
384 2012-06-10 14:45:49 <[7]> I'll throw it on github once the most important stuff actually works :)
385 2012-06-10 14:45:54 <finway> BlueMatt,oh ,like SafeBit
386 2012-06-10 14:46:17 <finway> But more geeky.
387 2012-06-10 14:47:13 <finway> [7], nice job.
388 2012-06-10 14:47:20 <[7]> I'm wondering whether I should try to implement some kind of "simple mode" that attempts to abstract the whole account business like bitcoin-qt does
389 2012-06-10 14:48:28 <[7]> feel free to play around with it, it's running on testnet :)
390 2012-06-10 14:50:11 <[7]> hm, to create a new account, you just do a setaccount on some pre-existing bitcoin address?
391 2012-06-10 14:50:37 <finway> Once the latest transaction in a coin is buried under enough blocks, the spent transactions before it can be discarded to save disk space.  To facilitate this without breaking the block's hash, transactions are hashed in a Merkle Tree [7][2][5], with only the root included in the block's hash. Old blocks can then be compacted by stubbing off branches of the tree.  The interior hashes do not need to be stored.
392 2012-06-10 14:51:59 <BlueMatt> finway: yes, its entirely possible, but some nodes always have to hold the full chain, so that others can download...
393 2012-06-10 14:53:07 <finway> BlueMatt, the network can't live without un-pruned nodes?
394 2012-06-10 14:54:04 <BlueMatt> in theory, it could-ish, but it requires some heavy changes...
395 2012-06-10 14:55:39 <finway> BlueMatt, i'm interested in it, i'll learn more.
396 2012-06-10 14:56:00 <finway> Scalability is the last big issue of bitcoin network.
397 2012-06-10 15:19:02 <mobile> hi
398 2012-06-10 15:19:43 <mobile> hello
399 2012-06-10 15:20:50 <mobile> lame
400 2012-06-10 15:21:02 <mobile> grrr
401 2012-06-10 15:25:16 <BlueMatt> mobile: people are around, though many people rarely respond to hi...
402 2012-06-10 15:58:05 <[7]> there's no way to delete an account, right?
403 2012-06-10 16:18:57 <[7]> it's kinda odd that some really basic things can only be done through the UI, but not the RPC interface
404 2012-06-10 16:20:08 <[7]> the underlying issue here seems to be that if you setaccount an accounts primary address to a different account a new primary address for the old account will be generated
405 2012-06-10 16:20:09 <luke-jr> [7]: they're really two separate clients :p
406 2012-06-10 16:20:43 <luke-jr> sharing some core code
407 2012-06-10 16:21:03 <[7]> which means you just can't get rid of an account without changing labels in bitcoin-qt, which obviously doesn't create a new address for an account that's going empty, but instead evicts the account
408 2012-06-10 16:21:32 <[7]> is there a point in bitcoind instead generating a new address in this case?
409 2012-06-10 16:29:15 <[7]> oh, even more fun
410 2012-06-10 16:29:31 <[7]> it's possible to create address-less accounts by moving funds to nonexistant account names
411 2012-06-10 16:30:09 <[7]> which means you'll probably have to create an address for that account first to make it show up in bitcoin-qt so you can remove it again
412 2012-06-10 16:31:01 <[7]> hahaha, no, in that case bitcoin-qt just removes the address, but leaves the account alone
413 2012-06-10 16:31:39 <[7]> any way you can think of to get rid of such an account? :)
414 2012-06-10 16:35:06 <someone42> would i be correct in saying that if locktime = 0, any sequence fields are ignored?
415 2012-06-10 16:48:06 <[7]> so private keys basically look like addresses, just a bit longer?
416 2012-06-10 16:48:09 <[7]> e.g. cQXpCqyoCRdPARsoJ3TNf3zrk4gPNG3UCYNhQRCej7ii6kyxqgEY
417 2012-06-10 16:49:47 <[7]> hm...
418 2012-06-10 16:49:48 <[7]> importprivkey <bitcoinprivkey> [label]
419 2012-06-10 16:49:53 <[7]> shouldn't that be [account]?
420 2012-06-10 16:55:27 <[7]> aarrrrrrgh
421 2012-06-10 16:55:29 <[7]> seriously...
422 2012-06-10 16:55:33 <[7]> "RPC error -4: Private key for address mmQDeLtWW6zA8o8pRYR8RouPHJRwUM9KZJ is not known"
423 2012-06-10 16:55:52 <[7]> why can't it say "wallet is locked", which is the real issue here?
424 2012-06-10 16:57:20 <luke-jr> [7]: "label" is an old name for accounts
425 2012-06-10 16:57:35 <luke-jr> maybe submit a pullreq to fix it, and rebase it for a few months until someone decides to merge it or not
426 2012-06-10 16:57:37 <luke-jr> <.<
427 2012-06-10 16:58:20 <[7]> I think I could submit a dozen pullreqs of that kind by now
428 2012-06-10 16:58:56 <luke-jr> sure, but probably want to do it slowly or they might get closed for stupid reasons <.<
429 2012-06-10 16:59:14 <luke-jr> and if it's all the same thing (replacing label with account in help), just make one doing all of them
430 2012-06-10 16:59:31 <[7]> nah, it's various different bugs in unimportant strings
431 2012-06-10 16:59:42 <[7]> and maybe adding one or two things to getinfo
432 2012-06-10 17:00:05 <xorgate> so i'm talking to bitcoind via the rpc. i wish to call gettransaction, but as stated earlier this will only work for 'foreign' (aka not mine) tx until 0.7.0 . Now i see in github there's already a patch for it, can i just grab master repo and compile, or does something maybe break?
433 2012-06-10 17:00:37 <luke-jr> xorgate: no, it will only work for your own, until 0.7
434 2012-06-10 17:00:51 <luke-jr> git master (github) is what will become 0.7
435 2012-06-10 17:01:04 <luke-jr> but don't expect it to be near the quality of the stable releases
436 2012-06-10 17:01:53 <xorgate> because it will go through testing first, you mean?
437 2012-06-10 17:06:04 <BlueMatt> yes
438 2012-06-10 17:06:19 <BlueMatt> its very poorly tested compared to stable releases
439 2012-06-10 17:11:23 <[7]> do you think it would be a controversial change to add a call to EnsureWalletIsUnlocked in dumpprivkey?
440 2012-06-10 17:14:04 <[7]> IMO it's a bug that it isn't there
441 2012-06-10 17:20:45 <BlueMatt> seems sane to me
442 2012-06-10 17:21:05 <BlueMatt> does it currently just return some other error if its locked?
443 2012-06-10 17:22:33 <[7]> BlueMatt: [20:55:38] <[7]> "RPC error -4: Private key for address mmQDeLtWW6zA8o8pRYR8RouPHJRwUM9KZJ is not known"
444 2012-06-10 17:22:53 <BlueMatt> yea, EnsureWalletIsUnlocked seems much more sane then
445 2012-06-10 17:23:38 <[7]> that would change the error to "RPC error -13: Error: Please enter the wallet passphrase with walletpassphrase first."
446 2012-06-10 17:23:55 <BlueMatt> yea
447 2012-06-10 17:34:40 <BlueMatt> could be...
448 2012-06-10 17:34:59 <BlueMatt> rpc should be cleaned up anyway...multiple files, etc
449 2012-06-10 17:40:37 <BlueMatt> would be cool to have separate rpc "modules" that communicate with wallet, net, blockchain/mempool, etc
450 2012-06-10 17:41:00 <BlueMatt> then EnsureWalletIsUnlocked should probably be a flag on walletrpc
451 2012-06-10 17:47:46 <[7]> can someone quickly give me a testnet private key that isn't in my wallet?
452 2012-06-10 17:47:53 <[7]> need to test importing :)
453 2012-06-10 17:48:48 <luke-jr> 93HCc7NRD4YwiWtPxivynqJuHpDUX5mzkEM8yxUgFbfmLFMbW3K
454 2012-06-10 17:48:54 <luke-jr> is msawWRJdTxhc9Jqn3keUK3qtuWqwWbGw1q
455 2012-06-10 17:49:09 <luke-jr> ./vanitygen -T m <-- handy
456 2012-06-10 18:28:12 <ThomasV_> tcatm: your txlist on bitcoincharts contains very old transactions. are they still being relayed by the network?
457 2012-06-10 18:43:26 <Diapolo> What exactly does this ExitTimeout(), which is created as a thread on Win-Shutdown?
458 2012-06-10 18:49:01 <BlueMatt> Im pretty sure it existed back with satoshi.  It seems to imply windows needs additional time before quitting, but I wouldnt know
459 2012-06-10 18:51:04 <BlueMatt> Diapolo: heh, I misunderstood laanwj's comment too, and had started to respond that it may end up making calls to pwalletMain after it has been deleted
460 2012-06-10 18:51:12 <[7]> maybe somehow related to windows trying to kill applications after 20 seconds during shutdown?
461 2012-06-10 18:52:53 <BlueMatt> [7]: what?
462 2012-06-10 18:53:02 <[7]> that exittimeout thing
463 2012-06-10 18:53:21 <BlueMatt> no, I didnt understand you comment
464 2012-06-10 18:53:44 <Diapolo> hey there
465 2012-06-10 18:53:47 <[7]> well, windows gets a bit angry if any given process doesn't terminate within 20 seconds during a system shutdown
466 2012-06-10 18:53:49 <Diapolo> had no eye on IRC
467 2012-06-10 18:54:27 <BlueMatt> [7]: ExitTimeout really doesnt appear to be doing anything for that, though...
468 2012-06-10 18:54:48 <Diapolo> Seems to be an architectural-mess if you ask me ^^.
469 2012-06-10 18:55:15 <BlueMatt> agreed, but, again, maybe Im the only one who finds calls to uiInterface.* to just be slightly less ugly forms of #ifdef
470 2012-06-10 18:56:08 <Diapolo> I prefer every simpler or better looking solution ;).
471 2012-06-10 18:56:24 <Diapolo> But first I have to understand, what's happening ...
472 2012-06-10 18:56:41 <Diapolo> ExitTimeout does an ExitProcess ...
473 2012-06-10 18:56:51 <Diapolo> Which process does it exit?
474 2012-06-10 18:56:52 <BlueMatt> as it stands now, sometimes we call Shutdown directly, sometimes uiInterface.QueueShutdown
475 2012-06-10 18:57:06 <BlueMatt> for now, Id say ignore ExitTimeout
476 2012-06-10 18:57:13 <Diapolo> are core and Qt 2 processes?
477 2012-06-10 18:57:42 <BlueMatt> no, ExitProcess(0); looks, to my untrained-on-windows eye, like the equivalent of exit(0);
478 2012-06-10 18:57:48 <BlueMatt> which we call on windows anyway, so...?
479 2012-06-10 18:58:19 <BlueMatt> Id assume ExitTimeout was there to work around some windows-specific bug, so Id say just leave it, it shouldnt hurt anything
480 2012-06-10 18:58:39 <Diapolo> BlueMatt: but if ExitProcess() would exit Bitcoin-Qt it would not log my added "Bitcoin-Qt exited" message, which I can read in debug.log here :D.
481 2012-06-10 18:58:57 <Diapolo> alright, main problem was, when Shutdown is called, the Qt Gui is simply killed without the chance for a clean shutdown, right?
482 2012-06-10 18:59:04 <kiba> hey guys
483 2012-06-10 18:59:10 <kiba> you heard of bitcoinweekly?
484 2012-06-10 18:59:12 <BlueMatt> as I read it, it will never get to ExitProcess(0);
485 2012-06-10 18:59:31 <BlueMatt> it only Sleep(50);s before exit(0);, but Sleep(5000); before ExitProcess(0);
486 2012-06-10 18:59:49 <BlueMatt> Diapolo: yes, but the gui needs to shutdown first
487 2012-06-10 19:00:19 <Diapolo> perhaps that is a dumb question but GUI = Bitcoin-Qt?
488 2012-06-10 19:00:24 <BlueMatt> yea
489 2012-06-10 19:00:28 <Diapolo> alright ^^
490 2012-06-10 19:01:18 <BlueMatt> who doesnt?
491 2012-06-10 19:01:18 <kiba> why the developers aren't compressing the blockchain yet?
492 2012-06-10 19:01:24 <BlueMatt> compressing wont help
493 2012-06-10 19:01:26 <Diapolo> laanwj said calling QueueShutdown in Shutdown would not work, as the Qt EvenLoop would be gone ...
494 2012-06-10 19:01:33 <Diablo-D3> compressing actually could help
495 2012-06-10 19:01:49 <Diablo-D3> but it'd take a custom dictionary compressor
496 2012-06-10 19:01:52 <BlueMatt> Diapolo: because sometimes QueueShutdown is called first, and then it calls Shutdown to finish
497 2012-06-10 19:02:06 <BlueMatt> Diablo-D3: it would help download speed, but not chain sync speed?
498 2012-06-10 19:02:14 <Diablo-D3> both.
499 2012-06-10 19:02:17 <kiba> I need to write an article for my magazine
500 2012-06-10 19:02:23 <kiba> bitcoinweekly is going to come back
501 2012-06-10 19:02:26 <BlueMatt> Diablo-D3: how?
502 2012-06-10 19:02:30 <Diablo-D3> Ill probably write a bitcoin impl someday
503 2012-06-10 19:02:33 <Diablo-D3> Ill show you then
504 2012-06-10 19:02:34 <kiba> and it's going to take its niche back from bitcoinmagazine.net
505 2012-06-10 19:02:40 <Diablo-D3> but Im just too busy working on lugh
506 2012-06-10 19:03:07 <kiba> bitcoinmagazine.net and bitcoinweekly.com have very different focus
507 2012-06-10 19:03:18 <kiba> bitcoinmagazine is like a party animal and social schemer.
508 2012-06-10 19:03:40 <BlueMatt> Diablo-D3: I fail to see how sig verification would be sped up by compression...
509 2012-06-10 19:03:41 <kiba> it's trying to incentivize people to sign up, tweet them, etc
510 2012-06-10 19:03:46 <kiba> and bitcoinweekly
511 2012-06-10 19:03:47 <kiba> is like
512 2012-06-10 19:03:49 <kiba> ALL SERIOUS
513 2012-06-10 19:04:09 <Diablo-D3> blueMatt: oh, thats easily sped up by opencl.
514 2012-06-10 19:04:23 <kiba> bitcoinmagazine starts their content halfway down the screen
515 2012-06-10 19:04:24 <BlueMatt> ok, and how is that related to compression?
516 2012-06-10 19:04:38 <kiba> it's like it's not even improtant
517 2012-06-10 19:04:41 <Diablo-D3> bluematt: we were talking download speed
518 2012-06-10 19:04:43 <BlueMatt> kiba: cool, but how is this development related?
519 2012-06-10 19:04:51 <Diablo-D3> it'd also help storage too
520 2012-06-10 19:04:52 <kiba> BlueMatt: nothing
521 2012-06-10 19:04:56 <kiba> I am just dissing my competitor
522 2012-06-10 19:05:05 <gribble> New news from bitcoinrss: Rudd-O opened issue 1438 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1438>
523 2012-06-10 19:05:09 <Diablo-D3> bluematt: we need a second impl in C anyhow
524 2012-06-10 19:05:13 <BlueMatt> Diablo-D3: well, ok, you could speed up disk writing a bit, but...
525 2012-06-10 19:05:21 <Diablo-D3> so might as well finish up lugh, and build a new lib on it.
526 2012-06-10 19:05:23 <BlueMatt> Diablo-D3: on ssds/etc it would probably barely help
527 2012-06-10 19:05:37 <Diablo-D3> Im not on an ssd, and bitcoin takes like209582309582309580293580 fucking minutes to start
528 2012-06-10 19:05:40 <BlueMatt> a second full implementation, period, would be nice
529 2012-06-10 19:05:45 <BlueMatt> Diablo-D3: tmpfs?
530 2012-06-10 19:05:52 <Diablo-D3> no
531 2012-06-10 19:05:57 <Diablo-D3> its fine once its all in cache though
532 2012-06-10 19:06:00 <Diapolo> BlueMatt: QueueShutdown() sends a quit to the Qt EvenLoop ... that would not trigger our Shutdown()?
533 2012-06-10 19:06:07 <BlueMatt> Diablo-D3: it wasnt a question, it was a suggestion ;)
534 2012-06-10 19:06:12 <Diablo-D3> bluematt: either way
535 2012-06-10 19:06:19 <Diablo-D3> I like where lugh is going
536 2012-06-10 19:06:23 <Diablo-D3> I just realized something hilarious
537 2012-06-10 19:06:31 <Diablo-D3> so, I build this layered stm impl, right?
538 2012-06-10 19:06:33 <BlueMatt> Diapolo: I was under the impression it called shutdown at some point in the callback...
539 2012-06-10 19:06:43 <BlueMatt> Diablo-D3: wtf is lugh?
540 2012-06-10 19:06:46 <Diablo-D3> I can start transactions while transactions are running, and it just becomes part of the parent transactions
541 2012-06-10 19:06:59 <Diablo-D3> bluematt: my base library, sorta like glib and whatnot, but not shit.
542 2012-06-10 19:07:06 <Diablo-D3> Im tired of people using C worng
543 2012-06-10 19:07:06 <Diapolo> BlueMatt: I can't seem to find that ... see line 94 bitcoin.cpp
544 2012-06-10 19:07:10 <Diablo-D3> so Im going to use it right.
545 2012-06-10 19:07:17 <BlueMatt> you are re-implementing glib???
546 2012-06-10 19:07:24 <Diablo-D3> bluematt: no no no
547 2012-06-10 19:07:27 <Diablo-D3> its just a base library.
548 2012-06-10 19:07:36 <BlueMatt> because there arent already enough of those
549 2012-06-10 19:07:38 <Diablo-D3> reimplementing glib wouldnt make any sense, the API is the worst part of it
550 2012-06-10 19:07:45 <Diablo-D3> no, there actually ISNT enough
551 2012-06-10 19:07:50 <Diablo-D3> they all do _the same fucking thing_
552 2012-06-10 19:07:53 <Diablo-D3> and they all do it badly.
553 2012-06-10 19:08:03 <Diablo-D3> why the fuck didnt they just do it right instead
554 2012-06-10 19:08:09 <kiba> Diablo-D3: just use ruby
555 2012-06-10 19:08:18 <Diablo-D3> kiba: fuck you.
556 2012-06-10 19:08:24 <Diablo-D3> and ruby is balls slow as well
557 2012-06-10 19:08:53 <kiba> you are sure opininated.
558 2012-06-10 19:08:56 <Diablo-D3> bluematt: anyhow, so, stm, right? I just realized, since my malloc impl will use my stm impl.... mallocs are now transaction aware.
559 2012-06-10 19:09:17 <kiba> how about an interview with my magazine, bitcoinweekly.com
560 2012-06-10 19:09:28 <Diablo-D3> that means if I abort a transaction... it aborts the malloc as well.
561 2012-06-10 19:09:31 <kiba> about your GLBSE traded company
562 2012-06-10 19:09:46 <Diablo-D3> kiba: everyone is asking me for an interview.
563 2012-06-10 19:09:57 <Diablo-D3> wait until I have an ocean of solar panels in a field somewhere.
564 2012-06-10 19:10:03 <BlueMatt> Diablo-D3: transaction'd malloc...that makes sense...
565 2012-06-10 19:10:24 <Diablo-D3> bluematt: no one fucking does this! and why the fuck is everything so goddamned threaded in shit
566 2012-06-10 19:10:32 <Diablo-D3> Im almost getting rid of threads.
567 2012-06-10 19:10:43 <BlueMatt> Diapolo: uhhh...well then its fucked up, it  should call Shutdown
568 2012-06-10 19:10:57 <Diablo-D3> an app written that uses lugh will be using processes and pipes most of the time
569 2012-06-10 19:11:10 <BlueMatt> wump: ping
570 2012-06-10 19:11:26 <Diablo-D3> the only thread usage will be for stuff where you really do have to share the memory space.
571 2012-06-10 19:11:28 <Diapolo> BlueMatt: Can you verify this finding? Seems all very weird ...
572 2012-06-10 19:11:45 <BlueMatt> Diapolo: afaict, you are right, which is very broken
573 2012-06-10 19:11:59 <Diablo-D3> bluematt: but yeah, lugh + opencl, I probably could do bitcoin 10 times faster
574 2012-06-10 19:12:20 <BlueMatt> doing opencl sig checking, yea, bitcoin would be insanely faster
575 2012-06-10 19:12:53 <Diablo-D3> but thats far in the future
576 2012-06-10 19:13:04 <BlueMatt> Diablo-D3: no, no nevermind it does call Shutdown
577 2012-06-10 19:13:04 <Diablo-D3> I have to go spend a few months writing a malloc impl first
578 2012-06-10 19:13:10 <BlueMatt> Diapolo: ^
579 2012-06-10 19:13:10 <Diablo-D3> tabfail
580 2012-06-10 19:13:15 <BlueMatt> sorry
581 2012-06-10 19:13:19 <Diapolo> Diablo-D3 I think reducing fragmentation of used DBs and block-chain file would be a start!
582 2012-06-10 19:13:33 <Diablo-D3> Diapolo: probably
583 2012-06-10 19:13:34 <Diapolo> BlueMatt: Where does it do this?
584 2012-06-10 19:13:39 <Diablo-D3> but I could just write a damned db for this
585 2012-06-10 19:13:47 <BlueMatt> Diapolo: I think using an os that doesnt fragment like fucking shit would fix the problem
586 2012-06-10 19:14:16 <Diapolo> Well I use a patch, which keeps the block-chain file in one fragment, this helps a little.
587 2012-06-10 19:14:32 <BlueMatt> Diapolo: (just guessing) when you call the qt quit method, app.exec() returns, allowing it to call Shutdown(NULL); in qt/bitcoin.cpp
588 2012-06-10 19:15:17 <Diapolo> BlueMatt: I found noui_QueueShutdown() but this is not used with Qt I think ^^.
589 2012-06-10 19:16:02 <BlueMatt> Diapolo: if I were gonna do this, I would change Shutdown to be if(GUI) uiInterface.QueueShutdown; else FinishShutdown(); and change bitcoin.cpp:293 to FinishShutdown
590 2012-06-10 19:16:15 <BlueMatt> and remove uiInterface.Shutdown calls everywhere else
591 2012-06-10 19:16:37 <Diapolo> BlueMatt: you are right, after it return it reaches Shutdown()
592 2012-06-10 19:18:54 <Diapolo> BlueMatt: FinishShutdown() would be the current Shutdown() right?
593 2012-06-10 19:19:06 <BlueMatt> yrs
594 2012-06-10 19:19:08 <BlueMatt> yea
595 2012-06-10 19:20:32 <Diapolo> BlueMatt: and uiInterface.QueueShutdown() should become just Shutdown() ... sounds good.
596 2012-06-10 19:21:02 <BlueMatt> again, gavin may hate that, but I find uiInterface.QueueShutdown to be barely cleaner than an ifdef
597 2012-06-10 19:21:32 <Diapolo> Gavin dislikes many things I do so perhaps you should open that pull ^^.
598 2012-06-10 19:21:52 <BlueMatt> I dont think he'll dislike it more of less from me
599 2012-06-10 19:22:25 <Diapolo> But Bitcoin-Qt crashing is the worst possibility!
600 2012-06-10 19:35:49 <Diapolo> BlueMatt: Okay I did the changes, will open a new pull tomorrow it's a little late. Will comment in the ipc thread, too :). Thanks for your input, good work!
601 2012-06-10 19:53:45 <[7]> left to be implemented: send, sendmany, signmessage, verifymessage, settxfee, addmultisigaddress, sendrawtx, backupwallet, keypoolrefill
602 2012-06-10 19:54:04 <[7]> I think chances are reasonably good to get that done tomorrow
603 2012-06-10 19:54:38 <[7]> which means we'll finally have a bitcoind web interface that can deal with wallet encryption soon!
604 2012-06-10 19:55:37 <[7]> 700 lines of JS, 400 lines of HTML and 300 lines of python so far
605 2012-06-10 19:55:59 <[7]> so I'd guess the whole thing will be like 2000 lines when it's finished
606 2012-06-10 19:56:06 <sipa> nice
607 2012-06-10 19:56:32 <[7]> the python stuff being the web server + rpc proxy
608 2012-06-10 20:05:56 <[7]> does bitcoin actually encrypt the private keys with the passphrase?
609 2012-06-10 20:06:14 <sipa> no, they are encrypted with a master key
610 2012-06-10 20:06:34 <[7]> ah, that explains why changing the passphrase is so much faster than initially encrypting a wallet
611 2012-06-10 20:06:39 <sipa> and the master key is encrypted with a key that is derived from the passphrase
612 2012-06-10 20:06:43 <[7]> the latter of which quite literally takes ages
613 2012-06-10 20:06:54 <sipa> mostly bdb sillyness
614 2012-06-10 20:06:57 <[7]> yeah
615 2012-06-10 20:07:14 <[7]> I observed >100MB of write traffic scattered all over the place while encrypting a 500KB wallet
616 2012-06-10 20:07:21 <tcatm> ThomasV: Probably not.
617 2012-06-10 20:08:01 <BlueMatt> sipa: I thought we used checkpoints now? shouldnt that keep the writes way below 100M?
618 2012-06-10 20:08:05 <BlueMatt> or is bdb just /that/ bad?
619 2012-06-10 20:08:13 <[7]> this was with 0.6.2 btw
620 2012-06-10 20:08:38 <sipa> BlueMatt: my logdb branch creates a new wallet *instantly*
621 2012-06-10 20:08:52 <BlueMatt> which one is that again?
622 2012-06-10 20:09:00 <sipa> while it can take *seconds* now with bdb wallets
623 2012-06-10 20:09:22 <sipa> logdb = append-only key-value store for wallets
624 2012-06-10 20:09:29 <BlueMatt> hmm...yea we do checkpoint it...wow bdb sucks
625 2012-06-10 20:09:38 <BlueMatt> sipa: ah, yea...I cant wait for that
626 2012-06-10 20:10:15 <sipa> bdb is just overengineered for what we need
627 2012-06-10 20:10:20 <[7]> wow, ctrl+c on the console just segfaulted bitcoin-qt 0.6.2
628 2012-06-10 20:10:30 <BlueMatt> [7]: yep, its always done that
629 2012-06-10 20:11:14 <BlueMatt> sipa: yea...though 100MB writes for 500K in data seems excessive no matter what kind of engineering you have...
630 2012-06-10 20:11:23 <sipa> we.really don't need multi-process multi-database nested synchronized atomic and guaranteed recoverable transactions
631 2012-06-10 20:11:39 <BlueMatt> yea...
632 2012-06-10 20:12:16 <BlueMatt> and we certainly dont need to have wallet in the same dbenv as txdb
633 2012-06-10 20:12:26 <sipa> indeed
634 2012-06-10 20:13:10 <[7]> hahaha
635 2012-06-10 20:13:17 <[7]> with eatmydata wallet encryption happens almost instantly
636 2012-06-10 20:13:29 <sipa> eatmydata?
637 2012-06-10 20:13:53 <BlueMatt> "This package contains a small LD_PRELOAD library (libeatmydata) and a couple of helper utilities designed to transparently disable fsync and friends (like open(O_SYNC)"
638 2012-06-10 20:14:16 <BlueMatt> heh, I wonder how fast chain download goes with that
639 2012-06-10 20:14:27 <[7]> heh, should I try? :)
640 2012-06-10 20:14:34 <phantomcircuit> that seems vaguely like a bad idea...
641 2012-06-10 20:14:46 <phantomcircuit> BlueMatt, it's not a whole lot faster
642 2012-06-10 20:14:50 <phantomcircuit> same thing with tmpfs
643 2012-06-10 20:15:06 <[7]> phantomcircuit: it's a perfectly fine idea for removing annoyances while playing with UI stuff on testnet :P
644 2012-06-10 20:15:09 <phantomcircuit> you get from 0-125k faster
645 2012-06-10 20:15:13 <BlueMatt> phantomcircuit: vaguely? seems like a whole lote worse idea than vaguely...
646 2012-06-10 20:15:14 <phantomcircuit> but after that it's cpu bound
647 2012-06-10 20:15:14 <sipa> interesting
648 2012-06-10 20:15:43 <BlueMatt> phantomcircuit: ah...makes sense, too much sig verification...someone should thread that
649 2012-06-10 20:16:05 <[7]> BlueMatt: sig verification... wait... shouldn't that work well on GPUs? :)
650 2012-06-10 20:16:10 <phantomcircuit> BlueMatt, really the right way to do it is a pipeline with threads
651 2012-06-10 20:16:14 <BlueMatt> [7]: that would work too
652 2012-06-10 20:16:22 <BlueMatt> phantomcircuit: thats what I was thinking...
653 2012-06-10 20:16:25 <phantomcircuit> the problem is the network protocol doesn't have anyway to hint what the next 500 blocks are
654 2012-06-10 20:16:35 <BlueMatt> yes it does
655 2012-06-10 20:16:40 <phantomcircuit> so you'd end up calling the uh i forget getblocks? getdata?
656 2012-06-10 20:16:44 <phantomcircuit> something like that a lot
657 2012-06-10 20:16:45 <BlueMatt> getblocks
658 2012-06-10 20:17:00 <BlueMatt> we already call it a lot...
659 2012-06-10 20:17:19 <sipa> we do a getdata for every block anyway
660 2012-06-10 20:17:22 <BlueMatt> see: https://github.com/bitcoin/bitcoin/pull/1233 which does block buffering...
661 2012-06-10 20:17:36 <BlueMatt> (and handles requesting block lists earlier)
662 2012-06-10 20:17:41 <phantomcircuit> BlueMatt, right so the basic issue is you'd end up calling getblocks a whole lot more
663 2012-06-10 20:17:51 <BlueMatt> no you wouldnt...
664 2012-06-10 20:17:55 <phantomcircuit> right now it's requested every 500 blocks in initial download mode
665 2012-06-10 20:18:10 <phantomcircuit> the only way to keep the pipeline full would be to request it more often
666 2012-06-10 20:18:13 <BlueMatt> I thought we were talking about threading signature verification...
667 2012-06-10 20:18:20 <phantomcircuit> other wise every 500 blocks you have rtt latency from the network
668 2012-06-10 20:18:43 <[7]> one rtt every 500 blocks is probably fine if it runs async from the cpu bound stuff
669 2012-06-10 20:18:43 <BlueMatt> see that pull request, it does it-ish
670 2012-06-10 20:18:48 <phantomcircuit> we are :)
671 2012-06-10 20:18:51 <BlueMatt> and keeps the pipeline perfectly full...
672 2012-06-10 20:19:56 <[7]> what does settxfee do btw? IIUC it sets just the *minimum* fee, right?
673 2012-06-10 20:20:04 <phantomcircuit> correct
674 2012-06-10 20:20:09 <phantomcircuit> right so
675 2012-06-10 20:20:13 <phantomcircuit> thread calling getblocks
676 2012-06-10 20:20:21 <[7]> i.e. it's kinda pointless to call it at all
677 2012-06-10 20:20:22 <phantomcircuit> threads verifying transactions in returned blocks
678 2012-06-10 20:20:38 <phantomcircuit> thread connecting blocks with verified transactions to blockchain
679 2012-06-10 20:20:46 <phantomcircuit> inb4crash
680 2012-06-10 20:20:49 <BlueMatt> yea, I didnt do the second split (yet)
681 2012-06-10 20:21:05 <BlueMatt> well, I had in a previous version, but I havent ported it again, yet
682 2012-06-10 20:22:58 <BlueMatt> because the initial checks are so short, you fill the pipe really easily, the network is really fast compared to actual disk commits
683 2012-06-10 20:27:13 <phantomcircuit> depends on the disk but yeah for conventional spinning rust you're going to get 100 IOPS tops if you're the only thing running
684 2012-06-10 20:28:13 <BlueMatt> yea, on fast disks/really fast cpus (or before last checkpoint, were we dont do sig verification) its pretty quick
685 2012-06-10 20:31:02 <BlueMatt> so you may not be able to keep the buffer full, but Ive only tested it very thoroughly downloading over lan
686 2012-06-10 20:31:30 <BlueMatt> benchmarks over WAN arent very useful, so Ive just tested it, not really benched it or run it too much
687 2012-06-10 20:32:32 <Diablo-D3> this is why god invented apachebench
688 2012-06-10 20:32:51 <Diablo-D3> DoSing victims into fucking craters for over 9000 years
689 2012-06-10 21:01:52 <TD> i'd think the primary bottleneck right now on chain download speed is if you accidentally get connected to a slow node
690 2012-06-10 21:01:57 <TD> this is what i see with bitcoinj anyway
691 2012-06-10 21:02:19 <TD> we randomly pick some nodes from a DNS peer, and sometimes those nodes serve up blocks at 4-5 per second or something pathetic like that. normally means they are downloading the chain themselves
692 2012-06-10 21:02:31 <TD> coding to avoid them isn't that hard. it just isn't done yet
693 2012-06-10 21:03:10 <bayleef> So, what up with these 'VerifySignature failed' things? Is this supposed to resolve itself at some point?
694 2012-06-10 21:03:19 <BlueMatt> hmm...cant say I see that often, but then I end up benchmarking mostly on lan anyway...in any case, the satoshi client really, really needs to be able to handle that better
695 2012-06-10 21:03:31 <BlueMatt> (it currently just suffers through it during ibd which...sucks)
696 2012-06-10 23:49:56 <bayleef> I keep getting this in my log btw. Anything I can do about it? It's trying to connect blocks 176947 and 176948. ERROR: ConnectInputs() : e3d2b843ef VerifySignature failed
697 2012-06-10 23:50:45 <bayleef> is this supposed to resolve itself? It's been trying to connect the same blocks for days with the exact same result
698 2012-06-10 23:51:52 <forrestv> bayleef, you probably have a corrupt database
699 2012-06-10 23:52:44 <bayleef> but this is a fresh blockchain download :(
700 2012-06-10 23:54:27 <BlueMatt> bayleef: have you tried opening with a higher checkblocks?
701 2012-06-10 23:56:16 <bayleef> Trying that now