1 2017-08-10 00:18:12 <jimpo> Not sure who usually reviews bitcoin.org pull requests, but I would appreciate a review for correctness on https://github.com/bitcoin-dot-org/bitcoin.org/pull/1740
 2 2017-08-10 00:20:02 <wbnns> @jimpo Hey, thanks - we'll check it out.
 3 2017-08-10 03:39:54 <petertodd> /away
 4 2017-08-10 11:14:10 <JackH> there is no RPC for the p2wsh in core yet, right?
 5 2017-08-10 14:36:51 <stevenroose> according to the wiki here
 6 2017-08-10 14:36:53 <stevenroose> https://en.bitcoin.it/wiki/Script#Constants
 7 2017-08-10 14:37:11 <stevenroose> OP_0 doesn't push 0 on the stack like OP_1-OP_16
 8 2017-08-10 14:37:26 <stevenroose> "An empty array of bytes is pushed onto the stack. (This is not a no-op: an item is added to the stack.)"
 9 2017-08-10 14:38:01 <stevenroose> same for OP_FALSE
10 2017-08-10 14:38:26 <stevenroose> does an empty item on the stack count as "false" for OP_IF?
11 2017-08-10 14:44:10 <Chris_Stewart_5> stevenroose: Yes. IIRC any item that is *NOT* OP_1/OP_TRUE counts as false
12 2017-08-10 14:44:57 <stevenroose> Chris_Stewart_5: thanks. kinda weird that OP_0 doesnt put a 0 on the stack, but well
13 2017-08-10 14:45:21 <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 2017-08-10 14:46:53 <Chris_Stewart_5> stevenroose: So here is how a bool is evaluated in Script https://github.com/bitcoin/bitcoin/blob/8c1dbc5e9ddbafb77e60e8c4e6eb275a3a76ac12/src/script/interpreter.cpp#L38
15 2017-08-10 14:47:28 <Chris_Stewart_5> I was wrong by the looks of it wrt to the OP_1/OP_TRUE thing
16 2017-08-10 14:48:39 <Chris_Stewart_5> and I guess that was a tangent to your original question any way :-)
17 2017-08-10 14:52:12 <stevenroose> Chris_Stewart_5: is this channel usually active? didn't want to ask in -wizards
18 2017-08-10 14:55:24 <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
19 2017-08-10 14:57:49 <stevenroose> good, I'll wait
20 2017-08-10 15:06:17 <Chris_Stewart_5> the answer to your question is yes, an empty item on the stack counts as false. see code i linked to
21 2017-08-10 15:06:39 <stevenroose> oh, thanks,looked over the link
22 2017-08-10 15:06:42 <stevenroose> I assumed so though
23 2017-08-10 15:07:11 <stevenroose> Chris_Stewart_5: many thanks :)
24 2017-08-10 15:22:46 <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)?
25 2017-08-10 15:24:15 <dgenr8> You'd want to include unspendable UTXO's
26 2017-08-10 15:36:44 <Chris_Stewart_5> dgenr8: Not sure, what is the benefit of this compared to just syncing sequentially?
27 2017-08-10 15:37:24 <Chris_Stewart_5> and parrellizing the validation of txs instead of the validation of individual utxo states
28 2017-08-10 15:37:41 <Chris_Stewart_5> seems better to me
29 2017-08-10 15:43:08 <dgenr8> You can't parallelize validation of txes because each tx is potentially dependent on previous tx
30 2017-08-10 15:49:08 <Chris_Stewart_5> dgenr8: And why wouldn't that same arguement apply to UTXOs? UTXO validation *is* tx validation
31 2017-08-10 15:49:16 <Chris_Stewart_5> I suppose I meant signature validation
32 2017-08-10 15:50:57 <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.
33 2017-08-10 15:51:31 <Chris_Stewart_5> Sure, but why not just apply that logic on a tx level and save bandwidth?
34 2017-08-10 15:53:09 <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?
35 2017-08-10 15:53:31 <Chris_Stewart_5> Could be, might be better to ask in #bitcoin-core-dev
36 2017-08-10 15:54:29 <dgenr8> An advantage of my suggestion is that each thread only needs a sub-sequence of blocks
37 2017-08-10 15:55:11 <Chris_Stewart_5> what do you mean by sub seqeunce?
38 2017-08-10 15:55:18 <dgenr8> a segment of the chain
39 2017-08-10 15:55:46 <semidef> I have a question about SPV clients and detecting double spends ...
40 2017-08-10 15:55:48 <Chris_Stewart_5> ah. Is the overall goal you are trying to achieve faster IBD?
41 2017-08-10 15:55:54 <dgenr8> yes
42 2017-08-10 15:56:15 <semidef> My understanding is that the SPV client adds its own addresses to the bloom filter ...
43 2017-08-10 15:56:41 <dgenr8> also reindex
44 2017-08-10 15:57:26 <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 ...
45 2017-08-10 15:57:27 <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
46 2017-08-10 15:58:02 <dgenr8> i wondering if its been done before
47 2017-08-10 15:58:12 <Chris_Stewart_5> I would be interested in seeing what they say in #bitcoin-core-dev, try asking there.
48 2017-08-10 15:58:27 <semidef> Let's say the SPV is all sync'ed up. Later, a peer sends it a tx matched by the filter ...
49 2017-08-10 15:59:13 <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?
50 2017-08-10 16:00:04 <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.
51 2017-08-10 16:00:22 <dgenr8> semidef: today, yes. about the most they do is make sure they get it from all peers
52 2017-08-10 16:00:56 <dgenr8> much more is possible
53 2017-08-10 16:02:59 <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.
54 2017-08-10 16:15:21 <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)
55 2017-08-10 16:25:15 <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?
56 2017-08-10 18:30:24 <corinrose_> any thoughts on the subspace messaging protocol? reasons it's not in use?
57 2017-08-10 18:36:37 <dgenr8> semidef: nope
58 2017-08-10 23:30:36 <tachys_> can anyone explain in concrete terms what a witnessScript is?
59 2017-08-10 23:31:50 <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.
60 2017-08-10 23:33:29 <tachys_> from what I can tell, the redeemScript includes the SHA256(witnessScript)