📅 Original date posted:2016-01-11
📝 Original message:On Fri, Jan 8, 2016 at 4:50 PM, Gavin Andresen via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> And to fend off the messag that I bet somebody is composing right now:
>
> Yes, I know about a "security first" mindset. But as I said earlier in the
> thread, there is a tradeoff here between crypto strength and code
> complexity, and "the strength of the crypto is all that matters" is NOT
> security first.
If the crypto code is properly encapsulated, the code complexity costs
of choosing one hashing function over another should be non-existent.
You made the space argument which is valid, but in my opinion code
complexity shouldn't be a valid concern in this discussion.
As a maybe uninteresting anecdote, I proposed the asset IDs in
https://github.com/ElementsProject/elements/tree/alpha-0.10-multi-asset
to do the same ```ripemd160 . sha256``` choice that Mark Friedenbach
had proposed and I had approved for
https://github.com/jtimon/freimarkets/blob/master/doc/freimarkets_specs.org#asset-tags
. More humble than me, he admitted he had made a design mistake much
earlier than me, who (maybe paradoxically) probably had less knowledge
for making crypto choices at the low level. In the end I was convinced
with examples I failed to write down for documentation and can't
remember.
That's not to say I have anything to say in this debate other than
code complexity (which I do feel qualified to talk about) shouldn't be
a concern in this debate. Just want to focus the discussion on what it
should be: security vs space tradeoff.
Since I am admittedly in doubt, I tend to prefer to play safe, but
neither my feelings nor my anecdote are logical arguments and should,
therefore, be ignored for any conclusions in the ```ripemd160 .
sha256``` vs sha256d debate. Just like you non-sequitor "sha256d will
lead to more code complexity", if anything, sha256d should be simpler
than ```ripemd160 . sha256``` (but not simpler enough that it matters
much).
Jorge Timón [ARCHIVE] /
npub1fx…cl2d8
2023-06-07 17:47:46
in reply to nevent1q…35ee
Author Public Key
npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8Seen on
wss://relay.noswhere.comPublished at
2023-06-07 17:47:46Event JSON
{
"id": "6f7452c13dbcd3a37bbb9471cb95ee066b9c87df900892d68a9164fe3349e1f8",
"pubkey": "498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84",
"created_at": 1686160066,
"kind": 1,
"tags": [
[
"e",
"e1f46f49861d474f81d81bf43d690af02c9b35e1c9c4fe5cc415112a34c1c041",
"",
"root"
],
[
"e",
"4ba3c87b784bf402ca6006f10e4c8f3b0cfe4112ed2846bf3b637ffdf5fa504c",
"",
"reply"
],
[
"p",
"857f2f78dc1639e711f5ea703a9fc978e22ebd279abdea1861b7daa833512ee4"
]
],
"content": "📅 Original date posted:2016-01-11\n📝 Original message:On Fri, Jan 8, 2016 at 4:50 PM, Gavin Andresen via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e And to fend off the messag that I bet somebody is composing right now:\n\u003e\n\u003e Yes, I know about a \"security first\" mindset. But as I said earlier in the\n\u003e thread, there is a tradeoff here between crypto strength and code\n\u003e complexity, and \"the strength of the crypto is all that matters\" is NOT\n\u003e security first.\n\nIf the crypto code is properly encapsulated, the code complexity costs\nof choosing one hashing function over another should be non-existent.\nYou made the space argument which is valid, but in my opinion code\ncomplexity shouldn't be a valid concern in this discussion.\n\nAs a maybe uninteresting anecdote, I proposed the asset IDs in\nhttps://github.com/ElementsProject/elements/tree/alpha-0.10-multi-asset\nto do the same ```ripemd160 . sha256``` choice that Mark Friedenbach\nhad proposed and I had approved for\nhttps://github.com/jtimon/freimarkets/blob/master/doc/freimarkets_specs.org#asset-tags\n. More humble than me, he admitted he had made a design mistake much\nearlier than me, who (maybe paradoxically) probably had less knowledge\nfor making crypto choices at the low level. In the end I was convinced\nwith examples I failed to write down for documentation and can't\nremember.\n\nThat's not to say I have anything to say in this debate other than\ncode complexity (which I do feel qualified to talk about) shouldn't be\na concern in this debate. Just want to focus the discussion on what it\nshould be: security vs space tradeoff.\nSince I am admittedly in doubt, I tend to prefer to play safe, but\nneither my feelings nor my anecdote are logical arguments and should,\ntherefore, be ignored for any conclusions in the ```ripemd160 .\nsha256``` vs sha256d debate. Just like you non-sequitor \"sha256d will\nlead to more code complexity\", if anything, sha256d should be simpler\nthan ```ripemd160 . sha256``` (but not simpler enough that it matters\nmuch).",
"sig": "cb81d36ad7a49eb841498fb65de9781cd2936c170ed6b84835e34ff39aaba00d7934c9b6569508926bfd6f2b0b444d04365f264cd02d4fb3223bed0657bc9018"
}