Bitcoin Forum
September 02, 2015, 11:48:55 PM *
News: New! Latest stable version of Bitcoin Core: 0.11.0 [Torrent]
 
  Home Help Search Donate Login Register  
  Show Posts
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 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 ... 967 »
681  Economy / Speculation / Re: Gold collapsing. Bitcoin UP. on: July 07, 2015, 03:24:19 AM
as you know, even Gavin talks about this memory problem from UTXO.  and yes, i read the Reddit thread that resulted in which you participated and i'm aware that UTXO can be dynamically cached according to needs.
http://gavinandresen.ninja/utxo-uhoh

Gavin was insufficently precise. There is a reddit thread is full of people calling gavin a fool ( Sad ) for saying "memory" when he should have been saying fast storage.  https://twitter.com/petertoddbtc/status/596710423094788097

Why do you think it's prudent to argue this with me?

i'm not really arguing about this with you.  you said UTXO is not in memory.  i'm saying it depends on how fast a node wants to verify tx's via the dynamic caching setting they choose which does get stored in memory.

Quote

Quote
i didn't say this full block spam attack we're undergoing wasn't affecting my node at_all.  sure, i'm in swap, b/c of the huge #unconf tx's but it hasn't shut down or stressed my nodes to any degree.  one of the arguments by Cripplecoiners was that these large block attacks would shut full nodes down from destabilization resulting in centralization.  i'm not seeing that.
The highest number of unconfirmed transactions I've seen ever is about 8MB. Even if we assume the real max was 3x that this is not explaining your hundreds of megabytes of swap.   We just had half the hashpower of the network mining without validating creating multiple large forks and large reorginizations, but you don't see any destabilization. Okay.

ok, i'm not getting the bolded part.  this graph shows 37 MB worth of unconf tx's, no?:



Quote
Let me chime in hear quickly, because I think Greg and I are talking about slightly different things.  My model was considering the time between the first moment that a pool could begin hashing on a blockheader, and when the previous block had been processed, a new non-empty block template constructed, and the hashers re-assigned to work on this non-empty block.  

It looks like this time, empirically, is 15 sec (F2Pool) and 30 sec (AntPool), based on these estimates.  

Here I suspect you're suffering from an excess of empiracisism without adequately devling into the mechenism.   You can directly measure that time time from input to minable on an actual node under your control and will observe the time is hundreds of times faster than your estimate. Why?   Miners don't magically know when their pool has new work, they'll get work in the first milliseconds and then grind on it some time before submitting returning work.  Even if the pool long polls them, it takes time to replace work. So what I suspect you're actually measuring there is the latency of the mining process...  which is consistent with what we've expirenced with P2Pool (5-20 second latencies from ASIC miners are common).

I noted you posted a result of a classification, did you run the same data through a simple logistic regression with prior size as the treatment? The intercept in the model would be interesting.

But indeed, these conversations have been conflating several seperate issues (latency vs throughput, etc.). Tricky to avoid that since they're all relevant.

but you haven't verified that f2pool or Antpool has increased their minrelaytxfee have you to minimize their mempool?
I have, they'd previously cranked it down, and were producing small blocks and were flamed in public.  They've since turned it back up.

Quote
remember, this whole mempool discussion was based off you responding to Peter's mathematics post the other day where you argued that the block verification times were only 80ms for a 250 kB block b/c tx's had been pre-verified after being passed around to all nodes across the network and didn't require re-verification by miners on the relay network and was therefore a refutation of his hypothesis of increasing block verification times (16-37sec on avg) leading to SPV mining.
As PeterR points out, they only need to wait for verification to actually verify (which they're not doing today), though they may have to wait longer to include transactions---- though I point out thats not fundimental e.g. no matter how big the backlog is you can produce a template sufficient to completely fill a block while doing no more work than handling a mempool of twice the maximum block size.  (by using a tiered mempool, though no one has bothered to implement this yet-- no one has even been complaining about how long createnewblock takes, due to the ability to produce empty blocks without skipping transactions).

682  Economy / Speculation / Re: Gold collapsing. Bitcoin UP. on: July 07, 2015, 03:13:17 AM
look at what we're facing with this latest spam attack.  note the little blip back on May 29 which was Stress Test 1.  Stress Test 2 is the blip in the middle with the huge spikes of the last couple of days on the far right.  this looks to me to be the work of a non-economic spammer looking to disrupt new and existing users via stuck tx's which coincides with the Grexit and trouble in general in the traditional fiat markets.  they want to discourage adoption of Bitcoin.  the fastest way to eliminate this attack on users is to lift the block size limit to alleviate the congestion and increase the expense of the spam:

683  Economy / Speculation / Re: Gold collapsing. Bitcoin UP. on: July 07, 2015, 02:56:24 AM
GAH! I'm not saying it's a good setting-- I'm just giving a concrete example that nodes (and miners) can control their mempool sizes, as this was at odds with cypherdoc's expectations-- instead he thought miners might be suffering because of large mempools-- and I pointed out that if their mempool was too big they could simply reduce it and he said he didn't believe me. I don't know how I could have made it more clear, but I hope its clear now. Smiley



yes, thanks for reminding me of that minrelaytxfee as an adjustable variable to screen the mempool.  i had read about that the other day on Reddit but forgot.  i'm not a tech guy afterall. Wink

but you haven't verified that f2pool or Antpool has increased their minrelaytxfee have you to minimize their mempool?  remember, this whole mempool discussion was based off you responding to Peter's mathematics post the other day where you argued that the block verification times were only 80ms for a 250 kB block b/c tx's had been pre-verified after being passed around to all nodes across the network and didn't require re-verification by miners on the relay network and was therefore a refutation of his hypothesis of increasing block verification times (16-37sec on avg) leading to SPV mining.
684  Economy / Speculation / Re: Gold collapsing. Bitcoin UP. on: July 07, 2015, 02:41:59 AM
why does the 0 tx block have to come "immediately" after a large block?

They don't.  Empty blocks can come after any sized block.  But I just showed that F2Pool is more likely to produce an empty block when the previous block was large, than when the previous block was not large.  

This makes sense to me because I expect that for large blocks, there's more time between when F2Pool has just enough information to begin hashing, and when they have processed the block and sent a new non-empty blocktemplate to their hashers to work one.  If this time is longer, then there's a better chance they get lucky and mine an empty block.  See what I mean?


i think so which is also why these 0 tx blocks usually come within a minute of a large block?
685  Economy / Speculation / Re: Gold collapsing. Bitcoin UP. on: July 07, 2015, 02:23:35 AM
why does the 0 tx block have to come "immediately" after a large block?

They don't.  Empty blocks can come after any sized block.  But I just showed that F2Pool is more likely to produce an empty block / "defensive block" when the previous block was large than they are when the previous block was small or medium. 



it might be interesting to see if Antminer becomes statistically significant after 2 blocks instead of 1.
686  Economy / Speculation / Re: Gold collapsing. Bitcoin UP. on: July 07, 2015, 02:18:13 AM
1.  Is F2Pool/AntPool more likely to produce an empty block when the previous block is large?

2.  Is F2Pool/AntPool more likely to produce an empty block when mempool swells?

I think the answer to Q1 will be "yes." But I don't see why the answer to Q2 would be yes for any reason other than the previous block is more likely to be large when mempool swells (i.e., mempool is not the cause, just correlated).

OK, based on the data from JohhnyBravo, it looks like the answer to Q1 is "YES" for F2Pool but "NO" for AntPool.  Here's a rough summary based on the last 100 days of blocks:



If anyone's interested in how I did this, I'll give you a brief walk through.  I first put the data into three bins:
(1) blocks produced by the Miner after a small block (0 kB - 333 kB),
(2) blocks produced by the Miner after a medium block (334 kb - 666 kB), and
(3) blocks produced by the Miner after a large block (667 kB - 1000 kB).  
I also removed any data points where the Miner found a block while mining upon his own previous block.  

For a "null hypothesis," I assumed that getting an empty block was the outcome of a repeated Bernoulli trial. I used a Bernouli trial with P_empty = 3.5% for F2Pool and P_empty = 6.3% for AntPool.  

I then asked, if the null hypothesis is true, then what are the chances of getting, e.g., in the case of F2Pool, 34 (or more) empty blocks out of 619 "large-block" trials?  We'd only expect 619 x 0.035 = 22 empty blocks!

The sum of a repeated Bernoulli trial has a Poisson distribution, so I integrated the corresponding Poisson distribution between 34 and 619 to determine the chances of getting this many (or more) empty blocks by dumb luck.  As we can see, there's only a 0.4% chance of this happening.  This suggests we reject the null hypothesis in favour of the idea that "Yes, F2Pool is actually more likely to produce an empty block when the previous block was large."

This also means that the effect I modelled on the weekend is real, at least for miners behaving like F2Pool.  I'm curious though, why AntPool's data is so different.

why does the 0 tx block have to come "immediately" after a large block?
687  Economy / Speculation / Re: Gold collapsing. Bitcoin UP. on: July 07, 2015, 02:02:12 AM
just look at this.  pitiful.  just shameful that core dev allows attacking spammers, emboldened by Stress Tests 1&2, to disrupt new and existing users who can be found complaining all over Reddit with stuck tx's.  this is exactly the dynamic that Mike Hearn was talking about.  look at that level of unconf tx's, 51000, never seen before and the highly disruptive 2.90 TPS:

https://www.reddit.com/r/Bitcoin/comments/3cbpwe/new_transaction_record_just_reached_147_txs/csu5leg


688  Economy / Speculation / Re: Gold collapsing. Bitcoin UP. on: July 07, 2015, 01:43:31 AM
no, memory is not just used for 1MB blocks.  it's also used to store the mempools plus the UTXO set.  large block attacks
Again, you're wrong on the technology. The UTXO set is not held in ram. (There is caching, but its arbritary in size, controlled by the dbcache argument).

as you know, even Gavin talks about this memory problem from UTXO.  and yes, i read the Reddit thread that resulted in which you participated and i'm aware that UTXO can be dynamically cached according to needs.
http://gavinandresen.ninja/utxo-uhoh
Quote

Quote
have the potential to collapse a full node by overloading the memory.  at least, that's what they've been arguing.
"They" in that case is sketchy nutballs advocating these "stress tests", and _you_ arguing that unconfirmed transactions are the real danger.

Super weird that you're arguing that the Bitcoin network is overloaded with average of space usage in blocks, while you're calling your system "under utilized" when you're using a similar proportion of your disk and enough of your ram to push you deeply into swap.

i didn't say this full block spam attack we're undergoing wasn't affecting my node at_all.  sure, i'm in swap, b/c of the huge #unconf tx's but it hasn't shut down or stressed my nodes to any degree.  one of the arguments by Cripplecoiners was that these large block attacks would shut full nodes down from destabilization resulting in centralization.  i'm not seeing that.
689  Economy / Speculation / Re: Gold collapsing. Bitcoin UP. on: July 06, 2015, 10:29:47 PM
cypherdoc, who is paying you now ? (KNC ?)

LOL, no one.
690  Economy / Speculation / Re: Gold collapsing. Bitcoin UP. on: July 06, 2015, 10:10:48 PM
no, memory is not just used for 1MB blocks.  it's also used to store the mempools plus the UTXO set.  large block attacks
Again, you're wrong on the technology. The UTXO set is not held in ram. (There is caching, but its arbritary in size, controlled by the dbcache argument).

Quote
have the potential to collapse a full node by overloading the memory.  at least, that's what they've been arguing.
"They" in that case is sketchy nutballs advocating these "stress tests", and _you_ arguing that unconfirmed transactions are the real danger.

Super weird that you're arguing that the Bitcoin network is overloaded with average of space usage in blocks, while you're calling your system "under utilized" when you're using a similar proportion of your disk and enough of your ram to push you deeply into swap.

Quote
There is no requirement that mempools be in sync, -- in fact, they're not and the whole purpose of the blockchain is to synchronize nodes.  The mempools of nodes with identical fee and filtering policies and whom are similarly positioned on the network will be similar, but any change in their policies will make them quite different.
well, that was precisely Peter's mathematical point the other day that you summarily dismissed.  f2pool and Antminer are NOT in a similar position on the network as they are behind the GFC.  they have in fact changed their verification policies in response to what they deem are large, full blocks as a defensive measure.  that's why their average validation times are 16-37sec long and NOT the 80ms you claim.  thus, their k validation times of large blocks will go up and so will their number of 0 tx SPV defensive blocks. and that's why they've stated that they will continue to mine SPV blocks.  thanks for making his point.
PeterR wasn't saying anything about mempools, and-- in fact-- he responded expressing doubt about your claim that mempool size had anything to do with this.  Moreover, I gave instructions that allow _anyone_ to measure verification times for themselves.  Your argument was that miners would be burned by unconfirmed transactions, I responded that this isn't true-- in part because they can keep whatever mempool size they want.

To further make the point about mempools, here is what the mempool looks like on a node with mintxfee=0.0005 / minrelaytxfee=0.0005 set:


$ ~/bitcoin/src/bitcoin-cli  getmempoolinfo
{
    "size" : 301,
    "bytes" : 271464
}


Quote
it also is a clear sign that miners do have the ability and financial self interest to restrict block sizes and prevent bloat in the absence of a block limit.
Their response was not to use smaller blocks, their response was to stop validating entirely.  (And, as I pointed out-- other miners are apparently mining without validating and still including transactions).

Quote
these SPV related forks have only occurred, for the first time ever, now during this time period where spammers are filling up blocks and jacking up the mempool.  full blocks have been recognizable as 950+ and 720+kB.  this is undeniable.
If we're going to accept that every correlation means causation;  what should we say about the correlation between finding out that you've taken hundreds of thousands of dollars in payments for paid shilling and finding out loud and opinionated you are on this blocksize subject?

In this case, these forks are only visible by someone mining an invalid block, which no one had previously done for over a year.

Quote
if they are seeing inc orphans, why haven't they retracted their support of Gavin's proposal
They are no longer seeing any orphans at all, they "solved" them by skipping validation entirely. They opposed that initial proposal, in fact, and suggested they could at most handle 8MB, which brought about a new proposal which used 8MB instead of 20MB though only for a limited time. Even there the 8MB was predicated on their ability to do verification free mining, which they may be rethinking now.

Quote
i don't believe that.
I am glad to explain things to people who don't understand, but you've been so dogmatically grinding your view that it's clear that every piece of data you see will only "confirm" things for you; in light of that I don't really have unbounded time to waste trying. Perhaps someone else will.


On my phone now so this is going to be hard to respond.

First, nice try pretending UTXO is not potentially a memory problem. We've had long debates about this on this thread so you are just being contrary.

Second, my reference to Peters argument above aid nothing about mempool; I was talking  about block verification times. You're obfuscation again.

Third, unlike SPV mining if 0 tx blocks like now, didn't mean they would do the same without a limit. Perhaps they would pare down block sizes to an efficient level of other larger miners were allowed to clear out the unconfirmed TX set.

Fourth, you have no shame do you with the ad hominems? No, I'm not endorsing for any company like I told everyone ahead of time I was doing for HF.
691  Economy / Speculation / Re: Gold collapsing. Bitcoin UP. on: July 06, 2015, 08:37:02 PM
meanwhile, my full nodes sit here totally unstressed and under-utilized.  Roll Eyes



i thought gmax et al said "large" blocks were going to collapse my nodes?

I've been reading this thread since a long time, and mostly enjoyed the economic insights it used to be about.  However, I can only agree with those who see cypherdoc's reputation fading with his supposedly technical comments like the one above.  It has been pointed out repeatedly and should be clear as day - currently we have the 1 MB limit you are complaining about.  That's precisely why your nodes are "unstressed and under-utilized".  From the current stress on your nodes, you can at best guess very vaguely at what they would be doing with larger blocks.  I don't see why that's an argument you make in favour of increasing the blocksize.  (Same as your comments about "full" blocks that were debunked by others above.)

no, memory is not just used for 1MB blocks.  it's also used to store the mempools plus the UTXO set.  large block attacks have the potential to collapse a full node by overloading the memory.  at least, that's what they've been arguing.
692  Economy / Speculation / Re: Gold collapsing. Bitcoin UP. on: July 06, 2015, 08:33:00 PM
since small pools can also connect to the relay network, and i assume they do, there is no reason to believe that large miners can attack small miners with large blocks.  in fact, we've seen the top 5 chinese miners deprecated due to the GFC making it clear they CANNOT perform this attack despite what several guys have FUD'd.
Basic misunderstanding there--- Being a larger miner has two effects: One is throughput not latency related: Being larger creates a greater revenue stream which can be used to pay for better resources.   E.g. if the income levels support one i7 CPU per 10TH/s of mining, then a 10x larger pool can afford 10x more cpus to keep up with the overall throughput of the network, which they share perfectly (relay network is about latency not so much about throughput-- its at best a 2x throughput improvement, assuming you were bandwidth limited);    the other is latency related,   imagine you have a small amount of hashpower-- say 0.01% of the network-- and are a lightsecond away on the moon.  Any time there is a block race, you will lose because all of the earth is mining against you because they all heard your block 1+ seconds later.  Now imagine you have 60% of the hashpower on the moon, in that case you will usually win because even though the earth will be mining another chain, you have more hashpower. For latency, the size of miner matters a lot, and the size of the block only matters  to the extent that it adds delay.

i don't believe that.  when i ran my small solo mining pool, i'll bet that the quality of my resources and bandwidth were superior to that of the large mining pools i've seen in the videos.  furthermore, if my small pool is connected to the same relay network as a large miner, then the transmission of our respective blocks on the moon should reach earth at the same time, thus, our respective chances to find the next block simply goes back to our respective % hashrates compared to the network.
Quote
When it comes to orphaning races miner sizes matters, in some amount that is related to the product of the size-of-the-miner and time it takes to validate a block.

Quote
how can that be?  mining pools all use a full node around which they coordinate their mining.  all full nodes are relatively in sync with their mempools  
There is no requirement that mempools be in sync, -- in fact, they're not and the whole purpose of the blockchain is to synchronize nodes.  The mempools of nodes with identical fee and filtering policies and whom are similarly positioned on the network will be similar, but any change in their policies will make them quite different.

well, that was precisely Peter's mathematical point the other day that you summarily dismissed.  f2pool and Antminer are NOT in a similar position on the network as they are behind the GFC.  they have in fact changed their verification policies in response to what they deem are large, full blocks as a defensive measure.  that's why their average validation times are 16-37sec long and NOT the 80ms you claim.  thus, their k validation times of large blocks will go up and so will their number of 0 tx SPV defensive blocks. and that's why they've stated that they will continue to mine SPV blocks.  thanks for making his point.

it also is a clear sign that miners do have the ability and financial self interest to restrict block sizes and prevent bloat in the absence of a block limit.

Quote

IBLT doesn't currently exist, and other mechenisms like the relay network protocol don't care about mempool synchronization levels.

Quote
pt being, it's statistically unlikely that full blocks today represent the magical level of "large" blocks that Satoshi set 6 yrs ago.  the problems we are having with the forks are a result of the defensive tactics being taken from those full blocks.

Almost none of the blocks have been 1MB, the issues arise before then. _Consistent_ 1MB blocks wouldn't have been supportable on the network at the time that limit was put in place-- back in the 0.5.x-ish days we were getting up to 2minutes for a 100k block to reach the whole network; the 1MB was either forward-looking, set too high, or only concenred about the peak (and assuming the average would be much lower) ... or a mixture of these cases.

these SPV related forks have only occurred, for the first time ever, now during this time period where spammers are filling up blocks and jacking up the mempool.  full blocks have been recognizable as 950+ and 720+kB.  this is undeniable.
Quote

Quote
have the Chinese miners given you a technical reason why they're SPV'ing?

F2Pool reported that as block sizes grew they saw increased orphaning rates and that they were seeing an orphan rate of 4% though this was at a time before the relay network and when GHash in europe had ~50% of the hashpower under them.  Excluding the recent issues they've had almost no orphans since, they report.

if they are seeing inc orphans, why haven't they retracted their support of Gavin's proposal for an immediate inc to 8MB?
Quote

Then why don't we decrease the blocktime from 10 min down to let's say 2 min. This way we can also have more transactions/second without touching the blocksize.
Ouch,  the latency related issues issues are made much worse by smaller interblock gaps once they are 'too small' relative to the network radius. When a another block shows up on the network faster than you can communicate about your last you get orphaned.  And for throughput related bottlenecks it doesn't matter if X transactions come in the form of a 10mb block or 10 1mb blocks.




693  Economy / Speculation / Re: Gold collapsing. Bitcoin UP. on: July 06, 2015, 06:51:43 PM
the spammers smell blood.  and the core devs do nothing:

694  Economy / Speculation / Re: Gold collapsing. Bitcoin UP. on: July 06, 2015, 06:41:09 PM
meanwhile, my full nodes sit here totally unstressed and under-utilized.  Roll Eyes



i thought gmax et al said "large" blocks were going to collapse my nodes?
695  Economy / Speculation / Re: Gold collapsing. Bitcoin UP. on: July 06, 2015, 06:34:06 PM
meanwhile, my full nodes sit here totally unstressed and under-utilized.  Roll Eyes

696  Economy / Speculation / Re: Gold collapsing. Bitcoin UP. on: July 06, 2015, 06:10:32 PM
oh my, ugly as hell:

697  Economy / Speculation / Re: Gold collapsing. Bitcoin UP. on: July 06, 2015, 06:07:57 PM

I favor Adam Backamoto's

stop equating Adam to Satoshi.  no contest.

you have a serious Daddy problem.
698  Economy / Speculation / Re: Gold collapsing. Bitcoin UP. on: July 06, 2015, 06:06:41 PM
and you thought Bitcoin was volatile?  pfft.  peanuts to the stock mkt; huge opening gap down from last nights futures dump, all the way back up to retest the flat, followed by another huge dump down.  it will only get worse:

699  Economy / Speculation / Re: Gold collapsing. Bitcoin UP. on: July 06, 2015, 06:03:33 PM
wow, Varoufakis out.  one less Bitcoin Bear; altho we still have lots of them roaming around here:

http://www.nytimes.com/2015/07/07/business/international/yanis-varoufakis-abruptly-resigns-as-greek-finance-minister.html?hp&action=click&pgtype=Homepage&module=a-lede-package-region&region=top-news&WT.nav=top-news&_r=0
700  Economy / Speculation / Re: Gold collapsing. Bitcoin UP. on: July 06, 2015, 05:52:35 PM
1.  Why do larger mining pools have less orphans, assuming most miners even small ones are connected to the relay network?
Because it greatly reduces the time it takes to transmit blocks but does not completely eliminate it-- nothing can (due to the speed of light).  In particular, something I didn't know until my conversation with them on July 4th:  the nearest relay network hub to F2Pool is still 200ms away due to insane routing that sends traffic between some networks in china and singapore via the US (thanks NSA?).

since small pools can also connect to the relay network, and i assume they do, there is no reason to believe that large miners can attack small miners with large blocks.  in fact, we've seen the top 5 chinese miners deprecated due to the GFC making it clear they CANNOT perform this attack despite what several guys have FUD'd.

Quote
2. Even if mining pools set higher fees, aren't the unconfirmed TX's still added to their mempools?
No.

Quote

how can that be?  mining pools all use a full node around which they coordinate their mining.  all full nodes are relatively in sync with their mempools which is the whole concept on which IBLT depends on. 
Quote
Quote
3. How is it that 1MB just "happened" to be the magic number at which blocks are deemed to be "large" ?
I don't know what you're talking about there.  AFAICT F2Pool would also consider e.g. 750k "large".

750 kB blocks are clearly being mined by miners who haven't changed the default.  in fact, i think the top 2 Chinese miners only recently changed their default to 1MB.

pt being, it's statistically unlikely that full blocks today represent the magical level of "large" blocks that Satoshi set 6 yrs ago.  the problems we are having with the forks are a result of the defensive tactics being taken from those full blocks.

have the Chinese miners given you a technical reason why they're SPV'ing?
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 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 ... 967 »
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!