< morcos>
sipa: i have a few questions for you when you have a couple mins
< morcos>
1) secp256k1, i've been doing my benchmarking on ConnectBlock and CreateNewBlock improvements assuming that might be released and merged for 0.12. It's fine either way, but do you have a sense of status?
< morcos>
2) I'd like to create a modification to UpdateCoins so that when you are explicitly creating the outputs for a new tx you don't touch the database. Should this be a flag to ModifyCoins or a new function NewCoins.
< morcos>
the reaosn I believe this is safe is you blow away the old coins immediately afterwards anyway with FromTx, so if there were some reason those old coins existed (which they shouldn't because then you would no longer have the inputs available anyway) it would already be broken.
< wumpus>
I'm also interested in status of secp256k1 verification :)
< morcos>
but in the depths of brokenness, one difference is whether the new coins i'm creating are marked FRESH or not. since i'm just assuming they don't exist i'd like to mark my new coins as FRESH, but in the circumstance where these were then spent, then the conflicting coins would never be written over the underlying databases coins, unlike what would happen now.
< morcos>
Since this is a slight change in behavior (that should never happen) I wanted hour thoughts on that.
< morcos>
Also this question is for everyone. Thanks to Luke-Jr and gmaxwell I realized you can actually do the priority portion of the block relatively quickly in CreateNewBlock as well. But to do this I need to be able to get priority without accessing inputs. I can think of 3 options:
< morcos>
a) use current CTxMemPoolEntry::GetPriority() which is an upper bound on the possible actual priority (seems bad as it's gameable)
< morcos>
b) take the part of 6357 which calculates inchainInputValue when a mempool entry is created and use that to have a lower bound on actual priority (don't update when further inputs are confirmed) (the downside of this approach is it could be slightly broken during a reorg)
< morcos>
c) use 6357 to dynamically calculate priority. I rebased this and will push. I think its reasonably efficient, but its adding more machinary to support priority, thats also a bit complicated. Is priority here for the forseaeable future?
< morcos>
Oh and one more question sipa. Is 6914 something that you are about to change, should I also benchmark with that included, or hold off?
< morcos>
gmaxwell and sipa: re point 2 above. So correct me if I'm wrong. the existing 2 cases of duplicate coin bases are just that only duplicate coin bases. the first coinbase is now overwritten and lost, and as of yet, the second has not been spent.
< morcos>
so in order to preserve correct behavior with that, i do need to make sure I overwrite the existing coins in those 2 cases when we're processing the chain from the beginning.
< morcos>
it seems the best way to do this is to special case coinbase outputs being created (UpdateCoins already special cases coinbases). And in the case of coinbase outputs being created either still do the txdb lookup, or don't mark the new coins as FRESH to force them to be written
< morcos>
i realize this is getting a tad hacky, but it seems its well worth it to avoid all these database lookups
< morcos>
any other thoughts on how to properly accomplish this?
< helo>
second time today, sync.cpp:112: void potential_deadlock_detected(const std::pair<void*, void*>&, const LockStack&, const LockStack&): Assertion `onlyMaybeDeadlock' failed.
< helo>
at 725539e, and 8fe30fb4 (~current head)
< helo>
built/running on ubuntu 15.10 with boost 1.58 fwiw