Transcript for #bitcoin-dev 2018/01/24

18:00 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)?
18:00 eck what other thin/light clients?
18:00 eck like electrum?
18:01 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?
18:02 eck i would consider it spv
18:02 eck generally i've seen people use the word to refer to any light client
18:02 eck even if it's not an spv client as originally envisioned
18:07 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)
18:07 gmaxwell I think the BIP37 stuff is basically orthorgonal.
18:10 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.
18:11 eck are you suggesting there's an alternative way to structure the commitments so you wouldn't have to download the whole chain?
18:11 jimpo What do you mean that the BIP 37 stuff is orthogonal? It seems to implement the transaction inclusion proofs mentioned in section 8
18:12 gmaxwell eck: yes.
18:12 jimpo Not the bloom filter stuff so much, just the merkleblock message
18:13 eck i was not aware of that, how can i learn more
18:13 gmaxwell jimpo: I mean what originally imagined was that that the payee would give you the transaction and root, not the p2p network.
18:15 eck the merkle root at the time the transaction was created?
18:15 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.
18:16 eck i'm about to board a flight, i'll have to ponder this in the air
18:16 eck might ask you more about it later
18:41 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
18:42 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. :)
19:13 __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 !
23:17 tyranny > 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
23:17 tyranny what is the correct way to access that type?
23:34 tyranny oh. I found out the book has a hell outdated libbitcoin api.