📅 Original date posted:2017-10-01
📝 Original message:Given the proposed fixed signature size, It seems better to me that we
create a SIGHASH_WITNESS_WEIGHT flag as opposed to SIGHASH_WITNESS_DEPTH.
Mark, you seem to be arguing that in general we still want weight
malleability even with witness depth fixed, but I don't understand in what
scenario we would want that.
It strikes me that is most scenarios all parties signing an input would do
so after an execution path through the script has been agreed upon by all
parties, in which case the witness weight can be fixed.
In rare cases where the smart contract requires that some parties sign in
advance of the decision about the execution path (for example, I'm thinking
about delegation here, but I want to keep my remarks general), we wouldn't
want to fix the witness depth either.
A SIGHASH_WITNESS_WEIGHT would prevent all possible malleability that would
modify the transaction's fee/weight priority (at least for that one input),
and greatly reduce the overall attack surface of witness malleability
issues.
On Sun, Oct 1, 2017 at 1:04 AM, Mark Friedenbach via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Clean stack should be eliminated for other possible future uses, the most
> obvious of which is recursive tail-call for general computation capability.
> I’m not arguing for that at this time, just arguing that we shouldn’t
> prematurely cut off an easy implementation of such should we want to. Clean
> stack must still exist as policy for future soft-fork safety, but being a
> consensus requirement was only to avoid witness malleability, which
> committing to the size of the witness also accomplishes.
>
> Committing to the number of witness elements is fully sufficient, and
> using the number of elements avoids problems of not knowing the actual size
> in bytes at the time of signing, e.g. because the witness contains a merkle
> proof generated by another party from an unbalanced tree, and unbalanced
> trees are expected to be common (so that elements can be placed higher in
> the tree in accordance with their higher expected probability of usage).
> Other future extensions might also have variable-length proofs.
>
> > On Sep 30, 2017, at 7:47 PM, Luke Dashjr <luke at dashjr.org> wrote:
> >
> > Should it perhaps commit to the length of the serialised witness data
> instead
> > or additionally? Now that signatures are no longer variable-length,
> that'd be
> > possible...
> >
> > As far as tail-call needs are concerned, CLEANSTACK wouldn't have been
> checked
> > until AFTER the tail-call in the first draft. But I suppose eliminating
> it for
> > other possible future purposes is still useful.
> >
> > Luke
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171001/61186661/attachment.html>;
Russell O'Connor [ARCHIVE] /
npub1dw…8plrw
2023-06-07 18:06:46
in reply to nevent1q…8j4m
Author Public Key
npub1dw88wd5gqsqn6ufxhf9h03uk8087l7gfzdtez5csjlt6pupu4pwsj8plrwPublished at
2023-06-07 18:06:46Event JSON
{
"id": "69c80e6a6987e47d0c329640d8bb292f2167100b5639e79545a592803026125b",
"pubkey": "6b8e77368804013d7126ba4b77c7963bcfeff909135791531097d7a0f03ca85d",
"created_at": 1686161206,
"kind": 1,
"tags": [
[
"e",
"9b9c879c7c4c0058d6eaf17164d815d71eee483d01b14c0d8895961d9935e9fd",
"",
"root"
],
[
"e",
"ce5c211f772ad1b3d07ed0e0680f38f8bb9045ab00e482b399a7a2b8d66c66d3",
"",
"reply"
],
[
"p",
"5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803"
]
],
"content": "📅 Original date posted:2017-10-01\n📝 Original message:Given the proposed fixed signature size, It seems better to me that we\ncreate a SIGHASH_WITNESS_WEIGHT flag as opposed to SIGHASH_WITNESS_DEPTH.\n\nMark, you seem to be arguing that in general we still want weight\nmalleability even with witness depth fixed, but I don't understand in what\nscenario we would want that.\n\nIt strikes me that is most scenarios all parties signing an input would do\nso after an execution path through the script has been agreed upon by all\nparties, in which case the witness weight can be fixed.\nIn rare cases where the smart contract requires that some parties sign in\nadvance of the decision about the execution path (for example, I'm thinking\nabout delegation here, but I want to keep my remarks general), we wouldn't\nwant to fix the witness depth either.\n\nA SIGHASH_WITNESS_WEIGHT would prevent all possible malleability that would\nmodify the transaction's fee/weight priority (at least for that one input),\nand greatly reduce the overall attack surface of witness malleability\nissues.\n\nOn Sun, Oct 1, 2017 at 1:04 AM, Mark Friedenbach via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Clean stack should be eliminated for other possible future uses, the most\n\u003e obvious of which is recursive tail-call for general computation capability.\n\u003e I’m not arguing for that at this time, just arguing that we shouldn’t\n\u003e prematurely cut off an easy implementation of such should we want to. Clean\n\u003e stack must still exist as policy for future soft-fork safety, but being a\n\u003e consensus requirement was only to avoid witness malleability, which\n\u003e committing to the size of the witness also accomplishes.\n\u003e\n\u003e Committing to the number of witness elements is fully sufficient, and\n\u003e using the number of elements avoids problems of not knowing the actual size\n\u003e in bytes at the time of signing, e.g. because the witness contains a merkle\n\u003e proof generated by another party from an unbalanced tree, and unbalanced\n\u003e trees are expected to be common (so that elements can be placed higher in\n\u003e the tree in accordance with their higher expected probability of usage).\n\u003e Other future extensions might also have variable-length proofs.\n\u003e\n\u003e \u003e On Sep 30, 2017, at 7:47 PM, Luke Dashjr \u003cluke at dashjr.org\u003e wrote:\n\u003e \u003e\n\u003e \u003e Should it perhaps commit to the length of the serialised witness data\n\u003e instead\n\u003e \u003e or additionally? Now that signatures are no longer variable-length,\n\u003e that'd be\n\u003e \u003e possible...\n\u003e \u003e\n\u003e \u003e As far as tail-call needs are concerned, CLEANSTACK wouldn't have been\n\u003e checked\n\u003e \u003e until AFTER the tail-call in the first draft. But I suppose eliminating\n\u003e it for\n\u003e \u003e other possible future purposes is still useful.\n\u003e \u003e\n\u003e \u003e Luke\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171001/61186661/attachment.html\u003e",
"sig": "d91aaef65f67d92cd08422baaad228db3e0aa466191a0f06a69046c8b94ef02042a5078ad241ed35d7594435229aebbc7e287b879a23dafb796df9f90afb6c8a"
}