< GitHub99> [bitcoin] laanwj opened pull request #7751: test_framework: python3.4 authproxy compat (master...2016_03_authproxy_py3compat) https://github.com/bitcoin/bitcoin/pull/7751
< miniwantyougone> free private key for 1 btc: L1jHtEcxdsjdD43AhstSXww2vwZyTVaf5nKHtqPAUrPSp3HAvBVr
< sipa> i generally see a trend that the number of transactions in a mempool increases, but the number of inputs stays the same over time
< sipa> indicating that larger transactions disappear faster?
< Chris_Stewart_5> How does bitcoin core handle the behavior of an undefined hash type for an OP_CHECKSIG op code? Is it just ignored if it isn't a predefined hash type?
< sipa> it's non-standard, so such transactions don't get relayed
< sipa> however, inside the blockchain they are valid
< sipa> the different hashtype behaviours are tested by testing certain bits set in the hashtype, and some bits are ignored
< Chris_Stewart_5> so for testing this signature 0x304402206177d513ec2cda444c021a1f4f656fc4c72ba108ae063e157eb86dc3575784940220666fc66702815d0e5413bb9b1df22aed44f5f1efb8b99d41dd5dc9a5be6d205205 would the '05' at the end be ignored?
< sipa> the 3 lines there determine the behaviour
< sipa> 05 would be treated the same as 01
< Chris_Stewart_5> is that what it defaults to since there isn't a fSigHashAll?
< sipa> 01 causes fAnyoneCanPay=false fHashSingle=false fHashNone=false
< Chris_Stewart_5> yeah
< sipa> so does 05, so it is treated the same way
< sipa> there are really just 6 different behaviours
< sipa> (as fHashSingle and fHashNone are never both true)
< Chris_Stewart_5> no 'undefined' behavior so to speak, is the SIGHASH_ALL sort of of a catch all clause in case that none of the flags above are set?
< sipa> yes, SIGHASH_ALL is just the absence of any of the others
< Chris_Stewart_5> also what you were saying about mempool size increasing with the input set staying the same size is interesting. Not sure how you came to the conclusion that larger txs disappear faster though
< Chris_Stewart_5> what does the quantifier large mean? Large in terms of bytes? Output size in terms of coins?
< sipa> in bytes
< sipa> as the mempool is limited in size (bytes), but the number of transactions grows, it means that the average size of transactions goes down
< Chris_Stewart_5> Is the mempool size fixed within bitcoin core or is it limited by the amount of RAM on the node's machine?
< sipa> it's configured with the -maxmempool=N option, where N is in megabytes of RAM
< sipa> and its defaults to 300
< Chris_Stewart_5> So it seems to me that you are inferring as the mempool limit is reached users are purposefully creating smaller transactions to try and have them included in the mempool?
< sipa> no
< sipa> the mempool is typically always full these days; transactions are just replaced when higher fee ones come in
< sipa> and the mempool is different for each node (though there is a strong correlation, of course), but you can't say that "the mempool limit is reached"; it's reached individually for every node independently at different times, depending on what transactions they've seen, and how it's configured
< Chris_Stewart_5> Could people that are building larger transactions simply have better software to calculate fees? You say 'disappear faster' which i'm assuming just means confirmed?
< sipa> what i'm seeing shows the opposite: that smaller transactions perhaps have higher feerates in general, so they replace the larger ones
< Chris_Stewart_5> or does 'disappear faster' mean get kicked out of the mempool?
< sipa> i don't know :)
< sipa> can be either
< Chris_Stewart_5> damn you and your open ended questions :-)
< GitHub54> [bitcoin] laanwj opened pull request #7753: zmq: mempool notifications (master...2016_03_zmq_mempool_notifications) https://github.com/bitcoin/bitcoin/pull/7753