Your objection to BIP110 ??

[PepeLapiu]

Lets make a trade then, --- we'll pick some neutral arbitration process, to decide if I'm right or you are right that if a coin is controlled by a classical timelock commit authored now that pays to a 110 prohibited script (such as a big multisig)

I see what you did here. Sneaky coretard!

Your original claim was that if the user commits his coin into a timelock with op_if in Taproot, and he deletes his keys, as part of some stoopit kinap prevention scheme, than he would lose his coin to BIP110.

Can you find me a tutorial on how to do this anywhere on line? Preferably something done before BIP110 was announced some 6-8 months ago.

Is there anyone anywhere who teaches people to delete their keys as a way to protect their coin with op_if in Taproot? Asking for a friend.....

For security some people have made transactions which are timelocked for the future, so that e.g. kidnappers can't force them to make payments or so that the transactions for inheritance will only be valid in the future.  After making the transaction they can delete their private keys so that they can't be forced to make any more alternatives, or they can simply lose them -- an eventuality that the presigned transaction was created to pay for.    These presigned transactions can pay to any valid address, for example a 4 of 8 taproot multisig that has a tree depth of more than 7 levels (e.g. family members/friends/heirs).

BIP110 would functionally destroy these coins.  

Where can I find a tutorial on how to commit my coin to a timelock with op_if in Taproot, and delete my keys, as an acceptable method of kidnap prevention?

[ertil]

Is it really necessary for bitcoin to survive as money to have all those stupid "smart contracts"?

It is not necessary, but once you have it, then removing it would mean confiscating people's coins.

Because of that, I wanted to design it to support every possible transaction type I could think of.  The problem was, each thing required special support code and data fields whether it was used or not, and only covered one special case at a time.  It would have been an explosion of special cases.  The solution was script, which generalizes the problem so transacting parties can describe their transaction as a predicate that the node network evaluates.  The nodes only need to understand the transaction to the extent of evaluating whether the sender's conditions are met.

And now, BIP-110 says: "your Script is too complicated for us to understand, let's make it unspendable". If it would succeed, then people would never know, where that "too complicated" starts, and where it ends (because BIP-110 supporters never defined any list of cases, which they wouldn't block in the future). Which means, that it would be necessary, to constantly ask Luke, which Script will be accepted, and which will be blocked, because otherwise, you would risk sending it to some Script, which would be blocked later, just because it is too complex for some people to understand.

Edit:

New output scriptPubKeys exceeding 34 bytes are invalid, unless the first opcode is OP_RETURN, in which case up to 83 bytes are valid.

That means a simple 2-of-2 bare multisig will be invalidated by BIP-110. Which means invalidating things, which were widely used since BIP-11, created in 2011.

Edit: Even better: if someone has a timelocked transaction with a single uncompressed public key, then it would be invalid:

Code:

+--------------------------------------+
| Alice 50.00 BTC -> Charlie 99.99 BTC |
| Bob   50.00 BTC                      |
+--------------------------------------+
| timelock: 2026-10-15                 |
+--------------------------------------+

If Charlie's public key is uncompressed, then his coins are burned by BIP-110. No multisig, no tricks, just a plain, old, P2PK, used by Satoshi.

Which means, that after activating BIP-110, this transaction would be invalid as well: https://mempool.space/tx/f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16

[PepeLapiu]

Is it really necessary for bitcoin to survive as money to have all those stupid "smart contracts"?

It is not necessary, but once you have it, then removing it would mean confiscating people's coins.

Bullshit! Nobody is knowledgeable enough to be using Nunchuk to construct a complicated and convoluted inheritance scheme with op_if in Taproot, while simultaneously being unaware of the coming new rules, while simultaneously using an old out of date wallet or one that refuses to update to BIP110, and doing both the commit and redeem during the one year period of BIP110, and also choosing to delete their keys.

And now, BIP-110 says: "your Script is too complicated for us to understand, let's make it unspendable".

LOL. BIP110 says "your script of too spammy for us to deal with, let's freeze it for a year."

If it would succeed, then people would never know, where that "too complicated" starts, and where it ends (because BIP-110 supporters never defined any list of cases, which they wouldn't block in the future).

To change the rules in the future, we'd have to fork again. There is no BIP110 ability to change the rules on the fly.

BIP110 is an anti-spam upgrade. You don't like it because you are a coretard and a spammer. So you grasp at straws to make up any scenario that makes BIP110 look bad.

Which means, that it would be necessary, to constantly ask Luke, which Script will be accepted, and which will be blocked

You are an idiot, or you think everyone else is an odiot. Nobody can change the rules on the fly.