Replies inline.
On 3/7/19 10:44 AM, Luke Dashjr wrote:
On Wednesday 06 March 2019 21:39:15 Matt Corallo wrote:
I'd like to ask the BIP editor to assign a BIP number.
Needs a Backward Compatibility section, and should have a bips repo PR opened
after discussion on the ML.
Oops, I guess most of the "Discussion" section can just be moved into a
"Backwards Compatibility" section. Will do before PR'ing.
* The 4th change (making non-standard signature hash types invalid)
may be worth discussing. In order to limit the number of potential
signature hashes which could be used per-input (allowing us to cache
them to avoid re-calculation), we can disable non-standard sighash
types. Alternatively, however, most of the same effect could be achieved
by caching the just-before-the-last-byte sighash midstate and hashing
only the last byte when a checking signatures. Still, them having been
non-standard for many years makes me doubt there is much risk involved
in disabling them, and I don't see much potential use-case for keeping
them around so I'd like to just remove them.
I don't understand what is being removed here.
This refers to the following spec change:
If the sighash type byte (ie last byte in a signature being evaluated
during the execution of OP_CHECKSIG[VERIFY] or OP_CHECKMULTISIG[VERIFY])
is anything other than 1, 2, 3, 0x81, 0x82, or 0x83, the script
execution fails. This does not apply to 0-length signature stack elements.
As for why the timewarp vulnerability should (IMO rather obviously) be
fixed, it seems rather clear that the only potential use for exploiting
it would be either to inflate the currency supply maliciously by miners
or to fork in what amounts to extension blocks. As for why extension
blocks are almost certainly not the right approach to such changes, its
likely worth reading this old post:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013510
.html
While I agree that extension blocks are typically a bad choice, I'm not sure
the argument really applies to forward blocks. (That being said, I find
forward blocks overcomplicated and probably not a reason to avoid this.)
I agree they are somewhat separate ideas, but the arguments in that
thread apply equally to timewarp-based inter-block-time reductions. If
you want to discuss it further, I'd suggest a new thread.
* Transactions smaller than 65 bytes when serialized without witness
data are invalid.
Rationale should include the reason(s) why the size doesn't count the witness
here.
Will add.
** Note that miners today only enforce increasing timestamps against the
median-timestamp-of-last-11-blocks, so miners who do not upgrade may
mine a block which violates this rule at the beginning of a difficulty
window if the last block in a difficulty window has a timestamp in the
future. Thus, it is strongly recommended that SPV clients enforce the
new nTime rules to avoid following any potential forks which occur.
This should probably be moved outside Discussion. (Perhaps to the missing
Backward Compatibility section?)
* There are several early-stage proposals which may affect the execution
of scripts, including proposals such as Schnorr signatures, Taproot,
Graftroot, and MAST. These proposals are not expected to have any
interaction with the changes in this BIP, as they are likely to only
apply to SegWit scripts, which are not covered by any of the new rules
except for the sighash type byte rule. Thus, the sighash type byte rule
defined above only applies to *current* signature-checking opcodes, as
any new signature-checking is likely to be implemented via the
introduction of new opcodes.
It's not clear that new opcodes will necessarily always be used. Probably
would be good to clarify the "non-Segwit or witness v0 only" rule in the
Specification section.
Note that you inherently have to use a new opcode for such things - the
non-standard type bytes *are* defined and define a sighash/signature,
they can't be simply redefined to a new sighash/signature type in a soft
fork.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
