Quote from: ETFbitcoin on Today at 12:19:38 PM

Quote from: franky1 on Today at 11:57:01 AM

Quote from: ETFbitcoin on Today at 11:25:17 AM

Wouldn't it prevent custodial service from creating batch transaction (where batch transaction use less block size compared with creating a transaction for each user request)?

no, it wont prevent batching. it will prevent spam over batching by performing the legacy linier sigops attack.
currently there are ways to 'fill a block' using just 5 transactions with 16,000 tx sigops each
static const int64_t MAX_BLOCK_SIGOPS_COST = 80000;
static const unsigned int MAX_STANDARD_TX_SIGOPS_COST = MAX_BLOCK_SIGOPS_COST/5;

Could you show any example? I don't care whether it's on mainnet, testnet or signet.

ask nicely and you shall receive
https://www.blockchain.com/btc/block/364422
its just 2 transactions and filled the block and took the nodes a heck of a long time to validate due to the bloat of soo many signatures

Quote from: franky1 on Today at 11:57:01 AM

Quote from: ETFbitcoin on Today at 11:25:17 AM

Since coin-age priority was never part of Bitcoin protocol,
1. Do you think it's possible to enforce it on Bitcoin protocol? Currently miner/pool can mine empty block and choose any transaction.
2. Most miner/pool will be hesitant to support this change.

also coin-age is part of code. its a simple: current blockheight - utxo blockheight = coin age
and also miners in the first few years did obide by a different fee formulae than the current weight cludge

enforcing it is the same as how pools obide by the weight (vbyte vs byte) formulae

While coin-age was part of code, it was never part of Bitcoin protocol. See https://bitcoin.stackexchange.com/q/54583.
[/quote]
taproot was not part of the protocol before X date.
the thing is though. it is not rocket science to do current height - utxo height.
it does not require a PHD in cryptography to master it.

Quote from: ETFbitcoin on Today at 12:19:38 PM

Quote from: franky1 on Today at 11:57:01 AM

Quote from: ETFbitcoin on Today at 11:25:17 AM

I see, but we know it's more than removing the "weight". Since it require hard fork, it'll force many people to upgrade their software and another activation signal which will take some time (IMO at least 6 months is required) and attract another controversy (such as cutting backward compatibility).

backward compatibility.. ? how many people are actually running nodes from pre 2017.. i bet its not 5% of network
also the march2017-august 2017 proved that mandated activation can happen. (bip148 and bip91)

I'm aware about low percentage of node which use client that doesn't support SegWit. My point it'll be one of reasons against hard-fork.

if there are less than 5% using old nodes that dont like 4mb. then there is no hard fork controversy