Bitcoin Forum

The consensus from Tuesday's IRC meeting (https://bitcointalk.org/index.php?topic=56376.0) is to replace OP_EVAL with "pay-to-script-hash" -- a simpler, safer-but-less-powerful alternative for creating bitcoin addresses for multisignature and future more-complex transactions.

So please read the BIP: https://en.bitcoin.it/wiki/BIP_0016
And the source: https://github.com/gavinandresen/bitcoin-git/tree/pay_to_script_hash

Important dates:
Feb 1 deadline to try to get 50+% of hashing power to express support.
Feb 15: "full validation" pay-to-script-hash switchover date (assuming success on Feb 1)

pull request: https://github.com/bitcoin/bitcoin/pull/748

So "King is dead, long live the King"?

I've read the BIP, but not the source yet.

The thing that strikes me about this, as well as OP_EVAL before it, is that while it's not a bad solution, it seems to be to be solving the wrong problem. The problem we're trying to solve is that it's the recipient of a payment who really wants control over where the funds ultimately end up. I see this as very similar to problems like that it's often the recipient who wants to determine the amount of the transaction fee to get it in a block. It would be better if there were an easy way for senders to create a transaction, and then instead of broadcasting to miners, sent it directly to the recipient. The recipient would then add their own transaction, to send it to their multisignature vault or to send it to their physical bitcoin bar or to have some go to a transaction fee or whatever, and then the bundle of two transactions would be what gets broadcast out for mining. And miners would be somewhat aware of this transaction bundling such that they would include the transaction with the fee as well as the original transaction based on their rules, since even if the original transaction by itself doesn't have a fee, the bundle does and so they'd get their cut.

