Topic: Wonder who this solominer is? 88.6.216.9 - page 34. (Read 60464 times)

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.

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.

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".

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.

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.

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.

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 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).

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.

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, this:


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.

Sure, I never suggested such a thing.


I merely opposed your "Who cares?" attitude. If 15% of the blocks never includes any transactions then Bitcoin does not behave as people expect it to and that might hurt Bitcoin's reputation. It's possible to worry a little bit about the state of the network without screaming for protocol changes.

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. 

Yes that is called a 51% attack. Even if the "good chain" pulls ahead for a block (or 20) given enough time someone with 51% of hashing power will always have the longest chain.

51% is mostly academic likely one would want a larger "house advantage" in these coin flips between good side and bade side.  Meni did some math on "how long" it would take with various % to have a 99% chance of being ahead.  51% is very long but is scales up very rapidly.  So likely someone who could afford ~5TH/s would spend a little more and make their attack more efficient.

Say this guy acquires 51%. Is an option for him to include txns and operate responsibly, but refuse to accept any blocks issued by other parties. Thus, anyone with 51% effectively can have 100% and mines every single block. Is this correct?

AND?

If there was a rule that a block must have 2+ transaction don't you think he could simply pass 1 satoshi from one of this accounts to another in every single block?

You have no right to have your transaction in the next block.  If you want higher assurances then increase the fee you pay.  As block subsidy declines this entity will either need to start including transactions or face dwindling revenue.


Well, if my transaction has not been included in a block yet I have to wait longer before it is.

Well, if my transaction has not been included in a block yet I have to wait longer before it is.

I think we need specialized ASIC miners, to defeat the botnet.

And btw:  this is not botnet, cause i can't find a block today.

Just wanted to mention I am now offering the Deluxe Bitcoin Network Disrupter Service.

Bring down this crazy train once and for all!  Starter packages from as little as $2,999.95 USD per day!

Results absolutely guaranteed.  Sorry, no paypal.


 

You guys realize that for a $1.99 you can buy a SuperComputer for a week.  Oh wait you can't and neither can you disrupt Bitcoin for "a few thousand dollars a day".