<blockquote style="border-left: 3px solid rgb(200, 200, 200); border-color: rgb(200, 200, 200); padding-left: 10px; color: rgb(102, 102, 102);"><div style="font-family: Arial, sans-serif; font-size: 14px;"><span dir="auto"></span><span dir="auto">This way, the attacker would have to revert the chain to steal which is assumed impossible.</span><br></div></blockquote>
<div class="protonmail_signature_block protonmail_signature_block-empty" style="font-family: Arial, sans-serif; font-size: 14px;">
<div class="protonmail_signature_block-user protonmail_signature_block-empty">
</div>
<div class="protonmail_signature_block-proton protonmail_signature_block-empty">
</div>
</div>
<div style="font-family: Arial, sans-serif; font-size: 14px;"><br></div><div style="font-family: Arial, sans-serif; font-size: 14px;">Or just create its own "QR output"?</div><div style="font-family: Arial, sans-serif; font-size: 14px;"><br></div><div style="font-family: Arial, sans-serif; font-size: 14px;">If your threat model assumes an attacker can promptly recover the private key from the public key then once the user broadcasts his transaction spending both the old output and his own QR output the attacker could simply create his own QR output and RBF the honest transaction.</div><div style="font-family: Arial, sans-serif; font-size: 14px;"><br></div><div style="font-family: Arial, sans-serif; font-size: 14px;">I suppose you could in theory have, in addition to making spending old outputs invalid on their own, a rule which dictates they may only be spent along with a QR output at least X blocks old. This would give the honest user a headstart in this race, but meh.<br></div><div class="protonmail_quote">
On Sunday, March 16th, 2025 at 2:25 PM, Martin Habovštiak <martin.habovstiak@gmail.com> wrote:<br>
<blockquote class="protonmail_quote" type="cite">
<div dir="auto">Hello list,<div dir="auto"><br></div><div dir="auto">this is somewhat related to Jameson's recent post but different enough to warrant a separate topic.</div><div dir="auto"><br></div><div dir="auto">As you have probably heard many times and even think yourself, "hashed keys are not actually secure, because a quantum attacker can just snatch them from mempool". However this is not strictly true.</div><div dir="auto"><br></div><div dir="auto">It is possible to implement fully secure recovery if we forbid spending of hashed keys unless done through the following scheme:</div><div dir="auto">0. we assume we have *some* QR signing deployed, it can be done even after QC becomes viable (though not without economic cost)</div><div dir="auto">1. the user obtains a small amount of bitcoin sufficient to pay for fees via external means, held on a QR script</div><div dir="auto">2. the user creates a transaction that, aside from having a usual spendable output also commits to a signature of QR public key. This proves that the user knew the private key even though the public key wasn't revealed yet.</div><div dir="auto">3. after sufficient number of blocks, the user spends both the old and QR output in a single transaction. Spending requires revealing the previously-committed sigature. Spending the old output alone is invalid.</div><div dir="auto"><br></div><div dir="auto">This way, the attacker would have to revert the chain to steal which is assumed impossible.</div><div dir="auto"><br></div><div dir="auto">The only weakness I see is that (x)pubs would effectively become private keys. However they already kinda are - one needs to protect xpubs for privacy and to avoid the risk of getting marked as "dirty" by some agencies, which can theoretically render them unspendable. And non-x-pubs generally do not leak alone (no reason to reveal them without spending).</div><div dir="auto"><br></div><div dir="auto">I think that the mere possibility of this scheme has two important implications:</div><div dir="auto">* the need to have "a QR scheme" ready now in case of a QC coming tomorrow is much smaller than previously thought. Yes, doing it too late has the effect of temporarily freezing coins which is costly and we don't want that but it's not nearly as bad as theft</div><div dir="auto">* freezing of *these* coins would be both immoral and extremely dangerous for reputation of Bitcoin (no comments on freezing coins with revealed pubkeys, I haven't made my mind yet)</div><div dir="auto"><br></div><div dir="auto">If the time comes I'd be happy to run a soft fork that implements this sanely.</div><div dir="auto"><br></div><div dir="auto">Cheers</div><div dir="auto"><br></div><div dir="auto">Martin</div></div>
<p></p>
-- <br>
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:bitcoindev+unsubscribe@googlegroups.com" rel="noreferrer nofollow noopener">bitcoindev+unsubscribe@googlegroups.com</a>.<br>
To view this discussion visit <a href="https://groups.google.com/d/msgid/bitcoindev/CALkkCJY%3Ddv6cZ_HoUNQybF4-byGOjME3Jt2DRr20yZqMmdJUnQ%40mail.gmail.com" target="_blank" rel="noreferrer nofollow noopener">https://groups.google.com/d/msgid/bitcoindev/CALkkCJY%3Ddv6cZ_HoUNQybF4-byGOjME3Jt2DRr20yZqMmdJUnQ%40mail.gmail.com</a>.<br>
</blockquote><br>
</div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoindev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href="https://groups.google.com/d/msgid/bitcoindev/XHIL8Z4i4hji8LhbJ0AiKQ4eago2evXwjTGUOqqyAye_2nM3QicDpHo6KkcznBAHPUrIWSLj_GuiTQ_97KPjxcOrG8pE0rgcXucK2-4txKE%3D%40protonmail.com?utm_medium=email&utm_source=footer">https://groups.google.com/d/msgid/bitcoindev/XHIL8Z4i4hji8LhbJ0AiKQ4eago2evXwjTGUOqqyAye_2nM3QicDpHo6KkcznBAHPUrIWSLj_GuiTQ_97KPjxcOrG8pE0rgcXucK2-4txKE%3D%40protonmail.com</a>.<br />