Bitcoin Forum
October 16, 2018, 06:02:28 PM *
News: Make sure you are not using versions of Bitcoin Core other than 0.17.0 [Torrent], 0.16.3, 0.15.2, or 0.14.3. More info.
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 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 956 ... 1035 »
  Print  
Author Topic: [ANN] [MINT] Mintcoin (POS / 5%) [NO ICO] [Fair distro, community maintained]  (Read 1341993 times)
Derek492
Sr. Member
****
Offline Offline

Activity: 357
Merit: 250



View Profile
July 02, 2015, 05:38:41 AM
 #18101

I don't think going blackcoin is really on the table at the moment. And honestly if it is, someone can add that on top of my commits.

So what we now need to decide is if the final decision is 15 second hashdrift/interval and a 30 second timedrift allowance. The other item that will need to be decided is when this fork will occur. MINT is large enough and has enough people and companies running nodes, that it should be at a few weeks from now. This will be a hard fork, so a protocol change cutting off nodes that haven't updated. If we don't cut off all old nodes, then they will get on an incorrect chain and will still be connected to the real chain's nodes and will exhaust their resources by requesting the same thing over and over. Its possible to pull this off in a "soft" approach, but the memory and bandwidth exhaustion is not nearly worth it.

Yep.

So basically, we release an updated wallet right now for everyone to upgrade to that will cause a the change (fork) to take effect starting in a few weeks from now. Right?
15 second hashdrift/search interval and 30 second timedrift sounds good to me.
What about increasing the confirmations? I think it would be a good idea. If we did do 40 that would be high enough that we wouldn't need to lower the minimum waiting period to stake, thus allowing more people to mint, but still maintain good security.

Stop Mining.   Start Minting.   Mintcoin  [MINT]
5% annual minting reward. Mintcoins don't wear out like mining gear. They keep on minting!
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1539712948
Hero Member
*
Offline Offline

Posts: 1539712948

View Profile Personal Message (Offline)

Ignore
1539712948
Reply with quote  #2

1539712948
Report to moderator
1539712948
Hero Member
*
Offline Offline

Posts: 1539712948

View Profile Personal Message (Offline)

Ignore
1539712948
Reply with quote  #2

1539712948
Report to moderator
1539712948
Hero Member
*
Offline Offline

Posts: 1539712948

View Profile Personal Message (Offline)

Ignore
1539712948
Reply with quote  #2

1539712948
Report to moderator
Derek492
Sr. Member
****
Offline Offline

Activity: 357
Merit: 250



View Profile
July 02, 2015, 05:43:11 AM
 #18102


My point is that 20 day waiting time deters people from remaining online while they gain nothing, this makes n/w less secure. Is this correct? If yes then changing waiting time to say 1 day will incentivize people to keep there wallets open as they will be staking and getting rewards. I am not vouching for lowest waiting time but for a balanced reduction so that people are online most of the time.

I am aware that there is max cap to weight but it is large enough that you can easily stake if you have any amount of coins that are significant. If you just want everyone even with a single coin to stake while its not good for the network then i don't get your logic. Security of network is more important than making sure that everyone get their rewards. If having a lower cap is inevitable to secure the network what should we choose?

Do you think there is not a problem of low network weight right now? Am I just making it up so that i can argue about introducing PoS 2.0? I would be more than happy if we can solve the problem w/o going to PoS 2.0, its just my opinion that it is a better system. I have suggested other ways previously of solving this problem that i see. So, if you are not worried about rocking the boat then please try to see my point of view.

@presstab I am just asking your informed opinion about PoS 2.0 so that if i have any delusions or unaware of some fault in it then i get to know about it. Nothing about implementing it.
I understand your point, but I would rather increase confirmations to increase security, than reduce the amount of people able to mint. Confirmations is the other way to accomplish the same security goal.  Mintcoin is about minting, and if people cannot stake/mint then I think you will lose a lot of potential users right there.

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

Activity: 854
Merit: 1000



View Profile
July 02, 2015, 06:07:31 AM
 #18103

I understand your point, but I would rather increase confirmations to increase security, than reduce the amount of people able to mint. Confirmations is the other way to accomplish the same security goal.  Mintcoin is about minting, and if people cannot stake/mint then I think you will lose a lot of potential users right there.

Thanks for understanding. The issue you are discussing is timewarp attack which will be solved by discussed adjustments. I am talking about low network weight which wont be solved by these adjustments. We need people to remain online to strengthen the network.

