Bitcoin Forum
December 05, 2016, 12:40:33 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: BIP17 backward compatability  (Read 859 times)
Costia
Newbie
*
Offline Offline

Activity: 28



View Profile
January 26, 2012, 06:27:08 AM
 #1

can you make OP_CHECKHASHVERIFY to remove the last stack item?
then you can add OP_DEPTH 0 OP_EQUAL at the end of the public sig which will cause old clients to reliably fail verification unless they verify the script - i.e. support bip17.
1480941633
Hero Member
*
Offline Offline

Posts: 1480941633

View Profile Personal Message (Offline)

Ignore
1480941633
Reply with quote  #2

1480941633
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Maged
Legendary
*
Offline Offline

Activity: 1260


View Profile
January 26, 2012, 05:47:02 PM
 #2

can you make OP_CHECKHASHVERIFY to remove the last stack item?
then you can add OP_DEPTH 0 OP_EQUAL at the end of the public sig which will cause old clients to reliably fail verification unless they verify the script - i.e. support bip17.
Huh? You don't WANT old client to fail verification unless you purposely want to fork the chain, and if we do that, we might as well make other changes, too.

Costia
Newbie
*
Offline Offline

Activity: 28



View Profile
January 26, 2012, 05:51:27 PM
 #3

If the old clients aren't a majority why would it fork the chain?
If they are a majority, the alternative will be that all BIP17 transactions are spendable by anyone.
What am i missing here?
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
January 26, 2012, 06:52:13 PM
 #4

What am i missing here?
If the old clients won't verify it, they will reject the block containing it entirely, no matter how many other nodes say it's legit.

Costia
Newbie
*
Offline Offline

Activity: 28



View Profile
January 26, 2012, 06:53:51 PM
 #5

bummer
Smiley
Costia
Newbie
*
Offline Offline

Activity: 28



View Profile
January 26, 2012, 10:12:53 PM
 #6

how about this:

sig1 OP_0 sig1 sig2 SEPARATOR 2 pub1 pub2 2 checkmultisig pub1

hash <hash(pub1)> compare checksig <hash(x)> OP_CHECKHASHVERIFY OP_DROP

x is all the mess from the separator up to the hash(x)
the pub will be twice as long but at a const. length (the complex script can be as long is it needs)
an old client will always verify at least the first sig
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
January 26, 2012, 10:34:26 PM
 #7

how about this:

sig1 OP_0 sig1 sig2 SEPARATOR 2 pub1 pub2 2 checkmultisig pub1

hash <hash(pub1)> compare checksig <hash(x)> OP_CHECKHASHVERIFY OP_DROP

x is all the mess from the separator up to the hash(x)
the pub will be twice as long but at a const. length (the complex script can be as long is it needs)
an old client will always verify at least the first sig
Could use OP_DUP and such instead of the sig twice... but not too bad of an idea, actually! Addresses would end up a little long, but maybe not entirely unmanagable: 8TAwKxdJjw3tjdWJFhLg3PPnhaYFic1rHzDMTqmZukt1d2y8yFwEhAJndKcBM (length 61)

This is based on 1 byte version (= 5), 20 bytes "script hash", 20 bytes "script hash" XOR "first signature hash" (so you can't change one without changing the other...), and then the usual 4 bytes checksum.

Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!