1 2015-09-16 06:15:19 <bedeho> does regular m-of-n and p2sh scriptSigs both start with leading OP_0?
  2 2015-09-16 08:56:06 <dcousens> bedeho: OP_CHECKMULTISIG will need a preceeding OP_0
  3 2015-09-16 08:56:17 <dcousens> whether it is a p2sh script is not relevant
  4 2015-09-16 13:52:19 <jgarzik> jonasschnelli, travis failed on #6315
  5 2015-09-16 13:53:17 <jonasschnelli> jgarzik: hmm... let me look at it.
  6 2015-09-16 13:54:02 <jonasschnelli> jgarzik: "configure.ac:2: error: Autoconf version 2.69 or higher is required"!
  7 2015-09-16 13:54:23 <jonasschnelli> https://travis-ci.org/bitcoin/bitcoin/jobs/80639010#L293
  8 2015-09-16 13:55:13 <jgarzik> hrm
  9 2015-09-16 13:55:15 <jonasschnelli> jgarzik: could that be related to the zmq merge?
 10 2015-09-16 13:55:53 <jgarzik> jonasschnelli, probably
 11 2015-09-16 13:58:54 <sipa> jgarzik: you're signing with an unknown gpg key?
 12 2015-09-16 13:58:59 <sipa> commit signs
 13 2015-09-16 13:59:41 <jgarzik> sipa, the jgarzik@pobox.com key has been used for years
 14 2015-09-16 13:59:56 <jgarzik> though with a period of jgarzik@exmulti.com inserted in there
 15 2015-09-16 14:00:54 <sipa> jgarzik: there is a script to verify that no unknown keys sign commits
 16 2015-09-16 14:01:02 <sipa> we should adapt it to include that key them
 17 2015-09-16 14:02:16 <jgarzik> Man, Debian does a good job of hiding ISOs of old versions
 18 2015-09-16 14:06:03 <jonasschnelli> hmm... the post zmq PR travis somehow requires Autoconf version 2.69 or higher,... but can't see any relation to the configure.ac changes: https://github.com/bitcoin/bitcoin/pull/6103/files#diff-67e997bcfdac55191033d57a16d1408a
 19 2015-09-16 14:06:43 <jgarzik> jonasschnelli, agree it's not immediately apparently, but it is a likely suspect
 20 2015-09-16 14:06:54 <jgarzik> I tested on three platforms too :/
 21 2015-09-16 14:07:07 <jgarzik> *immediately apparent
 22 2015-09-16 14:07:44 <jonasschnelli> 99% sure that the source is the zmq patch: https://travis-ci.org/bitcoin/bitcoin/builds
 23 2015-09-16 14:10:44 <jgarzik> jonasschnelli, the way autoconf works, use of a new macro turns on a lot of unused machinery
 24 2015-09-16 14:10:49 <jgarzik> e.g. AM_CONDITIONAL
 25 2015-09-16 14:12:13 <jonasschnelli> jgarzik: but we use AM_CONDITIONAL already at L877+ ... but the zqm one has a different syntax.
 26 2015-09-16 14:14:39 <jgarzik> jonasschnelli, it might also be something new in a *.am
 27 2015-09-16 14:15:59 <Diablo-D3> jonasschnelli: re: autoconf version 2.69 isnt that new, btw
 28 2015-09-16 14:16:27 <jonasschnelli> Diablo-D3, jgarzik: sure, we could force travis to update autoconf in "before_script"
 29 2015-09-16 14:16:41 <jonasschnelli> something like "sudo apt-get install --only-upgrade autoconf"
 30 2015-09-16 14:17:07 <jonasschnelli> but nevertheless id like the find the marco that does not work < 2.69
 31 2015-09-16 14:17:19 <moa> https://github.com/bitcoin/bitcoin/commit/ca5e2a18648cdc0f2a756e7d549f509adce25b00
 32 2015-09-16 14:17:40 <Diablo-D3> I usually have a line in my configure.ac that forces version requirements anyhow
 33 2015-09-16 14:17:46 <moa> doesn't the first line here show the change?
 34 2015-09-16 14:17:56 <jonasschnelli> moa: thanks!
 35 2015-09-16 14:18:44 <jonasschnelli> jgarzik: i think you accidental merged this in.
 36 2015-09-16 14:18:47 <jgarzik> wow.  auto-merging added that
 37 2015-09-16 14:18:59 <moa> jgarzik: yep uou gotta watch that with autotools
 38 2015-09-16 14:20:07 <jonasschnelli> moa was looking at the right stuff - the code in master - instead of the PRs (like i did).
 39 2015-09-16 14:20:15 <moa> i think I saw other obsolete warnings from those earlier commits that will show up when you roll <2.69 back to 2.60
 40 2015-09-16 14:20:31 <moa> which is why it auto updated, maybe
 41 2015-09-16 14:20:44 <dcousens> sipa: in https://github.com/bitcoin/bitcoin/pull/6403#issuecomment-140741430, did you refer to the right issue?
 42 2015-09-16 14:27:59 <sipa> dcousens: shouod be 6654
 43 2015-09-16 14:28:04 <sipa> on mobile currently
 44 2015-09-16 14:29:08 <moa> yeah ... http://pastebin.com/iGwBLJ9g < that was after 13b8282
 45 2015-09-16 14:34:34 <jonasschnelli> sipa: can ReadBlockFromDisk() get called without locking cs_main? Is CBlockIndex::nDataPos and ::nFile immutable?
 46 2015-09-16 14:35:14 <sipa> jonasschnelli: not since pruning...
 47 2015-09-16 14:35:29 <sipa> but we could institute a separate lock for file position information
 48 2015-09-16 14:36:21 <jonasschnelli> sipa: just tried to reduce the cs_main lock in ZMQ: https://github.com/bitcoin/bitcoin/pull/6103/files#r39172953
 49 2015-09-16 14:37:30 <jonasschnelli> Right. A file position lock could make sense and should be deadlock save
 50 2015-09-16 14:41:23 <jgarzik> Travis supports osx as well as linux, interesting.
 51 2015-09-16 14:42:26 <phantomcircuit> uh
 52 2015-09-16 14:42:50 <phantomcircuit> generally speaking i would say that exposing zeromq as a potentially public interface is a bad idea
 53 2015-09-16 14:43:09 <moa> another issue with that 0mq commit is the depends build for zmq is not working ...
 54 2015-09-16 14:43:33 <moa> packages_linux variaable inside packages.mk has not been passe through to depends/Makefile
 55 2015-09-16 14:43:52 <moa> neither packages_darwin ... but I didn't test that as I'm on linux
 56 2015-09-16 14:45:55 <moa> other than that it works ok
 57 2015-09-16 14:47:42 <dcousens> gmaxwell: what is CPFP?
 58 2015-09-16 14:47:51 <dcousens> I haven't caught up on everything yet :P
 59 2015-09-16 14:47:52 <sipa> child pay for parent
 60 2015-09-16 14:48:38 <jgarzik> phantomcircuit, I think 0mq should default to off-but-built-in
 61 2015-09-16 14:49:52 <sipa> agree
 62 2015-09-16 14:49:55 <dcousens> thanks sipa,  I'm guessing that means children transaction fees could pay for parent transaction fees?  in the sense that fees can be calculated in terms of transaction trees not just individuals?
 63 2015-09-16 14:50:10 <sipa> dcousens: indeed
 64 2015-09-16 14:53:02 <dcousens> gmaxwell: I'm not sure I understand your 2nd point in terms of "never have their fees paid"
 65 2015-09-16 14:54:06 <jonasschnelli> jgarzik, phantomcircuit: IIRC 0mq cannot be linkes static on windows at the moment (https://github.com/bitcoin/bitcoin/pull/6103#issuecomment-99272898)
 66 2015-09-16 14:54:22 <jonasschnelli> s/linkes/linked
 67 2015-09-16 14:54:51 <dcousens> maaku: I think you replied to me in the wrong issue,  but with the context of hte wrong issue
 68 2015-09-16 14:55:23 <dcousens> wait no,  you replied to @dakk, but wrote me instead
 69 2015-09-16 14:55:53 <dcousens> (RE: https://github.com/bitcoin/bitcoin/issues/6677#issuecomment-140762524)
 70 2015-09-16 14:55:55 <drazisil> why do version 536870919 (BIP101) blocks not get rejected as invalid? What makes it still a valid block? being under 1mb?
 71 2015-09-16 14:56:40 <jgarzik> drazisil, yes, under 1M
 72 2015-09-16 14:58:01 <drazisil> jgarzik: ok, so it doesn't care what's in the version field. I assume it still checks for a BIP34 coinbase of the height, it doesn't that matter anymore either?
 73 2015-09-16 14:58:09 <drazisil> or*
 74 2015-09-16 14:58:47 <sipa> drazisil: if higher version numbers were invalid, every version update would be a hard fork
 75 2015-09-16 15:00:21 <drazisil> sipa: right, wasn't thinking about that. so what is currently checked to make sure a block is valid? just size?
 76 2015-09-16 15:01:20 <sipa> and version
 77 2015-09-16 15:01:24 <sipa> and transactions
 78 2015-09-16 15:01:29 <sipa> and serialization
 79 2015-09-16 15:01:34 <sipa> and signatures
 80 2015-09-16 15:01:37 <sipa> and utxo inputs
 81 2015-09-16 15:01:43 <kanzure> and limits
 82 2015-09-16 15:02:36 <drazisil> thank you very much
 83 2015-09-16 15:16:56 <jgarzik> heading out for kids & lunch - ping me on IRC or file a github issue if more zmq stuff appears
 84 2015-09-16 15:17:13 <jgarzik> will take care of the rest in 1.5 hours
 85 2015-09-16 15:19:00 <drazisil> another question, if I may? where in the codebase is the coinbase generated?
 86 2015-09-16 15:23:03 <sipa> drazisil: by minerd
 87 2015-09-16 15:23:06 <sipa> by miners
 88 2015-09-16 15:24:06 <drazisil> sipa: Oh, I thought it was set by the node and not the mining software
 89 2015-09-16 15:29:41 <morcos> sipa: question about mempool locking: in ATMP we lock pool.cs while taking a copy of the view and then release it.  why would we consider it safe to release it?  in practice its protected by cs_main, so there isn't an issue, but is not 100% clear to me what pool.cs is protecting.
 90 2015-09-16 15:31:48 <morcos> I think locking needs to be added for #6654, and i'm trying to figure out where it should go
 91 2015-09-16 15:35:43 <phantomcircuit> jgarzik, that sounds reasonable, but the 0mq codebase in general makes me nervous
 92 2015-09-16 15:37:08 <morcos> I suppose the way to think about it is if you're modifying the mempool you need to hold main and mempool.cs, so that way if you're reading from it you only need check mempool.cs?  So in particular it's ok for ATMP to not hold pool.cs except when its modifying the mempool (since it holds main)
 93 2015-09-16 15:38:18 <moa> phantomcircuit: quantify your nervousness? ... like on a scale of butterflies-in-your-tummy to wet-your-pants nervous?
 94 2015-09-16 15:39:37 <phantomcircuit> moa, historically 0mq has had lots of really obvious remote crash bugs
 95 2015-09-16 15:40:16 <phantomcircuit> the code is old and mature, but it's starting point didn't even consider security
 96 2015-09-16 15:40:56 <morcos> sipa: re:mempool locking If that's the correct way of thinking about it, maybe I should comment that?  And then I'm not sure I understand why its necessary to have the pool.cs locks we do have in ATMP (until a modification is happening).
 97 2015-09-16 15:42:11 <Lightsword> so can 0mq be used as an alternative to the json-rpc interface for mining?
 98 2015-09-16 15:42:28 <moa> phantomcircuit: i see, like most of the internet
 99 2015-09-16 15:44:19 <sipa> Lightsword: no, it is publish only, and unreliable
100 2015-09-16 15:45:33 <Lightsword> sipa, so is it just an alternative to longpoll or having a blocknotify trigger script?
101 2015-09-16 15:48:48 <sipa> yes
102 2015-09-16 15:57:44 <Lightsword> is there any plan to eventually allow block templates to be sent over 0mq as well or is it not suitable for that?
103 2015-09-16 16:55:15 <maaku> dcousens: whoops, sorry
104 2015-09-16 16:57:14 <kanzure> maaku: nope i guess i was just confusing those two proposals (re: moxie/formal verification stuff)
105 2015-09-16 16:57:59 <maaku> ah ok makes sense from what you quoted
106 2015-09-16 16:58:04 <maaku> i mean they are totally related
107 2015-09-16 17:00:46 <kanzure> maaku: the boundaries are not completely clear to me; why wouldn't you insert consensus rules into an OP_MOXIE-using script?
108 2015-09-16 17:06:25 <phantomcircuit> <Lightsword> is there any plan to eventually allow block templates to be sent over 0mq as well or is it not suitable for that?
109 2015-09-16 17:07:57 <phantomcircuit> in general i think that notifications which have a payload aren't a great idea
110 2015-09-16 17:14:05 <maaku> kanzure: I'm not sure I understand? OP_MOXIE would be consensus rules, since the execution of the moxiescript would be within consensus
111 2015-09-16 17:16:53 <maaku> so yeah, OP_MOXIE is a general, theoretically complete way to extend consensus rules
112 2015-09-16 17:18:02 <maaku> although in practice mundane things like push limits prevent you from doing too much
113 2015-09-16 17:18:58 <maaku> the problem with OP_MOXIE for doing new smart contracting features though is that it is hard to write generic signers -- a signer that is able to check that the script is safe before it signs
114 2015-09-16 19:11:35 <bitcoin-dev347> Hi, everyone! Quick question... I'm aware of Shamir's Secret Sharing as an alternative to P2SH multisignature. However, it requires combining all parts on a single device to sign a transaction.
115 2015-09-16 19:12:06 <phantomcircuit> that's correct
116 2015-09-16 19:12:08 <bitcoin-dev347> Is anyone aware if it's possible to do something similar, but by combining partial signatures rather than partial keys?
117 2015-09-16 19:13:26 <bitcoin-dev347> I'm looking to design a system that would require m-of-n signatures, but with m and n much larger than P2SH permits.
118 2015-09-16 19:15:29 <phantomcircuit> bitcoin-dev347, not with ecdsa, with schnorr the signatures can be combined
119 2015-09-16 19:16:09 <sipa> bitcoin-dev347: search key tree signatures :)
120 2015-09-16 19:16:20 <bitcoin-dev347> Thanks, I was actually just linked here in a pm: https://www.youtube.com/watch?v=gcQLWeFmpYg
121 2015-09-16 19:16:24 <arubi> I just linked him to your talk sipa :)
122 2015-09-16 19:16:51 <sipa> arubi: cool :)
123 2015-09-16 21:45:16 <xeon-enouf> guys... i know you'll have excuses, but please, for the love of ${DEITY}, hook directly into the board when recording audio - don't pick up the room audio reverberating like a chicken without a head once its left the PA spkrs and has bounced around the room like tidybowl man in a toilet O_o
124 2015-09-16 22:23:10 <Diablo-D3> https://onetoday.google.com/page/refugeerelief
125 2015-09-16 23:01:44 <TrevinHofmann> sipa - I was the user asking about large m-of-n multisig earlier. I've finished your SF speech on tree signatures. It was brilliant! Do you know of any potential time frame for making the required soft fork(s) in Bitcoin?
126 2015-09-16 23:02:10 <TrevinHofmann> I'm considering ideas to improve/extend P2Pool, and tree signatures would be very useful.
127 2015-09-16 23:36:00 <bedeho> is there a good tool to get diagnostics on why a particular tx and input cannot spend a given scriptPubKey?
128 2015-09-16 23:36:33 <bedeho> with deep feedback on where the script evalution fails? e.g. if oy have forgotten leading OP_0 etc, if signature i does not work in multisig etc.
129 2015-09-16 23:53:54 <dcousens> bedeho not that I know of,  though you could just compile the interpreter with custom logging and disconnect the node? :P