You can test it. When there are tickets in your mempool, restart dcrd and check. Does the ticket db handle this? AFAIK, it doesn't. Thanks for the patch. I'm new to go, so I certainly won't judge or demand most idiomatic solution, although I want to learn to do things that way. Note that slices are reference types, so when s is sorted in a function, it's sorted in the caller because the underlying buffer isn't copied, even without a pointer. However, ops that rewrite header are different.
But they say slices are passed as values : https://play.golang.org/p/i4zpWK4COz more in depth https://blog.golang.org/go-slices-usage-and-internals
The header is passed by value. It contains a pointer to the buffer. The buffer is not copied. From https://blog.golang.org/slices (EDIT: Unlike simply modifying elements as done in sort...) With append, it returns a new slice header, and as the syntax suggests, it may be entirely different.
Opened @root ' s example and clicked "run". Append inside "onlyPassing" did not change the slice outside the function.
Exactly what I was trying to say in my last post. append makes a new slice header, and the function input may remain (depending on slice capacity, not length). When I said "ops that rewrite the header", this is what I'm referring to. On the other hand, simply modifying elements, as done by sort, will be seen outside the function. Please look: https://play.golang.org/p/ReBjgpd9Nw This is how sort is designed, in fact. It does not take a pointer (necessarily), just an interface, and there is no return. https://play.golang.org/p/Rc1Q2RF3ri / https://play.golang.org/p/XfFpsqQ4up Here's a more complicated example, but showing how even append may not need to create a new buffer if the the slice has enough unused capacity.. https://play.golang.org/p/K0L4vWbr9N (updated)
Testing a glimpse at the window of fees around the mineability (top 20 fees) threshold for getting mined in the next block: Code: 2016-06-20 18:14:12.65 -0700 PDT - Mempool ticket fees (38741): 0.1837, 0.0770, 0.0101, 0.0772 (l/m, mean, median, std), n=306 Mineable tickets, limit -4/+4: [0.18367 0.18367 0.18367 0.18367] --> 0.18367 (threshold) --> [0.18367 0.20202 0.20202 0.20202] Would something like this be helpful? The number 4 can be adjustable to see more or less around the limit. EDIT: It just helped me pick a perfect fee, so I guess it's good. Maybe the formatting should change though. EDIT 2: Just made a flag, and tested with a huge number. Quite interesting: Code: dcrspy.exe -m --nostakeinfo --feewinradius=99 gives: 2016-06-20 18:26:45.40 -0700 PDT - Mempool ticket fees (38743): 0.1833, 0.0544, 0.0120, 0.0655 (l/m, mean, median, std), n=338 Mineable tickets, limit -99/+19: [0.04054 0.04951 0.04956 0.04956 0.05051 0.05051 0.05068 0.06480 0.06489 0.06489 0.06497 0.06497 0.06497 0.06497 0.06505 0.07095 0.07095 0.07827 0.07827 0.07827 0.07853 0.07853 0.07901 0.07901 0.07901 0.07901 0.07901 0.07901 0.07901 0.07901 0.07928 0.07928 0.07928 0.07928 0.07928 0.07928 0.07928 0.09410 0.09410 0.09410 0.09427 0.09427 0.09427 0.09444 0.09444 0.09444 0.10714 0.10754 0.11204 0.11204 0.11204 0.11204 0.11204 0.11204 0.11204 0.11224 0.11224 0.11224 0.11224 0.11224 0.11245 0.11245 0.11245 0.15152 0.15152 0.15152 0.15152 0.15152 0.15152 0.15203 0.15203 0.15203 0.15203 0.15203 0.15203 0.16500 0.16500 0.16531 0.16531 0.16531 0.16531 0.16561 0.17172 0.17230 0.18333 0.18333 0.18333 0.18333 0.18333 0.18333 0.18333 0.18333 0.18333 0.18333 0.18333 0.18333 0.18333 0.18333 0.18333] --> 0.18333 (threshold) --> [0.18333 0.18333 0.18333 0.18333 0.18333 0.18333 0.18333 0.18333 0.18333 0.18367 0.18367 0.18367 0.18367 0.18367 0.18367 0.25510 0.25510 0.33333 0.33446] Running it with --feewinradius=999 was just as interesting. LOTS of fees at 0.01010.
I like this mempool ticket fees feature. Do you use a verbose getrawmempool call for this? How do you check that transaction is a ticket, vote or the regular send transaction? Code: { "0083c0f67e1daf853446b1a910f43eccaf30e0549c35afbfc264a3b070fb246b": { "size": 340, "fee": 0, "time": 1466491245, "height": 38796, "startingpriority": 3.52002950046e+10, "currentpriority": 3.5299061264433334e+10, "depends": [] }, "029439fbdb6882a42281a4a25945564571b7db7d0e7181d5642b30b3fe020a03": { "size": 297, "fee": 0.01493898, "time": 1466491904, "height": 38799, "startingpriority": -1.5753375906040268e+07, "currentpriority": 1.5753375906040268e+07, "depends": [ "f142208a631a83967966a5418e97d3b7f2dcec4be88922119e0f3bc6288df432" ] }, "072223ee3a14c01060527ad0af7a82194e8e1bcd326aa3f94201f1df45eab2e2": { "size": 253, "fee": 0.07500001, "time": 1466491244, "height": 38796, "startingpriority": 2.37139613388e+11, "currentpriority": 2.371797059715849e+11, "depends": [] } }
Yar, that be the spot for the index computation. There's some late night hackage there, so expect that part to change. For example, I don't think targetFeeWindow gets used anywhere. Checking the type of an incoming tx is done here: https://github.com/chappjc/dcrspy/blob/master/mempool.go#L104 But when it's time to get all mempool ticket fees, it's easy in code because of dcrjson.GRMTickets; https://github.com/chappjc/dcrspy/blob/master/mempool.go#L311
I do not deserve any thanks, I wanted to have the mempool monitoring and you just gave it to us. Thank you for that. It is going to be a nice feature to my GUI wallet experiment, probably some user friendly way to buy stake tickets with pool cooperation and price analysis is going to be a great addition for Decred.
@root As I mentioned in that thread, I'd be happy to contribute to the backed/controller part of the project... just for the fun of coding.
Not to derail this thread, in a week or two I'd like to share a skeleton and a list of features for discussion.
In the recently released version 0.1.2, support for email notification was added. Note however that there is a small bug in the release version that requires a small config file workaround if NOT using email notifications. Oops. Fixed in master, however.
Wow, someone is wasting a ton of DCR! Mineable tickets, limit -60/+19: [0.01111 0.01115 0.01115 0.01115 0.02837 0.20202 0.25253 0.25338 0.28131 0.28131 0.28131 0.28131 0.28131 0.28131 0.28131 0.28131 0.28131 0.28131 0.28131 0.28131 0.28131 0.28131 0.28184 0.28184 0.28184 0.28184 0.28184 0.28184 0.28184 0.28184 0.28184 0.28184 0.28184 0.28184 0.28184 0.28184 0.28184 0.28184 0.28184 0.28184 0.28184 0.28184 0.28184 0.28184 0.28184 0.28184 0.28184 0.28184 0.28184 0.28184 0.28184 0.28184 0.28184 0.28184 0.28184 0.28184 0.28184 0.28184 0.28236 0.28236] --> 0.28236 (threshold) --> [0.28236 0.28236 0.28236 0.28236 0.28236 0.28236 0.28236 0.28236 0.28236 0.28236 0.28236 0.28236 0.28236 0.28236 0.28236 0.28236 0.28236 0.28236 0.28236]
I've been neglecting this thread, but there have been many developments since 0.1.2. I made a quick edit to the announcement post, but I will rewrite it shortly with a list of features and fixes. When the getbalance changes in dcrwallet settle down, I'm going to update dcrspy, which will mark v0.8.0.