1 2011-10-30 01:01:59 <CIA-101> bips: genjix master * r816a18e / bip-test.md : testing. - http://git.io/jwQopw
  2 2011-10-30 01:06:45 <CIA-101> bips: genjix master * rc67d1fc / (8 files):
  3 2011-10-30 01:06:46 <CIA-101> bips: Renamed .txt files to .md for your github viewing pleasure.
  4 2011-10-30 01:24:16 <CIA-101> bitcoinjs/node-bitcoin-p2p: Stefan Thomas master * rd3234af / lib/blockchain.js : Enabled transaction verification during chain download. - http://git.io/YrEEEg
  5 2011-10-30 01:24:17 <CIA-101> bitcoinjs/node-bitcoin-p2p: Stefan Thomas master * rafe552a / (lib/util.js native.cc): Added BitcoinKey.signSync(). - http://git.io/PUADnw
  6 2011-10-30 01:34:20 <gmaxwell> https://bitcointalk.org/index.php?topic=50281.0  < wallet encryption claims its first victim? (or stops its first theif? depending on how much you buy that story)
  7 2011-10-30 01:36:16 <cjdelisle> lol rainbow table
  8 2011-10-30 01:36:19 <Diablo-D3> :3
  9 2011-10-30 01:36:52 <gmaxwell> "um because I really have no idea of my password at all. I'm so clueless about it that I need a rainbow table" ...
 10 2011-10-30 01:38:31 <phantomcircuit> lol rainbow table
 11 2011-10-30 01:38:35 <phantomcircuit> nope not gonna happen
 12 2011-10-30 01:38:45 <phantomcircuit> i propose we ban zhoutong
 13 2011-10-30 01:38:53 <phantomcircuit> his constant part/join is annoying as hell
 14 2011-10-30 01:38:57 <copumpkin> yup
 15 2011-10-30 01:38:59 <copumpkin> I agree
 16 2011-10-30 01:39:01 <phantomcircuit> and he is never actually here
 17 2011-10-30 01:39:31 <copumpkin> I think he joins and parts every time someone places an order on bitcoinica
 18 2011-10-30 01:39:37 <phantomcircuit> lol
 19 2011-10-30 01:53:41 <Davincij15> copying the BTC wallet over to .namecion folder and doing -rescan did it!  I got my lost coins!  YEAH!
 20 2011-10-30 01:53:48 <cjdelisle> looks like a bad network connection though so letting him know why is a good idea....
 21 2011-10-30 01:56:18 <copumpkin> cjdelisle: yes, I've left him a couple of messages with gribble telling him about it
 22 2011-10-30 01:56:25 <copumpkin> either he never checks IRC or he just ignored it
 23 2011-10-30 02:37:52 <CIA-101> bips: etotheipi master * r4261991 / bip-0010.md :
 24 2011-10-30 02:43:59 <devrandom> ;;later tell BlueMatt is the gitian-win32.yml file incomplete in bitcoin/bitcoin master?  there don't seem to be any commands to cross-compile qt, and there's a ref to $HOME/qt which is never populated
 25 2011-10-30 02:43:59 <gribble> The operation succeeded.
 26 2011-10-30 02:52:31 <luke-jr> wtf is .md
 27 2011-10-30 02:59:23 <justmoon> luke-jr, Markdown
 28 2011-10-30 05:27:51 <luke-jr> ;;bc,stats
 29 2011-10-30 05:27:54 <gribble> Current Blocks: 151100 | Current Difficulty: 1468195.4272208 | Next Difficulty At Block: 151199 | Next Difficulty In: 99 blocks | Next Difficulty In About: 21 hours, 18 minutes, and 45 seconds | Next Difficulty Estimate: 1208707.62831654 | Estimated Percent Change: -17.673927741
 30 2011-10-30 05:51:16 <CIA-101> bitcoinjs/node-bitcoin-p2p: Stefan Thomas master * r32b839c / lib/blockchain.js : Fixed bug where invalid blocks could remain in cache. - http://git.io/AjqKWg
 31 2011-10-30 05:51:18 <CIA-101> bitcoinjs/node-bitcoin-p2p: Stefan Thomas master * r89bb9b3 / (lib/scriptinterpreter.js test/script.js): Changed script interpreter to asynchronous syntax. Preparation for #29. - http://git.io/VLD7-g
 32 2011-10-30 05:51:19 <CIA-101> bitcoinjs/node-bitcoin-p2p: Stefan Thomas master * rcb22a44 / lib/schema/transaction.js : Check sanity of inIndex in Transaction.hashForSignature(). - http://git.io/ckun4g
 33 2011-10-30 10:36:47 <terrytibbs> goddammit zhoutong
 34 2011-10-30 10:53:52 <cocktopus> 0o
 35 2011-10-30 10:54:19 <nathan7> What does a cocktopus look like?
 36 2011-10-30 10:54:33 <nathan7> Eight cocks, usable as arms?
 37 2011-10-30 10:54:42 <cocktopus> !google cocktopus
 38 2011-10-30 10:54:43 <gribble> The Cocktopus | Robots with Feelings: <http://www.robotswithfeelings.com/2010-01-27/the-cocktopus>; cocktopus's Channel - YouTube: <http://www.youtube.com/user/cocktopus>; Toonhole | Cocktopus: <http://www.toonhole.com/2011/02/cocktopus/>
 39 2011-10-30 10:55:11 <nathan7> Heh.
 40 2011-10-30 11:30:15 <CIA-101> libbitcoin: genjix * ra3abd4ba0d10 /src/network/network.cpp: std::ref(...)'ize bound reference arguments.
 41 2011-10-30 15:40:22 <CIA-101> libbitcoin: genjix * r709619d0db26 / (4 files in 2 dirs): call handle_send(...) after attempting send in channel.
 42 2011-10-30 16:33:39 <BlueMatt> devrandom: ping
 43 2011-10-30 16:33:43 <BlueMatt> graingert: ping
 44 2011-10-30 16:34:23 <BlueMatt> ;;later tell devrandom see https://github.com/bitcoin/bitcoin/pull/597 and https://github.com/bitcoin/bitcoin/pull/598 (it just took a long time to get a working xcompile on ubuntu)
 45 2011-10-30 16:34:23 <gribble> The operation succeeded.
 46 2011-10-30 16:36:25 <BlueMatt> ;;later tell graingert that is because I dint get around to moving the db4.8 package from bitcoin/libdb to bitcoin/bitcoin...Ill go do that now
 47 2011-10-30 16:36:25 <gribble> The operation succeeded.
 48 2011-10-30 16:45:34 <graingert> BlueMatt: Sorry I was grabbing le pizza
 49 2011-10-30 16:46:30 <BlueMatt> graingert: ok, I uploaded db4.8 to bitcoin/bitcoin and removed bitcoin/libdb as it is no longer necessary
 50 2011-10-30 16:46:45 <BlueMatt> bitcoin-qt should now work on oneiric
 51 2011-10-30 16:46:49 <BlueMatt> (once the build runs)
 52 2011-10-30 16:47:54 <graingert> I'm still uncomfortable with the PPA including extra packages
 53 2011-10-30 16:48:09 <BlueMatt> I agree, but its the only reasonable way...
 54 2011-10-30 16:48:15 <graingert> it seemed gavinanderson was pro using libdb4.8(!++)-dev
 55 2011-10-30 16:48:17 <BlueMatt> (unless you want to static-link db)
 56 2011-10-30 16:48:26 <graingert> or using libdb5.1++
 57 2011-10-30 16:48:43 <BlueMatt> you mean rewrite bitcoin to use libdb4.8 instead of libdb4.8++?
 58 2011-10-30 16:48:43 <Diablo-D3> no
 59 2011-10-30 16:48:51 <Diablo-D3> you cant switch to 5.1 because 5.x is oraclized
 60 2011-10-30 16:49:04 <BlueMatt> stfu Diablo-D3
 61 2011-10-30 16:49:04 <graingert> that's not a reason Diablo-D3
 62 2011-10-30 16:49:13 <Diablo-D3> it is when its a license and patent issue
 63 2011-10-30 16:49:20 <BlueMatt> its not though...
 64 2011-10-30 16:49:20 <graingert> urm
 65 2011-10-30 16:49:34 <graingert> Diablo-D3: paste me the license url
 66 2011-10-30 16:49:40 <BlueMatt> its not a license issue, and patent issue is not an issue
 67 2011-10-30 16:49:42 <Diablo-D3> find it yourself, if you can
 68 2011-10-30 16:49:43 <luke-jr> 5.x is afaik compatible with 4.8
 69 2011-10-30 16:49:44 <graingert> Diablo-D3: bdbd has been dual licensed
 70 2011-10-30 16:50:03 <graingert> Diablo-D3: it's your argument the onus of proof is on you
 71 2011-10-30 16:50:03 <luke-jr> Debian (and Ubuntu) are removing 4.x entirely
 72 2011-10-30 16:50:15 <Diablo-D3> its not my argument in that sense
 73 2011-10-30 16:50:22 <Diablo-D3> its why most projects have not gone to 5.x
 74 2011-10-30 16:50:24 <graingert> luke-jr: If that's true then we should switch to 5.x
 75 2011-10-30 16:50:28 <BlueMatt> luke-jr: yea, problem is 5.X isnt in many old version's repos
 76 2011-10-30 16:50:32 <luke-jr> Diablo-D3: pretty much everything has
 77 2011-10-30 16:50:41 <Diablo-D3> luke-jr: [Citation Needed]
 78 2011-10-30 16:50:45 <luke-jr> BlueMatt: so depend on 4.8+
 79 2011-10-30 16:50:50 <luke-jr> BlueMatt: compatible is compatible
 80 2011-10-30 16:50:51 <BlueMatt> luke-jr: we currently do
 81 2011-10-30 16:51:00 <BlueMatt> luke-jr: but in oneiric, there is no 4.8++
 82 2011-10-30 16:51:03 <BlueMatt> (and debian testing)
 83 2011-10-30 16:51:03 <graingert> luke-jr: we can't because ubuntu 11.10 does not have it
 84 2011-10-30 16:51:05 <luke-jr> 5.x is 4.8+
 85 2011-10-30 16:51:13 <graingert> no it's not
 86 2011-10-30 16:51:15 <luke-jr> yes it is
 87 2011-10-30 16:51:18 <luke-jr> 5 > 4
 88 2011-10-30 16:51:21 <Diablo-D3> er no luke, you cant magically go backwards in db
 89 2011-10-30 16:51:26 <BlueMatt> he means 4.8+ not 4.8++
 90 2011-10-30 16:51:31 <BlueMatt> (very big difference)
 91 2011-10-30 16:51:32 <luke-jr> Diablo-D3: between 4.8 and 5.x, you can
 92 2011-10-30 16:51:33 <graingert> oh
 93 2011-10-30 16:51:35 <Diablo-D3> even read only opening a db in bdb will upgrade the db
 94 2011-10-30 16:51:42 <Diablo-D3> that means you can never go back
 95 2011-10-30 16:51:45 <luke-jr> C O M P A T I B L E
 96 2011-10-30 16:51:54 <graingert> o?
 97 2011-10-30 16:51:57 <Diablo-D3> 5.x also contains api differences.
 98 2011-10-30 16:52:09 <Diablo-D3> blueMatt: I agree
 99 2011-10-30 16:52:14 <Diablo-D3> this is why it was standardized on 4.8
100 2011-10-30 16:52:19 <BlueMatt> exactly
101 2011-10-30 16:52:21 <Diablo-D3> because osx was on 4.8 and everyone else was on 4.7
102 2011-10-30 16:52:21 <upb> once you go black, you can never go back
103 2011-10-30 16:52:46 <BlueMatt> and we cant upgrade to 5.X until all "supported" versions of debian/ubuntu have it in their repos...
104 2011-10-30 16:52:50 <luke-jr> BlueMatt: official packages will be made by the distro
105 2011-10-30 16:52:55 <graingert> using a db file as an interchange format is a major issue
106 2011-10-30 16:53:00 <BlueMatt> luke-jr: hence the quotes
107 2011-10-30 16:53:05 <graingert> and that's why we are having this problem
108 2011-10-30 16:53:07 <Diablo-D3> distros who break shit know better.
109 2011-10-30 16:53:41 <graingert> I think we need a big push for a proper wallet interchange format
110 2011-10-30 16:53:49 <graingert> that we can stick to _forever_ (ish)
111 2011-10-30 16:53:56 <BlueMatt> graingert: go ahead (patches welcome, as always)
112 2011-10-30 16:54:07 <graingert> BlueMatt: well no it's not a patches issue
113 2011-10-30 16:54:14 <luke-jr> graingert: dump to gzip'd XML on quit, and load it to db on load?
114 2011-10-30 16:54:17 <graingert> as this is something people need to decide on what the API will be
115 2011-10-30 16:54:29 <graingert> luke-jr: I was thinking that, or GPG key export format
116 2011-10-30 16:54:30 <Diablo-D3> s/gzip/lrzip/
117 2011-10-30 16:54:31 <BlueMatt> problem is...there is no good solution
118 2011-10-30 16:54:33 <luke-jr> wait, nm, bitcoind is already slow
119 2011-10-30 16:54:38 <luke-jr> Diablo-D3: lrzip is insane slow on 32-bit
120 2011-10-30 16:54:45 <tcatm> wouldn't statically linking db4.8 be a good workaround?
121 2011-10-30 16:54:53 <luke-jr> tcatm: no, static linking is broken by design
122 2011-10-30 16:54:59 <luke-jr> nothing should ever be static linked
123 2011-10-30 16:55:03 <graingert> okay new plan
124 2011-10-30 16:55:05 <BlueMatt> tcatm: dynamic linking and including our own db4.8 packages for oneiric is better (IMO)
125 2011-10-30 16:55:16 <luke-jr> ^
126 2011-10-30 16:55:18 <graingert> a new command to export / import ecdsa keys as GPG compatible
127 2011-10-30 16:55:26 <tcatm> BlueMatt: yep, that's okay, too
128 2011-10-30 16:55:35 <graingert> and then tell people to backup that
129 2011-10-30 16:55:41 <graingert> rather than their wallet.dat
130 2011-10-30 16:55:45 <BlueMatt> tcatm: the debate is really because that both are bad solutions...
131 2011-10-30 16:56:00 <graingert> this will give you wallet merging as a bonus
132 2011-10-30 16:56:16 <luke-jr> infinitely more important than these silly build issues though, IMO, is the multiple reports of 0.5 corrupting wallets
133 2011-10-30 16:56:31 <BlueMatt> linky?
134 2011-10-30 16:56:38 <luke-jr> no linky.
135 2011-10-30 16:56:44 <BlueMatt> ?
136 2011-10-30 16:56:44 <luke-jr> people on IRC
137 2011-10-30 16:56:49 <BlueMatt> link to logs?
138 2011-10-30 16:56:49 <graingert> luke-jr: paste bin
139 2011-10-30 16:57:03 <luke-jr> most Bitcoin channels are not publicly logged.
140 2011-10-30 16:57:13 <luke-jr> nor do I recall when/where
141 2011-10-30 16:57:17 <graingert> luke-jr: well you presumably have logs
142 2011-10-30 16:57:18 <BlueMatt> #bitcoin and -dev are
143 2011-10-30 16:57:20 <luke-jr> nor are they reproducable
144 2011-10-30 16:57:24 <luke-jr> BlueMatt: not #bitcoin
145 2011-10-30 16:57:25 <graingert> BlueMatt: really?
146 2011-10-30 16:57:29 <tcatm> maybe we could first remove all non-transaction data (I think some settings are still saved in the wallet) from the wallet and then find a good replacement database? maybe some append-only format so we can't corrupt the database too much
147 2011-10-30 16:57:44 <Diablo-D3> aaand
148 2011-10-30 16:57:45 <BlueMatt> luke-jr: graingert http://bitcoinstats.com/irc/bitcoin/logs/2011/10
149 2011-10-30 16:57:48 <Diablo-D3> 960 finally locked up
150 2011-10-30 16:57:50 <Diablo-D3> took a few days
151 2011-10-30 16:57:58 <luke-jr> BlueMatt: that site is logging illegally then
152 2011-10-30 16:58:00 <graingert> BlueMatt: just bitcoin dev
153 2011-10-30 16:58:08 <BlueMatt> graingert: the link goes right to #bitcoin
154 2011-10-30 16:58:10 <graingert> oh crumbs
155 2011-10-30 16:58:12 <BlueMatt> luke-jr: take it up with the site
156 2011-10-30 16:58:27 <graingert> BlueMatt: that really should put a message on entry then
157 2011-10-30 16:58:34 <BlueMatt> graingert: it used to
158 2011-10-30 16:58:34 <graingert> or at least in the topic
159 2011-10-30 16:58:38 <graingert> (freenode rules)
160 2011-10-30 16:58:40 <BlueMatt> and it used to be in topic
161 2011-10-30 16:58:48 <BlueMatt> but people removed it, I dont know why or who
162 2011-10-30 17:00:39 <luke-jr> BlueMatt: nope, it was never in the topic at least
163 2011-10-30 17:01:11 <BlueMatt> hm, I could have sworn it was
164 2011-10-30 17:01:23 <BlueMatt> oh well, BCBot used to always send a similar message on #bitcoin as well as -dev
165 2011-10-30 17:01:34 <luke-jr> that would be rather annoying
166 2011-10-30 17:09:35 <BlueMatt> graingert: https://github.com/bitcoin/bitcoin/pull/600
167 2011-10-30 17:13:11 <graingert> BlueMatt: https://bitcointalk.org/index.php?topic=50368.0
168 2011-10-30 17:13:55 <graingert> luke-jr: can you fact check that please?
169 2011-10-30 17:14:05 <graingert> luke-jr: it's a brain dump of my understanding
170 2011-10-30 17:14:13 <graingert> brb pizza
171 2011-10-30 17:14:33 <luke-jr> Upgrade to libdb5.x++ and cause new wallets to be incompatible with old bitcoin versions <-- 5.x should be compatible, and not break anything
172 2011-10-30 18:16:18 <graingert> BlueMatt: https://github.com/jim618/multibit/wiki/Stable%20wallet%20format
173 2011-10-30 18:16:33 <graingert> it seems other clients have had similar problems
174 2011-10-30 18:16:42 <graingert> they are using the protobuf format
175 2011-10-30 18:19:09 <lfm> what are these new short output scripts?
176 2011-10-30 18:19:56 <graingert> lfm: link to an example
177 2011-10-30 18:20:21 <lfm> ok one sec
178 2011-10-30 18:21:58 <lfm> http://blockexplorer.com/t/59GUt4zqzS
179 2011-10-30 18:22:52 <justmoon> lfm, that's unspendable
180 2011-10-30 18:23:18 <lfm> ok someone blew a lot of btc then, theres about 20 of them
181 2011-10-30 18:24:43 <justmoon> hmm, somebody asked me for a reliable way to prove the destruction of coins recently
182 2011-10-30 18:24:50 <justmoon> I recommended sending them to address 0
183 2011-10-30 18:25:07 <justmoon> this is what this looks like, not sure if it was generated by the original client though or a custom one
184 2011-10-30 18:25:54 <lfm> ya its a way to destroy coins, not like the old send to address 0
185 2011-10-30 18:26:25 <lfm> its new
186 2011-10-30 18:26:45 <diki> since when is 2600k btc a lot?
187 2011-10-30 18:26:55 <diki> i am honestly surprised
188 2011-10-30 18:26:56 <copumpkin> diki: it's a reasonable amount to most people
189 2011-10-30 18:26:59 <lfm> the old way looked like a valid address of 1111111111111111111114oLvT2
190 2011-10-30 18:27:18 <copumpkin> diki is the 1%
191 2011-10-30 18:27:22 <diki> i mean i'd understand if it was 10k or so, but...2600k?
192 2011-10-30 18:27:32 <lfm> diki its the most coins destroyed ever
193 2011-10-30 18:27:53 <JFK911> is that a bug
194 2011-10-30 18:27:54 <lfm> verifyably destoryed
195 2011-10-30 18:28:46 <diki> who is the person who accidentally?
196 2011-10-30 18:28:53 <upb> 2600K is 2.6M
197 2011-10-30 18:28:56 <copumpkin> nobody knows
198 2011-10-30 18:29:00 <diki> upb, mispelled
199 2011-10-30 18:29:09 <lfm> and 2600k btc would still be $7800000.00 but its not that many destroyed anyway
200 2011-10-30 18:29:10 <copumpkin> well, at least one person knows, presumably
201 2011-10-30 18:29:11 <diki> I hope he was an evil person
202 2011-10-30 18:29:14 <copumpkin> unless they fucked up without knowing
203 2011-10-30 18:34:40 <edcba> ;;bc,mtgox
204 2011-10-30 18:34:41 <gribble> {"ticker":{"high":3.65026,"low":3.2,"avg":3.473987115,"vwap":3.412128059,"vol":50777,"last_all":3.25,"last_local":3.25,"last":3.25,"buy":3.24599,"sell":3.24999}}
205 2011-10-30 18:37:19 <lfm> ya it is 2611 btc not 2600k
206 2011-10-30 18:38:12 <graingert> lfm:  that's mtgox fucking up
207 2011-10-30 18:38:20 <graingert> diki: it's 2.6k
208 2011-10-30 18:39:19 <lfm> makes sense, someone doing a lot of txn all in one block. It looks like they had a wrong wallet file or something
209 2011-10-30 18:40:27 <graingert> lfm: nope mtgox and eligus have a deal
210 2011-10-30 18:40:55 <graingert> eligus will mine all mtgox tx no matter what
211 2011-10-30 18:42:06 <lfm> oh so mtgox generated some bad txn then eligius put them in a block for them even if no one else would have?
212 2011-10-30 18:44:06 <upb> haha way to fail
213 2011-10-30 18:44:11 <CIA-101> bitcoinjs/node-bitcoin-p2p: Stefan Thomas master * rbe9b384 / lib/rpc/get.js : Miscellaneous fixes/additions to the RPC. (+5 more commits...) - http://git.io/l8CepQ
214 2011-10-30 18:44:13 <upb> thast what you get when you write a bitcoind in PHP
215 2011-10-30 18:44:20 <lfm> still the zero address part suggests to me they had a corrupt wallet file running or something like that
216 2011-10-30 18:45:38 <graingert> lfm: nope
217 2011-10-30 18:45:44 <graingert> lfm: it was a hacked bitcoind
218 2011-10-30 18:45:47 <graingert> and a hacked miner
219 2011-10-30 18:46:03 <justmoon> graingert, why a hacked miner?
220 2011-10-30 18:46:13 <justmoon> ah because they don't meet IsStandard()?
221 2011-10-30 18:46:18 <BlueMatt> graingert: seems cool, but it will take at least another release before anything like that will get merged into bitcoin-qt, also bdb will have to be linked to support reading old wallets and converting them (which results in the same issues as if we just upgraded to bdb5.X)
222 2011-10-30 18:46:33 <BlueMatt> and for 0.5, a decision has to be made wrt libdb5.X
223 2011-10-30 18:46:53 <graingert> luke-jr: claims old wallets will "just work"
224 2011-10-30 18:47:05 <graingert> oh old wallets as in current wallets
225 2011-10-30 18:47:22 <BlueMatt> for bdb5.X: bdb5.X will open old wallets just fine, no code changes necessary, just change the link
226 2011-10-30 18:47:22 <graingert> wallet.db vs wallet.export
227 2011-10-30 18:47:33 <graingert> that's good
228 2011-10-30 18:47:35 <graingert> go for that afaik
229 2011-10-30 18:47:36 <BlueMatt> but it will upgrade the wallet file and it will no longer be readable from bdb4.X
230 2011-10-30 18:47:41 <graingert> ah
231 2011-10-30 18:47:44 <graingert> that sucks
232 2011-10-30 18:47:51 <BlueMatt> which is the reason Im using bdb4.X for now
233 2011-10-30 18:47:56 <graingert> but everyone on ubuntu will be using encrypted wallets anyway
234 2011-10-30 18:48:03 <graingert> *
235 2011-10-30 18:48:03 <lfm> ya what wont work is reading dbs touched by bdb5 with bdb4.8
236 2011-10-30 18:48:07 <graingert> going from unencrypted to encrypted
237 2011-10-30 18:48:43 <BlueMatt> (the encryption addition is why we switched from bdb4.7 to 4.8 with 0.4)
238 2011-10-30 18:54:14 <graingert> most ubuntu'ers will be on the stretch ppa
239 2011-10-30 18:54:47 <graingert> ppa:stretch/bitcoin
240 2011-10-30 18:54:58 <graingert> as that's the only one that was about before
241 2011-10-30 18:55:13 <graingert> and that's still on 0.3.24 I think
242 2011-10-30 18:55:13 <lfm> and ubuntuers can still install bdb4.8 on 11.10 if they have a clue
243 2011-10-30 18:55:53 <graingert> lfm: well not the issue is will people on 11.04 want to install lib5.1++ to use their new bitcoin wallet
244 2011-10-30 18:56:39 <graingert> I think do the same thing that was done for encryption and warn that importing a 4.8 db will cause the old wallet to be incompatible
245 2011-10-30 18:56:49 <graingert> with older OS
246 2011-10-30 18:57:32 <lfm> why do you need bdb5.x?
247 2011-10-30 19:00:30 <graingert> lfm: ubuntu latest does not support bdb4.8
248 2011-10-30 19:00:47 <graingert> and I'm not keen on installing extra packages on people's pc
249 2011-10-30 19:01:04 <graingert> a bitcoin with bdb4.8 deps will never get into multiverse
250 2011-10-30 19:01:08 <diki> hmm...windows is always backwards compatible
251 2011-10-30 19:01:40 <diki> rather...most applications
252 2011-10-30 19:01:54 <diki> so an app that works in 7 would theoretically work on 98 SE as well
253 2011-10-30 19:01:56 <lfm> diki thats nice, but irrelevant
254 2011-10-30 19:02:07 <diki> however an app that works on 11.10 but doesnt on 11.04 is fail...
255 2011-10-30 19:02:13 <diki> which is what happened with me
256 2011-10-30 19:02:22 <diki> gcc 4.6.2 is ONLY available to 11.10
257 2011-10-30 19:02:51 <lfm> diki you can install any version of gcc on any version of linux you want
258 2011-10-30 19:03:03 <diki> i couldnt for 11.04
259 2011-10-30 19:03:13 <diki> it wasnt in the repository
260 2011-10-30 19:03:18 <BlueMatt> oneiric HAS db4.8 packages in it, including libdb4.8-dev, it does NOT have libdb4.8++-dev and libdb4.8++ as the debian maintainers are trying to move people off of 4.8
261 2011-10-30 19:03:27 <lfm> just cuz caonical or debian doesnt make a pretty package for you doesnt mean it cant be done
262 2011-10-30 19:03:36 <graingert> lfm: it can be done
263 2011-10-30 19:03:45 <graingert> and that's currently the way the ppa is swinging
264 2011-10-30 19:03:54 <graingert> BlueMatt: would it be possible to have two ppa?
265 2011-10-30 19:04:07 <BlueMatt> you mean one with 5.1 and one with 4.8?
266 2011-10-30 19:04:09 <graingert> BlueMatt: bitcoin and bitcoinnewdb
267 2011-10-30 19:04:12 <graingert> yep
268 2011-10-30 19:04:16 <graingert> how much overhead is that?
269 2011-10-30 19:04:45 <BlueMatt> not a single user has the wish to chose between the two...if they do they probably are building themselves
270 2011-10-30 19:04:46 <graingert> I'd rather hook my ubuntu up to bitcoinnewdb
271 2011-10-30 19:05:05 <BlueMatt> the goal of adding ppas is to make getting bitcoin running easy...
272 2011-10-30 19:05:21 <graingert> well using the bitcoin/bitcoin repo would get bitcoin running easy
273 2011-10-30 19:05:42 <graingert> running bitcoin/newdb would get bitcoin running easy with 5.x
274 2011-10-30 19:06:29 <lfm> I actually found it rather easy to add bdb4.8++ to ubuntu 11.10
275 2011-10-30 19:06:49 <graingert> lfm: it is but our ppa package will now try to wipe out yours
276 2011-10-30 19:06:53 <BlueMatt> what Im currently looking at doing: creating a bdb4.8++ upload that ONLY does bdb4.8++ not bdb4.8 meaning it wont conflict
277 2011-10-30 19:07:15 <BlueMatt> (but no telling how long its gonna take)
278 2011-10-30 19:07:21 <lfm> graingert: didnt use ppa stuff, just the tar.gz stuff
279 2011-10-30 19:07:29 <graingert> oh god
280 2011-10-30 19:07:38 <graingert> lfm: you're free to fuck up your OS btw
281 2011-10-30 19:07:39 <lfm> easy like i SAID
282 2011-10-30 19:07:50 <lfm> IS IN /USR/LOCAL
283 2011-10-30 19:07:56 <graingert> ^
284 2011-10-30 19:08:13 <lfm> sorry caps lock slipped
285 2011-10-30 19:08:33 <luke-jr> [15:28:46] <diki> who is the person who accidentally?
286 2011-10-30 19:08:35 <luke-jr> MtGox
287 2011-10-30 19:08:52 <BlueMatt> ...?
288 2011-10-30 19:08:54 <luke-jr> [15:47:36] <BlueMatt> but it will upgrade the wallet file and it will no longer be readable from bdb4.X <-- citation needed
289 2011-10-30 19:09:00 <lfm> luke threw away 2611 btc?
290 2011-10-30 19:09:17 <luke-jr> MtGox bug destroyed 2611 BTC
291 2011-10-30 19:09:22 <graingert> lfm: luke-jr helped mtgox throw away 2611 btc
292 2011-10-30 19:09:25 <graingert> ish
293 2011-10-30 19:09:28 <graingert> mtgox's fault
294 2011-10-30 19:09:36 <dgores> Hello, Why is "OP_DUP, OP_HASH160, OP_PUBKEYHASH, OP_EQUALVERIFY, OP_CHECKSIG" preferred over "OP_PUBKEY, OP_CHECKSIG"?  Why is bitcoin address used insted of the public key itself?
295 2011-10-30 19:09:37 <BlueMatt> what...?
296 2011-10-30 19:09:37 <graingert> luke-jr mined it
297 2011-10-30 19:09:44 <BlueMatt> mtgox lost 2611 BTC?
298 2011-10-30 19:09:51 <luke-jr> dgores: address is shorter for humans to relay
299 2011-10-30 19:09:52 <graingert> old news
300 2011-10-30 19:09:56 <luke-jr> BlueMatt: yes
301 2011-10-30 19:09:58 <BlueMatt> when was this?
302 2011-10-30 19:10:01 <luke-jr> recently
303 2011-10-30 19:10:09 <BlueMatt> not an answer
304 2011-10-30 19:10:10 <lfm> dgores: length?
305 2011-10-30 19:10:54 <lfm> bluematt see http://blockexplorer.com/t/59GUt4zqzS for instance
306 2011-10-30 19:11:25 <BlueMatt> graingert: old news as in 2 days old...for people not as active in bitcoin that is very new...
307 2011-10-30 19:11:40 <graingert> fair enough
308 2011-10-30 19:11:59 <graingert> I've seen it being discussed way too many times :p
309 2011-10-30 19:12:25 <graingert> lost my cool a little, sorry
310 2011-10-30 19:12:35 <dgores> luke-jr: Ok, that makes sense.  Thanks.
311 2011-10-30 19:12:44 <BlueMatt> oh, luke mined it because it was nonstd...
312 2011-10-30 19:12:47 <luke-jr> BlueMatt: MtGox used their "anything at no fee" contract with Eligius to mine those
313 2011-10-30 19:13:02 <BlueMatt> mmm, but no other pool would have taken it bc it is nonstd...
314 2011-10-30 19:13:10 <BlueMatt> (not blaming you...)
315 2011-10-30 19:13:10 <graingert> luke-jr: can you rename your pool to something I can spell?
316 2011-10-30 19:13:23 <luke-jr> nor would Eligius if they hadn't explicitly asked us to
317 2011-10-30 19:13:30 <luke-jr> graingert: not my fault you can't spell
318 2011-10-30 19:13:42 <graingert> luke-jr: or leave a bot in #bitcoin and #bitcoin-dev called Eligius
319 2011-10-30 19:13:45 <BlueMatt> now thats just rude...
320 2011-10-30 19:13:47 <luke-jr> lol
321 2011-10-30 19:13:48 <graingert> so I can tab complete it
322 2011-10-30 19:14:44 <lfm> graingert: its in some bible or something if you need an updated spelling dictionairy
323 2011-10-30 19:15:46 <graingert> I have a choice of Eligibles Elitism Eligibility  and  Religious
324 2011-10-30 19:15:54 <graingert> so close
325 2011-10-30 19:16:01 <luke-jr> http://www.thinkbabynames.com/meaning/1/Eligius
326 2011-10-30 19:16:22 <lfm> graingert: if you use any of those most of us will know what you mean
327 2011-10-30 19:16:29 <BlueMatt> names never make sense...welcome to the internet
328 2011-10-30 19:16:32 <BlueMatt> ;)
329 2011-10-30 19:16:38 <graingert> I'm going for Elitism
330 2011-10-30 19:16:48 <graingert> Eloi would do
331 2011-10-30 19:16:51 <graingert> I can spell that
332 2011-10-30 19:17:24 <lfm> or just Luke's pool
333 2011-10-30 19:17:33 <graingert> prolly go for that
334 2011-10-30 19:17:52 <luke-jr> graingert: #Freenode says 3 weeks till I can claim the Eligius nick
335 2011-10-30 19:18:18 <graingert> nice
336 2011-10-30 19:34:59 <graingert> BlueMatt: do you have any objection to the 5.x ppa?
337 2011-10-30 19:35:20 <graingert> and have you discovered if luke-jr 's comment is true?
338 2011-10-30 19:35:28 <graingert> I havn't found any information on it
339 2011-10-30 19:35:41 <BlueMatt> a. whats luke's comment
340 2011-10-30 19:36:14 <BlueMatt> b. objection...not really, however, Im making packages that will JUST include db4.8++ meaning they wont conflict with system-shipped packages, so I dont think it would be worth it at that point
341 2011-10-30 19:36:23 <BlueMatt> and at that point, I would rather JUST have db4.8 ppa
342 2011-10-30 19:36:27 <graingert> http://bitcoinstats.com/irc/bitcoin-dev/logs/2011/10/30/4#l2053947
343 2011-10-30 19:36:49 <BlueMatt> what, he claims db4.8 can read db5.X db files?
344 2011-10-30 19:36:54 <graingert> yes
345 2011-10-30 19:37:58 <graingert> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621374
346 2011-10-30 19:38:15 <graingert> he packages which use Berkeley DB transactional mode need to upgrade the database files before the upgrade.  This is fairly straightforward and is well documented on the Berkeley DB website.  But you probably  already know that because it's not the first Berkeley DB transition.
347 2011-10-30 19:38:54 <BlueMatt> the api is compatible
348 2011-10-30 19:38:58 <BlueMatt> the files are not
349 2011-10-30 19:39:11 <BlueMatt> (there is an identical bug on bitcoind on debian)
350 2011-10-30 19:39:18 <BlueMatt> (hence why bitcoind on debian uses db5.X)
351 2011-10-30 19:39:20 <graingert> I see
352 2011-10-30 19:39:58 <BlueMatt> (for bitcoin no upgrades should be needed, correct?)
353 2011-10-30 19:39:59 <luke-jr> so don't use txnl mode&
354 2011-10-30 19:40:07 <BlueMatt> just run with db5.X and it will upgrade automatically
355 2011-10-30 19:41:11 <graingert> people shouldn't be moving wallets between machines anyway
356 2011-10-30 19:41:55 <BlueMatt> thats not something we should impose on our users
357 2011-10-30 19:42:00 <BlueMatt> "if you move your wallet, it will break"
358 2011-10-30 19:42:03 <graingert> and we're going to have to switch to 5.X eventually
359 2011-10-30 19:42:13 <BlueMatt> that is a ways off
360 2011-10-30 19:43:10 <graingert> I'd push to bite the bullet
361 2011-10-30 19:43:43 <BlueMatt> yes, I am 100% sure I DID test bdb versions on bitcoin, and 5.X upgraded wallets so that 4.X cannot open them
362 2011-10-30 19:43:53 <BlueMatt> (4.X vs 4.Y only log files are incompatible)
363 2011-10-30 19:44:28 <BlueMatt> graingert: then we are in the same situation but reversed...we have to ship db5.X packages in the repo for old versions
364 2011-10-30 19:44:40 <graingert> no you don't
365 2011-10-30 19:44:44 <graingert> do you?
366 2011-10-30 19:44:50 <graingert> can't they stick with 4.X
367 2011-10-30 19:44:58 <BlueMatt> then you are at the point of telling users their wallets wont work between oses
368 2011-10-30 19:45:03 <graingert> do you need the same build script for all release
369 2011-10-30 19:45:07 <BlueMatt> which is much worse
370 2011-10-30 19:45:09 <graingert> well they shouldn't
371 2011-10-30 19:45:15 <BlueMatt> why not?
372 2011-10-30 19:45:19 <graingert> people shouldn't be moving their wallet
373 2011-10-30 19:45:23 <graingert> only their coin
374 2011-10-30 19:45:24 <BlueMatt> why not?
375 2011-10-30 19:45:33 <BlueMatt> I dont think that is a reasonable restriction
376 2011-10-30 19:45:45 <BlueMatt> especially when we can (fairly) easily avoid it
377 2011-10-30 19:45:49 <graingert> okay stick to 4.8++
378 2011-10-30 19:45:58 <graingert> and move to 5 once we have a standard interchange format
379 2011-10-30 19:46:12 <graingert> does that sound like a deal?
380 2011-10-30 19:46:13 <BlueMatt> I agree conflicting and overriding os-shipped packages is not acceptable, but I dont think we have to...
381 2011-10-30 19:46:26 <BlueMatt> why move to 5 at all, if you are converting to a new format?
382 2011-10-30 19:46:58 <graingert> well it would parse the wallet.json/proto/xml into a wallet.db
383 2011-10-30 19:47:11 <BlueMatt> (note that we cant really switch to db5.X for another couple years due to old distros...)
384 2011-10-30 19:47:21 <BlueMatt> which are still supported
385 2011-10-30 19:47:30 <BlueMatt> and its easier to use an old version than a new one
386 2011-10-30 19:47:38 <graingert> can you have different deps on each releasE?
387 2011-10-30 19:47:40 <graingert> release*
388 2011-10-30 19:47:45 <graingert> on laucnhpad?
389 2011-10-30 19:47:53 <graingert> launchpad*
390 2011-10-30 19:47:54 <BlueMatt> you mean for each distro? yes
391 2011-10-30 19:48:12 <graingert> so why not have a 4.8 build for natty-
392 2011-10-30 19:48:20 <graingert> and a 5.x build for oneiric+
393 2011-10-30 19:48:21 <BlueMatt> because then wallets arent portable
394 2011-10-30 19:48:26 <BlueMatt> which imo is not acceptable
395 2011-10-30 19:48:34 <graingert> but they would be if we had an export format
396 2011-10-30 19:48:44 <graingert> my point being stick to 4.8 for now, till we have a standard export format
397 2011-10-30 19:48:52 <graingert> then move to whatever the os supports
398 2011-10-30 19:49:08 <BlueMatt> well Im not sure either way, but its not a decision that need be made now
399 2011-10-30 19:49:26 <Eliel> if we make an export format, might as well make that the default wallet format :P
400 2011-10-30 19:49:28 <BlueMatt> for now just stick with 4.8 for everything and we can reopen the debate when we have a standard exchange format...
401 2011-10-30 19:49:35 <BlueMatt> Eliel: cant, it wont have tx support
402 2011-10-30 19:49:37 <BlueMatt> (unless it does)
403 2011-10-30 19:49:39 <Eliel> oh right
404 2011-10-30 19:49:58 <graingert> Eliel: and export is different to the db format
405 2011-10-30 19:50:07 <graingert> Eliel: the db can be machine dependant
406 2011-10-30 19:50:38 <graingert> Eliel: multibit seem to have gone for a proto format
407 2011-10-30 19:50:52 <graingert> I'm personally not into proto and would rather have json
408 2011-10-30 19:50:56 <BlueMatt> also, now that I think about it, I have no problem as long with os/machine-dependent db formats as long as there is a clean export option
409 2011-10-30 19:50:58 <graingert> for it's much greater support
410 2011-10-30 19:51:25 <graingert> which seems to be the way gpg works
411 2011-10-30 19:51:32 <graingert> standard aa export options
412 2011-10-30 19:51:38 <graingert> and you can store them however you want
413 2011-10-30 19:53:48 <BlueMatt> (also there is already a json export format as used by sipa's rpc export/import stuff)
414 2011-10-30 19:53:58 <graingert> BlueMatt gpg --export -a "User Name" > public.key
415 2011-10-30 19:54:02 <graingert> for bitcoin
416 2011-10-30 19:54:04 <graingert> I propose
417 2011-10-30 19:54:17 <CIA-101> bitcoinjs/node-bitcoin-p2p: Stefan Thomas master * rb823191 / lib/scriptinterpreter.js : Catch errors during signature verification and treat signature as invalid. - http://git.io/Z-EiMA
418 2011-10-30 19:54:23 <BlueMatt> meh, not my job to make an export decision
419 2011-10-30 19:54:40 <graingert> BlueMatt: who's is it ? gavin?
420 2011-10-30 19:54:51 <BlueMatt> essentially
421 2011-10-30 19:55:11 <graingert> OP_EVAL seems his priority atm
422 2011-10-30 19:57:40 <graingert> BlueMatt: https://bitcointalk.org/index.php?topic=50368
423 2011-10-30 19:57:45 <graingert> note my edit
424 2011-10-30 19:58:15 <graingert> sounds good?
425 2011-10-30 20:01:43 <BlueMatt> yea, though I would note that afaik not many people really use ppas much, so conflicts should be a very, very, very minor issue
426 2011-10-30 20:04:49 <BlueMatt> also, if they do their packages properly, they wont really conflict...
427 2011-10-30 20:06:33 <graingert> not many people really use ppas?
428 2011-10-30 20:06:49 <graingert> it's the recomended way of installing unofficial software
429 2011-10-30 20:07:04 <graingert> see ombubuntu or webupd8
430 2011-10-30 20:07:21 <BlueMatt> well most software is in the repos
431 2011-10-30 20:09:12 <graingert> BlueMatt: https://github.com/bitcoin/bitcoin/pull/220
432 2011-10-30 20:09:27 <BlueMatt> yes, I know
433 2011-10-30 20:09:33 <BlueMatt> thats what I referenced earlier
434 2011-10-30 20:09:39 <BlueMatt> <BlueMatt> (also there is already a json export format as used by sipa's rpc export/import stuff)
435 2011-10-30 20:09:41 <graingert> BlueMatt: oh I saw a different link
436 2011-10-30 20:09:48 <graingert> oh that
437 2011-10-30 20:10:22 <graingert> once that's in we can think about db stuff then
438 2011-10-30 20:10:29 <graingert> awesome so problem solved?
439 2011-10-30 20:11:02 <BlueMatt> imo
440 2011-10-30 20:11:52 <graingert> nice
441 2011-10-30 20:13:34 <graingert> !later tell gavinanderson it would be nice if wallet import export (https://github.com/bitcoin/bitcoin/pull/220) could be pulled http://bitcoinstats.com/irc/bitcoin-dev/logs/2011/10/30/5#l2054246 so we don't have to worry about machine dependant wallets
442 2011-10-30 20:13:35 <gribble> The operation succeeded.
443 2011-10-30 20:13:57 <graingert> woops that link was supposed to go at the end
444 2011-10-30 20:14:00 <graingert> oh well
445 2011-10-30 20:16:05 <luke-jr> graingert: there's a good reason it hasn't been pulled
446 2011-10-30 20:16:16 <graingert> luke-jr: oh dear
447 2011-10-30 20:17:13 <luke-jr> graingert: import a key and all of a sudden there's a bunch of debits on your accounts
448 2011-10-30 20:17:17 <luke-jr> unrelated debits
449 2011-10-30 20:18:29 <graingert> oh dear
450 2011-10-30 20:20:35 <graingert> well once that bug is fixed then
451 2011-10-30 20:41:23 <luke-jr> graingert: half the problem is that it *isn't* a bug :/
452 2011-10-30 20:43:09 <graingert> ah
453 2011-10-30 20:43:20 <graingert> do you get all the debits of the imported address?
454 2011-10-30 20:43:53 <graingert> eg isn't that intentional?
455 2011-10-30 20:45:54 <luke-jr> it really depends on your intention of the import
456 2011-10-30 20:46:05 <luke-jr> if you want to import a balance, you don't necessarily want the full history
457 2011-10-30 20:46:12 <luke-jr> if you're restoring a backup, you do
458 2011-10-30 20:46:30 <luke-jr> actually hmm
459 2011-10-30 20:46:47 <luke-jr> case A (importing a balance), you don't *really* want to import the key either, just resend anything it controls to a secure address
460 2011-10-30 20:46:48 <graingert> if you import a key pair
461 2011-10-30 20:47:06 <graingert> you want their history
462 2011-10-30 20:47:47 <Eliel> yes, if you didn't care for the history, you'll send the coins. If you care about the history, you'll import it.
463 2011-10-30 20:48:29 <Eliel> in most cases, I'd expect the amount if history in your wallet to be the same, if it's just one key.
464 2011-10-30 20:51:24 <luke-jr> perhaps import/export should be restricted to full wallets only, and have an additional function for "import this key as a redirector, immediately resending funds to a trusted key, and ignoring its history"
465 2011-10-30 20:55:17 <CIA-101> libbitcoin: genjix * r8494687870bd / (5 files in 4 dirs): Updated nettest for latest changes.
466 2011-10-30 21:03:00 <Eliel> luke-jr: in what case would the history not be related to the address? example pelase.
467 2011-10-30 21:04:32 <lfm> eliel a gift
468 2011-10-30 21:04:32 <luke-jr> Eliel: in most cases, actually
469 2011-10-30 21:04:52 <luke-jr> Eliel: if you send someone 1 BTC, that 1 BTC could be from *any* address you have the key for
470 2011-10-30 21:05:07 <luke-jr> even one you might export later, unrelated to the transaction you're about to make
471 2011-10-30 21:06:02 <Eliel> I'd expect import/export keys to be mostly done between one's own wallets and sends for transactions to others but in that case it would make sense, yes.
472 2011-10-30 21:06:35 <Eliel> I mean, if you get a private key from someone else, it makes no sense to just import it. For security reasons, you'd want to transfer the bitcoins to a secure address.
473 2011-10-30 21:07:30 <gmaxwell> Eliel: I think thats how import will have to be implemented generally because users won't realize how dangerous any other kind of import is if misused.
474 2011-10-30 21:07:51 <gmaxwell> It's sort of subtle what a mess imports can make.
475 2011-10-30 21:08:51 <Eliel> true. Unless there's an easy question people can answer that can settle whether or not the keys should be just imported or not.
476 2011-10-30 21:09:27 <Eliel> I mean, the other reason to import the keys from another wallet is so you can receive money through them.
477 2011-10-30 21:09:47 <gmaxwell> You can still super confuse yourself even with just your own keys. E.g. say you have historical transactions which use a key you just imported in addition to keys you didn't import. What should the history show?
478 2011-10-30 21:10:38 <Eliel> true. I guess ther distinction between whole wallet import and key import needs to be made.
479 2011-10-30 21:11:14 <gmaxwell> Right now IIRC you won't see a txn in the history unless you have all of the relevant keys. .. if you allow spliting you can end up with txn showing up twice (in two wallets) which is just about as bad as showing up nowhere.
480 2011-10-30 21:12:11 <graingert> in that case I propose invalidating the key, and then keeping the key and automatically invalidating it on new tx into it
481 2011-10-30 21:12:25 <graingert> ie pulling all money from it, and pulling any new money into it out
482 2011-10-30 21:13:03 <graingert> it would be usefull to put a record on the block chain to say you're changing the key for an address :p
483 2011-10-30 21:13:22 <Eliel> would having two import methods work then? one called "wallet merge" and the other "import key"?
484 2011-10-30 21:13:23 <graingert> ie all bitcoin to this address can be sent using this other address
485 2011-10-30 21:13:51 <gmaxwell> graingert: thats the best I can come up with but it means every time you double-import you'll have a doublespend war.
486 2011-10-30 21:13:53 <graingert> Eliel: how about import money or import keys
487 2011-10-30 21:14:10 <graingert> import keys you get a sort of harfling history
488 2011-10-30 21:14:13 <Eliel> the "wallet merge" dialog might have a checkbox you can check to indicate whether the keys in the imported wallet can be trusted to be secure.
489 2011-10-30 21:14:38 <gmaxwell> Eliel: Sure it's secure! only my spouse has another wallet with all of those!
490 2011-10-30 21:14:52 <gmaxwell> (and then you're doublespending each other and getting funds stuck)
491 2011-10-30 21:15:26 <gmaxwell> E.g. if I import a couple of your inputs in your wallet without you removing them, then if we spend at ~the same time we'll probably end up with stuck transactions.
492 2011-10-30 21:15:48 <Eliel> uh, right.
493 2011-10-30 21:16:01 <gmaxwell> E.g. I spend {E1 G1} and you spend {E1 E2}  .. one of these txn with lose, and either G1 and E2 become unspendable until someone hacks their wallet.
494 2011-10-30 21:16:25 <gmaxwell> So yea, you think anyone is going to answer those questions correctly?
495 2011-10-30 21:16:46 <gmaxwell> I can say that _I_ wouldn't I didn't realize all these problems existed until someone pointed it out to me.
496 2011-10-30 21:16:47 <graingert> in that case what should be supported
497 2011-10-30 21:16:51 <graingert> is replacing your wallet
498 2011-10-30 21:16:55 <graingert> with another
499 2011-10-30 21:17:02 <graingert> and being able to switch between them
500 2011-10-30 21:17:30 <graingert> importing a wallet will export your old one and replace it
501 2011-10-30 21:17:42 <gmaxwell> Yea, multi-wallet support... Also, merge a full wallet that warns to not to use it in isolation anymore..  And a load-bitcoins-from keys is probably okay too. But what that should do is not show you any evidence of success until the merge has had several confirmations.
502 2011-10-30 21:18:06 <gmaxwell> (and it should show failure if someone else successfully did the merge)
503 2011-10-30 21:18:16 <graingert> sweet
504 2011-10-30 21:18:22 <graingert> so it that problem 2 solved?
505 2011-10-30 21:18:46 <gmaxwell> Yes, well. So go code it.. what SIPA coded just does the basic thing which seems to be unworkable.
506 2011-10-30 21:19:01 <devrandom> BlueMatt: thanks
507 2011-10-30 21:19:13 <BlueMatt> np?
508 2011-10-30 21:19:19 <graingert> lol