The vendor of the software you're running (the bitcoin development team overall) doesn't believe that the risks (of software bugs, DOS, and bloat attacks) is well enough understood in the software they're releasing to leave that functionality fully open.  Especially because use of the corner cases in the chain may make it difficult to fix them.   It's a conservative position that some people don't agree with— but the people who don't agree aren't stepping up to provide the QA evidence to convince other people of their confidence.  ::shrugs::

I'm happy the reference software takes a conservative position, though I also hope this position is a short term one that will go away with more experience and testing.


Indeed, and Eligius' willingness to do so indirectly cost MTGOX many thousands of bitcoins when a software bug caused them to send some weird transactions that Eligius mined— though this is clearly not Eligius' fault as MTGOX compounded their own error by then explicitly directing eligius to mine them.

Can you point to a positive use of Eligius' mining of non-standard transaction yet?  When bluematt and I tried using a non-standard transaction for a puzzle a few months back we couldn't manage to get Eligius to mine it.  So I have no examples to suggest.

I ... don't mean to argue that you're doing a bad thing there, but I think the case that what you're doing is an important improvement is fairly weak.   With only one moderate size pool (and perhaps some tiny solo miners) accepting non-standard txn at least the DOS/bloat exposure is limited by the small number of blocks mined with those rules.

Luke, shame on you for just dropping this message and calling for a forum vote without giving people who disagree with you the fair time to write an opposing position.  (Edit: Specifically I'm complaining about the forum vote aspect of this, Luke has been pretty upfront with his complaints at least since he started raising them)

As with a lot of things, the subtle details here are technical can be tricky to understand.  It's hard to find an expression of the situation to help people reason about the consequences without having to learn everything that the developers know.

Here is my take on the situation:   We have a couple of related needs:  We need to have receiver controlled disposition of funds (e.g. you should be able to elect to have a multi-party secured wallet _personally_ without burdening people who send to you),  we need this to have a compact representation both as an address (600 byte address have severe usability problems) and in the chain (so the sender doesn't have to pay larger fees just because you have a complicated escrow for your account),  and ideally we'd like to move more of the blockchain storage from outputs to inputs because inputs are always prunable so this will help tame chain bloat in the future.

After some discussion it was proposed that we add a new opcode, OP_EVAL which would allow a transaction validated by a script provided in the transaction itself.  With a solution in hand, no more alternatives were considered and implementation was performed.

Things were looking pretty good for about a month, but then Roconnor went to implement OP_EVAL in his own implementation of the bitcoin blockchain validation code and he immediately sounded alarms:  He found some serious bugs in the OP_EVAL implementation (which were quickly fixed), but he also had a more fundamental complaint:  OP_EVAL makes script turing complete, and breaks the ability to statically analyze scripts.

At least the former part wasn't unknown to the other developers— but I don't think we'd thought through the consequences completely because adding turing completeness wasn't at all one of the goals (see the list above), it was a side effect. A side effect we thought was tamed by recursion limits (which weren't actually working), but the recursion limits aren't enough to recover the analyizability of script that is lost.

Analyiziability is important because its what allows you to make definite, accurate, statements about what a script will and won't do without actually executing it.  It also makes it possible to write implementations of bitcoin with stronger concrete and auditable statements about their security.   It's the property that lets you uphold the security principle of "validate input; then act on it".   Because the bitcoin system's security comes _PURELY_ from software— it doesn't matter how great Gavin is, he can't reverse your transactions if they go wrong due to software bugs—  its very important for the continued adoption of bitcoin that we be able to back it up with the most secure software possible, and that we be able to prove that security to skeptics.

Roconnor's concerns came very late in the process, but they deserved a lot of weight: As one of few people who have implemented the whole system from scratch (not even something Gavin can say of himself) he has a important and almost-unique perspective,  he can also rightfully be considered an expert in the field of formal software validation, and his concerns came packaged with real security vulnerabilities that everyone else had missed— proving his deep understanding of the code.   TD, author of the BitcoinJ implementation, had already expressed serious reservations about the whole thing.

Perhaps most significantly for me is this simple fact:   Script was very clearly designed by Satoshi to NOT be turing complete, and considerable effort was made in this design to achieve this property. The second sentence of the description of script on our wiki says "It is purposefully not Turing-complete, with no loops.".  It seems foolish to me to abandon a core design principle of script, one which greatly helps in reasoning about its security, without a darn good reason.  And we don't have a reason at all— our purpose had nothing to do with turing-completeness, that was just a side effect.  (the size limits of script and limited IO make it pretty hard to come up with anything where the turing completeness is actually useful)

After further discussion and iteration over roughly a half dozen other proposals it was realized that it was possible to accomplish _exactly_ the original goals, in a much simpler manner, without introducing Turing completeness.  This is what P2SH does.   I personally think that if we'd come up with the idea of P2SH first, we would have stopped there and never considered OP_EVAL.

Unfortunately,  Luke has taken this position that I consider weird:  That P2SH is bad because it's a special case instead of being a regular opcode that executes arbitrary code, and this special-caseness makes it inelegant.  My own position is that none of this is natural law: every behavior is a special case and happens only because the software says it so— some parts are more regular than others but what we should care about is implementation complexity and P2SH's complexity is very low.

What perplexes me more is that Luke stated he would withhold his complains if the 'other developers' announced that "Bitcoin 2.0" (whatever that would be) would only use P2SH style transactions and that non-P2SH would be deprecated.  I think a lot of people who have considered this consider it a likelihood— the potential pruning savings of P2SH style transactions are tremendous and could significantly reduce spam risks,  but no one can make promises about a future system which doesn't exist and may not involve the current developers or may never exist.

[It was also unfortunate that Luke had other commitments at the weekly development meeting where ~everyone else decided that P2SH was an acceptable compromise,  so he sort of appeared two days later complaining about it after it was perceived by many other people as already settled. As a result not a lot of care has been given to his complaints, even though he has been pretty persistent about them]


I fail to see a lot of genuineness in complaints that take the form of "do it completely, or not at all, a little isn't acceptable" unless there is a good reason that the moderate path is a bad one, and I don't see any reason why the moderate path is a bad one here.

P2SH is a good technical solution which addresses our needs and which has decreased complexity and risk compared to OP_EVAL.   Should there ever be a need for the turing completeness that OP_EVAL offers enough to justify the costs/risks then it could be deployed, P2SH does not preclude the possibility of OP_EVAL in the future.

Yes, thats why I posted it. I was more entropy than I thought.


You keep adding things.  In your first suggestion you said DOB plus email but maybe not email.    Fine, if you add enough stuff there you'll make the multiparty speedup ineffective.   This still does nothing against attacking individual users where all that data is completely known.

(Add too much and you also create vulnerabilities that they'll get the data wrong later.  E.g. If you ask for name I might give you 'greg maxwell' 'gmaxwell 'gregory maxwell' 'Gregory Maxwell' etc.  I recently had to go through some pain to get my access to a banking site fixed because I was unable to reproduce the answers they required for the special trapdoor questions— because all the options they had were inapplicable to me, I don't have a favorite sports team, or own a pet, etc.)


Because a lot of users will get tired of the bullshit questions, or mistake them for personal-data-collection that might identify them to other people, and leave them blank or put a dot in them.

But:


Right, so you're spending a lot of effort there on something which does nothing against a targeted attack.


You have me there: Nothing is IMPOSSIBLE so long as you keep moving the target.    But if you're willing to go that far, why not go the whole way and take 128 bits of honest-to-god non-user-generated entropy and not need to have a silly argument of ever escalating measures and arm waving about my-strengthening-is-really-good-I-promise in order to convince people that it's secure,  while simultaneously armoring the system against the random idiots who is going to make their key "bitcoin bitcoin bitcoin bitcoin bitcoin 1234" and then make headlines when they get robbed.


I have three different genuinely random 128 bit keys memorized with electrum style conversion to words. I'm not especially good at memorizing. ::shrugs::  "So please don't tell me it IMPOSSIBLE"  


You can stop at that one, it's what I suggested in my original message. If the basis of the wallet is known high entropy stuff with enough entropy to meet regular cryptographic standards (e.g. ~>=128 bits) then there is no need for further discussion.


Not exactly, my contention was the you kept describing 'deterministic' wallets as being based exclusively on a user provided pass-phrase. This kind of scheme is flawed and naively weak,— and moreover that it would be recognized as much by almost anyone who has spent much time thinking about or researching the subject— and I haven't moved an inch from that position.  Rather: You've moved from your position of pure user provided data to adding actual randomness, though not quite enough for me to actually declare your proposals secure, so sadly I can't join you in declaring victory.

If I created dispute simply by being unclear about my position, then I apologize.  I really wasn't trying to argue that there had to be a backup (though I think there should be)— and my original post explicitly mentioned the possibility of the user memorizing a decently sized machine generated random number after converting it to a friendly form.  My position was only that there needs to be enough actual entropy to get near 128 bits of security and that users will not provide even enough security to get by with strengthening (a fact you implicitly admit by suggesting the need of demographic "salt" to prevent collisions, but fail to acknowledge that the same weak passwords that lead to collisions are also a problem in targeted attacks where the salt doesn't help!).

I might be able to, if your billion fold hardening was the addition operator or if you were calculating the 'billion fold' vs a memcpy, then I absolutely could (and of course the amount of 'salt' is irrelevant in such a statement). But that was never my contention.

My contention was instead that a system that attempted to work this way would be insecure _in practice_ due to human factors, and/or weaknesses in the strengthening system (which is not provably strong— e.g. it could actually by like my 'addition' example, and so it becomes an large additional assumption).


You can't win this sub-argument.  People forget passwords all the time— what if you get sick or hit on the head and lose a few chunks of your memory?  And you could remember an electrum seed sequence and make your memory your only backup if you want, at lest if you're the kind of person who would have any hope of remembering a secure password otherwise.

The difference there being the failure mode: Assuming the user would do something poorly, it's more secure if he leaves his backups carelessly laying around than if he uses a low entropy password (like "e352e8bceb", "8W3G7Pds9712++", or "7XiBKeJe5ochSqVW") that someone could simply bruteforce.   Sloppy backups, or especially sloppy backups plus a weak password, is simply more secure than a weak password.

And what if he emails it to himself? He can still be protected by passphrase. How is that less secure then any seed information not existing at all?   Even if you assume that he might use a somewhat weaker pass-phrase due to the existence of the stored entropy an attacker would still have to compromise his email account. Do you really think the false-confidence-induced entropy loss is going to be more harm than have-to-also-find-and-crack-his-email is a gain?

I'm responding mostly out of mathmatical interest and because I'd gone through the trouble of writing this post before I saw that you'd persisted in your yelling.


They aren't randomly distributed, people like to #@$@ on some dates more than others resulting in more births on some days than others.

The FCC ham radio callsign database is the only thing I have handy with a lot of birth dates in it.. With 723624 entries, it is a pretty good sample.


But the actual entropy is greater than I expected: 8.513275 bits,  8.510952 dropping the leap-day.

But this doesn't matter— say you get your 14.58 bits of DOB salt (the entropy from the FCC database for the full DOB), then an attacker going after only a million users simultaneously still enjoys a 40x speedup over a scalar attacker.

If they are chosen randomly. Which almost always they won't be if you allow the user to do it.

40 bit searches aren't that hard either— I did a bigger search that 40 bits to find the signature at the bottom of this post.  You can argue that your strengthening makes that impossible but the security of strengthening is pretty squishy.  


Preventing accidental collision just hides the actual insecurity of the system. If there was any risk of accidental collision then the risk of compromise by a savvy attacker with a good probability model is much greater.


If you don't let the user choose, you have what I suggested in my original post except without enough entropy.  The scheme electrum  uses only 12 words taken from a dictionary that uses words which are distinct and easily memorable and provides 128 bits of entropy.

If you offer the [generate new] you lose at least log2(average clicks) of entropy from the clicking, but probably more because users will just click until they hit a password with usually low markov entropy, e.g. they'll self-select insecure sequences because those ones are more memorable and it's exactly that process the attacker will model.

If the dictionary is well chosen you can have acceptable machine generated seeds which users can reasonably memorize without compromising on entropy.


Please, stop conflating 'deterministic' with shit-in-your-memory. They are not the same. A wallet which was based on a cryptographic PRNG with two megabytes of starting state would absolutely be deterministic but could never be memorized.  (also— please don't yell, it's not polite)

If you add the qualification, "while in the hands of a large collection of actual users", which of course is the goal of anyone writing software worth discussing here,  then it absolutely is true, at least if you're going to insist that purely random electrum seeds aren't easy to memorize.

(I think the memorability of electrum seeds is debatable. The kind of user who might have a fighting chance of using a pure password scheme securely will have no trouble memorizing an electrum seed. Joe-blow not so much. The difference here is that in a password only scheme joe-blow— who happens to work at mtgox— would get owned, lose 100,000 of other people's bitcoins and send our reputation into the trash,  while in the electrum/armory like scheme he'd take the require 30 seconds to make a backup and everything would stay secure)

That isn't "salt" by anyone's definition,  it's additional structured very low entropy passphrase material— which might do enough to keep the horrible insecurity of the system from casually being discovered (much in the same way as the debian breakage of openssl still leaving the PID as a source of randomness preventing that flaw from being discovered for years) but it wouldn't actually make the system acceptably secure.

128 bits isn't an absolute requirement, it's a comfortable rule of thumb.  You can arrive at basically this number by making conservative estimates about the energy requirements of brute force (e.g. assuming an optimal classical computer, incrementing a counter, requires about 240 million tons of tnt energy equivalent to increment from 0 to 2^128-1, which is clearly secure against whatever threat model or algorithmic speedups you wish to suppose)

This, plus the fact that 128 bits of security is almost always very cheap to have has resulted in the conventional wisdom that cryptosystems with less security than that are snake oil.    You can probably drop a couple bits and wave claims of strengthening at it and pass the smell test, but not much more than that.

The whole bitcoin system was designed to provide at least 128 bits of security for this reason.


Because most attackers will not have the encrypted wallet. Your security is passphrase PLUS wallet, which is an enormously higher standard than just passphrase. Belt and suspenders.  And what I'm describing for deterministic wallets is effectively the same:  Something you have (the random seed) and something you know (the passphrase).

Moreover, you can't actually measure entropy. You can make guesses based on assumed source models,  but you don't really know it unless you generated it.  Rejecting passwords by some simplistic model actually reduces entropy.


Whoa whoa whoa.  Full stop.  Salt?  Where does this 'salt' come from?  If you make the 'salt' at least 128 bits and store it you have _exactly_ what I've described.  And that's a fine thing: so long as there is enough entropy from strongly random sources to make blind attacks infeasible then its all good.  But you still have to record that salt someplace.
(and if you're strengthening you also need to store the strengthening amount, unless you always strengthen to the least common denominator)

It's pretty hard to reason about strengthening, because you can't generally prove that there isn't a way to shortcut it. In fact, if you assume quantum computation you get a minimum speedup of sqrt(n) for any possible strengthening scheme.  Strengthening has practical value and should be used whenever weak passwords might be used, but it's not a replacement for real entropy.
 

You're assuming that the passphrase has 40 bits of entropy, this is a fundamental error.  Multiple studies have shown that its basically impossible to get high entropy passphrases from humans, even if you give them excellent advice.  People on this forum have frequently bragged about their oh so secure schemes, which actually provide fairly little entropy.   This isn't because they're bad or stupid, or because they deserved to get robbed— being random is something that humans are just not good at.

(The 30 minutes assumption is insane too— almost all users would choose a less secure alternative over waiting 30 minutes—  but whatever, taking off a factor of 100 isn't what breaks your argument)

Moreover, even if the user is bad and stupid and deserves to get robbed— when they _do_ get robbed the reputation of the whole system is called into question. Responsible security conscious developers build systems which remain secure even in the face of user stupidity— ones which only fail in the face of unstoppable heroic stupidity whos stupidity would be obvious to even the most unsophisticated observers.

Even the most intelligent users will sometimes make boneheaded moves, so even if you're confident that you're better than the typical user— you still should strongly prefer software that isn't gratuitously vulnerable to operator error. Any developer who isn't assuming that their users will make mistakes, will choose passwords with less entropy then they think they have, will leak partial passwords to shoulder surfers, etc. just hasn't studied the problem space hard enough.

You should take care to not describe a deterministic wallet as requiring no backup at all, ever.  I'm completely confident that the official client will _never_ implement a deterministic wallet that has no known-random component. Moreover, you should not use any client which implements such a thing because its developers obviously have a poor grasp on security.

Instead, what you would have is a deterministic wallet with a random component with at least 128 bits of real entropy. Perhaps it can convert it into a special list of words that you can memorize if you really want (e.g. electrum does this) plus whatever pass-phrase you use,  you'd backup this random data _once_.  Then you don't have to back it up anymore.  (it's, in fact, arguably better to actually leave the password out of the generation and only use it to decrypt the stored seed— so that its possible for you to change the password if you worry that someone might have seen you type it in)

You should sit down and do the math — the value to you in destroy other people's bitcoin is very small unless you happen to own most of the bitcoin, far less value than stealing it.  In fact the attacker is best off living that potential victim alone, because his bitcoins will be worth more if people are not afraid to use bitcoin due to the attacks.


Attempts to destroy your bitcoin can also be foiled with a simple offline backup— a $2 usb key or two is cheap insurance. You're a fool if you don't have an offline backup because dataloss happens even when there are no attackers.

'Backing up' to the blockchain is a horrific idea. It would provide no security (what is the point of 'secret' data which is known to everyone) over just using the password alone— and using a password alone is itself a terrible idea because people are bad at producing strong passwords even when they are trying, it would burden the bitcoin network and prematurely degrade our decenteralization.

You can't tell if a txn involves you in the checkmultisig case, either, fwiw.   If clients start tracking and showing users every transaction that mentions an address they have people will just start spamming the network with 2-of-3's where one of the users is a random person.

But more significantly, thats not the case where this P2SH matters most— P2SH style transactions have two most important qualities— they move the storage from output scripts, which are more expensive to store, to input scripts which are less expensive because they are always prunable,  and they allow a recipient of funds to specify their own payment rules in a compact address (and take the fee burden related to complicated payout rules themselves).   This means I can have a multi-agent trust for my organization or a multi-device escrow for my own wallet without having to burden everyone that sends me funds.

Absolutely.

I'm not superkeen on the weird salt string. We really don't need any more mystic Satoshi worship around here. Just make it something boring like "pbkdf2minikey".

The iteration count function should also not allow stupidly small values 2^((n>>2)+13) would be more reasonable.  This should speed up generation for most sane cases, as it will avoid values tuning up to be too weak to be usable.

OMG! is that why it's called Diablo miner???


Indeed, I probably had two dozen "oh heck yea, this breaks it! ... oh wait" moments while learning about it, reading the papers, reading the source, etc. I had the good sense, however, to not go all high and mighty on the forums until I had at least half a clue.  Listen before you speak is reasonable standard of behavior, and it's not wrong to hold people to it via an occasional bit of mockery when it results in a mock-worthy event.
FWIW, it's also good to point out testnet.  The OP claimed hesitance in attacking bitcoin proper: Thats a good thing, since it's a system many people use. But we have testnet mode specifically for this purpose.  You can test on testnet without fear of upsetting/hurting anyone and without losing much of value if you end up burning coins.   Bitcoin can be started in testnet mode with the -testnet parameter.

I believe in current code the upper bound on the fee with default settings is 0.05 BTC— above that the transaction would have to be bigger then the client is willing to generate. (it would take a great number of ins/outs to hit that but I'm not sure how many— but since it depends on inputs too it's hard to give you a simple function)

I'm fairly doubtful that code is going to get released— he was looking for investors, presumably to fund a private farm with that design. So unless you're planning on duplicating the work yourself (with substantial effort since he appeared to be carefully non-specific about the solutions to the problems he's encountered) don't be counting on running anything based on a three ring design anytime soon.

No.
The parent post is borderline-gibberish that betrays fundamental misunderstandings of Bitcoin on several levels.
Yes, using editing tools you can make your wallet display crazy stuff. No, the crazy stuff has no influence on the outside world.  No, it's not a "security issue"— if you don't want your software displaying crazy stuff don't use recovery tools to twiddle with the non-user-serviceable parts. It's actually unlikely that the crazy values can will actually cause the loss of bitcoin, but not impossible (e.g. if you delete the private keys).
Any negative numbers are meaningless in the context of the whole system Bitcoin tracks coins (transactions) not balances, and it certainly doesn't track bitcoind _account_ balanaces which are a purely local book-keeping function.
As far as the rest goes— Yes, you can remove coins from Bitcoin forever but you don't need his elaborate series of steps. Just send coins to a wallet which has no backups and destroy the wallet data and the coins are lost.  Yippie! more scarcity for everyone else.

Interesting, but how do you plan on reconciling the hyperspatial hash-cascades, especially in the face of multiphasic avalanche? I would expect the Kullback-Leibler divergence in any such system would tend to infinity. The result would indubitably carry a non-trivial risk of oedipal collision with the motherbase-prime and, accordingly, an attacker employing Pollard's less popular kangaroo vis-à-vis your euclidean multi-metric could identify vari-wallet Nash-distinguishers against the lineage in constant time (assuming a tradeoff with a very modest log n quantum pre-computation step and n-th Ackermann order storage), certainly no one here needs any explanation as to why this would be a terrible outcome.

I recently read of a system described in an IEEE journal which could potentially be profitably incorporated into a mining system for such a multigenerational token architecture as you describe which might address some of these challenges, or alternatively, applied by an attacker in order to achieve negative time compromises. If combined with a retroencabulator, the potential for cross-chain synergy would be unprecedented.

Perhaps you should consider it.

I don't think I even heard about it for several days later, are you sure about that?

And what I posted about wasn't even the attack that actually happened. Though I'd love to take credit realizing that lots of inputs would gum up the wallet, which is so obvious in retrospect,  what I was pointing out was that the fees were out of wack.  Moreover, I was interested in finding out if it was easier to influence chain fee policy in a chain which was mostly solomined (as ltc was at the time).    At the time the attack irritated me as much as anyone else— it screwed up my mining psychology experiment by providing a non-selfish motivation for changing the fee schedule.

Here is the thread for anyone interested https://bitcointalk.org/index.php?topic=51915.0.  I don't think I ever saw any of the posts in it after the first until just now. I knew about the attacks from IRC (and from seeing my own blockchain copies grow).

Unlikely Luke I don't think Litecoin is a scam. It may be ultimately pointless, as Art convinced me when I suggested scrypt POW in #bitcoin-dev a long time before litecoin— the cpu pow really means that only criminals can mine it profitably (perhaps ultimately a fate for Bitcoin too), and the increased block rate makes it actually 4x less lite than bitcoin when you have a pruning node.  But I've never had anything against worse than those reservations against it, and have defended it against people trying to spread "dark pool fud" here.

Well you came in blablah about coiledcoin, it was trolling as far as I could tell.   I'm not very active in #eligius but luke wasn't around at the time.   I got a talking to as a result of that kick— he's a lot more tolerant of casual trolling than I am, and I wasn't aware that he'd been hanging out in your channel.  Sorry about that.

I had nothing to do with the litecoin dustspam attack, except for potentially forseeing part of it as a consequence of the anti-dos rules being unchanged from bitcoin and totally out of wack with the low currency value and fast chain speed (though the fact that the attacker would send to pre-existing addresses in order to slow down wallets wasn't even something I'd guessed would happen), and I posted patches to correct it ahead of the attack.

I'd appreciate it if you edited your message to retract this claim, as well as any other places where you've made it.

Thanks.