MIME-Version: 1.0
References: <CABHetKwan91zqm=0y=_84vG7ffveWTPYONZP_hLQx5o40iAnuQ@mail.gmail.com>
 <Y9PPvBiWOXpBefmD@camus> <980df778-cc94-4f98-8eb1-cbb321883369@gmail.com>
In-Reply-To: <980df778-cc94-4f98-8eb1-cbb321883369@gmail.com>
From: Nagaev Boris <bnagaev@gmail.com>
Date: Fri, 29 Dec 2023 16:01:52 -0300
Message-ID: <CAFC_Vt7r_HA73UBmDdYsjxMirLfPb3K+3do_NwS-2o=Jsmw0gA@mail.gmail.com>
To: Greg Tonoski <gregtonoski@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Ordinal Inscription Size Limits
Precedence: list

On Fri, Dec 29, 2023 at 1:34=E2=80=AFPM Greg Tonoski via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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.

Hi Greg!

How about storing data in multisig signatures? Make a 1/n multisig and
store the data in (n-1) dummy public keys. It is stored in witness and
is quite efficient and hard to filter out only if together with
legitimate multisigs.

Another smart place for hidden data is Merkle proof in Taproot. The
depth is limited to 128 levels, so put 1 valid leaf and add data to
127 fake elements to calculate the Merkle root.

I think there are more ways like this. If the current place is banned,
they can always waste money in other parts of bitcoin transactions. It
is impossible to stop someone who can afford to waste money from doing
it. (Well, it is, but not in a decentralized voluntary way of
Bitcoin.) My approach is just to wait for them to run out of money and
use Lightning Network for payments meanwhile.

--=20
Best regards,
Boris Nagaev