I don't have a specific response to share at this moment, but I may make
one later.
But for the sake of elevating the discourse, I'd encourage people
responding this to read through
https://rubin.io/bitcoin/2021/12/04/advent-7/ as I think it has some
helpful terminology and categorizations.
I
On Mon, Feb 07, 2022 at 08:34:30PM -0800, Jeremy Rubin via bitcoin-dev wrote:
> Whether [recursive covenants] is an issue or not precluding this sort
> of design or not, I defer to others.
For reference, I believe the last time the merits of allowing recursive
covenants was discussed at length on
(I have not yet read the recent posts on RBF but i wanted to react on the
"additive feerate".)
> # Purely additive feerate bumps should never be impossible
It's not that simple. As a miner, if i have less than 1vMB of transactions in
my mempool. I don't want a 10sats/vb transaction paying
This is great in theory, but I think it kinda misses *why* the complexity keeps creeping in. We
agree on (most of) the goals here, but the problem is the goals explicitly lead to the complexity,
its not some software engineering failure or imagination failure that leads to the complexity.
On
> It's not that simple. As a miner, if i have less than 1vMB of
transactions in my mempool. I don't want a 10sats/vb transaction paying
10sats by a 100sats/vb transaction paying only 1sats.
I don't understand why the "<1vMB in the mempool" case is even worth
consideration because the
One quick thought to the proposal and perhaps to sponsors in general(didn't
have time to go over original proposal again):
Since sponsors can come from anywhere, the wallet application must have
access to the mempool to know what inputs must be double spent to RBF the
sponsor transaction.
Seems
This would be very useful for the Validating Lightning Signer project,
since we need to prove to a non-network connected signer that a UTXO has
not been spent. It allows the signer to make sure the channel is still
active.
( the related design doc is at
There's been much talk about fee-bumping lately, and for good reason -
dynamic fee management is going to be a central part of bitcoin use as
the mempool fills up (lord willing) and right now fee-bumping is
fraught with difficulty and pinning peril.
Gloria's recent post on the topic[0] was very
The design document which inspired Neutrino outlined the use of oracles to
provide a moderate level of confidence to lightweight clients in the filters
they have received from an untrusted source. Current implementations of
lightweight wallets using Neutrino either trust in a single source, or
That's not really pinning; painning usually refers to pinning something to
the bottom of the mempool whereas these mechanisms make it easier to
guarantee that progress can be made on confirming the transactions you're
interested in.
Often times in these protocols "the call is coming inside the
10 matches
Mail list logo
