Bram Cohen's proposal to deal with onchain spam. \ stacker news ~bitcoin

pull down to refresh

Bram Cohen's proposal to deal with onchain spam.bramcohen.com/p/the-problem-with-inscriptions

1104 sats \ 4 comments \ @denationalized 9 Mar bitcoin freebie

I agree with the second paragraph of this post.

#ordinals #inscriptions #brc20

it would be far better for Bitcoin development to put together a soft fork to create a vbytes cost for UTXO creation

I don't understand this, does it mean to write more data into the block when there is more witness data? So.. increase the impact of "spam"? Or are miners currently not aware of the size of the witness data and can't compute the vbyte cost? Must be something else, because these two don't make sense?

31 sats \ 0 replies \ @denationalized OP 9 Mar

I don't understand this, does it mean to write more data into the block when there is more witness data? So.. increase the impact of "spam"? Or are miners currently not aware of the size of the witness data and can't compute the vbyte cost? Must be something else, because these two don't make sense?

The vbyte metric helps to adjust for the fact that witness data is discounted in SegWit transactions. For non-SegWit transactions (legacy transactions, not much used anymore), the transaction size in bytes is the same as the size in virtual bytes (vbytes). For SegWit transactions, the size in vbytes is typically less than the size in bytes due to the discount applied to witness data.

Miners prioritize transactions based on their fee rate per vbyte. Users may want to optimize their fees by considering the effective size of the transaction in vbytes rather than the raw size in bytes.

TLDR: Witness data is cheaper than the rest of the data in transactions. Bram proposes to make witness data more expensive. Making it more expensive may cause the users to pay slightly more on average than before Taproot but should help in pricing out spammers (an that should in turn drive down the fees).

P.S. Bitcoin's last soft fork, Taproot, is also called SegWit v.1. Not to be confused with SegWit v.0.

0 sats \ 1 reply \ @hasherstacker 10 Mar

It’s massively increasing the costs of running full nodes and hence bad.

Back in 2015 such things got railroaded through so fast that even the core devs were alarmed at how much it smacked of centralized control, but now there’s the opposite problem, where even simple obvious fixes can’t get in.

What is being done to fix this?

0 sats \ 0 replies \ @denationalized OP 10 Mar

Nothing that I am aware of. I am worried by the lack of proposals and soft-forks.