No, it was a person who goes by the name of "Joric", who also went and created the website. The discussion wasn't secret, it was all in #bitcoin on freenode in early 2011 IIRC.  The logs for the channel aren't public, but I can send them to you if you're curious.

Electrum users don't seem to mind.  Correctly written software should may it easy— and standards exist to help people make best practices sofware, I certainly don't expect people to go out and roll their own implementations. 

Or did you write your own copy of SHA256?

Lot of good they're currently doing him (or likely to do him ever— considering the charges). I'd really rather not participate in a discussion where someone with charges like this is held up as exemplar, as it's too easy to go off on a insane tangent.

But thats the thing about security it exists in the context of many other things. Bitcoins that can't be taken from you only achieve their full value to a spherical-convict who can't be put in a jail cell. It also has to be weighed against the very real risk that you run a fever and forget the key. For every person whos coins are attempted to be seized there will be 100 others who just forget their keys. ::shrugs::

I think people are imagining just different scales of things.  Perhaps you think about the problem and imagine something like a 20% uncertainty in the true medium/long term supply of coins.  Someone else, looking at the same trends and facts may be imagining a world where there is a 99.99% uncertainty in the medium/long term supply of coins.

I hope that most people would find a lot more agreement if not for the speculation on what the future would look like... and if so, then should one of those futures come true deciding what (if anything) should be done about it would be easier.  Hope hope hope.

We actually have something much more effective than whats described in the paper in Bitcoin-QT already. This is part of why 0.8 was so much faster than prior versions— it changed to doing all the validation against a separate maximally pruned data structure.  Some additional work is needed to make sure nodes can still be bootstrapped— that there still exist ample distributed copies of the historical data and that new nodes can find them— in a world where a lot of nodes are pruned... but the pruning itself is all there. You can, quite literally, go and delete all the old block files (past 288 blocks or so) and your node will run fine until a peer tries to bootstrap from you and fetches an old block (and then it will crash. ).

Exactly... and to distract from understanding Bitcoin for what it is and isn't— whatever it's creators motivations were Bitcoin is an open and transparent artifact, I feel that we've been blessed beyond belief that when we argue about Bitcoin those arguments can be settled simply by the fact of what it is and without endless appeals to authority and speculation about its creators intentions. Bitcoin is what Bitcoin does. Fixing on its creation sullies it.

Who said anything about "random alphabet-number-symbol mix"? Alphabet-number-symbol mix is terrible cargo cult security and shouldn't be used. Go reread my posts. Good schemes for memorization use a mnemonic encoding that translates large integers to and from english text.

Though generally the properties that make phrases _easy_ to memorize are what actually produce the statistical properties that make them easy to predict.  But predictability is resolved by using a lossless encoding process with known entropy rather than a human source.

(And memorization still has a rather severe forgetting problem. Like people overestimate their ability to be random, we also over estimate the integrity of our memory. The public has very little experience handling keys which cannot ever be recovered if lost.)

I actually have IRC logs about the creation of the phrase brainwallet and brainwallet.org.  It was created by someone who introduction to the subject matter was his own efforts to crack peoples insecure keys, and he was irritated that he only found a few coins. No kidding. Don't try to glorify history to people who watched it first hand.

It's possible to memorize keys without using an insecure generation scheme. Though if you think thats going to protect you from evidence of unlawful activity on your computer: (1) Perhaps you should engage in less unlawful activity.  (2) you're going to be rather disappointed when you realize how complete computer forensics is, hiding a key will probably be the least of your concerns.

Personally I think 1 year is insane.  5 or 10 and perhaps thats something which would be reasonable for some cryptocurrency to implement. I wasnt attempting to give the impression that I thought 1 year was a good trade-off.  Just trying to point out that the OP's motivation wasn't to take coins from anyone, his definition of sufficient time and notice being crazy is another matter.  

