1 2016-01-24 00:04:41 <kadoban> Anyone have/know of any bitcoin script ASM -> hex/bytes test data, and maybe  hex/bytes (of a script) -> valid or invalid test data?
 2 2016-01-24 00:21:47 <Chris_Stewart_5> kadoban: Here is some script that should be valid https://github.com/bitcoin/bitcoin/blob/master/src/test/data/script_valid.json
 3 2016-01-24 00:22:06 <Chris_Stewart_5> kadoban: scripts that should be invalid: https://github.com/bitcoin/bitcoin/blob/master/src/test/data/script_invalid.json
 4 2016-01-24 00:29:17 <kadoban> Chris_Stewart_5: Right, thanks. I have those, but I need something extra for … test data of scripts in hex/bytes format.
 5 2016-01-24 00:29:49 <NicolasDorier> kadoban for what it can help : https://blockchainprogramming.azurewebsites.net/checktx
 6 2016-01-24 00:30:15 <NicolasDorier> but you need transactions from segnet
 7 2016-01-24 00:30:51 <NicolasDorier> I think I will collect some tx that are in the segnet blockchain and link the example on the website.
 8 2016-01-24 00:31:20 <kadoban> Hmm, I still need to look up what segnet/segwit is. I haven't been up on that yet.
 9 2016-01-24 00:33:56 <kadoban> *sigh* life intrudes, gotta go. Thanks for the help, I'll ask again later if that doesn't cover it.
