Bitcoin Forum
December 16, 2018, 11:41:20 PM *
News: Latest Bitcoin Core release: 0.17.0 [Torrent].
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Coin melting: how hide transactions from network analysis  (Read 2152 times)
skeltoac
Newbie
*
Offline Offline

Activity: 10
Merit: 0



View Profile
September 21, 2013, 02:58:40 PM
 #1

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!
Until I saw that the block was mined by a pool that pays out transaction fees I thought this would be somebody trying to hide transactions from network analysis.

You can mine a block containing transactions you haven't broadcast. So you can keep your own transaction fees, effectively transferring arbitrary sums to addresses where no actual transactions exist between sender and recipient.

There are plenty of miners with sufficient hashing power to solo mine and get a block every now and then.

blockchain.info seems to ignore transaction fees in its taint analysis. Are there any network analysis tools that treat mining fees as transactions?

"Coin melting" is awesome.
1545003680
Hero Member
*
Offline Offline

Posts: 1545003680

View Profile Personal Message (Offline)

Ignore
1545003680
Reply with quote  #2

1545003680
Report to moderator
1545003680
Hero Member
*
Offline Offline

Posts: 1545003680

View Profile Personal Message (Offline)

Ignore
1545003680
Reply with quote  #2

1545003680
Report to moderator
PLAY NOW
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1545003680
Hero Member
*
Offline Offline

Posts: 1545003680

View Profile Personal Message (Offline)

Ignore
1545003680
Reply with quote  #2

1545003680
Report to moderator
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2072
Merit: 1007

Newbie


View Profile
September 21, 2013, 04:36:58 PM
 #2

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.
ronimacarroni
Full Member
***
Offline Offline

Activity: 126
Merit: 100



View Profile
September 21, 2013, 08:36:49 PM
 #3

or better yet.
Use anoncoins.*
*after the zerocoin implementation
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2072
Merit: 1007

Newbie


View Profile
September 21, 2013, 08:49:34 PM
 #4

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.

So... why doesn't the "bigger pool" attempt to "remine" regular blocks worth a mere 25 bitcoins each?

Coz next blocks give 25 BTC as well.

Regards, your Captain Obvious.
skeltoac
Newbie
*
Offline Offline

Activity: 10
Merit: 0



View Profile
September 22, 2013, 01:31:48 AM
 #5

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.

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.
hashman
Legendary
*
Offline Offline

Activity: 1031
Merit: 1000


View Profile
September 22, 2013, 06:48:18 AM
 #6

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.

So... why doesn't the "bigger pool" attempt to "remine" regular blocks worth a mere 25 bitcoins each?

Coz next blocks give 25 BTC as well.

Regards, your Captain Obvious.

Well... they can "remine" that one as well? And the one after that? And so on?

Every time a block is orphaned, somebody has remined that block. 
NewLiberty
Legendary
*
Offline Offline

Activity: 1204
Merit: 1001


Gresham's Lawyer


View Profile WWW
September 22, 2013, 03:37:15 PM
 #7

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

FREE MONEY1 Bitcoin for Silver and Gold NewLibertyDollar.com and now BITCOIN SPECIE (silver 1 ozt) shows value by QR
Bulk premiums as low as .0012 BTC "BETTER, MORE COLLECTIBLE, AND CHEAPER THAN SILVER EAGLES" 1Free of Government
cypherdoc
Legendary
*
Offline Offline

Activity: 1764
Merit: 1002



View Profile
September 22, 2013, 04:02:02 PM
 #8

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.

So... why doesn't the "bigger pool" attempt to "remine" regular blocks worth a mere 25 bitcoins each?

Coz next blocks give 25 BTC as well.

Regards, your Captain Obvious.

Well... they can "remine" that one as well? And the one after that? And so on?

Every time a block is orphaned, somebody has remined that 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?
Gavin Andresen
Legendary
*
Offline Offline

Activity: 1652
Merit: 1014


Chief Scientist


View Profile WWW
September 23, 2013, 12:00:51 AM
 #9

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.

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


How often do you get the chance to work on a potentially world-changing project?
skeltoac
Newbie
*
Offline Offline

Activity: 10
Merit: 0



View Profile
September 23, 2013, 02:43:08 AM
 #10

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.

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

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

Activity: 1031
Merit: 1000


View Profile
September 23, 2013, 09:33:56 AM
 #11

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.

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.

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.       
   
 
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2072
Merit: 1007

Newbie


View Profile
September 23, 2013, 09:47:32 AM
 #12

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.


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.        

Confirmed.
Peter Todd
Legendary
*
Offline Offline

Activity: 1106
Merit: 1001


View Profile
September 23, 2013, 10:13:53 AM
 #13

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! 

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.

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.

Correct.

eleuthria
Legendary
*
Offline Offline

Activity: 1750
Merit: 1002



View Profile
September 24, 2013, 06:07:42 AM
 #14

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

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.

RIP BTC Guild, April 2011 - June 2015
thezerg
Legendary
*
Offline Offline

Activity: 1246
Merit: 1000


View Profile
September 24, 2013, 12:53:18 PM
 #15

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.

So... why doesn't the "bigger pool" attempt to "remine" regular blocks worth a mere 25 bitcoins each?

Coz next blocks give 25 BTC as well.

Regards, your Captain Obvious.

Well... they can "remine" that one as well? And the one after that? And so on?

Every time a block is orphaned, somebody has remined that 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?

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

Peter Todd
Legendary
*
Offline Offline

Activity: 1106
Merit: 1001


View Profile
September 24, 2013, 01:58:03 PM
 #16

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.

So what % of orphans are you seeing?

NewLiberty
Legendary
*
Offline Offline

Activity: 1204
Merit: 1001


Gresham's Lawyer


View Profile WWW
September 24, 2013, 03:02:37 PM
 #17

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!  
 

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.

FREE MONEY1 Bitcoin for Silver and Gold NewLibertyDollar.com and now BITCOIN SPECIE (silver 1 ozt) shows value by QR
Bulk premiums as low as .0012 BTC "BETTER, MORE COLLECTIBLE, AND CHEAPER THAN SILVER EAGLES" 1Free of Government
skeltoac
Newbie
*
Offline Offline

Activity: 10
Merit: 0



View Profile
September 24, 2013, 04:33:57 PM
 #18

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!  
 

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.

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).
NewLiberty
Legendary
*
Offline Offline

Activity: 1204
Merit: 1001


Gresham's Lawyer


View Profile WWW
September 24, 2013, 04:44:45 PM
 #19

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!  
 

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.

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

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.

FREE MONEY1 Bitcoin for Silver and Gold NewLibertyDollar.com and now BITCOIN SPECIE (silver 1 ozt) shows value by QR
Bulk premiums as low as .0012 BTC "BETTER, MORE COLLECTIBLE, AND CHEAPER THAN SILVER EAGLES" 1Free of Government
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!