📅 Original date posted:2014-03-12
📝 Original message:On Wed, Mar 12, 2014 at 2:39 PM, Pavol Rusnak <stick at gk2.sk> wrote:
> On 03/12/2014 08:26 PM, Jean-Paul Kogelman wrote:
> > So upon entering a password with a typo, the user will not be notified
> of an
> > error, but be presented with a wallet balance of 0, after the blockchain
> has
> > been scanned. I'm sorry, but that's not the kind of experience I would
> want to
> > present to my users.
>
> Sure, you can have either plausible deniability or typo checking, not
> both at the same time.
>
>
The proposed BIP uses a bloom filter, so it has both plausible deniability *and
*typo checking. The bloom filter is optimized for two elements and will
catch something like 99.9975% of typos, despite allowing two different
passwords.
> Would you care to elaborate how optional outsourcing of the KDF breaks
> > compatibility?
>
> I'm afraid one would end up with code generated in one client that is
> unusable in a different client, because the client's developer thought
> that using fancier algorithm instead of the proposed ones was a good idea.
>
>
This is clearly in violation of the spec. You could argue this about
anything in Bitcoin. What if a developer decided to replace SHA256 with
SHA3 in their implementation of a Bitcoin client? Obviously this would
cause issues.
Will
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140312/46fa5b6b/attachment.html>;
William Yager [ARCHIVE] /
npub1mt…qzgqk
2023-06-07 15:15:15
in reply to nevent1q…rcyf
Author Public Key
npub1mtzsyxnmqze93rehd90508tdg7k4mwktknmtamqam55446tkaq7qnqzgqkPublished at
2023-06-07 15:15:15Event JSON
{
"id": "5bf3563520b5c6c586c288a786c3a30d333f076ee1a4c1727dfb3b8216eb3fc7",
"pubkey": "dac5021a7b00b2588f37695f479d6d47ad5dbacbb4f6beec1ddd295ae976e83c",
"created_at": 1686150915,
"kind": 1,
"tags": [
[
"e",
"e2b06c13dda090fd765a6fae17847c84821995c150a37c86a1dca89140911552",
"",
"root"
],
[
"e",
"ed420a0bf7f4b476f2a9754cf7dac9a15e771b94be2eed226b76061a58d6692a",
"",
"reply"
],
[
"p",
"7631397e469f47f3535567311f5f7c17129e0ff2cb253df015e3d92ddfd92c63"
]
],
"content": "📅 Original date posted:2014-03-12\n📝 Original message:On Wed, Mar 12, 2014 at 2:39 PM, Pavol Rusnak \u003cstick at gk2.sk\u003e wrote:\n\n\u003e On 03/12/2014 08:26 PM, Jean-Paul Kogelman wrote:\n\u003e \u003e So upon entering a password with a typo, the user will not be notified\n\u003e of an\n\u003e \u003e error, but be presented with a wallet balance of 0, after the blockchain\n\u003e has\n\u003e \u003e been scanned. I'm sorry, but that's not the kind of experience I would\n\u003e want to\n\u003e \u003e present to my users.\n\u003e\n\u003e Sure, you can have either plausible deniability or typo checking, not\n\u003e both at the same time.\n\u003e\n\u003e\nThe proposed BIP uses a bloom filter, so it has both plausible deniability *and\n*typo checking. The bloom filter is optimized for two elements and will\ncatch something like 99.9975% of typos, despite allowing two different\npasswords.\n\n\u003e Would you care to elaborate how optional outsourcing of the KDF breaks\n\u003e \u003e compatibility?\n\u003e\n\u003e I'm afraid one would end up with code generated in one client that is\n\u003e unusable in a different client, because the client's developer thought\n\u003e that using fancier algorithm instead of the proposed ones was a good idea.\n\u003e\n\u003e\nThis is clearly in violation of the spec. You could argue this about\nanything in Bitcoin. What if a developer decided to replace SHA256 with\nSHA3 in their implementation of a Bitcoin client? Obviously this would\ncause issues.\n\nWill\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140312/46fa5b6b/attachment.html\u003e",
"sig": "e8c222c234648a3d9de0db3121471834820dcbec34748d35e237cb74ff3fdc5f1aecf3c2f0eb7d5b877c3f0a147f6c0f37e6910c9b1ab2305df721bedbd9330f"
}