The Rolling Thread :) (go to end for newest posts)
- Thread starter TanteStefana
- Start date
I have a question, does anyone know how bitnodes are set up? How are they paid? I'm also wondering if it would be more advantageous to have more masternodes? I don't know if it would slow down the response times. I do know we could easily do it by halving the cost of a masternode to 500 coins. Not sure that's a good idea though??
I think the developers (crowning?) are planning on minimum standards for masternodes. That would be good, even if I have to upgrade, LOL. I'd like to see a masternode network that can do many things for the coin, so a minimum standard is probably a necessity in the end
NP Bite
I think the developers (crowning?) are planning on minimum standards for masternodes. That would be good, even if I have to upgrade, LOL. I'd like to see a masternode network that can do many things for the coin, so a minimum standard is probably a necessity in the end
NP Bite
Do I understand this correctly? One Bitcoin member (presumably one with lots of bitcoin? Has put up coin to pay a random full Bitcoin node each week. Out of 4000+ nodes, they have 1 chance per week to win $20 worth of bitcoin. I think it's an admirable thing to do, but frankly, it's not enough to run a node, Chances of winning the lottery are pretty slim if it's only 1 time per week, and there are so many nodes. On average, it would take years to win $20.
I guess it's more of a fun game to play while supporting the network. And many people do run full nodes, which is great, but what about the future? The people who started with Bitcoin are ideologically motivated. Will that continue 20 years down the line? Maybe, maybe not?
I guess it's more of a fun game to play while supporting the network. And many people do run full nodes, which is great, but what about the future? The people who started with Bitcoin are ideologically motivated. Will that continue 20 years down the line? Maybe, maybe not?
I'll admit that I am not sure how the bitnodes thing works, but one thing we can be certain of is that it is not part of the bitcoin protocol, so this is completely optional. On the surface, it does not seem sustainable, unless the people contributing the reward money stand to benefit in some way. And if that part is not clear, then the pessimistic little guy sitting on my right shoulder is whispering to me that I should assume their intentions are not entirely pure.
One thing to note about the full node issue is that it is directly tied to the mining.
We all know about the problem of centralization of PoW through the use of large pools (and if you don't know, ask thelonecrouton). Well upon closer inspection, you'll see that the full node issue actually exacerbates this problem. Currently the only incentive to run a full bitcoin node is profit from mining pool operation. So only mining pool operators will continue the necessary expense to keep their hardware "up to snuff" as far as full node requirements go.
As only the richest pool operators with increasingly powerful/dedicated hardware will be able to maintain full nodes, the number of pool operators will also decrease. This effect is quite similar to how the number of individual miners has drastically decreased, but the hash rate and cost of the ASIC hardware has at the same time exponentially increased.
With DASH in its current form, we already have two full-node incentives built into the protocol: mining and masternodes. That doesn't even include users who simply leave their fully synched wallets open 24/7. I know some already do this as "liquidity providers" for darksend mixing, but there is no subsidy for doing so AFAIK.
This brings me to another point: We have many more than 2100 "full nodes" in the DASH network. Anyone with a DASH Core 0.11.2.x daemon or QT open and synced is a full node at that moment. Since we don't have electrum or greenaddress or blockchain.info types of services (YET), everyone using a wallet outside of an exchange is basically going to be using a full node during the time he has it open and synched. Given the nature of p2p, I'm not sure there is an easy way to count the number of nodes at any given time. (I thought that was the main intention of the bitnodes thing. This reward scheme must be a recent development.)
So full nodes aren't really an issue now, but they will be once we start getting more adoption and users transacting via SPV clients, plus with Evan's recently alluded-to plans of A to D transaction abbreviation, I believe we will also introduce a new class of lightweight client that will further reduce the number of full nodes. So what all this means for us is awesome future-proofing...and I didn't even touch the topic of scalability! (I'm sure I'm not the only one eagerly awaiting Evan's proposal for this!)
Regarding masternode hardware,
I think the devs are already on the masternode HW issue. It probably is less of a specific hardware requirements thing, and more of an actual performance returned thing. So you'll know if your VPS isn't good enough because you'll get kicked off the PoSe list. And btw, there is already a built-in hardware requirement: If your VPS doesn't physically keep up, it won't be synced or will crash/etc, and you risk not getting paid. So I'm guessing that even with the current network situation, if we suddenly loaded the network up with services (i.e. everybody starts furiously using IX and darksend mixing, plus whatever other new goodies we may have in the oven), then it's possible that only those with more powerful servers will stay alive. But it will also mean that adoption has gone way up, along with the price and reward for running a masternode. So basically we don't have to worry about the masternode performance. Our friend economics will do its thing.
As far as the number of masternodes goes, i think I recall reading that Evan believes 3000 to be good number, and if he does, it means he probably put a lot of thought into it. There has previously been a lot of discussion regarding this. I don't think there is a difference between 500 or 1000 collateral economically, because the same % of the market cap is still securing the network. Assuming that this rule is also true of the hardware requirements (for example, 2x the total masternodes means 1/2 the current hardware requirements), then the only difference would be the number of unique IPs, I guess. I'm sure Evan and others have already considered the different possibilities here when he came up with the reward schedule.
One thing to note about the full node issue is that it is directly tied to the mining.
We all know about the problem of centralization of PoW through the use of large pools (and if you don't know, ask thelonecrouton). Well upon closer inspection, you'll see that the full node issue actually exacerbates this problem. Currently the only incentive to run a full bitcoin node is profit from mining pool operation. So only mining pool operators will continue the necessary expense to keep their hardware "up to snuff" as far as full node requirements go.
As only the richest pool operators with increasingly powerful/dedicated hardware will be able to maintain full nodes, the number of pool operators will also decrease. This effect is quite similar to how the number of individual miners has drastically decreased, but the hash rate and cost of the ASIC hardware has at the same time exponentially increased.
With DASH in its current form, we already have two full-node incentives built into the protocol: mining and masternodes. That doesn't even include users who simply leave their fully synched wallets open 24/7. I know some already do this as "liquidity providers" for darksend mixing, but there is no subsidy for doing so AFAIK.
This brings me to another point: We have many more than 2100 "full nodes" in the DASH network. Anyone with a DASH Core 0.11.2.x daemon or QT open and synced is a full node at that moment. Since we don't have electrum or greenaddress or blockchain.info types of services (YET), everyone using a wallet outside of an exchange is basically going to be using a full node during the time he has it open and synched. Given the nature of p2p, I'm not sure there is an easy way to count the number of nodes at any given time. (I thought that was the main intention of the bitnodes thing. This reward scheme must be a recent development.)
So full nodes aren't really an issue now, but they will be once we start getting more adoption and users transacting via SPV clients, plus with Evan's recently alluded-to plans of A to D transaction abbreviation, I believe we will also introduce a new class of lightweight client that will further reduce the number of full nodes. So what all this means for us is awesome future-proofing...and I didn't even touch the topic of scalability! (I'm sure I'm not the only one eagerly awaiting Evan's proposal for this!)
Regarding masternode hardware,
I think the devs are already on the masternode HW issue. It probably is less of a specific hardware requirements thing, and more of an actual performance returned thing. So you'll know if your VPS isn't good enough because you'll get kicked off the PoSe list. And btw, there is already a built-in hardware requirement: If your VPS doesn't physically keep up, it won't be synced or will crash/etc, and you risk not getting paid. So I'm guessing that even with the current network situation, if we suddenly loaded the network up with services (i.e. everybody starts furiously using IX and darksend mixing, plus whatever other new goodies we may have in the oven), then it's possible that only those with more powerful servers will stay alive. But it will also mean that adoption has gone way up, along with the price and reward for running a masternode. So basically we don't have to worry about the masternode performance. Our friend economics will do its thing.
As far as the number of masternodes goes, i think I recall reading that Evan believes 3000 to be good number, and if he does, it means he probably put a lot of thought into it. There has previously been a lot of discussion regarding this. I don't think there is a difference between 500 or 1000 collateral economically, because the same % of the market cap is still securing the network. Assuming that this rule is also true of the hardware requirements (for example, 2x the total masternodes means 1/2 the current hardware requirements), then the only difference would be the number of unique IPs, I guess. I'm sure Evan and others have already considered the different possibilities here when he came up with the reward schedule.
Thanks Bridgewater Glad you got paid, Bite!
I would still like to see Darksend manditory as well as instantX. I guess we need to know if they are fully scalable first, though I would think they are. Sure it costs a bit, but I think the fees are so minimal, it's acceptable as a known use fee. It's probably too complicated to enforce for DarkSend as people are opening and closing their wallets all the time, but I don't see why instantX isn't used all the time?
Crap, another sleepless night
Glad you got paid, Bite!I would still like to see Darksend manditory as well as instantX. I guess we need to know if they are fully scalable first, though I would think they are. Sure it costs a bit, but I think the fees are so minimal, it's acceptable as a known use fee. It's probably too complicated to enforce for DarkSend as people are opening and closing their wallets all the time, but I don't see why instantX isn't used all the time?
Crap, another sleepless night
Agreed. I think automatic mixing of all coins will happen at some point... That would really seal the deal as far as fungibility is concerned.
As for instantX, we should wait and see what Evan has planned. I'm interested in how the user-selectable locking time will work.
Once senders can specify how long they want their transaction to be locked in the masternode network, should they have to pay different amounts for the length of that time? Is there an ongoing load to the masternode network's CPU or memory usage when handling IX transactions prior to POW, or is it a one-time thing?
I'm sure we can dream up a plethora of uses for setting specific maturity dates, from "don't cash that check 'till next Tuesday" to a newfangled private-key based bearer bond... If the load of these things starts adding up to increased server hardware requirements, then the maintenance fee for locking transactions could be adjustable based on locking time.
On the other hand, we could logically treat MN running costs the same way we do mining hardware. It could be a harmonious economical balance that evens itself out: When the IX load increases MN minimum hardware requirements, then the DRK/$ price will probably have have increased a great deal, too. More load on the network means more people using DRK. I suppose it remains to be seen how much load the Darksend mixing and IX locking will be for the MN network when DRK is handling the transactions of millions of people each day.
Have you ever tried cal-mag powder? Drinking some before bed can really do wonders for your sleep.
As for instantX, we should wait and see what Evan has planned. I'm interested in how the user-selectable locking time will work.
Once senders can specify how long they want their transaction to be locked in the masternode network, should they have to pay different amounts for the length of that time? Is there an ongoing load to the masternode network's CPU or memory usage when handling IX transactions prior to POW, or is it a one-time thing?
I'm sure we can dream up a plethora of uses for setting specific maturity dates, from "don't cash that check 'till next Tuesday" to a newfangled private-key based bearer bond... If the load of these things starts adding up to increased server hardware requirements, then the maintenance fee for locking transactions could be adjustable based on locking time.
On the other hand, we could logically treat MN running costs the same way we do mining hardware. It could be a harmonious economical balance that evens itself out: When the IX load increases MN minimum hardware requirements, then the DRK/$ price will probably have have increased a great deal, too. More load on the network means more people using DRK. I suppose it remains to be seen how much load the Darksend mixing and IX locking will be for the MN network when DRK is handling the transactions of millions of people each day.
Have you ever tried cal-mag powder? Drinking some before bed can really do wonders for your sleep.
Its the whole payment, setting at 10% would give 1 out of every 10 full payments I think.
One crazy idea for you guys.
We all know that the main vulnerability of Bitcoins, which prevents it from becoming full-fledged money - the lack of fungibility of coins. Fungibility of Bitcoins is spoiled by the fact that each amount contains previous history of operations. And a bad "history-legacy" can be used as a factor of discrimination in the subsequent use of coins (So we can talk about "clean" bitcoins vs "dirty" bitcoins).
For example, if you recive coins that were previously stolen, passed through darkmarkets etc. - They in some sense are "corrupted" and you may have problems with their further usage.
Dash resolves that vulnerability - darksend mechanism are used to anonymize - clean up the history of previous operations for your DASH. As a result DASH becomes real fungible digital cash (money).
So why do not we call processes of anonymization - just a "Cleaning"!
It sounds simple, understandable, positive(!) and not as "criminal" as "Anonymization".
Thus users will have in their wallets:
1. Standard Dash
2. Cleaned Dash
3. And "To Clean" button.
Even your grandmother would understand this principle and do not have to explain for everybody what is "Anonymization", "Mixing", "Darksend", ... and why is it necessary for ordinary people.
"KISS" principle in action - because we need an acceptance of ordinary people.
What do you think about this?
We all know that the main vulnerability of Bitcoins, which prevents it from becoming full-fledged money - the lack of fungibility of coins. Fungibility of Bitcoins is spoiled by the fact that each amount contains previous history of operations. And a bad "history-legacy" can be used as a factor of discrimination in the subsequent use of coins (So we can talk about "clean" bitcoins vs "dirty" bitcoins).
For example, if you recive coins that were previously stolen, passed through darkmarkets etc. - They in some sense are "corrupted" and you may have problems with their further usage.
Dash resolves that vulnerability - darksend mechanism are used to anonymize - clean up the history of previous operations for your DASH. As a result DASH becomes real fungible digital cash (money).
So why do not we call processes of anonymization - just a "Cleaning"!
It sounds simple, understandable, positive(!) and not as "criminal" as "Anonymization".
Thus users will have in their wallets:
1. Standard Dash
2. Cleaned Dash
3. And "To Clean" button.
Even your grandmother would understand this principle and do not have to explain for everybody what is "Anonymization", "Mixing", "Darksend", ... and why is it necessary for ordinary people.
"KISS" principle in action - because we need an acceptance of ordinary people.
What do you think about this?
Last edited by a moderator:
We are Dash (Digital Cash).
We could simply call the Mixing button "Make Digital Cash"
Dash balance:
Digital Cash balance:
Thoughts?
I think you probably read my reply this morning on the BCT thread, but in the USA and I think in GB and Australia as well, "cleaning" money implies laundering (washing) which is illegal :tongue: So, I understand what you're saying, but we'll need a different term
The thing about privacy vs illegal money laundering, is that the side that protects human rights MUST trump whatever law enforcement would like to get a hold of (information).
The thing about privacy vs illegal money laundering, is that the side that protects human rights MUST trump whatever law enforcement would like to get a hold of (information).
Last edited by a moderator:
Jeff Garzik on DASH:
"heh, DarkCoin rebranded to Dash. They finally figured out "CriminalCoin" was poor marketing."
https://twitter.com/jgarzik/status/586298066359209984
"heh, DarkCoin rebranded to Dash. They finally figured out "CriminalCoin" was poor marketing."
https://twitter.com/jgarzik/status/586298066359209984
"THEY don't see us"....yeah, right :tongue:Jeff Garzik on DASH:
"heh, DarkCoin rebranded to Dash. They finally figured out "CriminalCoin" was poor marketing."
https://twitter.com/jgarzik/status/586298066359209984
Condescending people piss me off. I have engaged them on Twitter.Jeff Garzik on DASH:
"heh, DarkCoin rebranded to Dash. They finally figured out "CriminalCoin" was poor marketing."
https://twitter.com/jgarzik/status/586298066359209984
How about "fungibilize"? It's not a real word and maybe it's a bit of a mouthful, but if someone knows what fungibility is, surely they can figure out fungibilize means. Good for Google queries too.I think you probably read my reply this morning on the BCT thread, but in the USA and I think in GB and Australia as well, "cleaning" money implies laundering (washing) which is illegal :tongue: So, I understand what you're saying, but we'll need a different term
The thing about privacy vs illegal money laundering, is that the side that protects human rights MUST trump whatever law enforcement would like to get a hold of (information).
The term "tumble" seems to have more acceptance in this case. I guess drying has more positive connotations than the wash cycle? It's fluffy and warm
Fungibilize is nice, but some might think they need to go buy some some foot spray after using it.
Seriously though, the button is an interim solution. Superior fungibility will come one day when we eventually get default automatic mixing without user input.
Fungibilize is nice, but some might think they need to go buy some some foot spray after using it.
Seriously though, the button is an interim solution. Superior fungibility will come one day when we eventually get default automatic mixing without user input.
I had 3 which did the same...stop it, delete peers.dat, start it again and do a "masternode start" from your hot wallet.
So I'm sitting here the past few days thinking WHY? Why is the price dropping, and I just realized April 15th is Tax day in the USA! LOL, there always is a reason! People are needing extra $ to pay their taxes ;P I'm quite sure now that that is what it is! What do you all think?
- Apr 8, 2014
- 1,959
- 1,320
- 1,283
no no they are accumulating the funds for the election campaign of coins101
didn`t you know about it?
LOL, he's like 2 years early, no? Anyway, until he offers something for the straight women on the boards, I'm not committing my vote, LOL
Hey everyone. I was going to get an advertisement up on the forum, but I just didn't get it done in time (but will next time). Anyway, if anyone is interested in reading my husband's novel, Steemjammer, it's free on Amazon until Tuesday and the second book is 99 cents, a different promotion style. We're trying things out as we're really green! :tongue:
Anyway, it's steempunk/urban fantasy style for young adults (or anyone really) Might be a little too scary for very young children. I hope some of you will take a look and let us know what you think Thanks!
Anyway, it's steempunk/urban fantasy style for young adults (or anyone really) Might be a little too scary for very young children. I hope some of you will take a look and let us know what you think
Thanks!
Guys, i am having a problem with MN. So they run for 2 hours and then go offline. I delete pears.dat, debug.log, db.log and restart and restart from hot wallet. After couple of hours both MN go offline. Does anyone else experience it?
Had the same problem once. Tried everything for weeks.
Only thing that helped in the end was to get a new ip for my MN. As soon as I switched to a different ip everything worked fine!