public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Aleksandr Kwaskoff <kwaskoff@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?
Date: Thu, 11 May 2023 15:12:22 +0200	[thread overview]
Message-ID: <CAPj1HDfoAismQ2ye_AxuCERphW8DCw-21vSduTt7aTheJkmqBQ@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1510 bytes --]

if we forget about backward compatibility and the impact of other types of
transactions, then the following two options would be possible:
a) allocate only up to 10% of the space in the block for non-standard
transactions - then all senders of non-standard transactions will compete
with each other and it's only 10% with other types of transactions. In the
absence of non-standard transactions, all space of the block will be given
to standard ones. And in the absence of standard transactions - all space
of the block will be given to non-standard ones. If bitcoin-chain was
created primarily for standard transactions, then such a model will have to
be supported by the majority.
b) change the architecture in such a way that the onchain ordinals
transaction became much more expensive, which would force them to go to
their own type of the LN - this would be a kind of justice, like the
displacement of small transactions from the onchain to the LN happening
already now


-- 

Thank you, we will succeed! | Dziękujemy, uda nam się!

President of NGO FinTechAssociation | Prezes organizacji pozarządowej
FinTechStowarzyszenie

*Dipl.-Ing. *Aleksandr Kwaskoff

Telegram t.me/kwaskoff

Poland, Warsaw | Polska, Warszawa





[image: --]

President of NGO FinTechAssociation <http://t.me/finteh>

Aleksandr Kwaskoff
[image: https://]about.me/kwaskoff
<https://about.me/kwaskoff?promo=email_sig&utm_source=email_sig&utm_medium=email_sig&utm_campaign=external_links>

[-- Attachment #2: Type: text/html, Size: 8857 bytes --]

             reply	other threads:[~2023-05-11 13:13 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-11 13:12 Aleksandr Kwaskoff [this message]
  -- strict thread matches above, loose matches on Subject: below --
2023-05-12  9:36 [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes? jk_14
2023-05-09  8:41 jk_14
2023-05-09 12:50 ` Erik Aronesty
2023-05-10  3:08   ` Weiji Guo
2023-05-07 17:22 Ali Sherief
2023-05-08 12:33 ` Michael Folkson
2023-05-08 12:58 ` Erik Aronesty
2023-05-08 17:13   ` Michael Folkson
2023-05-08 19:31     ` Ali Sherief
2023-05-08 19:47     ` Erik Aronesty
2023-05-08 20:36       ` Michael Folkson
2023-05-08 20:59         ` Erik Aronesty
2023-05-08 21:01           ` Erik Aronesty
2023-05-09 15:21     ` Tom Harding
2023-05-08 16:37 ` Melvin Carvalho
2023-11-03 10:15   ` Brad Morrison
2023-11-03 10:39     ` Melvin Carvalho
2023-11-04  9:58     ` ArmchairCryptologist
2023-05-08 22:37 ` Luke Dashjr
2023-05-09  0:02   ` Peter Todd
2023-05-09  1:43     ` Ali Sherief
2023-05-09 16:32     ` Erik Aronesty
2023-05-09 21:06       ` Tom Harding
2023-05-10 20:44       ` Keagan McClelland

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=CAPj1HDfoAismQ2ye_AxuCERphW8DCw-21vSduTt7aTheJkmqBQ@mail.gmail.com \
    --to=kwaskoff@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /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