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
fair. i suppose you could support cpfp in any dust filtering. im not a
fan, but I think its the only legit way to defend the chain from non money
use cases
On Mon, May 8, 2023, 7:58 PM Peter Todd wrote:
> On Sun, May 07, 2023 at 07:59:40PM -0400, Erik Aronesty via bitcoin-dev
> wrote:
> >
> 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.
A reason to not ban storing arbitrary/non-functional data is that people will
still want to store things, so will start (ab)using useful data to do so, which
On May 8, 2023 at 1:16:41 PM, Moth via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> From what I understand, things like inscriptions can only be inserted
> between two specific flags - OP_FALSE and OP_IF. Having a validation check
> to reject witness scripts that have arbitrary
> 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,
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
On Sun, May 07, 2023 at 07:59:40PM -0400, Erik Aronesty via bitcoin-dev wrote:
> possible to change tx "max fee" to output amounts?
>
> seems like the only use case that would support such a tx is spam/dos type
> stuff that satoshi warned about
>
> its not a fix for everything, but it seems
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).
From what I understand, things like inscriptions can only be inserted between
two specific flags - OP_FALSE and OP_IF. 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
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
On Sun, May 7, 2023 at 12:36 PM David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On 2023-05-06 21:03, Michael Folkson via bitcoin-dev wrote:
> > Essentially my concern is going forward current maintainers will
> > decide which proposed new maintainers to add and
Hi David
>> Essentially my concern is going forward current maintainers will decide
>> which proposed new maintainers to add and which to block.
> This is how a large percentage of organizations are run. The current members
> of a board or other governance group choose who will become a new
Hi Waxwing,
On Tue, 2 May 2023 at 02:37, AdamISZ wrote:
> Hi Lloyd,
> thanks for taking a look.
>
> > I think your view of the uselessness of single signer adaptors is too
> pessimistic. The claim you make is that they "don't provide a way to create
> enforcement that the publication of
possible to change tx "max fee" to output amounts?
seems like the only use case that would support such a tx is spam/dos type
stuff that satoshi warned about
its not a fix for everything, but it seems could help a bit with certain
attacks
___
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
21 matches
Mail list logo
