1 2018-01-24 18:00:15 <jimpo> I've heard some amount of debate over the meaning of "SPV". Is there a generally agreed difference between SPV and other thin/light clients (of the P2P network)?
 2 2018-01-24 18:00:36 <eck> what other thin/light clients?
 3 2018-01-24 18:00:39 <eck> like electrum?
 4 2018-01-24 18:01:58 <jimpo> No, I mean direct clients of the P2P network. So is BIP 37 generally considered SPV (I think I've heard luke-jr disagree with that)? And would the BIP 157 stuff count as SPV or no because it doesn't check Merkle branches?
 5 2018-01-24 18:02:37 <eck> i would consider it spv
 6 2018-01-24 18:02:47 <eck> generally i've seen people use the word to refer to any light client
 7 2018-01-24 18:02:54 <eck> even if it's not an spv client as originally envisioned
 8 2018-01-24 18:07:03 <gmaxwell> jimpo: what you're hearing from luke is some pedantry because what the whitepaper describes in section 8, in the second paragraph part, has never been implemented and can't be efficiently implemented in the bitcoin protocol as is (though we now know how to do it theoretically)
 9 2018-01-24 18:07:32 <gmaxwell> I think the BIP37 stuff is basically orthorgonal.
10 2018-01-24 18:10:16 <gmaxwell> The whitepaper expresses an idea that if there is an invalid block, an honest peer (assuming it has at least one) of a SPV client could tell it about it and it could download the block and check for itself. But because of how the commitments in bitcoin are structured, the minimum amount of data which is sufficient to validate a single block is the whole chain before it.
11 2018-01-24 18:11:21 <eck> are you suggesting there's an alternative way to structure the commitments so you wouldn't have to download the whole chain?
12 2018-01-24 18:11:58 <jimpo> What do you mean that the BIP 37 stuff is orthogonal? It seems to implement the transaction inclusion proofs mentioned in section 8
13 2018-01-24 18:12:47 <gmaxwell> eck: yes.
14 2018-01-24 18:12:56 <jimpo> Not the bloom filter stuff so much, just the merkleblock message
15 2018-01-24 18:13:01 <eck> i was not aware of that, how can i learn more
16 2018-01-24 18:13:43 <gmaxwell> jimpo: I mean what originally imagined was that that the payee would give you the transaction and root, not the p2p network.
17 2018-01-24 18:15:39 <eck> the merkle root at the time the transaction was created?
18 2018-01-24 18:15:54 <gmaxwell> eck: blocks need an additional commitment that gives the height and transaction position for each input of each transaction. They also need an additional commitment to the fees of all transactions and the partial sums of the fees.
19 2018-01-24 18:16:50 <eck> i'm about to board a flight, i'll have to ponder this in the air
20 2018-01-24 18:16:56 <eck> might ask you more about it later
21 2018-01-24 18:41:34 <luke-jr> gmaxwell: it's not pedantry, because "SPV" is used as justification for not using a full node, whereas light wallets today are substantially different enough that Satoshi's claims for SPV don't hold up
22 2018-01-24 18:42:23 <gmaxwell> I agree its an important point for the reason you state it. But it's super not informative to just say "thats not spv" about things. :)
23 2018-01-24 19:13:32 <__jnsmk__> wow I got the resolution to contribute to bitcoin in 2018, looks like I have a lot to learn before I can get started !
24 2018-01-24 23:17:27 <tyranny> https://ptpb.pw/0DA_ > vanity.cpp:38:6: error: ‘bc::wallet’ has not been declared . I use the libbitcoin first time and doing the example from book. What's wrong with it? Tried libbitcoin namespace too
25 2018-01-24 23:17:54 <tyranny> what is the correct way to access that type?
26 2018-01-24 23:34:11 <tyranny> oh. I found out the book has a hell outdated libbitcoin api.