BIP 17

[Gavin Andresen]

What frightens me is that there is no way back if we make this step and it turns out to be a wrong direction.

Please explain to me how ANY of the proposals (the original OP_EVAL, BIP 16, and BIP 17) are any different in the "what if we change our minds and want to remove support" case?

Removing support for BIP 17 would be harder than removing support for BIP 16, because if the network doesn't support it all BIP 17 transactions can be stolen as soon as they're broadcast.

Imagine there are a bunch of un-redeemed BIP 17 transactions in the block chain and support for BIP 17 goes away.  Every single one of them could be immediately redeemed by anybody.

The situation is better with BIP 16, because of the "half validation" done by old nodes.  Admittedly not a lot better, but it is the "belt and suspenders" nature of BIP 16 that makes me prefer it.

[1714925915]

1714925915

[1714925915]

1714925915

[1714925915]

1714925915

[Steve]

What frightens me is that there is no way back if we make this step and it turns out to be a wrong direction.

Please explain to me how ANY of the proposals (the original OP_EVAL, BIP 16, and BIP 17) are any different in the "what if we change our minds and want to remove support" case?

Removing support for BIP 17 would be harder than removing support for BIP 16, because if the network doesn't support it all BIP 17 transactions can be stolen as soon as they're broadcast.

Imagine there are a bunch of un-redeemed BIP 17 transactions in the block chain and support for BIP 17 goes away.  Every single one of them could be immediately redeemed by anybody.

The situation is better with BIP 16, because of the "half validation" done by old nodes.  Admittedly not a lot better, but it is the "belt and suspenders" nature of BIP 16 that makes me prefer it.

Isn't it still possible for anyone to spend out of a BIP-16 transaction if someone has ever revealed the public key (so, if you ever spend from a BIP16 transaction, you would certainly want to spend out of every transaction funding that address to avoid a chance that someone will spend those other transactions)?  

So, let me see if I can sum up the choices when changing the protocol (regardless of which proposal is adopted):

1) Make things backward compatible in order to avoid a chain split - this creates a risk that coins can be stolen because old nodes/miners aren't performing full validation on the new transactions…to avoid this risk you do what?  wait until 100% of all mining capacity has upgraded before using the new transaction types?

2) Ensure that no nodes (old/new, miner or non miner) allow any transaction that doesn't pass all validation and accept that a chain split could (will) happen - this creates a risk that people who don't upgrade can end up with un-spendable coins in their wallets (a double spend could be executed by creating a transaction accepted in the new chain, but not in the old, then spend those coins again on the old chain).

I'm not sure which is the better approach…just trying to make sense of it.  However, it feels like it's better to ensure coins can't be accidentally spent and that full validation is always performed.  If the super majority of the network is switching, then people will upgrade or patch…that's just part of the deal with bitcoin IMO.  I also question the wisdom of OP_NOP bytecodes.  Seems like it would be smarter to make them cause a script to immediately fail (if that were the case, we wouldn't be having this discussion, we would be talking about a clean implementation and a proper transition of the network).

[Steve]

Also, this whole debate makes me wonder whether it wouldn't be worthwhile factoring out the script validation/execution engine to allow that bit to be independently upgraded from the rest of the bitcoin client.  It might also help with unit testing and verifying a critical bit of code to keep it separated from everything else.

[Luke-Jr]

if the network doesn't support it all BIP 17 transactions can be stolen as soon as they're broadcast.

... and with every such proposal, lack of network support means the transactions can all be stolen as soon as someone else tries to redeem them. Not really much better.

[interlagos]

What frightens me is that there is no way back if we make this step and it turns out to be a wrong direction.

Please explain to me how ANY of the proposals (the original OP_EVAL, BIP 16, and BIP 17) are any different in the "what if we change our minds and want to remove support" case?
...

Yes, since any of the selected proposals will be cut in stone (in order for multisig transactions of this type to remain spendable) we will have to stick to it indefinitely. What I meant is that by making this brave step into unknown with BIP16 we might be violating some other properties of original Satoshi script which we haven't even thought of. Staying within current framework with BIP17 it is safer to assume that those properties will remain intact.

And as Luke pointed out it is still possible to make this transition later and support second type of multisig transactions or maybe new scripting system all together.

[jojkaart]

Also, this whole debate makes me wonder whether it wouldn't be worthwhile factoring out the script validation/execution engine to allow that bit to be independently upgraded from the rest of the bitcoin client.  It might also help with unit testing and verifying a critical bit of code to keep it separated from everything else.

Personally, I'd love to see Haskell code being used for that. It _is_ a rather big dependency though. Haskell code is, to the best of my knowledge, completely sandboxed if you disallow usage of IO Monad. Haskell is a strictly typed pure functional language which gives it some very nice properties, especially when writing code that needs to work just right and have no surprises.

[Luke-Jr]

Personally, I'd love to see Haskell code being used for that. It _is_ a rather big dependency though. Haskell code is, to the best of my knowledge, completely sandboxed if you disallow usage of IO Monad. Haskell is a strictly typed pure functional language which gives it some very nice properties, especially when writing code that needs to work just right and have no surprises.

Maybe the future BIP 12/16 replacement can evaluate Haskell?

[jojkaart]

Personally, I'd love to see Haskell code being used for that. It _is_ a rather big dependency though. Haskell code is, to the best of my knowledge, completely sandboxed if you disallow usage of IO Monad. Haskell is a strictly typed pure functional language which gives it some very nice properties, especially when writing code that needs to work just right and have no surprises.

Maybe the future BIP 12/16 replacement can evaluate Haskell?

That's a bad idea for precisely the same reasons as OP_EVAL is a bad idea

[Maged]

if the network doesn't support it all BIP 17 transactions can be stolen as soon as they're broadcast.

... and with every such proposal, lack of network support means the transactions can all be stolen as soon as someone else tries to redeem them. Not really much better.

Actually, it is somewhat better. Even if BIP 16 is one day removed (which would be stupid, so that's incredibly unlikely), the "half validation" provides the same protection as address transactions do if ECC is one day completely compromised. The built-in protection means that the owner of the transaction can still safely spend their funds if:
1) They wait until BIP 16 support is re-enabled.
2) They never broadcast the redeeming transaction themselves until it is in a block (either that they mined themselves, or they have someone trusted mine).

