Wonder who this solominer is? 88.6.216.9

[MintCondition]

The idea has floated several times to reject blocks that don't contain at least some portion of the transactions that you node is aware of.  Might be time to reconsider it

Of course, it wouldn't be anything as simple as "reject empty blocks" or "reject blocks with less than X transactions".  Those won't work.

It will need to be more like "I see 100 pending transactions that are valid and should be included in the next block.  This block I just got from the network contains less than 25% of them, so I will reject it."  There will probably need to be a threshold too, like "I only see 10 pending transactions, and that isn't enough to enforce a minimum number on this incoming block, so I will accept it, even though it has none".

As a first guess, I would say that a threshold of 10 or 20 and a fraction of 1/4 to 1/2 would work well. 

This kind of rule enables a new kind of transaction spamming attack.

When a block is found, the set of transactions it covers could have been determined up to 120 seconds earlier, because that's the work-expiry period most pools employ. So if an attacker would want to prevent currently outstanding work from being able to find a valid block, he could just inject 3x the current amount of transactions into the network. Nodes will then reject any block found by the 'old' work.

Newly distributed work, on the other hand, will include the spam-transactions. That makes it eligible for a block again, so the attacker needs to repeated his strategy for lasting effectiveness. This causes an exponential growth in spammy transactions. Depending on the goals of the attacker and the transaction costs of the spam-transactions this may or may not be worthwhile.

[DeathAndTaxes]

@DeathAndTaxes, this:

The idea has floated several times to reject blocks that don't contain at least some portion of the transactions that you node is aware of.  Might be time to reconsider it

Of course, it wouldn't be anything as simple as "reject empty blocks" or "reject blocks with less than X transactions".  Those won't work.

It will need to be more like "I see 100 pending transactions that are valid and should be included in the next block.  This block I just got from the network contains less than 25% of them, so I will reject it."  There will probably need to be a threshold too, like "I only see 10 pending transactions, and that isn't enough to enforce a minimum number on this incoming block, so I will accept it, even though it has none".

As a first guess, I would say that a threshold of 10 or 20 and a fraction of 1/4 to 1/2 would work well.  

And the rules are made by the majority of the hashing power. So considering we all want what is best for Bitcoin I am hoping that the 3 biggest pools will apply this rule and kill this ignore nonsense. Otherwise it could potentially take a very long time for transactions to be confirmed. Like I said before: I regard this as simply malevolent  behavior and if I had access to >50% of the hashing power would ban it.

I'm hoping some group of people that actually has >50% hashing power agrees.

Horribly stupid idea and would lead to a small cartel locking up 100% of the blocks or worse fragmenting the Bitcoin network is forked chains which can never be reorged depending on how it is implemented.

Method a) Chain selection by miners: (seems to be method advocated by wachtwoord as he indicates hashing power)

If miner's decided which chain to build on based on these rules it would require 51% support.  If they have 51% control of the network they could simply exclude work of all other miners and use "protecting the network" as an excuse.

Bitcoin is decentralized.  No node knows for sure it has seen all the transactions and likely hasn't at any snapshot in time.  Deepbit, slush, and enough other miners to make up 51% of hashing power decide only they get to mine.  They share hundreds of low value transactions with each other only.  Ever other miner is invalid.  All their blocks are rejected.  If you want to mine you need to join the cartel.  In time the pools could consolidate into a single pool with shares of the profit and raise fees on miners.  Anyone trying to mine outside the cartel would simply have their work rejected.

You just handed complete centralization of Bitcoin to the largest pools.  Awesome.  

Method b) Nodes invidually determine which nodes are invalid (seems to be the method advocated by kjj )

