Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

[ArmchairCryptologist via bitcoin-dev]

While I don't necessarily disagree about the block size limit, efforts to 
increase it in the past has been effectively stonewalled since, as it turns 
out, all you have to do to not increase it is nothing.

If we are looking to address the current mempool spam in particular, it looks 
to me that it isn't specifically caused by exploiting taproot to add large 
amounts of data to the blockchain, there are just a large amount of spam 
transactions creating dust and moving it around. To the best of my knowledge, 
this type of spam could to some extent be mitigated by adding a dynamic dust 
limit, where in addition to today's fixed limit of 546 sats, UTXOs are 
considered to be dust if they cannot be economically spent at the fee rate of 
the transaction creating it.

Of course, it complicates matters somehow that you cannot generally know how 
much data is required to spend a UTXO, especially with taproot, so you'd need 
to calculate it by assuming that it will require the typical amount of data for 
a basic UTXO. With the same assumptions used to define the original dust limit, 
Ignoring that segwit/taproot can be somewhat cheaper, that would be 182 sats 
per byte.

Say if a transaction has a fee rate of 100 sat/b - the dust limit for UTXOs 
this transaction creates would then be increased from 546 sats to 18200 sats. 
So if you want to spam the blockchain with dust, the higher you push the fees, 
the more sats you need to leave behind in each UTXO.

There are of course pros and cons to such an approach, and you could argue the 
need to cap it in various ways, but it feels to me that it would be worth 
considering, especially considering that it is mempool policy rather than 
consensus critical.

--
Best,
ArmchairCryptologist

--- Original Message ---
On Friday, November 3rd, 2023 at 11:15 AM, Brad Morrison via bitcoin-dev 
 wrote:

> Right now, https://mempool.space/ indicates that there are about 105,000 
> unconfirmed transactions and that current memory usage is 795 mb of 300 mb.
> ...
> Expanding the block size is the simplest way to expand network capacity and 
> lower transactional costs___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

[Melvin Carvalho via bitcoin-dev]

pá 3. 11. 2023 v 11:16 odesílatel Brad Morrison 
napsal:

> Melvin/all,
>
> You make good points about high network fees being disruptive.
>
> What is more disruptive are spikes & valleys (instability) that last
> longer than the mempool cycle can handle.
>
> Right now, https://mempool.space/ indicates that there are about 105,000
> unconfirmed transactions and that current memory usage is 795 mb of 300 mb.
>
> We could compare the bitcoin networks' ability to process transactions to
> the California Independent System Operator's (CAISO -
> https://www.caiso.com/Pages/default.aspx) task of ensuring the CA
> electrical grid stays supplied with the least expensive electricity
> available and does not get overloaded, nor has to export too much
> electrical power to other grids in times of surplus.
>
> A big part of doing that is noticing past trends and preparing for future
> growth, if that is the goal.
>
> Expanding the block size is the simplest way to expand network capacity
> and lower transactional costs.
>

The block size is a sensitive topic, as it has been used as an attack
vector in the past.  It is now a loaded topic baked into the mythology of
the project.  Discourse on the topic benefit from a dispassionate analysis
of the technical trade-offs and what properties of the network they affect.

There exists an attack on bitcoin where the lowest fee rises to make it
much harder to participate.  You could imagine a well funded attack,
creating fees of, say, 10,000 sats/vbyte, for a period of time.

While this could be viewed as positive from one lens (miners benefit),
there would at least be a vocal minority, legitimately arguing that this is
disruptive to the ordinary function of the network.

It's worth recognizing that a bigger block size makes this kind of
disruptive attack more expensive.

It's a tricky topic because of the history, and because some of the "spam"
may be seen by some as legitimate.

I think in the long-term miners and users will treat the fee auction in new
ways, with the use of AI algorithms.  Trillions are transmitted through the
bitcoin network.  A fraction of that is captured.  As the block subsidy
goes away over the next 2 decades, it might lead to a kind of "AI mexican
standoff" where the highest value transactions pay a bit more for priority
transfers.  AI will likely change the game theory, and we'll find out how,
over the next 2 epochs.

If that is the case, then block size can increase with hardware advances,
while maintaining much valued decentralized properties of the network.  In
this regard we probably would benefit from things like stratumv2 and
utreexo being rolled out first.


> Thank you,
>
> Brad
>
>
>
> On 2023-05-08 09:37, Melvin Carvalho via bitcoin-dev wrote:
>
>
>
> po 8. 5. 2023 v 13:55 odesílatel Ali Sherief via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> napsal:
>
>> 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 

Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

[Brad Morrison via bitcoin-dev]

Melvin/all, 

You make good points about high network fees being disruptive. 