Isn't it still possible for anyone to spend out of a BIP-16 transaction if someone has ever revealed the public key (so, if you ever spend from a BIP16 transaction, you would certainly want to spend out of every transaction funding that address to avoid a chance that someone will spend those other transactions)? 

If support for BIP 16 is ever dropped, you'd be correct. However, just like normal addresses, each transaction should use a unique P2SH address. When I realized this, it blew my mind. The more things change, the more they stay the same...

So, let me see if I can sum up the choices when changing the protocol (regardless of which proposal is adopted):

1) Make things backward compatible in order to avoid a chain split - this creates a risk that coins can be stolen because old nodes/miners aren't performing full validation on the new transactions…to avoid this risk you do what?  wait until 100% of all mining capacity has upgraded before using the new transaction types?

Nope. We just need 50%. Any block containing an invalid P2SH transaction will be seen as invalid to the part of the network that supports P2SH. If that part of the network is over 50% of the hash power, it will eventually overtake the bad chain, keeping old clients connected to the correct chain.

2) Ensure that no nodes (old/new, miner or non miner) allow any transaction that doesn't pass all validation and accept that a chain split could (will) happen - this creates a risk that people who don't upgrade can end up with un-spendable coins in their wallets (a double spend could be executed by creating a transaction accepted in the new chain, but not in the old, then spend those coins again on the old chain).

Again, the only way a permanent chain split could happen is if over 50% of the hash power doesn't fully validate P2SH transactions.

I also question the wisdom of OP_NOP bytecodes.  Seems like it would be smarter to make them cause a script to immediately fail (if that were the case, we wouldn't be having this discussion, we would be talking about a clean implementation and a proper transition of the network).

A full protocol update would NOT be "clean". Old clients would permanently be stuck on their own network.

[sturle]

I like whoever proposed that the string in the coinbase refer to the BIP, in the future that's the way it should be done.

There is a problem with this approach.  Due to FUD spread by some people (well, mostly one), many see this as a kind of "vote" unrelated to the actual implementation of BIP 16.  Just put /P2SH/ in the coinbase to "vote".  If miners "vote" without actually validating the pay-to-script-hash transactions, there will be a miscount and chain splits may occur.  This is even more dangerous to BIP 17.  If I understand this correctly, until more than 50% of the hashing power validate BIP 17 transactions correctly, anyone can steal a BIP 17 transaction before it enters a block.  If a large pool "votes" BIP 17 in the coinbase without actually supporting the specification, this may well happen.

[Stefan Thomas]

BIP 16 gives 5-10 times more room for transaction growth than BIP 17 before bumping into block limits.

While somewhat incidental, I'd like to note that this seems to me to be a very strong, pragmatic argument in favor of BIP 16.

From a theoretical perspective I also feel that BIP 16 is better. If the goal is to store code differently, it is best to handle this before execution by a preprocessor and not via a special opcode that changes execution flow in non-trivial ways. I have a very easy time implementing and feeling comfortable with BIP 16 as it only affects the way scripts are stored/loaded and not how they are executed. There are no new opcodes which can be used in unexpected places or unexpected combinations and there is no change to EvalScript, which is an argument that anyone who has actually tried to implement this function securely has to give a lot of weight to.

[interlagos]

BIP 16 gives 5-10 times more room for transaction growth than BIP 17 before bumping into block limits.

While somewhat incidental, I'd like to note that this seems to me to be a very strong, pragmatic argument in favor of BIP 16.

From a theoretical perspective I also feel that BIP 16 is better. If the goal is to store code differently, it is best to handle this before execution by a preprocessor and not via a special opcode that changes execution flow in non-trivial ways. I have a very easy time implementing and feeling comfortable with BIP 16 as it only affects the way scripts are stored/loaded and not how they are executed. There are no new opcodes which can be used in unexpected places or unexpected combinations and there is no change to EvalScript, which is an argument that anyone who has actually tried to implement this function securely has to give a lot of weight to.

I quoted your post Stefan in the new thread under general Bitcoin discussion here:
https://bitcointalk.org/index.php?topic=61125.msg714569#msg714569
It seams more heated and there are more participants now.

[Stefan Thomas]

I quoted your post Stefan in the new thread under general Bitcoin discussion here:
https://bitcointalk.org/index.php?topic=61125.msg714569#msg714569
It seams more heated and there are more participants now.

Thanks, much appreciated.

[Costia]

I think it comes down to this:
Do people want to introduce something new to the bitcoin scripting system or use a hack and keep the old one.
Gavin's main concerns seem to be keeping old clients functional.
My preference is to introduce a new opcode. But i do not feel that bip17 is mature enough since it introduces new security risks.
So i think something like bip17 should be implemented, but in a way that cannot be exploited/misenterpreted by older clients even if BIPXX has less than 50% support.

[chrisrico]

edit... oops, posted in the wrong thread

[Luke-Jr]

But i do not feel that bip17 is mature enough since it introduces new security risks.
So i think something like bip17 should be implemented, but in a way that cannot be exploited/misenterpreted by older clients even if BIPXX has less than 50% support.

BIP 17 does not introduce any new security risks that aren't also risks with BIP 16.

[Costia]

But i do not feel that bip17 is mature enough since it introduces new security risks.
So i think something like bip17 should be implemented, but in a way that cannot be exploited/misenterpreted by older clients even if BIPXX has less than 50% support.

BIP 17 does not introduce any new security risks that aren't also risks with BIP 16.

it does. if you send a new transaction before 50% of the hash power is updated it will be redeemable by anyone
with bip16, you will at least need to know the script - its not much, but its not nothing either.

I think the whole "how to do updates" issue should be discussed on general terms, and not just in the context of these BIPs. Its not the last major change you will do to bitcoin.
Currently there are n't even any update notifications - so people have to manually check the website/forum every month or so...

[Luke-Jr]

But i do not feel that bip17 is mature enough since it introduces new security risks.
So i think something like bip17 should be implemented, but in a way that cannot be exploited/misenterpreted by older clients even if BIPXX has less than 50% support.

BIP 17 does not introduce any new security risks that aren't also risks with BIP 16.

it does. if you send a new transaction before 50% of the hash power is updated it will be redeemable by anyone
with bip16, you will at least need to know the script - its not much, but its not nothing either.

And to redeem it, you have to make the script known even before your redemption gets confirmed. So any rogue miner/relayer can easily swipe it the moment you try to spend.

[Costia]

still better than nothing

[Steve]

But i do not feel that bip17 is mature enough since it introduces new security risks.
So i think something like bip17 should be implemented, but in a way that cannot be exploited/misenterpreted by older clients even if BIPXX has less than 50% support.

BIP 17 does not introduce any new security risks that aren't also risks with BIP 16.

it does. if you send a new transaction before 50% of the hash power is updated it will be redeemable by anyone
with bip16, you will at least need to know the script - its not much, but its not nothing either.

And to redeem it, you have to make the script known even before your redemption gets confirmed. So any rogue miner/relayer can easily swipe it the moment you try to spend.

Right, so it's clear that with either BIP-16 or BIP-17, it's not a prudent thing to use the new transactions until we're well beyond 50% support.  But you have to admit that with BIP-17, it's a hole you could drive a truck through while with BIP-16 it's more like threading a needle (you'd have to get really lucky that you saw a transaction well before the rest of the network saw it or you'd need control over a substantial amount of hashing power (yet another argument against large pools).

My bigger concern is Gavin's concern about the state of the script implementation code (how well it's understood, how well it's tested).  I think everyone is largely in agreement about how transactions should work in ideal circumstances (at least, I pretty much agree with Gavin's other post about it).  But it's prudent to consider the risk of the unknowns in code that people don't seem to fully understand or trust to be free of potentially devastating bugs.