The problem is that at any moment in time your node my not see every transaction.  This is important:  CHAIN SELECTION BY NODES IS DETERMINISTIC AND MUST ALWAYS BE TO AVOID FATAL FORKS.  Now matter how a node is made aware of a block, how delayed, or what other data it has at the time it currently always picks the same chain.  This keeps the entire network operating on the same chain and avoids fatal forks (forks which can't be re-organized by simply allowing dominant chain to grow longer).  

If nodes determine which block is valid based on information it has (which may be incomplete) then it is possible (actually very probable given enough time) that some nodes will consider block X valid and some consider block X invalid.  Deterministic chain selection is now fatally broken.  Once a node considers a block invalid it won't change its mind and thus any blocks built on it also become valid.  The two fragments keep diverging.  Forks will build upon forks upon forks until the network a fragmented mess of sub networks each with a different view of the current coin balances.  An attacker could exploit this fact by broadcasting transactions (not in the block it just mined) selectively right before broadcasting the block to ensure some nodes will consider a block valid and some not.  Even without malicious intent the network would destroy itself if chain selection isn't deterministic.

It is a non-issue.  Over time transaction fees will make up a larger and larger share of the revenue a miner needs to stay profitable.

[wachtwoord]

Bitcoin is decentralized.  No node knows for sure it has seen all the transactions and likely hasn't at any snapshot in time.  Deepbit, slush, and enough other miners to make up 51% of hashing power decide only they get to mine.  They share hundreds of low value transactions with each other only.  Ever other miner is invalid.  All their blocks are rejected.  If you want to mine you need to join the cartel.  In time the pools could consolidate into a single pool with shares of the profit and raise fees on miners.  Anyone trying to mine outside the cartel would simply have their work rejected.

You just handed complete centralization of Bitcoin to the largest pools.  Awesome.  

This is true in the current system as well. I don't really mind about cartel forming, it is a natural consequence of the free market. (also why I'm against anti-cartel laws but that is another issue)

It is a non-issue.  Over time transaction fees will make up a larger and larger share of the revenue a miner needs to stay profitable.

It is in the long term. However this will likely delay acceptance a (very) long time and:

1) Another currency (which does what I ask) might overtake Bitcoin and I am invested in Bitcoin
2) Even if no other currency overtakes Bitcoin, I want the benefits of such a system as soon as possible (both the advantages everyone will have from the worldwide usage of a currency such as Bitcoin as the personal benefit i will have from my investment).

[kjj]

Method b) Nodes invidually determine which nodes are invalid (seems to be the method advocated by kjj )

The problem is that at any moment in time your node my not see every transaction.  This is important:  CHAIN SELECTION BY NODES IS DETERMINISTIC AND MUST ALWAYS BE TO AVOID FATAL FORKS.  Now matter how a node is made aware of a block, how delayed, or what other data it has at the time it currently always picks the same chain.  This keeps the entire network operating on the same chain and avoids fatal forks (forks which can't be re-organized by simply allowing dominant chain to grow longer).  

If nodes determine which block is valid based on information it has (which may be incomplete) then it is possible (actually very probable given enough time) that some nodes will consider block X valid and some consider block X invalid.  Deterministic chain selection is now fatally broken.  Once a node considers a block invalid it won't change its mind and thus any blocks built on it also become valid.  The two fragments keep diverging.  Forks will build upon forks upon forks until the network a fragmented mess of sub networks each with a different view of the current coin balances.  An attacker could exploit this fact by broadcasting transactions (not in the block it just mined) selectively right before broadcasting the block to ensure some nodes will consider a block valid and some not.  Even without malicious intent the network would destroy itself if chain selection isn't deterministic.

It is a non-issue.  Over time transaction fees will make up a larger and larger share of the revenue a miner needs to stay profitable.

You've added a number of assumptions.  The biggest one is that you assume that block rejection is permanent.

Taking out just that one added assumption, and the system works again.  If my node has block X, and another block comes in (call it Y) that has the hash of block X-1 in it, that new block is rejected.  Unless when block Y+1 comes in and has the hash of block Y in it instead of X.  When that happens, block X is tossed out, and block Y gets unrejected.

In this case, if block Y+1 meets the acceptance criteria, block Y becomes valid, even though I didn't like it when I first saw it.  However, if block Y+1 is also an antisocial block, they both remain on the lonely pile until a good miner builds on top of it, or until the X chain grows longer than the Y chain, making the issue moot.

There may be holes in my idea, but I don't believe that this is one.

16 or 20 years from now, when the subsidy has dropped and hopefully the fees have increased, this may be a non-issue.  But today, it is a real issue.  We are paying full price for these blocks, but only getting part of the value.

For the record, I have no problem with botnets contributing to bitcoin, as far as bitcoin is concerned (i.e. ignoring the moral issues of theft of service or whatever you want to call it), as long as they are contributing to the security of both past and present transactions.

[coblee]

Taking out just that one added assumption, and the system works again.  If my node has block X, and another block comes in (call it Y) that has the hash of block X-1 in it, that new block is rejected.  Unless when block Y+1 comes in and has the hash of block Y in it instead of X.  When that happens, block X is tossed out, and block Y gets unrejected.

In this case, if block Y+1 meets the acceptance criteria, block Y becomes valid, even though I didn't like it when I first saw it.  However, if block Y+1 is also an antisocial block, they both remain on the lonely pile until a good miner builds on top of it, or until the X chain grows longer than the Y chain, making the issue moot.

There may be holes in my idea, but I don't believe that this is one.

Seems like a bad idea. There's going to be a lot of wasted work if half the miners are working on a different block. You will effectively halve the total network hashrate and make it that much easier to 51% the network. Plus if X+1 and Y+1 are found around the same time, it gets worse. This also makes it easier for some to try to double spend their coins.

Probably best to keep things as they are and things will sort themselves out as designed.

[muyuu]

@DeathAndTaxes, this:

The idea has floated several times to reject blocks that don't contain at least some portion of the transactions that you node is aware of.  Might be time to reconsider it

Of course, it wouldn't be anything as simple as "reject empty blocks" or "reject blocks with less than X transactions".  Those won't work.

It will need to be more like "I see 100 pending transactions that are valid and should be included in the next block.  This block I just got from the network contains less than 25% of them, so I will reject it."  There will probably need to be a threshold too, like "I only see 10 pending transactions, and that isn't enough to enforce a minimum number on this incoming block, so I will accept it, even though it has none".

As a first guess, I would say that a threshold of 10 or 20 and a fraction of 1/4 to 1/2 would work well. 

And the rules are made by the majority of the hashing power. So considering we all want what is best for Bitcoin I am hoping that the 3 biggest pools will apply this rule and kill this ignore nonsense. Otherwise it could potentially take a very long time for transactions to be confirmed. Like I said before: I regard this as simply malevolent  behavior and if I had access to >50% of the hashing power would ban it.

I'm hoping some group of people that actually has >50% hashing power agrees.

Horribly stupid idea and would lead to a small cartel locking up 100% of the blocks or worse fragmenting the Bitcoin network is forked chains which can never be reorged depending on how it is implemented.

Method a) Chain selection by miners: (seems to be method advocated by wachtwoord as he indicates hashing power)

If miner's decided which chain to build on based on these rules it would require 51% support.  If they have 51% control of the network they could simply exclude work of all other miners and use "protecting the network" as an excuse.

Bitcoin is decentralized.  No node knows for sure it has seen all the transactions and likely hasn't at any snapshot in time.  Deepbit, slush, and enough other miners to make up 51% of hashing power decide only they get to mine.  They share hundreds of low value transactions with each other only.  Ever other miner is invalid.  All their blocks are rejected.  If you want to mine you need to join the cartel.  In time the pools could consolidate into a single pool with shares of the profit and raise fees on miners.  Anyone trying to mine outside the cartel would simply have their work rejected.

You just handed complete centralization of Bitcoin to the largest pools.  Awesome. 

Method b) Nodes invidually determine which nodes are invalid (seems to be the method advocated by kjj )

The problem is that at any moment in time your node my not see every transaction.  This is important:  CHAIN SELECTION BY NODES IS DETERMINISTIC AND MUST ALWAYS BE TO AVOID FATAL FORKS.  Now matter how a node is made aware of a block, how delayed, or what other data it has at the time it currently always picks the same chain.  This keeps the entire network operating on the same chain and avoids fatal forks (forks which can't be re-organized by simply allowing dominant chain to grow longer). 

If nodes determine which block is valid based on information it has (which may be incomplete) then it is possible (actually very probable given enough time) that some nodes will consider block X valid and some consider block X invalid.  Deterministic chain selection is now fatally broken.  Once a node considers a block invalid it won't change its mind and thus any blocks built on it also become valid.  The two fragments keep diverging.  Forks will build upon forks upon forks until the network a fragmented mess of sub networks each with a different view of the current coin balances.  An attacker could exploit this fact by broadcasting transactions (not in the block it just mined) selectively right before broadcasting the block to ensure some nodes will consider a block valid and some not.  Even without malicious intent the network would destroy itself if chain selection isn't deterministic.

It is a non-issue.  Over time transaction fees will make up a larger and larger share of the revenue a miner needs to stay profitable.

Lots of good insight there, DeathAndTaxes. I had been thinking of these kind of network attacks and there are many intriguing possibilities. I wonder how resilient is the ecosystem in that particular department.

One particular attack I had been thinking of is to fool someone into accepting a payment by somehow isolating him from the real latest few blocks. Network split attacks are possible in some P2P networks. I've seen a few of these that blew my mind. Some easier some harder. One technical aspect of the P2P I'd like to know about: is there node-to-node strong authentication? because a naive P2P connection wouldn't guarantee that different IPs belong to different nodes. This is usually not a concern in P2P since it doesn't make sense to spend more bandwidth upstream while receiving less downstream (gobbling up connections and impersonating nodes), but it could be a possible attack here.

Shame to have a full-time job... all this is fascinating.

[kjj]

Seems like a bad idea. There's going to be a lot of wasted work if half the miners are working on a different block. You will effectively halve the total network hashrate and make it that much easier to 51% the network. Plus if X+1 and Y+1 are found around the same time, it gets worse. This also makes it easier for some to try to double spend their coins.

Probably best to keep things as they are and things will sort themselves out as designed.

We get network splits all the time.  And good miners would have an incentive to build off of the blocks other good miners, so the forks would rarely be anything near 50/50.

And most importantly, this gives the antisocial miners powerful incentives to become good miners, without waiting for however many years it takes for fees and subsidies to do that automatically.

[DeathAndTaxes]

We get network splits all the time.  

Well no we rarely get splits.  A properly tuned mining pool will have an orphan rate of less than 1%.

The goal is to keep the rate as low as possible because the effective hashrate (what matters in an attack) is degraded by a higher orphan rate.

You also seem to ignore all the attack vectors you open up.  Bitcoin is already complex but relatively secure with a few well known attack vectors (mostly involving various forms of double spending and 51% attack).

Just a couple (and likely there are dozens) of possible new attack vectors:

Malicious profit boosting pool:
A malicious pool could create a low latency network with large numbers of connections to Bitcoind (think 10,000+ connections).   It would very rapidly learn of new blocks and have the ability to very rapidly issue new transactions.  Currently that "knowledge" is worthless because even if you detect a new block before rest of the network the only thing that can alter that event is you producing a block (which is very hard).

What you have done is make it very EASY to alter that event.
1) "mean pool" detects block by "honest miner" pool
2) mean pool spams the network with thousands of transactions broadcasting directly to all 10,000+ nodes.
3) each node that gets the transaction flood prior to the block will determine the block invalid.
4) "mean pool" builds on exsiting block height and orphans "honest miner" pool's block.

Simplistically adding a high frequency trading concept to block generation.  You have created an economic incentive to orphan blocks of other miners at very little cost.  Of course pools that don't do this produce less revenue and are less attractive.  The resulting effect is an arms race where pools try to out orphan other pools increasing the number of forks, reducing the effective hashrate and making the network less secure.

Divide an conquer
Using similar method as above, an attacker could take over the network with less than 51% of hashing power.  By degrading the good network through well timed forks and splitting the effective hashing power an attacker with less than 51% of hashing power could out build the degraded network.  The 51% attack has become the 40%? 33%? attack.