What is more disruptive are spikes & valleys (instability) that last
longer than the mempool cycle can handle. 

Right now, https://mempool.space/ indicates that there are about 105,000
unconfirmed transactions and that current memory usage is 795 mb of 300
mb. 

We could compare the bitcoin networks' ability to process transactions
to the California Independent System Operator's (CAISO -
https://www.caiso.com/Pages/default.aspx) task of ensuring the CA
electrical grid stays supplied with the least expensive electricity
available and does not get overloaded, nor has to export too much
electrical power to other grids in times of surplus. 

A big part of doing that is noticing past trends and preparing for
future growth, if that is the goal. 

Expanding the block size is the simplest way to expand network capacity
and lower transactional costs. 

Thank you, 

Brad

On 2023-05-08 09:37, Melvin Carvalho via bitcoin-dev wrote:

> po 8. 5. 2023 v 13:55 odesílatel Ali Sherief via bitcoin-dev 
>  napsal: 
> 
>> 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.
> 
> This is a nuanced and sensitive topic that has been discussed previously, as 
> far back as 2010, in a conversation between Gavin and Satoshi: 
> 
> https://bitcointalk.org/index.php?topic=195.msg1617#msg1617 
> 
> Gavin: That's a cool feature until it gets popular and somebody decides it 
> would be fun to flood the payment network with millions of transactions to 
> transfer the latest Lady Gaga video to all their friends...
> Satoshi: That's one of the reasons for transaction fees.  There are other 
> things we can do if necessary. 
> 
> High fees could be viewed as disruptive to the network, but less disruptive 
> than regular large reorgs, or a network split. 
> 
> It might be beneficial to brainstorm the "other things we can do if 
> necessary". 
> 
> A simple observation is that increasing the block size could make it more 
> challenging to spam, though it may come at the expense of some 
> decentralization. 
> 
>> -Ali 
>> 
>> --- 
>> 
>> [1]: 
>> https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the-promise-and-peril-of-bitcoin-backed-tokens/
>>  [1] 
>> ___
>> 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
 

Links:
--
[1]
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

Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

[Jaroslaw via bitcoin-dev]

W dniu 2023-05-11 13:57:11 użytkownik Keagan McClelland via bitcoin-dev 
 napisał:

> The current fees we are experiencing are still significantly lower than they 
> need to be if Bitcoin is going to survive in a post-subsidy era. If our 
> layered protocols can't survive the current fee environment, the answer is to 
> fix the layered protocols.


