Yeah, you wish. Today I went to pay an invoice and the transaction fees have suddenly rocked up again to 280 sat/vB for low priority, and pruning is activated for <21 sat/vB. 

I like this option more since at the very least it makes abuse very expensive while satisfying those who claim "censorship"!
But through script size threshold not OP codes because if we place any kind of restrictions on OP codes we may end up hurting regular users who aren't injecting junk into the blockchain.

I may have a simpler idea - adjust the weight unit calculation and place x10 multiplier on script sizes >10000 bytes. This means the vsize is now almost x10 itself which corresponds to an x10 increase in fees. Now Ordinals and BRC-20 users who abuse the protocol to dump stupid JSON like:


will be paying a penalty to miners (who still win regardless, because even if BRC-20 volume reduces to 10% the x10 fee on the remaining inscriptions compensates for that.) Also covers OP_RETURN edge cases at the cost of making fringe use-cases for Bitcoin more expensive for L2 node operators.

great thing about code is there are many ways to do thing
however fees recently were 5sat/byte.. now 200sat/byte.. meaning 40x.. so you only wanting to penalise them by 10x is low
also them taking up 10kb with lean tx being 0.25kb is again a 40x space steal.. so penalty should be way more then 10x. more so a minimum multiplier of 40x.. id prefer 200x



i was thinking back to the days when there was a fee formulae that created a 'priority' score. where by first 50,000bytes had 'priority' of 0 fee(lean tx, old utxo age). then there was 250,000byte of high fee space and then 700,000byte of low priority low fee..
but modernising it by using a priority space based on opcodes.. where there were 2 separate "fee estimation" where nodes would default to 200x fee for the 10% space of junk.. that junk can only go in that 10% space. and mining pools would only put junk in if they are paying the 200x fee rate estimate..
this too would make the scam junkers think again if its costing them 200x * X% of blockspace for 1 tx.. and instead they become leaner to fit in more brc creations per block in that 10% allotment. but yes paying 200x for lean junk

This is true. As a collector of old blockchain knick-knacks I looked into it once and all the original Colored Coins protocols are dead. I tried messaging their creators and they never responded to me.


Point taken. The big difference is BRC-20 tokens can't offer any kind of functionality... They aren't being used for anything other than hot potato ponzinomics. I suspect we'll never see them gain functionality as it will be prohibitively expensive to move them around as compared to ETH (usually), MATIC or BSC. Besides, that's not what the players of that particular game are there for, anyway.

It depends on how you define downtime. In 2017 there were a couple of times that the exchanges were forced to shut down all deposits and withdrawals of Ether and its tokens because the network congestion had effectively crashed their system!

A real down-time by its real definition is something that stops functioning, and in the context of a cryptocurrency network going through a down-time would probably be when it stops producing blocks and a majority of full nodes can't connect with the rest of the network to validate.


I'm talking about how the network is currently designed, and it's robust.

Yeah the network could be strengthened.  One way is to recognize the main purpose is not sending 0.00009999 btc or less in a send.

As the main chain should not allow small sends.


0.0001 is $3.75 value its small enough.

and 0.00001 is minimum fee that is  $0.375

Also 8mb blocks.

These three changes along with no node pruning allowed would work.

4tb ssd are cheap they can handle a larger chain.

Full sized nodes are a must.

Also certified a ssd with linux os and first 12 years of the chain could be sold by a few companies.

he didnt dismantle anything.. try to read like someone that knows the code.. not someone on auto pilot allegiance to core dev gods sponsorship deal preferences.. .. .. he twisted words and pretended x crap didnt happen (but then debunks himself by then saying it did but not in the way he read me saying it). then he goes on and says things cant be consensus because by definition its not. but then says how nodes are consistant in things based on known parameters..

priority formulae CAN be made a consensus rule.. anything can be made a consensus rule.. the rules are just code. and anything can be made a rule and enforced by the code..

got to love gmax's twistings
everyone this week has seen mempools pruned purely for low fee rate.. everyones seen it. the prune rule is remove transactions due to a fee rate..
where as a fee priority would remove spammy, bloaty transactions first..

so when this was said

he pretends pruning mempool has nothing to do with the fee rate, "market".
(facepalm)
its the fee rate level, rules and code that decides what to prune!! which affects the market.. its all related and symbiotic

rather than a proper coded formulae that would have decided that spammers should be pruned or bloaters should be pruned first

THEY CHOSE to make the pruning no longer remove spam/bloat first. and instead remove low market fee first

the point i raised then and keep raising is we keep getting occurrences of congestion where junk and spam are allowed in and many peoples genuine transactions are dropped due to a fee rate rule. rather than a rule that actually prefers to drop junk/spam first.. rather then a rule that penalises just the junk/spammers
they prefered to "simplify" to "just a fee market" to cause everyone to be penalised when junk/spam occured but not deal with the junk/spam problem..

..
next funny is how he says about how this stuff reduces all the transaction relay repeats.. but then due to their actions, guess what.. people need to re-send their transactions to get back into mempool if the market goes down or respend with a higher fee RBF before being pruned or after being pruned if still not high enough or even send a child transaction to try to keep the low fee in mempool.. thus more transactions do get relayed just to fight the pruning mechanism

its not about that. code can do wonderful things. its not just about nodes own mempools. thats just the first post/checkpoint that makes transactors think about the transactions they produce to have best chance of even reaching a mining pool... when broadcasting to peers at the pre-confirm relay
if they want better chances, they organise there transaction to be lean, mature utxo and not use certain junk opcodes

separately.. the consensus enforcement..
its about when mining pools solve a block. nodes check if they contain junk that has not paid fair fee according to fee formulae.. reject the block. thus enforcing pools to actually choose transactions wisely. its what consensus rules are for

you call it censorship resistance.. but just look at what mining pools do now. they cherry pick transactions anyway. atleast having decency rules about what should get priority to get included first.. where the indecent junk get penalised personally if they want to be included. again its not censorship if a spammy junk bloaty transaction has to pay 200x higher than a normal tx.


not even a 2 step mining process.. just a fee formulae score reading. as soon as it reaches a threshold of priority, put it in the block template, if not just leave it in mempool until utxo age matures or transactor RBF. or mempool of mining node prunes low priority thresholds

...
my posts about a fee priority formulae are not about censoring (default reject, no question) transactions. its about penalising transactions specifically independently without penalising everyone.. transactions that spam(young utxo). bloaty transactions(tx length). junk transactions (abuse unconditioned opcodes)