Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Oct 10 2017 22:42
    @jpitts banned @etherchamp1_twitter
  • Jun 05 2016 10:33
    @chriseth banned @adamskee
Daniel
@DanielRX
What is the warning...?
Julian Sauer
@notorious-clay
browser/Payment.sol:5:29: Warning: This looks like an address but has an invalid checksum. If this is not used as an address, please prepend '00'. Correct checksummed address: '0xca35b7d915458ef540ade6068dfe2f44e8fa733c.'
area
@area
pragma solidity ^0.4.21;
pragma experimental ABIEncoderV2;

contract NestedArrays {

    function test1(uint256[][3] u) returns (uint256 x){
        x = u[0][0] + u[1][0] + u[2][0];
    }

}
The above compiles, but I am unable to get it working correctly, either in remix or with a truffle test. When I run in remix, and pass something like [[1],[2,3],[4,5]] the transaction reverts and the 'decoded input' is very clearly wrong. A function declared with uint256[3][] works as expected, but that's not what I want (i.e. I want to pass an array containing three variable length arrays, not an array containing a variable number of arrays with length three). Is such a function parameter not properly supported, even though it compiles?
Jim McDonald
@mcdee
@notorious-clay Solidity expects addresses to conform to EIP-55 checksumming. In your case that address should be listed as 0xCA35b7d915458EF540aDe6068dFe2F44E8fa733c (note some upper-case letters)
@notorious-clay you might also want to consider updating your version of Solidity to one more recent, as it will show the correct error message and checksummed version of the address
Daniel
@DanielRX
@mcdee he did post the error message which listed the address but seems it failed to checksum it
(he used remix which may be why)
phalexo
@phalexo
Has ERC223 been accepted as a "standard"? Or is it still in the air? Thanks.
facundomedica
@facundomedica
Its status is "draft", it should be "accepted" to be a standard
Julian Sauer
@notorious-clay
thanks @mcdee
what is the latest version of solidity?
facundomedica
@facundomedica
@notorious-clay 0.4.21
ethernian
@ethernian

hello guys,
I have just constructed and successfully executed a token transfer transaction with extra data behind the message call (check extra 8888 added at the end of tx payload).
https://etherscan.io/tx/0xac41ca71ce075d7efb031433b205f99382cd63532de684b4437a23096b242c74

It seems working, but the question is: is it specified in solidity or it can change any time?
It is could be interesting as the base for stealth token transaction in ethereum

