1 2011-12-19 01:04:24 <ByteCoin> ping sipa
  2 2011-12-19 01:05:45 <ByteCoin> ;;seen spia
  3 2011-12-19 01:05:46 <gribble> I have not seen spia.
  4 2011-12-19 01:05:53 <ByteCoin> ;;seen sipa
  5 2011-12-19 01:05:53 <gribble> sipa was last seen in #bitcoin-dev 7 hours, 10 minutes, and 47 seconds ago: <sipa> no, i don't think so
  6 2011-12-19 01:06:15 <ByteCoin> quit
  7 2011-12-19 03:04:33 <DiabloD3> holy fuck
  8 2011-12-19 03:04:53 <DiabloD3> http://abcnews.go.com/International/wireStory/north-korea-supreme-leader-kim-jong-il-died-15185454#.Tu63Y-hg-9w
  9 2011-12-19 03:05:47 <luke-jr> &
 10 2011-12-19 03:07:27 <DiabloD3> luke-jr: WHERES YOUR GOD NOW, BIATCH?!
 11 2011-12-19 03:07:36 <luke-jr> same place He always is.
 12 2011-12-19 03:07:51 <DiabloD3> dude, if Obama can complete his set of world terrorist leaders by nuking Iran
 13 2011-12-19 03:07:56 <DiabloD3> hes President FOREVER
 14 2011-12-19 03:08:34 <luke-jr> not that simple
 15 2011-12-19 03:09:01 <DiabloD3> /bin/laden AND lil kim?
 16 2011-12-19 03:09:10 <DiabloD3> thats enough for canonization
 17 2011-12-19 03:09:11 <cjdelisle> erm I doubt obama will get credit for kim il's death, I mean if he was old age then maybe he would
 18 2011-12-19 03:09:12 <luke-jr> what happens when Iran takes out the GPS sats?
 19 2011-12-19 03:09:14 <DiabloD3> saint bama
 20 2011-12-19 03:09:39 <cjdelisle> Yes We Cancer
 21 2011-12-19 03:09:39 <luke-jr> &
 22 2011-12-19 03:09:40 <DiabloD3> luke-jr: we didnt have GPS in WWII, I doubt we need it now.
 23 2011-12-19 03:09:45 <luke-jr> Obama shouldn't get credit for Laden either
 24 2011-12-19 03:09:49 <DiabloD3> cjdelisle: ... you know better.
 25 2011-12-19 03:09:53 <luke-jr> DiabloD3: in WWII, someone flew the bomb
 26 2011-12-19 03:10:02 <DiabloD3> luke-jr: ALL THE WAY DOWN, YEEEHAWHH
 27 2011-12-19 03:10:28 <DiabloD3> fuck I want to watch that movie now
 28 2011-12-19 03:10:30 <DiabloD3> goddamnit luke
 29 2011-12-19 03:10:31 <luke-jr> are there any more human-delivery nukes?
 30 2011-12-19 03:10:51 <DiabloD3> You cant fight in here, this is a war room!
 31 2011-12-19 03:10:58 <cjdelisle> hehe
 32 2011-12-19 03:11:22 <DiabloD3> ;;ticker
 33 2011-12-19 03:11:23 <gribble> Best bid: 3.21, Best ask: 3.2101, Bid-ask spread: 0.0001, Last trade: 3.21, 24 hour volume: 9769, 24 hour low: 3.1751, 24 hour high: 3.2189
 34 2011-12-19 03:11:41 <cjdelisle> Chappelle's black bush was epic
 35 2011-12-19 03:11:42 <DiabloD3> ;;calc 3.21 * 2.81
 36 2011-12-19 03:11:43 <gribble> 9.0201
 37 2011-12-19 03:11:52 <cjdelisle> o/t I know
 38 2011-12-19 03:25:38 <[Tycho]> I wonder how much would cost a coin from block 0 or 1 :)
 39 2011-12-19 03:26:49 <roconnor> Tycale_: probably free transaction
 40 2011-12-19 03:26:51 <roconnor> er
 41 2011-12-19 03:26:58 <roconnor> [Tycho]:
 42 2011-12-19 03:29:55 <DiabloD3> yeah, it should end being nearly free if not absolutely free
 43 2011-12-19 03:30:25 <[Tycho]> Normal transactions are free anyway.
 44 2011-12-19 03:30:44 <roconnor> [Tycho]: is that so?
 45 2011-12-19 03:30:49 <[Tycho]> Yes.
 46 2011-12-19 03:30:57 <DiabloD3> "By using a subdimensional vector space useless hyperspace will be destroyed in the process."
 47 2011-12-19 03:30:59 <roconnor> I don't understand the transaction fee rules
 48 2011-12-19 03:31:05 <roconnor> the wiki page is very confusing
 49 2011-12-19 03:31:37 <DiabloD3> roconnor: it uses a pretty simple "whore" formula
 50 2011-12-19 03:31:42 <DiabloD3> the more of a whore you are, the more you pay.
 51 2011-12-19 03:31:56 <[Tycho]> Well, there are some limits when it's close to the desired maximum block size.
 52 2011-12-19 03:32:13 <roconnor> [Tycho]: I'm more concerend about getting transactions relayed
 53 2011-12-19 03:32:22 <[Tycho]> Oh, relayed...
 54 2011-12-19 03:32:33 <[Tycho]> I need to find a solution for that.
 55 2011-12-19 03:32:45 <roconnor> [Tycho]: you and everyone else
 56 2011-12-19 03:32:47 <[Tycho]> Also, there is luke-jr's node for relaying.
 57 2011-12-19 03:32:54 <roconnor> well that is my current thinking
 58 2011-12-19 03:33:05 <roconnor> send everything to Eligius
 59 2011-12-19 03:33:15 <roconnor> but that hardly seems scalable
 60 2011-12-19 03:33:15 <[Tycho]> I'm mining most of the network's free TXes.
 61 2011-12-19 03:33:48 <[Tycho]> I wonder how fees will surge if I'll stop this :)
 62 2011-12-19 03:34:24 <roconnor> [Tycho]: implement a 1 satoshi fee
 63 2011-12-19 03:34:31 <[Tycho]> Why ?
 64 2011-12-19 03:34:42 <[Tycho]> 1 satoshi won't make any profit for me.
 65 2011-12-19 03:35:10 <[Tycho]> Currently my rules are 0.01 or more BTC to be considered non-free.
 66 2011-12-19 03:36:49 <roconnor> sounds arbitrary
 67 2011-12-19 03:37:22 <[Tycho]> Why ? 1 bitcent is a nice number.
 68 2011-12-19 03:37:30 <DiabloD3> rcorreia: its not
 69 2011-12-19 03:37:59 <DiabloD3> rcorreia: also, bitcoin tends to try to produce optimum fee raping on blocks when space is contested
 70 2011-12-19 03:38:17 <DiabloD3> ie, the more the tx is worth, the more likely it will make it into the block if the block is full
 71 2011-12-19 03:39:32 <vsrinivas> right. among other fields use to determine this, the value of the tx's outputs and the time they're been unspent iirc are used.
 72 2011-12-19 03:40:13 <DiabloD3> yeah, the formula last time I saw it is trying to be fair as possible
 73 2011-12-19 03:44:00 <[Tycho]> Wow, a new proportional pool opened :) https://bitcointalk.org/index.php?topic=54970.msg0#new
 74 2011-12-19 03:44:13 <[Tycho]> I wonder how long it will take for hoppers to kill it.
 75 2011-12-19 03:46:14 <SomeoneWeird> LOL their site looks pretty shit
 76 2011-12-19 03:46:52 <DiabloD3> SomeoneWeird: take a look at eligius's lately?
 77 2011-12-19 03:47:36 <rjk2> "Welcome to Simplecoin.us" wat
 78 2011-12-19 03:48:09 <rjk2> with the actual link pointing to tntmining
 79 2011-12-19 03:49:05 <DiabloD3> Im not seeing it
 80 2011-12-19 03:49:38 <rjk2> on the stats page
 81 2011-12-19 03:49:46 <[Tycho]> Looks a bit like 50BTC pool.
 82 2011-12-19 03:49:59 <SomeoneWeird> not really why DiabloD3
 83 2011-12-19 03:50:22 <DiabloD3> SomeoneWeird: ooglay
 84 2011-12-19 03:50:28 <SomeoneWeird> ahah
 85 2011-12-19 03:50:32 <DiabloD3> rjk2: hrm, I should lock the thread.
 86 2011-12-19 03:50:58 <rjk2> it looks like a default template that someone forgot to mod
 87 2011-12-19 03:51:12 <[Tycho]> http://pool.mkalinin.ru/
 88 2011-12-19 03:51:54 <[Tycho]> Looks similar to me.
 89 2011-12-19 03:52:21 <rjk2> yeah looks like the same software
 90 2011-12-19 03:52:26 <rjk2> must be open source
 91 2011-12-19 03:52:31 <rjk2> or something
 92 2011-12-19 03:53:08 <[Tycho]> Open source forces people to use same design, how disappoiting...
 93 2011-12-19 03:53:41 <rjk2> or they are lazy
 94 2011-12-19 03:54:07 <SomeoneWeird> it is
 95 2011-12-19 03:54:13 <[Tycho]> One year ago it would take some efforts to make a new pool.
 96 2011-12-19 03:54:15 <SomeoneWeird> it's simplecoin
 97 2011-12-19 03:54:24 <[Tycho]> Now you need just a couple of minutes :)
 98 2011-12-19 03:54:29 <rjk2> simplecoin is a pool software?
 99 2011-12-19 03:54:33 <SomeoneWeird> yes
