Search content
Sort by
Showing 20 of 25 results by natb
Re: Python Bitcoin ECC library, supports signing, transactions, determinstic wallets
Vitalik, this is exactly what I was looking for. I'm going to replace my HW wallet test harness with your library (the one I was using before was functional, but I'd say not the cleanest library in the world). Thanks for sharing - I'll let you know if I run across any issues or have any improvement ideas.
Re: SIGHASH_WITHINPUTVALUE: Super-lightweight HW wallets and offline data
Yes you are missing something.
The way Trezor works is that the untrusted host computer provides the Trezor wallet with every transaction that the to-be-signed transaction's inputs spend. All transactions refer to transaction inputs by a secure cryptographic hash, the transaction id. Thus it is impossible for the host computer to hide what transaction inputs are in fact being signed by the wallet - the worst the host computer could do is have the wallet harmlessly sign a completely invalid transaction.
The way Trezor works is that the untrusted host computer provides the Trezor wallet with every transaction that the to-be-signed transaction's inputs spend. All transactions refer to transaction inputs by a secure cryptographic hash, the transaction id. Thus it is impossible for the host computer to hide what transaction inputs are in fact being signed by the wallet - the worst the host computer could do is have the wallet harmlessly sign a completely invalid transaction.
Ahh, of course - I was overcomplicating things in my mind. Thanks for setting me straight. My test harness was making up these previous hashes for the purpose of tx signature testing, so I mentally wrote them off as arbitrary.
If my device is presented with the previous transactions for addresses A, B, and C (which include their total value) I can simply SHA256 these, make sure the hashes in the outpoint structures for the tx I'm going to sign match, and then I know the total alleged value for A, B, C and can present outputs and fees to the user. As you said before, the worst thing the SW feeding me stuff to sign can do is make me create a bogus transaction that will be rejected by the network. A bit of a hassle, but at least its just doing a streaming calculation of a SHA256 (not ECDSA thank goodness!) and no blockchain data is necessary. I feel alot better now, back to making progress
However, life as a HW wallet designer would still be much better with the proposed addition.
Re: SIGHASH_WITHINPUTVALUE: Super-lightweight HW wallets and offline data
The script subsystem only requires the tx you are signing.
The point is more succinct - avoid extending the Bitcoin standard.
I would also like a SIGHASH flag where you can specify a specific output to sign (so you can specify change address with pledges for SIGHASH_ANYONECANPAY), but I don't think it's a good idea to change Bitcoin's current design. More dependencies and execution paths = poor design = insecure code. We should be taking things out, not putting in.
The point is more succinct - avoid extending the Bitcoin standard.
I would also like a SIGHASH flag where you can specify a specific output to sign (so you can specify change address with pledges for SIGHASH_ANYONECANPAY), but I don't think it's a good idea to change Bitcoin's current design. More dependencies and execution paths = poor design = insecure code. We should be taking things out, not putting in.
When a signing device is presented a tx to sign, unfortunately it requires much more than the tx itself to give the end user an indication of how much is being proposed to send. Only the outputs are known with 100% certainty. The device must also know with 100% confidence the value of the inputs so the fees can be calculated. This in turn creates way more dependencies and code paths for a HW signing device.
Anyway, I'm now genuinely curious on how the Trezor is solving this problem. Etothepi, you mentioned they ran into it, and I presume they have attempted to solve it. Assuming that the software driving the HW wallet is not trusted (which is the cornerstone assumption of a good offline HW wallet design), I don't see how the device can pull this off without having a good deal of the blockchain present including some of it pre-programmed in the device at manufacturing. Maybe I'm missing some technique here, I'm all ears.
Re: SIGHASH_WITHINPUTVALUE: Super-lightweight HW wallets and offline data
So what is the process for getting a request like this in front of the development team for an opinion at least? I read up on https://en.bitcoin.it/wiki/BIP_0001#BIP_Work_Flow and it mentions vetting the idea on this forum as a starting point. Who typically chimes in on this sort of thing, and when do we know if it is worth writing up a BIP or not? I'm fairly new to this process, so forgive any naive questions.
Re: SIGHASH_WITHINPUTVALUE: Super-lightweight HW wallets and offline data
If it's so trivial to implement then where is your proposed implementation and BIP? It could be re-implemented fifty times through rejections and objections and still be less work that the true work associated with all the testing, wallet implementations, and alt-implementations associated with this idea.
Anyway, it doesn't simplify offline signing all that much, it just makes it possible with more limited hardware. The actual code is basically the same in both cases. Heck, the design effort required for the hardware isn't much different in most cases: moderately fast USB interfaces aren't a big deal these days and come pre-packaged.
This also encourages the design of really limited hardware wallets that don't support the payment protocol: if you don't know who you are paying, all you've done is limited the rate that your funds can be stolen a bit. Heck, on that basis I think I'd actually NACK such a patch myself...
Anyway, it doesn't simplify offline signing all that much, it just makes it possible with more limited hardware. The actual code is basically the same in both cases. Heck, the design effort required for the hardware isn't much different in most cases: moderately fast USB interfaces aren't a big deal these days and come pre-packaged.
This also encourages the design of really limited hardware wallets that don't support the payment protocol: if you don't know who you are paying, all you've done is limited the rate that your funds can be stolen a bit. Heck, on that basis I think I'd actually NACK such a patch myself...
It definitely simplifies offline signing significantly. With the proposed modification, the HW wallet only has to present the user with a prompt to confirm sending X coins to Y address with Z fee using some number of wallet addresses for which it has the private key. If the transaction that the device is being asked to sign is not what the user expects (including the case of large fee), they reject it. Simple.
As it stands now, the HW wallet has to be able to prove without a doubt the current value of its wallet addresses so that the fee can be properly calculated and presented (or to trigger an auto-reject if the fee is above a threshold). This requires tracking and verifying a large enough chunk of the blockchain to prove this. What's the lightest way a small HW wallet can do this without trusting the SW feeding it transactions to sign? It's something I'm researching right now, but the proposed modification would make this problem irrelevant and cut down development and testing time significantly.
Re: SIGHASH_WITHINPUTVALUE: Super-lightweight HW wallets and offline data
I'll gladly do what is needed to support this proposal, whatever way I can. I wonder what some of the other HW wallet guys are doing (e.g. Trezor)? Probably some form of SPV - but this kind of thing seriously increases the complexity and resource demands of a small HW wallet implementation.
Re: SIGHASH_WITHINPUTVALUE: Super-lightweight HW wallets and offline data
Well, that is quite unfortunate. Thanks for the update, guess I have to go find another way to prevent the 'transaction fee' attack on my wallet...
Re: SIGHASH_WITHINPUTVALUE: Super-lightweight HW wallets and offline data
etotheipi - your original proposal is just the thing I'm looking for and is quite simple and elegant. I was happily implementing my lightweight HW wallet and blundered across this nasty snag just today. Has there been any further development on this front recently?
Re: Deterministic Usage of DSA and ECDSA Digital Signature Algorithms (RFC 6979)
Thanks for the additional vectors
I'd like to contribute some test vectors of my own.
The test vectors are fully canonical signatures with S components <= order/2. They contain both vectors were the S component had to be flipped and not flipped.
The test vectors were generated with haskoin:
http://github.com/plaprade/haskoin-crypto/blob/master/src/Haskoin/Crypto/ECDSA.hs
The project is still experimental and I haven't announced it publicly yet, but the cryptography part should be relatively stable by now.
I hope it can help!
The test vectors are fully canonical signatures with S components <= order/2. They contain both vectors were the S component had to be flipped and not flipped.
Code:
"Haskoin test vectors for RFC 6979 ECDSA (secp256k1, SHA-256)"
"(PrvKey HEX, PrvKey WIF, message, R || S as HEX, sig as DER)"
( "0000000000000000000000000000000000000000000000000000000000000001"
, "KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU73sVHnoWn"
, "Everything should be made as simple as possible, but not simpler."
, "33a69cd2065432a30f3d1ce4eb0d59b8ab58c74f27c41a7fdb5696ad4e6108c96f807982866f785d3f6418d24163ddae117b7db4d5fdf0071de069fa54342262"
, "3044022033a69cd2065432a30f3d1ce4eb0d59b8ab58c74f27c41a7fdb5696ad4e6108c902206f807982866f785d3f6418d24163ddae117b7db4d5fdf0071de069fa54342262"
)
( "fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364140"
, "L5oLkpV3aqBjhki6LmvChTCV6odsp4SXM6FfU2Gppt5kFLaHLuZ9"
, "Equations are more important to me, because politics is for the present, but an equation is something for eternity."
, "54c4a33c6423d689378f160a7ff8b61330444abb58fb470f96ea16d99d4a2fed07082304410efa6b2943111b6a4e0aaa7b7db55a07e9861d1fb3cb1f421044a5"
, "3044022054c4a33c6423d689378f160a7ff8b61330444abb58fb470f96ea16d99d4a2fed022007082304410efa6b2943111b6a4e0aaa7b7db55a07e9861d1fb3cb1f421044a5"
)
( "fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364140"
, "L5oLkpV3aqBjhki6LmvChTCV6odsp4SXM6FfU2Gppt5kFLaHLuZ9"
, "Not only is the Universe stranger than we think, it is stranger than we can think."
, "ff466a9f1b7b273e2f4c3ffe032eb2e814121ed18ef84665d0f515360dab3dd06fc95f5132e5ecfdc8e5e6e616cc77151455d46ed48f5589b7db7771a332b283"
, "3045022100ff466a9f1b7b273e2f4c3ffe032eb2e814121ed18ef84665d0f515360dab3dd002206fc95f5132e5ecfdc8e5e6e616cc77151455d46ed48f5589b7db7771a332b283"
)
( "0000000000000000000000000000000000000000000000000000000000000001"
, "KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU73sVHnoWn"
, "How wonderful that we have met with a paradox. Now we have some hope of making progress."
, "c0dafec8251f1d5010289d210232220b03202cba34ec11fec58b3e93a85b91d375afdc06b7d6322a590955bf264e7aaa155847f614d80078a90292fe205064d3"
, "3045022100c0dafec8251f1d5010289d210232220b03202cba34ec11fec58b3e93a85b91d3022075afdc06b7d6322a590955bf264e7aaa155847f614d80078a90292fe205064d3"
)
( "69ec59eaa1f4f2e36b639716b7c30ca86d9a5375c7b38d8918bd9c0ebc80ba64"
, "KzmcSTRmg8Gtoq8jbBCwsrvgiTKRrewQXniAHHTf7hsten8MZmBB"
, "Computer science is no more about computers than astronomy is about telescopes."
, "7186363571d65e084e7f02b0b77c3ec44fb1b257dee26274c38c928986fea45d0de0b38e06807e46bda1f1e293f4f6323e854c86d58abdd00c46c16441085df6"
, "304402207186363571d65e084e7f02b0b77c3ec44fb1b257dee26274c38c928986fea45d02200de0b38e06807e46bda1f1e293f4f6323e854c86d58abdd00c46c16441085df6"
)
( "00000000000000000000000000007246174ab1e92e9149c6e446fe194d072637"
, "KwDiBf89QgGbjEhKnhXJwe1E2mCa8asowBrSKuCaBV6EsPYEAFZ8"
, "...if you aren't, at any given time, scandalized by code you wrote five or even three years ago, you're not learning anywhere near enough"
, "fbfe5076a15860ba8ed00e75e9bd22e05d230f02a936b653eb55b61c99dda4870e68880ebb0050fe4312b1b1eb0899e1b82da89baa5b895f612619edf34cbd37"
, "3045022100fbfe5076a15860ba8ed00e75e9bd22e05d230f02a936b653eb55b61c99dda48702200e68880ebb0050fe4312b1b1eb0899e1b82da89baa5b895f612619edf34cbd37"
)
( "000000000000000000000000000000000000000000056916d0f9b31dc9b637f3"
, "KwDiBf89QgGbjEhKnhXJuH7LrciVrZiib5S9h4knkymNojPUVsWN"
, "The question of whether computers can think is like the question of whether submarines can swim."
, "cde1302d83f8dd835d89aef803c74a119f561fbaef3eb9129e45f30de86abbf906ce643f5049ee1f27890467b77a6a8e11ec4661cc38cd8badf90115fbd03cef"
, "3045022100cde1302d83f8dd835d89aef803c74a119f561fbaef3eb9129e45f30de86abbf9022006ce643f5049ee1f27890467b77a6a8e11ec4661cc38cd8badf90115fbd03cef"
)
"(PrvKey HEX, PrvKey WIF, message, R || S as HEX, sig as DER)"
( "0000000000000000000000000000000000000000000000000000000000000001"
, "KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU73sVHnoWn"
, "Everything should be made as simple as possible, but not simpler."
, "33a69cd2065432a30f3d1ce4eb0d59b8ab58c74f27c41a7fdb5696ad4e6108c96f807982866f785d3f6418d24163ddae117b7db4d5fdf0071de069fa54342262"
, "3044022033a69cd2065432a30f3d1ce4eb0d59b8ab58c74f27c41a7fdb5696ad4e6108c902206f807982866f785d3f6418d24163ddae117b7db4d5fdf0071de069fa54342262"
)
( "fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364140"
, "L5oLkpV3aqBjhki6LmvChTCV6odsp4SXM6FfU2Gppt5kFLaHLuZ9"
, "Equations are more important to me, because politics is for the present, but an equation is something for eternity."
, "54c4a33c6423d689378f160a7ff8b61330444abb58fb470f96ea16d99d4a2fed07082304410efa6b2943111b6a4e0aaa7b7db55a07e9861d1fb3cb1f421044a5"
, "3044022054c4a33c6423d689378f160a7ff8b61330444abb58fb470f96ea16d99d4a2fed022007082304410efa6b2943111b6a4e0aaa7b7db55a07e9861d1fb3cb1f421044a5"
)
( "fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364140"
, "L5oLkpV3aqBjhki6LmvChTCV6odsp4SXM6FfU2Gppt5kFLaHLuZ9"
, "Not only is the Universe stranger than we think, it is stranger than we can think."
, "ff466a9f1b7b273e2f4c3ffe032eb2e814121ed18ef84665d0f515360dab3dd06fc95f5132e5ecfdc8e5e6e616cc77151455d46ed48f5589b7db7771a332b283"
, "3045022100ff466a9f1b7b273e2f4c3ffe032eb2e814121ed18ef84665d0f515360dab3dd002206fc95f5132e5ecfdc8e5e6e616cc77151455d46ed48f5589b7db7771a332b283"
)
( "0000000000000000000000000000000000000000000000000000000000000001"
, "KwDiBf89QgGbjEhKnhXJuH7LrciVrZi3qYjgd9M7rFU73sVHnoWn"
, "How wonderful that we have met with a paradox. Now we have some hope of making progress."
, "c0dafec8251f1d5010289d210232220b03202cba34ec11fec58b3e93a85b91d375afdc06b7d6322a590955bf264e7aaa155847f614d80078a90292fe205064d3"
, "3045022100c0dafec8251f1d5010289d210232220b03202cba34ec11fec58b3e93a85b91d3022075afdc06b7d6322a590955bf264e7aaa155847f614d80078a90292fe205064d3"
)
( "69ec59eaa1f4f2e36b639716b7c30ca86d9a5375c7b38d8918bd9c0ebc80ba64"
, "KzmcSTRmg8Gtoq8jbBCwsrvgiTKRrewQXniAHHTf7hsten8MZmBB"
, "Computer science is no more about computers than astronomy is about telescopes."
, "7186363571d65e084e7f02b0b77c3ec44fb1b257dee26274c38c928986fea45d0de0b38e06807e46bda1f1e293f4f6323e854c86d58abdd00c46c16441085df6"
, "304402207186363571d65e084e7f02b0b77c3ec44fb1b257dee26274c38c928986fea45d02200de0b38e06807e46bda1f1e293f4f6323e854c86d58abdd00c46c16441085df6"
)
( "00000000000000000000000000007246174ab1e92e9149c6e446fe194d072637"
, "KwDiBf89QgGbjEhKnhXJwe1E2mCa8asowBrSKuCaBV6EsPYEAFZ8"
, "...if you aren't, at any given time, scandalized by code you wrote five or even three years ago, you're not learning anywhere near enough"
, "fbfe5076a15860ba8ed00e75e9bd22e05d230f02a936b653eb55b61c99dda4870e68880ebb0050fe4312b1b1eb0899e1b82da89baa5b895f612619edf34cbd37"
, "3045022100fbfe5076a15860ba8ed00e75e9bd22e05d230f02a936b653eb55b61c99dda48702200e68880ebb0050fe4312b1b1eb0899e1b82da89baa5b895f612619edf34cbd37"
)
( "000000000000000000000000000000000000000000056916d0f9b31dc9b637f3"
, "KwDiBf89QgGbjEhKnhXJuH7LrciVrZiib5S9h4knkymNojPUVsWN"
, "The question of whether computers can think is like the question of whether submarines can swim."
, "cde1302d83f8dd835d89aef803c74a119f561fbaef3eb9129e45f30de86abbf906ce643f5049ee1f27890467b77a6a8e11ec4661cc38cd8badf90115fbd03cef"
, "3045022100cde1302d83f8dd835d89aef803c74a119f561fbaef3eb9129e45f30de86abbf9022006ce643f5049ee1f27890467b77a6a8e11ec4661cc38cd8badf90115fbd03cef"
)
The test vectors were generated with haskoin:
http://github.com/plaprade/haskoin-crypto/blob/master/src/Haskoin/Crypto/ECDSA.hs
The project is still experimental and I haven't announced it publicly yet, but the cryptography part should be relatively stable by now.
I hope it can help!
Re: Deterministic Usage of DSA and ECDSA Digital Signature Algorithms (RFC 6979)
Ok. I was seeing it as insurance against faulty PRNGs. Hardware wallets are always going to have a problem in ensuring the private keys are generated ok anyway.
But if you did want to check the signing nonce would it be possible to pre-generate a file of random numbers, store them on the wallet and give them to the purchaser of the wallet in a file or online, then deterministically generate the number and add the next number from the random number file and reduce mod n and sign with this?
But if you did want to check the signing nonce would it be possible to pre-generate a file of random numbers, store them on the wallet and give them to the purchaser of the wallet in a file or online, then deterministically generate the number and add the next number from the random number file and reduce mod n and sign with this?
Sure, I suppose you could do this. However, its probably easier to do the following if your wallet is conforming to BIP 32 and using RFC 6979 for signing:
1. User generates their own master seed
2. User, with software running on their own computer, generates N keys using BIP 32 and the seed from step 1 and signs a bunch of test transactions using these keys.
3. User loads your HW wallet with the master seed from step 1
4. User asks your wallet to sign the same test transactions they did in step 2.
5. User compares his local signatures with the ones generated by you, if they match - your wallet is working as expected without any code review needed.
Now, the normal user will generate a master seed based on input from the user plus randomness from your device. This seed is displayed only on your devices screen so it never leaves the device. The user could then, if they so chose, repeat steps 2,4,5 on a secure computer to again verify your wallet was 100% doing as they expected.
This is what I plan on doing for my device. I think its pretty solid. And I don't buy the argument that you need 'insurance' by adding randomness to RFC 6979 - if you think you need to do that aren't you saying you don't trust that SHA-256 is truly a 1-way trapdoor function with no fast way to brute force it? If you believe that then there are alot more problems in the Bitcoin protocol itself which relies on SHA-2 for alot of things.
I'm happy to be proven wrong if anyone finds something bad about my logic above
Re: Deterministic Usage of DSA and ECDSA Digital Signature Algorithms (RFC 6979)
This is all well and good - yes it works just fine. However as I understand it, it spoils the benefits of having a 3rd party entity be able to *exactly* reproduce your signatures to verify that your HW device is not doing anything dumb when generating said signatures. This gives them confidence that your HW wallet is not leaking information about private keys through sub-par 'random' number generation.
What would be the disadvantage of deterministically generating k each time and then multiplying by a PRNG generated number and reducing mod n and use this to sign?
Wouldn't you get protection against the failure of either method this way?
Wouldn't you get protection against the failure of either method this way?
Re: Deterministic Usage of DSA and ECDSA Digital Signature Algorithms (RFC 6979)
Wow, thanks for posting your 'microecdsa' code - now I get to see how what I came up with stacks up to your version
Couple questions:
Is the algo you created resistant to side-channel attacks (constant time for doing the scalar multiply)?
Can you give me any insights/references into your 'PRECOMPUTED_CP/IV' technique?
Couple questions:
Is the algo you created resistant to side-channel attacks (constant time for doing the scalar multiply)?
Can you give me any insights/references into your 'PRECOMPUTED_CP/IV' technique?
Last news about DRBG: http://en.wikipedia.org/wiki/Dual_EC_DRBG#Controversy 
Btw, slush and I are trying to implement RFC6979 into python-ecdsa/microecdsa. Hopefully we'll publish the results soon (or watch https://github.com/trezor/python-ecdsa and https://github.com/trezor/microecdsa repos).
Btw, slush and I are trying to implement RFC6979 into python-ecdsa/microecdsa. Hopefully we'll publish the results soon (or watch https://github.com/trezor/python-ecdsa and https://github.com/trezor/microecdsa repos).
The rules of the game until now had been: we work with the NSA through NIST competitions to standardize cryptography. The NSA continues to collect the intelligence it needs through exploiting side channels, weak random number generators, bugs, and even strong-arm techniques, but the algorithms are secure. You can trust the math.
These new revelations apparently throw that out the window. In recent years the NSA actively pushed NIST for standards that it knew were insecure.
...
EDIT: gmaxwell, was the algorithm for parameter selection published? If so, I must have missed this.
These new revelations apparently throw that out the window. In recent years the NSA actively pushed NIST for standards that it knew were insecure.
...
EDIT: gmaxwell, was the algorithm for parameter selection published? If so, I must have missed this.
This is the key revelation to me as well. It seems that the trust in the parameters chosen for the various curves must be questioned at this point. Does anyone have a history of how our secp256k1 curve parameters were chosen, by whom, and by what process it was tested to give it a 'recommended curve' stamp of approval? It is just a curiosity for me - the point that the Bitcoin framework allows for a substitution of signing technique is noted and understood in the event that a flaw was discovered in our curve, or techniques to accelerate cracking ECC itself were discovered.
⭐ Merited by ETFbitcoin (1)
Ok, so your take is basically the same as the commenter on Schneier's blog (https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html#c1678526).
Basically he says what you are saying - that a recommended 'random' number generator for use with ECC has been proven to have backdoors, and that some families of ECC curves have weaknesses. However, because we're using secp256k1, a known curve with explainable/justifiable constants, the concern cited by Bruce is not applicable to Bitcoin in addition to the weak motivation for attacking it anyhow.
Thanks for the reply.
Basically he says what you are saying - that a recommended 'random' number generator for use with ECC has been proven to have backdoors, and that some families of ECC curves have weaknesses. However, because we're using secp256k1, a known curve with explainable/justifiable constants, the concern cited by Bruce is not applicable to Bitcoin in addition to the weak motivation for attacking it anyhow.
Thanks for the reply.
I've been reading up recently on the revelations that the NSA is subverting implementations/service providers to undermine various internet crypto standards (see this: http://www.theguardian.com/world/2013/sep/05/nsa-gchq-encryption-codes-security).
Now this has all of the basic hallmarks of a 'scare campaign' where people are led to believe that crypto techniques/mathmatics themselves are insecure rather than the truth that the NSA is attacking the services or implementations directly (much easier). Therefore I was ready to write this off as 'not relevant' to an open source peer reviewed protocol like Bitcoin.
However, something Bruce Schneier (someone intimately familiar with the mathematics behind crypto algorithms) said has given me some concern. He is suggesting that the ECC constants have been manipulated to facilitate subversion (see his blog comment here: https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html#c1675929). For his full essay, go here: https://www.schneier.com/essay-446.html.
Any thoughts on implications here we need to be concerned about?
Now this has all of the basic hallmarks of a 'scare campaign' where people are led to believe that crypto techniques/mathmatics themselves are insecure rather than the truth that the NSA is attacking the services or implementations directly (much easier). Therefore I was ready to write this off as 'not relevant' to an open source peer reviewed protocol like Bitcoin.
However, something Bruce Schneier (someone intimately familiar with the mathematics behind crypto algorithms) said has given me some concern. He is suggesting that the ECC constants have been manipulated to facilitate subversion (see his blog comment here: https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html#c1675929). For his full essay, go here: https://www.schneier.com/essay-446.html.
Any thoughts on implications here we need to be concerned about?
Thanks much for that video reference, its a handy addition to BIP 0032 and helps flesh out some of the motivations behind the scheme. I am also creating a HW wallet prototype and am happily using BIP 0032 as my foundation for key generation. I appreciate the python implementation as it's a great check and reference.
One thing I've heard a bit about is BIP "0032.5" - could you comment on the motivations for this and what the key differences with BIP 0032 are - or maybe point me to a draft version of this that I can read? Thanks!
One thing I've heard a bit about is BIP "0032.5" - could you comment on the motivations for this and what the key differences with BIP 0032 are - or maybe point me to a draft version of this that I can read? Thanks!
There is a lot of additional documentation for BIP32 in addition to the BIP itself:
For example, http://www.youtube.com/watch?v=WcnMjkc31Fs
I'm disappointed that this is the first time I've heard your complaints. It has now been independently implemented by at least four parties. Your feedback sounds good though, do you have any proposed revised text? (And indeed, your understanding is correct).
The motivation there is that the ECC homomorphism based public derivation has that highly surprising backwards enumeration property. In some use-cases it could easily cause a total loss. E.g. I export a private key from my wallet and give it to you, and you already have the extended key for that chain for auditing... oops now you have all the coins on that chain.
The text on that is a bit weaker because we added it later... we'd hoped for a while that there would be a way to remove that property but couldn't find one. The auditing behavior still exists, but works only in publicly derived chains.
Some client software may choose to only use public derivation, thus facilitating auditing. If they do they should probably avoid offering key export function for single private keys, simply because it has turned out to be really hard to educate users about the exposure.
For example, http://www.youtube.com/watch?v=WcnMjkc31Fs
I'm disappointed that this is the first time I've heard your complaints. It has now been independently implemented by at least four parties. Your feedback sounds good though, do you have any proposed revised text? (And indeed, your understanding is correct).
The motivation there is that the ECC homomorphism based public derivation has that highly surprising backwards enumeration property. In some use-cases it could easily cause a total loss. E.g. I export a private key from my wallet and give it to you, and you already have the extended key for that chain for auditing... oops now you have all the coins on that chain.
The text on that is a bit weaker because we added it later... we'd hoped for a while that there would be a way to remove that property but couldn't find one. The auditing behavior still exists, but works only in publicly derived chains.
Some client software may choose to only use public derivation, thus facilitating auditing. If they do they should probably avoid offering key export function for single private keys, simply because it has turned out to be really hard to educate users about the exposure.
Most consumers, in the long run, will be fine running SPV clients. The network will still be decentralized as many businesses will want to run a full node in order to be able to directly verify transactions.
Yes I think this is a fair point. I have not studied the network side of Bitcoin much - is there any way to know how many full nodes are running at any one time?
Use an SPV wallet like MultiBit. It requires very little in the way of blockchain storage and sync time.
I agree that this is a viable solution, but then again it makes Bitcoin less distributed. The nice thing about running a full Bitcoin node is that you are one of the voices in the network contributing your say to what chain is legit and what chain is not. If everyone is running wallets across only a few 'trusted' servers we lose this awesome feature of Bitcoin.
As a practical matter, solving the blockchain length is an important one IMHO. I don't yet have any ideas to contribute to solving this.
Re: What are your thoughts on programming with COMMON LISP,SCHEME?
I think if you are looking to write self-modifying (adaptive) code, I don't think doing anything on the Bitcoin transaction/mining level is interesting problem for this type of programming. Bitcoin transactions are bound by a known set of rules, and the core problem of generating blocks in mining revolves around using brute force to get a certain hash output.
I think the most interesting place for adaptive algorithms is in a trading application. Having your program attempt to 'learn' any patterns that may exist in Bitcoin trading is an interesting problem - and one that is also very applicable to the stock market as well not just Bitcoin.
I think the most interesting place for adaptive algorithms is in a trading application. Having your program attempt to 'learn' any patterns that may exist in Bitcoin trading is an interesting problem - and one that is also very applicable to the stock market as well not just Bitcoin.