< jtimon>
btw sorry wumpus I published #7565 with a TODO description and the wrong code in it :(
< jtimon>
I force pushed now after adding a description
< jtimon>
nevermind the checks failed
< morcos>
Just want to throw a few random thoughts out there. I don't see anything to worry about, but just in case someone else wants to think about this too.
< morcos>
In working on the fee filter stuff, I've been paying a bit closer attention to how limited mempools as in 0.12 work and in particular interact with each other
< morcos>
There are a couple of slightly odd effects
< morcos>
For one, the expiration period of 72 hours causes some weird frequency effects.. For instance your node from when you start it takes some time to get full the first time, but this is less than 72 hours... then it stays pretty much rate limited most of the time...
< morcos>
until the first 72 hour mark is hit, then it kind of quickly starts draining and approx 12 hours or whatever number of half lives later, the node isn't limited anymore
< morcos>
its not clear to me exactly how in sync this behavior will be between different nodes...
< morcos>
but it causes kind of bursts of traffic (or at least it sometimes can)
< morcos>
I'm finding it a bit hard to imagine some kind of disaster situation where there is some resonant frequency of the network, but i do think its possible the 72 hour expiration
< morcos>
is doing more harm than good right now. (given what gets expired is junk that just gets reaccepted some point later)
< morcos>
combining this with built in rebroadcast of txs... its not super pretty
< morcos>
anyway, if you read the above and say "so...", i think i agree with you, but just wanted to share in case someone thought something more than that.
< warren>
morcos: are you pointing particularly to the bursty resonance as a potential issue? The way this was dealt with in other widely deployed open source apps was to add a degree of randomness in expiration or periodicity.
< cfields>
gitian builders: sigs pushed. apologies for the long delay
< cfields>
off to bed now, will check in tomorrow after ~12hrs of sleep :)
< btcdrak>
cfields: needs code signed :-P
< cfields>
btcdrak: hmm?
< btcdrak>
cfields: oh I am blind >.<
< jonasschnelli>
BlueMatt: which commit was not signed?
< jonasschnelli>
You use something like: bitcoind -zmqpubhashtx=tcp://127.0.0.1:28332
< jonasschnelli>
and you can listen (with another application) on tcp://127.0.0.1:28332
< fanquake>
wumpus PR'd my signed sigs
< wumpus>
thanks, merged
< JackH>
ahh now I get how its put together, thanks jonasschnelli
< JackH>
order is back into my world
< jtimon>
JackH: the zmq req/resp pattern has not been implemented as an alternative to the RPC interface if you were wondering that
< jtimon>
ok, never mind then
< JackH>
gotcha
< JackH>
yeah this was the confusing point
< JackH>
if it was alternate to RPC or not
< jonasschnelli>
It's not an alternative for RPC.
< jonasschnelli>
at the moment, it's more a "push-channel" for new blocks/transactions
< jtimon>
I mean, we could do that too now that the zmq optional dependency is there, but nobody has coded it yet
< jonasschnelli>
Alternative for the -blocknotify
< jonasschnelli>
The ugly thing with RPC is, you can get informed when a new block arrives without endless pulling.
< jonasschnelli>
Another solution would be long-poll
< jonasschnelli>
(over RPC)
< jtimon>
I just meant a zmq equivalent of the whole RPC API (using zmq's req/resp pattern), I'm not sure we're still talking about the same thing
< jonasschnelli>
jtimon: Yes. This would work... but where would be the benefits?
< jtimon>
maybe interacting with the zmq API is more convenient to some than interacting with the RPC? (ie like the "rest" API may be more convenient than the RPC?). To be clear, I'm not sure it's worth doing, just saying that it could be done
< wumpus>
no, that would be overkill, we already have RPC and rest, no need to add another way to query. zmq is meant for notification only
< wumpus>
(zmq in bitcoin core, I mean)
< jtimon>
yeah, probably not worth it, but I thought that may be what JackH was looking for, that's all
< jtimon>
s/looking for/ expecting about zmq in bitcoin core
< JackH>
I was just looking to understand how it fit
< wumpus>
and I don't think anything can beat rest with regard to ease of API usage
< wumpus>
jtimon: yes, agreed, it would be possible (I think there's even a pull around somewhere, one of the first zmq pulls, that enabled command submission through it)
< JackH>
this release will produce about 120 conspiracy posts on reddit
< michagogo>
Fanquake: you messed up your windows sig
< gamersg>
regarding the reduced disk usage for wallets in 0.12, will this automatically reduce file size of older wallets created in prior versions?
< wumpus>
no, nothing will happen automatically
< wumpus>
it doesn't matter whether it is an old or new wallet though, the instructions for enabling pruning are the same
< gamersg>
wumpus: im not talking about blockchain
< gamersg>
wumpus: the wallet.dat file
< wumpus>
you mean removing the merkle proofs? I don't know, may require database compaction or such for it actually to reduce the size of the dat
< gamersg>
oh looks like the release notes were talking about pruning
< JackH>
cool gui on 0.12
< gamersg>
im quite sure i read somewhere that txn proofs were being stored in the .dat file which are unnecessary now
< PRab>
How did we get so many gitian signed builds of 0.12.0 so quickly?
< btcdrak>
haha, everyone was itching for the release.
< PRab>
The detached sigs were posted at 2am (eastern) and now just 5 hours later there are enough merged to release.
< PRab>
I love that we were able to release so quickly, but the timing is almost unnaturally tight.
< btcdrak>
PRab: *shrug*, all the QA and deterministic processes were fulfilled.
< wumpus>
in constrast to the build, attaching signatures goes really fast, ~10 min at most for both Win+OSX
< wumpus>
(and most of that is VM setup and teardown)
< PRab>
agreed. I wonder where most of the gitian builders are. In the USA, that was all during the middle of the night. For people elsewhere, it makes perfect sense.
< wumpus>
yea, lots of devs from Europe
< btcdrak>
wumpus: so where is the party? we need a holiday now
< PRab>
Either way, cool that it is officially released!!
< PRab>
Keep up the good work.
< slackircbridge>
<mrhodl> Tor is on by default now, right?
< PRab>
laudam, theymos, and achow101 probably should add their gpg key to /contrib/gitian-downloader
< zooko>
How was the bitcoin-dev mailing list GNU Mailman configured to hold all postings for moderation?
< zooko>
I'd like to try the same thing on zcash-dev.
< instagibbs>
^^^ kanzure
< kanzure>
instagibbs: thank you
< kanzure>
zooko: it's manual, sadly. the mailing list that moderated emails are sent to is configured to only allow email from bitcoin-dev-owner@lists.linuxfoundation.org, that's the only configuration detail. when rejecting email, the moderator has to type bitcoin-dev-moderation@lists.ozlabs.org into the bitcoin-dev moderation queue interface.
< kanzure>
zooko: (and also check a box to forward the rejected email)
< kanzure>
instagibbs: slack notifications for bitcoin irc mentions is pretty cool, it works.
< kanzure>
cc btcdrak
< btcdrak>
kanzure: so it's setup as one way because I am worried about moderation difficulties: if someone spams the Slack channel, IRC moderators can only ban the bot, which would then cut the feed.