Topic: Refereed Transactions (Read 5195 times)

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.

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

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.

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.

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.


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.


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

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?

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

Dunno about OP_BLOCKNUMBER, but if this instruction returns the number of the block in which the script (or even the scriptSig) is meant to be included into, i can't see the problem... except for chain reorganisation.
Of course, it should not return the current block number as in "today's last blocknumber" in the case it is verified later.

I'd like to know if I'm missing something.

You're right -- it is impossible to do safely. The attacker could do something like:

I mean.. the only real issue i see is the timestamping vs chain reorg problem.

I'm not really sure your argument is valid or possibly I don't understand.
Bob would put the data in the chain when he provide the scriptSig (he forged using the certificated) to redeem his due.
He is supposed to do that before the deadline, and bitcoins are frozen until then. What fork could that induce?

Any script opcodes that import state from outside can be used to fork the block chain. It's not sufficient to have OP_BLOCKNUMBER only be spendable after N blocks as somebody can write a script that is valid up until a certain time and then becomes invalid, allowing arbitrary forking of the chain even in the absence of naturally occurring re-orgs.

Transactions that "mature" after a certain time are possible with nLockTime, although without replacement it's not that useful. 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.

Interesting! Strange that this ownership is symmetric in sender/recipient/escrow.

I was thinking that the referee should be left apart from the actual bitcoin transaction and would only sign a " gave his account prior to " certificate. But maybe it's a good way to deal with the deadline problem? (Referee would be trusted to handle the deadline correctly.)