📅 Original date posted:2015-04-09
📝 Original message:Hi Mike,
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?
>
That's a good point, maybe SIGHASH_WITHOUT_PREV_SCRIPTPUBKEY and
SIGHASH_WITHOUT_PREV_VALUE should be assumed false, since you need the data
anyway. That gets the total number of flags down to 17. If we eliminate
SIGHASH_WITHOUT_TX_VERSION (I can't think of any good reason for this one),
then we're down to a 2-byte nHashType. SIGHASH_SIGN_STACK_ELEMENT could
also be removed, I'm not convinced of the usefulness of that one either.
>
> 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 don't think it's quite a blank check, but it would enable replay attacks
in the form of sending the money to the same place it was sent before if an
address ever receives coins again. Almost like auto-forwarding addresses.
If, in addition, you signed with just that input and no outputs as well,
then you're basically forfeiting your rights to any coins sent to that
address.
It allows for some dangerous combinations, but we already have some
dangerous nHashTypes. e.g. SIGHASH_NONE | SIGHASH_ANYONECANPAY. Good
documentation and careful developers shouldn't have any issues if they use
a standard set of sighash flag combinations for their standard use cases.
But developers that need special combinations can now use them, so long as
they are careful and think things through.
>
> 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.
>
>
It's hard, though, because there is different data needs to be signed for
each input. Although, I suppose if you signed your input with
SIGHASH_WITHOUT_PREV_SCRIPTPUBKEY, SIGHASH_WITHOUT_PREV_VALUE, and the
equivalent of SIGHASH_ALL, then the hash that needs to be signed would be
the same for all of your inputs. Strangely enough, I think we might have
just found use cases for the flags that we had nearly dismissed.
Another possibility would be to put the previous scriptPubKey and previous
output value at the END of the serialized transaction, so that you could
make use of some sort of a signature hash midstate. But that feels a little
messy. It sort of makes sense to have a base serialization for a
transaction and then append it with whatever input/output specific
information you have, but still, messy.
Is hashing transaction data once for each input really a huge bottleneck,
though? Do mobile devices have an issue with this?
Best,
Stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150409/8fc6b376/attachment.html>;
Stephen Morse [ARCHIVE] /
npub1ja…q0j2u
2023-06-07 15:32:24
in reply to nevent1q…aws4
Author Public Key
npub1ja0fa5k6j04r2h7jp33lvdy2kzpv5yj60ce4wvcca7fvxe99hw5qqq0j2uPublished at
2023-06-07 15:32:24Event JSON
{
"id": "dc46d9c1dea8c16a7c869049b016110b180d738088df1ebdb739fed5ae845ef2",
"pubkey": "975e9ed2da93ea355fd20c63f6348ab082ca125a7e33573318ef92c364a5bba8",
"created_at": 1686151944,
"kind": 1,
"tags": [
[
"e",
"5206ce2c8620dd8f1134d6ac01a117c32a073608bbe0cb98c349a3703407d0c0",
"",
"root"
],
[
"e",
"582baa4b78cb44143b60d0632b9fb7749387d6fa342efa2d9569241785d58474",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 Original date posted:2015-04-09\n📝 Original message:Hi Mike,\n\nHi Stephen,\n\u003e\n\u003e It's an interesting idea. I'm not sure that all the combinations make\n\u003e sense. Excluding the connected output script or value but still signing the\n\u003e prev tx hash appears pointless: the script cannot change anyway, and you\n\u003e still need to know what it is to actually calculate the inputs to it, so\n\u003e what is the point of this?\n\u003e\n\nThat's a good point, maybe SIGHASH_WITHOUT_PREV_SCRIPTPUBKEY and\nSIGHASH_WITHOUT_PREV_VALUE should be assumed false, since you need the data\nanyway. That gets the total number of flags down to 17. If we eliminate\nSIGHASH_WITHOUT_TX_VERSION (I can't think of any good reason for this one),\nthen we're down to a 2-byte nHashType. SIGHASH_SIGN_STACK_ELEMENT could\nalso be removed, I'm not convinced of the usefulness of that one either.\n\n\n\u003e\n\u003e I also worry that quite a few of these combinations could be unexpectedly\n\u003e dangerous. If you don't sign the prevout hash or value and combine it with\n\u003e a regular pay-to-address output then you've effectively written a blank\n\u003e cheque that can be used by anyone, to claim any money ever sent to that\n\u003e address ... no? And then any p2p\n\u003e\nnode or miner could do so, making the transaction pretty useless.\n\u003e\n\u003e That isn't inherently a problem as long as people understand which\n\u003e combinations have what effects or cannot be used for various reasons. But\n\u003e it would need good documentation and careful thought to explore each\n\u003e possibility people might use.\n\u003e\n\nI don't think it's quite a blank check, but it would enable replay attacks\nin the form of sending the money to the same place it was sent before if an\naddress ever receives coins again. Almost like auto-forwarding addresses.\nIf, in addition, you signed with just that input and no outputs as well,\nthen you're basically forfeiting your rights to any coins sent to that\naddress.\n\nIt allows for some dangerous combinations, but we already have some\ndangerous nHashTypes. e.g. SIGHASH_NONE | SIGHASH_ANYONECANPAY. Good\ndocumentation and careful developers shouldn't have any issues if they use\na standard set of sighash flag combinations for their standard use cases.\nBut developers that need special combinations can now use them, so long as\nthey are careful and think things through.\n\n\n\u003e\n\u003e I'll leave the soft fork business to one side for now. I think any change\n\u003e in CHECKSIG or new version of it would likely be ready around the same time\n\u003e as the hard fork we need for changing the block size limit anyway, and it's\n\u003e much cleaner to do it that way.\n\u003e\n\u003e The most important change that we need in sighash calculation, IMO, is\n\u003e ensuring that you don't have to hash data over and over again without a\n\u003e good reason. The current sighash definition is unfortunate because it's\n\u003e possible to make small transactions that involve hashing huge amounts of\n\u003e data. It's not clear to me that your proposal fixes that: ideally there\n\u003e would be one exactly one sighash for one transaction no matter how many\n\u003e checksigs are involved in verifying it.\n\u003e\n\u003e\nIt's hard, though, because there is different data needs to be signed for\neach input. Although, I suppose if you signed your input with\nSIGHASH_WITHOUT_PREV_SCRIPTPUBKEY, SIGHASH_WITHOUT_PREV_VALUE, and the\nequivalent of SIGHASH_ALL, then the hash that needs to be signed would be\nthe same for all of your inputs. Strangely enough, I think we might have\njust found use cases for the flags that we had nearly dismissed.\n\nAnother possibility would be to put the previous scriptPubKey and previous\noutput value at the END of the serialized transaction, so that you could\nmake use of some sort of a signature hash midstate. But that feels a little\nmessy. It sort of makes sense to have a base serialization for a\ntransaction and then append it with whatever input/output specific\ninformation you have, but still, messy.\n\nIs hashing transaction data once for each input really a huge bottleneck,\nthough? Do mobile devices have an issue with this?\n\nBest,\nStephen\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150409/8fc6b376/attachment.html\u003e",
"sig": "77d3406707e23229d7954e995fac39f191d4e4b34cb859a1ca17e6818ab4a465faa41a53b4d88cc4987df1906f5b742cfe9eadc973c79353683fd95dc157e7ae"
}