Bitcoin Forum
December 03, 2016, 02:27:22 AM *
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] 2 3 4 5 6 »  All
  Print  
Author Topic: PULL request #748 : Pay-to-script-hash (OP_EVAL replacement)  (Read 11465 times)
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
January 07, 2012, 02:10:58 PM
 #1

The consensus from Tuesday's IRC meeting 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)


How often do you get the chance to work on a potentially world-changing project?
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
genjix
Legendary
*
expert
Offline Offline

Activity: 1232


View Profile
January 07, 2012, 05:01:56 PM
 #2

pull request: https://github.com/bitcoin/bitcoin/pull/748
Andrew Vorobyov
Hero Member
*****
Offline Offline

Activity: 565



View Profile
January 07, 2012, 09:26:00 PM
 #3

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

pc
Sr. Member
****
Offline Offline

Activity: 253


View Profile
January 08, 2012, 02:41:42 AM
 #4

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

Activity: 742

BTCDig - mining pool


View Profile WWW
January 08, 2012, 03:57:48 AM
 #5

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

BTCDig - mining pool (Stratum, VarDiff, DGM, SSL, JSON API)
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
January 08, 2012, 01:40:45 PM
 #6

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.
pc
Sr. Member
****
Offline Offline

Activity: 253


View Profile
January 08, 2012, 10:00:33 PM
 #7

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.
vess
Full Member
***
Offline Offline

Activity: 141



View Profile WWW
January 09, 2012, 05:58:01 AM
 #8

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?


I'm the CEO of CoinLab (www.coinlab.com) and the Executive Director of the Bitcoin Foundation, I will identify if I'm speaking for myself or one of the organizations when I post from this account.
notme
Legendary
*
Offline Offline

Activity: 1526


View Profile
January 10, 2012, 10:22:08 PM
 #9

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.

https://www.bitcoin.org/bitcoin.pdf
While no idea is perfect, some ideas are useful.
12jh3odyAAaR2XedPKZNCR4X4sebuotQzN
blueadept
Full Member
***
Offline Offline

Activity: 225


View Profile
January 10, 2012, 10:30:44 PM
 #10

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.

Like my posts?  Connect with me on LinkedIn and endorse my "Bitcoin" skill.
Decentralized, instant off-chain payments.
notme
Legendary
*
Offline Offline

Activity: 1526


View Profile
January 10, 2012, 10:39:38 PM
 #11

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.

https://www.bitcoin.org/bitcoin.pdf
While no idea is perfect, some ideas are useful.
12jh3odyAAaR2XedPKZNCR4X4sebuotQzN
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
January 11, 2012, 12:38:25 AM
 #12

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.


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

Activity: 1078


View Profile
January 11, 2012, 11:26:57 AM
 #13

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

Activity: 1652


Chief Scientist


View Profile WWW
January 11, 2012, 03:24:48 PM
 #14

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

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

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.

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

Activity: 714


View Profile
January 11, 2012, 05:38:15 PM
 #15

Scary.

Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2086



View Profile
January 11, 2012, 06:38:51 PM
 #16

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

Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
January 11, 2012, 07:23:48 PM
 #17

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

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.

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

Activity: 2086



View Profile
January 11, 2012, 07:40:09 PM
 #18

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

No, not "something else", it is "if you see this very-specific sequence of bytes in the scriptPubKey then do this ADDITIONAL validation."
Ok, so "if you see a program that does X, after executing it, execute something else or you risk losing money"...

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

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.
OP_EVAL did that just fine.

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.
Breaking the protocol is not trivia.

Maged
Legendary
*
Offline Offline

Activity: 1260


View Profile
January 11, 2012, 10:18:23 PM
 #19

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.

ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 416


View Profile
January 11, 2012, 10:38:11 PM
 #20

If Satoshi thought that it was better to save a few bytes than to use a standard design, he would have used...

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
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!