[SNRG] 🔥 Synergy 🔥 Cloud.Synergycoin.com Cloud Bot Now Live!! 🔥

[ridery99]

Is hyper pos inflation implemented yet?

[1714775723]

1714775723

[1714775723]

1714775723

[1714775723]

1714775723

[1714775723]

1714775723

[1714775723]

1714775723

[Digital_Currency_LTD]

Is hyper pos inflation implemented yet?

No, no will be hyper pos inflation.

[Colonel Crouton]

Yeah, the best is now to wait and see how the things will go...
It was interesting to read last few pages, few nice arguments, but I have to agree what olcaytu2005 wrote:
"Did you see that any pump group give ayaw their profit?? They just dump their coins."

I never saw a pump group that didn't pump a coin to get their profits. This one hasn't been pumped yet.

Did anyone notice that the dev made an update yesterday?

[NextGenCrypto]

To-Do for Pump Group Release

• scan for previous registrations to know which stealth transactions will relay the pick for the current pump
• scan for said stealth transaction and extract the pick information
• scan transactions belonging to the registration address to report the minimum balance
• gui refinements (lock input fields for manual entry and other "fool-proofing")
• full-cycle testing and associated debugging
• block reward adjustment (assuming consensus for higher rewards remains unchallenged)
• deployment (versioning, building, & bundling)

Before I get to the update, I would like to mention that, in addition to bumping block rewards, I want to increase the block time, most likely to 4-6 minutes. Block times are currently 2 minutes. I dislike how fast the chain is growing right now. Short block times gained in popularity when it was assumed that quick confirmations might lead to vendor adoption. However, new technology has become available that obviates short block times. Probably the best example is Vanilla Coin's zero time.

Now to the update.

I finished the GUI "fool-proofing", added the new version information, and have done many full-cycle tests successfully. I only need to put in the new block rewards and then build. I should have a beta release (version 1.2.0.0, protocol 62200)  within 24 hours. During the beta testing period, I will streamline the code so that updating the GUI less CPU intensive than it is now. Mostly, I will set up some caching. For example, I presently execute a full search for the pick transaction on every new block. I wrote this code to be very efficient already, but the best behavior is to not make a search if the results are already available.

Users may not notice the improved efficiency because the present behavior is very fast. However, I consider it good practice to reduce the work load on the CPU, if possible.

I also need to provide feedback if a user has already registered for a pump, but I feel like that can wait for the beta testing period. Presently, users will be required to remember if they have already registered. In the future, the registration status will be indicated in the pump page.

I would have loved to have pushed changes to the github repository tonight, but I decided that I should change the block rewards before pushing. I'm certain that in the remote chance that I don't have builds tomorrow, I will be at a stage where I can push the source code changes to the repository.

Interesting change to the longer block times, that's not something you see very often these days exactly for the reason you state.  Makes no sense to me given nobody is gaining the adoption they think they will.  I trust your judgment on this one as I really don't know better.

[Colonel Crouton]

To-Do for Pump Group Release

• scan for previous registrations to know which stealth transactions will relay the pick for the current pump
• scan for said stealth transaction and extract the pick information
• scan transactions belonging to the registration address to report the minimum balance
• gui refinements (lock input fields for manual entry and other "fool-proofing")
• full-cycle testing and associated debugging
• block reward adjustment (assuming consensus for higher rewards remains unchallenged)
• deployment (versioning, building, & bundling)

Before I get to the update, I would like to mention that, in addition to bumping block rewards, I want to increase the block time, most likely to 4-6 minutes. Block times are currently 2 minutes. I dislike how fast the chain is growing right now. Short block times gained in popularity when it was assumed that quick confirmations might lead to vendor adoption. However, new technology has become available that obviates short block times. Probably the best example is Vanilla Coin's zero time.

Now to the update.

I finished the GUI "fool-proofing", added the new version information, and have done many full-cycle tests successfully. I only need to put in the new block rewards and then build. I should have a beta release (version 1.2.0.0, protocol 62200)  within 24 hours. During the beta testing period, I will streamline the code so that updating the GUI less CPU intensive than it is now. Mostly, I will set up some caching. For example, I presently execute a full search for the pick transaction on every new block. I wrote this code to be very efficient already, but the best behavior is to not make a search if the results are already available.