Now, I can understand that it seems that the serialized scripts proposal is a bit simpler, and might get people able to actually use multisignature transactions quicker, but I'm not sure that's actually the case (though it very well might be). My proposal (which I don't think was original to me, but I'm not sure where on the boards I've seen these ideas before) would only need to be implemented by recipients that wanted the functionality (by upgrading to clients that could be set with what they wanted to have happen to incoming payments), and miners that wanted to look for transaction fees more smartly could upgrade to get them. To start with, the transmission of the initial payment transaction could use the existing P2P transaction relay system, as I don't think it's a huge problem for most of these scenarios if others in the world are aware of the transaction before the second half by the recipient to put it where they want it, or even if the initial payment ends up in a block first. There's already been talk that we need to at some point have a better transaction transmittal system, regardless of how we get recipients to put funds where they want them, but we can worry about that later if we need it later.

Btw, patches for older versions of the client is ready and tested?

Payer-provided transactions is something I've been discussing for quite some months now. The intention is that senders can avoid fees, and so can recipients if their risk analysis indicates double spending is unlikely (payment comes from a trusted payer). It needs some changes to Bitcoin to resolve fees recursively across dependencies in the memory pool, and then of course a series of protocols around it to make passing transactions around easy.

I'm heading in this direction with BitCoinJ. It's one reason I think addresses, qrcodes etc will one day disappear and be seen as a legacy of Bitcoins early days, kind of like how "CGI-BIN" is a legacy of the early days of the web which is hardly seen anymore. Instead making a payment will mean uploading one or more transactions to the recipient who will then decide whether to broadcast, keep, or submit directly to a pool.

Gavins motivation with this change is to try and avoid building up new protocols around Bitcoin and let peopl continue to use addresses. I don't agree that this is worth changing the block validation rules (which is an extreme measure in any event), but that's a minority viewpoint and the decision was made already.

I'm happy to see that there are people working on the sender-providing-transaction-for-recipient model, and I'm happy that Gavin's working on the fancier scripts model. This is very early in Bitcoin's life, and I think that it's good for the various models to get some work to see what does and doesn't work. As Mike Hearn alluded to, and I know that I've seen this sentiment elsewhere on the boards as well, this is very similar to the early days of the Internet, where there's a lot of potential, the mainstream has no clue that it exists, and it's hard to know exactly how this will all take shape. (Actually, the more I think about it, even the Internet is still really young.) Thank you all for all your work, and I wish that I had the time to contribute more to Bitcoin myself. I look forward to seeing how these various models of how transactions will be created, transmitted, and mined all turn out eventually.

Gavin,

Thanks for this work.

Is the intent with BIP 16 to maintain the irrevocability of sending, that is, to ensure that once 'sent' coins will always leave an address, whether or not the script hash is ever proffered?

Regarding the transition plans, wouldn't it be preferable to require more than 55% of currently running mining hardware.  Recent graphs show there has been much hardware sitting on the sidelines ready to be restarted.  If 55% support the new validation rules, and immediately after the rules are switched, 10% extra hardware is brought online using old validation rules, that chain could outpace the new validation chain.

Most of the mining hardware will mine in cooperation with existing pools (DeepBit, Slush's pool, Eligius, BTCGuild, etc.).  The pools set the policy for transaction validation and block generation.  The mining hardware only performs partial hash collision attempts.  If enough of the big pools support P2SH to make up 55%, that's unlikely to decrease much if extra mining hardware comes on because most of the hash power will go to those pools.

You have to think like you want to attack it.  If I'm bringing 10% more power onto the network at that moment, it's for a reason.  If it's only 55%, it doesn't matter who controls that 55%, it's the other 45% plus the 10% additional that matters because you need to get enough of them to join you to outrun the attacker.  But, with how much mining takes place in pools, it shouldn't be too hard to get 75-85% consensus.  That would require at least 25-35% additional force brought on line and would make me more comfortable.

If we manage to get 55% or better on Feb 1, then for the next two week's I'll be sending out the message "Upgrade or you might be on the short end of a blockchain split come Feb 15" -- and I expect the result to be a large majority of miners supporting P2SH by the Feb 15'th switchover date. If we're still at 55% on Feb 7'th then I'll be worried, too, and might advise miners to push the hard switchover date a couple of weeks (if they're using the patches I'm creating then it is a command-line argument to bitcoind).

The real danger is for the 45% -- after Feb 15 (assuming the switchover happens) all it takes is for one old miner who is including non-standard transactions in their blocks to create a block containing a transaction that is invalid under the new rules.  They announce the block, and any miners who haven't upgraded would happily build on it, only to waste some hashing power because the 55% majority will sooner or later reject their chain.

However, I don't think anybody will accidentally mine a block spending an 'invalid under the new rules transaction' in it (the number of people mining non-standard transactions seems to be very small), and it seems unlikely an attacker would waste time solving one or more blocks that they knew were going to be rejected by a majority of the network.

You're right, it's unlikely anyone will accidentally do it. But I can guarantee there are malicious people around just itching to cause a bit of havoc in bitcoin. It would be best to plan for the case of "it will happen that someone will mine a block" rather than "I don't think anyone would waste time to".

Right........


Also, the worst case scenario isn't very scary-- worst case is the less-than-50%-of-miners who did the switch find themselves on the short end of a blockchain split, so they lose revenue (and transactions take longer to confirm because the network is working on two different chains).

That would motivate them to either quickly recruit more hashing power or quickly switch back to the old rules.

Scary.

/P2SH/ should be Rejected as-is. It's at the very least worse than OP_EVAL, and broken by design.

It basically makes a special-case out of a specific template. This is like saying "if you see a program that does X, instead of executing it, execute something else instead".

The only excuse for this kind of design would be if scriptPubKey were to be deprecated (recommended against all future use, but still supported during a [long] transition period), and this special-casing is a strict backward compatibility mechanism. The current BIP 16 does not (explicitly) say this is the case.

Either BIP 16 should be revised to explicitly deprecate scriptPubKey, or Rejected and replaced with a revised OP_EVAL or some other sane solution.

No, not "something else", it is "if you see this very-specific sequence of bytes in the scriptPubKey then do this ADDITIONAL validation."

As for saying something in BIP 16 about obsoleting scriptPubKey :  no.  Although I think in the future we'll move towards all transactions being pay-to-script-hash, I think it is dumb to put anything like "we think this is what is going to happen in the future" into standards documents.

Can we keep the big picture in mind?  The reason I'm pushing so hard for "send bitcoins to a multisignature-protected-address" functionality is so users stop losing their bitcoins to malware infecting their computers and smartphones and to scammers.

We can spend more months arguing over trivia, but I would much rather we spent the time thinking hard about, and building, great wallet and escrow solutions that solve Bitcoin's biggest technical problems.

Ok, so "if you see a program that does X, after executing it, execute something else or you risk losing money"...

Deprecation is a common thing in standards documents - just look at all of it in the HTML specifications if you want an example. In any case, this isn't merely "we think this is what is going to happen in the future", it's "what it happening now: scriptPubKey is no longer considered standard, just tolerated/accepted for compatibility". This is implied by abusing it for backward compatibility, but should be explicit.

OP_EVAL did that just fine.

Breaking the protocol is not trivia.

I hate to bring up the Satoshi argument, but Luke is right. If Satoshi thought that it was better to save a few bytes than to use a standard design, he would have used <pubKeyHash> OP_ADDR1 instead of OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG for the scriptPubKey of a standard address transaction. Worse than that, this is like suggesting that he should have just made it so <pubKeyHash> infers that.

Let's not hold Satoshi's inferred design decisions sacrosanct. There's lots he did well but also lots that's bad.

I sympathise with Luke's misgivings about P2SH. As a solution it seems to fall between the two stools of having a clean scripting language and dispensing with the script language altogether.

Gavin said something like "It's a hack but I like it." - a sentiment typically followed by years of regret.

I suggest that we redefine OP_NOP1 as OP_DO_EVERYTHING and the scriptPubKey should be [20-byte-hash-value] OP_DO_EVERYTHING. This saves an byte which should please Gavin and is clearly not pretending to be anything it's not.

I also propose we take the opportunity to remove miner support for all disabled opcodes and OP_CODESEPARATOR pending the reuse of their values.

ByteCoin

I find this pretty scary. It may be "worse case" but when worse case happens by someone mining a single block and the result is a drop in the network hash rate by almost 50% and people lose money, that seems non-optimal. Depending on the make up of the pools that support it it could push one of them over 50%.

Note that I'm not opposing the new feature being introduced, I'm concerned about the bad things that seem possible when it happens. Would it be possible to push out a client first that activates some far time in the future at a particular block number when it's expected a larger number of clients would have updated.

What percentage support by February 15'th would make you comfortable?  As I said, if it is 55% from Feb 1 to Feb 15'th (or, worse, if it varies a lot in that time) then I think we'll need to re-assess. I expect to get well over 70% support starting Feb 1.

I'd rather use some common sense rather than spend days arguing about exactly what percentage aught to be specified in the BIP, or how many standard deviations of variance are acceptable between Feb 1 and 15.

I'm a bit confused as to why this is considered advantageous over OP_CHECKMULTISIG (https://en.bitcoin.it/wiki/BIP_0011).  In order to be able to tell If my bitcoin address is involved in a multisig transaction I first have to know the scriptSig?

Consider the following use case: I want to receive payment for some goods I've sold on an auction website. The buyer isn't happy with sending the entire funds up front so instead he sends me a two part multi signature transaction, on the condition that once I send him a tracking number he will provide the signature of his key. As I understand it there would be way for me as the seller to tell whether I have received any funds without the buyer contacting me and providing me with the script (which I then have to manually hash & verify). The payment won't show in my client, I can't get an alert from a 3rd party etc.

How would script hashes be represented in a wallet service? Should the script hash be masqueraded as a bitcoin address or should they be differentiated? OP_CHECKMULTISIG seems like it would be easier to represent in a client, you can label it "Payment of x received, requires approval of bitcoin address 1223".  I'm worried it could be very confusing for end users, people have a hard time understanding bitcoin addresses as is already.

I guess key exchange &  script verification & user notification are out of bitoin network, maybe in "Stratum"?

To bitcoin, redeemer need to provide right scripts to redeem these coins, and making scripts needs negotiations.

I don't think they make the two-person-escrow case you describe any simpler; use a plain CHECKMULTISIG for that case.

I think they might make third-party escrow easier; the escrow agent would get public keys from all the participants and then give the buyer a short script hash to send the funds into escrow, instead of giving them three separate public keys. If all the key gathering negotiation happens automatically (as it should) then it doesn't really matter, but I suspect that it will take a while to get a secure, convenient, well-supported multiparty transaction negotiation protocol defined and implemented. So I bet pay-to-script-hashes for escrow transactions will get copied and pasted (or put into emailed or SMS-ed URLs) for at least a year or two.

But the use case I REALLY care about is the secure, multiple-signatures-required-to-spend wallet. Script hashes are the same length as existing bitcoin addresses, so it should be much easier for services that can already send to bitcoin addresses to be modified to send to multisignature script hashes (if they use bitcoind to validate addresses then they will just need to update bitcoind; otherwise it is a trivial change to their bitcoin-address-validation routine to recognize the new pay-to-script-hash format).

Hopefully more than 30% of miners have enough common sense to oppose.

Why is it necessary to rely on a third party escrow service when most transactions could be made without?

For example #bitcoin-otc could provide a list of trusted representatives along with their bitcoin addresses which people can use as arbitrators. An (A + B) or (c) transaction where C is the arbitrator. Using CHECKMULTISIG I could imagine a form in the client with the destination address, a checkbox saying "Require authorisation from self" and an additional field "Add arbitrator" - relatively straight forward and the majority of transaction would not need to involve #bitcoin-otc or the arbitrator. However with P2SH hash #bitcoin-otc needs to have a web service to construct the transaction, users need to copy their public keys into the web service and once the script hash is constructed add it to their bitcoin client.


I started trying to think of different ways split key wallets could maintain compatibility with the existing widespread use of pay to address. The easiest way would be for wallet services to mange the private keys of a number of User's public addresses and automatically forward payments received using a user defined CHECKMULTISIG template.

The other method I came up with started getting a bit complex, but i'll post it anyway:

Redefine OP_NOP1 as a new opcode OP_ATTACH_SCRIPT. Conceptually it would allow the owner of an address to pre register a script which must be run before funds can be redeemed allowing them to change authentication method at their own free without needing to move funds.

After an OP_ATTACH_SCRIPT any successful call to OP_CHECKSIG will cause the top stack item to be inserted into an index using the pubKey as the primary key.
All calls to OP_CHECKSIG in a scriptSig that reference a public key which has an attached script cause the script to be retrieved and executed using the current stack. If the scriptSig contains a OP_ATTACH_SCRIPT it is executed after.

You first need to attach a script to an address by using a transaction with a scriptSig in the following format (example two signature transaction (A + B)).


Execution:

OP_PUSHDATA1 33 {[pubkey2] OP_CHECKSIG} <sig> <pubKey> OP_ATTACH_SCRIPT OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
<script> <sig> <pubKey> OP_ATTACH_SCRIPT OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
<script> <sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
<script> <sig> <pubKey> <pubKey> OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
<script> <sig> <pubKey> <pubKeyA> <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
<script> <sig> <pubKey> OP_CHECKSIG
On success ** attachedScripts.put(<pubKey>, <script>) **

Funds are sent to the address using the a standard scriptPubKey template.


Once a script is attached subsequent scriptSigs need to prepended with each additional signature and then the standard scriptSig template.


For new clients this is executed as follows:

<sig> <sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG   
<sig> <sig> <pubKey> <pubKey>   OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG   
<sig> <sig> <pubKey> <pubHashA> <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG   
<sig> <sig> <pubKey>  OP_CHECKSIG
On success ** attachedScripts.find(<pubKey>) **
<sig> {[pubkey2] OP_CHECKSIG}

The script will validate for old clients as :


Remove multi sig support using:


Redefine multi sig as A + (B or C) using:


Advantages:
1) Maintain full out of the box compatibility with existing pay to pubKeyHash - payments will appear in all existing bitcoin clients.
2) Needs only to include additional [pubKeys] once on script attach, not in every scriptsig. This would potential save 32 bytes per 2 key transactions, 64 bytes per 3 key transactions etc.
4) Maintain consistency of the scripting language
5) You can change the authentication required for a particular address. People can enable multiSig on their existing vanity addresses, You can change "Wallet protection services" without needing to change address.
6) Potentially allow people to "trade" addresses for example you could buy a popular vanity and change the authentication type by hand removing the need to trust that the original key was removed. Same concept can be applied to physical bitcoins, or bitbills.

