📅 Original date posted:2023-01-13
🗒️ Summary of this message: Two methods for decentralized coinjoin conflict monitoring are proposed: running a relay node with a conflict-detection patch or assuming a conflict exists for unexplainable failures.
📝 Original message:On Tue, Jan 10, 2023 at 10:14:47AM -1000, David A. Harding wrote:
> 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.
So for something as simple as reliable coinjoining - an important privacy
feature that we'd like all wallets to use - you expect people to run
well-connected 24/7 nodes running specialty software?
Even if you run a node as you suggest, there's certainly no guarantee that
you'd learn about any double-spend without doing a severe sybil attack against
the network; the 8 outgoing nodes a typical node has samples a tiny fraction of
the network. And *even if* you sybil attack to try to detect conflicts there's
still no guarantee as attackers can use all kinds of special techniques to get
transactions into miner mempools and not others.
> 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.
You're suggesting that to avoid enabling full-rbf, coinjoin's and other
decentralized multi-party protocols risk getting coins tied up for hours trying
to do conflict resolution rather than just fixing the underlying problem with
what's literally a one-line code change that 17% of the v24.x nodes have
decided to enable.
> 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.
Fact is, full-rbf defeats those attacks much better. And I'm amazed that you
don't consider raising the cost of attacks on coinjoins and similar
decentralized protocols by almost three orders of magnitude to be important:
why are you prioritizing a few highly centralized, often AML/KYC'd, unconfirmed
tx acceptance services over decentralized protocols which provide privacy and
security to a lot more users?
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230113/5516cb92/attachment.sig>;
Peter Todd [ARCHIVE] /
npub1m2…a2np2
2023-06-07 23:18:29
in reply to nevent1q…mzcq
Author Public Key
npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2Published at
2023-06-07 23:18:29Event JSON
{
"id": "39716b273153fbca57b50a6294c09793302c80763ffda94416ad1cb8af243a44",
"pubkey": "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa",
"created_at": 1686179909,
"kind": 1,
"tags": [
[
"e",
"93af7b1be8797d2a1683551105f962f360fcab88fd5768c2fa8ac19d93416ad2",
"",
"root"
],
[
"e",
"6c66e89bf1278631611bb0fc5c21e7dc428f148cf204ffb5ff63ca3433e24240",
"",
"reply"
],
[
"p",
"d3574a24208f4e3d0821bb4a69a0c3ae842043d444fa5c4a8c49c369918a6fb2"
]
],
"content": "📅 Original date posted:2023-01-13\n🗒️ Summary of this message: Two methods for decentralized coinjoin conflict monitoring are proposed: running a relay node with a conflict-detection patch or assuming a conflict exists for unexplainable failures.\n📝 Original message:On Tue, Jan 10, 2023 at 10:14:47AM -1000, David A. Harding wrote:\n\u003e On 2023-01-10 00:06, Peter Todd wrote:\n\u003e \u003e Remember, we'd like decentralized coinjoin implementations like\n\u003e \u003e Joinmarket to\n\u003e \u003e work. How does a decentralized coinjoin implement \"conflict monitoring\"?\n\u003e \n\u003e 1. Run a relay node with a conflict-detection patch. Stock Bitcoin Core\n\u003e with -debug=mempoolrej will tell you when it rejects a transaction\n\u003e for conflicting with a transaction already in the mempool, e.g.:\n\u003e \n\u003e 2022-11-01T02:53:17Z\n\u003e 867b85d68d7a7244c1d65c4797006b56973110ac243ab5ee15a8c4d220060c58 from\n\u003e peer=58 was not accepted: txn-mempool-conflict\n\u003e \n\u003e I think it would be easy to extend this facility to list the inputs\n\u003e which conflicted. So if Alice sees a conflict created by Mallory,\n\u003e she can create a new coinjoin transaction without Mallory. This\n\u003e method has the advantage of being fast and attributing fault,\n\u003e although it does require Alice's node be online at the time Mallory's\n\u003e conflict is propagated.\n\nSo for something as simple as reliable coinjoining - an important privacy\nfeature that we'd like all wallets to use - you expect people to run\nwell-connected 24/7 nodes running specialty software?\n\nEven if you run a node as you suggest, there's certainly no guarantee that\nyou'd learn about any double-spend without doing a severe sybil attack against\nthe network; the 8 outgoing nodes a typical node has samples a tiny fraction of\nthe network. And *even if* you sybil attack to try to detect conflicts there's\nstill no guarantee as attackers can use all kinds of special techniques to get\ntransactions into miner mempools and not others.\n\n\u003e 2. Simply assume a conflict exists for otherwise unexplainable failures.\n\u003e For example, if Alice sees several new blocks whose bottom feerates\n\u003e are well below the feerates of an unconfirmed coinjoin transaction\n\u003e that Alice helped create and broadcast, she can assume it's a\n\u003e conflict that is preventing preventing confirmation of the coinjoin.\n\u003e She can find an entirely different set of collaborators and create a\n\u003e non-conflicting transaction without ever needing to know which inputs\n\u003e from the original transaction conflicted. This method has the\n\u003e disadvantage of being slow (on the order of hours) and not attributing\n\u003e fault, although it doesn't require Alice has any information beyond\n\u003e copies\n\u003e of recent blocks.\n\nYou're suggesting that to avoid enabling full-rbf, coinjoin's and other\ndecentralized multi-party protocols risk getting coins tied up for hours trying\nto do conflict resolution rather than just fixing the underlying problem with\nwhat's literally a one-line code change that 17% of the v24.x nodes have\ndecided to enable.\n\n\u003e I didn't list these methods or others before because the specific method\n\u003e used to\n\u003e detect conflicts doesn't matter to the realization that software which\n\u003e uses conflict detection and evasion to defeat the $17.00 attack also\n\u003e defeats the $0.05 attack without any need for full-RBF.\n\nFact is, full-rbf defeats those attacks much better. And I'm amazed that you\ndon't consider raising the cost of attacks on coinjoins and similar\ndecentralized protocols by almost three orders of magnitude to be important:\nwhy are you prioritizing a few highly centralized, often AML/KYC'd, unconfirmed\ntx acceptance services over decentralized protocols which provide privacy and\nsecurity to a lot more users?\n\n-- \nhttps://petertodd.org 'peter'[:-1]@petertodd.org\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 833 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230113/5516cb92/attachment.sig\u003e",
"sig": "fc60bf55bf47aea353fc7b75375fbaf2511c01b04694337dd270e9facd2200866222965b5c07606bd3df958c38fe91867c673697bacab24854cdc6890c495291"
}