Bitcoin Forum
May 05, 2024, 08:56:46 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 [42] 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 »
  Print  
Author Topic: SUPERCOIN'S REVIVAL  (Read 115619 times)
Griffith
Legendary
*
Offline Offline

Activity: 1400
Merit: 1000


View Profile
June 10, 2016, 01:23:19 AM
 #821

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.

1714899406
Hero Member
*
Offline Offline

Posts: 1714899406

View Profile Personal Message (Offline)

Ignore
1714899406
Reply with quote  #2

1714899406
Report to moderator
"There should not be any signed int. If you've found a signed int somewhere, please tell me (within the next 25 years please) and I'll change it to unsigned int." -- Satoshi
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1714899406
Hero Member
*
Offline Offline

Posts: 1714899406

View Profile Personal Message (Offline)

Ignore
1714899406
Reply with quote  #2

1714899406
Report to moderator
barrysty1e
Hero Member
*****
Offline Offline

Activity: 636
Merit: 516



View Profile WWW
June 10, 2016, 04:57:40 AM
 #822

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:

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

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).

my father wears sneakers in the pool
Griffith
Legendary
*
Offline Offline

Activity: 1400
Merit: 1000


View Profile
June 10, 2016, 05:55:54 AM
 #823

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:

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

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.
barrysty1e
Hero Member
*****
Offline Offline

Activity: 636
Merit: 516



View Profile WWW
June 10, 2016, 12:16:07 PM
 #824

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:

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

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?

my father wears sneakers in the pool
mdtspain
Legendary
*
Offline Offline

Activity: 1076
Merit: 1003


View Profile
June 10, 2016, 03:16:14 PM
 #825

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:

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

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
Griffith
Legendary
*
Offline Offline

Activity: 1400
Merit: 1000


View Profile
June 10, 2016, 05:33:50 PM
 #826


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

im unsure of what you think im waiting to do?
shrimpdigger
Member
**
Offline Offline

Activity: 123
Merit: 10

NYC NYC NYC


View Profile
June 11, 2016, 03:20:39 PM
Last edit: June 11, 2016, 07:30:31 PM by shrimpdigger
 #827

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


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.
mdtspain
Legendary
*
Offline Offline

Activity: 1076
Merit: 1003


View Profile
June 11, 2016, 04:01:23 PM
 #828



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


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.
TvZ
Sr. Member
****
Offline Offline

Activity: 315
Merit: 251


View Profile
June 11, 2016, 06:53:00 PM
 #829


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!

shrimpdigger
Member
**
Offline Offline

Activity: 123
Merit: 10

NYC NYC NYC


View Profile
June 11, 2016, 07:36:29 PM
 #830

+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.
TvZ
Sr. Member
****
Offline Offline

Activity: 315
Merit: 251


View Profile
June 11, 2016, 09:14:39 PM
 #831

+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.

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.



kiklo
Legendary
*
Offline Offline

Activity: 1092
Merit: 1000



View Profile
June 12, 2016, 07:00:41 AM
 #832

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.

 Cool
Majormax
Legendary
*
Offline Offline

Activity: 2534
Merit: 1129


View Profile WWW
June 12, 2016, 02:16:50 PM
 #833

+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.

Agree. The Community will keep Super alive and healthy. Give developers space and time.
Majormax
Legendary
*
Offline Offline

Activity: 2534
Merit: 1129


View Profile WWW
June 12, 2016, 02:19:04 PM
 #834

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.

 Cool

Sounds fine to me.

It would be helpful to have some prospective technicals (ie only the changes) for the new chain.
Griffith
Legendary
*
Offline Offline

Activity: 1400
Merit: 1000


View Profile
June 12, 2016, 10:43:29 PM
Last edit: June 13, 2016, 07:25:18 AM by Griffith
 #835

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
mdtspain
Legendary
*
Offline Offline

Activity: 1076
Merit: 1003


View Profile
June 13, 2016, 04:04:39 PM
 #836

So what exatly you doing ?  Shocked
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
barrysty1e
Hero Member
*****
Offline Offline

Activity: 636
Merit: 516



View Profile WWW
June 14, 2016, 10:30:08 AM
 #837

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..

my father wears sneakers in the pool
TvZ
Sr. Member
****
Offline Offline

Activity: 315
Merit: 251


View Profile
June 16, 2016, 06:45:35 PM
 #838

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 Wink


TvZ
Sr. Member
****
Offline Offline

Activity: 315
Merit: 251


View Profile
June 16, 2016, 07:49:20 PM
 #839

alcurex has remade its website and moved to a new domain.
All accounts and balances have been moved to the new exchange.

https://alcurex.org/index.php/crypto/mainindex

The new alcurex website looks very nice.

https://alcurex.com


SUPER will be listed soon!
mdtspain
Legendary
*
Offline Offline

Activity: 1076
Merit: 1003


View Profile
June 17, 2016, 09:02:47 AM
 #840

alcurex has remade its website and moved to a new domain.
All accounts and balances have been moved to the new exchange.

https://alcurex.org/index.php/crypto/mainindex

The new alcurex website looks very nice.

https://alcurex.com


SUPER will be listed soon!

Ziet er idd goed uit. Hoe weet je dat Super daar binnenkort ook verhandelbaar is. Ik kan daar geen info over vinden
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 [42] 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!