1 2016-01-11 01:18:39 <Lightsword> BlueMatt, server infrastructure I might be able to run it but my c++ isn’t exactly good enough to maintain the codebase
  2 2016-01-11 02:29:28 <jayd3e> how does the client know when a message ends over the wire and another begins?
  3 2016-01-11 02:29:36 <jayd3e> my version/ping messages are getting intermixed
  4 2016-01-11 02:29:42 <sipa> messages have a length field
  5 2016-01-11 02:30:11 <jcorgan> and the next thing you should receive after the length bytes are consumed is another message header
  6 2016-01-11 02:30:31 <jayd3e> kk so I have something wrong
  7 2016-01-11 02:33:40 <dgenr8> since I've never seen it mentioned before, does anyone else see a major drawback of block-level bloom filters?
  8 2016-01-11 02:36:33 <phantomcircuit> dgenr8, can you specify what you mean exactly?
  9 2016-01-11 02:37:26 <dgenr8> the obvious.  client now sees no transaction until it is included in a block
 10 2016-01-11 02:38:06 <sipa> you can still use the bloom approach for lone transactions, as the assymetry argument doesn't apply there
 11 2016-01-11 02:38:19 <sipa> though it has the same privacy problem
 12 2016-01-11 02:47:12 <phantomcircuit> dgenr8, you just treat the entire mempool as a giant bloom filter
 13 2016-01-11 02:47:15 <phantomcircuit> tada!
 14 2016-01-11 02:47:24 <phantomcircuit> er a giant block
 15 2016-01-11 02:47:28 <phantomcircuit> *word*
 16 2016-01-11 02:49:22 <dgenr8> i perceive that you recognize the infeasibility of that idea
 17 2016-01-11 03:07:15 <jayd3e> so I've succeeded in sending a "version" message over the wire to a full node.  In wireshark, it's recognized as the "bitcoin" protocol
 18 2016-01-11 03:07:51 <jayd3e> however, I'm not getting a verack back
 19 2016-01-11 03:17:35 <jcorgan> if you can send the msg to a local bitcoin node you setup, there may be some information in that nodes debug log that would help
 20 2016-01-11 03:19:38 <jayd3e> nice
 21 2016-01-11 03:19:41 <jayd3e> will do that
 22 2016-01-11 03:33:57 <phantomcircuit> dgenr8, amusingly no that would actually more or less work as long as you setup relaying of deltas to the bloom filter
 23 2016-01-11 03:42:41 <jayd3e> jcorgan: I got this https://gist.github.com/jayd3e/c6eaad593b3cc5b7f5e1
 24 2016-01-11 03:42:46 <jayd3e> in the debug
 25 2016-01-11 03:47:31 <dgenr8> kk. you send a packet per tx and call that a win versus a call to .contains() that returns false virtually every time
 26 2016-01-11 05:14:04 <Luke-Jr> hm, the new CTxMemPoolEntry priority calculation is actually more broken than I thought
 27 2016-01-11 06:02:48 <btcdrak> Luke-Jr: explain
 28 2016-01-11 06:04:04 <Luke-Jr> btcdrak: it's an off-by-one because it uses the current tip's height rather than the next one
 29 2016-01-11 06:04:46 <Luke-Jr> so not a complete disaster, but would mean priority-mined transactions wait an additional block
 30 2016-01-11 06:05:19 <Luke-Jr> I'll probably just throw the fix (and rpc test) on #7149
 31 2016-01-11 06:47:55 <Lightsword> capabilities.
 32 2016-01-11 06:47:55 <Lightsword> Does it look like anyone is going to step up to maintain the relay network codebase or an alternative since BlueMatt is no longer maintaining it? If it shuts down without a viable replacement mining decentralization could be seriously damaged as it would be very difficult for smaller pools to compete. I would be willing to run the server infrastructure if needed but maintaining the codebase is a different matter that is currently beyond my
 33 2016-01-11 06:51:44 <Luke-Jr> ._.
 34 2016-01-11 06:52:00 <Luke-Jr> Lightsword: the fact that the relay network is relied on means mining decentralisation is *already* seriously damaged
 35 2016-01-11 06:52:13 <Lightsword> Luke-Jr, I don’t disagree
 36 2016-01-11 06:52:23 <Luke-Jr> I didn't ask BlueMatt, but I suspect that's part of why he no longer wishes to maintain it..
 37 2016-01-11 06:52:44 <Lightsword> Luke-Jr, I don’t know what other options we have in the near term though
 38 2016-01-11 06:53:40 <Lightsword> I think right now relay network is the only way blocks are getting through the GFW in any reasonable amount of time
 39 2016-01-11 06:55:09 <Lightsword> I’m worried that even the increase from SegWit would be too much to handle without relay network.
 40 2016-01-11 06:55:25 <Luke-Jr> well, that much is obvious
 41 2016-01-11 06:55:31 <Luke-Jr> we can't even hit 1 MB without it IMO
 42 2016-01-11 06:55:49 <Lightsword> Luke-Jr, what would you suggest then?
 43 2016-01-11 06:56:08 <Luke-Jr> Lightsword: getting miners to stop making big blocks
 44 2016-01-11 06:56:21 <Luke-Jr> blockmaxsize=500000
 45 2016-01-11 06:56:48 <Lightsword> Luke-Jr, that doesn’t sound likely….and the Chinese pools don’t care because they will just mine on headers
 46 2016-01-11 06:57:11 <Luke-Jr> well, maybe Bitcoin won't survive 2016. we'll see I guess.
 47 2016-01-11 06:57:58 <Luke-Jr> another possibility is that it becomes a China-only system
 48 2016-01-11 06:58:19 <Luke-Jr> at least for mining
 49 2016-01-11 07:02:05 <Lightsword> Luke-Jr, that’s not good….we need some sort of solution here, the chinese pools aren’t intentionally hurting other pools but they are responding to political pressure to mine full blocks and I don’t see that changing anytime soon
 50 2016-01-11 07:02:40 <Luke-Jr> Lightsword: unfortunately, need of a solution does not give rise to actually having a solution :/
 51 2016-01-11 07:03:07 <Luke-Jr> I mean, 0.12 will hopefully make serious improvements in CPU time
 52 2016-01-11 07:03:12 <Luke-Jr> but I don't know if that will be enough
 53 2016-01-11 07:03:49 <Lightsword> CPU is already a small source of delay from my profiling, the GFW is the largest source of delay
 54 2016-01-11 07:04:01 <Luke-Jr> given unlimited dev time, we could experiment with UDP block relay to cross GFW
 55 2016-01-11 07:04:12 <Luke-Jr> Lightsword: even over the p2p network?
 56 2016-01-11 07:04:31 <Lightsword> Luke-Jr, especially over the p2p network from what I can tell
 57 2016-01-11 07:05:15 <Luke-Jr> Lightsword: get Bitmain to put one of their devs to work on this? :P
 58 2016-01-11 07:06:05 <Lightsword> Luke-Jr, do you want all pool nodes to get hacked from a vulnerability? :P
 59 2016-01-11 07:06:41 <Lightsword> Luke-Jr, anyways I think we need to solve this before SegWit is deployed
 60 2016-01-11 07:07:38 <Luke-Jr> Lightsword: as long as they follow Core's peer review process, I doubt they can get a vuln in accidentally
 61 2016-01-11 07:08:06 <Luke-Jr> Lightsword: what if segwit is deployed with a soft-limit of 1 MB?
 62 2016-01-11 07:08:23 <Luke-Jr> eg, reject blockmaxsize >1000000 in the software, but not as a consensus rule
 63 2016-01-11 07:08:51 <Lightsword> Luke-Jr, if it’s not a consensus rule the pools will very likely override it, they already do with the soft blocksize limit
 64 2016-01-11 07:09:04 <Luke-Jr> :/
 65 2016-01-11 07:09:14 <Lightsword> Luke-Jr, I don’t think bitmain knows what peer review is....
 66 2016-01-11 07:09:25 <Luke-Jr> Lightsword: what if the block relay network censors blocks >1MB? :P
 67 2016-01-11 07:09:48 <Lightsword> Luke-Jr, won’t help, because the chinese pools will just mine on headers
 68 2016-01-11 07:09:54 <Luke-Jr> :|
 69 2016-01-11 07:10:34 <Lightsword> Luke-Jr, it’s not the Chinese pools that benefit from relay network it is everyone else
 70 2016-01-11 07:10:52 <Lightsword> the Chinese pools are being nice though and running it so as not to hurt other pools
 71 2016-01-11 07:16:49 <CodeShark> the "let's raise the block size limit" meme is political at this point, unfortunately
 72 2016-01-11 07:17:56 <CodeShark> on purely technical grounds I wouldn't see any rush to raise it...but certain people have been making a stink about it which has completely turned priorities upside down
 73 2016-01-11 07:18:14 <CodeShark> This is the sad reality
 74 2016-01-11 07:18:49 <Lightsword> CodeShark, I agree, at this point we need something to hold mining decentralization together until we have better options
 75 2016-01-11 07:19:10 <CodeShark> Had we been focusing on actual improvements to bitcoin we might now be in a position where it's safe to raise the limit
 76 2016-01-11 07:19:14 <Lightsword> relay network is what we have right now but if it’s going to be shut down before SegWit we are IMO screwed
 77 2016-01-11 07:19:28 <aj> Lightsword: "hold decentralisation together" is an impressively mixed metaphor :)
 78 2016-01-11 07:19:29 <CodeShark> Segwit is one such improvement
 79 2016-01-11 07:19:41 <Luke-Jr> aj: lol
 80 2016-01-11 07:19:51 <CodeShark> :)
 81 2016-01-11 07:19:57 <Lightsword> aj, yeah, it’s the only thing enabling smaller pools to be viable though
 82 2016-01-11 07:22:13 <CodeShark> Then we need someone to take over the relay network
 83 2016-01-11 07:23:09 <Luke-Jr> tempted to suggest we find someone who can be expected to abuse it to censor illegal activity or something that encourages obsoleting it ;)
 84 2016-01-11 07:23:23 <Lightsword> CodeShark, I agree, I would if my c++ skills were up to it but the best I can offer is infrastructure operations
 85 2016-01-11 07:23:33 <Luke-Jr> right now, people apparently don't believe it's possible
 86 2016-01-11 07:23:40 <Luke-Jr> C++? isn't it Java?
 87 2016-01-11 07:23:53 <Lightsword> Luke-Jr, it hasn’t been java for ages
 88 2016-01-11 07:24:01 <Luke-Jr> the server end?
 89 2016-01-11 07:24:03 <Lightsword> both
 90 2016-01-11 07:24:09 <Lightsword> it’s all c++ now
 91 2016-01-11 07:24:32 <Lightsword> https://github.com/TheBlueMatt/RelayNode/tree/master/c%2B%2B
 92 2016-01-11 07:24:36 <Luke-Jr> does it actually need any code changes?
 93 2016-01-11 07:24:48 <Lightsword> Luke-Jr, I think it does for SegWit
 94 2016-01-11 07:24:54 <Luke-Jr> oh, right
 95 2016-01-11 07:25:21 <Luke-Jr> is Coinbase the best way to sell all my bitcoins?
 96 2016-01-11 07:25:23 <Luke-Jr> :P
 97 2016-01-11 07:25:31 <Lightsword> .....
 98 2016-01-11 07:25:44 <Luke-Jr> joking
 99 2016-01-11 11:33:50 <fredrin> Is there a list of segnet testnet nodes?
