< gmaxwell>
I'm surprised no large miners are on 0.13rc yet.
< gmaxwell>
(I know none aren't because I watched dozens of blocks go by today without picking up some pretty high fee CPFP transactions)
< Lightsword>
gmaxwell, should I update to it in production?
< gmaxwell>
I think you should. As far as we know it's mature and stable. I've been mining on it since before the RCs and haven't seen any issues. Obviously normal risks of new software apply, so you might want to keep a closer eye on it than normal.
< Lightsword>
gmaxwell, are there any config differences that changes since 0.13 that I should set?
< gmaxwell>
Some changes in the how block size limits are configured, mentioned in the release notes. I'm not recalling anything else that would be applicable to you, but I'll go through the release notes right now.
< sipa>
Lightsword: actually, comments on the release notes are pretty welcome
< sipa>
it's often hard to judge what is obvious and what is confusing to someone who hasn't followed all the changes in detail
< GitHub169>
[bitcoin] sipa opened pull request #8519: [0.13] A few small improvements to the 0.13 release notes (0.13...relnotes-0.13) https://github.com/bitcoin/bitcoin/pull/8519
< GitHub58>
[bitcoin] laanwj opened pull request #8520: build: Remove check for `openssl/ec.h` (master...2016_08_remove_openssl_ech_check) https://github.com/bitcoin/bitcoin/pull/8520
< sipa>
in 0.13 the meaning of bytespersigop changed; it doesn't cause rejection of transactions that exceed the bytes/sigop ratio; it merely requires a higher fee for them
< Lightsword>
oh
< Lightsword>
so I should be able to remove that and still send higher sigops transactions now?
< sipa>
yes; they'll just be treated as if they were larger
< sipa>
say a 200 byte transaction with 20 sigops... for fee and miner selection purposes it will be treated as if it was 400 bytes large
< sipa>
(the default is -bytespersigop=20)
< sipa>
may i ask why you need to send such transactions?
< Lightsword>
some transactions with OP_RETURN’s it seemed were throwing sigops errors when I tried sending them
< Lightsword>
they weren’t transactions I created, but was asked to mine for some company
< sipa>
OP_RETURN shouldn't affect that... rather the opposite
< sipa>
they increase the size without increasing sigops
< GitHub97>
[bitcoin] laanwj closed pull request #8519: [0.13] A few small improvements to the 0.13 release notes (0.13...relnotes-0.13) https://github.com/bitcoin/bitcoin/pull/8519
< GitHub136>
bitcoin/0.13 7f84015 Pieter Wuille: Inline mempool RPCs and feefilter into misc sections
< GitHub136>
bitcoin/0.13 fe20b83 Pieter Wuille: Remove refactors from list of changes
< GitHub136>
bitcoin/0.13 2f58589 Pieter Wuille: Mention dump/import support for HD wallets
< wumpus>
it may help releasing 0.13.0, it makes sense for no one to mine (in a big operation) with an rc
< sipa>
wumpus: parse failure
< wumpus>
well I wouldn't use a rc to mine either
< wumpus>
and just wait for the release
< sipa>
well, me personally would like to see people from all parts of the ecosystem - including mingers - test the rc, to find potential problems with it
< sipa>
on the other hand, i can't really state "the rc is safe to mine with!", as that would imply it should be a release already
< sipa>
s/mingers/miners/
< wumpus>
maybe they tested on small scale
< wumpus>
"that would imply it should be a release already" maybe it should
< sipa>
a few days won't matter
< wumpus>
any reason to not tag rc3 as final right now?
< sipa>
i know of no problems
< wumpus>
it had almost no changes compared to rc2, so I don't think it needs as long testing as rc2
< sipa>
#8490 ?
< wumpus>
needs rebase
< gmaxwell>
Since, afaict, virtually no one in this space has reasonable qualification testing, if people don't mine on RCs we might as well not have them as far as mining is concerned.
< sipa>
#8518 worries me, but shouldn't affect mainnet in 0.13.0
< gmaxwell>
sipa: since there were segwit peers in his log that weren't disconnected, I don't see any reason to believe that it isn't just as it describes-- peers that were stalling the transfer.
< sipa>
ah
< sipa>
but it seems he is not making progress
< sipa>
i think it's due to having multiple potential chains on top of his current state
< MarcoFalke>
gmaxwell: the peers will come in and go after 2 seconds. I have the Debug window open and it looks like a fifo queue of peers.
< MarcoFalke>
Somewhat odd that no one reported similar problems, though.
< MarcoFalke>
Deleted peers.dat twice. On the first try it synced fine. On the second try I was back at the stalling problem.
< MarcoFalke>
Could it be that we are populating the fetch window with headers and then expect the 0.13 peer to deliver a block in 2 seconds?
< sipa>
NicolasDorier: 8295 used locks and a cachedhashesmap, no?
< NicolasDorier>
yes, my mistake
< NicolasDorier>
I checked your PR after, edited my comment
< sipa>
ah, i see
< NicolasDorier>
sipa: 8464 seems fine as well may make things easier as well for libconsensus stuff later
< NicolasDorier>
I'm fine for merging my PR, but also fine if you make a new PR and squash those two commits together, I think your implementation is simpler, more efficient and will make my life easier for libconsensus later.
< NicolasDorier>
However I don't understand why std::vector<std::unique_ptr<CachedHashes>> is needed and can't be just std::vector<CachedHashes>. The CachedHashes have the same life time as the vector
< sipa>
NicolasDorier: resizing a vector changes the addresses
< sipa>
by using an unique_ptr for each element, the cavhedhashes don't move
< sipa>
ah
< sipa>
we could just resize the vector to have block.vtx.size() entries
< NicolasDorier>
sipa: well, in this case there is a bug in my PR ? I am using a map<uint256, CachedHashes>
< NicolasDorier>
ah no
< NicolasDorier>
I'm copying stuff
< sipa>
indeed, and you do the lookup every time again
< sipa>
i do it ahead of time
< sipa>
each CScriptCheck gets a pointer to the CachedHashes it uses
< sipa>
also, adding elements to a map does not invalidate pointers
< NicolasDorier>
it does not relocate the elements as the vector ?
< sipa>
indeed
< NicolasDorier>
I slightly prefer a resize followed by std::vector<CachedHashes> instead of using a unique_ptr. Anyway, whatever you choose let me know when you do the PR. Squash my commit, I don't really care, easier to review.
< sipa>
yes, i agree; reserve + no unique_ptr is better
< NicolasDorier>
sipa: Just a reminder, you were mentionning that you were OK with a HashCacheMap because it would be useful for later. I did not really followed why (something with signature aggregation if I remember), that's just reminder.
< sipa>
NicolasDorier: yes, that's why i'm not strongly in favor of my own solution :)
< sipa>
we'll need something like this anyway
< NicolasDorier>
mmh
< sipa>
doesn't mean we can't use this now
< NicolasDorier>
well, whichever is fine for me. I still don't see far enough to see how the HashCacheMap will be useful, as how the signature aggregation will be implemented is still blurry in my mind. Both of them are fine to me, if you do a PR, will test and ACK as well.
< sipa>
not HashCachedMap itself; but some mutable data structure that individual script checks can modify
< NicolasDorier>
if so I think it is better to do it later with another class specially for that like a "TransactionContext" or something like that
< NicolasDorier>
not a big deal to code when it will be needed
< sipa>
NicolasDorier: i left you as author since you still wrote most of the code
< NicolasDorier>
as you want, but well, except the big_transaction tests nothing will be really left in reality :D
< sipa>
the tests are important :)
< sipa>
NicolasDorier: split the commit into 2
< sipa>
better now?
< NicolasDorier>
why splitting ?
< NicolasDorier>
ah you mean make a separate commit for the test only ?
< NicolasDorier>
as you want, I don't really mind
< sipa>
it seems that the only versions on the network that would relay invalid witness txn are 0.10.x
< sipa>
<=0.9 would not, due to nonstandard script
< sipa>
>=0.11 would not, due to CLEANSTACK rule
< sipa>
given that, could we just not bother with the double validation for witness txn, and special rules about not DoS scoring invalid witness txn for non-witness peers?
< GitHub50>
[bitcoin] jl2012 opened pull request #8526: Make non-minimal OP_IF/NOTIF argument non-standard for P2WSH (master...minimalif) https://github.com/bitcoin/bitcoin/pull/8526
< GitHub26>
[bitcoin] sipa opened pull request #8527: Take minRelayTxFee into account in FEEFILTER messages (master...clampfeefilter) https://github.com/bitcoin/bitcoin/pull/8527