V12 Testing Thread

yidakee said:
What do mean 6 confs? I just submitted another one successfully wihtout errors
Click to expand...
I had to wait until the tx from prepare hit 6 confirmations before doing mnbudget submit. the option to instantx the prepare is gone

when you do submit it returns the hash, but in the log you will see it fails.

and immediately regret this... this is going to be annoying to look at.

hug pls.
 
cwnage said:
I had to wait until the tx from prepare hit 6 confirmations before doing mnbudget submit. the option to instantx the prepare is gone

when you do submit it returns the hash, but in the log you will see it fails.

and immediately regret this... this is going to be annoying to look at.

hug pls.
Click to expand...

Holy moly! Is that the reason I constantly fail to actually submit? I get the hashes though, they just don't show in mnbudget show. Where do you see it fails, in the debug.log ?

.
 
Yea something like:
Code: 
CBudgetProposalBroadcast::IsBudgetCollateralValid - Collateral requires at least 6 confirmations - 5 confirmations
CBudgetManager::AddProposal - invalid budget proposal - Collateral requires at least 6 confirmations - 5 confirmations
 
I have a concern about impersonating in proposals. Impersonating devs/community members that have done work. Starting proposals in the name of charities. Making similarly named propals to confuse voters. No real domain verification. Kind of weird to ask for less anon on this coin. I guess as a MN it's up to you to vote responsibly?

If masternodes actually fetched the URL and it were json and contained the txid or something - that could be used as a means of authenticating the requestor. Earlier proposals I saw hinted towards this. But I see this being a pain to implement, and could DDoS sites... so... double edged sword.

I'm also a little concerned about malicious URLs being presented in the url, the crypto community being profitable target to use some 0day on (and get your coin back). Again up to MN owners to protect themselves.
 
UdjinM6 and all other testers.
Win7 x64 - v0.12.0.43-e52809a - Masternode count: 93.

Just started and timed how much wallet is consuming time to sync ALL.
It took 3 minutes and 15 seconds to clear ALL syncs.
Thats 3 mins 5 secs too much, in my opinion, comments?

Edit: Wallet was last time running about 12 hours ago.
 
AjM said:
UdjinM6 and all other testers.
Win7 x64 - v0.12.0.43-e52809a - Masternode count: 93.

Just started and timed how much wallet is consuming time to sync ALL.
It took 3 minutes and 15 seconds to clear ALL syncs.
Thats 3 mins 5 secs too much, in my opinion, comments?

Edit: Wallet was last time running about 12 hours ago.
Click to expand...
And compared to v11, it was 48 h behind and took 12 secs to fully sync.
 
AjM said:
UdjinM6 and all other testers.
Win7 x64 - v0.12.0.43-e52809a - Masternode count: 93.

Just started and timed how much wallet is consuming time to sync ALL.
It took 3 minutes and 15 seconds to clear ALL syncs.
Thats 3 mins 5 secs too much, in my opinion, comments?

Edit: Wallet was last time running about 12 hours ago.
Click to expand...
I agree. Blockchain actually syncs quite fast.
But the problem is we have no idea when masternode list sync is done so we wait while some (new) data is still coming and after a short timeout we switch to next thing to sync. And because winners and budgets depend on masternode list we can't just skip that step or do sync in parallel. Yet.
As a compromise we can remove "(out of sync)" once blockchain is synced (you can do txes right after OR even start mixing when few MNs appear in list) and leave progress bar to show the rest of the process. Thoughts?
 
UdjinM6 said:
I agree. Blockchain actually syncs quite fast.
But the problem is we have no idea when masternode list sync is done so we wait while some (new) data is still coming and after a short timeout we switch to next thing to sync. And because winners and budgets depend on masternode list we can't just skip that step or do sync in parallel. Yet.
As a compromise we can remove "(out of sync)" once blockchain is synced (you can do txes right after OR even start mixing when few MNs appear in list) and leave progress bar to show the rest of the process. Thoughts?
Click to expand...
I think all but bc sync should do in the backround, user does not need to know other syncs.

Edit: 2 typos.
 
UdjinM6 said:
I agree. Blockchain actually syncs quite fast.
But the problem is we have no idea when masternode list sync is done so we wait while some (new) data is still coming and after a short timeout we switch to next thing to sync. And because winners and budgets depend on masternode list we can't just skip that step or do sync in parallel. Yet.
As a compromise we can remove "(out of sync)" once blockchain is synced (you can do txes right after OR even start mixing when few MNs appear in list) and leave progress bar to show the rest of the process. Thoughts?
Click to expand...
Mining should be blocked until all synced.. my node forked when got new block with different payee while not completely sync .
 
moli said:
Report Memo --- Win32 v0.12.0.43-6ff903f

I don't see DS Denominate fees get confirmed unorderly anymore since Evan fixed it:
https://github.com/dashpay/dash/commit/6ff903f27b88b8fde8d45ca0c3282f3295d1bf97?diff=split

But DS is so slow to a crawl......
Click to expand...

We're going to work on speeding up DS next release. Everything else is looking great, I'm going to patch a small fix for the super rare event that caused a problem with 1 client last night then I think we're ready to launch today.
 
you're a goof :p

All good - I cleared my day so.....
Getting the 2nd Pi ready for 'work/build/compile' - in no particular order....
Whole reason I bought it was to re-build MN when the time comes
1 running
1 building
no delay - swap....

I await patiently.....
 
I have 3 wallets running since y'day,
One is only running remote MNs, no DS or IX - All good, receiving Mined fees and matches Insight @ block 83819
Other two set mixing 2000 coins, 8 rounds - Not good, many unconfirmed and conflicted tx, one stuck @ 83677, other @ 83763

Trying -reindex from wallet repair tools - syncing MNs and especially MN winners sure dose take a while.
 
bertlebbert said:
I have 3 wallets running since y'day,
One is only running remote MNs, no DS or IX - All good, receiving Mined fees and matches Insight @ block 83819
Other two set mixing 2000 coins, 8 rounds - Not good, many unconfirmed and conflicted tx, one stuck @ 83677, other @ 83763

Trying -reindex from wallet repair tools - syncing MNs and especially MN winners sure dose take a while.
Click to expand...

Does that mean you think we are not ready for mainnet? Please share your opinion.
 
bluebit said:
Change "Darksend" to "privaTX" please. Private Transaction :)
Click to expand...
Darksend already has its own dentity and trademark, i don't see the point of changing it to "privaTX" as darksend transactions aren't private, they're public on the blockchain.
 
You must log in or register to reply here.
Back
Top