Topic: How the validation after the mining can detect a fraudolent node behaviour (Read 206 times)

Around 100-200ms at most.

Alas, almost all the large pools don't actually do this, they do allow invalid transactions in the blocks they build on.

They send out work to all their miners, based on a block they haven't verified, then once they have later fully checked the block, they send out work based on the knowledge of what transactions were used in the block ... thus why they mine empty blocks, since they have no idea what transactions were used before they verify them, and wish to send out work before they verify the block.

One feature of bitcoin and all altcoins (except stablecoins) is that when an output is spent to an "address", the only way that it is possible to spend that output is by the private keys associated with that address when the address was generated signing a transaction (and that transaction being broadcast). This is the primary feature that gives bitcoin and altcoins value. There are no assets, nor any expectation of future dividends backing bitcoin and altcoins. Not all addresses are generated the same way, and some may require multiple private keys to spend any outputs received to a particular address, however, this is determined when the address is generated.

If there was an altcoin in which it is possible for an arbitrary person to spend someone else's coin, there would be no reason for anyone to give this altcoin any value. There would be no reason for someone to exchange anything of value for a coin that could be taken from them by the majority of miners, who could potentially later switch to mining a different coin.

Some stablecoins can be 'frozen' by their sponsor for potentially arbitrary reasons. However, even stablecoins sponsors cannot move an arbitrary stablecoin output to a different address without the associated private keys.

In addition to the above "promise" (it is really more of a guarantee) that no one can spend bitcoin sent to your address without knowing your private key, there are other features that also give bitcoin and altcoins value, but without the aforementioned promise, all of these features would be useless.

Thank you for reminding me this thing too Danny. Infact a source of doubts was coming from the fact i was convinced that to impose your fork was enough to have a longer chain but as you clarified you also need a valid (validated) chain in terms of signature and no double spending. Otherwise you may dispose of a longer chain but it will be ignored if is fraudolent

You could, since you would outpace the creation of blocks by the rest of the world, so your forked chain would continue to be longer.

However, as you can hopefully see from the explanation that I posted above, if your chain included an invalid transaction then all the nodes that are running the real Bitcoin software would continue to just ignore your chain. You would have created a forked altcoin, and if you could convince others to use your custom software, then they would have access to coins on your chain separately from the Bitcoin chain.

In addition to having more than 50% of the world's hashpower, you could also just change your software to add something to your blocks that doesn't exist in a Bitcoin block and then make that extra thing a requirement for blocks accepted by your software above a chosen block number. Since Bitcoin blocks wouldn't have that extra thing, your software would see all future Bitcoin blocks as invalid and wouldn't accept them in place of your chain with less proof of work. This is effectively what happened with Bitcoin Cash.

Initially, Bitcoin Cash was just going to be creating blocks that are invalid according to the Bitcoin software. Those invalid Blocks would result in a forked chain via the same mechanism as I described.  Their initial hope was that the vast majority of the world would switch to their software and therefore their chain would always have the most proof of work.  Since Bitcoin is a system of consensus, they would effectively BE Bitcoin, and the small minority of users running the old software would be the altcoin.

Once they realized that they weren't going to be able to initially convince enough people to use their software to guarantee that their chain always had the most proof of work, they had to find a way to maintain their chain and keep it from continuously being overwritten by the Bitcoin blockchain. They had to modify their software in a way that made standard Bitcoin blocks look invalid to their software.  That way there was no risk of a re-organization of the blockchain using blocks from the Bitcoin blockchain.  Once they did that, they were able to extend their chain indefinitely.  It still doesn't affect Bitcoin, because their blocks are still invalid according to the Bitcoin rules, but they no longer had to worry about having more total proof of work.


You are correct. Preventing invalid transactions can be (and is) accomplished without proof of work.

The proof of work is needed for that second part where one chain is chosen over another.  If it isn't slow and expensive to create a block, then an attacker could just create a burst of blocks to accomplish a variety of attacks.

For example, I could create software that makes two equally valid copies of a transaction. One copy would pay some recipient (perhaps you?), the other copy would, instead, pay a second address that I control.  Then I could broadcast the transaction that pays you while I simultaneously create a block that uses the transaction that pays me.  I'll hold on to that block secretly and not broadcast it to anyone yet. Every time I see another block from the network, I'll just create another block of my own on top of my secret chain so that my chain is always one block longer than the rest of the world. When you finally accept my payment and provide me something of value in exchange, I can then broadcast my secret chain to the world.  All nodes (including yours) will see this longer chain and immediately throw out all the blocks that they have back to the block height where mine starts, and they will accept my longer chain in place of it.  I'll have my bitcoins back, and you'll have provided me something of value in exchange for nothing at all. The transaction that pays you will be seen as an invalid transaction by the whole world (including your nodes) since it spends bitcoins that (according to the blockchain) have already been spent elsewhere.