I also believe that this discussion should be expanded to the problem of 
Bitcoin's survival in the post-subsidy era, because it's very related, i.e. 
also directly related to the high transaction fees. The only difference is that 
the current $30 fee situation is probably temporary, and the future $40 
(today's price tag) fee situation in post-subsidy era will be hopeless for 
change other than to reduce the difficulty of the network and hence its 
security and the marketcap/price in the end of day.

Because if the current network hashrate (current level of security) would drop 
e.g. to half of what it was in the past - the Store-of-Value feature simply 
collapse, while it's one of the most important (if not: the most important) 
long term feature of Bitcoin and as such advertised...
If you really care about SoV - you can't accept network security regression. 
Period.

I am a committed supporter of the free market. And Bitcoin is not the e-mail 
system, where sending is free and therefore spam which costs nothing to the 
sender - becomes a problem. In Bitcoin, every transaction costs - and in such a 
situation, distinguishing paid transactions into the good ones and the bad ones 
- would be a mistake and contradict the idea of the free market.

We should not interfere where the free market intervenes: the same way how 
small transfers are migrating to LN, the same way "non-economic", low value 
informations will migrate to Layer2 (RGB, Taro or maybe something else yet)

But, we should intervene there, where there is no free market. And I am not 
alone in alarming that there is such a place in Bitcoin.
In the post-subsidy era There Is No Free Market between: active users 
(overtaxed) and pasive users (free riders).

One of possible (very conservative) option to introduce free market there - is 
to delay halving in case of 4 years network difficulty regression situation.
Such a long-term regression of network difficulty means nothing else that 
transaction revenue from active users is not able to fund current network 
security anymore for both active and passive users. Delaying of halving is 
simply: not introducing additional more damage to the network security (really 
conservative approach)
Another option is: demurrage (but I'm not very sure it will work fine, at least 
before "hyperbitcoinzation")

Again, from my almost 50yo experience:
Bitcoin network difficulty can be more-less constant or can be slightly 
increasing (both options are "good for Bitcoin") but we should do our best - to 
avoid the network security regression.
I did.


Regards
Jaroslaw

___
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

Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

[Aleksandr Kwaskoff via bitcoin-dev]

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 

Aleksandr Kwaskoff
[image: https://]about.me/kwaskoff

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

[Tom Harding via bitcoin-dev]

On 5/9/23 09:32, Erik Aronesty via bitcoin-dev wrote:

obviously it's easy enough to evade if every non-economic user simply  > keeps enough bitcoin around and sends it back to himself > > so 
maybeit's a useless idea? but maybe that's enough of a hassle to stop > 
people (it certainly breaks ordinals, since it can never be 1 sat)


Padding the change is not just a hassle, it requires holding extra BTC 
in a hot wallet, which has a cost.


Spenders could also get around the rule by paying miners off-network, 
but having to do so would be an appropriate penalty for broadcasting a 
non-economic transaction.



___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

[Keagan McClelland via bitcoin-dev]

Erik,

I'm curious about what you believe to be "non-economic" txs. As far as I
can tell, any transaction included in the blockchain is economically
motivated by the very evidence of fees paid. That said, for the sake of
argument if we assume that there exists a category of information that
constitutes "non-economic" information, then so long as there is any
variance in the way to express a single economic intention, there exists a
vector for including "non-economic" information. I'll add beyond this that
there must always be variance in the way to express the same intent because
the signature data must be indistinguishable from entropy for Bitcoin's
security to hold.

Even if we eliminate small UTXOs, OP_RETURN, or whatever other vector of
the day that is currently being used to propagate such "non-economic"
information, we will always have the potential variance in the signature
data to do so. The best you can hope for is to make such means so
inefficient that the real cost-per-bit is expensive enough that there are
fewer distinct use cases. However, this isn't enough to actually *prevent*
the "spam". By increasing the cost-per-bit, it may limit it to only
"non-economic" information of extremely high value (note the
contradiction), it limits the number of use cases while also increasing the
impact of the use cases that make it past that threshold. Thus, it isn't
the impact of spam that is being reduced so much as it is reducing the
number of distinct use cases that result in "spam". Perhaps this is enough
to make spam more intermittent, and maybe on those grounds alone it could
be worth it, but I doubt it.

IMO the proper way to handle things like this isn't to introduce consensus
or relay policy to incentivize the expansion of the chain weight these
"non-economic" use cases require, but rather to reduce the necessary chain
footprint of supposed "economically motivated" transactions, which
incidentally is the entire point of all layered scaling tech. The current
fees we are experiencing are still significantly lower than they need to be
if Bitcoin is going to survive in a post-subsidy era. If our layered
protocols can't survive the current fee environment, the answer is to fix
the layered protocols.

Food for thought.

Stay Inspired,
Keags

On Tue, May 9, 2023 at 12:38 PM Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
>> > no data at all
>
>
> exactly, which is why a relationship between "cpfp-inclusive outputs" and
> "fees" makes sense.   it's clear that's a good definition of dust, and not
> too hard to get a working pr up for the network-layer.   i get that your
> node will still route.   i get that it would break timestamps, indeed, it
> would break all non-economic use cases if we made it a consensus change.
>
> but that's the point of the discussion.
>
> the question is whether breaking all non-economic use cases is the right
> move, given the game-theory of what underpins bitcoin
>
> i'm sad (honestly) to say that it might be
>
> it may very well be that bitcoin *cannot* be a "global ledger of all
> things" in order to remain useful and decentralized, and instead the
> monetary use case must be it's only goal
>
> also, i'm not really advocating for this solution so much as i would like
> a
>
> - rational conversation about the incentives
> - whether this solution would be an effective enough barrier to keep most
> non-economic tx off bitcoin
>
> obviously it's easy enough to evade if every non-economic user simply
> keeps enough bitcoin around and sends it back to himself
>
> so maybe it's a useless idea?   but maybe that's enough of a hassle to
> stop people (it certainly breaks ordinals, since it can never be 1 sat)
>
> ___
> 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

Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

[Weiji Guo via bitcoin-dev]

> I would like to point out that I'm not an advocate for doing anything at
this point aside from working on l2

Speaking of L2, I had recently proposed a new opcode OP_ZKP to enable
payments based on ZKP proof. I wonder if it has drawn enough attention but
it seems to me a viable way to address transaction fee issues, in addition
to enabling more smart contracts. And it will be a Bitcoin native L2, not a
side chain, not pegging.

  scriptPubKey:   OP_ZKP
  scriptSig:   ...  


I haven't figured out how to use OP_ZKP to incentivize BRC-20, inscription
etc. to move to L2. But I like to bring it up here and I am open to your
feedback and comments.

Thanks,
Weiji

On Tue, May 9, 2023 at 8:51 PM Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I would like to point out that I'm not an advocate for doing anything at
> this point aside from working on l2
>
> just to make it inconvenient for people
>
> I just think the discussion of outputs and fees is interesting and related
> to the game theory portion of Bitcoin
>
>
>
> On Tue, May 9, 2023, 8:23 AM Jaroslaw via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>>
>>
>> Ok, I need to highlight one important thing well proven by this
>> discussion (like it or not)...
>>
>> Not the spam itself is the real reason of feeling: "something must be
>> done"
>> The reason is: $30 fee per transaction (I hope you all agree)
>>
>>
>> Let me paraphrase some quotes used in this discussion, then:
>>
>> 1. Lack of block subsidy long term and necessity of $40 tx fee to
>> compensate it - "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."
>>
>> 2. "the harmony of Bitcoin transactions is being disrupted right now" due
>> to lack of block subsidy and due to exorbitant $40 tx fees as an effect
>> necessary to keep the network security untouched
>>
>> 3. "Fee spikes aren't fun" and it's obvious that keeping the network
>> security only on enormous tx fees of active users and having passive users
>> as free-riders - isn't fun, too
>>
>> 4. by ignoring Bitcoin long-term security budget problem - "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
>> tremendous $40 tx fees can never happen again"
>>
>> 5. "Action against exorbitant fees should have been taken months ago.
>> (...) It's a mistake that the" tail emission or other necessary solution -
>> weren't implemented on time
>>
>> 6. "we need to find a solution for long-term horrible fees problem - that
>> fits everyone's common ground."
>>
>>
>> Yes, we need - instead of being still in a heavy denial state.
>>
>> No additional comment then, except this little one:
>> Delay of halving in case of 4 years long network difficulty regression
>> situation.
>>
>>
>> Regards,
>> Jaroslaw
>>
>>
>>
>>
>>
>> W dniu 2023-05-09 00:37:57 użytkownik Luke Dashjr via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> napisał:
>>
>> Action should have been taken months ago. Spam filtration has been a
>> standard part of Bitcoin Core since day 1. It's a mistake that the existing
>> filters weren't extended to Taproot transactions. We can address that, or
>> try a more narrow approach like OP_RETURN (ie, what "Ordisrespector" does).
>> Since this is a bugfix, it doesn't really even need to wait for a major
>> release.
>>
>> (We already have pruning. It's not an alternative to spam filtering.)
>>
>> Luke
>>
>>
>>
>>
>> On 5/7/23 13:22, Ali Sherief via bitcoin-dev 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 

Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

[Erik Aronesty via bitcoin-dev]

>
>
> > no data at all


exactly, which is why a relationship between "cpfp-inclusive outputs" and
"fees" makes sense.   it's clear that's a good definition of dust, and not
too hard to get a working pr up for the network-layer.   i get that your
node will still route.   i get that it would break timestamps, indeed, it
would break all non-economic use cases if we made it a consensus change.

but that's the point of the discussion.

the question is whether breaking all non-economic use cases is the right
move, given the game-theory of what underpins bitcoin

i'm sad (honestly) to say that it might be

it may very well be that bitcoin *cannot* be a "global ledger of all
things" in order to remain useful and decentralized, and instead the
monetary use case must be it's only goal

also, i'm not really advocating for this solution so much as i would like a

- rational conversation about the incentives
- whether this solution would be an effective enough barrier to keep most
non-economic tx off bitcoin

obviously it's easy enough to evade if every non-economic user simply keeps
enough bitcoin around and sends it back to himself

so maybe it's a useless idea?   but maybe that's enough of a hassle to stop
people (it certainly breaks ordinals, since it can never be 1 sat)
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

[Tom Harding via bitcoin-dev]

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 
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 
 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 
 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/


___
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___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

[Melvin Carvalho via bitcoin-dev]

po 8. 5. 2023 v 13:55 odesílatel Ali Sherief via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> napsal:

> 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.
>

This is a nuanced and sensitive topic that has been discussed previously,
as far back as 2010, in a conversation between Gavin and Satoshi:

https://bitcointalk.org/index.php?topic=195.msg1617#msg1617

Gavin: That's a cool feature until it gets popular and somebody decides it
would be fun to flood the payment network with millions of transactions to
transfer the latest Lady Gaga video to all their friends...
Satoshi: That's one of the reasons for transaction fees.  There are other
things we can do if necessary.

High fees could be viewed as disruptive to the network, but less disruptive
than regular large reorgs, or a network split.

It might be beneficial to brainstorm the "other things we can do if
necessary".

A simple observation is that increasing the block size could make it more
challenging to spam, though it may come at the expense of some
decentralization.


> -Ali
>
> ---
>
> [1]:
> https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the-promise-and-peril-of-bitcoin-backed-tokens/
> 
> ___
> 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

Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

[Erik Aronesty via bitcoin-dev]

I would like to point out that I'm not an advocate for doing anything at
this point aside from working on l2

just to make it inconvenient for people

I just think the discussion of outputs and fees is interesting and related
to the game theory portion of Bitcoin



On Tue, May 9, 2023, 8:23 AM Jaroslaw via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
>
> Ok, I need to highlight one important thing well proven by this discussion
> (like it or not)...
>
> Not the spam itself is the real reason of feeling: "something must be done"
> The reason is: $30 fee per transaction (I hope you all agree)
>
>
> Let me paraphrase some quotes used in this discussion, then:
>
> 1. Lack of block subsidy long term and necessity of $40 tx fee to
> compensate it - "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."
>
> 2. "the harmony of Bitcoin transactions is being disrupted right now" due
> to lack of block subsidy and due to exorbitant $40 tx fees as an effect
> necessary to keep the network security untouched
>
> 3. "Fee spikes aren't fun" and it's obvious that keeping the network
> security only on enormous tx fees of active users and having passive users
> as free-riders - isn't fun, too
>
> 4. by ignoring Bitcoin long-term security budget problem - "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
> tremendous $40 tx fees can never happen again"
>
> 5. "Action against exorbitant fees should have been taken months ago.
> (...) It's a mistake that the" tail emission or other necessary solution -
> weren't implemented on time
>
> 6. "we need to find a solution for long-term horrible fees problem - that
> fits everyone's common ground."
>
>
> Yes, we need - instead of being still in a heavy denial state.
>
> No additional comment then, except this little one:
> Delay of halving in case of 4 years long network difficulty regression
> situation.
>
>
> Regards,
> Jaroslaw
>
>
>
>
>
> W dniu 2023-05-09 00:37:57 użytkownik Luke Dashjr via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> napisał:
>
> Action should have been taken months ago. Spam filtration has been a
> standard part of Bitcoin Core since day 1. It's a mistake that the existing
> filters weren't extended to Taproot transactions. We can address that, or
> try a more narrow approach like OP_RETURN (ie, what "Ordisrespector" does).
> Since this is a bugfix, it doesn't really even need to wait for a major
> release.
>
> (We already have pruning. It's not an alternative to spam filtering.)
>
> Luke
>
>
>
>
> On 5/7/23 13:22, Ali Sherief via bitcoin-dev 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]:
> 

Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

[Michael Folkson via bitcoin-dev]

> im unclear as to the purposepaying an onchain transaction fee greater than 
> the amount receiving could possibly serve.

If you expect fees to continue to rise and be sustained at abnormally high 
levels for a long period of time you might seek to close your Lightning 
channel(s) and move whatever value you can from these Lightning channel(s) 
onchain even if it means paying a higher fee than the amount you are receiving.

I don't necessarily recommend doing this (it would depend on a number of 
factors, both personal and external) but there is no reason to prevent someone 
in say the consensus rules from doing this if they wish.

--
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 20:47, Erik Aronesty  wrote:

> im unclear as to the purpose paying an onchain transaction fee greater than 
> the amount receiving could possibly serve.
>
> what benefit do you get aside from losing bitcoin?
>
> are there any, non-theoretical, benefits to facilitating dust transactions?
>
> we could, of course, have it be non-consensus (no route dust) to start with
>
> On Mon, May 8, 2023 at 1:13 PM Michael Folkson 
>  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 
>>  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 
>>>  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)

 ___
 

Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

[Jaroslaw via bitcoin-dev]

Ok, I need to highlight one important thing well proven by this discussion 
(like it or not)...

Not the spam itself is the real reason of feeling: "something must be done"
The reason is: $30 fee per transaction (I hope you all agree)


Let me paraphrase some quotes used in this discussion, then:

1. Lack of block subsidy long term and necessity of $40 tx fee to compensate it 
- "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."

2. "the harmony of Bitcoin transactions is being disrupted right now" due to 
lack of block subsidy and due to exorbitant $40 tx fees as an effect necessary 
to keep the network security untouched

3. "Fee spikes aren't fun" and it's obvious that keeping the network security 
only on enormous tx fees of active users and having passive users as 
free-riders - isn't fun, too

4. by ignoring Bitcoin long-term security budget problem - "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 tremendous 
$40 tx fees can never happen again"

5. "Action against exorbitant fees should have been taken months ago. (...) 
It's a mistake that the" tail emission or other necessary solution - weren't 
implemented on time

6. "we need to find a solution for long-term horrible fees problem - that fits 
everyone's common ground."


Yes, we need - instead of being still in a heavy denial state.

No additional comment then, except this little one:
Delay of halving in case of 4 years long network difficulty regression 
situation.


Regards,
Jaroslaw





W dniu 2023-05-09 00:37:57 użytkownik Luke Dashjr via bitcoin-dev 
 napisał:

Action should have been taken months ago. Spam filtration has been a standard 
part of Bitcoin Core since day 1. It's a mistake that the existing filters 
weren't extended to Taproot transactions. We can address that, or try a more 
narrow approach like OP_RETURN (ie, what "Ordisrespector" does). Since this is 
a bugfix, it doesn't really even need to wait for a major release.

(We already have pruning. It's not an alternative to spam filtering.)

Luke




On 5/7/23 13:22, Ali Sherief via bitcoin-dev 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/






___
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

Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

[Ali Sherief via bitcoin-dev]

Hey guys,

I'm more of the opinion that if this particular format the spam transactions 
are using is addressed, it will not only cause the mempool to relax, but it 
will also give us time to regroup and work on Layer 2 before the next onslaught 
of spam transactions using a (slightly) different format begins.

-Ali

On Tue, May 9, 2023 at 3:02 AM, Peter Todd  wrote:

> On Mon, May 08, 2023 at 06:37:34PM -0400, Luke Dashjr via bitcoin-dev wrote:
>> Action should have been taken months ago. Spam filtration has been a
>> standard part of Bitcoin Core since day 1. It's a mistake that the existing
>> filters weren't extended to Taproot transactions. We can address that, or
>> try a more narrow approach like OP_RETURN (ie, what "Ordisrespector" does).
>> Since this is a bugfix, it doesn't really even need to wait for a major
>> release.
>
> Miners are making millions of dollars from these inscription transactions.
> Miners can and do run their own nodes and interconnect to each other. Many
> people like myself will continue to run nodes that do not attempt to block
> inscriptions. And of course, the current flood of BRC-20 transactions embed
> very little data in the chain per transaction and could easily be adapted to
> use OP_RETURN or any number of other data embedding schemes; if they were
> modified to embed no data at all they wouldn't be much smaller, and I'm sure
> you'd still be complaining that they were spam.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

[Erik Aronesty via bitcoin-dev]

> value you can from these Lightning channel(s) onchain even if it means
paying a higher fee than the amount you are receiving.

in that case, you're not getting any value - you're losing value.   the
only benefit i could imagine would be to prevent the other party from
having access to the funds should the channel expire.

regardless, this is an edge case.   it's clear that a utxo whose value is
less than the fee paid to move it is dust, and we already have plenty of
code to censor dust transactions

> no reason to prevent

the reason to prevent them is to prevent something that has more value than
the bitcoin itself from being stored on-chain.  that is to say:
real-estate ownership, nfts, or any other thing that isn't "using bitcoin
as money"

by going at the "incentive/economic layer", rather than pointlessly forcing
brc-20 and ordinals users to obfuscate their transactions, we can provide a
permanent incentive to keep that stuff off of bitcoin

personally, i'm not sure it's desirable to keep it off of bitcoin, but if
it is, the only sure way to disincentivize it is to go at it in this way or
similar

i suspect all the opcode validation suggestions are just silly.   ordinals
can time their fork to the same moment, and store data in a less efficient,
but still functional, way using any number of mechanisms.   we've had
similar things posted on-chain since 2010 (my favorite was a software
license key - in an attempt to make bitcoin nodes illegal.   it's still in
there)


On Mon, May 8, 2023 at 4:36 PM Michael Folkson <
michaelfolk...@protonmail.com> wrote:

> > im unclear as to the purpose paying an onchain transaction fee greater
> than the amount receiving could possibly serve.
>
> If you expect fees to continue to rise and be sustained at abnormally high
> levels for a long period of time you might seek to close your Lightning
> channel(s) and move whatever value you can from these Lightning channel(s)
> onchain even if it means paying a higher fee than the amount you are
> receiving.
>
> I don't necessarily recommend doing this (it would depend on a number of
> factors, both personal and external) but there is no reason to prevent
> someone in say the consensus rules from doing this if they wish.
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
>
> Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
>
> --- Original Message ---
> On Monday, May 8th, 2023 at 20:47, Erik Aronesty  wrote:
>
> im unclear as to the purpose paying an onchain transaction fee greater
> than the amount receiving could possibly serve.
>
> what benefit do you get aside from losing bitcoin?
>
> are there any, non-theoretical, benefits to facilitating dust transactions?
>
> we could, of course, have it be non-consensus (no route dust) to start with
>
>
>
>
>
> On Mon, May 8, 2023 at 1:13 PM Michael Folkson <
> michaelfolk...@protonmail.com> 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
>> 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 

Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

[Erik Aronesty via bitcoin-dev]

the more i think about it, the more that this is essential.   consider that
bitcoin is secured by mining and mining is secured by fees.   all of that
is relative to the value of bitcoin itself.   but consider the incentive
for a reorg if a single ordinal is worth 1 billion dollars and is being
transferred.  now all the incentive logic is thrown to the wind.
 non-monetary use is quite dangerous to network stability, and the game
theory underpinning it, imo.

On Mon, May 8, 2023 at 4:59 PM Erik Aronesty  wrote:

> > value you can from these Lightning channel(s) onchain even if it means
> paying a higher fee than the amount you are receiving.
>
> in that case, you're not getting any value - you're losing value.   the
> only benefit i could imagine would be to prevent the other party from
> having access to the funds should the channel expire.
>
> regardless, this is an edge case.   it's clear that a utxo whose value is
> less than the fee paid to move it is dust, and we already have plenty of
> code to censor dust transactions
>
> > no reason to prevent
>
> the reason to prevent them is to prevent something that has more value
> than the bitcoin itself from being stored on-chain.  that is to say:
> real-estate ownership, nfts, or any other thing that isn't "using bitcoin
> as money"
>
> by going at the "incentive/economic layer", rather than pointlessly
> forcing brc-20 and ordinals users to obfuscate their transactions, we can
> provide a permanent incentive to keep that stuff off of bitcoin
>
> personally, i'm not sure it's desirable to keep it off of bitcoin, but if
> it is, the only sure way to disincentivize it is to go at it in this way or
> similar
>
> i suspect all the opcode validation suggestions are just silly.   ordinals
> can time their fork to the same moment, and store data in a less efficient,
> but still functional, way using any number of mechanisms.   we've had
> similar things posted on-chain since 2010 (my favorite was a software
> license key - in an attempt to make bitcoin nodes illegal.   it's still in
> there)
>
>
> On Mon, May 8, 2023 at 4:36 PM Michael Folkson <
> michaelfolk...@protonmail.com> wrote:
>
>> > im unclear as to the purpose paying an onchain transaction fee greater
>> than the amount receiving could possibly serve.
>>
>> If you expect fees to continue to rise and be sustained at abnormally
>> high levels for a long period of time you might seek to close your
>> Lightning channel(s) and move whatever value you can from these Lightning
>> channel(s) onchain even if it means paying a higher fee than the amount you
>> are receiving.
>>
>> I don't necessarily recommend doing this (it would depend on a number of
>> factors, both personal and external) but there is no reason to prevent
>> someone in say the consensus rules from doing this if they wish.
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at protonmail.com
>> GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
>>
>> Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
>>
>> --- Original Message ---
>> On Monday, May 8th, 2023 at 20:47, Erik Aronesty  wrote:
>>
>> im unclear as to the purpose paying an onchain transaction fee greater
>> than the amount receiving could possibly serve.
>>
>> what benefit do you get aside from losing bitcoin?
>>
>> are there any, non-theoretical, benefits to facilitating dust
>> transactions?
>>
>> we could, of course, have it be non-consensus (no route dust) to start
>> with
>>
>>
>>
>>
>>
>> On Mon, May 8, 2023 at 1:13 PM Michael Folkson <
>> michaelfolk...@protonmail.com> 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
>>> 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 

Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

