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

V12 Release

The only way that left for them to stuck is that some old but compatible MNs (i.e.they are on proto 70103) still send "tx" instead of "dstx" mesages for mixing and as a result such transaction cannot be identified and prioritised. This should be ok in almost every case but for some huge txes mixing 0.1 inputs this result in very low priority -> "conflicted" status.


This would require protocol bump i.e. to disable enforcing (for about a week or so) and ask whole network to update again. Does not worth it imo.


Wallet is already doing this (resending unconfirmed txes) every 5~30 minutes (time is randomized to prevent malicious nodes from determining the initial transaction source).
https://github.com/dashpay/dash/blob/master/src/wallet.cpp#L1224-L1260
Is there anything we can put something in the config to disable connecting to old peers?

For the long unconfirmed transactions during mixing, would changing the transaction fee/relay fee help? (These usually don't say conflicted, just unconfirmed. Or is this also related to tx/dstx)

Thanks. Great it is already resending unconfirmed. I suggest adding an info popup saying (transaction not confirmed, will automatically resend in 5-30min) or something.
 
Is there anything we can put something in the config to disable connecting to old peers?
Nope, proto is the same.
For the long unconfirmed transactions during mixing, would changing the transaction fee/relay fee help? (These usually don't say conflicted, just unconfirmed. Or is this also related to tx/dstx)
Nope, there is no fee for dstx (and that's a part of the problem but you can't introduce fee there to fix it because this will break anonymity)
Thanks. Great it is already resending unconfirmed. I suggest adding an info popup saying (transaction not confirmed, will automatically resend in 5-30min) or something.
I don't think it's a good idea to keep bugging user with popups :rolleyes:
I have been wondering about this. What is Dash plan for mitigating this kind of attack?
First of all... NO PANIC!!!111 :grin: I would wait for bitcoin to release patch for this problem https://github.com/bitcoin/bitcoin/pull/6769 in new 0.10 binaries.
There are also few other things we might consider to merge like upnp critical patch for example etc. I'm not following too close so might be missing something and it would be nice to review their release and grab all the things we need at once.
 
Nope, proto is the same.

Nope, there is no fee for dstx (and that's a part of the problem but you can't introduce fee there to fix it because this will break anonymity)

I don't think it's a good idea to keep bugging user with popups :rolleyes:

First of all... NO PANIC!!!111 :grin: I would wait for bitcoin to release patch for this problem https://github.com/bitcoin/bitcoin/pull/6769 in new 0.10 binaries.
There are also few other things we might consider to merge like upnp critical patch for example etc. I'm not following too close so might be missing something and it would be nice to review their release and grab all the things we need at once.
https://bitcoin.org/en/alert/2015-10-12-upnp-vulnerability
 
Nope, proto is the same.

Nope, there is no fee for dstx (and that's a part of the problem but you can't introduce fee there to fix it because this will break anonymity)

I don't think it's a good idea to keep bugging user with popups :rolleyes:

First of all... NO PANIC!!!111 :grin: I would wait for bitcoin to release patch for this problem https://github.com/bitcoin/bitcoin/pull/6769 in new 0.10 binaries.
There are also few other things we might consider to merge like upnp critical patch for example etc. I'm not following too close so might be missing something and it would be nice to review their release and grab all the things we need at once.
Thanks Ud.
I think the primary slow down with mixing is the unconfirmed transactions caused by 0 fee. This will get worse as there are more transactions. Hopefully, we can evolve out of this with Evolution.
 
Ud,
Can we start a mix before waiting for an unconfirmed transaction to confirm? I realize, if all the mixes get in the same block, that would be bad. We could limit commingling mixes to 2 or 3 sets with different denominations. That should at least double the mixing speed.
 
Ud,
Can we start a mix before waiting for an unconfirmed transaction to confirm? I realize, if all the mixes get in the same block, that would be bad. We could limit commingling mixes to 2 or 3 sets with different denominations. That should at least double the mixing speed.
In my understanding - absolutely https://github.com/dashpay/dash/pull/615
That's 12.1 feature and it require some testing but I'm mixing like this few months already and had no issues so far despite the fact that I have to be more careful about my wallet backup because standard keypool is getting obsolete very fast sometimes (this issue however can be mitigated by a huge keypool, like 10000 or smth, but I'm too lazy to make it / wait for keypool refill :tongue:).
 
UdjinM6 - if we're going to have v13 which i understand the code is rewritten pretty much, do we need v12.1 or should it be merged to v13?
 
UdjinM6 - if we're going to have v13 which i understand the code is rewritten pretty much, do we need v12.1 or should it be merged to v13?
Not sure I'm the right guy to answer this question :rolleyes:
We need eduffield to come back from Dash European Tour :wink: and discuss/agree on some some ETA or kind of approximate roadmap or smth like that I guess. If we are to test v13 somewhere soon - I doubt we need v12.1 at all then (you might noticed that there are not so much activity on github these days). Otherwise I would launch another testing because it's getting too quiet on testnet... :grin:
Personally: while guys having fun working hard in Europe I'm playing with bitcoin-0.12 merged into our master https://github.com/UdjinM6/dash/tree/mergebtcmaster for a few days now. They solved few locking issues there and we might borrow same concept and fix the rest of issues in our part etc., not to mention other huge changes and refactoring happened in 1600+ commits. Some of them are quite nice, some are quite questionable though... Anyway there are also few yet non-merged pull requests in bitcoin that I'd like to get my hands on to make them work with Dash too and that's why I started this merging actually. But don't expect anything like that soon because if that would be a base for 12.1 or 12.2 or whatever version before v13 that would require a lot more extensive testing than current 12.1 for sure. I'm just purely experimenting here. :smile:
 
Not sure I'm the right guy to answer this question :rolleyes:
We need eduffield to come back from Dash European Tour :wink: and discuss/agree on some some ETA or kind of approximate roadmap or smth like that I guess. If we are to test v13 somewhere soon - I doubt we need v12.1 at all then (you might noticed that there are not so much activity on github these days). Otherwise I would launch another testing because it's getting too quiet on testnet... :grin:
Personally: while guys having fun working hard in Europe I'm playing with bitcoin-0.12 merged into our master https://github.com/UdjinM6/dash/tree/mergebtcmaster for a few days now. They solved few locking issues there and we might borrow same concept and fix the rest of issues in our part etc., not to mention other huge changes and refactoring happened in 1600+ commits. Some of them are quite nice, some are quite questionable though... Anyway there are also few yet non-merged pull requests in bitcoin that I'd like to get my hands on to make them work with Dash too and that's why I started this merging actually. But don't expect anything like that soon because if that would be a base for 12.1 or 12.2 or whatever version before v13 that would require a lot more extensive testing than current 12.1 for sure. I'm just purely experimenting here. :smile:
Haha... Very cool, Udjin to know you've been doing all this... lol..
I've been kinda wondering what's up with btc and watching the devs discuss in their channels... they seem quite organized and orderly with their meetings and discussions and all open to the public.. quite interesting :)
 
In my understanding - absolutely https://github.com/dashpay/dash/pull/615
That's 12.1 feature and it require some testing but I'm mixing like this few months already and had no issues so far despite the fact that I have to be more careful about my wallet backup because standard keypool is getting obsolete very fast sometimes (this issue however can be mitigated by a huge keypool, like 10000 or smth, but I'm too lazy to make it / wait for keypool refill :tongue:).
Excellent.

No need to change config files. Just type keypoolrefill 10000. Takes about 5min. I am running a 100000 key wallet as a liquidity provider on mainnet.

Do you want the liquidy providers to do some testing with the new version?
 
Thanks Ud.
I think the primary slow down with mixing is the unconfirmed transactions caused by 0 fee. This will get worse as there are more transactions. Hopefully, we can evolve out of this with Evolution.
When zero fee transaction + InstantX works flawlessly without a giant blocksize, DASH is much more attractive than BTC. If you have been using a Bitcoin Core wallet with lower than recommended tx fee, you can tell that it is a pain in the butt. So, I am very looking forward to Evanution. :tongue:
 
I think there is a bug with starting up a masternode with an input with less than 25 confirmations. Previously, the wallet would nicely say you need 25 confirmations before you can start your masternode. Now the wallet just hangs and eventually says not responding. Once you have the 25 confirmations it works.
 
I think there is a bug with starting up a masternode with an input with less than 25 confirmations. Previously, the wallet would nicely say you need 25 confirmations before you can start your masternode. Now the wallet just hangs and eventually says not responding. Once you have the 25 confirmations it works.

15 confs, not 25. For about 11 months now:

https://github.com/dashpay/dash/blame/master/src/masternode.h#L16

I haven't tried starting a mn before 15, so the bug might be there.
 
I had the same issue with the wallet when starting the node, hanged even I had already +15 confirmations BUT deleting peers mnbudget mncache and payments helped.
 
Thanks. This time I think it messed up some of the files when it locked up. Removed the peers, mnbudget, etc on local and remote and she went. This error is predictable and happens with every new node for me.. - I am a little impatient at getting a new node going, so I try to start with a few confirms to see the message for how many confirmations to wait.
Splawik21, since you had the same thing happen without an 'underconfirmed' output, maybe it is related to the mncache/mnbudget files that conflict with accepting a new node.
 
Back
Top