Rent Rigs @ MiningRigRentals: https://www.miningrigrentals.com/register?ref=9685 | Mine Zcash, X11, ETH, BTC, LTC hashrate available @ Genesis Mining: 9yx2ib (Promo Code for 3% off)
Sell & Buy/Rent hashing power @ Nicehash.com: https://www.nicehash.com/?refby=63551
Trade BTCINR on Coinsecure.in (Global trade available: http://blog.coinsecure.in/post/153309186530/coinsecure-goes-global-by-reducing-the-barrier-for): https://coinsecure.in/signup/z5ehHIOLvHN5sWAq3wTu
sambiohazard
Hero Member
*****
Offline Offline

Activity: 854
Merit: 1000



View Profile
July 02, 2015, 06:20:34 AM
 #18104

Here is why i don't like the current arrangement of people coming online once in 20 days or expecting rewards for keeping coins in their wallet while not securing the network. Also this explains why who invest more should be rewarded proportionately.

http://shreysfinanceblog.com/2015/06/24/why-socialism-fails/

Rent Rigs @ MiningRigRentals: https://www.miningrigrentals.com/register?ref=9685 | Mine Zcash, X11, ETH, BTC, LTC hashrate available @ Genesis Mining: 9yx2ib (Promo Code for 3% off)
Sell & Buy/Rent hashing power @ Nicehash.com: https://www.nicehash.com/?refby=63551
Trade BTCINR on Coinsecure.in (Global trade available: http://blog.coinsecure.in/post/153309186530/coinsecure-goes-global-by-reducing-the-barrier-for): https://coinsecure.in/signup/z5ehHIOLvHN5sWAq3wTu
cryptomommy
Sr. Member
****
Offline Offline

Activity: 425
Merit: 250


View Profile
July 02, 2015, 11:58:10 AM
 #18105

I don't think going blackcoin is really on the table at the moment. And honestly if it is, someone can add that on top of my commits.

So what we now need to decide is if the final decision is 15 second hashdrift/interval and a 30 second timedrift allowance. The other item that will need to be decided is when this fork will occur. MINT is large enough and has enough people and companies running nodes, that it should be at a few weeks from now. This will be a hard fork, so a protocol change cutting off nodes that haven't updated. If we don't cut off all old nodes, then they will get on an incorrect chain and will still be connected to the real chain's nodes and will exhaust their resources by requesting the same thing over and over. Its possible to pull this off in a "soft" approach, but the memory and bandwidth exhaustion is not nearly worth it.

Agreed - We have allot of work to do on top of the fork in order to ensure that we provide the best possible user experience for the community during the transition to the new wallet. Once PressTab has completed his changes we will need to test out the changes in a private group - during that time supasonic has volunteered to add the GUI modifications for the following:

make repairwallet easier to find (under Help)
When the wallet opens it would be nice to have the client choose between import wallet or create new wallet.
Require verification of password when sending mintcoins - if password option is enabled

He is also researching this comment:

As for syncing time, dooglus from CLAM has made a very interesting commit this last week that I want to play around with. It has to do with bootstrap files that are not all in one file. For example a bootstrap that is block 1-100k, 100k-200k, etc. This adds the ability to start with the appropriate bootstrap file if you are partially synced. I haven't toyed around with it enough yet, but it shows promise.

Once those changes are implemented and tested we will need a mass distribution to exchanges and community members.

The fork will need to be out long enough to ensure we complete all of these tasks for the community members to ensure there are minimal bad vibes during the upgrade.

Do you think 30 days is enough time for the fork for exchanges & community members?

We can send the exchanges a heads up now with a fork estimated date so they can plan ahead and ensure the manpower is available to make the change.
litemaster
Full Member
***
Offline Offline

Activity: 169
Merit: 100


View Profile
July 02, 2015, 02:08:51 PM
 #18106

How long before my coins in wallet start minting?

They been maturing for 2 days now

It takes them 20 days to become mature for minting.

Fucking hell...

I know right?Huh? I have answered this question a few time myself on here. The site need to put this featured more prominently or something.

BITCOIN: 13UY67yfRjRVMR6hauZJbauHiDfeM2qXSg
MINTCOIN: MdVzxTfLDrzdij9vpee1YJGotBahfsfmqs
ASIACOIN: AH7dunb5G99XzCNj1KnGCdPkqc27pRPfBu
Derek492
Sr. Member
****
Offline Offline

Activity: 357
Merit: 250



View Profile
July 02, 2015, 03:24:20 PM
 #18107

I don't think going blackcoin is really on the table at the moment. And honestly if it is, someone can add that on top of my commits.

So what we now need to decide is if the final decision is 15 second hashdrift/interval and a 30 second timedrift allowance. The other item that will need to be decided is when this fork will occur. MINT is large enough and has enough people and companies running nodes, that it should be at a few weeks from now. This will be a hard fork, so a protocol change cutting off nodes that haven't updated. If we don't cut off all old nodes, then they will get on an incorrect chain and will still be connected to the real chain's nodes and will exhaust their resources by requesting the same thing over and over. Its possible to pull this off in a "soft" approach, but the memory and bandwidth exhaustion is not nearly worth it.

Agreed - We have allot of work to do on top of the fork in order to ensure that we provide the best possible user experience for the community during the transition to the new wallet. Once PressTab has completed his changes we will need to test out the changes in a private group - during that time supasonic has volunteered to add the GUI modifications for the following:

make repairwallet easier to find (under Help)
When the wallet opens it would be nice to have the client choose between import wallet or create new wallet.
Require verification of password when sending mintcoins - if password option is enabled

He is also researching this comment:

As for syncing time, dooglus from CLAM has made a very interesting commit this last week that I want to play around with. It has to do with bootstrap files that are not all in one file. For example a bootstrap that is block 1-100k, 100k-200k, etc. This adds the ability to start with the appropriate bootstrap file if you are partially synced. I haven't toyed around with it enough yet, but it shows promise.

Once those changes are implemented and tested we will need a mass distribution to exchanges and community members.

The fork will need to be out long enough to ensure we complete all of these tasks for the community members to ensure there are minimal bad vibes during the upgrade.

Do you think 30 days is enough time for the fork for exchanges & community members?

We can send the exchanges a heads up now with a fork estimated date so they can plan ahead and ensure the manpower is available to make the change.
At least get in contact with the exchanges, and probably ask them how much time they need to make the upgrade.

So to confirm, is everyone in agreement on changing the hashdrift/search interval to 15 seconds, the timedrift to 30 seconds, and the confirmations to 40? This will greatly bulletproof the security of Mintcoin.

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

Activity: 613
Merit: 500


Mintcoin: Get some


View Profile
July 02, 2015, 04:10:34 PM
 #18108


At least get in contact with the exchanges, and probably ask them how much time they need to make the upgrade.

So to confirm, is everyone in agreement on changing the hashdrift/search interval to 15 seconds, the timedrift to 30 seconds, and the confirmations to 40? This will greatly bulletproof the security of Mintcoin.
Sounds good to me.

Presstab, have you had a chance to look at the code and verify the situation regarding any coin cap?

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

Activity: 616
Merit: 500


Online since '89...


View Profile WWW
July 02, 2015, 04:20:46 PM
 #18109

I don't think going blackcoin is really on the table at the moment. And honestly if it is, someone can add that on top of my commits.

So what we now need to decide is if the final decision is 15 second hashdrift/interval and a 30 second timedrift allowance. The other item that will need to be decided is when this fork will occur. MINT is large enough and has enough people and companies running nodes, that it should be at a few weeks from now. This will be a hard fork, so a protocol change cutting off nodes that haven't updated. If we don't cut off all old nodes, then they will get on an incorrect chain and will still be connected to the real chain's nodes and will exhaust their resources by requesting the same thing over and over. Its possible to pull this off in a "soft" approach, but the memory and bandwidth exhaustion is not nearly worth it.

Agreed - We have allot of work to do on top of the fork in order to ensure that we provide the best possible user experience for the community during the transition to the new wallet. Once PressTab has completed his changes we will need to test out the changes in a private group - during that time supasonic has volunteered to add the GUI modifications for the following:

make repairwallet easier to find (under Help)
When the wallet opens it would be nice to have the client choose between import wallet or create new wallet.
Require verification of password when sending mintcoins - if password option is enabled

He is also researching this comment:

As for syncing time, dooglus from CLAM has made a very interesting commit this last week that I want to play around with. It has to do with bootstrap files that are not all in one file. For example a bootstrap that is block 1-100k, 100k-200k, etc. This adds the ability to start with the appropriate bootstrap file if you are partially synced. I haven't toyed around with it enough yet, but it shows promise.

Once those changes are implemented and tested we will need a mass distribution to exchanges and community members.

The fork will need to be out long enough to ensure we complete all of these tasks for the community members to ensure there are minimal bad vibes during the upgrade.

Do you think 30 days is enough time for the fork for exchanges & community members?

We can send the exchanges a heads up now with a fork estimated date so they can plan ahead and ensure the manpower is available to make the change.
At least get in contact with the exchanges, and probably ask them how much time they need to make the upgrade.

So to confirm, is everyone in agreement on changing the hashdrift/search interval to 15 seconds, the timedrift to 30 seconds, and the confirmations to 40? This will greatly bulletproof the security of Mintcoin.


Seems reasonable, go for it....

DNotesVault
“First, they ignore you. Then, they laugh at you. Then, they fight you. Then you win!” – Mahatma Gandhi 
Prepare for your future now, check out CRISP For Retirement and our complete family of CRISP savings plans.
coolbeans94
Hero Member
*****
Offline Offline

Activity: 613
Merit: 500


Mintcoin: Get some


View Profile
July 02, 2015, 04:34:21 PM
 #18110

I'm positive if we pull this off mintcoin is going to soar and may one day even overtake bitcoin itself.

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

Activity: 1316
Merit: 1000


Pivx Core Developer - HyperStake Founder


View Profile
July 02, 2015, 04:45:28 PM
 #18111


At least get in contact with the exchanges, and probably ask them how much time they need to make the upgrade.

So to confirm, is everyone in agreement on changing the hashdrift/search interval to 15 seconds, the timedrift to 30 seconds, and the confirmations to 40? This will greatly bulletproof the security of Mintcoin.
Sounds good to me.

Presstab, have you had a chance to look at the code and verify the situation regarding any coin cap?

Yes I looked, sorry forgot to reply to this particular issue. It looks like it is as I expected, and the "max coins" doesn't have anything to do with controlling rewards at a particular point in time, and is simply a cap on the maximum transaction amount allowed for the network.

presstab's Block Explorer Service | available for most coins! | Richlist w/ Address Claim | Market Cap Charts | Stake Weight Tracking | PoS % Rate Tracking
PIVX - Private Instant Verified Tx | HyperStake - Fun & Easy High Reward Staking
Flyskyhigh
Sr. Member
****
Offline Offline

Activity: 292
Merit: 250


Ezekiel 34:11, John 10:25-30


View Profile
July 02, 2015, 05:13:27 PM
 #18112


At least get in contact with the exchanges, and probably ask them how much time they need to make the upgrade.

So to confirm, is everyone in agreement on changing the hashdrift/search interval to 15 seconds, the timedrift to 30 seconds, and the confirmations to 40? This will greatly bulletproof the security of Mintcoin.
Sounds good to me.

Presstab, have you had a chance to look at the code and verify the situation regarding any coin cap?

Yes I looked, sorry forgot to reply to this particular issue. It looks like it is as I expected, and the "max coins" doesn't have anything to do with controlling rewards at a particular point in time, and is simply a cap on the maximum transaction amount allowed for the network.
So basically it will just be 5% gain per year forever. Cool. I actually think that is better because it will always motivate people to keep minting. Like a goid savings bond not too low, but not too high. BTW, Mintcoin just hit a new all time high.  80 sats! ^ ^

Sick of mining?  Start minting!  5% per year!  Mintcoin "MINT"
coolbeans94
Hero Member
*****
Offline Offline

Activity: 613
Merit: 500


Mintcoin: Get some


View Profile
July 02, 2015, 05:39:34 PM
 #18113


At least get in contact with the exchanges, and probably ask them how much time they need to make the upgrade.

So to confirm, is everyone in agreement on changing the hashdrift/search interval to 15 seconds, the timedrift to 30 seconds, and the confirmations to 40? This will greatly bulletproof the security of Mintcoin.
Sounds good to me.

Presstab, have you had a chance to look at the code and verify the situation regarding any coin cap?

Yes I looked, sorry forgot to reply to this particular issue. It looks like it is as I expected, and the "max coins" doesn't have anything to do with controlling rewards at a particular point in time, and is simply a cap on the maximum transaction amount allowed for the network.
If that is the case, we need to update the announcement page to be clear, and any place that gives the coin description.

Edit: I updated it on Reddit.

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

Activity: 854
Merit: 1000



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

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

Rent Rigs @ MiningRigRentals: https://www.miningrigrentals.com/register?ref=9685 | Mine Zcash, X11, ETH, BTC, LTC hashrate available @ Genesis Mining: 9yx2ib (Promo Code for 3% off)
Sell & Buy/Rent hashing power @ Nicehash.com: https://www.nicehash.com/?refby=63551
Trade BTCINR on Coinsecure.in (Global trade available: http://blog.coinsecure.in/post/153309186530/coinsecure-goes-global-by-reducing-the-barrier-for): https://coinsecure.in/signup/z5ehHIOLvHN5sWAq3wTu
supasonic
Newbie
*
Offline Offline

Activity: 4
Merit: 0


View Profile
July 03, 2015, 12:34:32 AM
 #18115

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
 #18116

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: 610
Merit: 500


Anglo Saxon Crypto Enthusiast


View Profile WWW
July 03, 2015, 04:29:04 AM
 #18117

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.

Visit http://aswp.life ~ Payments accepted in DASH! Purchase Firearms held in trust and much more!
Derek492
Sr. Member
****
Offline Offline

Activity: 357
Merit: 250



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


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
 #18119


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: 1316
Merit: 1000


Pivx Core Developer - HyperStake Founder


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


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.

presstab's Block Explorer Service | available for most coins! | Richlist w/ Address Claim | Market Cap Charts | Stake Weight Tracking | PoS % Rate Tracking
PIVX - Private Instant Verified Tx | HyperStake - Fun & Easy High Reward Staking
Pages: « 1 ... 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 956 ... 1035 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!