The idea doesn't seem feasible at all unless you solve for sybill attacks and if you could do that you wouldn't need mining to begin with.

In an anonymous network you don't really think it would be brain dead easy to make a 1 PH/s farm look like 1,000 1TH/s rigs do you (or 1 million 1 GH/s rigs)?

So is the letter "A", this entire forum, all floating point numbers, and whole Bitcoins.  They all use more than one bit and hence are represented by bits of data.  Still I have never once heard anyone refer to 1E-8 BTC as "1 bit" until you just did.  Even if some people do it certainly wouldn't be a majority and thus saying Danny is "wrong" is kinda silly right?

56 bits is pretty weak for a salt and worse they would be heavily biased.  Due to non-random distribution an attacker could choose to start from the most probable values and expand on the precomputation tables as time permits.  Taking a ballpark guess the majority (51%) of Americans would have less than 20 bits of salt.  Granted if your name is Olef-Olef-Olefz WashingFrankenburg and you were born in Greater Bumfuck, Uganda in 1999 you probably are safe.  On the other hand if you are John Smith born in 1980 in New York well you just have a false sense of security.  I would advocate against using this type of system but if you absolutely felt the need to use such a system it should involve more questions and ones with a flatter distribution and that are less likely to be known through casual contact:
What is the name of the street where you first lived (enter just the base word excluding any prefixes or suffixes "Main" vs "E Main St")?

What is your mothers maiden name?
What is your grandmother's middle name?
On what date did your grandparent who died the youngest die?
etc

I agree this is better than just a single hash brain wallet but the implicit zero factor nature of brainwallets means that better is probably still going to result in lost funds.  The difficulty is that humans are both BAD at entropy and BAD at recognizing low entropy values.  Most users simply fail at picking a strong password.  However in most applications there is a second factor.  To steal a desktop wallet requires the passphrase (probably weak) AND the actual file.  To break into a website (which hopefully disables logins after failed attempts) requires the weak passphrase AND the hashed password table.  Brian Wallets don't have that luxury.

Well first of all there is no "mistaken".   You can call "a bi"t whatever you want and so can Danny and so can anyone else.  There is no international standards body to act as a body of trusted elders to lay down the definition by decree.  Still I have NEVER see anyone refer to 1E-8 BTC as a "bit".  Of all the possible subunits the only two which have almost universal consensus are "1 Bitcoin" (1BTC or 1E8 satoshis) and "1 satoshi" (1 discrete unit or 1E-8 BTC).


I think that it is self evident.  You assume everyone else believes 1E-8 BTC = "1 bit" while the reality is (I am guessing here) >99% of the population would disagree with the assessment.

Agreed with Tim.  Please let this post die.  It is a horribly insecure method.

Lets assume that it can only be brute forced (in reality many of your friends you steal your coins on the first attempt).   If we consider all possible birthdates in the last century that is 16 bits of entropy.  However we can shave 2 bits off by looking at only likely birthdates (say between ages of 16 and 66).  The US census provides name lists which cover 90% of the population and that consists of only ~887K last names and ~3K first names.  In the US there are only 30,000 recognized cities, towns, and unincorporated areas.  Put all together you could cover ~90% of all possible permutations of US Bitcoiners with 9.7 * 10^16 attempts.  This might sound like a lot until you consider that the Bitcoin network to date has made 1.2*10^24 hashing attempts (12,433,044x as much). 

Volume is not the number of trades but the number of "units" traded.   A single trade of 100 LTC would add 100 LTC to the daily volume.   Volume can only be compared in consistent terms.  Saying 20,000 LTC is higher volume than 5,000 BTC would be like saying a million pennies is more than a 1 ton of gold.  

Sure some addresses will be less than 40 bytes but 100% of addresses in 100% of the cases?  So how does a merchant handle a bad delivery address?  Just mail it to a known bad address and hope it works?  A standard which can only handle a subset of possible values isn't a very good standard.

OP_RETURN is limited to 40 bytes.  That is good for a txn return bitcoin address but not much more.  Certainly not enough to shop from a poster or do entire order and delivery processing on blockchain.

Not really it is something I believe many people have considered simply because RFC6979 is "overkill" however the advantage of a widely adopted standard is it tends to become more widely adopted providing a defacto "universal solution".


It is better.  No doubt about it.  Pretty much anything is better than a random k.  Random k is fragile solution.  It is easy to implement but also very easy to get wrong.  

In general however HMACs are preferable over raw hashes because they have been proven to be cryptographically resilient to various attacks even when the underlying hash is weakened.  It also the more logical tool.  Someone who uses HMAC in other fields would immediately recognize how/why the HMAC is being used.  A HMAC is a keyed hash.  HMAC(message + secret) = keyed_digest.

Look familiar. A transaction is a message and a private key is a secret.  The system is being used exactly as it was intended, not some clever hack or workaround.  The right tool for the job means attack vectors are likely to be better researched.  You can bet that right not cryptographers are researching attacks and weaknesses which may lead to a HMAC "leaking" the secret.  That isn't necessarily the case of a H(secret + known_non_secret).


You could but like your humorous cartoon indicates it may not stop at that.  While RFC6979 may be "excessive" nobody has shown it is insecure.  In time it is very likely that it could end up in general purpose cryptographic libraries (much like pbkdf2 and HMAC-SHA256 are).