Daniel
@DanielRX
Is it possible for the bytecode for a contract to differ on etherchain and etherscan?
Jim McDonald
@mcdee
@DanielMReed possibly, if there are bugs in either website. Going to the chain direct is the only way to obtain bytecode without trusting a third party
Daniel
@DanielRX
@mcdee wanna take a look in /remix and see if you can work it out? I copied the etherchain source over and it just fails
phalexo
@phalexo
What would be the pitfalls of using ERC223 draft implementation at this time? Any thoughts? Thanks.
Jim McDonald
@mcdee
@phalexo i don't use remix so wouldn't know
Daniel
@DanielRX
It's an etherscan/etherchain issue I mean
Jim McDonald
@mcdee
@phalexo it's not a standard and there are enough competing (better) standards out there that at this stage it's unlikely to win mass adoption
phalexo
@phalexo
Thanks. Same question about other "standards" then, besides ERC20?
Jim McDonald
@mcdee
@phalexo they're all up in the air. My favourite is 777 but they're debating registry implementations at the moment (and honestly I'd prefer it if solidity devs could stop equating "not succeeding" with "reverting" as it would open new possibilities). If I had to build something today I'd build an ERC20 token with a separate token store and the ability to upgrade to another token standard when it's ready
@DanielMReed like I say, check out the bytecode on the blockchain and see which site matches
Daniel
@DanielRX
It's the verification that is failing, seems the bytecode is the same but the opcodes vary is all for that side
Jim McDonald
@mcdee
@DanielMReed Verification is very dependent on solidity version, optimisation and unfortunately bugs in the way that referenced code is imported. If you are pulling in any imports from outside of your immediate tree that might be part of the problem
phalexo
@phalexo
@mcdee The tricky part about upgrading one standard to another is what happens with data stored in state variables, and whether the storage structure changes. If a new standard 's changes are "orthogonal" to the old one it should be relatively easy.
Jim McDonald
@mcdee

@phalexo with most of the proposed standards the changes are orthogonal, yes. Anything that isn't you could plan for in advance if you think that it's at all a likely outcome.

In my ERC-20 contracts I have a separate storage contract for token balances but allowances are in the ERC-20 contract. If I upgrade to a contract without allowances (or without the same way of doing allowances) I can just drop the existing ones with the old contract and set something new up on the new contract. Plus, there's no reason why you couldn't leave the ERC-20 contract in place and have multiple contracts access the same token store

Daniel
@DanielRX
@mcdee See I know that, but none of those apply, the source is open, 0 imports, same version, same optim
Jim McDonald
@mcdee
@DanielMReed try compiling locally and checking the bytecode perhaps?
Jasvir Singh Grewal
@jasvir99
hi there. I was looking on qtum erc20 token and observed some strange addresses. https://etherscan.io/token/0x9a642d6b3368ddc662CA244bAdf32cDA716005BC#balances
can anyone please explain me, what are those?
Jim McDonald
@mcdee
@jasvir99 given that the contract doesn't list those as special cases I'd guess they were burn addresses (or programming mistakes)
Daniel
@DanielRX
Looks like burn (0x22222... 0x33333.... etc)
But aren't burns meant to transfer to 0x0?
ethernian
@ethernian
@DanielMReed: originally token "burning" is just reducing an account's balance without increasing some other account's balance. Transfer to "burning" addresses (i.e. without known private key) has the same effect, assuming the token are locked there forever.
Natali
@natyscode
Hi all ! What would be the best way to handle an array in solidity with such structure: ["val1":X, "val2":Y, "val3":Z]?
lukas-berlin
@lukas-berlin
@dip239 thats not correct. Burning also adjusts totalSupply. sending to unspendable address doesn´t
ethernian
@ethernian
lukas-berlin: is there any standard for burning tokens?
ethernian
@ethernian
I mean, burning is a nonstandard ERC20 extension anyway and totalSupply adjustments can be implementation dependent.
Personally, I would maintain tokenSupply and tokenInCirculation separately. Pls. correct me if I am wrong.
Jim McDonald
@mcdee
@dip239 if you send tokens to a burn address you should keep totalsupply the same. If you destroy them you should reduce totalsupply. Basically, the sum of all holdings should equal totalsupply
cheetah1295
@cheetah1295

Hi guys, I have a serious problem when using Remix IDE. I use Javascript VM to test my code . when I use an account to test it the address of the account is not the same as msg.sender
My code is about organising an election and for this function:

function presentyourself(address a){
require(addvoters[msg.sender].adr == a);
candidates[addvoters[msg.sender].index].cur = true;}

addvoters is a mapping : mapping (address => Voter) public addvoters;
and Voter is the structure representing a voter
cur is a boolean indicating if he presented himself as candidate or not

I need the msg.sender to be the same as the address of the account ( for more security) but it is not the case... any thoughts ?

_

Jim McDonald
@mcdee

the address of the account is not the same as msg.sender

Not sure what this means. The address of the account that sends the transaction is msg.sender, by definition (unless you are calling one contract from another, but I doubt that you're doing that)

cheetah1295
@cheetah1295

image.png

I'm simulating the elction by trying multiple accounts ( which play the role of the voters )

My code continues here
image.png
Jim McDonald
@mcdee
What is a in presentyourself()?
cheetah1295
@cheetah1295
It is a variable representing an address
Jim McDonald
@mcdee
But what does the address represent?
cheetah1295
@cheetah1295
It is supposed to represent the adress of a voter who wants to present himself as a candidate
Let me explain in more details :
When the owner has authorized a voter ( by authorizing his address) I can change the account ( at the right) to simulate the fact that this authorized voter wants to present himself as a candidate, so the account (linked to the authorized voter) will execute the function presentyourself in order to present himself as candidate at the election
Jim McDonald
@mcdee

the adress of a voter who wants to present himself as a candidate...so the account (linked to the authorized voter) will execute the function presentyourself...

Surely that should be msg.sender then rather than an (arbitrary) function parameter