📅 Original date posted:2020-04-22
📝 Original message:
On Wed, Apr 22, 2020 at 03:03:29PM -0400, Antoine Riard wrote:
> > In that case, would it be worth re-implementing something like a BIP61
> reject message but with an extension that returns the txids of any
> conflicts?
>
> That's an interesting idea, but an attacker can create a local conflict in
> your mempool
You don't need a mempool to send a transaction. You can just open
connections to random Bitcoin nodes directly and try sending your
transaction. That's what a lite client is going to do anyway. If the
pinned transaction is in the mempools of a significant number of Bitcoin
nodes, then it should take just a few random connections to find one of
those nodes, learn about the conflict, and download the pinned
transaction.
If that's not acceptable, you could find some other way to poll a
significant number of people with mempools, e.g. BIP35 mempool messages
or reusing the payment hash in a bunch of 1 msat probes to LN nodes who
opt-in to scanning their bitcoind's mempools for a corresponding
preimage.
-Dave
-------------- 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/lightning-dev/attachments/20200422/2f72c33e/attachment.sig>;
David A. Harding [ARCHIVE] /
npub16d…x4wrd
2023-06-09 12:59:51
in reply to nevent1q…gt4t
Author Public Key
npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrdPublished at
2023-06-09 12:59:51Event JSON
{
"id": "b67cd311bf24d867918159d51aae9a8b5a40964c270542d137fe82a024cf939a",
"pubkey": "d3574a24208f4e3d0821bb4a69a0c3ae842043d444fa5c4a8c49c369918a6fb2",
"created_at": 1686315591,
"kind": 1,
"tags": [
[
"e",
"ee435bc1a0c788f72e8a81b7b60de4f1b61098c601fe4125e1e3cc7e4c34ee87",
"",
"root"
],
[
"e",
"c91a039cba3e41917633fdc6e59724c78f2da08155207e49cbfd3cc77a3bbd0e",
"",
"reply"
],
[
"p",
"01f53a3166b3b23139201763777e070fcfed5555ad7555f7e90114c0c9e0e8b4"
]
],
"content": "📅 Original date posted:2020-04-22\n📝 Original message:\nOn Wed, Apr 22, 2020 at 03:03:29PM -0400, Antoine Riard wrote:\n\u003e \u003e In that case, would it be worth re-implementing something like a BIP61\n\u003e reject message but with an extension that returns the txids of any\n\u003e conflicts?\n\u003e \n\u003e That's an interesting idea, but an attacker can create a local conflict in\n\u003e your mempool\n\nYou don't need a mempool to send a transaction. You can just open\nconnections to random Bitcoin nodes directly and try sending your\ntransaction. That's what a lite client is going to do anyway. If the\npinned transaction is in the mempools of a significant number of Bitcoin\nnodes, then it should take just a few random connections to find one of\nthose nodes, learn about the conflict, and download the pinned\ntransaction.\n\nIf that's not acceptable, you could find some other way to poll a\nsignificant number of people with mempools, e.g. BIP35 mempool messages\nor reusing the payment hash in a bunch of 1 msat probes to LN nodes who\nopt-in to scanning their bitcoind's mempools for a corresponding\npreimage.\n\n-Dave\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/lightning-dev/attachments/20200422/2f72c33e/attachment.sig\u003e",
"sig": "9478385d8a1c2c2b9bcdb15598d72be885a276b103cdf34f2e8de988d5c5d25bea1c979208cf569a96cfcd0a8ce79f6e47be45bd2bfd921d4c1253285453f7fa"
}