š
Original date posted:2023-01-10
šļø Summary of this message: Two methods for implementing "conflict monitoring" in decentralized coinjoin implementations like Joinmarket are proposed: running a relay node with a conflict-detection patch or assuming a conflict exists for unexplainable failures.
š Original message:On 2023-01-10 00:06, Peter Todd wrote:
> Remember, we'd like decentralized coinjoin implementations like
> Joinmarket to
> work. How does a decentralized coinjoin implement "conflict
> monitoring"?
1. Run a relay node with a conflict-detection patch. Stock Bitcoin Core
with -debug=mempoolrej will tell you when it rejects a transaction
for conflicting with a transaction already in the mempool, e.g.:
2022-11-01T02:53:17Z
867b85d68d7a7244c1d65c4797006b56973110ac243ab5ee15a8c4d220060c58 from
peer=58 was not accepted: txn-mempool-conflict
I think it would be easy to extend this facility to list the inputs
which conflicted. So if Alice sees a conflict created by Mallory,
she can create a new coinjoin transaction without Mallory. This
method has the advantage of being fast and attributing fault,
although it does require Alice's node be online at the time Mallory's
conflict is propagated.
2. Simply assume a conflict exists for otherwise unexplainable failures.
For example, if Alice sees several new blocks whose bottom feerates
are well below the feerates of an unconfirmed coinjoin transaction
that Alice helped create and broadcast, she can assume it's a
conflict that is preventing preventing confirmation of the coinjoin.
She can find an entirely different set of collaborators and create a
non-conflicting transaction without ever needing to know which inputs
from the original transaction conflicted. This method has the
disadvantage of being slow (on the order of hours) and not
attributing
fault, although it doesn't require Alice has any information beyond
copies
of recent blocks.
I didn't list these methods or others before because the specific method
used to
detect conflicts doesn't matter to the realization that software which
uses conflict detection and evasion to defeat the $17.00 attack also
defeats the $0.05 attack without any need for full-RBF.
-Dave
David A. Harding [ARCHIVE] /
npub16dā¦x4wrd
2023-06-07 23:18:29
in reply to nevent1qā¦jq39
Author Public Key
npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrdPublished at
2023-06-07 23:18:29Event JSON
{
"id": "6c66e89bf1278631611bb0fc5c21e7dc428f148cf204ffb5ff63ca3433e24240",
"pubkey": "d3574a24208f4e3d0821bb4a69a0c3ae842043d444fa5c4a8c49c369918a6fb2",
"created_at": 1686179909,
"kind": 1,
"tags": [
[
"e",
"93af7b1be8797d2a1683551105f962f360fcab88fd5768c2fa8ac19d93416ad2",
"",
"root"
],
[
"e",
"46d211c5af73d4457ca6a468e7462eba2d0779def9e01f96daa4f13d15e718cc",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "š
Original date posted:2023-01-10\nšļø Summary of this message: Two methods for implementing \"conflict monitoring\" in decentralized coinjoin implementations like Joinmarket are proposed: running a relay node with a conflict-detection patch or assuming a conflict exists for unexplainable failures.\nš Original message:On 2023-01-10 00:06, Peter Todd wrote:\n\u003e Remember, we'd like decentralized coinjoin implementations like \n\u003e Joinmarket to\n\u003e work. How does a decentralized coinjoin implement \"conflict \n\u003e monitoring\"?\n\n1. Run a relay node with a conflict-detection patch. Stock Bitcoin Core\n with -debug=mempoolrej will tell you when it rejects a transaction\n for conflicting with a transaction already in the mempool, e.g.:\n\n 2022-11-01T02:53:17Z \n867b85d68d7a7244c1d65c4797006b56973110ac243ab5ee15a8c4d220060c58 from \npeer=58 was not accepted: txn-mempool-conflict\n\n I think it would be easy to extend this facility to list the inputs\n which conflicted. So if Alice sees a conflict created by Mallory,\n she can create a new coinjoin transaction without Mallory. This\n method has the advantage of being fast and attributing fault,\n although it does require Alice's node be online at the time Mallory's\n conflict is propagated.\n\n2. Simply assume a conflict exists for otherwise unexplainable failures.\n For example, if Alice sees several new blocks whose bottom feerates\n are well below the feerates of an unconfirmed coinjoin transaction\n that Alice helped create and broadcast, she can assume it's a\n conflict that is preventing preventing confirmation of the coinjoin.\n She can find an entirely different set of collaborators and create a\n non-conflicting transaction without ever needing to know which inputs\n from the original transaction conflicted. This method has the\n disadvantage of being slow (on the order of hours) and not \nattributing\n fault, although it doesn't require Alice has any information beyond \ncopies\n of recent blocks.\n\nI didn't list these methods or others before because the specific method \nused to\ndetect conflicts doesn't matter to the realization that software which\nuses conflict detection and evasion to defeat the $17.00 attack also\ndefeats the $0.05 attack without any need for full-RBF.\n\n-Dave",
"sig": "2b79e3cd93b4f6a0305ee0bf0c42f736bab29529af2c91712d48941ddacbde72c2eea90aa13e4d2617671ef231f35815183c05fc8e2a206e4437d852f9fdb1e3"
}