Hi Suhas,
>From my understanding, the main crux of the reasoning exposed in your post
would be to solidify the transaction-relay paradigm we have been following
during the last years, e.g introducing the carve-out rule specifically for
lightning commitment transactions, or more recently version=3
Hi Peter,
> tl;dr: I'm broadcasting full-RBF replacements paying extremely high fees to
> reward miners that turn on full-RBF. I'm starting small, just ~$100/block in
> times of congestion. Miner and pool profit margins are pretty small, on the
> order of $1k/block in many cases, so I know it
>
> (the only way to replace a transaction is Replace-By-Fee but this
> implies the transaction that IS TO BE REPLACED has a certain flag set,
> and it is optional).
>
1. full rbf is becoming standard. tx without full rbf can just be
rejected as a part of the sabu protocol
2. that's fine.
Hi John,
Sorry for late feedback. Very much appreciated the in depth report!
So, I second Greg's main question, which I've really been thinking about a bit
myself since starting to research this area more: it feels like the Bitcoin
protocol research community (or, uh, some of it) should focus
--- Original Message ---
On Thursday, October 20th, 2022 at 23:08, Peter Todd via bitcoin-dev
wrote:
> On Wed, Oct 19, 2022 at 03:17:51AM +, alicexbt via bitcoin-dev wrote:
>
> > > And the
> > > impression I got from the PR review club discussion more seemed like
> > > devs
> ...and the attacker also pays out the nose if they're exploiting rule #3.
I agree the attacker puts more at stake in this case. If we're assuming
they pay the price and get mined, they can be booted from the protocol
whenever they get mined. I was speaking about the worst case scenario where
On Wed, Nov 02, 2022 at 10:19:00AM -0400, Greg Sanders wrote:
> Sorry, I forgot one point which is pertinent to this conversation.
>
> *Even with* fullrbf-everywhere and V3, pinning via rule#3 and rule#5 are
> still an issue in coinjoin scenarios.
>
> Each coinjoin adversary can double-spend
Sorry, I forgot one point which is pertinent to this conversation.
*Even with* fullrbf-everywhere and V3, pinning via rule#3 and rule#5 are
still an issue in coinjoin scenarios.
Each coinjoin adversary can double-spend their coin to either full package
weight(101kvb),
or give 24 descendants,
On Tue, Nov 01, 2022 at 10:21:59PM -0400, Antoine Riard via bitcoin-dev wrote:
> Hi list,
>
> Reading Suhas's post on mempool policy consistency rules, and the grounded
> suggestion that as protocol developers we should work on special policy
> rules to support each reasonable use case on the
My idea, which I hated and didn't propose, was to mark utxos specifically
for this exact purpose, but this is extremely ugly from a wallet/consensus
perspective. nVersion is cleaner(well, except the below issue), at the cost
of forcibly marking all utxos in a transaction the same way.
> On the
Assigning blame here seems to be the paramount concern here. If we can
assign blame, most coinjoin-like protocols can terminate in bounded block
time, assuming fees are properly set.
It's also worth noting that in coinjoin cases, they're obviously coinjoins,
so pinging explorers over Tor HS seems
> I think that's a huge oversimplification of "rational" -- otherwise
you might as well say that deliberately pinning txs is also rational,
because it allows the person doing the pinning to steal funds from their
counterparty by forcing a timeout to expire.
To be clear, a pinner is attempting to
Hi list,
Reading Suhas's post on mempool policy consistency rules, and the grounded
suggestion that as protocol developers we should work on special policy
rules to support each reasonable use case on the network rather to arbiter
between class of use-cases in the design of an
unified set of
I'm now running a full-RBf bounty program for miners.
tl;dr: I'm broadcasting full-RBF replacements paying extremely high fees to
reward miners that turn on full-RBF. I'm starting small, just ~$100/block in
times of congestion. Miner and pool profit margins are pretty small, on the
order of
14 matches
Mail list logo
