path: root/cb/d0012ee52123d86bbb04af6fcdc22404ad65bc

Return-Path: <bradmorrison@sonic.net>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id D0DCFC0037
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bradmorrison@sonic.net>
To: Erik Aronesty <erik@q32.com>, Bitcoin Protocol Discussion
 <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CAJowKgJ8n0GFj3S88qW+rk2RcLg-1JH9aL22YtTB-55EEQzsYw@mail.gmail.com>
References: <CABHetKwan91zqm=0y=_84vG7ffveWTPYONZP_hLQx5o40iAnuQ@mail.gmail.com>
 <Y9PPvBiWOXpBefmD@camus> <980df778-cc94-4f98-8eb1-cbb321883369@gmail.com>
 <CAJowKgJ8n0GFj3S88qW+rk2RcLg-1JH9aL22YtTB-55EEQzsYw@mail.gmail.com>
Message-ID: <bda67a7ba6432b080d9c45e15cb80372@sonic.net>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <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
--=_a93dee4ea6a11bc8b22e928bf0d53171
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; charset=
=3DUTF-8" /></head><body style=3D'font-size: 10pt'>
<p>Erik, </p>
<p>Fees AKA costs are the best spam control system and I thank you for high=
lighting that.</p>
<p>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.</p>
<p>In the USA, where I am, large businesses like UBER, Lyft, and many major=
 telecom, cable, &amp; 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.</p>
<p>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.</p>
<p>Brad</p>
<div>&nbsp;</div>
<p><br /></p>
<p>On 2023-12-30 01:58, Erik Aronesty via bitcoin-dev wrote:</p>
<blockquote type=3D"cite" style=3D"padding: 0 0.4em; border-left: #1010ff 2=
px solid; margin: 0"><!-- html ignored --><!-- head ignored --><!-- meta ig=
nored -->
<div dir=3D"auto">Bitcoin already has a spam prevention system called "fees=
".&nbsp; &nbsp;I don't believe it's insufficient.&nbsp; The only issue is t=
he stochastic nature of its effectiveness
<div dir=3D"auto">&nbsp;</div>
<div dir=3D"auto">Which can be resolved with things like payment pools, tre=
e payments (<a href=3D"https://utxos.org/uses/scaling/" target=3D"_blank" r=
el=3D"noopener noreferrer">https://utxos.org/uses/scaling/</a>), etc.</div>
<div dir=3D"auto">&nbsp;</div>
<div dir=3D"auto">&nbsp;</div>
</div>
<br />
<div class=3D"gmail_quote">
<div class=3D"gmail_attr" dir=3D"ltr">On Fri, Dec 29, 2023, 9:33 AM Greg To=
noski via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundati=
on.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 .8ex; border-left:=
 1px #ccc solid; padding-left: 1ex;">&gt; Unfortunately, as near as I can t=
ell there is no sensible way to<br /> &gt; prevent people from storing arbi=
trary data in witnesses ...<br /> <br /> To prevent "from storing arbitrary=
 data in witnesses" is the extreme<br /> case of the size limit discussed i=
n this thread. Let's consider it along<br /> with other (less radical) opti=
ons in order not to lose perspective, perhaps.<br /> <br /> &gt; ...without=
 incentivizing even worse behavior and/or breaking<br /> &gt; legitimate us=
e cases.<br /> <br /> I can't find evidence that would support the hypothes=
is. There had not<br /> been "even worse behavior and/or breaking legitimat=
e use cases" observed<br /> before witnesses inception. The measure would p=
robably restore<br /> incentives structure from the past.<br /> <br /> As a=
 matter of fact, it is the current incentive structure that poses<br /> the=
 problem - incentivizes worse behavior ("this sort of data is toxic<br /> t=
o the network") and breaks legitimate use cases like a simple transfer<br /=
> of BTC.<br /> <br /> &gt; If we ban "useless data" then it would be easy =
for would-be data<br /> &gt; storers to instead embed their data inside "us=
eful" data such as dummy<br /> &gt; signatures or public keys.<br /> <br />=
 There is significant difference when storing data as dummy signatures<br /=
> (or OP_RETURN) which is much more expensive than (discounted) witness.<br=
 /> Witness would not have been chosen as the storage of arbitrary data if<=
br /> it cost as much as alternatives, e.g. OP_RETURN.<br /> <br /> Also, b=
anning "useless data" seems to be not the only option suggested<br /> by th=
e author who asked about imposing "a size limit similar to OP_RETURN".<br /=
> <br /> &gt; But from a technical point of view, I don't see any principle=
d way to<br /> &gt; stop this.<br /> <br /> Let's discuss ways that bring i=
mprovement rather than inexistence of a<br /> perfect technical solution th=
at would have stopped "toxic data"/"crap on<br /> the chain". There are at =
least a few:<br /> - <a href=3D"https://github.com/bitcoin/bitcoin/pull/284=
08" target=3D"_blank" rel=3D"noopener noreferrer">https://github.com/bitcoi=
n/bitcoin/pull/28408</a><br /> - <a href=3D"https://github.com/bitcoin/bitc=
oin/issues/29146" target=3D"_blank" rel=3D"noopener noreferrer">https://git=
hub.com/bitcoin/bitcoin/issues/29146</a><br /> - deprecate OP_IF opcode.<br=
 /> <br /> I feel like the elephant in the room has been brought up. Do you=
 want to<br /> maintain Bitcoin without spam or a can't-stop-crap alternati=
ve, everybody?<br /> _______________________________________________<br /> =
bitcoin-dev mailing list<br /> <a href=3D"mailto:bitcoin-dev@lists.linuxfou=
ndation.org">bitcoin-dev@lists.linuxfoundation.org</a><br /> <a href=3D"htt=
ps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" target=3D"_bla=
nk" rel=3D"noopener noreferrer">https://lists.linuxfoundation.org/mailman/l=
istinfo/bitcoin-dev</a></blockquote>
</div>
<br />
<div class=3D"pre" style=3D"margin: 0; padding: 0; font-family: monospace">=
_______________________________________________<br /> bitcoin-dev mailing l=
ist<br /> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-=
dev@lists.linuxfoundation.org</a><br /> <a href=3D"https://lists.linuxfound=
ation.org/mailman/listinfo/bitcoin-dev" target=3D"_blank" rel=3D"noopener n=
oreferrer">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</=
a></div>
</blockquote>
</body></html>

--=_a93dee4ea6a11bc8b22e928bf0d53171--