<unnamed>

Public Key

npub1mxz2kkpp4z07x65rxwr6gsksd9cnwn0q22lx874t63dh6uulsy7qxnqexn

Profile Code

nprofile1qqsdnp9ttqs638lrd2pn8paygtgxjufhfhs990nrl24agkmaww0cz0qprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctvqy28wumn8ghj7un9d3shjtnyv9kh2uewd9hsrzxrr8

Publishing to

relay.snort.social

relay.damus.io

Last Notes

2023-06-08 00:54:05 CEST

- reply

📅 Original date posted:2021-05-23
📝 Original message:As far as I know, P2TR address contains 32-byte public key. It can be used directly by creating Schnorr signature or indirectly, by revealing tapscript. Does it mean that any taproot output could be modified on-the-fly after being confirmed without changing an address? I mean, if we have base point as the private key with P2TR address tb1p0xlxvlhemja6c4dqv22uapctqupfhlxm9h8z3k2e72q4k9hcz7vqqzj3dz, then the owner of that key can modify spending conditions without moving on-chain coins?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210523/ef943c18/attachment.html>

2023-06-08 00:53:52 CEST

- reply

📅 Original date posted:2021-05-23
📝 Original message:> Perhaps the only things that cannot be usefully changed in a softfork is the block header format and how proof-of-work is computed from the block header.
Why not? I can imagine a soft fork where the block header would contain SHA-256 and SHA-3 hashes in the same place. The SHA-256 would be calculated as-is, but the SHA-3 would be truncated only to cover zero bits in SHA-256 hashes. In this way, if SHA-256 would be totally broken, old nodes would see zero hashes in the previous block hash and the merkle tree hash, but the new nodes would see correct SHA-3 hashes in the same place. So, for example if we have 1d00ffff difficulty, the first 32-bits would be zeroes for all old nodes, but all new nodes would see SHA-3 truncated to 32-bits in the same place. The difficulty could tell us how many zero bits we should truncate our SHA-3 result to. Also, in the same way we could introduce SHA-4 in the future as a soft-fork if SHA-3 would be broken and we would see many zero bits in our mixed SHA-256 plus SHA-3 consensus.
On 2021-05-23 13:01:32 user ZmnSCPxj via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> Good morning Jorge, et al,
>
> > Hardforks can be useful too.
> > But, yes, I agree softforks are preferable whenever possible.
>
> I think in principle the space of possible softforks is very much wider than can be trivially expected.
>
> For instance, maaku7 once proposed a softfork that could potentially change the block discovery rate as a softfork.
> Although this required exploiting a consensus bug that has since been closed.
>
> The example of SegWit shows us that we can in fact create massive changes to the transaction and block formats with a softfork.
>
> For example, it is possible to change the Merkle Tree to use SHA3 instead, in a softfork, by requiring that miners no longer use the "normal" existing Merkle Tree, but instead to require miners to embed a commitment to the SHA3-Merkle-Tree on the coinbase of the "original" block format, and to build "empty" SHA2-Merkle-Trees containing only the coinbase.
> To unupgraded nodes it looks as if there is a denial-of-service attack permanently, while upgraded nodes will seek blocks that conform to the SHA3-Merkle-Tree embedded in the coinbase.
>
> (Do note that this definition of "softfork" is the "> 50% of miners is enough to pull everyone to the fork".
> Some thinkers have a stricter definition of "softfork" as "non-upgraded nodes can still associate addresses to values in the UTXO set but might not be able to detect consensus rules violations in new address types", which fits SegWit and Taproot.)
>
> (In addition, presumably the reason to switch to SHA3 is to avoid potential preimage attacks on SHA2, and the coinbase is still in a SHA2-Merkle-Tree, so... this is a bad example)
>
> Perhaps the only things that cannot be usefully changed in a softfork is the block header format and how proof-of-work is computed from the block header.
> But the flexibility of the coinbase allows us to hook new commitments to new Merkle Trees to it, which allows transactions to be annotated with additional information that is invisible to unupgraded nodes (similar to the `witness` field of SegWit transactions).
>
>
> ------------
>
>
> Even if you *do* have a softfork, we should be reminded to look at the histories of SegWit and Taproot.
>
> SegWit became controversial later on, which delayed its activation.
>
> On the other hand, Taproot had no significant controversy and it was widely accepted as being a definite improvement to the network.
> Yet its implementation and deployment still took a long time, and there was still controversy on how to properly implement the activation code.
>
> Any hardforks would not only have to go through the hurdles that Taproot and SegWit had to go through, but will *also* have to pass through the much higher hurdle of being a hardfork.
>
> Thus, anyone contemplating a hardfork, for any reason, must be prepared to work on it for several **years** before anyone even frowns and says "hmm maybe" instead of everyone just outright dismissing it with a simple "hardfork = hard pass".
> As a simple estimate, I would assume that any hardfork would require twice the average amount of engeineering-manpower involved in SegWit and Taproot.
> (this assumes that hardforks are only twice as hard as softforks --- this estimate may be wrong, and this might provide only a minimum rather than an expected average)
>
> There are no quick solutions in this space.
> Either we work with what we have and figure out how to get around issues with no real capability to fix them at the base layer, or we have insight on future problems and start working on future solutions today.
> For example, I know at least one individual was maintaining an "emergency" branch to add some kind of post-quantum signature scheme to Bitcoin, in case of a quantum break.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 20:31:00 CEST

