{"type":"rich","version":"1.0","author_name":"npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpx","author_url":"https://nostr.ae/npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpx","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2016-01-08\n📝 Original message:Pieter Wuille via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\nwrites:\n\u003e Yes, this is what I worry about. We're constructing a 2-of-2 multisig\n\u003e escrow in a contract. I reveal my public key A, you do a 80-bit search for\n\u003e B and C such that H(A and B) = H(B and C). You tell me your keys B, and I\n\u003e happily send to H(A and B), which you steal with H(B and C).\n\nFWIW, this attack would effect the current lightning-network \"deployable\nlightning\" design at channel establishment; we reveal our pubkey in the\nopening packet (which is used to redeem a P2SH using normal 2of2).\n\nAt least you need to grind before replying (which will presumably time\nout), rather than being able to do it once the channel is open.\n\nWe could pre-commit by exchanging hashes of pubkeys first, but contracts\non bitcoin are hard enough to get right that I'm reluctant to add more\nhoops.\n\nCheers,\nRusty."}