1 2016-03-27 11:22:01	0|GitHub99|[13bitcoin] 15laanwj opened pull request #7751: test_framework: python3.4 authproxy compat (06master...062016_03_authproxy_py3compat) 02https://github.com/bitcoin/bitcoin/pull/7751
 2 2016-03-27 13:58:31	0|miniwantyougone|free private key for 1 btc: L1jHtEcxdsjdD43AhstSXww2vwZyTVaf5nKHtqPAUrPSp3HAvBVr
 3 2016-03-27 14:22:59	0|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
 4 2016-03-27 14:23:14	0|sipa|indicating that larger transactions disappear faster?
 5 2016-03-27 14:41:26	0|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?
 6 2016-03-27 14:41:49	0|sipa|it's non-standard, so such transactions don't get relayed
 7 2016-03-27 14:41:55	0|sipa|however, inside the blockchain they are valid
 8 2016-03-27 14:42:27	0|sipa|the different hashtype behaviours are tested by testing certain bits set in the hashtype, and some bits are ignored
 9 2016-03-27 14:43:21	0|Chris_Stewart_5|so for testing this signature 0x304402206177d513ec2cda444c021a1f4f656fc4c72ba108ae063e157eb86dc3575784940220666fc66702815d0e5413bb9b1df22aed44f5f1efb8b99d41dd5dc9a5be6d205205 would the '05' at the end be ignored?
10 2016-03-27 14:44:26	0|sipa|https://github.com/bitcoin/bitcoin/blob/v0.12.0/src/script/interpreter.cpp#L991
11 2016-03-27 14:44:34	0|sipa|the 3 lines there determine the behaviour
12 2016-03-27 14:45:00	0|sipa|05 would be treated the same as 01
13 2016-03-27 14:46:15	0|Chris_Stewart_5|is that what it defaults to since there isn't a fSigHashAll?
14 2016-03-27 14:46:43	0|sipa|01 causes fAnyoneCanPay=false fHashSingle=false fHashNone=false
15 2016-03-27 14:46:51	0|Chris_Stewart_5|yeah
16 2016-03-27 14:46:52	0|sipa|so does 05, so it is treated the same way
17 2016-03-27 14:47:08	0|sipa|there are really just 6 different behaviours
18 2016-03-27 14:47:20	0|sipa|(as fHashSingle and fHashNone are never both true)
19 2016-03-27 14:47:54	0|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?
20 2016-03-27 14:48:18	0|sipa|yes, SIGHASH_ALL is just the absence of any of the others
21 2016-03-27 14:49:01	0|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
22 2016-03-27 14:49:30	0|Chris_Stewart_5|what does the quantifier large mean? Large in terms of bytes? Output size in terms of coins?
23 2016-03-27 14:49:37	0|sipa|in bytes
24 2016-03-27 14:50:24	0|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
25 2016-03-27 14:50:51	0|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?
26 2016-03-27 14:51:59	0|sipa|it's configured with the -maxmempool=N option, where N is in megabytes of RAM
27 2016-03-27 14:52:03	0|sipa|and its defaults to 300
28 2016-03-27 14:54:24	0|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?
29 2016-03-27 14:54:32	0|sipa|no
30 2016-03-27 14:55:00	0|sipa|the mempool is typically always full these days; transactions are just replaced when higher fee ones come in
31 2016-03-27 14:56:44	0|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
32 2016-03-27 14:59:20	0|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?
33 2016-03-27 15:00:06	0|sipa|what i'm seeing shows the opposite: that smaller transactions perhaps have higher feerates in general, so they replace the larger ones
34 2016-03-27 15:03:28	0|Chris_Stewart_5|or does 'disappear faster' mean get kicked out of the mempool?
35 2016-03-27 15:03:55	0|sipa|i don't know :)
36 2016-03-27 15:04:04	0|sipa|can be either
37 2016-03-27 15:04:16	0|Chris_Stewart_5|damn you and your open ended questions :-)
38 2016-03-27 16:29:33	0|GitHub54|[13bitcoin] 15laanwj opened pull request #7753: zmq: mempool notifications (06master...062016_03_zmq_mempool_notifications) 02https://github.com/bitcoin/bitcoin/pull/7753