Time to restore the pre-taproot transaction size limit?

[donaldhino]

Time to restore the pre-taproot transaction size limit? The timechain should only store financial transactions.

[1714907253]

1714907253

[1714907253]

1714907253

[1714907253]

1714907253

[NotATether]

Doesn't look like that's going to happen, unfortunately.

Well Michael Folkson did explain to me that there are quite a few less efficient but still venomous ways for someone to add spam into the blockchain even if size limits are enforced, by adding them in other parts of a regular transaction.

In particular:

> to curtail the loophole in BIP 342 (which defines the validation rules for Taproot scripts) which has allowed these unintended consequences?

There were technical reasons for the design decisions in BIP 342. As Andrew says in his post [ 0 ]:

"If we ban "useless data" then it would be easy for would-be data storers
to instead embed their data inside "useful" data such as dummy
signatures or public keys. Doing so would incur a ~2x cost to them, but
if 2x is enough to disincentivize storage, then there's no need to have
this discussion because they will will be forced to stop due to fee
market competition anyway. (And if not, it means there is little demand
for Bitcoin blockspace, so what's the problem with paying miners to fill
it with data that validators don't even need to perform real computation
on?).

But if we were to ban "useful" data, for example, saying that a witness
can't have more than 20 signatures in it, then we are into the same
problem we had pre-Taproot: that it is effectively impossible construct
signing policies in a general and composeable way, because any software
that does so will need to account for multiple independent limits. We
deliberately replaced such limits with "you need to pay 50 weight for
each signature" to makes this sort of analysis tractable."

I guess while these morons waste their money buying spam and eggs, I should reactivate some of my L2 projects.

[Carlton Banks]

There were technical reasons for the design decisions in BIP 342. As Andrew says in his post [ 0 ]:

"If we ban "useless data" then it would be easy for would-be data storers
to instead embed their data inside "useful" data such as dummy
signatures or public keys. Doing so would incur a ~2x cost to them, but
if 2x is enough to disincentivize storage, then there's no need to have
this discussion because they will will be forced to stop due to fee
market competition anyway. (And if not, it means there is little demand
for Bitcoin blockspace, so what's the problem with paying miners to fill
it with data that validators don't even need to perform real computation
on?).

But if we were to ban "useful" data, for example, saying that a witness
can't have more than 20 signatures in it, then we are into the same
problem we had pre-Taproot: that it is effectively impossible construct
signing policies in a general and composeable way, because any software
that does so will need to account for multiple independent limits. We
deliberately replaced such limits with "you need to pay 50 weight for
each signature" to makes this sort of analysis tractable."

you've mixed it up, achow101 posted that

[NotATether]

you've mixed it up, achow101 posted that

Good to know, but I actually just pasted this from fanquake's reply to me.

[noonesh]

Taproot intended outcomes are amazing, no discussion. But the unintended consequence, unfortunately washes all the gains away.
Complex transactions would be more efficient, therefore would cost less fees and less block space.

Now what we see is block space (which is a scarce resource) been wasted with things not related to the higher intentions presented here: https://bitcoin.org/bitcoin.pdf

A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution.

Once we had worried about block size, had year long fights around it, wanted as much people as possible to be able to have their own nodes, be able to have a copy of the blockchain and validate transactions by themselves. One of the biggest bragging differences from Bitcoin to Eth was that nobody can run a Full Node of the Shitcoin, but with very low investmant can have a Full Node of Bitcoin.

Now with this NFT/Ordinal thing the gains of Taproot are gone, actually is flooding the blockchain with non-transaction/signature/script-to-spend-utxo data, opened an attack vector, people cannot transact anything lower than 20 USD anymore... Lots of problems.

I don't care with what people spend their money on, but Bitcoin project has a purpose, very well described in the white-paper and in all its history, and the purpose was never to be a P2P cloud storage for people's shitcoins and drawing.

Greatness is scarce in the world and Bitcoin came to rescue that. If this is an unintentional consequence, something should be done to rescue the greatness of Bitcoin, otherwise it will risk to become just a ETH competitor with a prettier story.

[o_e_l_e_o]

you've mixed it up, achow101 posted that

It was Andrew Poelstra, not Andrew Chow.

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021372.html

Leaving aside for a moment the technical aspects of preventing this kind of use case, I tend to agree with this part of the reply from Michael Folkson:

I personally get the desire to "do something". Fee spikes aren't fun especially for some Lightning use cases and many of us don't like how people are using the limited block space currently. But a game of whack-a-mole with blunt tools such as policy rules and especially consensus rules is ineffective at best and harmful at worst. You may not like this use case but assuming you embark on a game of whack-a-mole what's to stop a group of people popping up in a year declaring their opposition to your use case and trying to prevent your use case? Consensus rules are set and the rest is left to the market.

I'm not even that bothered by the fee spikes - more by the storing of trash data on the blockchain. But at the same time, I would be very uncomfortable with with unilaterally deciding what is an acceptable use case. I am vehemently opposed to censorship when it is performed by centralized exchanges, blockchain analysis companies, the odd mining pool, and so on. Why should I be happy with censorship in this case, even if it is blocking a use case I think is worthless?

[ABCbits]

Time to restore the pre-taproot transaction size limit? The timechain should only store financial transactions.

Even before Taproot, it's possible to store non-financial data using either,
1. OP_RETURN.
2. Part of Bitcoin address which represent hashed public key/script.
3. Redeem script which contain arbitrary data. Take note before taproot, script has limit 10000 bytes while Taproot have no such limit.

To ensure blockchain used mostly financial transactions, Bitcoin need to perform hardfork to adopt technology/protocol used by GRIN coin.

I guess while these morons waste their money buying spam and eggs, I should reactivate some of my L2 projects.

Even if you move to L2, usually you need to create on-chain transaction to "move" your Bitcoin.

[Carlton Banks]

Bitcoin need to perform hardfork to adopt technology/protocol used by GRIN coin.

if Grin is better, just use it. I expect the experts are right on this one though: there will always be ways to embed arbitrary data into cryptocurrency transactions, so finding the some "best" way to mitigate it is the true answer

[ABCbits]

Bitcoin need to perform hardfork to adopt technology/protocol used by GRIN coin.

if Grin is better, just use it.

I never intend to claim Grin is generally better than Bitcoin. I mention Grin's technology because it's very poor choice to store data. For example, someone attempt to store Mimblewimble whitepaper on Grin blockchain[1]. But it turns out the data is scattered randomly and the script needed to re-organize scattered data is much bigger than data itself[2].

I expect the experts are right on this one though: there will always be ways to embed arbitrary data into cryptocurrency transactions, so finding the some "best" way to mitigate it is the true answer

I agree on that. But so far there's no serious attempt to find "best" way to make people less interested to store arbitrary data on cryptocurrency blockchain.


[1] https://github.com/NicolasFlamel1/MimbleWimble-Coin-Arbitrary-Data-Storage
[2] https://forum.grin.mw/t/public-transaction-data-is-a-huge-risk-vector/10426/13

[Carlton Banks]

I mention Grin's technology because it's very poor choice to store data.

that's also true of Bitcoin, but it's not stopping people using it to store data.

unless the mining pools themselves devised this concept (or other similar schemes in the future), and are operating as a cartel (i.e. refunding one anothers tx fees from data storage transactions), then people will simply run out of money to sustain these things. And even if the mining pools were doing such a thing, quitting after some critical amount of time is necessary to avoid suspicion.

so it will always burn itself out one way or another.

[hZti]

What is the issue with the data being stored in the transactions, especially if it is so hard to stop it? To me it seems much more obvious to have a larger block size, which will in return end up with faster transaction times.

When bitcoin was released, the block size was the same, but there were not even 1 percent of the current users. Now we have more then 100 times more users that will result in more then 100 times the transactions. You don’t have to be a genius to see that the network will be blocked by transactions.

[vapourminer]

What is the issue with the data being stored in the transactions, especially if it is so hard to stop it? To me it seems much more obvious to have a larger block size, which will in return end up with faster transaction times.

When bitcoin was released, the block size was the same, but there were not even 1 percent of the current users. Now we have more then 100 times more users that will result in more then 100 times the transactions. You don’t have to be a genius to see that the network will be blocked by transactions.

you dont have to be a genius to see the downsides of "larger block size" either

just hit up bcash_lol or bsv for your large block storage needs please

[ABCbits]

I mention Grin's technology because it's very poor choice to store data.

that's also true of Bitcoin, but it's not stopping people using it to store data.

--snip--

You're missing the point. Grin is much worse than Bitcoin (even when Bitcoin is already very bad choice) to store arbitrary data due to technical reason i mentioned earlier.

What is the issue with the data being stored in the transactions, especially if it is so hard to stop it? To me it seems much more obvious to have a larger block size, which will in return end up with faster transaction times.

When bitcoin was released, the block size was the same, but there were not even 1 percent of the current users. Now we have more then 100 times more users that will result in more then 100 times the transactions. You don’t have to be a genius to see that the network will be blocked by transactions.

While i'm in favor for increasing block size limit, i wouldn't want to see bigger block just to see block mostly filled with BRC-20 or ORC-20 transaction. And FYI,
1. Bigger block size limit doesn't always mean faster transaction time due to 10 minute block time.
2. Bigger block means faster blockchain size growth and higher requirement to full node.

--snip--

you dont have to be a genius to see the downsides of "larger block size" either

just hit up bcash_lol or bsv for your large block storage needs please

Those coin has low market cap/popularity not only because reckless block size increase though. For example BSV is associated with fraudster/fake satoshi and they have coin confiscation stealing feature (see https://blog.bitmex.com/bitcoin-sv-hardfork-significant-security-risks/).