Transcript for #bitcoin-dev 2016/01/11

01:18 Lightsword
02:29 jayd3e how does the client know when a message ends over the wire and another begins?
02:29 jayd3e my version/ping messages are getting intermixed
02:29 sipa messages have a length field
02:30 jcorgan and the next thing you should receive after the length bytes are consumed is another message header
02:30 jayd3e kk so I have something wrong
02:33 dgenr8 since I've never seen it mentioned before, does anyone else see a major drawback of block-level bloom filters?
02:36 phantomcircuit dgenr8, can you specify what you mean exactly?
02:37 dgenr8 the obvious. client now sees no transaction until it is included in a block
02:38 sipa you can still use the bloom approach for lone transactions, as the assymetry argument doesn't apply there
02:38 sipa though it has the same privacy problem
02:47 phantomcircuit dgenr8, you just treat the entire mempool as a giant bloom filter
02:47 phantomcircuit tada!
02:47 phantomcircuit er a giant block
02:47 phantomcircuit *word*
02:49 dgenr8 i perceive that you recognize the infeasibility of that idea
03:07 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
03:07 jayd3e however, I'm not getting a verack back
03:17 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
03:19 jayd3e nice
03:19 jayd3e will do that
03:33 phantomcircuit dgenr8, amusingly no that would actually more or less work as long as you setup relaying of deltas to the bloom filter
03:42 jayd3e jcorgan: I got this https://gist.github.com/jayd3e/c6eaad593b3cc5b7f5e1
03:42 jayd3e in the debug
03:47 dgenr8 kk. you send a packet per tx and call that a win versus a call to .contains() that returns false virtually every time
05:14 Luke-Jr hm, the new CTxMemPoolEntry priority calculation is actually more broken than I thought
06:02 btcdrak Luke-Jr: explain
06:04 Luke-Jr btcdrak: it's an off-by-one because it uses the current tip's height rather than the next one
06:04 Luke-Jr so not a complete disaster, but would mean priority-mined transactions wait an additional block
06:05 Luke-Jr I'll probably just throw the fix (and rpc test) on #7149
06:47 Lightsword capabilities.
06:47 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
06:51 Luke-Jr ._.
06:52 Luke-Jr Lightsword: the fact that the relay network is relied on means mining decentralisation is *already* seriously damaged
06:52 Lightsword
06:52 Luke-Jr I didn't ask BlueMatt, but I suspect that's part of why he no longer wishes to maintain it..
06:52 Lightsword
06:53 Lightsword I think right now relay network is the only way blocks are getting through the GFW in any reasonable amount of time
06:55 Lightsword
06:55 Luke-Jr well, that much is obvious
06:55 Luke-Jr we can't even hit 1 MB without it IMO
06:55 Lightsword Luke-Jr, what would you suggest then?
06:56 Luke-Jr Lightsword: getting miners to stop making big blocks
06:56 Luke-Jr blockmaxsize=500000
06:56 Lightsword
06:57 Luke-Jr well, maybe Bitcoin won't survive 2016. we'll see I guess.
06:57 Luke-Jr another possibility is that it becomes a China-only system
06:58 Luke-Jr at least for mining
07:02 Lightsword
07:02 Luke-Jr Lightsword: unfortunately, need of a solution does not give rise to actually having a solution :/
07:03 Luke-Jr I mean, 0.12 will hopefully make serious improvements in CPU time
07:03 Luke-Jr but I don't know if that will be enough
07:03 Lightsword CPU is already a small source of delay from my profiling, the GFW is the largest source of delay
07:04 Luke-Jr given unlimited dev time, we could experiment with UDP block relay to cross GFW
07:04 Luke-Jr Lightsword: even over the p2p network?
07:04 Lightsword Luke-Jr, especially over the p2p network from what I can tell
07:05 Luke-Jr Lightsword: get Bitmain to put one of their devs to work on this? :P
07:06 Lightsword Luke-Jr, do you want all pool nodes to get hacked from a vulnerability? :P
07:06 Lightsword Luke-Jr, anyways I think we need to solve this before SegWit is deployed
07:07 Luke-Jr Lightsword: as long as they follow Core's peer review process, I doubt they can get a vuln in accidentally
07:08 Luke-Jr Lightsword: what if segwit is deployed with a soft-limit of 1 MB?
07:08 Luke-Jr eg, reject blockmaxsize >1000000 in the software, but not as a consensus rule
07:08 Lightsword
07:09 Luke-Jr :/
07:09 Lightsword
07:09 Luke-Jr Lightsword: what if the block relay network censors blocks >1MB? :P
07:09 Lightsword
07:09 Luke-Jr :|
07:10 Lightsword
07:10 Lightsword the Chinese pools are being nice though and running it so as not to hurt other pools
07:16 CodeShark the "let's raise the block size limit" meme is political at this point, unfortunately
07:17 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
07:18 CodeShark This is the sad reality
07:18 Lightsword CodeShark, I agree, at this point we need something to hold mining decentralization together until we have better options
07:19 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
07:19 Lightsword
07:19 aj Lightsword: "hold decentralisation together" is an impressively mixed metaphor :)
07:19 CodeShark Segwit is one such improvement
07:19 Luke-Jr aj: lol
07:19 CodeShark :)
07:19 Lightsword
07:22 CodeShark Then we need someone to take over the relay network
07:23 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 ;)
07:23 Lightsword CodeShark, I agree, I would if my c++ skills were up to it but the best I can offer is infrastructure operations
07:23 Luke-Jr right now, people apparently don't believe it's possible
07:23 Luke-Jr C++? isn't it Java?
07:23 Lightsword
07:24 Luke-Jr the server end?
07:24 Lightsword both
07:24 Lightsword
07:24 Lightsword https://github.com/TheBlueMatt/RelayNode/tree/master/c%2B%2B
07:24 Luke-Jr does it actually need any code changes?
07:24 Lightsword Luke-Jr, I think it does for SegWit
07:24 Luke-Jr oh, right
07:25 Luke-Jr is Coinbase the best way to sell all my bitcoins?
07:25 Luke-Jr :P
07:25 Lightsword .....
07:25 Luke-Jr joking
11:33 fredrin Is there a list of segnet testnet nodes?
12:26 jl2012 We are migrating to segwit2 branch
16:07 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?
16:13 phantomcircuit skyzer, nothing
16:13 skyzer thx
16:31 Chris_Stewart_5 Why aren't signatures validated when you are syncing with the blockchain for the first time?
16:42 sipa Chris_Stewart_5: speed
16:42 sipa Chris_Stewart_5: the software has built-in checkpoints
16:42 sipa which we're trying to grt rid of, as they confuse people's understanding of the security model
16:45 phantomcircuit Chris_Stewart_5, signatures above 295000 are validated, but not below because of speed as sipa said
16:50 Chris_Stewart_5 sipa: phantomcircuit is this the most up to date bip wrt segwit
16:51 Chris_Stewart_5 https://github.com/CodeShark/bips/blob/segwit/bip-codeshark-jl2012-segwit.mediawiki
16:51 CodeShark It's about to be updated quite a bit
16:51 jl2012 wait a moment
16:52 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?
16:53 CodeShark As in a few minutes, I think ;)
16:53 Chris_Stewart_5 Ok thanks :-).
16:54 jl2012 Chris_Stewart_5: https://github.com/bitcoin/bips/pull/277
16:54 CodeShark A few seconds :)
17:02 Chris_Stewart_5 When executing a pay-to-pubkey script, if OP_EQUALVERIFY fails, it is not neccessary to run the OP_CHECKSIG right?
17:02 Chris_Stewart_5 sorry pay-to-pubkey-hash
17:02 jl2012 yes, same as non-segwit tx
18:01 CodeShark If any verify op fails, the script fails in its entirety
18:02 Chris_Stewart_5 CodeShark: thanks :-)
18:15 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?
18:17 sipa Chris_Stewart_5: the consensus subdirectory, script/interpreter, coins.*, parts of main.cpp, ...
18:46 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?
18:53 sipa pinhead: anyonecanspend is a property of a scriptpubkey
18:53 sipa it basically means a scriptPubKey that is ewuivalent to OP_TRUE
18:54 sipa there is no special sighash
18:54 pinhead @sipa thanks
22:23 warren https://testnet-faucet.elementsproject.org/ please donate to this testnet faucet?