100 2016-01-11 12:26:11 <jl2012> We are migrating to segwit2 branch
101 2016-01-11 16:07:22 <skyzer> sorry if i'm behind segwit details, but i haven't seen anything about what web wallets need to do to use segwit functionality. basically my webwallet uses now 'sendmany' api call to do sendouts. With segwit do I have to use some new call or not?
102 2016-01-11 16:13:28 <phantomcircuit> skyzer, nothing
103 2016-01-11 16:13:38 <skyzer> thx
104 2016-01-11 16:31:52 <Chris_Stewart_5> Why aren't signatures validated when you are syncing with the blockchain for the first time?
105 2016-01-11 16:42:10 <sipa> Chris_Stewart_5: speed
106 2016-01-11 16:42:22 <sipa> Chris_Stewart_5: the software has built-in checkpoints
107 2016-01-11 16:42:46 <sipa> which we're trying to grt rid of, as they confuse people's understanding of the security model
108 2016-01-11 16:45:15 <phantomcircuit> Chris_Stewart_5, signatures above 295000 are validated, but not below because of speed as sipa said
109 2016-01-11 16:50:58 <Chris_Stewart_5> sipa: phantomcircuit is this the most up to date bip wrt segwit
110 2016-01-11 16:51:00 <Chris_Stewart_5> https://github.com/CodeShark/bips/blob/segwit/bip-codeshark-jl2012-segwit.mediawiki
111 2016-01-11 16:51:33 <CodeShark> It's about to be updated quite a bit
112 2016-01-11 16:51:41 <jl2012> wait a moment
113 2016-01-11 16:52:46 <Chris_Stewart_5> CodeShark: as in this week or as in a few hours? Also is there going to be anything included about versions of Script?
114 2016-01-11 16:53:36 <CodeShark> As in a few minutes, I think ;)
115 2016-01-11 16:53:49 <Chris_Stewart_5> Ok thanks :-).
116 2016-01-11 16:54:04 <jl2012> Chris_Stewart_5: https://github.com/bitcoin/bips/pull/277
117 2016-01-11 16:54:21 <CodeShark> A few seconds :)
118 2016-01-11 17:02:12 <Chris_Stewart_5> When executing a pay-to-pubkey script, if OP_EQUALVERIFY fails, it is not neccessary to run the OP_CHECKSIG right?
119 2016-01-11 17:02:40 <Chris_Stewart_5> sorry pay-to-pubkey-hash
120 2016-01-11 17:02:57 <jl2012> yes, same as non-segwit tx
121 2016-01-11 18:01:08 <CodeShark> If any verify op fails, the script fails in its entirety
122 2016-01-11 18:02:54 <Chris_Stewart_5> CodeShark: thanks :-)
123 2016-01-11 18:15:07 <Chris_Stewart_5> Has there been any documentation done for labeling 'consensus critical' parts of the bitcoin repo? Is there a good rule of thumb?
124 2016-01-11 18:17:53 <sipa> Chris_Stewart_5: the consensus subdirectory, script/interpreter, coins.*, parts of main.cpp, ...
125 2016-01-11 18:46:34 <pinhead> question about segwit soft-fork: do segwit transaction scriptPubKey's use a special SIGHASH flag? Is "ANYONE CAN SPEND" a sighash type? or just refers to a Tx with no cryptographic burden on the output?
126 2016-01-11 18:53:38 <sipa> pinhead: anyonecanspend is a property of a scriptpubkey
127 2016-01-11 18:53:56 <sipa> it basically means a scriptPubKey that is ewuivalent to OP_TRUE
128 2016-01-11 18:54:14 <sipa> there is no special sighash
129 2016-01-11 18:54:54 <pinhead> @sipa thanks
130 2016-01-11 22:23:14 <warren> https://testnet-faucet.elementsproject.org/  please donate to this testnet faucet?