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

Quote from: franky1 on Today at 10:33:42 AM

Quote from: ETFbitcoin on Today at 10:03:55 AM

Since i didn't find word "size", "block size" and "hard fork", i'll ask these question to @franky1
1. Do you think increasing block size limit is the only option for scaling (since you're not fan of SegWit, Taproot and LN)?
2. How should Bitcoin community determine block size limit? Arbitrary number (4MB, 32MB, etc.)? Based on hardware/internet growth? Based on cost of running full node (e.g. maximum $500 for initial setup and $25/month for operational cost)?

1. there are many ways to increase transaction counts.
a. reducing the tx_signops_limit. dis-incentivises big corps from filling blocks with just a few hundred transactions

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;

this could be brought down.. not to just 1-2 like you are thinking, but to say 50 or a few hundred, thus still allowing batching but preventing a max sigops attack of blocks with only 5 transactions using up the block limits

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

Quote from: franky1 on Today at 10:33:42 AM

c. also changing the fee formulae to make 'spam transactions (those that spend multiple times a day/every block, just to bloat blocks) more expensive will cut down the amount of needless transactions, giving more room to genuine spenders

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

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

1. miners do already have a 'fee' formula.. i already explained that they obide by the x 4 legacy rule..
you can tell because legacy transactions are more expensive and so if pools only followed greed of 'more sats the better' they would only accept legacy transactions. and ignore "cheap" segwit.
the very reason they deem a segwit "cheap" the same 'value' as a legacy 'premium' is becasue they do follow the x4 calculation of value per byte/vbyte

2. again they already do support it.

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

Quote from: franky1 on Today at 10:33:42 AM

as for what the community wanted in 2017 was a 2mb base atleast. i would now say thats about 4mb base block as a acceptable way to go. and that can be achieved by just removing the 'weight' miscalculating cludgy code and just having the maxblocksize as 4mb straight and open for full transaction utility. along with a new fee formulae and sigoplimit reduction to avoid bloaty spam.

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..
also the march2017-august 2017 proved that mandated activation can happen. (bip148 and bip91)

oh and because the consensus.h rule is maxblocksize 4mb. the hard block rule is 4mb. its just the cludgy code after that limits some transactions to not utilise it. so all the majority nodes of 2017+ dont need an upgrade. blocks wont be rejected for being 4mb