[Peter Todd via bitcoin-dev]

On Mon, May 08, 2023 at 06:37:34PM -0400, Luke Dashjr via bitcoin-dev wrote:
> Action should have been taken months ago. Spam filtration has been a
> standard part of Bitcoin Core since day 1. It's a mistake that the existing
> filters weren't extended to Taproot transactions. We can address that, or
> try a more narrow approach like OP_RETURN (ie, what "Ordisrespector" does).
> Since this is a bugfix, it doesn't really even need to wait for a major
> release.

Miners are making millions of dollars from these inscription transactions.
Miners can and do run their own nodes and interconnect to each other. Many
people like myself will continue to run nodes that do not attempt to block
inscriptions. And of course, the current flood of BRC-20 transactions embed
very little data in the chain per transaction and could easily be adapted to
use OP_RETURN or any number of other data embedding schemes; if they were
modified to embed no data at all they wouldn't be much smaller, and I'm sure
you'd still be complaining that they were spam.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

[Luke Dashjr via bitcoin-dev]

Action should have been taken months ago. Spam filtration has been a 
standard part of Bitcoin Core since day 1. It's a mistake that the 
existing filters weren't extended to Taproot transactions. We can 
address that, or try a more narrow approach like OP_RETURN (ie, what 
"Ordisrespector" does). Since this is a bugfix, it doesn't really even 
need to wait for a major release.


