Transcript for #bitcoin-dev 2017/08/10

00:18 jimpo Not sure who usually reviews pull requests, but I would appreciate a review for correctness on
00:20 wbnns @jimpo Hey, thanks - we'll check it out.
03:39 petertodd /away
11:14 JackH there is no RPC for the p2wsh in core yet, right?
14:36 stevenroose according to the wiki here
14:36 stevenroose
14:37 stevenroose OP_0 doesn't push 0 on the stack like OP_1-OP_16
14:37 stevenroose "An empty array of bytes is pushed onto the stack. (This is not a no-op: an item is added to the stack.)"
14:38 stevenroose same for OP_FALSE
14:38 stevenroose does an empty item on the stack count as "false" for OP_IF?
14:44 Chris_Stewart_5 stevenroose: Yes. IIRC any item that is *NOT* OP_1/OP_TRUE counts as false
14:44 stevenroose Chris_Stewart_5: thanks. kinda weird that OP_0 doesnt put a 0 on the stack, but well
14:45 Chris_Stewart_5 Hah, yes it took me a while to grasp that. Let me double check the OP_1/OP_TRUE thing though.
14:46 Chris_Stewart_5 stevenroose: So here is how a bool is evaluated in Script
14:47 Chris_Stewart_5 I was wrong by the looks of it wrt to the OP_1/OP_TRUE thing
14:48 Chris_Stewart_5 and I guess that was a tangent to your original question any way :-)
14:52 stevenroose Chris_Stewart_5: is this channel usually active? didn't want to ask in -wizards
14:55 Chris_Stewart_5 stevenroose: Eh, it's really hit or miss depending on the time zone. There are a few active contributors in here tho
14:57 stevenroose good, I'll wait
15:06 Chris_Stewart_5 the answer to your question is yes, an empty item on the stack counts as false. see code i linked to
15:06 stevenroose oh, thanks,looked over the link
15:06 stevenroose I assumed so though
15:07 stevenroose Chris_Stewart_5: many thanks :)
15:22 dgenr8 Is there code out there that uses N UTXO snapshots to parallelize full blockchain validation (by making considering later chunk success conditional on validation of earlier chunks)?
15:24 dgenr8 You'd want to include unspendable UTXO's
15:36 Chris_Stewart_5 dgenr8: Not sure, what is the benefit of this compared to just syncing sequentially?
15:37 Chris_Stewart_5 and parrellizing the validation of txs instead of the validation of individual utxo states
15:37 Chris_Stewart_5 seems better to me
15:43 dgenr8 You can't parallelize validation of txes because each tx is potentially dependent on previous tx
15:49 Chris_Stewart_5 dgenr8: And why wouldn't that same arguement apply to UTXOs? UTXO validation *is* tx validation
15:49 Chris_Stewart_5 I suppose I meant signature validation
15:50 dgenr8 Everything in chunk 2 can be validated with a snapshot as the starting point. The result is subject to the condition that the snapshot is the end result of validating chunk 1.
15:51 Chris_Stewart_5 Sure, but why not just apply that logic on a tx level and save bandwidth?
15:53 dgenr8 I think your suggestion may also be possible with some fancy improvements to CCoinsView etc to do efficient differential snapshots. Hmm actually ... is it already there?
15:53 Chris_Stewart_5 Could be, might be better to ask in #bitcoin-core-dev
15:54 dgenr8 An advantage of my suggestion is that each thread only needs a sub-sequence of blocks
15:55 Chris_Stewart_5 what do you mean by sub seqeunce?
15:55 dgenr8 a segment of the chain
15:55 semidef I have a question about SPV clients and detecting double spends ...
15:55 Chris_Stewart_5 ah. Is the overall goal you are trying to achieve faster IBD?
15:55 dgenr8 yes
15:56 semidef My understanding is that the SPV client adds its own addresses to the bloom filter ...
15:56 dgenr8 also reindex
15:57 semidef When the SPV first syncs block headers, if it requests block data, it gets filtered blocks with merkle paths and tx data for relevant txs ...
15:57 Chris_Stewart_5 dgenr8: IIRC all blocks are downloaded to disk indepdendently of what point your tx validation is at so if your scheme is faster it would be plausible to do
15:58 dgenr8 i wondering if its been done before
15:58 Chris_Stewart_5 I would be interested in seeing what they say in #bitcoin-core-dev, try asking there.
15:58 semidef Let's say the SPV is all sync'ed up. Later, a peer sends it a tx matched by the filter ...
15:59 semidef The question: Is the SPV depending on the full node peer to not send it tx's that spend outputs not in the UTXO pool?
16:00 semidef That is, it's not up to the SPV to somehow get the tx's that are used as inputs to the new tx, right, and check for double spends itself.
16:00 dgenr8 semidef: today, yes. about the most they do is make sure they get it from all peers
16:00 dgenr8 much more is possible
16:02 semidef dgenr8: Thanks. It's not possible to request an arbitrary tx from the blockchain without issuing new getblocks and getdata requests, right? So it would be difficult to retrieve the inputs to the new tx.
16:15 dgenr8 semidef: it's not easy with the current protocol, but it's not rocket science. satoshi-derive fullnodes have optimized themselves away from this kind of thing (at one time every node had a txindex)
16:25 semidef If the protocol were modified to allow an SPV client to request an arbitrary confirmed tx by txid, would a modern satoshi-derrived full node be able to find it without txindex=1?
18:30 corinrose_ any thoughts on the subspace messaging protocol? reasons it's not in use?
18:36 dgenr8 semidef: nope
23:30 tachys_ can anyone explain in concrete terms what a witnessScript is?
23:31 tachys_ I'm trying to use bitcoinjs-lib to craft a P2WSH address, and it requires the witness script, however I can't tell what that is.
23:33 tachys_ from what I can tell, the redeemScript includes the SHA256(witnessScript)