📅 Original date posted:2019-02-05
📝 Original message:On 2/4/19 8:18 PM, Jim Posen via bitcoin-dev wrote:
- snip -
> 1) Introduce a new P2P message to retrieve all prev-outputs for a given
> block (essentially the undo data in Core), and verify the scripts
> against the block by executing them. While this permits some forms of
> input script malleability (and thus cannot discriminate between all
> valid and invalid filters), it restricts what an attacker can do. This
> was proposed by Laolu AFAIK, and I believe this is how btcd is
proceeding.
I'm somewhat confused by this - how does the undo data help you without
seeing the full (mistate compressed) transaction? In (the realistic)
thread model where an attacker is trying to blind you from some output,
they can simply give you "undo data" where scriptPubKeys are OP_TRUE
instead of the real script and you'd be none the wiser.
On 2/5/19 1:42 AM, Olaoluwa Osuntokun via bitcoin-dev wrote:
- snip -
> I think it's too late into the current deployment of the BIPs to change
> things around yet again. Instead, the BIP already has measures in place for
> adding _new_ filter types in the future. This along with a few other filter
> types may be worthwhile additions as new filter types.
- snip -
Huh? I don't think we should seriously consider
only-one-codebase-has-deployed-anything-with-very-limited-in-the-wild-use
as "too late into the current deployment"?
Matt
Matt Corallo [ARCHIVE] /
npub1e4…jxmcu
2023-06-07 18:16:22
in reply to nevent1q…0zgn
Author Public Key
npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcuSeen on
wss://relay.nostr.bandPublished at
2023-06-07 18:16:22Event JSON
{
"id": "6aefb205d4d06e1958b401743c677654908ad3cf87628f807c14f09ad29d21b0",
"pubkey": "cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba",
"created_at": 1686161782,
"kind": 1,
"tags": [
[
"e",
"97c0ce78b62d3274e700b5b31976e55b4f8b4af0d55ebfe0f570f183e8cfddf3",
"",
"root"
],
[
"e",
"2c37387a187e289459cfd5f67ff329851c2776cc6973bc4c34a1cd6632fa7b28",
"",
"reply"
],
[
"p",
"2df3fc2660459521b852c995d4fc1a93938389a5e085677d0ebb33ef92cc5476"
]
],
"content": "📅 Original date posted:2019-02-05\n📝 Original message:On 2/4/19 8:18 PM, Jim Posen via bitcoin-dev wrote:\n- snip -\n \u003e 1) Introduce a new P2P message to retrieve all prev-outputs for a given\n \u003e block (essentially the undo data in Core), and verify the scripts\n \u003e against the block by executing them. While this permits some forms of\n \u003e input script malleability (and thus cannot discriminate between all\n \u003e valid and invalid filters), it restricts what an attacker can do. This\n \u003e was proposed by Laolu AFAIK, and I believe this is how btcd is \nproceeding.\n\nI'm somewhat confused by this - how does the undo data help you without \nseeing the full (mistate compressed) transaction? In (the realistic) \nthread model where an attacker is trying to blind you from some output, \nthey can simply give you \"undo data\" where scriptPubKeys are OP_TRUE \ninstead of the real script and you'd be none the wiser.\n\nOn 2/5/19 1:42 AM, Olaoluwa Osuntokun via bitcoin-dev wrote:\n- snip -\n\u003e I think it's too late into the current deployment of the BIPs to change\n\u003e things around yet again. Instead, the BIP already has measures in place for\n\u003e adding _new_ filter types in the future. This along with a few other filter\n\u003e types may be worthwhile additions as new filter types.\n- snip -\n\nHuh? I don't think we should seriously consider \nonly-one-codebase-has-deployed-anything-with-very-limited-in-the-wild-use \nas \"too late into the current deployment\"?\n\nMatt",
"sig": "afc135b17c2bba467991a3035a4b28f9dd08304bc25fea11a0ef4d3f6a12aca2042b9b0668587ba27afffdd0861de5c963e46fc806ff94f8b495a19fdc18e216"
}