Refereed Transactions

[gim]

The block in which the script is meant to be included into can't be known by people verifying the transaction.

You mean miners? They know the number of the block they (try to) generate or the number of the block they verify, as far as I know?

[ByteCoin]

Clients currently need to verify all transactions before they are relayed.

Because clients don't know what block a OP_BLOCKNUMBER transaction will get into, they can't easily verify the transaction.

Workaround: Verify the transaction with the current blocknumber. When a new block arrives, kick the verified transaction back into the just received queue. Forbid OP_BLOCKNUMBER transactions from being spent with zero confirmations. To speed up reverification, the results of checking signatures could be cached.

Obviously miners know what the block number is when they try to incorporate the transaction into a block.

Any script opcodes that import state from outside can be used to fork the block chain.

It's not obvious to me that this is true. I presume that the forking mechanism relies on the clients disagreeing among themselves about the state and the transaction being structured so that this disagreement changes who gets the coins. If everyone is forever in agreement about what the outside state was when the transaction was included in the block chain then I don't see the problem. Please explain if a problem remains.

Also scripting isn't really disabled. You just have to get your new script into the whitelist and then convince some miners to upgrade. All clients will understand that new script type afterwards.

The point of scripting is to allow primitive operations to be combined in various ways to produce a predictable overall behaviour which possibly has never been seen before. Alternatively, transaction types could be hard coded to conform to specific behaviour which is well known and understood. The current behaviour is much more like the latter than the former so I think it's true to say that scripting is disabled.

ByteCoin

[Mike Hearn]

I presume that the forking mechanism relies on the clients disagreeing among themselves about the state and the transaction being structured so that this disagreement changes who gets the coins. If everyone is forever in agreement about what the outside state was when the transaction was included in the block chain then I don't see the problem. Please explain if a problem remains.

It's safe if the scripts can't import anything which changes (like the time or the current block number). For instance nothing stops somebody from signing the current block index, and then having that index and the signature put into a script as constants.

If a script can access outside state then look at Theymos' example. You can make a script that is valid, included into the chain and then suddenly becomes invalid. Everyone would begin building a new chain starting at that point - but as the attacker you knew that would happen, so you already made a longer chain yourself. You can now reverse transactions at will, defeating the point of BitCoins security.

[theymos]

It's safe if the scripts can't import anything which changes (like the time or the current block number). For instance nothing stops somebody from signing the current block index, and then having that index and the signature put into a script as constants.

If OP_BLOCKNUMBER expanded into "the block this transaction is in" rather than "the current block" (when the transaction is in a block), and these transactions had a maturation time, wouldn't that be OK? The block number of the transaction can't be changed without a reorg, and we assume reorgs won't be longer than ~100 blocks.

[ByteCoin]

If a script can access outside state then look at Theymos' example. You can make a script that is valid, included into the chain and then suddenly becomes invalid.

As Theymos indicates above, OP_BLOCKNUMBER pushes on the stack the block number which the transaction occupies (or is likely to occupy) in the block chain.

Miners know what the block number is going to be when they are trying to mine blocks and hence they check that the OP_BLOCKNUMBER transaction is valid for that block.

Given a block chain containing OP_BLOCKNUMBER transactions, if the OP_BLOCKNUMBER transaction was ever valid then it will remain valid as (apart from reorgs) transactions don't change block numbers.

Please post whether you think a problem remains with OP_BLOCKNUMBER now that this point has been clarified.

ByteCoin

[Mike Hearn]

I don't know. It sounds OK if there is also a maturation time. I'll ask Satoshi next time I send him a bunch of questions.