1 2016-01-04 00:14:13 <dgenr8> rusty: based on your article, do you think txes could be expired from the mempool more aggressively than every 72 hours?
 2 2016-01-04 00:15:05 <rusty> dgenr8: I think that's probably premature.  Things are likely to get worse, not better.
 3 2016-01-04 00:16:38 <dgenr8> if you mean fees going up, does that really matter?  it seems more about the chance it will ever be included, if it hasn't already after X time/blocks
 4 2016-01-04 00:23:40 <Luke-Jr> dgenr8: then it ought to be a week
 5 2016-01-04 00:29:38 <rusty> dgenr8: hmm, well, this can be done from first principles.  If you failed to get into 432 blocks (50% chance), you probably had less than a 0.2% chance of getting into any block.  With 1 week, it's 80% chance you get in a block, which is not that different.
 6 2016-01-04 00:51:59 <dgenr8> rusty: interesting approach but i don't think it works. suppose the going feerate is x, and you are offering x/10.
 7 2016-01-04 00:57:37 <dgenr8> "not on a block trajectory"
 8 2016-01-04 03:50:46 <flound1129> are new blocks written to blocks/blkXXX.dat before being broadcast?
 9 2016-01-04 08:13:25 <jl2012> is there a consensus limit for CHECKMULTISIG not to have more than 20 keys?
10 2016-01-04 08:18:54 <aj> jl2012: MAX_PUBKEYS_PER_MULTISIG is 20, and you get a hard error if that's hit yeah
11 2016-01-04 08:20:00 <jl2012> thanks, I found the code
12 2016-01-04 10:39:54 <bedeho> what is the difference between the mempool and relay set? is one subset of the other?
13 2016-01-04 10:40:03 <sipa> nope
14 2016-01-04 10:40:13 <sipa> the mempool is what we expect to be in next blocks
15 2016-01-04 10:40:20 <sipa> the relay set is what was recently relayed
16 2016-01-04 10:41:11 <bedeho> relayed to us?
17 2016-01-04 10:41:22 <sipa> yes
18 2016-01-04 10:41:50 <sipa> the relay set is needed because nodes may request recently forwarded transactions from us, even if those txn were evicted from the mempool or included in a block
19 2016-01-04 10:41:54 <bedeho> ok, so if someone relays tx which as confirmed long ago, then that would still be in relay set, but not in mempool
20 2016-01-04 10:42:17 <sipa> no, we don't accept a ln already confirmed txn for relay
21 2016-01-04 10:42:23 <sipa> it would be treated as double soend
22 2016-01-04 10:42:58 <bedeho> I see
23 2016-01-04 10:43:53 <bedeho> and if unconfirmed tx has fee 0, and we expect it to not be mined any time soon, then it would not be in mempool, but it would be in relay set?
24 2016-01-04 10:44:03 <sipa> no, in neither
25 2016-01-04 10:44:36 <sipa> the relay set is there because a txn may disappear from the mempool after we announce the tx to a peer, but before they request it from us
26 2016-01-04 10:45:21 <bedeho> I see, ok thank you sipa
27 2016-01-04 12:34:20 <m_> gavinandresen: they complain about the chief scientist title? care to change it to something, perhaps funny?
28 2016-01-04 12:34:57 <m_> like bank shill or whatever
29 2016-01-04 12:36:07 <m_> or chief improvement delayer to not sound offensive
30 2016-01-04 16:03:47 <atomos> where did gmaxwell go
31 2016-01-04 16:15:20 <maaku> he hasn
32 2016-01-04 16:15:25 <maaku> hasn't been here for a while
33 2016-01-04 19:43:37 <astj> Hello, I’m trying to do a p2sh transaction via the rawtransaction api. Anytime I attempt to provide data to the transaction via txin.scriptSig, I get “Operation not valid with the current stack size”. Scripts that don’t rely on scriptSig data seems to work fine though. Does anyone have experience doing p2sh transactions with data from a ScriptSig?
34 2016-01-04 19:44:34 <astj> This error occurs specifically when I try to sign the transaction that is attempting to spend
35 2016-01-04 19:50:35 <morcos> astj: have you tried using importaddress?
36 2016-01-04 19:50:59 <astj> no, but I can try
37 2016-01-04 19:52:20 <morcos> I think if you do importaddress {redeemscript}
38 2016-01-04 19:53:03 <astj> It seems like import address will let me just watch for transactions to that address. I’ll give it a whirl though
39 2016-01-04 19:53:07 <morcos> then if you try to sign a transaction that has a P2SH of that script as a txin, it'll find the redeemscript and populate it into the script sig for you.
40 2016-01-04 19:53:19 <morcos> and signing should work if you have the private key
41 2016-01-04 19:54:02 <morcos> uh, yeah so i haven't tried this myself
42 2016-01-04 19:54:17 <astj> ok that makes sense, I’ll try it now and report
43 2016-01-04 19:57:55 <morcos> looks like you might need to pass the 4th argument as true, and maybe consider changing the third depending on whether you want to rescan
44 2016-01-04 20:00:50 <astj> you mean 3rd argument , I think it only has 3
45 2016-01-04 20:04:19 <astj> bleh, neg. It doesn’t seem to affect the outcome. I tried importing both the hex encoded redeem script and the hashed address version of the script, no dice either way.
46 2016-01-04 20:08:07 <morcos> ok, i happened to be curious about this myself, so if i figure something out i'll let you know, maybe on #bitcoin though would be better
47 2016-01-04 20:08:08 <astj> you were right about the 4th parameter, it lists it in the code, not the online docs
48 2016-01-04 20:08:28 <astj> yeah sure, I’ll jump there tx for your help
49 2016-01-04 20:48:46 <astj> @morcos, I figured it out. It was a bug in my code. I have a script that was adding on the data I wanted to process to the ScriptSig, but I wasn’t signing the output from that, so the ScriptSig data wasn’t there to be processed :| . It seems to be working as I expect it to now.
50 2016-01-04 23:48:36 <gijensen> Would it be possible for an RPC call to dump all the TX IDs of a given blockheight or blockhash in the chainstate database efficiently? I guess what I'm wondering is, is it ordered in any way?
51 2016-01-04 23:49:48 <sipa> the database on disk is ordered
52 2016-01-04 23:50:03 <sipa> the caches are sorted by randomized hash
53 2016-01-04 23:51:42 <gijensen> sipa, I believe that'll help, thanks.
54 2016-01-04 23:53:17 <sipa> dumping is certainly possible, but not trivial without flushing the caches first
55 2016-01-04 23:53:34 <sipa> which would temporarily reduce validation performance
56 2016-01-04 23:53:46 <sipa> as the caches currently have no way to iterate their entries