Disadvantages:
2) Client needs to track what pub keys have a Script attached. An index like this is needed:
   
   
This would need to be updated during re-org.

3) Like P2SH this needs 50% miners adoption - old clients may find themselves on the shorter side of the blockchain.
4) Need to "register" an address by sending at least one transaction from it, addresses would be more permanent and less disposable.

I propose OP_NOP1 become OP_CODEHASHCHECK (therefore this proposal is called "CHC"). When this instruction is encountered, it:
1. Extracts all the code in scriptSig from the last OP_CODESEPARATOR (per static analysis) onward
2. Performs a HASH160(code) - call this the "codehash"
3. Compares this codehash to the top item of the stack
4. If this comparison fails, aborts the transaction as a failure

This should be safe, staticly analyzable, and sanely compatible with the existing scripting system.

One downside: there is zero protection enforced by old clients (/P2SH/ at least verifies the spender knows the correct script). I consider this a non-issue since an attacker can find out the correct script as soon as the legitimate spending transaction gets relayed, and so long as the CHC miners have well over 50%, it should be fairly safe by the standard 6 confirmations.

Even if I don't understand deeper all the things of the discussion, this is my opinion:

The Bitcoin project was born to bring evolution the the actual monetary system.
I think that was the main idea: evolution against the old. ( I think also that many are here because of this, and not to simply become rich )
It couldn't born without this main idea, so I think that you should not abandon this line.

