if you can double your bitcoin in any way i'm sure the price will tank to 50% of current price long before you can do anything


what happen if both chain hold 50% of the network?, it's like having a bitcoin with half the network and a new altcoin that want to be bitcoin 2.0

Hi.,

      How can we claim or spent the unspent bitcoins that are lodging as unspent transaction in Blockchain...?

Thanks

Isn't it obvious?
We can see every address that coins go to, or come from. Even passing thru a tumbler taints the outputs to some extent.

I am in a small city and we dont have Bitcoin atm at the moment.
I just registrated to www.kraken.com...Is this site Good? Can I buy with my debit card in kraken?

It seems like the second block has been mined aswell looking at this  : http://xtnodes.com/xt_blocks.php , when we are supposed to upgrade to XT though ? I know it's on January and stuff however do we need 75% nodes running or we need 750 block mined from 1000

While having a high-capacity set of full nodes increases the on-blockchain transaction rate, the requirement of full nodes to be high capacity has a centralizing effect.

Yes, except who has the power to alter who is classified as an "attacker"?  Once you can blacklist an IP can't someone decide to apply to it anyone?

You seem to think I hate Tor. I am actually the maintainer of a full blown Tor implementation (Orchid). I've done a lot of work on integrating it into bitcoinj and I'm basically the only guy who can actually move the needle on Tor/Bitcoin usage, by enabling the use of it by default in consumer wallets that have hundreds of thousands of installs. We're not there yet (it's still too slow) but we're a lot closer than before.

This doesn't change the fact that Tor is heavily abused. It can be useful but it's a frequent source of attacks of all kinds. So finding ways to get the good without the bad involves some tricky coding.

Below, you say "anyone can jam the network with just two IP addresses". Yes, that's unfortunate isn't it. I've been sounding the alarm about Bitcoin Core's poor DoS protection for years. Nobody listened, that's why I have now written a new anti-DoS system that can handle this sort of thing. It starts by clustering and deprioritising Tor because we've seen actual jamming attacks that came through Tor, and because using it is a lot safer and more convenient for an attacker than using your own IP addresses or using a botnet. But it absolutely should be extended to have more advanced heuristics. Instead of whinging that (gasp) loading a file from a web server is "insane", maybe you should be writing code instead.

Yes, I know how does DDOS work and can confirm that blocking Tor is stupid and ineffective method.
There are huge botnets around with over 15K IPs each, that you cannot identify because, unlike Tor nodes, they are not listed somewhere.
If someone wants to run devastating DDOs again bitcoin network, they will succeed without help of Tor.

You seem to think I hate Tor. I am actually the maintainer of a full blown Tor implementation (Orchid). I've done a lot of work on integrating it into bitcoinj and I'm basically the only guy who can actually move the needle on Tor/Bitcoin usage, by enabling the use of it by default in consumer wallets that have hundreds of thousands of installs. We're not there yet (it's still too slow) but we're a lot closer than before.

This doesn't change the fact that Tor is heavily abused. It can be useful but it's a frequent source of attacks of all kinds. So finding ways to get the good without the bad involves some tricky coding.

Below, you say "anyone can jam the network with just two IP addresses". Yes, that's unfortunate isn't it. I've been sounding the alarm about Bitcoin Core's poor DoS protection for years. Nobody listened, that's why I have now written a new anti-DoS system that can handle this sort of thing. It starts by clustering and deprioritising Tor because we've seen actual jamming attacks that came through Tor, and because using it is a lot safer and more convenient for an attacker than using your own IP addresses or using a botnet. But it absolutely should be extended to have more advanced heuristics. Instead of whinging that (gasp) loading a file from a web server is "insane", maybe you should be writing code instead.

I support blocksize increasing idea, but not in a form of fork such as XT, which besides block size has some shady unannounced privacy affecting features such as Tor blacklisting.

IMO, everything must be done inside Core client.

Introduce the beginnings of anti-DoS resource scheduling.

This adds code that takes effect if a node gets completely full (this should never happen unless there's an attack or the number of nodes falls dangerously low).

Peers now have a priority that attempts to estimate their importance. Currently it is just based on IP address. The default score is zero. In future it may take into account things like how many blocks were relayed, etc. When a node reaches its max connection slots, it will attempt to find a peer with a lower priority than the one trying to connect and disconnect it, to stay below the max connection limit.

Peer priorities are based on matching the connecting IP against a set of IP groups. For now, the only IP group is one that gives Tor exits a score of -10. This is to address DoS attacks that are being reported on the main network in which an attacker builds many connections via Tor to use up all the connection slots and jam the node for clearnet users. It's a more robust approach than simply banning abused proxies altogether.

The code has both a static list and a list that's downloaded when the node starts.

Other anonymizing proxy networks that are attractive to DoS attackers may also be added as alternative IP groups, as a quick fix. Eventually peer priority can be calculated in a more free floating and dynamic manner and the hardcoded IP approach may become unneeded.

sharknado
waste my time