Please show me a statement made by Gavin which is inaccurate or a personal attack.

The whole characterization of Luke vs Gavin is nonsense to begin with. BIP16 arose out of combining a half dozen proposals, it was a _consensus_ proposal. At the regular development meeting that produced it no one was objecting to it at the end (partially no one because Luke had to leave early, before he left he indicated that he would only support it if some language about deprecating non-BIP16 transactions was added to the BIP).


Come on, you know it's not the same. A single BIP17 stealer hidden on tor with only one connection to the network will be 100% effective (in an network without P2SH validation, of course). A BIP16 stealer is only 100% effective if run by a large miner, otherwise it is only X% effective in cases where the stealer is on the shortest path between the spender and X% of the mining hash power.   I agree that it's a corner case, but there is a difference there.

This isn't true.  Yes, Gavin created a bot that exploits a differential weakness of BIP17 vs BIP16. This was pretty helpful as luke was insisting there was no difference, and this let us feel out how the difference actually mattered.

This doesn't make testing impossible, and there are in fact test transaction there. It actually aided testing and helped find some misbehavior in the software Luke was running with BIP17.

I have mined testnet for Luke several times to aid in his testing (and, in fact, did a costly 40 blockish reorg for him).

I think it's unfortunate that both Tycho and Genjix are both spreading overt misinformation here in order to create controversy.  (Tycho making insane claims that testing BIP17 is impossible, Genjix with falsely describing this as a "vote", claiming that people don't want you to know about this open and widely discussed matter, the over the top subject line)

The kind of hysteria being promoted here is a very big disincentive to contributing technically to bitcoin. I encourage everyone to be patient and thoughtful and recognize that bitcoin can not survive if people with powerful media presences are able to disrupt development and exhaust the developers at will.  Discussion is great, but consider whos interest panic is well aligned with: Certainly not the interest of the Bitcoin using community. Don't let your emotions be manipulated.

This isn't the case. QC only gives a sqrt(N) speedup for generic blackbox non-linear inversion.  So on a magical pixie dust computer a 256 bit hash function has the same security as a 128 bit hash function has on a classical computer that does the same number of operations per second.

There are QC strong versions of all the applicable cryptographic operations, we don't use them only because they have much higher overhead (like 16kbyte signatures), but the mass media loves to over-hype the capabilities of (still non-existent) quantum computers so you never hear about them.

The scheme of H(pubkey) addresses in Bitcoin is a bit of insurance against many kinds of ECDSA (classical or otherwise) weakining.

P2SH (of any kind) largely preserve this property, though they may slightly increase exposure to classical cryptanalytic attacks because they allow an attacker almost arbitrary stuffing to produce a matching address without also having to solve the discrete log problem. E.g. with current addresses an attacker doesn't just have to find a preimage, he'd have to find one that he knows the ECDSA private key for. Under P2SH there is a wider variety of acceptable inputs.

That said, even if we used the now-compromised MD5 algorithm the practical MD chosen prefix collision attack there couldn't be used to steal random people's money with P2SH (because it requires the attacker produce both messages, it's not a preimage attack) though it might permit an attacker to generate an unusual escrow script  which could also be redeemed under a second set of rules.  (Not that this weakness exists with our SHA256 much less the HASH160, but I think its useful to reason about how the system would work with parts replaced with compromised versions).

No, Luke didn't have to test on the real network.

He tested on the real network before he was aware of the stealing bot, in fact. He tested on the real network because he controls the content of the blocks of 400GH/s.  He tested on the real network because he could.

When the stealing bot was noticed and was causing Luke some trouble with continued testing I mined some 40ish blocks to reorganize testnet to undo the stealing bot so Luke could continue his testing there.  (something that I couldn't do on the real network, which is part of the reason testnet is so much better for testing)

CIDR could be implemented, as could lists... might make sense to do as part of IPv6 support.

The rate limiting I coded up is per-IP, and localhost is exempted. I also started with per-group (e.g. /16 for ipv4) but thought it too risky.

Anti-brute-force is really a protection of last resort— the attacker doesn't have to be impatient he could use dozens of IPs (e.g. tor) and scan you for months in slow motion, even if its fairly aggressive it does not have that much protective value, e.g. even it it only allowed one bad attempt per IP ever, getting 1000 IPs is not _that_ hard and would have been sufficient here. So this sort of feature has to be carefully weighed against the DOS vulnerabilities it might create.

The real hope of this kind of protection is to reduce the odds of success and increase the cost of attacking enough so that few people bother attacking in the first place... creating a kind of protective halo of disinterest around the few users where all of the other better protections have failed.

And in the process actually leaks information about the length of the password, though admittadly not much it's still kind of embarrassing since it lets the attacker know when their attack is likely to be profitable or not.

I have a patch in progress which improves logging and does the rate limiting. Being sure it doesn't create a dos and isn't gratuitously incompatible with the threaded RPC is why it's not already a pull request.  (also, I'm kinda uncomfortable about timeouts in the code since it's currently single threaded... any simple implementation of delays is an automatic DOS).

(the improved logging is important because it makes it slightly more likely that the attacker will get caught, but mostly because right now the vague logging causes people to open up allowip more than required because it's not clear why their requests are being rejected, especially as we have pretty weird wildcarding syntax)

And yes— m3ta had to do a lot of things to create this vulnerability.   But it isn't like he did them because he was _trying_ to get robbed, he did them because various tools and capabilities in our ecosystem put him in a position where the mistake was easy to make, and anytime that happens _someone_ will make the mistake eventually— it just happened to be him.  The fact that he was exploited was also because lots of other people are vulnerable too, otherwise the attackers wouldn't exist.

(And if you saw this thread and didn't go check your RPC and firewall settings, just to be sure, you're a fool— in my view)

If you look at industrial accidents there is a constant pattern in most of them— some stupendous feat of human error managed to bypass several safeties designed to prevent human error, all at the same time.   If you focus on the magnitude of the human error, you'll do nothing to reduce the incidence of failure in the future. Human error is a natural force as unstoppable as gravity.  We should build systems which have every worthwhile immunity, because the human failure is not going to go away. (It's going to get a lot worse, in fact, as more unsophisticated users adopt bitcoin)

In addition to some belts an suspenders in resisting basic brute-force attacks there are other things that could be done. There are _other_ daemons with similar RPC ports that don't have this problem because the daemon itself generates a default key and puts it in the file. e.g. Chrony.

This is an archived thread of P2Pool discussion.

See the new thread for more recent P2Pool discussion.

In the time since P2Pool's original announcement it has evolved considerably.  I thought  having to wade through hundreds of pages of inapplicable cruft about old versions of the software to get to useful information was a disservice to people here, so I split off the old discussion to a separate archival thread.

P2Pool has come a long way since its humble beginnings: It's now a completely realistic solution for a great many miners. The software is still rapidly developing but it is reliable, featureful, and, of course, P2Pool is critical for the health and welfare of the Bitcoin system: Our trust in the Bitcoin system depends on it being highly decentralized. P2Pool prevents the centralization that non-distributed pools create.  This is important enough to people that P2Pool miners are currently being paid by Bitcoin users to participate.  P2Pool pools payments but mining decisions are still left to all the miners just as bitcoin was intended to work.

This "pool" (really a decentralized/distributed network just like Bitcoin) is still attractive even for people who aren't thinking about the health of Bitcoin overall. P2pool's decentralization is accomplished without compromising on miner profits and, unlike solo mining, while still allowing stable income. The things which p2pool can't do, like provide the utmost low variance (PPS) are offset by the lack of fees and by removing the risk of cheating by pool operators (which is almost undetectable if only done in moderation).

P2Pool isn't ideal for low speed (e.g. CPU) miners, and may never be— but it's absolutely a no brainier for anyone who would even consider solo-mining and a good majority of the people in between.

I'm personally really happy about the new built in per-worker graphs:


I hope to see more useful monitoring features in the future.

Yup. And it bears repeating, it's an idiotic voting system— even if it weren't getting ignored as spam,  miners could just willy nilly pick the election outcomes by simply refusing to mine 'votes' for particular addresses.

POW chain systems are amazing, but they're not good for votes except of very specialized kinds.

I encourage people to work on cryptosystem powered voting. But while many in the bitcoin community will be interested in it and would be glad to use it, such systems shouldn't be build on bitcoin itself. It's not a good fit technically nor cramming unrelated data into bitcoin welcome by people who want bitcoin to be used as a decentralized currency.

This is true for regular pools too! The pool will only credit you for work matching a header they gave you.

Kudos to the writers. I think they covered the subject matter pretty reasonably.

The parody of the weusecoins video was a riot. Can we get a copy of that?

Ah!  Please nag the authors of that software to implement the same anti-dos fee rules as are in the reference client. The rules in the client are there to protect the client from the network not processing it's transactions. Your experience is an example of this— sometimes people miss the importance of it simply because so few txn hit the mandatory fee rules (though subcent output ones always do).

I don't know what the resend policy is for that client. In the reference client it will remember transactions forever that it was a party to (which I'm sure the android one does too), and it will rebroadcast them after a random delay with a maximum of 30 minutes every time a block has been solved since the last rebroadcast without including them.

This isn't weird in the _slightest_. Though just about all nodes will happily mine normal zero fee txn, most will not mine zero fee bitdust transactions because they are indistinguishable from a DOS attack.  (And this protection being insufficient is what litcoin's chain grew from like 50 MB to about 400MB in a week or so).

