Gold collapsing. Bitcoin UP.

[Mengerian]

remember that, if i'm right, and full blocks are indicating additional incremental demand due to currency crises, this is going to be a more regular thing.  this is what we've theorized about for years.  the network HAS to be ready if you want to Moon.

1MB isn't going to cut it.  right now, unconf tx's are now up to 10000 with now >5TPS delays.

To be clear, I agree. Smoothly adjusting fees are another tool in the scaling toolbox, though, and should be ready for use as well. Where we're going, a 8 or 20x increase all by itself might not cut it. I'm eyeing a 500x price increase for the next bubble (peak, crashing afterward to 5-10x lower: ~$10-20K/BTC), which will mean a pretty big increase in transaction volume and may overrun even the 20MB blocks if we don't even have a fee market up yet.

We need as many scaling solutions in place as possible to enable the next bull run.

The nice thing about this debate is it's incentivizing them all. I'm confident we'll have the blocksize cap increase, hopefully in advance and not as a reaction to a stalled rally, but also a lot of other things. It's worth pushing against the small-blockers not because they have any real power to stop the increase, but because it lights a fire under them to do their part in making those optimizations to try to prove we can get by with smaller blocks. It's a futile effort on their part, but it ends up helping with large blocks, too.

Yes, it seems that increasing the blocksize limit is almost inevitable. No one can "centrally plan" bitcoin, at the end of the day anyone can run any software they want to interact with the network. It would be trivial for someone to branch off the source code using git, and release a version with Gavin's patch applied, or BIP 100, or some other change. Using git this version can easily track all the other developments, and all changes are well-defined and change history is cryptographically verified.

Since no one can apply top-down control over the network, we have to look at the incentives of the various participants. If miners, node operators, merchants, etc want larger blocks, then they would have an incentive to run software that allows a transition to larger blocks, and indicate that they are doing so.

The most overriding incentive is to stay in line with the network consensus. But if miners start mining blocks indicating that they implements BIP 100 or BIP 101, then network participants can indicate that they will accept larger blocks contingent on most others also accepting them.

In the longer term, it would also be good if this debate fosters a more diverse software ecosystem, which would allow other protocol changes to be decided by the market in this manner.

[1713902973]

1713902973

[1713902973]

1713902973

[1713902973]

1713902973

[1713902973]

1713902973

[1713902973]

1713902973

[1713902973]

1713902973

[Odalv]

we agree on the need for a fee mkt.  where we apparently disagree is where it is to be enforced.  i say, instead of with artificial block size caps which require a centrally planned decision with core devs, we offload it away from core devs to the actors involved directly in the tx negotiation; miners and users.  yes, miners might have trouble distinguishing btwn spam and real tx's but the point is that they can construct a block with however and whichever many tx's they wish to include based on their internal assessment of the situation at the time.  only they can do this.  

I agree with this, especially if you mean removing the hard cap entirely and letting orphan considerations limit the blocksizes based on miner choices.

only users can determine how much they are willing to pay.

Assuming you mean as part of a market process where users and miners meet at price points, I agree.

yes, this is what i mean.  thanks.

Yes, the more mining costs the more miners will mine.

of course, the sarcasm.

the point is, miners control the size of their blocks.  they will construct them to be profitable.

This with big hashing power will create rules. You .. small miner .. will have to accept all blocks they will create. If you are lucky then you found 1 block per month.  

[justusranvier]

Smart people have warned for a long time that zero-conf transactions are brittle.  If an 'industry' has built up around them, tough shit.

Serious question: are certain developers trying to get pushed out of their position? Is this all an elaborate warrant canary?

Employing those kinds of tactics means they become the damage around which the rest of Bitcoin will route.

[rocks]

I think tvbcof means to say Bitcoin wasn't ever going to be useful for point of sales. (I assume that means Bitcoin by itself.)

In the interest of not repeating old points, this is what Hearn has to say on this: https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d

