Restrictions on Script Public Keys with standardness rules #137
Conversation
benthecarman
force-pushed
the
standardness-rule
branch
3 times, most recently
from
f53d608 to
bcf142d
Compare
| 2. `OP_HASH160` `20` 20-bytes `OP_EQUAL` (pay to script hash), OR | ||
| 3. `OP_0` `20` 20-bytes (version 0 pay to witness pubkey hash), OR | ||
| 4. `OP_0` `32` 32-bytes (version 0 pay to witness script hash), OR | ||
| 5. `OP_1` through `OP_16` inclusive, followed by a single push of 2 to 40 bytes |
There was a problem hiding this comment.
Are those rules scoping funding inputs script pubkey ? Note, non-Taproot and v1+ witness program spends aren't standards and will be rejected by the current Bitcoin Core policy (see AreInputsStandard in src/policy/policy.cpp).
Unless we fully verify inputs pubkeys and witnesses against standardness rules, a malicious counterparty should be able to fail propagation of the funding tx...
There was a problem hiding this comment.
Added to apply to funding inputs
There was a problem hiding this comment.
Ooops, my bad, I meaned that input scriptpubkey standardness isn't the same that output one. Non-Taproot and v1+ witness program are excluded for inputs. So I would formalize differently,
"If the scriptpubkey is sent to: P2PKH, P2SH, P2WPH, P2WSH, segwit v1+"
"If the scriptpubkey is spent from : P2WPKH, P2WSH"
Note the restriction on inputs excluding P2SH, P2PKH, THIS IS UNSAFE TO USE NON-SEGWIT INPUTS !
A malicious counterparty can malleate the input, confirm the funding, break the sigs of second-stage dlcs/refund and thus take in hostage collateral funds.
There was a problem hiding this comment.
Fixed to use the same wording for inputs as the BOLTs
benthecarman
force-pushed
the
standardness-rule
branch
from
bcf142d to
e5a539c
Compare
benthecarman
force-pushed
the
standardness-rule
branch
from
e5a539c to
2256f71
Compare
benthecarman
force-pushed
the
standardness-rule
branch
from
2256f71 to
29a8538
Compare
Closes #53
standardness rules taken from: lightning/bolts#672