1 2016-01-10 01:49:18 <btcdrak> Luke-Jr: "Merge the pull request when the author is ready (allowing some time for further peer review)."
  2 2016-01-10 01:49:30 <btcdrak> in BIP-0001
  3 2016-01-10 02:20:42 <lorenzoasr> i'm looking for infos about priority rules in bitcoind 0.11
  4 2016-01-10 02:20:59 <lorenzoasr> i really appreciate if someone could link some docs
  5 2016-01-10 02:22:20 <lorenzoasr> my node reply -1 to all "estimatepriority" requests, for nblocks in 0...n
  6 2016-01-10 02:46:10 <lorenzoasr> anyone alive ?
  7 2016-01-10 02:48:02 <sipa> nope, sorry
  8 2016-01-10 03:17:36 <roconnor> hi sipa.
  9 2016-01-10 03:29:27 <Luke-Jr> roconnor: !
 10 2016-01-10 03:31:35 <roconnor> hi Luke-Jr.
 11 2016-01-10 03:33:50 <Luke-Jr> ltns
 12 2016-01-10 03:34:52 <sipa> ohai
 13 2016-01-10 12:01:12 <lorenzoasr> rep
 14 2016-01-10 17:52:27 <orphanblock> is there a script available that can estimate # of additional transactions that would fit in an existing block when seg wit is deployed?
 15 2016-01-10 17:53:46 <orphanblock> I mean run something against real blocks. We could do this for each new block and have it visible on site somewhere as a reference.
 16 2016-01-10 18:16:27 <NicolasDorier> orphanblock: it depends on the adoption of segwit. If segwit is adopted at 100% and we assume 280 bytes per wit tx, then you have around 3657 transaction per block
 17 2016-01-10 18:16:50 <NicolasDorier> if it is at 0% and we assume 400 bytes per normal tx, you have around 2560.
 18 2016-01-10 18:22:27 <NicolasDorier> basically witness data is around 30% of tx size
 19 2016-01-10 18:25:03 <orphanblock> Right, so what I'm looking for is a script that would take an existing block and apply seg wit rules to it, to come up with how many more transactions (of the average type in this block) could fit into this block.
 20 2016-01-10 18:25:24 <orphanblock> So I want to apply something to real blocks.
 21 2016-01-10 18:25:41 <orphanblock> Because they are mix of p2sh etc. So we need real data.
 22 2016-01-10 18:32:40 <NicolasDorier> there is no exact formula, but for example I took 392690
 23 2016-01-10 18:32:49 <NicolasDorier> and stripped all the scriptSig data
 24 2016-01-10 18:33:07 <NicolasDorier> it make a 749059 bytes block
 25 2016-01-10 18:33:14 <NicolasDorier> to 331126
 26 2016-01-10 18:33:49 <NicolasDorier> for 1288 transaction
 27 2016-01-10 18:34:15 <orphanblock> right but then you have to add back: .25*sigdata + I think 33 bytes per output (could be wrong about that).
 28 2016-01-10 18:34:54 <NicolasDorier> the problem is that there is no exact formula, even right now you can't know exactly how much transaction can fit in a block
 29 2016-01-10 18:36:13 <NicolasDorier> from my data you can say one tx is in average 581 bytes while a segwit one is 257
 30 2016-01-10 18:36:36 <NicolasDorier> it makes 4000 tx in a block
 31 2016-01-10 18:36:47 <NicolasDorier> I think this is good estimate if 100% adoption
 32 2016-01-10 18:36:52 <orphanblock> I don't know what you mean by "exact formula". I think we know everything that is needed to calculate
 33 2016-01-10 18:37:00 <NicolasDorier> you can't calculate
 34 2016-01-10 18:37:04 <NicolasDorier> there is no formula
 35 2016-01-10 18:37:26 <NicolasDorier> even now, you don't have formula to know how much transaction in a block
 36 2016-01-10 18:37:34 <NicolasDorier> it depends on transactions people submit
 37 2016-01-10 18:37:47 <orphanblock> I want to apply a script to actual blocks.
 38 2016-01-10 18:37:55 <NicolasDorier> this is what I did
 39 2016-01-10 18:37:57 <orphanblock> Like what you did but more detailed.
 40 2016-01-10 18:38:21 <NicolasDorier> https://usercontent.irccloud-cdn.com/file/mDcoyPFY/
 41 2016-01-10 18:38:28 <orphanblock> You didn't add back the .25*sig data, and also did you strip out the sig data properly based on p2sh vs p2pkh?
 42 2016-01-10 18:38:44 <NicolasDorier> I stripped all sig data
 43 2016-01-10 18:39:16 <NicolasDorier> if segwit works is fully adopted, there is no scriptsig anymore so I stripped everything
 44 2016-01-10 18:40:41 <NicolasDorier> Here,  https://usercontent.irccloud-cdn.com/file/xDOnLhdu/
 45 2016-01-10 18:40:56 <NicolasDorier> no... one sec
 46 2016-01-10 18:41:25 <orphanblock> Ok, so maybe my understanding of the latest spec is not up to speed. currently for p2pkh outputs isn't the input (spending that) like this: <sig> <public_key>  and in Seg Wit just: <public_key>? Or does that get stripped as well?
 47 2016-01-10 18:43:01 <NicolasDorier> Here if you want a formula:
 48 2016-01-10 18:43:05 <NicolasDorier> https://usercontent.irccloud-cdn.com/file/0bizvHVs/
 49 2016-01-10 18:43:36 <NicolasDorier> no, in segwit, except if you wrap segwit into a P2SH, which will not happen once fully adopted, you have 0 bytes scriptsig
 50 2016-01-10 18:43:52 <NicolasDorier> everythign is in the witness
 51 2016-01-10 18:46:51 <NicolasDorier> so based on my data, scriptSig makes up 55% of the transaction size.
 52 2016-01-10 18:49:50 <orphanblock> Ok, thanks. So we would just have to add back .25*sigdata and then to see available space in block. I'll see what I can do with the script you posted. Assuming that QBitNinjaClient is available on web.
 53 2016-01-10 18:50:01 <NicolasDorier> well, my code is not exact in fact... if there is 100% of witnesses tx the full 1MB core size can't be filled... need better formula, will do it tomorrow :p
 54 2016-01-10 18:50:14 <NicolasDorier> yes it is, it is in C#
 55 2016-01-10 18:50:18 <NicolasDorier> use NBitcoin and QBitNinja nuget package
 56 2016-01-10 18:50:27 <NicolasDorier> you can check out https://blockchainprogramming.azurewebsites.net/
 57 2016-01-10 18:50:47 <NicolasDorier> maybe you need some base in c# though if you want to play with it.
 58 2016-01-10 18:51:59 <orphanblock> ok, thx, not a c# fan but I'll look.
 59 2016-01-10 18:53:16 <NicolasDorier> you can code on xamarin or mono develop if you are on linux, NBitcoin and QBitNinja should work fine there
 60 2016-01-10 21:37:37 <jayd3e> so I'm trying to run a little test of the protocol, by attempting to craft a ping message to a running full node(I'm using one of the nodes from the core client)
 61 2016-01-10 21:37:52 <jayd3e> I've successfully crafted the ping message I'm pretty sure, but I'm not seeing a pong pop up in wireshark
 62 2016-01-10 21:38:15 <sipa> what protocol version are you using?
 63 2016-01-10 21:38:26 <sipa> are you including a nonce after the ping?
 64 2016-01-10 21:38:27 <jayd3e> is this b/c I'm bypassing the step where the full node accepts me as a valid peer?  Or should I just be able to send a ping to any node and get back a pong
 65 2016-01-10 21:39:03 <jayd3e> sipa: I'm not specifying a version of the protocol anywhere, using this reference https://en.bitcoin.it/wiki/Protocol_documentation
 66 2016-01-10 21:39:35 <jayd3e> sipa: and yup, from what I can see the nonce is a part of the ping message overall, so I'm including a nonce IN the ping message and not "after" necessarily
 67 2016-01-10 21:40:11 <sipa> right
 68 2016-01-10 21:40:21 <sipa> are you sending the version/verack messages?
 69 2016-01-10 21:40:33 <sipa> they negotiate the protcol version used
 70 2016-01-10 21:40:46 <sipa> the default protocol you start off with doesn't have pong
 71 2016-01-10 21:41:25 <jayd3e> sipa: I'm not.  So I take it that I can't send a ping message to a full node until I've send those messages, negotiated the protocol version, which will register me as a peer on the full node
 72 2016-01-10 21:41:59 <jayd3e> sipa: oh gotcha, so before nodes would just wait for the socket to fail I'm assuming?
 73 2016-01-10 21:45:24 <sipa> jayd3e: you must negotiate a version; all messages are ignored before that point
 74 2016-01-10 21:45:38 <jayd3e> kk gotcha
 75 2016-01-10 21:48:43 <phantomcircuit> jayd3e, you cant send *anything* to a node before receiving a verack
 76 2016-01-10 21:49:48 <belcher> speaking of the protocol, how do spv wallets like multibit find their tx history ? so like given a bunch of addresses, how do you find your UTXOs and spent txes
 77 2016-01-10 21:50:03 <jayd3e> phantomcircuit: awesome, thanks, will code that into the process
 78 2016-01-10 21:50:27 <sipa> belcher: bip37, unfortunatrly
 79 2016-01-10 21:50:34 <phantomcircuit> belcher, poorly
 80 2016-01-10 21:50:45 <belcher> ah, bloom filters
 81 2016-01-10 21:50:54 <phantomcircuit> a better design was proposed in -wizards a while ago
 82 2016-01-10 21:51:03 <belcher> i read the spec, i didnt realise it could get history rather than just new incoming blocks
 83 2016-01-10 21:51:32 <phantomcircuit> you calculate a bloom filter for each block and then spv clients download the bloom filter (or series of increasingly specific bloom filters)
 84 2016-01-10 21:51:54 <phantomcircuit> belcher, getdata {something}_MERKLE_BLOCK
 85 2016-01-10 21:52:10 <phantomcircuit> belcher, it's unfortunately an extremely expensive service for nodes to provide
 86 2016-01-10 21:52:15 <belcher> and then do this for every block from genesis until now ?
 87 2016-01-10 21:52:17 <phantomcircuit> so it's going by bye
 88 2016-01-10 21:53:27 <belcher> yeah thats a bit like a full node sync'ing, except it doesnt download the entire blockchain but a subset
 89 2016-01-10 21:55:20 <phantomcircuit> belcher, yes except the amount of work required is asymetric
 90 2016-01-10 21:55:44 <phantomcircuit> the client can set a very specific filter and process very little data while the node has to process everything
 91 2016-01-10 21:56:13 <belcher> the use case im thinking of is an 'spv client' that only connects to a node you know
 92 2016-01-10 21:56:30 <belcher> for example a wallet on your tails OS that connects to your node on a raspberry pi
 93 2016-01-10 21:56:37 <phantomcircuit> belcher, the bloom filters of increasing specificity are still better though since they can be precalculated
 94 2016-01-10 21:56:50 <phantomcircuit> bip37 was a mistake
 95 2016-01-10 21:56:54 <phantomcircuit> but such is life
 96 2016-01-10 21:57:19 <belcher> that must mean multibit actually takes a long time to sync, unlike electrum which sync's straight away
 97 2016-01-10 21:57:43 <phantomcircuit> belcher, iirc multibit only runs the sync from the time of the first generated key
 98 2016-01-10 21:57:46 <phantomcircuit> so it's pretty fast
 99 2016-01-10 21:57:50 <belcher> ah
100 2016-01-10 21:58:04 <belcher> so the recovery mnemonic is the HD seed plus date
101 2016-01-10 21:58:08 <belcher> yes thats good
102 2016-01-10 21:58:09 <phantomcircuit> bbl
103 2016-01-10 22:36:31 <BlueMatt> anyone here have any interest in running the relay network? I have no interest in maintaining it anymore
104 2016-01-10 22:57:30 <PRab> BlueMatt: How much bandwidth does it end up using?
105 2016-01-10 22:57:52 <BlueMatt> nothing significant
106 2016-01-10 22:58:36 <PRab> Do people get grumpy if it has unplanned downtime?
107 2016-01-10 22:59:12 <nkuttler> BlueMatt: what kind of maintenance is necessary?
108 2016-01-10 23:00:53 <BlueMatt> PRab: if it goes to long...but mostly people dont notice if things go down
109 2016-01-10 23:01:03 <BlueMatt> nkuttler: not much...C++ development, mostly
110 2016-01-10 23:01:34 <nkuttler> oh, so the codebase and the infrastructure, i see
111 2016-01-10 23:02:27 <PRab> Oh... do you me running the relay network as in running the software, or as in maintaining/updating the codebase?
112 2016-01-10 23:02:51 <BlueMatt> both
113 2016-01-10 23:03:37 <PRab> I would be willing to run it on some very basic hardware (pine64a/raspberri pi 2) on a comcast connection, but really don't have the time/commitment to go for more than that.
114 2016-01-10 23:04:20 <PRab> Right now I do that with the tahoe-lafs test grid introducer and using get ~95% uptime.
115 2016-01-10 23:04:33 <BlueMatt> ehhhhh, its not a comcast/decentralized thing....its a very-deliberate-selection-of-vpses/centralized thing
116 2016-01-10 23:04:35 <nkuttler> i have some experience with config management, automated deployments etc, but know basically zero C. if the infrastructure is paid for i could see if i can help
117 2016-01-10 23:04:35 <PRab> /s/using/usually
118 2016-01-10 23:05:07 <PRab> Gotcha. Sorry then I think I'm out.
119 2016-01-10 23:34:40 <tachys> Is there an authoritative source anywhere for BIP 9 and its proposed implementation?
120 2016-01-10 23:36:21 <sipa> tachys: BIP9 is in the bips repository
121 2016-01-10 23:36:31 <sipa> there are two unfinished implementations
122 2016-01-10 23:38:50 <tachys> sipa: ah thanks, I was looking at an outdated bip source at https://en.bitcoin.it/wiki/Bitcoin_Improvement_Proposals