Transaction that expires if not included in next block

[unabridged]

Is there a way to make a transaction that has to occur in the next block or it becomes invalid? Would you need a new transaction script opcode that gives the previous block hash so you can compare it?

My idea is once this is available clients can keep their own list of trusted addresses and if they see a transaction sent from these addresses in a block they can use it to weight the blockheight count of different forks so they can pick a shorter more trusted branch over a longer untrusted branch, reducing a chance of a 51% attack. If certain transactions can be locked directly behind a specific block it keeps the attacker from including these transactions in their fork and using that transaction's trust.

Then trusted members of the community can make these transactions every few blocks and users can subscribe to them by adding their address to their trust list. You can have the weighting grow large depending how far back the last trusted transaction occurred starting with, for example (n is current block height):

1 block back = normal weight
2 blocks back = 2x weight, so now a new fork would require a chain of height  >n+1 to orphan this block
3 blocks back = 3x weight, fork requires height >n+2 to orphan this block

As long as the weights are not too high it still makes it possible for the client to eventually get back onto the full network in the case of a legitimate fork, but makes it impossible for an attacker to grow a large chain in private. Also by not worry about the weighting until there is a risk of orphaning more than one block, the client only begins using extra resources to check for trusted transactions in rare occasions.

[1713976526]

1713976526

[ByteCoin]

No and yes respectively.

A number of mechanisms have been proposed to implement this, notably OP_BLOCKNUMBER however all parties accept that implementing it would break a number of important invariants.

I think it's safe to say that no such functionality will be implemented for the foreseeable future.

To address the thrust of your post - I'm confident that such a trust scheme will never be implemented in Bitcoin as it is more complex and prone to manipulation than the current system. I also believe that no Bitcoin-like scheme which "builds" trust in this fashion will ever succeed for roughly the same reasons.

ByteCoin

[makomk]

No. There's intentionally no way of tying transactions to blocks, because block chain reorganisations or even just blocks arriving sooner than expected would cause payments to simply disappear. Solidcoin 2 has a trusted block scheme based on trusted parties inserting transactions into the block chain and it failed exactly because transactions can't be tied to blocks. Your suggested method also opens up a whole bunch of new 51% attacks.

[unabridged]

No. There's intentionally no way of tying transactions to blocks, because block chain reorganisations or even just blocks arriving sooner than expected would cause payments to simply disappear. Solidcoin 2 has a trusted block scheme based on trusted parties inserting transactions into the block chain and it failed exactly because transactions can't be tied to blocks. Your suggested method also opens up a whole bunch of new 51% attacks.

These transactions would not be used for payments for that reason, they would just be a way for an account to sign a specific block chain by sending a small token amount (probably to another account they own). We could even force these transactions to have no output (money sent to miner) or output only to the same address to prevent using them for payment.

This is entirely unrelated to anything that solidcoin2 does, sc2 does not insert transactions into a normal block chain it just allows "trusted" nodes to create extremely low difficulty blocks after a normal block.

It would open up new attacks based on social engineering, but trust could be quickly removed by the user at any time.  The decentralized nature of how each user chooses which addresses to trust would make it difficult to perform. Each user choosing small set of addresses from a few prominent forum posters and exchanges would make it extremely difficult for an outside attacker to 51% the chain. And users who choose no trusted addresses would function exactly the same as the current client. While this may not be an issue with bitcoin because 51% is not a significant threat due to the size of the network, for a smaller chain I think this type of distributed voluntary trust would reduce 51% risk greatly.

[pc]

If all you're trying to do is have users sign off on which they think is the "most correct" blockchain, I think it'd be easier to just have accounts signing hashes of blocks they think are correct, and distributing those hashes separately, rather than trying to embed them in the blockchain somehow.

[Gavin Andresen]

If all you're trying to do is have users sign off on which they think is the "most correct" blockchain, I think it'd be easier to just have accounts signing hashes of blocks they think are correct, and distributing those hashes separately, rather than trying to embed them in the blockchain somehow.

+1

[unabridged]

If all you're trying to do is have users sign off on which they think is the "most correct" blockchain, I think it'd be easier to just have accounts signing hashes of blocks they think are correct, and distributing those hashes separately, rather than trying to embed them in the blockchain somehow.

I like this idea, would it be possible to distribute these signed hashes through the client protocol, similar to how tx are shared?