Bitcoin Forum
March 19, 2024, 08:23:46 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 [905] 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 ... 1035 »
  Print  
Author Topic: [ANN] [MINT] Mintcoin (POS / 5%) [NO ICO] [Fair distro, community maintained]  (Read 1369737 times)
sambiohazard
Hero Member
*****
Offline Offline

Activity: 840
Merit: 1000



View Profile
July 02, 2015, 10:11:35 PM
 #18081

Great work by Presstab on researching. Hoping for everything to go smoothly in testing. Finally we are going forward with patching important vulnerabilities & improving UI, thanks to effort of CryptoMommy & other active members. Thanks to @Kiklo for suggesting Presstab as dev for these changes. I am really happy to see this thread updated with latest discussion which was not happening previously. Thanks to all Smiley
Bitcoin addresses contain a checksum, so it is very unlikely that mistyping an address will cause you to lose money.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
supasonic
Newbie
*
Offline Offline

Activity: 4
Merit: 0


View Profile
July 03, 2015, 12:34:32 AM
Last edit: July 03, 2015, 01:24:37 AM by supasonic
 #18082

Hello Everyone. Just been updating myself on the discussion. I spoke with cryptomommy about the UI changes and have a few ideas for the update.

I noticed that a lot of the code is from an early Peercoin fork. Big project to bring it more inline with more recent ideas and revelations. I want to propose adding some statistical gathering code to in a point release before the fork so we can see how blocks are propagating through the network, this way we can see how much time drift is reflected and which limit is best. At this point any lower number is better than two hours but what would be best for MintCoin? Lets find out! I'm working on the UI commits and want to add the data collection as well.

A later and bigger project would be bringing down some memory usage and sync times by packing the block chain into chunks and hashing them and and distributing them among the peers building the db during some idle cycles later. Any ideas or examples of that would be appreciated as I said, it would be a big project.

I'm also taking request for other idea as coding work for me slows down this time of year. I love the Idea of MintCoin and want to see it succeed.

Thanks for any input
coolbeans94
Hero Member
*****
Offline Offline

Activity: 613
Merit: 500


Mintcoin: Get some


View Profile
July 03, 2015, 03:44:26 AM
 #18083

Hello Everyone. Just been updating myself on the discussion. I spoke with cryptomommy about the UI changes and have a few ideas for the update.

I noticed that a lot of the code is from an early Peercoin fork. Big project to bring it more inline with more recent ideas and revelations. I want to propose adding some statistical gathering code to in a point release before the fork so we can see how blocks are propagating through the network, this way we can see how much time drift is reflected and which limit is best. At this point any lower number is better than two hours but what would be best for MintCoin? Lets find out! I'm working on the UI commits and want to add the data collection as well.

A later and bigger project would be bringing down some memory usage and sync times by packing the block chain into chunks and hashing them and and distributing them among the peers building the db during some idle cycles later. Any ideas or examples of that would be appreciated as I said, it would be a big project.

I'm also taking request for other idea as coding work for me slows down this time of year. I love the Idea of MintCoin and want to see it succeed.

Thanks for any input
Okay. I have several questions:
So no hard fork required for adding the statistical gathering code? Can you explain how it works a little more? Would it further affect performance? Would the information be made publicly viewable for analysis? How long would it take to gather sufficient information in order to make a decision? Is this code already implemented in other coins?
From prior discussion here, we were thinking the best option is the 30 second time drift as that would totally eliminate any possibility of a decreasing difficulty timewarp attack since mintcoin has 30 second block target, there is no reason to go lower or higher. And, if other coins are already successful with low time drifts (like 15 seconds), then why not just go ahead and proceed with it in Mintcoin? But, I guess if we need the statistical data, if just to just verify before we proceed, then it is a smart thing to do.

(1.) Moral happiness depends upon moral order.
(2.) Moral order depends upon the harmonious action of all our powers, as
individuals and as members of society.
dragonseer
Hero Member
*****
Offline Offline

Activity: 611
Merit: 500


Anglo Saxon Crypto Enthusiast


