rich1.0npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxhttps://nostr.ae/npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxnjumphttps://nostr.ae📅 Original date posted:2016-01-08 📝 Original message:Pieter Wuille via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> writes: > Yes, this is what I worry about. We're constructing a 2-of-2 multisig > escrow in a contract. I reveal my public key A, you do a 80-bit search for > B and C such that H(A and B) = H(B and C). You tell me your keys B, and I > happily send to H(A and B), which you steal with H(B and C). FWIW, this attack would effect the current lightning-network "deployable lightning" design at channel establishment; we reveal our pubkey in the opening packet (which is used to redeem a P2SH using normal 2of2). At least you need to grind before replying (which will presumably time out), rather than being able to do it once the channel is open. We could pre-commit by exchanging hashes of pubkeys first, but contracts on bitcoin are hard enough to get right that I'm reluctant to add more hoops. Cheers, Rusty.