📅 Original date posted:2015-04-09
📝 Original message:Hi Stephen,
It's an interesting idea. I'm not sure that all the combinations make
sense. Excluding the connected output script or value but still signing the
prev tx hash appears pointless: the script cannot change anyway, and you
still need to know what it is to actually calculate the inputs to it, so
what is the point of this?
I also worry that quite a few of these combinations could be unexpectedly
dangerous. If you don't sign the prevout hash or value and combine it with
a regular pay-to-address output then you've effectively written a blank
cheque that can be used by anyone, to claim any money ever sent to that
address ... no? And then any p2p node or miner could do so, making the
transaction pretty useless.
That isn't inherently a problem as long as people understand which
combinations have what effects or cannot be used for various reasons. But
it would need good documentation and careful thought to explore each
possibility people might use.
I'll leave the soft fork business to one side for now. I think any change
in CHECKSIG or new version of it would likely be ready around the same time
as the hard fork we need for changing the block size limit anyway, and it's
much cleaner to do it that way.
The most important change that we need in sighash calculation, IMO, is
ensuring that you don't have to hash data over and over again without a
good reason. The current sighash definition is unfortunate because it's
possible to make small transactions that involve hashing huge amounts of
data. It's not clear to me that your proposal fixes that: ideally there
would be one exactly one sighash for one transaction no matter how many
checksigs are involved in verifying it.
thanks,
-mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150409/4579e124/attachment.html>;
Mike Hearn [ARCHIVE] /
npub17t…4qgyd
2023-06-07 15:32:24
in reply to nevent1q…xu2n
Author Public Key
npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydPublished at
2023-06-07 15:32:24Event JSON
{
"id": "582baa4b78cb44143b60d0632b9fb7749387d6fa342efa2d9569241785d58474",
"pubkey": "f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2",
"created_at": 1686151944,
"kind": 1,
"tags": [
[
"e",
"5206ce2c8620dd8f1134d6ac01a117c32a073608bbe0cb98c349a3703407d0c0",
"",
"root"
],
[
"e",
"071e0af6a78fda4d484b03fc08e04c32b1f3f97c1d2753c66346cff9cfa0c1ae",
"",
"reply"
],
[
"p",
"975e9ed2da93ea355fd20c63f6348ab082ca125a7e33573318ef92c364a5bba8"
]
],
"content": "📅 Original date posted:2015-04-09\n📝 Original message:Hi Stephen,\n\nIt's an interesting idea. I'm not sure that all the combinations make\nsense. Excluding the connected output script or value but still signing the\nprev tx hash appears pointless: the script cannot change anyway, and you\nstill need to know what it is to actually calculate the inputs to it, so\nwhat is the point of this?\n\nI also worry that quite a few of these combinations could be unexpectedly\ndangerous. If you don't sign the prevout hash or value and combine it with\na regular pay-to-address output then you've effectively written a blank\ncheque that can be used by anyone, to claim any money ever sent to that\naddress ... no? And then any p2p node or miner could do so, making the\ntransaction pretty useless.\n\nThat isn't inherently a problem as long as people understand which\ncombinations have what effects or cannot be used for various reasons. But\nit would need good documentation and careful thought to explore each\npossibility people might use.\n\nI'll leave the soft fork business to one side for now. I think any change\nin CHECKSIG or new version of it would likely be ready around the same time\nas the hard fork we need for changing the block size limit anyway, and it's\nmuch cleaner to do it that way.\n\nThe most important change that we need in sighash calculation, IMO, is\nensuring that you don't have to hash data over and over again without a\ngood reason. The current sighash definition is unfortunate because it's\npossible to make small transactions that involve hashing huge amounts of\ndata. It's not clear to me that your proposal fixes that: ideally there\nwould be one exactly one sighash for one transaction no matter how many\nchecksigs are involved in verifying it.\n\nthanks,\n-mike\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150409/4579e124/attachment.html\u003e",
"sig": "4b11f97ee7790ce3bab6305e7ecd5c2172e9c866d5f13733950fa5028ee13d19a9909829cc409312b8aa2b7009a91d6c9e232e5cdf63b8caea1755fc32c16250"
}