Spend, split and spend double spend attack
Attacker could make a large spend, try to fork the network and then double spend the transaction in the new block.  It would require a significant amount of hashing power and would only hurt 1-confirm transactions but the end result is the same, less security.  1-confirm transactions would need to be treated more like 0-confirm transactions now.


Those are just a couple and likely isn't an exhaustive list.  In summary currently orphans and splits are rare AND it is nearly impossible to intentionally cause one.  this makes orphans and splits "weak" attack vector.  Hard to attack via a method that is both rare and difficulty to induce.  Allowing non-deterministic chain selection makes it possible to induce (or at least attempt) to induce splits.  That creates an economic incentive to do so.

The protocol is fine and shouldn't be complicated because people are sad their FREE transactions aren't included in the next block.  If you want to influence the network stop being cheap and RAISE THE FEES.  More fees = more incentive not to mine empty blocks.  Currently all fines combined are less than 0.08% of block revenue.  There is no real economic incentive to include transactions.

TL/DR:
"WHAH.  My free transactions are talking too long.   I want faster free stuff".

[kjj]

...snip...

I can't tell if you are trolling me or not.

We really do get forks every few days.  Here is a list of roughly half of them over the last few months.  http://blockexplorer.com/q/reorglog.

And the problem isn't that free transactions aren't being included in blocks, the problems is that no transactions are being included in blocks.

[DeathAndTaxes]

Like I said RARE and unpredictable.

Every few days is rare. 
There are 144 blocks per day. 
Your list had roughly 1 replacement every 877 blocks.
99.89% of the time no replacement occured.

Most people would describe that as rare and more importantly it is unpredictable.  There is effective method to "force" a fork.  So it presents a weak attack vector.  It occurs rarely and can't be effectively induced by the attacker.  Making forks occur in response to something the attacker can do weakens the network.  Period. 

I won't be wasting any more time about it because:
a) it won't get any support from any major developer
b) it shouldn't get any support because it "solves" a trivial problem while opening up whole avenues of attack
c) even if it was pushed by developers it would never get 51% support of both miners and nodes.

[kjj]

Every three days (roughly) is rare to you?  I don't think you'll find many people to agree with that.  And it is only unpredictable if you need it to happen on a specific block.  If you don't care which block it happens on, then you just need to wait a bit.

The forks that would happen under this plan would be essentially identical to the forks that happen now, and they would be resolved in the same way, and in roughly the same amount of time.

P.S.  Your "flood the network with transactions" attack only works in a world without clocks.  In a world with clocks, like the one we live in, we can keep a count of how many valid transactions were visible X seconds ago, where X is greater than roughly double the mean latency of the network.  30 would be a good value for X.

[DeathAndTaxes]

Every three days (roughly) is rare to you?  I don't think you'll find many people to agree with that.  And it is only unpredictable if you need it to happen on a specific block.  If you don't care which block it happens on, then you just need to wait a bit.

The forks that would happen under this plan would be essentially identical to the forks that happen now, and they would be resolved in the same way, and in roughly the same amount of time.

P.S.  Your "flood the network with transactions" attack only works in a world without clocks.  In a world with clocks, like the one we live in, we can keep a count of how many valid transactions were visible X seconds ago, where X is greater than roughly double the mean latency of the network.  30 would be a good value for X.

Bitcoin doesn't use clocks specifically because it is non deterministic.  By timing the 30 second threshold you could cause some nodes to see the next block as invalid and some to see it as valid.

And yes 3 days is utterly meaningless.  1 block out of 700+ is rare by any standard.  Someone wins the lottery every week thus it is pretty common to win the lottery right?

Still go ahead and fork the blockchain because that is the only way such a reckless and useless proposal sees the light of day.

[piuk]

Seems they have changed ip 88.190.236.238 Or blocked my node.

[rjk]

Seems they have changed ip 88.190.236.238 Or blocked my node.

