Gregory Maxwell [ARCHIVE] on Nostr: 📅 Original date posted:2011-10-27 🗒️ Summary of this message: The author ...
đź“… Original date posted:2011-10-27
🗒️ Summary of this message: The author opposes checkmultisig as a standard transaction type due to a misunderstanding of the bijection between hash160s and public keys.
đź“ť Original message:(taking this a bit out of order)
On Thu, Oct 27, 2011 at 3:32 AM, Michael Grønager <gronager at ceptacle.com> wrote:
> OK, let me try to explain what I see is the problem:
[snip]
> This, I find a nice and clean setup, where cryptographic keys can be mapped to assets.
>From my perspective that clean boundary remains: Functionally the
script is part of the cryptographic key.
[snip]
> except if you also have the knowledge of the script that was used.
Which you must.
I can see no functional difference than if you said of the current
system "except if you also have knowledge of the final 32 bits of the
ECC private key".
I don't see any reason to expect clients to identify funds without
knowing the information required— it's impossible. I mean, sure, you
_could_ bruteforce the final 32 bits of your private key— or you could
attempt to try the cartesian product of every key you have with every
key seen in the block chain for finding an op_eval script. But thats
unworkable, unnecessary, equally bad for all client types, and not
being suggested. Under either system a coin is not yours unless you
know all of the right bits— knowing some is not good enough.
Could you suggest how else we could gain the advantages of op_eval
without it? How can I secure my wallet under whatever scheme I like—
create a trust that requires multiparty signoff— and securely have
senders pay into it without expecting them all to handle some rare and
complicated procedure for sending to me? (Or a burdensome address
which serializes a script and a large amount of data into hundreds of
characters, and which still may be unable to represent the rules I
wish to have govern my account— and which the sender might mutate—
e.g. twiddling the threshold counts— and cause me great
problems/confusion)
[snip]
> So far we the bitcoin addresses are (for all practical purposes) a one-to-one mapping between a pubkey and uint160. This mean that your wallet is defined solely by your privatekeys (from which you can extract pubkeys and then uint160 btc-addresses).
[snip]
> I agree that it will work and I (and bitcoin-js and blockexplorer) can of change the concept of a wallet to also include scripts, but it breaks an intrinsic logic of uint160s and transactions that has so far been quite nice and clean.
>
> So I also support checkmultisig to be the standard transaction type, but I do not appreciate the support of OP_EVAL.
On the basis of the discussion here I now oppose checkmultisig as a
standard transaction type. (Sorry, I'm not trying to be a jerk if it
came off that way, I'm not opposing it simply because you support it:)
The advantage I saw of having it was faster deployment for the
explicit escrow cases that don't need to encode the payment rules in
an address (as is needed for wallet security and trusts)... but it
seems to me that there is a serious misunderstanding that there is a
bijection between hash160s and public keys, and one between ECC
private keys and spendable transactions, and that this bijection is
desirable or even essential to bitcoin.
I'm concerned that this misunderstanding will moot the flexibility of
the script system because every script that doesn't look like a direct
mapping of hash160->pubkey->payee will be regarded as _broken_— not
just useless to one app or another which could have simply chosen not
to generate those addresses— but actually incompatible with bitcoin,
as is basically being argued here— or, keeping in mind that people can
freely mine non-standard transactions, could this result in tools
which are rendered insecure by unexpected transaction types— Will a
system that thinks HASH160 = IDENTITY recognize that a script which
also requires an additional secret key on the stack is unspendable?
Keeping checkmultisig alone as a standard transaction, when it's
functionally a redundant subset of OP_EVAL (and inferior because it
reduces the txn you can place in a block) could only further that
misunderstanding. :-/
🗒️ Summary of this message: The author opposes checkmultisig as a standard transaction type due to a misunderstanding of the bijection between hash160s and public keys.
đź“ť Original message:(taking this a bit out of order)
On Thu, Oct 27, 2011 at 3:32 AM, Michael Grønager <gronager at ceptacle.com> wrote:
> OK, let me try to explain what I see is the problem:
[snip]
> This, I find a nice and clean setup, where cryptographic keys can be mapped to assets.
>From my perspective that clean boundary remains: Functionally the
script is part of the cryptographic key.
[snip]
> except if you also have the knowledge of the script that was used.
Which you must.
I can see no functional difference than if you said of the current
system "except if you also have knowledge of the final 32 bits of the
ECC private key".
I don't see any reason to expect clients to identify funds without
knowing the information required— it's impossible. I mean, sure, you
_could_ bruteforce the final 32 bits of your private key— or you could
attempt to try the cartesian product of every key you have with every
key seen in the block chain for finding an op_eval script. But thats
unworkable, unnecessary, equally bad for all client types, and not
being suggested. Under either system a coin is not yours unless you
know all of the right bits— knowing some is not good enough.
Could you suggest how else we could gain the advantages of op_eval
without it? How can I secure my wallet under whatever scheme I like—
create a trust that requires multiparty signoff— and securely have
senders pay into it without expecting them all to handle some rare and
complicated procedure for sending to me? (Or a burdensome address
which serializes a script and a large amount of data into hundreds of
characters, and which still may be unable to represent the rules I
wish to have govern my account— and which the sender might mutate—
e.g. twiddling the threshold counts— and cause me great
problems/confusion)
[snip]
> So far we the bitcoin addresses are (for all practical purposes) a one-to-one mapping between a pubkey and uint160. This mean that your wallet is defined solely by your privatekeys (from which you can extract pubkeys and then uint160 btc-addresses).
[snip]
> I agree that it will work and I (and bitcoin-js and blockexplorer) can of change the concept of a wallet to also include scripts, but it breaks an intrinsic logic of uint160s and transactions that has so far been quite nice and clean.
>
> So I also support checkmultisig to be the standard transaction type, but I do not appreciate the support of OP_EVAL.
On the basis of the discussion here I now oppose checkmultisig as a
standard transaction type. (Sorry, I'm not trying to be a jerk if it
came off that way, I'm not opposing it simply because you support it:)
The advantage I saw of having it was faster deployment for the
explicit escrow cases that don't need to encode the payment rules in
an address (as is needed for wallet security and trusts)... but it
seems to me that there is a serious misunderstanding that there is a
bijection between hash160s and public keys, and one between ECC
private keys and spendable transactions, and that this bijection is
desirable or even essential to bitcoin.
I'm concerned that this misunderstanding will moot the flexibility of
the script system because every script that doesn't look like a direct
mapping of hash160->pubkey->payee will be regarded as _broken_— not
just useless to one app or another which could have simply chosen not
to generate those addresses— but actually incompatible with bitcoin,
as is basically being argued here— or, keeping in mind that people can
freely mine non-standard transactions, could this result in tools
which are rendered insecure by unexpected transaction types— Will a
system that thinks HASH160 = IDENTITY recognize that a script which
also requires an additional secret key on the stack is unspendable?
Keeping checkmultisig alone as a standard transaction, when it's
functionally a redundant subset of OP_EVAL (and inferior because it
reduces the txn you can place in a block) could only further that
misunderstanding. :-/