Users may not notice the improved efficiency because the present behavior is very fast. However, I consider it good practice to reduce the work load on the CPU, if possible.

I also need to provide feedback if a user has already registered for a pump, but I feel like that can wait for the beta testing period. Presently, users will be required to remember if they have already registered. In the future, the registration status will be indicated in the pump page.

I would have loved to have pushed changes to the github repository tonight, but I decided that I should change the block rewards before pushing. I'm certain that in the remote chance that I don't have builds tomorrow, I will be at a stage where I can push the source code changes to the repository.

Interesting change to the longer block times, that's not something you see very often these days exactly for the reason you state.  Makes no sense to me given nobody is gaining the adoption they think they will.  I trust your judgment on this one as I really don't know better.

That part of the update definitely slipped under the ole radar. Long block times are a long term thing right? I mean if you want a pump and dump, don't you just do 20 second block times so everyone convinces themselves that it will be accepted at coffee shops and fast food establishments within a year?

[NextGenCrypto]

To-Do for Pump Group Release

• scan for previous registrations to know which stealth transactions will relay the pick for the current pump
• scan for said stealth transaction and extract the pick information
• scan transactions belonging to the registration address to report the minimum balance
• gui refinements (lock input fields for manual entry and other "fool-proofing")
• full-cycle testing and associated debugging
• block reward adjustment (assuming consensus for higher rewards remains unchallenged)
• deployment (versioning, building, & bundling)

Before I get to the update, I would like to mention that, in addition to bumping block rewards, I want to increase the block time, most likely to 4-6 minutes. Block times are currently 2 minutes. I dislike how fast the chain is growing right now. Short block times gained in popularity when it was assumed that quick confirmations might lead to vendor adoption. However, new technology has become available that obviates short block times. Probably the best example is Vanilla Coin's zero time.

Now to the update.

I finished the GUI "fool-proofing", added the new version information, and have done many full-cycle tests successfully. I only need to put in the new block rewards and then build. I should have a beta release (version 1.2.0.0, protocol 62200)  within 24 hours. During the beta testing period, I will streamline the code so that updating the GUI less CPU intensive than it is now. Mostly, I will set up some caching. For example, I presently execute a full search for the pick transaction on every new block. I wrote this code to be very efficient already, but the best behavior is to not make a search if the results are already available.

Users may not notice the improved efficiency because the present behavior is very fast. However, I consider it good practice to reduce the work load on the CPU, if possible.

I also need to provide feedback if a user has already registered for a pump, but I feel like that can wait for the beta testing period. Presently, users will be required to remember if they have already registered. In the future, the registration status will be indicated in the pump page.

I would have loved to have pushed changes to the github repository tonight, but I decided that I should change the block rewards before pushing. I'm certain that in the remote chance that I don't have builds tomorrow, I will be at a stage where I can push the source code changes to the repository.

Interesting change to the longer block times, that's not something you see very often these days exactly for the reason you state.  Makes no sense to me given nobody is gaining the adoption they think they will.  I trust your judgment on this one as I really don't know better.

That part of the update definitely slipped under the ole radar. Long block times are a long term thing right? I mean if you want a pump and dump, don't you just do 20 second block times so everyone convinces themselves that it will be accepted at coffee shops and fast food establishments within a year?

Well, this certainly isn't following the same pattern as what the trolls claim.  No doubt about that.

[tx42]

Well, this certainly isn't following the same pattern as what the trolls claim.  No doubt about that.

Not necessarily. The dev still said you could get quick confirmations with zero time. I question the wisdom of that. Zero time is unproven and has some theoretical holes most of which don't seem to be adequately addressed in the whitepaper or any follow up commentary from the dev John Connor.

[ridery99]

[Colonel Crouton]

Well, this certainly isn't following the same pattern as what the trolls claim.  No doubt about that.

Not necessarily. The dev still said you could get quick confirmations with zero time. I question the wisdom of that. Zero time is unproven and has some theoretical holes most of which don't seem to be adequately addressed in the whitepaper or any follow up commentary from the dev John Connor.

Now you are the one fudding. Are you saying that Grandpa is following the same pattern as other pump and dump coins?

