6

You're essentially talking about a "fork" - or a separate chain. It wouldn't and couldn't interface with bitcoin - merely work (at best) alongside it. Exchanges, merchants, and official bitcoin wallets could not be fooled into using this alternative. Someone would have to download a compromised client. As each block refers to the previous one, there would be ...


3

It would be recommended to connect directly to most of the major pools. This way one doesn't need to rely on any other nodes to relay the informations. However, you should note that the conflicting transaction could already be pre-mined, rendering such precautions useless.


3

What happens if now the 10% fork (chain A) will mine a block and send it to the network? When a miner building on top of chain A finds a valid block, it will relay the block to the rest of the network. For convention let us assume the fork (chain A and chain B) has happened at block height N. This is how different nodes on the network will react when they ...


3

BlockChain.info now provides a list of hub nodes. The top entries from that list are all well connected.


3

You could try connecting to various mining pools, fallback nodes or seed nodes. Those should be well connected. The best option, however, would be to host your own Bitcoin node on a server and set it to connect to a lot of outbound peers. This would also ensure that you would be able to see most transactions quickly and also broadcast the transactions that ...


3

Yes, double spend attempts can happen. They're the reason we need a blockchain in the first place. To be able to know which transaction was "first" and which one was the double spend we need an agreed-upon record of history: the blockchain. Until a transaction is in the blockchain, there is no way to know whether it was the first or a double spend, so it's ...


2

It's the other way around. The race attack is a specific type of doublespend attempt. It requires the recipient to accept unconfirmed transactions as payment. The attacker supplies an unconfirmed transaction to the victim that pays the victim. Meanwhile, they broadcast a conflicting transaction to the network. As the merchant saw their own transaction first,...


2

I believe you are asking if the inter-block interval matters for the success rate of a high hashpower reorg attack. It does, because if it is too fast the honest participants will spend a substantial fraction of their time not working on the same (honest) chain, because they haven't heard of each others blocks or have created their own blocks before other ...


1

Or is there a big gap in my logic? Your logic is right, it is just that no decent service will accept a payment unless 1, 3 or even 6 block confirmation. How common are such race attacks Not common at all, but if the services or the person is forced to accept unconfirmed block, here is a link with information about how to better perform and how to ...


1

Bitcoin consensus is never final, but instead just becomes increasingly stable as more blocks are added. In the example in the whitepaper a successful attacker will spend some amount of time "tied" but this tie will eventually be resolved by additional blocks. If the additional blocks are on the attacker's fork then it will resolve in the attacker's favor.


1

There is no acceptance to send to the network. Every node makes its own, independent decision of what blocks to accept based on what chain contains only valid blocks and has the most proof of work. This is the entire rationale behind proof of work and the reason it works. The rule is this: 1) Invalid blocks are always ignored. Blocks must have only valid ...


1

As Doug said in the question comments (posted here as an answer by his request): If there is at least 1 conf by the network, a race-based double-spending attack is not possible. Therefore the attack he describes is a fork-based double spend similar to his questions here and here.


1

You have already answered your question. The basic double spending attack in question is just that: The attacker initiates a Bitcoin transaction and claims a benefit from it. Then the attacker does the same thing again, potentially broadcasting the new, conflicting transaction to a larger number of nodes in the Bitcoin network, in an attempt to have the new ...


1

BlockChain.info now provides a list of hub nodes. While there is no guarantee they will relay your transactions, connecting to several will likely ensure your transactions are propagated to many peers quickly.


1

One possible way to deal with this is to set up a second bitcoind on a separate server, which is well connected to the network (i.e. not behind NAT or something strange like that) whose sole purpose is to listen to the network and take connections from your first bitcoind.


Only top voted, non community-wiki answers of a minimum length are eligible