Topic: BIP 17 - page 3. (Read 9151 times)
is there already an implementation of both BIPs?
BTW, why is the address of BIP17 longer than BIP16?
BIP17 and BIP16 both use BIP13 addresses...
you dont need computing power, you just send a competing transaction, and wichever gets first into a block will be accepted
BTW, why is the address of BIP17 longer than BIP16?
BTW, why is the address of BIP17 longer than BIP16?
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.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.
with bip16, you will at least need to know the script - its not much, but its not nothing either.
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.
still better than nothing
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.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.
with bip16, you will at least need to know the script - its not much, but its not nothing either.
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.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.
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...
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. 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.
edit... oops, posted in the wrong thread
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.
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.
I quoted your post Stefan in the new thread under general Bitcoin discussion here:
https://bitcointalksearch.org/topic/m.714569
It seams more heated and there are more participants now.
https://bitcointalksearch.org/topic/m.714569
It seams more heated and there are more participants now.
Thanks, much appreciated.
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://bitcointalksearch.org/topic/m.714569
It seams more heated and there are more participants now.
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 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. 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.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.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).
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. 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
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? 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.
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.
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. Jump to: