Bitcoin Forum

Not sure if you've all been following the latest push-to-script-hash (p2sh aka OP_EVAL) discussions. OP_EVAL was Rejected because it isn't staticly analyzable (this is a useless property for Bitcoin scripts, but a nice-to-have attribute for idealistic reasons). Now Gavin has proposed a new BIP 16 "/P2SH/" to replace it. However, this replacement is far worse: it basically replaces the scripting system Bitcoin is built on with a single special-cased template. While this might be fine if BIP 16 actually proposed abolishing the current scripting system (while using the templated design to retain backward compatibility), it does not explicitly say so, and Gavin refuses to make this implied decision part of the specification/BIP. In effect, what BIP 16 proposes is the same thing as if a computer were to look for a specific program and stop you from using it unless your computer had a magic USB key for it (that is, it's not the program checking for the USB key, which would be the sane solution, but instead the computer that would be running it).

Since this is a protocol change, Gavin cannot, however, go ahead with it entirely on his own. He needs at the very least a majority of miners to go along with it, and he's mentioned 70% as the cutoff point.

Here's the catch: Gavin is forcing everyone using the latest Bitcoin code to vote for BIP 16. If you want to oppose this insane protocol change, you will need to modify your bitcoind source code or you will be voting IN FAVOUR OF IT by default (as of git master commit 922e8e2). I have written code that allows you the freedom to vote for (-p2sh) or against (-nop2sh):
    https://github.com/bitcoin/bitcoin/pull/755 (https://github.com/bitcoin/bitcoin/pull/755)
You can apply it to your bitcoind code like so:
    curl https://github.com/bitcoin/bitcoin/pull/755.diff | patch -p1

Tycho (DeepBit) has expressed dislike of /P2SH/, but has not yet committed to opposing it either. To stop this from going through, the easiest way to achieve the needed 30% is with the support of BTC Guild, BTCMine, EclipseMC, and Eligius combined. However, every little bit helps!

Also, there ARE other solutions to the P2SH need/problem. A compromise between OP_EVAL and BIP 16 would be workable, and there is at least one eval-less proposal that is even easier to statically analyze without breaking the scripting system (CODEHASHCHECK aka CHC). Gavin has thus far ignored this because he just wants to rush into a protocol upgrade to get two-factor addresses out there.

For reference:

• OP_EVAL (BIP 12) is at https://en.bitcoin.it/wiki/BIP_0012
• /P2SH/ (BIP 16) is at https://en.bitcoin.it/wiki/BIP_0016
• CODEHASHCHECK is summarized at https://bitcointalk.org/index.php?topic=56969.msg687795#msg687795 (https://bitcointalk.org/index.php?topic=56969.msg687795#msg687795)

Please let me know if your pool will support or oppose BIP 16.

Luke
Eligius

P.S. Why is static analysis useless for Bitcoin? Because you need to evaluate all scripts to validate them anyway. Sure, you could reject invalid ones with too many signature checks early, but there are equal and better ways to attempt a DoS without these (for example, including exactly the maximum signature checks, then failing for some entirely unrelated reason).

Luke, you try my patience.

I'm going to step away from the code for a few days to calm down before I do something stupid because my patience is wearing thin.

I've been trying to figure out your opposition to P2SH for a while now.  Your premise seems to be wrong, as far as I can tell, so you are coming to an incorrect conclusion.

Your premise, clearly stated here, is that Gavin is trying to replace the current script system.  That does not appear to be the case at all.  P2SH uses the exact same script system that we've been using all along, the only difference is when the script appears.

In the current system, the script is presented to the network when the transaction is created.  In P2SH, the script is presented when the transaction is redeemed.

There is no other change that I can see.  No one is suggesting that we abandon the current scripting system.  P2SH actually uses the current system to expand itself.  It also enables addresses that correspond to arbitrary protection schemes, rather than needing a new type of special address for every type of recipient wallet.

Also, can you try to explain OP_CODEHASHCHECK better?  I really can't see what problem it is attempting to solve.

Luke.. from a miners position i got to tell you: Just stop it. You make yourself as ridicolous as RealSolid is for a long while and for the same reasons: in the last few days you act like an arrogant self-righteous asshole. I know you will end up telling us about freedom of open source and democtratic elections and stuff, but tell you what - i dont give a shit about that. I like the way bitcoin was handled till now and if Gavin decides one way i trsut HIM more than you to make the right choice since lately you have shown a grade of mental instability that is only comparable to RealSolid.

So, just stop your erratic behaviour or fuck off. Bitcoin can survive better without you at the moment than with you with your current attitude.

Sorry to all for the harsh tone, but i tried to keep out of trouble a while now but the day came i finally had to respond...

If you want a monarchial currency, why not just use the Fed's USD? Gavin isn't perfect, and this is one example. Sorry you consider making people aware of a problem to be "mental instability".

I would prefer to hear your response to kjj, who seems to be making salient points.

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." (https://en.bitcoin.it/wiki/Script).  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.

This would've been a lot better received if it was brought up while the technical discussions were still ongoing. I originally proposed something like OP_EVAL in https://bitcointalk.org/index.php?topic=46429 (https://bitcointalk.org/index.php?topic=46429), and I think P2SH achieves everything I wanted out of that. CODEHASHCHECK is arguably better, but only slightly - certainly not by enough to justify delaying deployment. Getting some sort of multisig transactions working is rather urgent, and P2SH is the implementation we have, and it carefully avoids opening any cans of worms.

What this really seems to be about is politics - LukeJr is uncomfortable with Gavin having the power to alter the Bitcoin protocol. I think that this power should be phased out eventually--but not yet. We'll mark that transition with a "1.0" version number. We still need protocol improvements. Gavin's shown no indication that he'd ever abuse his position, and he's the only one who's actually putting in the work required. And this is a really bad time to start a power struggle, because LukeJr isn't really going against Gavin - he's going against the output of a community discussion which he didn't take part in.

(As for the technical side - the issue seems to be that P2SH introduces a new interaction between the concept of "standard transactions" and the scripting system. Before, a transaction would be accepted if it was standard and the script returned success; now there's an additional requirement, which is that one of the standard transaction types now calls for you to rerun the script in a different way. This means that the "standard transactions" concept is now actually part of the scripting system, rather than a secondary sanity check, so it can't be fully dropped in the future. However, the special case is on the sender-script side, and I don't think allowing nonstandard scripts there was ever plausibly a good idea. I do still want to see the standard-transaction types broadened to include fancy tricks with time locking, but that's considerably less urgent.)

I've raised the issue with Gavin more than once. He seems to have been going out of his way to ignore it and force his decision on everyone. I can't just give him all the time in the world because he has set a deadline only a month away; so miner awareness needs to begin now.

Please don't imply this is security-related, or that static analysis provides any security advantage. While it does optimize rule checking in cases that will never matter, it doesn't provide any practical benefit for security.

More foolish to abandon the concept of scriptPubKey being a script entirely (as BIP 16 does), yet still support it being used as a script. OP_EVAL wasn't perfect, but at least the script remained a script.

I wasn't asking for any promises about the future. I was simply saying "if we're going to replace the script with a single hash, let's actually do that"; that is, the BIP should explicitly say "scriptPubKey is considered deprecated and is replaced with hashRedeemScript. For the sake of backward compatibility, hashRedeemScript must be formatted <like so>, and if it is found not to be formatted like this, it is to be interpreted as a legacy scriptPubKey for compatibility only."

In the current script system every operation has a purpose and scripts executes in a methodical order (http://pastehtml.com/view/bkmlakf30.html). When P2SH is introduced scripts can no longer be executed simply by interpreting the instructions. P2SH undermines the scripting language because it requires that if the interpreter spots a specific template do something else rather than execute the script.

Take the a standard P2SH template:

scriptSig: [signature] [serializedScript]
scriptPubKey: OP_HASH160 [serializedScriptHash] OP_EQUAL

If it were to follow the rules of the scripting system exactly as it is now it would always return true.

[signature] [serializedScript] OP_HASH160 [serializedScriptHash] OP_EQUAL
[signature] [serializedScript] [serializedScriptHashA] [serializedScriptHash] OP_EQUAL

There is no operation to stay that  [serializedScript] should be deserialized and run. At least OP_EVAL & OP_CODEHASHCHECK follow the rules.

Btw I am not opposed to this for any political reasons, I think Gavin does an absolutely superb job as project leader, it just seems like a short sighted change to me.

That's a good point, but it's a negative point. "Standard" scripts is merely miner bias. It's a flaw that the software developer is allowed to force his biases on miners, as it is right now, and making "standard" transactions a protocol thing would make the problem even worse. Miners are free to choose what transactions they accept on an individual basis, and work should be done to make that easier, not harder. That is, "standard" transactions should be undefined entirely. Eligius already will accept any transaction, "standard" or not, without bias.

While I disagree strongly with the monarchial powers being given to Gavin, that is not the basis for my objection to BIP 16 specifically.

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.

Who says it's urgent? Is someone paying money for developing it fast?

The proposed change is quite major as it changes the logic of accepting blocks in the blockchain and it'll require all miners to upgrade. I was under the impression that such changes (i.e. increasing the block size limit) would be implemented and discussed years in advance of going live, and here we have a proposal that's only a month away!

OP_EVAL is one example where too quick a change could've been catastrophic and no-one had really thought of it until Roconnor came along.

Therefore my vote is a NO - this change is way too quick. Rushing it faster by flagging it as urgent is in my opinion dangerous.

EDIT - added:

DISCLAIMER: I don't fully understand the change, so may be wrong there.

I agree. P2SH would probably work OK, but it's not consistent with the rest of Script, so I would prefer that it not be used.

(I voted for both P2SH and CODEHASHCHECK in the poll, since I think they're both acceptable solutions.)

Did you read gmaxwell's long post above?

I'm guessing he's looking for a TL;DR explanation ;D
That text wall (I did read it) covered an entire page on my 2048x1154 monitor at full screen ;D

It isn't just stolen wallets.  It allows a range of potential applications where it takes 2 entities to release funds.

Bitcoin needs mutli-sig.  I don't know enough to weigh in on the merits and dangers of the 3 proposed solutions but mult-sig is essential for Bitcoin to grow to the next phase.

Epoch: The problem this is solving is M-of-N multi-key addresses. It lets you set up your wallet so that there are multiple keys, stored in different places - for example, one on your computer, one on your smartphone, and one in a safe - and require that several of them be used together in order to spend coins. That way, if your computer is compromised, the attacker can't steal your coins without also compromising one of the other keys. This feature is extremely important; it would have prevented the allinvain attack, it allows corporations to hold coins without having to completely trust any one employee, and it makes escrow work better. Implementation has to be done in two stages - first adding support for it in the protocol, then second adding support for it in the user interface. We're currently on the first part, and talking about the relative merits of different ways of doing it. All of the proposals currently on the table are protocol changes that enable M-of-N multi-key addresses, and pretty much everyone agrees that at least one of the proposals must be adopted.

The short version is that right now the sender has to provide everything up front.  Say I want to set up my wallet to require "(A and B) or C" keys.  To create a transaction that can only be redeemed in that way, I need to provide three public key hashes, or about 480 bits, which makes for long addresses.  It gets worse if I'm a large corporation that wants to require 7 of 13 keys, for example, since then the address is 13*160 bits long.

P2SH lets me create my own script, then give only a single 160 bit hash (of my secret script) to someone that wants to pay me.

I'm sorta coming around to Luke's side, at least a little.  Piuk's reply (https://bitcointalk.org/index.php?topic=58579.msg690150#msg690150) to me makes it much more clear.  I still haven't figured out how OP_CODEHASHCHECK is intended to work, so I wouldn't say that I'm a convert exactly.

The problem is that there doesn't seem to be any good way to do this.  Anything we do will break old clients, potentially in dangerous ways.  Dangerous for the people using them, of course, not the network as a whole (except that one could argue that harming some users harms us all).

The super simple version on "why":
Currently Bitcoin only supports a single signature for transactions.  That leads to a whole host of potential issues, risks, and need for implicit trust (something Bitcoin was designed to reduce/eliminate).  EVENTUALLY Bitcoin needs some form of multi-sig.  Maybe not today but it does need it.  Without multi-sig too many transactions are "trust me it is safe".  That is fine for an academic experiment but for Bitcoin to grow to the next level multi-sig is essential.  Without some change mult-sig is not implementable in any useful fashion.

The proposal and debate is on HOW to allow effective implementation of a NEW capability (multi-sig).

The super simple version of "how":
We need multi-sig (see how why above)
The initial plan for multi-sig was OP_EVAL.  Simple version: it doesn't work.

Gavin's proposed solution was P2SH.  It was discussed and work is going forward.  Luke missed some meetings so his concerns are coming lake.  Luke believes it is "flawed" because it breaks existing method of handling scripts which is seems a "hack around" and "clunky".  (I think :) Reread his post for more detailed explanation).

There is an alternative CODEHASHCHECK but that would mean going back to the drawing board and could have problems of it's own.  This has been in the works for some time so I can see Gavin's desire to get it finished.

Luke claim is at this point Gavin is unwilling to back down from P2SH and it is a mistake.  Gavin counter is that P2SH is viable if not perfect.  Some believe Luke fears are excessive or overblown (read gmaxwell post for a rebutal).  I don't think it can be simplified more than that.  This is low level protocol nuts and bolts decisions.

As jimrandomh mentioned, M-of-N would allow for some important features. The protocol already supports this kind of transaction (so you could theoretically do two-factor authentication now), but there are major drawbacks. In order to do two-factor authentication with the current system, you would need to do one of these things:
- Have everyone sending you BTC use a recent Bitcoin client version and potentially pay higher fees for sending you BTC. Also, your Bitcoin addresses may be double the normal size or larger.
- Every time you receive BTC, the client will automatically need to send the received BTC back to yourself in a new transaction. Received transactions will temporarily not be protected by your two-factor authentication scheme, and you'll pay tons of extra fees.

OP_EVAL, P2SH, and CHC are some proposals for changing the protocol in a backward-compatible way so that these drawbacks are eliminated for two-factor authentication and many other possible future features that require "fancy transactions" (escrow, password-based authentication, etc.). OP_EVAL is broken and will probably not be used. P2SH is probably OK, but the specific way it is implemented is hack-like and inelegant. I like CHC.

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.

Here's my motivation for /P2SH/ or something like it:

I want to stop playing whack-a-mole with wallet stealing viruses and trojans, and I think requiring more than one private key to sign away your bitcoins is the critical feature needed to do that. Keep one set of keys on your computer, another set of keys on your cell phone, teach each to talk to the other before sending out bitcoins and you're safe (as long as a virus or trojan doesn't infect BOTH your cell phone and your computer at the same time).

The bitcoin protocol already supports that, but the bitcoin network, the bitcoin software, and the bitcoin addresses that we're all using now don't support multisignature transactions.

OP_EVAL and /P2SH/ and Luke's OP_CODEHASHCHECK are all slightly different ways of implementing multisignature transactions that are as short as the bitcoin addresses we're using today.


RE: the timeframe:

I'm pushing this hard because I'm tired of hearing that users lost their bitcoins to trojans and viruses, and getting there is a multi-step process that will take a lot longer than I'd like:

1. First a majority of miners have to validate, accept and mine the new transaction types. (that's the Feb 15 date)
2. Second we have to convince enough people to upgrade so that they are relayed around the network and not dropped
3. Finally, we can release software with wallets that use the new feature.

I'm losing patience because this process started in October, over three months ago, and certain people seem determined to do whatever they can to derail it-- if I was more conspiracy-theory-minded I would think somebody was purposely trying to keep bitcoin less secure than it can be. roconnor brought up legitimate complaints with OP_EVAL that were discussed and addressed with /P2SH/, but I can't respond to every half-baked scheme that is supposedly "better" or I will spend all of my time explaining why something like CODEHASHCHECK is a bad idea and have no time left over to making Bitcoin better.

I get the frustration of feeling lack you are being pushed back to step 1 four months after the fact.  It sucks in any project and honestly I don't know how core open source developers like you do it.  In my world (corporate closed source software) when an issue like this happens someone up the chain makes a call and we move forward (for better or worse).

Still I don't think you have a choice on the highlighted part. If you want the reason just look at the #1 & #2 you explained above. 

(Just a side note, this is exactly how I feel with Coinbaser, which has been tested and in production for almost a whole year now...)
I don't have any objection to push-to-script-hash in principle, and would prefer it be in soon too - I just don't want to see it done in a way we'll regret for years.

OP_CODEHASHCHECK is in some ways even a bugfix (OP_CHECKSIG almost does it), and seems like it could be done with much less modifications than the other two schemes, in addition to being both (much easierly!) staticly analyzable and in form with the original script design. If there are real problems with this solution, please do share them, as part of making Bitcoin better.

Just to explain for those that don't know. You can already receive payments to a split key wallet using OP_CHECKMULTISIG (https://en.bitcoin.it/wiki/BIP_0011) which is already implemented and requires no change to block validation rules. However you would need to use a double length bitcoin address. e.g.

1CCPUpxshNH5EPetALLDhz56dg3soyrHEELKLdDRCkwH1MPN1q8fcpzBA3tiRJfSY9S

you can of course can use tools like firstbits to shorten this to just a few characters. Its not ideal, but if split key wallet services can already use it I don't think there is any need to rush in something which would make irreversible changes to the concept of a bitcoin script .

Except the sender will pay the extra fees (due to larger transactions) for your security.  Obviously that relationship is backwards. 

Sender - pays more
Receiver - is safer

If you asked me for payment at that address I would ask you for another address on principle alone.

Here is an example CHC (herein called OP_CHECKHASHVERFIY or CHV) implementation. Can it get any simpler? (https://github.com/luke-jr/bitcoin/commit/51decbe12f05d32f13b455852e139d6c3c5ef82e)

Shame on you.

^this.
It's urgent, and what luke-jr doing is stalling.

And again,
Gavin write OP_EVAL, you oppose.
Gavin write P2SH, you oppose.
You propose CHC, where's the code?

With no code, you propose a vote?
 >:(

Here is my explanation of luke's proposal as I understand it. Standard script template for a single key would be:


1) Combine ScriptSig & ScriptPubKey

   <sig> OP_CODESEPARATOR <pubKey> OP_CHECKSIG <scriptHash> OP_CHECKHASHVERIFY

2) <sig> is pushed onto the stack
   
   OP_CODESEPARATOR <pubKey> OP_CHECKSIG <scriptHash> OP_CHECKHASHVERIFY

3) OP_CODESEPARATOR marks the beginning of the data to be hashed

   <pubKey> OP_CHECKSIG <scriptHash> OP_CHECKHASHVERIFY

4) <pubKey> is pushed onto the stack

   OP_CHECKSIG <scriptHash> OP_CHECKHASHVERIFY

5) OP_CHECKSIG validates <sig> and <pubkey> as normal

   <scriptHash> OP_CHECKHASHVERIFY

6) <scriptHash> is pushed onto the stack

   OP_CHECKHASHVERIFY

7) Everything from the marker that was set at OP_CODESEPARATOR up to stack -1 is hashed and compared with the top stack item e.g. <scriptHash>. If equal the script is valid.

Advantages
- Like P2SH hash enables "pay to script" functionality - transfers multiSig fees from sender to receiver & reduces muliSig blockchain bloat.
- The script interprets as a script, no magic code path based on template matching.
- Static analysis without deserializing anything.
- Fairly simple, should be just as fast to get it in use as P2SH. Luke has coded it already.

Disadvantages
- Old clients validate almost nothing, with P2SH they at least check the <scriptHash> matches the <script>
- Requires redefinition of an op code

And piuk, implement your idea, and make a pull request.

Well, luke, if you implement your CHC idea before 1st Feb, maybe you'll get that monarchial powers .  ;)

Hmm, what? I didn't/don't oppose OP_EVAL.
A few posts above yours.
I don't want monarchial powers. If people wanted a monarchial currency, they'd be using USD. I just don't want Bitcoin broken in a rush to get a new feature.

finway, spam much? Lay off the crack, dude. That was like 5 posts in as many minutes.

SInce Gavin apparently does not have time to explain why Luke's solution is bad, can someone else maybe do so?

