public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?
@ 2023-05-11 13:12 Aleksandr Kwaskoff
  0 siblings, 0 replies; 25+ messages in thread
From: Aleksandr Kwaskoff @ 2023-05-11 13:12 UTC (permalink / raw)
  To: bitcoin-dev

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

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


-- 

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

President of NGO FinTechAssociation | Prezes organizacji pozarządowej
FinTechStowarzyszenie

*Dipl.-Ing. *Aleksandr Kwaskoff

Telegram t.me/kwaskoff

Poland, Warsaw | Polska, Warszawa





[image: --]

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

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

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

^ permalink raw reply	[flat|nested] 25+ messages in thread
* Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?
@ 2023-05-12  9:36 jk_14
  0 siblings, 0 replies; 25+ messages in thread
From: jk_14 @ 2023-05-12  9:36 UTC (permalink / raw)
  To: Keagan McClelland, Bitcoin Protocol Discussion


W dniu 2023-05-11 13:57:11 użytkownik Keagan McClelland via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> 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



^ permalink raw reply	[flat|nested] 25+ messages in thread
* Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?
@ 2023-05-09  8:41 jk_14
  2023-05-09 12:50 ` Erik Aronesty
  0 siblings, 1 reply; 25+ messages in thread
From: jk_14 @ 2023-05-09  8:41 UTC (permalink / raw)
  To: 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 <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]: 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




^ permalink raw reply	[flat|nested] 25+ messages in thread
* [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?
@ 2023-05-07 17:22 Ali Sherief
  2023-05-08 12:33 ` Michael Folkson
                   ` (3 more replies)
  0 siblings, 4 replies; 25+ messages in thread
From: Ali Sherief @ 2023-05-07 17:22 UTC (permalink / raw)
  To: bitcoin-dev

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

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)

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

^ permalink raw reply	[flat|nested] 25+ messages in thread
end of thread, other threads:[~2023-11-04  9:59 UTC | newest]

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox