Add some WD-40, slowly reink yourself.

But still less than inkjet: http://www.tonermonkey.com/apple/appleribbon02.htm or http://www.amamax.com/coacoricarea.html

To be clear, it's not "incrementing".  It's a hash that changes if the private key or message changes.  In other words, there's no way to sign two different messages or with two different private keys using the same k-value with RFC6979.  It should be pretty strong, I'm just more sensitive to deviating from NIST/FIPS standards with our recent enterprise focus.

I wish people would stop referring to "you are at risk if you don't use RFC6979".  We have seen in the wild, poorly-supported platforms, with poorly implemented RNGs cause problems for people that reuse addresses.  However, Armory only runs on systems with proper RNG capabilities AND using an RNG for ECDSA signing is part of the NIST standard.  RFC6979 is exactly what it says "Request for Comments".  It's not a standard, never been approved by any organization.  I recognize that it might be more trustworthy than the javascript RNG or Android RNG (which have both caused problems in the past), but in our environment I'd prefer to use the NIST/FIPS standard RNG version of signing.

For instance, we're working on HSM integration now, and the whole thing is a giant [$15,000!] FIPS-certified hardware and software stack.  If we tried to implement RFC6979 we'd be breaking all the crypto certifications of the device.   This would mean our HSMs would immediately be unsuitable for any government use.  This means it would be unsuitable for a wide variety of environments that depend on FIPS certifications.  

This doesn't mean that I don't think RFC6979 is useful.  It's that it's a tradeoff between using an approved, standardized process, and using a "proposed" process that addresses shortcomings in some platforms that don't even meet sanity checks for RNG capability.  While I think it would be tough to argue that the RFC6979 process was insecure, we don't like modifying such sensitive parts of crypto processes without at least some review by standards bodies (with real cryptographers).

My attitude on all this is:  I personally believe (using judgement) that RFC6979 is a good choice, as standardizing it across applications solves issues with platforms using weak RNGs, as any shortcomings it might have are better than having a bad RNG behind the signing.  But I'm not going to shove all our users into it (at least without a way to disable it) on platforms that have solid RNGs and can apply the approved signing algorithms.  For now, we've made det-signing opt-in, and I think pending further review we'll switch the default to make it opt-out.  

https://hashtalk.org/topic/32358/how-much-did-gaw-invest-in-paycoin-and-paybase/29

WTF?

Haha YES! Now this is the type of guy I'd hire... probably really smart, Self Awareness, humility and a bit a humor. #hired

True... Pretty good point, I guess it doesn't really matter. I think I thought I was cool there for like 10 minutes when we discovered the fact that this Ray character is actually Mike. Carry on... and God Bless you, I didn't even know this community of virgin weirdos sitting on message boards talking about cryptocurrency existed. Cheers to that!

You are shilling in the wrong place.  It is crystal clear among everyone who has seen a scam coin or two that xpy is a scam coin.  It was created to be Josh's personal piggy bank.  A coin with 97% premine alone would be laughed out of town around here but when you add in the hyperinflation designed to further benefit the one who premined all the coins, holy shit it becomes obnoxiously galling that this thing has any value at all.  At fractions of a cent this coin would be completely overvalued.  At its current price it is obvious that the only thing keeping this thing from crashing to zero is the fact that GAW funneled all of its customers money into this sinking ship of fools and they don't want to jump now because they are so very far underwater.  Which probably describes you and the reason you are shilling here in the first place.

It takes the random number generator out of the process for generating a signed transaction. Somehow (I do not know the details). It makes it safer, as the signatures can't leak any information (i.e. something to help calculate the private key...) when using weak RNG implementations, plus some other benefits I expect. Also, it's last on the changelog list for 0.93

Notice how he's careful to say the promised deals were *verbal* agreements:


He can't claim to have had written contracts with the companies he claimed to be partnering with because then (a) those contracts would have still been binding, even if the companies got a little nervous, and (b) he could produce the written contracts and prove the naysayers wrong. So he claims that they were verbal agreements only, and the naysayers scared those companies away. All of them. As if Amazon and Target and so on would do business that way.

Not to mention that on the very day that paybase launched he was still promising merchant integration with Amazon and the ability to purchase directly from Amazon via paybase. Amazon didn't back out of a verbal agreement at the last minute, obviously. He promised this knowing that a few hours later the facts would prove him wrong in front of everyone.

What Homero doesn't seem to grasp is if the community says fuck your Shit-coin then fuck your Shit-coin.

Sounds like a good enough reason to justify the disabling by default, you need at least 10 opinions  . But I I know, you mean opinions from people who make it their business to know cryptography from all the theory based angles who can spot signatures leaking information in some way no-one's thought of, etc. I might wait just a while to use it, but it sounds like a good thing in principle (it makes address re-use safer/safe IIRC)

Great, can I reuse an old blockchain copy?

I am also curious about this supernode functionality, in depth documentation would be useful

'Mine's perfect' - that comment doesn't really help me - my wife's is also now running, but we didn't learn much from that either.

I'm running bitcoind independantly - and seem to be getting on better - currently scanning transaction history whereas before Armory 'locked up' almost as soon as bitcoind failed.

it is different.