Topic: PULL request #748 : Pay-to-script-hash (OP_EVAL replacement) - page 6. (Read 12717 times)

Right........


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.

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

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.

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.

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.

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.

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

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.

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

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.

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

pull request: https://github.com/bitcoin/bitcoin/pull/748

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)