Bitcoin Forum
March 31, 2015, 05:25:04 AM *
News: Latest stable version of Bitcoin Core: 0.10.0 [Torrent] (New!)
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 ... 195 »
1  Bitcoin / Development & Technical Discussion / Re: trustless address lookup for thin-clients on: March 30, 2015, 04:17:38 PM
There is a recent study showing an attack that exploits the way bitcoin core handles addr messages and chooses peers.
That particular work is irrelevant here, Bitcoin core is intrinsically safe against the attacks this poster is describing. What SPV nodes do to different (and usually inherently less safe).
2  Alternate cryptocurrencies / Altcoin Discussion / Re: XMR vs DRK on: March 29, 2015, 06:45:16 PM
Cryptography has never been a significant part of cryptocurrency - even though it may share the first few letters. It works on a system of digital signatures.
It would seem that you actually do not understand what cryptography is in the modern sense.

A fundamental nature of information is that it wants to be freely copied everywhere to everyone. That any bit is equal and indistinguishable from any other bit of the same value and that any bit is eventually known to all who care.  Cryptography is all that technology by which we hope to confine and constrain the nature of information, to put up fences and direct it to our exclusive purposes, against all attacks and in defiance of the seemingly (and perhaps actually) impossible.  Digital signatures are cryptography by any modern definition and utilize the same tools and techniques (for example, a DSA signature is a linear equation encrypted with an additively homorphic encryption), and suffer from most of the same challenges as the message encryption systems to which you seem to be incorrectly defining cryptography as equivalent.  Moreover, the use of digital signatures isn't the only (or even most relevant) aspect of cryptography in cryptocurrencies-- e.g. the prevention of double spending of otherwise perfectly copyable and indistinguishable information in a decentralized system is a cryptographic problem which we address using cryptographic tools, and-- like all other practical cryptography-- achieve far less than perfect confidence in our solution. As are more modest ends like interacting with strangers but not being subject to resource exhaustion from them.

Far more so than other sub-fields of engineering, cryptographic systems are doing something which is fundamentally at odds with nature and share an incredible fragility and subtly as a result (and perhaps all are failures, we have no proof otherwise).

A failure to understand and respect these considerations has resulted in a lot of harmful garbage and dysfunctional software.
3  Bitcoin / Development & Technical Discussion / Re: Thinking about ways to make it more difficult to link IP address to txn creator. on: March 29, 2015, 04:15:34 PM
Actually, it seems the vulnerability has already been identified in 2013:
That isn't what Cryddit is describing at least not precisely, and of course that was fixed years ago. (The 97% thing is just because there are long forgotten nodes left running on old software that no one maintains; they likely don't have wallets.)

I don't believe Cryddit is correct; but his description isn't precise enough for me to tell for sure.  I /think/ what he's saying is that I first tell all nodes a dust output that nodes won't mempool and likely won't get mined, then later I give nodes a transaction spending that transaction with an invalid signature. To most nodes this second transaction will be an orphan (spends an input they don't know about).  But Cryddit believes the recipient of the transaction will DOS ban you.   I think this is incorrect: first, if the transaction was mempool rejected then it wouldn't end up in their wallet unless it gets mined (in which case it would be available in the utxo set to all nodes), secondly even if it was in their wallet the wallet is not consulted for lookups on incoming transactions.  But perhaps Cryddit would be kind enough to clarify his thinking?

There are ways we know those dust txn could be used to reduce users' privacy though... send them to nodes that don't implement a dust check and then observe them rebroadcasting them when they don't get mined for a long time. This is part of why the anti-dust rules were implemented.
4  Bitcoin / Development & Technical Discussion / Re: BIP39 mnemonics: checksum vs plausible deniability on: March 28, 2015, 03:09:00 AM
Which has nothing to do with the claimed lack of deniability.  
Are you having a bad day? Your message seems needlessly antagonistic. (Edit: Ah you edited your post. ... OKAY, yea, tone can be hard to convey.)

That particular flaw is only somewhat related to deniability, although it's not unrelated.  Please refer to the prior conversion, I remarked that the specification was largely designed as a brainwallet scheme as one of the general negatives against it. You claimed this was inaccurate, assuming a particular model of use which is intentionally not mandatory, I clarified.

Say there exist two Bitcoin Core wallets encrypted with the same passphrase.  Can anyone use their keys to prove that they are linked? _No_. Any existing wallet you have the private keys for can be encrypted with any passphrase. There is no linkage created by using a particular storage scheme. Even to whatever extent that someone way convinced you were the owner of both because they personally found you in possession of two wallet files and the key,that proof isn't transferable-- they could have fabricated that evidence themselves.

