From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id D1EA5C0037 for ; Sat, 30 Dec 2023 09:58:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 9A3044027D for ; Sat, 30 Dec 2023 09:58:57 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 9A3044027D Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=gmail-com.20230601.gappssmtp.com header.i=@gmail-com.20230601.gappssmtp.com header.a=rsa-sha256 header.s=20230601 header.b=zDuLtNDZ X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VTyqRpxE3FLr for ; Sat, 30 Dec 2023 09:58:55 +0000 (UTC) Received: from mail-yw1-x1136.google.com (mail-yw1-x1136.google.com [IPv6:2607:f8b0:4864:20::1136]) by smtp4.osuosl.org (Postfix) with ESMTPS id 8FCD8401CA for ; Sat, 30 Dec 2023 09:58:55 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 8FCD8401CA Received: by mail-yw1-x1136.google.com with SMTP id 00721157ae682-5eb8b6e8d76so8500827b3.1 for ; Sat, 30 Dec 2023 01:58:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail-com.20230601.gappssmtp.com; s=20230601; t=1703930334; x=1704535134; darn=lists.linuxfoundation.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=ZMzTy5/MaFpjZSSpRdmQK6Ae3vFQIKpl8BjPpLaHnxo=; b=zDuLtNDZpmdSK4aEZ8/1UfQ4LdGb2mIYzJvl+qpXdrXhantGwy0Z5PLokLzdW1tOP6 0CEsxIYJTSjniZLcVvH+XUi4DM95ixH0+8JAq/u+2ez6fYy32xh/4/SofBuOL47iEgfh pyFPHFh4dXINXUgA1Fl+3fD9bzwusQ1yKwIUtaLwHFcWnkQkme1Xk9zD+p18zBfUsKe7 JKF8KUE7ep6E+1zItBA4hhqh8yefFxKT6cm5cw/jMIBnzTV6WkpgGFFKhrsMRElqFBtw FRDc77647BiyuhFy3K6Nbj1IXa0IUsv7HF5Gft57Lri2EOYfwLQ/0D1HpA4bmfM1GBVD xa3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703930334; x=1704535134; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ZMzTy5/MaFpjZSSpRdmQK6Ae3vFQIKpl8BjPpLaHnxo=; b=ADHkHzdqnljzgkz3Xml99ag5uG9otTVhZEw8ImMd+H0g5dPXVCuC0HvcCFWJVCBXgQ PUaqLftK1imulxN3PojkjxITF0EO1GJBb0lCpyYOQJy7Q8EVUwiIssXUWJC/8UtH4KXU 9m+TjYVWHZWmj/k2XyVFN3TPX46fWyS5x3nQh9mFDfOkhibJYVP0w43KS8jah0HmvpZa m5bFUeAiDCnxtTGZb8WppBZqaLoBYpWjJbQaqwG40BTAkwbjYSKxxB7OsoqzC2v7TluS IlW1UkqXnnRQuJLzxpXe6XNpMSik0wIKDU3s1RaO1ozdXjk0P4pQ+mT1Ms83Hs4Xk8jN qBeA== X-Gm-Message-State: AOJu0YwJX3+OgioqxbeHPZjuLNRIxGYagDTq/pauh3dPAJwpNym/u0As y888Q+0q3NAZK5tYyTAM+GJM/Tztsz1XegQfsWZOuuo= X-Google-Smtp-Source: AGHT+IGnyJYz2PrAwBsYX80jdr/pxevYtYJiTn2GMLj9TW1pUF0zFQFLOnWxvNCHildXAfteJGanntHwjsJh69Y0+og= X-Received: by 2002:a25:c444:0:b0:daf:f8b6:2d5e with SMTP id u65-20020a25c444000000b00daff8b62d5emr9261760ybf.4.1703930334239; Sat, 30 Dec 2023 01:58:54 -0800 (PST) MIME-Version: 1.0 References: <980df778-cc94-4f98-8eb1-cbb321883369@gmail.com> In-Reply-To: <980df778-cc94-4f98-8eb1-cbb321883369@gmail.com> From: Erik Aronesty Date: Sat, 30 Dec 2023 02:58:41 -0700 Message-ID: To: Greg Tonoski , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000004b6243060db73262" X-Mailman-Approved-At: Sat, 30 Dec 2023 15:58:26 +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: Sat, 30 Dec 2023 09:58:57 -0000 --0000000000004b6243060db73262 Content-Type: text/plain; charset="UTF-8" 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 > --0000000000004b6243060db73262 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Bitcoin already has a spam prevention system called "= ;fees".=C2=A0 =C2=A0I don't believe it's insufficient.=C2=A0 T= he only issue is the stochastic nature of its effectiveness

Which can be resolved with things like paymen= t pools, tree payments (https:/= /utxos.org/uses/scaling/), etc.



On Fri, Dec 29, 2023, 9:33 AM Greg Tonoski via bitcoi= n-dev <bitcoin-= dev@lists.linuxfoundation.org> wrote:
> Unfortunately, as near as I can tell there is no sensible wa= y to
> prevent people from storing arbitrary data in witnesses ...

To prevent "from storing arbitrary data in witnesses" is the extr= eme
case of the size limit discussed in this thread. Let's consider it alon= g
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<= br> been "even worse behavior and/or breaking legitimate use cases" o= bserved
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 transfe= r
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 suc= h 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 sugg= ested
by the author who asked about imposing "a size limit similar to OP_RET= URN".

> 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<= br> perfect technical solution that would have stopped "toxic data"/&= quot;crap on
the chain". There are at least a few:
- https://github.com/bitcoin/bitcoin/pull/28= 408
- https://github.com/bitcoin/bitcoin/issue= s/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, everybo= dy?
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
--0000000000004b6243060db73262--