You have to push this project always to the best future evolution, and don't protect too much the actual system, even if we can name the actual system "v0.5.1".

If an implementation/idea is going to close many open doors on the evolution of Bitcoin, just to protect the some parts of the actual system ... I think that it's wrong.

Bitcoin project is really young, you can't limit it just now.

Or ideally those 5-6 individuals will vote AGAINST it in this case...

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

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

Whilst it's fun to think about these things, could we get agreement on the following things please:

• Redefining the block validation rules is difficult and expensive. If you look how much time has been spent on this rabbit hole already, the last thing we should be seeing are yet more proposals for even more complex changes.
• The whole OP_EVAL/P2SH thing is not required for secure wallets. It is an optimization. You can have a scriptPubKey using CHECKMULTISIGs encoded into an address just fine. It'd be long, but we're talking about a binary data structure encoded as text anyway.

I stress the last part because it's not at all clear to me that addresses containing a script hash are easier for people to add support for than an address containing a full script itself. They're both different types of addresses, and you'll have to do coding work to support either. Ultimately a decoded address just contains bytes. Whether you copy those bytes into a magic scriptPubKey template, or use the bytes as the full contents of a scriptPubKey, doesn't seem to make much difference, except that the latter can be done without any controversial changes to Bitcoins design and the former doesn't.

I just pulled p2sh into master, replacing the OP_EVAL code that I pulled last month before the controversy erupted.

If you think it is a bad idea, then don't use it.  Hopefully it will inspire you to prove that I'm an idiot and completely wrong about people continuing to use 30-something-character "bitcoin addresses" for the next year or three.

So how do people using master vote against /P2SH/?

Looks like Gavin's idea of a vote is forcing people to vote in his favour unless they edit code. If you run latest git master, you are voting for this terrible proposal.

Merge https://github.com/bitcoin/bitcoin/pull/755 to get a choice (-p2sh or -nop2sh)

See also: https://bitcointalk.org/index.php?topic=58579.0

Can someone explain me ( us ) what is exactly the meaning of "safer-but-less-powerful"?
What are we going to miss?

If you trust all your ideas, I'm sure that you can explain it clearly.

As it's not an actual extension to the scripting language (as OP_EVAL and OP_CODEHASHCHECK are), you basically cannot use it in combination with (an actual) scriptPubKey. It's either or.

Sorry, I need also to speak clearly.

I was asking an explanation as I were your grandmother.

Newsflash, if you want support that quick, you better speak up.. Im just finding out about the change in the chain now...
This is bloody important! I love the idea.. just do it.. force us all too! lol

Could this be tested on testnet before it becomes mandatory in prodnet? Isn't that a good place to test potentially forking changes?

It has.

True! But this is a valid way to get backwards compatibility when extending a syntax. For example, C preprocessor directives like "#ifdef" are actually comments, but when a compliant preprocessor is present, they are executed before the actual code is compiled. Now, Alan Snyder, when he pushed for the addition of the preprocessor could have instead opted to add "eval" to C or he could have added special operators or keywords. But arguably, using a preprocessor with a backwards compatible syntax for this situation was a better choice.

I don't follow the argument that it's somehow best to solve the issue of moving the script from scriptPubKey to scriptSig on the scripting language level.

The reason we get these awkward domain-specific proposals (OP_DOSOMETHINGVERYSPECIFIC) or ultra-powerful proposals (OP_EVAL) is precisely because it's not generally the job of a programming language to move its own code from one place to another.

For example, to implement OP_CODEHASHCHECK we would need to change EvalScript to know about where scriptSig ends and scriptPubKey begins. The scripting language is not meant to be aware of the block chain, it is meant to be a simple, stack-based language.

