Bitcoin Forum
December 10, 2016, 06:47:48 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2] 3 4 5 6 »  All
  Print  
Author Topic: PULL request #748 : Pay-to-script-hash (OP_EVAL replacement)  (Read 11485 times)
doublec
Legendary
*
Offline Offline

Activity: 1078


View Profile
January 11, 2012, 11:24:49 PM
 #21

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).
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.
1481395669
Hero Member
*
Offline Offline

Posts: 1481395669

View Profile Personal Message (Offline)

Ignore
1481395669
Reply with quote  #2

1481395669
Report to moderator
1481395669
Hero Member
*
Offline Offline

Posts: 1481395669

View Profile Personal Message (Offline)

Ignore
1481395669
Reply with quote  #2

1481395669
Report to moderator
1481395669
Hero Member
*
Offline Offline

Posts: 1481395669

View Profile Personal Message (Offline)

Ignore
1481395669
Reply with quote  #2

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

Posts: 1481395669

View Profile Personal Message (Offline)

Ignore
1481395669
Reply with quote  #2

1481395669
Report to moderator
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
January 12, 2012, 12:07:54 AM
 #22

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%.

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.

How often do you get the chance to work on a potentially world-changing project?
piuk
Hero Member
*****
expert
Offline Offline

Activity: 910



View Profile WWW
January 12, 2012, 01:29:13 AM
 #23

I'm a bit confused as to why this is considered advantageous over OP_CHECKMULTISIG.  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.

finway
Hero Member
*****
Offline Offline

Activity: 714


View Profile
January 12, 2012, 02:28:06 AM
 #24

I'm a bit confused as to why this is considered advantageous over OP_CHECKMULTISIG.  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.

Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
January 12, 2012, 02:32:01 AM
 #25

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 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).

How often do you get the chance to work on a potentially world-changing project?
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2100



View Profile
January 12, 2012, 04:46:18 AM
 #26

I expect to get well over 70% support starting Feb 1.
Hopefully more than 30% of miners have enough common sense to oppose.

piuk
Hero Member
*****
expert
Offline Offline

Activity: 910



View Profile WWW
January 12, 2012, 10:44:06 AM
 #27

I think they might make third-party escrow easier;

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.

Quote
But the use case I REALLY care about is the secure, multiple-signatures-required-to-spend wallet.

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)).

Quote
scriptSig: OP_PUSHDATA1 33 {[pubkey2] OP_CHECKSIG} <sig><pubKey> OP_ATTACH_SCRIPT

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.

Quote
scriptPubKey: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

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

Quote
scriptSig: <sig> <sig> <pubKey>

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 :

Quote
scriptSig: <sig> <sig> <pubKey> OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

Remove multi sig support using:

Quote
scriptSig: OP_PUSHDATA1 1 OP_TRUE OP_ATTACH_SCRIPT <sig> <sig> <pubKey>

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

Quote
scriptSig: OP_PUSHDATA1 67 {1 [pubkey1] [pubkey2] 2 OP_CHECKMULTISIG} OP_ATTACH_SCRIPT  <sig> <sig> <pubKey>

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:
   
   
Quote
std::map<uint256, CScript> attachedScripts

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.



Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2100



View Profile
January 12, 2012, 04:42:05 PM
 #28

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.

HostFat
Staff
Legendary
*
Offline Offline

Activity: 2296


I support freedom of choice


View Profile WWW
January 12, 2012, 05:27:59 PM
 #29

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.

Eternity Wall: Messages lasting forever - The Rock Trading (ref): A good exchange / gateway Ripple, with support for multisig, since 2007. 
https://bitcointa.lk: Bitcointalk backup if offline - Bitcoin Foundation Italia - Blog: http://theupwind.blogspot.it
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2100



View Profile
January 12, 2012, 06:40:38 PM
 #30

To be honest, the state of the current mining situation makes it extremely easy to make this switch rather safely. As long as the major pool operators are in agreement, easy. You can have over 70% of the mining power with 5-6 individuals.
Or ideally those 5-6 individuals will vote AGAINST it in this case...

gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2030



View Profile
January 12, 2012, 06:41:02 PM
 #31

I'm a bit confused as to why this is considered advantageous over OP_CHECKMULTISIG.  In order to be able to tell If my bitcoin address is involved in a multisig transaction I first have to know the scriptSig?

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.

Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
January 13, 2012, 02:26:52 PM
 #32

Quote
But the use case I REALLY care about is the secure, multiple-signatures-required-to-spend wallet.

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. (snip)

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.
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
January 13, 2012, 03:33:21 PM
 #33

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.

How often do you get the chance to work on a potentially world-changing project?
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2100



View Profile
January 13, 2012, 03:39:14 PM
 #34

I just pulled p2sh into master, replacing the OP_EVAL code that I pulled last month before the controversy erupted.
So how do people using master vote against /P2SH/?

Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2100



View Profile
January 13, 2012, 05:30:49 PM
 #35

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)

Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2100



View Profile
January 13, 2012, 06:18:06 PM
 #36

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

HostFat
Staff
Legendary
*
Offline Offline

Activity: 2296


I support freedom of choice


View Profile WWW
January 13, 2012, 06:37:31 PM
 #37

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.

Eternity Wall: Messages lasting forever - The Rock Trading (ref): A good exchange / gateway Ripple, with support for multisig, since 2007. 
https://bitcointa.lk: Bitcointalk backup if offline - Bitcoin Foundation Italia - Blog: http://theupwind.blogspot.it
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2100



View Profile
January 13, 2012, 06:41:26 PM
 #38

Can someone explain me ( us ) what is exactly the meaning of "safer-but-less-powerful"?
What are we going to miss?
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.

HostFat
Staff
Legendary
*
Offline Offline

Activity: 2296


I support freedom of choice


View Profile WWW
January 13, 2012, 06:46:35 PM
 #39

Sorry, I need also to speak clearly.

I was asking an explanation as I were your grandmother.

Eternity Wall: Messages lasting forever - The Rock Trading (ref): A good exchange / gateway Ripple, with support for multisig, since 2007. 
https://bitcointa.lk: Bitcointalk backup if offline - Bitcoin Foundation Italia - Blog: http://theupwind.blogspot.it
teflone
Hero Member
*****
Offline Offline

Activity: 770


You're fat, because you dont have any pics on FB


View Profile
January 14, 2012, 01:45:59 AM
 #40

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%.

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.

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

For Canadians by Canadians: Canada's Bitcoin Community - https://www.coinforum.ca/
Pages: « 1 [2] 3 4 5 6 »  All
  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!