Bitcoin Forum
December 13, 2017, 02:33:04 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 [9] 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 »
  Print  
Author Topic: The Ethereum Paradox  (Read 84377 times)
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
February 16, 2016, 10:39:16 AM
 #161

For asset transfers, I need to think about the harm that can be done and whether the same problem applies. For scripting (with external I/O) it is clearly impossible to assume/enforce strict partitioning of state.

Case in point: atomic cross chain transfers. That's the realisation of the failure in contemporary blockchains. I don't believe it causes a breakdown of the nash equilibrium, though - the miners still follow their usual rules.

For readers, what monsterer is pointing out here is that the design of decentralized cross-chain (meaning two coins' block chains, not two candidate chains for the same longest-chain-rule block chain) exchange suffers from if either block chain orphans the block that the other block chain depended on, i.e. that a chain reorganization on one block chain of one coin isn't enforced on the other coin's block chain, thus one of the parties in the exchange steals from the other (because the one keeps the coins on both chains).

So monsterer is offering this as an example where even for only asset exchange block chains (i.e. no scripting), there is the case that external factors can cause the "system" to fail from the perspective of the user.

And this is the main problem with Blockstream's proposed Side Chains, in that chain reorganizations could cause a cascade of failure, which thus seem to make Side Chains totally insecure and unworthy of adoption. Some people have argued that exchanges could be delayed by sufficient confirmations, but remember that with proof-of-work a lie-in-wait 51% attacker can rewrite the entire block chain. Then again others point out that we are screwed any way with a 51% attacker and that the community will organize. Note I rebutted this in my video, by explaining that community can't organize. Please watch my video to get the full explanation. Note that the Chinese mining cartel already controls 65% of Bitcoin's hashrate and has vetoed any block size increase, not even allowing the doubling of block size for Bitcoin Classic, thus this has shown the community can't overcome a 51% attack.

You might argue that the author of any script which disobeys these hidden dependency rules isn't following the rules of the system.

For monsterer's example (not Side Chains), I argue that the user is capable of associating that failure with incorrect use of the system and localized to use of a decentralized exchange. Whereas the distinction from the partitioned scripting case is that users wouldn't even be able to know what service they used had caused the failure, because the failure could occur derivatively due to intertwined cascade from other scripts. In short, the users (or programmers) of violating scripts may be aware that the assumption of cross-partition has been violated, but the rest of the users would be incapable of making this determination!

The question is: is this problem actually fixable in theory? Can you imagine a system whereby a single transaction contains multiple downward dependencies which potentially merge partitions? Is there a case where a conflict in ordering dependency can occur between scripts?

Even the script can't stop a user from copying data from one partition to another. So even if Ethereum only runs authorized and vetted scripts, this afaics wouldn't totally ameliorate the issue.

Edit: Of course (external) I/O from scripts can input to other scripts in a myriad of cascade and permuted entanglement.

When I write 'external I/O', I mean differentiated from referencing some data on the block chain as an input, e.g. UXTO. You see that for asset exchange, the data is deterministic because all I/O must sum to 0 and the directed acyclic graph assures us there is no recursion of the state.

Edit#2: It appears to me that for asset exchange all I/O is deterministic. For scripting, this is not the case due to external I/O, not even without partitions! But at least without partitions, then scripting apparently doesn't violate the Nash equilibrium in the sense that all scripts are validated by all validators (thus there is no way for the validators for a partition to lie to the other validators). Whereas in partitioning, sufficient (w.r.t. to the consensus-by-betting resolution) validators might lie about their partition (i.e. pursue another strategy) since that is another game theory strategy that is introduced by the partitioning given that the partitions can't be enforced externally. The distinction is about Nash equilibrium. Per the definition of Nash equilibrium, then validators pursing another strategy (i.e. lying) destroys the Nash equilibrium.

No script fails from the perspective of the block chain. The external users see failure, because only the external users are aware they violated the strict partitioning of state. And thus the spaghetti of external failure becomes as intertwined as inputs and outputs from many partitions cross-pollute cascades and intertangled scripts.

Edit: the block chain thinks it is validating the block chain because it erroneously thinks strict partitioning is enforced. External users see that validation is failing, because they violated the assumption of strict partitioning by cross-polluting the state via the external I/O of the block chain. Thus holistically and systemically there is failure (from the perspective of the external users and thus the coin's market value plummets as users abandon the system due to failures).

1513132384
Hero Member
*
Offline Offline

Posts: 1513132384

View Profile Personal Message (Offline)

Ignore
1513132384
Reply with quote  #2

1513132384
Report to moderator
1513132384
Hero Member
*
Offline Offline

Posts: 1513132384

View Profile Personal Message (Offline)

Ignore
1513132384
Reply with quote  #2

1513132384
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1513132384
Hero Member
*
Offline Offline

Posts: 1513132384

View Profile Personal Message (Offline)

Ignore
1513132384
Reply with quote  #2

1513132384
Report to moderator
monsterer
Legendary
*
Offline Offline

Activity: 1008


View Profile
February 16, 2016, 10:57:11 AM
 #162

Even the script can't stop a user from copying data from one partition to another. So even if Ethereum only runs authorized and vetted scripts, this afaics wouldn't totally ameliorate the issue.

Edit: Of course (external) I/O from scripts can input to other scripts in a myriad of cascade and permuted entanglement.

When I write 'external I/O', I mean differentiated from referencing some data on the block chain as an input, e.g. UXTO. You see that for asset exchange, the data is deterministic because all I/O must sum to 0 and the directed acyclic graph assures us there is no recursion of the state.

What I mean is, is it possible to specify a set of non cyclic dependencies for any given transaction, which when ordered by the system results in a complete resolution of this dependency entanglement?
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
February 16, 2016, 11:13:12 AM
 #163

Even the script can't stop a user from copying data from one partition to another. So even if Ethereum only runs authorized and vetted scripts, this afaics wouldn't totally ameliorate the issue.

Edit: Of course (external) I/O from scripts can input to other scripts in a myriad of cascade and permuted entanglement.

When I write 'external I/O', I mean differentiated from referencing some data on the block chain as an input, e.g. UXTO. You see that for asset exchange, the data is deterministic because all I/O must sum to 0 and the directed acyclic graph assures us there is no recursion of the state.

What I mean is, is it possible to specify a set of non cyclic dependencies for any given transaction, which when ordered by the system results in a complete resolution of this dependency entanglement?

You are referring to asset exchange (not Ethereum's scripting). As you have stated, only the consensus mechanism can choose between the plurality of partial orderings because the partial orderings are arbitrary (and in the presence of competing double-spends, the partial orderings are conflicting). Thus Nash equilibrium depends on the consensus mechanism not being gameable which is the point I was making in my Edit#2 of my prior post.

I am interpreting your posts as you continue wishing for some sort of absolute, structural synchrony which can't exist in distributed systems. Did I misunderstand your question?

YarkoL
Legendary
*
Offline Offline

Activity: 978



View Profile
February 16, 2016, 11:22:28 AM
 #164

Some people have argued that exchanges could be delayed by sufficient confirmations, but remember that with proof-of-work a lie-in-wait 51% attacker can rewrite the entire block chain.

I think that any kind of attempted solution of any problem is subject to the same "criticism".

"Sure, this works... but remember that 51% attacker can rewrite the entire chain"

dev blog https://yarkol.github.io
BTC 18kHb54jqcpWEkuAkCFsGMzR6BMgYnpi2T
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
February 16, 2016, 11:26:53 AM
 #165

Some people have argued that exchanges could be delayed by sufficient confirmations, but remember that with proof-of-work a lie-in-wait 51% attacker can rewrite the entire block chain.

I think that any kind of attempted solution of any problem is subject to the same "criticism".

"Sure, this works... but remember that 51% attacker can rewrite the entire chain"

Good you pointed that out, so I can clarify.

The distinction for Side Chains is one block chain is subject to the 51% attack of the other block chain. So the security is only as strong as the weakest block chain.

YarkoL
Legendary
*
Offline Offline

Activity: 978



View Profile
February 16, 2016, 11:28:01 AM
 #166

Some people have argued that exchanges could be delayed by sufficient confirmations, but remember that with proof-of-work a lie-in-wait 51% attacker can rewrite the entire block chain.

I think that any kind of attempted solution of any problem is subject to the same "criticism".

"Sure, this works... but remember that 51% attacker can rewrite the entire chain"

The distinction for Side Chains is one block chain is subject to the 51% attack of the other block chain.

Well you got me again.

dev blog https://yarkol.github.io
BTC 18kHb54jqcpWEkuAkCFsGMzR6BMgYnpi2T
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
February 16, 2016, 11:28:39 AM
 #167

Some people have argued that exchanges could be delayed by sufficient confirmations, but remember that with proof-of-work a lie-in-wait 51% attacker can rewrite the entire block chain.

I think that any kind of attempted solution of any problem is subject to the same "criticism".

"Sure, this works... but remember that 51% attacker can rewrite the entire chain"

The distinction for Side Chains is one block chain is subject to the 51% attack of the other block chain.

Well you got me again.

See my edit. No you got me, because I failed to explain that clearly.

monsterer
Legendary
*
Offline Offline

Activity: 1008


View Profile
February 16, 2016, 11:30:26 AM
 #168

You are referring to asset exchange (not Ethereum's scripting). As you have stated, only the consensus mechanism can choose between the plurality of partial orderings because the partial orderings are arbitrary (and in the presence of competing double-spends, the partial orderings are conflicting). Thus Nash equilibrium depends on the consensus mechanism not being gameable which is the point I was making in my Edit#2 of my prior post.

I am interpreting your posts as you continue wishing for some sort of absolute, structural synchrony which can't exist in distributed systems. Did I misunderstand your question?

This is more a theoretical question about the overall solvability of the problem with scripting, dependencies and ordering. All inputs to a script come via a transaction, so, I am asking if there were a set of dependencies specifiable in any given transaction that forced the referenced transactions* to be ordered before the new transaction, is this enough for the system to decide on an overall order?

*) To address your other point, specifically in ethereum, dependencies would have to be specified as references to previous blocks, not previous transactions because, as you point out, there is only a partial order in a blockchain. The system would then have to group transactions with compatible dependencies into blocks.

In addition, yes, I am hoping an eventual total ordering of transactions is possible.
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
February 16, 2016, 11:53:43 AM
 #169

You are referring to asset exchange (not Ethereum's scripting). As you have stated, only the consensus mechanism can choose between the plurality of partial orderings because the partial orderings are arbitrary (and in the presence of competing double-spends, the partial orderings are conflicting). Thus Nash equilibrium depends on the consensus mechanism not being gameable which is the point I was making in my Edit#2 of my prior post.

I am interpreting your posts as you continue wishing for some sort of absolute, structural synchrony which can't exist in distributed systems. Did I misunderstand your question?

This is more a theoretical question about the overall solvability of the problem with scripting, dependencies and ordering. All inputs to a script come via a transaction, so, I am asking if there were a set of dependencies specifiable in any given transaction that forced the referenced transactions* to be ordered before the new transaction, is this enough for the system to decide on an overall order?

*) To address your other point, specifically in ethereum, dependencies would have to be specified as references to previous blocks, not previous transactions because, as you point out, there is only a partial order in a blockchain. The system would then have to group transactions with compatible dependencies into blocks.

In addition, yes, I am hoping an eventual total ordering of transactions is possible.

If you are talking about scripting, then I think you've failed to entirely understand the point. That is that the data specified as input to any script can't be prevented from being taken from another script (in another partition) by the external entity that provided that "transaction" as you call it. The data can't be dependently typed such that it totally orders the universe external to the block chain. That is a fundamentally known fact of computer science and the Second Law of Thermodynamics. This is for example why Haskell has the IOMonad and the Control.Monad.ST.Unsafe. A 100% dependently typed program is 100% deterministic and thus can't be programmed to do anything new, i.e. it is an entirely closed system and can't accept any external entropy.

If you want to talk about total eventual ordering of transactions for directed acyclic graphs, I think we should do so in your thread.

monsterer
Legendary
*
Offline Offline

Activity: 1008


View Profile
February 16, 2016, 11:57:45 AM
 #170

If you are talking about scripting, then I think you've failed to entirely understand the point. That is that the data specified as input to any script can't be prevented from being taken from another script by the external entity that provided that "transaction" as you call it.

That is exactly the point, though - if the external entity is required to specify the dependencies explicitly, the system ought to be able to reach an appropriate ordering.

If you want to talk about total eventual ordering of transactions for directed acyclic graphs, I think we should do so in your thread.

I wasn't driving at discussing that, it just naturally appeared as a direct consequence of looking at your problem statement for ethereum.
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
February 16, 2016, 11:59:17 AM
 #171

If you are talking about scripting, then I think you've failed to entirely understand the point. That is that the data specified as input to any script can't be prevented from being taken from another script by the external entity that provided that "transaction" as you call it.

That is exactly the point, though - if the external entity is required to specify the dependencies explicitly, the system ought to be able to reach an appropriate ordering.

Re-read my prior post. You seem to not understand basic facts of computer science and thermodynamics, i.e. you can't prevent the external entity from lying.

monsterer
Legendary
*
Offline Offline

Activity: 1008


View Profile
February 16, 2016, 12:06:19 PM
 #172

Re-read my prior post. You seem to not understand basic facts of computer science and thermodynamics, i.e. you can't prevent the external entity from lying.

Try to stay civil please. External inputs to a script always come in the form of a transaction. Any given transaction may depend on other transactions. As long as this dependency constraint is respected in the resulting overall ordering of transactions, I'm not sure there is a problem?
stoat
Sr. Member
****
Offline Offline

Activity: 322


View Profile
February 16, 2016, 12:14:41 PM
 #173

Anonymint chatting absolute horse cock again.

0x8d1b4e41652eacec5715dc5c4833f6b713573de6 If you agree with me, please support a friend of mine in need.
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
February 16, 2016, 02:16:52 PM
 #174

Re-read my prior post. You seem to not understand basic facts of computer science and thermodynamics, i.e. you can't prevent the external entity from lying.

Try to stay civil please. External inputs to a script always come in the form of a transaction. Any given transaction may depend on other transactions. As long as this dependency constraint is respected in the resulting overall ordering of transactions, I'm not sure there is a problem?

What did I write that wasn't civil and factual?

If a student was babbling nonsense in front of the entire classroom and the Professor tried to amicably ask the student to please go study a bit more because he doesn't seem to understand some basic issues, and the student continued to ramble on filling up the entire 2 hour class session with his misunderstanding, would the Professor be uncivil to finally put his foot down and demand "please stop".

I don't know why you can't comprehend what I have already written. The "transaction" which contains the input data for a script, can be set by any external entity. How do you propose to require that the bits & bytes of that input data declares its dependencies when it is impossible to force the external entity to declare where the data came from? You seem to not understand some basic facts about modularity and type systems in programming. Even if you could force the external entity to declare the full lineage of the input data (i.e. 100% dependently typed), that would require that the scripting can't be programmable, i.e. the external I/O capability would be eliminated. If you don't understand why, please go learn about the typing systems Coq and Epigram.

Please review a post about typing Modularity from Philip Wadler on Gilad Bracha's blog (hope you realize who those two guys are) and note his post immediately followed my post. My post was even deeper than Wadler's and in fact what I wrote there in 2011 is exactly what I am writing here about Ethereum. If anyone wants to identify a god in computer science, Philip Wadler would rank orders-of-magnitude higher than Szabo. Even the Lex Spoon who comments after Wadler wrote the book on Scala. Gilad only wrote the specification for Java.

You should know that Wadler invented the Expression Problem, which is precisely about how to produce statically typed extensible programmability without needing to refactor and recompile. I did a lot of research on this Expression Problem and even Stackoverflow deleted some of my earlier research.



Anonymint chatting absolute horse cock again.

You are so ignorant of Computer Science that you don't even know the difference between horse shit and a textbook.

How can anyone expect me to be nice to you, when you belittle academics.

I suppose it is good you are so stupid that you don't realize how stupid you are, as it can be considered a defense mechanism against depression. Ignorant bliss.

monsterer
Legendary
*
Offline Offline

Activity: 1008


View Profile
February 16, 2016, 02:28:23 PM
 #175

If a student was babbling nonsense in front of the entire classroom and the Professor tried to amicably ask the student to please go study a bit more because he doesn't seem to understand some basic issues, and the student continued to ramble on filling up the entire 2 hour class session with his misunderstanding, would the Professor be uncivil to finally put his foot down and demand "please stop".

Frankly, you are no such professor and I am no such student. This is a discussion among peers in a forum.

I don't know why you can't comprehend what I have already written. The "transaction" which contains the input data for a script, can be set by any external entity. How do you propose to require that the bits & bytes of that input data declares its dependencies when it is impossible to force the external entity to declare where the data came from?

Why do we need to force the external entity to do its job correctly? If a mechanism exists with which this entity can do its job correctly, then by not using said mechanism the fault lies entirely with that entity. If there are subsequent systems built which utilise said entity, they will have to be updated to remove their reliance upon it because it is faulty. To hope for anything else is to hope for the impossible.
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
February 16, 2016, 02:39:45 PM
 #176

If a student was babbling nonsense in front of the entire classroom and the Professor tried to amicably ask the student to please go study a bit more because he doesn't seem to understand some basic issues, and the student continued to ramble on filling up the entire 2 hour class session with his misunderstanding, would the Professor be uncivil to finally put his foot down and demand "please stop".

Frankly, you are no such professor and I am no such student. This is a discussion among peers in a forum.

Sorry this is evidence that is not the case that we are not peers.

And the sooner you respect that, then the sooner I can respect you.

I don't know why you can't comprehend what I have already written. The "transaction" which contains the input data for a script, can be set by any external entity. How do you propose to require that the bits & bytes of that input data declares its dependencies when it is impossible to force the external entity to declare where the data came from?

Why do we need to force the external entity to do its job correctly? If a mechanism exists with which this entity can do its job correctly, then by not using said mechanism the fault lies entirely with that entity. If there are subsequent systems built which utilise said entity, they will have to be updated to remove their reliance upon it because it is faulty. To hope for anything else is to hope for the impossible.

monsterer you are babbling nonsense. Sorry I am not going to unravel for you the entangled myopia you are weaving. The more I try to explain, the more deeply you will nest your misunderstanding. This is simply ridiculous that you are incapable of understanding freshmen level Computer Science.

Did you study at the university?

monsterer
Legendary
*
Offline Offline

Activity: 1008


View Profile
February 16, 2016, 02:59:52 PM
 #177

monsterer you are babbling nonsense. Sorry I am not going to unravel for you the entangled myopia you are weaving. The more I try to explain, the more deeply you will nest your misunderstanding. This is simply ridiculous that you are incapable of understanding freshmen level Computer Science.

Did you study at the university?

It's a shame that you are unable to explain yourself given a straightforward question and are forced to resort to childish insults.
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
February 16, 2016, 03:14:31 PM
 #178

monsterer you are babbling nonsense. Sorry I am not going to unravel for you the entangled myopia you are weaving. The more I try to explain, the more deeply you will nest your misunderstanding. This is simply ridiculous that you are incapable of understanding freshmen level Computer Science.

Did you study at the university?

It's a shame that you are unable to explain yourself given a straightforward question and are forced to resort to childish insults.

I have already explained it. I was also cordial in hinting to you that you needed re-read my post and learn. Then you pushed it by saying my cordial hint was not civil. So I tried to explain it to you again. Now you've gone one step further by calling your Professor childish.

I think perhaps what you are proposing (yet you did not articulate it) is that you want every transaction to require that the input data is annotated to specify where that data appears on the block chain (i.e. which script output it is). But that means you are proposing to exclude "external I/O"; and I had already written upthread that yes if a design excludes external I/O then the problem is solved, but this means the programmability is mostly useless, e.g. no new accounts, etc..

Please monsterer think about what I have written. Please learn about type systems and what "dependently typed" means. Take some quiet time.

Peachy
Full Member
***
Offline Offline

Activity: 170



View Profile WWW
February 16, 2016, 03:29:14 PM
 #179

Being someone with first hand experience, and the technical knowledge to present challenges to TPTB's arguments when applicable, I can tell you its just too damn painful to do so.

No developer worth any salt is going to engage with him because it simply devolves into name calling if you don't align with his thoughts.  Before long the n00b, b-lister, you are not worthy comments start regardless of if he's right or not and its just a noisy waste of time.  I've seen the same towards people just trying to understand and not necessarily even disagreeing.

The discussion ends in a blaze of fire with one of the parties leaving, usually it's not TPTB that has departed (he can argue all damn day) so it "looks" from the outside that he won, even if in reality his "facts" are wrong.

Aaaand it begins.

TPTB:  Something to consider:
http://www.principiadiscordia.com/forum/index.php?topic=32044.0

Smartest Guy in the Room syndrome is related to Dunning/Kruger Effect, and affects men and women equally.

The Smartest Guy in the Room is smart enough to know that he's smarter than most people, but not smart enough to recognize when other people are smarter. He defaults to the belief that because he is smarter than the majority of the population, he must be smarter than the people he's talking to, and tends to look no further or deeper than whatever initial assumption he has made or conclusion he has come to.

The Smartest Guy in the Room is recognizable for his tendency to dismiss other people's views without critically examining why, for glancing at a discussion, assuming other people are being foolish, and correcting them based on that assumption without actually checking the source material himself to understand what they are discussing, and for either digging in his heels and screeching, or for "refusing to argue because it's pointless" whenever anyone else presents difficult-to-refute information that contradicts his conclusion.

He actually can't learn, because he thinks he already knows, and that the rest of us simply aren't smart enough to see his enlightenment. The Smartest Guy in the Room has usually been through at least one, sometimes two jailbreaks, but then something critical happened; he stopped. Convinced that he had broken out of his cell, he latched onto whatever form of enlightenment helped him get there, failing to realize that enlightenment is a verb, not a noun. Clinging to the implements of his enlightenment, he also failed to notice that he is once again squatting in a cell almost identical to the one he believed he had left behind.

There is nothing that can be done with a Smartest Guy in the Room, as any attempt to convince him that he is missing out on a huge aspect of bipedal development will simply lead to him thinking that you don't understand his unique and highly sophisticated perspective. In that sense, the Smartest Guy in the Room is stuck in a state of arrested development, at approximately age fourteen.

He is a lost cause and cannot be rehabilitated.

RADiX (formerly eMunie): The future of money
TPTB_need_war
Sr. Member
****
Offline Offline

Activity: 420


View Profile
February 16, 2016, 03:41:29 PM
 #180

Good luck with that.  One of the things that made Bitcoin great is consensus via economics that's advantageous for the individual and the group.

Yeah it is absolutely great that China's mining bloc controls 65% of Bitcoin's hashrate and has vetoed any block size increase, including Classic's proposed mere doubling of the block size to 2MB only. Ostensibly they want to force transaction fees higher to fatten their profits. This is called an oligarchy and it is great for individuals like us, so we can pay through the nose to the oligarchy.

Thanks again for your incredible wisdom and including your sage proclamation that Szabo is a crypto god and was/is Satoshi.

Peachy has joined you in my very exclusive Ignore list, which I reserve for the wisest soothsayer salesmen.

Pages: « 1 2 3 4 5 6 7 8 [9] 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!