1 2011-12-22 00:55:20 <Diablo-D3> http://news.ycombinator.com/item?id=3378642
  2 2011-12-22 00:55:22 <Diablo-D3> bitcoin thread!
  3 2011-12-22 01:49:41 <vsrinivas> anyone here have trouble building recent (0.5ish) bitcoin trees from git? in particular, with the lack of __STDC_LIMIT_MACROS in a few files that use C99 macros?
  4 2011-12-22 02:23:11 <luke-jr> vsrinivas: there was a merge this morning of what turned out to be problematic C99-standards-compliance fixes, but that was reverted within hours
  5 2011-12-22 02:29:25 <vsrinivas> ok.
  6 2011-12-22 04:41:34 <finway> Instant transfer with Bitcoin but without 3rd parties http://t.cn/SfpSsw
  7 2011-12-22 04:41:54 <finway> Looks interesting.
  8 2011-12-22 04:49:28 <gmaxwell> finway: 'meh' Perhaps, to make it work it would have to be fairly expensive. There are more efficient ways to do it, e.g. getting a signature from an anti-double-spending authority.
  9 2011-12-22 04:49:52 <gmaxwell> Perhaps it would sound better if it were described as 'creating trust by donating to network security'
 10 2011-12-22 04:50:49 <finway> yeah, exposing address still need third party
 11 2011-12-22 04:51:22 <gmaxwell> as far as the proof-of-treachery goes, that really shouldn't be in the blockchain proper, because only a minority of nodes will care about it and it isn't essential to validating the trustworthyness of the currency as a whole.
 12 2011-12-22 04:51:52 <gmaxwell> but it would be an okay thing for a merged-mining-parallel chain, or something like that.
 13 2011-12-22 04:52:35 <gmaxwell> (a pretty cheap to maintain one)
 14 2011-12-22 04:53:56 <finway> got it
 15 2011-12-22 04:54:32 <gmaxwell> It's ignoring the many other valid charitable causes beyond network security that users could fund in order to make costly addresses.
 16 2011-12-22 04:55:15 <gmaxwell> e.g. say we have more hash power than we need (an unlikely problem&) it would be better if you could make addresses expensive by instead donating to the faucet or archive.org, etc.
 17 2011-12-22 04:59:35 <finway> But that's manipulative
 18 2011-12-22 05:01:03 <gmaxwell> so is funding fees.
 19 2011-12-22 08:18:42 <osmosis> where can I find a changelog for 0.5.1 ?
 20 2011-12-22 08:21:01 <osmosis> found here  http://bitcoin.org/releases/2011/12/15/v0.5.1.html
 21 2011-12-22 08:35:51 <osmosis> in bitcoin-qt , send coins label field seems misleading.
 22 2011-12-22 08:36:37 <osmosis> seems that it should be read-only data and not editable..since the label comes from the addressbook.
 23 2011-12-22 08:49:28 <wumpus> osmosis: well you can edit it; it will change the label of the address... it's meant to  that when sending to a new address, you can label it immediately
 24 2011-12-22 08:50:06 <wumpus> it works the same as bank sites here
 25 2011-12-22 08:50:34 <wumpus> of course, you could make it read only when the address entered is already in the address book
 26 2011-12-22 08:56:59 <osmosis> wumpus, ok. i see the purpose now.  Perhaps a dialog box about changing the label if the label is modified would be appropriate.
 27 2011-12-22 08:57:41 <wumpus> yeah, do send a pull :)
 28 2011-12-22 10:15:12 <Eliel> this is an interesting proposal http://vermorel.com/journal/2011/12/20/instant-transfer-with-bitcoin-but-without-3rd-parties.html
 29 2011-12-22 10:15:50 <Eliel> however, for small amounts, I doubt even that's needed.
 30 2011-12-22 10:42:35 <CIA-100> bitcoinjs/node-bitcoin-p2p: Stefan Thomas master * r41a7220 / (3 files in 3 dirs): Some housekeeping. - http://git.io/ga5I6A https://github.com/bitcoinjs/node-bitcoin-p2p/commit/41a7220fcd2e03855e4c38e9baad42fe48b3c1de
 31 2011-12-22 14:12:29 <Diablo-D3> ;;ticker
 32 2011-12-22 14:12:30 <gribble> Best bid: 3.73977, Best ask: 3.73979, Bid-ask spread: 2.00000000001e-05, Last trade: 3.73977, 24 hour volume: 59543, 24 hour low: 3.509, 24 hour high: 4.00999
 33 2011-12-22 14:12:37 <[Tycho]> Are there any OP_CHECKMULTISIG TXes in testnet or main net ?
 34 2011-12-22 14:12:40 <Diablo-D3> ;;calc 3.54 * 3.73
 35 2011-12-22 14:12:40 <gribble> 13.2042
 36 2011-12-22 14:39:55 <[Tycho]> why scriptsig is not decoded here ? http://blockexplorer.com/testnet/tx/f5eb769eff73a4781b600064ac16dff54e039994e7dedb77903a19b5edec1fc7
 37 2011-12-22 14:42:16 <lianj> decoded in what?
 38 2011-12-22 14:42:54 <lianj> in OP_0 ?
 39 2011-12-22 14:44:09 <phantomcircuit> [Tycho], i think it gives up when the script is weird
 40 2011-12-22 14:45:57 <lianj> no, the 0 is not data, its just the OP_0
 41 2011-12-22 14:47:14 <[Tycho]> Previous script is redeemed, so it was valid.
 42 2011-12-22 14:47:19 <[Tycho]> But not decoded by BBE
 43 2011-12-22 14:48:04 <lianj> it is decoded.
 44 2011-12-22 14:48:50 <lianj> just that bbe decodes the opcodes OP_0 and OP_2-16 as 0 and 2-16
 45 2011-12-22 14:50:19 <[Tycho]> What's the point of that script then ?
 46 2011-12-22 14:53:04 <lianj> http://paste.pocoo.org/show/hZqP7MhGlRIa5j8XEBkT/
 47 2011-12-22 14:55:32 <lianj> http://paste.pocoo.org/show/prdQmAlT8SDu26FraVGW/
 48 2011-12-22 14:55:35 <gavinandresen> [Tycho]: why the 0 in the scriptSig?  Because there is a bug in CHECKMULTISIG -- it pops one too many items off the stack
 49 2011-12-22 14:57:47 <gavinandresen> (so to work around that bug, my code adds an extra OP_0 byte to all multisignature signatures)
 50 2011-12-22 14:57:58 <[Tycho]> lianj: why "done" ?
 51 2011-12-22 14:58:16 <[Tycho]> gavinandresen: it's too late to fix it ?
 52 2011-12-22 14:58:50 <[Tycho]> gavinandresen: also, why OP_EVAL instead of real CHECKMULTISIG ?
 53 2011-12-22 14:59:30 <[Tycho]> I saw "OP_SMALLINTEGER << OP_PUBKEYS << OP_SMALLINTEGER << OP_CHECKMULTISIG" template mentioned in source. Will it work ?
 54 2011-12-22 14:59:45 <gavinandresen> Yes
 55 2011-12-22 15:00:01 <gavinandresen> ... but I didn't write a RPC method that will generate non-OP_EVAL multisig transactions
 56 2011-12-22 15:00:11 <[eval]> gavinandresen: will the bug be fixed before 0.6 is released?
 57 2011-12-22 15:00:13 <[Tycho]> Cool.
 58 2011-12-22 15:01:25 <gavinandresen> RE: fixing the CHECKMULTISIG bug:  let me think about it for a bit, I THINK it would be safe to fix it for new clients, but until the entire network upgrades an extra OP_0 should still be added to signatures
 59 2011-12-22 15:01:48 <[eval]> gavinandresen: so the final code will have to work whether or not there's an extra OP_0 in it?
 60 2011-12-22 15:01:56 <gavinandresen> Just fixing CHECKMULTISIG if it is 'inside' an OP_EVAL would be safe, but that's ugly so I don't want to do it.
 61 2011-12-22 15:02:33 <gavinandresen> The code already works if there is extra stuff at the beginning of a scriptSig.  It is just ignored.
 62 2011-12-22 15:02:47 <[eval]> ok
 63 2011-12-22 15:02:50 <gavinandresen> ... that's part of why OP_EVAL is backwards-compatible with old clients
 64 2011-12-22 15:03:24 <gavinandresen> (they see <signatures> <op_eval_stuff>, check to see if the <op_eval_stuff> is FALSE (it never is), and then just ignore the extra <signatures>)
 65 2011-12-22 15:03:28 <[eval]> i'm pretty excited about this... i'm running git HEAD now and loving the new features :> thanks for everything you've been doing!
 66 2011-12-22 15:03:57 <[eval]> (bitcoind only)
 67 2011-12-22 15:04:09 <gavinandresen> Great!  Please try hard to break it....
 68 2011-12-22 15:04:56 <[Tycho]> Pull 669 description looks incorrect...
 69 2011-12-22 15:05:42 <gavinandresen> which part?  I'll fix....
 70 2011-12-22 15:06:02 <[Tycho]> It says "if you own all the public keys of a multisignature transaction, then you are able to spend"
 71 2011-12-22 15:06:09 <[Tycho]> But that should be private keys
 72 2011-12-22 15:06:26 <gavinandresen> thanks, fixed
 73 2011-12-22 15:06:35 <[Tycho]> Also it says ./bitcoind addmultisigaddress 2 '["...public_key_1...","...public_key_2..."]
 74 2011-12-22 15:06:41 <[Tycho]> And addmultisigaddress <'["key","key"]'>
 75 2011-12-22 15:06:54 <[Tycho]> Is that "2" parameter skipped ?
 76 2011-12-22 15:07:47 <[Tycho]> Should be more clear to use ["key1", ... ], otherwise looks like 2 and only 2 keys are supported.
 77 2011-12-22 15:08:04 <BitMark> did 0.5.1 include the rpcssl fix?
 78 2011-12-22 15:08:07 <[eval]> and specify whether that key is public or private please
 79 2011-12-22 15:08:22 <gavinandresen> hmm, the source is addmultisigaddress <nrequired> <'["key","key"]'> [account]
 80 2011-12-22 15:08:23 <[eval]> in the help for the RPC
 81 2011-12-22 15:08:30 <gavinandresen> markdown is doing something funny....
 82 2011-12-22 15:08:58 <[Tycho]> gavinandresen: so the nrequired is missing then.
 83 2011-12-22 15:09:12 <gavinandresen> yes, have to figure out how to get github markdown not to do funky things with <>
 84 2011-12-22 15:09:36 <[Tycho]> Oh, so "markdown" was not a nickname :)
 85 2011-12-22 15:09:49 <gavinandresen> http://github.github.com/github-flavored-markdown/
 86 2011-12-22 15:11:06 <lianj> gavinandresen: whats the meaning of OP_NOP1 now, not a reserved word anymore?
 87 2011-12-22 15:11:12 <gavinandresen> &lt; and &gt; works
 88 2011-12-22 15:11:23 <gavinandresen> lianj: OP_NOP1 is being redefined to mean OP_EVAL
 89 2011-12-22 15:11:43 <gavinandresen> See BIP 12 for details....
 90 2011-12-22 15:11:59 <lianj> ah, now the backlog about eval makes sense though :>
 91 2011-12-22 15:12:17 <lianj> maybe it should be mentioned on the wiki
 92 2011-12-22 15:12:29 <[eval]> actually nm, the help specifies what keys to put in... awesome
 93 2011-12-22 15:12:45 <[eval]> gonna play with it a little when i have a chance
 94 2011-12-22 15:13:12 <lianj> [Tycho]: then ofc its not 'done' there. sorry
 95 2011-12-22 15:13:30 <gavinandresen> lianj: good idea
 96 2011-12-22 15:14:09 <[eval]> woah
 97 2011-12-22 15:14:17 <[Tycho]> So that script is posted as string in scriptsig ? Or as script ?
 98 2011-12-22 15:14:57 <[eval]> i just noticed an imbalance in my balances, gavinandresen
 99 2011-12-22 15:15:01 <jgarzik> the balance remains correct in getinfo