Now say there exist two BIP39 wallets sharing a mnemonic or sharing a password. Can anyone use their keys and the mnemonic data to prove that they are linked? Yes.  Because BIP39 generates a key using a one way function instead of encrypting a uniform value with (a requirement for working with short user generated strings), all usage of the same data will be linked. It may be surprising to people that using this facility (which, at best, only protects against fringe threats of the sort that one probably ought not worry about)  can leave them more exposed to other fringe threats.  It could be called 'denyable' relative to a single wallet for everything, but it's very much less denyable than two totally separate wallets, or two wallets encrypted with the same passphrase.  Likewise, its not possible to rotate your passphrase if you're concerned that it might have leaked... not without expiring all the keys (for which no facility really exists in the Bitcoin space if you've given any of those keys out).

The actual scheme here prevents the non-linkable usage even when used perfectly, because it's not possible to take a random unrelated private key and convert it into a mnemonic in this scheme; so the bad use by people actually does have an effect on everyone else. (Except by not using the 'deniability' feature at all and just keeping two totally separate wallets)

Stated another way; Absent the brainwallet anti-feature it's possible to have a scheme where a mnemonic exists and is easily computable for any combination of password and private key, and in such a scheme the existence of a mnemonic, password, and pair of keys does not automatically undeniably prove their linkage. You can't have that in a scheme which is designed to not need any persistent storage, however.  Probably not a big deal, but enough that I think its a bit sad and ironic to see people use something to gain the 'feature' of denyability when they would be better off not using it; the feature should probably be called "multiple wallets with less written down", which may well be interesting to people-- but probably an entirely non-overlapping set of people. Smiley
5  Bitcoin / Development & Technical Discussion / Re: BIP39 mnemonics: checksum vs plausible deniability on: March 28, 2015, 02:40:07 AM
The comparison to brainwallet is inaccurate.  Would you call bitcoin core's encrypted wallet a brainwallet?  Of course not unless you stretch the definition to the point of being silly.
You misunderstand. The lack of checksum enforcement on the mnemonic means that many people directly use the 'mnemonic' as a "brainwallet". The suggested uniform mnemonic encoding approach is completely non-normative. (This was an intentional design feature, and at one point a draft of the BIP basically advocated the usage; this was a quite controversial proposal, if you may note some of its former authors even had their names removed from it due to disputes about the construction; the state of the BIP was as far as the community was able to push the remaining authors away from that kind of dangerous construction; but its still possible to use it that way and many people do).
6  Bitcoin / Development & Technical Discussion / Re: BIP39 mnemonics: checksum vs plausible deniability on: March 28, 2015, 12:10:42 AM
However, gmaxwell suggests that it is unreasonable to assume such ineffectiveness on the part of the ninjas and, once the secret master key is revealed, absurd for the suspect (after already admitting to owning the dummy wallet) to claim that the secret wallet is not his.
Just so.

Quote
I see nothing in the details which makes it weaker than a hypothetical KDF...
Nor do I.  The PBKDF2 looks technically sound to me (assuming the choice of a sound hash function) but then again I'm not a cryptographer.  I really don't know what gmaxwell was driving at with the "woefully weak KDF" comment.
The intensity of the PBKDF2 at 2048 iterations is almost completely ineffectual, it's likely not worth the code/implementation complexity.

For comparison, on my laptop bitcoin core chooses about 200,000 iterations for its wallet encryption (it dynamically picks a number that takes 100ms to decode)-- and it only uses one core (if we redo wallet encryption in a new format we'll be sure to fix that).

Part of it is because the application space of  BIP39 is unclear. If the keys are chosen securely then there is no gain from having a KDF (and no real harm in having a weak one, except for code complexity). If people use it like a brainwallet then given what we know about how users choose "random secrets" then the KDF is seriously inadequate; considering the infrequency of use and the huge attacker advantages (precomputation because brainwallet schemes cannot be effectively salted, and hardware advantages) you'd likely want something that takes several seconds on the best hardware the user has access to.

7  Bitcoin / Development & Technical Discussion / Re: Adding points on an Elliptic curve on: March 27, 2015, 10:41:59 AM
I see at least one error in your addition implementation (I can point it out if you really want, but I think if your goal is to learn, you will learn more if I don't; if your goal is to get something working I suggest rethinking your goal)..., What are you trying to accomplish?  If you want to make an implementation to actually use your approach (kludging together a result from semi-tech popular press books, rather than stepping back and understanding first principles) will be horrifyingly slow and likely end up broken or insecure.

If you're just trying to learn, you should probably step back and work on each component one at a time so you know exactly where your error is, and so you can gain some understanding. E.g. write tests for your field multiplies, field adds, write a test for your modular inverse (try lots of numbers, invert and multiply by itself to check the identity).  You don't necessarily have to have the answers to check against... check the algebraic identities.  e.g., for points:

A = G + G
B = A + G
C = B + G
D = C + G
B == D + -A
D == B + A
A == C + -A
A + C  == B + B
Infinity = C + -C.
A + D + -A == -D + D + D
... and so on.

Though it's perfectly possible to build a correct implementation with no known value vectors; if you really want them I would suggest I suggest installing (or getting web access to) sage (sagemath), as it has a fine implementation of elliptic curves on finite fields and can easily be used as a 'pocket calculator' to check your results: E.g.

sage: F = FiniteField (0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F)
sage: C = EllipticCurve ([F (0), F (7)])
sage: G = C.lift_x(0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798)
sage: G
( 55066263022277343669578718895168534326250603453777594175500187360389116729240 : 32670510020758816978083085130507043184471273380659243275938904335757337482424 : 1)
sage: G+G
( 89565891926547004231252920425935692360644145829622209833684329913297188986597 : 12158399299693830322967808612713398636155367887041628176798871954788371653930 : 1)
sage: G+G+G
(112711660439710606056748659173929673102114977341539408544630613555209775888121 : 25583027980570883691656905877401976406448868254816295069919888960541586679410 : 1)
sage: 8675309*G
( 66641067246008511739397675128206923493293851901978595085468284019495272794983 : 22882405661336615738255795181502754819791112635438119114432507482219105379189 : 1)
sage: 8675309*G*0x5363ad4cc05c30e0a5261c028812645a122e22ea20816678df02967c1b23bd72
(102906664656524967437285391368203362606397786797828404077808951036579554576623 : 22882405661336615738255795181502754819791112635438119114432507482219105379189 : 1)
sage: 8675309*G*0x5363ad4cc05c30e0a5261c028812645a122e22ea20816678df02967c1b23bd72^2
( 62036446572098911670458903520965529606848330631474128915637932959742841971720 : 22882405661336615738255795181502754819791112635438119114432507482219105379189 : 1)
sage: 8675309*G*0x5363ad4cc05c30e0a5261c028812645a122e22ea20816678df02967c1b23bd72^3
( 66641067246008511739397675128206923493293851901978595085468284019495272794983 : 22882405661336615738255795181502754819791112635438119114432507482219105379189 : 1)

Though there are other high quality implementations of secp256k1 in C, ... since you seem comfortable using a C derived language, why not just use another implementation to get your test cases?
8  Bitcoin / Development & Technical Discussion / Re: BIP39 mnemonics: checksum vs (im)plausible deniability on: March 27, 2015, 09:55:33 AM
Example:

You've got a "deniable" mnemonic written down, with a few bitcents in it.

The 'real' wallet is a word or two changed from what you've written down.

Ninjas bust in your doors and demand your keys. They find the mnemonic and aren't impressed by your cover-- they found your house due to your purchases at their dry cleaning cover operation and their records show you have hundreds of coins and transactions not reflected in the wallet they've found.

They torture you-- as ninjas are known to do-- but somehow you resist the lead pipe cryptanalysis.  Unfortunately for you, they also own a laptop computer with a fast gpu an in a fraction of a second they've found your other wallet just by searching a few billion nearby keys; alternatively they turn on your computer and find the missing word(s) in your swap file (most (if not all) BIP39 implementations have no ability to mlock their memory), or they find it loaded into some 'hardware wallet' and defeat the pitiful physical security with a flick of a jtag enabled throwing star.

Now they have your secret stash, you think: oh well, you're not worse off that if you hadn't used the deniability... But actually:

They tell you the penalty for the anti-ninja sources of funds they find in that wallet is death-- you plead "No, that wallet must be my _evil inlaws_, not mine!" but your claim isn't just implausible, it's absurd. The partial mnemonic is in your handwriting; weakly you protest "I'll tell the ninja overlord that you made me write it!" but there is no chance another randomly selected key maps to a mnemonic that anyone could possibly ever find, so the overlord will know both of those addresses started with the (same) mnemonic and couldn't have been produced the other way around. The first 'cover' one was well linked to your identity-- in your effort to make the cover more plausible you made the (undeniably) linked sibling more undeniable linked to you.

If instead the attempt at deniability were implemented as a difference between two keys and coded bijectively, using keyed permutations instead of hashing, such that for any pair of keys there was some set of words that encoded the difference between them; the story would still be sad (because the ninjas will likely run of of patience before you finish your cryptographic explanation) but perhaps less so-- they really could have picked any two random addresses, computed the linking words between them, and coerced you to write them down; perhaps your plea to the overlord would be heard. Smiley

Realistically, the deniability is operational security theater in any case. Virtually no users manage, nor does the software they use really support, operating with the kind of incredible fastidiousness required to sustain any level of real deniability against scrutiny stronger than a bored child. Preventing information leakage is insanely hard, far more so than most give it credit.  I shouldn't complain, stunts like this (and software that encourages it) results in many more coins being lost then they could possibly protect for theft. Everyone elses Bitcoins become more valuable as a result, ... hurray, I guess?   ::shrugs:: I protest a bit just because it's weird to see something called 'deniable' when its so undeniably linked to its sibling once you do know all of them.

Effectively BIP39 is a thinly veiled brainwallet scheme with a woefully weak KDF. It's prone to misuse, and when misused it picks up all the bad properties you might expect it to pick up.
9  Bitcoin / Development & Technical Discussion / Re: BIP39 mnemonics: checksum vs plausible deniability on: March 27, 2015, 07:01:04 AM
That deniability is less strong than you (and others) think.

Assume I do recover the full mnemonic (e.g. from sniffing if off your computer). Because the mapping is one way (it's not an efficiently computable bijection) I can trivially prove that all the private keys that I do happen to know of are all linked to (and derived from) the same mnemonic (fragment).
10  Bitcoin / Development & Technical Discussion / Re: Checklocktimeverify on: March 27, 2015, 06:56:43 AM
Just saw this, i think it's amazing. I'm wondering what it wasn't included in version 0.10.x?

https://github.com/bitcoin/bitcoin/compare/master...petertodd:checklocktimeverify
Because it's not a finished proposal according to its author (and it was created too late for 0.10 in any case.)
11  Bitcoin / Development & Technical Discussion / Re: Will dynamic libraries of libconsensus and secp256k1 be distributed ? on: March 25, 2015, 08:36:43 PM
IIRC, only a very small portion of the consensus code is actually in the library right now. Quite a bit of work remains to be done to make it robust enough to deploy elsewhere.
Right and the API may well change, etc.   The current progress is just the first step.
12  Bitcoin / Development & Technical Discussion / Re: Will dynamic libraries of libconsensus and secp256k1 be distributed ? on: March 25, 2015, 05:34:48 PM
Eventually.

Libsecp256k1 is not used for Bitcoin consensus currently and is not yet suitable.
13  Bitcoin / Development & Technical Discussion / Re: Historical question: When did Bitcoin client software implement privacy features on: March 24, 2015, 07:11:09 PM
I don't think that it is.  A transaction is an event that consumes inputs and creates outputs.  Those outputs later become inputs in another transaction.
You've moved the goal-post there.  Smiley  The change outputs are _always_ to new addresses, they're in random order,  that someone might guess that they were associated is true... but not something that selection policy can do much about.
14  Bitcoin / Project Development / Re: [ADVICE] UPDATE OpenSSL NOW! - 12 vulns! on: March 24, 2015, 07:08:45 PM
but this board is also for the development and technic discussion of general projects for bitcoin i think. so advice for security update should fit in. if not, please advice me.
It very explicitly is not, please see the description of the subforum: "Technical discussion about Satoshi's Bitcoin client and the Bitcoin network in general. No third-party sites/clients, bug reports that do not require much discussion (use github), or support requests.".

Quote
#EDIT: it s good when linux distros backport only the fixes which used to remove vulns . but i think most users apply patching manually without waiting for official updatepatch. spescially webmasters. and also not sure what is sense of reformatting in the SAME TIME??? why not only fix vuln and in next version increment reformat codebase?
I do not know why they did that. I think its unreasonable.
15  Bitcoin / Project Development / Re: [ADVICE] UPDATE OpenSSL NOW! - 12 vulns! on: March 24, 2015, 04:23:11 PM
The disclosed vulnerabilities are not very exciting for Bitcoin implementations and I am not aware of any reason people should rush to deploy in the context of Bitcoin software (the subject of this subforum! your webserver is another matter)

The diff between 1.0.1l and 1.0.1m is over 700k lines of code because they also reformatted the whole codebase at the same time. If someone has told you've they've reviewed the changes carefully they're lying.

Gentoo (and, I believe, Debian) appears to be rejecting openssl's huge patch and is working on backporting the specific fixes.

16  Bitcoin / Development & Technical Discussion / Re: Flaw or just a bad debater :( on: March 23, 2015, 02:24:23 PM
Your wife is right to not just accept a more secure claim easily.

I guess the greatest point to make is that the banking system is also heavily dependent on software and involves a lot of use of completely opaque software-- even opaque to the bank itself-- where subtle backdoors could be introduced and fraud could, in theory, be conducted which is indistinguishable from your normal activity, meaning that the banks normal 'fix it after the fact' might not work.   So I don't think it would be correct to say that traditional banking is necessarily in a superior position with respect to the particular attack vector of subtle software backdoors.

Bitcoin is completely open and transparent software updates to it are reviewed by a great many people. We have some evidence that critical intentional errors would be caught on the basis of the less serious accidental errors which have been caught.  Going further, even if a bad version is released, nothing pushes that onto users systems but the users themselves. New versions take a fairly long time to become widely deployed which allows time for additional review and analysis.

You're also right to point out that if there were some catastrophic failure which everyone agreed was a failure the community of Bitcoin users wouldn't just say "oh well, we have to live with it".  Actions external to the system could correct most things, though it's hard to reason about that because it's assuming the system failed and it'll be upto messy human politics to resolve things.

Ultimately I think the best description here would be to say that Bitcoin is differently strong from banks. It has different weaknesses-- it's believed to be more sensitive to software engineering and to end-user security, and it's believed to be less sensitive to political abuse, uncertain economic policy, and various kinds of uncasual fairness.  In practice Bitcoin could be either more or less secure than traditional banks, depending on your own practices and exposures (e.g. if you make large cash transactions you are more exposed to random seizures with banks, if you get malware on your computer you are more exposed to Bitcoin theft); and unpredictable activity going on in the wider world (compare vulnerabilities in Bitcoin software to the cyprus banking haircut).

From the perspective of straight computer security banks generally have awful security, but because they have almost limitless power to seize funds and reverse transactions in practice their security is usually okay. But not always--, the same unlimited seizure and reversal power contributes to many of the awful stories of completely unjustified civil forfeiture (and other kinds of adverse action without due process), or just the huge cost and collateral harm when the bank does make an error give reason to think carefully about how you manage your funds. The traditional banking system also leaves you exposed to monetary policy, where inflation continually devalues your money to the benefit of powerful third parties... Today, Bitcoin has substantial volatility risks and risks related to it being new and niche, but these and other reasons are points that may make it ultimately a productive and widely used tool for society.

17  Bitcoin / Development & Technical Discussion / Re: Likelihood of transaction hash mutating with current state of BIP062 on: March 23, 2015, 12:38:53 PM
From what I understand most of BIP062 is now implemented via soft fork
Not so. There have been no soft forks related to that yet.
Quote
Will malleability ever be totally eliminated?
No. It is an intentional and useful feature, without it things like lighthouse would not be possible
18  Other / Off-topic / Re: JavaScript and Js.processing Discussion and Developments on: March 22, 2015, 08:58:29 PM
Your personal growth and capabilities are not an appropriate subject matter for the development and technical subforum.
19  Bitcoin / Development & Technical Discussion / Re: Thinking about ways to make it more difficult to link IP address to txn creator. on: March 22, 2015, 05:04:53 PM
I implemented what is effectively 'split routing' for Bitcoin Core some time ago (just a switch that makes it not relay transaction; so an additional utility can getrawtransaction and handle it some other way).  But it's not currently compatible with the conflicted detection in Bitcoin core because the transaction says out of the mempool until its heard over the network and erroneously shows as conflicted, so I've been waiting for that to change.   If someone is interested in working on this in Bitcoin Core, feel free to lemme know and I can point out what needs to be done.  Primary difficulty is just in writing test harnesses and test cases, because this area of the software is under-tested currently so we're not comfortable taking changes without accompanying tests.

It would be straight-forward on top of that to provide a small sidecar daemon that handled your broadcasting for you (including by using fancy things like a high latency mix network).
20  Bitcoin / Development & Technical Discussion / Re: Quantum Error Correction, Hashing, & Quantum Teleportation on: March 22, 2015, 12:53:07 PM
These are two areas I foresee quantum computing affecting Bitcoin:(cf. this thread)
The first is largely uninteresting (as explained in the linked thread), the second is irrelevant.

Both are off-topic for this subforum, at least in the above armwave and speculate form.
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 ... 195 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!