Transaction inclusion and exclusion

[jonald_fyookball]

I'm trying to better understand the inner workings of bitcoin so I can contribute my ideas about how to thwart the dangers of a 51% attack.

I understand one of the main threats being that a mining monopolist can arbitrarily exclude transactions.

My question for the moment is: what transactions does the protocol try to force to be included or excluded in a block?

[Foxpup]

None. A miner has complete freedom to choose which transactions are or are not included in the blocks they mine (by default, transactions paying fees are included in favour of ones that don't, but any arbitrary criteria can be used). However, any transaction that is rejected by one miner may be included in a later block by another miner, and the first miner cannot normally prevent this. However, during a 51% attack, no other miners can get their blocks into the main chain, so no other miners can include transactions that were rejected by the attacker (at least until the attack is over).

[jl2012]

what transactions does the protocol try to force to be included in a block?

Nope

what transactions does the protocol try to force to be excluded in a block?

Any invalid transactions

[fbueller]

You can see this happen when you compare Eligius vs other pools: Each pool can control what transactions get included in a block, usually based on fee's, size, etc. Most operators use a client which prevents non-standard transactions (really really unusual ones) from being included in a block. Given bitcoins scripting possibilities, there are still only two particular transaction types that are standard at the moment. Eligius will mine non-standard transactions into blocks, even though no one else will.

Standard transactions:
Pay to pubkey hash
Pay to script hash (very particular circumstances, ie, m < 3 && n < 4)
 - These will not be forced into a block, they will only be included if they have an adequate fee.

Non-standard:
p2sh addresses where m > 3, n > 4.
https://en.bitcoin.it/wiki/Script#Transaction_puzzle
other unusual scripts.
 - If you broadcast these, the nodes your connected to probably will not even relay the transactions to others. It has very little chance of propagation. It would need to be directly pushed to Eligius in order for it to go through.

Even though the majority don't allow non-standard transactions into the chain, one someone does, they will eventually trickle into blocks (With Eligius at 15% hashrate a non-standard txn with sufficient fee should confirm within an hour), and at which point they can be spent.

[jonald_fyookball]

I'm thinking about a system where nodes can look at old transactions, ordered chronologically.
Oldest transactions should be forced in, not left up to miner's discretion.  That's the basic idea.
What do you guys think?

[kjj]

I'm thinking about a system where nodes can look at old transactions, ordered chronologically.
Oldest transactions should be forced in, not left up to miner's discretion.  That's the basic idea.

How?  Why?

[DannyHamilton]

I'm thinking about a system where nodes can look at old transactions, ordered chronologically.
Oldest transactions should be forced in, not left up to miner's discretion.  That's the basic idea.
What do you guys think?

What if a miner hasn't heard about the old transaction?  How can the miner know when the transaction was created?  Have you really thought through all the details of what you're trying to do?

How would this scenario be handled?
You and I are both miners.
I hear about transaction A before I hear about transaction B
You hear about transaction B before you hear about transaction A

I mine a block with transaction A in it (and not transaction B)
You mine a block with transaction B in it (and not transaction A)

Which block belongs on the blockchain, and which is invalid?

[jonald_fyookball]

Thanks all for the responses.

Yes Danny, I'm generally aware of these kinds of issues that exist in a distributed system.
We have to create consensus among the nodes.

I haven't created an implementation plan yet...still gathering information to fully understand the problem.
Let me think about the "how" this can be done.

[DannyHamilton]

Yes Danny, I'm generally aware of these kinds of issues that exist in a distributed system.
We have to create consensus among the nodes.

The blockchain and proof-of-work is the consensus system.  And as you've already realized, the weakness is that it is subject to a 51% attack.

You're going to find this to be very difficult to "solve".

If a better solution for decentralized distributed consensus existed, bitcoin wouldn't be the revolutionary ingenious protocol that it is.

[jonald_fyookball]

yes but arent improvements being made every year?  little tweaks and upgrades that fix weaknesses?

[jl2012]

I'm thinking about a system where nodes can look at old transactions, ordered chronologically.
Oldest transactions should be forced in, not left up to miner's discretion.  That's the basic idea.
What do you guys think?

Thanks all for the responses.

Yes Danny, I'm generally aware of these kinds of issues that exist in a distributed system.
We have to create consensus among the nodes.

I haven't created an implementation plan yet...still gathering information to fully understand the problem.
Let me think about the "how" this can be done.

Bitcoin is ALREADY a consensus system for the chronology of transactions. So you are just going to reinvent bitcoin, or something that is fundamentally better than bitcoin.

[jonald_fyookball]

not trying to reinvent bitcoin!  just hoping to improve it a little.

thoughts:

1. longest-chain-wins  may be too simple.  could be longest-VALID-chain wins,
with some rules for validation, namely that the chain should include certain transactions.

2. transactions can be timestamped, either locally by each miner, or in some seperate
bucket or sidechain

3. in the event of a 51% attack, older transactions would eventually be forced into
the blocks, or nodes would start rejecting chains that are deemed corrupted (manipulated)

[jonald_fyookball]

My next question is what happens to the transactions that are received by a node.  Bitcoin transactions only take a few seconds, so every node receives the transactions being sent. What does it do with the transaction before it is entered into the block?  It sits in some bucket, right?  What happens if a node receives the transaction but it not in the next block?  At what point does it get discarded?

[kjj]

1. longest-chain-wins  may be too simple.  could be longest-VALID-chain wins, with some rules for validation, namely that the chain should include certain transactions.

Surely you can see that this path just closes the circle, right?  How do you create a distributed agreement on which transaction must be included?

2. transactions can be timestamped, either locally by each miner, or in some seperate bucket or sidechain

Ditto.

[jonald_fyookball]

1. longest-chain-wins  may be too simple.  could be longest-VALID-chain wins, with some rules for validation, namely that the chain should include certain transactions.

Surely you can see that this path just closes the circle, right?  How do you create a distributed agreement on which transaction must be included?

2. transactions can be timestamped, either locally by each miner, or in some seperate bucket or sidechain

Ditto.

Well, you build it into the protocol.

One problem though is that an attacker can try to circumvent the aims of the protocol.
For example, let's say you created a rule that you reject new blocks unless they contain
the oldest transactions, the attacker can flood the system with many of their own transactions
so most of the oldest ones are those of the attacker.