- reply

📅 Original date posted:2021-03-20
📝 Original message:So, things have to be complicated to be secure? By definition, using some private key, calculating some public key from it and incrementing that key is secure (it is definitely no worse than address reuse). The only problem with using "privKey", "(privKey+1) mod n", "(privKey+2) mod n" and so on is that all of those public keys could be easily linked together. If that is the only problem, then by making offset deterministic but less predictable, it should be secure enough, right? So, instead of simple incrementation, we would have "privKey" (parent), "(privKey+firstOffset) mod n" (first child), "(privKey+secondOffset) mod n" (second child) and so on. And as long as this offset is not guessed by the attacker, it is impossible to link all of those keys together, right?
> On 2021-03-20 11:08:30 user Tim Ruffing <crypto at timruffing.de> wrote:
> > On Fri, 2021-03-19 at 20:46 +0100, vjudeu via bitcoin-dev wrote:
> > > is it safe enough to implement it and use in practice?
> >
> > This may be harsh but I can assure you that a HD wallet scheme that can
> > be specified in 3 lines (without even specifying what the security
> > goals are) should not be assumed safe to implement.
> >
> > Tim
> >
> >
>

2023-06-07 20:31:00 CEST

- reply

📅 Original date posted:2021-03-22
📝 Original message:> I can't really answer that question because it's not specified how "nonce" is obtained.
Nonce depends directly on your derivation path. By default, you can just start from 256-bit zero value and increment it if you want standard derivation path. But optionally it can be something else that is unique, for example username. So, if you have "0/0/0/0" derivation path, then you have four nonces with 256-bit zero each time. But if you have '0/"bitcointalk.org"/5321992/"coinlatte"' derivation path (as mentioned by the author of this scheme), then your first nonce is 256-bit zero value, your second nonce is SHA-256 of "bitcointalk.org", which is f245bd5620ee79314f48d9e9641a5406bd03745f6ac516e2801ef6ccbfe40ced, your third nonce is 0000000000000000000000000000000000000000000000000000000000513508 and your fourth nonce is 314870494d3a9136ba0a67ceb33534cbd438e982105d20cc076204c6fc99594d. There is an example in mentioned topic here: https://bitcointalk.org/index.php?topic=5321992.msg56503261#msg56503261
> the master private key is involved in the derivation of "nonce" (then "nonce" may be unpredictable)
It is impossible, because having some parent public key should be enough to derive child public keys. But even if you know the nonce, you have no idea what masterPublicKey was used in SHA-256 (that is the thing you are looking for if you try to link addresses together).
To see how difficult it is to get some parent key from some child key, you can try going up the tree in the mentioned example. SHA-256 empty string is e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855, but if used directly, that leads us to some key starting with 03 prefix, so we should negate it and get 1c4f3bbd6703e3eb65040b37669046da93009b024aad0cef1b3cc57157e388ec. Then, we have our child key 02 a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd and to break this scheme and prove that going to the parent key is possible, we have to find something like this:
masterPublicKey = attackerPublicKey + SHA256(attackerPublicKey || nonce)
02 a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd = attackerPublicKey + SHA-256(attackerPublicKey || 0000000000000000000000000000000000000000000000000000000000000000)
For me, it seems that finding attackerPublicKey here is impossible. Of course the absence of solution does not mean that it is secure, but I think it is a good example to show how strong this scheme is.
On 2021-03-21 22:45:19 user Tim Ruffing <crypto at timruffing.de> wrote:
> On Sat, 2021-03-20 at 21:25 +0100, vjudeu via bitcoin-dev wrote:
> > So, things have to be complicated to be secure?
>
> Not at all. But we first need to spend some thoughts on what "secure"
> means before we can tell if something is secure.
>
> > By definition, using some private key, calculating some public key
> > from it and incrementing that key is secure (it is definitely no
> > worse than address reuse).
>
> If secure means that it does not hurt the unforgeability of ECDSA, then
> I believe you're right.
>
> > The only problem with using "privKey", "(privKey+1) mod n",
> > "(privKey+2) mod n" and so on is that all of those public keys could
> > be easily linked together. If that is the only problem, then by
> > making offset deterministic but less predictable, it should be secure
> > enough, right? So, instead of simple incrementation, we would have
> > "privKey" (parent), "(privKey+firstOffset) mod n" (first child),
> > "(privKey+secondOffset) mod n" (second child) and so on. And as long
> > as this offset is not guessed by the attacker, it is impossible to
> > link all of those keys together, right?
>
> I believe this intuition is also a good first approach. So let's have a
> look: You say that offset = SHA256(masterPublicKey || nonce). Is this
> predictable by the attacker?
>
> I can't really answer that question because it's not specified how
> "nonce" is obtained. Since this is supposed to be a deterministic
> scheme, I see two basic ways: Either the master private key is involved
> in the derivation of "nonce" (then "nonce" may be unpredictable) or
> it's not (then "nonce" is predictable).
>
> Another fact that may or not be a problem is that it may be possible to
> compute a parent private key from the a private key. Again, I can't
> tell because I don't know how nonce is obtained.
>
> Taking a step back, BIP 32 addresses all of these concerns. I agree it
> could be simpler but I don't see a practical necessity to invent a new
> scheme. In any application where this proposal could potentially be
> used, BIP 32 could also be used and it's just good enough.
>
> Tim
>
>
> >
> > > On 2021-03-20 11:08:30 user Tim Ruffing <crypto at timruffing.de>
> > > wrote:
> > > > On Fri, 2021-03-19 at 20:46 +0100, vjudeu via bitcoin-dev wrote:
> > > > > is it safe enough to implement it and use in practice?
> > > >
> > > > This may be harsh but I can assure you that a HD wallet scheme
> > > > that can
> > > > be specified in 3 lines (without even specifying what the
> > > > security
> > > > goals are) should not be assumed safe to implement.
> > > >
> > > > Tim
> > > >
> > > >
> > >
> >
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>

