{"type":"rich","version":"1.0","author_name":"npub1fvuxqdqg7klqqgy3yy8gdxjv4phu92sll5y8zqm2qe5qdrhxymhqf3vq7f","author_url":"https://nostr.ae/npub1fvuxqdqg7klqqgy3yy8gdxjv4phu92sll5y8zqm2qe5qdrhxymhqf3vq7f","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 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"}