< bitcoin-git>
[bitcoin] kallewoof closed pull request #10304: [rpc] Allow a txid param in getrawmempool (master...getrawmempool-include-txid) https://github.com/bitcoin/bitcoin/pull/10304
< bitcoin-git>
[bitcoin] kallewoof opened pull request #10310: [doc] Add hint about getmempoolentry to getrawmempool help. (master...doc-getrawmempool-getmempoolentry) https://github.com/bitcoin/bitcoin/pull/10310
< fanquake>
cfields Can you take a look another the zeromq changes when you get a chance. I've played around with defining D_WIN32_WINNT=0x0600, but obviously I'm not doing something quite right. Will PR other depends changes today as well.
< bitcoin-git>
bitcoin/master 7278537 Jonas Schnelli: [Qt] Don't add arguments of sensitive command to console window
< bitcoin-git>
bitcoin/master a3e756b Jonas Schnelli: Merge #10093: [Qt] Don't add arguments of sensitive command to console window...
< bitcoin-git>
[bitcoin] jonasschnelli closed pull request #10093: [Qt] Don't add arguments of sensitive command to console window (master...2017/03/qt_console) https://github.com/bitcoin/bitcoin/pull/10093
< jonasschnelli>
For the HD restore keypool topup during SyncTransaction: I can I can't block the thread in the middle of SyncTransaction. But halting after the block has been stream through SyncTransaction may results in missing funds.
< jonasschnelli>
Should the wallet really freeze the validation/net process because we can't extend the keypool?
< jonasschnelli>
What if the wallet just refuses to sync/write best block if it can't topup the keypool and wait until the wallet is unlocked, then topup and call ScanForWalletTransactions?
< wumpus>
I think only in case of pruning, when there is the risk the blocks will be lost
< jonasschnelli>
wumpus: Good point.
< jonasschnelli>
Should the BlockConnected() (it's now the main signal that calls SyncTransaction) allows to halt the validation process? Or do we need another signal into the other direction?
< jonasschnelli>
I think setting a validation flag directly from wallet is not ideal
< bitcoin-git>
bitcoin/master 2580ff8 Wladimir J. van der Laan: Merge #10314: Remove unused forward declaration for non-existent ScriptPubKeyToJSON(...)...
< gribble>
https://github.com/bitcoin/bitcoin/issues/10285 | net: refactor the connection process. moving towards async connections. by theuni · Pull Request #10285 · bitcoin/bitcoin · GitHub
< BlueMatt>
cfields: yea, #10285 is super annoying because it seems to be a step in the wrong direction by itself
< BlueMatt>
:/
< gribble>
https://github.com/bitcoin/bitcoin/issues/10285 | net: refactor the connection process. moving towards async connections. by theuni · Pull Request #10285 · bitcoin/bitcoin · GitHub
< cfields>
BlueMatt: yea, understood. I kinda expected that type of feedback :(
< cfields>
BlueMatt: the next commits make things happen in callbacks, so the flow needs to be broken up. But I'm afraid that's just too much for one PR.
< BlueMatt>
yea, i mean im not gonna nack it because i know you're going somewhere, but maybe open the next pr to get concept acks before this one gets merged?
< BlueMatt>
(which is apparently what we're all doing now)
< bitcoin-git>
[bitcoin] practicalswift opened pull request #10319: Remove unused argument from MarkBlockAsInFlight(...) (master...remove-unused-argument) https://github.com/bitcoin/bitcoin/pull/10319
< questioner2>
<questioner> ok guys. imagine its december 2017. segwit has activated. blocks are being made to segwit specification. all the major nodes are relaying and accepting to the consensus and policy of 0.13.2+.. now then. we have a legacy user making a legacy transaction. is the network and pool nodes only allowing 4k sigops (20k/5) or 16k (80k/5) for the legacy tx. can someone show me where the (20k/5) still exists as a rule
< luke-jr>
questioner2: sigops in legacy scripts count 4x toward the 80k limit
< luke-jr>
this is in validation.cpp:GetTransactionSigOpCost
< questioner2>
so a legacy tx can make 4 tx of 20k each
< questioner2>
ok after trying to read what you say. the consensus/policy is 80k/5 for tx sigops = 16k. but legacy tx has 4x of the 16k = 4k
< questioner2>
so just 20 tx of 4k legacy can use up all the blocks sigops
< sipa>
questioner2: the easiest way to see it is that from the point of view of an old wallet, nothing changed
< sipa>
20k legacy sigops were allowed before, 20k legacy sigops are allowed after
< questioner2>
is using up all 20k legacy treated as using up all 80k block sigops. or treated as legacy tx only use 25% of blocksigop limits allowing segwit transactions to still have 60x sigops spare to use in the base block
< questioner2>
60k*
< sipa>
a legacy sigop counts as 4 segwit sigops
< sipa>
so 20k legacy sigops would fill a block
< questioner2>
so 5 legacy tx of 4k sigops would fill the block not allowing segwit txdata to sit in base block
< questioner2>
4k sigops each* (=20k legacy)
< sipa>
just as 1M of non-segwit transactions would fill the whole block, not leaving space for segwit transactions
< sipa>
*1M bytes
< questioner2>
i understand data spam of 1m ;egacy in base block can stop segwit tx's as one spam attack vector. i am just looking at other attack vectors using sigops where it doesnt need 1m of data, just a certain number of sigops to hold up possible capcity utility