2023-06-07 20:31:00 CEST

- reply

📅 Original date posted:2021-03-20
📝 Original message:How length extension attack is possible here? The input of SHA-256 has constant length of 512 bits in this scheme. And if someone will get some child public key, there is still no way to reverse it to the parent public key, because even if the second block of SHA-256 is the same all the times, the attacker still does not know the outcome of SHA-256, so the last round of SHA-256 is unknown and doing calculations backwards seems to be impossible.
> On 2021-03-20 03:08:39 user Arik Sosman <me at arik.io> wrote:
> > Hi Erik,
> >
> > Would sha256-hmac(nonce, publicKeyPoint) still be a suitable/safe alternative without relying on sha3? That should at the very least eliminate length extension attacks.
> >
> > Best,
> > Arik
> >
> > > On Mar 19, 2021, at 6:32 PM, Erik Aronesty via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > >
> > > use sha3-256. sha256 suffers from certain attacks (length extension,
> > > for example) that could make your scheme vulnerable to leaking info,
> > > depending on how you concatenate things, etc. better to choose
> > > something where padding doesn't matter.
> > >
> > > On Fri, Mar 19, 2021 at 7:28 PM vjudeu via bitcoin-dev
> > > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > >>
> > >> I recently found some interesting and simple HD wallet design here: https://bitcointalk.org/index.php?topic=5321992.0
> > >> Could anyone see any flaws in such design or is it safe enough to implement it and use in practice?
> > >> If I understand it correctly, it is just pure ECDSA and SHA-256, nothing else:
> > >>
> > >> masterPublicKey = masterPrivateKey * G
> > >> masterChildPublicKey = masterPublicKey + ( SHA-256( masterPublicKey || nonce ) mod n ) * G
> > >> masterChildPrivateKey = masterPrivateKey + ( SHA-256( masterPublicKey || nonce ) mod n )
> > >>
> > >> Also, it has some nice properties, like all keys starting with 02 prefix and allows potentially unlimited custom derivation path by using 256-bit nonce.
> > >> _______________________________________________
> > >> bitcoin-dev mailing list
> > >> bitcoin-dev at lists.linuxfoundation.org
> > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > > _______________________________________________
> > > bitcoin-dev mailing list
> > > bitcoin-dev at lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> >
>
>
>
>

2023-06-07 20:30:58 CEST

- reply

📅 Original date posted:2021-03-19
📝 Original message:I recently found some interesting and simple HD wallet design here: https://bitcointalk.org/index.php?topic=5321992.0
Could anyone see any flaws in such design or is it safe enough to implement it and use in practice?
If I understand it correctly, it is just pure ECDSA and SHA-256, nothing else:
masterPublicKey = masterPrivateKey * G
masterChildPublicKey = masterPublicKey + ( SHA-256( masterPublicKey || nonce ) mod n ) * G
masterChildPrivateKey = masterPrivateKey + ( SHA-256( masterPublicKey || nonce ) mod n )
Also, it has some nice properties, like all keys starting with 02 prefix and allows potentially unlimited custom derivation path by using 256-bit nonce.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210319/84226cbf/attachment.html>