For better or worse I think we've already signed the suicide pact on this one. The gut reaction people have is just too violently negative and no amount of reason will get people through it... so even if you could prove that Bitcoin will die without such a fix (and its not clear that this is the case) then you'll only succeed in proving Bitcoin will die.

As a high preacher of the philosophical school of thou-shall-not-fuxor-the-contract and the view that Bitcoin's existence as a mathmatical object as outside the influence of popular opinion as possible is what makes it worth having, I still do feel the urge to suggest a little caution with the width of your statements here.

Bitcoin in its exact form, as originally released, was worthless. Anyone could spend anyones coin. Anyone could pick an arbitrary block and slay it so that new nodes would ignore it and split the consensus. Anyone could crash all the nodes (in a dozen different ways). Anyone could create a block 1/32nd the size of the system maximum and cause the system to fragment. Anyone could create unbounded amounts of additional coin. All these flaws and more were in the original software, coded into the rules of the system.

If changing the software, at all, was Bitcoins death then Bitcoin never really existed. ... But clearly it does exist. These things were fixed, in 2010, 2011, 2012, and 2013.  I hope that this list never grows, but perhaps it will.  Will we put Bitcoin down and walk away because the software is a suicide pact which can never be changed at all. No.

Should our moral responsibility be to uphold the Bitcoin contract? Absolutely. Does that contract include every flaw and mistaken in the software? Clearly not— mankind simply does not have the engineering tools and talent to build it another way.  Where is the line?  Unclear. Reasonable people can disagree, and thus the taint of the influence of man.

I hope for Bitcoin's sake that serious life or death flaws will remain uncontroversial fixes... and that Bitcoin can survive a few changes here and there, as required, by a true consensus.  If it turns out that can't work, I have noting to offer as an alternative: a tyranny of a majority is certainly not what we signed up for.

If that is the case I think it will be truly sad, because I think such a failure of Bitcoin would salt the earth for a generation for the idea of a system whos trust is in math rather than man... but perhaps it will be. Time will tell.

Shame on you.  Disagree, by all means— it's a controversial subject.  But at least understand what you're talking about. There is nothing about "early adopter's coins" in his commentary, he's suggesting a requirement that after a long notice period old coins need to move or will become unmovable. It has nothing to do with not accepting early adopter coins, though it would require people with those coins to move them once. If it was done the way he envisioned it working not a single person would lose access to their coins, though some people might be moderately inconvenienced. The effect of it is that ambiguity about how many actual coins exist would be substantially reduced. Maybe this is a terrible evil horrible idea, but at least complain about what he's actually suggesting and not some paranoid delusional parody of it.

Your speculation has higher entropy than my speculation.  Multi-collissions scale much much better than linearly. E.g. even with just the rho method only moderately more computation is required than the 2^128 operations expected to compromise a single ECDSA key to compromises almost all ECDSA keys on a particular curve.

Collision attacks (e.g. all known methods of discrete log solving) favor single large attackers, they are unlike mining is that the probability of success is not constant but goes up the more work they've done.

There will indeed be plenty of notice that a particular scheme is looking weak, and the non-lost coins will be moved... you could have easily been quoting me there on "modern cryptographic algorithms" but I think you're wrong when it comes to practical attacks: The reason we get advanced notice is generally from certificational weaknesses which don't translate into practical attacks. With MD5 collisions we went basically overnight from (I think) two known examples with sensible files existing in the world, to a tool that would produce them freely on my desktop— though we had many years of warning.  Bitcoin further complicates that with single coins being high value: How could an economy functioning on a few thousands BTC "price in" the sudden reintroduction of a single 111,000 BTC "lost coin"?

I don't see how any economy could price that in even if the reintroduction was relatively slow, whatever that would be it would constitute an enormous highly distorting value transfer from the entire economy to whomever operates those cracking devices.  I can't tell you exactly how people would deal with it— blacklisting those coins, or just abandoning Bitcoin— but I can pretty much promise that people will not just tolerate it if such a thing came to pass.