Look again at the original post: "few sub-cent tx with no fees "

As far as forgetting them— the advice upthread is bad.   If you modify the wallet to make it forget about them and then leave it off for a bit,   other nodes will forget about the transaction on their own after a few hours— the memory pool has a finite lifetime.  They only remember it because the owner node keeps reminding them.

After the network has forgotten the transactions and your own node has been mindwiped,  you can respend the inputs just fine. 

Of course, modifying your wallet to remove the transactions is a big pain in the ass... but since the OP obviously modified his client software to get it to create this suspiciously-DOS-attack-like transactions which the client would have refused to generate without modification, he should have no problem trimming the wallet on his own.

Cheers.

People have different motivations behind this general functionality.

Gavin wants it so that the bitcoin software can offer wallets that require two party signoff (or two of three, or whatever).  When you spend from such a wallet you'd ask one of your second parties for a signature and they might follow up with you via SMS or a phone call.  Perhaps you are the second party yourself, with software on your mobile phone.   In any case the effect is that a hacker or trojan on your system can not steal your bitcoins.

This solves a fundamental weakness bitcoin has right now:  The security of typical desktop computers is terrible and hard to fix.  You might get 0wned up with respect to a classical banking site but they can and _will_ reverse the transactions resulting from your machine being compromised, but we can't do that with bitcoin.  If we want bitcoin to grow we have to solve this problem— bitcoin is not going to grow if it's only safely usable by Linux using security experts.

Personally, (as a Linux using security expert wannabe) I'm more excited about the prospects of using the same functionality to do escrow transactions without requiring any new functionality in the bitcoin code.   I want to sell you a car,  you  don't want me to be able to run off with your funds if the car is a lemon.  We agree to form an address (using a separate tool or potentially a JS webpage) that can only be redeemed if both of us sign off on it.  You pay to the address, putting the funds into escrow— I give you the car— if it doesn't blow up you unlock the txn and I can spend it.

You can use the same functionality to implement trusts and other kinds of fancy payment rules, — and do this all without additional changes to the bitcoin software within the same framework (though you'd need small little external programs to create the special addresses).

These things can be done without P2SH but then they'd require direct support for them in the senders software or  scary (and unwieldy) serialized script addresses, and result in lots of output side chain bloat.

Also, for the wallet-protection use case, without P2SH the _sender_ has to pay the fees related to large transaction data due to complicated rules which are required by you.
 

If you don't think the blockchain size is an issue, I invite you to delete your copy of the chain and restart your client. In 20 hours, most likely, you can tell me if you still agree with that position.    

"alternate potential solutions" are additive with this, not exclusive.  P2SH makes a fundamental improvement to the storage requirements, by moving most of the storage to the input script side it makes the size of a pruned chain much smaller. This is especially important for the large scripts that complicated escrow/trust/wallet-security addresses will require.   It's basically not possible to make the output scripts smaller than BIP 16 (P2SH): they consist of only two bytes more than the payee-hash itself.  (and those two bytes are essential for compatibility with existing nodes).

Other improvements, like public key recovery can be combined with P2SH to make the inputs sides smaller. But thats independent— and applies equally if you're using P2SH or not.

Part of the reason why this isn't a secondary concern is that the use cases that we hope to enable with P2SH would result in transactions which are 2-3x (or more) larger than standard single party transactions with all that data in the script outputs (which are potentially never prunable), so its important that the feature that enables that functionality also contain the solution to the chain bloat it potentially enables.

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.