public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Tom Harding <tomh@thinlink.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: Tue, 9 May 2023 08:21:46 -0700	[thread overview]
Message-ID: <1b4db941-4c64-979e-9b3b-ea112aab9080@thinlink.com> (raw)
In-Reply-To: <-2tdTjN6WfQI-CTPM49DiMOC2X5El1vJdlWTQvpalXAHKVLdFd_7ADpYN7Cz57v0fJSkaiG75fHJzcBtvJgn7Pj-RZrEk6hXk6Rp_1Y7SrE=@protonmail.com>

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

> And prevent perfectly reasonable transfers of value


Such a transfer can only be reasonable when off-chain value is attached 
to the coins.  A rule like this is the embodiment of the philosophy that 
the Bitcoin network is for onchain-economic transactions.

Parties could get around the rule by paying miners off-network, and that 
would be an appropriate penalty for using non-onchain-economic transactions.



On 5/8/23 10:13, Michael Folkson via bitcoin-dev wrote:
> > probably easier just to reject any transaction where the fee is 
> higher than the sum of the outputs
>
> And prevent perfectly reasonable transfers of value and attempted 
> Lightning channel closes during fee spikes? If I *want*​ to close my 
> Lightning channel during a protracted fee spike where I have to pay an 
> onchain transaction fee greater than the amount I am receiving you 
> want to stop me doing that? You are impinging on a valid use case as 
> well as requiring a consensus rule change.
>
> -- Michael Folkson
> Email: michaelfolkson at protonmail.com <http://protonmail.com/>
> GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
> Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
>
> ------- Original Message -------
> On Monday, May 8th, 2023 at 13:58, Erik Aronesty via bitcoin-dev 
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> probably easier just to reject any transaction where the fee is 
>> higher than the sum of the outputs
>>
>>
>>
>> On Mon, May 8, 2023, 7:55 AM Ali Sherief via bitcoin-dev 
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>     Hi guys,
>>
>>     I think everyone on this list knows what has happened to the
>>     Bitcoin mempool during the past 96 hours. Due to side projects
>>     such as BRC-20 having such a high volume, real bitcoin
>>     transactions are being priced out and that is what is causing the
>>     massive congestion that has arguable not been seen since December
>>     2017. I do not count the March 2021 congestion because that was
>>     only with 1-5sat/vbyte.
>>
>>     Such justifiably worthless ("worthless" is not even my word -
>>     that's how its creator described them[1]) tokens threaten the
>>     smooth and normal use of the Bitcoin network as a peer-to-pear
>>     digital currency, as it was intended to be used as.
>>
>>     If the volume does not die down over the next few weeks, should
>>     we take an action? The bitcoin network is a triumvirate of
>>     developers, miners, and users. Considering that miners are
>>     largely the entities at fault for allowing the system to be
>>     abused like this, the harmony of Bitcoin transactions is being
>>     disrupted right now. Although this community has a strong history
>>     of not putting its fingers into pies unless absolutely necessary
>>     - an example being during the block size wars and Segwit - should
>>     similar action be taken now, in the form of i) BIPs and/or ii)
>>     commits into the Bitcoin Core codebase, to curtail the loophole
>>     in BIP 342 (which defines the validation rules for Taproot
>>     scripts) which has allowed these unintended consequences?
>>
>>     An alternative would be to enforce this "censorship" at the node
>>     level and introduce a run-time option to instantly prune all
>>     non-standard Taproot transactions. This will be easier to
>>     implement, but won't hit the road until minimum next release.
>>
>>     I know that some people will have their criticisms about this,
>>     absolutists/libertarians/maximum-freedom advocates, which is
>>     fine, but we need to find a solution for this that fits
>>     everyone's common ground. We indirectly allowed this to happen,
>>     which previously wasn't possible before. So we also have a
>>     responsibility to do something to ensure that this kind of
>>     congestion can never happen again using Taproot.
>>
>>     -Ali
>>
>>     ---
>>
>>     [1]:
>>     https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the-promise-and-peril-of-bitcoin-backed-tokens/
>>     <https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the-promise-and-peril-of-bitcoin-backed-tokens/?outputType=amp>
>>     _______________________________________________
>>     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

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

  parent reply	other threads:[~2023-05-09 15:21 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-07 17:22 [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes? 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 [this message]
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
2023-05-09  8:41 jk_14
2023-05-09 12:50 ` Erik Aronesty
2023-05-10  3:08   ` Weiji Guo
2023-05-11 13:12 Aleksandr Kwaskoff
2023-05-12  9:36 jk_14

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=1b4db941-4c64-979e-9b3b-ea112aab9080@thinlink.com \
    --to=tomh@thinlink.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