Hot answers tagged


Because values of type lambda can be kept in storage or passed as parameters (either as lambda or as bytes to be UNPACKed), it is possible to write contracts which can upgrade themselves... This won't always make sense, but might sometimes be useful. For example, one of the very early mainnet contracts appears to have a kind of upgrade mechanism: https://...


Disclaimer: This is just an example for educational purposes, don't use it in production. Here is a fairly primitive upgradable design for a Liquidity smart contract: Proxy Contract Holds the state / storage Points to a Logic Contract, and proxies its entry points Can be amended / upgraded, by its rightful owner. You can run into decentralization / ...


There are three main considerations at play 1) it's a way to augment proof of stake consensus with a form of TAPOS. While transactions are not used as a chain selection rule, they do leave a forensic trail that can be used to differentiate between the real chain and fakes. How valuable this is depends on how paranoid you are about weak subjectivity. 2) ...


The idea is just that, when you create a transaction, you might have expectations on what already happened on the network. Including a transaction hash prevents including the transaction in a fork where these expectations are not correct (some former transactions didn't happen). Note that you can include a transaction in the 64 blocks after the hash, so it ...


Cryptonomic published an article on exactly this topic recently.


From the white paper, "If an attacker ever succeeds in forcing a long reorganization with a fork, he will be unable to include such transactions, making the fork obviously fake. This is a last line of defense, TAPOS is a great system to prevent long reorganizations but not a very good system to prevent short term double spending."

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