for the moment guys, we've got some pretty insane/crazy ideas coming up for SUPER (amongst other things), all doable.. just needs a bit of patience.. no hints..
Take your time, my SUPER is staking anyway
Topic: SUPERCOIN'S REVIVAL - page 39. (Read 115687 times)
Take your time, my SUPER is staking anyway
for the moment guys, we've got some pretty insane/crazy ideas coming up for SUPER (amongst other things), all doable.. just needs a bit of patience.. no hints..
So what exatly you doing ? 
Ecc , MWC and SUPER its your coins I was think all time ...
Ecc , MWC and SUPER its your coins I was think all time ...
no. i didnt create any of them. i took over ECC when i was first learning crypto. the coin was very broken and since then all the issues have been fixed. if you look at some of my first ECC updates they are terrible and had to be redone because i didnt yet understand the full system.
i agreed to work with the MWC team at some point cuz they had three coders and i came to help them with something i wanted to make myself anyway. turns out the lead dev at the time was a scammer and left after he dumped on hype he created. the other dev they had disappeared with no word one day and never returned and i got stuck with the coin.
Super community needed someone to take over to maintain the chain and make minor fixes because the coin is essentially complete except for the memory issue which im testing right now, the dev who created it did a wonderful job but eventually got driven away by fudders. its probably got the best anon system of any coin out there but the community was so self destructive during its high point that a lot of people left after a price dip and there arent many people left.
i just wanted to make applications for use with coins. never intended on running three coins. id love it if interested parties came in to code the changes they want to see for super and mwc. anyone is free to do so.
ive been saying this for months anytime anyone asks. on top of that, i got hired by an actual company who wants to use crypto as a payment system for goods and services as a full time software engineer and network security manager.
so thats about where everything is right now.
Regarding MWC: We were so patient for more than a year but there were not any substantial updates. You were dealing with new coins since then and left us just without any new updates, only new postpones as you are still doing it now. I even donated you some coins and hoped for at least a proper communication. The project was at the end too big for Griffith.
Yeah, we where all fooled by Griffith. I donated a working in wallet trading to him, he never did anything with it. Now on this moment I don't care anymore I just try to warn other coin holders for Griffith....he's all words and nothing else
i messaged barry about it two days ago (friday afternoon my time but saturday for him), he might not be online during the weekends. im waiting on a response from him atm
edit: we connected and are now discussing things about the new chain and other improvements
edit: we connected and are now discussing things about the new chain and other improvements
Hmm,
Best Solution for the Time Being is pretty obvious.
Barrysty1e should do the swap, since it can be done quickly.
Griffith , your New Job is your Primary Responsibility and that is totally understandable.
After the Swap you will have a few years to Completely Perfect your Designs and it can be added at that later time.
Rushing it out before all of the kinks are worked out would hurt more than help.
Before the swap , the new block speed needs to be decided, 90 seconds would be a good choice , decreased orphans & much faster syncing , it has my vote.
Best Solution for the Time Being is pretty obvious.
Barrysty1e should do the swap, since it can be done quickly.
Griffith , your New Job is your Primary Responsibility and that is totally understandable.
After the Swap you will have a few years to Completely Perfect your Designs and it can be added at that later time.
Rushing it out before all of the kinks are worked out would hurt more than help.
Before the swap , the new block speed needs to be decided, 90 seconds would be a good choice , decreased orphans & much faster syncing , it has my vote.
Sounds fine to me.
It would be helpful to have some prospective technicals (ie only the changes) for the new chain.
+1 TvZ
Waiting is patience and patience is often profits. Waiting is my fav part about all this. We got a new guy on board to work with the current team, if you wanna call it a takeover thats fine.
Stake and Hold.
Waiting is patience and patience is often profits. Waiting is my fav part about all this. We got a new guy on board to work with the current team, if you wanna call it a takeover thats fine.
Stake and Hold.
Agree. The Community will keep Super alive and healthy. Give developers space and time.
Hmm,
Best Solution for the Time Being is pretty obvious.
Barrysty1e should do the swap, since it can be done quickly.
Griffith , your New Job is your Primary Responsibility and that is totally understandable.
After the Swap you will have a few years to Completely Perfect your Designs and it can be added at that later time.
Rushing it out before all of the kinks are worked out would hurt more than help.
Before the swap , the new block speed needs to be decided, 90 seconds would be a good choice , decreased orphans & much faster syncing , it has my vote.
Best Solution for the Time Being is pretty obvious.
Barrysty1e should do the swap, since it can be done quickly.
Griffith , your New Job is your Primary Responsibility and that is totally understandable.
After the Swap you will have a few years to Completely Perfect your Designs and it can be added at that later time.
Rushing it out before all of the kinks are worked out would hurt more than help.
Before the swap , the new block speed needs to be decided, 90 seconds would be a good choice , decreased orphans & much faster syncing , it has my vote.
+1 TvZ
Waiting is patience and patience is often profits. Waiting is my fav part about all this. We got a new guy on board to work with the current team, if you wanna call it a takeover thats fine.
Stake and Hold.
Waiting is patience and patience is often profits. Waiting is my fav part about all this. We got a new guy on board to work with the current team, if you wanna call it a takeover thats fine.
Stake and Hold.
I have a lot of patience too, my SUPER is staking for a long time now and it gaves me many thousands of extra free SUPER!
Hopefully Griffith and the new guy are gonna make SUPER great AGAIN! They have my full support.
+1 TvZ
Waiting is patience and patience is often profits. Waiting is my fav part about all this. We got a new guy on board to work with the current team, if you wanna call it a takeover thats fine.
Stake and Hold.
Waiting is patience and patience is often profits. Waiting is my fav part about all this. We got a new guy on board to work with the current team, if you wanna call it a takeover thats fine.
Stake and Hold.
I'll keep my trust in Griffith, i'm sure he's doing whatever he can for SUPER.
Maybe this sound strange but... he's having a real life too and probably
also some other activities next to SUPER.
Some more respect would be nice.
For all those negative talking people, if you can do it better, DO IT!
Contact Griffith to offer your help.
I'm unfortunately not a dev so i did my part to get SUPER listed at
https://www.coinexchange.io/market/SUPER/BTC
and
https://btcpool.exchange/Market?pair=SUPER/BTC
It's simple, if you like SUPER do your part, even if it is just a small
nice tweet about SUPER!
Good question ....why wait. Thats all Griffith does...all the time....for years now.
So Griffith let barrystyle or is it james take over this coin so it can go forward. I would be pleased to invest in it. For now I have placed a small buy order on coin exchange.io
So Griffith let barrystyle or is it james take over this coin so it can go forward. I would be pleased to invest in it. For now I have placed a small buy order on coin exchange.io
Dude we are all waiting, talking about it now is a distraction but since you brought it up lets clarify.
While we wait for stuff, Griffith maintains the chain and finds new pr guy(hope he chimes in soon btw)
There will be no takeover, there will be new team members joining team super.
Now lets let them discuss it until many minds can find what is to be the next step in development.
Thankyou for your buy order on coinexchange.io we have 0.69056216 BTC value on the buy side which is a good start.
DUDE.... no takeover? then it's not worth for me to invest in Super. Griffith will do nothing so keep waiting. In the meanwhile I will take my buy offer and place it somewhere else.
Good question ....why wait. Thats all Griffith does...all the time....for years now.
So Griffith let barrystyle or is it james take over this coin so it can go forward. I would be pleased to invest in it. For now I have placed a small buy order on coin exchange.io
So Griffith let barrystyle or is it james take over this coin so it can go forward. I would be pleased to invest in it. For now I have placed a small buy order on coin exchange.io
Dude we are all waiting, talking about it now is a distraction but since you brought it up lets clarify.
While we wait for stuff, Griffith maintains the chain and finds new pr guy(hope he chimes in soon btw)
There will be no takeover, there will be new team members joining team super.
Now lets let them discuss it until many minds can find what is to be the next step in development.
Thankyou for your buy order on coinexchange.io we have 0.69056216 BTC value on the buy side which is a good start.
why not use my automated chainswap technique with 60 second pos blocks?
this would mean that instead of roughly 0.85gb chain growth per year, it will be 0.28gb per year.
meaning that you'd reach where we are now after 6 years.
the way i see it now, both of our solutions require a new chain; why wait?
PMd you about this. just to make coms easier.
Good question ....why wait. Thats all Griffith does...all the time....for years now.
So Griffith let barrystyle or is it james take over this coin so it can go forward. I would be pleased to invest in it. For now I have placed a small buy order on coin exchange.io
So Griffith let barrystyle or is it james take over this coin so it can go forward. I would be pleased to invest in it. For now I have placed a small buy order on coin exchange.io
im unsure of what you think im waiting to do?
was considering doing a coin swap to eliminate some of these issues... thoughts? possibly to merge a coin or two.
edit: i have a mobile wallet for any bitcoin clone crypto just about done right now
edit edit:
i have been working on a chain that keeps the current one that just holds less variables inside the blockindex class and will calculate the rest when it needs them and it uses about half the ram.
with your suggestion, if im understanding your correctly, would be to launch a new chain with people logging the value of their current wallets (via BE) and then having it resend out the coins to the same addresses (amount) then using the BE to redistribute the coins. but now the chain is different, reset, and smaller. effectively doing the same thing a coin swap would do but automatically?
edit: i have a mobile wallet for any bitcoin clone crypto just about done right now
edit edit:
Neat idea would be to run Supercoin through a block explorer and log all balances (besides dust), nullify the chain by changing pchMessage bytes, change block value for block 1 to a suitable amount which could encompass total values of addresses that we've logged, relaunch chain and then distribute on block 2.
Other variables could be changed to reflect current state of coin including block reward etc.
This way everyone can just dump their existing addresses via dumpprivkey; move to new wallet, reimport the keys and everything should be (relatively) as it was. Except the wallet isn't chugging through 2,000,000 blocks to sync; or verify when a new key is added.
About 4 hours work.
Note - I do not hold any SUPER; someone has approached me asking how this coin could be made 'SUPER' again.
barrystyle
Other variables could be changed to reflect current state of coin including block reward etc.
This way everyone can just dump their existing addresses via dumpprivkey; move to new wallet, reimport the keys and everything should be (relatively) as it was. Except the wallet isn't chugging through 2,000,000 blocks to sync; or verify when a new key is added.
About 4 hours work.
Note - I do not hold any SUPER; someone has approached me asking how this coin could be made 'SUPER' again.
barrystyle
i have been working on a chain that keeps the current one that just holds less variables inside the blockindex class and will calculate the rest when it needs them and it uses about half the ram.
with your suggestion, if im understanding your correctly, would be to launch a new chain with people logging the value of their current wallets (via BE) and then having it resend out the coins to the same addresses (amount) then using the BE to redistribute the coins. but now the chain is different, reset, and smaller. effectively doing the same thing a coin swap would do but automatically?
yep, essentially culling the previous 3.8 mil blocks yet all addresses holding the correct amounts.
another potential thought would be the reliance on leveldb itself; LMDB looks to be a good replacement with a tiny footprint.. however this would be a reasonable body of work.
compression is a neat idea however compaction/expansion will require just as much ram (if not more) per load cycle and would be even slower during client bootup.
there isn't going to be a silver bullet with a 20 second PoS time; perhaps spacing this to a 60 or 90s would resolve the amount the chain grows (fastcoin/infinitecoin suffers from this too).
i know its possible to condense blocks so you dont have to load them all into memory to store them. i did a LOT of testing with it, my conclusion was that you need to have the chain do it from the start rather than implement it later because of the way it loads transactions and looks up blocks using the index. i know that you also need to use a different data structure other than a std::map because even if you delete elements from a map the size doesnt shrink. essentially a custom class would be needed (i have one prototyped) that would be the new way to store the chain. its based on the idea of using a vector as a map, with individual look up functions, while still being able to shrink its size (BTW there are a lot of map.find function calls, which is not something you can do with a vector. map find is O log N while going through each element in a vector to find something is O N. so this isnt feasible, it takes the wallet over 3 hours to load doing it this way) so just replacing the map with a vector cant be done.
id rather find a solution that just restart the chain every year because that doesnt really solve any of the problems.
why not use my automated chainswap technique with 60 second pos blocks?
this would mean that instead of roughly 0.85gb chain growth per year, it will be 0.28gb per year.
meaning that you'd reach where we are now after 6 years.
the way i see it now, both of our solutions require a new chain; why wait?
Good question ....why wait. Thats all Griffith does...all the time....for years now.
So Griffith let barrystyle or is it james take over this coin so it can go forward. I would be pleased to invest in it. For now I have placed a small buy order on coin exchange.io
was considering doing a coin swap to eliminate some of these issues... thoughts? possibly to merge a coin or two.
edit: i have a mobile wallet for any bitcoin clone crypto just about done right now
edit edit:
i have been working on a chain that keeps the current one that just holds less variables inside the blockindex class and will calculate the rest when it needs them and it uses about half the ram.
with your suggestion, if im understanding your correctly, would be to launch a new chain with people logging the value of their current wallets (via BE) and then having it resend out the coins to the same addresses (amount) then using the BE to redistribute the coins. but now the chain is different, reset, and smaller. effectively doing the same thing a coin swap would do but automatically?
edit: i have a mobile wallet for any bitcoin clone crypto just about done right now
edit edit:
Neat idea would be to run Supercoin through a block explorer and log all balances (besides dust), nullify the chain by changing pchMessage bytes, change block value for block 1 to a suitable amount which could encompass total values of addresses that we've logged, relaunch chain and then distribute on block 2.
Other variables could be changed to reflect current state of coin including block reward etc.
This way everyone can just dump their existing addresses via dumpprivkey; move to new wallet, reimport the keys and everything should be (relatively) as it was. Except the wallet isn't chugging through 2,000,000 blocks to sync; or verify when a new key is added.
About 4 hours work.
Note - I do not hold any SUPER; someone has approached me asking how this coin could be made 'SUPER' again.
barrystyle
Other variables could be changed to reflect current state of coin including block reward etc.
This way everyone can just dump their existing addresses via dumpprivkey; move to new wallet, reimport the keys and everything should be (relatively) as it was. Except the wallet isn't chugging through 2,000,000 blocks to sync; or verify when a new key is added.
About 4 hours work.
Note - I do not hold any SUPER; someone has approached me asking how this coin could be made 'SUPER' again.
barrystyle
i have been working on a chain that keeps the current one that just holds less variables inside the blockindex class and will calculate the rest when it needs them and it uses about half the ram.
with your suggestion, if im understanding your correctly, would be to launch a new chain with people logging the value of their current wallets (via BE) and then having it resend out the coins to the same addresses (amount) then using the BE to redistribute the coins. but now the chain is different, reset, and smaller. effectively doing the same thing a coin swap would do but automatically?
yep, essentially culling the previous 3.8 mil blocks yet all addresses holding the correct amounts.
another potential thought would be the reliance on leveldb itself; LMDB looks to be a good replacement with a tiny footprint.. however this would be a reasonable body of work.
compression is a neat idea however compaction/expansion will require just as much ram (if not more) per load cycle and would be even slower during client bootup.
there isn't going to be a silver bullet with a 20 second PoS time; perhaps spacing this to a 60 or 90s would resolve the amount the chain grows (fastcoin/infinitecoin suffers from this too).
i know its possible to condense blocks so you dont have to load them all into memory to store them. i did a LOT of testing with it, my conclusion was that you need to have the chain do it from the start rather than implement it later because of the way it loads transactions and looks up blocks using the index. i know that you also need to use a different data structure other than a std::map because even if you delete elements from a map the size doesnt shrink. essentially a custom class would be needed (i have one prototyped) that would be the new way to store the chain. its based on the idea of using a vector as a map, with individual look up functions, while still being able to shrink its size (BTW there are a lot of map.find function calls, which is not something you can do with a vector. map find is O log N while going through each element in a vector to find something is O N. so this isnt feasible, it takes the wallet over 3 hours to load doing it this way) so just replacing the map with a vector cant be done.
id rather find a solution that just restart the chain every year because that doesnt really solve any of the problems.
why not use my automated chainswap technique with 60 second pos blocks?
this would mean that instead of roughly 0.85gb chain growth per year, it will be 0.28gb per year.
meaning that you'd reach where we are now after 6 years.
the way i see it now, both of our solutions require a new chain; why wait?
was considering doing a coin swap to eliminate some of these issues... thoughts? possibly to merge a coin or two.
edit: i have a mobile wallet for any bitcoin clone crypto just about done right now
edit edit:
i have been working on a chain that keeps the current one that just holds less variables inside the blockindex class and will calculate the rest when it needs them and it uses about half the ram.
with your suggestion, if im understanding your correctly, would be to launch a new chain with people logging the value of their current wallets (via BE) and then having it resend out the coins to the same addresses (amount) then using the BE to redistribute the coins. but now the chain is different, reset, and smaller. effectively doing the same thing a coin swap would do but automatically?
edit: i have a mobile wallet for any bitcoin clone crypto just about done right now
edit edit:
Neat idea would be to run Supercoin through a block explorer and log all balances (besides dust), nullify the chain by changing pchMessage bytes, change block value for block 1 to a suitable amount which could encompass total values of addresses that we've logged, relaunch chain and then distribute on block 2.
Other variables could be changed to reflect current state of coin including block reward etc.
This way everyone can just dump their existing addresses via dumpprivkey; move to new wallet, reimport the keys and everything should be (relatively) as it was. Except the wallet isn't chugging through 2,000,000 blocks to sync; or verify when a new key is added.
About 4 hours work.
Note - I do not hold any SUPER; someone has approached me asking how this coin could be made 'SUPER' again.
barrystyle
Other variables could be changed to reflect current state of coin including block reward etc.
This way everyone can just dump their existing addresses via dumpprivkey; move to new wallet, reimport the keys and everything should be (relatively) as it was. Except the wallet isn't chugging through 2,000,000 blocks to sync; or verify when a new key is added.
About 4 hours work.
Note - I do not hold any SUPER; someone has approached me asking how this coin could be made 'SUPER' again.
barrystyle
i have been working on a chain that keeps the current one that just holds less variables inside the blockindex class and will calculate the rest when it needs them and it uses about half the ram.
with your suggestion, if im understanding your correctly, would be to launch a new chain with people logging the value of their current wallets (via BE) and then having it resend out the coins to the same addresses (amount) then using the BE to redistribute the coins. but now the chain is different, reset, and smaller. effectively doing the same thing a coin swap would do but automatically?
yep, essentially culling the previous 3.8 mil blocks yet all addresses holding the correct amounts.
another potential thought would be the reliance on leveldb itself; LMDB looks to be a good replacement with a tiny footprint.. however this would be a reasonable body of work.
compression is a neat idea however compaction/expansion will require just as much ram (if not more) per load cycle and would be even slower during client bootup.
there isn't going to be a silver bullet with a 20 second PoS time; perhaps spacing this to a 60 or 90s would resolve the amount the chain grows (fastcoin/infinitecoin suffers from this too).
i know its possible to condense blocks so you dont have to load them all into memory to store them. i did a LOT of testing with it, my conclusion was that you need to have the chain do it from the start rather than implement it later because of the way it loads transactions and looks up blocks using the index. i know that you also need to use a different data structure other than a std::map because even if you delete elements from a map the size doesnt shrink. essentially a custom class would be needed (i have one prototyped) that would be the new way to store the chain. its based on the idea of using a vector as a map, with individual look up functions, while still being able to shrink its size (BTW there are a lot of map.find function calls, which is not something you can do with a vector. map find is O log N while going through each element in a vector to find something is O N. so this isnt feasible, it takes the wallet over 3 hours to load doing it this way) so just replacing the map with a vector cant be done.
id rather find a solution that just restart the chain every year because that doesnt really solve any of the problems.
was considering doing a coin swap to eliminate some of these issues... thoughts? possibly to merge a coin or two.
edit: i have a mobile wallet for any bitcoin clone crypto just about done right now
edit edit:
i have been working on a chain that keeps the current one that just holds less variables inside the blockindex class and will calculate the rest when it needs them and it uses about half the ram.
with your suggestion, if im understanding your correctly, would be to launch a new chain with people logging the value of their current wallets (via BE) and then having it resend out the coins to the same addresses (amount) then using the BE to redistribute the coins. but now the chain is different, reset, and smaller. effectively doing the same thing a coin swap would do but automatically?
edit: i have a mobile wallet for any bitcoin clone crypto just about done right now
edit edit:
Neat idea would be to run Supercoin through a block explorer and log all balances (besides dust), nullify the chain by changing pchMessage bytes, change block value for block 1 to a suitable amount which could encompass total values of addresses that we've logged, relaunch chain and then distribute on block 2.
Other variables could be changed to reflect current state of coin including block reward etc.
This way everyone can just dump their existing addresses via dumpprivkey; move to new wallet, reimport the keys and everything should be (relatively) as it was. Except the wallet isn't chugging through 2,000,000 blocks to sync; or verify when a new key is added.
About 4 hours work.
Note - I do not hold any SUPER; someone has approached me asking how this coin could be made 'SUPER' again.
barrystyle
Other variables could be changed to reflect current state of coin including block reward etc.
This way everyone can just dump their existing addresses via dumpprivkey; move to new wallet, reimport the keys and everything should be (relatively) as it was. Except the wallet isn't chugging through 2,000,000 blocks to sync; or verify when a new key is added.
About 4 hours work.
Note - I do not hold any SUPER; someone has approached me asking how this coin could be made 'SUPER' again.
barrystyle
i have been working on a chain that keeps the current one that just holds less variables inside the blockindex class and will calculate the rest when it needs them and it uses about half the ram.
with your suggestion, if im understanding your correctly, would be to launch a new chain with people logging the value of their current wallets (via BE) and then having it resend out the coins to the same addresses (amount) then using the BE to redistribute the coins. but now the chain is different, reset, and smaller. effectively doing the same thing a coin swap would do but automatically?
yep, essentially culling the previous 3.8 mil blocks yet all addresses holding the correct amounts.
another potential thought would be the reliance on leveldb itself; LMDB looks to be a good replacement with a tiny footprint.. however this would be a reasonable body of work.
compression is a neat idea however compaction/expansion will require just as much ram (if not more) per load cycle and would be even slower during client bootup.
there isn't going to be a silver bullet with a 20 second PoS time; perhaps spacing this to a 60 or 90s would resolve the amount the chain grows (fastcoin/infinitecoin suffers from this too).
To address the not working full time issue, or no new developments. its incredibly difficult to actually try to solve the current issues while keeping the chain compatible with all blocks that have already been issued. Every time i get a new idea for something i do go back and test it. i work on a LOT of crypto projects and am currently working for a company trying out a corporate block chain based payment system.
I have been telling a lot of projects i have worked with in the past that i dont have time anymore in an effort to reduce the amount of things i am working on and focus on a few. i'm down to 3 projects now instead of like 7 or 8.
I have been telling a lot of projects i have worked with in the past that i dont have time anymore in an effort to reduce the amount of things i am working on and focus on a few. i'm down to 3 projects now instead of like 7 or 8.
was considering doing a coin swap to eliminate some of these issues... thoughts? possibly to merge a coin or two.
edit: i have a mobile wallet for any bitcoin clone crypto just about done right now
edit edit:
i have been working on a chain that keeps the current one that just holds less variables inside the blockindex class and will calculate the rest when it needs them and it uses about half the ram.
with your suggestion, if im understanding your correctly, would be to launch a new chain with people logging the value of their current wallets (via BE) and then having it resend out the coins to the same addresses (amount) then using the BE to redistribute the coins. but now the chain is different, reset, and smaller. effectively doing the same thing a coin swap would do but automatically?
edit: i have a mobile wallet for any bitcoin clone crypto just about done right now
edit edit:
Neat idea would be to run Supercoin through a block explorer and log all balances (besides dust), nullify the chain by changing pchMessage bytes, change block value for block 1 to a suitable amount which could encompass total values of addresses that we've logged, relaunch chain and then distribute on block 2.
Other variables could be changed to reflect current state of coin including block reward etc.
This way everyone can just dump their existing addresses via dumpprivkey; move to new wallet, reimport the keys and everything should be (relatively) as it was. Except the wallet isn't chugging through 2,000,000 blocks to sync; or verify when a new key is added.
About 4 hours work.
Note - I do not hold any SUPER; someone has approached me asking how this coin could be made 'SUPER' again.
barrystyle
Other variables could be changed to reflect current state of coin including block reward etc.
This way everyone can just dump their existing addresses via dumpprivkey; move to new wallet, reimport the keys and everything should be (relatively) as it was. Except the wallet isn't chugging through 2,000,000 blocks to sync; or verify when a new key is added.
About 4 hours work.
Note - I do not hold any SUPER; someone has approached me asking how this coin could be made 'SUPER' again.
barrystyle
i have been working on a chain that keeps the current one that just holds less variables inside the blockindex class and will calculate the rest when it needs them and it uses about half the ram.
with your suggestion, if im understanding your correctly, would be to launch a new chain with people logging the value of their current wallets (via BE) and then having it resend out the coins to the same addresses (amount) then using the BE to redistribute the coins. but now the chain is different, reset, and smaller. effectively doing the same thing a coin swap would do but automatically?
Griffith is a competent developer, but is not able to work full time on Super. Collaboration would be ideal.
I often see that good develpers come in for unjustified criticism on the Forum, and it's a tough job !
I often see that good develpers come in for unjustified criticism on the Forum, and it's a tough job !
Collaboration would be ideal.
Yer hats off to the guy for getting Super this far whist not losing sanity from the fud.
Im in for the long run, Super Ecc. id swap 1/? for any MWC if any holders abound.
Jump to: