Alan Reiner [ARCHIVE] on Nostr: 📅 Original date posted:2011-10-25 🗒️ Summary of this message: The proposed ...
📅 Original date posted:2011-10-25
🗒️ Summary of this message: The proposed OP_EVAL tool for multi-signature transactions is optional, and regular OP_CHECKMULTISIG can still be used. It is important to keep the subscripts/mappings in the wallet forever, and there should be an easy way to add such a script/mapping to the wallet.
📝 Original message:On Tue, Oct 25, 2011 at 10:49 AM, Gregory Maxwell <gmaxwell at gmail.com>wrote:
> On Tue, Oct 25, 2011 at 9:21 AM, Gavin Andresen <gavinandresen at gmail.com>
> wrote:
> > You give the hash to whoever is paying you, and store the hash -->
> > script mapping when you do that (assuming you're not using a
> > deterministic wallet; if you are, you probably just increment a
> > counter in the wallet).
>
> If anyone finds that solution unsatisfying, consider— It's already the
> case that I could take one of your disclosed public keys and create an
> infinite series of secondary keys out of it for which only you could
> decode, and the only way for you to find them in the blockchain would
> be to have performed the same procedure and made a note of the
> addresses you're watching for.
>
>
(1) As I understand it, OP_EVAL is being proposed as an *optional* tool for
multi-signature transactions. It sounds like to me, that you can still use
the regular OP_CHECKMULTISIG if you are concerned about these things. If
you're dealing with too many parties with questionable reliability that they
will notify you of transacitons that include you, I don't see anything wrong
with declaring that you'd only prefer dealing with OP_CMS transactions and
not OP_EVAL (besides some grumbling from them that their way is "better").
Either way, they're screwing themselves, too, if they want to include you on
transactions and don't notify you as such (kind of defeats the purpose of
multi-sig txs).
(2) I think it's unnecessary to discuss cases where you somehow lose your
mappings but not your private keys. In order for OP_EVAL scripts to work,
the subscripts/mappings are *just as important* as your regular private
keys. They should be kept in your wallet forever just like your private
keys--and thus you lose none of them or all of them. The only real
difference is that they aren't sensitive like your private keys, so they
don't have to be encrypted.
(3) There should most definitely be a button on the main client that allows
you to "Add OP_EVAL script" or something along those lines (maybe something
with a less obscure name). We need to make it as easy as possible for
someone to add such a script/mapping to their wallet. Although, this
invites a breach of one of my core rules of user interfaces: if the
functionality is dependent on the user performing some regular maintenance
task, you better be prepared for all users to fail at doing it. Even
diligent users are going to forget/mess-up sometimes. If failure at
performing this task results in breaking the client or losing money, we
should avoid promoting that usage paradigm.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111025/e630403f/attachment.html>;
🗒️ Summary of this message: The proposed OP_EVAL tool for multi-signature transactions is optional, and regular OP_CHECKMULTISIG can still be used. It is important to keep the subscripts/mappings in the wallet forever, and there should be an easy way to add such a script/mapping to the wallet.
📝 Original message:On Tue, Oct 25, 2011 at 10:49 AM, Gregory Maxwell <gmaxwell at gmail.com>wrote:
> On Tue, Oct 25, 2011 at 9:21 AM, Gavin Andresen <gavinandresen at gmail.com>
> wrote:
> > You give the hash to whoever is paying you, and store the hash -->
> > script mapping when you do that (assuming you're not using a
> > deterministic wallet; if you are, you probably just increment a
> > counter in the wallet).
>
> If anyone finds that solution unsatisfying, consider— It's already the
> case that I could take one of your disclosed public keys and create an
> infinite series of secondary keys out of it for which only you could
> decode, and the only way for you to find them in the blockchain would
> be to have performed the same procedure and made a note of the
> addresses you're watching for.
>
>
(1) As I understand it, OP_EVAL is being proposed as an *optional* tool for
multi-signature transactions. It sounds like to me, that you can still use
the regular OP_CHECKMULTISIG if you are concerned about these things. If
you're dealing with too many parties with questionable reliability that they
will notify you of transacitons that include you, I don't see anything wrong
with declaring that you'd only prefer dealing with OP_CMS transactions and
not OP_EVAL (besides some grumbling from them that their way is "better").
Either way, they're screwing themselves, too, if they want to include you on
transactions and don't notify you as such (kind of defeats the purpose of
multi-sig txs).
(2) I think it's unnecessary to discuss cases where you somehow lose your
mappings but not your private keys. In order for OP_EVAL scripts to work,
the subscripts/mappings are *just as important* as your regular private
keys. They should be kept in your wallet forever just like your private
keys--and thus you lose none of them or all of them. The only real
difference is that they aren't sensitive like your private keys, so they
don't have to be encrypted.
(3) There should most definitely be a button on the main client that allows
you to "Add OP_EVAL script" or something along those lines (maybe something
with a less obscure name). We need to make it as easy as possible for
someone to add such a script/mapping to their wallet. Although, this
invites a breach of one of my core rules of user interfaces: if the
functionality is dependent on the user performing some regular maintenance
task, you better be prepared for all users to fail at doing it. Even
diligent users are going to forget/mess-up sometimes. If failure at
performing this task results in breaking the client or losing money, we
should avoid promoting that usage paradigm.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111025/e630403f/attachment.html>;