Re: [bitcoin-dev] Ordinal Inscription Size Limits

From: Brad Morrison <bradmorrison@sonic•net>
To: Erik Aronesty <erik@q32•com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Ordinal Inscription Size Limits
Date: Mon, 01 Jan 2024 05:33:02 -0800	[thread overview]
Message-ID: <bda67a7ba6432b080d9c45e15cb80372@sonic.net> (raw)
In-Reply-To: <CAJowKgJ8n0GFj3S88qW+rk2RcLg-1JH9aL22YtTB-55EEQzsYw@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3683 bytes --]

Erik, 

Fees AKA costs are the best spam control system and I thank you for
highlighting that. 

However, I think that bitcoin has yet to receive sufficient payments
usage to challenge credit card payments system when it comes to a race
to the bottom in terms of processing transactional fees. 

In the USA, where I am, large businesses like UBER, Lyft, and many major
telecom, cable, & electric utilities process huge volumes of regular and
irregular credit card payments on a monthly basis. Almost none oft hose
transactions are completed in bitcoin. 

A focus on lowering fees by increasing the block size by 10x is the
simplest method to start accepting more payments in bitcoin from larger
businesses. 

Brad

On 2023-12-30 01:58, Erik Aronesty via bitcoin-dev wrote:

> Bitcoin already has a spam prevention system called "fees".   I don't believe it's insufficient.  The only issue is the stochastic nature of its effectiveness 
> 
> Which can be resolved with things like payment pools, tree payments (https://utxos.org/uses/scaling/), etc. 
> 
> On Fri, Dec 29, 2023, 9:33 AM Greg Tonoski via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: 
> 
>>> Unfortunately, as near as I can tell there is no sensible way to
>>> prevent people from storing arbitrary data in witnesses ...
>> 
>> To prevent "from storing arbitrary data in witnesses" is the extreme
>> case of the size limit discussed in this thread. Let's consider it along
>> with other (less radical) options in order not to lose perspective, perhaps.
>> 
>>> ...without incentivizing even worse behavior and/or breaking
>>> legitimate use cases.
>> 
>> I can't find evidence that would support the hypothesis. There had not
>> been "even worse behavior and/or breaking legitimate use cases" observed
>> before witnesses inception. The measure would probably restore
>> incentives structure from the past.
>> 
>> As a matter of fact, it is the current incentive structure that poses
>> the problem - incentivizes worse behavior ("this sort of data is toxic
>> to the network") and breaks legitimate use cases like a simple transfer
>> of BTC.
>> 
>>> 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.
>> 
>> There is significant difference when storing data as dummy signatures
>> (or OP_RETURN) which is much more expensive than (discounted) witness.
>> Witness would not have been chosen as the storage of arbitrary data if
>> it cost as much as alternatives, e.g. OP_RETURN.
>> 
>> Also, banning "useless data" seems to be not the only option suggested
>> by the author who asked about imposing "a size limit similar to OP_RETURN".
>> 
>>> But from a technical point of view, I don't see any principled way to
>>> stop this.
>> 
>> Let's discuss ways that bring improvement rather than inexistence of a
>> perfect technical solution that would have stopped "toxic data"/"crap on
>> the chain". There are at least a few:
>> - https://github.com/bitcoin/bitcoin/pull/28408
>> - https://github.com/bitcoin/bitcoin/issues/29146
>> - deprecate OP_IF opcode.
>> 
>> I feel like the elephant in the room has been brought up. Do you want to
>> maintain Bitcoin without spam or a can't-stop-crap alternative, everybody?
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #2: Type: text/html, Size: 5398 bytes --]