Wonder how hard it would be to set up proxy nodes that would grab the real IP of the sender, and forward it to your main node while also giving you the real IP (instead of your proxy's IP).

[DeathAndTaxes]

Seems they have changed ip 88.190.236.238 Or blocked my node.

Wonder how hard it would be to set up proxy nodes that would grab the real IP of the sender, and forward it to your main node while also giving you the real IP (instead of your proxy's IP).

I wonder how hard it would be to have the solo miner setup a dozen $5 VPS with different providers and change their IP addresses periodically to obfuscate any tracking.  Alternatively having blocks "appear" from one of hundred tor endpoints would make tracking impossible.

[rjk]

Seems they have changed ip 88.190.236.238 Or blocked my node.

Wonder how hard it would be to set up proxy nodes that would grab the real IP of the sender, and forward it to your main node while also giving you the real IP (instead of your proxy's IP).

I wonder how hard it would be to have the solo miner setup a dozen $5 VPS with different providers and change their IP addresses periodically to obfuscate any tracking.  Alternatively having blocks "appear" from one of hundred tor endpoints would make tracking impossible.

Of course. But the proxy nodes would be helpful outside of this situation, for determining the real first sender of a transaction.

[finway]

Is this LargeCoin or BotNet?

[cunicula]

Is their share of hashing power growing over time?

[kjj]

Every three days (roughly) is rare to you?  I don't think you'll find many people to agree with that.  And it is only unpredictable if you need it to happen on a specific block.  If you don't care which block it happens on, then you just need to wait a bit.

The forks that would happen under this plan would be essentially identical to the forks that happen now, and they would be resolved in the same way, and in roughly the same amount of time.

P.S.  Your "flood the network with transactions" attack only works in a world without clocks.  In a world with clocks, like the one we live in, we can keep a count of how many valid transactions were visible X seconds ago, where X is greater than roughly double the mean latency of the network.  30 would be a good value for X.

Bitcoin doesn't use clocks specifically because it is non deterministic.  By timing the 30 second threshold you could cause some nodes to see the next block as invalid and some to see it as valid.

And yes 3 days is utterly meaningless.  1 block out of 700+ is rare by any standard.  Someone wins the lottery every week thus it is pretty common to win the lottery right?

Still go ahead and fork the blockchain because that is the only way such a reckless and useless proposal sees the light of day.

If we want to keep abusing the lottery analogy, I should point out that every single node on the entire network "wins" about once a week, just not all at the same time.

I had typed up a lengthy reply last night, but I paused to consider what you have said on the subject, and then I slept on it.

My conclusion is that you haven't actually read, or at least not understood, a thing that I've said.  I have two reasons for thinking that.

First, you have completely misunderstood the problem.  See here for example.  Important part quoted below.

The protocol is fine and shouldn't be complicated because people are sad their FREE transactions aren't included in the next block.  If you want to influence the network stop being cheap and RAISE THE FEES.  More fees = more incentive not to mine empty blocks.  Currently all fines combined are less than 0.08% of block revenue.  There is no real economic incentive to include transactions.

TL/DR:
"WHAH.  My free transactions are talking too long.   I want faster free stuff".

And second, you have completely ignored the parts of my posts where I explain the mechanism to be used by nodes to resolve their temporary, local conflicts.  Example here.

Let me be very clear.  I propose that:
1. nodes temporarily reject blocks that they can identify as antisocial.  Nodes already temporarily reject blocks, but for different reasons.
2. nodes have a method whereby a block that was temporarily rejected can become accepted.  Again, nodes already do this.

Further, I assert that:
1. these will not lead to permanent or even long-lived chain forks, for exactly the same reason that the ordinary chain forks that we get about once a week are not permanent, and can't become permanent.
2. any method used to game the system to create blocks that include only dummy transactions created by the attacker to circumvent rejection will necessarily require more effort than simply doing the right thing (including ordinary transactions), giving the current antisocial miner(s) a strong incentive to become a positive part of the network.

[Raize]

If this miner got to the point where they are mining 51% of the network and had supernodes specifically designed to capture transactions, could they start changing those transactions into 1% spend and 99% fees and then only accept transactions where the fee was higher than the sent coin?