Topic: Coin melting: how hide transactions from network analysis (Read 2215 times)

Yes, thank you.  That is what I inferred was intended to have been written as well.  The text was slightly less precise in a way that overstated the problem, significant as it may be.  As you point out there are also discrete and predictable times at reward halving where it merits additional inspection.

The assumption was that the average block's fees are much smaller than the mining reward. When the fees become more significant the calculation must include the expected value fees lost. Instead of F>2R, you'll be looking for F>2R+2F_avg. As R approaches zero this inequality becomes easier to satisfy.

We're probably still off by an R or an F here or there. And we haven't even discussed the scenario when R_1 = 2R_2 (when R_1 is the last block to receive 25BTC).

I think you are right in all elements but may have slightly misstated this?   Would it be better stated that this will be an incentive problem whenever the fees+reward approach ~ twice the average fee+reward?  
It seems it is less of a problem of just fees>reward*2 which is expected to become very common indeed.

So what % of orphans are you seeing?

As soon as a miner receives a new valid block, it will switch to mining the next one on that chain because clients consider the longest, highest difficulty chain the main one and the cost to switch to mining the block after the one you just received is negligible.

But if someone finds a block before they receive your newly mined block there's now 2 valid blocks -- that is, the beginnings of a fork in the blockchain.  Since the longest valid chain "wins" (clients consider the longest, highest difficulty chain the main one) the race is now on to find the next block; if it build off of their block then your block is "orphaned".

Therefore to stop a fork it is good to:
1. Receive other miner's blocks as soon as possible to minimize the time you are mining on a shorter chain.
2. Broadcast your block as widely as possible to minimize the time others mine on the shorter chain.

Once there is a fork the goal is to find a block on your chain first.  To do this:
3. Broadcast your block as widely as possible to encourage others to use your chain.

Obviously a larger pool has an advantage here as it starts with a lot of processing power that's going to be mining off its' block.

Gavin is right that a rigorous analysis would be fun, but in the meantime you could do as much of all of the above as possible.  AFAIK there are parameters, etc. that can be adjusted in the client to increase your connectivity, etc.  But I haven't looked at the source for awhile for I forget if they are programming constants or are config parameters...

HDD speed, CPU speed, and how well connected you *AND* your peers are, in roughly that order (assuming server quality bandwidth).

1) HDD Speed:  Disk access still seems to be a relatively heavy hit whenever a new block is found.
2) CPU Speed:  Validating a new block and subsequently updating to work on the new block both appear to be mostly (entirely?) single threaded operations, so the raw clock rate is quite important.
3) Connectivity:  Assuming you're on a server quality connection, your biggest limits are how many peers you're connected to, and how well *those* peers are connected.  I've found having only 30-60 connections is preferred over having 120-1000 connections, when your 30-60 include at least 10 "known good nodes".  The biggest window for orphans are the first 2-3 hops of distributing your block (most orphan races, according to blockchain.info are roughly a 80%/20%  or 95%/5% split on how much of the network has seen a particular block in the orphan race.  I've never seen those numbers approach a true 50/50 split.

This is actually why BTC Guild has taken the "many individual bitcoind instances" approach.  Each one is connected to each other, and each one has a list of about 10 different nodes they always try to connect to, then let the other 40-50 nodes come randomly.

You're analysis is correct, although we have two solutions in the works:

1. Discourage fee sniping with nLockTime: If clients always create transactions such that only the next block can include them, it becomes less attractive to re-org blocks because you won't be able to cherry pick high-fee transactions that have been created since the last block. We can implement this right now, although it's relatively weak protection; I mostly wrote the patch because I don't want systems to start making assumptions about nLockTime now that prevent us from implementing that fix in the future.

2. Transaction checkpoints: Every transaction has a individual "checkpoint" block, and if included in a block in a chain that doesn't include that blockhash the block mining the transaction isn't allowed to collect its fee. You can still re-org a block to grab an individual transaction, but all the other transactions will then (probably) not be available to you. This change requires a soft-fork to implement, but is better protection than #1.

Finally a limited blocksize helps too: if transaction fees are roughly equal you eventually run out of space in the block anyway.

IMO the biggest problem with this re-org business isn't the re-orgs themselves, but rather that it gives incentives for mining pools to get bigger because only a large pool can profitably attempt re-orgs. This could be a serious problem if a significant portion of mining income in the future was in the form of fidelity bond fee sacrifices.


Correct.

Big pools can mine 2 blocks in a row:



If someone created a block with hundreds bitcoins as fees, someone would attempt to remine it.



Confirmed.

This might be a bit off topic but I'm actually quite curious about this analysis.

If you want to "remine" a block, orphaning somebody else's, it means you must make sure your new block is part of the longest current chain, so you really need to mine two blocks.

Lets say you have 1/n of the hash rate, with expected reward for a block is R+F.  The probability to solve two blocks is n^-2.  Lets assume negligible fees on the current block but a large melting set of fees on a just announced block.  Our expected mining return will be equal for remining when:

(2R+F)n^-2 = R/n     or  F=R(n-2)

It seems that this is another region where the equations break down as you approach the 50% of hash rate figure.  At that rate, the problem becomes similar to the St. Petersburg bet and it appears that such a miner will have incentive to put hashpower toward remining every block. 

If you have 1/4 of the hashpower today, you will try to remine (fork the chain) when there is a fee of 2R or 50BTC.  At 5% of hashrate, this gives a cutoff of 18x the reward for when it becomes possible to backtrack.  Traditionally we have always had a pool or two floating at around the 1/4 level.  Therefore when the fees approach ~ twice the reward (and they will eventually if the network stays alive) this will become a problem! 

Confirm please:  the network currently does not care the value of the hash of a block, apart from it being lower than the value prescribed by the difficulty.       
   
 

The taint-tracking and network analysis algorithms are the ones I'm referring to as needing updating. Not bitcoin itself.

No, they can't. You just extend the taint-tracking through the newly minted coins (e.g. if you try to "melt" 75 BTC with the 25 BTC reward, then the resulting 100 BTC should be considered 75% tainted).

RE: orphans:  orphans happen naturally when two nodes on the network find blocks at approximately the same time. Somebody should do a rigorous analysis to determine what are the most important factors affecting orphan rates (number of connections? quality of connections? bandwidth available to "blast out" the new block? block size? Number of not-previously-seen transactions included in the block?)

i just had a solo mined block orphaned for the first time.  annoying as hell.

how does that happen and how do i check the logs (ubuntu) to analyze what happened?

Intent or timing accident...who is to say?

Every time a block is orphaned, somebody has remined that block. 

Such a counterattack has a known benefit and a computable cost. There's the opportunity cost of spending hashing power on trying to orphan a block rather than confirm it.

Would the current block reward be the simple upper limit on "safe melting" or is it more complex than that? I think it would be significantly more than the block reward and it would depend on the attacking pool's mining probability. A pool with 5% of the global hashing power might improve their odds by trying to orphan a block (remining the non-broadcasted transactions for their fees) when it would provide over 40x the next block's reward otherwise.

Coz next blocks give 25 BTC as well.

Regards, your Captain Obvious.

or better yet.
Use anoncoins.*
*after the zerocoin implementation

Such melting can't be done safely by a small pool, coz a bigger pool can make an attempt to "remine" the block and collect the fees by itself.

A solo miner (or a pool operator if they keep the fees) can use large transaction fees to avoid taint and network analysis. These algorithms must be updated to include transaction fees.

Re: 1CfsAiYaVfk12dnZpZALcRSP9jjWDk26FX - Stop making transactions!