Quote from: I_bitcoin on November 27, 2013, 09:18:12 PM

Quote from: Rassah on November 26, 2013, 10:03:06 PM

Quote from: romerun on November 26, 2013, 08:52:09 PM

if I have it right the maximum number of transactions btc network can handle is 7 per sec. coffee purchase and walmart trip has to go offchain eventually.

Only temporary limit while devs still work on improving the system. It's still in beta, and they don't want it to explode in use before its ready. Eventually, transaction limits will be removed, blockchain will be pruned, and the system will be able to handle way more transactions per second than VISA or anyone else (it can already handle such volume with current technology, but we don't want to force people to download 500MB blocks just yet Wink

)

Have not seen the recent work by the devs and you don't know me :-). That said, spent a lot of time reviewing the design and firmly believe that this sucker will scale quite well (so I agree with you Rassah).

Not everyone will be able to run a full node, that is very very clear. There will be plenty of people who donate a node due to the advantage it brings in transaction speed/identification and the bandwidth available to the typical business should allow for full nodes.

Also, am doubting that the speed to push new blocks (from a miner perspective) is as bad as folks think. Decent size datacenters have at least 10G uplinks and the main penalty is going to be on those miners/pools that are far away from each other. Australia, for example, may struggle to win at mining as consistently as places that are "closer" and "denser."

It would be interesting to see an analysis of time to block vs. block size to date (just to see if there are any correlations on this). Still need to do that unless someone has already done it?

The block propagation time is already 4.5 seconds (I don't know why they took down that linked page, I had discussed in depth a solution to selfish-mining attack on that page). As you may know the equation for orphan rate depends on block propagation time, and 500MB block sizes will increase that propagation delay.

Any way, that "coming" (we can't be sure the vested interests of mining will accept it) fix doesn't fix the fact that transaction fees in Bitcoin are always rising nominally or the relative security must implode, but debit card payments I believe have a fixed fee in some cases (not percentage). Bitcoin devs propose lowering the fee, to counter-act this effect, but the transaction fee is a market rate and it appears to me it will be a Spiraling Fee.

Copying those posts here, just in case they delete the blog page again.

Quote

My proposed fix is nonsense, because if the relay is cooperating in the attack by sharing the secret with a selfish-mining pool, then the pool still knows which shares to withhold. So any postulated extra oversight that could be applied to the relay is nonsense. Apologies.

However, I just realized that the selfish-mining attack can be easily defeated. I was originally thinking the pool miners can only spy on their own shares, not the shares of the others in the pool, in terms of knowing that the pool received the winning share. However, I've realized that when the pool starts mining the withheld share, then all miners in the pool will know it because they must be told to solve a new block.

Thus, this selfish-mining attack can be defeated if all pools join as miners of the other pools.

If altcoins were to implement Meni Rosenfeld's oblivous shares, the above counter-measure would only apply to know which pools are selfish-mining, and would not enable the competing pools to start mining on the withheld block. If oblivious shares is implemented, then relays would need to be employed so that competing pools could poll the relays for the new hash to mine when their spying on a selfish-mining pool reveals a withheld block solution.

Also Daniel Larimer has proposed selecting the block with the lowest hash solution within the propagation delay of the network, as another fix for selfish-mining.

Quote

Hey why did you take down the Block Propagation blog page, I had elaborated on my suggested solution.

Emin had countered by stating that the pool could change the hash when adding more transactions. Someone pointed out that the hash of the previous block would change. I pointed out that pool miners have an incentive to require the pool to provide the previous block hash, because if selfish-mining becomes widespread then the system will be taken over by one entity eventually.

I also added that an attacker which doesn't employ a public pool can't be spied on, yet it also can't leverage the domino cascade of employing public miners to mine the withheld share, since this could be spied on.

I contemplated whether it is possible to detect which pool miners are the spies. The spies can mine the withheld share without broadcasting. If all pools spy on each other, then the outcome is the same as if it was broadcasted, but without detection of the spies.