Or is everyone still flailing around trying to find something bad about it and maybe not having much success in doing so?

-MarkM-

...

Do that please.

Code is here:

Posted 10 hours ago...

With code that make sense, does it work?  ::)
Dose is solve the "Special Case" problem?  does it cause a split?

Hey look... an explanation of what the code does earlier in the thread:


As far as I understand, old clients (miners at least) will need to be upgraded with any of these methods to ensure they don't create blocks the new code considers invalid.

RE: Why OP_CODEHASHVERIFY is bad:

First, it requires that you concatenate the scriptSig and the scriptPubKey and execute them as on Script.

Bitcoin used to validate scripts that way, but ArtForz discovered a bug in July of 2010 (the OP_RETURN bug) that allowed anybody to spend anybody else's bitcoins.  It by far Bitcoin's biggest bug and Satoshi's biggest brain-fart.

Part of the fix was to make executing the scriptSig completely independent of executing the scriptPubKey (see commit 7f7f07 in the tree if you're really interested).

Is there some other subtle bug involving the interaction of OP_CODESEPARATOR, OP_CHECKSIG, OP_IF and the proposed OP_CODEHASHVERIFY lurking? I don't know, and I'm not about to risk all of Bitcoin to find out.

Second, Luke obviously isn't very familiar with all the details of transaction validation, or he would know that a scriptPubKey needs to leave a true value on the stack or validation fails.  So either OP_CODEHASHVERIFY both verifies AND leaves a true value on the stack (in which case it is inconsistent with the other VERIFY opcodes that consumer their operands) or it should be OP_CODEHASHEQUAL.

Third, the whole reason OP_EVAL caused controversy and was withdrawn is because adding a new opcode is more risky than adding a little extra validation logic.  OP_CODEHASHVERIFY is almost as risky as OP_EVAL.

Fourth, the code Luke posted is a joke. He doesn't modify VerifyScript to combine the scriptSig and scriptPubKey, so there is no way for the code hash to get communicated between the scriptSig and the scriptPubKey.  I think he is just trying to do whatever he can to cause trouble and confusion.

strikethrough added:  I read through his code again and his code is a joke for a different reason than I thought at first glance (I missed the vchLastScript nonsense).

^ this.

I previously wrote "CODEHASHCHECK is arguably better, but only slightly". After reading Gavin's comment and the linked patch, I take that back. Introducing a non-stack interaction between scriptSig and scriptPubKey is a bad idea and a big deal, much moreso than special-case matching a script is.

The insane thing is 28% of voters picked the first two options.

Saying I don't want multi-sig is saying "I want Bitcoin to forever remain this small, overly complex, and vulnerable system used by an insignificant number of people".

This may have been a problem with my interpretation but scriptSig and scriptPubkey would not actually need to be combined if OP_CODEHASHVERIFY hashed only up to the end of scriptSig (not stack -1 as I worded it)?

I think luke just made these two options to ignore them.

Now now, DAT, implementing either P2SH or OP_CODEHASHVERIFY will hardly make the system less complex, would you agree?
Other than that, you're right on point.

I never even partook in this discussion because it's over my head as a mere miner.
Unless someone takes the time to study the code and do extensive formal algorithm analysis (we're talking of a huge amount of time here), the intricacies of changing the protocol are far over their head.
The concept of that poll is therefore laughable.

I don't like seeing Luke go crying wolf and turn to the general forum populace⁽¹⁾ for support of his cause.


(1) why else would he post this in Mining instead of Development & Technical Discussion?

Yeah, I basically added those as a control for the poll. Their results tell me the poll is worthless.

Because it's the miners who are voting and in control of the situation. Yet somehow they're being kept in the dark and forced to vote a specific way...

I'm sure that many readers don't even realize how this scripting thing is related to phone/hw authentication.

Actually I think that there should be another, better solution for multisig TXes.

No, it doesn't.

Much more likely there's a subtle bug in the more complicated BIP 16.

That's what I thought, but I didn't see that implemented in the code. In any case, it's not relevant to CHV.
It is inconsistent with the other opcodes, but that is required to remain backward compatible: it either makes the script fail entirely, or it functions as a NOP. On the other hand, BIP 16 is inconsistent with the whole script concept.

How? The reason OP_EVAL caused controversy was that it wasn't statically analyzable. This does not apply to CHV. I heard nothing of a problem with new opcodes.

At the end of scriptSig, the code from the last OP_CODESEPARATOR until the end is stored at the front of the stack. At the beginning of scriptPubKey, it is pulled off the beginning and put in a new variable only used by CHV.

I am a miner.  I don't understand any of the poll options, and I bet most miners don't. If miners don't understand the technical details (and I don't think the majority do) that leaves the vote to be decided by other merits, like who they like better, or what pool they mine at.  The different codes should be evaluated by people who have the ability to evaluate the code, not people who are stuck evaluating the authors.  Once the codes are evaluated, the pros a cons of each - in plain language - could be sent to miners and users to vote.  This change might be implemented by miners, but it affects all users. Just my 2 bitcents.

Well I guess we need to define complex.

A cellphone is incredibly complex.  The protocols that handle authentication, tower handoff, inter-carrier romaing, etc are even more complex however to the end user it is simply.  Pick up phone dial and it works.
Multi-sig adds complexity on the back end but it allows safer more secure systems on the front end.

A wallet which must be signed by both the desktop and android phone is (more) secure.  The user won't care how it works they will just know IT JUST WORKS.
A company (which posts a $100K bond) and offers to insure transactions against double spends is a complex enterprise but to the merchant IT JUST WORKS.

So it allows building robust systems which don't rely on the user having either a masters degree in information technology and network security or just putting blind trust in another company (MyBitcoin) to use effectively.

The problem is that ultimately for anything to be implemented it will need miners to vote.  They will vote by supporting the protocol with hashing power so miners need to be involved in the discussion.

If no proposal gains support of 51% of miners and at least a significant % of the nodes it will go nowhere.

So, we're basically going into higher levels of abstraction, just like with programming languages or frameworks.
That is a definition I can agree with.

What I had in mind when countering your post was:
Let's look at bitcoin protocol as a class.
It is reasonable that simplicity at the high-abstraction (public) level is paid for by greater amount of work and complexity being done at the invisible (private) low-level.
Not only can't low-level bugs usually be fixed (at best, they can be mitigated) at the high client-side level, but also the more complicated the low-level becomes, the harder it is to analyze it for flaws.
Thus, the overall complexity does not change, it's just shifted down.

Naturally, I believe we need multi-sig. I'm also confident the core developers will implement a decent and well-scrutinized approach.


EDIT::Some minor wording issues fixed.

My vote for what it's worth is in support of Gavin.

All technical details aside, gmaxwell has clearly enumerated the goals that such a proposal has been trying to achieve.  Luke has not.  I am not persuaded that Luke-Jr has any of the practical considerations of the needs of a payment network as a priority.

Rather, I see Luke as trying to impose some sort of orthodoxy on the way things work as a prime goal in and of itself - to hell with everything else - just like his vision that the entire world should switch to counting in base 16 with his "tonal" numbers because it's "easier".  Here's another example of an interaction between me and him that left me thinking wtf: https://en.bitcoin.it/wiki/Talk:Wallet_protocol ... Luke is a very talented developer but has totally lost credibility with me as a leader, or qualified to fairly evaluate the different tradeoffs that go into any design decision for a given application.

I will go with whichever flavor of multisig transactions chosen by Gavin and gmaxwell, as I have faith in their abilities to make the right decision for the project.

The only thing driving the urgency is how far malware will go to steal the coins.  Sure, this doesn't need to be done tomorrow, or next week, or next month.  The longer there is no practical multisig, the greater opportunity we'll be giving to malware authors to come up with more sophisticated attacks to steal our coins.  Gavin alluded to it as a cat and mouse game, he is right.  Bitcoin got "this far" and crashed because its security was clearly not far enough along.

I don't thoroughly understand P2SH yet, but one of the key advantages I understand there to be is far less that needs to be tested because it will have far fewer capabilities than OP_EVAL.

Revised protocol draft, without stack abuse: https://github.com/luke-jr/bitcoin/commit/f026234cf4edc53de4d9e60ccea581adbcb8ee3c

Ok, since none of the options are perfect, how about we try to satisfy everyone with a hybrid solution?

How about we just redefine OP_NOP1 to mean "do nothing right now, but if the rest of this script is valid in the normal sense, then unpack the second script and run it too".  It'll break old clients, and we have to deal with that, but this way we don't have a special case second code path.  Essentially do exactly what P2SH does, but make the recognition explicit with a dedicated opcode, and not implicit.  Make it a flag that can only be set by the OP_P2SH opcode and can't be cleared, maybe even make the new opcode trigger an immediate validation failure if found by the second pass interpreter so that people can't try to sneak recursion in with it.

So, the default P2SH scriptPubKey would become:

Mike, it's still going to be a cat and mouse game, as all security is.
Of course, raising the bar is always desirable. Common multi-sig deployment will render the old attack vectors ineffective.
However, we can rest assured that the bad guys will bring themselves up to speed and keep mounting increasingly complex attacks.

I do believe, however, that it's not inadequate security that's hampering wide-scale Bitcoin adoption but excessive technical issues with the client:
(1) slow initial block chain download.
(2) UI deficiencies (please put in a "Rescan" button somewhere. Non-technical users can't be reasonably expected to user the --rescan parameter).
(3) lack of wallet security (wallet encryption isn't offered by default, why?).
(4) no automatic wallet backups by the client (understandable in the light of (3) as unencrypted wallets should never be automatically backed up).

I'm sad to say these relatively MINOR issues do seem to have a heavy negative impact on the overall impression of the client.

Being active on the Newbies and Support subforums, I hear those issues being raised time and time again by very non-technical users who install the client and expect everything to just work.
They hear about the bitcoin PROTOCOL being secure and confuse that with client-side security (data theft/loss).

I'm writing this here hoping to raise these issues with the core developers.
Very little work put into purely cosmetic issues can make a lot of positive impact.

I trust no one that's why i use bitcoin when trading with you people so let's try keeping the trust factor aside a moment when serious protocol changes are involved.

At this moment i am really pleased and happy with the way bitcoin works as a protocol and at the user interface but it seems that, according to many, i am a big geek for being able to use it as such. Even my parents understood how to use it the first day with no problems.

I like Gavin's and team efforts to improve and make the life easier for the not-so-techie people in every aspect but not on this one. We started with OP_EVAL and it didn't work so good and now Gavin's proposes another method, better in theory, with a short BIP and a shorter deadline ahead. Some voices start to raise and Gavin states he's almost out of patience. This doesn't sound right to me.
Until now the one who has the most convincing arguments is Luke-jr. He states that, and i agree with, the power must remain with the miners, between others.

So please, bitcoin developers, don't ruin this trying to make it better. If we can't agree on something like this maybe isn't the time to do it and you can leave the people adapt by themselves like they did for over 3 years. I don't want bitcoin adapted for large corporations or complicated centralized services. You already gave us the encrypted wallets so, if you ask me, the people that can't guard their money don't deserve to have them.

I don't code or read code either only a small miner, investing time and resources into this project and be happy with what i get. The thing that gives value to bitcoin is all of you out there doing same. Thank you

Wouldn't this be like a driver who has never worked on an engine let alone designed one, trying to tell a bunch of engineers that one of them is the most convincing not because of the merits of his design, but because he argues that the control over the engine design must remain with the drivers, not the engineers?

I think when Gavin says he is out of patience, he means he needs a beer, and not because he needs to release some untested code ASAP.

sort of... the fact is the engineers always design or improve their product according to the users feedback, if i'm not mistaken, like you did with your coins  :D

Absolutely, it's the drivers who ultimately decide whether to buy the car.

In this case, Bitcoin is like a car that is easily stolen.  That might work for you, but is preventing a lot of other people being interested in it.  Not very many people can effectively ensure malware won't get on their system.  So the feedback of "don't worry about me, I keep my car in a garage at all times, at home and everywhere else I go" isn't feedback that's going to increase mass appeal.

In addition, Luke is the kind of person who would design your next car to be steered with your feet and accelerated with your hands, just like airplanes are taxied, and he would argue that this is easier and safer for everybody because pilots won't have to switch between two ways to drive a vehicle when it is on the ground.  (Simply do a search for "tonal bitcoin" for a prime example)

Fixed in 0.5.2 (at least in some/many cases).
It's -rescan. It's also never needed in theory...
Wallet encryption is mostly a PR stunt. In the end, you still can't back up the "encrypted" wallet as-is without losing privacy, and a trojan can just wait until you unlock your wallet.
This is the one biggest problem with Bitcoin-Qt right now IMO. I don't see any reason the AES code can't be recycled to encrypt the whole file when backing up.

That being said, these are all off-topic here... Can a mod split it off (ideally in the Dev forum)?

Funny you should say that. DeathAndTaxes and I were helping a guy just last night and -rescan fixed his problem (https://bitcointalk.org/index.php?topic=58610).

Naturally if your machine is crawling with malware you've already lost the war. Only multi factor authentication (multi-sig) can help you.
That being said, encryption by default is VERY useful because an encrypted wallet can be much more safely propagated defending it against data loss, eg. it can be uploaded to the internet and the attackers won't be able to breach it provided the passphrase is half-decent.

A great idea but the user needs to have encrypted the wallet in the first place for that to work. We don't want to rely on some hard-coded default encryption passphrase now, do we?


I only posted this here because the discussion had already watered down but you are 100% correct Luke.
I request the Mods kindly split this subdiscussion into a new topic, please.

What car is not easily stolen ? You can insure it if you want but the engineers can do very little about it by putting alarms or hard to copy keys in it. Overprotecting users won't do any good to increase adoption. Educating them how to drive the damn thing maybe.

Btw i try not to comment on people i don't personally know.

How do you educate everyone to never get malware?  Have them stay off the internet?  There is simply no other way...

For me to practice safe bitcoin, I essentially dedicate a computer to it.  It is convenient that I own spare equipment that can be used for this purpose.  Most users do not.

I don't know of any car that can be remotely stolen where *poof* it just disappears off the owner's driveway, completely untraceably and anonymously, just because (for example) the owner had the misfortune of driving within range of a bad guy's WiFi hotspot on the way home, something he could not have foreseen nor avoided nor knew ever happened.  But that's essentially how bitcoins are right now.  Any of these proposals, if adopted, will give the average user a serious and easily-understood way to prevent this from happening to their bitcoins - I appreciate that most everybody sees that.

now i agree with you, so bitcoins are not cars. I only hope the dev's implement good and tested security measures in the protocol.

In my opinion, rushing things has the potential of causing far more harm than individuals getting their wallets stolen. Introducing a serious security vulnerability into core Bitcoin is incomparably worse than individuals getting their wallets stolen.

I have great respect for both Gavin and all the other developers who devote much of their time to improve Bitcoin. It is greatly appreciated. But I honestly think that we're far better off with Bitcoin developing slowly and steadily. There is no rush. There is no deadline to reach. If developing a secure implementation of multi-signature authentication takes 12 months, the wider adoption of bitcoin might very well be postponed 12 months. But if an insecure implementation opens a hole in core Bitcoin, we have destroyed much of the trust that has been built up around Bitcoin so far. It will not be impossible to restore, but I think we can expect that if this happens, every time Bitcoin is mentioned, a side remark of the serious incidence will be added. And justifiably so.
In my view, we have plenty of time for Bitcoin to slowly evolve into a secure and widely adopted technology. Not rushing can only postpone this, rushing it might do irreparable damage.

From reading Gavin's posts I understand that these kinds of issues arise out of a disconnect in the development of Bitcoin: many features to implement with a very high standard of security and few people to actually implement them and audit them. It seems we are better off solving this fundamental issue, rather than hurrying protocol changes through, in order to attract new users.
I imagine that a sort of Bitcoin Foundation be set up, where large corporate actors (with money) from the Bitcoin scene can buy a seat on the board of this foundation. They each buy a vote with their seat. The money is used to fund developers and, perhaps most importantly, security advisers, that can bring to the Bitcoin development process the level of familiarity with software security that is necessary. Their seat on the board gives them a vote in decidingo what their yearly donation, or at least a part of it, is used for in promoting the development of Bitcoin. I see it working in many ways similar to projects like Linaro (http://en.wikipedia.org/wiki/Linaro) and the Khronos Group (http://en.wikipedia.org/wiki/Khronos_Group#Members_of_Khronos_Group). They are not-for-profit organizations that bring together competitors in an industry, through the common goal of improving the software that they all rely on.
I'm not sure if there is actually enough capital available in the Bitcoin economy for this to work at the moment, but I think this is needed for Bitcoin to keep evolving in a secure and stable manner.

Why not allow all the implementations to coexist for a while?  Different miners/pools can support whatever implementations they want.  When we are ready to transition to the proven method, we vote against the other methods by requiring a higher fee for those types of transactions, or not mining them at all.  Basically, I think we should let the market decide.  If one method bloats the chain, require higher fees.  If one method introduces a security issue, exclude it.

Because...

Why?  As long as the implementations are run on machines with no private keys they can't break anything.  The main client can take a conservative approach, and additional implementations can be used by other miners/pool operators.  If a pool op introduces a flaw, he's only at risk if he doesn't take precautions to isolate the pool server from private key storage.  Software monoculture is why we have such a shitty security environment to work in.  We need diverse methodology so the entire network doesn't all break at once.

Can anyone provide a TL;DR? Haven't read the above thread, if it's there already just tell me.

You can also answer on Stack Exchange (http://bitcoin.stackexchange.com/questions/2595/tldr-what-are-the-implications-of-bip-12-vs-bip-16)

Unless one is needed for the coinbase transaction (I'm unclear on that), mining requires no private keys, only public keys to pay to.  So, it could be anything from a few small miners to an entire pool op taking it live after he's comfortable with small scale tests.  If a private key is required (I'm not sure what for), it could be swept to a different address anytime it received funds.

TL;DR?

Bitcoins are growing up, people are making decisions that they need to make, while others are biting their nails.

For security purposes, bitcoin wallets need 2 keys-- at least-- and that point remains unargued.

How it would be effective for escrow however is beyond me considering that it wouldn't do anything other than provide a false sense of security, unless of course you made it 20 keys and trusted the opinions of all of those people (who knows, maybe that's the future of the internet? ;))

Bottom line, Gavin is kind of a project leader, and as a fellow project leader I understand him when he makes a decision based on an interest in providing an actual result. Bureaucracy slows things down. Luke Jr is a also a project leader who doesn't want bitcoin development decisions being rushed into. I understand him when he brings these issues to the public as they are quite serious. Everything development related reflects on the entire bitcoin community.

So here's my two cents-- Gavin, at the risk of 'wasting your time', can't you have two separate developments going on and test them both for functionality? Isn't that what a project leader is supposed to do? Luke? Can't you just start working on the direction you'd like to go and present it in a way that could be agreed with?

You know, not everyone here on these forums is a bitcoind code wrangler, but that doesn't mean we couldn't all learn. Situations like these make me think I should get involved myself.

You don't understand the proposals. Anyone "testing it out" risks ending up on a separate network.

You are correct.  I'm tired and you're right.  Each implementation would be required to perform all the validations.  Since validations are pretty much all we're doing here, it's an everyone or no one scenario, not a buffet.  Sorry for the derailment.

Can anyone provide links to anything that has details on this incident? I've tried searching without luck.

I originally voted for Luke's CODEHASHCHECK proposal because it sounded more elegant and because I fully support the idea of bitcoin becoming more democratic. However I liked the analogy of P2SH like being a preprocessor to C++ in this post by Stefan Thomas: https://bitcointalk.org/index.php?topic=56969.msg691560#msg691560 so I might consider voting for P2SH as well. Of course one might argue that bitcoin protocol should not evolve as C++ but that's another story.

Anyway my point is that we should consider worst cases more carefully compared to what particular approach enables.
There must be a step-by-step plan of what might go wrong and what our actions should be.

By the way last time I checked P2Pool was third in hashrate distribution (after DeepBit and BTCGuild) so convincing a few pool owners might still work for some time, but in a long run individual miners should be involved in decision making and everybody should understand the pros and cons of a particular approach.

FWIW, the BIP16-as-preprocessor argument seems fundamentally flawed to me... The C preprocessor acts on explicit statements at compile-time. Scripts are already compiled, and BIP16 is affecting behaviour without any statements or equivalent.

Current global p2pool hash rate is around 70-80 GH/s (http://forre.st:9332/graphs/). So it's less than 1% (http://btcserv.net/bitcoin/history/).

Just think: Theoretically here pretty soon you'll be able to drop $50k on 2 ButterflyLabs rack boxes and get that on your own.

I checked at bitcoinwatch.com it could have been a spike or other pools were down, anyway it seems more than 1% right now.
And then there is this Unknown blob, what if those guys aren't following the thread and won't upgrade?
We should consider all consequences.

No need to speculate on known fact. p2pool has ~80GH/s.  It has never had more than 100GH/s and certainly nothing like the >1000 GH/s necessary to be the #3 pool.  Currently the global hashrate is ~9400 GH/s so p2pool is <1%.

Understanding all this things in details would take me too much time. As far as I understood, that /P2SH/ thing is going to break stuff... I say just keep it on the testnet long enough before making a decision about it then... As already said, it's not as if there was a deadline to release it...

All righty, I mostly stepped away from the keyboard for a couple of days and I'm less frustrated and angry.

So first, I want to apologize to Luke for calling his CODEHASHCHECK code "a joke." I was frustrated that after weeks of discussion and gathering consensus around /P2SH/ he and piuk (and a couple others) decide it would be a good idea to propose slightly-different-but-not-obviously-better alternatives.

I still think Luke went about this the wrong way; for example, I think I would have been happy to accept a patch that made supporting /P2SH/ optional if he had presented it rationally instead of posting "ALERT! GAVIN IS HIJACKING BITCOIN! ACTION NEEDED!" I'd still be happy to accept a patch turning on/off the "put /P2SH/ in the coinbase" (assuming the general consensus is that is a good idea), but that's a discussion that should happen in the Dev/Tech forum.

In fact, most of the discussion in this thread on the merits of various proposals belongs in the Dev/Tech forum, and most of the concerns expressed here in this thread have already been discussed over the last several months.

Thank you for bearing this responsibility Gavin.  It must take great patience.

Gavin,

I beg of you, give users MORE time to adopt this change and think about the dates you choose.  We have several users on our pool that are either travelling or are away from their PC's for extended periods of time, and if this is going to require everyone to update then getting all the pool admins on board so they can then warn/inform their user's about the change is critical.  Nobody sent me or Geebus a memo, I just happen to find it, and this is true for A LOT of user's on this forum and other forums.  Waiting until the day when it just stops working to only find out that a critical change was made a week ago and that's why we were unable to mint new coins is frustrating to everyone involved.

I think as a core developer, you should be in touch with or have a list of all the pool admins contact info in order to notify them of these types of changes, then they can send the word out to their users however they see fit.  We (@BitcoinPool) would gladly put the news of this on the front page and e-mail all our users about the change. One post on one forum on the Internet and hoping/expecting everyone to read it just doesn't seem to be a good way to spread the word.

Other than that, keep up the good work.

Seems to me that the consensus of you devs (as voted between yourselves) was for P2SH.  That alone is good enough for me.  Luke missed out on that, and that's too bad, but he's one person in a group that disagrees.  Oh well.

Aside from that, the poll in this thread (while obviously not amazingly accurate) also indicates P2SH as a preferred solution by more than double the votes.

Seems pretty clear to me.

Pool users shouldn't have to update anything.  Pools build the block they hand out, users just try to find a nonce for it.  You should know this if you run a pool.  Additionally, there is a development mailing list you can join where this was heavily discussed:
http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development

notme is exactly right; the change is backwards-compatible, pool users don't have to do anything.

Pools and solo miners should upgrade, or they run a (very small) risk that they'll waste time hashing a block that can't be valid.

The risk is very small because it requires that somebody mine a block containing a /P2SH/ transaction that is valid-under-the-old-rules, invalid-under-the-new. That won't happen by accident, somebody malicious will have to create such a transaction and then find a miner who is willing to put that non-standard transaction in their block (and is willing to create a block they know the network will reject).

They would spend a lot of time (and therefore money) on an attack that would do nothing but slow down transaction confirmations a tiny bit and maybe trip up some random, unlucky mining pool or solo miner who didn't bother upgrading.



Gory details if you're not already bored:

Old miners and clients will ignore all /P2SH/ transactions; they won't relay them to other nodes and won't put them in blocks they mine, because they're non-standard.  So an attacker can't broadcast an invalid /P2SH/ transaction and hope it gets included in a block; they'll have to mine a block themself, or partner with a big solo miner or pool who is willing to produce bad blocks.

If an attacker DID manage to create a block with a timestamp after the switchover date and a bad /P2SH/ transaction in it, then some percentage of the network will try to build on that bad block.  Lets say 70% of hashing power supports /P2SH/.  That would mean only 70% of the network was working on a good block-chain, and the result would be transactions taking, on average, about 14 minutes to confirm instead of the usual 10 minutes.

In other words: they'd give up a $300 block reward and manage to just give the network a tiny little hiccup.

Thank you for the detailed explanation.  Much appreciated.

I will not claim to understand the details of the discussion, but If I understand the high-level issue, we are trying to find a second solution to a problem for which we already have a solution (use double length addresses).
That tells me a couple of things:
- There is no urgency in adopting a second solution.
- The second solution had better be significantly better than the existing one and be thoroughly verified.

To those who say that the double length address solution is unacceptable because it will create higher fees to the coin sender, I would argue that if double length addresses become the norm they will not incur higher fees.

Now for a naive proposal:
Rather than requiring two keys that security conscious users can keep on separate devices, why not just split the existing key in two, and keep the two halves in separate devices?

Fees are higher because these transactions take more bytes.  I don't think your argument has any teeth.

You can't just slap the keys back together to sign because you never want both keys on the same device.

I'm wondering if the following scenario is possible with P2SH:

"Ex:  I want to buy a FPGA miner for 100 bitcoins.

I put 100 in escrow.  The seller is required to put some amount, maybe 10%  along with mine in to escrow.  Range could be a sliding scale from 1% to 100% of the amount I put in escrow.  Escrow now contains 110 coins.

You would have to be a pretty rich jerk to maliciously scam people repeatedly.  Worst case scenario, untrusting buyers could demand 100% matching escrows for first time transactions."

quoted from:
https://bitcointalk.org/index.php?topic=60158.msg701749#msg701749

This summarizes my feeling. It's not like it is impossible to do multi-sig payments, they just result in slightly larger transactions.

Anyway, as says the quote above, I cannot claim I understand the details. I would just like to know if theymos opinion that this is mostly a style issue is a consensus, or there's more than style at stake. (not saying that style isn't important, it definitely is. I just want to understand if there is more to it)

The issue isn't "slightly" larger transactions.  Complex transactions can be much larger than normal transactions, and it puts the burden on the wrong party.  See this post (https://bitcointalk.org/index.php?topic=56969.msg696836#msg696836).

Actually this is possible with any multisig scheme, even without special redeeming scripts.

It isn't a solution.  It is completely nonviable.

I use multi-sig so I (not you) gain the advantage of higher security.
My address is longer so when YOU (not me) transfer funds You (not me) pay the higher fees.

I get all the benefit you get all the fees.  Also the fees can be significantly more and rise w/ more complexity and security (for example not just 2 sigs but 3,4,5).

So you pay more and more and more in fees and I get more and more and more security.  

Multi-sig will have a very limited usefulness (mostly academic) without a change to protocol.  It would be like pricing gas on the inverse of how large your car is and wondering why fuel efficiency sucks. :)

It can't be only the larger address that's provoking all this discussion... As far as I know, the output addresses are not the relevant part of a transaction, when talking about size. It is the public key attached to each input that make transactions large, isn't it? A transaction with 5 inputs and 1 output is much larger than a transaction with 1 input and 5 outputs.

Maybe the script that the sender must attach to its transaction have to be much larger than the standard script? Is that it?

There are no addresses.

Your wallet is a list of private/public key pairs.  When you want someone to pay you, you take a hash of a public key, then give them the hash.  To redeem that transaction later, you need to provide the same public key that created the hash, and prove that you know the private key that corresponds to that public key by signing the transaction with it.

The minimum amount of information needed to create a secure transaction to a single keypair is a single hash.  We then embed that hash into a string using special rules, and we call it an address, but it never exists in the bitcoin system as anything but a hash.

Now, say you want to create a transaction that can be redeemed by either of two different keypairs.  How much information do you need to create that transaction?  You need two hashes, one for each key, and then you can create a script that can be satisfied by either of them.

It gets worse.  If you want to have a (A and B) or C system, you need to provide hashes of all three keys.  If you want a (N of M) system, you need to provide all N hashes.

And that isn't all.  Not only do we need to provide 3 key hashes for (A and B) or C, but we need to standardize the interchange format so that you can create an address that includes the three hashes and the relationship between them.  And we need a format for (2 of 3), and another one for (3 of 4), and in general we need a format for every system.  The CEO and CFO can spend if they agree, but otherwise either of them requires a majority of keys from the board of directors?  New format.  Any junior officer can spend with the consent of either the CEO or the CFO and the consent of at least one board member?  New format.

With P2SH, the addresses that you give out are the size of a single hash, regardless of what lurks beneath.

The redemption transaction grows, since it will include the script in addition to all of the needed public keys, and all of the needed signatures.  But, that is a problem for the person spending from the complex transaction, not the person spending to it.

I know addresses are hashes. I just always thought that the relevant part of a transaction size was the public key of each input, not the hashes of the ouput or the script.

Concerning formats, is it impossible to have an unique, generic format allowing the receiver to send the full script plus any hashes or generic data to the sender, in the form of a big string? Defining only such format once should be enough.

I understand that it would be better if the receiver pays the fee for the inclusion of his script, but, honestly, how expensive are transactions right now anyway? They are very cheap, this extra fee price can't be relevant to the point of stressing people the way we see in this thread.

TL;DR: I don't see any urgency in this change.

I disagree that the fee issue is a small one.  Fees are small now, but this may not continue to be the case.  In very complicated transactions, the existing methodology can lead to humongous addresses and much larger transactions.  Dealing with various address lengths will be confusing to users, and the existing scheme has the incentives backwards.  Why should I pay more for your security?  The urgency comes from the fact that we need to make multisig very easy to use so that windows users can have a hope of not having their bitcoins stolen.  Without this, bitcoin is dead in the water... at least until the Windows monoculture breaks apart because of it's own inescapable design vulnerabilities.  I wouldn't count on that happening soon though.

That's why you should accept payment with a standard short address and then move your funds yourself to your safer "savings" account with a script as complex as you like.

It's pretty much already happened actually.
You should keep your wallet in your pocket, and for the vast majority of people that is not a Windows machine.
You should keep your "savings account" in a safe place, probably a "bank" in the cloud that'll one day even pay you some interest, and that also most likely means anything but a Windows machine.

Good points about the primary use cases not being on windows.  At least they haven't managed to infest phones and servers like desktops.

I guess the one case I can think of that P2SH fits that doesn't work now is escrow without the escrow needing to do anything besides publish an address and sign a set of terms.  Something along the lines of, include a 1% fee to my address in a 2 of 3 transaction and I will arbitrate any disputes.  As it is now, the escrow has to provide an address for each transaction, then sweep the funds to a new multisig transaction.  In that case, they may as well just hold the funds like they do now.

This is what I see in this thread:

https://i.imgur.com/4awR0.png (http://xkcd.com/309/)

My vote is for P2SH:

• There's no strong points against it.
• It's the only proposal so far that allows space savings in the future. Just imagine more and more complex unredeemed transactions saved in the chain: with P2SH is just a hash.
• Less potential of having a security flaw.

The only slight drawback I see is that you have to save the script somewhere to redeem it instead just a private key, but I don't think it's a problem if a good escrow negotiation scheme is implemented in the client (to avoid sending an escrow to someone who doesn't save the script).

edit: s/unredeemable/unredeemed/
Edit 2: It seems PIP 17 also allows the same space savings as PIP 16. Correct me if I'm wrong.

I'm about to update my bitcoind appropriately to cast my "vote" which I shall not share here, what I do wish to share here is my concern for this quote un-quote voting process, Luke you made a point that Gavin is forcing anyone who has the latest bitcoind to vote in favor by default yet you are encouraging large pool ops to basically force a default vote upon on all of their miners by changing the pools bitcoind to not support gavins change , now admittedly I am reading/writing this from my phone so I may have missed something but in all fairness isn't this supposed vote meant to be by miners and not by pool ops?

I know for myself As someone who has mined extensively for almost a year  if I am given a chance to vote on a change in bitcoin as a miner - it should be my vote that is counted and pool ops should not have the ability to vote for me and for everyone else that mines with them.

Can someone please provide information on how the votes are counted, and how a pool op is able to vote for the miners that actually Provide the hashing power?

Votes are counted in the coinbase transactions that actually end up in the blockchain.  People that are mining through pools are working on blocks provided by the pool (usually), so they are working on coinbases provided by the pool.  Which means that it is the pool operators that are voting, not the pool users.

The pool operators should probably ask their users, or should tell their users which way they are voting so that pool users can change pools if needed.

If you are not actually directly submitting blocks that you generate and mine yourself, you are not really voting, and you don't need to set your node up one way or the other, since it won't matter at all.

Not sure if you are aware of this but as a pool miner YOU DON'T COMMUNICATE WITH THE BITCOIN NETWORK.  Thus your "vote" is worthless.  What is necessary (not just for this issue but any issue) is having 51% of HASHING POWER support a change.

So if you support change X but you mine at a pool which doesn't then .... your hashing power is "voting" AGAINST that change.

You have two options:
a) find out if your pool is supporting change X and if they aren't then go to another pool
b) solo mine


Of course they do.  There is no vote in the sense of a democratic election.  To make ANY change (this goes far beyond BIP 16) it must have support of 51% of the HASHING POWER.  When you mine in a pool your miner is STUPID.  It makes no decisions and thus can't "vote".  It will gladly hash whatever the pool gives it (rejecting P2SH transactions, attacking alt-chains, double spending bitcoin network, etc).


The miner isn't providing hashing power to the Bitcoin network.  The miner is giving hashing power to the pool operator to use as the pool operator sees fit.  This dynamic has always existed since the first pool was launched.  It is a large reason why there is concern over very large pools and the POWER it gives pool operators.

In my opinion, you give up your right to vote when you mine at a pool. The pool can choose to hear you on what you'd like the pool's vote to be, but they don't have to. A miner should consider this before deciding to mine for a pool.

In order to regain your vote, you can choose mine with p2pool instead. This avoids the, for many, unacceptably long wait between finding blocks as a solo miner, and the variance in time in finding them.
The added work that a miner who works for p2pool will have to do, is run an instance of bitcoind (for collecting transactions) and also an instance of p2pool. So the main obstacle, compared to pooled mining, is having the proper amount of storage space (of sufficient quality - I suspect a USB stick isn't fast enough) for holding the block chain. Mining in this manner, your vote (which is determined by the bitcoind version you're running) will be heard only every time you find a block. So with 1GH/s of mining power you probably won't make your voice heard in time. But that doesn't seem unreasonable, since you have a very small part of the total hashing power (currently 1GH/s is ~0.01% of total hashing power) anyway.
If you want to make sure you vote with your hashing power at all times, joining a pool whose vote you agree with will achieve this.

For most of us miners, it really does not matter. Despite the way we voted above, Luke-jr will win and it will be Bip-17 or what ever he comes up with. Luke-jr is lining up pool ops to go his way on it. Since miners go where the money is, there is little chance that miners will move from one pool to another just to encourage their pool's op to vote a certain way. Since pools have greater than 51% of the hashing power, they (the pool op's) will be deciding what which way it goes. And right now, it looks like Luke-jr has most of them in his pocket. Basically, it is Luke-jr's way or the highway and all others be damned.

If the other pool ops didn't agree with "my way", they certainly wouldn't be voting that was just because I said to. The only pool op I know of that plans to vote for BIP 16 is doing so because Gavin said to and he doesn't want to look into the details.

Individual miners do not have a horse in this race.

Since most miners go where the money is (lowest fee/Highest return of BTC with a smidgen of reliability thrown in) they have no say. The pool op's will be deciding with whatever bitcoind they choose to run.

The right thing to do would be for pool op's to have their own poll for their pool's miners and then support what ever decision the majority chose. I doubt that will ever happen.

I personally would like the whole damn thing shelved for six months until there has been a proper amount of time to decide on a solution and to test it out on testnet.

There is way too much at stake for this to be rushed into the live chain/code.

After reading all of this discussion, I have now upgraded bitcoind to 0.5.2 on my miners (I mine solo), and encourage all other miners to do the same.  I will also encourage pool operators to upgrade and announce support for their pools.  Bitcoin needs this functionality now, not later.

But not in the form of BIP 16.

i kinda agree, can't see too much consensus in the dev team either so a little more brainstorming could be needed  :D

I can't see any better implementation yet.  This has already been discussed for a long time.  BIP 16 is a good solution, and the only way to get there in the near future.  Neither longer addresses and blockchain bloat, nor turing completeness in the scripting language seems like better solutions to me.  BIP 16 has the greatest support by a large margin, so please let us just get BIP 16 out there.

BIP 17 is implemented.

No, it really hasn't been going on very long.

BIP 16 is terrible, and de facto protocol breakage. BIP 17 can get us there tomorrow if we really need to rush. It doesn't require longer addresses, nor bloat the blockchain (in fact, it saves more space than BIP 16 does!), nor is it remotely turing complete (it doesn't even require an eval-like function at all!).

I try not to respond to trolls, but....

Quit spreading FUD. If you think BIP 16 is terrible, please give a rational reason, beyond "It is a special case," which I have repeatedly responded to.

This pissing contest made me curious enough to try an understand the various code snippets and documentation (or lack thereof) of each proposal, something I have never been goaded into previously.

I believe that OP_CODEHASHCHECK is a dead end. Further, I believe that while OP_EVAL could be nice to have, /P2SH/ addresses concerns with it, and remains useful for the majority of users, if implemented properly.

I therefore cast my vote for /P2SH/.

Could you explain why you think it's a dead end?  BIP17 seems cleaner to me, but with an upgrade related security issue.  While BIP16 seems like a hack (and I don't like OP_EVAL if only for the fact that it makes static analysis more difficult and it doesn't really add much capability aside from running some code in a slightly different context (outside of the scriptSig execution context)).  There also seems to be a strong urge to not allow the full use of scripting facilities in scriptSig, which I can only attribute to a "cargo cult" that has formed based on past issues.  Both BIPs seem to be contortions that try to do things in a backward compatible way…and actually, I think "backward compatible" is the wrong way to look at it.  They aren't backward compatible at all…it's just that they are designed to exploit some permissiveness in the validation rules of old clients…but the old clients aren't actually doing what they need to do with respect to validating these new kinds of transactions.  I have a strong feeling that this is wrong headed.  It would be better for the old clients to reject these new transactions and for miners to upgrade and once there is general agreement that 70 or 80% of the mining power is ready to accept the new transactions, then set a date a month or two out when miners will start allowing them.  Any stragglers (miners or clients) will quickly switch over when they realize they are at risk of having un-marketable coins.

P.S.  It also occurs to me that as a "democratic money" that this process is exactly the way it should happen.  Trying to exploit the permissiveness of old clients feels like it's subverting what should be an, albeit painful, but consensus building exercise.

I think that what it achieves is only a short-term solution, and will quickly need to be supplemented to be worth using in the long term - whereas /P2SH/ looks to me like a more complete option.

However, please do note that this isn't the kind of thing I mull over daily, and after such a cursory overview that is what jumped out at me. So take it for what it is worth.

Ok.  I tried to wrap my head around it over the weekend.  What gives me pause with both OP_EVAL and BIP-16 is that they are pushing code onto the stack for later execution.  This undermines the deliberate desire to keep the scripting language non-turing complete.  An example of the things that I wonder about with OP_EVAL is could I nest an OP_EVAL in serialized code I push on the stack.  The "standard transactions" checks could trivially stop such a thing, but you've now created a situation where you're dependent on such "standard transactions" checks for the security of the system.  I would instead like to see a day where there is enough confidence in the implementation of the scripting system that such checks could be discarded.

I have a lot of experience in language and virtual machine design (bytecode interpreters, JIT VMs, and dynamic translation engines), so this topic is very interesting to me.

They wouldn't be validating them in any case. This backward compatibility allows them to keep working with transactions they do recognize. The permissiveness being "exploited" (at least for BIP 12 and 17) was put there expressly for this purpose.

The change you're describing requires 100% of not just mining power, but also all users (including merchants who may be unable to upgrade for various reasons). The backward compatibility in BIP 12,16,17 allows upgrading the network with only a super-majority among miners' consensus.

This change is actually fully in line with "democratic money"; what Bitcoin is, at the core protocol, is in fact "unanimous money". ;)

The only long-term benefit of BIP16 over BIP17 is that you can fit more multi-factor addresses into a block before the inevitable Bitcoin 2.0 upgrade is needed. If we do end up needing that much before Bitcoin 2.0, we can roll out something similar to BIP12/16 at that time, presumably after we've had many more months to consider the consequences.

This is a stressful war because they set hard dates again and again, rushing to tell miners when most of them aren't even aware of this (and some didn't see BIP 17 that replaces the CHC idea), or just don't care.