Since creating blocks was effectively free and instantaneous, there wasn't ever any real risk to me.  The worst that could happen to me even if I failed at my exploit is that I get what I paid for. Meanwhile, you could never feel confident that your payment wouldn't disappear.  It's impossible to run a currency where recipients can never feel confident that they've actually received a payment. Nobody would accept it.

What i meant speaking of attacks was referring to this Danny sentence:

"If 'X' includes ANY invalid transaction in his block, then he will create a very short-lived hard fork"

Totally clear, and i guess if i control 51% of the computational power i could extend the fork with fraudolent fake transactions indefinitely...

51% attack steal can't spend someone's coins or create coins out of thin air or really do anything like "controlling the blockchain". It can just undo the latest blocks, so the way to profit from it is to send someone coins, wait until they give you something in exchange, then undo the blocks with your transaction and have your coins back in your wallet. But aside from requiring 51% of hashrate, you also need to find someone who would agree to a large deal in BTC and will require just a few confirmations and not, let's say, 144 or 288 confirmations.

Such attacks happened with altcoins and exchanges suffered losses, but with Bitcoin it's very unlikely to see it on practice.

It's really remarkable how helpful some users of this forum are. Puzzling out such queries with such long and constructive answers reveals the conviction of those people about an idea and their willingness to support it, non-profitably, for years. Bravo, DannyHamilton! Your responses inspire to continue learning.

---

You don't need 51% of the nodes to succeed a fraudulent attack. It's not a one-IP-one-vote system. An attacker could easily create thousands of nodes, but they'd succeed nothing if they didn't accumulate the majority of the computational power.

To give a short answer to your main question: It's consensus that prevents people from persuading others to install a censored version of the currency with certain exceptions, such as not verifying all transactions, but just accepting absolutely some.

The validation of an entire block including all the transactions generally takes less than 3 seconds on any reasonably modern hardware.

Absolutely great and exhaustive answer my friend. Thank you so much for the time spent on it. I had figured exactly the case you explained.

My mistake was to consider just the POW as condition to send and attach new blocks to the chain. But the other honest nodes have a method (i guess is very quick in terms of time, a small fraction of the POW time) for instantly detecting the fraudolent attempt, because they control quickly the full path of the bitcoins movements. Now i understand also why you need 51% of the nodes willing to be fraudolent to succeed.

All transactions are verified by all nodes including all other solo miner nodes and mining pool nodes before adding the transaction to their own mempool or relaying the transaction to any other node.

This means that if, in your example, 'A' tried to send his fake transaction out to any other node (before 'X' mined it into a block), then every node that he sent it to would see that it didn't have a valid signature. They would therefore refuse to add that transaction to their own mempool, and they would refuse to relay it to any other node.  Therefore, the ONLY nodes that would even be aware that the transaction was sent would be ones that 'A' controls. If he was directly connected to 'X', AND 'X' was running custom-designed software that would accept unsigned transactions, then the mining nodes controlled by 'X' would also be aware of the transaction. 'A' and 'X' might be able to also convince a few of their friends to run this custom designed steal-a-coin node software. If so, then those friends would also have that transaction in their own mempool and would relay the transaction to any node willing to listen to them.

'X' has a big problem though if he chooses to include that transaction in one of the blocks that he mines.  This is because:

All blocks are verified by all nodes including all other solo miner nodes and mining pool nodes before adding the block to their own blockchain or relaying the block to any other node.

If 'X' includes ANY invalid transaction in his block, then he will create a very short-lived hard fork.  When he tries to send that block to any other node that is not running the steal-a-coin node software, they will verify every transaction in the block as well as the proof of work.  If any transaction is invalid according to the consensus rules of Bitcoin, all of these normal Bitcoin nodes will reject the entire block. These Bitcoin nodes won't add that block to their own copy of the blockchain, and they won't relay that block to any other nodes. Having an invalid transaction in your block is just as bad as having a block that doesn't have the proper proof of work. Meanwhile, the friends of 'A' and 'X' that are running the steal-a-coin custom software will accept the block and will add it to their own blockchain.

Let's imagine for the moment that 710,000 blocks are in the blockchain.  X creates block number 710,001 with this invalid transaction and completes the necessary proof-of-work before any other miner completes and broadcasts block 710,001.

'A', 'X', and their friends have added it to their own blockchains, but the entire rest of the world rejects the block.  So, now 'A', 'X', and their friends have a blockchain with 710,001 blocks in it and nobody else does. In approximately 10 minutes someone somewhere else in the world will complete and broadcast their own block number 710,001.  Since most of the world all refused to accept the invalid transaction before the block was mined, they won't even know about its existence. That invalid transaction won't be in this valid block from this other miner. Since this new block will be valid, all of the proper Bitcoin nodes will add it to their own blockchain and will relay it to all the nodes that they are connected to.

Now, we have a hard forked chain.  99.9999% of the world has a blockchain without the invalid transaction, while all of the nodes run by 'A', 'X', and their friends have a blockchain with the invalid transaction.  Most of the world doesn't even know that the invalid block or the invalid transaction exists. And, then here comes the brilliance of Satoshi's solution to the Byzantine Generals problem...

In about 10 more minutes, another block (block number 710,002) will be mined somewhere in the world. This block ALSO won't include the invalid transaction since (if you recall) none of the valid nodes kept a copy of it, so they don't even have it to include it in their blocks. This block 710,002 will be broadcast throughout the world.  The nodes being run by 'A', 'X', and their friends will hear about this block 710,002 (since they remained connected to the valid bitcoin nodes in an attempt to get their invalid transaction sent out).  Their nodes will see that there is a chain that has more total proof-of-work than the chain that they have, and that this longer chain does not include their block number 710,001.  Since the blockchain concept includes the rule that "longest chain wins", they will abandon their invalid block and replace it with blocks 710,001 and 710,002 that they receive from the valid nodes.  Now 'X's invalid block has been abandoned by the entire world (even abandoned by 'A', 'X', and their friends). This is why I said the fork would be short-lived.

Since the block reward that pays the miner is a transaction in the miner's block, 'X' has now earned NOTHING from his mining of the invalid block.  Not only did he fail to assist his friend in getting an invalid transaction into the Bitcoin blockchain, but he has also spent a lot of money on mining equipment and electricity to miner a block all on his own, and has lost the 6.25 Bitcoin block reward (more than $375,000 at today's exchange rate) that he would have earned if he had just been mining honestly instead of running his friend's steal-a-coin software.

Go ahead, try and convince ANY friend of yours to give up over $375,000 of their hard-earned money to run your fancy software that will accomplish nothing.  The system is designed to keep nearly all miners working in support of the system because failing to do so is expensive and they can earn more money doing it the right way.

My question arose because of course i lack basic computer science notions. My understanding was that whatever you fed the SHA256 function with (meaning regarledless the transactions are real or fake) , a sufficiently powerful computational power could in theory solve the POW and sneakily try to insert a new block that would be not recognizable by the other miners

That's correct.


From what I know it's before the mining. I don't know if such a transaction is even relayed by the nodes, but the miners will surely not accept it in a block.


However, if you want to be sure, maybe you move this topic into Development & Technical Discussion; then you should get answers from people who know this better than me.
(see page's bottom-left: move topic)

Marvellous explaination. That is what i missed: the signature element!
So there is no way to use a fake signature and mine that as well in order to finish a POW right?

Just a detail i would like to ask more: The fake transaction conjectured here would be rejected immediately before mining or after the mining in the subsequent validation process?

I'll basically say what Kano said, but I'll try to say it different:

The blockchain is something that contains the "path" of every satoshi from the moment it was created (received as block reward by a miner or pool) until now.
A transaction moving coins from one address to another has to have a real basis, it has to continue an existing "path".
So the first part is: the only two ways for A to get coins is to either mine (but one block gives only 6.25BTC + the tx fees), either receive from B.

Now, the software is made in a way that a transaction is accepted/valid only if it's signed by the sender. Since neither X nor B don't know A's private key, they cannot sign the transaction.

Shortly:
* Since A is not a miner he cannot get new coins (out of thin air)
* Since A doesn't know B's private key, he cannot forge a valid transaction that will steal B's coins; and if it's not valid, it will be rejected.

The only bitcoins created out of 'thin air' are the coinbase reward in the coinbase transaction for mining a block.
This of course has specific rules also.

All other transactions are simply spending previously known outputs.

All miners must verify that all transactions they put into their blocks are valid.

Hello,
Sorry i know that my question is surely a bit naive but i am really just starting to dig into it

Imagine individual X is a mining node. Imagine his friend, individual A, possesses 0 bitcoins. The individual B possesses 100 bitcoins. X and A know that B owns 100 bitcoins. B doesn't know neither X nor A.

A sends a new transaction to the nodes, a transaction where he receive 999 bitcoins from B, without B knows it. Lets say X manages to grab and mine successfully this transaction in block, finding during the mining the number to get the required target hash with the right number of zeros. Therefore he has solved the problem and provided the proof of work, even if one transaction of the block, that of A getting the 999 bitcoins, is fake.

In this situation, how can the validators detect this fraudolent action? The Pow is provided and solved, X has been the first to solve it. Why can't that block go straight into the chain?

Which piece of comprehension i am losing here?

thank you very much