Tried to open the electrum prototype wallet got "Unable to login to dapi". I've created an account, but how do I login?
The server had crashed  The software is pre-alpha basically... completely full of bugs |
|
|
|
From what I understand, the quadratic explosion that occurs from 1mb to 2mb cannot be solved with fees. It will either need to limit the max transactions or the size of a transaction - to say 1mb. Aside from that, do we have any maths on how x11 and 2mb blocks propagate and how that can affect mining and network operation? I don't feel that people voting yes or no in such technical issues is appropriate. I mean, yes, we all want bigger blocks, heck, why not 100mb? I mean duuuh? But there are tradeoffs involved and we have to see what they are. If possible, I'd like to know these things: 1) With the proposed fee structure, how much would it cost me -as an attacker- to add 1gb of bloat to our blockchain? I want to know if its doable for one of our competitor coins to "sponsor" an attack and make our wallet unusable because noone will want to download a 500gb wallet and say "fuck dash, it's taking ages". This is not a theoretical attack, Monero had been on the receiving end of a bloat attack in the past - presumably by Bytecoin (?). 2) What's the propagation and verification speed data regarding 2mb blocks combined with 2.5m intervals - which, sometimes can get down to a few seconds and will it create problems in case of 2mb blocks? Is there any testnet simulation run or something with full blocks, or specially crafted attack blocks to see what will happen at full load? 3) Is there any reason in particular why we would like this change to occur now, instead of the future when we need >28tx/s? The only thing I can think of is ...marketing, in the sense of "hey bitcoin, look over here, we are doing it democratically" - and hitting the news with it, but, again, I'm not comfortable about the decision process when people don't have all the tradeoff data. Actually I don't feel good at all when it's left to anyone's decision process with a simple yes and no  Happy birthday people, the future is bright  I believe the masternode network can solve all issues with scalability from the blocksize perspective. 1.) We didn't propose an exact fee structure yet, that will determined when the coding begins. It will be enough to stop a sybil/bloat attack and also enough to allow users a very low cost to transact on our network. 2.) The problems with propagation do not pass from the Bitcoin network to the Dash network, due to the high quality second tier infrastructure. We can require specific infrastructure from our masternodes, which will allow for very quick block propagation no matter the size. The miners simply will need to be connected to the masternode network from each of it's edges (which we will describe how to do this eventually, it's not very difficult). Imagine propagating a 20MB block through a network of 3500 computers with 10GB/s networking. It's not hard to see the advantage we have. As for the question, how will we require the masternodes have specific hardware? The next proof-of-service implementation is going to be as simple as a few of us testing the network's masternodes using open source tools to determine the quality of service. We will then provide evidence that can be double checked by other masternodes, then we will use a voting mechanism to flag their masternodes. They will see the flags and know what they have to do in order to remove them, until they do they won't get paid. Once they fix the issues, they can propagate a message asking for a re-evaluation. Also, that's to say our market cap would be orders of magnitude higher as well. To even have 20MB blocks on average we would have hundreds of millions of users. At which point the masternodes will make plenty of money to be required to run on Xeons and have 10GB/s networking. 3.) We need to start preparing for mass user adoption now and make sure we can support this type of load. By doing this now, we'll have years to prepare and won't have to have huge debates about making changes to an already working system. If Bitcoin did this when they were 25% full, they wouldn't be having this issue, right? Why wait? |
|
|
|
That's what I thought, but am I correct in thinking that with the 2nd tier quorum structure DASH will rely far less on POW mining for its security because miners don't have all the power and because DASH is based on X11 we are far less likely to be in the same situation as Bitcoin regarding the centrlisation of mining hardware and the concerns relating to that?
I think Dash relies as much as Bitcoin on mining for security. The 2nd tier is more about making coins at given address be almost indistinguishable from coins at another address which is a different thing from what he's talking about I think. As far as security goes, the 2nd tier enhances security for the particular case of zero mining confirmations which is the case that people who use instant transactions are concerned with. Mining confirmations and hashpower are still the primary source of security in the long term. (By the way, there's a scene in that documentary by the "Supersize Me" guy where he goes into a shop and buys stuff with bitcoin and the transaction is instant. I always wondered how that worked - now I know, they just don't bother waiting for any confirmations). EDIT: I found the scene. Go to 11:44 to see a real world 0-conf bitcoin transaction in action. http://www.disclose.tv/action/viewvideo/198650/Morgan_Spurlock__Living_On_Bitcoin__The_Inside_Man_Bitcoin_CNN_Full_Documentary/Very risky when RBF reaches mainnet... The grand plan for evolution is to eventually JUST have miners generate the proof of work hashes, then all of the transactions are scheduled to be added to blocks by the masternode network quorums. So the statement that we rely just as much on mining for security is true, but the roles are split up so miners can't screw with the blocks. |
|
|
|
What you don't take into account is that in oficial election the 50%+1 don't take in account the abstain and blank vote.
Anyway I don't think this apply for our system.
72h + 20% have my vote too.
Yes, the 50% vs 10/20% boils down to how the abstain votes are handled... with a >=50% system: 1750:1250 pass 2000:200 pass 1500:1000 fail 750:0 fail with a +20% system: 1750:1250 fail 2000:200 pass 1500:1000 fail 750:0 pass I would personally prefer a low-turnout vote like 750:0 to fail rather than pass... and a high turnout vote like 1750:1250 to pass rather than fail... just my 2 cents It doesn't really look like Abstain is used much actually. Unless there's a bug or something? ./dash-cli mnbudget show | grep Abs
"Abstains" : 0,
"Abstains" : 0,
"Abstains" : 0,
"Abstains" : 0,
"Abstains" : 0,
"Abstains" : 0,
"Abstains" : 0,
"Abstains" : 0,
"Abstains" : 0,
"Abstains" : 0,
|
|
|
|
I would personally get rid of the 10% thing, and change it to 50 or 60% of the total MNs being the minimum for a vote to pass...
At current, that would be 1731 or 2077 votes to pass (out of 3462 MNs total)
Edit: With this option, I would feel better about the 24 hour minimum... if a proposal has 2000+ yes votes in 24hr, that's unanimous support
Nothing would ever get passed. Look at the average participation . https://dashninja.pl/budgets.htmlI have looked at participation, and it is higher than you think... The soda budget got 1400 yes votes in under 3 days... that would have easily hit 1700 given a few more days... not an issue This budget got over 2000 votes: https://dashninja.pl/budgetdetails.html?budgetid=lamassu-integrationI said average participation, not peak. Average participation is 34%, which actually isn't too shabby. Maybe we could raise the threshold from 10% to 20% without any impact. So 72 hours and 20% minimum? |
|
|
|
Can DASH masternode network be used for escrowing and settling bets? I mean it like this. Let's say some users, who are "oddmakers" start creating a list of bets and lock some money in the network to cover incoming bets at given odds. "Will this happen by 1/1/2017?" "Will team A win over team B on the game of Jan 10 2016?" People who feel like betting, deposit money on addresses of the network at the given odds and if they win will take the winnings. If not, the oddmaker takes their money. The mechanism of locking and unlocking the money will be coded into dash when the winning condition is met. This is all data of if-then-else type. The only human component required is, I think, in those who determine the outcome of the game. So humans need to actually know what happened and inform the network of whether, for example, team A beat team B. In order for the system to not be "gamed", a large participation of "witnesses" would increase the reliability of the results. Masternode operators could perhaps be used as those who insert the result and verify its authenticity, in order to settle the bets. Back in june I had the option on betting on one eventuality that would take place 6-7 months ahead. Since I can't even trust that an online crypto-betting company will be around for that long, I opted not to bet and not to lock my money. But if this was done over the dash network, I'd do it. There are other bets (even leveraged bets) like "will BTC go up or down?", "will the dow go up or down" which can take data directly from the markets for auto-settlements that would theoretically not require human intervention. sound like a good DAPI App That's in one of the evolution papers somewhere  |
|
|
|
I have to agree 24h is short.
1 week?
The (Number Yes - Number of No) > 10% is really good.
1 week is too high. It will block re-submissions from getting paid. Imagine someone submits a proposal 3 times in the last couple of weeks, there's no way for the protocol to know the community has been talking about this specific proposal for 3 weeks . Instead of having to submit a brand new proposal, can't we have proposal amendments, which when submitted adds an additional 3 days (1728 blocks) on to the discussion time. So initial proposal discussion time for a 700 DASH proposal would be 7 days (700 DASH/100) submitted at block 1000 and ends at block 5032 . A 5 day discussion takes place and based on that discussion an amendment is made and the discussion time is increase by 3 days (5032+1728 blocks = End time at block 6760) to give people time (now 5 days left) to discuss the new amendment before voting. If another amendment is submitted the additional time added would be the time lost discussing the previous amendment unless the time lost was greater than 1728 blocks, in which case 1728 blocks of time would be added on to the end time block. Example * Initial proposal submitted on block 1000 and to end at block 5032 * 5 days of discussion takes place (current block 3880) * The First amendment is submitted (1728 blocks added to end time block. New End time block = 5032 + 1728 = Block 6760 ) * 1 Day of discussion takes place (current block 4456) * Second amendment is submitted at block 4456 - because the block height difference between the first amendment and the second amendment is 576 blocks (1 day) and less then 1728 Blocks (3 days) only the difference is added to the End time block, which makes the new end time block 6760 + 576 = Block 7336 * 4 Days of discussion takes place (current block 6760) * Third amendment is submitted on block 6760. because the block height difference between 2nd and 3rd amendments is greater than 1728 blocks, 1728 block are added to the end time block. end time block now = 7336 + 1728 = Block 9064 * No more amendments are submitted and 2304 Blocks or 4 days later MN's have voted and the proposal passes This process ensures there will be an end date and also gives people time to discuss new proposal amendments. Amendments would be nice, but it's a nightmare to code. Maybe eventually  |
|
|
|
I would personally get rid of the 10% thing, and change it to 50 or 60% of the total MNs being the minimum for a vote to pass...
At current, that would be 1731 or 2077 votes to pass (out of 3462 MNs total)
Edit: With this option, I would feel better about the 24 hour minimum... if a proposal has 2000+ yes votes in 24hr, that's unanimous support
Nothing would ever get passed. Look at the average participation . https://dashninja.pl/budgets.html |
|
|
|
I have to agree 24h is short.
1 week?
The (Number Yes - Number of No) > 10% is really good.
1 week is too high. It will block re-submissions from getting paid. Imagine someone submits a proposal 3 times in the last couple of weeks, there's no way for the protocol to know the community has been talking about this specific proposal for 3 weeks . |
|
|
|
I agree on raising the 24hr minimum. I just wanted to clarify something. It's not just 10% for a budget to pass.
Quote from wiki: "Budgets are proposals which receive 10% of the possible votes (currently about 350 out of 3500) more yes votes than no votes. "
I think raising the 24hr minimum will do the trick.
A situation I would like to avoid goes like this: Evan or Otoh proposes a budget 24hr before the superblock. Even+Otoh vote yes with, lets say conservatively 700 votes. There is now only 24 hours to get 350 no votes... not counting all the lemmings who will vote yes just because they see it started 700 to 0... 700:350 would pass 1000:650 would pass There is also less than 24 hours to discuss the issue... Seems like this situation could be remedied with a longer than 24hr window Edit: I also do not like Evan's answer that he will monitor the budget to make sure nobody sneaks anything in... What happens if Evan goes on vacation, has a heart attack, or is less trustworthy than you think? I would much rather trust the protocol than, "I promise I'll watch and make sure nothing fishy happens" How about 72 hours? |
|
|
|
Evan does not own 500+ nodes. Otoh our largest investor currently owns about 430 nodes as he divested a big portion of his nodes in favor of more distribution and a healthier network, also giving new whales the opportunity to buy in. Having said that, I don't see why the minimum age for a proposal could not be changed to 48 or 72 hours to always give the network more time. I think that is a really good suggestion.
How would you know? I ran the numbers 6 months ago, but I estimated Evan should have mined 750,000+ in the first 24-48 hours with the hashrate he himself claimed to have at the time... that's 750MNs already... (not that he necessarily has them online right now) Then they start collecting 50% of the mining share as masternodes, he should have 1000+ by now... Yeah, your numbers are off and Minotaur is correct. I do not hold as many coins as Otoh. The system is designed in such a way that the founders eventually lose complete control of the voting system. It's on purpose, we are the ones that have the best idea of what needs to be done currently, but over the next few years our voting power will become less and less. Look at the emission schedule here: https://docs.google.com/spreadsheets/d/1RpLd87PTs65sz8USrrXwGRoVGVbzaC-nunErEtGSJoE/edit#gid=055% of the coins are going to people other than the masternodes (miners and budgets), that means a good portion of those will actually be turned into fresh masternodes. Over a long period of time this will dilute our power in the system. In 2020 we will have nearly 10 million coins and probably about 7000 masternodes (Just a guess based on current trends). In 2025 we will have nearly 12 million coins and probably about 9000 masternodes. You should be able to see where I'm going. Those with a many masternodes can't even keep control of this if they are dedicating a good deal of earned coins back into the system. Year by year, our network will become increasingly more decentralized. I think it's a good strategy. You also have to consider running masternodes isn't free. Operators must pay for hosting or someone to administer their nodes. Those coins are also reentering the supply and some of them will be turned into a new masternode, ran by someone else. Every part of this process further decentralizes the system over time. |
|
|
|
No, I mean, that seems like it should belong in our proposal system bylaws. The protocol is a place for stopping exploits. It should remain as flexible as possible.
The bylaws would say something to the effect of "Proposal submission deadline for the budget is 7 days before the next payout date, to allow a reasonable amount of time to discuss and debate new entries. " In the case where a person goes against the bylaws, the network would vote them down automatically.
Fair enough, but I feel like something needs to be tweaked a bit. I have already seen a few votes come and go without a chance to vote on them. I feel like it is over too quickly. For something like a soda machine, which will remain someone's personal property, I feel like discussion is required. I am also skeptical about who is on the receiving end of these expenses... I assume whoever put up that proposal is doing the graphics design, and keep the $400 +$500 travel expenses. How much more of the $2000 are they keeping? These are the types of things I would like time to discuss before voting... but, I also don't want to troll forum(s) 24/7 to make sure I don't miss my chance...
I think instead of requiring a waiting period we just get the amount of votes needed right. 10% seems too low to me and I would suggest 20% for low budget projects and 30% for higher budget projects. Either way the system is fair. A bad proposal will not get in if has more no votes than 10% of the yes votes(20% yes/11% no).
Perhaps this will help extend the voting period? I'm not sure of the best solution, but I would appreciate it being looked into, thanks. I would also say the 10% rule is fair, eventually there just simply won't be enough money to go around. The amount of support you need to get paid is actually more than the weakest proposal in the system. This is on purpose, imagine we have 50 proposals in the system up for voting and all of the ones getting paid have more than 20-30% of the networks support. As the network grows it should get much harder to get funded. |
|
|
|
A proposal has to be on the network for at least 1 day before it qualifies to get paid. This was added to the system to stop that exact situation. Many of us monitor the budget system for the last few right before payment, so it would be impossible for anyone to sneak something in.
That's what "IsEstablished" means
Could you please raise this to 30-days? I do NOT like being rushed to vote on something I do not fully understand. I would like time to debate the proposal before being forced to vote on it A prime example is the soda machine... I would like to know who ends up owning this machine that the community is paying for... How much they plan to charge, and what they play to do with any proceeds from soda sales... this is important stuff if you want me to buy you a soda machine... I want to know what you are planning to do with my money... With only 3 days of deliberation, I wont get answers to my questions before the vote is over... Now imagine if I only check once/week... I might not even get 1 day to ask questions... I could have missed the vote entirely That seems like a standard that shouldn't be enforced by the protocol itself just for the sake of flexibility. For example, we strive to release budgets at least a week early to allow the network to consider them fully. However, we (the core team) were not behind the soda machine budget at all and it was submitted a total of 3 times, the first time right after our original budget. The first two were incorrect and wouldn't have been paid at all. I can imagine all sorts of situations where last minute alterations are needed, but the community is already well informed about the changes that are happening. So you don't think I should have time to debate a proposal before voting on it? You don't care that I don't want to monitor dash 24/7? If I only check once/week, and a budget gets passed after 3 days, there is a 57% chance I did not even have the opportunity to vote, much less ask questions... I feel discussion is necessary, and a 30-day minimum should be implemented for discussion and voting. I don't understand why you would say no... please elaborate No, I mean, that seems like it should belong in our proposal system bylaws. The protocol is a place for stopping exploits. It should remain as flexible as possible. The bylaws would say something to the effect of "Proposal submission deadline for the budget is 7 days before the next payout date, to allow a reasonable amount of time to discuss and debate new entries. " In the case where a person goes against the bylaws, the network would vote them down automatically. |
|
|
|
A proposal has to be on the network for at least 1 day before it qualifies to get paid. This was added to the system to stop that exact situation. Many of us monitor the budget system for the last few right before payment, so it would be impossible for anyone to sneak something in.
That's what "IsEstablished" means
Could you please raise this to 30-days? I do NOT like being rushed to vote on something I do not fully understand. I would like time to debate the proposal before being forced to vote on it A prime example is the soda machine... I would like to know who ends up owning this machine that the community is paying for... How much they plan to charge, and what they play to do with any proceeds from soda sales... this is important stuff if you want me to buy you a soda machine... I want to know what you are planning to do with my money... With only 3 days of deliberation, I wont get answers to my questions before the vote is over... Now imagine if I only check once/week... I might not even get 1 day to ask questions... I could have missed the vote entirely That seems like a standard that shouldn't be enforced by the protocol itself just for the sake of flexibility. For example, we strive to release budgets at least a week early to allow the network to consider them fully. However, we (the core team) were not behind the soda machine budget at all and it was submitted a total of 3 times, the first time right after our original budget. The first two were incorrect and wouldn't have been paid at all. I can imagine all sorts of situations where last minute alterations are needed, but the community is already well informed about the changes that are happening. |
|
|
|
Question.... shouldn't the system wait until the proposal expires before paying out? IIRC, the end date for the soda budget was Feb 10, 2016... yet it paid today? After only 3 days? I can Imagine a situation where someone proposes a budget, yes votes with their 500 MNs, and it gets paid before anyone has a chance to vote it down... not good... there should be a 30-day minimum or something! What if someone only checks once/week to vote? They totally missed their chance if this gets paid after only being up for 3 days! A proposal has to be on the network for at least 1 day before it qualifies to get paid. This was added to the system to stop that exact situation. Many of us monitor the budget system for the last few right before payment, so it would be impossible for anyone to sneak something in. "btc-miami-conf" : { "Name" : "btc-miami-conf", "URL" : " www.dashwhale.org/p/btc-miami-conf", "Hash" : "f0b16b4e748140a73550c8e169b2fdbc3346b5a3afb7e75d23dce08848c23716", "FeeHash" : "167697aa31df18683602decc79a5b5845279f3cdd201443ff7599dae35840367", "BlockStart" : 365552, "BlockEnd" : 390476, "TotalPaymentCount" : 1, "RemainingPaymentCount" : 1, "PaymentAddress" : "XembppomwnwrKPS4ShwRVS4A3r5pCJj1hJ", "Ratio" : 0.96871239, "Yeas" : 792, "Nays" : 25, "Abstains" : 0, "TotalPayment" : 1952.23000000, "MonthlyPayment" : 1952.23000000, "IsEstablished" : true, "IsValid" : false, "IsValidReason" : "", "fValid" : true } That's what "IsEstablished" means |
|
|
|
Budgets are paying out NOW! "main" : {
"FeeTX" : "9d868ff3dc5c8fbaac258003af4f827f19ba834966f7640337f4e8565f0c7cd7",
"Hash" : "df477a808ad192a52523321766d07e7d1f3a3b4ec79e46829bd0cc74b47d597c",
"BlockStart" : 398784,
"BlockEnd" : 398791,
"Proposals" : "lamassu-integration,core-team,public-awareness,590-soda-machine,dash-org,Sponsor-DailyDecrypt,ds-liquidity,transform-pr",
"VoteCount" : 3243,
"Status" : "OK",
"IsValid" : true,
"IsValidReason" : ""
} http://explorer.dash.org/block/0000000000053206a7e5d6ea521e7493b028aefb2a9682eff2891c1ba1e78519http://explorer.dash.org/block/00000000000a48eec8db06a8ce99096f6656c3dca9204eb9979a14989529cc3a |
|
|
|
dash for soda? Lame.....  You guys can come up with something better than that for sure. Agreed, but... Have to start somewhere I guess... Not lame at all. For those late to the party, what they're going to do is give away Dash at the North American Bitcon Conference, a little more than the soda costs, then have people buy a soda via instantX from the vending machine to show how easy it is to pay with Dash, and have it instantly confirmed, no delay, and no risk to the vendor / retail establishment. And there IS a problem with the shadows, unless the Fanta can is convex instead of concave   I still think it's lame... Try reading this: https://www.rebelmouse.com/dashisdigitalcash/l-1534366103.htmlI understand the concept!!!... I just think soda is ultra lame!!! It seems like a great proof of concept showing the power of instant transactions to me. |
|
|
|
Now that we are discussing budget proposals ..
Do we have a fix for the problem which caused the public awareness budget not getting paid in december 2015 ?
Yes, this will be fixed completely in the next version or evolution . Until then we will be finalizing the budgets manually to make sure they work. |
|
|
|
|
Show Posts
