12.1 Testnet Testing Phase Two Ignition

Status
Not open for further replies.
Ahh i see. Changed the rpc port and dashd will launch, but still wont detect external IP for some reason. still wont detect the external ip for some reason. i have externalip set in both conf files..
 
gujo82 said:
Ahh i see. Changed the rpc port and dashd will launch, but still wont detect external IP for some reason. still wont detect the external ip for some reason. i have externalip set in both conf files..
Click to expand...

From the looks of it your dash.conf files are missing

Code: 
testnet=1

line. Please double check all dash.conf files (wallet + masternode) for that entry. Restart all if you have missed them.

gujo82 said:
RolandMN-TS01 13.69.252.102:19999 91sE66vU6NQtYjooTyogTD2FFFFFFFFFFFFFFsXgYqgGp424TG yTfeeHYXXXXXXXXXXXXXXXtyBxdqZ7vy8q9Zm 0
Click to expand...

The format is incorrect, instead of yTfeeHYXXXXXXXXXXXXXXXtyBxdqZ7vy8q9Zm you'll need the txid of the 1000 tDash transaction. Use

https://test.explorer.dash.org/address/yTfeeHYXXXXXXXXXXXXXXXtyBxdqZ7vy8q9Zm

to lookup the correct value.
 
I just opened up my debug console and this appeared:
Stupid me, I made a proposal and forgot I did it, LOL
Click to expand...

And I'm on the wrong chain :p Dash Core version v0.12.1.0-88ee7a3 (64-bit)

Updated
 
Last edited:
Yeah i simply altered the adresses to not post the correct ones, guess it wont matter for test, but security sticks for all things i guess :)

think i might have figured the problem, forgot to configure the masternode.conf on the MN itself, only did it on the cold-wallet qt PC..so will check that tomorrow :)

edit: fixed the masternode.conf on the MN, restarted.. but something is weird.. doing "dash-cli masternode list-conf" simply gives me 2 empty brackets.. so it doesnt seem to load the conf :/
 
Last edited:
Hello all you Testnet people!

The community appreciates your participation in testnet and in part voted for the DashForce proposal to help fund it. Splawik21 reached out to a few members last week on behalf of DashForce but no new members have joined the Dash nation testnet_tips slack channel since then. So far just a handful of people have received testnet tips including tantestefana, ec1warc1, bertlebbert, gustafx and I just sent a tip to flare and udjinm6.
A little birdy told me there is also a bigger testnet proposal in the works to help in whatever ways are needed. But for now the community has tasked DashForce with showing their appreciation for your dedication and all the hard work that goes into testnet.

I know everyone in here is here because of their passion for the project but please allow the community to show y'all some love too.:)

If you don't want to join slack then please just post a Dash address in your sig or send me a PM. Thanks

Dash Nation slack invite
http://dash-nation-invite.herokuapp.com/
 
Hello everyone!

The 12.1 build rate seems to be slowing down a bit, which is great for the prospects of a next stable release. As I have been doing for quite some time now, I continue to build for both the unstable (testnet) Dash Core and maintain the stable release for the Red Hat family of operating systems. And as I do periodically, here's a reminder where you can get your hot fresh packages. These packages (and repositories) are the easiest distribution of Dash Core to install, update, and maintain -- latest test net: build 750 or v0.12.1.0-g1c6c0d8

If you have already configured your linux system to point at my repositories, open up your Software Management Application and click "Update"
...or just type this on the commandline: sudo dnf upgrade -y

If you have not, or are simply curious, read on...

Dash Core on Fedora Linux, CentOS, and RHEL

Discussion: Dash Core for Fedora, CentOS, and RHEL
https://gist.github.com/taw00/b2382aaabb321b0cf9ce104185e1b3b7

Instruction: v12.1 Testnet Masternode setup
https://gist.github.com/taw00/e978f862ee1ad66722e16bcc8cf18ca5

Dash Core source packages, for Fedora, CentOS, and RHEL:
https://github.com/taw00/dashcore-srpms

yum/dnf repository head: https://toddwarner.keybase.pub/repo/dashcore/

If you know your way around yum or dnf, then you probably could get started with just this bit of knowledge…
curl https://gist.github.com/taw00/4b66dcf87d7883c120544680195ba24e/raw -o dashcore-fedora.repo
curl https://gist.github.com/taw00/0c755c153cbc43a3e1e2b5b4b671e44f/raw -o dashcore-centos.repo
 
Last edited:
please keep this thread to tech - testing ONLY
we let the above pass but please stick to the plan - TESTING :rolleyes:
 
qwizzie said:
Mixing seems to be working again fast and furocious with latest build version v0.12.1.0-8c16880
and with multi-session enabled.

Note : i do come across a difference in enabled number of masternodes between my wallets (some show 5, some show 58), but it does not seem to effect the mixing
Update : the "enabled number of masternodes 58" also seems to be dropping over time, i guess the network is still busy with sorting that out.

QEvA67i.png
Click to expand...

I can confirm, latest build works like charm, mixed 1000tDash in ~60mins

upload_2016-12-22_12-53-45.png
 
Yep mixing is going fast!!!!
8 rounds and 1000 coins all lasted 1h 59 min
In the end 1100 coins were mixed.
 

Attachments

seems like i have gotten 1/2 MNs running with sentinel, thx alot to @flare for troubleshooting :)

Iam curious if there is any "to-do list" of testcases etc to run? iam no developer by any means, but im quite tech-savvy :)
 
gujo82 said:
seems like i have gotten 1/2 MNs running with sentinel, thx alot to @flare for troubleshooting :)

Iam curious if there is any "to-do list" of testcases etc to run? iam no developer by any means, but im quite tech-savvy :)
Click to expand...

Yep :)

Code: 
$ dash-cli masternode list full 13.69.252.102
{
  "ff26fdc7b0097b54e8198fe3c570d210ec4391db88bc5124667d36812e3420c7-1": "        ENABLED 70204 yTfeeHYc2ct8QDmPAD1tyBxdqZ7vy8q9Zm 1482434051    39438 1482428253 123532 13.69.252.102:19999"
}
 
Dedicated tMN updated to v0.12.1.0-c438e74 and synced nmarley sentinel. Did a few mixing tests with speedy results. Now running a liquidity provider which also appears to be functioning properly.

Is there any specific area that core devs feel we should be focusing on testing right now?
 
Dash Core version v0.12.1.0-1c6c0d8 (64-bit) windows and linux versions running very well. Checking to see if there is a new version. I didn't watch to see how long it took, but mixing finished up pretty quickly for me.

Ugh, yes, there is a new version :p I'll update now :D Xmas to New Years will be very busy for me, I hope I can keep up with testing :/ Sorry if I drop out :(
 
Hi developers, please read :) :

I am attempting to run a testnet p2pool instance

because I am already running one on the only machine I currently have to work with, I thought there would be no problem since 12.1 runs in .dashcore instead of .dash.

Except that when I set up .dashcore/dash.conf for testnet, and ran dash-qt from my folder, it tried to connect to mainnet (which was running/open) and .dash folder - and failed. (latest build 64 bit linux)

I then ran dashd instead and had no problems.

I'm guessing nobody has noticed because everyone uses dashd??
 
I'm on the latest wallet, trying to send my android wallet (testnet) 880 tDash via private send. It tells me it's unable to locate enough mixed funds. My mixed balance is 2340+

Why is this happening? Cant I send up to 1000 coins privately?

OK, I was able to send 500 coins privately. maybe this is a new limit? Is that so? If so, is this a compliance issue? Trying to stay under $10,000?
 
I see a problem with our system. If someone (assume a merchant) requests instant send, the other user can still choose not to send fund via instant send by unclicking that box. Because funds are then in limbo, the customer won't resend, and the merchant is stuck with waiting for the funds, completely ruining the point of instant send.

So the merchant either has to detain the customer or make them come back to pick up their merchandise, or else he's stuck with the same problem as Bitcoin has, to risk the customer leaving with the goods while he waits for a confirmation.

We need a way, so that when the merchant, or the receiver requests a payment with instant send, the payer can not change that to non-instant. Is that possible? It has to be part of the system, not just the wallets. Otherwise, a wallet that allows you to uncheck the instant pay box will simply be made. There needs to be something that blocks acceptance of non-instant sends.
 