100 2011-12-22 15:15:16 <[eval]> alex@John-Galt:~/bitcoin/src$ ./bitcoind getbalance
101 2011-12-22 15:15:17 <[eval]> 205.59089360
102 2011-12-22 15:15:23 <jgarzik> unfortunately, since it was so few bitcoins, I don't have a pre-0.59999 wallet backup
103 2011-12-22 15:16:00 <gavinandresen> jgarzik: can you run it against an old binary and get a diff of the listtransactions output?
104 2011-12-22 15:17:09 <[Tycho]> gavinandresen: what is the expected format for public keys in addmultisigaddress command ?
105 2011-12-22 15:17:17 <[eval]> the accounts show up correctly in 0.5.1
106 2011-12-22 15:17:29 <jgarzik> gavinandresen: yeah, 0.5.1 worked for me
107 2011-12-22 15:17:31 <[eval]> { "" : 199.72903839, "FEES" : 0.00000000, "SAVINGS" : 5.86185521
108 2011-12-22 15:17:31 <gavinandresen> Tycho:  either hex or base58 (same formats output by the validateaddress extension)
109 2011-12-22 15:17:34 <jgarzik> gavinandresen: I'll see...
110 2011-12-22 15:17:47 <[Tycho]> validateaddress outputs both ?
111 2011-12-22 15:17:52 <gavinandresen> yes
112 2011-12-22 15:18:03 <jgarzik> gavinandresen: spends disappeared from listtransactions, but receives still appear
113 2011-12-22 15:19:21 <gavinandresen> jgarzik: d'oh!  sounds like definitely a bug...
114 2011-12-22 15:23:57 <[eval]> gavinandresen: i don't see my sends OR moves in 0.5.1 OR in git HEAD but i see the correct balances for accounts in 0.5.1 but not in git HEAD (that SAVINGS account has too many coins and it doesn't end up balancing correctly)
115 2011-12-22 15:24:37 <[eval]> and on that note, i have to dip out for a bit
116 2011-12-22 15:26:41 <BitMark> error: -rpcssl=1, but bitcoin compiled without full openssl libraries.
117 2011-12-22 15:27:09 <gavinandresen> BitMark: version 0.5?  That bug was fixed in 0.5.1
118 2011-12-22 15:27:18 <BitMark> running 0.5.1
119 2011-12-22 15:27:43 <gavinandresen> grumble grumble.....
120 2011-12-22 15:28:02 <gavinandresen> BitMark: what platform?
121 2011-12-22 15:28:10 <BitMark> linux
122 2011-12-22 15:28:12 <BitMark> Bitcoin version 0.5.1-beta
123 2011-12-22 15:28:42 <gavinandresen> This is why we need dedicated QA testers
124 2011-12-22 15:28:52 <BitMark> i saw you merged and closed https://github.com/bitcoin/bitcoin/pull/687
125 2011-12-22 15:29:32 <BitMark> would the build log have a clue?
126 2011-12-22 15:29:46 <helo> anyone know of a good micropayment system we could use to motivate dedicated testers?
127 2011-12-22 15:29:53 <rjk2> bitcoin?
128 2011-12-22 15:30:06 <BitMark> its entirely possible i am doing something wrong
129 2011-12-22 15:30:42 <gavinandresen> BitMark: More likely you're the first person to actually test to see if the fix actually fixed the problem
130 2011-12-22 15:32:06 <BitMark> i think i heard mention about the possibility of actually hiring a QA person
131 2011-12-22 15:32:12 <BitMark> ?
132 2011-12-22 15:33:05 <gavinandresen> Alex Waters was being paid to do QA, but then TruCoin (the company doing the funding) did the typical startup thing and ran into funding issues of their own....
133 2011-12-22 15:33:38 <BitMark> ah
134 2011-12-22 15:34:48 <BitMark> would QA bounties work?
135 2011-12-22 15:35:05 <gavinandresen> BitMark: can you open an issue on github?  I'm busy tracking down the listtransactions issue...
136 2011-12-22 15:35:17 <BitMark> roger willco
137 2011-12-22 15:35:24 <finway> ;;ticker
138 2011-12-22 15:35:25 <gribble> Best bid: 3.846, Best ask: 3.8477, Bid-ask spread: 0.0017, Last trade: 3.846, 24 hour volume: 60391, 24 hour low: 3.509, 24 hour high: 3.99199
139 2011-12-22 15:40:07 <BitMark> https://github.com/bitcoin/bitcoin/issues/722
140 2011-12-22 15:41:35 <jgarzik> gavinandresen: built.  starting -rescan...  will file an issue if this works
141 2011-12-22 15:42:36 <gavinandresen> jgarzik: thanks. I built a 0.4 bitcoind, and am trying to reproduce the issue
142 2011-12-22 15:48:27 <jgarzik> gavinandresen: issue reproduced
143 2011-12-22 15:48:38 <gavinandresen> jgarzik: yup, here, too....
144 2011-12-22 15:48:38 <jgarzik> gavinandresen: something definitely wrong post-0.5.1
145 2011-12-22 15:49:00 <jgarzik> gavinandresen: so 0.5.1 WFM, git HEAD fails
146 2011-12-22 16:02:31 <jgarzik> gavinandresen: opening issue...
147 2011-12-22 16:03:05 <Uber> Has anyone played with the idea of bitcoin HFT/Algo trading?
148 2011-12-22 16:03:16 <jgarzik> Uber: yes
149 2011-12-22 16:04:18 <Uber> did you find that there was arbitrage? or did you lose out with the recent collapse in ES?
150 2011-12-22 16:04:33 <jgarzik> Uber: I didn't say it was me :)
151 2011-12-22 16:04:46 <jgarzik> Uber: HFT has been discussed on the forums.  TD[gone] mentioned that Satoshi had some ideas, too.
152 2011-12-22 16:05:35 <finway> I want to help testing, is there a complie-howto?
153 2011-12-22 16:06:27 <Uber> Ya i've read what little there is on the forums... I have a degree in finance with an emphasis in derivatives with International Business minor.
154 2011-12-22 16:07:09 <Uber> looking at the volume of the bitcoins shows how easy the market can be manipulated
155 2011-12-22 16:07:15 <Uber> just check out nanex.com
156 2011-12-22 16:07:37 <Uber> they provide analysis of HFT algos with real stocks
157 2011-12-22 16:08:00 <Uber> the volume they are pushing is in the millions, the volume of bitcoins being transacted is the hundreds of dollars
158 2011-12-22 16:08:46 <Uber> http://www.nanex.net/*
159 2011-12-22 16:12:03 <sipa> jgarzik, gavinandresen: already figured out which commit broke it?
160 2011-12-22 16:12:38 <gavinandresen> sipa: nope
161 2011-12-22 16:13:16 <gavinandresen> sipa: I thought it might be your change to AddToWalletIfInvolvingMe.... but I'm changing my mind....
162 2011-12-22 16:14:27 <sipa> if balances remain intact, i don't think the actual list of transactions in the wallet changed
163 2011-12-22 16:16:17 <gavinandresen> I've got some transaction ids for a test wallet that aren't being assigned to the correct account, about to fire up a debugger to figure out why...
164 2011-12-22 16:16:23 <gmaxwell> Uber: you might find more willing discussion about markets in #bitcoin  the focus here is on the development of the bitcoin software itself, the bitcoin distributed algorithim, and the bitcoin network protocol(s).
165 2011-12-22 16:16:36 <jgarzik> sipa: yes, it is possible that this is just a listtransactions (display) issue
166 2011-12-22 16:17:12 <jgarzik> Uber: yes, bitcoin market is tiny, and therefore easily manipulated
167 2011-12-22 16:17:22 <jgarzik> Uber: just like penny stocks or any other tiny market
168 2011-12-22 16:17:31 <Uber> exactly, super light trading volume
169 2011-12-22 16:17:43 <Uber> gmaxwell: thanks for the advice
170 2011-12-22 16:17:57 <Uber> jbarzik: thanks too
171 2011-12-22 16:21:31 <sipa> gavinandresen, jgarzik: having IsChange() report true in too many cases would explain the symptom
172 2011-12-22 16:21:40 <sipa> (just a wild guess)
173 2011-12-22 16:22:08 <gavinandresen> ... I fixed that bug last week...  I think....
174 2011-12-22 16:22:30 <sipa> not that IsChange() looks wrong to me, but i didn't test anything now
175 2011-12-22 16:22:40 <gavinandresen> And that doesn't explain why I'm seeing a transaction assigned to account "from2" in 0.4, but "" in HEAD
176 2011-12-22 16:22:53 <sipa> indeed
177 2011-12-22 16:27:37 <gmaxwell> was the wallet that lost data encrypted?
178 2011-12-22 16:27:43 <gmaxwell> (e.g. is the resilvering causing this)
179 2011-12-22 16:28:18 <sipa> resilvering didn't change between 0.5.1 and HEAD
180 2011-12-22 16:28:32 <gavinandresen> no, my test wallet is unencrypted
181 2011-12-22 16:28:35 <gmaxwell> oh sorry, I'm LIFOing the discussion.
182 2011-12-22 16:37:31 <[Tycho]> Uber: ICBIT is planned to support HFT.
183 2011-12-22 16:42:21 <gavinandresen> sipa: I think the bug is happening as the wallet is loaded; getting a wtx.strFromAccount = "" when it should be another account (down deep in db.cpp LoadWallet
184 2011-12-22 16:42:45 <sipa> eww
185 2011-12-22 16:54:19 <gavinandresen> ... leading suspect is now separation of CLIENT_VERSION from PROTOCOL_VERSION....
186 2011-12-22 16:54:49 <luke-jr> except they're the same right now, aren't they?
187 2011-12-22 16:55:02 <gavinandresen> Nope, PROTOCOL_VERSION is 0.6, CLIENT_VERSION is 0.5.99
188 2011-12-22 16:55:06 <luke-jr> bisect?
189 2011-12-22 16:55:11 <gavinandresen> I did that on purpose to try to shake out bugs....
190 2011-12-22 16:55:19 <luke-jr> oh, yeah, that *would* make it likely that
191 2011-12-22 17:04:43 <sipa> gavinandresen: how could version values influence how transactions are counted?
192 2011-12-22 17:05:15 <gavinandresen> They don't...
193 2011-12-22 17:05:47 <gavinandresen> I just thought maybe there was some conditional "if version < something" code that affected wallet deserialization
194 2011-12-22 17:06:32 <gavinandresen> There's definitely something funky going on with wallet deserialization
195 2011-12-22 17:08:30 <gavinandresen> Anybody understand deeply how GetSerializeSize() works?  Leading suspect is now the added private CWallet* pointer in CWalletTx....
196 2011-12-22 17:09:41 <sipa> if CWalletTx's IMPLEMENT_SERIALIZE didn't change, GetSerialSize() shouldn't change either
197 2011-12-22 17:11:15 <gavinandresen> mmmm.... 1:11, time to eat lunch and think on this a bit
198 2011-12-22 17:11:54 <luke-jr> gavinandresen: you're not using stdint still, are you?
199 2011-12-22 17:12:06 <gavinandresen> luke-jr: nope
200 2011-12-22 17:27:06 <jgarzik> gavinandresen: back from lunch.  running git bisect.
201 2011-12-22 17:35:26 <jgarzik> 'git bisect run $cmd' is fun
202 2011-12-22 17:43:48 <gavinandresen> $cmd is "run bitcoind -daemon, wait a while for it to startup, then listtransactions and grep for the missing one?"
203 2011-12-22 17:45:13 <gavinandresen> tree at commit fc9096 is good...
204 2011-12-22 17:53:27 <gavinandresen> tree at 99a289 is good...
205 2011-12-22 18:00:37 <jgarzik> gavinandresen: one more bisect and I've got a winner
206 2011-12-22 18:00:54 <gavinandresen> jgarzik: excellent!
207 2011-12-22 18:01:43 <heinz`> anyone have issues with 0.5.0 and 0.5.1 crashing on win7 when it tries to update
208 2011-12-22 18:02:18 <heinz`> 0.4.0 is fine
209 2011-12-22 18:04:38 <luke-jr> heinz`: 0.4.2 ?
210 2011-12-22 18:05:06 <heinz`> didn't see that one to d/l 0.4.0
211 2011-12-22 18:05:10 <heinz`> i'll try that one now
212 2011-12-22 18:05:44 <luke-jr> I don't think anyone's made binaries for Windows
213 2011-12-22 18:05:49 <luke-jr> just 0.4.1
214 2011-12-22 18:05:51 <heinz`> i see 0.4.1
215 2011-12-22 18:05:54 <heinz`> i'll try that one
216 2011-12-22 18:06:06 <gavinandresen> jgarzik: 9e4705 ?
217 2011-12-22 18:06:34 <jgarzik> still compiling
218 2011-12-22 18:09:58 <heinz`> 0.4.1 is fine as well
219 2011-12-22 18:09:59 <heinz`> odd
220 2011-12-22 18:10:57 <jgarzik> commit e679ec969c8b22c676ebb10bea1038f6c8f13b33
221 2011-12-22 18:11:00 <jgarzik> gavinandresen: ^^
222 2011-12-22 18:11:22 <jgarzik> e679ec969c8b22c676ebb10bea1038f6c8f13b33 is the first bad commit
223 2011-12-22 18:11:27 <luke-jr> heinz`: how about 0.5.0rc1 ?
224 2011-12-22 18:12:24 <gavinandresen> jgarzik: yes, that would be bad until commit be237c
225 2011-12-22 18:12:44 <gavinandresen> ... and then it gets bad again at the very-next commit, where the testnet default ADDRESSVERSION changes...  I think.
226 2011-12-22 18:12:51 <luke-jr> gavinandresen: what happened to the 0.5.0rc bins?
227 2011-12-22 18:13:16 <gavinandresen> luke-jr: I imagine they got removed when I removed the test/ sub-folder
228 2011-12-22 18:14:16 <gavinandresen> jgarzik: ... although there may be multiple bugs here.  Is your test wallet main-net or testnet?
229 2011-12-22 18:14:24 <heinz`> luke-jr you wouldn't happen to have a link for that one would you?
230 2011-12-22 18:15:12 <jgarzik> gavinandresen: test wallet?  bah!  testing with real wallet on mainnet ;)
231 2011-12-22 18:15:16 <luke-jr> gavinandresen: how nice, I guess Windows users can't bisect even a little :P
232 2011-12-22 18:15:52 <gavinandresen> jgarzik: can you see if your problem is fixed by be237c  ?
233 2011-12-22 18:16:13 <jgarzik> gavinandresen: starting with what top-of-tree?
234 2011-12-22 18:16:54 <gavinandresen> uhh... I mean git checkout b2337c   and test
235 2011-12-22 18:17:02 <gavinandresen> be237c
236 2011-12-22 18:30:25 <gavinandresen> Ok, bug number 1 is testnet-only, due to changing the ADDRESSVERSION from 111 to 192, it causes transactions to be assigned to the wrong accounts.  Bug number 2, 'sends' missing from listtransactions, I'm still looking for.
237 2011-12-22 18:34:09 <jgarzik> gavinandresen: be237c is confirmed broken
238 2011-12-22 18:34:15 <gavinandresen> jgarzik: thanks
239 2011-12-22 18:36:56 <cj> okay, how do I build the .deb again?
240 2011-12-22 18:37:40 <jgarzik> gavinandresen: definitely looks like OP_EVAL patch here.  I wonder if IsMine changed somehow.
241 2011-12-22 18:38:37 <gavinandresen> IsMine uses ExtractAddress, which DID definitely change....
242 2011-12-22 18:41:21 <[Tycho]> Is there any roadmap that mentions required feature set for 0.6-1.0 versions ?
243 2011-12-22 18:41:34 <gavinandresen> ... but from my debugging the problem looks like when the wallet is loaded.
244 2011-12-22 18:45:33 <luke-jr> gavinandresen: are accounts associated with addresses, rather than pubkeys? O.o
245 2011-12-22 18:50:35 <sipa> luke-jr: addresses correspond to txout scripts, and it is using those that you 'receive' coins
246 2011-12-22 18:51:14 <luke-jr> sipa: yes, I know.
247 2011-12-22 18:51:41 <sipa> so it seems right to me that a group of such addresses is combined into an account
248 2011-12-22 18:51:53 <luke-jr> sipa: doesn't work with the address version change ;)
249 2011-12-22 18:53:05 <sipa> testnet = don't care
250 2011-12-22 18:53:10 <luke-jr> :P
251 2011-12-22 18:53:29 <sipa> you can temporarily do a conversion at load time
252 2011-12-22 18:53:36 <sipa> so both old and new forms of an address are loaded
253 2011-12-22 18:54:16 <gavinandresen> if testnet == don't care, then we should just keep testnet address == 111.......
254 2011-12-22 18:55:25 <sipa> gavinandresen: i though the version would only change at the next reset
255 2011-12-22 18:55:39 <sipa> but that's maybe hard to implement
256 2011-12-22 19:11:28 <gavinandresen> ok, I'm an idiot.  And gdb sucks....
257 2011-12-22 19:12:28 <luke-jr> O.o
258 2011-12-22 19:13:15 <luke-jr> jk :P
259 2011-12-22 19:13:49 <gavinandresen> Bug is in the OP_EVAL ExtractAddress, which really should be named ExtractAddress_but_only_if_it_is_in_the_keystore_if_you_pass_in_a_non_null_keystore
260 2011-12-22 19:14:50 <sipa> gavinandresen: i should have added a comment about that...
261 2011-12-22 19:14:54 <luke-jr> >_<
262 2011-12-22 19:15:17 <gavinandresen> ... and I should have noticed my new version made the keystore param unused
263 2011-12-22 19:16:05 <[Tycho]> Something to worry about ?
264 2011-12-22 19:16:09 <luke-jr> always nice to catch bugs before RCs though
265 2011-12-22 19:16:22 <luke-jr> [Tycho]: not on the pool side of things I think
266 2011-12-22 19:16:28 <gavinandresen> Yes, that's why I'm trying to pull the big scary changes early.
267 2011-12-22 19:16:45 <[Tycho]> I wanted to implement 3* addresses support :)
268 2011-12-22 19:17:00 <gavinandresen> And right, this doesn't affect the backports
269 2011-12-22 19:17:51 <[Tycho]> But I didn't wanted to implement that bitcoinaddress class..
270 2011-12-22 19:18:02 <sipa> why not?
271 2011-12-22 19:18:21 <[Tycho]> This would require many changes.
272 2011-12-22 19:20:03 <gavinandresen> Refactoring:  ExtractAddress() will only extract addresses, I'll modify the code that calls it with a keystore arg to check to see if the address is in the keystore if it needs to care....
273 2011-12-22 19:36:33 <sipa> gavinandresen: idea was that if you had a txout with multiple alternative (combinations of) keys/addresses, that it would in the general case just return one, but in case of an own payment, use he key that you own
274 2011-12-22 19:37:50 <luke-jr> http://en.wikipedia.org/wiki/C++11#Generalized_constant_expressions <--  does this imply C++11 doesn't support non-const array sizes? :|
275 2011-12-22 19:38:56 <gmaxwell> luke-jr: yea, C++ the standard doesn't have vararray.
276 2011-12-22 19:39:05 <luke-jr> gmaxwell: but not even C++11 ?
277 2011-12-22 19:39:07 <luke-jr> wtf?
278 2011-12-22 19:39:09 <gmaxwell> Worse, they just removed it from a mandatory feature of C99 because MSFT wouldn't implement it.
279 2011-12-22 19:39:29 <luke-jr> how can they change C99 after 99?
280 2011-12-22 19:39:51 <gmaxwell> (and because of some crazy pedantry about misuse of it making it impossible to reason about peak stack usage to which I say, don't misuse it)
281 2011-12-22 19:41:35 <gavinandresen> sipa: replacing ExtractAddress(...pwallet,address) with ExtractAddress...address) && pwallet->HaveKey(address) makes sense to me, and is safe.  When we support funky "this or that" transactions then we can revisit to figure out what needs to be done....
282 2011-12-22 19:42:31 <gavinandresen> Probably we want another method that uses ExtractAddresses and returns all the addresses that belong to me.  Or that I know how to get a private key for....
283 2011-12-22 19:42:41 <gavinandresen> ... or a signature...
284 2011-12-22 19:43:27 <sipa> gavinandresen: agree
285 2011-12-22 19:50:07 <CIA-100> bitcoin: Daniel Folkinshteyn * r5d816a5f38c4 supybot-bitcoin-marketmonitor/OTCWebsite/viewratings.php: OTCWebsite: improve description of first rating date http://tinyurl.com/6omuu4k
286 2011-12-22 19:54:47 <gavinandresen> sipa: can you do a quick review, make sure I'm not being an idiot again?  https://github.com/gavinandresen/bitcoin-git/commit/c78846899de77527109b61665112ce9b36f6fd85
287 2011-12-22 19:56:12 <sipa> looks good at first sight
288 2011-12-22 19:57:25 <gavinandresen> ... fixes listtransactions....
289 2011-12-22 19:58:54 <gavinandresen> Does anybody here use Eclipse on the Mac to work with C++ code?  I'm wondering if it would be any better at showing me the contents of a std::vector<std::pair<std::string,std::string>>> than gdb is....
290 2011-12-22 19:59:45 <CIA-100> bitcoin: Gavin Andresen master * rce336fd / src/base58.h : Back out testnet default address change, it breaks accounts on old wallets. - http://git.io/3boqNQ https://github.com/bitcoin/bitcoin/commit/ce336fdc21c25c055ffef28fbe7c61164df7ca24
291 2011-12-22 19:59:50 <CIA-100> bitcoin: Gavin Andresen master * r2e17ac8 / (7 files in 3 dirs): Fix broken ExtractAddress (refactored, made callers check for addresses in keystore if they care) - http://git.io/uZL7KQ https://github.com/bitcoin/bitcoin/commit/2e17ac83c65b65fe2037b8c8941c25e288905903
292 2011-12-22 20:06:34 <macintosh264> Excuse me. I am looking for other admins on the #bitcoin chanel. I have been baned for incorrect perception of what I am trying to say. It is revelant to bitcoin, so I can say it.
293 2011-12-22 20:10:20 <[Tycho]> :)
294 2011-12-22 20:13:33 <gavinandresen> ok, i may have to amend 'gdb sucks', to "gdb-versions-prior-to-7 suck"... (learning about writing extensions in python.... mmmmm, python.....)
295 2011-12-22 20:23:31 <mcorlett> Where on the roadmap is URI integration ?? la "bitcoin:address"?
296 2011-12-22 20:23:48 <mcorlett> I know Spesmilo already has it.
297 2011-12-22 20:24:42 <luke-jr> mcorlett: Bitcoin-Qt refuses to implement compliant URI support.
298 2011-12-22 20:24:52 <luke-jr> mcorlett: non-compliant URI support is on the table for 0.6
299 2011-12-22 20:26:20 <mcorlett> luke-jr: What does "on the table" mean?
300 2011-12-22 20:26:31 <luke-jr> mcorlett: I think it's pretty likely that it will be merged
301 2011-12-22 20:26:35 <jgarzik> gavinandresen: git HEAD has fixed my issue
302 2011-12-22 20:27:02 <gavinandresen> jgarzik: great.
303 2011-12-22 20:27:18 <mcorlett> luke-jr: Great. Does "non-compliant" mean that it's not cross-compatible with different operating systems?
304 2011-12-22 20:27:31 <gavinandresen> non-compliance means it doesn't do everything luke-jr wants it to do
305 2011-12-22 20:27:33 <luke-jr> mcorlett: no, it means it only works on some URIs
306 2011-12-22 20:27:52 <gavinandresen> (the rest of us are tired of arguing with him, so we're just ignoring the features we don't like)
307 2011-12-22 20:28:28 <mcorlett> I see. I've read the URI article on the Wiki. What's getting scrapped, exactly?
308 2011-12-22 20:28:53 <luke-jr> mcorlett: specifically, Bitcoin-Qt only works with URIs that specify amounts in BTC units
309 2011-12-22 20:29:52 <gavinandresen> .. yeah, the whole X/x/whatever for amounts thing.
310 2011-12-22 20:30:46 <sipa> i'd like to introduce base-phi amounts to the spec
311 2011-12-22 20:31:30 <sipa> http://en.m.wikipedia.org/wiki/Golden_ratio_base
312 2011-12-22 20:31:50 <gavinandresen> good idea.  phi-characters are legal in URIs, right?
313 2011-12-22 20:31:57 <luke-jr> sipa: you don't need to troll too
314 2011-12-22 20:32:06 <gavinandresen> ... if not, we can punycode them....
315 2011-12-22 20:32:40 <gavinandresen> luke, we're just tired of you being too stubborn to bend when consensus is that the uri scheme as implemented is Just Fine.
316 2011-12-22 20:33:01 <luke-jr> gavinandresen: as implemented where?
317 2011-12-22 20:33:09 <gavinandresen> ... perfect as the enemy of the good and all that...
318 2011-12-22 20:33:11 <luke-jr> gavinandresen: you're the last client to implement it, and the only one to break compliance
319 2011-12-22 20:33:20 <luke-jr> gavinandresen: perfect is only the enemy of the good when the good suffers
320 2011-12-22 20:33:35 <luke-jr> whcih is not the case here
321 2011-12-22 20:33:44 <gavinandresen> ok, I'm going to be quiet again, like I said I'm tired of arguing
322 2011-12-22 20:34:27 <luke-jr> the URI scheme as implemented, is the same as specified by community consensus early 2011 on the wiki, with future-compatibility for other units.
323 2011-12-22 20:35:07 <luke-jr> to complain and refuse to merge a compliant implementation months later, for no reason whatsoever, is merely trolling
324 2011-12-22 20:38:57 <mcorlett> Have there been any compelling arguments made for either side?
325 2011-12-22 20:39:22 <luke-jr> mcorlett: only for the standard side, and the (rejected by everyone) low-level side
326 2011-12-22 20:39:51 <gavinandresen> Keep It Simple, Stupid is the argument against having multiple ways of specifying amounts.   Because simple means less code, less ways for things to break, less opportunity for bad guys confusing users, etc etc
327 2011-12-22 20:40:24 <gavinandresen> "Oh, you mean I paid 99 HEXADECIIMAL bitcoins????"
328 2011-12-22 20:40:49 <gavinandresen> (ok, now I really am going to be quiet)
329 2011-12-22 20:40:51 <luke-jr> gavinandresen: that would be a client implementation issue, one which doesn't exist.
330 2011-12-22 20:41:20 <mcorlett> I.. I'll just leave you two alone for now..
331 2011-12-22 20:41:36 <luke-jr> he left
332 2011-12-22 20:43:23 <luke-jr> mcorlett: there's always Spesmilo ;)
333 2011-12-22 20:44:29 <mcorlett> luke-jr: Oh, I've been enjoying it thoroughly. I'd just rather not put URI links on my projects if they result in an error message for the majority of users.
334 2011-12-22 20:45:56 <luke-jr> mcorlett: starting with Bitcoin-Qt 0.6, the worst that should happen is the amount field is left blank
335 2011-12-22 20:46:58 <luke-jr> amount-less URIs included ofc
336 2011-12-22 20:46:58 <mcorlett> luke-jr: That's not really a deal-braker for me. But I can see how it may be for some people.
337 2011-12-22 20:48:01 <luke-jr> well, the goal is to be usable for everyone, not to be a deal-breaker :P
338 2011-12-22 20:48:11 <luke-jr> so the more people who can use it, the better
339 2011-12-22 20:49:47 <luke-jr> so the more people who can use it, the better
340 2011-12-22 20:49:49 <luke-jr> err
341 2011-12-22 21:02:25 <mcorlett> luke-jr: What are your thoughts on Electrum?
342 2011-12-22 21:02:44 <luke-jr> the alloy?
343 2011-12-22 21:02:53 <mcorlett> The client
344 2011-12-22 21:03:32 <mcorlett> Specifically, the whole client-server, client-keeps-the-private-key situation.
345 2011-12-22 21:04:26 <luke-jr> sounds good for some/most users
346 2011-12-22 21:04:38 <luke-jr> "No scripts: Electrum does not download any script. A compromised server cannot send you arbitrary code and steal your bitcoins." sounds like FUD though
347 2011-12-22 21:05:38 <gmaxwell> ...
348 2011-12-22 21:05:58 <gmaxwell> Indeed, it might be accidental fud though.
349 2011-12-22 21:06:03 <luke-jr> maybe.
350 2011-12-22 21:06:09 <luke-jr> but someone working with Bitcoin should know better
351 2011-12-22 21:06:22 <gmaxwell> e.g. "we were careful to avoid this" rather than "this makes us better than something else"
352 2011-12-22 21:06:57 <luke-jr> well, "scripting" is inherent in any verifying bitcoin implementation
353 2011-12-22 21:07:07 <gmaxwell> then again, I don't doubt that there isn't some crazy JS implementation out there thats completely vulnerable to that kind of thing.
354 2011-12-22 21:07:49 <gmaxwell> luke-jr: I don't think they're talking about bitcoin scripts. I think they're contrasting the implementation to a server-hosted-client-side thing that is all written in JS and can have the client software swapped out for the bitcoin stealing kind in an instant.
355 2011-12-22 21:08:07 <gmaxwell> But I agree that the net effect there is kinda fuddish.
356 2011-12-22 21:08:09 <luke-jr> ah