View Profile
July 03, 2015, 04:29:04 AM
 #18084

Hello Everyone. Just been updating myself on the discussion. I spoke with cryptomommy about the UI changes and have a few ideas for the update.

I noticed that a lot of the code is from an early Peercoin fork. Big project to bring it more inline with more recent ideas and revelations. I want to propose adding some statistical gathering code to in a point release before the fork so we can see how blocks are propagating through the network, this way we can see how much time drift is reflected and which limit is best. At this point any lower number is better than two hours but what would be best for MintCoin? Lets find out! I'm working on the UI commits and want to add the data collection as well.

A later and bigger project would be bringing down some memory usage and sync times by packing the block chain into chunks and hashing them and and distributing them among the peers building the db during some idle cycles later. Any ideas or examples of that would be appreciated as I said, it would be a big project.

I'm also taking request for other idea as coding work for me slows down this time of year. I love the Idea of MintCoin and want to see it succeed.

Thanks for any input
Okay. I have several questions:
So no hard fork required for adding the statistical gathering code? Can you explain how it works a little more? Would it further affect performance? Would the information be made publicly viewable for analysis? How long would it take to gather sufficient information in order to make a decision? Is this code already implemented in other coins?
From prior discussion here, we were thinking the best option is the 30 second time drift as that would totally eliminate any possibility of a decreasing difficulty timewarp attack since mintcoin has 30 second block target, there is no reason to go lower or higher. And, if other coins are already successful with low time drifts (like 15 seconds), then why not just go ahead and proceed with it in Mintcoin? But, I guess if we need the statistical data, if just to just verify before we proceed, then it is a smart thing to do.


Before selling all my Mintcoin before they go on to reach 200 Sat or whatever I did think that someone should demonstrate this attack before hard forking and changing the fast confirming parameters of Mintcoin.  But regardless let's look at strategy first in terms of how Mintcoin co-exists with other cryptos. Let's say Bitcoin is your 'Reserve Crypto' which is a standard bearer for cryptos as a usable and practical currency alternative in a 21st century environment. The scheme I proposed for http://poisonedchalice.io for instance, supposes that a stable currency with a 4 billion dollar market cap is mature enough to leverage for some fixed term investment over a four year period. You want Bitcoin to be relatively stable as the lynchpin to this kind of financial product (stable after a 2015 Q4 correction, that is).

