Propulsion
The buck stops here.
- Feb 26, 2014
- 1,008
- 468
- 183
- Dash Address
- XerHCGryyfZttUc6mnuRY3FNJzU1Jm9u5L
What about services that check for only one tx? It will be harder to implement if an automated service if there are multiple transactions.Yep, that's another possible solution. Has to be implemented though![]()
What of the pools that will not update to the new version? If the enforce is not active they would still be paying the old masternode?Once released, masternodes that haven't updated will not be paid anymore, instantly. So there will be a hurry and the ones that do it first, will get all of the first payments![]()
Hmm? I'm not sure where you got this from, but it's not the case at all. The 5000DRK limit is a hard limit for the entire wallet. Lets say a user has 100k DRK, the wallet would actually end up making a bunch of 500DRK inputs and 100DRK inputs. The only reason I added the hard limit was because there's no easy way to denominate a portion of the wallet without doing the rest.The technical background of the 5000 DRK limitation is, that with current denomination scheme (0.1 ; 1 ; 10 ; 100 ; 500) the tx scripts for sending amounts > 5000 DRK get to large (20k+) and will not be relayed/mined by miners.
Possible solutions are to
a) extend the scheme by additional denomination units (e.g. 1000 & 5000)
b) switch to different scheme:
- either binary scheme as proposed by Kristov Atlas ( 1 + 2 + 4 + 8 + 16 + 32 + 64 + 128 + ...)
- or a optimized scheme as proposed by babygiraffe in https://darkcointalk.org/threads/development-updates-july-7th.1735/#post-11434
Yeah, they'd pay the old masternode network until they updated.What of the pools that will not update to the new version? If the enforce is not active they would still be paying the old masternode?
(I didn't update for 2 days, was still on .15 while network was on .16 and .17, and my tp2pool payee in block template was from my pool that wasn't updated)
When it's time to update, we'll post a very detailed explanation of what to doSo I guess what we are requesting, as masternode owners, is clear guidance about what to do and when.
I doubt you'll be sending >$30,000 to thoseWhat about services that check for only one tx? It will be harder to implement if an automated service if there are multiple transactions.
You do have a point.I doubt you'll be sending >$30,000 to those![]()
so splitting in 5k pieces before denomination is not a solution right?Hmm? I'm not sure where you got this from, but it's not the case at all. The 5000DRK limit is for a hard limit for the entire wallet. Lets say a user has 100k DRK, the wallet would actually end up making a bunch of 500DRK inputs and 100DRK inputs. The only reason I added the hard limit was because there's no easy way to denominate a portion of the wallet without doing the rest.
You'll simply start the wallet with -OverrideDarksendLimit=1so splitting in 5k pieces before denomination is not a solution right?
it was discussed on the previous page..
wouldn't it be possible that the user could determine the hard limit of the wallet?
I just interpreted the size calculation for the transaction - if i got it wrong: my badHmm? I'm not sure where you got this from, but it's not the case at all. The 5000DRK limit is a hard limit for the entire wallet. Lets say a user has 100k DRK, the wallet would actually end up making a bunch of 500DRK inputs and 100DRK inputs. The only reason I added the hard limit was because there's no easy way to denominate a portion of the wallet without doing the rest.
Well once all of the masternodes are running the new version and everyone is updated, I can release that after the fact and it will work without any change to the network.Before DS+ I was hoping Evan would create a similar wallet like the pre-DS+ wallets, which we would just check mark the Darksend box and send any amount of drk and let the network do the anonymizing. Now it doesn't work like that, and DS+ doesn't work with amounts larger than 5000. So does it mean users will need two wallets, one with DS+ and one with no DS+ to be able to do both?
Thanks, Evan. And so far the windows wallet v.17 seems to be doing well.Well once all of the masternodes are running the new version and everyone is updated, I can release that after the fact and it will work without any change to the network.
I'm not getting this Evan... So essentially there will be two MN active "forks" ? If mining pools do not get orphaned, what will their incentive to update! At best, they might even revert back to the 10% version. It was such a hard battle to get to 95% consensus, if we need to do another round without the "fear" of orphaned blocks... most will just goYeah, they'd pay the old masternode network until they updated.
They'll update or we'll kick them off the network.I'm not getting this Evan... So essentially there will be two MN active "forks" ? If mining pools do not get orphaned, what will their incentive to update! At best, they might even revert back to the 10% version. It was such a hard battle to get to 95% consensus, if we need to do another round without the "fear" of orphaned blocks... most will just go
"whhat? again? oh bugger off"
.
I'll be happy to get my hands on some instances6 EC2 instances built and ready to go. I'll keep them running for a month or two. First dev to message me gets them![]()
This is where a user friendly wallet with some kind of status / progress % would be ideal. I can picture a lot of freaked out people, Where's my money gone! lolWallet is not finished denominating, 100 DRK are at 6 rounds, 2 rounds missing.