Topic: Binding transaction to previous block (Read 874 times)
That will probably never be implemented because it's too dangerous. Search for OP_BLOCKNUMBER.
What you intend to do is possible with the scripting mechanism, but that is not presently implimented.
could you explain?
The whitepaper describes a rudimentary scripting system, wherein transactions are requesting that the miners run a simple script. This scripting mechanism allows many other forms of complex transactions to occur, such as coins that can be claimed by more than one party, or that require signatures from more than one party, in order to be valid. Conditional transactions that can be delayed until such-n-such block number, and can be revoked or replaced prior to that block number; or even coins that can be claimed by any address that can produce the right keycode. Such transactions just languish in the transaction queue until they can be satisfied as valid by their own internal script. Currently, this scripting mechanism isn't implimented in the current client, and it doesn't look like it will be for some time.
within the scripting mechanism, how do you retrieve current block number or hash of previous block? from what I have read there are no constants like OP_PREVHASH or OP_BLOCKNUM. Transactions being delayed from being locked until block n is handled by lock_time which is not part of the scripting.
I'm just going by the commands listed on https://en.bitcoin.it/wiki/Script, and as far as I understand even if all of these commands were implemented in the client transactions scripts still cannot in any way reference the current block number or the previous block hash which would be required to create a transaction that expires in not included in the block.
What you intend to do is possible with the scripting mechanism, but that is not presently implimented.
could you explain?
The whitepaper describes a rudimentary scripting system, wherein transactions are requesting that the miners run a simple script. This scripting mechanism allows many other forms of complex transactions to occur, such as coins that can be claimed by more than one party, or that require signatures from more than one party, in order to be valid. Conditional transactions that can be delayed until such-n-such block number, and can be revoked or replaced prior to that block number; or even coins that can be claimed by any address that can produce the right keycode. Such transactions just languish in the transaction queue until they can be satisfied as valid by their own internal script. Currently, this scripting mechanism isn't implimented in the current client, and it doesn't look like it will be for some time.
within the scripting mechanism, how do you retrieve current block number or hash of previous block? from what I have read there are no constants like OP_PREVHASH or OP_BLOCKNUM. Transactions being delayed from being locked until block n is handled by lock_time which is not part of the scripting.
I'm just going by the commands listed on https://en.bitcoin.it/wiki/Script, and as far as I understand even if all of these commands were implemented in the client transactions scripts still cannot in any way reference the current block number or the previous block hash which would be required to create a transaction that expires in not included in the block.
What you intend to do is possible with the scripting mechanism, but that is not presently implimented.
could you explain?
The whitepaper describes a rudimentary scripting system, wherein transactions are requesting that the miners run a simple script. This scripting mechanism allows many other forms of complex transactions to occur, such as coins that can be claimed by more than one party, or that require signatures from more than one party, in order to be valid. Conditional transactions that can be delayed until such-n-such block number, and can be revoked or replaced prior to that block number; or even coins that can be claimed by any address that can produce the right keycode. Such transactions just languish in the transaction queue until they can be satisfied as valid by their own internal script. Currently, this scripting mechanism isn't implimented in the current client, and it doesn't look like it will be for some time.
What you intend to do is possible with the scripting mechanism, but that is not presently implimented.
could you explain?
1. You do not have a guarantee that your transaction will be included in the next block mined, it might take several generated blocks for someone to include your transaction,
2. Your transaction will be retained as a pending transaction by mining nodes until it is included in the blockchain. It won't be discarded just because it was included in a block that was orphaned.
I think your questions allude to a perceived issue that is not present.
2. Your transaction will be retained as a pending transaction by mining nodes until it is included in the blockchain. It won't be discarded just because it was included in a block that was orphaned.
I think your questions allude to a perceived issue that is not present.
I understand that currently transactions will still be propagated if the block is orphaned and get added back into the new chain, but I want a way to make a special transaction that expires if it does not get included in the next block. This is not a bug report, this is a feature request.
What you intend to do is possible with the scripting mechanism, but that is not presently implimented. Creating a client that does not favor the fork branch with the longest proof of work is very dangerous, and is more likely to introduce another attack vector than solve any perceived problem with the basic proof of work problem. There exist more security checks in the protocol (some in the present client, others only proposed) than just the proof-of-work itself, so it's unlikely that your concerns are not already addressed. However, I don't really understand your concern.
1. You do not have a guarantee that your transaction will be included in the next block mined, it might take several generated blocks for someone to include your transaction,
2. Your transaction will be retained as a pending transaction by mining nodes until it is included in the blockchain. It won't be discarded just because it was included in a block that was orphaned.
I think your questions allude to a perceived issue that is not present.
2. Your transaction will be retained as a pending transaction by mining nodes until it is included in the blockchain. It won't be discarded just because it was included in a block that was orphaned.
I think your questions allude to a perceived issue that is not present.
My idea is once this is available clients can keep a list of trusted addresses (including all that are in their wallet) and if they see a transactions from these addresses in a block they can use it to weight the blockheight count of different forks so they will pick a shorter more trusted branch over a longer untrusted branch, reducing a chance of a 51% attack. If transactions can be locked directly behind a specific block it keeps the attacker from including the transactions in their fork and using their trust.
Currently is there a way to force a transaction to occur only after a specific block, so if it is not included in the very next block it becomes invalid? Or will this require a new opcode in the transaction script that gives the hash of the previous block?
Jump to: