• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

Version 12.1 Release

Status
Not open for further replies.
IPv4 is now manditory for masternodes ???
They were ambiguous about this right up to the last second...
this hurts :(
Yup. And it makes DASH look stupid. It's the sort of thing we'd expect from Apple, Bitcoin, or the US Government.

They keep claiming some "network fragmentation" nonsense, but it's just not reality... I ran dual stack and pure IPv6 nodes previously, and the dual stackers acted as bridges when bound to IPv6. thouogh not intended by design, this treatment worked perfectly as it was, and was flatly denied knowing that few people would actually examine it and find that the claim is bullshit.

There is a lot of "retrograde" happening as the false problems behind "adoption" are being hammered instead of examining the real problems.

It's a lot like having a car that won't run, so you check that the gas tank has gas in it... It's a bit low, so you fill it up. The car still won't run. So you just squirt gas in the windows and all over it, seal up the trunk so you can make a big pool of gas back there... They have no grasp of the greater marketplace, so they just keep on doing the one thing they do know....

Clearly the problem is elsewhere, but since they know nothing about engines, they just keep squirting gas on everything hoping that'll fix it. It's reached an extreme that they're starting to put inherent advantages on the chopping block in order to create more places to put more useless gas...

This is amplifying the Vendor Hostility problem. But, since they have no clue of the marketplace at large, they simply imagine that the Vendor Hostility problem doesn't exist. The extremism of it is stating to show in many details of the project, the IPv4 horseshit is only a minor point of exposure.

Continuing to expand Snowflake-desirable feature set was merely a waste of time before. Now, they're actually planning to remove Vendor-desirable features in order to create even more Snowflake-desirable features. What will this do for Adoption? Nothing. There will just be a bunch more whiny, clueless Snowflakes standing around with nowhere to use their DASH, repeatedly asking "Golly, I wonder why Vendors won't accept Crypto payments..." I'm telling you why. Pay attention!

They are either unwilling, or unable, to notice the problem, and it is growing unchecked...

If one were to put on the tinfoil hat, one might conclude that they're trying to force ATMs into relevancy...

I've done all the research needed to create a 3rd Party retail payment service backed by DASH. But, the direction DASH keeps moving would destroy such a service. Any sane business person would realize that it's a guaranteed bad move to invest in a venture for which the foundational entity is trying to destroy such venture. There's no future in it, so why would someone do it?

There's a chance that a more diverse model could exist, subsidizing the DASH/Retail element from it's primary business. But, again; why? Where's the incentive to create a parasitic sideshow?

I could be doing this by tomorrow. But, why do I want to waste money on a dead end project that DASH is openly and willfully trying to destroy before it is even created? BitPay or Coinbase could do it, but, again; why? Sure, you could sell it to them on being the first service of Crypt in Retail that actually works... But when they realize, as they mus, that DASH wants to undermine the inherent qualities of crypto that make it desirable for such use in the first place... That'd be a stupid move for them to make, which is why they haven't made it.

IX is still initiated backwards.

Payments planned to be reversible in the future, by an arbitrary 3rd party which has already demonstrated Vendor Hostility.

This model already exists. It's called Visa.
that is correct
Interpretation: We don't care @jimbit
sorry laaa
Interpretation: Fuck you, @jimbit
 
Last edited:
Got huge problems compiling on a Debian Stable build server. Can't do a git-pull. Thousands of merge conflicts. Total disaster.
Cloned again from github, but I cannot compile due to missing libraries. Would be nice if you would list changed requirements for compilation somewhere.

Code:
"g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.9/README.Bugs> for instructions.
Makefile:5418: recipe for target 'libbitcoin_server_a-init.o' failed
make[2]: *** [libbitcoin_server_a-init.o] Error 4"
 
Got huge problems compiling on a Debian Stable build server. Can't do a git-pull. Thousands of merge conflicts. Total disaster.
Cloned again from github, but I cannot compile due to missing libraries. Would be nice if you would list changed requirements for compilation somewhere.

Code:
"g++: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.9/README.Bugs> for instructions.
Makefile:5418: recipe for target 'libbitcoin_server_a-init.o' failed
make[2]: *** [libbitcoin_server_a-init.o] Error 4"
Possibly be killed because out of memory. please also check notes for buiding in doc/build-unix.md.
 
Possibly be killed because out of memory. please also check notes for buiding in doc/build-unix.md.

Thanks for the reply. Yes, according to the docs: "It is recommended to have at least 1 GB of memory available when compiling Dash Core". Never had problems compiling on machines with 2GB. Since 12.1 G++ eats memory like corn flakes.

I have increased the VM memory to 3072GB, but it's still eating up all the RAM and Swap. nvm, I'll just assign 16GB. Should be enough.
 
What happens to the Hardware wallets like Trezor and Ledger when Feb 12th hits with all 12.1...?
Technically it is possible now to start masternodes from a HW wallet - but it is not very user friendly yet.

If you are into Python/hacking you can use https://github.com/chaeplin/dashmnb by @chaeplin - @dark-sailor was succesful with it. Otherwise you'll need to wait some weeks for more mature solutions to hit the market.
 
I've just kicked off a 2 round 100 Dash privateSend mixing session... Let's see how long it takes...

Update: 15mins in and we're 50% done. Impressive :)

Edit: finished within 30mins. That's a big improvement on 12.0. Really impressive!

Walter
 
Last edited:
100 hrs after Dash 12.1 Launch = 98% - 100% Miner Support !
What a community - Tx to All ; )

Please retweet !!
https://twitter.com/Dashpay/status/830019978367741953

NxFZvhO.png
 
Anyone having issues on Linux (Ubuntu 16.04)? I have re-index two times and it seems like wallet.dat is not imported as the balance is 0 (updated from dash-0.12.0). Having the wallet.dat file saved, but what steps to follow in order to stay up-to-date and have the right balance, too.

EDIT:

I have try all of the rebuild options and nothing help. Should I download the old version of the wallet and using the wallet.dat file to start using it again?
 
Last edited:
@gotqn you need to copy wallet.dat from .dash to .dashcore and you are fine (remember to do it when the client s off)
When you started 12.1 the client created a new directory and empty wallet.
 
@gotqn you need to copy wallet.dat from .dash to .dashcore and you are fine (remember to do it when the client s off)
When you started 12.1 the client created a new directory and empty wallet.

Thanks a lot. It works like a charm. Additional question - when I am backing the wallet.dat file what file to use - this in .dashcore, or this in .dash?
 
12.1 info
The Network is doing well (update)
- Miners are at 100%
- Masternodes around 77%
but Merchants ,Exchanges ,3rd Parties ,.... still need time ,so there is NO rush to switch Enforcement back on again - no date is set yet ; )
(as we do NOT wanna leave anybody behind)

UHsEWSS.png
 
Status
Not open for further replies.
Back
Top