Check out this soft schedule proposal (https://bitcointalk.org/index.php?topic=60433.msg710331#msg710331).

If scripting is mostly disabled anyway except for a few special cases, and using a special case is "the way to go" for this feature, then maybe in an ideal coin (think altcoins here if inability to change bitcoin itself this deeply this late in the game) should from the outset just have special cases and no actual scripting?

Do we know yet what scripting actually buys us? If so, maybe each use-case can be provided as a special case and scripting per se never even be contemplated let alone actually implemented or deployed?

One might argue that scripting allows future use-cases we have not yet thought of, but special cases could too, the new thing could simply be added to the list of special cases. Our 'opcodes" could simply be enumerators, enumerating the "special cases" aka "use cases"?

Bastardising our scripting language by hacking "special cases" over it or subverting our list of allowed cases aka use cases aka special cases by having a "scripting language" both sound bad, shouldn't we either go with a script language or go with an enumerated list of special aka use cases, one or the other, instead of a hack job that is neither cleanly but instead has possibly the downsides of both?

-MarkM-

In my opinion, a scripting language makes sense, even if it's disabled. In any case, enabling a disabled scripting language seems much easier than implementing a scripting language in a currency that didn't support it to begin with. I suspect this is the reason that Bitcoin has a scripting language.

I agree with the developers that Bitcoin is at a stage where it is too early to fully unleash the power of the scripting language. I think Bitcoin needs time to mature, and attract attention, developers and capital, in order to enable us to create a secure implementation of the scripting language.

It seems to me that the developers acknowledge that a powerful scripting language is a double-edged sword. It adds tremendous power and an almost unlimited number of use cases to the currency, while at the same time greatly increases the number of routes through which an attacker can subvert Bitcoin. I think it's sensible that Bitcoin was born with a scripting language that is currently de facto disabled.

My point is that special cases cannot ever provide the functionality of a scripting language. But a restricted scripting language can provide the functionality of special cases. Currently, I think it's sensible to restrict Bitcoin in this way, while still retaining the option of enabling scripting entirely when we feel that we have a secure implementation of the scripting language.

And how many of those losses are not fault to the person who lost them?  Making a change to the network because of bad or irresponsible behavior is NOT a good idea?

So what is the current deficiency in the Bitcoin technology/network which has NOTHING to do with human behavior that requires this change?
Sam

You've never heard of safety engineering have you?

One guy crashes a plane into a mountain, pilot error.  Several people crash the same type of plane into mountains, design problem.

Lots of bitcoin users have crashed into mountains.  Each one of them made a mistake.  Gavin is trying to change the design so that the system is much more tolerant of these mistakes.

The problem is still behavioral and has already been solved with encrypted wallets.

If we make changes to the Bitcoin protocol to ameliorate every possible human error we will end up with an unusable system.
Sam

Do you know what a keylogger is? It is something that renders an encrypted wallet essentially useless. Requiring more than one diverse device to confirm a transaction is another solution to this issue.

The bitcoin developers certainly have NOT been adding features willy-nilly left right and center. To say otherwise is simply delusional.

And how does one go about getting a keylogger on their system?  Largely by bad behavior.


I agree completely, so far.

But implementing this change to offset an persons behavior would be setting the precedent that it's the Bitcoin technologies responsibility,  and require future changes, which could lead to "willy-nilly left right and center" changes.
Sam

Sadly this isn't true!  It has do to with the way in which the opcodes in the existing scripting system were disabled -- or perhaps more accurately "never enabled".

Existing clients treat any script containing a disabled opcode as invalid (https://en.bitcoin.it/wiki/Invalid_block).  As a result, enabling a disabled opcode requires upgrading all clients (miners, exchanges, end-users, etc).

OP_EVAL/P2SH/CHV work because they transfer validity-checking responsibility from the end-user to the miners, resulting in a much smaller set of clients to upgrade.

Is there a problem? or do you have yet another solution in need of a problem to solve?

Yes, the problem with BIP 16 is obvious and I and others have discussed it enough. Read the BIP (https://en.bitcoin.it/wiki/BIP_0016), or at least genjix's summary (http://bitcoinmedia.com/the-truth-behind-bip-16-and-17/).

In my humble opinion, this kind of trash talk against BIP 16 is bad for Bitcoin.

The poll in this thread says the community prefers BIP 16.

The chart on the bitcoin wiki (https://en.bitcoin.it/wiki/P2SH_Votes) says the core developers prefer BIP 16.

And the actions of the big mining pools and independent miners (http://blockchain.info/P2SH) says that they overwhelmingly prefer BIP 16.

Luke, I'd be delighted to add Eligius to the list of pools that are supporting BIP 16 in my signature.

The poll in this thread is worthless as it doesn't ask the real question.

Please give a real reason for this change.  Is there a flaw in the Bitcoin technology that requires this?  Or are you all trying to ameliorate a flaw in human nature with software?
Sam

But your talking about modifying the block chain which will be permanent.  There may be unforeseen consequences that I have seen no evidence that they have been thought through.  Also the security environment with our PC's and the internet are not static.  The way Bitcoin is currently implemented is not be the way it will implemented in the future.

Making changes which break backward compatibility should be avoided unless absolutely necessary.  The case has not been made that this is absolutely necessary, at least to my satisfaction.  Additional security can be implemented in the Bitcoin Client, third party services or new hardware devices that haven't been developed yet all which would require no change to the protocol and block chain.

By the way don't get me started on the car air bag fiasco. :)
Sam

I do think changes should be avoided at all cost's, UNLESS ABSOLUTELY NECESSARY!  I understand there was a change the HAD to be made because of an actual flaw, that is/was appropriate.  This issue can be ameliorated in so many other ways, and is, that folks should question it a little more than they are.

I am not concerned about one pool effectively preventing the change by not voting for it and that is why I am mining there full time right now.  And if Tycho did start supporting BIP16 and the implementation was NOT a done deal I would mine elsewhere until it was implemented or defeated, granted at that point it wouldn't really make a difference except clear my conscience if things did go awry because of one of these multi-sig schemes.

I am much more concerned with the Bitcoin community trying to strong arm and badger a pool op into doing what they want and effectively take away my voice of dissension in the process.  That is very troubling to me.

Would there be a mass exodus from Deepbit if they decided to support multi-sigs?  I don't know.  But Deepbits hash rate is up significantly recently, whereas BTCGuild is about level where it has always been but Ozco is significantly higher for that pool in support of it.

So I don't think the personality of Tycho by him/her self will defeat what the rest of the community wants but if it is defeated it will be by the voice of miners Deepbit represents.
Sam

What change are you fearing? AT THE VERY WORST, all that can happen is that new (OP_EVAL/P2SH/CHV) transactions have "something bad" (if anything?) happen to them. Existing transactions aren't changed and do not get affected by this.

Do pray tell, how? What are your significant contributions towards mitigating this issue?

You seem to have an irrational fear of a multi signature transaction type being widely implemented and made useable by a larger segment of users. Why?

This is certainly annoying (at best), but it isn't the end of the world. He is doing a great job of ignoring everyone ;D

When I started with Bitcoin all I wanted to do was solo mine with a mid range GPU and just check my wallet 2 or 3 times a year.  That didn't work out.  But if it had worked out that way and a multi-sig was implemented while I had an old bitcoind running then I would have risked loosing my coins.  I think there are several people in that boat right now.  Bitcoin users shouldn't be forced to keep up on all of this minutia just to make sure their coins and transactions are protected.


I have take steps to protect my wallet and network.


I have a fear of fixing things that haven't been demonstrated to be broken.


And why is he ignoring everyone?  Because he has nothing to say on the subject or because of retribution?
Sam

Well I wasn't invited to a meeting, strangely enough.

But it sounds like a done deal or is it not?
Sam

I am starting to understand your perspective. However, it is flawed! This protocol change CAN NOT AND WILL NOT erase old bitcoins, NOR will it make them unspendable. You are not at risk of losing ANY of your bitcoins, whether you are running an old client or a new one.

I meant mitigating it for the larger userbase, not just yourself.

What are the deadlines involved? (if there are any - also, a reference link to keep track of that would be appreciated, if it exists).

Someone sent some BTC to my "If you just want me to shut up pay me here:" address a few hours ago.  I just now saw this and apologize for not honoring it because of being unobservant.  I would be happy to refund it if you would like.  If so please PM me with the amount you donated and an address.
Thanks,
Sam

Eheh, that was me, I don't need a refund though. ;)

Which one was it?

What trash talk? criticism isn't trash talk. Some people disagree about BIP 16 being the right step to take, that's all. Having disagreement isn't necessarily bad for Bitcoin. Letting personal issues take over technical arguments is worse for Bitcoin IMO.

I don't know enough about the protocol to make a technical argument. Maybe in a few months time when work allows I will. But know I'd feel a lot more comfortable about the future of bitcoin if these issues were discussed in a civil way and focusing in the technical aspect...

0.1 BTC to the "shut up" address, is that what you mean?

FWIW, I had intended to give up and withdraw BIP 17 last week, but decided against it due to multiple people PMing me saying they read the BIPs and agree. So I'm giving it a bit more time in hopes the tide turns enough that we don't get stuck with BIP 16.

Yep :)
Thanks,
Sam

After reading this thread it's clear to me we need to have this additional validation rules that apply to the new transactions to attract more users and add security to bitcoin network.  Each method has it's risks and different pros and cons but none of them are perfect.

As a software developer that has a VERY VERY basic understanding of each method and not fully sold on P2SH or Luke-jr's CODEHASHCHECK, if I had a gun to my head I would select CODEHASHCHECK based on what I have read in this thread.  The only reason I can come up with to support P2SH is because Gavin Andresen is not arrogant and that is not a valid reason.

I am not married to any solution and if I wanted to decide on a particular solution, I would need to study the bitcoin protocol a lot more before I could make well educated choice.

From what I can tell the risks are the same and the implementation of both methods can be criticized and considered "Bad" for various reasons.

With that said, I would suggest this change be done on another block chain like Namecoin that does not have a large market cap and reputation to protect.  Changing another block chain gives you faster deployment of the new code and redeployment should a flaw be discovered.

That's my 2 bitcents.

Davinci

Both BIPs have been tested on Bitcoin's "testnet", and BIP 17 (formerly "CODEHASHCHECK") has been tested on the main Bitcoin network.

I assumed it was tested on testnet but that's not real world enough.   People need to be able to use it day to day and give hackers time to pick it apart and find a flaw.  Remember the OP_EVAL and the flaw found after it was considered.

I understand you are concerned as I am about the reputation of bitcoin however I just think of all the people telling me bitcoin failed because MTGox was hacked.   I would hate to see the protocol hacked, thus give the haters real ammunition against bitcoin.

Davinci

Perhaps, but in reality the only way to get real day-to-day testing is in the main chain.

Hello, Dr. Tyrell.  Love your FPGA work. 

Good comment.  A thought occurs.

In a currency system that functions entirely in software, such a fundamental system, being able to remediate issues, incorporate substantial functionalities should be as close to seamless as possible.

In other words, it seems that there is a fundamental flaw in BTC in that there is no semi-transparent (time frame voluntary, then mandatory) way to move all BTC participants to the next code revision - or  reversion if needed.  Of course, having some segmentation to target updates to relevant components.

These are the growing pains of BTC.  I would hope there are safe, effective and highly coordinated ways to mature the BTC system.

These are the thoughts of a newcomer, but seems these types of problems, and the necessary clunky coordination needed, would frustrate the current average Interwebs user and hinder widespread adoption.