RPI -- even rpi2 -- is really underpowered for supporting Bitcoin Core-- it's embarrassingly slow compared to other inexpensive ARM systems.  Just last week Gavin was arguing for unsupporting all 32-bit systems entirely; though I believe everyone else working on Bitcoin core disagrees, it's not great to be spinning up new systems which are at the very edge of whats supportable.  Not all arm cpus are equal, and you can easily have order of magnitude differences in speed with the same nominal MHz.

Many SD cards also have very low performance and write endurance. Esp with the low memory meaning the node cannot cache much, I would expect Bitcoin core will wear out the SD card somewhat quickly unless special optimizations are made to reduce the amount of write activity.

Because of the slowness of it, the vendor here ships with a "trusted" blockchain preloaded, instead of verified from the network. The result isn't easily verifiable, so your trusting that the source (or someone who has compromised their systems) isn't backdooring it in some way-- thats a risk even the developers of Bitcoin Core wouldn't ask you to take with the binaries they put out, Bitcoin core binaries get verified by a public reproducible build process.

It's great for people to run nodes; but you should run nodes in ways that don't introduce more single points of trust in the network;  adding more nodes that ultimately depend on trusting one person or another isn't much better than people just using the node that trusted party is running.

That sounds like a question of fact, not of law. The judge may have erred in rejecting it.

In any case, I don't disagree with you; I was just presenting an alternative view (As you can see, I've defended your position in other posts.)-- I don't think the position I outlined is likely to go anywhere.

Correction to my post.  It turns out that it wasn't the case that MTGox did nothing to piss off Force and Bridges; it seems MTGox earned their ire by failing to respond to a shakedown request: http://imgur.com/a/ecQ5T (ah, Magicaltux's email screenshots are inlined in the post above).

(Force asks for 250 BTC as part of a 'partnership', Magicaltux doesn't respond, he sends more emails... later the send an "I told you so" email; the same day they filed for the warrant to seize MTGox's funds)

Blackbird0's position is that there were multiple investigations. It's possible (I don't know the case well enough to know) that the other investigation was separate enough that that argument doesn't hold weight. You can see my prior post for another argument that depends less on that, but at this point in time it's not entirely good what good it will do. While the argument I gave might have sewn doubt for a jury, the jury didn't hear it and unless they're able to argue that this mess is of the right shape they won't get  a chance to try that argument in a trial court.

They did much more than steal some bitcoins according to the indictment. The investigators, in an effort to conceal their criminality and in bad faith did systematically conceal and destroy material evidence collected during their investigation. The investigators had administrator access to the Silk Road systems which they used to rob the silk road service and then framed the original owner of their admin account for the theft (and then, with another account, offered to conduct a "hit" against that admin to extract more money from DPR) in one of many (successful) extortion attempts they carried out over months-- spanning back long before the government had any idea who DPR might be (e.g. in April 2013 they believed it was "A.A."). Their unlawful actions were not limited to SR, e.g. Force ripped off a random user of the CoinMKT exchange to the tune of a quarter million dollars where he was moonlighting (against policy and in a conflict of interest) as their compliance officer. When Force's improper use of an administrative subpoena (to attempt to unblock his rightfully suspicious-flagged account) was reported to his  superior by Venmo (a payment processor subsidiary of Paypal) he responded by attempting to seize Venmo's accounts.

Lets put aside for a moment Force and Bridge's roles as law enforcement and read their indictment as though they were just private individuals. Considering their access, strongly established involvement (e.g. the money trail connecting _them_ to SR appears to be much stronger than the money trail connecting Ross to SR), established pattern of fraudulent and vindictive activities including framing C.G. for the theft of bitcoin; they'd make a nice direction to throw doubt at the prosecutions claims and support of Ross'  "it was someone else" argument.

Consider the counterfactual with the character portrait painted in their indictment in mind: If Force and/or Bridges had had the opportunity to take over the operation of SR (from which they could rip people off on a greater scale), would they have done so? I think the picture painted by the indictment says yes. If they had and Ross pissed them off, would they have framed him? I think the indictment says yes (or even without pissing them off: They seized MTGox's US accounts immediately after successfully getting their own funds out (to the detriment of everyone now suffering from MTGox's insolvency)). I think this is a much more powerful line of argument than "maybe magicaltux did it", at least. They destroyed evidence related to their own interactions with magicaltux (and appeared to have made a successful unlawful forfeiture against MTGox as part of their criminal activities). In the story told in the indictment, these parties had the motive, the means, and opportunity that would have permitted them to frame Ross in order to conceal their own criminality (or to protect someone else who was paying them more); and the defense was apparently prohibited from presenting this in the trial.

No doubt the prosecution did their hardest to separate out  any potentially poisoned evidence, but these parties were the states only inside eyes inside silkroad. It seems unlikely to me that any of the later evidence was derived in isolation of their input, but regardless: it appears that they'd heavily spoiled the crime scene before any of the other investigators arrived.

What this actually means in terms of the actual law and procedures in the court, but I can't imagine that it would have had no effect on the jury unless they were prohibited from hearing it, nor can I really imagine them being prohibited from hearing it if it had been anything other than law enforcement agents (e.g. if it had just been other random criminals).  But they were. I can't imagine why the defense didn't delay the trial so that more of this information could be presented.

This information has certainly made a number of strange things I observed make more sense.

Edit: Ah, I see Ross' attorney has made a statement: http://freeross.org/ulbrichts-attorneys-statement-regarding-silk-road-corruption/   Seems that I called at least part of their approach, plus apparently the state used the existence of this other prosecution to suppress other evidence from being presented.  Hopefully Dratel will now move to have whatever relevant filings or orders were made regarding this unsealed, so we can get a more objective view of how much this prejudiced the case.

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

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.

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.

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.

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

Just so.

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.

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?

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.

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.

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

Because it's not a finished proposal according to its author (and it was created too late for 0.10 in any case.)

Right and the API may well change, etc.   The current progress is just the first step.

Eventually.

Libsecp256k1 is not used for Bitcoin consensus currently and is not yet suitable.

You've moved the goal-post there.    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.

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

I do not know why they did that. I think its unreasonable.

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.