📅 Original date posted:2021-03-15
📝 Original message:I think Luke is pointing out that with the Signature and the Message you
should be able to recover the key.
if your address is H(P) and the message is H(H(P) || txn), then the you can
use the public H(P) and the signature to recover the PK and verify that
H(P) == P (I think you then don't even have to check the signature after
doing that).
Therefore there is no storage benefit.
For the script path case, you might have to pay a little bit extra though
as you'd have to reveal P I think? But perhaps that can be avoided another
way...
--
@JeremyRubin <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;
On Mon, Mar 15, 2021 at 3:06 PM Matt Corallo via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> There have been many threads on this before, I'm not sure anything new has
> been brought up here.
>
> Matt
>
> On 3/15/21 17:48, Luke Dashjr via bitcoin-dev wrote:
> > I do not personally see this as a reason to NACK Taproot, but it has
> become
> > clear to me over the past week or so that many others are unaware of this
> > tradeoff, so I am sharing it here to ensure the wider community is aware
> of
> > it and can make their own judgements.
>
> Note that this is most definitely *not* news to this list, eg, Anthony
> brought it up in "Schnorr and taproot (etc)
> upgrade" and there was a whole thread on it in "Taproot: Privacy
> preserving switchable scripting". This issue has been
> beaten to death, I'm not sure why we need to keep hitting the poor horse
> corpse.
>
> >
> > In short, Taproot loses an important safety protection against quantum.
> > Note that in all circumstances, Bitcoin is endangered when QC becomes a
> > reality, but pre-Taproot, it is possible for the network to "pause"
> while a
> > full quantum-safe fix is developed, and then resume transacting. With
> Taproot
> > as-is, it could very well become an unrecoverable situation if QC go
> online
> > prior to having a full quantum-safe solution.
>
> This has been discussed ad nauseam, and it all seems to fall apart once
> its noted just how much Bitcoin could be stolen
> by any QC-wielding attacker due to address reuse. Ultimately, no "pause"
> can solve this issue, and, if we learned about
> a QC attacker overnight (instead of slowly over time), there isn't
> anything that a non-Taproot Bitcoin could do that a
> Taproot Bitcoin couldn't.
>
> > Also, what I didn't know myself until today, is that we do not actually
> gain
> > anything from this: the features proposed to make use of the raw keys
> being
> > public prior to spending can be implemented with hashed keys as well.
> > It would use significantly more CPU time and bandwidth (between private
> > parties, not on-chain), but there should be no shortage of that for
> anyone
> > running a full node (indeed, CPU time is freed up by Taproot!); at
> worst, it
> > would create an incentive for more people to use their own full node,
> which
> > is a good thing!
>
> This is untrue. The storage space required for Taproot transactions is
> materially reduced by avoiding the hash indirection.
>
> > Despite this, I still don't think it's a reason to NACK Taproot: it
> should be
> > fairly trivial to add a hash on top in an additional softfork and fix
> this.
>
> For the reason stated above, i think such a fork is unlikely.
>
> > In addition to the points made by Mark, I also want to add two more, in
> > response to Pieter's "you can't claim much security if 37% of the supply
> is
> > at risk" argument. This argument is based in part on the fact that many
> > people reuse Bitcoin invoice addresses.
> >
> > First, so long as we have hash-based addresses as a best practice, we can
> > continue to shrink the percentage of bitcoins affected through social
> efforts
> > discouraging address use. If the standard loses the hash, the situation
> > cannot be improved, and will indeed only get worse.
>
> I truly wish this were the case, but we've been beating that drum for at
> least nine years and still haven't solved it.
> Worse, there's a lot of old coins that are unlikely to move any time soon
> that are exposed whether we like it or not.
>
> > Second, when/if quantum does compromise these coins, so long as they are
> > neglected or abandoned/lost coins (inherent in the current model), it
> can be
> > seen as equivalent to Bitcoin mining. At the end of the day, 37% of
> supply
> > minable by QCs is really no different than 37% minable by ASICs. (We've
> seen
> > far higher %s available for mining obviously.)
>
> Except its not? One entity would be able to steal that entire block of
> supply rather quickly (presumably over the course
> of a few days, at maximum), instead of a slow process with significant
> upfront real-world cost in the form of electricity.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210315/7b7aea3f/attachment-0001.html>;
Jeremy [ARCHIVE] /
npub1q8…8qwta
2023-06-07 18:30:51
in reply to nevent1q…rygq
Author Public Key
npub1q86n5vtxkwerzwfqza3hwls8pl8764244464talfqy2vpj0qaz6q38qwtaPublished at
2023-06-07 18:30:51Event JSON
{
"id": "09ecd5c6f26bd0afcdf691e0aa662b249bf1dffe9135668eb9051456960e7935",
"pubkey": "01f53a3166b3b23139201763777e070fcfed5555ad7555f7e90114c0c9e0e8b4",
"created_at": 1686162651,
"kind": 1,
"tags": [
[
"e",
"a234deec8deaa4b2f960309b1c4b9227805148596a77c14f96fdcb654e31f3ba",
"",
"root"
],
[
"e",
"669a53afe932c304328fa023ed6f7a76b3cad12d504bd5ab2660fc5b8720ae37",
"",
"reply"
],
[
"p",
"931a6829f7e5cb4e97113f9e9c9b91597fea65dd5df324f02e5687e9c7973d7d"
]
],
"content": "📅 Original date posted:2021-03-15\n📝 Original message:I think Luke is pointing out that with the Signature and the Message you\nshould be able to recover the key.\n\nif your address is H(P) and the message is H(H(P) || txn), then the you can\nuse the public H(P) and the signature to recover the PK and verify that\nH(P) == P (I think you then don't even have to check the signature after\ndoing that).\n\nTherefore there is no storage benefit.\n\nFor the script path case, you might have to pay a little bit extra though\nas you'd have to reveal P I think? But perhaps that can be avoided another\nway...\n--\n@JeremyRubin \u003chttps://twitter.com/JeremyRubin\u003e\n\u003chttps://twitter.com/JeremyRubin\u003e\n\n\nOn Mon, Mar 15, 2021 at 3:06 PM Matt Corallo via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e There have been many threads on this before, I'm not sure anything new has\n\u003e been brought up here.\n\u003e\n\u003e Matt\n\u003e\n\u003e On 3/15/21 17:48, Luke Dashjr via bitcoin-dev wrote:\n\u003e \u003e I do not personally see this as a reason to NACK Taproot, but it has\n\u003e become\n\u003e \u003e clear to me over the past week or so that many others are unaware of this\n\u003e \u003e tradeoff, so I am sharing it here to ensure the wider community is aware\n\u003e of\n\u003e \u003e it and can make their own judgements.\n\u003e\n\u003e Note that this is most definitely *not* news to this list, eg, Anthony\n\u003e brought it up in \"Schnorr and taproot (etc)\n\u003e upgrade\" and there was a whole thread on it in \"Taproot: Privacy\n\u003e preserving switchable scripting\". This issue has been\n\u003e beaten to death, I'm not sure why we need to keep hitting the poor horse\n\u003e corpse.\n\u003e\n\u003e \u003e\n\u003e \u003e In short, Taproot loses an important safety protection against quantum.\n\u003e \u003e Note that in all circumstances, Bitcoin is endangered when QC becomes a\n\u003e \u003e reality, but pre-Taproot, it is possible for the network to \"pause\"\n\u003e while a\n\u003e \u003e full quantum-safe fix is developed, and then resume transacting. With\n\u003e Taproot\n\u003e \u003e as-is, it could very well become an unrecoverable situation if QC go\n\u003e online\n\u003e \u003e prior to having a full quantum-safe solution.\n\u003e\n\u003e This has been discussed ad nauseam, and it all seems to fall apart once\n\u003e its noted just how much Bitcoin could be stolen\n\u003e by any QC-wielding attacker due to address reuse. Ultimately, no \"pause\"\n\u003e can solve this issue, and, if we learned about\n\u003e a QC attacker overnight (instead of slowly over time), there isn't\n\u003e anything that a non-Taproot Bitcoin could do that a\n\u003e Taproot Bitcoin couldn't.\n\u003e\n\u003e \u003e Also, what I didn't know myself until today, is that we do not actually\n\u003e gain\n\u003e \u003e anything from this: the features proposed to make use of the raw keys\n\u003e being\n\u003e \u003e public prior to spending can be implemented with hashed keys as well.\n\u003e \u003e It would use significantly more CPU time and bandwidth (between private\n\u003e \u003e parties, not on-chain), but there should be no shortage of that for\n\u003e anyone\n\u003e \u003e running a full node (indeed, CPU time is freed up by Taproot!); at\n\u003e worst, it\n\u003e \u003e would create an incentive for more people to use their own full node,\n\u003e which\n\u003e \u003e is a good thing!\n\u003e\n\u003e This is untrue. The storage space required for Taproot transactions is\n\u003e materially reduced by avoiding the hash indirection.\n\u003e\n\u003e \u003e Despite this, I still don't think it's a reason to NACK Taproot: it\n\u003e should be\n\u003e \u003e fairly trivial to add a hash on top in an additional softfork and fix\n\u003e this.\n\u003e\n\u003e For the reason stated above, i think such a fork is unlikely.\n\u003e\n\u003e \u003e In addition to the points made by Mark, I also want to add two more, in\n\u003e \u003e response to Pieter's \"you can't claim much security if 37% of the supply\n\u003e is\n\u003e \u003e at risk\" argument. This argument is based in part on the fact that many\n\u003e \u003e people reuse Bitcoin invoice addresses.\n\u003e \u003e\n\u003e \u003e First, so long as we have hash-based addresses as a best practice, we can\n\u003e \u003e continue to shrink the percentage of bitcoins affected through social\n\u003e efforts\n\u003e \u003e discouraging address use. If the standard loses the hash, the situation\n\u003e \u003e cannot be improved, and will indeed only get worse.\n\u003e\n\u003e I truly wish this were the case, but we've been beating that drum for at\n\u003e least nine years and still haven't solved it.\n\u003e Worse, there's a lot of old coins that are unlikely to move any time soon\n\u003e that are exposed whether we like it or not.\n\u003e\n\u003e \u003e Second, when/if quantum does compromise these coins, so long as they are\n\u003e \u003e neglected or abandoned/lost coins (inherent in the current model), it\n\u003e can be\n\u003e \u003e seen as equivalent to Bitcoin mining. At the end of the day, 37% of\n\u003e supply\n\u003e \u003e minable by QCs is really no different than 37% minable by ASICs. (We've\n\u003e seen\n\u003e \u003e far higher %s available for mining obviously.)\n\u003e\n\u003e Except its not? One entity would be able to steal that entire block of\n\u003e supply rather quickly (presumably over the course\n\u003e of a few days, at maximum), instead of a slow process with significant\n\u003e upfront real-world cost in the form of electricity.\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\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210315/7b7aea3f/attachment-0001.html\u003e",
"sig": "ca462914ea52cff7d3e649d1e31392d2842ccac5c7906488e06a47ceca112e781154b34c0ca29de26901fdcd33e98ccaddb9ac977d740631a88953b2bd37f7ca"
}