Yes, sorry if I was unclear. The temporary restriction of 257 B is
ultimately based on the size, which doesn't accommodate for that design
ideal. It's a tradeoff until a better solution is implemented. While it
might not be optimal in all cases to have 128 scripts, the fact remains
that size/depth _allows for it_. (And 128 depth is still unrealistic,
even if you don't like the script-count framing.)
Luke
On 10/4/25 19:12, jeremy wrote:
- Limit taproot control block to 257 bytes (128 scripts max), or at
least way less than it currently is. 340e36 scripts is completely
unrealistic.
this is a misunderstanding of taptree's depth purpose, which is not to
bound the number of elements directly.
It's a bound on the huffman encoding to optimize for on-chain cost
with many scripts and known likelihood of execution.
So the right way to constrain taproot is by bounding the minimum
probability of script execution. E.g., if it's one-in-4 billion chance
of executing, then you'd need depth 32.
128 depth was chosen because if a branch is (2^128 -1)/2^128 unlikely
to execute, then it's negligibly likely, the same order of probability
as being able to e.g. brute force a key.
On Friday, October 3, 2025 at 6:46:16 PM UTC-4 /dev /fd0 wrote:
Hi Luke,
> We can do these all together in a temporary softfork that
self-expires after a year or two.
That sounds reasonable and it could work if we can agree on the
specifics of this proposal. As Jeremy also mentioned in his email,
we could set up an auto-renewing restriction lasting 1–2 years
with the option to remove it later if we decide we want to.
/dev/fd0
floppy disk guy
On Sat, Oct 4, 2025 at 1:39 AM Luke Dashjr <[email protected]> wrote:
If we're going this route, we should just close all the gaps
for the immediate future:
- Limit (new) scriptPubKeys to 83 bytes or less. 34 doesn't
seem terrible. UTXOs are a huge cost to nodes, we should
always keep them as small as possible. Anything else can be
hashed (if SHA256 is broken, we need a hardfork anyway).
- Limit script data pushes to 256 bytes, with an exception for
BIP16 redeem scripts.
- Make undefined witness/taproot versions invalid, including
the annex and OP_SUCCESS*. To make any legitimate usage of
them, we need a softfork anyway (see below about expiring this).
- Limit taproot control block to 257 bytes (128 scripts max),
or at least way less than it currently is. 340e36 scripts is
completely unrealistic.
- Make OP_IF invalid inside Tapscript. It should be
unnecessary with taproot, and has only(?) seen abuse.
We can do these all together in a temporary softfork that
self-expires after a year or two. This would buy time to come
up with longer-term solutions, and observe how it impacts the
real world. Since it expires, other softforks making use of
upgradable mechanisms can just wait it out for those
mechanisms to become available again - therefore we basically
lose nothing. (This is intended to buy us time, not as a
permanent fix.)
Alternatively, but much more complex, we could redesign the
block weight metric so the above limits could be exceeded, but
at a higher weight-per-byte; perhaps weigh data 25% more per
byte beyond the expected size. This could also be a temporary
softfork, perhaps with a rolling window, so future softforks
could be free to lower weights should they be needed.
Another idea might be to increase the weight based on
coin-days-destroyed/coin-age, so rapid churn has a higher
feerate than occasional settlements. But this risks
encouraging UTXO bloat, so needs careful consideration to
proceed further.
Happy to throw together a BIP and/or code if there's community
support for this.
Luke
On 10/2/25 16:42, PortlandHODL wrote:
Proposing: Softfork to after (n) block height; the creation
of outpoints with greater than 520 bytes in the ScriptPubkey
would be consensus invalid.
This is my gathering of information per BIP 0002
After doing some research into the number of outpoints that
would have violated the proposed rule there are exactly 169
outpoints. With only 8 being non OP_RETURN. I think after 15
years and not having discovered use for 'large'
ScriptPubkeys; the reward for not invalidating them at the
consensus level is lower than the risk of their abuse.
* *Reasons for
*
o Makes DoS blocks likely impossible to create that
would have any sufficient negative impact on the network.
o Leaves enough room for hooks long term
o Would substantially reduce the divergence between
consensus and relay policy
o Incredibly little use onchain as evidenced above.
o Could possibly reduce codebase complexity. Legacy
Script is largely considered a mess though this isn't
a complete disablement it should reduce the total
surface that is problematic.
o Would make it harder to use the ScriptPubkey as a
'large' datacarrier.
o Possible UTXO set size bloat reduction.
* *Reasons Against *
o Bitcoin could need it in the future? Quantum?
o Users could just create more outpoints.
Thoughts?
source of onchain data
<https://github.com/portlandhodl/portlandhodl/blob/main/greater_520_pubkeys.csv>
PortlandHODL
--
You received this message because you are subscribed to the
Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/bitcoindev/6f6b570f-7f9d-40c0-a771-378eb2c0c701n%40googlegroups.com
<https://groups.google.com/d/msgid/bitcoindev/6f6b570f-7f9d-40c0-a771-378eb2c0c701n%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the
Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/bitcoindev/001afe1d-0282-4c68-8b1c-ebcc778f57b0%40dashjr.org
<https://groups.google.com/d/msgid/bitcoindev/001afe1d-0282-4c68-8b1c-ebcc778f57b0%40dashjr.org?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google
Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/bitcoindev/1e0f9843-0f08-4dea-b037-24df38bf8ed0n%40googlegroups.com
<https://groups.google.com/d/msgid/bitcoindev/1e0f9843-0f08-4dea-b037-24df38bf8ed0n%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
You received this message because you are subscribed to the Google Groups "Bitcoin
Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/bitcoindev/0585bba3-fb88-41d6-b86c-167774c14eb9%40dashjr.org.
