< bitcoin-git>
[bitcoin] str4d opened pull request #10408: Net: Improvements to Tor control port parser (master...torcontrol-parser-patches) https://github.com/bitcoin/bitcoin/pull/10408
< cfields>
jonasschnelli: I'll give it a detailed look in the morning (getting ready for bed atm). Looks ok at a glance, though. Though, I'm a bit confused about nBlocksInFlight being atomic.
< jonasschnelli>
cfields: Okay. Thanks... have a rest (it's not urgent). And yes, I would like to hear why you think nBlocksInFlight as an atomic may be confusing.
< cfields>
jonasschnelli: just looks like it should either be non-atomic and require the lock, or be atomic and possibly out of sync.
< jonasschnelli>
Okay... let me check that again. Thanks for pointing out.
< cfields>
jonasschnelli: (i haven't looked deeply, so no idea if it makes sense), maybe useful to trigger a gui event for mapBlocksInFlight.erase(), similar to the other recent changes like that?
< cfields>
that way you'd keep it cached at the gui and not have to query the other way?
< jonasschnelli>
cfields: But wouldn't mapBlocksInFlight.erase() not result in still downloading the blocks?
< jonasschnelli>
IMO what the GUI should know is how many blocks are still "in transit" when someone pressed "pause"...
< jonasschnelli>
because you won't stop a peer of sending you the already requestes blocks...
< jonasschnelli>
and you should accept them,...
< jonasschnelli>
*the peer should accept them
< cfields>
jonasschnelli: i just mean add a gui event for when mapBlocksInFlight is added to or removed. that way the gui gets notifications for each change, and doesn't have to try to query
< jonasschnelli>
aha... yeah. That would work.. though seems a bit an overkill to add a signal for that... but maybe not.
< cfields>
jonasschnelli: yea, that's the part i wasn't sure about. I only mentioned because it's the direction things have been going in lately.
< jonasschnelli>
Yes. That's true. Maybe its useful for other stuff as well..
< jonasschnelli>
What are the downside of the atomic approach? Calling the getter in the middle of an "update sequence"?
< cfields>
yea, possible off-by-one in some future code i guess. unlikely to be an actual issue probably, just feels a bit icky to introduce a race strictly because the non-racy path would require the slow lock :(
< cfields>
s/race/de-sync/, i suppose
< bitcoin-git>
[bitcoin] practicalswift opened pull request #10409: [tests] Add fuzz testing for BlockTransactions (BLOCKTXN) and BlockTransactionsRequest (GETBLOCKTXN) deserialization (master...fuzz-blocktransactions) https://github.com/bitcoin/bitcoin/pull/10409
< Chris_Stewart_5>
If I have a transaction that spends a raw witness spk and the input is already signed on the spending tx, and then I'm trying to call fundrawtransaction to add a fee. Is this currently unsupported in bitcoin core? Do I need to use P2SH(P2WSH)?