Bitcoin Forum
September 20, 2019, 03:08:10 PM *
News: Latest Bitcoin Core release: 0.18.1 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 [45]
881  Bitcoin / Bitcoin Discussion / Re: Sending change to a different address, does it help much? on: January 23, 2015, 04:45:15 PM
I know about CoinJoin but not sure people will widely use it unless it is integrated in most wallets and on by default. The majority always tends to take the easiest path no matter what it means for security and privacy.
882  Bitcoin / Bitcoin Discussion / Re: Sending change to a different address, does it help much? on: January 23, 2015, 03:57:55 PM
If you were worried about this, you could always split up the BTC before sending into equal amounts. If you wanted to make a payment of 1 BTC, you could always send 2 BTC to a new address, then send 1 BTC to another person, with 1 BTC going to a new change address.

Then the 8 BTC change from the 1st transaction is still tracked to the payer.

Additionally, it would be difficult for someone to tell for sure that you made a 1 BTC payment vs a 9 BTC payment. They could assume but won't always be correct.

Of course, it is high probability rather than certainty.
883  Bitcoin / Bitcoin Discussion / Sending change to a different address, does it help much? on: January 23, 2015, 03:05:45 PM
To protect your privacy, it is commonly recommended to send change to a new freshly generated address. It is argued that this makes it impossible to distinguish the payment from the change which makes it harder to group the transactions that belong to you.

Correct me if I'm wrong, I'm afraid it doesn't help in many cases. The reason is simple: payment value is usually smaller than the change.

When I spend money from my debit card, the payment amount is usually much smaller than the remaining balance. That's because I don't want to refill my card as often as I spend. The same spending habits applied to Bitcoin make transactions traceable.

If you have 10 BTC (say, you received it from an exchange) and want to pay 1 BTC, your transaction will have two outputs:
1 BTC - the payment,
9 BTC - the change to another your address.
Without any other knowledge, just by looking at the output values, it is usually safe to say that 1 BTC is the payment and 9 BTC is the change, and the address where the 9 BTC landed is again your address. Any other coins received to this address will be tracked to you. The subsequent transaction that spends the 9 BTC will be tracked to you.

Any thoughts how this situation is really often and how to protect one's privacy?
884  Bitcoin / Development & Technical Discussion / Re: Fake block timestamps can cause a temporary fork? on: January 19, 2015, 08:12:39 AM
I like the dice example, there is one small difference though.
If the controversial block was block number 1001 then the miners who initially rejected it (segment B) will continue working on another version of block 1001 while the miners who accepted it will switch to block 1002. That means, for segment B to win, it'll have to produce 2 blocks (1001 and 1002) faster than equally powerful segment A produces one block 1002. This probability is low, and segment B is probably wasting its resources.

There is no long term damage anyway.

885  Bitcoin / Development & Technical Discussion / Re: Fake block timestamps can cause a temporary fork? on: January 18, 2015, 09:12:55 AM
Why would a miner want only half the network to build on their block?

That makes no sense... what is the +2hr timestamp miner trying to accomplish?


No obvious benefit to the miner, just a short lived disruption of the network (I don't think it is big enough to qualify for a DoS). If successful, it would split miner resources and cause the next block to be mined at half speed.

The main point here is that relying on node current time is dangerous for consensus. Even if it doesn't cause major trouble, it complicates things. Fortunately the 2h rule is the only place in bitcoin protocol that instructs node to make a decision based on its own clock.
886  Bitcoin / Development & Technical Discussion / Re: Fake block timestamps can cause a temporary fork? on: January 18, 2015, 08:45:26 AM
Yes, it's done in CheckBlockHeader called from CheckBlock preventing the block from being cached.


Great. That means the chances of quick recovery are high.
887  Bitcoin / Development & Technical Discussion / Fake block timestamps can cause a temporary fork? on: January 17, 2015, 05:50:31 PM
Every block includes a timestamp as set by the miner who mined the block. There is a rule that other nodes reject the block if its timestamp is more than 2 hours in the future. It is a hard limit: if the timestamp is 2:00:01 in the future relative to node time, the node rejects it; if it's only 1:59:59 in the future, the node accepts it.

What happens if a miner finds a block and sets its timestamp exactly 2 hours in the future relative to some accurate time source? Since the clocks of all other nodes are never perfectly synchronized and distributed somewhere around the true time, I would expect that approximately half of the nodes (whose clock is slightly ahead of the true time) accept the block, while the other half will reject and forget it. Half of the miners will accept the block and start building a new block on top of it (with half of the original hash power), the other half will continue working on the previous block. We've got a blockchain fork caused by misbehavior of just one node. One of the two forks will eventually win but, before that, transaction confirmations might be delayed. Did I get anything wrong?

I think when designing a distributed consensus system, such as Bitcoin, one should be cautious about making a decision based on node time. Node time is different at different nodes and this a source of disagreement that potentially destroys consensus. Hopefully just temporarily.

Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 [45]
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!