Topic: [ANN] TIMEREUM (TME) VERSION 2.0: "ELIXIR" (ELIX) RELEASED (NEW THREAD) - page 25. (Read 126698 times)
August 22, 2017, 03:53:40 PM
I was windering what happened with TME in nova in the last few days, but couldn't imagine a delisting... I hope nova can make a viable solution resolving the issue.
August 22, 2017, 03:47:52 PM
is it still possible to withdraw from Novaexchange ?
August 22, 2017, 03:03:17 PM
Quote
When a batch is spawned, the exchange balance checker thinks the contract made an error, but in reality a genesis holder has spawned a batch. Thinking about an edge case where an exchange address were a child address, or the exchange scanned through transactions of a child address, the confusion is understandable.
I propose to use ANTIMANIA's solution with a slight alteration: TME sent is burned, and a new token is produced. The eccentricity of TME's production algorithm means that we should issue a new token that has a predictable balanceOf() function and is made by converting TME. Those scanners do not understand and cannot account for (without additional teaching) TME's production algorithm; TME basically comes out of thin air at certain addresses.
A question dev, If i spawn all batches and i send TME i will produce new token but new token will be 1:1 of TME sent or will have same function as TME and if i keep long time i can produce more (10 years = 5000 new token)?
Any newer contract will need to know about uncreated batches. I wouldn't build a system that would take away the batch functionality.
your decision ?
Antimania and I are in communication about moving forward. For now just hang tight.
Sounds good. we will wait patiently for your decision.
August 22, 2017, 12:52:38 PM
ill buy some... when its on exchange
August 22, 2017, 12:49:30 PM
I think soon all problems will be solved. Dev on the right track. Well done, he needs our support!
I agree give the coin time to develop!!!
August 22, 2017, 12:48:30 PM
I think soon all problems will be solved. Dev on the right track. Well done, he needs our support!
August 22, 2017, 12:24:44 PM
wait wait wait , are we , i mean you guys gonna make "cook" new batch of TMe, so what happened to old one? they just died? or are you gonna retrieve our "genesis address" ?
what im missing here?
what im missing here?
Don't worry, your genesis addresses be fine. Thanks for your patience.
August 22, 2017, 12:01:34 PM
wait wait wait , are we , i mean you guys gonna make "cook" new batch of TMe, so what happened to old one? they just died? or are you gonna retrieve our "genesis address" ?
what im missing here?
what im missing here?
Don't worry, your genesis addresses be fine. Thanks for your patience.
August 22, 2017, 11:08:50 AM
wait wait wait , are we , i mean you guys gonna make "cook" new batch of TMe, so what happened to old one? they just died? or are you gonna retrieve our "genesis address" ?
what im missing here?
what im missing here?
August 22, 2017, 10:51:47 AM
Quote
When a batch is spawned, the exchange balance checker thinks the contract made an error, but in reality a genesis holder has spawned a batch. Thinking about an edge case where an exchange address were a child address, or the exchange scanned through transactions of a child address, the confusion is understandable.
I propose to use ANTIMANIA's solution with a slight alteration: TME sent is burned, and a new token is produced. The eccentricity of TME's production algorithm means that we should issue a new token that has a predictable balanceOf() function and is made by converting TME. Those scanners do not understand and cannot account for (without additional teaching) TME's production algorithm; TME basically comes out of thin air at certain addresses.
A question dev, If i spawn all batches and i send TME i will produce new token but new token will be 1:1 of TME sent or will have same function as TME and if i keep long time i can produce more (10 years = 5000 new token)?
Any newer contract will need to know about uncreated batches. I wouldn't build a system that would take away the batch functionality.
your decision ?
Antimania and I are in communication about moving forward. For now just hang tight.
August 22, 2017, 10:50:45 AM
I really like this dev efforts but i am interested in knowing the problems that exchanges are having with TME because i remembered that TME was listed on etherdata but was delisted and Novaexchange also threatened of delisting TME, what are the reason(s) behind this ?
it never got listed in the first place on etherdelta because of a compatibility issue.novaexchange is threatening of delisting tme because sometimes deposits get stuck and they are too incompetent to fix it and don't really listen to the dev's advice on how to fix it
Nova mentioned the balanceOf() function returns inconsistent results when compared to transfers. Indeed, this is to be expected.
I have not seen their code, but I believe Nova may be having issues with the following:
Imagine Nova is moving TME around by making transfers. After making a transfer, they check to make sure the right amount of TME is in the receiving address as was sent from the sender by checking the balanceOf() function on each address.
With TME, that sometimes doesn't work, because transfers are used to spawn batches. You instead need to check that the transaction did not run out of gas, and ignore the occasionally "conflicting" feedback from balanceOf()
The situation really applies when they are scanning the transactions of a child address, and the example transaction hash they provided was for a transfer to the exchange from a child address.
This is the best guess I have right now.
If Nova adds to its algorithm the verification of addresses from which the deposit was sent, according to the table of coincidence of the address with the child's address? I mean this: http://timereum.com/Website/List/addressesList.pdf. If the address is the same, then this is the birth of a batch of coins. Can they do this?
They could, but they have chosen thus far not to.
August 22, 2017, 10:35:50 AM
I really like this dev efforts but i am interested in knowing the problems that exchanges are having with TME because i remembered that TME was listed on etherdata but was delisted and Novaexchange also threatened of delisting TME, what are the reason(s) behind this ?
it never got listed in the first place on etherdelta because of a compatibility issue.novaexchange is threatening of delisting tme because sometimes deposits get stuck and they are too incompetent to fix it and don't really listen to the dev's advice on how to fix it
Nova mentioned the balanceOf() function returns inconsistent results when compared to transfers. Indeed, this is to be expected.
I have not seen their code, but I believe Nova may be having issues with the following:
Imagine Nova is moving TME around by making transfers. After making a transfer, they check to make sure the right amount of TME is in the receiving address as was sent from the sender by checking the balanceOf() function on each address.
With TME, that sometimes doesn't work, because transfers are used to spawn batches. You instead need to check that the transaction did not run out of gas, and ignore the occasionally "conflicting" feedback from balanceOf()
The situation really applies when they are scanning the transactions of a child address, and the example transaction hash they provided was for a transfer to the exchange from a child address.
This is the best guess I have right now.
If Nova adds to its algorithm the verification of addresses from which the deposit was sent, according to the table of coincidence of the address with the child's address? I mean this: http://timereum.com/Website/List/addressesList.pdf. If the address is the same, then this is the birth of a batch of coins. Can they do this?
August 22, 2017, 09:49:47 AM
Quote
When a batch is spawned, the exchange balance checker thinks the contract made an error, but in reality a genesis holder has spawned a batch. Thinking about an edge case where an exchange address were a child address, or the exchange scanned through transactions of a child address, the confusion is understandable.
I propose to use ANTIMANIA's solution with a slight alteration: TME sent is burned, and a new token is produced. The eccentricity of TME's production algorithm means that we should issue a new token that has a predictable balanceOf() function and is made by converting TME. Those scanners do not understand and cannot account for (without additional teaching) TME's production algorithm; TME basically comes out of thin air at certain addresses.
A question dev, If i spawn all batches and i send TME i will produce new token but new token will be 1:1 of TME sent or will have same function as TME and if i keep long time i can produce more (10 years = 5000 new token)?
Any newer contract will need to know about uncreated batches. I wouldn't build a system that would take away the batch functionality.
your decision ?
August 22, 2017, 09:44:13 AM
I had vote in the livecoin platform,and I wish we can exchange it successful in it.
everybody was active in the thread,it 's pretty good community as I see
everybody was active in the thread,it 's pretty good community as I see
August 22, 2017, 09:20:54 AM
Quote
When a batch is spawned, the exchange balance checker thinks the contract made an error, but in reality a genesis holder has spawned a batch. Thinking about an edge case where an exchange address were a child address, or the exchange scanned through transactions of a child address, the confusion is understandable.
I propose to use ANTIMANIA's solution with a slight alteration: TME sent is burned, and a new token is produced. The eccentricity of TME's production algorithm means that we should issue a new token that has a predictable balanceOf() function and is made by converting TME. Those scanners do not understand and cannot account for (without additional teaching) TME's production algorithm; TME basically comes out of thin air at certain addresses.
A question dev, If i spawn all batches and i send TME i will produce new token but new token will be 1:1 of TME sent or will have same function as TME and if i keep long time i can produce more (10 years = 5000 new token)?
Any newer contract will need to know about uncreated batches. I wouldn't build a system that would take away the batch functionality.
August 22, 2017, 09:15:26 AM
How to i can mine this coin at the moment! I am not have Parent-child address pair
Thánks
Well then you can't mine them without Genesis address, maybe you can buy them. Thánks
I'm offering 0.0001 each TME coin :p.
August 22, 2017, 09:03:17 AM
Sucks that the exchanges had issues with the transactions but it looks like things are getting sorted. Hopefully a swap won't be to difficult if it ends up being needed.
August 22, 2017, 07:31:31 AM
Quote
When a batch is spawned, the exchange balance checker thinks the contract made an error, but in reality a genesis holder has spawned a batch. Thinking about an edge case where an exchange address were a child address, or the exchange scanned through transactions of a child address, the confusion is understandable.
I propose to use ANTIMANIA's solution with a slight alteration: TME sent is burned, and a new token is produced. The eccentricity of TME's production algorithm means that we should issue a new token that has a predictable balanceOf() function and is made by converting TME. Those scanners do not understand and cannot account for (without additional teaching) TME's production algorithm; TME basically comes out of thin air at certain addresses.
A question dev, If i spawn all batches and i send TME i will produce new token but new token will be 1:1 of TME sent or will have same function as TME and if i keep long time i can produce more (10 years = 5000 new token)?
August 22, 2017, 07:30:10 AM
No worries, i think after Dev solve the problem , TME will move up again on another exchange.
which exchange is better liqui ? What's the update of this project? Any latest news from Dev?
August 22, 2017, 07:23:28 AM
How to i can mine this coin at the moment! I am not have Parent-child address pair
Thánks
Thánks
I'm selling 12500 TME. 1TME = 0.0001 Eth
Jump to: