Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id D0DCFC0037 for ; Mon, 1 Jan 2024 13:43:19 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id ACDC081429 for ; Mon, 1 Jan 2024 13:43:19 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org ACDC081429 Authentication-Results: smtp1.osuosl.org; dkim=pass (2048-bit key) header.d=sonic.net header.i=@sonic.net header.a=rsa-sha256 header.s=net23 header.b=xtSxGvWn X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 588N7xHmx5Th for ; Mon, 1 Jan 2024 13:43:18 +0000 (UTC) X-Greylist: delayed 612 seconds by postgrey-1.37 at util1.osuosl.org; Mon, 01 Jan 2024 13:43:18 UTC DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 6D2CE81421 Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) by smtp1.osuosl.org (Postfix) with ESMTPS id 6D2CE81421 for ; Mon, 1 Jan 2024 13:43:18 +0000 (UTC) Received: from webmail.sonic.net (b.webmail.sonic.net [184.23.169.32]) (authenticated bits=0) by d.mail.sonic.net (8.16.1/8.16.1) with ESMTPA id 401DX2wu010017; Mon, 1 Jan 2024 05:33:03 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sonic.net; s=net23; t=1704115984; bh=Dq7vfOJCRzqy6gO5CID7FzqzlnObqUDIj0I2oSLfPS0=; h=MIME-Version:Date:From:To:Subject:Message-ID:From:Subject; b=xtSxGvWnxGlwIpuutOdtsF65oAk6ivBN2NfhKu/A3YUNX9/n273bDU5mL6FWa9ekf L+hXT+2RvsrdPkscYJQ50k1vubbC82NR0TXg4XYx/j8PWXipEgQgAv/I62320zXBCu 9PYs+PN9jyafmCwMTUzjpEvt7ixOXMA/hmN/f1qm486JcuT6kn6fkfILk3S6fY7l6R YujzPsjMRmA0MokPaXzhNVB/qQNNjNbPVEBMTHHfOpEeC8HTYzS2VnMP7Y4EE2ivRM Nq61sjeQUCTreQ52rWnJREh+cMUzku6f1NImbucecpgOmpR05hzYa6TQ9XLNIWv+kC CBMXH6VDna8Gw== MIME-Version: 1.0 Date: Mon, 01 Jan 2024 05:33:02 -0800 From: Brad Morrison To: Erik Aronesty , Bitcoin Protocol Discussion In-Reply-To: References: <980df778-cc94-4f98-8eb1-cbb321883369@gmail.com> Message-ID: User-Agent: Roundcube Webmail/1.3.17 X-Sonic-Auth: YULA+qcdIeNwsitDHTCOENKBQhFZ+c2+6vcztIMpfIMFIfLUXyCh+zuTalS7HMeF3AsRwnKzz3gtaKaknemnlBfAUQUWEGdRlOo7FPbYM4I= Content-Type: multipart/alternative; boundary="=_a93dee4ea6a11bc8b22e928bf0d53171" X-Sonic-CAuth: UmFuZG9tSVbPWQkxyPWhAYSejqpp3F4/4oQtZo0WowtjAtjStoP6ShSuCwHvPLR5WlRkHVRN/Nbmzi/n9/k7I1aw3z+f1YoPOGKIVuvhNis= X-Sonic-ID: C;YMW2Saqo7hGbOEZFP63e0g== M;khnbSaqo7hGbOEZFP63e0g== X-Sonic-Spam-Details: -0.0/5.0 by cerberusd X-Mailman-Approved-At: Tue, 02 Jan 2024 12:09:06 +0000 Subject: Re: [bitcoin-dev] Ordinal Inscription Size Limits X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jan 2024 13:43:19 -0000 --=_a93dee4ea6a11bc8b22e928bf0d53171 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII 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 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 --=_a93dee4ea6a11bc8b22e928bf0d53171 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Erik,

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

However, I think that bitcoin has yet to receive sufficient payments usa= ge 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 a= nd 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 simp= lest method to start accepting more payments in bitcoin from larger busines= ses.

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 t= he stochastic nature of its effectiveness
 
Which can be resolved with things like payment pools, tre= e payments (https://utxos.org/uses/scaling/), etc.
 
 

On Fri, Dec 29, 2023, 9:33 AM Greg To= noski via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> Unfortunately, as near as I can t= ell there is no sensible way to
> prevent people from storing arbi= trary data in witnesses ...

To prevent "from storing arbitrary= data in witnesses" is the extreme
case of the size limit discussed i= n this thread. Let's consider it along
with other (less radical) opti= ons in order not to lose perspective, perhaps.

> ...without= incentivizing even worse behavior and/or breaking
> legitimate us= e cases.

I can't find evidence that would support the hypothes= is. There had not
been "even worse behavior and/or breaking legitimat= e use cases" observed
before witnesses inception. The measure would p= robably 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
t= o 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 "us= eful" 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<= br /> it cost as much as alternatives, e.g. OP_RETURN.

Also, b= anning "useless data" seems to be not the only option suggested
by th= e author who asked about imposing "a size limit similar to OP_RETURN".

> But from a technical point of view, I don't see any principle= d way to
> stop this.

Let's discuss ways that bring i= mprovement rather than inexistence of a
perfect technical solution th= at would have stopped "toxic data"/"crap on
the chain". There are at = least a few:
- https://github.com/bitcoi= n/bitcoin/pull/28408
- https://git= hub.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 alternati= ve, everybody?
_______________________________________________
= bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/l= istinfo/bitcoin-dev

= _______________________________________________
bitcoin-dev mailing l= ist
bitcoin-= dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--=_a93dee4ea6a11bc8b22e928bf0d53171--