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

[bitcoin-dev] Responsible disclosures and Bitcoin development

[alicexbt via bitcoin-dev]

Hi Bitcoin Developers,

There is an open issue in bitcoin core repository which was created last week: 
https://github.com/bitcoin/bitcoin/issues/27586

I think this should have been reported privately as vulnerability instead of 
creating a GitHub issue even if it worked only in debug mode. Some users in the 
comments have also experienced similar issues without debug build used for 
bitcoind. I have not noticed any decline in the number of listening nodes on 
bitnodes.io in last 24 hours so I am assuming this is not an issue with 
majority of bitcoin core nodes. However, things could have been worse and there 
is nothing wrong in reporting something privately if there is even 1% 
possibility of it being a vulnerability. I had recently reported something to 
LND security team based on a closed issue on GitHub which eventually was not 
considered a vulnerability: https://github.com/lightningnetwork/lnd/issues/7449

In the CPU usage issue, maybe the users can run bitcoind with bigger mempool or 
try other things shared in the issue by everyone.

This isn't the first time either when vulnerability was reported publicly: 
https://gist.github.com/chjj/4ff628f3a0d42823a90edf47340f0db9 and this was even 
exploited on mainnet which affected some projects.

This email is just a request to consider the impact of any vulnerability if 
gets exploited could affect lot of things. Even the projects with no financial 
activity involved follow better practices.

/dev/fd0
floppy disk guy

Sent with [Proton Mail](https://proton.me/) secure email.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Witness script validation to reject arbitrary data

[Moth via bitcoin-dev]

> They could have just as easily used OP_RETURN
outputs or any number of other data encoding techniques.

But doesn't OP_RETURN render the UTXO unspendable, thereby making it impossible 
to "trade" the minted BTC-20 tokens?

Moth

Sent from Proton Mail for iOS

On Mon, May 8, 2023 at 7:55 PM, Peter Todd <[p...@petertodd.org](mailto:On Mon, 
May 8, 2023 at 7:55 PM, Peter Todd < wrote:

> On Mon, May 08, 2023 at 08:16:41PM +, Moth via bitcoin-dev wrote:
>> From what I understand, things like inscriptions can only be inserted 
>> between two specific flags - OP_FALSE and OP_IF.
>
> That's just an artifical limitation of the current inscription protocol. There
> are endless ways to embed arbitrary data in Bitcoin transactions. Blocking 
> them
> all is a hopeless task.
>
>> Having a validation check to reject witness scripts that have arbitrary data 
>> between these two flags could be used to reject inscriptions while still 
>> allowing all the benefits of taproot. This will prevent people from 
>> overloading the network with txns geared solely for ordinals and brc-20 
>> tokens.
>>
>> Is there a reason such a validation check is a bad idea? We already have 
>> OP_RETURN to store arbitrary data that is limited to 80kb. Was it an 
>> oversight that arbitrary data can be inserted between OP_FALSE and OP_IF 
>> when the size limit for witness scripts was lifted as part of taproot?
>
> It's pointless to even try.
>
> The current flood of inscription txs are very small, about 150vB, and embed
> very little data in the chain. They could have just as easily used OP_RETURN
> outputs or any number of other data encoding techniques. Blocking that kind of
> use-case is hopeless.
>
> The _purpose_ of the current flood of BRC-20 inscriptions - tl;dr the creation
> of a new set of assets via an auction - is something that doesn't even require
> any data to be embedded in the chain at all. They could have implemented them
> with perfectly normal transactions indistinguishable from any other
> transaction. Blocking that is truly hopeless.
>
> --
> 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?

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

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

[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] Civ Kit: A Peer-to-Peer Electronic Market System

[Chris Stewart via bitcoin-dev]

>In traditional finance, front-running is defined as "entering into an
equity trade, options or future contracts with advance knowledge of a block
transaction that will influence the price of the underlying security to
capitlize on the trade" [0]. In Bitcoin/Civkit parlance, a front-running
could be a board on the discovery of a batch of market offers increasing
liquidity for a fiat-2-btc pair, seizing the opportunity by forwarding a
HTLC across a Lightning payment path to enter into the trade, before
publishing the offer on its board.

To summarize, assume we have Mary the Maker, Terry the Taker, and Bob the
bulletin board operator

1. Mary the Maker publishes a limit order to buy a derivative
2. Bob the bulletin board operator has the option to execute against Mary's
order
3. If Bob doesn't want to execute against the order, he relays the order to
Terry the Taker (and other subscribers to Bob's market)
4. Terry has the option to execute a trade against Mary's limit order
5. If Terry decides not to execute, Mary's order sits on the bulletin board.

I personally don't think this is that big of a concern, if Bob can collect
outsized profits from his trusted position as the bulletin board operator,
Terry will eventually move to other markets because Bob is only relaying
what Bob perceives to be unprofitable orders.

>From the perspective of Mary, she is happy. Her order got executed at the
price she specified. Terry is the one that loses here. This model ends up
looking much more like a brokerage rather than an exchange market
structure. Terry should open up his own brokerage (bulletin board) and
compete on quoting prices with Bob.

Bob and Terry can then be compared on metrics like execution quality
, which then
draws more market activity since they are providing better prices.

>Somehow mass front-running on the board is a "champagne" issue I'll be
happy to have.

This. Frontrunning is a good problem to have, that means your market has
active participants and liquidity. Finding what products people are
interested in trading, and giving them a good user experience is more
important. Everything else will fall in line after that.


On Mon, May 1, 2023 at 1:06 PM Antoine Riard via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi all,
>
> One of the most relevant feedback I received on the paper publication was the 
> lack of underscoring front-running resistance as a fundamental property 
> wished for a peer-to-peer marketplace.
>
> It is expected the level of front-running resistance aimed by the market 
> participants to be heavily functioned by the types of trades considered: fiat 
> currencies, real goods, services. For some classes of goods, e.g commodities 
> one cannot expect the same level of item liquidity due to cycle of production 
> and exogenous factors like weather. Some types of trades marketplaces might 
> be exposed to far less front-running risks and rather would have to deal with 
> accurate risk modelling of the underlying goods. E.g attest there is a 
> decentralized identifier or any other linkage proof of the physical good 
> existence staying valid for the duration of offer lifetime. Offers conditions 
> themselves might be far more verbose and precise special Bitcoin Script paths 
> to morph the shipment risks.
>
> On the other hand, the types of trades like fiat currencies or bitcoin 
> financial contracts (e.g discreet log contracts or submarine swaps), 
> front-running risk by the bulletin board sounds a qualified concern. In 
> traditional finance, front-running is defined as "entering into an equity 
> trade, options or future contracts with advance knowledge of a block 
> transaction that will influence the price of the underlying security to 
> capitlize on the trade" [0]. In Bitcoin/Civkit parlance, a front-running 
> could be a board on the discovery of a batch of market offers increasing 
> liquidity for a fiat-2-btc pair, seizing the opportunity by forwarding a HTLC 
> across a Lightning payment path to enter into the trade, before publishing 
> the offer on its board.
>
> I think you have at least two security paradigms to mitigate front-running 
> happening peer-to-peer marketplace. The first one is to duplicate the 
> announcement of the offers to a number of concurrent board operated by 
> independent identities and in parallel monitor the latency. Latency anomalies 
> should be spotted on by watchtower-like infrastructure at the service of 
> makers/takers and in case of repeated anomalies a maker should disqualify the 
> misbehaving board from future announcements. As all statistical mitigation it 
> is not perfect and open the way to some margin of exploitation by the boards, 
> as the watchtower monitoring frequency can be guessed. Additionally, this 
> latency monitoring paradigm sounds to be valid under the assumption that at 
> least one board is "honest" and board might have a 

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?

[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] Witness script validation to reject arbitrary data

[Aymeric Vitte via bitcoin-dev]

Le 08/05/2023 à 23:43, Christopher Allen via bitcoin-dev a écrit :
> There was a recent thread discussing raising the limit on
> OP_RETURN https://github.com/bitcoin/bitcoin/issues/27043
Indeed we already discussed all of this, and the conclusion was: there
are no reasons to impose limits, because people will find some deviant
(or not) workarounds (like Stamps), and fees will regulate this

And how to control the value of what is stored? If I store e=mc2, the
way I like since as many said it's super easy to find plenty of ways to
store in bitcoin, this one is short and supposed to have more value than
bitcoin, no?

Personnally I think of course that you should store a reference to
something and not the something, so a few hashes and/or signatures which
you cannot do with OP_RETURN today (80B Moth, not 80kB)

I don't see very well what can be done against the freeriders, except
avoiding that they impact the whole network (a bit à la bittorrent),
maybe the issue is more about decentralization rather than trying to
impose limitations, so the decentralized miners can't have the whole
image of the whole txs and hold low fees txs, which is not the case at
all today, but it seems a bit utopic right now

Or maybe when the ordinal meme stuff/BRC20 will be proven to have
finally zero value the market will self regulate

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