From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1QfzOU-00053q-25 for bitcoin-development@lists.sourceforge.net; Sun, 10 Jul 2011 19:10:18 +0000 X-ACL-Warn: Received: from rhcavuit02.kulnet.kuleuven.be ([134.58.240.130] helo=cavuit02.kulnet.kuleuven.be) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1QfzOS-0002YM-Hp for bitcoin-development@lists.sourceforge.net; Sun, 10 Jul 2011 19:10:18 +0000 X-KULeuven-Envelope-From: sipa@ulyssis.org X-Spam-Status: not spam, SpamAssassin (not cached, score=-48.798, required 5, autolearn=disabled, DKIM_ADSP_CUSTOM_MED 0.00, FREEMAIL_FROM 0.00, KUL_SMTPS -50.00, NML_ADSP_CUSTOM_MED 1.20) X-KULeuven-Scanned: Found to be clean X-KULeuven-ID: 5809E12808A.A3B4D X-KULeuven-Information: Katholieke Universiteit Leuven Received: from smtps01.kuleuven.be (smtpshost01.kulnet.kuleuven.be [134.58.240.74]) by cavuit02.kulnet.kuleuven.be (Postfix) with ESMTP id 5809E12808A; Sun, 10 Jul 2011 21:10:09 +0200 (CEST) Received: from smtp.ulyssis.org (mail.ulyssis.student.kuleuven.be [193.190.253.235]) by smtps01.kuleuven.be (Postfix) with ESMTP id 0917731E702; Sun, 10 Jul 2011 21:10:09 +0200 (CEST) Received: from wop.ulyssis.org (wop.intern.ulyssis.org [192.168.0.182]) by smtp.ulyssis.org (Postfix) with ESMTP id 0CC8310067; Sun, 10 Jul 2011 21:11:34 +0200 (CEST) Received: by wop.ulyssis.org (Postfix, from userid 615) id 2E82687C1B0; Sun, 10 Jul 2011 21:10:07 +0200 (CEST) Date: Sun, 10 Jul 2011 21:10:07 +0200 X-Kuleuven: This mail passed the K.U.Leuven mailcluster From: Pieter Wuille To: Matt Corallo Message-ID: <20110710191005.GA6467@ulyssis.org> References: <1309801974.3423.80.camel@Desktop666> <1309811972.29355.19.camel@Desktop666> <1309828239.29355.28.camel@Desktop666> <1310307677.2230.5.camel@Desktop666> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1310307677.2230.5.camel@Desktop666> X-PGP-Key: http://sipa.ulyssis.org/pubkey.asc User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Score: 1.2 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (pieter.wuille[at]gmail.com) 0.0 DKIM_ADSP_CUSTOM_MED No valid author signature, adsp_override is CUSTOM_MED 1.2 NML_ADSP_CUSTOM_MED ADSP custom_med hit, and not from a mailing list 0.0 AWL AWL: From: address is in the auto white-list X-Headers-End: 1QfzOS-0002YM-Hp Cc: bitcoin-development Subject: Re: [Bitcoin-development] Encrypted Wallet Backward Compatibility X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jul 2011 19:10:18 -0000 On Sun, Jul 10, 2011 at 04:21:17PM +0200, Matt Corallo wrote: > > At Luke's suggestion, I did a bit more digging and was able to find a > data structure in wallet settings that should cause all versions (well > all versions since Bitcoin was in github, and probably before then) to > crash on load instead of making a new wallet or opening in some bizarre > half-state. I just put an empty object in addrIncoming (nfc what it was > used for, but it will get the desire effect and it isnt used anywhere in > the code aside from its definition). > You can see the commit at > https://github.com/TheBlueMatt/bitcoin/commit/2e8383469d7e12a495b3a1dbd41a8d211ff34fe8 > Does anyone disagree and think a different solution would work better? Though giving an mostly incomprehensible/unrelated error is never nice to the user, i believe it's better than creating an empty wallet and letting the user wonder where his wallet went. This way, we fail soon and don't ever get a corrupt wallet. > This resolves all known issues and suggestions that I know of on newenc > except for the invalid mlock calculations, which I will go fix right > now. So...aside from that bug does anyone have any remaining > suggestions/blockers on newenc and, if not, can we get final ACKs on it? ACK on newenc, and thanks for all the work you put in it already. -- Pieter