Re: [Bitcoin-development] New opcodes and transaction version numbers (was 'relax the IsStandard rules for P2SH transactions')
On Mon, Sep 29, 2014 at 12:30:11AM -0400, Alan Reiner wrote: > On 09/28/2014 10:35 PM, Peter Todd wrote: > > This can be solved by upgrading the address format at > > the same time to let senders know they must send the funds in a > > transaction with an increased version number, but obviously needing new > > addresses for every new opcode defeats the purpose of P2SH. > > Can't this be solved with a single update to the address format, > allowing a tx version number to be part of the address serialization? > Then the sending software will apply that version to the payment tx. > Of course, I'm not sure if allowing nodes to create transactions with > version numbers outside of their programming is safe. It seems like it > should be since we're talking about soft forks anyway, but there's > probably some subtleties I'm overlooking. Keep in mind that when a *wallet* - not a node - creates a transaction the scriptPubKeys in the transaction outputs have been specified by the receiver(s) and aren't executed until they are spent. Modulo sigops(1) there is absolutely no reason why the wallet should care what the contents of those scriptPubKeys are at all. This is particularly apparent when you remember that there may be multiple recipients of a transaction. If I'm paying Alice and Bob, who have specified that they want the transaction to have version number 2 and 3 respectively, now what? Do we take the highest of the two and constrain ourselves for how scripts are interpreted for all eternity? It just doesn't make very much sense. Meanwhile the man-hours of effort that would be required to implement that "one-time" address format change is huge - it took literally years for everyone to update their software to just support P2SH addresses. I'm working on a CHECKLOCKTIMEVERIFY implementation right now, and know of exchanges who would like to use it ASAP. Why make them wait years for everyone to upgrade? On that basis alone I think the question ought to be why should we use transaction version numbers to enable new opcodes rather than just enabling them globally based on block version numbers. 1) Satoshi implemented a per-block sigop limit to prevent blocks from causing an unreasonable number of signature checking operations, but rather than computing that limit based on the scripts actually executed, the limit is computed based on the contents of all scriptSigs and scriptPubKeys in the block. This is bizzare given that the contents of the latter are *not* executed, and the former misses the prevout scriptPubKeys that *are* executed. In short this means you can create a block that passes the sigop limit, yet executes millions of expensive signature operations by being filled with scriptSigs spending txouts with large numbers of sigops in their scriptPubKeys. P2SH improves on this situation somewhat by counting the sigops in redeemScripts towards the limit, but missed the opportunity to just count all sigops in all scriptSigs directly. -- 'peter'[:-1]@petertodd.org 092e056ab9c5a3242bfa911ba9a0a8a3836bcd4b5fcab2f8 signature.asc Description: Digital signature -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] New opcodes and transaction version numbers (was 'relax the IsStandard rules for P2SH transactions')
On 09/28/2014 10:35 PM, Peter Todd wrote: > This can be solved by upgrading the address format at > the same time to let senders know they must send the funds in a > transaction with an increased version number, but obviously needing new > addresses for every new opcode defeats the purpose of P2SH. Can't this be solved with a single update to the address format, allowing a tx version number to be part of the address serialization? Then the sending software will apply that version to the payment tx. Of course, I'm not sure if allowing nodes to create transactions with version numbers outside of their programming is safe. It seems like it should be since we're talking about soft forks anyway, but there's probably some subtleties I'm overlooking. -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] New opcodes and transaction version numbers (was 'relax the IsStandard rules for P2SH transactions')
On Thu, Jun 19, 2014 at 09:54:31AM -0400, Gavin Andresen wrote: > RE: soft-forks bumping version numbers: > > Yes, we have consensus that is the way we will do it. I should probably > turn https://gist.github.com/gavinandresen/2355445 into an informational > BIP. That gist is mistaken. To see the problem consider the "re-define OP_NOP1 to be OP_Q_CHECKSIGVERIFY" example. It says "Transactions that use the new opcode are given a new version number." The problem is in the definition of "use" Lets first suppose that the evaluation of a scriptPubKey was done according to the transaction version # of the transaction creating the scriptPubKey. This is technically feasible as the UTXO set records the version of the transaction creating the txout. However if I create a P2SH address whose redeemScript makes use of a new opcode - say the new OP_Q_CHECKSIGVERIFY - non-upgraded clients sending funds to that address will be creating scriptPubKeys whose contents can be spent by anyone. Not exactly ideal! This can be solved by upgrading the address format at the same time to let senders know they must send the funds in a transaction with an increased version number, but obviously needing new addresses for every new opcode defeats the purpose of P2SH. On the other hand suppose scriptPubKey evaluation is done according to the version of the transaction spending the scriptPubKey. This is insecure as now transaction outputs using the new opcode can be trivially spent by just spending them in a transaction with the previous version number; the OP_Q_CHECKSIGVERIFY is evaluated as OP_NOP and checks nothing. If txouts be spent only by transactions with nVersion >= the nVersion of the transaction spending them, but again you're forced to upgrade the address format for every new opcode. Interestingly this shows that the common assertion that "P2SH should have been done by upgrading the tx version #" is in fact wrong except for the fact that P2SH required an address format upgrade anyway; doing that for future opcode upgrades would be a mistake. With the above in mind the "Relax IsStandard rules for P2SH transactions" pull-req(1) is incomplete as it doesn't blacklist usage of the upgradable NOPx opcodes. After a future soft-fork redefining a NOPx opcodes' behavior non-upgraded nodes will accept and mine transactions that may now be invalid, the latter creating invalid blocks and thus false confirmations. I've created a pull-req to fix this issue by specifically blacklisting the NOPx opcodes if they are executed: https://github.com/bitcoin/bitcoin/pull/5000 Secondly the "Blockchain Rule Update Process" gist above should be rewritten to say that new opcodes will be enabled for all scripts by the block nVersion upgrade mechanism; scripts must never depend on a NOPx opcode being executed least they be rendered unspendable by a future upgrade. By comparison BIP62 proposes that the transaction version # be increased to indicate that the sender wants anti-malleability rules to be applied. This is an appropriate usage of tx version numbers as in this case the person creating the transaction wants the anti-malleability rules applied; the creator of the scriptPubKey's being spent does not care whether or not they are spent in a transaction that is or is not malleable. Equally the new owners of the txouts being created don't in general care how they were created. (modulo certain special-purpose protocols where they would have the transaction anyway) 1) https://github.com/bitcoin/bitcoin/pull/4365 -- 'peter'[:-1]@petertodd.org 05ec432fd4c506119a0123a028911fa3981bcde0568b66ab signature.asc Description: Digital signature -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
