Important: We will not request anything from your side. Any e-mail, website, etc. asking you to do something for the re-airdrop is fake. Remember, you do not have to do anything, just wait for your OMG to arrive. If anyone reaches out and asks you for information to participate in the OMG airdrop they are trying to scam you. If you come across any potential scams or other malicious behavior regarding this airdrop please notify us via contact@golem.network.

We will use the distribution of GNT from block 4269226 (13–07–2017 10:46:05 UTC), which is the block when a portion of OMG was transferred to Golem’s multisig. The amount for re-airdrop is 29,303.67 OMG. Here is an overview of the process and what you need to know going forward:

• Golem is going to redistribute OMG tokens sent to Golem multisig wallet 0x7da82C7AB4771ff031b66538D2fB9b0B047f6CF9 in the OMG airdrop.
• Golem received OMG tokens in the transaction 0xa9cd19cdb0f7a7ba4ffa56950bb961f1efa50eb40a6d7441b10047f658d9e51f in block 4269226.
• The distribution of OMG tokens available in Golem’s multisig to GNT holders has been calculated according to GNT balances in the same block 4269226.
• Addresses of wallets owned by Golem and Golem team have been filtered out and will not receive any OMG.
• The minimum GNT balance required to receive any OMG was ~ 25633 GNT. Holders with this amount will receive just above 1 OMG.
• 1547 GNT addresses meet the requirements for the re-airdrop.
• If you held more than 25633 GNT at the time of the block your allotment will be proportional to your holding.
• The transfers are going to be executed in 30 batch transactions of 50 using a helper contract.

Reminder: you are responsible for your own security. Avoid phishing traps by sticking to official sources.

Re-airdrop of OMG tokens was originally published in The Golem Project on Medium, where people are continuing the conversation by highlighting and responding to this story.

The bug was indeed the exchange’s fault, but it was also related to the way Ethereum contracts see the transaction input data and Solidity ABI (e.g. the way the methods of Solidity contracts encode and decode arguments). So of course it was not specific to GNT, but indeed to all ERC20 tokens, as well as other contracts which have transfer-like methods. Yes you read it right: this could potentially work for any Ethereum-based token listed on said exchange, if only withdrawals were managed in the same way as GNT. We do not know this to be the case, but assume it was very likely.

Ethereum Contract ABI