100 2011-12-19 03:54:34 <SomeoneWeird> iirc
101 2011-12-19 03:54:42 <rjk2> oh ok
102 2011-12-19 03:54:50 <SomeoneWeird> yep, the pools that have custom interfaces are going to do better than the ones using other one
103 2011-12-19 03:54:51 <SomeoneWeird> s
104 2011-12-19 03:57:41 <[Tycho]> I'm mostly talking about core.
105 2011-12-19 05:00:54 <forrestv> BlueMattBot, what did you mean by "-keepnode=localhost" in your comment on my pull request?
106 2011-12-19 05:00:55 <BlueMattBot> forrestv did you mean me? Unknown command 'what'
107 2011-12-19 05:01:00 <forrestv> hm
108 2011-12-19 05:51:54 <luke-jr> DONT SPAM the Chan version
109 2011-12-19 05:51:59 <luke-jr> DONT SPAM the Chan help
110 2011-12-19 05:52:00 <luke-jr> hmm
111 2011-12-19 05:52:03 <luke-jr> <.<
112 2011-12-19 05:52:07 <BlueMattBot> Available commands:
113 2011-12-19 05:52:07 <luke-jr> BlueMattBot: DONT SPAM the Chan help
114 2011-12-19 05:52:08 <BlueMattBot> abort <job> - specify which job to abort
115 2011-12-19 05:52:09 <BlueMattBot> botsnack [<snack>] - om nom nom
116 2011-12-19 05:52:10 <BlueMattBot> build <job> [now|<delay>[s|m|h]] [<parameterkey>=<value>]* - schedule a job build, with standard, custom or no quiet period
117 2011-12-19 05:52:11 <BlueMattBot> currentlyBuilding - list jobs which are currently in progress
118 2011-12-19 05:52:12 <BlueMattBot> health [<job>|-v <view>] - show the health of a specific job, jobs in a view or all jobs
119 2011-12-19 05:52:12 <luke-jr> omg
120 2011-12-19 05:52:13 <BlueMattBot> jobs [<job>|-v <view>] - show the status of a specific job, jobs in a view or all jobs
121 2011-12-19 05:52:14 <BlueMattBot> s [<job>|-v <view>] - show the status of a specific job, jobs in a view or all jobs
122 2011-12-19 05:52:14 <copumpkin> lol
123 2011-12-19 05:52:15 <BlueMattBot> schedule <job> [now|<delay>[s|m|h]] [<parameterkey>=<value>]* - schedule a job build, with standard, custom or no quiet period
124 2011-12-19 05:52:16 <BlueMattBot> testresult [<job>|-v <view>] - show the test results of a specific job, jobs in a view or all jobs
125 2011-12-19 05:52:16 <copumpkin> wtf
126 2011-12-19 05:52:20 <luke-jr> ^
127 2011-12-19 05:52:53 <luke-jr> botsnack, but no botpunish? -.-
128 2011-12-19 06:55:08 <CIA-100> bitcoin: mtve broken * r874b41..acdf31 bitcoin-pl/ (12 files in 2 dirs): (14 commits) http://tinyurl.com/83wnxhl
129 2011-12-19 10:34:38 <[Tycho]> Is there any name for value opposite to hash ?
130 2011-12-19 10:50:28 <Mqrius> plaintext?
131 2011-12-19 10:53:01 <[Tycho]> No.
132 2011-12-19 10:55:22 <[Tycho]> For example, 98c1eb4ee93476743763878fcb96a25fbc9a175074d64004779ecb5242f645e6 is a sha256 hash of "word".
133 2011-12-19 10:55:40 <[Tycho]> And "word" is a ... (what?) of 98c1eb4ee93476743763878fcb96a25fbc9a175074d64004779ecb5242f645e6 ?
134 2011-12-19 11:04:02 <epscy> input?
135 2011-12-19 11:14:31 <Mqrius> I still say plaintext, in most cases. 98c1eb4ee93476743763878fcb96a25fbc9a175074d64004779ecb5242f645e6 is the hash of "word", while "word" is the plaintext of 98c1eb4ee93476743763878fcb96a25fbc9a175074d64004779ecb5242f645e6.
136 2011-12-19 11:29:40 <lianj> but plaintext suggests plaintext :P
137 2011-12-19 11:32:15 <Mqrius> lianj: Yes, well, this name for the reverse-hash is only valid where the source is something plaintext. It would be strange to use it for the elliptic curve point for example. (The "plaintext" of a bitcoin address)
138 2011-12-19 13:12:10 <[Tycho]> What patch do CBase58Data comes from ?
139 2011-12-19 13:18:21 <knotwork> re reverse hash: reverse hash seems sensible enough term. But maybe you could try calling it the hashed or the hashee
140 2011-12-19 14:10:06 <CIA-100> bitcoin: mtve broken * rb8c4f9176111 bitcoin-pl/ (main.pm script.pm): fix for http://blockexplorer.com/t/6pBzfRAnxY http://tinyurl.com/75o75vp
141 2011-12-19 14:10:07 <CIA-100> bitcoin: mtve broken * rdb37f1d1760d bitcoin-pl/main.pm: correct fix for prev commit http://tinyurl.com/7yeom6u
142 2011-12-19 14:12:33 <CIA-100> bitcoin: Luke Dashjr master * r6477348 / src/net.cpp : Add my DNS seed domain - http://git.io/HS5dzg https://github.com/bitcoin/bitcoin/commit/647734881c5c4a27357e289733fe02900cf1a70c
143 2011-12-19 14:12:34 <CIA-100> bitcoin: Gavin Andresen master * rcd2b883 / src/net.cpp : Merge pull request #709 from luke-jr/newdnsseeds ... https://github.com/bitcoin/bitcoin/commit/cd2b8832fdb087e740e8d6da69c75f46d69b52d2
144 2011-12-19 14:19:38 <sipa> [Tycho]_: key import/export
145 2011-12-19 14:21:48 <gavinandresen> BlueMatt: ping
146 2011-12-19 14:25:19 <CIA-100> bitcoin: Gavin Andresen master * rf8ded58 / (12 files in 2 dirs): Implement BIP 14 : separate protocol version from client version - http://git.io/ZwrWoQ https://github.com/bitcoin/bitcoin/commit/f8ded588a2f78ac2767a60c716a7d15c273b4fc7
147 2011-12-19 14:26:20 <CIA-100> bitcoin: Gavin Andresen master * rfc90967 / (src/qt/bitcoingui.cpp src/qt/bitcoingui.h): Merge pull request #699 from laanwj/about_qt ... https://github.com/bitcoin/bitcoin/commit/fc90967876a0b8c762cba4a9f40a80db7a8b0432
148 2011-12-19 14:27:28 <CIA-100> bitcoin: Gavin Andresen master * r99a289f / (16 files in 2 dirs): Merge pull request #574 from sipa/dumpprivkey ... https://github.com/bitcoin/bitcoin/commit/99a289f531e9dc42aa81ea32ff84b807a46b6a9c
149 2011-12-19 14:30:42 <gavinandresen> sipa: I'm getting a missing symbol linking with the merged dumpprivkey
150 2011-12-19 14:31:04 <sipa> :o
151 2011-12-19 14:31:20 <sipa> i built it a few days ago
152 2011-12-19 14:31:54 <gavinandresen> sipa: https://gist.github.com/1497693
153 2011-12-19 14:31:59 <gavinandresen> (back in a few minutes....)
154 2011-12-19 14:32:35 <sipa> are you using an old key.o, and no rpcdump.o ?
155 2011-12-19 14:33:21 <sipa> wait, that doesn't make sense
156 2011-12-19 14:33:26 <gavinandresen> I did a make clean first....
157 2011-12-19 14:33:41 <gavinandresen> .... oh, wait, never mind, hacked Makefile
158 2011-12-19 14:36:56 <[Tycho]_> sipa: I see it used in key import/export but somehow don't see where it's defined...
159 2011-12-19 14:37:34 <sipa> [Tycho]_: in base58.h
160 2011-12-19 14:38:24 <[Tycho]_> Hmm, converting 100 hash160 to addresses takes almost 70 ms in PHP :(
161 2011-12-19 14:38:43 <sipa> use a programming language
162 2011-12-19 15:03:15 <[Tycho]_> Another deepbit programmer already asked me to move the site to same platform as core pool, but I still can't agree :)
163 2011-12-19 15:03:29 <[Tycho]_> May be will think about something like fastcgi...
164 2011-12-19 15:16:28 <BlueMatt> gavinandresen: I highly think the solution to many of the bdb encryption problems is to do our own keystore in a text file we control completely
165 2011-12-19 15:17:19 <gavinandresen> BlueMatt:  I highly think the solution is keys on separate devices
166 2011-12-19 15:17:34 <sipa> i think those two solutions are orthogonal
167 2011-12-19 15:18:04 <BlueMatt> /agreed
168 2011-12-19 15:18:12 <upb> i believe strongy the solution to everything is either 1) add another layer of abstraction or 2) implement the idea inhouse
169 2011-12-19 15:18:24 <sipa> i don't think we'll ever be able to move the keys completely outside of the software
170 2011-12-19 15:18:31 <gavinandresen> Yes, but I'm not planning on putting any effort into keys-in-a-text-file-we-control because I think the multi-device solution is much more important
171 2011-12-19 15:19:01 <BlueMatt> so you are just gonna put a ton of effort into bdb workarounds?
172 2011-12-19 15:19:13 <gavinandresen> BlueMatt: no
173 2011-12-19 15:19:48 <gavinandresen> BlueMatt: I just want to know what the risks are, so users can know what the risks are
174 2011-12-19 15:19:53 <BlueMatt> you already have, and Im pretty sure the point about wallet passphrase change is broken
175 2011-12-19 15:20:23 <BlueMatt> and I agree, keys should be on separate devices, but that is a long ways off, and we have to do something other then keep them in bdb in the meantime
176 2011-12-19 15:21:22 <sipa> moving away from bdb is really not that hard
177 2011-12-19 15:21:30 <sipa> (for private keys)
178 2011-12-19 15:21:43 <gavinandresen> Ok.... anybody working on that?
179 2011-12-19 15:21:50 <sipa> we've been discussing it some time ago
180 2011-12-19 15:22:20 <sipa> but, no
181 2011-12-19 15:22:29 <BlueMatt> well in standard bitcoin fashion it has been heavily discussed, but I dont think anyone is working on it
182 2011-12-19 15:23:06 <gavinandresen> Well, I've been very clear on what my priorities are, and I'm not going to work on it.
183 2011-12-19 15:23:17 <sipa> i've got a few other things on my priority list now, but i wouldn't mind working on it
184 2011-12-19 15:23:25 <sipa> gavinandresen: fair enough
185 2011-12-19 15:23:29 <gavinandresen> ... but what do you suggest we tell 0.4 users?
186 2011-12-19 15:23:52 <sipa> upgrade to 0.4.1 or 0.5?
187 2011-12-19 15:24:00 <sipa> or is there something i'm missing?
188 2011-12-19 15:24:18 <gavinandresen> sipa: I send an email a few minutes ago RE: sending an alert
189 2011-12-19 15:24:22 <sipa> oh
190 2011-12-19 15:24:44 <BlueMatt> I think the install scripts should be fixed so that the upgrade procedure removes wx
191 2011-12-19 15:24:53 <BlueMatt> Im surprised that was never done...
192 2011-12-19 15:26:28 <gavinandresen> Some people considered the 'keep the wx version around' a feature, not a bug
193 2011-12-19 15:27:07 <sipa> hmm, does changing the passphrase trigger a wallet rewrite?
194 2011-12-19 15:27:35 <sipa> if not, there is certainly a chance that the key could be recovered from the old mkey record in the bdb slack space
195 2011-12-19 15:27:41 <gavinandresen> are we sure it needs to?  does it overwrite a db entry, or add a new one?
196 2011-12-19 15:27:42 <BlueMatt> mmm, well as long as 0.4 crashes when opening an encrypted wallet, we are ok...
197 2011-12-19 15:27:52 <Eliel> one way of solving the bdb leaving data around issue would be to simply not save the data in the file in cleartext, ever. That is, make the only difference between unencrypted wallet and encrypted wallet that "unencrypted" wallet contains the encryption key used to encrypt the private keys.
198 2011-12-19 15:27:56 <sipa> gavinandresen: that's irrelevant, i believe
199 2011-12-19 15:28:24 <sipa> Eliel: and have the master key available on disk?
200 2011-12-19 15:28:28 <gavinandresen> I'd really like to get past "I believe" and "I'm pretty sure" ....
201 2011-12-19 15:28:31 <sipa> Eliel: that just moves the problem
202 2011-12-19 15:28:36 <gmaxwell> Eliel: then you just leave the master key.
203 2011-12-19 15:29:08 <sipa> BlueMatt: 0.4 doesn't crash on opening an encrypted wallet
204 2011-12-19 15:29:12 <BlueMatt> gavinandresen: I would be willing to bet that sipa is right here
205 2011-12-19 15:29:30 <BlueMatt> sipa: oh, oops wrong client sorry
206 2011-12-19 15:29:32 <gavinandresen> If, in practice, you change the wallet passphrase 100 times and BDB never actually leaves anything in 'slack space' because it is always overwriting the same number of bytes in the same record, then that's good enough.
207 2011-12-19 15:29:53 <gavinandresen> (it'll leave stuff in the transaction log, but that's OK because that gets removed at shutdown)
208 2011-12-19 15:29:55 <sipa> gavinandresen: i don't think bdb ever overwrites date, unless you set a specific option when opening the file
209 2011-12-19 15:29:56 <BlueMatt> gavinandresen: I would be willing to bet that isnt true
210 2011-12-19 15:30:20 <sipa> but i guess we need to test this
211 2011-12-19 15:30:38 <sipa> sec
212 2011-12-19 15:31:18 <gavinandresen> again, I just want to know whether or not we can tell users "upgrade to 0.5.1 and wallet encryption is fixed".  If we can't... then we probably should just tell them "wallet encryption is broken.  Stay tuned, we're figuring out how to fix it."
213 2011-12-19 15:31:35 <Eliel> sipa: it moves the problem, yes, but it's simpler to to erase one key than n+1 keys from the hdd.
214 2011-12-19 15:31:53 <sipa> Eliel: but the master key doesn't ever change
215 2011-12-19 15:32:06 <sipa> if it touched disk once, your entire wallet should be considered comprimised
216 2011-12-19 15:32:39 <sipa> gavinandresen: i'm testing something, sec
217 2011-12-19 15:32:48 <gavinandresen> sipa: thanks
218 2011-12-19 15:32:51 <Eliel> sipa: that's easily fixed.
219 2011-12-19 15:33:12 <BlueMatt> Eliel: you are changing the problem to the problem sipa is currently testing...
220 2011-12-19 15:33:47 <sipa> gavinandresen: but if the problem is that changing a passphrase results in the old mkey record remaining available, it should be changed to causing a wallet.dat-rewrite as well
221 2011-12-19 15:33:53 <BlueMatt> you took a problem that was related (and pretty much solved), and changed it to the one we are looking at fixing
222 2011-12-19 15:34:54 <gavinandresen> sipa: yep.  I'd be more comfortable with that if I knew why people are reporting leftover wallet.dat.rewrites on their disks.....
223 2011-12-19 15:36:41 <sipa> BlueMatt: hmm, where in CWallet::ChangeWalletPassphrase does the old mkey get removed?
224 2011-12-19 15:36:53 <sipa> oh wait, it just writes a new one with the same key
225 2011-12-19 15:36:58 <sipa> never mind
226 2011-12-19 15:41:27 <helo> it would be nice if bitcoin-qt, when flushing writes to disk on close, would have a pop-up like the loading screen
227 2011-12-19 15:41:44 <sipa> gavinandresen: i checked the number of times an 'mkey' record was available in wallet.dat
228 2011-12-19 15:42:03 <sipa> gavinandresen: changing the passphrase doesn't change that number (1)
229 2011-12-19 15:42:08 <sipa> it practice
230 2011-12-19 15:42:22 <sipa> no guarantee that that is absolutely true all the time, of course
231 2011-12-19 15:43:17 <gavinandresen> sipa:  great.  I'll do a little testing, too...
232 2011-12-19 15:49:44 <luke-jr> upb: I'm the only one working on proper abstraction so far :<
233 2011-12-19 15:50:06 <upb> yeah too bad
234 2011-12-19 15:50:10 <BlueMatt> luke-jr: abstraction of what?
235 2011-12-19 15:50:11 <upb> it was meant as a joke :D
236 2011-12-19 15:50:43 <luke-jr> [11:27:43] <BlueMatt> mmm, well as long as 0.4 crashes when opening an encrypted wallet, we are ok& <-- it shouldn't.
237 2011-12-19 15:51:00 <BlueMatt> luke-jr: keep reading...
238 2011-12-19 15:51:42 <luke-jr> BlueMatt: wallet access abstraction
239 2011-12-19 15:52:21 <BlueMatt> mmm, well do keys in text file support
240 2011-12-19 15:52:31 <luke-jr> wait, wallet encryption is broken AGAIN?
241 2011-12-19 15:52:51 <luke-jr> BlueMatt: I'm only doing the abstraction :P
242 2011-12-19 15:52:52 <BlueMatt> no, but its so full of hacks that it would be nice to move off of bdb to do key storage
243 2011-12-19 15:54:23 <sipa> gavinandresen: bad news
244 2011-12-19 15:54:37 <sipa> gavinandresen: fresh wallet, encrypt it -> mkey record is available *twice* in the wallet.dat file
245 2011-12-19 15:54:53 <BlueMatt> wtf?
246 2011-12-19 15:54:53 <sipa> (although only being in the database once)
247 2011-12-19 15:55:10 <sipa> change passphrase: one of the old ones is still there
248 2011-12-19 15:55:13 <BlueMatt> damn bdb
249 2011-12-19 15:56:23 <sipa> i really don't want to use bdb for any sensitive data anymore
250 2011-12-19 15:56:40 <BlueMatt> agreed
251 2011-12-19 15:59:40 <luke-jr> sigh
252 2011-12-19 16:01:34 <luke-jr> how about replacing backupwallet with an full-encryptable XML export, and just not using bdb for backups?
253 2011-12-19 16:02:05 <sipa> luke-jr: walletdump needs a bit of work still, but it's quite close to that
254 2011-12-19 16:02:11 <sipa> JSON instead of XML thoug
255 2011-12-19 16:02:33 <luke-jr> why JSON? x.x
256 2011-12-19 16:02:39 <sipa> because i can read it
257 2011-12-19 16:02:47 <luke-jr> wasn't the long-term goal to get away from JSON?
258 2011-12-19 16:02:58 <sipa> never heard about such a goal
259 2011-12-19 16:02:59 <luke-jr> XML is easier to read than JSON :P
260 2011-12-19 16:03:17 <luke-jr> sipa: JSON has poor software support.
261 2011-12-19 16:03:37 <sipa> it's significantly easier to read in many languages than XML, imho
262 2011-12-19 16:03:45 <luke-jr> um, no&
263 2011-12-19 16:03:54 <luke-jr> virtually every language has an XML library
264 2011-12-19 16:04:01 <sipa> yeds
265 2011-12-19 16:04:02 <sipa> yes
266 2011-12-19 16:04:07 <luke-jr> virtually every JSON library, when it exists, is buggy
267 2011-12-19 16:04:12 <sipa> and it still requires a lot more work than JSON
268 2011-12-19 16:04:20 <sipa> but i won't argue about this - if you want XML export, please implement it
269 2011-12-19 16:08:29 <gavinandresen> sipa:  ok, thanks for testing.  I'm torn on what to tell 0.4 users; 0.5.1 is definitely more secure, but, obviously, still broken in subtle ways.
270 2011-12-19 16:09:07 <BlueMatt> gavinandresen: so fix 0.5.1, release, upgrade alert
271 2011-12-19 16:09:31 <sipa> i *really* don't like the mkey record being twice in that file *after* rewriting it
272 2011-12-19 16:09:32 <gavinandresen> luke-jr: the vulnerability is:  start with a weak passphrase, change it, and the hashed-but-weak passphrase may still be in the wallet.dat file.
273 2011-12-19 16:10:27 <Eliel> what would that do in practise if someone brute forces it?
274 2011-12-19 16:10:32 <luke-jr> gavinandresen: so& same problem as before? any reason the same solution won't work?
275 2011-12-19 16:10:36 <sipa> i don't even get it how that is possible
276 2011-12-19 16:10:44 <luke-jr> gavinandresen: 0.4 users can upgrade to 0.4.2
277 2011-12-19 16:10:45 <sipa> is that record being relocated within the file?
278 2011-12-19 16:12:11 <BlueMatt> luke-jr: bitcoin-wx users?
279 2011-12-19 16:12:11 <gavinandresen> sipa:  darn good question, why is the old mkey being written?  That might explain cypherdoc's bug, too...
280 2011-12-19 16:12:29 <sipa> gavinandresen: the old mkey is not being written
281 2011-12-19 16:12:34 <gavinandresen> (he said he had to use his old passphrase to unlock his new, re-written wallet)
282 2011-12-19 16:12:40 <sipa> gavinandresen: the current mkey is written twice
283 2011-12-19 16:12:45 <sipa> and only overwritten once
284 2011-12-19 16:12:47 <gavinandresen> sipa:  ah, ok.
285 2011-12-19 16:12:47 <luke-jr> BlueMatt: oh, only if someone steps up to maintain wx, right
286 2011-12-19 16:13:13 <sipa> still, wallet rewriting prunes any non-existing record
287 2011-12-19 16:13:17 <sipa> so encryption is "safe"
288 2011-12-19 16:13:30 <sipa> but changing a passphrase (without rewriting) isn't
289 2011-12-19 16:14:11 <sipa> cypherdoc's problem looks just like a crashed/failed rewrite
290 2011-12-19 16:14:34 <sipa> and bdb reverting
291 2011-12-19 16:14:50 <gavinandresen> Ok, so the easy solution is trigger a wallet rewrite whenever you change your wallet passphrase.
292 2011-12-19 16:15:17 <sipa> me to
293 2011-12-19 16:15:22 <gavinandresen> luke-jr: ... too much assuming happening in this project....
294 2011-12-19 16:18:38 <BlueMatt> gavinandresen: no, too much talk without testing/working in this project
295 2011-12-19 16:18:45 <sipa> that too :)
296 2011-12-19 16:18:46 <BlueMatt> which results in assumptions
297 2011-12-19 16:18:55 <sipa> my mistake, i assumed i caused a resilver in my own branch after changing a passphrase
298 2011-12-19 16:19:14 <sipa> seems i didn't
299 2011-12-19 16:20:34 <gavinandresen> BlueMatt: RE: talking:  want to volunteer to fix and test the windows installer so 0.4 to 0.5 upgrades happen smoothly?
300 2011-12-19 16:21:05 <BlueMatt> gavinandresen: Ill take a look...
301 2011-12-19 16:21:39 <devrandom> BlueMatt: I didn't get a chance to look into qt-win32 yet, but let me know if you had any insights re non-determinism beyond the .prl files
302 2011-12-19 16:22:17 <BlueMatt> devrandom: will do, I have it on my todo list, but it did look like its 99% deterministic, I need some more time to look into it...
303 2011-12-19 16:32:43 <BlueMatt> gavinandresen: the qt-win32 zip you used is out-of-date (hence why I cant get close to it in my builds)
304 2011-12-19 16:33:36 <BlueMatt> gavinandresen: can you run a new build and upload it somewhere for comparison?
305 2011-12-19 16:34:41 <gavinandresen> BlueMatt: I'm not clear on what you want me to do-- re-fetch an input and re-build it?
306 2011-12-19 16:35:48 <BlueMatt> gavinandresen: no, just rebuild the qt gitian yml (as long as your qt-everywhere-opensource-src-4.7.4... is the 97195eb... sha256)
307 2011-12-19 16:36:38 <gavinandresen> BlueMatt: ok, but I thought we determined that builds done on the same day were deterministic.....
308 2011-12-19 16:38:36 <BlueMatt> gavinandresen: assuming you use a recent version, yea, but I want to make sure you can duplicate on the latest version vs mine on diff hardware, etc...
309 2011-12-19 16:39:12 <gavinandresen> BlueMatt: ok, building now... (it'll be a while before it is done)
310 2011-12-19 16:39:56 <BlueMatt> thanks
311 2011-12-19 16:44:37 <coderrr> what do you guys think about a setting for the gitian build process to use multiple cores ?
312 2011-12-19 16:45:01 <coderrr> or would that make the output non deterministic ?
313 2011-12-19 16:45:53 <BlueMatt> it already has one
314 2011-12-19 16:45:55 <BlueMatt> -j
315 2011-12-19 16:46:22 <k9quaint> how can you work on the day after the glorious leader has died :(
316 2011-12-19 16:46:24 <BlueMatt> and it usually doesnt make it nondeterministic, but sometimes does (so the gitian files are modified to not use the -j option if it is nondeterministic with -j)
317 2011-12-19 16:46:36 <coderrr> ah ok
318 2011-12-19 16:46:37 <BlueMatt> k9quaint: heh
319 2011-12-19 16:46:58 <gavinandresen> k9quaint: I'm not dead yet.
320 2011-12-19 16:47:05 <BlueMatt> haha
321 2011-12-19 16:47:24 <k9quaint> ah, to witness the birth of a thousand conspiracy theorys :)
322 2011-12-19 16:47:29 <gavinandresen> heh
323 2011-12-19 16:48:06 <BlueMatt> (and was replaced with his even crazier son...)
324 2011-12-19 16:48:07 <gavinandresen> ... I need a bigger pair of glasses to play the part of Glorious Leader....
325 2011-12-19 16:48:23 <BlueMatt> and a weird hat
326 2011-12-19 16:48:54 <k9quaint> you might need to fix your hair
327 2011-12-19 16:48:56 <gavinandresen> ... and fawning yes-men, as opposed to you guys who always slap me upside the head when I have dumb ideas....
328 2011-12-19 16:49:30 <gavinandresen> "Follow me men!  We shall invade PayPal at Dawn!"
329 2011-12-19 16:49:34 <BlueMatt> heh
330 2011-12-19 16:50:01 <BlueMatt> arg...compared to a build from yesterday "Binary files qt1/lib/libQtSql.a and qt2/lib/libQtSql.a differ"
331 2011-12-19 16:51:49 <BlueMatt> coderrr: also useful is the -m option to set the amount of memory for the virtual build server (if you are gonna use -j you need -m)
332 2011-12-19 16:51:52 <sipa> why do we need qt's sql?
333 2011-12-19 16:52:07 <BlueMatt> sipa: rm lib/libQtSql.a is probably not a bad idea
334 2011-12-19 17:07:50 <BlueMattBot> Project Bitcoin build #136: STILL FAILING in 24 min: http://jenkins.bluematt.me/job/Bitcoin/136/
335 2011-12-19 17:09:10 <luke-jr> sudo make block
336 2011-12-19 17:10:27 <BlueMatt> sipa: you broke it^
337 2011-12-19 17:10:55 <gmaxwell> BlueMatt: there is a jenkins option where it will figure out who broke the build and email the,
338 2011-12-19 17:10:59 <gmaxwell> er them.
339 2011-12-19 17:11:37 <BlueMatt> gmaxwell: it usually posts the list of commit authors here (and should have listed sipa, except that I had the irc notification broken and it was pming me instead of the chan, so there are no "changes" on that build)
340 2011-12-19 17:11:56 <BlueMatt> email, Ill take a look...
341 2011-12-19 17:13:11 <BlueMatt> gmaxwell: yes, there is though Im weary of enabling it as it doesnt check which commit broke the build, it just sends to every commit's author since last build
342 2011-12-19 17:13:22 <BlueMatt> gmaxwell: and Im assuming people will complain if I turn it on...
343 2011-12-19 17:14:06 <BlueMatt> aww, I got a "Binary files qt1/lib/libQtGui.a and qt3/lib/libQtGui.a differ"
344 2011-12-19 17:14:16 <coderrr> BlueMatt, ah thx, i've already extracted out and frakensteined the win32 gitian build scripts so i could do a standalone win32 build w/o a VM
345 2011-12-19 17:15:11 <BlueMatt> np
346 2011-12-19 17:17:30 <luke-jr> *%&#*)%&#)
347 2011-12-19 17:17:33 <luke-jr> someone find a block plz
348 2011-12-19 17:18:05 <BlueMatt> doubtful, ask gmaxwell
349 2011-12-19 17:18:52 <sipa> BlueMatt: seems the win32 build doesn't compile key.o and rpcdump.o ?
350 2011-12-19 17:18:53 <gmaxwell> luke-jr: you want someone to mine testnet?
351 2011-12-19 17:19:39 <gmaxwell> luke-jr: I'll mine testnet for you if you want.
352 2011-12-19 17:19:42 <BlueMatt> sipa: its just running the bitcoin-qt.pro qmake followed by make-j2
353 2011-12-19 17:20:17 <sipa> BlueMatt: it's in the win32 build for bitcoind
354 2011-12-19 17:20:39 <BlueMatt> oh, sorry...well in that case its just running the makefile.linux-mingw makefile
355 2011-12-19 17:20:58 <BlueMatt> (which it appears was not updated)
356 2011-12-19 17:21:06 <sipa> wow, never noticed that file
357 2011-12-19 17:21:41 <BlueMatt> it had been in my repo for a long time and not committed because its poorly-written...
358 2011-12-19 17:21:49 <BlueMatt> (and very ubuntu-specific_
359 2011-12-19 17:21:54 <BlueMatt> s/_/)/
360 2011-12-19 17:23:16 <CIA-100> bitcoin: Pieter Wuille master * r3ae6516 / src/makefile.linux-mingw : add key.o and rpcdump.o to makefile.linux-mingw - http://git.io/PxEX7Q https://github.com/bitcoin/bitcoin/commit/3ae65166b53ffcf37565cc8362558f3edb9a37b0
361 2011-12-19 17:23:52 <luke-jr> gmaxwell: I just want a block found somehwere :P
362 2011-12-19 17:24:02 <gmaxwell> luke-jr: even on testnet? Why?
363 2011-12-19 17:24:06 <luke-jr> testing :P
364 2011-12-19 17:24:14 <gmaxwell> okay, I'll do a testnet block.
365 2011-12-19 17:24:18 <luke-jr> hold on then, lemme switch
366 2011-12-19 17:24:42 <luke-jr> ok, on testnet now
367 2011-12-19 17:24:53 <gmaxwell> okay.
368 2011-12-19 17:25:54 <gmaxwell> bin
369 2011-12-19 17:25:55 <gmaxwell> g
370 2011-12-19 17:26:14 <gmaxwell> luke-jr: happy now?
371 2011-12-19 17:26:24 <luke-jr> hmm, no
372 2011-12-19 17:26:51 <gavinandresen> luke-jr: you testing op_eval 0.6 changes on testnet?  (that's actually what I'm working on right now...)
373 2011-12-19 17:26:59 <luke-jr> gavinandresen: no
374 2011-12-19 17:27:13 <luke-jr> gavinandresen: furthermore, I'd prefer to see OP_EVAL wait for sipa's stuff at least :p
375 2011-12-19 17:27:24 <luke-jr> before being validated by non-miners, I mean
376 2011-12-19 17:27:49 <luke-jr> gmaxwell: still mining?
377 2011-12-19 17:28:19 <gmaxwell> No, if you need me to again lemme know.
378 2011-12-19 17:28:29 <gmaxwell> There there were two blocks right after the one I got.
379 2011-12-19 17:28:39 <luke-jr> gmaxwell: I do, my code doesn't seem to be working
380 2011-12-19 17:28:40 <luke-jr> oh
381 2011-12-19 17:28:41 <gmaxwell> oh, three actually.
382 2011-12-19 17:28:42 <luke-jr> so someone else is mining
383 2011-12-19 17:28:48 <gmaxwell> yea apparently.
384 2011-12-19 17:28:48 <sipa> luke-jr: unless there's reasonable consensus about updating the script language (i'm in favor, obviously), i don't plan to implement it
385 2011-12-19 17:29:21 <luke-jr> sipa: I think we can get both Tycho and I behind it ;)
386 2011-12-19 17:29:42 <gavinandresen> behind what?
387 2011-12-19 17:29:52 <rjk2> i think Graet might be mining on testnet right now, to test his DGM setup
388 2011-12-19 17:29:55 <sipa> gavinandresen: https://gist.github.com/1262449 :)
389 2011-12-19 17:30:30 <BlueMatt> its kinda sad when everyone knows who it is mining on testnet
390 2011-12-19 17:30:35 <gavinandresen> I think that is a great idea that will need six months of review/thought.
391 2011-12-19 17:31:13 <gmaxwell> gavinandresen: luke (and [Tycho]_ to some degree I think) were clamoring for a new address format for send-to-compressed-pubkey because it's smaller in the chain. And I flamed him (with some technical support from Sipa) that key recovery is clearly superior and should be done instead as per sipa's proposal.
392 2011-12-19 17:31:23 <gavinandresen> ... and I think we need multidevice wallets right now, so I'm going to throw a hissy fit if all of the op_eval planning/discussion is deferred
393 2011-12-19 17:31:25 <[Tycho]_> Hello.
394 2011-12-19 17:32:03 <luke-jr> gavinandresen: I think implementing multidevice wallets will be 6 months out ;)
395 2011-12-19 17:32:06 <gavinandresen> I'm hearing two issues:  new scripting language and key recover.
396 2011-12-19 17:32:11 <BlueMatt> gavinandresen: realistically, most people arent gonna bother setting up a multidevice wallet
397 2011-12-19 17:32:21 <gavinandresen> luke-jr: yes, IF we get mining support in NOW.
398 2011-12-19 17:32:29 <gmaxwell> (see also: http://people.xiph.org/~greg/addr.compare.html)
399 2011-12-19 17:32:37 <sipa> gmaxwell: http://sourceforge.net/mailarchive/message.php?msg_id=28559816
400 2011-12-19 17:32:41 <gavinandresen> BlueMatt: I want bitcoin version 1.0 wallets to be multidevice by default.
401 2011-12-19 17:32:45 <luke-jr> gavinandresen: mining support is already in. ;)
402 2011-12-19 17:32:54 <sipa> gmaxwell: has some more explanation
403 2011-12-19 17:33:00 <BlueMatt> gavinandresen: that doesnt mean most people will use it...
404 2011-12-19 17:33:19 <luke-jr> gavinandresen: so long as ONLY miners do the verification, OP_EVAL as-is can be used today.
405 2011-12-19 17:33:34 <luke-jr> gavinandresen: while still deferring for script improvmenet
406 2011-12-19 17:33:42 <luke-jr> script improvements to include key recovery
407 2011-12-19 17:33:52 <sipa> i have no problem with pushing a simple OP_EVAL now that will allow multidevice stuff
408 2011-12-19 17:33:53 <luke-jr> ie, non-miners keep doing OP_NOP
409 2011-12-19 17:34:13 <sipa> and start thinking about *all* possible improvements to the scripting language, which could together go in an OP_EVAL2
410 2011-12-19 17:34:34 <sipa> as obviously i've only changed a few things, while there may be much more possible
411 2011-12-19 17:34:46 <[Tycho]_> "multidevice wallets" ?
412 2011-12-19 17:35:17 <gavinandresen> luke-jr: I'm not clear on what you're proposing, then.  The pending op_eval pull (which I just rebased and cleaned up) is, essentially, mining-and-testnet-only
413 2011-12-19 17:35:54 <luke-jr> gavinandresen: oh, it won't make the client part reject invalid OP_EVALs?
414 2011-12-19 17:36:18 <gavinandresen> luke-jr: it will make the client relay/check them, yes.
415 2011-12-19 17:36:51 <gmaxwell> gavinandresen: I think luke is proposing to delay phase2 of the rollout (where the new rules get enforced on the chain) so that more things can be added to OP_EVAL.
416 2011-12-19 17:36:52 <luke-jr> gavinandresen: if Eligius includes an OP_EVAL in a block, that does not fit the current OP_EVAL rules, will clients rejects that if they have your pull?
417 2011-12-19 17:37:07 <gmaxwell> sipa: how the heck could we do the op_eval2 without introducing yet another address type? :(
418 2011-12-19 17:37:16 <luke-jr> for example, a block including an OP_EVAL with OP_RECOVER in it
419 2011-12-19 17:37:22 <sipa> gmaxwell: very good point...
420 2011-12-19 17:37:34 <BlueMatt> how much additional cpu does key recovery take?
421 2011-12-19 17:37:41 <sipa> BlueMatt: 5% or so
422 2011-12-19 17:37:54 <BlueMatt> mmm
423 2011-12-19 17:37:57 <TD> argh
424 2011-12-19 17:38:11 <TD> can we please punt on scripting language "improvements" until we're actually using at least 10% of the power of todays language?
425 2011-12-19 17:38:27 <gavinandresen> the voice of reason enters....
426 2011-12-19 17:38:31 <gmaxwell> Not so.
427 2011-12-19 17:38:46 <TD> i want to work with jim+andreas to do multi-device wallets in javaland next year
428 2011-12-19 17:38:54 <gmaxwell> The improvement here that people are actually caring about is recovery, not anything fancy.
429 2011-12-19 17:38:59 <TD> probably in Q2 timeframe unless somebody steps up to help
430 2011-12-19 17:39:20 <BlueMatt> TD: there is a difference between improvements that can be implemented and used by current clients on simple sends, whereas most of the stuff in the current language is useful only in complicated weird cases
431 2011-12-19 17:39:25 <gavinandresen> So: for key recovery, take a couple of the other OP_NOP opcodes and implement key recovery.....
432 2011-12-19 17:39:28 <gavinandresen> LATER
433 2011-12-19 17:39:33 <sipa> BlueMatt: https://bitcointalk.org/index.php?topic=6430.msg100334#msg100334
434 2011-12-19 17:39:43 <TD> key recovery? this is for the smaller transactions?
435 2011-12-19 17:39:50 <sipa> TD: yes
436 2011-12-19 17:39:52 <gmaxwell> TD: yes.
437 2011-12-19 17:40:05 <TD> why not just implement pruning and get a 75% win without any backwards compatibility breaks
438 2011-12-19 17:40:07 <gavinandresen> For the record:  I think transaction size is completely and utterly a non-issue right now
439 2011-12-19 17:40:22 <gmaxwell> See the message/thread: http://sourceforge.net/mailarchive/message.php?msg_id=28559816
440 2011-12-19 17:40:32 <TD> BlueMatt: i'm not sure escrow or 2-factor coins are really that weird. the existing payment systems provide forms of this, even if they aren't always very good
441 2011-12-19 17:40:59 <sipa> TD: pruning is impossible for full nodes
442 2011-12-19 17:41:16 <BlueMatt> TD: 2-factor is already coming
443 2011-12-19 17:41:24 <BlueMatt> sipa: since when?
444 2011-12-19 17:41:29 <TD> i'm all for using pubkeys over addresses when there's no chance of the key contents being seen by users (aka not a user-visible address)
445 2011-12-19 17:41:38 <TD> sipa: as long as some nodes keep the full chain, others can prune their copies
446 2011-12-19 17:41:45 <TD> sipa: you'd end up with a 3-level network
447 2011-12-19 17:41:47 <BlueMatt> sipa: obv you cant send blocks, but most people dont have to do that
448 2011-12-19 17:41:48 <sipa> indeed
449 2011-12-19 17:41:54 <gmaxwell> TD: pruning isn't magical pixie juice in any case. Moreover, people are now asking for pay-to-pubkey in order to redeuce space on full nodes but it diminishes the improvement of pruning.
450 2011-12-19 17:42:00 <TD> sipa: or possibly, a few places/servers keeping the full record and then if you want a semi-full node, you bootstrap off them
451 2011-12-19 17:42:33 <sipa> yea, indeed
452 2011-12-19 17:43:11 <sipa> i don't really like the idea of further limiting the amount of full nodes (capable of serving the chain) on the network
453 2011-12-19 17:43:18 <luke-jr> reminder: 2-factor/multi-device does NOT require OP_EVAL
454 2011-12-19 17:43:41 <gavinandresen> sipa: I haven't heard anybody volunteer to implement pruning, so I think you don't have to worry.
455 2011-12-19 17:43:41 <TD> sipa: well, disk space is cheap, with that i agree. pruning for me is some way off
456 2011-12-19 17:43:42 <BlueMatt> sipa: its gonna happen one way or another, but I agree, network analysis needs to come first
457 2011-12-19 17:43:45 <TD> not the highest priority
458 2011-12-19 17:43:50 <gmaxwell> sipa++  it's not like we have a surplus of them
459 2011-12-19 17:43:52 <TD> anyway, home time
460 2011-12-19 17:44:31 <gavinandresen> luke-jr:  to answer your question RE: "new stuff in OP_EVAL" -- with my patch clients will completely validate stuff in OP_EVAL blocks after Feb 1.
461 2011-12-19 17:44:38 <gmaxwell> Besides, what people complaining about more than space is synctime that it takes 24 hours to sync up for people. Pruning doesn't improve that in any fundimental way.
462 2011-12-19 17:44:40 <luke-jr> without key recovery, it's full nodes VS pruning nodes
463 2011-12-19 17:44:50 <luke-jr> gavinandresen: that's the problem.
464 2011-12-19 17:45:13 <gavinandresen> luke-jr: why?  Key recovery is orthogonal to op_eval and multisigs
465 2011-12-19 17:45:27 <gavinandresen> (as is a new improved scripting language)
466 2011-12-19 17:45:32 <BlueMatt> gmaxwell: and synctime will probably not change much with key recovery...
467 2011-12-19 17:45:58 <luke-jr> gavinandresen: OP_EVAL is our one chance to add stuff to the scripting without a block chain fork
468 2011-12-19 17:45:59 <sipa> gavinandresen: key recovery requires a new scripting language, which can only easily be implemented through the use of an OP_EVAL-like construct
469 2011-12-19 17:46:22 <sipa> so, yes, it's possible to do this in an OP_EVAL2, and yet another address type
470 2011-12-19 17:46:35 <sipa> gavinandresen: actually, not necessarily
471 2011-12-19 17:46:37 <sipa> eh
472 2011-12-19 17:46:44 <gmaxwell> or a single type, and op_eval2 nested in op_eval.
473 2011-12-19 17:46:52 <sipa> indeed
474 2011-12-19 17:46:55 <gavinandresen> gmaxwell: yup
475 2011-12-19 17:47:01 <luke-jr> gmaxwell: that takes up even more space :P
476 2011-12-19 17:47:15 <gmaxwell> Okay, that prospect makes me feel better about not doing it now... though losing yet another byte sucks.
477 2011-12-19 17:47:22 <sipa> gmaxwell: you don't
478 2011-12-19 17:47:36 <gmaxwell> oh?
479 2011-12-19 17:48:07 <sipa> i think we need to distinguish between scripts using OP_EVAL, and scripts doing a spend-to-script-hash
480 2011-12-19 17:48:25 <sipa> you can do OP_EVAL directly without using the hash of the subscript being evaluated, right?
481 2011-12-19 17:48:27 <gmaxwell> oh!
482 2011-12-19 17:49:15 <sipa> so you'd get a < <addrhash> <OP_CHECKHASH> > <OP_EVAL2> script
483 2011-12-19 17:49:26 <sipa> instead of the current send-to-address scripts
484 2011-12-19 17:50:12 <luke-jr> hmm
485 2011-12-19 17:50:36 <luke-jr> in any case, let's add pubkey addresses then :P
486 2011-12-19 17:50:50 <sipa> gmaxwell: of course, you may want to use the new scripting language inside a spend-to-script-hash
487 2011-12-19 17:50:51 <gmaxwell> darnit.
488 2011-12-19 17:51:03 <sipa> which will require recursion and a lost byte
489 2011-12-19 17:51:16 <gmaxwell> sipa: yea, :(
490 2011-12-19 17:51:43 <gmaxwell> At least its a byte lost in the input script.
491 2011-12-19 17:51:47 <gavinandresen> Tell you what, I'll pay for that extra byte.
492 2011-12-19 17:51:57 <sipa> luke-jr: let's start by implementing compressed pubkeys whatsoever
493 2011-12-19 17:52:07 <luke-jr> sipa: sure :P
494 2011-12-19 17:52:22 <sipa> gavinandresen: when would you want to close the 0.6 merging window?
495 2011-12-19 17:52:36 <BlueMatt> wumpus: ping
496 2011-12-19 17:52:56 <gavinandresen> sipa: first or second week in January, I think
497 2011-12-19 17:53:40 <sipa> gavinandresen: in case a nice test routine is in place, and no reasonable complaints appear, is compressed pubkeys viable for 0.6?
498 2011-12-19 17:54:06 <luke-jr> sipa: I thought compressed pubkeys were done?
499 2011-12-19 17:54:33 <luke-jr> there's like 5-10 things that are ready to merge for 0.6, even if it were frozen tomorrow ;P
500 2011-12-19 17:54:35 <gavinandresen> sipa: do the alternative implementations have any issues with compressed pubkeys?
501 2011-12-19 17:54:43 <gavinandresen> (and are there any already in the main blockchain?)
502 2011-12-19 17:55:01 <sipa> gavinandresen: no alternative implementations that i know of fail on compressed pubkeys
503 2011-12-19 17:55:15 <sipa> maybe we should try that - there are only compressed ones in the testnet chain now
504 2011-12-19 17:55:57 <gavinandresen> sipa:  what would happen if we just switched to all-transactions-use-compressed ?
505 2011-12-19 17:56:19 <gavinandresen> (is there any reason to continue supporting non-compressed?)
506 2011-12-19 17:56:21 <sipa> gavinandresen: you can't; it's all-future-addresses-are-compressed
507 2011-12-19 17:56:31 <gavinandresen> Ah, ok.
508 2011-12-19 17:56:35 <sipa> old addresses will always keep using non-compressed-keys
509 2011-12-19 17:56:40 <gavinandresen> ... right, because the hash changes....
510 2011-12-19 17:56:53 <sipa> though you can't tell from an address whether it's for a compressed or non-compressed key
511 2011-12-19 17:57:01 <sipa> (which is nice, so senders don't require an update)
512 2011-12-19 17:58:50 <gavinandresen> As long as it gets thoroughly tested I have no objections; my preference would be to default-to-compressed, and just make sure the transition happens gracefully.
513 2011-12-19 17:59:16 <gavinandresen> (I assume old non-compressed keys would get two wallet entries, and sends to either compressed or uncompressed versions works properly?)
514 2011-12-19 17:59:47 <gavinandresen> (there I go, assuming again.....)
515 2011-12-19 18:00:05 <sipa> gavinandresen: no
516 2011-12-19 18:00:31 <sipa> wallets contain <pubkey,privkey> entries, that doesn't change
517 2011-12-19 18:00:54 <sipa> only for new addresses, the pubkey is compressed, and the corresponding address is different as well
518 2011-12-19 18:01:10 <luke-jr> IIRC the only thing that changes is that new pubkeys have a shorter length ;P
519 2011-12-19 18:01:33 <sipa> you never get to see the base58 encoded form of the hash of the compressed pubkey of a pubkey that used to be non-compressed
520 2011-12-19 18:01:38 <sipa> hence, no-one will ever send to it
521 2011-12-19 18:01:56 <sipa> luke-jr: basically, yes
522 2011-12-19 18:02:48 <sipa> gavinandresen: yet i'm very much in favor of just doing a gradual transition
523 2011-12-19 18:03:41 <gavinandresen> Well, since all the old keypool keys will be uncompressed it sounds like most people won't be using compressed keys... (unless default for new wallets is compressed)
524 2011-12-19 18:04:37 <sipa> any txout that sent to a non-compressed address will require the use of the non-compressed pubkey anyway
525 2011-12-19 18:04:52 <sipa> so the only place where the option to use compressed pubkeys exists, is for newly generated addresses
526 2011-12-19 18:05:22 <BlueMatt> all the cool ideas to optimize the maximum perf we can get out of bitcoin, whereas the poor design of block download and just poor optimization of coding to begin with can give us just as much, if not more speed...
527 2011-12-19 18:05:42 <sipa> by the way, there is a possibility of optimising block download
528 2011-12-19 18:06:03 <sipa> using a bloom filter, many db writes could be avoided
529 2011-12-19 18:06:09 <BlueMatt> yep
530 2011-12-19 18:06:40 <sipa> it's not so trivial, and i'm not sure whether it's worth it (we still need the same amount of db reads, and still need to write new blocks)
531 2011-12-19 18:06:43 <BlueMatt> or disk writes could just be done in another thread so that we dont have to wait on disk writes to verify the next block...
532 2011-12-19 18:06:44 <gavinandresen> sipa:  cool, that sounds like a really great idea.  Anybody working on it?
533 2011-12-19 18:06:53 <sipa> gavinandresen: justmoon, in bitcoin-js :)
534 2011-12-19 18:06:56 <luke-jr> I suspect just dropping fsync would work wonders
535 2011-12-19 18:07:07 <BlueMattBot> Yippie, build fixed!
536 2011-12-19 18:07:08 <BlueMattBot> Project Bitcoin build #137: FIXED in 40 min: http://jenkins.bluematt.me/job/Bitcoin/137/
537 2011-12-19 18:07:09 <BlueMattBot> pieter.wuille: add key.o and rpcdump.o to makefile.linux-mingw
538 2011-12-19 18:07:12 <sipa> o/
539 2011-12-19 18:07:28 <BlueMatt> that is one excited bot...
540 2011-12-19 18:07:44 <luke-jr> BlueMatt: btw, that bot is evil
541 2011-12-19 18:07:46 <gavinandresen> luke-jr: I did some experimenting with that, didn't make a huge difference
542 2011-12-19 18:07:50 <BlueMatt> luke-jr: ?
543 2011-12-19 18:07:58 <BlueMattBot> Available commands:
544 2011-12-19 18:07:58 <luke-jr> BlueMattBot: DONT SPAM the Chan help
545 2011-12-19 18:07:59 <BlueMattBot> alias [<alias> [<command>]] - defines a new alias, deletes one or lists all existing aliases
546 2011-12-19 18:08:00 <BlueMattBot> build <job> [now|<delay>[s|m|h]] [<parameterkey>=<value>]* - schedule a job build, with standard, custom or no quiet period
547 2011-12-19 18:08:01 <BlueMattBot> comment <job> <build-#> <comment> - adds a description to a build
548 2011-12-19 18:08:01 <luke-jr> ^
549 2011-12-19 18:08:02 <BlueMattBot> currentlyBuilding - list jobs which are currently in progress
550 2011-12-19 18:08:03 <BlueMattBot> health [<job>|-v <view>] - show the health of a specific job, jobs in a view or all jobs
551 2011-12-19 18:08:04 <BlueMattBot> q - show the state of the build queue
552 2011-12-19 18:08:05 <BlueMattBot> s [<job>|-v <view>] - show the status of a specific job, jobs in a view or all jobs
553 2011-12-19 18:08:06 <BlueMattBot> status [<job>|-v <view>] - show the status of a specific job, jobs in a view or all jobs
554 2011-12-19 18:08:07 <BlueMattBot> userstat <username> - prints information about a Jenkins user
555 2011-12-19 18:08:08 <BlueMatt> luke-jr: got dammit
556 2011-12-19 18:08:20 <DiabloD3> kickban him
557 2011-12-19 18:08:20 <luke-jr> BlueMatt: wasn't me
558 2011-12-19 18:08:26 <luke-jr> BlueMatt: fix your stupid bot
559 2011-12-19 18:08:30 <DiabloD3> bluematt: also, I want a tshirt that says "got damnit" now
560 2011-12-19 18:09:28 <BlueMatt> luke-jr: https://issues.jenkins-ci.org/browse/JENKINS-10827
561 2011-12-19 18:10:02 <luke-jr> <kutzi> BlueMatt, if you're concerned that the bot might spam a channel, IMO you shouldn't expose the bot in th 1st place <-- wtf?
562 2011-12-19 18:10:44 <luke-jr> BlueMatt: furthermore, the last comment there has a fix
563 2011-12-19 18:11:38 <BlueMatt> wait, they fixed that crap?
564 2011-12-19 18:11:51 <BlueMatt> oh, joy and their stupid bug system didnt email me...wtf?
565 2011-12-19 18:17:55 <luke-jr> lol
566 2011-12-19 18:20:42 <luke-jr> someone stopped mining testnet? :|
567 2011-12-19 18:23:38 <sipa> luke-jr: still have that list of 32-byte version byte prefixes anywhere?
568 2011-12-19 18:23:45 <BlueMatt> luke-jr: hey, not my fault, jenkins didnt even bother to tell me there was an update for the server...
569 2011-12-19 18:23:54 <luke-jr> sipa: no, but I can post a python script&
570 2011-12-19 18:24:24 <luke-jr> http://paste.pocoo.org/show/523192/
571 2011-12-19 18:25:49 <BlueMatt> luke-jr: in other exciting news, the option supposedly committed isnt in my control panel
572 2011-12-19 18:25:55 <sipa> i'll need a format for private keys with compressed pubkeys
573 2011-12-19 18:26:06 <sipa> i consider using a new version byte for those
574 2011-12-19 18:27:46 <luke-jr> >_<
575 2011-12-19 18:28:05 <luke-jr> sipa: why not just insert an extra octet after the version, for irony's sake?
576 2011-12-19 18:28:14 <sipa> luke-jr: that's another possibility indeed
577 2011-12-19 18:35:11 <CIA-100> bitcoin: Luke Dashjr blknotify * rdf4881dd9cf1 bitcoind-personal/src/ (init.cpp main.cpp): Execute a command when best block changes (-blknotify=<cmd>) http://tinyurl.com/d9bwoa5
578 2011-12-19 18:35:31 <luke-jr> jgarzik: ^
579 2011-12-19 18:35:41 <luke-jr> https://github.com/bitcoin/bitcoin/pull/714
580 2011-12-19 18:40:53 <luke-jr> +// Name of client reported in the 'version' message. Report the same name
581 2011-12-19 18:40:54 <luke-jr> +// for both bitcoind and bitcoin-qt, to make it harder for attackers to
582 2011-12-19 18:40:56 <luke-jr> +// target servers or GUI users specifically.
583 2011-12-19 18:40:58 <luke-jr> ^ this is bs -.-
584 2011-12-19 18:41:17 <gmaxwell> ... I don't think it's bullshit.
585 2011-12-19 18:41:28 <gmaxwell> I don't know that it actually matters much though.
586 2011-12-19 18:41:33 <luke-jr> gmaxwell: it defeats the entire purpose of reporting client
587 2011-12-19 18:41:45 <luke-jr> might as well have EVERY client report the same thing for "security"
588 2011-12-19 18:41:46 <BlueMatt> not even close
589 2011-12-19 18:42:03 <BlueMatt> it reports the same since they have the same net/block codebase
590 2011-12-19 18:42:09 <gmaxwell> luke-jr: ther behavior of -qt /d is identicial from the network perspective, save that.
591 2011-12-19 18:42:13 <BlueMatt> thus are as far as other nodes are concerned, identical
592 2011-12-19 18:42:30 <gmaxwell> Other clients could already be detected in more subtle ways.. so hiding it would be pointless and exposing it helps people be smart.
593 2011-12-19 18:42:51 <luke-jr> the version stuff is INTENTIONALLY designed to report both wallet codebase and front-end
594 2011-12-19 18:43:19 <BlueMatt> are there any legitimate reasons why another client should know if you are running -qt or d?
595 2011-12-19 18:43:26 <luke-jr> statistics
596 2011-12-19 18:43:37 <luke-jr> that's the entire purpose of the version field
597 2011-12-19 18:43:43 <gmaxwell> BlueMatt: yes, it lets me know if I'm attacking a soft-and-chewy desktop, vs a hardened but full of cash webservice.
598 2011-12-19 18:43:47 <luke-jr> https://en.bitcoin.it/wiki/BIP_0014
599 2011-12-19 18:44:10 <BlueMatt> luke-jr: thats just plain not true
600 2011-12-19 18:44:40 <luke-jr> there is no other purpose for it
601 2011-12-19 18:44:57 <BlueMatt> uhh...dealing with bugs in other clients?
602 2011-12-19 18:45:02 <gmaxwell> luke-jr: does it help if you think of it as a vendor+version field?
603 2011-12-19 18:45:26 <luke-jr> BlueMatt: that's strictly forbidden
604 2011-12-19 18:45:46 <BlueMatt> Im not gonna argue this
605 2011-12-19 18:46:05 <luke-jr> gmaxwell: this stuff was all put in the spec
606 2011-12-19 18:46:25 <luke-jr> yet another case of "let's ignore the spec everyone worked on, and violate it left and right for our implementation"?
607 2011-12-19 18:47:09 <BlueMatt> or another case of luke-jr writing a stupid "spec" which we deliberately ignore because its stupid
608 2011-12-19 18:47:12 <gmaxwell> bullshit, I didn't get "bitcoind" and "bitcoin-qt" would be different messages in BIP_0014
609 2011-12-19 18:47:21 <luke-jr> BlueMatt: no u
610 2011-12-19 18:47:22 <gmaxwell> They are the _same_ program.
611 2011-12-19 18:47:25 <gmaxwell> They _same_ code.
612 2011-12-19 18:47:31 <luke-jr> gmaxwell: then read it again
613 2011-12-19 18:47:32 <gmaxwell> The _same_ on network behavior.
614 2011-12-19 18:47:36 <gmaxwell> The _same_ releases.
615 2011-12-19 18:47:37 <luke-jr> they are NOT the same program
616 2011-12-19 18:47:45 <gmaxwell> The _same_ developers.
617 2011-12-19 18:47:52 <TD> heh
618 2011-12-19 18:47:57 <TD> facebook has started advertising bitcoin related services to me
619 2011-12-19 18:48:00 <gmaxwell> Where can I download bitcoind without bitcoinqt?
620 2011-12-19 18:48:03 <TD> zuckerberg++
621 2011-12-19 18:48:13 <gmaxwell> TD: facebook itself??
622 2011-12-19 18:48:21 <TD> the ads on the right hand side
623 2011-12-19 18:48:27 <TD> a bitcoin accepting business appeared there
624 2011-12-19 18:48:31 <BlueMatt> heh
625 2011-12-19 18:48:33 <BlueMatt> nice
626 2011-12-19 18:48:34 <luke-jr> BlueMatt: no u
627 2011-12-19 18:48:54 <luke-jr> "Bitcoin user agents are a modified browser user agent with more structure to aid parsers and provide some coherence. In bitcoin, the software usually works like a stack starting from the core code-base up to the end graphical interface. Therefore the user agent strings codify this relationship."
628 2011-12-19 18:49:01 <luke-jr> Example: "/Satoshi:5.64/bitcoin-qt:0.4/"
629 2011-12-19 18:49:21 <gmaxwell> They could.
630 2011-12-19 18:49:25 <gmaxwell> They're not required to.
631 2011-12-19 18:49:57 <luke-jr> "Status: Accepted"
632 2011-12-19 18:50:00 <sipa> luke-jr: if bitcoind and bitcoin-qt are not the same program, it would mean that the version byte would also need to include all compile options (since they select different parts of the source code being compiled in), and possibly compiler version, compilation date, host machine, ... (since they determine which possible bugs in the binary where introduced)
633 2011-12-19 18:50:11 <sipa> s/version byte/version string/
634 2011-12-19 18:50:36 <luke-jr> sipa: the user agent is strictly information, and is not allowed to be use to try to workaround bugs
635 2011-12-19 18:50:40 <gmaxwell> luke-jr: Sure, I don't oppose it being /possible/ to use it that way.
636 2011-12-19 18:50:49 <luke-jr> gmaxwell: the spec says it IS used that way
637 2011-12-19 18:50:50 <sipa> i don't object to putting bitcoin-qt or bitcoind there
638 2011-12-19 18:51:08 <gmaxwell> "In the rare case they may even provide an emergency method of shunning faulty clients that threaten network health- although this is strongly unrecommended and extremely bad form."  < discouraged.
639 2011-12-19 18:51:09 <sipa> but if it's only informational, it's not breaking the spec by hiding information
640 2011-12-19 18:51:27 <luke-jr> gmaxwell: that's shunning, nothing more
641 2011-12-19 18:51:32 <luke-jr> "User agent: simple informational tool. Protocol should not be modified depending on user agent."
642 2011-12-19 18:51:47 <luke-jr> sipa: lying != hiding
643 2011-12-19 18:51:54 <gmaxwell> ...
644 2011-12-19 18:52:12 <BlueMatt> ;;seen wumpus
645 2011-12-19 18:52:12 <luke-jr> iff information needs to be hidden (yay security by obscurity?), the information given should be correct
646 2011-12-19 18:52:13 <gribble> wumpus was last seen in #bitcoin-dev 3 days, 0 hours, and 57 seconds ago: <wumpus> BlueMatt: ok, added a pull request
647 2011-12-19 18:52:18 <luke-jr> ie, /Satoshi:0.6/
648 2011-12-19 18:52:42 <gmaxwell> luke-jr: don't even pull out "security by obscurity", you know thats crap. Security works in layers.
649 2011-12-19 18:52:55 <luke-jr> gmaxwell: hiding versions for "security" is a joke
650 2011-12-19 18:53:09 <BlueMatt> luke-jr: not even close
651 2011-12-19 18:53:25 <gmaxwell> It's not a version, it's an operational mode.
652 2011-12-19 18:54:19 <gmaxwell> Should it also emit the current balance.. (for staistical purposes, of course!)
653 2011-12-19 18:55:21 <gmaxwell> How about a flag to tell if the wallet is encrypted or not that would be a nice statistic to have that would allow us to reason better about sending an alert.
654 2011-12-19 18:55:37 <gmaxwell> (in the eventuality of more wallet crypto bugs... :( )
655 2011-12-19 18:57:09 <gmaxwell> I'm sorry, these are strawmen of course, but so is yelling "security by obscurity".
656 2011-12-19 18:59:22 <sipa> luke-jr: not if you consider from the point "client is allowed to put any version/build information in this field"
657 2011-12-19 19:00:37 <gmaxwell> There are a lot of stats which are more interesting than -qt/d but I'd be very worried about advertising them to all possible attackers.
658 2011-12-19 19:01:00 <gmaxwell> E.g. knowing OS versions, compiler/toolchain, libraries, use of ssl, would all be helpful.
659 2011-12-19 19:07:49 <sipa> can someone fire up his botnet?
660 2011-12-19 19:07:56 <sipa> i don't like waiting for a block on mainnet :)
661 2011-12-19 19:16:05 <gmaxwell> sipa: whats the delay on wallet export? (it's super usable for making reasonably sized backups)
662 2011-12-19 19:20:50 <CIA-100> bitcoin: Gavin Andresen master * rbafb43d / src/bitcoinrpc.cpp : Merge branch 'txn_block_info' of https://github.com/luke-jr/bitcoin - http://git.io/llDFuA https://github.com/bitcoin/bitcoin/commit/bafb43d6c18c1bf7eb1fcc04bed85e45bd03e961
663 2011-12-19 19:23:04 <CIA-100> bitcoin: Gavin Andresen master * r3528650 / (src/init.cpp src/qt/bitcoin.cpp): Merge pull request #690 from runeksvendsen/qt-cmdline-options-parsing ... https://github.com/bitcoin/bitcoin/commit/3528650560a2c417da2303869c743da019defc6d
664 2011-12-19 19:38:07 <genjix> hey tcatm
665 2011-12-19 19:38:28 <genjix> could i have access to post conference videos on bitcoinwatch?
666 2011-12-19 19:38:51 <genjix> also i can post stories from http://bitcoinmedia.com/ if you want too
667 2011-12-19 19:48:44 <luke-jr> genjix: gavinandresen just violated BIP 0014 :P
668 2011-12-19 19:49:08 <gmaxwell> lies.
669 2011-12-19 19:49:43 <gmaxwell> luke-jr: where does BIP0014 say you can't put "box of cocks" in that field?
670 2011-12-19 19:50:03 <gavinandresen> gmaxwell: ooh, good idea....
671 2011-12-19 19:50:41 <gavinandresen> ... and very tempting, but no, I think we'll stick with /bitcoin-qt:0.5.99/ for now
672 2011-12-19 19:50:49 <luke-jr> gavinandresen: that's not compliant.
673 2011-12-19 19:51:18 <sipa> http://blockchain.info/tx-index/13401517/94af4607627535f9b2968bd1fbbf67be101971d682023d6a3b64d8caeb448870?show_adv=yes -> first compressed-key transaction on main net
674 2011-12-19 19:51:38 <luke-jr> it should be /Satoshi:0.5.99/Bitcoin-Qt:0.5.99/ for Bitcoin-Qt and /Satoshi:0.5.99/bitcoind:0.5.99/ for bitcoind
675 2011-12-19 19:52:00 <tcatm> genjix: what's your gpg key?
676 2011-12-19 19:52:49 <luke-jr> or /Satoshi:0.5.99/ if you want to be lame
677 2011-12-19 19:53:04 <gavinandresen> We're being lame and using "bitcoin-qt" to mean "satoshi"
678 2011-12-19 19:53:17 <luke-jr> gavinandresen: that's not just lame, it's in violation :P
679 2011-12-19 19:53:22 <luke-jr> bitcoind is not bitcoin-qt
680 2011-12-19 19:53:40 <gmaxwell> Then perhaps use a domain name there?
681 2011-12-19 19:53:44 <genjix> tcatm: http://privatepaste.com/download/12fba8cc39
682 2011-12-19 19:53:49 <gmaxwell> "bitcoin.org:0.5.99"
683 2011-12-19 19:53:52 <luke-jr> gmaxwell: there's no domain name for the Satoshi codebase
684 2011-12-19 19:53:59 <luke-jr> bitcoin.org is independent
685 2011-12-19 19:54:00 <gmaxwell> there is a domain where you can get it right now.
686 2011-12-19 19:54:10 <luke-jr> gmaxwell: bitcoin.org SHOULD have other clients on it
687 2011-12-19 19:54:19 <genjix> gavinandresen: he does have a point. i could take bitcoin-qt and use it with a different core
688 2011-12-19 19:54:37 <genjix> i was talking before with john about trying libbitcoin with it for example
689 2011-12-19 19:54:45 <gavinandresen> genjix:  ... then don't call that bitcoin-qt, call it something else....
690 2011-12-19 19:54:59 <sipa> ok, a compressed-key transaction was just accepted in a mainnet block
691 2011-12-19 19:55:07 <gmaxwell> How about .. git describe --tags --match 'v*' 2>/dev/null | sed 's/^v//'
692 2011-12-19 19:55:14 <sipa> if there are incompatible miners... they have a problem :)
693 2011-12-19 19:55:18 <gmaxwell> sipa:  now.. what clients just sotpped working?
694 2011-12-19 19:55:24 <genjix> well bitcoin-qt is one code-base, satoshi is another code-base
695 2011-12-19 19:55:31 <genjix> like kernel + libc
696 2011-12-19 19:55:47 <gavinandresen> Can I make sipa the Naming King as well as Version King?
697 2011-12-19 19:55:56 <sipa> please don't
698 2011-12-19 19:56:00 <genjix> :o
699 2011-12-19 19:56:04 <tcatm> genjix: interesting email address in that key ;)
700 2011-12-19 19:56:06 <genjix> <-- viewpoint
701 2011-12-19 19:56:10 <luke-jr> genjix: Bitcoin-Qt is a GUI for the Satoshi codebase (right now)
702 2011-12-19 19:56:30 <genjix> tcatm: genjix@riseup.net? how so?
703 2011-12-19 19:56:37 <gmaxwell> Again: git describe --tags --match 'v*' 2>/dev/null | sed 's/^v//'    < just make it automatically populate that at build time. :
704 2011-12-19 19:56:40 <genjix> luke-jr: yep, i'm agreeing with you
705 2011-12-19 19:56:40 <gmaxwell> :)
706 2011-12-19 19:57:03 <genjix> however whatever. naming wars aren't productive
707 2011-12-19 19:57:06 <luke-jr> https://github.com/bitcoin/bitcoin/pull/715 <-- fix
708 2011-12-19 19:57:19 <gmaxwell> (and use a hook to write it out into a file, so that builds not from git use the static copy from the last checkout)
709 2011-12-19 19:57:33 <genjix> i'll just dislike, but it's not a HUGE deal zomg im gonna cry
710 2011-12-19 19:57:35 <gmaxwell> If bitcoin used automake I'd give a patch for it, since I use that automatic git naming in other stuff.
711 2011-12-19 19:58:25 <sipa> genjix: i'm afraid that bitcoin-qt contains a lot of code that should be in an intermediate layer, to access the wallet
712 2011-12-19 19:58:47 <sipa> genjix: i plan on working on that, but before that it may be hard to put another backend in
713 2011-12-19 19:59:03 <genjix> aha well we have many months :)
714 2011-12-19 19:59:07 <gmaxwell> I do really wish the backend and wallet were seperate programs, esp so you could run multiple wallets against one fullnode, but they aren't and no one is working on them.
715 2011-12-19 19:59:18 <genjix> i like that the checkpoint code is split off now
716 2011-12-19 19:59:19 <luke-jr> sipa: I suspect Bitcoin-Qt actually has its own intermediate layer :P
717 2011-12-19 19:59:23 <sipa> luke-jr: it does
718 2011-12-19 19:59:40 <genjix> i was thinking maybe that's a good point to start sharing code between multiple projects
719 2011-12-19 19:59:40 <sipa> luke-jr: but still, it should access a wallet's abstraction layer, and not wallet code directly
720 2011-12-19 19:59:53 <luke-jr> sipa: yes, that's what the Wallet Protocol was supposed to be
721 2011-12-19 20:00:00 <genjix> bitcoin validation layer- with swig bindings for java, python, javascript
722 2011-12-19 20:00:14 <sipa> luke-jr: then by all means implement it
723 2011-12-19 20:00:14 <tcatm> genjix: http://privatepaste.com/download/bb0dd1f566
724 2011-12-19 20:00:15 <gmaxwell> oy, seperate process please.
725 2011-12-19 20:00:16 <CIA-100> bitcoin: various bugfix_client_name * r2ff55c..01ea41 bitcoind-personal/ (28 files in 4 dirs): (13 commits) http://tinyurl.com/d99qfma
726 2011-12-19 20:00:24 <BlueMatt> did bitcoin-wx autostart minimized?
727 2011-12-19 20:00:25 <sipa> luke-jr: but the first step is separating the code bases
728 2011-12-19 20:00:38 <sipa> luke-jr: which imho has priority
729 2011-12-19 20:00:39 <gmaxwell> which points out another issue.. what happens when you have one bitcoind with three different frontend versions using it?
730 2011-12-19 20:00:43 <luke-jr> BlueMatt: why the rename?
731 2011-12-19 20:00:57 <BlueMatt> luke-jr: what rename?
732 2011-12-19 20:01:04 <luke-jr> BlueMatt: wxBitcoin => bitcoin-wx
733 2011-12-19 20:01:16 <BlueMatt> who the fuck cares what I call it?
734 2011-12-19 20:01:38 <luke-jr> shrug
735 2011-12-19 20:01:47 <luke-jr> j/w
736 2011-12-19 20:02:53 <BlueMatt> anyway, does anyone know if wx client started minimized when autostarting?
737 2011-12-19 20:02:55 <genjix> tcatm: i got your info, but you used an old gpg key of mine
738 2011-12-19 20:03:08 <genjix> might want to delete that
739 2011-12-19 20:03:18 <vsriniva1> BlueMatt: it did not, iirc;
740 2011-12-19 20:03:20 <genjix> C21EA5BC <- new one
741 2011-12-19 20:03:59 <BlueMatt> should the wx one?
742 2011-12-19 20:04:00 <tcatm> genjix: got a revocation certificate?
743 2011-12-19 20:04:14 <genjix> tcatm: nope
744 2011-12-19 20:04:44 <genjix> but its fine since i was able to read your message.
745 2011-12-19 20:04:50 <luke-jr> wumpus: is "About Qt" a bugfix? :P
746 2011-12-19 20:04:56 <BlueMatt> s/wx/qt/
747 2011-12-19 20:05:01 <tcatm> gpg --gen-revoke -u 8561E832
748 2011-12-19 20:05:51 <vsriniva1> luke-jr: wouldn't supporting 0014 in 4.x be a feature addition?;
749 2011-12-19 20:05:59 <luke-jr> vsriniva1: not sure.
750 2011-12-19 20:06:14 <luke-jr> vsriniva1: it could be argued, that BIP 0014 is a protocol change
751 2011-12-19 20:06:30 <genjix> tcatm: http://privatepaste.com/download/5930c19f7a
752 2011-12-19 20:06:33 <sipa> luke-jr: i'd say no
753 2011-12-19 20:06:42 <genjix> tcatm: can i post general news or just conference videos?
754 2011-12-19 20:07:14 <sipa> luke-jr: for statistics purposes, v0.4 still uses network version == client version
755 2011-12-19 20:07:40 <luke-jr> I guess as long as new clients don't start cutting off ones that don't comply with BIP 0014&
756 2011-12-19 20:07:49 <sipa> i hope not
757 2011-12-19 20:08:21 <tcatm> genjix: thanks for the cert. you can post any news but only economical stuff (i.e. things the average bitcoin user might be interested in, not software releases except for the most used clients)
758 2011-12-19 20:08:38 <genjix> ok
759 2011-12-19 20:10:29 <CIA-100> bitcoin: Luke Dashjr 0.5.x * r96c700f5e4b2 bitcoind-stable/src/net.cpp: Merge branch '0.5.0.x' into 0.5.x http://tinyurl.com/7x3pe5z
760 2011-12-19 20:11:55 <luke-jr> tcatm: erm, that's not entirely fair..
761 2011-12-19 20:12:16 <luke-jr> tcatm: "most used" is pretty much determined solely by what is on bitcoin.org
762 2011-12-19 20:13:11 <luke-jr> when someone has a fully functional client, there's no reason it shouldn't be listed too
763 2011-12-19 20:13:32 <sipa> agree
764 2011-12-19 20:14:50 <luke-jr> in fact, Spesmilo *should* probably be on there already.
765 2011-12-19 20:15:03 <tcatm> on bitcoinwatch?
766 2011-12-19 20:15:19 <luke-jr> bitcoin.org
767 2011-12-19 20:16:03 <luke-jr> I guess we're talking about different stuff :p
768 2011-12-19 20:22:25 <genjix> well the software is improving on all sides. with the core systems we have BitcoinJava, libbitcoin and BitcoinJS. with GUIs we have electrum, multibit, safebit, spesmilo, bitcoin-android
769 2011-12-19 20:22:41 <genjix> and multibit has some *really* nice features
770 2011-12-19 20:22:51 <genjix> electrum has a pretty cool design.
771 2011-12-19 20:23:17 <genjix> eventually the pressure will mount, so it isn't a worry :) on software side, i'm confident everything we decentralise into a healthy network
772 2011-12-19 20:24:10 <genjix> right now: Deepbit controls 50% of mining power, mtgox controls 90% of exchange market, and Satoshi client is 95% of all clients. (source for numbers: my ass)
773 2011-12-19 20:24:53 <genjix> Deepbit will lower as mining becomes more professional. Satoshi will lower because installed software is somewhat of a meritocracy
774 2011-12-19 20:25:10 <genjix> mtgox is a worry
775 2011-12-19 20:25:19 <_Fireball> what makes people stick to it?
776 2011-12-19 20:25:34 <genjix> liquidity from their market volume
777 2011-12-19 20:25:39 <gmaxwell> The most important thing to have diversity in, however, is chain validation  which we have none because none of those clients are full nodes  and which 'meritocracy' is less important.
778 2011-12-19 20:25:58 <genjix> gmaxwell: libbitcoin does blockchain validation
779 2011-12-19 20:26:04 <genjix> BitcoinJS too
780 2011-12-19 20:26:19 <_Fireball> so it's a closed loop - noone goes to a new exchange because there is no volume. And there is no volume because noone goes there.
781 2011-12-19 20:26:26 <gmaxwell> I didn't think bitcoinjs did. Is libbitcoin actually usable except for analysis scripts? could I use it to mine?
782 2011-12-19 20:26:28 <genjix> gmaxwell: https://gitorious.org/libbitcoin/libbitcoin/blobs/master/src/validate.cpp
783 2011-12-19 20:26:31 <sipa> exchanges exhibit network effect
784 2011-12-19 20:26:42 <genjix> _Fireball: exactly.
785 2011-12-19 20:26:48 <sipa> genjix: can you verify the full main chain already?
786 2011-12-19 20:26:54 <sipa> with libbitcoin?
787 2011-12-19 20:27:03 <genjix> yes
788 2011-12-19 20:27:12 <sipa> all opcodes implemented?
789 2011-12-19 20:27:24 <genjix> the ones used in the main chain
790 2011-12-19 20:27:31 <sipa> nice :)
791 2011-12-19 20:27:40 <gmaxwell> genjix: it would be really nice to have a hook in bitcoind where it only accepts a block if its also accepted by a sidecar node. Then a miner could concurrently validate with several independant implementations and only follow the chain that passes all of them.
792 2011-12-19 20:28:11 <gmaxwell> genjix: but we can split you by mining some non-standard txn that uses some opcode not currently in the main chain that you don't implement?
793 2011-12-19 20:28:49 <genjix> then i'll add it. haven't added all opcodes because other pressing issues