10 2016-01-24 02:36:06 <ebfull> what is the most common `vin` arity for a bitcoin transaction in practice? is there a tool equipt to calculate that easily via the blockchain?
11 2016-01-24 02:56:01 <alpalp> arity?
12 2016-01-24 03:11:27 <kefkius> I think he meants how many inputs are in the average tx
13 2016-01-24 03:15:09 <kefkius> Given that the number of txs that spend very small amounts are larger than the number of txs that spend very large amounts, I would guess that it's a very low number like 1 or 2
14 2016-01-24 03:17:02 <kefkius> Especially since every input spends only one output, but one output can be the result of many inputs
15 2016-01-24 03:17:34 <alpalp> its probably almost always 1-2, with the occasional gigantic ones
16 2016-01-24 03:17:54 <kefkius> (So txs that gather many tiny inputs are less common)
17 2016-01-24 03:24:14 <ebfull> of particular interest to me is if it is more common for a transaction to have one input or two inputs
18 2016-01-24 04:55:33 <kefkius> ebfull: Since headers-first means that blocks may not be stored sequentially on disk, I wrote this script to count the number of inputs in txs for START_BLOCK through END_BLOCK - http://pastebin.com/Qhh8DBL2
19 2016-01-24 04:55:47 <kefkius> Using blockchain.info
20 2016-01-24 04:56:42 <kefkius> Running it without changing START_BLCOK or END_BLOCK, it tells me that every tx in blocks 100-105 had 1 input
21 2016-01-24 04:57:15 <kefkius> So, it's up to you if you want to run it for move relevant block ranges ;)
22 2016-01-24 05:05:58 <kefkius> Then again, coinbase inputs all have 1 input, so that would skew the results. This one is better: http://pastebin.com/BcfbsGw6
23 2016-01-24 05:06:08 <kefkius> coinbase txs*
24 2016-01-24 06:10:48 <ebfull> kefkius: awesome!
25 2016-01-24 06:16:57 <xintox> how come wheezy is no longer supported on the ppa?
26 2016-01-24 06:16:58 <xintox> http://ppa.launchpad.net/bitcoin/bitcoin/ubuntu
27 2016-01-24 06:17:06 <xintox> wheezy gives 404 now
28 2016-01-24 06:39:40 <netg> cmake glibc dependencies?
29 2016-01-24 15:16:48 <jonasschnelli> Does anybody knows why this transaction does not confirm? https://blockexplorer.com/tx/b78abd83918516dbc4960a053b6efe3cc2535f506ac9156554e96ba9aee916f6
30 2016-01-24 15:17:02 <jonasschnelli> Feerate: 0.00029625239005736135
31 2016-01-24 15:17:11 <jonasschnelli> inputs have >1000 confs.
32 2016-01-24 15:18:06 <jonasschnelli> estimatefee 10 -> 0.00018782
33 2016-01-24 15:18:07 <belcher> jonasschnelli high S value ? according to bc.i
34 2016-01-24 15:18:19 <jonasschnelli> hmm....
35 2016-01-24 15:18:34 <jonasschnelli> belcher: thanks.
36 2016-01-24 15:24:01 <jonasschnelli> belcher: Thanks. I was using ugly Trezor code to encode DER from compact. Thanks for your feedback.
37 2016-01-24 15:32:56 <Chris_Stewart_5> What is a high S value?
38 2016-01-24 15:36:38 <rockhouse> belcher: I would be interessted too in knowing what you mean with high S value, do you mind explaining?
39 2016-01-24 15:38:17 <belcher> an ecdsa signature is (r, s), both numbers are modulo N, if s is a valid signature then N - s will also be valid, we call the second one the high-S value, its a source of transaction malleability and a few months ago the code was patched to only accept lowS signatures
40 2016-01-24 15:38:26 <sturles> Chris_Stewart_5: rockhouse: https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki
41 2016-01-24 15:39:26 <rockhouse> thx belcher and sturles!
42 2016-01-24 15:39:30 <Chris_Stewart_5> Wow thanks belcher, sturles was BIP62 the one that was abandoned by sipa due to complexity?
43 2016-01-24 15:39:56 <belcher> it was never even finished IIRC, it was just a collection of ways to solve malleability
44 2016-01-24 15:40:07 <belcher> more of a discussion than a concrete plan, like many bips
45 2016-01-24 15:40:29 <Chris_Stewart_5> gotcha, pretty much irrelevant now to due to segwit right?
46 2016-01-24 15:40:46 <instagibbs> Chris_Stewart_5, it couldn't have provably fixed malleability even if completely implemented, form what I understand
47 2016-01-24 15:41:05 <instagibbs> yeah segwit supercedes it
48 2016-01-24 16:02:09 <Chris_Stewart_5> when reading this in documentation Hash(new commitment|witness nonce)  '|' refers to bitwise or, not logical or correct?
49 2016-01-24 16:03:47 <instagibbs> I thought it was simply concat
50 2016-01-24 16:04:15 <instagibbs> no need to do bit logic if you're already using a secure one way func
51 2016-01-24 16:04:55 <Chris_Stewart_5> Could be, I'm learning and i'm not super familiar with C documentation (if that's even what this is)
52 2016-01-24 16:05:08 <Chris_Stewart_5> C documentation style*
53 2016-01-24 16:05:27 <instagibbs> link?
54 2016-01-24 16:05:47 <Chris_Stewart_5> https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#extensible-commitment-structure
55 2016-01-24 16:09:34 <nickler> that's concat. OR would be insecure in commitment constructions because you'd trivially find collisions.
56 2016-01-24 17:27:50 <frankenmint> e development process (ignoring ad hoc communication/collaboration between individuals)?
57 2016-01-24 17:27:50 <frankenmint> I presume that not all features need to have a bip if they just plain make sense...how does that normally work for small things and iterative changes??? I've seen a few pending requests where a sort of community feedback is requested and you all either say Nack ack or utack (nay, yay, not tested yay) but beyond that, these chat rooms on irc, the mailing list, and the whole bip process...am i missing any aspects of th
58 2016-01-24 17:53:39 <Luke-Jr> frankenmint: BIPs are only for cross-software standards
59 2016-01-24 17:53:51 <Luke-Jr> eg, consensus rule changes, URIs, protocols, etc
60 2016-01-24 17:54:27 <Luke-Jr> things which affect only one particular piece of software (node policy, functionality, etc) is just reviewed by that project under their own terms
61 2016-01-24 17:54:40 <Luke-Jr> for the reference software (Core), there needs to be general agreement for a merge