********** v12.0.45 : New Version ************* This is going to be our official v12 release. Please update if you haven't already, everything seems to be working pretty well now. @UdjinM6 chinese tw fix DS bug - endless collateral creation until one of them confirms refactor names and select logic for `ONLY_` coins enum members add masternodeSync.GetSyncStatus() / refactor mn sync status UI updates let translations mix qt and printf fixes for masternrode rpc fix GetSporkValue add mn list and mnw timeouts / use gettime / lower base timeout @eduffield lock wallet for select check mnw peer version fix GetSporkValue return fix spork int error Fix dseg message https://www.dashpay.io/downloads/ |
|
|
|
v12.0.45 Incoming  |
|
|
|
Since the developers are a little modest, I will add some of the cool features they forgot to show off in the release notes.  - Masternode inputs are locked automatically.
- GUI Wallet repair tools.
- Specific Spork, Masternode, etc update bars to ensure instanTX and darksend capability.
- Selectable interface themes and customizable wallet title.
- Masternode.conf is created automatically (if existing, the donation columns are ignored).
thanks for this, I was wondering. what the update consisted of. The details of the release are here: https://dashtalk.org/threads/v12-release.5888/Solarminer was just kindly posting about some cool features that were not featured in the official release. We did so many things I couldn't even remember all of them...  |
|
|
|
Sorry for a noob question....how long do we have before we HAVE to update our MN's? I'm waiting for Splwaik to return from vaction. Do we have a few days? Thanks.
I saw the date of 5th of September somewhere.. September 5th is when the networks will split. However, masternodes must be updated when enforcement goes into effect, which is 3-4 days out probably. |
|
|
|
If you're running linux, please go download the newest version here (protocol version 70103): https://www.dashpay.io/downloads/We're fixing a couple other things, then we'll be pushing out 12.0.45 later on today. |
|
|
|
We're definitely open to improving the pool distribution if anyone has ideas. However, PoS is incompatible with anything that uses masternode quorums. The quorums are chosen based off of the proof-of-work hash, so if we were to switch to a proof-of-stake model, we would end up with less secure hashes and other issues that would have to be addressed. That would allow an attacker to pick the masternodes that approve a transaction lock for example, something that we definitely want to avoid.
I might have an idea, but maybe it is too hard to implement. I believe as we all want to have as much spread of the hashing on one side and pool owners to have much profit from their miners on another side is really hard to meet. My idea is to use power of MNs in a way that every block which is mined on a pool with the higher/highest share of total hashrate should earn less DASHes then normal 50% of the block. If it can be implemented dynamical sharing the earnings of a block pool/MN we could dynamically solve spreading of hashes as miner will leave top hashrate pools by himself. So I am see it as like the more blocks you are finding in time the less profit you are getting from it... at the end of the day whole hash spreading should meet the equilibrium of spreading near to p2p pools. Also pools could compete again in % of fees as they used to... Maybe it is not possible to implement easily but I think it is a good idea for dynamically change block rewards for miners and MNs. I really think that this idea has potential, would like to hear from devs if they see it in a same way? Dynamically block reward is already achieved = difficulty of the network, so we could adjust it more per block with dynamically sharing block reward miner/MN as it is already on protocol level. pseudo math just to maybe represent better idea: DBR = dynamically block reward for miner in DASHs BR = block reward in DASHs = 5 DASH NSBR = network percentage of block reward for miner in percentage = 50% BPT = blocks found per time (defined time frame, lets say 1hr) for a miner , lets agree maxBPT to be 10 just to prove theory, if miner founds more then 10 blocks per time we will still use 10 in equation DBR = BR * (1- log(BPT)) * NSBR/100 And for MNs reward is = BR - DBR something like this  Well does this sounds interesting ... maybe we are on way to fix that 51% blockchain attack Good one rentahash, you could be in dev team for ideas EDIT: congratz on V12 guys, 2 masternodes updated 1 min ago! when im syncing wallet i get this stuck more than 15min  That's OK. It will start successfully syncing when more of the network gets updated. |
|
|
|
Got my masternode updated and started from the cold wallet. But I can't seem to see it in the masternode list?
I guess I'll have to wait for the nodes to sync up properly.
Great work DASH Team, really appreciate all the hard efforts to bring V12 to the network!
The network is slowly updating, it will take a bit for everything to start working properly. |
|
|
|
Imagine the miners were as committed to the dash project? Coinmine still has over 60% of the hashrate. This could kill all credibility for a coin to consistently have over 60% of it's hashrate generating from one pool.
I recall when BTC had this same issue, the community pulled together and miners started leaving the pool responsible.
All this community seems hell bent on protecting are their own feelings and rationale when called out on instamine etc.
If I were smooth or any of the other dash haters I would simply keep calling the community out on their laggard response to a network hashrate distribution issue.
Buckle up, do something as a community, spread the word to your miner friends on dash and tell them to leave coinmine for the time being and join another pool or go p2p mining(it's so dam easy)
Several long-time members have see this coming for a long time and have been trying to sound the alarm. Every time we try, we are completely ignored by the devs and largely ignored by the community. I finally just gave up and figured "why bother?" The possibility of a bad actor launching a "51% attack" against any PoW coin is, to me, doomsday. People like to point out that no rational pool admin would do such a thing, and they are right, for the most part. But what happens if: a) Pool gets hacked. If Target and God knows how many other major corporations with dekamillion dollar IT budgets can get successfully hacked, do you really thing suchpool (or whomever) can't be? b) Pool op is irrational/delusional/destructive. c) Pool op concludes that double spending will net him more income than the pool itself does. Look at exit scams like Evolution--the guy was making insane bank, so stealing everything and shutting down the site seemed irrational. But when he figured out he could make more in one scam than he could in five years of hard work, he took the easy route. I've practically begged devs to explore another model. Proof of Service runs our masternode network--how come something like that can't run our blockchain? I don't know, maybe it's impossible, but nobody even bothers to respond to my threads on dashtalk, so I don't even make them anymore. The only good news in this whole deal is that, as far as I know, InstantX transactions cannot be double spent because they are locked by the masternode network. In a worst-case scenario, that might could be used to stabilize the network until the problem could be dealt with. P.S. A bit of reading between the lines implies that the devs are looking strongly toward the possibility of using the masternode network in their future scalability plans. With the new "sendinstantxto" (or whatever the exact command is), it's now easier to send multiple IX's at the same time. This looks promising. We're definitely open to improving the pool distribution if anyone has ideas. However, PoS is incompatible with anything that uses masternode quorums. The quorums are chosen based off of the proof-of-work hash, so if we were to switch to a proof-of-stake model, we would end up with less secure hashes and other issues that would have to be addressed. That would allow an attacker to pick the masternodes that approve a transaction lock for example, something that we definitely want to avoid. |
|
|
|
I realize there's no hurry on V12, but just out of curiosity...we've already blown through two release dates...is there any idea of when this might be released? Reading the test thread it looks like it could be anywhere from hours to days to a week!
In a couple hours |
|
|
|
Build error /usr/include/qt5/QtCore/qglobal.h:1008:4: error: #error "You must build your code with position independent code if Qt was built with -reduce-relocations. " "Compile your code with -fPIC or -fPIE."
# error "You must build your code with position independent code if Qt was built with -reduce-relocations. "\
Any work around that doesn't involve QT4? Anyone? I've never seen that error, but I found this from googling around: https://forum.qt.io/topic/28359/qt5-compilation-catastrophic-error/4Hope that helps |
|
|
|
what is the policy for non standard transactions, and do miners/pools include them into blocks? Is multi-sig fully supported ?
what is the policy for non standard transactions, and do miners/pools include them into blocks? No Is multi-sig fully supported ? Yes |
|
|
|
Doesn't count as anonymous because 80%+ of the utxoset is owned by entities who mined them before it became public and global, which means that those entities can deanonymise pretty much all future transactions.
Marketcap is irrelevant as it's easily inflated (doubly so when all you have to do is slightly bump the price due to the massive amount that's already emitted).
That's a valid point, because when you mix you'll randomly mix with them 82% of the time. We can actually work out the probability of transactions being 100% transparent to this hidden party. Mixin of 1 would be transparent 82.2% of the time. Mixin of 2 would be transparent 67.2% of the time. Mixin of 3 would be transparent 55.1% of the time. Mixin of 4 would be transparent 45.2% of the time. Mixin of 5 would be transparent 37.0% of the time. Mixin of 6 would be transparent 30.4% of the time. Mixin of 7 would be transparent 24.9% of the time. The more you mix with, the more transactions cost and the more storage it requires. |
|
|
|
TESTNET UPDATE - (ONLY TESTNET)DOWNGRADE TEST - 0.11.2.23
I'm happy to announce that v12 looks like it's finished and is very stable! The final test we will need to do is to downgrade the network to 0.11.2.23, then re-upgrade to 12.0.35. The final version will activate a hard fork and the budget system within a day of being launched. Then after a few days (probably about Wednesday), we'll launch v12 officially on mainnet!
Instructions:
1. Please download the official client from dashpay.io
2. Go into dash.conf and add "txindex=1" (our database has this on by default now)
3. Start the client with --reindex
4. Start masternodes anything else you had running
The reindex will send us back to the last valid block before v12 became active last time, so we might need to recreate masternodes. However, when we upgrade from 11.2.23 to 12.0 they should still function correctly.
Thanks so much for helping with testing and the hard work you've put in! You've all made this release a great success already.
-Evan https://dashtalk.org/threads/v12-testing-thread.5484/page-104
|
|
|
|
Here's an interesting thought experiment... The only real problem with that logic is we need to store the transactions in a block after they happen and blocks have an upper limit on size. 3000 tx per second that would mean we have 450000.0 transactions in a block. I'm getting about 107MB per block with some rough math. If the network requires about 4x the blocksize in bandwidth, we could possibly need about 100MB a minute. To get 100MB a minute consistently we could have a 3rd tier that lives on a high performance network (maybe a specific zone of AWS for high performance computing). If you want to use our high performance network, you would switch through a 2-way peg to this second chain, which has pretty much infinite speed. We could actually have a bunch of these, all on separate networks throughout the world, so that if one is having problems, there's always redundancy. Hmm... The masternode network + quorums is quite powerful for solving these types of problems. Question; Would that be 100 mb a minute be the same size on the blockchain? How would we store such a behemoth? I mean seriously, no matter how you shake it, blockchain size is going to have to be dealt with some day, and somewhere, I think most would agree, the whole thing must be stored in it's entirety, decentralized. This will be a problem for everyone. What do you think needs to be done? I can see chopping it up and storing sections of it, redundantly, amongst groups of nodes, perhaps in a compressed format, digitally signed and archived (again redundantly) with the "working" chain being a trimmed version. What other options might there be? Thanks for your opinion! That's the on-chain size, but by then we'll have pruning. So we'll just be storing unspent outputs. Even if the blockchain is a terabyte pruned, it's only being stored by the masternodes on this separate chain. We're talking about having billions of transactions per day, that means that Dash is worth tons of money. This network would be ran by the masternode operators and they would still be earning a share of the revenue for providing the services. At this point, the services are very costly, but the rewards will be even greater. This is going to be a business for the masternode operators, something like what's happening with Bitcoin pools but much more decentralized. So a full blockchain for the masternoders and a 'pruned' one for general full client use, is it known how much space can be saved by this technique of streamlining the blockchain ? I have no idea, I just know pruning is definitely possible. I think generally we would just have clients use an API for moving money around, the API would hit a random masternode in the network. Then we just build a nice lite client on top of it. If you need a full-client, you could use the Dash network itself. |
|
|
|
Here's an interesting thought experiment... The only real problem with that logic is we need to store the transactions in a block after they happen and blocks have an upper limit on size. 3000 tx per second that would mean we have 450000.0 transactions in a block. I'm getting about 107MB per block with some rough math. If the network requires about 4x the blocksize in bandwidth, we could possibly need about 100MB a minute. To get 100MB a minute consistently we could have a 3rd tier that lives on a high performance network (maybe a specific zone of AWS for high performance computing). If you want to use our high performance network, you would switch through a 2-way peg to this second chain, which has pretty much infinite speed. We could actually have a bunch of these, all on separate networks throughout the world, so that if one is having problems, there's always redundancy. Hmm... The masternode network + quorums is quite powerful for solving these types of problems. Question; Would that be 100 mb a minute be the same size on the blockchain? How would we store such a behemoth? I mean seriously, no matter how you shake it, blockchain size is going to have to be dealt with some day, and somewhere, I think most would agree, the whole thing must be stored in it's entirety, decentralized. This will be a problem for everyone. What do you think needs to be done? I can see chopping it up and storing sections of it, redundantly, amongst groups of nodes, perhaps in a compressed format, digitally signed and archived (again redundantly) with the "working" chain being a trimmed version. What other options might there be? Thanks for your opinion! That's the on-chain size, but by then we'll have pruning. So we'll just be storing unspent outputs. Even if the blockchain is a terabyte pruned, it's only being stored by the masternodes on this separate chain. We're talking about having billions of transactions per day, that means that Dash is worth tons of money. This network would be ran by the masternode operators and they would still be earning a share of the revenue for providing the services. At this point, the services are very costly, but the rewards will be even greater. This is going to be a business for the masternode operators, something like what's happening with Bitcoin pools but much more decentralized. |
|
|
|
Bitcoin currently handles 7 unconfirmed tx per second + confirmation/waiting time
DASH handles 10 confirmed tx per second and you can walk out the shop with the merchant safe and happy.
Not quite right, the entire Bitcoin network handles a maximum of 7 txes per second. Each IX only requires a tiny subset of the 3000 MN total to work. You're looking at tx throughput two orders of magnitude+ better than BTC, each one in seconds, not minutes/hours. So if the subset is 10 for example, at 3k M-Nodes the TPS would be 3,000 as well, I assume? That's 1k more than VISA handles atm. This is a very interesting read on that matter: https://en.bitcoin.it/wiki/ScalabilityHere's an interesting thought experiment... The only real problem with that logic is we need to store the transactions in a block after they happen and blocks have an upper limit on size. 3000 tx per second that would mean we have 450000.0 transactions in a block. I'm getting about 107MB per block with some rough math. If the network requires about 4x the blocksize in bandwidth, we could possibly need about 100MB a minute. To get 100MB a minute consistently we could have a 3rd tier that lives on a high performance network (maybe a specific zone of AWS for high performance computing). If you want to use our high performance network, you would switch through a 2-way peg to this second chain, which has pretty much infinite speed. We could actually have a bunch of these, all on separate networks throughout the world, so that if one is having problems, there's always redundancy. Hmm... The masternode network + quorums is quite powerful for solving these types of problems. |
|
|
|
dash is not even really anonymous, it will replaced sooner or later by an cryptonode coin  Once the budget system is running we're going to have bounties available. How about $2000 to break an 8 round DS? It's never been done because it's impossible |
|
|
|
|
Show Posts