While k = sha256(privkey|mdigest) works so does k = sha256(magic|privkey|mdigest) or k = sha256(mdigest|privkey) or k = sha256(XOR(mdigest,privkey)), or k = sha256(privkey), or even k = sha256(message|nonce) or k = sha(message) XOR nonce or k = left32(message) XOR nonce.  The last three aren't deterministic but it would avoid a situaiton where a repeat nonce compromises the key

So if your choices are using algorithm above OR use random k well I would say use your algorithm.  If you can implement RFC6979 then I would say use that over another potentially good but incompatible solution.

As a side note even the simplest solution  k = XOR(privkey, known_constant) works. 

The txn has been accepted into their memory pool but I don't believe Eligius will include it in a block without a fee though.
http://eligius.st/wiki/index.php/Policies

Actually looking at the debug.log it looks likes the error is simply indicating the txn is non-standard.


You would need to find a method to relay this txn directly to a miner that accepts non-standard txns. 

ScriptPubKey indicates the issue is with one of the vouts.  IIRC an empty PkScript ("output script") is no longer valid.  One thing I never understood is that internally Bitcoin has a number of error codes to indicate exactly why the txn failed but then it "dumbs them down" and returns essentially uselessly vague error codes.

One other thing that would help is if "decoderawtransaction" actually did some parsing and validation.  It could indicate if the txn is non-standard and/or invalid and EXACTLY why.

The tool I linked does (and it outputs RIPEMD-160 was well).

The problem is your tool.   The tool you are using is hashing the input as "text".  Bitcoin public keys are byte arrays.  We may represent them as a hex values but you need to be hashing the actual bytes (i.e "0x77" is the value 119 not two numeric digits seven and seven).

You need a tool which hashes the bytes.  Here is one.   It supports RIPEMD160 as well so you can walk through the example from the beginning.
http://www.fileformat.info/tool/hash.htm?hex=445C7A8007A93D8733188288BB320A8FE2DEBD2AE1B47F0F50BC10BAE845C094

There are encryption systems which can use ECC keys.  

ECIES is one system:
https://en.wikipedia.org/wiki/Integrated_Encryption_Scheme

However a couple things to keep in mind.   I don't know of any widely deployed open source software which uses it so you will be reinventing the wheel.  Could you develop such software, extensively test it, and then ensure your recipient also has said software (doesn't do much good if the recipient isn't using it) so that you can encrypt a message using a PUBLIC KEY you obtain (not address which is a public key hash) so the recipient can decrypt it by exporting a private key from his wallet into some software he is unfamiliar with?  Probably.

It wouldn't work any better than other widely deployed systems like PGP and unless you are very good you run the risk of compromise which affects both systems.  I would by default be suspect of any software where I have to export one or more private keys from my wallet (that control MONEYZ) to a third party software in order to  decrypt a message.  Even if legit it certainly doesn't sound smart or reasonable.

There is no such thing as "unhashing" a bitcoin address.  The user would have to supply you his public key not address (public key hash).  Once again it comes down to a very convoluted system for what benefit.   Just use open source software widely distributed and extensively peer reviewed like PGP.

As described that has absolutely zero chance of being approved by the SEC.  Bearer shares and notes are explicitly unlawful under federal law.  They are unlawful for expressly that reason.  It isn't just a US thing, bearer shares have been outlawed most places on the planet.   Sure maybe you be able to issue bearer shares in Somolia but then again the coins are backed by dollars they are backed by the promise to rpeay dollars.  Any doubt on the legality of the entity casts doubt on the promise to repay.

No.  Bitcoin uses ECDSA which is a digital signature algorithm not an encryption algorithm.  You could use another algorithm which supports encryption however Bitcoin address is not a Public Key it is a hash of the public key.   If you need to use a third party algorithm, third party software, and exchange keys directly well you might as well use something that was designed for this purpose like PGP.

Both 7000 and 7100 can be used with the same closed loop system.  The point is that the larger the difference between ambient (i.e. outside) temp and the condensation point of the working fluid the more efficient the operation.   Now obviously a fluid which boils at 400C would be very efficient but it would also mean the processors would be 400C as well which wouldn't be good.   So the optimal working fluid in a two phase immersion cooling system is one with the HIGHEST boiling point which is still maintains the processors at an acceptable temp.

Solid.  If due to the limits of the architecture you didn't get RFC6979 implemented I personally would still prefer a simple deterministic function like k=SHA256(key|mdigest) over the open ended risk of a random k.  Using a random k in my opinion is just bad practice and that goes beyond just Bitcoin specific uses (just ask Sony).

I would also recommend supporting RFC6979 (deterministic signatures).  It provides a level of confidence for users (they can verify your device produces the same signature for the same key and message as any other RFC6979 compatible software/device).  This can be important as it is possible for a hardware device to intentionally produce signatures which are valid but are cryptographically weak under certain conditions. The good news is there are some python libraries which have implemented RFC6979 (or at least a Bitcoin specific subset of it). 

If you are a proponent of Test Driven Development, RFC6979 makes unit test verification of signature generation easier.  For a given message digest and private key there is only one correct RFC6979 signature.