P2SH does not require any change to EvalScript. That's because P2SH is not a change to the scripting language at all. It is a backwards compatible change to the block chain, allowing for a hash to reside in the transaction output and for the script to be executed to reside in the corresponding input. That strikes me as much cleaner than meta-opcodes which hack into the interpreter to move code around.

To clarify: I'm not arguing that implementation concerns should guide our protocol-level decisions, but what I am saying is that in this case the implementation hacks hint at a design-level problem. Namely that we are trying to make a scripting language do a preprocessor's job.

Finally, this provides a very pragmatic reason for P2SH. Because it doesn't change EvalScript, it doesn't require nearly as much testing as the other proposals. I'm ok with Luke's idea (in fact I suggested to roconnor that he drop backward compatibility from his OP_CODEHASH proposal and that would have been CHC/CHV), but I prefer P2SH and I would request a much longer testing period if CHC/CHV was accepted.

Gavin,

I just wanted to double check that it has been considered what would happen if the serialised script itself matches the P2SH template. From the wording of the BIP it's sounds like it probably has been considered:


Otherwise there might be dos potential in a script of the following format:

scriptSig: <sig> <serializedScriptA> <serializedScriptB>
scriptPubKey: OP_HASH160 <scriptBHash> OP_EQUAL

Where <serializedScriptB> deserializes to "OP_HASH160 <scriptAHash> OP_EQUAL".

If only <serializedScriptB> was checked as being standard then a potentially malicious script could be hidden in <serializedScriptA>i.e. <serializedScriptA> could contain hundreds of OP_CHECKSIG's
 

serializedScriptA would never be executed, so it can contain whatever it wants. To the script interpreter it would be just a piece of data. P2SH only transposes the last stack item.

Agreed but in my understanding the initial scriptPubKey would transpose <serializedScriptB> into another scriptPubKey that if allowed would transpose <serializedScriptA>. If it isn't already an exception needs to be made so that the scriptPubKey resulting from deserializing <serializedScriptB> it can no longer be interpreted as a P2SH scriptPubKey.

No, the preprocessor only runs once, so there is no recursion.

Hey guys,

Your work is really crucial, and this modification seems really important. But saying that I understood at least half of it is a lie. At the moment, understanding girls seems easier than what you're talking about.  ;D If you want to have at least 55% of the miners to understand this, explain it clearly and simply.


My grandmother also want to understand. Please, explain to us the big picture if you want the modification to happen. And if you're against, what do you suggest instead (again, in a simple way)?

Thanks!

At this stage in the proceedings, with the resources out there to educate yourself, if you don't understand what's being discussed, your opinion is not relevant.

ByteCoin

Never mind, i'm an idiot. Proposal withdrawn.

I know my opinion is not relevant on that case, you learn me nothing new. My job is to mine, not to code and discuss Bitcoin scripts about OP_WHOCARES. But my GHash are relevant in that situation, and that's the same for all the miners out there.

I just came here to know about the situation, and help you to inform other miners about this if it worth it. I taught that having a simple message about the modification, so you can convince around 6 THash to adopt this could be a good idea.

But hey, if you don't give a **** about it, that's fine. I'm going to make the extra step in February to be sure that my workers don't support that modification. Seems Luke don't support it, so I'll ask him for any advice if I need them.

Thanks!

Your opinion matters, but like he said, all the information is out there.  A clear explanation will be given when a new client is released with one of these features if you can't bother to get up to speed to contribute to the decision of which route to take.

What exactly are you opposing?  Nothing has been released yet.  Perhaps instead of picking sides we should focus the discussion on reaching consensus about the advantages and disadvantages of each proposal.  Personally, I like the compromise of P2SH, but with it's own OP code.  Can anyone explain the aversion to add an OP code, and why it is worse than hacking it into the scripting system?

From what little I gather

p2sh requires a change that is incompatible with the current chain and way of doing things..It ultimatly requires everyone to upgrade..
Which is fine for me, because progress is being made..

Other people are suggesting other ways to allow multiple signatures using the current chain, and not needing an upgrade.

Please please correct me if Im wrong..

I have faith in Gavin.. plain and simple.

Every proposal will require upgrade.  That's not the issue.  The question I asked gets at it I believe, hopefully someone more knowledgeable will answer me.  It boils down to adding an OP code vs tainting the scripting system with a special case template.  Gavin just wants to be done with this functionality as this is the second attempt at implementation.  Luke-Jr isn't convinced it's the correct solution and has provided a simpler alternative that extends the protocol with an OP code instead of changing block validation rules.

Adding an op code is not a problem, satoshi designed this as the intended upgrade path.


However when you define a P2SH op code it becomes almost exactly the same as OP_EVAL. This brings with it a host of security concerns because it A) allows recursion and B) You can manipulate the hash using other operations before it's executed. Basically it leaves too many "What ifs" to be implemented quickly.

As you explained Luke-jr doesn't like Gavin's proposal because it taints the scripting system forcing that templates become a mandatory part of the language. Visa Versa Gavin doesn't like Luke's proposal because it also "taints" the scripting system, but in a different way. It requires that the scriptPubKey is able to look at data in the scriptSig which is not on the stack.

Thanks for the clarification... I was thinking of OP_NO_SKIP, but I got it confused with the proposal in Luke-Jr's thread.  Would it be possible to create a pull request to make it easy to see just the OP_NO_SKIP changes from github.

I commented on OP_NO_SKIP here: https://en.bitcoin.it/wiki/Talk:BIP_0017_DRAFT

OP_P2SH doesn't have to be OP_EVAL.  See here (https://bitcointalk.org/index.php?topic=58579.msg691937#msg691937).

