@franky1
Where have you been Frank, by the way?
Nowadays, we are short of true bitcoiners, the kind of people who have not given up with bitcoin and are still committed to the cause: an electronic p2p cash system. Where the hell are other guys?
I feel so lonely sometimes here the stupid block size debate has polarized this community in the worst way ever and we are short of true bitcoin advocates, keep posting more.
As of tx/s throughput I would say like 100 tx/s suffices for near future and is achievable by few improvements definitively including
1- a block time decrease
2- using schnorr signatures
for mid term we need decentralization by getting rid of pools to be prepared for sharding.
We should never ever trust any second layer protocol/solution for scaling or other serious issues which bitcoin is designed for. Putting utilities on top of bitcoin is not bad, actually it would be very helpful as long as such utilities are not designed to compete with bitcoin and alienate people from the core system.
1. a blocktime decrease doesnt help. it actually affects many other things and has to many impacts on other things to outweight a pro:con balance to make it plausible.
its far better to stay at 4mb per 10 min than do 1mb for 2.5min
2. schnorr sigs are useful for multisigs because it compact multiparties signatures to show as just 1 signature to hide who signs it. there are security risks as people can make a 2of 5 multisig. pretend its a 2 of 2 address and get someone to deposit funds into it (thinking they have absolute 50% control) and then the 2 of the 4 conmen sign it without the user who deposited funds knowing who actually signed it. and the transaction then appears like he consented to it. thus no legal route of recovery due to lack of proof that he didnt consent.
in a normal lean legacy payment system, you dont need dual signing or second party authorisation. thus no multisig, thus no compacting.. that was the point of bitcoin. not needing others. like i said going back to simple lean transactions is best
3. other things can be done instead, like opcodes that just need 1 sig even if there are 500 inputs from the same address.
so that if 500 different people paid into one address i wont need to sign all 500 times. but just once because its all in one address.. which is done by certain opcode not a schnorr
4. other things like new rules that if a mempool is more than 1mb but a block is less than 1mb then the pool is doing an obvious 'empty block' and thus gets auto rejected. thus ensuring pools are incentivised to fill blocks or not get a block reward. and thus help prevent pools backlogging transactions or trying to bottleneck the network by delaying confirmations of transactions by avoid adding them.. which is also a solution to one of the '51% attack vectors'. after all no one is silly enough to 51% a network just to reverse their coffee purchase. so the only 'threat' of a 51% attack is to bottleneck the network by not including tx's
5. if you want to decrease the blocktime to make it more user friendly for the 'i dont wanna wait at a cashier desk for 10 minute' argument.. well sorry but 2.5mins is just as lengthy a wait and doesnt really solve a queue build up at a retailer.
but that can be solved easily by funding a address a retailer owns(bartab analogy) and then let the retailer deduct balance internally on their system.
6. as for sharding. well thats just 2nd layer again. sharding is just LN factories of many tx's and multiple parties when you rub away alot of the buzzwording. sharding is from a banking analogy just like regional bank branches .. id say its better than reducing blocktime. but at the same time its then formalising the infrastructure into what banks do by forcing certain peoples activities being routed to a specific small pool of nodes
after all its far easier to deposit $90 into a starbucks legacy address and they just give you an in app balance of $90(30 coffee's) then to do all the convoluted effort of, make 5 LN locked channels funded with $18 per channel for good 'connectivity'/chance of success, but has the risks of channel offline situations(not able to spend $18) .. just for you to be able to buy at most 30 coffees(as long as all routes are avalable on the days after each $18 channel funds are spent).
think about it 10 onchain tx's to setup and eventualy close 5 channels. and no guarantee of being able to spend all $90.
where as just paying starbucks $90 in 1 legacy tx and they give you an inapp balance is so much easier for everyone and the network and even onchain fees
and especially with the risks that OTHER LN people will spend those $18 channel values by routing through you.. in short LN doesnt guarantee your $90 gets you 30 coffees.. but just depositing $90 (prepay) into a legacy address does
and thats the real funny part. those 'it cant scalers' think that the debate is about buying 1 coffee 3 times a day cant scale so needs offchain systems forced on everyone. when infact it just needs regular coffee drinkers to bulk buy(bartab) their coffee, but done simply using legacy transaction. rather than alternative networks requiring everyone to be online allday every day and where routing is required thus many people signing and agreeing to be part of your payment..
devs are over complicating solutions to issues they stifled and created themselves, all so they can own one of the precious future hubs/shards of nodes to get loads of fee's to repay their investors