No

[subSTRATA]

mm

[1715194702]

1715194702

[1715194702]

1715194702

[1715194702]

1715194702

[1715194702]

1715194702

[Stephen Gornick]

All fine? Working as intended? "Let's just ignore all unconfirmed transactions and get ourself 50 BTCs!"  

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.  

[Pieter Wuille]

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

[Syke]

All fine? Working as intended?

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

[kjj]

I'm pointing to ridicule situation - there are thousands of unconfirmed transaction but block will be accepted, which means
blockchain size will be increased by 1, even though mentioned block has no transactions other than 50BTCs payout. Since
that is possible, it's possible for determined attacker to "freeze" all non-BTC-generating transactions (almost) indefinitely.

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.

[wabber]

I'm pointing to ridicule situation - there are thousands of unconfirmed transaction but block will be accepted, which means
blockchain size will be increased by 1, even though mentioned block has no transactions other than 50BTCs payout. Since
that is possible, it's possible for determined attacker to "freeze" all non-BTC-generating transactions (almost) indefinitely.

Not really.  There are actually several ways to counter this if we ever need to... we can make it costly to be antisocial if we really need to.

How much worse the situation must become for that to happen? If there are already ways to fight it, why wait with implementation?

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.

[kjj]

I'm pointing to ridicule situation - there are thousands of unconfirmed transaction but block will be accepted, which means
blockchain size will be increased by 1, even though mentioned block has no transactions other than 50BTCs payout. Since
that is possible, it's possible for determined attacker to "freeze" all non-BTC-generating transactions (almost) indefinitely.

Not really.  There are actually several ways to counter this if we ever need to... we can make it costly to be antisocial if we really need to.

How much worse the situation must become for that to happen? If there are already ways to fight it, why wait with implementation?

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.

[wabber]

So, all it takes for an attacker to "paralyse" Bitcoin is to takeover major miners and set them to ignore transactions?

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.

[DeathAndTaxes]

So, all it takes for an attacker to "paralyse" Bitcoin is to takeover major miners and set them to ignore transactions?

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.

[DeathAndTaxes]

51%+ is just 4 pools. 75%+ is just 8 pools. That means 4 - 8 persons to compromise to make Bitcoin network "lag" badly.
If attacker goes for those 8 persons, it would surely increase transaction conformation time by much more than 20 minutes.

You should stop looking at profit motive all the time. Unless you do so, you'll fail to identify the real threats to Bitcoin. It
does not have to be Banksters or governments = it can be small group of people who would do it for fun, or to piss-off others.
There are probably countless possible situations where profit lost or gained is of secondary, tertiary or even no importance.

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.

[caveden]

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?

[kjj]

It's not just Deepbit. Bitminter is doing the same quite often.

Anyway, what's with timestamps? Time can be set on will, like 01-01-1337, or there are some limits? Does it actualy matters?

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:

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

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.

[kjj]

So, it could be a node blockchain.info is unaware of, or just latency delaying report from known node for long enough that report
over some other node(s) reaches blockchain.info earlier.

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.

Truth is that Deepbit was doing it. They even broadcast proof of their "sins", just check on their statistics page:

01.11 23:03:30
01.11 20:35:18

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.

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.

But does timestamp matters or it's just cosmetics?

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.

[Stephen Gornick]

But does timestamp matters or it's just cosmetics?

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.