coins101 (OP)
Legendary
Offline
Activity: 1456
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 16, 2017, 12:02:30 AM |
|
Interesting doing some background research on patents in the mobile payments space. Found this site which has some interesting features on Apple patents http://www.patentlyapple.com
|
|
|
|
adolf512
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 16, 2017, 12:58:58 PM |
|
Will this project offer any real advantages over dash? Technical Architecture * Total Coin Supply (about 20m, tbc) * Block halving (around 7% per year, tbc) * PoW only algo (tbc) * Block time (tbc) * Download clients (tbc) * Port (tbc) * RPC-Port (tbc)
That is a bad decision, exponential decrease in the block reward is far from ideal. Also i actually think discrete actual halvings is better than a smooth decrease.
|
|
|
|
coins101 (OP)
Legendary
Offline
Activity: 1456
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 16, 2017, 06:59:43 PM |
|
OP has been updated with details of the second SPR explorer to provide two places for cross checking block heights for the cut-off. We do not control them, but we have paid for the second one, which will have it's premium status open for about 9 months before it reverts back to basic status. This can be extended. http://cryptoguru.tk/RichList/index.php?Currency=SPRWe will also host the HELIUM explorer in the same places to validate and cross check the swaps.
|
|
|
|
|
stonehedge
Legendary
Offline
Activity: 1722
Merit: 1002
Decentralize Everything
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 16, 2017, 10:12:03 PM |
|
I'll have a nibble if any are left after I get some BTC together.
|
|
|
|
coins101 (OP)
Legendary
Offline
Activity: 1456
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 18, 2017, 04:25:41 PM |
|
Thanks whoever bought those. We'll be making some announcements about the launch process soon enough, once I get permissions from a few contributors to the project to put them in the OP.
|
|
|
|
|
coins101 (OP)
Legendary
Offline
Activity: 1456
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 19, 2017, 09:39:37 PM Last edit: March 19, 2017, 10:01:09 PM by coins101 |
|
Karmashark raised a good point about collateral requirements. Lets open up a discussion on masternode collateral. Here are some options: ![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fi.imgur.com%2FAIpPNpP.png&t=665&c=IzDFOc7IkRkFKw) We do need to seek views as people will have opinions on affordability of masternodes and distribution around early investors. We will have some limits as to what we can do to please everyone, but lets give it a go. From my perspective, 10,000 HLM generates too few servers. We'll be looking to run millions of user accounts so we have to take into account the numbers of severs we can run on the network to spread and carry the load. We also need to take into account 5%-20% of nodes going down at any one point due to DDoS attacks; day to day redundancy; and network performance as experienced by users. 250 HLM is towards the range we're interested in, but we won't need that level of capacity for a decade or more, so it creates a sybil risk until the price of HLM rises. 800 HLM to 1,250 HLM for collateral is the range that gives a good compromise between economic barrier to sybil attacks and providing sufficient room for supporting ordinary payments users on the network. Then we need to factor the current and near future coin supply. This has an impact on the choices we make now and in the near future. ![](https://ip.bitcointalk.org/?u=https%3A%2F%2Fi.imgur.com%2FFZEwJa8.png&t=665&c=85kWJ94d8dQYmA) We can change the rules down the road, but that would disrupt business as usual for everyone running masternodes. Running a 24/7 payments network for tens of millions of users means we'll have to look at migrate+upgrade (really hard) vs upgrade only if we ever need to switch the protocol while trying to meet end user SLAs. We will have 2 or 3 hard forks between launch and the end of 2018. We won't be anywhere near capacity by the end of 2018, so we can come back to this issue in 2018 when we start planning for something that will last for 10-20 years in terms of the collateral vs. server capacity.
|
|
|
|
Nikolaj
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 20, 2017, 12:38:17 AM |
|
Thanks whoever bought those. We'll be making some announcements about the launch process soon enough, once I get permissions from a few contributors to the project to put them in the OP. ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) Let us know, thanks in advance. I'll have the potential to support it on the server-side, as an early bid or for testing purposes. We'll have a talk soon about that
|
|
|
|
SockPuppetAccount
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 20, 2017, 12:57:45 AM |
|
We do need to seek views as people will have opinions on affordability of masternodes and distribution around early investors. We will have some limits as to what we can do to please everyone, but lets give it a go.
From my perspective, 10,000 HLM generates too few servers. We'll be looking to run millions of user accounts so we have to take into account the numbers of severs we can run on the network to spread and carry the load.
We also need to take into account 5%-20% of nodes going down at any one point due to DDoS attacks; day to day redundancy; and network performance as experienced by users.
250 HLM is towards the range we're interested in, but we won't need that level of capacity for a decade or more, so it creates a sybil risk until the price of HLM rises.
800 HLM to 1,250 HLM for collateral is the range that gives a good compromise between economic barrier to sybil attacks and providing sufficient room for supporting ordinary payments users on the network.
Then we need to factor the current and near future coin supply. This has an impact on the choices we make now and in the near future.
We can change the rules down the road, but that would disrupt business as usual for everyone running masternodes. Running a 24/7 payments network for tens of millions of users means we'll have to look at migrate+upgrade (really hard) vs upgrade only if we ever need to switch the protocol while trying to meet end user SLAs.
We will have 2 or 3 hard forks between launch and the end of 2018. We won't be anywhere near capacity by the end of 2018, so we can come back to this issue in 2018 when we start planning for something that will last for 10-20 years in terms of the collateral vs. server capacity.
DON'T make the requirement 1000 HLM on the dot, simply for the sake of marketing. It's an incredibly minor detail but take every opportunity possible to say, "HLM started off as a DASH fork but HLM is much more than a simple DASH clone". IMO, lean towards the high end for collateral requirement at launch, so 1250 HLM. I don't like having so much of the float locked up, but I suspect it is going to be wise to prioritize having a strong barrier to Sybil attacks as certain communities out there have plenty of money to burn. As it becomes feasible and necessary to do so, the requirement can drop towards the 250 HLM level.
|
|
|
|
entropycoin
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 20, 2017, 05:32:33 AM |
|
I still like (at least initially) a dynamic model tied to price. So that people aren't annoyed with constantly updating the collateral tied to a node, it could fluctuate quarterly, or even less frequently. But I think the goal should be to constantly provide a yield of at least a 2x the operational costs.
|
DRK: Xi2c97ZMtfU2nMeJkY1kD1Ry3tmRnnQfHP
|
|
|
stonehedge
Legendary
Offline
Activity: 1722
Merit: 1002
Decentralize Everything
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 20, 2017, 07:15:30 AM |
|
I still like (at least initially) a dynamic model tied to price. So that people aren't annoyed with constantly updating the collateral tied to a node, it could fluctuate quarterly, or even less frequently. But I think the goal should be to constantly provide a yield of at least a 2x the operational costs.
I like the concept of this but it would be a bitch to code in such a way that people didn't have to rebuild their masternodes every time the collateral requirement changed. I have no objection with going for 1,000 HLM from the start. There should be no in embarrassment in using Dash code as long as the plan is to use it as a foundation to build on and I don't think having the same 1000 Coin requirement is going to make HLM look like a simple clone. Especially over the long term.
|
|
|
|
entropycoin
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 20, 2017, 08:00:23 AM |
|
I still like (at least initially) a dynamic model tied to price. So that people aren't annoyed with constantly updating the collateral tied to a node, it could fluctuate quarterly, or even less frequently. But I think the goal should be to constantly provide a yield of at least a 2x the operational costs.
I like the concept of this but it would be a bitch to code in such a way that people didn't have to rebuild their masternodes every time the collateral requirement changed. I have no objection with going for 1,000 HLM from the start. There should be no in embarrassment in using Dash code as long as the plan is to use it as a foundation to build on and I don't think having the same 1000 Coin requirement is going to make HLM look like a simple clone. Especially over the long term. You could code it so it recognizes any integer greater than the minimum collateral requirement. Let's say the minimum requirement is 1000. After some initial hype, the marketcap retraces a bit to the point that 1000 is no longer profitable and the min requirement is temporarily changed to 1500. Person a has 1000 tied to a node, person b 2000. Person b was incentiveized to add more hlm to a node so they can take the Ron propiel set it and forget it approach. Person a has to monitor their node more closely and have a bit of hlm on standby (can't necessarily dump node profit into market). Both with a node win, because it'll always be profitable. I'm mostly interested in this for the dynamics it would create and the fact that as much as hlm rose in value it would likely never be unobtainable for the vast majority of those interested in setting up a node and least not for long unless insanely costly vps requirements become a necessity.
|
DRK: Xi2c97ZMtfU2nMeJkY1kD1Ry3tmRnnQfHP
|
|
|
e1ghtSpace
Legendary
Offline
Activity: 1526
Merit: 1001
Crypto since 2014
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 20, 2017, 08:12:25 AM |
|
I still like (at least initially) a dynamic model tied to price. So that people aren't annoyed with constantly updating the collateral tied to a node, it could fluctuate quarterly, or even less frequently. But I think the goal should be to constantly provide a yield of at least a 2x the operational costs.
I like the concept of this but it would be a bitch to code in such a way that people didn't have to rebuild their masternodes every time the collateral requirement changed. I have no objection with going for 1,000 HLM from the start. There should be no in embarrassment in using Dash code as long as the plan is to use it as a foundation to build on and I don't think having the same 1000 Coin requirement is going to make HLM look like a simple clone. Especially over the long term. You could code it so it recognizes any integer greater than the minimum collateral requirement. Let's say the minimum requirement is 1000. After some initial hype, the marketcap retraces a bit to the point that 1000 is no longer profitable and the min requirement is temporarily changed to 1500. Person a has 1000 tied to a node, person b 2000. Person b was incentiveized to add more hlm to a node so they can take the Ron propiel set it and forget it approach. Person a has to monitor their node more closely and have a bit of hlm on standby (can't necessarily dump node profit into market). Both with a node win, because it'll always be profitable. I'm mostly interested in this for the dynamics it would create and the fact that as much as hlm rose in value it would likely never be unobtainable for the vast majority of those interested in setting up a node and least not for long unless insanely costly vps requirements become a necessity. What if there were a limited amount of masternodes (dynamically increasing with the coin supply, maybe), but they only get paid according to their collateral. So someone who has 50x 100 hlm masternodes gets paid the same as someone with 1x 5000 hlm masternode. This means that there will probably be enough spots for a lot of people. They would all get paid randomly... ah damn, I forgot about sybil attacks. We should have a lower limit for the collateral, I guess, and this idea could still work. Does anyone think it is a good idea?
|
|
|
|
coins101 (OP)
Legendary
Offline
Activity: 1456
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 20, 2017, 12:39:13 PM |
|
I still like (at least initially) a dynamic model tied to price. So that people aren't annoyed with constantly updating the collateral tied to a node, it could fluctuate quarterly, or even less frequently. But I think the goal should be to constantly provide a yield of at least a 2x the operational costs.
I like the concept of this but it would be a bitch to code in such a way that people didn't have to rebuild their masternodes every time the collateral requirement changed. I have no objection with going for 1,000 HLM from the start. There should be no in embarrassment in using Dash code as long as the plan is to use it as a foundation to build on and I don't think having the same 1000 Coin requirement is going to make HLM look like a simple clone. Especially over the long term. You could code it so it recognizes any integer greater than the minimum collateral requirement. Let's say the minimum requirement is 1000. After some initial hype, the marketcap retraces a bit to the point that 1000 is no longer profitable and the min requirement is temporarily changed to 1500. Person a has 1000 tied to a node, person b 2000. Person b was incentiveized to add more hlm to a node so they can take the Ron propiel set it and forget it approach. Person a has to monitor their node more closely and have a bit of hlm on standby (can't necessarily dump node profit into market). Both with a node win, because it'll always be profitable. I'm mostly interested in this for the dynamics it would create and the fact that as much as hlm rose in value it would likely never be unobtainable for the vast majority of those interested in setting up a node and least not for long unless insanely costly vps requirements become a necessity. I like the idea of variable rewards. We'll see if we can put it on the road map for 2018/19 after we've done some specs and worked through the economic model. One of the aspects of ServiceNodes is that they will, over the long-term, pay for MasterNodes, development and other network costs (for those not familiar with the background as to why we have two types of layer 2 nodes). As the coinbase rewards diminish, the payments to masternodes and miners will come under the spotlight. You either put up fees, or you find an alternative source of income, so you have new money and fees. However, when you need to rely on services fees, they can be variable, so we will in time need to adapt to a quarter-by-quarter review of reward distributions to the network. If we're successful, people will deposit collateral to earn money on a relatively consistent rate of return - like a savings account. Any extra, we might be able to send to miners. Services income and low fees to sustain the network - this is a unique difference that DASH has not addressed.
|
|
|
|
coins101 (OP)
Legendary
Offline
Activity: 1456
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 20, 2017, 03:56:12 PM |
|
..What if there were a limited amount of masternodes (dynamically increasing with the coin supply, maybe), but they only get paid according to their collateral. So someone who has 50x 100 hlm masternodes gets paid the same as someone with 1x 5000 hlm masternode. This means that there will probably be enough spots for a lot of people.
They would all get paid randomly... ah damn, I forgot about sybil attacks. We should have a lower limit for the collateral, I guess, and this idea could still work.
Does anyone think it is a good idea?
Fixed numbers is an interesting idea. But what problem are we trying to solve? Incentives to invest or capacity to efficiently process? If we want the network to be used by tens of millions of users, then a limited number of masternodes means the network will potentially show signs of network lag due to an increasing user base being put onto a fixed number of servers. You wouldn't notice any problems for a few years, but then users would start to experience a lag in the service. Each server would have the ability to scale up in terms of storage space, but then you need to take account of processing capabilities and bandwidth. If we introduce a way to use up the coin supply in too few servers, users will experience problems and go elsewhere. This isn't so much about numbers of transactions per second. We'll need to scale to a huge number of those. This is about a system that introduces a thin client for running wallets online without having to download a client.
|
|
|
|
e1ghtSpace
Legendary
Offline
Activity: 1526
Merit: 1001
Crypto since 2014
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 20, 2017, 09:04:56 PM |
|
..What if there were a limited amount of masternodes (dynamically increasing with the coin supply, maybe), but they only get paid according to their collateral. So someone who has 50x 100 hlm masternodes gets paid the same as someone with 1x 5000 hlm masternode. This means that there will probably be enough spots for a lot of people.
They would all get paid randomly... ah damn, I forgot about sybil attacks. We should have a lower limit for the collateral, I guess, and this idea could still work.
Does anyone think it is a good idea?
Fixed numbers is an interesting idea. But what problem are we trying to solve? Incentives to invest or capacity to efficiently process? If we want the network to be used by tens of millions of users, then a limited number of masternodes means the network will potentially show signs of network lag due to an increasing user base being put onto a fixed number of servers. You wouldn't notice any problems for a few years, but then users would start to experience a lag in the service. Each server would have the ability to scale up in terms of storage space, but then you need to take account of processing capabilities and bandwidth. If we introduce a way to use up the coin supply in too few servers, users will experience problems and go elsewhere. This isn't so much about numbers of transactions per second. We'll need to scale to a huge number of those. This is about a system that introduces a thin client for running wallets online without having to download a client. Yeah, maybe processing power / internet speed / storage / whatever could also go towards the collateral, so that a better vps would get paid more? I don't know. But this does make them very decentralised, maybe spreadcoin could do this?
|
|
|
|
adolf512
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 21, 2017, 12:32:22 AM |
|
I had an idea to decrease the blockreward(including masternode reward) with the number of masternodes a whioe back, i no longer think that is a good solution but you might have a different view, this project will fail anyway, makes no difference.
|
|
|
|
KarmaShark
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 21, 2017, 01:55:04 AM |
|
Details regarding the launch of Helium, coin distribution (snapshot) along with pre-launch work you can help with all coming soon. Check the OP along with the current page here as we will be keeping the community engaged.
There will be advanced notice given prior to the Speadcoin snapshot, including an awareness campaign to introduce the industry to Helium. Every effort will be made to ensure the entire blockchain and cryptocurrency industry is well aware of the pending launch of Helium, so no one will be left out of the initial coin distribution.
|
|
|
|
chrysophylax
Legendary
Offline
Activity: 2870
Merit: 1091
--- ChainWorks Industries ---
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
March 21, 2017, 02:08:11 AM |
|
I had an idea to decrease the blockreward(including masternode reward) with the number of masternodes a whioe back, i no longer think that is a good solution but you might have a different view, this project will fail anyway, makes no difference.
well ... if you are so certain - why bother? ... situation here is very good - even though its in the planning process ... you know nothing of the background - otherwise you would have not mentioned that 'this project will fail anyway' ... had you known anything about the project - its history - the reasoning behind it - and more importantly - THE PEOPLE behind it - your choice of words WILL be a very different one ... hence why we ( cwi ) are here also ... im always amazed by comments like yours ... always ... but - be that as it may - do your research - and do your due diligence ... thats the only way to 'invest' into ANY project anyway - by 'investing' your time and effort ... if you believe this project will fail - or you believe this project will succeed - you are right ( henry ford said this ) ... because what you believe is what you will follow - and the consequences of what you do henceforth determines what will happen to YOU alone in future ... some of the most successful projects in the world at the moment - are considered failures in 'some' peoples eyes ( like bitcoin and dash for example ) ... big deal ... we will be following ( and backing ) this project as best we can ... no matter how big or small cwi becomes ... if not SOLELY for the fact that the people behind this project are determined solid respectable people ... thats it ... in 'our' eyes - this project will succeed ... tanx for you input mate ... #crysx
|
|
|
|
|