[NextGenCrypto]

Well, this certainly isn't following the same pattern as what the trolls claim.  No doubt about that.

Not necessarily. The dev still said you could get quick confirmations with zero time. I question the wisdom of that. Zero time is unproven and has some theoretical holes most of which don't seem to be adequately addressed in the whitepaper or any follow up commentary from the dev John Connor.

Now you are the one fudding. Are you saying that Grandpa is following the same pattern as other pump and dump coins?

We haven't seen any evidence of either.  The fudders will do what they do, they just don't know better and have been burned so many times they're oblivious to real projects.

[tx42]

Well, this certainly isn't following the same pattern as what the trolls claim.  No doubt about that.

Not necessarily. The dev still said you could get quick confirmations with zero time. I question the wisdom of that. Zero time is unproven and has some theoretical holes most of which don't seem to be adequately addressed in the whitepaper or any follow up commentary from the dev John Connor.

Now you are the one fudding. Are you saying that Grandpa is following the same pattern as other pump and dump coins?

No. I didn't quote the way I wanted. I was just agreeing with the dev that changing to long block times doesn't mean that you have to sacrifice fast transactions. But I was also just pointing out that zero time may not be the way to go just yet.

[Live4Crypto]

I love when the fudders start to show up.  That just means gramps is doing well.

[ridery99]

[je_sus]

Well, this certainly isn't following the same pattern as what the trolls claim.  No doubt about that.

Not necessarily. The dev still said you could get quick confirmations with zero time. I question the wisdom of that. Zero time is unproven and has some theoretical holes most of which don't seem to be adequately addressed in the whitepaper or any follow up commentary from the dev John Connor.

Now you are the one fudding. Are you saying that Grandpa is following the same pattern as other pump and dump coins?

No. I didn't quote the way I wanted. I was just agreeing with the dev that changing to long block times doesn't mean that you have to sacrifice fast transactions. But I was also just pointing out that zero time may not be the way to go just yet.

Can you explain more about these theoretical holes? From my limited understanding it seems like a big step forward for this coin.

[tradingmyseoul]

Hi,

I'm new to alt coins. I have some bitcoin but where do you think is the best place to buy Synergy? Is now a good time to buy?

I have only ever traded on cryptsy. But I don't see this on there, any idea why?

I bought some on bittrex, had to make a new account. I don't see why it's not on more exchanges?

I normally only buy and sell dogecoin so i'm new to this.

[je_sus]

Hi,

I'm new to alt coins. I have some bitcoin but where do you think is the best place to buy Synergy? Is now a good time to buy?

I have only ever traded on cryptsy. But I don't see this on there, any idea why?

I bought some on bittrex, had to make a new account. I don't see why it's not on more exchanges?

I normally only buy and sell dogecoin so i'm new to this.

Well you're a long way from home. Cryptsy is a decent exchange for a lot of the older coins. They aren't a big player in the field anymore and I think I would have more 'trust' in bittrex than them.

But, sure if we can get SNRG added to there then why not? Anyone tried to ask?

[Live4Crypto]

Grandpa Jones has joined us in the Slack channel!!  PM me an email address if you want to join in the conversation!  This address only needs to be used once.  It does not have to be your primary email address.  But please, come join us.

[bittamak]

Hi,

I'm new to alt coins. I have some bitcoin but where do you think is the best place to buy Synergy? Is now a good time to buy?

I have only ever traded on cryptsy. But I don't see this on there, any idea why?

I bought some on bittrex, had to make a new account. I don't see why it's not on more exchanges?

I normally only buy and sell dogecoin so i'm new to this.

To me, adding the coin to more exchanges would attract more/new investors which can be good for the coin.

[NextGenCrypto]

Hi,

I'm new to alt coins. I have some bitcoin but where do you think is the best place to buy Synergy? Is now a good time to buy?

I have only ever traded on cryptsy. But I don't see this on there, any idea why?

I bought some on bittrex, had to make a new account. I don't see why it's not on more exchanges?

I normally only buy and sell dogecoin so i'm new to this.

These things take time and SNRG is still relatively new and building its user base.  They'll come once they realize SNRG is here to stay.

[Digital_Currency_LTD]

Yes we need a bigger user base.