Yes I caught this mistake after I posted it. Thanks for taking a look anyway.

One more attempt before I give up https://en.bitcoin.it/wiki/BIP_UNOFFICIAL_DRAFT

piuk:  please read BIP 0001, it describes the process for getting BIP numbers assigned.

I read through the bitcoin-dev archive's discussion of OP_EVAL, and don't understand the extent of the concern about Turing completeness.  Guaranteeing resource limits on script execution is important, but runtime constraints like limiting numbers of recursions already go a long way toward imposing these guarantees.  Defense in depth of these guarantees is important, too, but if such a heavily-scrutinized proposal can go months without anyone noting that it affords Turing-completeness then relying on formal analysis Script-the-language to guarantee resource constraints by static analysis is infeasibly delicate and unreliable. 

A more direct and robust defense-in-depth would be for bitcoin's Script implementation to track the resource usage resulting from the execution of each opcode, and reject the script as invalid when usages exceed some thresholds.  If static analysis is currently valuable for miners assessing whether it's worth their while to process a given transaction, then OP_EVAL could be extended to include guarantees on the memory usage and counts of the opcodes and signatures executed by the script which invokes it, guarantees which could be ensured by simply rejecting the script if it violates them. 

Beyond the advantage of greatly strengthening the resource constraints, this approach would probably be much less expensive than junking all the analysis, development and testing put into OP_EVAL so far.

The issue you are discussing is way too complex for me to understand, however i got an idea:

Can we perhaps invite all developers (who already wrote "some" Bitcoin code) here to vote on this before implementing in the mainline client ?
Perhaps a closed dev-only poll (done with posts) would suffice.

You know Gavin - after some thinking i understand that we need to constantly move forward, but you are perhaps going too fast about this.
Shouldn't there be a longer wait period before implementation of something that can split chains ?

I mean this is a serious change. Shouldn't this be programmed in a way so that it is activated at, for example, block 190.000 ? This way we would lower the risk of splitting chains & stuff.

Why the rush ? This may be actually dangerous for the network. Can't we have more time to adapt ?

I really like the idea of having a full featured scripting engine; and using resource tracking to decide if the script is valid or not.  This is where the cost lies, before the fact static analysis is nice… however the real cost is in the difficulty to execute a script -  not what functions the script implements.

The code is written and committed to the master branch, backports are available for every bitcoin release since 0.3.19, and I'm as confident as I can be there are no major bugs or "gotchas" hiding in the pay-to-script-hash code. Several of the big mining pools have been testing it and will start deploying it on the main network.

"This stuff" IS programmed in a way so it is only activated on the main network after an agreed-upon time.

There are still two weeks until we look and see how much support it has, and almost a month before /P2SH/ transactions are fully validated on the main network. You want to wait 30,000 more blocks?  More than 7 months? That's a darn good way to get everybody to ignore the issue for 6 months and then restart this debate from square one with 1 month to go and a whole fresh set of people who think they're being helpful suggesting using OP_ADD to combine private keys because they don't realize we thought about and discarded that idea 4 months ago.

It's not a big deal to take a few seconds to say this idea won't work or to post a link to where it has previously been discussed. No need to be arsey about it.

P.S. It was not documented that math operations are limited to 4 bytes, for example the BitcoinArmory client will not abide by this.

Hey Gavin, what do you think about making the new P2SH transaction recognition explicit rather than implicit?


I think that this would address Luke's (somewhat valid) complaint about the magic transaction special case code path, while still being exactly P2SH.

I just read the BIP and a few of the messages in this thread (not all).  The BIP states:

"The purpose of pay-to-script-hash is to move the responsibility for supplying the conditions to redeem a transaction from the sender of the funds to the redeemer."

Could someone tell me why this is a transaction/protocol level problem and not just limitation of current clients?  Why is it not sufficient to simply solve this problem by having the sender send to a normal address that the recipient then turns around and sends to another address that imposes whatever rules they would like?  This has already been discussed as the approach to enable the recipient to set the transaction fees (sender creates a fee-less transaction and the recipient then sends back to themselves with a fee attached).

It seems to me that this BIP isn't solving an actual problem or limitation and it doesn't actually provide a multi-sig capability.  Why can't multi-sig simply be handled as a two step process…sender crafts a transaction to a normal address that the recipient then sends to an address that imposes a multi-sig rule.  If such transactions are sent directly from sender to recipient, a single use address could be generated by the recipient software, given to the sender and the recipient software would automatically generate the follow-on transaction that moves everything to the multi-sig transaction.  This could all be done in a transparent way for the user (to them, they are just asking the software to create a multi-sig address to give to the sender).

What you describe is an ugly hack, in my opinion.  But you are right that it is an entirely doable ugly hack.

First, that scheme requires that the recipient have an active node running at all times, or at least often enough to sweep receipts occasionally.  Second, it requires more transactions, up to twice as many, but less if the system gathers multiple transactions before sweeping.  Third, it requires that the extra transactions embed the all of the key hashes, making them rather large, and combined with the second point, it means a lot of needless bloat.  Also, it means a lot of hard to predict fees, since all of the extra transactions will be working from new, fresh transaction outputs.

In P2SH, there are no extra transactions, all transactions can be small regardless of the complexity of the redemption scheme, fees will be low since the ordinary oldest coins first policy can be kept, and it can all be done offline.

Also, I just realized that the sweeping scheme can reduce privacy and anonymity, since a sender will be able to watch for their payment to get swept and try to deduce extra information from the protection scheme.  In P2SH, all details of the protection stay hidden until the coins are redeemed.

Yep, I agree but figured I'd ask the question anyway.  Has this been tested on testnet yet?

Yes, of course. I did most of my testing on 'testnet-in-a-box' nodes, but spent a day producing P2SH blocks and transactions on testnet; see, for example this transaction that spends a P2SH transaction:
  http://blockexplorer.com/testnet/tx/cff697a07fa21780b2553c6e86bf956cb42838b0e9b226da2c6b3cd7754da736

Today I created a smart 'transaction fuzzer', and tomorrow I'll be creating and running stress-tests for the new p2sh and multisignature code to try to catch anything code review and unit tests might have missed.

So what happens if I put two OP_P2SH's in a scriptPubKey?  What happens if I put one in a scriptSig? What if I put it inside an OP_IF ... OP_ENDIF ?

I think you're really just suggesting that the "magic" scriptPubKey be 24 bytes big instead of 23, and start with one of the NOP opcodes-- yes? In which case there is going to be a special case code path anyway.

Either ignore it and leave the flag set, or reject the transaction as invalid.  Ignoring it should be safe enough, but setting a limit (like 1) will prevent people from spamming up the chain with tons of pointless repeated NOPs.


Bounce the transaction, at least for now.  Maybe some day in the future we will be able to safely handle a full blown OP_EVAL, but we don't have to treat it like one right now.


You could either allow it to be set conditionally when encountered inside the script, or ignore placement and set the flag either way based on finding the opcode during static analysis.  Conditionally setting the flag might actually be useful.  I need to study up on the conditionals, but it could end up being a pretty short path to (N of M) or K, with transactions that could be triggered by either the P2SH script, or by the ordinary key.

We could even require that it be the first opcode for now, with the desire that the restriction be relaxed in the future, if safe to do so.


Well, not really.  There wouldn't be any magic scriptPubKey.  Any valid scriptPubKey could become magic by including the NOP.  In practice, this means that most P2SH scripts would be identical to NOP + the current magic script, but down the road when scripting is better developed, people would be able to trigger P2SH from an arbitrary script, maybe.

It could possibly turn out that there are no useful cases for combining ordinary scripts with P2SH, in which case it would turn out that all we've done is made the magic codes one byte longer.  Even then, having an explicit marker for "hey, I'm a special transaction" could turn out to be worth the ~5% bloat.

P2SH is the best solution I've seen (or thought of) for moving redemption logic to the redeemer.  I'm far more comfortable with it than the old OP_EVAL proposal.  I think BIP 16 is a move in the right direction although I haven't thoroughly reviewed the pull request.

I only say something because there seems to be a lot of opposition in this thread.  I figured a +1 from the gallery might be more valuable in that case.

I think you're correct (I think it's just that changes like this make people nervous).  What then is the next step to enable multi-sig?  Is everything needed already in the scripting language?  Is it just a matter of updating clients and miners to no longer reject such transactions?

Yes, the next step is to get miners and clients to recognize a new 'standard' transaction type that does multisig.  BIP 11 (https://en.bitcoin.it/wiki/BIP_0011) describes them, they're already supported in git HEAD and by the p2sh code, and old miners and clients will recognize and validate blocks that contain OP_CHECKMULTISIG transactions.

I run two kinds of nodes, a bitcoind node and a phoenix-miner node. Which one, or both, of these nodes needs to be updated to support P2SH?

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

Just the bitcoind node.

Very few miners still run bitcoind nodes. So all you need to do is get the top 2 or 3 pool operators to switch to the new code and you've secured the 55%. Are any of the pools on board so far?

Thankfully, the majority of big pools are opposing BIP16.

I dout that!  Dont' spread FUD.

Just by grepping the blk0001.dat file, I see 4 votes for, and 8 votes against.  I'm pretty sure that means that Luke is still against it, one person is for it, and the entire rest of the mining world is uncommitted.

Just wondering, where do you see any votes for BIP16? I see 602 votes for BIP12/OP_EVAL, 8 against BIP16, and 4 for BIP17/CHV. But I was commenting on verbal discussions with other poolops.

I'm guessing from the fact he said this, but: in the blk0001.dat file.

Yeah, that's where I got that. There is no "/P2SH/" in blk0001.dat...

I looked... you're right.  Perhaps he just looked for P2SH and saw your NOP2SH spam.

Yeah, I just grepped out p2sh and saw 8 NOP2SH and 4 p2sh.  If the 4 strings I found are actually for BIP17 instead of BIP16, it doesn't change my conclusion in the least.

Here's what I see:


What's with those "NOP2SH;p2sh/CHV"?

Voting against BIP16 (which uses "/P2SH/") and for BIP17 (CHV).

http://blockchain.info/p2sh

Can you make a pool list for P2SH and NOP2SH,
I guess miners should know what their pools are voting for.

I know Eligius support NOP2SH, and i leave that pool.

If a redeeming P2SH transaction (or any transaction for that matter) is validated by the network (and I know it hasn't been spent yet), do I need to keep the "in" part of the tx or can I scrap it out? If I understand the protocol, I can left it out; in that case I fully support P2SH as the space savings in the future will be HUGE.

Well...  If you validate it yourself, and can be pretty sure that your database won't get corrupted or attacked, you could toss it, maybe.  I would need to read the chaining rules again to be sure.  But I would be very reluctant to prune that aggressively, even if the blockchain growth somehow manages to severely outpace the size growth of cheap hard drives.

Once transactions are validated and buried "deep enough" in the blockchain you can forget their inputs, because the inputs are only needed for validation.

... although SOMEBODY on the network should remember them, in case I-don't-trust-anybody nodes want to validate the entire blockchain.

That's exactly what I thought.

This is one of the things I find very cool about bitcoin.  You can have a kind of rolling history.  Only a relatively small number of nodes will need to retain the full history (though more than one just in case some bad fate befalls it).  And this is sufficient since anyone at any time could download and verify that entire history from the beginning.  All the other nodes just maintain an in motion picture of the network, allowing ancient history to expire off the back end.

Another related thought that I've had is that transactions with more outputs than inputs should somehow cost more since they increase the overall number of transactions that nodes need to retain for verification purposes (and transactions that have a fewer number of outputs than inputs decrease the number of transactions that the network needs to retain).

Be careful with such artificial transaction fees, because it's not really the number of transactions that a given transaction begets that is the problem, but the total bandwidth consumption and computational demand upon the network.  In the near term, a single transaction with numerous outputs is more efficient most of the time.  This is because, with a transaction fee that is higher simply because of the actual demands of resources, a send-to-many transaction is less burdensome in the short term, and the longer term results of future transactions are unpredictable.  As an example, it would generally be vastly less resource intensive for a large corporation to use send-to-many transaction for weekly payroll then to produce a standard two-output transaction for each employee.  In either case, however, what the employees do with those transactions next are not dependant upon how they are paid.  Such large send-to-many transactions take up a lot of space and bandwidth, but remain relatively efficient if compared to the space and bandwidth that those same outputs would have produced individually.  We can assume that the send-to-many transactions will have a much longer 'lifespan' in the blockchain before they can be pruned, but we can also assume that some percentage of the individual transaction would have lasted as long.

Can a pool operator please mine a block containing a P2SH transaction on main net and redeem it. I'd like to a do some P2SH preperation, but don't have Testnet setup.

You can do it with Eligius. Just be sure to pay the appropriate fee.

I'll be doing a BIP 17 P2SH test as soon as I'm done integrating it with git master (the hard part is undoing the BIP 16 mess).

I'm for p2sh and my pool will provide /P2SH/ in coinbase in two days.

Edit: Actually I want to support Gavin with his effort, but I'll eventually support BIP 17 if there will be broader agreement on it and it became "official" replacement.

Eligius is on board for BIP 17.

Whoah, this went definately too easy.

I mean, how decentralized are we, really ? What if US took over 5 biggest pools and having ~65% the next day we would have massive scale attacks on the network ?
That would be a disaster. Perhaps a temporary one, but still a disaster. How long do you think it will take before they try something like this ?

Shouldn't we all push for decentralized pools, like P2Pool (https://en.bitcoin.it/wiki/P2Pool) ?

Yes.

I'd love so see a bitcoin client with p2pool-technology built in; bring back the "generate coins" option!

But... that will take a while. If I was a pool operator, though, I'd be thinking about other bitcoin-related businesses where I could use my expertise (the pool operators deserve a lot of credit, they've had to deal with DOS attacks, keeping their wallets safe, servicing hundreds or thousands of customers banging on their servers constantly, etc).

Yes, but if what you say actually happened, all the people mining on those pools would drop out and switch to another pool (or mine solo).  Still, it would be quite disruptive (large scale attacks on pools have shown that it can have a very disruptive affect on network hash power).  A number of months ago someone came up with an idea that would allow individual miners in a pool to craft their own blocks (including any transactions they see fit, but the coinbase would deliver coins to the pool, not the individual miner).  P2pool is probably better though.  Good software on top of p2pool (with pretty graphs, reports and such) might help in attracting more people to it.

I implemented one a month or two ago, with support for ButterFlyLabs's BitFORCE...

p2pool is nice, but it competes more with solo mining than pools. Short of some breakthrough idea, p2pool can't provide the low variance that the current centralized pools do.

What fees?

So use Eligius, not the three largest pools. Solved.

p2pool is already averaging almost 2 blocks a day, and getting even faster as it grows. IMO that's plenty low enough variance for the average miner.

Which is what i said.


Yeah i have seen it, but i don't remember the Topic ID. Could somebody supply a link ?

Actually, the pool operators should investigate using p2pool themselves.  I think there are probably plenty of value add services that a pool operator could provide even when something like p2pool is out there (graphing, payout history, monitoring and alerting, etc).  P2pool should also lower the pool operators' costs substantially (not having to maintain as much server and bandwidth or do as much to defend against DDOS, etc).

Actually, I'm not sure this makes sense without major protocol changes. Currently, if you throw away the transaction inputs you can't prove to other nodes that the transaction was actually buried in the blockchain at the place you claim it was - transactions are hashed as a single piece of data and there's no way of verifying the hash without the entire transaction. So it's not really safe to bootstrap new mining nodes without a complete transaction history including inputs, even if they don't validate the entire chain.

I asked that question regarding transactions that you know for sure if they have been spent or not. It was before I wrote this proposal (https://bitcointalk.org/index.php?topic=60911.0) to make sure I didn't misunderstand the protocol. Also, you can partially hash a transaction (in blocks of 64 bytes) until less than 64 bytes of the input section remains, so it would always ocuppy 63+32 bytes at most; but there's no need to complicate things. In my proposal you could just hash the outputs.