TanteStefana said:
I see a problem with our system. If someone (assume a merchant) requests instant send, the other user can still choose not to send fund via instant send by unclicking that box. Because funds are then in limbo, the customer won't resend, and the merchant is stuck with waiting for the funds, completely ruining the point of instant send.
Click to expand...
This is why I brought it up... IX was designed from a snowflake perspective; me me me me me. So much "me" that it doesn't even realize that it does not actually deliver on it's premise.

TanteStefana said:
So the merchant either has to detain the customer or make them come back to pick up their merchandise, or else he's stuck with the same problem as Bitcoin has, to risk the customer leaving with the goods while he waits for a confirmation.

We need a way, so that when the merchant, or the receiver requests a payment with instant send, the payer can not change that to non-instant. Is that possible? It has to be part of the system, not just the wallets. Otherwise, a wallet that allows you to uncheck the instant pay box will simply be made. There needs to be something that blocks acceptance of non-instant sends.
Click to expand...
We're not supposed to be testing the fundamentals, I guess....

This is a defect that was exposed in the IX model by the DASH vending machine a year ago. What was done about it? Changed the name to something even less sensible, altered the failed dynamic not at all... This is why I don't call it IS/InstantSend. Bitcoin has InstantSend... Hell, all cryptos have InstantSend... Locks are supposed to be about Instant RECEIVE. IX, InstanTX, at least makes half sense...

The whole point of Transaction Locks is that the RECEIVER can be assured. Thus, it has to be initiated from the RECEIVER side.

The clueless snowflake mentality is painfully obvious in that all that is talked about is how the end user can spend, with no concern for how the vendor would receive.

If a TX lock is initiated by the recipient as soon as the owning client detects it's own address in the memory pool, we not only have a way of making this more real-world workable (eliminate the derps, the deliberate un-ckechers, and the black-hat modified clients), we can also detect and mark known bad actors who attempt to defraud TXes; there should be only one lock request presented to the network for any TX, ever! The submitting client should be able to present an appropriate signature based on the keypair. Anything else submitted can be flagged as a bad actor, and if any available deterministic string exists for that address (or just that address if not, which trivializes the potential repercussions), there could be consequences for the user without exposing his identity. Anyone attempting to submit multiple sends with one of his own addresses as the receiving address, which then makes the lock request, gives us positive feedback that the TX in question definitely won't reach the appropriate recipient... It works out perfectly. Closed-loop. It's a thing. A measurable response, not a blind hope. 3rd party observers submitting Lock requests just to spam it up or create false positives on the fraud check? They won't have a valid keysig, so throw it out. Nip it in the bud to save pipe... We've reduced bad actors to nothing but an increasingly futile attempt to waste bandwidth.

Has any thought even been given to this? Just how totally unconcerned is DASH with the recipient actually getting his money? IX is a gimmick in it's current implementation. How is it being changed? Is it being changed? Does anyone give a damn?

It looks like the network currently locks an input until it's one block deep. In case of chain wag, I think this should be deeper.

InstantReceive, not instant re-receive. This gives assurance that no TX can come from nowhere, like chainless instant re-send techs. The money has to be "seasoned" by the ledger before it can be IXed. Kinda like trying to buy a $0.5mil house with cash...
 
Last edited:
camosoul said:
This is a defect that was exposed in the IX model by the DASH vending machine a year ago. What was done about it? Changed the name to something even less sensible, altered the failed dynamic not at all... This is why I don't call it IS/InstantSend. Bitcoin has InstantSend... Hell, all cryptos have InstantSend... Locks are supposed to be about Instant RECEIVE. IX, InstanTX, at least makes half sense...

The whole point of Transaction Locks is that the RECEIVER can be assured. Thus, it has to be initiated from the RECEIVER side.
Click to expand...

Yes, that's why it has to be somehow un-trickable and part of the network. Maybe they can't do this yet, but will be able to in Evolution with contracts? It would be nice to get clarification on this??? @afreer ? Or is that you, @AndyDark ?

And I like your point about the name. :D
 
Status
Not open for further replies.
Back
Top