ð
Original date posted:2017-09-22
ð Original message:If the variable size increase is only a few bytes, then three possibilities
arise:
- one should allow signatures to be zero padded (to reach the maximum size)
and abandon strict DER encoding
- one should allow spare witness stack elements (to pad the size to match
the maximum size) and remove the cleanstack rule. But this is tricky
because empty stack elements must be counted as 1 byte.
- signers must loop the generation of signatures until the signature
generated is of its maximum size.
On Fri, Sep 22, 2017 at 6:39 PM, Mark Friedenbach <mark at friedenbach.org>
wrote:
> You generally know the witness size to within a few bytes right before
> signing. Why would you not? You know the size of ECDSA signatures. You can
> be told the size of a hash preimage by the other party. It takes some
> contriving to come up with a scheme where one party has variable-length
> signatures of their chosing
>
> > On Sep 22, 2017, at 2:32 PM, Sergio Demian Lerner <
> sergio.d.lerner at gmail.com> wrote:
> >
> > But generally before one signs a transaction one does not know the
> signature size (which may be variable). One can only estimate the maximum
> size.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170922/2f36b74f/attachment-0001.html>;
Sergio Demian Lerner [ARCHIVE] /
npub1fvâŠ3vq7f
2023-06-07 18:05:39
in reply to nevent1qâŠ5w0h
Author Public Key
npub1fvuxqdqg7klqqgy3yy8gdxjv4phu92sll5y8zqm2qe5qdrhxymhqf3vq7fPublished at
2023-06-07 18:05:39Event JSON
{
"id": "2d79dd6cb0a288ad42c38ac997e2086ad623a7ddbccdc8f88e843f3a6651b6ec",
"pubkey": "4b38603408f5be002091210e869a4ca86fc2aa1ffd0871036a0668068ee626ee",
"created_at": 1686161139,
"kind": 1,
"tags": [
[
"e",
"2a468f3688518e7a7f729ce11aaac86d8191608db6d8228100ef68169ab48586",
"",
"root"
],
[
"e",
"bf1550acf5eafb4a1e246f6747fcf93e0703fc7285731ad579a2c8e96f55c164",
"",
"reply"
],
[
"p",
"1c61d995949cbfaf14f767784e166bde865c7b8783d7aa3bf0a1d014b70c0069"
]
],
"content": "ð
Original date posted:2017-09-22\nð Original message:If the variable size increase is only a few bytes, then three possibilities\narise:\n\n- one should allow signatures to be zero padded (to reach the maximum size)\nand abandon strict DER encoding\n\n- one should allow spare witness stack elements (to pad the size to match\nthe maximum size) and remove the cleanstack rule. But this is tricky\nbecause empty stack elements must be counted as 1 byte.\n\n- signers must loop the generation of signatures until the signature\ngenerated is of its maximum size.\n\n\n\n\nOn Fri, Sep 22, 2017 at 6:39 PM, Mark Friedenbach \u003cmark at friedenbach.org\u003e\nwrote:\n\n\u003e You generally know the witness size to within a few bytes right before\n\u003e signing. Why would you not? You know the size of ECDSA signatures. You can\n\u003e be told the size of a hash preimage by the other party. It takes some\n\u003e contriving to come up with a scheme where one party has variable-length\n\u003e signatures of their chosing\n\u003e\n\u003e \u003e On Sep 22, 2017, at 2:32 PM, Sergio Demian Lerner \u003c\n\u003e sergio.d.lerner at gmail.com\u003e wrote:\n\u003e \u003e\n\u003e \u003e But generally before one signs a transaction one does not know the\n\u003e signature size (which may be variable). One can only estimate the maximum\n\u003e size.\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170922/2f36b74f/attachment-0001.html\u003e",
"sig": "4fa0cc09501ed04d2a72c135747eab3bb259f3db15d747265515b3bf8bf1f90402bbac66117b33805ed295834f17d11deda90c9f9e1586506c7cc2d0d2f0af4d"
}