(We already have pruning. It's not an alternative to spam filtering.)

Luke


On 5/7/23 13:22, Ali Sherief via bitcoin-dev 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/ 



___
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

Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

[Ali Sherief via bitcoin-dev]

I think one of the bigger problems facing the broader Bitcoin ecosystem is the 
lack of Lightning wallets for desktop. Mobile wallets are not really an issue, 
but as far as I know for desktop builds, there's really only Electrum, and Zap 
Wallet which support Lightning.

The alternative is interacting with the LN node directly, which probably won't 
be so bad, but it would be better if they carried GUI wallets like BItcoin Core 
does. Because windows and buttons help with mass adoption of pretty much 
everything.

I may even consider developing a Lighting wallet given the circumstances.

-Ali

On Mon, May 8, 2023 at 8:13 PM, Michael Folkson  
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 
>  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 
>>  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

Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

[Erik Aronesty via bitcoin-dev]

im unclear as to the purpose paying an onchain transaction fee greater than
the amount receiving could possibly serve.

what benefit do you get aside from losing bitcoin?

are there any, non-theoretical, benefits to facilitating dust transactions?

we could, of course, have it be non-consensus (no route dust) to start with





On Mon, May 8, 2023 at 1:13 PM Michael Folkson <
michaelfolk...@protonmail.com> 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
> 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/
>> 
>> ___
>> 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

Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

[Michael Folkson via bitcoin-dev]

> 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 
 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 
>  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

Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

[Erik Aronesty via bitcoin-dev]

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/
> 
> ___
> 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

Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?

[Michael Folkson via bitcoin-dev]

Hi Ali

I'd point you to Andrew Poelstra's post from January 2023 [0] and a Bitcoin 
StackExchange answer I recently posted [1].

> 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.

Miners are as far as I understand including high fee rate, consensus compatible 
transactions in mined blocks as the system has been set up for them to do. As I 
say in that StackExchange answer if you don't like it:

"There are theoretically two options: a consensus change or a policy change. A 
consensus change disallowing a certain kind of transaction that is acceptable 
under current consensus rules would need a soft fork and hence would be 
extremely difficult to pull off assuming that it was a considered a good idea 
by the broader community. Embedding arbitrary data in transactions would still 
be possible after this hypothetical soft fork and so its effectiveness would be 
limited. A default policy change (or custom policy option) would attempt to 
prevent a certain kind of transaction from propagating across the network 
without needing a consensus change. However, it would still be possible to 
submit these kinds of consensus compatible transactions directly to miners 
bypassing the P2P network."

> 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.

It isn't a philosophy or ideology consideration, it is a purely technical one. 
Congestion can happen using Taproot addresses or pre-Taproot addresses. There 
is fixed, limited block space and variable demand for that block space. You may 
not like how that block space is being used but if transactions are consensus 
compatible and paying fees at the market rate the system is working how it 
should.

> to curtail the loophole in BIP 342 (which defines the validation rules for 
> Taproot scripts) which has allowed these unintended consequences?

There were technical reasons for the design decisions in BIP 342. As Andrew 
says in his post [0]:

"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. Doing so would incur a ~2x cost to them, but
if 2x is enough to disincentivize storage, then there's no need to have
this discussion because they will will be forced to stop due to fee
market competition anyway. (And if not, it means there is little demand
for Bitcoin blockspace, so what's the problem with paying miners to fill
it with data that validators don't even need to perform real computation
on?).

But if we were to ban "useful" data, for example, saying that a witness
can't have more than 20 signatures in it, then we are into the same
problem we had pre-Taproot: that it is effectively impossible construct
signing policies in a general and composeable way, because any software
that does so will need to account for multiple independent limits. We
deliberately replaced such limits with "you need to pay 50 weight for
each signature" to makes this sort of analysis tractable."

I personally get the desire to "do something". Fee spikes aren't fun especially 
for some Lightning use cases and many of us don't like how people are using the 
limited block space currently. But a game of whack-a-mole with blunt tools such 
as policy rules and especially consensus rules is ineffective at best and 
harmful at worst. You may not like this use case but assuming you embark on a 
game of whack-a-mole what's to stop a group of people popping up in a year 
declaring their opposition to your use case and trying to prevent your use 
case? Consensus rules are set and the rest is left to the market.

Thanks

Michael

[0]: 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021372.html
[1]: 
https://bitcoin.stackexchange.com/questions/118197/ddos-attack-via-brc-20-ordinals-on-bitcoin

--
Michael Folkson
Email: michaelfolkson at [protonmail.com](http://protonmail.com/)
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F

Learn about Bitcoin: https://www.youtube.com/@portofbitcoin

--- Original Message ---
On Sunday, May 7th, 2023 at 18:22, Ali Sherief via bitcoin-dev 
 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