V12 Release

UdjinM6 said:
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
Click to expand...
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.
 
Solarminer said:
Is there anything we can put something in the config to disable connecting to old peers?
Click to expand...
Nope, proto is the same.
Solarminer said:
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)
Click to expand...
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)
Solarminer said:
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.
Click to expand...
I don't think it's a good idea to keep bugging user with popups :rolleyes:
Geert said:
I have been wondering about this. What is Dash plan for mitigating this kind of attack?
Click to expand...
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.
 
UdjinM6 said:
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.
Click to expand...
https://bitcoin.org/en/alert/2015-10-12-upnp-vulnerability
 
UdjinM6 said:
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.
Click to expand...
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.
 
Solarminer said:
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.
Click to expand...
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?
 
moli said:
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?
Click to expand...
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:
 
UdjinM6 said:
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:
Click to expand...
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 :)
 
UdjinM6 said:
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:).
Click to expand...
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?
 
Solarminer said:
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.
Click to expand...
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.
 
Solarminer said:
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.
Click to expand...

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.
 
You must log in or register to reply here.
Back
Top