Interesting. Netcoin recently switched to KGW and I see this morning that the coin appears to be broken. Not sure it's related though.
Alan McIntyre
@alanmcintyre
I think I would default to keeping the current simple algorithm with increased interval. The fancier the algorithm is, the more likely it has some weird dynamical behavior you never thought to check for.
and somebody smarter will come along and do some clever variational calculus thing to find an exploit that makes small miners sad
Alan McIntyre
@alanmcintyre
Can I be a wet blanket and ask if it would be better to just make the reward fixed and then re-evaluate whether the difficulty retargeting is still insufficient? Changing two behaviors--especially if we're going to come up with a new retargeting algorithm--seems fairly risky.
But I don't know if the current feeling in the community is that both things must be changed "right now."
At any rate, if I can help by running a testnet client or two, please post a message here and I'll be glad to.
Max K.
@langerhans
Well, for the community it has to be done yesterday and we should also integrate ethereum, scrypt-n, scrypt-jane, KGW and whatnot
Alan McIntyre
@alanmcintyre
lol
"yes please just cram all these features in all at once, I'm a developer and I know nothing could go wrong"
Max K.
@langerhans
I agree though that changing two things at once is not very representative in the outcome. but random block rewards is just for the "block gambling" problem
Alan McIntyre
@alanmcintyre
yeah I definitely think random rewards should go away first
Max K.
@langerhans
The multipool jumping problem is well known. I remember the Fedora community asking for help cause a Multipool jumped off them in mid diff cycle, leaving them with 5 times or so higher blocktimes.
Alan McIntyre
@alanmcintyre
Yeah mooncoin was stuck with multi-day confirm times not too long ago because of that too
although I think our base hash rate is high enough right now that we may not suffer as much from jumping
Max K.
@langerhans
So I'd say tackling both problems in one fork is somewhat resonable. A fork is always risky. Better fuck up once than twice :D
Alan McIntyre
@alanmcintyre
Just so the retargeting change is fairly simple and not some novel algorithm that nobody has tried before
Max K.
@langerhans
Well, if we really go for 10 minute retarget... I don't know a coin (in our scale) who tried that before
Alan McIntyre
@alanmcintyre
is that the current idea?
Max K.
@langerhans
That's what's in testing currently
Results seem to be promising
Alan McIntyre
@alanmcintyre
Well at least the current PR is just changing the interval and not the algorithm, which seems fairly safe I suppose.
Max K.
@langerhans
I don't know if they are still looking at other algos...
voidref
@voidref
I wonder if there's a way to block known multis
Alan McIntyre
@alanmcintyre
you mean try to block them from participating in mining?
_
Max K.
@langerhans
we're currently testing DigiShield
Alan McIntyre
@alanmcintyre
what's that?
Max K.
@langerhans
DigiByte's super new diff retarget algo which seems to be proven multipool proof
Looking at the change dogecoin/dogecoin@d0640f9 and specifically HasAddress() in wallet.cpp being used instead of IsChange() - I'm not entirely convinced that's a good idea. Specifically it appears to lose a check about whether checking the address ownership is needed, which sounds good until you realise it locks the wallet to do that check, and the lock will inherently dominate the time taken
voidref
@voidref
rnicoll, can you tell me if my change fix the Linux build?
that article says not to do it if the commit has already been pushed, which it has in this case.
Stuart P. Bentley
@stuartpb
How would I make dogecoind's RPC API multi-tenant? Right now it seems like a lot of it is based around a single wallet / everybody has access to all the wallets