Mintcoin on the other hand, can adopt a slower confirmation time, IF it is leaning more towards the investment side of things, and less towards the Point of Sale transactions/merchant space. This space is better filled by something like Zetacoin or Quark, which are superior alternatives to Bitcoin in this instance, held back only by a lack of productive community output and shallow trading volumes at this stage. But these are not POS coins, maybe you want to stick a percentage of savings into a POS coin and security becomes much more important.  So if an answer to timedrift is to increase the confirmation time, that means you are making a trade off where Mintcoin becomes more secure at the loss of 30, 60, 90 seconds on average (or whatever it is) each time you shift it around. I think that's a trade off most community members would be happy to make.  Personally I have just got 4 BTC out of Mintcoin, but, that's after buying and holding over the space of a year or so (I'll buy back under 29 Sat and before another rate drop) so as you can see fast confirmation times haven't really been all that important so far.

Crypto sales and more here: https://www.ebay.com.au/usr/dragon-seer
Derek492
Sr. Member
****
Offline Offline

Activity: 356
Merit: 250



View Profile
July 03, 2015, 06:25:49 AM
 #18085


Before selling all my Mintcoin before they go on to reach 200 Sat or whatever I did think that someone should demonstrate this attack before hard forking and changing the fast confirming parameters of Mintcoin.  But regardless let's look at strategy first in terms of how Mintcoin co-exists with other cryptos. Let's say Bitcoin is your 'Reserve Crypto' which is a standard bearer for cryptos as a usable and practical currency alternative in a 21st century environment. The scheme I proposed for http://poisonedchalice.io for instance, supposes that a stable currency with a 4 billion dollar market cap is mature enough to leverage for some fixed term investment over a four year period. You want Bitcoin to be relatively stable as the lynchpin to this kind of financial product (stable after a 2015 Q4 correction, that is).

Mintcoin on the other hand, can adopt a slower confirmation time, IF it is leaning more towards the investment side of things, and less towards the Point of Sale transactions/merchant space. This space is better filled by something like Zetacoin or Quark, which are superior alternatives to Bitcoin in this instance, held back only by a lack of productive community output and shallow trading volumes at this stage. But these are not POS coins, maybe you want to stick a percentage of savings into a POS coin and security becomes much more important.  So if an answer to timedrift is to increase the confirmation time, that means you are making a trade off where Mintcoin becomes more secure at the loss of 30, 60, 90 seconds on average (or whatever it is) each time you shift it around. I think that's a trade off most community members would be happy to make.  Personally I have just got 4 BTC out of Mintcoin, but, that's after buying and holding over the space of a year or so (I'll buy back under 29 Sat and before another rate drop) so as you can see fast confirmation times haven't really been all that important so far.
We are not talking about changing the confirmation time. Just the number of confirmations. Confirmation time will stay at 30 seconds which is still 20x faster than Bitcoin. You don't personally have to wait for all of the confirmations to know that it's going through, often after the first couple you know it's probably going to be all good and you can move along. Example, you initiate a transaction and in 30 seconds it is confirmed. Even with 40 confirmations, all 40 will complete in 20 minutes, which is still 3x faster than Bitcoin.

Stop Mining.   Start Minting.   Mintcoin  [MINT]
5% annual minting reward. Mintcoins don't wear out like mining gear. They keep on minting!
supasonic
Newbie
*
Offline Offline

Activity: 4
Merit: 0


View Profile
July 03, 2015, 01:21:06 PM
 #18086


Okay. I have several questions:
So no hard fork required for adding the statistical gathering code? Can you explain how it works a little more? Would it further affect performance? Would the information be made publicly viewable for analysis? How long would it take to gather sufficient information in order to make a decision? Is this code already implemented in other coins?
From prior discussion here, we were thinking the best option is the 30 second time drift as that would totally eliminate any possibility of a decreasing difficulty timewarp attack since mintcoin has 30 second block target, there is no reason to go lower or higher. And, if other coins are already successful with low time drifts (like 15 seconds), then why not just go ahead and proceed with it in Mintcoin? But, I guess if we need the statistical data, if just to just verify before we proceed, then it is a smart thing to do.


Just a suggestion a by no means a mandatory thing. The code would be about the client and its timing differences, not about the block chain. Most IBM PC variants lose about a second a day. Most OS'es adjust weekly for it and some applications adjust sooner. Ping times can be used to account for network latency on a node to node basis.

 I'm still delving into the innards of the codebase to see how efficiently the protocol is being implemented locally but a drift not set low enough still leaves MintCoin open to attacks although the effects decrease the lower the drift. The information would be public and could become part of the protocol if it helps since we will be forking.  I not aware of other coins that are implementing outside of the testnets.

If the consensus is 30 sec then it works. I myself am still reading up on the detail of this attack, a lot of details on POW coins and most of the POS stuff I'm reading is a little less. I like to see this discussion. Personally i think 30 seconds on a global network can cause issues, nothing to back it up yet still reading nd playing with test net.
presstab
Legendary
*
Offline Offline

Activity: 1330
Merit: 1000


Blockchain Developer


View Profile
July 03, 2015, 01:43:46 PM
 #18087


Okay. I have several questions:
So no hard fork required for adding the statistical gathering code? Can you explain how it works a little more? Would it further affect performance? Would the information be made publicly viewable for analysis? How long would it take to gather sufficient information in order to make a decision? Is this code already implemented in other coins?
From prior discussion here, we were thinking the best option is the 30 second time drift as that would totally eliminate any possibility of a decreasing difficulty timewarp attack since mintcoin has 30 second block target, there is no reason to go lower or higher. And, if other coins are already successful with low time drifts (like 15 seconds), then why not just go ahead and proceed with it in Mintcoin? But, I guess if we need the statistical data, if just to just verify before we proceed, then it is a smart thing to do.


Just a suggestion a by no means a mandatory thing. The code would be about the client and its timing differences, not about the block chain. Most IBM PC variants lose about a second a day. Most OS'es adjust weekly for it and some applications adjust sooner. Ping times can be used to account for network latency on a node to node basis.

 I'm still delving into the innards of the codebase to see how efficiently the protocol is being implemented locally but a drift not set low enough still leaves MintCoin open to attacks although the effects decrease the lower the drift. The information would be public and could become part of the protocol if it helps since we will be forking.  I not aware of other coins that are implementing outside of the testnets.

If the consensus is 30 sec then it works. I myself am still reading up on the detail of this attack, a lot of details on POW coins and most of the POS stuff I'm reading is a little less. I like to see this discussion. Personally i think 30 seconds on a global network can cause issues, nothing to back it up yet still reading nd playing with test net.

Keep in mind that the code adjusts each nodes time. So you could be over 30 seconds out of time but still be issuing the correct timestamps to the network when you stake.

Projects I Contribute To: libzerocoin | Veil | PIVX | HyperStake | Crown | SaluS
Derek492
Sr. Member
****
Offline Offline

Activity: 356
Merit: 250



View Profile
July 03, 2015, 01:52:47 PM
 #18088


Okay. I have several questions:
So no hard fork required for adding the statistical gathering code? Can you explain how it works a little more? Would it further affect performance? Would the information be made publicly viewable for analysis? How long would it take to gather sufficient information in order to make a decision? Is this code already implemented in other coins?
From prior discussion here, we were thinking the best option is the 30 second time drift as that would totally eliminate any possibility of a decreasing difficulty timewarp attack since mintcoin has 30 second block target, there is no reason to go lower or higher. And, if other coins are already successful with low time drifts (like 15 seconds), then why not just go ahead and proceed with it in Mintcoin? But, I guess if we need the statistical data, if just to just verify before we proceed, then it is a smart thing to do.


Just a suggestion a by no means a mandatory thing. The code would be about the client and its timing differences, not about the block chain. Most IBM PC variants lose about a second a day. Most OS'es adjust weekly for it and some applications adjust sooner. Ping times can be used to account for network latency on a node to node basis.

 I'm still delving into the innards of the codebase to see how efficiently the protocol is being implemented locally but a drift not set low enough still leaves MintCoin open to attacks although the effects decrease the lower the drift. The information would be public and could become part of the protocol if it helps since we will be forking.  I not aware of other coins that are implementing outside of the testnets.

If the consensus is 30 sec then it works. I myself am still reading up on the detail of this attack, a lot of details on POW coins and most of the POS stuff I'm reading is a little less. I like to see this discussion. Personally i think 30 seconds on a global network can cause issues, nothing to back it up yet still reading nd playing with test net.
If it is an optional wallet, then sure. ...If you don't need to hard fork it to implement that code, and it is simple enough to do with a standard non mandatory updated wallet version release, why not just push it out for us to use real quick, even if it is just a few days. Maybe not everyone will update to the new wallet but it will be good to get feedback, and also help us know how much time we need to give people for them to get updated in preparation for a hard fork. I am sure there will be plenty of people willing to run it to help us make the best decisions. In the meantime we should get everything ready to go for proposed hard fork, and do whatever neccessary testing we can there too.

Stop Mining.   Start Minting.   Mintcoin  [MINT]
5% annual minting reward. Mintcoins don't wear out like mining gear. They keep on minting!
cryptomommy
Sr. Member
****
Offline Offline

Activity: 425
Merit: 250


View Profile
July 03, 2015, 01:58:07 PM
 #18089

Before selling all my Mintcoin before they go on to reach 200 Sat or whatever I did think that someone should demonstrate this attack before hard forking and changing the fast confirming parameters of Mintcoin.  But regardless let's look at strategy first in terms of how Mintcoin co-exists with other cryptos. Let's say Bitcoin is your 'Reserve Crypto' which is a standard bearer for cryptos as a usable and practical currency alternative in a 21st century environment. The scheme I proposed for http://poisonedchalice.io for instance, supposes that a stable currency with a 4 billion dollar market cap is mature enough to leverage for some fixed term investment over a four year period. You want Bitcoin to be relatively stable as the lynchpin to this kind of financial product (stable after a 2015 Q4 correction, that is).

Mintcoin on the other hand, can adopt a slower confirmation time, IF it is leaning more towards the investment side of things, and less towards the Point of Sale transactions/merchant space. This space is better filled by something like Zetacoin or Quark, which are superior alternatives to Bitcoin in this instance, held back only by a lack of productive community output and shallow trading volumes at this stage. But these are not POS coins, maybe you want to stick a percentage of savings into a POS coin and security becomes much more important.  So if an answer to timedrift is to increase the confirmation time, that means you are making a trade off where Mintcoin becomes more secure at the loss of 30, 60, 90 seconds on average (or whatever it is) each time you shift it around. I think that's a trade off most community members would be happy to make.  Personally I have just got 4 BTC out of Mintcoin, but, that's after buying and holding over the space of a year or so (I'll buy back under 29 Sat and before another rate drop) so as you can see fast confirmation times haven't really been all that important so far.

I agree on that note - one thing we should not alter is the speed of Mintcoin - Its flipping amazing and extremely helpful whether sending / receiving to exchanges or a friend. We need the speed.

Have you or any of the community ever put any though into reducing the target block time? Current looks like 30 seconds. My concern would be long term syncability of the chain. It isn't too easy to sync it at the current 1.5 million blocks, and a few years from now it will be even harder. Raising the block time could be a beneficial long term change to throw in while a hard fork occurs.
This sounds very sensible to me with the understanding that our block chain is going to continue to grow - questions?

  • is it any less secure and why / why not?
    will this affect the speed of the coin in transactions (including confirmations)
  • Does it require a hard fork

I would say that mints biggest security risk is the 2 hour time drift allowance. Read about the vulnerability here http://bitcoinist.net/interview-presstab-pos-vulnerabilities/
The goal is to have as little vulnerability to timedrift as possible, while not compromising the ability to stake. Blackcoin and all of its derivatives are using 16 second timedrift now. I am using 60 second for HyperStake. But would think something along the lines of 3 minutes would work well for MINT.

PressTab - Can you give us three recommended timedrift parameters from high to low and explain how the timedrift will affect the coins speed / confirmation time on the exchanges / security benefits

I would like to have these decisions finalized by the end of the day so PressTab can begin phase 1 of the wallet.



Derek492
Sr. Member
****
Offline Offline

Activity: 356
Merit: 250



View Profile
July 03, 2015, 01:59:51 PM
 #18090



Keep in mind that the code adjusts each nodes time. So you could be over 30 seconds out of time but still be issuing the correct timestamps to the network when you stake.

Yeah. This is why I'm not too worried about it. I mean occasionally there may be a leap second, (not sure if that would affect it). I think there was one a few days ago actually to get universal standard time back in being correct with the suns alignment.

Stop Mining.   Start Minting.   Mintcoin  [MINT]
5% annual minting reward. Mintcoins don't wear out like mining gear. They keep on minting!
mchrist152
Newbie
*
Offline Offline

Activity: 23
Merit: 0


View Profile
July 03, 2015, 02:06:01 PM
 #18091

Kind of off topic but I'm an owner of mintcoin and a developer so I thought I'd try to go through the code. I've downloaded the code and I was going to build it but I wonder what the recommended IDE is.  Are you guys use QT-Creator?  That's what robo guy said he was using.  I'm mostly a windows guy.  Is it possible to successfully build the mintcoin wallet in windows or is that not recommended?  Thanks is advance.
Derek492
Sr. Member
****
Offline Offline

Activity: 356
Merit: 250



View Profile
July 03, 2015, 02:07:47 PM
 #18092

Before selling all my Mintcoin before they go on to reach 200 Sat or whatever I did think that someone should demonstrate this attack before hard forking and changing the fast confirming parameters of Mintcoin.  But regardless let's look at strategy first in terms of how Mintcoin co-exists with other cryptos. Let's say Bitcoin is your 'Reserve Crypto' which is a standard bearer for cryptos as a usable and practical currency alternative in a 21st century environment. The scheme I proposed for http://poisonedchalice.io for instance, supposes that a stable currency with a 4 billion dollar market cap is mature enough to leverage for some fixed term investment over a four year period. You want Bitcoin to be relatively stable as the lynchpin to this kind of financial product (stable after a 2015 Q4 correction, that is).

Mintcoin on the other hand, can adopt a slower confirmation time, IF it is leaning more towards the investment side of things, and less towards the Point of Sale transactions/merchant space. This space is better filled by something like Zetacoin or Quark, which are superior alternatives to Bitcoin in this instance, held back only by a lack of productive community output and shallow trading volumes at this stage. But these are not POS coins, maybe you want to stick a percentage of savings into a POS coin and security becomes much more important.  So if an answer to timedrift is to increase the confirmation time, that means you are making a trade off where Mintcoin becomes more secure at the loss of 30, 60, 90 seconds on average (or whatever it is) each time you shift it around. I think that's a trade off most community members would be happy to make.  Personally I have just got 4 BTC out of Mintcoin, but, that's after buying and holding over the space of a year or so (I'll buy back under 29 Sat and before another rate drop) so as you can see fast confirmation times haven't really been all that important so far.

I agree on that note - one thing we should not alter is the speed of Mintcoin - Its flipping amazing and extremely helpful whether sending / receiving to exchanges or a friend. We need the speed.

Have you or any of the community ever put any though into reducing the target block time? Current looks like 30 seconds. My concern would be long term syncability of the chain. It isn't too easy to sync it at the current 1.5 million blocks, and a few years from now it will be even harder. Raising the block time could be a beneficial long term change to throw in while a hard fork occurs.
This sounds very sensible to me with the understanding that our block chain is going to continue to grow - questions?

  • is it any less secure and why / why not?
    will this affect the speed of the coin in transactions (including confirmations)
  • Does it require a hard fork

I would say that mints biggest security risk is the 2 hour time drift allowance. Read about the vulnerability here http://bitcoinist.net/interview-presstab-pos-vulnerabilities/
The goal is to have as little vulnerability to timedrift as possible, while not compromising the ability to stake. Blackcoin and all of its derivatives are using 16 second timedrift now. I am using 60 second for HyperStake. But would think something along the lines of 3 minutes would work well for MINT.

PressTab - Can you give us three recommended timedrift parameters from high to low and explain how the timedrift will affect the coins speed / confirmation time on the exchanges / security benefits

I would like to have these decisions finalized by the end of the day so PressTab can begin phase 1 of the wallet.
30 block time translates to 30 second confirmations. As far as I know, we are all in consensus we are not going to change that.
What we were talking about earlier is increasing how many confirmations are required as the network standard. 4 which mintcoin currently us at is very low (low security). An attacker, would only need to control the network for 2 minutes in order to 51% attack it.  Increasing the # of confirmations to 40 would be exponentially more secure.

Stop Mining.   Start Minting.   Mintcoin  [MINT]
5% annual minting reward. Mintcoins don't wear out like mining gear. They keep on minting!
presstab
Legendary
*
Offline Offline

Activity: 1330
Merit: 1000


Blockchain Developer


View Profile
July 03, 2015, 02:14:00 PM
 #18093



Keep in mind that the code adjusts each nodes time. So you could be over 30 seconds out of time but still be issuing the correct timestamps to the network when you stake.

Yeah. This is why I'm not too worried about it. I mean occasionally there may be a leap second, (not sure if that would affect it). I think there was one a few days ago actually to get universal standard time back in being correct with the suns alignment.

The underlying security flaw really doesn't have anything to do with whether or not nodes are correctly in sync. The conversation about whats the correct time drift to use is more about security update than it is about having the perfect balance of time.

I think 15/30 should work well. How much longer do you guys want to delay this? I have already started coding it in, but can hold off any final commits until there is a clear consesus about the hashdrift, interval, and fork time.

Projects I Contribute To: libzerocoin | Veil | PIVX | HyperStake | Crown | SaluS
URSAY
Legendary
*
Offline Offline

Activity: 1946
Merit: 1000



View Profile
July 03, 2015, 02:56:04 PM
 #18094

Is this code already implemented in other coins?

If yes, which?
cryptomommy
Sr. Member
****
Offline Offline

Activity: 425
Merit: 250


View Profile
July 03, 2015, 03:15:43 PM
 #18095

Is this code already implemented in other coins?

If yes, which?

PressTab has implemented this code in his own personal project HyperStake - another great coin making headway
cryptomommy
Sr. Member
****
Offline Offline

Activity: 425
Merit: 250


View Profile
July 03, 2015, 03:19:54 PM
 #18096

I think 15/30 should work well. How much longer do you guys want to delay this? I have already started coding it in, but can hold off any final commits until there is a clear consesus about the hashdrift, interval, and fork time.

Please continue with 15/30 listening to the community this seems to be the most agreed upon. Once this is completed SupaSonic will implement the GUI modifications while I contact the exchanges with the raw wallet (only modification including the fork)

For the time please allow 30 days - this should give me plenty of time to work with the exchanges - they usually take 15 days or so to complete upgrades. I can also let them know when the expected fork will happen.

RoboGuy stuck in a network alert a few upgrades ago - please make sure to update the message to alert everyone when they open the wallet to upgrade to the newest version to help us get out the message.

Derek492
Sr. Member
****
Offline Offline

Activity: 356
Merit: 250



View Profile
July 03, 2015, 04:24:07 PM
 #18097

Is this code already implemented in other coins?

If yes, which?

PressTab has implemented this code in his own personal project HyperStake - another great coin making headway
Cool beans was referring to suprasonics statistics coding, not presstab timedrift coding.

Stop Mining.   Start Minting.   Mintcoin  [MINT]
5% annual minting reward. Mintcoins don't wear out like mining gear. They keep on minting!
Derek492
Sr. Member
****
Offline Offline

Activity: 356
Merit: 250



View Profile
July 03, 2015, 04:26:38 PM
 #18098

I think 15/30 should work well. How much longer do you guys want to delay this? I have already started coding it in, but can hold off any final commits until there is a clear consesus about the hashdrift, interval, and fork time.

Please continue with 15/30 listening to the community this seems to be the most agreed upon. Once this is completed SupaSonic will implement the GUI modifications while I contact the exchanges with the raw wallet (only modification including the fork)

For the time please allow 30 days - this should give me plenty of time to work with the exchanges - they usually take 15 days or so to complete upgrades. I can also let them know when the expected fork will happen.

RoboGuy stuck in a network alert a few upgrades ago - please make sure to update the message to alert everyone when they open the wallet to upgrade to the newest version to help us get out the message.


Sounds good. I guess the higher the price goes the more secure it is too, by making it harder more consequential to attack, so that's a good thing.

Stop Mining.   Start Minting.   Mintcoin  [MINT]
5% annual minting reward. Mintcoins don't wear out like mining gear. They keep on minting!
cryptomommy
Sr. Member
****
Offline Offline

Activity: 425
Merit: 250


View Profile
July 03, 2015, 04:28:57 PM
Last edit: July 03, 2015, 04:44:28 PM by cryptomommy
 #18099

Cool beans was referring to suprasonics statistics coding, not presstab timedrift coding.

Dope! Gotcha

The statistics coding is something I have been trying to figure out for awhile now - If this does not interfere with the wallet itself I would love to test it out (especially if we can swap if need be back without a hard fork)
Derek492
Sr. Member
****
Offline Offline

Activity: 356
Merit: 250



View Profile
July 03, 2015, 04:46:36 PM
 #18100

So the fork will be at about 85,000 blocks from now?

Stop Mining.   Start Minting.   Mintcoin  [MINT]
5% annual minting reward. Mintcoins don't wear out like mining gear. They keep on minting!
Pages: « 1 ... 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 [905] 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 ... 1035 »
  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!