Topic: [ANN][DASH] Dash (dash.org) | First Self-Funding Self-Governing Crypto Currency - page 1938. (Read 9723748 times)
August 17, 2015, 07:19:52 AM
Nice article of snowden on Dashtalk bye the way.....
August 17, 2015, 07:05:31 AM
Build from source choking @ :-
Code:
/usr/bin/ld: ./leveldb/libleveldb.a(db_impl.o): relocation R_X86_64_32S against `_ZTVN7leveldb2DBE' can not be used when making a shared object; recompile with -fPIC
./leveldb/libleveldb.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
make[2]: *** [dashd] Error 1
./leveldb/libleveldb.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
make[2]: *** [dashd] Error 1
Anyone got a work around?
https://github.com/dashpay/dash/blob/master/doc/
look for build-YOUR_OS.md file
also issue
Code:
./autogen.sh && ./configure && make clean
before actually running make 
August 17, 2015, 06:24:26 AM
I think your point is valid when thinking about Chinese miners.
For everything else, there is SPV.
And who the hell is going to support XT Full nodes for SPV? mobile app devs through sales? I don't think so.
Hence what pseudo-Satoshi wrote on the bitcoin-dev before yesterday.
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010238.html
Quote
They use my old writings to make claims about what Bitcoin was supposed to be. However I acknowledge that a lot has changed since that time, and new knowledge has been gained that contradicts some of my early opinions. For example I didn't anticipate pooled mining and its effects on the security of the network. Making Bitcoin a competitive monetary system while also preserving its security properties is not a trivial problem, and we should take more time to come up with a robust solution. I suspect we need a better incentive for users to run nodes instead of relying solely on altruism.
Calm down dear, calm down.
I was simply referring to the point that SPVs are more likely to be run in third world countries than full nodes.
Mike Hearn created the first Bitcoin SPV wallet and it is still the most popular, I think. He will have figured out what would happen on SPVs.
I think what they are hoping is that Bitcoin XT gets to a critical mass and becomes Bitcoin core when it reaches more than 75% of Bitcoin nodes. The big Chinese pools / miners have probably already signed up to XT, but on the basis that 75% economic threshold is reached.
Everyone is right to be worried about Bitcoin fragmenting. It is currently the reserve currency for most if not all altcoins.
August 17, 2015, 06:07:46 AM
What pseudo-Satoshi should say is that DASH has solved a critical issue that BTC has realised in that DASH has introduced an incentive for users to run master nodes in addition to finding a near perfect balance in providing a competitive monetary system while also preserving security and privacy.
This is why I am now backing a second option in DASH and will be exchanging some of my pseudo-Satoshi BTC into DASH.
さようなら
Thats precisely what it reads in the line. Bitcoin-XT surely is dividing the community. There are now non-BitcoinXT mining clients only to mess with XT. It's going bananas. This is going to harm BTC very badly. Not technically, but all around
August 17, 2015, 05:40:44 AM
I think your point is valid when thinking about Chinese miners.
For everything else, there is SPV.
And who the hell is going to support XT Full nodes for SPV? mobile app devs through sales? I don't think so.
Hence what pseudo-Satoshi wrote on the bitcoin-dev before yesterday.
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010238.html
Quote
They use my old writings to make claims about what Bitcoin was supposed to be. However I acknowledge that a lot has changed since that time, and new knowledge has been gained that contradicts some of my early opinions. For example I didn't anticipate pooled mining and its effects on the security of the network. Making Bitcoin a competitive monetary system while also preserving its security properties is not a trivial problem, and we should take more time to come up with a robust solution. I suspect we need a better incentive for users to run nodes instead of relying solely on altruism.
August 17, 2015, 05:20:24 AM
I must say, even though I read a lot of posts from people saying they don't like Mike Hearn, every time I read his arguments they make far more sense to me than than the anti-revision lobby (those who want the blocksize left alone).
If I were "big banks" / "the Elite" etc and I felt threatened by BTC and wanted to kill it, I would laugh at how naive the Bitcoin XT design is.
8mb blocks = bloat attack vector wide open. Bloat that can make Bitcoin XT => DOA within months. I would simply pay for some bogus transactions, insert tons of bloat (at 8mb blocks, you can get around to 115gb in 100 days and half a terabyte in one year) and then proclaim BTC dead because it's way too bloated for real life adoption.
Even at 40gb people are like "oh man, do I really have to download this?" and many simply don't do it. Why would they be happy with downloading TBs instead of GBs? And the western / developed world, is one thing with all the access in cheap technology that we have. What about countries where they really need bitcoin for online banking and wealth preservation, and where access to cheap hardware (or even cheap bandwidth) is more problematic than the west? Not everything is equal in this planet. In the USA a 2tb drive might be a couple of hours of one's job, while in some part of the planet it could be a month's wage.
I think your point is valid when thinking about Chinese miners.
For everything else, there is SPV.
August 17, 2015, 04:38:06 AM
I must say, even though I read a lot of posts from people saying they don't like Mike Hearn, every time I read his arguments they make far more sense to me than than the anti-revision lobby (those who want the blocksize left alone).
If I were "big banks" / "the Elite" etc and I felt threatened by BTC and wanted to kill it, I would laugh at how naive the Bitcoin XT design is.
8mb blocks = bloat attack vector wide open. Bloat that can make Bitcoin XT => DOA within months. I would simply pay for some bogus transactions, insert tons of bloat (at 8mb blocks, you can get around to 115gb in 100 days and half a terabyte in one year) and then proclaim BTC dead because it's way too bloated for real life adoption.
Even at 40gb people are like "oh man, do I really have to download this?" and many simply don't do it. Why would they be happy with downloading TBs instead of GBs? And the western / developed world, is one thing with all the access in cheap technology that we have. What about countries where they really need bitcoin for online banking and wealth preservation, and where access to cheap hardware (or even cheap bandwidth) is more problematic than the west? Not everything is equal in this planet. In the USA a 2tb drive might be a couple of hours of one's job, while in some part of the planet it could be a month's wage.
August 17, 2015, 04:05:37 AM
Working on it now....
[started over]
All MN upgraded fine.
All OK for me boss!
Edit 17.5% now, come on guys... Enforcement is coming
Maybe they don't want to pay the 15% dev tax for a release that failed to deliver the promised masternode blinding.
August 17, 2015, 04:01:04 AM
Build from source choking @ :-
Code:
/usr/bin/ld: ./leveldb/libleveldb.a(db_impl.o): relocation R_X86_64_32S against `_ZTVN7leveldb2DBE' can not be used when making a shared object; recompile with -fPIC
./leveldb/libleveldb.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
make[2]: *** [dashd] Error 1
./leveldb/libleveldb.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
make[2]: *** [dashd] Error 1
Anyone got a work around?
Check Dashtalk.org, either in the testing thread or maybe better now in the v12 announcement thread... here, let me see:
https://dashtalk.org/threads/v12-release.5888/page-16
Good luck!
August 16, 2015, 11:17:26 PM
Build from source choking @ :-
Code:
/usr/bin/ld: ./leveldb/libleveldb.a(db_impl.o): relocation R_X86_64_32S against `_ZTVN7leveldb2DBE' can not be used when making a shared object; recompile with -fPIC
./leveldb/libleveldb.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
make[2]: *** [dashd] Error 1
./leveldb/libleveldb.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
make[2]: *** [dashd] Error 1
Anyone got a work around?
August 16, 2015, 09:02:32 PM
Working on it now....
[started over]
All MN upgraded fine.
All OK for me boss!
Edit 17.5% now, come on guys... Enforcement is coming
August 16, 2015, 08:58:32 PM
Wow, 4 MN buy, someone hungry.
And only 4000 shoot the price up.
And only 4000 shoot the price up.
August 16, 2015, 08:28:36 PM
Build from source choking @ :-
Code:
/usr/bin/ld: ./leveldb/libleveldb.a(db_impl.o): relocation R_X86_64_32S against `_ZTVN7leveldb2DBE' can not be used when making a shared object; recompile with -fPIC
./leveldb/libleveldb.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
make[2]: *** [dashd] Error 1
./leveldb/libleveldb.a: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
make[2]: *** [dashd] Error 1
August 16, 2015, 08:27:02 PM
August 16, 2015, 08:17:26 PM
August 16, 2015, 07:44:47 PM
********** v12.0.45 : New Version *************
Our bamboo issues last night were resolved and 12.0.45 is now available. 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/
Our bamboo issues last night were resolved and 12.0.45 is now available. 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/
August 16, 2015, 07:36:40 PM
********** 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/
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/
Still says:
./dash-cli getinfo
{
"version" : 120044,
"protocolversion" : 70103,
yep, we are discussing it at dashtalk too .. both windows versions (32bit and 64bit) have correct download version description 0.12.0.45 and winrar version 0.12.0.45 files but turn out to be v0.12.0.44-61223ed
Linux versions also turn out to be v0.12.0.44, as does OSX
Best to hold off with the downloads (any downloads) untill further announcements.
FWIW, 61223ed is a commit from yesterday:
https://github.com/dashpay/dash/commit/61223ed1476f9c67b8171ed41ee7106ac2013d21
Definitely from before the commit marked v0.12.0.45
It's really strange, bamboo says it compiled v45 correctly, but the file inside does say 12.0.44. Hold off while we figure out what's going on with bamboo
Any update on this? Are we still holding off on updating?
That was resolved by Flare last night you are good to go, please everyone update is actually working great
v12.0.45
https://dashtalk.org/threads/v12-release.5888/page-12#post-63603
"I have updated the binaries on the main download website (https://www.dashpay.io/downloads/) to v0.12.0.45-b2b2cef now.
Sorry for the inconvenience caused by the wrong downloads."
Holger
https://www.dashpay.io/downloads/
https://dashtalk.org/threads/v12-release.5888/page-12#post-63603
"I have updated the binaries on the main download website (https://www.dashpay.io/downloads/) to v0.12.0.45-b2b2cef now.
Sorry for the inconvenience caused by the wrong downloads."
Holger
https://www.dashpay.io/downloads/
Thanks! I know many people probably just check the "last posts" of Evan to get updates...maybe somebody could ping him?
August 16, 2015, 07:26:41 PM
things that are happening "out there" are more than relevant for us to be aware of "in here"
Unfortunately, most of bitcointalk is full of garbage technical trainspotting & p*ssng contest threads like this one that totally obscure the real implications of each alternative - i.e. does bitcoin evolve as a universal peer-to-peer transferable token, or simply as a value base for a centralised superstructure of monopolised payment systems (see Vitalik Buterin comment here).
August 16, 2015, 06:51:40 PM
********* Bitcoin - "Forks at Dawn" ***********
Sorry if this has already been cited in the thread. I just stumbled across it and thought it was major stuff.
https://medium.com/@octskyward/why-is-bitcoin-forking-d647312d22c1
The Bitcoin core developer group have reached deadlock on the blocksize debate and it looks like it's going nuclear - i.e. a showdown between 2 forks. Might be the most exciting and significant event to have happened since MT Gox or the big "China Rise" - even more so possibly.
I must say, even though I read a lot of posts from people saying they don't like Mike Hearn, every time I read his arguments they make far more sense to me than than the anti-revision lobby (those who want the blocksize left alone).
To me, it's a debate between those who see bitcoin as a permanent, independent, peer-to-peer monetary medium and those who who want to revert to a fiat-like hierarchical financial model with centralised clearing systems.
I'm also sympathetic to letting the forking mechanism decide because that is the fundamental resolver of consensus for this technology. It's going to be tested sooner or later so it might as well be sooner. It'll just be another milestone in the long, slow cryptocurrency rights-of-passage stage.
Who is going to win ?
I sincerely hope the monetarists win over the technologists. There was an interesting exchange on Reddit on this a couple of weeks ago.
Greg's Reply
My comment on Greg's reply (I urge folks to listen to that Adam Back interview that I cited in there - it really goes to the core of the anti alt-coin agenda.
P.S. This is a good explanation of the practical implications:
Running XT at this time is equivalent with running Core. It's the same network, and the same Bitcoins. At some point in the future, if 75% mining majority is reached (but not before January 2016), the network will split whenever a miner creates a block larger than 1MB. This will not be accepted by Core unless they adopt a large blocks patch, but will be accepted by XT, and at this point there will effectively be two chains.
Running XT means that you will always be on the largest (75%+) chain, regardless of whether the fork actually happens or not. Running Core means that you will be left behind if a 75% majority is reached. Regardless of which version you run, coins will be safe (on both chains) as long as you acquired them prior to the fork, and for some time the chains will largely mirror each other.
Running XT means that you will always be on the largest (75%+) chain, regardless of whether the fork actually happens or not. Running Core means that you will be left behind if a 75% majority is reached. Regardless of which version you run, coins will be safe (on both chains) as long as you acquired them prior to the fork, and for some time the chains will largely mirror each other.
Interesting anti-XT view: https://bitcointalksearch.org/topic/m.12155904
OK, so far I've read Mike Hearn, but must come back to finish your lesson here
Unfortunately, I don't know if your lesson will be here later, so I took a copy of it for my records. Can't trust the mods here! But you're one of the most relevant, insightful people here, and things that are happening "out there" are more than relevant for us to be aware of "in here". And you keep people like me informed and aware, so that we can see things coming in the future for DASH. Thanks Tok! August 16, 2015, 05:20:43 PM
Ha, synced in minutes, whole blockchain
Yes indeed after rebuilding the index it took ~10min more or less....nice speed!My Raspberry is taking forever to sync - ugh
??maybe 6 hours??
Jump to: