📅 Original date posted:2014-06-18
📝 Original message:On Tue, Jun 17, 2014 at 9:40 PM, Gavin Andresen
<gavin at bitcoinfoundation.org> wrote:
> Assuming there is rough consensus, I'll make this a pull request (see
> https://github.com/gavinandresen/bitcoin-git/tree/relax_isstandard for code
> changes).
>
> ----
>
> Now that we are finally starting to see the use of multi-signature and other
> more complicated transaction forms in applications I think it is time to
> open up the "IsStandard" transaction rules on the main Bitcoin network.
Agreed!
> Discussion
> ----------
> Allowing any P2SH Script would allow an attacker to craft a single standard
> transaction output that requires on the order of 200 ECDSA signature
> checking operations to validate-- an order of magnitude more than is
> currently allowed. Therefore I am proposing that we keep the current
> 15-signature-checking-operations-per-transaction-output limit in place, but
> allow any combination of enabled Script opcodes. So, for example, you might
> have a P2SH Script that is redeemed with 2-of-2 OR 2-of-3 using:
Soungs good to me - to lift the restrictions and increase flexibility,
but also to be a careful and keep the DoS limits.
> The reference implementation's wallet will still only recognize P2SH
> transactions that use one of the standard transaction forms. To actually USE
> a new transaction form will require specialized wallets or specialized
> applications.
That's of course completely separate. As we all know, most wallet
innovation doesn't happen in the reference implementation wallet, and
it should not be used as the guide here.
Wladimir
Wladimir [ARCHIVE] /
npub1xq…ymc2p
2023-06-07 15:23:05
in reply to nevent1q…lj9t
Author Public Key
npub1xqshkqv2g7uea4xzqwvmgjcz7u8vfavw6aazs999v0azsv3w7u3qpymc2pPublished at
2023-06-07 15:23:05Event JSON
{
"id": "ef98337110e2c5b50e9d9e56d9008dae493efdb3bacae5ba8a55053f482e1743",
"pubkey": "30217b018a47b99ed4c20399b44b02f70ec4f58ed77a2814a563fa28322ef722",
"created_at": 1686151385,
"kind": 1,
"tags": [
[
"e",
"17417d4d019b711f77b6899176af0fd8ebc69e7fc942137a5d14e724419b7980",
"",
"root"
],
[
"e",
"d9d60db887689b58841a64b5b144631c1cc392f9658cf01e99866cc79a06e499",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2014-06-18\n📝 Original message:On Tue, Jun 17, 2014 at 9:40 PM, Gavin Andresen\n\u003cgavin at bitcoinfoundation.org\u003e wrote:\n\u003e Assuming there is rough consensus, I'll make this a pull request (see\n\u003e https://github.com/gavinandresen/bitcoin-git/tree/relax_isstandard for code\n\u003e changes).\n\u003e\n\u003e ----\n\u003e\n\u003e Now that we are finally starting to see the use of multi-signature and other\n\u003e more complicated transaction forms in applications I think it is time to\n\u003e open up the \"IsStandard\" transaction rules on the main Bitcoin network.\n\nAgreed!\n\n\u003e Discussion\n\u003e ----------\n\u003e Allowing any P2SH Script would allow an attacker to craft a single standard\n\u003e transaction output that requires on the order of 200 ECDSA signature\n\u003e checking operations to validate-- an order of magnitude more than is\n\u003e currently allowed. Therefore I am proposing that we keep the current\n\u003e 15-signature-checking-operations-per-transaction-output limit in place, but\n\u003e allow any combination of enabled Script opcodes. So, for example, you might\n\u003e have a P2SH Script that is redeemed with 2-of-2 OR 2-of-3 using:\n\nSoungs good to me - to lift the restrictions and increase flexibility,\nbut also to be a careful and keep the DoS limits.\n\n\u003e The reference implementation's wallet will still only recognize P2SH\n\u003e transactions that use one of the standard transaction forms. To actually USE\n\u003e a new transaction form will require specialized wallets or specialized\n\u003e applications.\n\nThat's of course completely separate. As we all know, most wallet\ninnovation doesn't happen in the reference implementation wallet, and\nit should not be used as the guide here.\n\nWladimir",
"sig": "def5f8a2fd6651fec3fcdcbd46e1bda2bf9677871bad6beae2fb9b668d93288e768877c3ca8f2e08c46e1b7a25d5067d18896f753d1a7127ee2d21c351ac1368"
}