Has there been no interest from wallet implementers in a possible span parameter: e.g. "this key has addresses assigned out to position X?"
For sure. I am hoping for this evolving more into a description of the wallet, not just the master key seed. Master key birth is the first step. The next would be topology of the tree (again with births) from this root and highest address used on the leafs. |
|
|
|
Hm. Why are such weak KDFs supported? Considering that you can now obtain specialized crackers for bc.i wallets that do ~10m passwords per second on a gpu, I'm a little more concerned about the systemic risk of weak KDFs than I was before.
Scrypt on typical Android mobile is hardly able to run with more than 2^14/8/8 Since key birth is added, this became an interesting BIP. I consider supporting it as master backup format for the BeBop wallet. |
|
|
|
The nonce is only 32 bits; could there come a day with the difficulty is high enough that no nonce works?
This was solved at least a year ago. The nonce is exhausted in sub-second at a miner working faster than 4 GH/s, but one can step the create time of the block and also alter the block by including new transactions. Actually having a small nonce incentives including new transactions to alter the hash. |
|
|
|
I fully realize trailing 0's are no more interesting than any other arbitrary sequence but Satoshi started it with his leading 0's. Why not leading 1's? Why not a leading sequence of 3.1415926535...? No, the cat is out of the bag.
Mining blocks is not about constructing a block hash with leading zeros, but a hash numerically less than a target number. Leading zeros in the hash are just the consequence of that target being less and less with increasing difficulty. Difficulty is the ratio of initial/current target. |
|
|
|
If you have a solid hash function (which SHA256 is) and you come across a collision, then either:
(1) SHA256 is broken
(2) You hashed two things that were identical
End of story.
Not doubting this, just curious what the actual math is convincing you that SHA256 is solid. Do you have a pointer? |
|
|
|
|
Is a cake using BOP API. You might even register a listener for the address.
|
|
|
|
I wrote one of the Java implementations that is also listed on the BIP page. If this is the one you refer to, then please elaborate on the bugs. I just finished a more detailed look at the code. There were only two bugs, both pedantic in nature. The rest of the code looks fine to me. Thanks for the audit. Since the "rest of the code" does the work in practically all cases, I think it is fine. I will add an exception checking the max depth and 0. |
|
|
|
I would, however, argue for better reference implementations (code is gospel). I found the Python one rather confusing. The Java one isn't bad, but it suffered from a few bugs at first glance.
I wrote one of the Java implementations that is also listed on the BIP page. If this is the one you refer to, then please elaborate on the bugs. |
|
|
|
More likely someone had the wrong assumption on the value of a referred output. These errors would be avoided by implementing SIGHASH_WITHINPUTVALUE https://bitcointalk.org/index.php?topic=181734.0 How many people need to burn themselves until we add this? Remembers me the history of introducing wallet encryption. |
|
|
|
If the generator is broken no operator will make it better. Feed a shifted pattern to | and see an other sort of disaster.
Agreed, but it's still important to prefer an operator that won't make it worse over one that will. do not get your point. xor is not worse than or since none of them add any value in this context. |
|
|
|
Thanks a lot for the great input, I summarize just the points that remember me to the details. pro Bitcoin - lower costs for customer and merchant
- independent proof of payment
- infrastructure suitable for interbank settlement
- separates technology and dispute resolution
- auditable transaction record for ever
- assurance contracts
- complementary use (donations, kids, oversees remittance)
- be your own bank
against Credit Cards - chance of identity theft
- chargebacks for merchants
- third party in the transaction
- geopolitical restrictions
- was not meant for the internet, card not present transactions were not intended
- fraud
Do you have a link to what "al-Qaeda learns carding" refers to? Other useful links like below I collected from earlier forum posts? http://www.pcpro.co.uk/news/383680/instagram-likes-worth-more-than-stolen-credit-cardshttp://www.fortmilltimes.com/2013/08/19/2898687/global-credit-debit-and-prepaid.html |
|
|
|
|
I am invited to join a panel discussion with local managing directors of MasterCard and Visa at a high profile Finance IT forum on 19. September.
Please feed me any arguments and facts with links you think would be helpful to make Bitcoin shine in comparison. Thanks in advance.
|
|
|
|
I was referring to seeded random generators f(xor(A,B)) versus f(A|B). With an ideal function, it shouldn't matter. With a broken one, it might matter.
With a broken one, you're much better off with f(A|B) than f(xor(A,B)). If A and B have too many bits in common, the xor is a disaster. If the generator is broken no operator will make it better. Feed a shifted pattern to | and see an other sort of disaster. |
|
|
|
|
as of 1.2 the relational schema is no longer part of the community version, but moved to the audit server.
|
|
|
|
I'm very skeptical when people claim Bitcoin will bring about a massive social revolution, or that governments can't control it. Satoshi explicitly disavowed such a claim and I agree with him.
Yes, Bitcoin merely redistributes some riches from those who got lazy and trust their lobby to those who are innovative and trust their math. The US Government can terminate Bitcoin globally, if it so chooses, which is why extensive lobbying is so essential. It really lives or dies at the whims of some congressmen.
I doubt they could achieve more than a few years of setback. I trust that there are congressmen who recognize, that this is a chance of redistributing on Wall Street, and would love to see that happen. If that's their grand plan to undermine crypto, then they suck at it.
 Hope you are right. |
|
|
|
|
It is known that the NSA employs a lot of bright guys, who certainly not only work on breaking code but also on how to prevent strong code in the first place.
A subtly but still seriously flawed PRNG planted into major operating systems could be a masterpiece of their effort.
It does not need complacency of Google to happen, just brilliance and social engineering on the other side.
|
|
|
|
Suffice it to say the failure was subtle. It isn't something easily found via code inspection.
Sounds like a sophisticated backdoor. The NSA doesn't need to engage in monkey tricks anyway, they can just go pressure the providers that most people use or hack the endpoints and circumvent encryption entirely.
This is the first time you do not embrace encryption as a solution for a problem. |
|
|
|
And wouldn't that expose data encrypted by other apps to similar security issues?
No. The issue has nothing to do with exposing encrypted data but with signatures exposing private keys. In contrary, this is a much bigger issue. The Android PRNG must be extremely weak (say a joke) that this surfaced in the insignificant number of keys android wallets repeatedly used. Encryption software usually use a key generated with PRNG, so do secure communication protocols. Pass phrases and asymmetric algorithms often only encrypt that pseudo random key. It is the pseudo random key that is really the secret, and is protecting the data. Knowing the weakness of the PRNG makes brute forcing of encryption feasible since key space in question is reduced to a joke. Therefore yes, a lot of encrypted data and communication (that was recorded in the past) is potentially affected by this "bug". We will never know if it was gross negligence or NSA compliant engineering at work. |
|
|
|
|
Show Posts