Raw Ethereum contracts have neither methods nor functions. Methods are features of high level languages like Solidity, and they use the Ethereum Contract ABI to specify how a contract’s bytecode is divided into methods, as well as how different types of arguments are encoded in transaction input data. (See https://github.com/ethereum/wiki/wiki/Ethereum-Contract-ABI for a reference.)

To invoke the transfer(address a, uint v) method of the GNT contract to transfer 1 GNT to address 0xabcabcabcabcabcabcabcabcabcabcabcabcabca one needs to include 3 pieces of data:

• 4 bytes, being the method id: a9059cbb
• 32 bytes, with the destination address (20 bytes) filled with leading zeros: 000000000000000000000000abcabcabcabcabcabcabcabcabcabcabcabcabca
• 32 bytes, being the value to transfer, 1 * 10¹⁸ GNT: 0000000000000000000000000000000000000000000000000de0b6b3a7640000

The full transaction would therefore look like this: a9059cbb000000000000000000000000abcabcabcabcabcabcabcabcabcabcabcabcabca0000000000000000000000000000000000000000000000000de0b6b3a7640000.

Transaction input data is infinite

This is one of the messier aspects of the Ethereum Virtual Machine, but it is critical to understanding the issue fully. The EVM can read bytes of any given input data offset using CALLDATALOADopcode. If the data in this offset is not provided in the transaction by the transaction creator, the EVM will get zeros as the answer. At the same time, the contract is able to check the real length of the provided transaction input data with the CALLDATASIZE opcode.

The bug

The service preparing the data for token transfers assumed that users will input 20-byte long addresses, but the length of the addresses was not actually checked. In the aforementioned transaction, the user filled in an invalid address of a shorter length: 79735. The resulting data was malformed because the address argument took 14.5 bytes (12 bytes for leading zeros + 4.5 bytes from user input). To be precise, the transaction data was fine for the Ethereum platform as it does not care about data included in the transactions except applying fee for every byte. The only reason why the token transfer was not executed by the GNT contract was that the amount in the transaction was ridiculously high (higher than the total supply, and of course higher than the balance of the address in question). The owner of the address was really quite lucky in that the user used such a short string for the address: with some (bad) luck, the user would be able to *incidentally* empty the address of all GNT and send them to some random address. This is when we realized that bug could also be used for attack, and was very serious.

The possible attack

As you may have noticed, allowing a user to input a shorter transfer address shifts the “amount of tokens to transfer” value to the left, making the value larger. It is also very easy to find a private key to an Ethereum address with zeros in the end of the address, e.g. 0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa0000.

Therefore, the owner of this address can enter 0xaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa (skipping zeros) in the service interface. The attacker could then order a transfer of some value X from the service, to the inserted malformed address. This would actually cause a transfer of a value shifted by 16 bits, i.e. 65536 times larger than X, to attacker’s Ethereum account!

What we have done about it?

Once identifying the possible attack, we contacted the exchange and informed them about the bug. That was a surprisingly difficult and annoying process; our CEO Julian had a call with a support line whose representative didn’t want to listen, and continued shouting that bugs are not his business, and was refusing to redirect us further up in the chain of command. Eventually however, after couple of hours of this, Alex managed to put us through to the CEO level, and our message went through. Once we heard confirmation that bug was fixed, we reached out to other exchanges. While we had no reason to assume that they were vulnerable, we also had no reason to assume the opposite. While we have to admit that we have not tested that for other exchanges or other tokens, we were shocked and a little bit terrified to realize the potential consequences of someone taking advantage of that bug for multiple tokens on multiple exchanges: The entire Ethereum token economy and startup ecosystem might be set back by years.

What can Ethereum do about this?

While I don’t think the Ethereum developers can do much more than continuing to educate the public about how the Ethereum actually works, we might suggest additional checks added in the future versions of Solidity, for example validating that the transaction input data length matches the expected data for the given contract method.

What should exchanges absolutely do about this?

1. Verify user input as strictly as possible. Simply checking the length of an address provided by a user secures them from the described attack. Moreover, validate the Ethereum address checksum if available (see EIP55), or even accept addresses exclusively with checksums. This both increases both security and user-friendliness.
2. Make sure that transaction data is properly encoded.
3. The generated transaction data might be also parsed back and checked against given user input.
4. Check if other parameters like gas, gas price, and the destination address of the generated transaction matches the expected values.

How to Find $10M Just by Reading the Blockchain was originally published in The Golem Project on Medium, where people are continuing the conversation by highlighting and responding to this story.

Ethereum project is more than smart contracts

Ethereum is all about a new cryptocurrency, smart contracts, the world computer, right? That is just the first piece of the puzzle. It is probably the biggest, the most famous and the most advanced system in comparison to anything else out there. But people behind the Ethereum project have also designed and created other peer-to-peer solutions and technologies:

• Ethereum is powered by the Cryptographic Network & Transport Protocol RLPx, also known as ÐΞVp2p after the names of its implementing software libraries. It is just one of the RLPx subprotocols. What about creating a P2P protocol for your application? Why not base it on RLPx/ÐΞVp2p?
• Whisper is a communications protocol designed for internal use by decentralized applications. It allows peers to exchange and broadcast encrypted messages within the same network. Ethereum does not interfere with the blockchain and messages are delivered free of charge.
• Swarm is a distributed storage platform and a content distribution service — yet another network protocol based on RLPx. This is a platform where applications can store their resources. We think about using such a platform for Golem to distribute resources needed for computing tasks.

Moreover, the Ethereum components are available in many programming languages, including Go, C++, Rust, Python, JavaScript. This is quite impressive considering the complexity of the project and the fact that it has been launched today. This is also great news for startup projects that aim at preparing prototypes in short time cycles.

So, Ethereum is not only a breakthrough for the blockchain technology. It also creates a great environment and vibrant community for us, who are very much inside the new P2P Internet. It is a great source of software components, protocol designs or inspirations. So why do we need Ethereum in the Golem Project?

Highly extensible solution for payments

The Golem Network requires a reliable payment system to automatically transfer value between network peers. At the end, a peer should get a reward for computing done on behalf of others. The Golem Network is a peer-to-peer network, so the payment system must be decentralized as well. The blockchain-based technologies are natural candidates. So why is it Ethereum that we chose among other solutions?

The value of a single payment processed by the Golem Network is very low. We call them nanopayments. However, the problem with nanopayments is that transaction fees have to be even smaller. Ethereum allowed us to design a payment scheme where smart contracts act as an intermediary: we optimized the costs of the payment system by using the Bank of Deposit smart contract as the central payment proxy. This solution aggregates payments and sends them as a single Ethereum transfer to save on fees. It is nothing new, nor very “smart”; it is usually referred to as transaction batching. E.g. the cost of 10 payments processed in a single transaction is half of 10 payments processed in 10 transactions. And the lower the fee, the more payments you are able to aggregate.

Transaction batching makes Golem feasible for our initial use cases at the present costs of gas. But this is just the beginning: we decreased the transaction cost even further by introducing a probabilistic payment scheme. See A Probabilistic Nanopayment Scheme for Golem for more details.

Apart from lower transaction costs, the central contract, which proxies all payments, opens up a number of opportunities, like imposing (voluntary or obligatory) fees on transactions within the Golem Network; or introducing escrow-like solutions for improved security; or compensation for the use of third-party software in the software-as-a-service model, where the Golem Network serves as a platform-as-a-service. Especially the latter opens up a broad spectrum of business applications that can be used in the Golem Network. So it does not only compete with cloud providers, but can serve as a distribution channel for software developers — both in a proprietary and an open source model.

So, are you frustrated that you can only buy DAO tokens with your Ethers? Worry no more, soon you will be able to buy much more using Golem!

Why Ethereum? was originally published in The Golem Project on Medium, where people are continuing the conversation by highlighting and responding to this story.