> ...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
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
