{"type":"rich","version":"1.0","author_name":"npub1ac86vemj7ce5z8jyxt39rna3tvwql6xd30ha3vxcd6esysp23d9qrlswfj","author_url":"https://nostr.ae/npub1ac86vemj7ce5z8jyxt39rna3tvwql6xd30ha3vxcd6esysp23d9qrlswfj","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2016-01-08\n📝 Original message:Tricky choice. On the one hand I had spotted this too before and maybe\none or two more exceptions to bitcoin's 128-bit security target and\nbeen vaguely tut-tutting about them in the background.  It's kind of a\nviolation of crypto rule of thumb that you want to balance things and\nnot have odd weak points as Watson was implying, it puts you closer to\nthe margin if there is a slip or other problem so you have an\nimbalanced crypto format.\n\nOn the other hand it's not currently a problem as such and it's less\nchange and slightly more compact.\n\nRIPEMD probably is less well reviewed than SHA2.  However SHA1 has\nproblems, and SHA2 is a bigger SHA1 basically so, hence the NIST\nmotivation for SHA3 designed to fix the design flaw in SHA1 (and SHA2\nin principle).\n\nSo then if we agree with this rule of thumb (and not doing so would\nfly against best practices which we probably shouldnt look to do in\nsuch a security focussed domain) then what this discussion is more\nabout is when is a good time to write down tech debt.\n\nI think that comes to segregated-witness itself which writes down a\ntidily organised by lines of code robust fix to a bunch of long\nstanding problems.\n\nDoing a 2MB hard-fork in comparison fixes nothing really.  Leaving\nknown issues to bake in for another N years eventually builds up on\nyou (not even in security just in software engineering) as another\nrule of thumb.  I mean if we dont fix it now that we are making a\nchange that connects, when will we?\n\nIn software projects I ran we always disguised the cost of tech-debt\nas non-negotiable baked into our estimates without a line item to\nescape the PHB syndrome of haggling for features instead of tech debt\n(which is _never_ a good idea:)\n\nPragmatism vs refactoring as you go.\n\nBut for scale I think segregated-witness does offer the intriguing\nnext step of being able to do 2 of 2, 3 of 3 and N of N which give\nsize of one sig multisig (indistinguishable even for privacy) as well\nas K of N key tree sigs, which are also significantly more compact.\n\nThere was also the other thing I mentioned further up the thread that\nif we want to take an approach of living with little bit of bloat from\ngetting back to a universal 128-bit target, there are still some\nfixable bloat things going on:\na) sending pubKey in the signature vs recovery (modulo interference\nwith Schnorr batch verify compatibility*);\nb) using the PubKey instead of PKH in the ScriptPubKey, though that\nloses the nice property of of not having the key to do DL attacks on\nuntil the signed transaction is broadcast;\nc) I think there might be a way to combine hash \u0026 PubKey to keep the\ndelayed PubKey publication property and yet still save the bloat of\nhaving both.\n\n* I did suggest to Pieter that you could let the miner decide to forgo\nSchnorr batch verifiability to get compaction from recovery - the pub\nkey could be optionally elided from the scriptSig serialisation by the\nminer.\n\nThe other thing we could consider is variable sized hashes (\u0026 a few\npubkey size choices) that is software complexity however.  We might be\nbetter of focussing on the bigger picture like IBLT/weak-blocks and\nbigger wins like MAST, multiSig Schnorr \u0026 key tree sigs.\n\nDidnt get time to muse on c) but a nice crypto question for someone :)\n\nAnother thing to note is combining has been known to be fragile to bad\ninteractions or unexpected behaviours.  This paper talks about things\ntradeoffs and weaknesses in hash combiners.\nhttp://tuprints.ulb.tu-darmstadt.de/2094/1/thesis.lehmann.pdf\n\nWeak concept NACK I think for losing a cleanup opportunity to store it\nup for the future when there is a reasonable opportunity to fix it?\n\nAdam\n\n\nOn 8 January 2016 at 15:34, Watson Ladd via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e On Fri, Jan 8, 2016 at 4:38 AM, Gavin Andresen via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e On Fri, Jan 8, 2016 at 7:02 AM, Rusty Russell \u003crusty at rustcorp.com.au\u003e wrote:\n\u003e\u003e\u003e\n\u003e\u003e\u003e Matt Corallo \u003clf-lists at mattcorallo.com\u003e writes:\n\u003e\u003e\u003e \u003e Indeed, anything which uses P2SH is obviously vulnerable if there is\n\u003e\u003e\u003e \u003e an attack on RIPEMD160 which reduces it's security only marginally.\n\u003e\u003e\u003e\n\u003e\u003e\u003e I don't think this is true?  Even if you can generate a collision in\n\u003e\u003e\u003e RIPEMD160, that doesn't help you since you need to create a specific\n\u003e\u003e\u003e SHA256 hash for the RIPEMD160 preimage.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Even a preimage attack only helps if it leads to more than one preimage\n\u003e\u003e\u003e fairly cheaply; that would make grinding out the SHA256 preimage easier.\n\u003e\u003e\u003e AFAICT even MD4 isn't this broken.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e It feels like we've gone over that before, but I can never remember where or\n\u003e\u003e when. I believe consensus was that if we were using the broken MD5 in all\n\u003e\u003e the places we use RIPEMD160 we'd still be secure today because of Satoshi's\n\u003e\u003e use of nested hash functions everywhere.\n\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e But just with Moore's law (doubling every 18 months), we'll worry about\n\u003e\u003e\u003e economically viable attacks in 20 years.[1]\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e That's far enough away that I would choose simplicity, and have all SW\n\u003e\u003e\u003e scriptPubKeys simply be \"\u003c0\u003e RIPEMD(SHA256(WP))\" for now, but it's\n\u003e\u003e\u003e not a no-brainer.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e Lets see if I've followed the specifics of the collision attack correctly,\n\u003e\u003e Ethan (or somebody) please let me know if I'm missing something:\n\u003e\u003e\n\u003e\u003e So attacker is in the middle of establishing a payment channel with\n\u003e\u003e somebody. Victim gives their public key, attacker creates the innocent\n\u003e\u003e fund-locking script  '2 V A 2 CHECKMULTISIG' (V is victim's public key, A is\n\u003e\u003e attacker's) but doesn't give it to the victim yet.\n\u003e\u003e\n\u003e\u003e Instead they then generate about 2^81scripts that are some form of\n\u003e\u003e pay-to-attacker ....\n\u003e\u003e ... wait, no that doesn't work, because SHA256 is used as the inner hash\n\u003e\u003e function.  They'd have to generate 2^129 to find a cycle in SHA256.\n\u003e\n\u003e For 2^80 they simply generate 2^80 scripts that look innocent, and\n\u003e 2^80 that are not. With high probability there is a collision. I agree\n\u003e that most cryptanalysis won't work because of the nesting, but 2^80 is\n\u003e not good.\n\u003e\u003e\n\u003e\u003e Instead, they .. what? I don't see a viable attack unless RIPEMD160 and\n\u003e\u003e SHA256 (or the combination) suffers a cryptographic break.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e --\n\u003e\u003e --\n\u003e\u003e Gavin Andresen\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\n\u003e\n\u003e\n\u003e --\n\u003e \"Man is born free, but everywhere he is in chains\".\n\u003e --Rousseau.\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"}