there are now two soda machine budget proposals since the last hour :
The first one has transaction id : cf26e6b9bca96048c8fc9ff48f3dbbc3eeb80c19ebc895c2bc13b6f4525170f9 so that looks to be Evan's budget proposal,
is the second one a mistake ?
First one couldn't fit, one DASH too much, so Evan submitted another one with a new total. i think its better we all vote NO to the second incorrect budget proposal (Proposal “591-soda-machine“) so it disappears from the budget list fast... Yep, that's the best idea. |
|
|
|
Hey guys, Can I please ask all you Masternode Voters out there, to come read and give your thoughts on this possible proposal to increase the core team's salaries. It's currently too small. The guys are getting paid something like under $200 worth of dash a month and they do so much. Unlike Evan and possibly one or two other people, most of the team came to us after the initial mining hiccup and cheap prices. What Dash they own were hard bought, and not so many. I know Evan wanted to be conservative, but I also think he intended to share the initial salary budget with a much smaller team. The team has grown quite a bit, and there are new team members going through the vetting process. Now I know that in the future, the way this should work, is each person working for Dash should be a sub-contractor. But we're still early on, and the wheels are being greased, and the MN owners are fickle, so one budget seems the safest route to go for now, the short term. Speaking of which, I propose we do this no more than quarterly, as the Dash price could jump up this year, and the budget Evan proposes could become plenty. Then again, it could continue to stagnate. So please come discuss this. I'm willing to put the 5 coins up for this, but I'm pretty damn poor so that's a lot of money to me, so I want a good indicator that this will be voted in before I risk it (It would break my heart if I lost them thar coins to a failed effort, LOL) So I can only feel confident if you all speak up. So please come over and give me a piece of your mind  https://dashtalk.org/threads/core-team-budget-update-proposal.7427/#post-77620We're actually working on making sweeping changes to the way the core-team salaries are calculated at the moment. Can we wait to have this conversation? We'll be releasing something soon, maybe Monday. |
|
|
|
There is 591 DASH available, the simple solution would be to do a proposal for that amount so the whole budget can be allocated. The difference is small 60 DASH that we can fund separate or later. Otherwise the 590 DASH would no be created. This way we can have full budget allocation this month which would be nice.
I can see: 1. Instantx-Soda-Machine - 650 DASH - 21.67% 2. labitconf-adv - 1,500 DASH - 18.7% So... Is there a risk of labitconf-adv won't be compensated (1500 DASH won't be created)? ... Seems like there is some space to improve the budget allocation algorithm... labitconf-adv is an old proposal, it was already paid and it will not be paid ever again. Maybe we should continue the conversation in dashtalk, not to disturb the conversation here. The only issue with the soda machine proposal is it exceeds the available budget by 60 DASH, that is all. To be honest proposal owner should have checked when making the proposal what was the availability. Solution is simple just do a new one for 590 DASH and done, the difference is small, no need to make it a big deal. Unfortanately the "591-soda-machine" was a little bit too big for the next super block and will not be paid. Due to this I've went ahead and submitted a new proposal called "590-soda-machine", which will definitely fit in the next budget. For future reference, here's how I figured out out the spacing. The command "mnbudget projection" will give you the exact budget that will be paid if the budget was finalized right now. From this command, from this command you can look at the last "TotalBudgetAlloted", which represents the total amount that will be allocated and paid in the next super block. Currently this amount is 7432.26000000. I've also added a new command in the v13-evo branch on our main github, "mnbudget nextbudgetsize", this will calculate the next budget superblock size. mnbudget nextbudgetsize == 802285689600 mnbudget totalbudgetalloted == 7432.26000000 802285689600-7432.26000000 = 59059689600 (590.59 DASH) So now we have an excess of .59 DASH, I think we're good  Ps: this is exactly how the budget system was intended to be used and work! It's really exciting to see us filling up the budgets to their exact allowed amount and prioritizing what we're doing. I'll also try to improve the commands for getting this type of information from the budget system, it's a real pain at the moment, but I see what needs to be done. Please vote! mnbudget vote cf26e6b9bca96048c8fc9ff48f3dbbc3eeb80c19ebc895c2bc13b6f4525170f9 yes |
|
|
|
our dash n drink machine's new face (first proto)  Hmm, maybe we can get this made into a banner? Or would that go on the side of the machine? |
|
|
|
I was browsing reddit when I stumbled across a really nice post about all of the issues with scaling Bitcoin. It's well worth the time to read: https://www.reddit.com/r/Bitcoin/comments/3ybaqj/an_attempt_at_a_fully_comprehensive_look_at_how/Here's one really great point I hadn't thought of. I've thought a lot about lightning, but I never made the connection between the price to publish and it's utility. Problems with The Lightning Network
The LN works relatively well (in theory) when the cost and time to publish a set of transactions to the network are kept low. Unfortunately, when the cost and time to publish a set of transactions on the blockchain become high, the LN's utility is diminished. The trust you get from a transaction on the LN comes only from the trustless nature of having transactions published to the bitcoin network. What this means is that if a transaction cannot be published on the bitcoin network then the LN transaction is not secured at all. As transactions fees rise on the bitcoin blockchain the LN utility is diminished. Lets take an example:
Cost of publishing a transaction to the bitcoin network = $20
LN transaction between Bob and Alice = $20.
Transaction between Bob and Alice has problem therefore we want to publish it to the blockchain.
Amount of funds left after transaction is published to the blockchain = $20 - $20 = $0. |
|
|
|
Ah yes, I should have, TBH it's so rare that I do transactions under 100 DASH to others that I forget about being able to use it, looking forward to when there's a higher limit - or none for InstantXing.
There's a 100 DASH limit to InstantX? I missed that one... I thought it was 1000. Ah, maybe it's 1,000 DASH, not sure, I just tried 199 DASH and it InstantXed np, so either I forgot the limit or my info is out of date. Ah, great. Unlimited InstantX would be a better sell, though, you're right. InstantX is now limited to 10000 DASH. The setting is just a spork |
|
|
|
This is how I envision DASH payments to work on the web... Am I close or a mile away?  DAPI allows ANY two peers on the network to communicate directly and send ANY messages they wish between themselves. Therefore all future implementation of this type of technology (payment channels, one click purchasing, etc) is actually done in the lite wallet itself (python, javascript, etc). So it's more like you telling the website "hey my username is Evan", then it sends a temporary request which allows the communication channel, after which let's say you want to buy socks, the website will ask your wallet directly, "Do you want buy socks from XYZ for $14? (along with the correct payment address to send to, etc)". Then you click OK, which sends the payment to that merchant. If you broadcast a payment using the first tier, there will be normal fees. We don't need RBF because we can calculate a fee per kb using masternode quorums for the rest of the network. For third tier users, they'll pay for processing time they use on the network, not per transaction. Each time you do anything, the network will update your profile and say "User Evan used 123 milliseconds of processing time" via a quorum action. All users get some amount of free processing time, which will be calculated by the network to allow 90% of our users to maintain 100% free accounts. In economic terms, our heavy users and economic inflation (e.g. creation of new coins being paid to the second tier) are going to subsidize our regular users by paying for their processing time on the network. I think the target audience should have completely free access to the network and we can shift things around to make that happen. |
|
|
|
How to make DASH look good in a few simple steps. 1 - Continue development of Evolution. 2 - Continue to shun anything that ice's favorite dev (Peter Todd) thows out there. 3 - When posting an image, be sure to laugh at tinypic making you type icebreaker  Every day that goes by, DASH looks better and better. Every day Bitcoin looks worse. BEHOLD:  Wtf?! That's fscking sabotage, it drastically alters a high percentage of existing uses and needs to be reverted immediately and Peter Todds commit access revoked. Ffs, that effects way more users than a change of block size would and the main "feature" seems to be allowing bidding wars to be included in bloated blocks. Should've known there was something dodgy about that guy when the unwelcome guests here in this thread where quoting him endlessly, the cancer's running deep in Bitcoin but every problem can be seen as an opportunity and Dash will come up with defences against this kind of BS, commits by consensus should stop this shit dead in its tracks. Every day that goes by proves that the world actually needs Dash. This space needs a project that proves you can govern and fund one of these projects with no centralization, support instant transactions and scales without centralizing the full nodes around a few large companies (which is also happening in BTC). BTC and Dash are really going in separate directions and I think we should start being careful about what we merge upstream; I'm definitely not merging RBF. |
|
|
|
Prototype Update: Thanks to @salmion for our new design  Looking great, but what does oaeu mean? My keyboard is dvorak  I didn't even know that existed! Wow, do you know how to use both types of keyboards? if so, does it mess you up? Still don't understand what oaeu means though. Google isn't helping  LOL. Anyway, love the new wallet layout and utilities, this is going to be truly awesome! and LOL, otoh, truly we are Ha, I just hit the first four letters... it's like typing asdf |
|
|
|
Prototype Update: Thanks to @salmion for our new design Looking great, but what does oaeu mean? My keyboard is dvorak |
|
|
|
Prototype Update: Thanks to @salmion for our new design |
|
|
|
[...]Masternodes could indeed wreck havoc. The InstantX white paper shows some math that claims an adversary needs 2/3 of the masternodes to attain 1.72% chance of controlling the majority of a single quorum. I think this math may be flawed. Can you whip up the correct probability math quickly or should I? https://www.dash.org/instantx/I see the flaw in Dash's math: Probabilities of attack can be calculated by the chance of a masternode being selected as the winning node for a given block (1/1000). To subvert the system an attacker would require operating all ten masternodes that won a given election The attacker only needs less than 10 of the of masternodes which are eligible to authorize an InstantX lock for a specific UTXO. Because if InstantX requires all 10 masternodes to authorize (which I believe is what the white paper implies), then the attacker can block (i.e. jam) InstantX 65% of the time with only 1/10 of the masternodes! With 50% of the masternodes, the attacker could jam the InstantX 99.9% of the time. There is the 50% attack. This is probably why for Evolution, Evan changed the requirement to a simple majority (or some N-of-M) of each eligible quorum. Dash's flawed math in the InstantX paper incorrectly assumes the attacker needs all 10 of the eligible masternodes. Thus if the attacker owns 50% of the masternodes, the attacker has at least the 6/10th majority in 38% of the InstantX transactions and also can block (jam) the InstantX transactions 62% time with only at least a 5/10ths minority. Thus the attacker can attack 38 + 62 = 100% of the time. There is the 50% attack again. And Evan erroneously claimed that Evolution eliminates the 50% attack.  That is the hypergeometric distribution. https://en.wikipedia.org/wiki/Hypergeometric_distributionhttp://math.stackexchange.com/questions/422414/probability-of-selecting-q-red-balls-from-m-red-balls-and-n-blue-ballsSo enter here: http://stattrek.com/online-calculator/hypergeometric.aspx | 1000 masternodes | Number of successes in population: | 500 adversarial, colluding masternodes | | 10 eligible masternodes | Number of successes in sample (x): | 6 needed for a majority |
I don't think anyone has the incentive to buy up 50% of the masternodes to do the other attacks (actually the attacks could be achieved somewhat infrequently with a much smaller % of the masternodes, e.g. with 10% of the masternodes every 666th UTXO could be jammed and every 10,000th UTXO could be spent as many times as desired).
This entire argument is based on an invalid premise! So your jamming attack doesn't work... https://github.com/evan82/dash/blob/master/src/instantx.h#L25The paper is very outdated and this is why I should have written the code first, then the whitepaper second. I found all of these issues when I was actually writing the code, so it doesn't include any of them. https://github.com/evan82/dash/blob/master/src/instantx.cpphttps://github.com/evan82/dash/blob/master/src/instantx.hhttps://github.com/evan82/dash/blob/master/src/main.cpp#L2973You should really try to follow the progress of evolution, what's happening is getting exciting. All of the existing Dash technology is just a simple prototype of what we're now making. For example, the new quorum system uses age-based quorum layering. Each quorum will have 25% nodes that are very old (more than 2 years), 25% that are more than a year, 25% that are more than six months and 25% that are more recent. As the network gets older, we will also use the most trusted nodes as 25% of all quorums, so it becomes impossible to gain a majority as a bad actor. Also, you said this "Thus if the attacker owns 50% of the masternodes, the attacker has at least the 6/10th majority in 38% of the InstantX transactions and also can block (jam) the InstantX transactions 62% time with only at least a 5/10ths minority. Thus the attacker can attack 38 + 62 = 100% of the time. There is the 50% attack again. And Evan erroneously claimed that Evolution eliminates the 50% attack. " That's not a 51% attack! There's only one and it's related to mining... That's the one I'm trying to solve. The idea behind this is I can create a system where the masternodes via quorum actions will determine which blocks will have which transactions... If the miners don't decide which transactions are in which block, it removes all mining vulnerabilities. They are responsible for creating the proof of work hashes, which are the bases for the quorum selection. Feedback and discussion is always welcome! Thanks for helping us make Dash Evolution better. |
|
|
|
The main reason why I don't vote anymore, is that I have no incentive to vote, since the vote is primarily (solely) defined by the three founders (Evan, Daniel and ?) and Otoh. Together they probably own up to 1,000,000 coins. This is public knowledge. I don't know if they have set up masternodes for all the coins they own, but it would seem reasonable to assume they did so (or largely so). The voting threshold was set to 10% (Yes - No) votes, which is far too low to consider this to be somewhat of a democratic voting process, taking into account the total amount of masternodes these 4 individuals (probably) own. It's safe to assume they control the outcome of the voting process. Evan avoided the question from the interviewer at the Mexico conference regarding this specific point. Evan didn't answer it truthfully, avoiding the essence of the question, so I'm sure he's aware this is not a long term (viable) setup. In the end it will just be a few people who will still vote, if nothing changes. A lot of time has gone by and it seemed to me that the initial configuration would remain so. This would effectively render DGBB a pointless functionality. How can you motivate anyone who just owns 1 or even 10 masternodes to participate, in the current setup/configuration? It's just a formality without any significance whatsoever. This was entirely to be expected and I'm somewhat surprised it has taken this long to actually being discussed, as if you all don't know what's going on? You think people are incapable of executing simple commands in their wallet console? It was obvious from the first post regarding DGBB that this was going to happen. I personally imagined this to be changed once the DGBB functionality was proven to be successfully implemented (which seems to be the case), but it hasn't and there's been no communication on changing this threshold, so up to now I'm still disappointed to see new proposals before actually fine-tuning DGBB to a more righteous configuration. Since I'm not being penalized for not voting and there's no financial incentive to vote, despite it primarily not being democratic, I've completely lost interest in voting for any new proposal. Why should I waste my energy on it? I have other projects I'm involved in, so I use my time where I'm of actual value. The technology is probably good, but the threshold to pass a vote with DGBB is obviously wrong. Why such low targets? Scared no proposal would ever pass through? The Dash team really needed that salary proposal to pass through didn't they? So going for 10% made it a sure thing. It's my opinion that the setting must be 50%+1 (Yes - No). If you don't achieve this, your proposal is simply not good or important enough. Feel free to try again. Yes this also means that some proposals from the Dash team itself may have a hard(er) time getting through. In my opinion, that's actually a good thing and would truly require (pretty much) the whole dash team ánd masternode owner community to vote and discuss/challenge/refine each proposal. It's not about being notified there's a new proposal, it's not about how easy the voting process is, ... it's the treshold. Raising the threshold will bring me back to the voting process. Right now raising the threshold to 50%+1 would result in no budget proposal ever passing, therefore nullifying the entire budget system in the first place. If you want the threshold to be raised, then start voting and maybe the team will raise it. If enough people stop voting, then the team will likely lower it. There have to be enough people participating in order for budgets to be able to pass. For what it's worth, iirc Otoh never votes his nodes. P.S. I'm not really concerned. Most people in democracies don't vote in any event. Shouldn't we start with the lowest hanging fruit? This whole system was thrown together in about 2 months and is pretty rough at the moment (although it's working really well I think). This Dashpay wallet could actually support viewing new proposals, it could keep track of the ones you've seen and ask you to vote on the ones you haven't. It's much easier to write really intuitive and friendly software that encourages this type of behavior without enforcing anything. About me and Otoh, both of us combined control ~800-900 masternodes, which is 23-26% of the current amount. This percentage is actually falling due to the additional masternodes being added every day, I would buy more Dash and start more nodes, but my wife would kill me |
|
|
|
Wow, that's nice |
|
|
|
I think last MN payment is missing. Does someone else has same problem? Or MN payment time has been changed? Does someone knows something about it?
Yes, I also have that problem. My masternode is still not receive any payment in about 7 days. I can confirm, it happened to me as well. I have one going on 10 days now, right when the last payment was supposed to hit, my place in the queue reset. The MN itself has been active for weeks. All I can say is that sometimes it happens. One of mine took 10 days, I don't know if that's the new norm or if I skipped a payment. There is a rare instance where if your masternode gets 2 votes but another gets more, they get paid and you both go to the back of the line. But that should be super rare. I think it's simply that we have so many Masternodes now. We average about 550 (not 576) blocks per day, and that ends up being a payment every 6.2 days. Add variance for the time you're up for payment, and it easily could be 4 days or 7+ days. But it should all even out. The payment system is built on probabilities. 10-15 days is normal. Anything beyond 15 days probably means there's something wrong with your node (it's still possible, even for 20+ days, but it'll probably take us about 10 years to find 1 example of that) |
|
|
|
I just allowed public commenting on the document in the settings, feel free! |
|
|
|
Am I actually watching you update this as I'm reading it? Very neeto. Yep |
|
|
|
Am I the only one who gets a little bit uneasy about the fungibility part lately? How is the priority currently beside all the other features? The sooner we get rid of this long darksend times, the better. When do you think the "separate paper" about Privacy & Fungibility is ready Evan? Thank you.
I'm currently looking at doing single layer DS through the DAPI implementation, which would also be blinded by network relay. DS is impenetrable at a single layer if it's blinded by the network. This would bring down mix times per 0 to 1000 dash to a few seconds on the network. Also, it doesn't cause as much bloat of the network to keep the privacy and fungibility. I think it'll work well. This is out of scope for the next prototype though, we want to create something super simple. |
|
|
|
|
Show Posts
