š
Original date posted:2014-06-19
š Original message:On Wed, Jun 18, 2014 at 08:52:22AM -0400, Gavin Andresen wrote:
> RE: most of Peter Todd's comments:
>
> All of that should be separate pull requests. Big Honking Pull Requests
> are harder to review and are more likely to be bike-shedded to death.
Well, just doing one and not the rest isn't necessarily a good idea. The
malleability protection definitely seems like a good idea, and has had
quite a bit of review.
> RE: not relaying/mining transactions with OP_NOPs so miners don't mine
> up-version transactions that are invalid under future-new-rules: I'm not
> convinced it is worth adding more code (more potential for bugs) to protect
> against something that isn't going to happen because up-version
> transactions are non-standard (due to version check) in any case.
Do we have consensus that future soft-forks to add new opcodes will
always be done in conjunction with a transaction nVersion bump? If so,
then that's ok, if not, then we should have a whitelist.
The code to restrict the opcodes to the softfork-safe subset is trivial,
a GetOp() loop and a switch statement. It can always be removed later.
Something that comes to mind is if we do always bump nVersion then
OP_NOPx always will have a parallel "do-nothing" behavior, which means
EvalScript() will always have to have code enabling that backwards
compatible behavior.
--
'peter'[:-1]@petertodd.org
000000000000000004e51d8d00eedb31ec1505d245f48960896b79f0e7193c2a
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 685 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140619/7b5d77e8/attachment.sig>;
Peter Todd [ARCHIVE] /
npub1m2ā¦a2np2
2023-06-07 15:23:05
in reply to nevent1qā¦0c68
Author Public Key
npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2Seen on
wss://relay.noswhere.comPublished at
2023-06-07 15:23:05Event JSON
{
"id": "aad549dcaffb3800c0ff7e5591e8cd2baf09a8a8da5bb01969349f3ccaf86d62",
"pubkey": "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa",
"created_at": 1686151385,
"kind": 1,
"tags": [
[
"e",
"17417d4d019b711f77b6899176af0fd8ebc69e7fc942137a5d14e724419b7980",
"",
"root"
],
[
"e",
"a126c9630fcfc31c4ba94c2cfa24fc8248273135045fa108bfc0e6bf2b6a5ae2",
"",
"reply"
],
[
"p",
"857f2f78dc1639e711f5ea703a9fc978e22ebd279abdea1861b7daa833512ee4"
]
],
"content": "š
Original date posted:2014-06-19\nš Original message:On Wed, Jun 18, 2014 at 08:52:22AM -0400, Gavin Andresen wrote:\n\u003e RE: most of Peter Todd's comments:\n\u003e \n\u003e All of that should be separate pull requests. Big Honking Pull Requests\n\u003e are harder to review and are more likely to be bike-shedded to death.\n\nWell, just doing one and not the rest isn't necessarily a good idea. The\nmalleability protection definitely seems like a good idea, and has had\nquite a bit of review.\n\n\u003e RE: not relaying/mining transactions with OP_NOPs so miners don't mine\n\u003e up-version transactions that are invalid under future-new-rules: I'm not\n\u003e convinced it is worth adding more code (more potential for bugs) to protect\n\u003e against something that isn't going to happen because up-version\n\u003e transactions are non-standard (due to version check) in any case.\n\nDo we have consensus that future soft-forks to add new opcodes will\nalways be done in conjunction with a transaction nVersion bump? If so,\nthen that's ok, if not, then we should have a whitelist.\n\nThe code to restrict the opcodes to the softfork-safe subset is trivial,\na GetOp() loop and a switch statement. It can always be removed later.\n\nSomething that comes to mind is if we do always bump nVersion then\nOP_NOPx always will have a parallel \"do-nothing\" behavior, which means\nEvalScript() will always have to have code enabling that backwards\ncompatible behavior.\n\n-- \n'peter'[:-1]@petertodd.org\n000000000000000004e51d8d00eedb31ec1505d245f48960896b79f0e7193c2a\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 685 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140619/7b5d77e8/attachment.sig\u003e",
"sig": "0731aac9f7d10e2a813e6d68f906a0644ec8f07fd692ffe97d234a4660bd279ac28687519a8601a5b118d4543c7b1f7056fb9a30c1a79fb679b46e6f1797030e"
}