Initial Coin Offerings (ICOs), MyEtherWallet, and EtherDelta

The ICO bubble seems to have become popular among crypto currency adopters in the last few months. We also went through some spectacular price action recently, with some crypto currencies losing 30%-50% of their value in a matter of days. Therefore, I thought to spend some time discussing the components that are being referenced in a number of online communities and the unnecessarily complicated paradigm some of them recommend.

Starting with MyEtherWallet: this has been my initial choice for a wallet to hold Ether. Part of the reason is that the Ether wallet application I ran once on my PC never managed to catch up with the public ledger, thus resulting in an unusable tool.

Also, MyEtherWallet is NOT an online wallet, plus the way it operates is very different from the way wallets work within conventional exchanges (such as Coinbase, Poloniex, Kraken, etc.). Let me expand on that and tell you why this is important.
Yes, MyEtherWallet happens to use Web technology (after all it is accessible as a Web page online) but it only requires the online infrastructure for transactions. In other words, you hold the private key of the wallet and nobody else holds it for you: If MyEtherWallet shuts down online services, you can use your keys in a different Ether wallet handler and you’re still in charge of your Ether and Erc20 tokens. Furthermore, and this is really important for transparency and fairness, when you transact Ether or Erc20 tokens with MyEtherWallet you are generating transactions on the Ether blockchain.
How is the above different from an online wallet available in conventional exchanges and why is it transparent and fair? Well, firstly with most other conventional online exchanges you do not own the private keys for your wallets: if you did you could, as example, transact outside of the exchange most of the time, thus avoiding the fees the exchange charges you, going with whoever else is cheaper at any given time or whoever has the best exchange ratio for the crypto currency couple you want to trade. Secondly, transactions within conventional exchanges do not generate blockchain transactions (you can verify this with a blockchain explorer, if in doubt): they use a pool of crypto currencies that the exchanges might have to acquire from the open market at some point. This means that if you buy e.g. a Bitcoin in a conventional online exchange, they don’t need to buy one on your behalf and you won’t need one to transact within the boundaries of the exchange itself. The only time the exchange allocates crypto currencies to users is when users transfer balances out, which generates a transaction on the blockchain: exchanges better have these currencies on the side line for when that happens or users will lose trust in them and avoid them.

Very much like fractional reserve banking, most conventional online exchanges know that not every account holder will withdraw their crypto currencies at the same time, so they only need to keep some on the side lines ready for when somebody transfers out. However, they have no obligation to have enough cryptos to cover the balance that all of its users hold with them.
Remember that crypto currency exchanges are NOT regulated by any financial authority (yet) and at times they wait to buy cryptos until these are cheap, so they also can sell them back to users for a profit: is it surprising that when prices fall and user’s buy demands raise exchanges cannot cope with that? It’s not just about volume: re-selling crypto currencies when their price is low is not convenient for exchanges, as that might mean selling at a net loss.
Essentially, their business model is along these lines: if they don’t annoy too many people they can stay afloat and make a profit with fees on transactions and reselling crypto currencies based on spread (and, possibly, at a premium). Part of such profits go towards ROI as they had to set up the exchange, recurring maintenance costs, etc.

Back to transparency and fairness, here’s my point: most conventional online exchanges can shut down without any notice and run away with the money because funding their wallets with fiat and participating in internal transactions are not recorded on the public ledger! They are not likely to run away as nobody wants to go through a class action, but remember it’s basically a trust relationship, with them working for profit. Things can also go wrong in case of hackers exploiting security vulnerabilities that might exist with some exchanges not so keen to roll-out updates and/or invest in security.

These are the two main reasons I personally do not trust exchanges and only use them for exchanging crypto currencies with other crypto currencies, based on price action. Once I am satisfied with the price action of the crypto currencies I hold there, I transfer them out to wallets for which I hold the private key. I then wait until the next price action to get back in the game.

Moving on to EtherDelta: this is currently my wallet and exchange of choice for Ether and Erc20 tokens that I have been investing during the early stages of the ICO mania. Much like MyEtherWallet, you own the private key of your wallet and you only need the online infrastructure for exchanging, depositing, and withdrawing Ether or ERC20 tokens. Also, unlike many conventional online exchanges, all transactions you make in EtherDelta, including moving funds from your wallet into the exchange account itself, generate transactions on the blockchain.

How do I know that EtherDelta provides me with a wallet that I am not forced to use just within their online exchange? Simple answer: I can use the private key that was generated when I created the EtherDelta profile in MyEtherWallet and transact from there.

When at the start of this post I mentioned an unnecessarily complicated paradigm I was referring to the fact that a number of crypto adopters suggest you always hold your Ether and Erc20 tokens in MyEtherWallet. They say you should only move them into EtherDelta to exchange them for other tokens or Ether, and finally move what you ended up with back into MyEtherWallet! This is not necessary and generates two extra transactions on the blockchain: the funding from your MyEtherWallet wallet to your EtherDelta wallet and the transfer out the other way around!
What you can do is to just create the EtherDelta wallet and keep your private key private. Any time you want to transact out of EtherDelta, such as funding an ICO, you open up your wallet in MyEtherWallet, using the mentioned private key, and transact there with your EtherDelta wallet address: in this way you can choose the amount of Gas to use, add additional data that certain ICOs require, etc.
What I encourage you doing is to NOT keep Ether and Erc20 tokens on the exchange: after your trading activities are over, simply deposit balances back into your EtherDelta wallet.

