wait for the news!!
wait for update
Topic: [ANN] TIMEREUM (TME) VERSION 2.0: "ELIXIR" (ELIX) RELEASED (NEW THREAD) - page 126. (Read 126691 times)
July 14, 2017, 12:33:37 PM
July 14, 2017, 12:00:48 PM
Yeah.
@dev:
take it easy. We can wait more.
Go have a beer or something tonight
@dev:
take it easy. We can wait more.
Go have a beer or something tonight
July 14, 2017, 11:53:56 AM
So Timereum going to live soon.
This must be a good news to all of us.
This must be a good news to all of us.
July 14, 2017, 11:48:15 AM
@nagatraju No need to depend on anybody. The person you'd be paired with could die today and you'd be able to generate your coins anytime.
minereum_investor1 It might be in everyone's interest to get a few coins circulating. By increasing circulation the value of the non-circulated coins will actually go up.
minereum_investor1 It might be in everyone's interest to get a few coins circulating. By increasing circulation the value of the non-circulated coins will actually go up.
One more question, getting a few coins circulating at the beginning of the smart contract deployment means that some persons will not be able to get the theoretical max supply per address pair as there are only 10 batches to create. Am I wrong ?
July 14, 2017, 11:40:47 AM
Quote
@nagatraju No need to depend on anybody. And the other half of the list can be used as a set of genesis addresses for a future installment of this project.
In this case go with the Deployment of the Smart Contract.
All the best to You, Me and all Airdrop Participants.
July 14, 2017, 11:37:39 AM
@nagatraju No need to depend on anybody. The person you'd be paired with could die today and you'd be able to generate your coins anytime.
minereum_investor1 It might be in everyone's interest to get a few coins circulating. By increasing circulation the value of the non-circulated coins will actually go up.
minereum_investor1 It might be in everyone's interest to get a few coins circulating. By increasing circulation the value of the non-circulated coins will actually go up.
July 14, 2017, 11:35:45 AM
"Another benefit is the unused address set could be used as a base for another token later on related to timereum."
I would do this the other way around.
After some time when miners are known in the community, they can pair themselves when they feel like it.
Instead of, in this early stage, getting paired with someone you dont know.
Its like asking me to agree to see just the next guy (or worse; an Australian) jerk off while I ram my keyboard
I would do this the other way around.
After some time when miners are known in the community, they can pair themselves when they feel like it.
Instead of, in this early stage, getting paired with someone you dont know.
Its like asking me to agree to see just the next guy (or worse; an Australian) jerk off while I ram my keyboard
July 14, 2017, 11:32:27 AM
Ok nice to read it 
.
This detail put aside, does that mean if all of the child-address holders don't want to create a batch until next year, the mining process will not start as long as they hold their coins ?
Thanks dev
.This detail put aside, does that mean if all of the child-address holders don't want to create a batch until next year, the mining process will not start as long as they hold their coins ?
Thanks dev
July 14, 2017, 11:30:18 AM
@minereum_investor1 You wouldn't give your batches to anyone. They still spawn in your address.
Can you explain it clearly?
So no need to depend on another person/pairing address!!?
July 14, 2017, 11:26:43 AM
It does not make 50% of the genesis addresses "useless." You're paired with someone else, and someone else is paired with you.
Since you'd have to keep track of who the parent address of your child is anyway, it isn't really very different from the first model. You don't "depend" on another person to get your coins.
It also works from a coding standpoint.
Another benefit is the unused address set could be used as a base for another token later on related to timereum.
I am definitely open to feedback, and I appreciate your opinions. Again, it's only experimental and splitting it up into multiple contracts is easily doable.
What if the person you are paired with loses his key, or gets hit by an Abrahamic hammer while vacationing in Syria and becomes hardcore muslim or just a friendly terrorist helping the good old fight against Assad and sees computers are the devil's playground and stops everything?Since you'd have to keep track of who the parent address of your child is anyway, it isn't really very different from the first model. You don't "depend" on another person to get your coins.
It also works from a coding standpoint.
Another benefit is the unused address set could be used as a base for another token later on related to timereum.
I am definitely open to feedback, and I appreciate your opinions. Again, it's only experimental and splitting it up into multiple contracts is easily doable.
What then?
July 14, 2017, 11:26:05 AM
@minereum_investor1 You wouldn't give your batches to anyone. They still spawn in your address.
July 14, 2017, 11:23:23 AM
Thanks for replying quickly dev 
The idea of being paired with another person seems scary as it implies to give our coin batch to the one who owns the parent address right ? I am possibly wrong and I would like to get an enlightenment on this please.
Also, you dev should take a look at this advice from Nagatraju regarding the coding issues :
"Simplify the contract. This might be impossible, depending on what exactly you're doing.
Split it into multiple contracts.
Refactor it to use libraries. If you're using lots of structs and mappings, this may make your code remarkably more readable."
Thank you dev.
The idea of being paired with another person seems scary as it implies to give our coin batch to the one who owns the parent address right ? I am possibly wrong and I would like to get an enlightenment on this please.
Also, you dev should take a look at this advice from Nagatraju regarding the coding issues :
"Simplify the contract. This might be impossible, depending on what exactly you're doing.
Split it into multiple contracts.
Refactor it to use libraries. If you're using lots of structs and mappings, this may make your code remarkably more readable."
Thank you dev.
July 14, 2017, 11:22:49 AM
Why don't you try these with your existing code:
- Continue to refactor into libraries. This is the #1 way to reduce the bytecode size of the main contract.
- Use shorter types for struct elements and sort them such that short types are grouped together. Started doing this and it makes a massive difference even if the code is not as readable or clean looking.
- Move duplicate functionality into generic functions or function modifiers (even if it means more function parameters).
- Instead of creating multiple getters (or multiple public members), create bundled getters that return multiple values at once.
- Use local variables to reference storage array elements.
- Remove some constant functions that are not critical to the contract.
July 14, 2017, 11:21:21 AM
@nagatraju You send 10^-18 timereum to them, and a batch of your coins spawn in your address. In the future this might be a more efficient way.
what is 10^-18 timereum ?! July 14, 2017, 11:15:50 AM
@nagatraju You send 10^-18 timereum to them, and a batch of your coins spawn in your address. In the future this might be a more efficient way.
July 14, 2017, 11:12:56 AM
"You're paired with someone else, and someone else is paired with you." That means I send my batch of coins to another person's (paired) address. And I need to get those coins from him, if I want to sell. Am I right?
July 14, 2017, 11:04:51 AM
It does not make 50% of the genesis addresses "useless." You're paired with someone else, and someone else is paired with you.
Since you'd have to keep track of who the parent address of your child is anyway, it isn't really very different from the first model. You don't "depend" on another person to get your coins.
It also works from a coding standpoint.
Another benefit is the unused address set could be used as a base for another token later on related to timereum.
I am definitely open to feedback, and I appreciate your opinions. Again, it's only experimental and splitting it up into multiple contracts is easily doable.
Since you'd have to keep track of who the parent address of your child is anyway, it isn't really very different from the first model. You don't "depend" on another person to get your coins.
It also works from a coding standpoint.
Another benefit is the unused address set could be used as a base for another token later on related to timereum.
I am definitely open to feedback, and I appreciate your opinions. Again, it's only experimental and splitting it up into multiple contracts is easily doable.
July 14, 2017, 11:04:07 AM
@JustMissed Exactly. We're working on reducing bytecode.
I realized I can cut bytecode in half by pairing one of every person's addresses with one of another person's addresses, so I have a new contract I've written up that does that. You'd only have to transfer 10^-17 timereum out from the 1 timereum you get on launch to the other person who is your parent address to get all your batches, and you'll get it back when the person you're paired with deploys their coins. The whole manual generation works in the same way, it's just a way to cut bytecode. We wouldn't need one set of addresses anymore, but we could keep the remaining unused list for a future installment of this project, or alternatively get rid of it. This is still experimental. Obviously if we choose this route, we'll update the pairings and keep everyone up to speed.
We're also looking into some other useful workarounds, and testing as well.
To the people asking about total supply: that is determined by when people choose to deploy batches.
I realized I can cut bytecode in half by pairing one of every person's addresses with one of another person's addresses, so I have a new contract I've written up that does that. You'd only have to transfer 10^-17 timereum out from the 1 timereum you get on launch to the other person who is your parent address to get all your batches, and you'll get it back when the person you're paired with deploys their coins. The whole manual generation works in the same way, it's just a way to cut bytecode. We wouldn't need one set of addresses anymore, but we could keep the remaining unused list for a future installment of this project, or alternatively get rid of it. This is still experimental. Obviously if we choose this route, we'll update the pairings and keep everyone up to speed.
We're also looking into some other useful workarounds, and testing as well.
To the people asking about total supply: that is determined by when people choose to deploy batches.
"pairing one of every person's addresses with one of another person's addresses" is very awful.
You must check for the solution with coding part.
Totally agree with Nagatraju. It makes 50% of the total genesis addresses useless right ?
Not only useless, Each one depend on other person. Which is horrible
July 14, 2017, 11:02:12 AM
@JustMissed Exactly. We're working on reducing bytecode.
I realized I can cut bytecode in half by pairing one of every person's addresses with one of another person's addresses, so I have a new contract I've written up that does that. You'd only have to transfer 10^-17 timereum out from the 1 timereum you get on launch to the other person who is your parent address to get all your batches, and you'll get it back when the person you're paired with deploys their coins. The whole manual generation works in the same way, it's just a way to cut bytecode. We wouldn't need one set of addresses anymore, but we could keep the remaining unused list for a future installment of this project, or alternatively get rid of it. This is still experimental. Obviously if we choose this route, we'll update the pairings and keep everyone up to speed.
We're also looking into some other useful workarounds, and testing as well.
To the people asking about total supply: that is determined by when people choose to deploy batches.
I realized I can cut bytecode in half by pairing one of every person's addresses with one of another person's addresses, so I have a new contract I've written up that does that. You'd only have to transfer 10^-17 timereum out from the 1 timereum you get on launch to the other person who is your parent address to get all your batches, and you'll get it back when the person you're paired with deploys their coins. The whole manual generation works in the same way, it's just a way to cut bytecode. We wouldn't need one set of addresses anymore, but we could keep the remaining unused list for a future installment of this project, or alternatively get rid of it. This is still experimental. Obviously if we choose this route, we'll update the pairings and keep everyone up to speed.
We're also looking into some other useful workarounds, and testing as well.
To the people asking about total supply: that is determined by when people choose to deploy batches.
"pairing one of every person's addresses with one of another person's addresses" is very awful.
You must check for the solution with coding part.
Totally agree with Nagatraju. It makes 50% of the total genesis addresses useless right ?
July 14, 2017, 10:59:12 AM
@JustMissed Exactly. We're working on reducing bytecode.
I realized I can cut bytecode in half by pairing one of every person's addresses with one of another person's addresses, so I have a new contract I've written up that does that. You'd only have to transfer 10^-17 timereum out from the 1 timereum you get on launch to the other person who is your parent address to get all your batches, and you'll get it back when the person you're paired with deploys their coins. The whole manual generation works in the same way, it's just a way to cut bytecode. We wouldn't need one set of addresses anymore, but we could keep the remaining unused list for a future installment of this project, or alternatively get rid of it. This is still experimental. Obviously if we choose this route, we'll update the pairings and keep everyone up to speed.
We're also looking into some other useful workarounds, and testing as well.
To the people asking about total supply: that is determined by when people choose to deploy batches.
I realized I can cut bytecode in half by pairing one of every person's addresses with one of another person's addresses, so I have a new contract I've written up that does that. You'd only have to transfer 10^-17 timereum out from the 1 timereum you get on launch to the other person who is your parent address to get all your batches, and you'll get it back when the person you're paired with deploys their coins. The whole manual generation works in the same way, it's just a way to cut bytecode. We wouldn't need one set of addresses anymore, but we could keep the remaining unused list for a future installment of this project, or alternatively get rid of it. This is still experimental. Obviously if we choose this route, we'll update the pairings and keep everyone up to speed.
We're also looking into some other useful workarounds, and testing as well.
To the people asking about total supply: that is determined by when people choose to deploy batches.
"pairing one of every person's addresses with one of another person's addresses" is very awful.
You must check for the solution with coding part.
Edit:
Simplify the contract. This might be impossible, depending on what exactly you're doing.
Split it into multiple contracts.
Refactor it to use libraries. If you're using lots of structs and mappings, this may make your code remarkably more readable.
Jump to: