📅 Original date posted:2011-10-27
🗒️ Summary of this message: Michael Grønager argues that the OP_EVAL proposal breaks the clean mapping of cryptographic keys to assets in Bitcoin addresses. He supports checkmultisig as the standard transaction type.
📝 Original message:OK, let me try to explain what I see is the problem:
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).
This also enables you to make a uint160 to tx mapping on a server (like on blockexplorer) and use a thin client to query for transactions just from a list of uint160 (whether it holds the private keys behind them or not).
In the case of a multisig transaction, lets say the 2of3 example, you could e.g. have all 3 corresponding uint160s but only one privkey, but still query the server and know the value of an asset of uint160s.
This, I find a nice and clean setup, where cryptographic keys can be mapped to assets.
If we now consider the OP_EVAL proposal. Here, a new use of the uint160, namely as a mapping of ripemd160(something extra and hash256(pubkey)) is introduced. This means that this clean mapping is broken. Your will have an extra "public key" being the "something extra", and there is no easy way to do the mapping from a list of private keys to public keys to uint160s that will result in the new condensed uint160, except if you also have the knowledge of the script that was used.
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.
Cheers,
Michael
On 26/10/2011, at 17:00, Gavin Andresen wrote:
> On Wed, Oct 26, 2011 at 4:58 AM, Michael Grønager <gronager at ceptacle.com> wrote:
>> I think it is a very important feature to be able to extract transaction to/from you only from your private keys.
>
> Why? If somebody is sending me bitcoins, then they'll have to get
> either an address or one or more public keys from me. OP_EVAL just
> lets me give them a short address that represents an arbitrary number
> of keys combined in an arbitrary way.
>
> I agree with Gregory: it shouldn't matter if that address is
> HASH(public key) or HASH(op_eval_script), the issues are the same (if
> you lose or cannot re-create the key/script then you're in trouble).
>
> Maybe I'm missing something; are you worried that blockexplorer won't
> know that coins sent to HASH(op_eval_script) are actually a
> complicated transaction until the coins are spent again? I'd consider
> that a feature, not a bug, because only the people involved in the
> transaction need to know the details until after the transaction is
> complete.
>
> Feel free to contact me about your 'tiered implementation for thin
> clients' -- I don't think OP_EVAL will make that significantly harder.
>
> I also agree with Alan: using OP_EVAL is not mandatory, I'm proposing
> that CHECKMULTISIG becomes a standard transaction type.
>
> --
> --
> Gavin Andresen
Michael Gronager, PhD
Owner Ceptacle / NDGF Director, NORDUnet A/S
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 62 14 01
E-mail: gronager at ceptacle.com
Michael Grønager [ARCHIVE] /
npub15f…xlq6h
2023-06-07 02:35:45
in reply to nevent1q…9e36
Author Public Key
npub15fmnxm546tg2sv0l7elusrvqsgezdzdg3m0flpml5fr2qf3f5slskxlq6hPublished at
2023-06-07 02:35:45Event JSON
{
"id": "a4d0a82278b8e46405386491465f67104297f88362ce3a62ee74ec4a38567f10",
"pubkey": "a277336e95d2d0a831fff67fc80d8082322689a88ede9f877fa246a02629a43f",
"created_at": 1686105345,
"kind": 1,
"tags": [
[
"e",
"38ab95ef62f6301977f9dec6ff3b1f25746d558345bec15abbd412157a28a77b",
"",
"root"
],
[
"e",
"c341b5b03ed62db5c6824515674ccef6c6598cd46e705bb32bfbb8f795abbee7",
"",
"reply"
],
[
"p",
"857f2f78dc1639e711f5ea703a9fc978e22ebd279abdea1861b7daa833512ee4"
]
],
"content": "📅 Original date posted:2011-10-27\n🗒️ Summary of this message: Michael Grønager argues that the OP_EVAL proposal breaks the clean mapping of cryptographic keys to assets in Bitcoin addresses. He supports checkmultisig as the standard transaction type.\n📝 Original message:OK, let me try to explain what I see is the problem:\n\nSo 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).\n\nThis also enables you to make a uint160 to tx mapping on a server (like on blockexplorer) and use a thin client to query for transactions just from a list of uint160 (whether it holds the private keys behind them or not).\n\nIn the case of a multisig transaction, lets say the 2of3 example, you could e.g. have all 3 corresponding uint160s but only one privkey, but still query the server and know the value of an asset of uint160s.\n\nThis, I find a nice and clean setup, where cryptographic keys can be mapped to assets.\n\nIf we now consider the OP_EVAL proposal. Here, a new use of the uint160, namely as a mapping of ripemd160(something extra and hash256(pubkey)) is introduced. This means that this clean mapping is broken. Your will have an extra \"public key\" being the \"something extra\", and there is no easy way to do the mapping from a list of private keys to public keys to uint160s that will result in the new condensed uint160, except if you also have the knowledge of the script that was used. \n\nI 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.\n\nSo I also support checkmultisig to be the standard transaction type, but I do not appreciate the support of OP_EVAL.\n\nCheers,\n\nMichael\n\n\nOn 26/10/2011, at 17:00, Gavin Andresen wrote:\n\n\u003e On Wed, Oct 26, 2011 at 4:58 AM, Michael Grønager \u003cgronager at ceptacle.com\u003e wrote:\n\u003e\u003e I think it is a very important feature to be able to extract transaction to/from you only from your private keys.\n\u003e \n\u003e Why? If somebody is sending me bitcoins, then they'll have to get\n\u003e either an address or one or more public keys from me. OP_EVAL just\n\u003e lets me give them a short address that represents an arbitrary number\n\u003e of keys combined in an arbitrary way.\n\u003e \n\u003e I agree with Gregory: it shouldn't matter if that address is\n\u003e HASH(public key) or HASH(op_eval_script), the issues are the same (if\n\u003e you lose or cannot re-create the key/script then you're in trouble).\n\u003e \n\u003e Maybe I'm missing something; are you worried that blockexplorer won't\n\u003e know that coins sent to HASH(op_eval_script) are actually a\n\u003e complicated transaction until the coins are spent again? I'd consider\n\u003e that a feature, not a bug, because only the people involved in the\n\u003e transaction need to know the details until after the transaction is\n\u003e complete.\n\u003e \n\u003e Feel free to contact me about your 'tiered implementation for thin\n\u003e clients' -- I don't think OP_EVAL will make that significantly harder.\n\u003e \n\u003e I also agree with Alan: using OP_EVAL is not mandatory, I'm proposing\n\u003e that CHECKMULTISIG becomes a standard transaction type.\n\u003e \n\u003e -- \n\u003e --\n\u003e Gavin Andresen\n\nMichael Gronager, PhD\nOwner Ceptacle / NDGF Director, NORDUnet A/S\nJens Juels Gade 33\n2100 Copenhagen E\nMobile: +45 31 62 14 01\nE-mail: gronager at ceptacle.com",
"sig": "cec538743d2c0fd70501130b727349fc2bc29631e1985523a27295c674a8f335aaae07f877f9463296e857467e76724cc0b875c6905df308bfb545f765709c28"
}