Let me state this once again: the EtherDelta wallet is fine for transacting outside of the exchange as long as you use it within MyEtherWallet to transact, which is where you have finer control over the details of transactions. What you cannot do is things like funding an ICO straight from your EtherDelta wallet within the exchange itself using the “transfer” option as you don’t seem to have fine control over the details of the transfer.
The reason this is possible is very simple: essentially a minimal wallet is a couple of keys, one private for authorizing transactions, and one public, an address for receiving/sending crypto currencies and tokens. The Ether wallets for which you hold the private key are all functionally identical once you activate them in MyEtherWallet.

Another reason for loading up your EtherDelta wallet in MyEtherWallet, and transacting from there, is that EtherDelta only shows three digits after the decimal dot for your balances. I am not sure whether this can be changed on the EtherDelta page or not, but if you want to see all decimals that you hold there, you are better off opening up the wallet in MyEtherWallet at present.

That’s it folks. Stay safe outta there with the ICO bubble reaching critical mass!

Posted in Cryptos, Security, Technical | Tagged , , , , , , , , , , , , | Leave a comment

Initial draft of the documentation about Palace Tape Loader F1

It’s an early draft, but I thought to share it nonetheless as the “Palace Tape Loader” uses a read bit routine that does not involve the use of timers!

You can have a peek at the loader’s code here.

Stay tuned for more information on this one, including heads-up about he original tape of “Barbarian 2”!

Posted in Retrocomputing, Technical | Tagged , , , , | Leave a comment

Even more maintenance work in TAPClean!

Over the course of the last few days I managed to fit a few changes/improvements in TAPClean:

  • I simplified the sync sequence matching logic in a number of scanners;
  • I modularised the Tx scan in “Mega-Save”, “Freeload Slowload”, “Alternative SW (DK)”, and “MSX Tape”;
  • I rewrote the “Freeload” scanner (finally!);
  • I added support for “Barbarian II” in “Palace Tape F1”.

All changes are now available in the code repo, tagged as “v0_36_pre_6”. Here’s what the first change looks like:

Simplification of the sync train matching code in TAPClean by Luigi Di Fraia

Simplification of the sync train matching code in TAPClean 0.36 preview 6

You can appreciate the above diffs to the “Tequila Sunrise” scanner by browsing the code repository here.

Finally I am looking for all tape images using either Palace F1/F2 as I might change these scanners significantly. It’s really something I am still pondering as the same sort of change was done for “Enigma” and I am not convinced of the real benefits.

Posted in Retrocomputing, Technical | Tagged , , , , , , | 2 Comments

More maintenance work in TAPClean!

I finally found the time to do some maintenance on TAPClean’s code as per my TODO list. In short, I consolidated “Ocean New F1” T1/T2  and “Snakeload 5.0” T1/T2 scanners into “Ocean New F1” and “Snakeload 5.0”, entirely rewritten.

The change on Snakeload also introduces a simpler sync sequence matching logic that I plan to roll-out to all other scanners. In both scanners I also implemented a modular approach to iterating across all supported Tx types that I shall roll out to other scanners too, including “Mega-Save”.

Stay tuned!

Posted in Retrocomputing, Technical | Tagged , , , , , , | Leave a comment

CHR scanner renamed and rewritten in TAPClean

Before bed today I decided to apply my field learnings about Mega-Save to the TAPClean scanner previously referred to as “CHR”, rewriting it from scratch.

One nice addition is the decoding of additional information that’s part of the file header and that was not documented so far (execution address and flags).
Here’s what TAPClean’s report looks like for Cauldron’s last file:

Seq. no.: 11
File Type: MEGA-SAVE T1
Location: $6DC6E -> $6EE46 -> $7ECDE -> $7ECE5
LA: $E000 EA: $FFC8 SZ: 8137
Pilot/Trailer Size: 158/0
Checkbyte Actual/Expected: $72/$72, PASS
Read Errors: 0
Unoptimized Pulses: 0
CRC32: 2E17E752
 - Pre-pilot byte count : 256
 - Re-execute loader : No
 - Execution by : JMP $800A (SYS 32778)

For Kettle’s last file we have:

Seq. no.: 7
File Type: MEGA-SAVE T2
Location: $B006 -> $C1DE -> $50676 -> $5067D
LA: $0801 EA: $9089 SZ: 34953
Pilot/Trailer Size: 158/0
Checkbyte Actual/Expected: $84/$84, PASS
Read Errors: 0
Unoptimized Pulses: 0
CRC32: D9DB8B7A
 - Pre-pilot byte count : 256
 - Re-execute loader : No
 - Execution by : BASIC RUN

The change is available in version 0.36-pre2 of TAPClean. I will make it available in binary form at some point after some more testing is done.

Happy days 🙂

Posted in Retrocomputing, Technical | Tagged , , , , , , | Leave a comment

Planning another TAPClean release

I decided that the significant changes to the Visiload scanner (which Paul Jones has helped to test thoroughly), along with the addition of two Visiload Tx variants, the rewrite of the Wildload scanner and a fix to the Pavloda scanner are worth publishing release 0.35 of TAPClean.

I shall therefore push the following changes into release 0.36:

  • partial support for CRL loader
  • support for adjustable pulse durations
  • implementation of a few recommendations and loader renaming as per TODO list

Stay tuned!

Posted in Retrocomputing, Technical | Tagged , , , , | Leave a comment

More on the tape loader documentation effort!

If you’ve not had a look at my documentation of the loader written by the Mega-Save tool, which was announced here, you might want to have a look now and provide some feedback!

Since the initial publishing of the information about the loader I’ve made quite a few significant changes, including:

  • enabling syntax highlighting for the code
  • making the code downloadable
  • providing instructions on how to rebuild the loader

Here’s the link again 🙂

The only thing I’d like to research further about DokuWiki is whether I can provide syntax highlighting specific for 64tass instead of having to use a built-in one, 6502tasm.

Posted in Retrocomputing, Technical | Tagged , , , , | Leave a comment