Does bitcoin properly handle the case of a hash collision? no - because it is considered too unlikely. The case of I_L >= n is also astronomically unlikely, so it's more a matter of improved performance and simpler data structures under expected circumstances and taking that less than 1 in 2^127 chance that it will fail, in which case we can recover by moving everything over to a new tree.
-Eric Lombrozo On Aug 9, 2014, at 5:34 PM, second isogeny <secondisog...@gmail.com> wrote: > > Does anyone see any concerns when it comes to security of the proposed > > change? > > Yes. This proposal is less secure. > > It is incompatible in theory with existing implementations of the > specification. The incompatibility is also a potentially a security > problem because it may cause users to believe a key is worthless when > it is not or to lose funds when they are unable to spend them. > > It is also an untimely proposal and would be inconsiderate other parties > who have done the work to produce correct and compatible implementations. > > > In case I_L >= n assign I_L := I_L mod n. > > This will make the selection of private keys uneven. > > The unevenness is small and it is unlikely to very matter much but it > is objectively less secure. Future advances in cryptography may make > the distinction more important. The change would eliminate any hope of > the specification ever having provable security equal to random keys. > > The bignum modulo operation also requires complex additional logic and is > just as likely to remain untested in implementations, though unit-testing > can test these cases by replacing the hash function. > > Because of layering no suitable modulo may be available and an incorrect > implementation could create a devastating weakness, like reflecting a > large class of keys to a small number of values. A similar error would > be unlikely for an incorrect implementation of skipping and someone who > managed to still fail would likely have failed either way. > > > most of the implementations don't do the checking at all, because tjen > > it's rather hard at application level to implement skipping logic. OTOH > > There are many corner cases which must be handled in cryptographic > software. > > You must handle the point at infinity cases, you must handle the signature > having a value of zero (or you leak the private key), in the point > arithemetics you must handle the special case of adding colinear points. > > If someone is unprepared to deal with these and many other complications > they may want to leave writing this kind of software for other people. > > ------------------------------------------------------------------------------ > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
signature.asc
Description: Message signed with OpenPGP using GPGMail
------------------------------------------------------------------------------
_______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
