📅 Original date posted:2019-05-09
📝 Original message:> Therefore, the input==output check is sufficient: if I use the same
> set of signers for an input and an output, I can be sure that the
> change goes to the same multisig wallet.
This is sufficient, in a simple case.
I consider cases where spending from different wallets ('wallet
compartments') can be aggregated into one transaction, for efficiency
and convenience in certain circumstances. (ex: legacy addresses that
cannot be abandoned due to users still sending to them, but managing
them separately is inconvenient; wallet 'compartments' that each have
different multisig policies and spending priorities, and change would
go to most secure compartment used, etc.)
This is most likely a 'borader problem', as you said, but this is just
what my code already does, although with stateful signers that
store trusted xpubs. I had an idea how to apply this to stateless hw
wallets, and shared it.
> > This would allow to distinguish the trusted output even if the
> > inputs are not all derived from the same set of xpubs, that could
> > happen in more complex scenarios (batching, key rotation, etc.),
> > and can possibly be used to have several different types of
> > 'trusted' outputs.
>
> This seems to be an attempt at a different, much broader problem. And
> it won't help if the attacker can replay a different trusted-xpub
> package (e.g., one that contains a revoked previously compromised
> key).
The auxiliary text can be constructed to include some code word that
would mark 'epoch' of the package, and will be displayed prominently.
Upon compromise, new trusted-xpub packages would use different 'epoch'
code word. This is one method to make it stateless (stateful way would
be to just have a counter inside hw wallet and check package version
against it).
Dmitry Petukhov [ARCHIVE] /
npub10r…9afdw
2023-06-07 18:17:53
in reply to nevent1q…y39w
Author Public Key
npub10r66s2stvnancx9axwnfc5a34asjkwkgmkq7ztm5hf30x7fa4szsv9afdwPublished at
2023-06-07 18:17:53Event JSON
{
"id": "7504ce8b6c28f30194a9d458cab214169b04edee802e5b4caa28a35c449fecdd",
"pubkey": "78f5a82a0b64fb3c18bd33a69c53b1af612b3ac8dd81e12f74ba62f3793dac05",
"created_at": 1686161873,
"kind": 1,
"tags": [
[
"e",
"e8ccb894d086c83c3d0b88d47f67ce9c654e9ff574985390aa744acf7402f91e",
"",
"root"
],
[
"e",
"e8e6e02cc69958079fb3612c966439a2bcccf2ba5ed773ca87de2fb9a054b781",
"",
"reply"
],
[
"p",
"ca8c3347ed582ff8fb2e2445e0b760ad336b2d74ae0d50208713d2516a316c04"
]
],
"content": "📅 Original date posted:2019-05-09\n📝 Original message:\u003e Therefore, the input==output check is sufficient: if I use the same\n\u003e set of signers for an input and an output, I can be sure that the\n\u003e change goes to the same multisig wallet.\n\nThis is sufficient, in a simple case.\n\nI consider cases where spending from different wallets ('wallet\ncompartments') can be aggregated into one transaction, for efficiency\nand convenience in certain circumstances. (ex: legacy addresses that\ncannot be abandoned due to users still sending to them, but managing\nthem separately is inconvenient; wallet 'compartments' that each have\ndifferent multisig policies and spending priorities, and change would\ngo to most secure compartment used, etc.)\n\nThis is most likely a 'borader problem', as you said, but this is just\nwhat my code already does, although with stateful signers that\nstore trusted xpubs. I had an idea how to apply this to stateless hw\nwallets, and shared it.\n\n\u003e \u003e This would allow to distinguish the trusted output even if the\n\u003e \u003e inputs are not all derived from the same set of xpubs, that could\n\u003e \u003e happen in more complex scenarios (batching, key rotation, etc.),\n\u003e \u003e and can possibly be used to have several different types of\n\u003e \u003e 'trusted' outputs.\n\u003e \n\u003e This seems to be an attempt at a different, much broader problem. And\n\u003e it won't help if the attacker can replay a different trusted-xpub\n\u003e package (e.g., one that contains a revoked previously compromised\n\u003e key).\n\nThe auxiliary text can be constructed to include some code word that\nwould mark 'epoch' of the package, and will be displayed prominently.\nUpon compromise, new trusted-xpub packages would use different 'epoch'\ncode word. This is one method to make it stateless (stateful way would\nbe to just have a counter inside hw wallet and check package version\nagainst it).",
"sig": "e979203764bce1e2934901434d633df15bea285ab0c1b4d739c128240f4a335c0b7aa1893994e531fe195abc90bf09b745c02a94e49f4e3109d03a81dbafb0ad"
}