public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Nagaev Boris <bnagaev@gmail.com>
To: Greg Tonoski <gregtonoski@gmail.com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Ordinal Inscription Size Limits
Date: Fri, 29 Dec 2023 16:01:52 -0300	[thread overview]
Message-ID: <CAFC_Vt7r_HA73UBmDdYsjxMirLfPb3K+3do_NwS-2o=Jsmw0gA@mail.gmail.com> (raw)
In-Reply-To: <980df778-cc94-4f98-8eb1-cbb321883369@gmail.com>

On Fri, Dec 29, 2023 at 1:34 PM 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.

-- 
Best regards,
Boris Nagaev


  reply	other threads:[~2023-12-29 19:03 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-27 12:44 [bitcoin-dev] Ordinal Inscription Size Limits Robert Dickinson
2023-01-27 12:58 ` rot13maxi
2023-01-28 10:58   ` alicexbt
2023-01-29 10:34     ` Robert Dickinson
2023-01-31  8:58       ` Erik Aronesty
2023-01-27 13:21 ` Andrew Poelstra
2023-01-27 15:43   ` Aymeric Vitte
2023-01-28 16:47     ` Aymeric Vitte
2023-01-28  4:26   ` Robert Dickinson
2023-12-29 12:27   ` Greg Tonoski
2023-12-29 19:01     ` Nagaev Boris [this message]
2023-12-30  9:58     ` Erik Aronesty
2024-01-01 13:33       ` Brad Morrison
2024-01-01 16:08         ` Erik Aronesty
2024-01-03  9:11           ` Brad Morrison
2024-01-03 13:05             ` Erik Aronesty
2023-02-03 19:56 ` Melvin Carvalho
2023-02-04 14:25   ` Kostas Karasavvas
2023-02-06 16:39     ` Erik Aronesty
2023-02-06 17:31 ` Claus Ehrenberg
2023-02-06 18:05   ` Erik Aronesty
2023-02-07 12:17     ` Aymeric Vitte

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAFC_Vt7r_HA73UBmDdYsjxMirLfPb3K+3do_NwS-2o=Jsmw0gA@mail.gmail.com' \
    --to=bnagaev@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=gregtonoski@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox