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
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/
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
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
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
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
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
> 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
>
>
> > 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
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
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,
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
> 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
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,
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
> 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
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
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,
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).
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
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
> 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
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
>
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
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
25 matches
Mail list logo
