š
Original date posted:2017-02-22
š Original message:On Tue, Feb 21, 2017 at 02:00:23PM -0800, Bram Cohen via bitcoin-dev wrote:
> When one side of a node is empty and the other contains exactly two things
> the secure hash of the child is adopted verbatim rather than rehashing it.
> This roughly halves the amount of hashing done, and makes it more resistant
> to malicious data, and cleans up some implementation details, at the cost
> of some extra complexity.
Note that this is a use-case specific concept of an idea I'm calling a
"generalized commitment"
A commitment scheme needs only have the property that it's not feasible to find
two messages m1 and m2 that map to the same commitment; it is *not* required
that it be difficult to find m given the commitment. Equally, it's not required
that commitments always be the same size.
So a perfectly reasonable thing to do is design your scheme such that the
commitment to short messages is the message itself! This adds just a single bit
of data to the minimum serialized size(1) of the commitment, and in situations
where sub-digest-sized messages are common, may overall be a savings.
Another advantage is that the scheme becomes more user-friendly: you *want*
programmers to notice when a commitment is not effectively hiding the message!
If you need message privacy, you should implement an explicit nonce, rather
than relying on the data to not be brute-forcable.
1) The more I look at these systems, the more I'm inclined to consider
bit-granularity serialization schemes... Heck, sub-bit granularity has
advantages too in some cases, e.g. by making all possible inputs to the
deserializer be valid.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170222/c6df5d46/attachment.sig>;
Peter Todd [ARCHIVE] /
npub1m2ā¦a2np2
2023-06-07 17:56:26
in reply to nevent1qā¦74qj
Author Public Key
npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2Published at
2023-06-07 17:56:26Event JSON
{
"id": "f83c59ae966c8651b570e1dec824a2cc24fa264476c87e9de712ab08fad2ca0a",
"pubkey": "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa",
"created_at": 1686160586,
"kind": 1,
"tags": [
[
"e",
"6c6e6cfb03a71f1ed835d1014a9970e74fef5ff22338252d81f441d50df18784",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "š
Original date posted:2017-02-22\nš Original message:On Tue, Feb 21, 2017 at 02:00:23PM -0800, Bram Cohen via bitcoin-dev wrote:\n\u003e When one side of a node is empty and the other contains exactly two things\n\u003e the secure hash of the child is adopted verbatim rather than rehashing it.\n\u003e This roughly halves the amount of hashing done, and makes it more resistant\n\u003e to malicious data, and cleans up some implementation details, at the cost\n\u003e of some extra complexity.\n\nNote that this is a use-case specific concept of an idea I'm calling a\n\"generalized commitment\"\n\nA commitment scheme needs only have the property that it's not feasible to find\ntwo messages m1 and m2 that map to the same commitment; it is *not* required\nthat it be difficult to find m given the commitment. Equally, it's not required\nthat commitments always be the same size.\n\nSo a perfectly reasonable thing to do is design your scheme such that the\ncommitment to short messages is the message itself! This adds just a single bit\nof data to the minimum serialized size(1) of the commitment, and in situations\nwhere sub-digest-sized messages are common, may overall be a savings.\n\n\nAnother advantage is that the scheme becomes more user-friendly: you *want*\nprogrammers to notice when a commitment is not effectively hiding the message!\nIf you need message privacy, you should implement an explicit nonce, rather\nthan relying on the data to not be brute-forcable.\n\n\n1) The more I look at these systems, the more I'm inclined to consider\nbit-granularity serialization schemes... Heck, sub-bit granularity has\nadvantages too in some cases, e.g. by making all possible inputs to the\ndeserializer be valid.\n\n-- \nhttps://petertodd.org 'peter'[:-1]@petertodd.org\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 455 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170222/c6df5d46/attachment.sig\u003e",
"sig": "6455f67be0b8c03d5a694534d84e683ce810701fbd9760f573316c9efd70be33195ce9ba2010170f32d6aba05f814e1932834fd087903ee7bb26e019d65996a3"
}