1

Let's say I am on a private net, with control over 50% of the hashpower, is there a way to cancel a block ? Could I get rid of a transaction ? If yes, how quickly would this "cancelation" take to propagate. Would it not be best to instead of cancelling a block, write an another block that would invalidate the first one ?

Thanks

3

Yes, but, I would give some thought to what we're doing and why we're doing it. There's a bit of circular logic here and it runs into conflicting objectives.

In theory, you could rewrite history with a 51% attack against your own chain and that would possibly be relatively easy in a private chain scenario where you control a majority of the miners.

The question that arises is this. If your goal is to reserve for yourself the possible of rewriting history, why use an append-only blockchain? Why not use a database with replicas and overwrite capability? The latter is well-solved and would probably be less trouble. Reserving this re-write capability would bring the authenticity of the private chain into doubt in any case in my opinion .

In other words, in my opinion it's not possible to engineer things such that a rewrite of history is probable and also retain the unique benefits of an immutable blockchain. These are conflicting objectives.

Maybe consider a contract design that can amend stored values in a forward-only auditable way.

Hope it helps.

p.s. It would happen as fast as you can splice a new block at the fork point and your miners a new longest chain.

1

Let's say you have a 2 node network: Node A mines at 1 Unit/s, and Node B mines at 2 Units/sec.

Node B can always mine more than node A, therefore if B wants to invalidate a block he sync to right before the one he wants to get rid of. B can then mine empty blocks (or mirror the transactions without a particular one they want to erase) until he catches up to A.

The next time B makes a block, Node A will see that there is a longer chain available and switch to B's chain without the transaction in it.

1

That is what I though, so lets take a scenario of lets say a bank transfer, and the transfert is fraudulent, we therefore want to cancel it. It would be better practice to create a smart contract for the transaction that has a "valid" field and change it to a false, this would therefore invalidate the transaction, rather then completely erasing the said transaction.

  • 1
    Sounds about right. Setting aside precise design details, if you think in terms of double-entry accounting and a prohibition on pencil-eraser, then a fraud could possibly be resolved with another entry. Recovery of losses is another matter. These concerns are generally addressed with collateral (or similar) and governance codified in a Smart Contract. – Rob Hitchens - B9lab Apr 13 '17 at 14:44
1

Further to the other comments. Yes you can by resetting the latest block to an earlier block and mining from there. However what you have done is create your own fork and all transactions on the original chain will be lost and would need to be replayed.

  • Ok, so every transaction that would have been done after the "fraudulent" blocked was mined would be cancelled. The best way still remains to design contracts in a way that they could be "invalidated" – Rémi Apr 14 '17 at 1:30
  • 1
    This would only be a valid strategy if your contracts controlled the total pool of value. Any value that leaves you contract (such as ether) cannot be declared 'invalid' in any sensible way. So for a token contract (which does control the entire value pool), you need only write a revert function and correctly permission its use. However, it's kind of missing the 'trustless' philosophy of Ethereum in which a 'proof' architecture is preferred so such revisions aren't necessary. An example is an automated escrow which pays out or reverts based on some future condition or proof. – o0ragman0o Apr 14 '17 at 1:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.