1 2012-08-01 01:15:13 <midnightmagic> gmaxwell: has the 0.6.3 had full disclosure yet?
  2 2012-08-01 01:16:19 <gmaxwell> midnightmagic: no, still under treshold and probably will remain so until the next major release.
  3 2012-08-01 01:17:16 <midnightmagic> gmaxwell: Thought so. Apologies in advance for the upcoming post. :-/
  4 2012-08-01 01:18:14 <doublec> midnightmagic: upcoming post where?
  5 2012-08-01 01:18:25 <midnightmagic> doublec: Just a bit of a rant. No big deal.
  6 2012-08-01 01:21:10 <gmaxwell> midnightmagic: We preannounced that the details would come out at a certian percentage of upgraded nodes.
  7 2012-08-01 01:21:31 <gmaxwell> midnightmagic: go encourage people to upgrade instead of whining.
  8 2012-08-01 01:24:43 <midnightmagic> gmaxwell: Characterizing it as "whining" when you already know the details is irritating on a level I refuse to fully convey. Not all of us have the position of information privilege that you have, nor have the extensive time of a full-time security researcher to go looking for exploits based on deliberately misleading hints. How can I even evaluate whether *-dev has fixed the issue properly? How can I measure if there's someone
  9 2012-08-01 01:24:49 <midnightmagic> trying to take advantage? Did the qt issue ever get full disclosure?
 10 2012-08-01 01:25:17 <gmaxwell> Yes, eons ago. And you were aware of it.
 11 2012-08-01 01:26:35 <gmaxwell> midnightmagic: If you didn't agree with the upgrade threshold stuff why didn't you complain previous. You are a part of this community too, and months delayed rates directed to the public at large are not an appropriate or effective communication channel.
 12 2012-08-01 01:26:44 <midnightmagic> That's true, but it's table scraps man. :-/
 13 2012-08-01 01:27:17 <gmaxwell> midnightmagic: Whats table scraps? AFAIK, You know _everything_ I know.
 14 2012-08-01 01:27:17 <midnightmagic> gmaxwell: I did. I have. Often and at-length. The usual response I get is "stop whining."
 15 2012-08-01 01:27:45 <gmaxwell> (on the QT one)
 16 2012-08-01 01:28:00 <midnightmagic> gmaxwell: I don't know the 0.6.3 details yet.
 17 2012-08-01 01:28:12 <gmaxwell> Then go get people to upgrade!
 18 2012-08-01 01:29:21 <midnightmagic> gmaxwell: As though I'll somehow be more successful than the devs, the forum, the download sites, and the IRC channels.. Here's a twelve-tonne rock. Lift it, and I will tell you the answer to the questions you ask.
 19 2012-08-01 01:29:29 <gmaxwell> Please realize that this comes across as though you're unwilling to help get the network non-vulnerable to a problem which will probably be immediately exploited when disclosed, but unhappy that it's not being disclosed yet.
 20 2012-08-01 01:30:01 <gmaxwell> midnightmagic: it seems to matter more urgently to you than it does to me.
 21 2012-08-01 01:31:39 <gmaxwell> midnightmagic: "How can I even evaluate whether *-dev has fixed the issue properly?" You can go find the vulnerability. Perhaps you'll find a different one in the process and everyone wins.
 22 2012-08-01 01:32:12 <midnightmagic> gmaxwell: We both know I haven't the time, given my level of expertise, to do that based on the deliberately obfuscated hints and check-ins.
 23 2012-08-01 01:32:26 <gmaxwell> midnightmagic: I can't find anyplace where you complained about the upgrade threshold. (or were told to stop whining wrt this)
 24 2012-08-01 01:33:41 <luke-jr> midnightmagic: you know the forums are just trolls, right? :p
 25 2012-08-01 01:33:45 <gmaxwell> midnightmagic: we're almost there, one more push should move it past thats why I said the next release would do it.
 26 2012-08-01 01:35:01 <luke-jr> we're actually at 75% now
 27 2012-08-01 01:35:09 <luke-jr> sooner than I expected
 28 2012-08-01 01:35:16 <midnightmagic> luke-jr: I just fundamentally disagree with untimely full-disclosure policies. Call me a 1996 bugtraq "consensus" nostalgite..
 29 2012-08-01 01:35:38 <luke-jr> midnightmagic: so you prefer to disclose when it would mean the end of Bitcoin?
 30 2012-08-01 01:37:09 <luke-jr> midnightmagic: would you be any happier, if it was disclosed to identified security experts (with public credentials/experience)?
 31 2012-08-01 01:37:48 <gmaxwell> midnightmagic: I think you're also confused about levels of disclosures. Bad responsivness means things like vendors taking months to disclose the existance of a bug and/or provide a fix.
 32 2012-08-01 01:37:56 <gmaxwell> We've disclosed its existance, provided fixes.
 33 2012-08-01 01:38:29 <gmaxwell> We've just not given you the scriptkiddy kit to go reproduce it yourself. For the vast majority of security announcements no such thing ever exists.
 34 2012-08-01 01:39:45 <lordcirth> Does bitcoin-qt have a QR code generator?
 35 2012-08-01 01:39:58 <luke-jr> lordcirth: since 0.6, yes
 36 2012-08-01 01:40:00 <midnightmagic> luke-jr: I'm pretty sure it wouldn't mean the end of bitcoin. More confirmations would indeed be better, unless independent security experts aren't actually verifying the fix.
 37 2012-08-01 01:40:24 <luke-jr> midnightmagic: maybe it does. we don't know the extent of the exploit.
 38 2012-08-01 01:40:41 <luke-jr> even Gavin and forrestv probably don't
 39 2012-08-01 01:41:36 <luke-jr> midnightmagic: and as gmaxwell pointed out, you know it exists: you could always use only offline wallets until the detail disclosure
 40 2012-08-01 01:41:41 <midnightmagic> gmaxwell: I'm not interested in script kiddy exploits. However, they do speed the process of verification. All I'm after is un-obfuscated details. Cripes, openssl vulnerabilities have more details in them than the 0.6.3 bug, and that's software that banks rely on.
 41 2012-08-01 01:42:19 <luke-jr> (surely it's happened?)
 42 2012-08-01 01:43:06 <midnightmagic> http://www.openssl.org/news/vulnerabilities.html
 43 2012-08-01 01:43:28 <midnightmagic> http://www.openssh.org/security.html
 44 2012-08-01 01:45:32 <gmaxwell> I can't fathom how you find that to be more detailed than what we've disclosed.
 45 2012-08-01 01:45:50 <luke-jr> midnightmagic: I'm having a hard time finding a vuln there that is actually harmful in a major way
 46 2012-08-01 01:46:29 <luke-jr> gmaxwell: that's true too - they don't seem to have *any* details for even the oldest of these
 47 2012-08-01 01:47:03 <da2ce718> *love shack, baby, love shack*
 48 2012-08-01 01:47:32 <gmaxwell> certantly by word count we disclosed more.
 49 2012-08-01 01:49:50 <midnightmagic> gmaxwell: Combine it with fix check-ins, and the exploit often becomes obvious. They identify the specific vulnerability; competent programmers can reconstruct the bug. If competent programmers are beneath the "must be this tall" threshold then how is that helpful? we're at devs, and blackhats' mercy.
 50 2012-08-01 01:50:30 <midnightmagic> gmaxwell: For a reasonable definition of "competent." I'm not talking Matt Dillon or Theo deRaadt. They're above competent.
 51 2012-08-01 01:51:36 <luke-jr> midnightmagic: these advisories don't tell you the fix checkin either
 52 2012-08-01 01:52:24 <midnightmagic> luke-jr: yeah they do.
 53 2012-08-01 01:52:49 <luke-jr> gmaxwell: PM
 54 2012-08-01 01:53:08 <luke-jr> midnightmagic: where?
 55 2012-08-01 01:54:20 <midnightmagic> luke-jr: The CVE has a "fixed in" version and most often it's very clear where the fix was committed.
 56 2012-08-01 01:54:46 <luke-jr> midnightmagic: note that the last non-trivial Bitcoin exploit before these (CVE-2010-5139) required a blockchain rewrite/fork to deal with; that was before Bitcoin had any value - we couldn't reasonably do that today
 57 2012-08-01 01:54:57 <luke-jr> midnightmagic: our CVEs have fixed in versions too
 58 2012-08-01 01:55:20 <luke-jr> https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures#CVE-2012-2459
 59 2012-08-01 01:55:23 <midnightmagic> luke-jr: The fixes are obfuscated.
 60 2012-08-01 01:55:48 <gmaxwell> midnightmagic: In any case, I can't even argue with you effectively now. You're incorrect on some things you're saying but we can't fairly discuss it without getting closer to the details than I'm willing to go, just for risk that I say something that ought to better be in a coordinated statement.
 61 2012-08-01 01:56:22 <luke-jr> ^
 62 2012-08-01 01:56:44 <midnightmagic> gmaxwell: I grok that, that's why I'm not asking for them.
 63 2012-08-01 01:56:46 <gmaxwell> (I'm not blaming you for that, it simply is)
 64 2012-08-01 01:56:49 <luke-jr> midnightmagic: are they? which of the fixes for past (already disclosed) CVEs are obfuscated?
 65 2012-08-01 01:58:19 <luke-jr> hmm, maybe I'm wrong
 66 2012-08-01 01:58:59 <luke-jr> the only one that seems like a similar case is CVE-2012-1910; I guess
 67 2012-08-01 01:59:41 <midnightmagic> luke-jr: And by obfuscated, I simply mean deliberately not fully explained with the intent to ensure that it is not easily reversible from the given information until such time as someone deems it safe to do so.
 68 2012-08-01 01:59:58 <Diablo-D3> midnightmagic: theres nothing wrong with that
 69 2012-08-01 02:00:11 <Diablo-D3> if its really easy to trigger, it should be very hard to know about without reading the source
 70 2012-08-01 02:00:29 <gmaxwell> midnightmagic: Seriously, that description also applies just as well to almost every overflow exploit out there... and as well to all the recent openssl ones you pointed to.
 71 2012-08-01 02:00:42 <midnightmagic> Diablo-D3: And when the fix is changing the build-against lib to a multi-threaded one? That could be anywhere in the source.
 72 2012-08-01 02:01:00 <Diablo-D3> midnightmagic: I dont see that being CVE related
 73 2012-08-01 02:01:16 <Diablo-D3> how is that a security problem?
 74 2012-08-01 02:01:20 <gmaxwell> I think our current level of disclosure is roughly compariable. We want to and should disclose more because we're working with some new kinds of vulnerabilities and there is a lot to be learned.
 75 2012-08-01 02:01:39 <Diablo-D3> gmaxwell: well
 76 2012-08-01 02:01:45 <Diablo-D3> have a disclosure timer.
 77 2012-08-01 02:01:53 <gmaxwell> Diablo-D3: we do!
 78 2012-08-01 02:01:59 <luke-jr> Diablo-D3: it's scheduled to be disclosed at 77% of the network being secure against it
 79 2012-08-01 02:02:02 <gmaxwell> it's based on the number of fixed nodes!
 80 2012-08-01 02:02:11 <Diablo-D3> okay
 81 2012-08-01 02:02:12 <luke-jr> we're at 75% now
 82 2012-08-01 02:02:16 <Diablo-D3> thats about what I was going to suggest
 83 2012-08-01 02:02:19 <Diablo-D3> but I would have done it at 90
 84 2012-08-01 02:02:39 <luke-jr> Diablo-D3: not even BIP 16 has 90% deployment
 85 2012-08-01 02:02:52 <luke-jr> heck, not even CVE-2012-1909 does
 86 2012-08-01 02:03:04 <gmaxwell> My impression is that things serious enough to justfiy 90% probably shouldn't be done then unless exploited. :(
 87 2012-08-01 02:03:49 <luke-jr> gmaxwell: or when we hardfork
 88 2012-08-01 02:03:52 <gmaxwell> We also have an oddness that we rightfully consider issues vulnerabilties that basically nothing else would due to the whole distributed algorithim dealing with digital-cash-that-wants-to-be-stolen.
 89 2012-08-01 02:04:05 <luke-jr> O.o
 90 2012-08-01 02:04:08 <luke-jr> Bitcoin has a will?
 91 2012-08-01 02:04:23 <gmaxwell> It sure seems like it wants to be stolen to me! :)
 92 2012-08-01 02:04:34 <gmaxwell> It certantly doesn't want to stay still.
 93 2012-08-01 02:04:54 <luke-jr> dunno, my paper wallet seems pretty still
 94 2012-08-01 02:05:40 <gmaxwell> yea, it's still once you make it not digital!
 95 2012-08-01 02:05:55 <gmaxwell> They don't call it dead tree for nothing.
 96 2012-08-01 02:06:36 <luke-jr> I thought it was called dead tree because it was made from a & dead tree ._.
 97 2012-08-01 02:08:11 <midnightmagic> gmaxwell: "integer underflow". "corrected in 1.0.1c". In source, that's tag OpenSSL_1_0_1c:1.1481.2.56.2.103. cvs -d /v2/mirrors/cvs/openssl co openssl ; cd openssl ; cvs  diff -rOpenSSL_1_0_1b -rOpenSSL_1_0_1c|less  likely candidates d1_enc.c and t1_enc.c diffs. There, fix obvious.
 98 2012-08-01 02:12:32 <midnightmagic> gmaxwell: Specified in fix revision; and in documents like NetBSD pkg-vulnerabilities, with the nature of the bug being described explicitly. Occasionally the vendors believe that describing the bug explicitly is fail. Those fixes I can't verify because it requires duplicating the security researcher's efforts.
 99 2012-08-01 02:15:22 <midnightmagic> I just got tired of grovelling through stack dumps and slowly divining proper alignment of noop slides in 1998.. :/
100 2012-08-01 02:17:59 <gmaxwell> You only consider that a disclosure because you're intimately familar what that class of vulnerability and how it's exploited.
101 2012-08-01 02:25:28 <midnightmagic> You are suffering from confirmation bias at the moment.
102 2012-08-01 02:30:05 <midnightmagic> And I hardly think a threaded-safe-lib rebuild is a fix for a new class of exploit.
103 2012-08-01 02:34:17 <gmaxwell> ::shrugs:: we've fixed the thing, described what we were fixing. Disclosed there was a fix, decribed the nastyness that could happen and where (something openssl doesn't do) and a nearby release tag. Which all sounds pretty compariable to me.
104 2012-08-01 02:38:27 <midnightmagic> How does CVE-2012-2333 not describe the nastiness that could happen?
105 2012-08-01 02:39:11 <midnightmagic> or -0027?
106 2012-08-01 02:41:07 <gmaxwell> and others don't.
107 2012-08-01 02:41:09 <gmaxwell> "A flaw in the fix to CVE-2011-4108 can be exploited in a denial of service attack. Only DTLS applications are affected."
108 2012-08-01 02:41:21 <midnightmagic> Who cares whether I tell someone with an exploit to publish it on his own schedule? We're *damned* lucky this guy isn't a Luigi Auriemma.
109 2012-08-01 02:42:38 <midnightmagic> CVE-2011-3210: "OpenSSL server code for ephemeral ECDH ciphersuites is not thread-safe, and furthermore can crash if a client violates the protocol by sending handshake messages in incorrect order."
110 2012-08-01 02:43:14 <gmaxwell> I .. don't? Well perhaps I do. I thought my message was good: Do whats right to protect people from harm, whatever that is...  Regardless, my don't fault the people here for not following some timeline that exists in your head.
111 2012-08-01 02:43:55 <midnightmagic> No, because it's the same timeline that exists in YOUR head.
112 2012-08-01 02:44:39 <gmaxwell> er regardless, my complaint with your possition is that you're complaining about what we've established here, in cooperation with the people reporting issues. No one is dragging their feet, the plan is all public, and you've not commented on it until a long delay to complain that we're delaying when we're not. :(
113 2012-08-01 02:45:04 <midnightmagic> I comment every time; and we've had this discussion three times now.
114 2012-08-01 02:45:11 <gmaxwell> Every time what?
115 2012-08-01 02:45:42 <midnightmagic> Every time a new obfuscated patch release comes out that we're all supposed to upgrade to but nobody really knows why.
116 2012-08-01 02:49:55 <luke-jr> midnightmagic: not a single one of these OpenSSL vulns is anywhere near as serious as Bitcoin bugs could be
117 2012-08-01 02:51:25 <midnightmagic> luke-jr: That's..  a bit aggrandized.
118 2012-08-01 02:52:54 <luke-jr> midnightmagic: show me one OpenSSL exploit listed that has potential to have permanent financial loss
119 2012-08-01 02:53:09 <luke-jr> afaict, the worst here are DoS
120 2012-08-01 02:53:37 <gmaxwell> any code execution one does.
121 2012-08-01 02:53:47 <luke-jr> gmaxwell: I didn't see any code execution one
122 2012-08-01 02:54:55 <luke-jr> in fact, it looks like they wait until there's 5-10 of these before they even release the fixes
123 2012-08-01 02:55:20 <midnightmagic> luke-jr: CVE-2009-3245. CVE-2007-5135.
124 2012-08-01 02:55:49 <midnightmagic> luke-jr: http://www.openssl.org/news/secadv_20030930.txt (remote root shell)
125 2012-08-01 02:56:03 <midnightmagic> luke-jr: http://www.openssl.org/news/secadv_20020730.txt (remote root shell)
126 2012-08-01 03:00:46 <luke-jr> midnightmagic: I can't clearly see how those were handled
127 2012-08-01 03:26:57 <midnightmagic> luke-jr: You just wanted one OpenSSL exploit which has the potential to have permanent financial loss, I quoted 5 in less than 3 minutes of casual searching. If you tell me you won't be convinced they divulged exploitable bugs until I write one based on a CVE, that's a rock I'm not going to lift.
128 2012-08-01 06:16:10 <OneEyed> blognewb: what would be wrong with getting even? It's better than losing money
129 2012-08-01 06:16:16 <OneEyed> Grmpf, sorry, wrong window
130 2012-08-01 07:32:38 <yellowhat> what is the preferred way to build bitcoin-qt in windows? any recommondations on IDE?
131 2012-08-01 07:45:17 <sipa> yellowhat: there are few people building on windows
132 2012-08-01 07:45:48 <sipa> the official wiblndows builds are created on ubuntu
133 2012-08-01 12:20:42 <jgarzik> 08/01/12 14:03:17 REORGANIZE
134 2012-08-01 12:20:43 <jgarzik> 08/01/12 14:03:17 REORGANIZE: Disconnect 1 blocks; 000000000000056f1bc3..000000000000073335b2
135 2012-08-01 12:20:44 <jgarzik> whee
136 2012-08-01 12:21:14 <sipa> pynode reorganizes?
137 2012-08-01 12:21:34 <jgarzik> it is very close
138 2012-08-01 12:21:41 <jgarzik> but the above is bitcoind
139 2012-08-01 12:21:58 <jgarzik> pynode stores multiple chain forks now.  Just need to add the switching code for the reorg case.
140 2012-08-01 12:22:31 <t7> you wrote a node in python?
141 2012-08-01 12:25:58 <jgarzik> t7: yes
142 2012-08-01 12:26:37 <t7> why python?
143 2012-08-01 12:27:03 <sipa> language flamewar go go go
144 2012-08-01 12:27:15 <t7> i guess it has lots of libraries ready to go
145 2012-08-01 12:28:02 <jgarzik> t7: FYI, vi is far better than emacs
146 2012-08-01 12:29:06 <sipa> oh please
147 2012-08-01 12:29:09 <sipa> just use edlin
148 2012-08-01 12:30:22 <t7> i can appreciate there are tasks that python (or any dynamically typed language) is good for but this didnt seem like one of them.
149 2012-08-01 12:30:33 <jgarzik> maybe nano should be considered, though
150 2012-08-01 12:31:04 <sipa> xkcd 378 comes to mind
151 2012-08-01 12:33:06 <jgarzik> hehehe
152 2012-08-01 12:34:00 <jgarzik> sipa: btw, trying to answer a forum question.  RPC getbalance returns balance for...  how many confirmations?  0? 1? 6?
153 2012-08-01 12:34:05 <jgarzik> I think it's 1-conf
154 2012-08-01 12:34:11 <jgarzik> but I'm buried in wallet.cpp
155 2012-08-01 12:34:29 <sipa> 1 for external transactions, 0 for change or send-to-self ones
156 2012-08-01 12:37:00 <jgarzik> thanks
157 2012-08-01 12:58:35 <gmaxwell> '0 for change or send-to-self ones' so long as their parents are change/send-to-self or confirmed, all the way up the stack.
158 2012-08-01 13:15:48 <jgarzik> gavinandresen sipa gmaxwell: currently leaning towards the opinion that we should release git HEAD, prior to any "big features" like leveldb at this point
159 2012-08-01 13:16:04 <jgarzik> git HEAD is currently a large collection of small, useful things
160 2012-08-01 13:16:08 <jgarzik> a release would be a useful checkpoint
161 2012-08-01 13:17:33 <sipa> jgarzik: there are some todo's left in git HEAD, but i'm in favor of releasing before any big further changes now
162 2012-08-01 13:18:20 <jgarzik> sipa: what are the todo's, in your mind?
163 2012-08-01 13:18:42 <jgarzik> we should probably make a pass over gavin's raw tx api
164 2012-08-01 13:18:53 <jgarzik> gmaxwell has a good point about locking txouts, I think
165 2012-08-01 13:20:00 <sipa> hmm, i just get that impression from the huge list of pull requests, i suppose
166 2012-08-01 13:20:23 <jgarzik> ok
167 2012-08-01 13:21:10 <sipa> if anything, that list should be reduced (either by closing or merging)... most things are not big changes
168 2012-08-01 13:22:11 <gmaxwell> jgarzik: I was already assuming any futher big things like leveldb would be next version.
169 2012-08-01 13:22:55 <gmaxwell> There are still a lot of small things and bits of polish needed, things like the locking.. or finishing off some of the new peer management stuff (e.g. I'd like to get bluematt's management rpc in to go with your status rpcs)
170 2012-08-01 13:23:10 <gmaxwell> there are also a bunch of more or less dead pulls.
171 2012-08-01 13:56:25 <luke-jr> jgarzik: do you really need to do the useless closing of open issues?
172 2012-08-01 13:58:07 <jgarzik> luke-jr: if you convince one of the other devs to reopen, that's fine -- because then it reflects that the action was against consensus
173 2012-08-01 13:58:55 <luke-jr> #570 had a consensus that it was needed, but that proper handling of stuck transactions was needed first
174 2012-08-01 14:01:09 <luke-jr> jgarzik: there is a generally acknowledged problem of lack of reviewing for pullrequests in general creating a backlog of them; closing them for lack of reviews doesn't help fix it
175 2012-08-01 14:02:32 <sipa> i do think pullrequests stay open for too long, both ones that should be merged and ones that should be closed
176 2012-08-01 14:02:49 <gmaxwell> luke-jr: So, the original version of the pull request had behavior that I think you would have also agreed was bad/risky. Maybe you fixed that in your update? But you didn't say what you did so I don't even know if I read the update. :(
177 2012-08-01 14:03:08 <jgarzik> sipa: yes
178 2012-08-01 14:03:39 <jgarzik> IMNSHO pull requests are for ready-to-go stuff, and stuff that stays open too long should just be closed
179 2012-08-01 14:03:50 <jgarzik> --but--
180 2012-08-01 14:04:01 <jgarzik> we should signal that we encourage people to open or reopen pull requests
181 2012-08-01 14:04:24 <sipa> can a non-admin reopen a pull request that was closed by an admin, actually?
182 2012-08-01 14:04:27 <sipa> s/admin/dev/
183 2012-08-01 14:04:38 <jgarzik> easy-to-close, easy-to-open is a good policy
184 2012-08-01 14:04:40 <gmaxwell> Right, I think reopening for retries is okay too, so long as there is some backoff.
185 2012-08-01 14:04:51 <jgarzik> sipa: reopen == resubmit, for that reason
186 2012-08-01 14:04:54 <gmaxwell> I think for reopens some should just be new pull requests (that mention theod ones)
187 2012-08-01 14:05:14 <luke-jr> jgarzik: a lot of pull requests that just sit open IS ready-to-go
188 2012-08-01 14:05:24 <jgarzik> reopens will be new pull requests by necessity, because it takes a dev to do it manually
189 2012-08-01 14:05:26 <gmaxwell> in particular, to avoid wading through a bunch of no longer applicable discussion.
190 2012-08-01 14:05:28 <jgarzik> otherwise
191 2012-08-01 14:11:00 <gmaxwell> I do wish there were more levels of workflow in this stuff. E.g. to sort out the believe to be pull ready vs we're discussing it.
192 2012-08-01 14:11:49 <jgarzik> gmaxwell sipa: coin control go/no-go.  We either need to drop this or carry it to the finish line.  https://github.com/bitcoin/bitcoin/pull/1359
193 2012-08-01 14:12:22 <jgarzik> _presuming_ it is mergeable (it is not ATM), need an ACK/NAK.
194 2012-08-01 14:12:28 <jgarzik> and especially need gavin input I think
195 2012-08-01 14:12:42 <sipa> as i said, i really don't like a single wallet variable that defines coin selection
196 2012-08-01 14:13:03 <sipa> that's very incompatible with multi-client RPC, for example
197 2012-08-01 14:13:06 <gmaxwell> jgarzik: we're going to drop it; because the advanced user functionality is replaced by the raw txn stuff. Though we need to pull in group finding rpc out, and add private key hiding to totally replace it.
198 2012-08-01 14:13:08 <jgarzik> from a project management standpoint, this commit has become a thread :)
199 2012-08-01 14:13:44 <sipa> but the raw txn functionality is not available in the gui
200 2012-08-01 14:13:54 <sipa> it's not the same thing
201 2012-08-01 14:14:05 <jgarzik> gmaxwell: I'm having trouble understanding/parsing "we need to pull in group finding rpc out"
202 2012-08-01 14:14:18 <gmaxwell> sipa: it's available in the gui console.  The gui interface on coin control is confusing and shouldn't be kept in any case.
203 2012-08-01 14:14:32 <sipa> ok, i only tested the gui part briefly
204 2012-08-01 14:14:37 <jgarzik> yeah, GUI console for RPC was a nifty idea
205 2012-08-01 14:15:05 <gmaxwell> jgarzik: one of the things that patch does is finds the sets of inputs which have been used in common in transactions (groups).  With that you can accomplish the same goals (though a little harder) using raw transactions.
206 2012-08-01 14:15:12 <luke-jr> gmaxwell: bitcoind features IMO can never replace Bitcoin-Qt features ;P
207 2012-08-01 14:15:25 <gmaxwell> luke-jr: they can when the GUI sucked in any case.
208 2012-08-01 14:15:49 <luke-jr> not saying to pull CC's GUI, just that rawtx doesn't really replace it
209 2012-08-01 14:15:56 <gmaxwell> Also, it's not a "bitcoind feature" as we have the gui console. Though I do generally agree that rpc commands don't replace gui, this hardly had one.
210 2012-08-01 14:16:24 <gmaxwell> I don't mean that the rawtxn stuff doesn't replace a _future_ coin control gui. But I think it replace this one.
211 2012-08-01 14:16:56 <sipa> i think ideally we'd have an expert mode view, where you can see individual coins, instead of the aggregate derived ledger view
212 2012-08-01 14:17:17 <sipa> because coincontrol inherently assumes you are aware of the underlying representation anyway
213 2012-08-01 14:17:42 <gmaxwell> sipa: In particular, I think what you're describing is a expert-transaction-constructor view.. basically a GUI on top of rawtxn.
214 2012-08-01 14:17:52 <sipa> actually, yes
215 2012-08-01 14:18:07 <sipa> but not only creator
216 2012-08-01 14:18:21 <sipa> also a viewer for the current transactions, which show the actual outputs and inputs
217 2012-08-01 14:18:48 <gmaxwell> A gui for decoderawtransaction / gettransaction verbose.
218 2012-08-01 14:19:43 <jgarzik> OK
219 2012-08-01 14:19:47 <gmaxwell> luke-jr: did we ever bust the tests out of coin control and the other non-cc changes?
220 2012-08-01 14:19:58 <luke-jr> sipa: actually worse, coin control misrepresents the underlying representation and adds to the confusion :P
221 2012-08-01 14:20:13 <luke-jr> gmaxwell: yes, those are merged
222 2012-08-01 14:20:16 <gmaxwell> great.
223 2012-08-01 14:21:11 <jgarzik> gmaxwell: it adds potentially interesting rpc 'listaddressgroupings'
224 2012-08-01 14:21:28 <gmaxwell> 09:15 < gmaxwell> jgarzik: one of the things that patch does is finds the sets of inputs which have been used in common in  transactions (groups).  With that you can accomplish the same goals (though a little harder) using raw  transactions.
225 2012-08-01 14:21:35 <gmaxwell> Thats what I'm talking about.
226 2012-08-01 14:21:38 <gmaxwell> I think we should pull that part.
227 2012-08-01 14:21:38 <luke-jr> jgarzik: your ultimatum on gmp_bip is not practical.
228 2012-08-01 14:22:05 <luke-jr> jgarzik: DM_HEX is required to be backward compatible, and DM_OBJ is required to deal with a bug
229 2012-08-01 14:22:31 <jgarzik> GMP backward compatibility is a low priority
230 2012-08-01 14:22:35 <luke-jr> ok
231 2012-08-01 14:22:41 <jgarzik> pick one, write it into the BIP
232 2012-08-01 14:22:57 <jgarzik> we only want one way of doing things
233 2012-08-01 14:22:58 <luke-jr> should I just remove all backward compat from it then?
234 2012-08-01 14:23:23 <jgarzik> luke-jr: I've no objection, but I cannot speak for other devs
235 2012-08-01 14:23:40 <gmaxwell> hm. thats a point. backwards compat isn't actually a terribly big deal as the caller can adapt.
236 2012-08-01 14:23:40 <jgarzik> I think we're too young to accumulate a bunch of backward compat cruft at this point
237 2012-08-01 14:23:49 <jgarzik> _especially_ in RPC land
238 2012-08-01 14:25:25 <sipa> at this point, i don't mind GMP doing a backward-incompatible change
239 2012-08-01 14:26:01 <gmaxwell> hmph. It's quite a pain to use listunspent to get unspent txn connected to particular addresses.
240 2012-08-01 14:26:28 <sipa> actually, if we're breaking it anyway, can we rename it to getblocktemplate?
241 2012-08-01 14:26:38 <jgarzik> sipa: ACK
242 2012-08-01 14:26:45 <jgarzik> ^2
243 2012-08-01 14:27:09 <sipa> that is also easier for callers that have to support both
244 2012-08-01 14:27:17 <jgarzik> yes
245 2012-08-01 14:27:18 <gmaxwell> very very slightly.
246 2012-08-01 14:27:31 <gmaxwell> But sure, if it's broken, renaming it is fine.
247 2012-08-01 14:27:38 <gmaxwell> luke-jr: do you hate that name?
248 2012-08-01 14:27:51 <luke-jr> I'd prefer something shorter, but I don't really care that much.
249 2012-08-01 14:28:17 <gmaxwell> gBlkTmpl_impl
250 2012-08-01 14:28:22 <gmaxwell> ;)
251 2012-08-01 14:28:40 <luke-jr> plzno
252 2012-08-01 14:29:10 <sipa> fortran style naming conventions!
253 2012-08-01 14:29:15 <gmaxwell> I wonder if there is a reason that gavin didn't make listunspent take any other filter arguments than confirmations.
254 2012-08-01 14:29:16 <luke-jr> getblocktemplate it is then? :P
255 2012-08-01 14:29:30 <gmaxwell> The obvious missing filters are address sets and value.
256 2012-08-01 14:29:46 <luke-jr> forrestv: that OK with you?
257 2012-08-01 14:30:26 <sipa> i don't mind a shorter name if there is a suggestion
258 2012-08-01 14:31:01 <luke-jr> getblocktmpl? :P
259 2012-08-01 14:32:04 <luke-jr> jgarzik: any objection if I remove DM_HASH (at least for now) too?
260 2012-08-01 14:34:28 <jgarzik> luke-jr: make it as simple as possible... go for it
261 2012-08-01 14:34:52 <sipa> the obj decomposition offers everything, right?
262 2012-08-01 14:35:54 <jgarzik> it should, though IIRC gmaxwell was grumping about some issue related to separate RPC decomp steps?
263 2012-08-01 14:36:15 <sipa> ah, right
264 2012-08-01 14:43:24 <luke-jr> sipa: yes
265 2012-08-01 14:43:35 <luke-jr> getblocktemplate or getblocktmpl or ?
266 2012-08-01 14:43:49 <luke-jr> and I'm *replacing* getmemorypool, right?
267 2012-08-01 14:49:04 <jgarzik> luke-jr: getblocktemplate
268 2012-08-01 14:49:19 <jgarzik> luke-jr: yes, delete getmemorypool, add getblocktemplate IMO
269 2012-08-01 14:52:50 <gribble> New news from bitcoinrss: gmaxwell opened pull request 1642 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1642>
270 2012-08-01 14:54:27 <luke-jr> gmaxwell: ty
271 2012-08-01 14:55:00 <helo> it would be pretty handy if the client could show how many peers a transaction has been sent to...
272 2012-08-01 14:55:16 <luke-jr> helo: it does O.o
273 2012-08-01 14:55:39 <gmaxwell> luke-jr: See my comments there: https://github.com/bitcoin/bitcoin/pull/1642
274 2012-08-01 14:55:53 <helo> oh, well carry on ;)
275 2012-08-01 14:58:52 <gmaxwell> luke-jr: perhaps it's enough to let listunspent take a list of addresses to filter by?
276 2012-08-01 14:59:30 <spitteler> wondering if there is an easier way to get the sender address of a known transactionid (rather then parsing from http://blockchain.info/tx-index/14187265/28a1976b68b6ab4b5bbe723ab7289d4352da9afdedee022b6b47348a57f3f181)
277 2012-08-01 15:00:04 <luke-jr> gmaxwell: maybe. I don't personally care about Coin Control stuff <.<
278 2012-08-01 15:01:00 <luke-jr> spitteler: Bitcoin doesn't have sender addresses
279 2012-08-01 15:02:23 <gmaxwell> spitteler: To elaborate on Luke's comment. There is no from address in bitcoin, you can get the prior transaction and look at its to address and _hope_ its the same party, and hope you can even parse the to address.. but you can't be at all sure its the same party.
280 2012-08-01 15:04:15 <luke-jr> jgarzik: sipa: back to BIP22 method name again - maybe "blocktemplate" is more appropriate since we're overloading the submission on it?
281 2012-08-01 15:04:42 <gmaxwell> it's shorter!
282 2012-08-01 15:05:49 <spitteler> how then does something as simple as satoshi dice send back winning without entering an address to send it to,  they get the sender address somehow
283 2012-08-01 15:06:17 <luke-jr> spitteler: SatoshiDice doesn't care if it works or not - it's just a DoS attack on Bitcoin after all
284 2012-08-01 15:07:03 <spitteler> ok, cause i am trying to add a refund function that will refund a customer if they over/under send coins to the address i give them for a transaction
285 2012-08-01 15:07:40 <spitteler> i guess there is no way to do that without the customer also specifying a return address?
286 2012-08-01 15:07:45 <luke-jr> spitteler: correct
287 2012-08-01 15:09:27 <jgarzik> sipa gmaxwell: was there ever any decision on RPC locking?  pushdown or table-driven?
288 2012-08-01 15:09:44 <jgarzik> I vaguely lean towards table-driven
289 2012-08-01 15:10:28 <sipa> eventually it will have to be pushdown anyway
290 2012-08-01 15:10:42 <luke-jr> table-driven seems safer
291 2012-08-01 15:19:21 <jgarzik> OK, pull request pass done.  Babysitting time.
292 2012-08-01 15:19:57 <luke-jr> jgarzik: sipa: back to BIP22 method name again - maybe "blocktemplate" is more appropriate since we're overloading the submission on it?
293 2012-08-01 15:20:18 <luke-jr> ugh, fastblockrelay needs rebasing already? XD
294 2012-08-01 15:22:40 <jgarzik> luke-jr: fine
295 2012-08-01 15:24:09 <jgarzik> luke-jr: but if gavin demands a rename to 'getblocktemplate' don't blame me <grin>
296 2012-08-01 15:24:29 <luke-jr> meh, how about I leave the current draft for review now, and decide a final name when Gavin connects? :P
297 2012-08-01 15:27:55 <luke-jr> (current draft = revised with code changes)
298 2012-08-01 15:34:43 <gmaxwell> I think its fantastic news that the biggest problem is now the name.
299 2012-08-01 15:41:19 <luke-jr> gmaxwell: :D
300 2012-08-01 15:45:52 <sipa> luke-jr: no problem with blocktemplate
301 2012-08-01 15:46:08 <luke-jr> sipa: what do you think of "blockmining"? <.<
302 2012-08-01 15:50:52 <gmaxwell> I like blocktemplate better.
303 2012-08-01 15:51:07 <gmaxwell> then again, blockmining may do better to promote the miner oriented uses of this.
304 2012-08-01 15:51:21 <gmaxwell> Foo Pool, now with extra secure BlockMining" protocol.
305 2012-08-01 15:53:57 <luke-jr> we seem to be doing some heavy drive-by chatting :P
306 2012-08-01 15:54:56 <jgarzik> sipa gmaxwell: just pushed doc/release-notes.txt, listed user visible stuff in upcoming release.  a glance would be appreciated.
307 2012-08-01 15:55:02 <jgarzik> mainly to spot missing stuff
308 2012-08-01 16:00:57 <luke-jr> I hate to close opti_getblkhash, but I'm no longer overly interested (I'm done using it) and jgarzik's index-by-height seems the best approach but complicated to get right
309 2012-08-01 16:01:59 <luke-jr> jgarzik: you said pynode was more or less a port of the C++ code; is it possible its index could be ported back?
310 2012-08-01 16:02:08 <gmaxwell> index by height seems like more work than its worth.
311 2012-08-01 16:02:25 <gmaxwell> the linear scan is really the important to make fast case.
312 2012-08-01 16:02:33 <gmaxwell> And your patch does that except for the being broken part.
313 2012-08-01 16:03:48 <luke-jr> so just move the func to main and have block changes void the cache?
314 2012-08-01 16:04:21 <gmaxwell> Sounds fine to me.
315 2012-08-01 16:05:42 <jgarzik> luke-jr: yeah, to be clear, my comment was in the category of "$this would be easy if..." rather than a suggested direction.  I agree w/ gmaxwell that maintaining index-by-height may be more costly in terms of permanent RAM (or a new db), versus the cost of the loop you already did
316 2012-08-01 16:06:17 <jgarzik> pynode uses it in several places.  bitcoind would only have one user, so costs > benefits there
317 2012-08-01 16:06:40 <luke-jr> safe to assume we only need to void the cache on SetBestChain?
318 2012-08-01 16:14:50 <jgarzik> What is the preference for indicating "mempool" / extended "getdata" behavior?
319 2012-08-01 16:15:02 <jgarzik> The commit bumps the protocol version to 60002, but I actually prefer an nServices bit.
320 2012-08-01 16:15:28 <jgarzik> However...  I am a bit reluctant to add the NODE_SPV_SERVER bit right now, as bloom filter is not yet in
321 2012-08-01 16:16:55 <jgarzik> I suppose NODE_SPV_SERVER could mean different things as protocol_version continues to increase...  add it now, then NODE_SPV_SERVER && nVersion > X indicates bloom filter too
322 2012-08-01 16:17:03 <jgarzik> but that seems messy
323 2012-08-01 16:22:42 <luke-jr> jgarzik: maybe just add it without any version/flag for now, and add a service flag when it's more "complete"?
324 2012-08-01 16:23:58 <jgarzik> yeah, definitely a bit reluctant to add NODE_SPV_SERVER right now
325 2012-08-01 16:24:00 <gmaxwell> ^ I thought that too.
326 2012-08-01 16:24:13 <jgarzik> there is value in advertising it -somehow- though, I think
327 2012-08-01 16:24:26 <gmaxwell> also, I'm also not super keen on adding and announcing new message types without a client to poll them.
328 2012-08-01 16:24:26 <jgarzik> thus, 60002
329 2012-08-01 16:25:03 <gmaxwell> (or even really, pulling the patch without a way to test them)
330 2012-08-01 16:25:16 <jgarzik> gmaxwell: <shrug> it was tested with a simple pynode script.  I could commit that to pynode/contrib or somesuch.
331 2012-08-01 16:25:23 <luke-jr> jgarzik: why does it need to be advertised?
332 2012-08-01 16:25:49 <jgarzik> luke-jr: how else to know if it may be used?
333 2012-08-01 16:26:00 <luke-jr> try it and see
334 2012-08-01 16:26:02 <luke-jr> :p
335 2012-08-01 16:26:18 <jgarzik> luke-jr: P2P commands don't have 1:1 request:response ratio
336 2012-08-01 16:26:31 <luke-jr> this one does
337 2012-08-01 16:26:42 <jgarzik> nope
338 2012-08-01 16:27:01 <luke-jr> oh, if the mempool is empty..
339 2012-08-01 16:28:40 <luke-jr> meh, if we can do it for ping, we can do it for this XD
340 2012-08-01 16:29:05 <jgarzik> yet another reason why I wanted a "getfeatures" or "listcommands" command
341 2012-08-01 16:29:44 <jgarzik> but oh well.. we only advertise version and service bits
342 2012-08-01 16:33:01 <luke-jr> I think my client still has your listcommands in it :P
343 2012-08-01 16:34:58 <jgarzik> I think listcommands is great for minor, optional features
344 2012-08-01 16:37:19 <luke-jr> gmaxwell: just imagine how long it would take to run a human in valgrind&
345 2012-08-01 16:37:54 <midnightmagic> ground-up humans
346 2012-08-01 16:38:16 <gmaxwell> luke-jr: If we identify a couple pulls which _will_ get merged for 0.7 if they get some more testing, and which _won't_ get merged... do you think you could do a set of builds with them and drive up some actual testing (e.g. from some of the audience that runs next-test)?
347 2012-08-01 16:38:29 <gmaxwell> luke-jr: in particular I'm thinking about the transaction/accounting time.
348 2012-08-01 16:38:30 <jgarzik> 50 Khps per core, baby
349 2012-08-01 16:38:32 <gmaxwell> But there may be otherones.
350 2012-08-01 16:39:39 <jgarzik> I wonder if pyminer has ever mined any blocks other than the couple I did on testnet, to prove it worked ;)
351 2012-08-01 16:45:42 <Joric> jgarzik, back in june 2012 i tried to use google app engine miner written entirely on java - ~2 shares a day on their cpu limits for the free hosting
352 2012-08-01 16:49:43 <Joric> *2011 sorry though it was ~ the same difficulty :)
353 2012-08-01 16:49:55 <luke-jr> gmaxwell: certainly
354 2012-08-01 16:50:20 <luke-jr> gmaxwell: my 'next' branch already aims to be that, based on puller ACKs - but explicit would help get it just right
355 2012-08-01 16:51:39 <gmaxwell> luke-jr: Right, we have things right now with some levels of acks which probably aren't going to go into 0.7. Perhaps I can go over what you have in next and see if there are things I think are dead/deferred which should come out and then we could try to get some push there.
356 2012-08-01 16:54:19 <luke-jr> gmaxwell: 1 sec
357 2012-08-01 16:57:08 <Lyspooner> hello friends. was there any further discussion from the devs about casascius "automatic mixing" idea presented on the forums here: https://bitcointalk.org/index.php?topic=94155.0 ?
358 2012-08-01 16:58:36 <luke-jr> gmaxwell: 936/gmp_bip, 1431/opt_ipv6, 1514/linker args, 1526/heightincoinbase, 1549/addnoderpc, 1572/optionsmodel_cleanup
359 2012-08-01 16:58:45 <luke-jr> haven't updated since 1595 or so tho
360 2012-08-01 16:59:16 <gmaxwell> Lyspooner: that is something that can be implemented purely externally to bitcoin now, and it should be at least first.
361 2012-08-01 16:59:25 <gmaxwell> Lyspooner: the timed thing is silly though. ::shrugs::
362 2012-08-01 17:00:16 <gmaxwell> Lyspooner: related, I heard that someone is coming out with a mixing service based on multi input transactions that after 0.7 is released. I'd expect it to be more secure due to big anonymity groups. (and also not bloaty)
363 2012-08-01 17:00:43 <Lyspooner> cool, thanks. any links?
364 2012-08-01 17:01:17 <gmaxwell> Lyspooner: Alas, no. I was just asked to review some stuff.
365 2012-08-01 17:01:29 <gmaxwell> (and I did a bunch of transactions testing the transaction behavior in testnet3)
366 2012-08-01 17:02:16 <gmaxwell> we have a spiffy 'bug' (feature?) with those transactions:
367 2012-08-01 17:03:04 <D34TH> there are no bugs
368 2012-08-01 17:03:07 <gmaxwell> "amount" : -50.00000000,
369 2012-08-01 17:03:12 <D34TH> ony undocumented features
370 2012-08-01 17:03:15 <gmaxwell> ..        "amount" : -100.00000000,
371 2012-08-01 17:03:58 <gmaxwell> (fee is normally negative...but here it's postive because it reflects the foreign input!)
372 2012-08-01 17:13:57 <luke-jr> gmaxwell: include pulls that need rebasing in your list, and I'll pester them :P
373 2012-08-01 17:24:10 <Ukto> gmaxwell: I'll accept that kind of fee :P
374 2012-08-01 17:50:48 <gribble> New news from bitcoinrss: dooglus opened issue 1643 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/issues/1643>
375 2012-08-01 17:54:06 <luke-jr> gmaxwell: updated next list: 936 gmp_bip, 1431 opt_ipv6, 1526 gavin/heightincoinbase, 1549 matt/addnoderpc, 1355 gmp_longpoll, 1393 refactor_times
376 2012-08-01 18:26:08 <gribble> New news from bitcoinrss: Diapolo opened pull request 1644 on bitcoin/bitcoin <https://github.com/bitcoin/bitcoin/pull/1644>
377 2012-08-01 18:26:35 <Diapolo> hey guys, I created a pull with current translations, I hope I didn't miss the build phase ;)?
378 2012-08-01 18:27:14 <sipa> there have not even been release candidates
379 2012-08-01 18:27:52 <Diapolo> Well I had the impression it was like a rush today ^^. Just wanted to be sure.
380 2012-08-01 18:28:25 <luke-jr> Diapolo: probably getting close
381 2012-08-01 18:29:09 <luke-jr> I'll probably do a next (note: not next-test) build to help get some final testing of some predecided "wanted in 0.7" pulls
382 2012-08-01 18:29:12 <gmaxwell> Diapolo: no, no rush, but we'll probably close to new things somewhat soon.
383 2012-08-01 18:29:34 <luke-jr> as soon as gmaxwell gets me the list, and gavin decides the new name for BIP22
384 2012-08-01 18:29:45 <sipa> translations can be updated right up to the release, imho
385 2012-08-01 18:29:53 <luke-jr> ^ that too
386 2012-08-01 18:30:54 <luke-jr> in fact, probably ideal to wait until immediately before the first RC, to even start merging translations in
387 2012-08-01 18:31:37 <luke-jr> jgarzik: can you rebase unlocked-rpc plz?
388 2012-08-01 18:31:54 <Diapolo> luke-jr: the client needs fresh translations, I'll update them over the whole RC phase, but would like to have a good looking translated client for even the first RC :)
389 2012-08-01 18:32:07 <luke-jr> Diapolo: hence "right before"
390 2012-08-01 18:32:14 <luke-jr> immediately*
391 2012-08-01 18:32:56 <Diapolo> now I got it :-P well I'm off for holidays soon, so take it or let it open until RC phase begins :)
392 2012-08-01 18:34:10 <Diapolo> While we are at "wanted in 0.7" any dev here that has Windows and can give my DEP patch a try? Would be sad if that doesn't make it because no one is able to test ^^. It's a pretty simple thing.
393 2012-08-01 18:35:38 <sipa> does it work for you?
394 2012-08-01 18:35:48 <Diapolo> sure
395 2012-08-01 18:35:55 <Diapolo> as seen on the screenshot
396 2012-08-01 18:36:03 <sipa> must have missed that
397 2012-08-01 18:36:34 <sipa> have you tested that it actually prevents executing code on the stack?
398 2012-08-01 18:37:08 <wumpus> Diapolo: the name of the pull request is wrong btw :p it also changes the DEP bit for bitcoind, not just bitcoin-qt
399 2012-08-01 18:37:25 <sipa> as it should, i guess
400 2012-08-01 18:37:29 <wumpus> yes
401 2012-08-01 18:37:38 <Diapolo> wumpus: if you want me, I can update :-P
402 2012-08-01 18:38:22 <wumpus> not really important, but just to be sure tat you realized
403 2012-08-01 18:38:24 <Diapolo> sipa: no I did not provoke a DEP crash, but I'm sure that should be not too hard to trigger
404 2012-08-01 18:39:05 <Diapolo> wumpus: as I never use bitcoind ^^ well thanks
405 2012-08-01 18:39:05 <wumpus> just malloc some memory and jump to it :)
406 2012-08-01 18:39:18 <sipa> i suppose you can write a function with an infinite loop, at run time copy it to a stack-allocated char array, cast the pointer to a function ptr, and call it
407 2012-08-01 18:39:46 <MMavipc> what's the length of a compressed DER private key supposed to be?
408 2012-08-01 18:39:51 <sipa> wumpus: well, i expect that to crash either way
409 2012-08-01 18:39:59 <sipa> MMavipc: 33 bytes
410 2012-08-01 18:40:06 <wumpus> yes, but the type of crash should tell you something
411 2012-08-01 18:40:09 <sipa> wait
412 2012-08-01 18:40:27 <sipa> MMavipc: private keys are not DER encoded
413 2012-08-01 18:40:39 <sipa> MMavipc: and a compressed private key does not exist
414 2012-08-01 18:40:43 <MMavipc> sipa: yes they are, open up your wallet.dat with a hex editor
415 2012-08-01 18:40:44 <makomk> sipa: depending on calling convention, I guess you could just write a single RET instruction to a buffer and call it.
416 2012-08-01 18:41:12 <sipa> MMavipc: ah, yes, the old encoding for private keys
417 2012-08-01 18:41:34 <sipa> MMavipc: iirc, the normal length (279 bytes?) minus 32
418 2012-08-01 18:41:46 <MMavipc> sipa: what's the new?
419 2012-08-01 18:42:18 <sipa> MMavipc: only storing the secret parameter, instead of the entire openssl eckey structure
420 2012-08-01 18:42:31 <MMavipc> sipa: I'm reading 271 bytes out of the berkeley db, normally its 282(3 extra bytes at beginning)
421 2012-08-01 18:42:53 <MMavipc> this is with a 0.6.3 wallet
422 2012-08-01 18:43:00 <sipa> MMavipc: the secret parameter is 32 bytes
423 2012-08-01 18:43:18 <sipa> but on-disk that is only used in encrypted wallets
424 2012-08-01 18:43:25 <MMavipc> sipa: I know this, but where in that 271 bytes are those 32 bytes
425 2012-08-01 18:44:12 <sipa> MMavipc: i'm sure you can find it by comparing a few private key structures
426 2012-08-01 18:44:23 <wumpus> Diapolo: ret is 0xc3 on x86
427 2012-08-01 18:44:30 <sipa> MMavipc: the only varying thing is the pubkey and the secret parameter, iirc
428 2012-08-01 18:46:56 <MMavipc> sipa: do you know of a less-hacky way to do this, rather than just extracting it?
429 2012-08-01 18:47:07 <Diapolo> wumpus: I was looking for an easy way to trigger this without asm
430 2012-08-01 18:47:53 <wumpus> Diapolo: it's only one byte... just put it in a buffer, cast it to a void() function, and call it