Topic: No (Read 1268 times)

It matters in exactly the way that I described.  A block with a timestamp too far into the future isn't valid, and a block with a timestamp older than the median of the last 11 blocks isn't valid.
[/quote]

And timestamp is used in computing difficulty so there it does need to be a sane value, just not down to the correct second off an atomic clock.

The only information that a node gets about the origin of a block is which of that node's peers sent it first, not where that peer got it, not where it was made.


Meh.  It isn't like deepbit hasn't hashed millions of other transactions over the years.  And because of the timestamp flex, you don't really have any idea how much time deepbit's system had to accumulate new transactions between the previous blocks, and the getworks that resulted in these blocks.


It matters in exactly the way that I described.  A block with a timestamp too far into the future isn't valid, and a block with a timestamp older than the median of the last 11 blocks isn't valid.

Blockchain.info isn't making any effort to figure out who made the block.  They are reporting who relayed it to them.  Sometimes those are the same, but other times, they are not.  Pieter mentioned that very early in this thread:


On timestamps, the network restricts them to be not more than 2 hours into the future, and not earlier than the median time of the last 11 blocks.  The 2 hours/future thing actually operates on the adjusted time, not the system time.  I'm not a big fan of that, but not everyone shares my OCD regarding NTP.

Deepbit is intentionally making empty blocks? What's the reason? To decrease its blocks' propagation time?
If that's the reason, wouldn't pool operators gain if they make sure to be all interconnected? This way they could make sure other pools are the first to receive a new block they generate, decreasing the chances of losing a block. P2Poll miners could also attempt to connect to all pools too.

I'm probably missing something, since if that was enough deepbit would probably go this way instead of ignoring transactions.. can somebody explain me what I'm missing then?

Meh.  At one point it looked like 51% would be 1 pool, then it became 2 pools, then 3, now it is 4.  You are talking about a massive collusion among people who have the most to lose if Bitcoin collapses.  Also Deepbit doesn't own the hashing power.  If they start double spending the network they can only do that once.  Miners will leave and then DeepBit (and co-conspirators) won't have the 51% to attack the network.

On edit:
http://blockchain.info/pools?timespan=4days

It is 5 pools to get 51% of the blocks in last 4 days and combined that is only 52%.  So if they collectively lost another 3% of hashing power to smaller pools or solo-miners you are now talking a conspiracy of the 6 largest pools.

Still that wasn't your point to begin with.  You point was an attacker could paralyze the network and reality is without 51%+ the best they can do is slow down confirmations (first confirm only) by a marginal amount.  With 51%+ an attacker can do more serious attacks anyways.

If you have 51% of the hashing power you can double spend the network to death anyways.  For economic miners as the block subsidy declines and transaction volume increases the incentive to include more transactions increases.  The trend has already begun. 

http://blockchain.info/charts/transaction-fees-usd

Daily tx fees have increased from ~$10 per day to $250 per day over the last year.  If that sounds like a lot the subsidy is ~$80,000 per day.  So fees pay about 0.3% of the network cost.  If we assume that over the next year the subsidy will be cut in half, the tx volume will quadruple, and avg fee per tx doubles that 0.3% will be more like ~5%.  No serious miner can ignore 5% of potential revenue.


Right now the high subsidy, and low tx fee volume creates a distortion in the market.  Larger blocks take longer to propagate and that creates a significant risk.  Say there are 1,000 tx waiting.  By including the 100 highest paying you could improve your revenue by ~0.2% however if doing so increases your orphan rate by 1% you lose revenue.  The "bottom 900" tx are even worse.  They may increase the orphan rate 2%+ but only contribute 0.3% more revenue.  The subsidy decline will make better align the needs of the network with the economic needs of miners.  The distortion of the high block subsidy will be solved with time.

TL/DR:
It is a minor "issue".  Higher tx volume, higher fees, and declining subsidies will make excluding paying tx uneconomical in time.

You would need 50% of all miners and thats alot to increase the average confirmation time from 10minutes to 20minutes. That doesn't really sound like a threat does it?
There's no financial interest in doing so and humans usually follow their financial interest. Even if you could get 50% to not include transactions, fees would increase and therefore more ppl would start including transactions again instead of losing money.

Because we don't want to make rules like that.  The reference client makes up the bulk of the network, so any rules in there carry a lot of weight.  Until the network is more diversified, the devs are cautious about such things.

Miners should be allowed to include or exclude transactions according to whatever rules they want.  And nodes should be allowed to dislike certain blocks, to some extent.  By putting rules in the reference client, the devs would be forcing their rules on everyone, and they don't want to, and simply won't do it unless things get pretty ugly.

Blocks with no transactions are still doing part of their job, just not all of it.  And they are still valid.

The idea that I proposed, in case you are interested, is to keep a timestamp on transactions in the memory pool, and to check them when a new block comes in.  If the new block doesn't include some fraction (10%?  25%? ) of the transactions that you knew about at some time prior to the block coming in (1 minute before?  5?  10? ), just quarantine the block until another block comes in, assuming that there was a sufficient number of known transactions (50?  100? ).  The new block will either be a better replacement for the antisocial block, or a block that builds on top of it.

This way, miners would have an incentive to include transactions, because more transactions means that a larger fraction of the network will relay your blocks, spreading it quicker, reducing your chances of getting orphaned.

Note that this proposal is actually fairly complicated, and no one would want to have to actually write it, nor maintain it.  It has the advantage of not centralizing control, but that's about all it has going for it.  Other solutions are possible, with varying combinations of complexity and ease of implementation, and the devs don't want to do any of them unless they actually have to.

Because it's already implemented. It's the fee. It was discussed how to block antisocial blocks in the past and the result was pretty much that it isn't possible. If miners don't want the fees they are free to not include transactions. If Deepbit doesn't include transaction they are actually telling everyone that they think the fees are too low and there's nothing wrong about that.

Not really.  There are actually several ways to counter this if we ever need to.

Not too long ago, there were a lot more of these no-transaction blocks and there was speculation that it might be a botnet doing them.  If it is a botnet, the rise of ASICs over the next few months will pretty well kill them off.  If it isn't a botnet, we can make it costly to be antisocial if we really need to.

Yup, working as intended. No one is forced to include any transactions they don't want. Time stamps are slightly flexible, by design.

Who do you assume deepbit is responsible for this? Blockchain.info shows who relayed a block first, not who mined it.

Trust the market.  

Deepbit doesn't do the work.  Miners who do are free to move to another pool.  

The fees that Deepbit passed up were earned by the next pool.

The market works these things out.

Also, later this month the block reward will drop to 25 BTC per block.  Thus those fees become a larger percent of the miner's proceeds.

Right now Blockchain.info shows about a thousand unconfirmed transactions.   By not including those transactions, Deepbit is doing a disservice to Bitcoin no doubt.  Those miners who hold bitcoins might consider this and send their hashing elsewhere.  

mm