📅 Original date posted:2014-07-18 📝 Original message:> 9. New signatures by the ...

Aaron Voisine [ARCHIVE] /

npub18gj…nkzl

2023-06-07 15:24:14

in reply to nevent1q…ydm6

📅 Original date posted:2014-07-18
📝 Original message:> 9. New signatures by the sender

I'm not suggesting it be required, but it would be possible to
mitigate this one by requiring that all signatures deterministically
generate k per RFC6979. I'm using this in breadwallet.

Aaron Voisine
breadwallet.com

On Fri, Jul 18, 2014 at 1:56 PM, Wladimir <laanwj at gmail.com> wrote:
> On Fri, Jul 18, 2014 at 5:39 PM, Mike Hearn <mike at plan99.net> wrote:
>> The rationale doesn't seem to apply to rule #4, what's so special about that
>> one?
>
>> 4. Non-push operations in scriptSig Any non-push operation in a scriptSig invalidates it.
>
> Having non-push operations in the scriptSig is a source of
> malleability, as there can be multiple sequences of opcodes that
> evaluate to the same result.
>
> Wladimir
>
> ------------------------------------------------------------------------------
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Author Public Key

npub18gjvug29c4yg46lmplq38e75gg6wn5mn8taytckcsr4jt8p74h3s5knkzl

Seen on

wss://relay.nostr.band

Show more details

Published at

2023-06-07 15:24:14

Kind type

1 Short Text Note

Event JSON

{ "id": "7c1071577313100a78fdfddf75c30c84da6fd0f8b96452dfe47df2883078fe5a", "pubkey": "3a24ce2145c5488aebfb0fc113e7d44234e9d3733afa45e2d880eb259c3eade3", "created_at": 1686151454, "kind": 1, "tags": [ [ "e", "bd724105ae316b349d93a76fd25acc857c6eaea5c338fe45ec1a0cf9e46b9c93", "", "root" ], [ "e", "fb4f22e9da2c6e5c53b20870b962c40f53e8aa5ba9083f6f046384dce7db63f7", "", "reply" ], [ "p", "30217b018a47b99ed4c20399b44b02f70ec4f58ed77a2814a563fa28322ef722" ] ], "content": "📅 Original date posted:2014-07-18\n📝 Original message:\u003e 9. New signatures by the sender\n\nI'm not suggesting it be required, but it would be possible to\nmitigate this one by requiring that all signatures deterministically\ngenerate k per RFC6979. I'm using this in breadwallet.\n\nAaron Voisine\nbreadwallet.com\n\n\nOn Fri, Jul 18, 2014 at 1:56 PM, Wladimir \u003claanwj at gmail.com\u003e wrote:\n\u003e On Fri, Jul 18, 2014 at 5:39 PM, Mike Hearn \u003cmike at plan99.net\u003e wrote:\n\u003e\u003e The rationale doesn't seem to apply to rule #4, what's so special about that\n\u003e\u003e one?\n\u003e\n\u003e\u003e 4. Non-push operations in scriptSig Any non-push operation in a scriptSig invalidates it.\n\u003e\n\u003e Having non-push operations in the scriptSig is a source of\n\u003e malleability, as there can be multiple sequences of opcodes that\n\u003e evaluate to the same result.\n\u003e\n\u003e Wladimir\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Want fast and easy access to all the code in your enterprise? Index and\n\u003e search up to 200,000 lines of code with a free copy of Black Duck\n\u003e Code Sight - the same software that powers the world's largest code\n\u003e search on Ohloh, the Black Duck Open Hub! Try it now.\n\u003e http://p.sf.net/sfu/bds\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development", "sig": "94feab60213199fa4e7bf3f675e7f1904a39a83986720da8a5caeeff2ef2087fc9c640cca558d5dfb3d8ae20ef175f6a2bb33d3397c49a7e2a75ee89605fdf05" }