< dgenr8> if peers are building on first-validated, miner has to balance the tx fee against the increased risk that peer will fail to finish validating his block first. this might just push up fees.
< alpalp> why would a peer fail to validate his first?
< alpalp> peer would need to validate 2 blocks instead of 1?
< dgenr8> parallel validation is being considered in some quarters
< alpalp> not sure how that applies. My fee thing was more a hypothetical. I might prefer one block at same height over another for many reasons
< dgenr8> ok, yes. PV is just one example of a non-first-seen rule
< alpalp> PV?
< luke-jr> dgenr8: why would you prefer to validate 2 competing blocks slower, vs validate one at a time?
< alpalp> if you can validate 2 in parallel faster than 2 serially, you know which to buildon
< dgenr8> luke-jr: BU is working on this to try to discourage blocks that take unusually long to validate
< luke-jr> alpalp: but it won't be faster
< luke-jr> dgenr8: it doesn't make much sense to measure actual validation time in light of compressed blocks..
< jl2012> friendsofbitcoin, luke-jr: if you want to rebase 7534 please do it after 8499 is merged. It has to disable uncompressed keys in segwit script
< luke-jr> jl2012: already did it
< luke-jr> can do it again
< sipa> jeremyrubin: does your cuckoo implementation favor h0 over h1?
< wallet42> can't join #bitcoin-dev anymore? need +r ?
< wallet42> also congrats on sipa's proposal for a BIP9 activation date. very excited. :-) i d'ont want to be a party pooper
< wallet42> but do you technically need to also define a timeout date?
< sipa> indeed.
< wallet42> or is it just 1year by default if nothing is specified?
< instagibbs> it's the suggested length in nip9
< instagibbs> bip9 even
< sipa> belcher: if you're in london, interested in meeting up?
< belcher> sure
< sipa> belcher: i'm leaving on wednesday
< belcher> pm'd
< jl2012> instagibbs: I'm not sure why it fails. It's random, like 50% chance
< Chris_Stewart_5> So I'm trying to follow the logic of broadcasting an inv message for a tx you have made from your wallet on the network, and I've made it to here in main.cpp, where it looks like the
< Chris_Stewart_5> inv message is queued up to be sent: https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L6727-L6728
< Chris_Stewart_5> however, where does the sending part actually happen?
< arubi> Chris_Stewart_5, this might be just a clue, I had the same Q a while ago and got to here: https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L4747
< Chris_Stewart_5> I think it happens here for the code I was looking at: https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L6751-L6752
< Chris_Stewart_5> which I *THINK* is responsible for serialization AND sending of the message?
< Chris_Stewart_5> EndMessage definition here: https://github.com/bitcoin/bitcoin/blob/master/src/net.cpp#L2637 which I'm unsure of what it exactly does :/
< arubi> wish I could be of more help.. p2p stuff are still black magic to me. I never went too deep into it yet
< Chris_Stewart_5> arubi: Me too, just starting to learn more about it :-). Thanks for the response though.
< arubi> np, I'll be listening for an answer too
< GitHub44> [bitcoin] btcdrak opened pull request #8932: Allow bitcoin-tx to create v2 transactions (master...bitcointx2) https://github.com/bitcoin/bitcoin/pull/8932