bitcoin
bitcoin copied to clipboard
petertodd
Raise witness stack element sizes to consensus limit
sounds good to me for experimentation. historically been concerns about raising such limits for the worst-case computationally witness. some old conversations here: https://bitcoincore.reviews/21224
In my discussions with miners about Libre Relay, a key thing they've asked for is good unit tests. So any change like this needs to be combined with whatever changes are needed to update the unit tests.
I also second the potential concerns re: DoS attacks. We should be confident that we're not potentially causing problems for miners. That's easy to do with OP_Return, as those scripts can't be executed. Not so easy otherwise.
I also second the potential concerns re: DoS attacks. We should be confident that we're not potentially causing problems for miners. That's easy to do with OP_Return, as those scripts can't be executed. Not so easy otherwise.
@reardencode See the soft / hard limit approach implemented in #6 as a way to minimize DoS surface for raising witness stack element sizes to consensus limit. Current default could stay the soft limit, while it could be opting set by full-node operators to max hard limit.
I think it'd be more useful to carefully analyze whether or not the stack element sizes pose a DoS attack risk. If they don't, we can just remove the limit.
Of course, IIUC there are no standardness limits for tapscript; that may be sufficient to address the realistic market demand. If no-one wants to create transactions with above-standard stack limits using legacy script, we don't need to change anything.
I think it'd be more useful to carefully analyze whether or not the stack element sizes pose a DoS attack risk
I think stack element sizes poses a DoS attack risk, in a world where you have things like OP_HASH160 / OP_SHA256. Of course, it’s let computational ressources consumption than an OP_CHECKSIG.
SHA-256 on a megabyte of data is something BitTorrent has done on older computers for a long time
