vjudeu [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2021-03-19 to 2021-05-23
💬 Posted a total of 9 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 22:54:05

- 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-07 22:53:53

- reply

📅 Original date posted:2021-05-23
📝 Original message:> Because the above block header format is hashed to generate the `prevBlockHash` for the *next* block, it is almost impossible to change the format without a hardfork.
First, assume that everything should be validated as today to be backward-compatible. For that reason, removing SHA-256 is impossible. Then, notice that breaking SHA-256 would mean that there would be more and more leading zeroes in "prevBlockHash". Breaking SHA-256 fully would mean reaching all zeroes hash. So, the old client would see "prevBlockHash" with all zeroes.
Soft-fork means that previously valid blocks could be invalid, so rules should be more strict. And that means we could have two headers, one for SHA-256 and one for SHA-3. Normally, it would mean that our 80-byte headers would take 160 bytes instead. But we could compress it a little bit if we share some data.
> * `nVersion`: 4 bytes
Version would be some higher number than today and validated as today. It could be shared for both headers.
> * `prevBlockHash`: 32 bytes, SHA2 of previous block.
Previous block hash in SHA-256 would have more and more leading zeroes, so we could reuse them and fill with SHA-3 truncated to N bits. In this way, after fully breaking SHA-256 it would be fully replaced by SHA-3. Until then, first N bits could refer to truncated SHA-3 and the rest to SHA-256. When passing that to old nodes, that bits could be zeroed, but all new nodes should see them and perform SHA-3 validation.
Example:
SHA-2 of some block: 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
SHA-3 of the same data: 95587d55da5108290c46bac70b622715ae380ef7a313febcc27aeb1c51a28d90
32 bytes stored for that block: 95587d550019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f
Of course, we should perform SHA-3 on a different data than used for SHA-2, at least merkle root should be recalculated, but it is just an example showing how single 32-byte string could store data for both hash functions.
> * `merkleTreeRoot`: 32 bytes, SHA2 of topmost Merkle tree node.
If SHA-256 would be broken, then we could use single coinbase transaction to prevent doing transactions in the old way. That transaction would contain SHA-3 of the new merkle root, as you mentioned. New nodes could treat that transaction as some kind of annex to the block header, but still doing SHA-2 is needed for backward compatibility. For that reason, storing 32 bytes for SHA-2 and 32 bytes for SHA-3 is needed, unless we have some fast way to get hash with all zeroes, then we can save that 32 bytes.
> * `nTime`: 4 bytes, miner-imagined time.
Time should be the same in both headers, so there is no need to duplicate it.
> * `nBits`: 4 bytes, encoded difficulty target
Difficulty should be different for SHA-2 and SHA-3. Finally when SHA-256 would be broken, we could reach 03000000 for SHA-256 and store only SHA-3 difficulty.
> * `nonce`: 4 bytes, random number with no other meaning.
Nonce should be also different for SHA-2 and SHA-3. If SHA-256 would be fully broken, it could be set to zero for SHA-2 and stored only for SHA-3.
On 2021-05-23 20:12:00 user ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning vjudeu,
>
> > > 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.
>
> I do not think I follow.
>
> The block header has a Merkle tree root that is a SHA-256 of some Merkle tree node, is that what you refer to?
> Do you mean the same Merkle tree node has to hash to some common value in both SHA-2 and SHA-3?
>
> Or do you refer to the `prevBlockHash`?
> Do you mean the same `prevBlockHash` has to somehow be the same, for some number of bits, in both SHA-2 and SHA-3?
>
> More specifically:
>
> * `nVersion`: 4 bytes
> * `prevBlockHash`: 32 bytes, SHA2 of previous block.
> * `merkleTreeRoot`: 32 bytes, SHA2 of topmost Merkle tree node.
> * `nTime`: 4 bytes, miner-imagined time.
> * `nBits`: 4 bytes, encoded difficulty target
> * `nonce`: 4 bytes, random number with no other meaning.
>
> What do you refer to?
>
> Because the above block header format is hashed to generate the `prevBlockHash` for the *next* block, it is almost impossible to change the format without a hardfork.
>
> Regaards,
> ZmnSCPxj
>
> >
> > 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 22:53:52

- 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 22:53:36

- reply

📅 Original date posted:2021-05-15
📝 Original message:We have some taproot address with private key "a" and public key "a*G", owned by Alice. Bob wants to take Alice's coins without her permission. He owns taproot address with private key "b" and public key "b*G". He knows "a*G" by exploring the chain and looking for P2TR outputs. To grab Alice's funds, he creates "(b-a)*G" taproot address and send some small amount to this address. Then, Bob can create a transaction with two inputs, taking coins from "a*G" and "(b-a)*G" addresses. All that is needed is producing a signature matching the sum of the public keys used in taproot, which is "(a+b-a)*G", reduced to "b*G", so Bob uses his "b" private key to produce Schnorr signature. Is there any protection from this attack?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210515/9b58f6eb/attachment.html>

2023-06-07 22:51:52

- reply

📅 Original date posted:2021-04-17
📝 Original message:Yes, transition from Proof of Work to Proof of Something Else is possible in a soft-fork way. All that is needed is getting miners and users support. Then, Proof of Work difficulty should drop to one, and the rest would be solved by Proof of Something Else. Old miners still could use ASIC miners to produce blocks with higher Proof of Work, but then their blocks would be rejected. Currently, you can also make a block with enormously low hash, but if this block would contain two transactions sending the same coins to two different places, it would be rejected, no matter how low that hash would be. As long as miners would produce enough Proof of Something Else and as long as most nodes would use upgraded software, it should be resistant to such attacks.
So, technically speaking, it is possible. The most difficult part is getting miners and users supporting it.
On 2021-04-16 23:47:44 user Erik Aronesty via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > I think you need to hard deprecate the PoW for this to work, otherwise all old miners are like "toxic waste".
>
> what would be the incentive? a POB would be required on every block
> (and would be lost if not used). so any miner doing this would just
> be doing "extra work" and strictly losing money over a miner that
> doesn't. a 99% reduction would be more than enough tho.
>
> On Fri, Apr 16, 2021 at 5:24 PM Jeremy <jlrubin at mit.edu> wrote:
> >
> > I think you need to hard deprecate the PoW for this to work, otherwise all old miners are like "toxic waste".
> >
> > Imagine one miner turns on a S9 and then ramps up difficulty for everyone else.
> >
> > On Fri, Apr 16, 2021, 2:08 PM Erik Aronesty via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>
> >> Not sure of the best place to workshop ideas, so please take this with
> >> a grain of salt.
> >>
> >> Starting with 3 assumptions:
> >>
> >> - assume that there exists a proof-of-burn that, for Bitcoin's
> >> purposes, accurately-enough models the investment in and development
> >> of ASICs to maintain miner incentive.
> >> - assume the resulting timing problem "how much burn is enough to keep
> >> blocks 10 minutes apart and what does that even mean" is also...
> >> perfectly solvable
> >> - assume "everyone unanimously loves this idea"
> >>
> >> The transition *could* look like this:
> >>
> >> - validating nodes begin to require proof-of-burn, in addition to
> >> proof-of-work (soft fork)
> >> - the extra expense makes it more expensive for miners, so POW slowly drops
> >> - on a predefined schedule, POB required is increased to 100% of the
> >> "required work" to mine
> >>
> >> Given all of that, am I correct in thinking that a hard fork would not
> >> be necessary?
> >>
> >> IE: We could transition to another "required proof" - such as a
> >> quantum POW or a POB (above) or something else .... in a back-compat
> >> way (existing nodes not aware of the rules would continue to
> >> validate).
> >> _______________________________________________
> >> 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 18:31:00

- 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 18:31:00

- 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 18:31:00

- 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 18:30:58

- 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>