I am not saying that we couldn't absorb the reintroduction of lost coins _today_, I am saying that it's possible that they won't become recoverable until Bitcoin had deflated past any reasonable prospect of being able to accommodate absorbing them.  We might disagree on where that boundary would be, but I don't think you can convince me there there isn't a degree of deflation under which a point recovery of a single gigantic coin is basically a currency extinction event if permitted.

Uh. Dunno who you're talking to, but one of the number one things people say to me is "What happens once all the coins are lost, without inflation you'll eventually run out of coins!"  and then I explain that people can just trade in smaller and smaller increments (adjusting units as they go— millibitcoin etc) and I think about 50% of the time they respond "Hm! interesting!" and about the other 50% of the time they say "whoa whoa! what happens when someone finds grandmas old coins, they'd rule the world!"

(Of course, if you've got someone actually concerned about that, I suppose that it means you've already convinced them that Bitcoin will rule the world, even if its a bad thing... which is perhaps what you meant?)

Except they stake-my-life-on-it will NOT be selected randomly if you allow any user to operate under that procedure. They will be selected "randomly" as in that same way that "DUCK SPATULA" is random: Not very.

If instead a cryptographically strong random number of, say, at least 128 bits is generated it can be directly converted into a secure mnemonic phrase with just 12 words (or fewer, if you want to deal with a bigger dictionary).  This is probably way smaller than your "five random phrases" but by being ruthlessly specific about HOW its generated and what "random" means, it's really just another way of representing a 128 bit key, and it's perfectly fine to memorize that.

If your construction involves the human picking the words or phrases, as it does 99 out of 100 times someone says "brainwallet" then the actual entropy is much lower. Humans are poor sources of randomness, and telling them to be "random" actually seems to make them worse at it. Powerful statistical models are quite good at predicting what humans will do, and while they won't break every single instance they can break a surprisingly large number.

People who haven't worked on password cracking have this quaint notion of running a little dictionary file through a program... and this would have been accurate in 1990 for someone cracking at your unix-crypt uni shell account.  Today the tools are significantly better and have been refined through the disclosure of hundreds of millions of unencrypted passwords and the same kind of statistical tools that power speech recognition and automatic human language transaction. This statistical intelligence gets backed up by the brute force of GPU and FPGA clusters that can try hundreds of million or even billions of attempts per second.

I'd rather not see cracking weak bitcoin brainwallets turn into a viable industry for people buying up no-longer-competative mining fpgas for pennies on the dollar.

No, the security it depends more on how much all attackers eveywhere in the world are spending on setting up ultrafast hardware for brainwallet cracking. This number is likely to become very big: "just pocket money" has a way of growing through lazyness and the sum of all pocket money is great in any case. This is especially the case because the attackers can attack everyone with the same effort it would take to attack one person.

Viable alternative to what? Done right it is just a cryptographically strong number, so it's not really an alternative in that case, it just "is" the other thing.

URGENT: IF YOU ARE USING THIS PACKAGE IN ITS SERVER/DAEMON MODE YOU MUST IMMEDIATELY CHANGE YOUR RPCPASSWORD

Edit /etc/bitcoin/bitcoin.conf   and replace the rpcpassword with a long random string, you don't ever need to remember it or use it.

Mashing the keyboard like "4ximgiwxkiqxkjisjfijxorqijkgojkjfkjq9ixjtrq9dqkewogkjtrijywjtuwehfx8uw"  is perfectly fine.


As an aside, Error, can you please sign the 179A 8CC0 90B4 95B2 4620  E172 FC6E 7E4E A436 0C84 key with your Bitcoin-OTC key 0ca1a03280f9711ca0c72356920290120a0aac5c?

Okay, I thought perhaps. But Sergio's protocol improvement prevents unwitting outsourcing.  Voluntarily outsourcing is okay I think, as a scarce resource is still being consumed by someone involved in the activity.

Isn't it more fun to wonder than to know?

Yea this was what I was referring to with "There are some possible optimizations in the client, like common prefix compression, but they're only small optimizations because the function is strongly pseudorandom".

The timing comment leaves me feeling a bit confused.  I don't hope to prevent outsourcing: if someone is storing the data then that creates the desired scarcity.   If the client instead wants to store no data but perform a billion computations (or what have you) per query, then I think thats okay:  The queries are super cheap  for the server and honest clients so they can be performed frequently. I think the parameters can be chosen so that the storage-less solution of recomputing most of the answer space for every query is pretty costly (which would also achieve the goal of limiting abuse).

No.

Practically everyone who knows about or cares about the BIP process loudly yells at people DO NOT USE BRAINWALLETS.  We've seen pretty concrete evidence that users are resistant to good advice in this space, and they are shocked when their favorite quotation is cracked and they lose their coins (But it was 60 characters long! I even added a special character! how is this possible?!),  the existing sites promoting this stuff won't use a KDF stronger than SHA256*1 because "users are stupid if they use weak passwords".


BIP∞: Brainwallets.

FOR GODS SAKE. DON'T DO IT.  YOU MAY THINK YOU ARE SMART ENOUGH. SO DID EVERYONE ELSE WHO GOT ROBBED. HUMANS ARE NOT A GOOD SOURCE OF ENTROPY.

YOU HAVE A SCHEME?  Pfft. THE SPACE OF ALL SCHEMES YOU'RE LIKELY TO HAVE PROBABLY ONLY HAS A FEW BITS OF ENTROPY. RANDOM PHRASE IN A BOOK? THERE ARE ONLY ABOUT 30 BITS OF SENTENCE SELECTION IN A LIBRARY.

OH NO. YOU ARE NOT LISTENING TO ME, ARE YOU?

OH CRAP. YOU THINK THAT "EIGHT CHARACTERS AND ONE FROM EACH CHARACTER CLASS" APPLIES HERE??  WEBSITE SECURITY MIGHT HAVE TO DEAL WITH 1000 ATTEMPTS PER SECOND, BUT SOME DUDE WITH A FPGA FARM IS PROBABLY PRECOMPUTING A BILLION BRAINWALLETS PER SECOND. JUST STOP.

NOOOOOOOOOOOO.

Well, now that you have no more Bitcoin I guess we don't have to worry about you using a brainwallet.

Cheers.


Of course, if by brainwallet you mean a key the user has memorized... it's not hard to memorize 128 bits mnemonic encoded. Though the risk of data loss is kinda sucky: People are really not all that used to data that cannot be recovered if lost.

Your service strips control away from users— by sending funds back to random addresses. When they have funds randomly show up how will they know where they came from?  Is it the prior person that they gave that address to— the only person in the world they gave that address to— paying them again (and so should they ship out some more product as a result?)  is it one of your payto's refunding? Should they want to send the funds another way, how do they know which payto was refunded?

