James MacWhyte [ARCHIVE] on Nostr: 📅 Original date posted:2021-07-26 📝 Original message:Hi Billy! See above, but ...
📅 Original date posted:2021-07-26
📝 Original message:Hi Billy!
See above, but to break down that situation a bit further, these are the
> two situations I can think of:
>
> 1. The opcode limits user/group A to send the output to user/group B
> 2. The opcode limits user A to send from one address they own to
> another address they own.
>
> I'm trying to think of a good use case for this type of opcode. In these
examples, an attacker who compromises the key for user A can't steal the
money because it can only be sent to user B. So if the attacker wants to
steal the funds, they would need to compromise the keys of both user A and
user B.
But how is that any better than a 2-of-2 multisig? Isn't the end result
exactly the same?
James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210726/688c8adb/attachment.html>;
📝 Original message:Hi Billy!
See above, but to break down that situation a bit further, these are the
> two situations I can think of:
>
> 1. The opcode limits user/group A to send the output to user/group B
> 2. The opcode limits user A to send from one address they own to
> another address they own.
>
> I'm trying to think of a good use case for this type of opcode. In these
examples, an attacker who compromises the key for user A can't steal the
money because it can only be sent to user B. So if the attacker wants to
steal the funds, they would need to compromise the keys of both user A and
user B.
But how is that any better than a 2-of-2 multisig? Isn't the end result
exactly the same?
James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210726/688c8adb/attachment.html>;