{"type":"rich","version":"1.0","title":"Matt Corallo [ARCHIVE] wrote","author_name":"Matt Corallo [ARCHIVE] (npub1e4…jxmcu)","author_url":"https://yabu.me/npub1e46n428mcyfwznl7nlsf6d3s7rhlwm9x3cmkuqzt3emmdpadmkaqqjxmcu","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2021-03-15\n📝 Original message:Right, totally. There was substantial debate on the likelihood of such a QC existing (ie a slow one) on the original \nthread several years ago, but ignoring that, my broader point was about the address reuse issue. Given that, there's \njust not much we can do with the existing hash-indirection.\n\nMatt\n\nOn 3/15/21 19:01, Karl-Johan Alm via bitcoin-dev wrote:\n\u003e On Tue, 16 Mar 2021 at 07:48, Matt Corallo via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e Overall, the tradeoffs here seem ludicrous, given that any QC issues in Bitcoin need to be solved in another way, and\n\u003e\u003e can't practically be solved by just relying on the existing hash indirection.\n\u003e \n\u003e The important distinction here is that, with hashes, an attacker has\n\u003e to race against the spending transaction confirming, whereas with\n\u003e naked pubkeys, the attacker doesn't have to wait for a spend to occur,\n\u003e drastically increasing the available time to attack.\n\u003e \n\u003e It may initially take months to break a single key. In such a\n\u003e scenario, anyone with a hashed pubkey would be completely safe* (even\n\u003e at spend time), until that speeds up significantly, while Super Secure\n\u003e Exchange X with an ultra-cold 38-of-38 multisig setup using Taproot\n\u003e would have a timer ticking, since the attacker need only find a single\n\u003e privkey like with any old P2PK output.\n\u003e \n\u003e (* assuming no address reuse)\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e"}