Right.  I think the people pushing full-RBF are more interested in making on-chain Bitcoin transactions less useful for point-of-sales than the often-stated goal of allowing users to "unstick" stuck transactions.  Since we can "unstick" a TX in ways that are first-seen safe, why break a system (zero-confirm TXs) that many people currently enjoy (well unless you're of the ideology that Bitcoin should only be a settlement backbone)?    

...or unless your transaction can wait for some non-trivial amount of time to confirm to the level of reliability that is necessary for it.

I don't follow.  It sounds like you think it would be a good thing to make zero-confirm transactions less secure.  Is this true?

Zero-confirm transactions are totally insecure. Use it only if you are a gambling company.

Completely not true, and again there is a large bitcoin ecommerce industry that proves you wrong.

Receivers of well formed transactions (i.e. transactions where all inputs are already confirmed, include an appropriate fee, and which are accepted by all your P2P peers [meaning you did not receive any alternative broadcasts using the same inputs]) are very secure with today's P2P rules and easy to accept for nominal amounts.

full-RBF breaks this.

I'll broadcast 2 (or even 10) transactions to different nodes(and services) at same time  and you cannot know what transacion was FIRST.
I can make it harder if I'll brodcast transactions just after block is found ... or DDOS you during this time

You fundamentally do not understand how distributed P2P networks work if you believe that.

If you broadcast two different transactions at the exact same time, then there will be disagreement among peers over which transaction was first. Some of your peers would say transaction a was first and some would say transaction b was first.

In which case you've just broken the 3rd property of well formed transactions that I listed above (i.e. accepted by all of your peers).

In your example, it is easy to see that this transaction is not well formed, is at risk of being a double spend, and is thus not accepted until it confirms in a block.

That is how zero confirm transactions are proceeded today in a "safe enough" manner.

The only method to attack a well formed zero confirm transaction is to collude with a mining pool that agrees to include a transaction double spend that was not announced to the P2P network. Your chance of success is only as good as the miner's chance of finding the next block.

[cypherdoc]

I think tvbcof means to say Bitcoin wasn't ever going to be useful for point of sales. (I assume that means Bitcoin by itself.)

In the interest of not repeating old points, this is what Hearn has to say on this: https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d

Right.  I think the people pushing full-RBF are more interested in making on-chain Bitcoin transactions less useful for point-of-sales than the often-stated goal of allowing users to "unstick" stuck transactions.  Since we can "unstick" a TX in ways that are first-seen safe, why break a system (zero-confirm TXs) that many people currently enjoy (well unless you're of the ideology that Bitcoin should only be a settlement backbone)?    

...or unless your transaction can wait for some non-trivial amount of time to confirm to the level of reliability that is necessary for it.

I don't follow.  It sounds like you think it would be a good thing to make zero-confirm transactions less secure.  Is this true?

Zero-confirm transactions are totally insecure. Use it only if you are a gambling company.

Completely not true, and again there is a large bitcoin ecommerce industry that proves you wrong.

Receivers of well formed transactions (i.e. transactions where all inputs are already confirmed, include an appropriate fee, and which are accepted by all your P2P peers [meaning you did not receive any alternative broadcasts using the same inputs]) are very secure with today's P2P rules and easy to accept for nominal amounts.

full-RBF breaks this.

don't forget wallets like Mycelium that shows you a realtime flooding graph displaying when your particularly tx has hit 90% of the full nodes across the network and then working out a very small probability that it will not confirm based on a double spend.

That is awesome, is this on the Android app, in which case how did I miss seeing that...

https://www.reddit.com/r/Bitcoin/comments/1xqh51/new_mycelium_wallet_feature_confirmations_within/

[Odalv]

oh, how wonderful, Coinbase's node offline.  that's explains the flatline in the price i was seeing there.

"everything's just fine".

can't wait for the explanation.

https://www.reddit.com/r/Bitcoin/comments/3bo0bj/coinbase_not_processing_blocks_since_hours/

Little stress test and nodes fail one after another. Bring us 20 MB block and 90% nodes go down.

[Erdogan]

I think tvbcof means to say Bitcoin wasn't ever going to be useful for point of sales. (I assume that means Bitcoin by itself.)

In the interest of not repeating old points, this is what Hearn has to say on this: https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d

Right.  I think the people pushing full-RBF are more interested in making on-chain Bitcoin transactions less useful for point-of-sales than the often-stated goal of allowing users to "unstick" stuck transactions.  Since we can "unstick" a TX in ways that are first-seen safe, why break a system (zero-confirm TXs) that many people currently enjoy (well unless you're of the ideology that Bitcoin should only be a settlement backbone)?    

Retracing a bit here to comment on the bolded part.

A settlement backbone between service companies is really, really uncomplicated:

1. I guess you are ok with filling up a multiple fare ticket card using bitcoin.
2. Expand that ticket card to add-ons like food. If so, a unit of account is needed, that would be bitcoin. The value on the card is denoted in bitcoin
3 Expand that card to other transport companies. Plus other types of companies like shops.
4 Expand with the ability to use the card in shops who are customers of a competing and cooperating card company.

Now bitcoin is the settlement system.

[Peter R]

I think tvbcof means to say Bitcoin wasn't ever going to be useful for point of sales. (I assume that means Bitcoin by itself.)

In the interest of not repeating old points, this is what Hearn has to say on this: https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d

Right.  I think the people pushing full-RBF are more interested in making on-chain Bitcoin transactions less useful for point-of-sales than the often-stated goal of allowing users to "unstick" stuck transactions.  Since we can "unstick" a TX in ways that are first-seen safe, why break a system (zero-confirm TXs) that many people currently enjoy (well unless you're of the ideology that Bitcoin should only be a settlement backbone)?    

...or unless your transaction can wait for some non-trivial amount of time to confirm to the level of reliability that is necessary for it.

I don't follow.  It sounds like you think it would be a good thing to make zero-confirm transactions less secure.  Is this true?

Zero-confirm transactions are totally insecure. Use it only if you are a gambling company.

"Secure" and "insecure" are not absolute adjectives.  Something can be more secure or less secure than something else.  Zero-confirm transactions are less secure than 1-confirm transactions, which are less secure than 2-confirm transactions.  It is up to the recipient to choose the level of security required for the exchange, based on network heuristics "like the current card companies" do, as pointed out by Erdogan.  

I often encounter this strange absolutism with a certain subset of the Bitcoin community; it's something that I rarely see in "meatspace."  It's like certain people can't deal with the idea that shades of gray exists, and instead work to color everything black or white.  

[rocks]

Smart people have warned for a long time that zero-conf transactions are brittle.  If an 'industry' has built up around them, tough shit.

Serious question: are certain developers trying to get pushed out of their position? Is this all an elaborate warrant canary?

Employing those kinds of tactics means they become the damage around which the rest of Bitcoin will route.

Now that's a thought.

Let's take it farther, are they in fact being coerced against their will to take these positions. Given they fact that their arguments are obviously FUD and yet they supposedly understand Bitcoin, it might be their way of expressing there is a state gun to their head to weaken bitcoin. The full-RBF proposal is one such absurdity

[cypherdoc]

we agree on the need for a fee mkt.  where we apparently disagree is where it is to be enforced.  i say, instead of with artificial block size caps which require a centrally planned decision with core devs, we offload it away from core devs to the actors involved directly in the tx negotiation; miners and users.  yes, miners might have trouble distinguishing btwn spam and real tx's but the point is that they can construct a block with however and whichever many tx's they wish to include based on their internal assessment of the situation at the time.  only they can do this.  

I agree with this, especially if you mean removing the hard cap entirely and letting orphan considerations limit the blocksizes based on miner choices.

only users can determine how much they are willing to pay.

Assuming you mean as part of a market process where users and miners meet at price points, I agree.

yes, this is what i mean.  thanks.

Yes, the more mining costs the more miners will mine.

of course, the sarcasm.

the point is, miners control the size of their blocks.  they will construct them to be profitable.

This with big hashing power will create rules. You .. small miner .. will have to accept all blocks they will create. If you are lucky then you found 1 block per month.  

why would a small miner be any more likely to choke on a large block than a large miner?

[Peter R]

You fundamentally do not understand how distributed P2P networks work if you believe that.

If you broadcast two different transactions at the exact same time, then there will be disagreement among peers over which transaction was first. Some of your peers would say transaction a was first and some would say transaction b was first.

In which case you've just broken the 3rd property of well formed transactions that I listed above (i.e. accepted by all of your peers).

In your example, it is easy to see that this transaction is not well formed, is at risk of being a double spend, and is thus not accepted until it confirms in a block.

That is how zero confirm transactions are proceeded today in a perfectly safe manner.

The only method to attack a well formed zero confirm transaction is to collude with a mining pool that agrees to include a transaction double spend that was not announced to the P2P network. Your chance of success is only as good as the miner's chance of finding the next block.

Very clear explanation, rocks. 

[sickpig]

that said I was wondering if another thing we could do is limiting max tx size. Did you rember that no more than a one or two months ago Peter Todd said that chain someone put an entire book on the blockchain?

maybe not an absolute limit but a progressive fee per kb... just a thougth.

can you explain the technicalities of that attack?

was it only possible b/c of p2sh?  also, did it only involve a non standard tx?  if so, isn't that only something that a miner could include into a block he self generates?  and why haven't we seen widespread usage of that attack if it's so effective that we have to worry about it?

nothing special actually, borrowing from here http://bitcoin.stackexchange.com/a/25292

There is a maximum standard transaction size since Bitcoin 0.8.2 of 100k per transaction.

There are a number of other limits that influence the validation and propagation of a transaction though. Specifically:

A block is limited to 20000 signature verifications.
The block itself can't be larger than 1Mb.
The standard Bitcoin client (Bitcoin Core / bitcoind) will refuse to relay transactions flagged as dust.
Enough fee should be included (0.0001 BTC/kb)

emph on standard is mine. not standard != invalid.

so there's not a direct limit to tx max size. I'm not expert enough to get all the details, though.

if memory serves in ptodd's git hub repo there's a python script that let you leverage those weak limits to fill the block chain with data (a lot of), maybe it even try to minimize the fee amount.

that said what I'm proposing is to increase the fee per KB progressively. e.g. the first 100 KB  will cost you X satoshi each, from 100 to 200 X*2 etc etc

you could use  whatever's monotonic increasing function you see fit.

but maybe I'm too naive and this is wishful thinking, maybe as soon as the block space will become more scarce the market will take care of the problem automatically

[Erdogan]

blocks full again with TPS unacceptably high --> unconf tx set ~ 3000, more than double normal.  pools taking defensive action.  when will Blockstream devs do something?:

Why do you call this "defensive" action?

when Chinese pools face a series of what they consider to be "large blocks", which in this case means full blocks as you can see from the data, they automatically switch to mining "header" blocks with 0 tx's during the time it takes to process all the tx's in the preceding large block.  this is b/c large blocks take a bit more time to process and check all the signatures so the argument goes that they can't afford to waste that precious time so for defensive purposed they just go ahead and start hashing  the next block with only the  "header" that in this case contain no tx's that might have included an invalid input from the preceding large block.

How about: When they see a new block, they immediately start mining based on that, with an empty transaction list. When they have removed the transactions in the last block from their own list of transactions to include, they mine with the new list. If a block is found quickly, it will be the empty block, else it will be a block with the new list.

You can see that the zero transaction blocks always come a short time after the previous. But they should not need minutes to establish a new list, so I am not sure.

Maybe some miner can chime in and say what really is going on.

your first paragraph was correct.

i'm not sure why the 0 tx blocks come so fast after the previous block.  i keep asking this.

it's the sigop checking of a large block, i believe, that takes the extra time.

Well my first paragraph suggested a reason. They need time to construct a new transaction list. When that is done, new transactions can more easily be added. The first list is the time consuming part.

Edit: The block finding is completely random. It is just as probable to find a block the first second, as after several minutes.

i know the probability is random.  so why has every_single_one i've seen always been within a minute or two?

Because they need to frenetically keep mining to cover investments and cost. They have to start mining before they have a list of transactions, and sometimes they find a block in that time interval. A miner could easily confirm or refute this, if one is in the room.

[tvbcof]

Smart people have warned for a long time that zero-conf transactions are brittle.  If an 'industry' has built up around them, tough shit.

Serious question: are certain developers trying to get pushed out of their position? Is this all an elaborate warrant canary?

Employing those kinds of tactics means they become the damage around which the rest of Bitcoin will route.

Not exactly sure what you are getting at, but on one of these threads I posited that Gavin's recent actions with XT might actually have been something of a way of bowing out of something he didn't really want to be a part of.  A lot of people in a lot of spheres seemed to almost litterally have their jaws agape at what he was proposing and how.

From your text I sort of sense that you are wondering the same thing.  Not sure who you see as possibly taking such action though.  One way or another, good eyes!

[cypherdoc]

that said I was wondering if another thing we could do is limiting max tx size. Did you rember that no more than a one or two months ago Peter Todd said that chain someone put an entire book on the blockchain?

maybe not an absolute limit but a progressive fee per kb... just a thougth.

can you explain the technicalities of that attack?

was it only possible b/c of p2sh?  also, did it only involve a non standard tx?  if so, isn't that only something that a miner could include into a block he self generates?  and why haven't we seen widespread usage of that attack if it's so effective that we have to worry about it?

nothing special actually, borrowing from here http://bitcoin.stackexchange.com/a/25292

There is a maximum standard transaction size since Bitcoin 0.8.2 of 100k per transaction.

There are a number of other limits that influence the validation and propagation of a transaction though. Specifically:

A block is limited to 20000 signature verifications.
The block itself can't be larger than 1Mb.
The standard Bitcoin client (Bitcoin Core / bitcoind) will refuse to relay transactions flagged as dust.
Enough fee should be included (0.0001 BTC/kb)

emph on standard is mine. not standard != invalid.

so there's not a direct limit to tx max size. I'm not expert enough to get all the details, though.

if memory serves in ptodd's git hub repo there's a python script that let you leverage those weak limits to fill the block chain with data (a lot of), maybe it even try to minimize the fee amount.

that said what I'm proposing is to increase the fee per KB progressively. e.g. the first 100 KB  will cost you X satoshi each, from 100 to 200 X*2 etc etc

you could use  whatever's monotonic increasing function you see fit.

but maybe I'm too naive and this is wishful thinking, maybe as soon as the block space will become more scarce the market will take care of the problem automatically

so b/c a book size tx is non-std, the only way to get it into a block is for a miner to self mine it into his own block.  and, in today's situation, if a pool miner operator is caught doing that on a regular basis, his constituent hashing miners would leave him en masse.

therefore, this isn't a problem long run.

[cypherdoc]

You fundamentally do not understand how distributed P2P networks work if you believe that.

If you broadcast two different transactions at the exact same time, then there will be disagreement among peers over which transaction was first. Some of your peers would say transaction a was first and some would say transaction b was first.

In which case you've just broken the 3rd property of well formed transactions that I listed above (i.e. accepted by all of your peers).

In your example, it is easy to see that this transaction is not well formed, is at risk of being a double spend, and is thus not accepted until it confirms in a block.

That is how zero confirm transactions are proceeded today in a perfectly safe manner.

The only method to attack a well formed zero confirm transaction is to collude with a mining pool that agrees to include a transaction double spend that was not announced to the P2P network. Your chance of success is only as good as the miner's chance of finding the next block.

Very clear explanation, rocks. 

Odalv, stop, please!

[Odalv]

I think tvbcof means to say Bitcoin wasn't ever going to be useful for point of sales. (I assume that means Bitcoin by itself.)

In the interest of not repeating old points, this is what Hearn has to say on this: https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d

Right.  I think the people pushing full-RBF are more interested in making on-chain Bitcoin transactions less useful for point-of-sales than the often-stated goal of allowing users to "unstick" stuck transactions.  Since we can "unstick" a TX in ways that are first-seen safe, why break a system (zero-confirm TXs) that many people currently enjoy (well unless you're of the ideology that Bitcoin should only be a settlement backbone)?    

...or unless your transaction can wait for some non-trivial amount of time to confirm to the level of reliability that is necessary for it.

I don't follow.  It sounds like you think it would be a good thing to make zero-confirm transactions less secure.  Is this true?

Zero-confirm transactions are totally insecure. Use it only if you are a gambling company.

Completely not true, and again there is a large bitcoin ecommerce industry that proves you wrong.

Receivers of well formed transactions (i.e. transactions where all inputs are already confirmed, include an appropriate fee, and which are accepted by all your P2P peers [meaning you did not receive any alternative broadcasts using the same inputs]) are very secure with today's P2P rules and easy to accept for nominal amounts.

full-RBF breaks this.

I'll broadcast 2 (or even 10) transactions to different nodes(and services) at same time  and you cannot know what transacion was FIRST.
I can make it harder if I'll brodcast transactions just after block is found ... or DDOS you during this time

You fundamentally do not understand how distributed P2P networks work if you believe that.

If you broadcast two different transactions at the exact same time, then there will be disagreement among peers over which transaction was first. Some of your peers would say transaction a was first and some would say transaction b was first.

In which case you've just broken the 3rd property of well formed transactions that I listed above (i.e. accepted by all of your peers).

In your example, it is easy to see that this transaction is not well formed, is at risk of being a double spend, and is thus not accepted until it confirms in a block.

That is how zero confirm transactions are proceeded today in a "safe enough" manner.

The only method to attack a well formed zero confirm transaction is to collude with a mining pool that agrees to include a transaction double spend that was not announced to the P2P network. Your chance of success is only as good as the miner's chance of finding the next block.

This is exactly what I think about you. You are spreading nonsense after nonsense. You are living in ideal/happy world where
 - there is not cheating
 - there are not governments like in china, russia ... (the one in USA are not using CIA, FBI .. to control citiziens)
 - there are not terrorists
 - only bitcoin happy community exists MtGox, Pirate40 ... :-)

[Odalv]

You fundamentally do not understand how distributed P2P networks work if you believe that.

If you broadcast two different transactions at the exact same time, then there will be disagreement among peers over which transaction was first. Some of your peers would say transaction a was first and some would say transaction b was first.

In which case you've just broken the 3rd property of well formed transactions that I listed above (i.e. accepted by all of your peers).

In your example, it is easy to see that this transaction is not well formed, is at risk of being a double spend, and is thus not accepted until it confirms in a block.

That is how zero confirm transactions are proceeded today in a perfectly safe manner.

The only method to attack a well formed zero confirm transaction is to collude with a mining pool that agrees to include a transaction double spend that was not announced to the P2P network. Your chance of success is only as good as the miner's chance of finding the next block.

Very clear explanation, rocks. 

Odalv, stop, please!

OK, I agree with you ( I'm tired :-), and I believe readers are not stupid )
1. Zero confirmed transactions, are the safest way how to transact with bitcoin.  100% security is confirmed
2. The more mining costs the more miners will mine.
3. The bigger blocks are the less spam.
4. ... another pearls :-)

[sickpig]

so b/c a book size tx is non-std, the only way to get it into a block is for a miner to self mine it into his own block.  and, in today's situation, if a pool miner operator is caught doing that on a regular basis, his constituent hashing miners would leave him en masse.

therefore, this isn't a problem long run.

I'd say that 100k is quite big and valid.

anyway I'll take a look at the "Infamous" book tx to see who mined it.

[rocks]

I think tvbcof means to say Bitcoin wasn't ever going to be useful for point of sales. (I assume that means Bitcoin by itself.)

In the interest of not repeating old points, this is what Hearn has to say on this: https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d

Right.  I think the people pushing full-RBF are more interested in making on-chain Bitcoin transactions less useful for point-of-sales than the often-stated goal of allowing users to "unstick" stuck transactions.  Since we can "unstick" a TX in ways that are first-seen safe, why break a system (zero-confirm TXs) that many people currently enjoy (well unless you're of the ideology that Bitcoin should only be a settlement backbone)?    

...or unless your transaction can wait for some non-trivial amount of time to confirm to the level of reliability that is necessary for it.

I don't follow.  It sounds like you think it would be a good thing to make zero-confirm transactions less secure.  Is this true?

Zero-confirm transactions are totally insecure. Use it only if you are a gambling company.

Completely not true, and again there is a large bitcoin ecommerce industry that proves you wrong.

Receivers of well formed transactions (i.e. transactions where all inputs are already confirmed, include an appropriate fee, and which are accepted by all your P2P peers [meaning you did not receive any alternative broadcasts using the same inputs]) are very secure with today's P2P rules and easy to accept for nominal amounts.

full-RBF breaks this.

I'll broadcast 2 (or even 10) transactions to different nodes(and services) at same time  and you cannot know what transacion was FIRST.
I can make it harder if I'll brodcast transactions just after block is found ... or DDOS you during this time

You fundamentally do not understand how distributed P2P networks work if you believe that.

If you broadcast two different transactions at the exact same time, then there will be disagreement among peers over which transaction was first. Some of your peers would say transaction a was first and some would say transaction b was first.

In which case you've just broken the 3rd property of well formed transactions that I listed above (i.e. accepted by all of your peers).

In your example, it is easy to see that this transaction is not well formed, is at risk of being a double spend, and is thus not accepted until it confirms in a block.

That is how zero confirm transactions are proceeded today in a "safe enough" manner.

The only method to attack a well formed zero confirm transaction is to collude with a mining pool that agrees to include a transaction double spend that was not announced to the P2P network. Your chance of success is only as good as the miner's chance of finding the next block.

This is exactly what I think about you. You are spreading nonsense after nonsense. You are living in ideal/happy world where
 - there is not cheating
 - there are not governments like in china, russia ... (the one in USA are not using CIA, FBI .. to control citiziens)
 - there are not terrorists
 - only bitcoin happy community exists MtGox, Pirate40 ... :-)

So you have no counter argument to present or explanation on how to attack a well formed transaction beyond the one example I provided, and instead just bring tin foil hat nonsense to the table. Got it.