Jump to content
Main menu
Main menu
move to sidebar
hide
Navigation
Main page
Recent changes
Random page
Help about MediaWiki
Matthews Lab
Search
Search
Appearance
Log in
Personal tools
Log in
Pages for logged out editors
learn more
Contributions
Talk
Editing
Coin archiving
(section)
Page
Discussion
British English
Read
Edit
Edit source
View history
Tools
Tools
move to sidebar
hide
Actions
Read
Edit
Edit source
View history
General
What links here
Related changes
Special pages
Page information
Appearance
move to sidebar
hide
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
= Some cool use-cases = <span id="use-case-1-preserving-cryptoeconomic-history"></span> == Use-case 1: Preserving cryptoeconomic history == Archiving old blockchains on Ethereum is highly useful from an economic perspective and might even be a new profession in the future. There could be cryptoeconomic historians whose job it was to preserve old blockchains on top of Ethereum to allow for future study by cryptoeconomists looking to understand the impact of early cryptoeconomic experiments on top of older blockchains. <span id="use-case-2-breathing-new-life-into-old-blockchains"></span> == Use-case 2: Breathing new life into old blockchains == There have been hundreds of blockchains forked from Bitcoin that achieved significant valuations over very short periods before fading into obscurity. Many of these blockchains had economic activity occur on them but are no longer functional or secure because its unprofitable to mine them. By recreating these coins on top of Ethereum as highly realistic simulations with virtual mining rules we allow them to function again as currencies - old blockchain assets are put back into circulation. <span id="use-case-3-decentralized-friggin-exchange"></span> == Use-case 3: Decentralized friggin’ exchange == By “scanning” in old blockchain assets on top of Ethereum we can create a situation where it becomes possible to directly link these new blockchains such that coins can be traded on a decentralized exchange. Technically this is already possible to do with Bitcoin-style blockchains but it is worth noting this can be done very elegantly on Ethereum. Technical note 1: the exchange would still need to be coded using atomic cross-chain contracts because using the Ethereum-layer to do this would create incompatibility between older-blockchains. Technical note 2: soft-forking to add CLTV is now trivial if they are virtual Ethereum assets - cool, right? <span id="use-case-4-new-wallet-support"></span> == Use-case 4: New wallet support == Because said older assets would all exist on Ethereum as virtual coins respecting their original rules - we can also add support for ERC-20. Imagine being able to use 100s of different older blockchain assets with your favorite Ethereum wallets today. It’s like you’re also benefiting from the entire ecosystem with this approach, so many of these coins would be significantly more usable. <span id="use-case-5-hard-forking-away-from-drama"></span> == Use-case 5: Hard-forking away from drama == Occasionally teams in the blockchain space experience a dead-lock where nobody can agree on the exact technical vision going forwards. In this case, if we scan in a blockchain into Ethereum it provides the market a simple mechanism for hard forking away from the original currency. It is possible to provide full backwards compatibility with the original currency. In this case, virtual transactions that occur on Ethereum would be made 100% compatible with transactions occurring on the real asset. You would then have logic to detect whether a transaction first occurred on the Ethereum “fork” or on the real asset and after a certain period of economic activity on the Ethereum fork you can stop requiring this backwards compatibility - in which case its a hard-fork. This would probably require adding some kind of settlement phase to the virtual coin and allow SPV-proofs to be given from the real asset. You would also have to keep the virtual coin in-sync with all transactions and block header activity happening on the real asset so its potentially a burden. <span id="use-case-6-smart-contracts-support"></span> == Use-case 6: Smart contracts support == It becomes possible to write smart contracts in this system that will work with all of these assets. This could be done in several different ways - the simplest of which is simply to allow the virtual mining layer to have programmable rules added by users for transaction inclusion. From a compatibility perspective, you are not violating any of the original protocol rules. It simply looks like “miners” have trustlessly colluded to enforce smart contracts in every possible case on behalf of the users programmable rules (a weird idea, honestly.) Seriously, proof-of-work allows this. Programmable virtual mining would also allow for Lightning to be added to every older-style blockchain at once. It’s like programming a soft fork as a hard fork but its still a… Mind = blown Anyway, this is still a hard fork though so its probably a bad idea. <span id="use-case-7-elegant-soft-forks"></span> == Use-case 7: Elegant soft-forks == If we define Script as the underlying primitive that gives all these coins their “smart contract” capabilities then Ethereum makes it incredibly, incredibly simple to add new functionality to these coins that is backwards-compatible. As an example: enable some of Satoshi’s disabled OP_CODES Or perhaps: add CLTV support to every asset? Or how about adding in new logic entirely? It’s Ethereum, it already allows for complex transactions so this is an incredibly elegant way to add new functionality to these older-style blockchains. By the way: all of the work in Bitcoin designed to avoid hard forks now becomes a huge benefit here as the work can be used to add support to hundreds of assets for new technical features without breaking older transactional protocols (or old-school software) :) <span id="technical-thoughts-on-implementation"></span>
Summary:
Please note that all contributions to Matthews Lab may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see
Matthews Lab:Copyrights
for details).
Do not submit copyrighted work without permission!
Cancel
Editing help
(opens in new window)