As I have said several times here, shared wallet services are not the only case where your service will cause funds to be lost (though they're currently the most common one). It's hostile to good key management retiring old keys, and it's hostile to wallets anonymizing payments by making joint transactions. Worst of all, it makes the users private wallet management practices— which should be their own personal business— constrained by you.  It degrades coin fungibility because the user may have coins they can pay you with (ones that were sent to convenient addresses they can receive more payments with) and ones they can't.

You are already taking a twitter-to address, just take a refund address as part of the same URL. Whats the big deal?

Is your own service even compatible with its own practices?  What happens if a paythru user releases their funds to an exchange using the same practices as your site (fortunately none currently do) which does an emergency shutdown and refunds all coins using the same algorithm you use? I assume you'll just uselessly loop at that point.

The impression I'm getting here is that I wouldn't personally trust you with my money. You seem to be somewhat blasé about putting other peoples funds at risk.

My my, thats unfortunate.  Had this been fixed before being exploited it would have been a trivial soft forking adjustment.  Even a simple temporary softforking adjustment to deny all transactions while it would have fixed would have prevented basically all the harm.

I agree that supply uncertainty is a concern and a mistake in the original system. It isn't clear to me that it can be resolved without causing greater damage, since the inviolability of our promises is even more important— if Bitcoin operates on mere popular whim it offers little more than the official currency of a democratic country.

What concerns me most in this space is the cryptographic break concern:  Lets imagine that at some point 90% of the coins are lost... no biggie, we just trade in smaller units. One small country costs 10 BTC, etc.  And then someone comes up with a way of breaking ECDSA and can suddenly recover hundreds of thousands of long lost coins and introduce them into circulation at will... perhaps many someones.

No cryptographer will claim that our current signature algorithm will be secure forever.  Bitcoin is forward adaptive and can gain new signature algorithims without a hard fork.  Non-lost coins should be migrated to new, more secure, signatures long before it's an issue.  But no one can move the lost coins so their reintroduction into circulation via cryptographic compromise could be uncontrolled and devastating to the Bitcoin economy.

The obvious fix for this is that any crypto upgrade would require coins to be moved after some suitable period... but as you've seen here, people are _very_ hostile to the idea.

I guess my thinking on this is that the idea that a system can be free from human intervention is a bit of an unrealistic fantasy, though one I frequently enjoy. A failure to intervene when doing so would be rational and necessary is also a kind of intervention, and the Bitcoin system may someday die from it. What does it matter if your coins are not "stolen" from you in the broadest possible sense if dogmatic adherence to that principle ultimately results in the coins being worthless?  Time will tell.

This is really a question for how _much_ these tools are used. What you're pointing to is that there is an information leak whenever the anonymity set is less than all users of the system. It's actually even worse than that: only a very small fraction of the world uses Bitcoin at all: So even if every transaction were anonymous internally to Bitcoin there would still be an information leak from the fact that you used Bitcoin at all.  The same kind of thing exist for any other anonymity system: Even if Tor was perfect, you'd still be a member of the tiny set of people using Tor (or had even heard of it), and in practice there are far more leaks than that (time of day, subject matter interests, languages spoken, etc).

What this says to me is that trying to draw a hard line at "no information loss" is misguided because no system can actually achieve that when you consider all possible information sources (and, of course, real attackers are not confined to stay within the bounds of your pretty little system: they will consider all possible information sources).

In general I prefer to say these are techniques to improve your privacy. In the conventional understanding of the word privacy we realize that privacy is seldom absolute.  Because of the public ledger Bitcoin's privacy is very fragile.  With current use practices today snooping so simple that webpages automate it for you easily can tell you all kinds of information about who transactions with who, and how much coin they have, how much they're earning, etc. You can't always answers these questions totally cold, but as soon as someone sends you funds you have a piece of yarn to yank on, and often their privacy will more or less completely unravel.

If zero information leak is not generally obtainable then what should we consider private or anonymous?  It depends a lot on the situation and the people involved.  But in considering something as a tool to improve privacy I don't need to draw bright lines: More privacy is better than less (when you actually want non-privacy you can always selectively disclose to the parties you wish to disclose to).

Besides, there are not-quite-privacy related motivations here too: Bitcoin's privacy limitations are a fungibility risk: If blacklisted coins become the norm Bitcoin may become unattractive to trade with because no one wants the risk of finding out they accepted a black coin, or we could potentially lose decentralization because accepting a feed from some centralized blacklisting authority may be the only reliable way to avoid receiving a black coin. Even if coinjoin usage did nothing to make anyone "anonymous" if it made attempts at large scale coin blacklisting cause too much collateral damage and fail at birth, that would be enough justification for it.

My thinking here is if the tools are easy and cheap they can be used very widely. Above all other criteria widespread usage is what makes the difference between your "plausible denyability" and whatever you'd call actual "anonymity". I'm also more generally concerned with more casual levels of privacy:  I don't want the guy at the coffee shop knowing my income or net worth. I don't want my landlord raising my rent because he see that I can afford it. I don't want my inlaws scrutinizing my purchases. Privacy is important to personal autonomy and dignity, and financial privacy can be important to protecting you from thieves and discrimination.

But because these risks are individually low probability and distant I don't want to put my funds at risk or pay a bunch of fees to achieve it. This takes "laundry" services mostly off the table as they have monitoring risk (mostly not my concern), theft risk, and fees. More abstractly, since I think other boring users would also conclude the same thing, I might expect 99% of the funds involved in such a service to be the proceeds of crimes. While recovering my privacy might be worth some risk of being falsely implicated in someone elses crime, paying for the privileged of having a 99% chance of receiving crime involved coins would be a bad deal.  Anonymity systems with only one kind of user really are useful to no one, and to be useful to common boring users overheads like fees and theft risk need to be eliminated.  I believe that relative to the overall scale of the economy criminal activity is small, but that only matters if you have privacy mechanisms the whole economy will participate with.

Assuming no coinjoin or shared wallet usage, when a transaction spends two coins paid to different addresses you can make a assumption that the a common party is probably the 'owner' of all the involved keys and the sender of the transaction.  Prior to the transaction you may not have had any information that those three 'identities' (coin1 scriptPubKey, coin2 scriptPubKey, and the party paying you) were one and the same.

When someone transacts in the intended way with a fresh address for every transaction the information leak is minimized: no more interconnection happens than is strictly needed, and the interconnection doesn't snowball.

If, after you've exhausted the funds sent to a particular scriptPubKey, someone sends you a tiny amount of coin to that scriptPubKey and you spend it in a new transaction then whatever linkage they knew carries forward and your deanonymization grows as a sufficiently small payment will only be useful when spent in combination with other coins. After several applications of this its very likely that all addresses in that wallet become publicly interconnected.  Turning a theoretical weakness ("You might not be very private") into an actual one.

Since those payments are necessarily small (when used to attack all users generically) and since they were non-solicited I think giving them away in coinjoin transactions is an elegant countermeasure: Its as least as good as never spending them, but it also sweeps the crud out of the UTXO set and salts the public ledger with misleading information.

It is never less than not including their inputs at all.

You don't need an account at all.  You're already prompting for a destination email address before giving the user an address to pay to. Prompt for a return address at the same time, it's as trivial as that. This is the standard, widely adopted, best practice in industry right now.

A failure to do that makes your service available to fewer customers, risks customer confusion/dissatisfaction and funds loss (when not if), and reduces Bitcoin user's autonomy over their own wallet management practices.

It isn't just a matter of accepting, those funds may go to other people, they may go to keys that no longer exist. When the returned funds show up the recipient may have no idea which transaction they were being refunded for and may, as a result, double pay (or improperly credit someone else). There may not even be a service involved, but regardless shared wallet services have been a common feature of the Bitcoin ecosystem system 2010. They are common well supported and within best practices. What you are doing is not.

Please don't be irresponsible. Do you plan on compensating people out of pocket for funds lost due to your practices?

No one was telling you to wait for anything.

This is not a safe assumption. The previous places that coins were sent to may have nothing to do with the rightful recipient of returned coins, in common cases like shared wallets or in less common cases like various transaction privacy mechanisms. It's also incompatible with privacy preserving practices like using an address only once, and accounting practices (you may end up sending funds to some offline key of the senders or some key they've destroyed). Many wallets will also not recognize a pay to pubkey transaction as their own. The assumption that you can infer a working return address has observably caused people to lose funds in the past.

Fixing yourself on receiving only particular transaction types is also hostile to the ecosystem, since it denies people autonomy in how they manage their own wallets.  If you may need a refund, you should be collecting a refund address before you provide a pay to address.

The new payment protocol stuff handles that atomically.